Consensus Series: Thunderella – ThunderCore

0 3


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.

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

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.

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:

  1. The active accelerator signs a proposal (block) to be added to the blockchain (linearly ordered log) and sends it to the committee.

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.
  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.

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.

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.

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!

You might also like

Pin It on Pinterest

Share This

Share this post with your friends!

WhatsApp chat