Why trusted execution environments will be integral to proof-of-stake blockchains

We are excited to bring Transform 2022 back in-person July 19 and virtually July 20 – 28. Join AI and data leaders for insightful talks and exciting networking opportunities. Register today!


Ever since the invention of Bitcoin, we have seen a tremendous outpouring of computer science creativity in the open community. Despite its obvious success, Bitcoin has several shortcomings. It is too slow, too expensive, the price is too volatile and the transactions are too public.

Various cryptocurrency projects in the public space have tried to solve these challenges. There is particular interest in the community to solve the scalability challenge. Bitcoin’s proof-of-work consensus algorithm supports only seven transactions per second throughput. Other blockchains such as Ethereum 1.0, which also relies on the proof-of-work consensus algorithm, also demonstrate mediocre performance. This has an adverse impact on transaction fees. Transaction fees vary with the amount of traffic on the network. Sometimes the fees may be lower than $1 and at other times higher than $50.

Proof-of-work blockchains are also very energy-intensive. As of this writing, the process of creating Bitcoin consumes around 91 terawatt-hours of electricity annually. This is more energy than used by Finland, a nation of about 5.5 million.

While there is a section of commentators that think of this as a necessary cost of protecting the entire financial system securely, rather than just the cost of running a digital payment system, there is another section that thinks that this cost could be done away with by developing proof-of-stake consensus protocols. Proof-of-stake consensus protocols also deliver much higher throughputs. Some blockchain projects are aiming at delivering upwards of 100,000 transactions per second. At this performance level, blockchains could rival centralized payment processors like Visa.  

Figure 1: Validators

The shift toward proof-of-stake consensus is quite significant. Tendermint is a popular proof-of-stake consensus framework. Several projects such as Binance DEX, Oasis Network, Secret Network, Provenance Blockchain, and many more use the Tendermint framework. Ethereum is transitioning toward becoming a proof-of-stake-based network. Ethereum 2.0 is likely to launch in 2022 but already the network has over 300,000 validators. After Ethereum makes the transition, it is likely that several Ethereum Virtual Machine (EVM) based blockchains will follow suit. In addition, there are several non-EVM blockchains such as Cardano, Solana, Algorand, Tezos and Celo which use proof-of-stake consensus.  

Proof-of-stake blockchains introduce new requirements

As proof-of-stake blockchains take hold, it is important to dig deeper into the changes that are unfolding.  

First, there is no more “mining.” Instead, there is “staking.” Staking is a process of putting at stake the native blockchain currency to obtain the right to validate transactions. The staked cryptocurrency is made unusable for transactions, i.e., it cannot be used for making payments or interacting with smart contracts. Validators that stake cryptocurrency and process transactions earn a fraction of the fees that are paid by entities that submit transactions to the blockchain. Staking yields are often in the range of 5% to 15%.  

Second, unlike proof-of-work, proof-of-stake is a voting-based consensus protocol. Once a validator stakes cryptocurrency, it is committing to staying online and voting on transactions. If for some reason, a substantial number of validators go offline, transaction processing would stop entirely. This is because a supermajority of votes are required to add new blocks to the blockchain. This is quite a departure from proof-of-work blockchains where miners could come and go as they pleased, and their long-term rewards would depend on the amount of work they did while participating in the consensus protocol. In proof-of-stake blockchains, validator nodes are penalized, and a part of their stake is taken away if they do not stay online and vote on transactions.  

Figure 2: Honest voting vs. dishonest voting.

Third, in proof-of-work blockchains, if a miner misbehaves, for example, by trying to fork the blockchain, it ends up hurting itself. Mining on top of an incorrect block is a waste of effort. This is not true in proof-of-stake blockchains. If there is a fork in the blockchain, a validator node is in fact incentivized to support both the main chain and the fork. This is because there is always some small chance that the forked chain turns out to be the main chain in the long term. 

Punishing blockchain misbehavior

Early proof-of-stake blockchains ignored this problem and relied on validator nodes participating in consensus without misbehaving. But this is not a good assumption to make in the long term and so newer designs introduce a concept called “slashing.” In case a validator node observes that another node has misbehaved, for example by voting for two separate blocks at the same height, then the observer can slash the malicious node. The slashed node loses part of its staked cryptocurrency. The magnitude of a slashed cryptocurrency depends on the specific blockchain. Each blockchain has its own rules.  

Figure 3: Misbehaving validators are slashed by other validators for reasons such as “Attestation rule offense” and “Proposer rule offense”

Fourth, in proof-of-stake blockchains, misconfigurations can lead to slashing. A typical misconfiguration is one where multiple validators, which may be owned or operated by the same entity, end up using the same key for validating transactions. It is easy to see how this can lead to slashing.  

Finally, early proof-of-stake blockchains had a hard limit on how many validators could participate in consensus. This is because each validator signs a block two times, once during the prepare phase of the protocol and once during the commit phase. These signatures add up and could take up quite a bit of space in the block. This meant that proof-of-stake blockchains were more centralized than proof-of-work blockchains. This is a grave issue for proponents of decentralization and consequently, newer proof-of-stake blockchains are shifting towards newer crypto systems that support signature aggregation. For example, the Boneh-Lynn-Shacham (BLS) cryptosystem supports signature aggregation. Using the BLS cryptosystem, thousands of signatures can be aggregated in such a way that the aggregated signature occupies the space of only a single signature.  

How trusted execution environments can be integral to proof-of-stake blockchains  

While the core philosophy of blockchains revolves around the concept of trustlessness, trusted execution environments can be integral to proof-of-stake blockchains.  

Secure management of long-lived validator keys  

For proof-of-stake blockchains, validator keys need to be managed securely. Ideally, such keys should never be available in clear text. They should be generated and used inside trusted execution environments. Also, trusted execution environments need to ensure disaster recovery, and high availability. They need to be always online to cater to the demands of validator nodes.  

Secure execution of critical code

Trusted execution environments today are capable of more than secure key management. They can also be used to deploy critical code that operates with high integrity. In the case of proof-of-stake validators, it is important that conflicting messages are not signed. Signing conflicting messages can lead to economic penalties according to several proof-of-stake blockchain protocols. The code that tracks blockchain state and ensures that validators do not sign conflicting messages needs to be executed with high integrity.  

Conclusions

The blockchain ecosystem is changing in very fundamental ways. There is a large shift toward using proof-of-stake consensus because it offers higher performance and a lower energy footprint as compared to a proof-of-work consensus algorithm. This is not an insignificant change. 

Validator nodes must remain online and are penalized for going offline. Managing keys securely and always online is a challenge. 

To make the protocol work at scale, several blockchains have introduced punishments for misbehavior. Validator nodes continue to suffer these punishments because of misconfigurations or malicious attacks on them. To retain the large-scale distributed nature of blockchains, new cryptosystems are being adopted. Trusted execution environments that offer disaster recovery, high availability, support new cryptosystems such as BLS and allow for the execution of custom code with high integrity are likely to be an integral part of this shift from proof-of-work to proof-of-stake blockchains.

Pralhad Deshpande, Ph.D., is senior solutions architect at Fortanix.

DataDecisionMakers

Welcome to the VentureBeat community!

DataDecisionMakers is where experts, including the technical people doing data work, can share data-related insights and innovation.

If you want to read about cutting-edge ideas and up-to-date information, best practices, and the future of data and data tech, join us at DataDecisionMakers.

You might even consider contributing an article of your own!

Read More From DataDecisionMakers