Contents
Your subscription could not be saved. Please try again.
Thanks for subscribing.
Hyperchains - our scaling solution for Stacks designed for high throughput, low latency workloads has been live on testnet for several months. We recently concluded an NFT use case simulation. This is a recap of how far we’ve come, our immediate priorities, mainnet readiness and future roadmap.
Note: hyperchains have been renamed subnets, due to the trademark for "hyperchains" already being registered. Learn more here.
Earlier this week, we announced that this scaling solution for Stacks needs a new name due to "hyperchains" already being trademarked. You can learn more about that announcement here and why we favour the new name "subnets." We are letting the community weigh in on the issue, and for this post, we will continue to refer to this upcoming solution as "hyperchains."
As discussed in our last hyperchains update, hyperchains have been live on testnet since June 2022. Since then, we launched an NFT use case to highlight the deposit-withdraw features on hyperchains. Watch a new video on Hiro's YouTube channel to see how to interact with an NFT on a hyperchain.
This use case is live only on devnet—a local Stacks network spun up inside Clarinet. For now, the NFT use case is in a controlled environment to help us set performance benchmarks for both throughput and latency.
Our initial goal to speed up the hyperchain has been to reduce confirmation times. One of the significant performance benefits of hyperchains is that because they functionally have a single miner (whether they truly have a single miner or a federated set), microblocks are guaranteed to be confirmed by the subsequent anchor block. This means that transactions are confirmed much faster than in the stacks-node: hyperchain microblocks count as confirmed blocks in hyperchains.
In the current implementation, we are diving deep into how microblock production works and if a transaction is broadcast to a hyperchain mempool, how quickly it is included in a microblock. We are also evaluating the dependency on Stacks block confirmation times and Bitcoin confirmation times. This benchmarking will also assess how often the hyperchain miner's block commit possibly misses the intended Stacks block. With this data, the logical next step is to improve the performance based on the benchmarks.
To paraphrase Arthur C. Clarke - We are relentless in our commitment to test the possible and to go beyond into the impossible.
Hyperchain performance is ultimately dependent on hyperchain block production and confirmation speed. Performance might also be influenced by MARF improvements- precisely the pace of operations in the SortitionDB and ClarityDB, both of which use the MARF.
Hyperchains will essentially be free of forks, so there is less need to use the MARF in its current form. The purpose of the MARF is to allow nodes to quickly validate the value of a particular key in ANY fork. Replacing the MARF with a flat key-value store will lead to considerable speedups.
We are replacing the MARF in hyperchains to use a flat key-value store, implemented with an SQLite database. The key/value updates with each new block, and those values will be stored in the database. As a result, when a new block is created:
Our previous version of the hyperchains contract validated the anchor block submission by allowing any miner to commit an anchor block. However, to support BFT consensus, the block commit public function has been updated to only allow a commit to succeed if it was signed by the threshold number of miners.
We added a new RPC interface for receiving block proposals to the hyperchain nodes to allow the participating miners to accept the proposed block data and provide their signatures over that data. The signature is then verified as coming from one of the other miners.
Block (and microblock) assembly in a hyperchain is a process that will involve one leader. This leader assembles the block and then proposes it to the other members of the mining coalition. This leader (or, failing that, any other members) can issue the block commit when enough members have signed. This leader is at the heart of the BFT algorithm, selecting and rotating when necessary. This Leader Selection doesn't modify much of the behaviour of the neon_node; the leader is going to act the same as the current miner, except for the changes in the other multi-party mining issues.
Other notable changes associated with this:
Sender validation to the block proposal RPC: this ensures that the proposal submitted was created by the multi-party leader. This is necessary to prevent the block proposal interface from being a denial-of-service vector.
Multi-party anchor block signatures: multi-party block commitments via a multi-party contract. The multi-party contract checks the transaction sender and the supplied signatures to confirm that at least the required-signers count of approvals has been achieved before using a block commit.
The current implementation of microblocks assumes a single-signer setup. The hyperchain node is being updated to support federated miners producing microblocks.
We also recently released 4 new Clarinet features that offer hyperchains functionality. Namely, the command clarinet integrate lets developers spin up a hyperchain node and test locally. We'd love your help testing hyperchains. To try the NFT use case on devnet, please follow the instructions on GitHub here. To spin up your own hyperchain node, follow these instructions. If you experience difficulties in the process, open an issue on GitHub.
Spinning up this demo and a hyperchain node requires familiarity with Clarity contracts and the Stacks blockchain. If you're new to the Stacks ecosystem, you may want to start with Stacks documentation and the Stacks blockchain GitHub.
We know everyone is excited about scaling solutions for Stacks. Bring your questions and join the conversation on August 11th 3pm EST for the Hyperchains AMA on Twitter (you will find the event at our account @hirosystems). You can submit questions live in the Twitter Spaces event or ahead of time on the Hyperchains AMA Discord channel. Set a reminder for the event here.
We have delivered the core functionality aspects of a hyperchain so far and made lots of progress to reach this point, and as we enter the next phase in hyperchains development, there are several projects we are working on, including:
That’s it for this update. We’ll share more progress on hyperchains in the coming weeks. If you are interested in learning more about our progress, join the Hyperchains AMA on August 11th at 3pm EST on Twitter. Set a reminder for the event here and submit your questions ahead of time on the Hyperchains AMA Discord channel.