Consensus Series: Thunderella

Last week, we covered Proof-of-Stake. This week we’ll go over the Thunderella consensus protocol. While this article is standalone, it’s highly recommended that you are familiar with the content covered in our preliminaries and PBFT posts.

Thunderella

The major innovation of the Thunderella consensus protocol is the combination of classical consensus with Nakamoto’s chain-style consensus, which brings the best of both worlds.

Classical protocols are extremely fast at a small scale. Transactions can be confirmed at speeds approaching centralized deployments. However, these protocols can be complex, difficult to implement, and do not scale in number of participants. In contrast, Nakamoto protocols are simple, have additional robustness properties, can scale in participants indefinitely, but take minutes to confirm transactions with high probability.

Recall in our description of PBFT, a view-change is executed if no proposal is seen from the primary for a sufficiently long period of time. During a view-change, nodes exchange messages to agree upon the following:

1. A view change has indeed happen
2. What the state of the network is just before the switch

In effect, nodes are coming to consensus without a primary proposer. The key observation for the Thunderella protocol is that we can rely on a Proof-of-Work slow-chain for consensus when it comes to 1. and 2. which we’ll call fallback and recovery respectively.

The Protocol

Assume a prior agreed upon set of accelerators and committee members (same as proposers and voters). A simplified version of the Thunderella protocol, which creates blocks on the fast-path can be described simply as follows:

Fast-Path

1. The active accelerator signs a proposal (block) to be added to the blockchain (linearly ordered log) and sends it to the committee.
2. Each committee member votes on the proposal by signing it if it is a valid extension of their blockchain and returns their vote to the accelerator.
3. Upon collecting ¾ of the committee’s votes, the active accelerator combines them into a notarization and broadcasts it.
4. If a notarization for a proposal is observed, that proposal is finalized and part of the immutable history of the blockchain.

Slow-Chain

The slow-chain is another Proof-of-Work blockchain where consistency and liveness are guaranteed. Here when we say something is “seen on the slow-chain” we mean that it is safe to assume (by the finality assumptions of the slow-chain blockchain) that all participants of the network have also seen it. In practice, this may mean waiting a few blocks for probabilistic finality.

1. Every 100th fast-path blocks (say), a hash and notarization of the block must be posted to the slow-chain in a timely manner. This is called an alive message.
2. This can be accomplished by including the alive message payload in the slow-chain transaction data field (say).
3. Note, that anyone can post this alive message and alive messages can not be forged as they require a valid notarization of the block.

Fallback and Recovery

1. When no new alive message is seen on the slow-chain after 20 slow-chain blocks (say) the fast-path is down and recovery begins. Committee members stop signing new proposals.
2. Recovery lasts for 10 slow-chain blocks (say) during which time participants will post a valid most recently seen block hash and notarization to the slow-chain.
3. After recovery, the next accelerator chosen based on a round robin policy (say) comes online and proposes from the latest block reported during the recovery phase.

Yell Messages

As an additional tool for ensuring censorship resistance and liveness, Thunderella defines yell messages. Yell messages are fast-path transactions that are sent to the slow-chain. These transactions are included in the fast-path by rules defined by the protocol (rather than the propose-notarize process for regular transactions). Thus even during recovery, a finalized yell message on the slow-chain is also a finalized fast-path transaction.

1. A user can wrap a valid signed fast-path transaction into a yell message (in the data field of a slow-chain transaction say) and post to the slow-chain.
2. When the slow-chain block containing the yell message is finalized, committee members expect to see this transaction appear on the fast-path. If it does not show up, fallback is triggered and the protocol enters recovery.
3. During recovery, each node on the network extends their blockchain from the last fast-path block based on yell messages they see on the slow-chain according a deterministic set of rules. Since we can always rely on PoW consensus on the slow-chain, every node independently arrives at the same extended fast-path.
4. Upon recovery, the new accelerator must extend from the extended fast-path chain in the previous step.

In the full protocol description, Thunderella goes even faster by allowing for multiple outstanding proposals (blocks that are not notarized). This trick is called proposal pipelining and we’ll see it again when we cover PaLa later on. The full Thunderella protocol is described in the Thunderella litepaper.

Takeaway

As Thunderella leverages a synchronous Proof-of-Work blockchain with ½ fault tolerance for the slow path, the voting threshold is ¾ which gives 50% fault tolerance for consistency on the partially synchronous fast path. Typically a partially asynchronous could achieve at best ⅓ fault tolerance for liveness as explained previously. However, by leveraging a synchronous slow-chain for recovering from a failed accelerator, Thunderella also achieves ½ fault tolerance for liveness. Note that the slow-chain need not be a PoW chain. However, the security of the protocol inherits the security of the underlying chain. For example, using a partially synchronous classical consensus slow-chain will result in the protocol being partially synchronous and having up to only ⅓ fault tolerance.

In practice, Thunderella provides confirmation after just 1 round of votes! With a PoW slow chain such as Ethereum, recovery may take several minutes where progress is slow and expensive. If the fast-path is reliable, recovery is rarely needed. The slow recovery issue can be addressed by using a faster classical consensus blockchain for the slow chain. While it was originally intended to be used as a layer 1 scaling solution for ThunderCore, Thunderella may be even more appropriate for a layer 2 side chain with an appropriate cross-chain bridge between the fast-path and slow-chain. For example, multiple untrusted operators (perhaps chosen through staking an ERC20 token) could use Thunderella as a Plasma side chain and have one message round confirmation during fast-path operation!

We hope this post was informative! Come back next week where we’ll go over the PaLa consensus protocol which is used by ThunderCore’s public blockchain.