The Liquid community has long requested a more lightweight Elements node client for better compatibility with cheaper off-the-shelf DIY hardware. Elements 21.1.1 starts to deliver on that promise by optimizing Liquid's block headers, and we plan to optimize node efficiency even further in future releases.

Under 21.1.1, internal benchmarks show upwards of a 50% reduction in memory usage when running liquidv1. By trimming some of the larger header fields kept in memory, we were able to reduce the overhead. With these new optimizations, we are confident users can now harness the full Bitcoin stack (i.e., Bitcoin, Core Lightning, and Liquid nodes) concurrently on little more power than a 8GB Raspberry Pi.

Elements 22.1.1 also comes packed with maintenance updates and smaller fixes, including:

  • Correct help messages for getsidechaininfo RPC and testproposedblock
  • Obscure mainchain RPC fields in the logs
  • Allow deploying Regtest networks with Pay-to-Witness-Script-Hash (P2WSH) peg-ins
  • Fix underflow when blocks are ahead of headers

The team also made several amends to assets via the elements-qt, including making the "use available balance" keep a selected asset, instead of defaulting back to L-BTC.

To dig into the finer points of the release, review the full changelog, and tell us what you like or what we could improve on by reaching out to us on the Developers page of the Build On L2 (BOL2) community.

Optimizing Elements (It’s All in the Headers)

We wanted to explain further the optimizations that enabled the reduction in memory overhead in Elements 21.1.1.

As a part of the behavior inherited from Bitcoin Core, all the block headers (block metadata) in Elements are kept in memory all the time. In Bitcoin, those headers are relatively small, so they do not have much of an effect, but in Elements, the header is much larger due to the faster, one-minute block times, DynaFed and block signature information. Currently, the Liquid blockchain (liquidv1)contains around 3x the number of blocks in Bitcoin.

Under the new trim_headers parameters (see PR #1190), we removed some of the larger header fields to reduce the overall memory overhead, but only after sufficient block time has passed since they are unlikely to be needed. This has a particular effect during IBD (Initial Block Download) because normally (Bitcoin and non-trim_headers mode), headers and blocks are downloaded independently, with the only requirement that headers are ahead of blocks, so that blocks can be validated when they arrive; this is not really an option for trim_headers mode, because either a) you trim and then cannot validate the block, or b) you do not trim and use as much memory as before. Our solution is to download headers and blocks more in "lockstep," which means that headers cannot get too far ahead of the blocks like they used to.

By trimming some of these unneeded fields from the headers kept in memory, we were able to reduce the overhead. The data on disk remains unchanged, however, allowing users to freely go back and forth between having the parameters or not.

Memory consumption post-IBD sync with tests executed on 8GB RAM, 4GB Swap VM.

Join BOL2 and Request New Features

The Elements platform remains a free, open-source download for anyone to set up their own sidechain solution on top of Bitcoin. Since its initial release, we have added new opcodes and functionality like Confidential Transactions and Issued Assets. Some of these upgrades to Elements were even implemented on Bitcoin, including OP_CSV and Segregated Witness (SegWit). Simplicity, a next-gen smart contracting language slated for release later this year on Liquid, is another possible upgrade to Bitcoin in the future.

We want to continue this legacy and welcome any feedback from the Bitcoin community on new opcodes and features to add to Liquid. The Build On L2 (BOL2) community platform is the best way to reach the engineering team and engage with other Liquid power users to discuss new ideas and projects.

We look forward to your questions and having a conversation there!

This article was originally posted on the Blockstream blog at: