Why trusted execution environments will be an integral part of proof-of-game blockchains

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’s too slow, too expensive, the price is too volatile and the transactions are too public.

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

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

While there is a section of commentators who think of it as an essential cost to protect the entire financial system securely, rather than just the cost of running a digital payment system, there is another section that thinks that these costs have been eliminated can be through the development of proof-of-game consensus protocols. Proof-of-game consensus protocols also yield much higher throughput. Some blockchain projects aim to deliver more than 100,000 transactions per second. At this level of performance, blockchains can compete with centralized payment processors such as Visa.

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

Proof-of-game blockchains introduce new requirements

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

First, there is no more “mining”. Instead, there is a “strike”. Strike is a process of putting the indigenous blockchain currency at stake to gain the right to ratify transactions. The cryptocurrency is rendered unusable for transactions, that is, it cannot be used for making payments or interacting with smart contracts. Validators who hold crypto-currency and process transactions earn a fraction of the fees paid by entities that submit transactions to the blockchain. Strike returns are often in the range of 5% to 15%.

Second, unlike proof-of-work, proof-of-play is a voice-based consensus protocol. Once a validator uses cryptocurrency, it commits to staying online and voting on transactions. If for some reason a significant number of validators go offline, transaction processing will stop completely. This is because a super majority of votes is needed to add new blocks to the blockchain. This is quite a departure from proof-of-work blockchains where miners can come and go as they please, and their long-term rewards will depend on the amount of work they did while participating in the consensus protocol. In proof-of-stake blockchains, validator nodes are penalized, and some of their interest is taken away if they do not stay online and vote on transactions.

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 a wrong block is a waste of effort. This is not true in proof-of-game blockchains. If there is a fork in the block chain, a validator node is actually prompted to support both the main chain and the fork. This is because there is always a small chance that the forked chain will turn out to be the main chain in the long run.

Punishment blockchain misconduct

Early proof-of-game blockchains ignored this problem and relied on validator nodes participating in consensus without misbehavior. But this is not a good assumption to make in the long run and that’s why new designs introduce a concept called “slashing.” In the event that a validator node observes that another node is misbehaving, for example by voting for two separate blocks at the same height, then the observer can cut the malicious node. The truncated node loses part of its cryptocurrency. The size of a cut cryptocurrency depends on the specific blockchain. Each blockchain has its own rules.

Fourth, in proof-of-stake blockchains, misconfigurations can lead to slashing. A typical malfunction is one where multiple validators, who can be owned or operated by the same entity, end up using the same key to validate transactions. It’s easy to see how this can lead to slashing.

Finally, early proof-of-game blockchains have a hard limit on how many validators could participate in consensus. This is because each validator draws a block twice, once during the preparation phase of the protocol and once during the commit phase. These signatures add up and can take up quite a bit of space in the block. This meant that proof-of-game blockchains were more centralized than proof-of-work blockchains. This is a serious problem for proponents of decentralization and, as a result, newer proof-of-game blockchains are moving to newer crypto systems that support signature aggregation. For example, the Boneh-Lynn-Shacham (BLS) crypto system supports signature aggregation. Using the BLS crypto system, thousands of signatures can be merged in such a way that the merged signature takes up the space of only a single signature.

How reliable execution environments can be an integral part of proof-of-game blockchains

While the core philosophy of blockchains revolves around the concept of infidelity, trusted execution environments can be an integral part of proof-of-game blockchains.

Secure management of long-lived validator keys

For proof-of-game blockchains, validator keys must be managed securely. Ideally, such keys should never be available in clear text. They must be generated and used within reliable operating environments. Reliable execution environments must also ensure disaster recovery and high availability. They must always be online to meet the requirements of validator nodes.

Safe execution of critical code

Reliable execution environments today are capable of more than secure key management. They can also be used to deploy critical code that works with high integrity. In the case of proof-of-game validators, it is important that conflicting messages are not signed. Signing conflicting messages can lead to financial penalties according to various proof-of-game blockchain protocols. The code that tracks blockchain status and ensures that validators do not sign conflicting messages must be executed with high integrity.

conclusions

The blockchain ecosystem is changing in many fundamental ways. There is a big shift towards the use of proof-of-game consensus because it offers higher performance and a lower energy footprint compared to a proof-of-work consensus algorithm. This is not an insignificant change.

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

To make the protocol work on a scale, several blockchains imposed penalties for misconduct. Validator nodes are still penalized for misconfigurations or malicious attacks on them. To maintain the large-scale distributed nature of blockchains, new crypto systems are being adopted. Reliable execution environments that provide disaster recovery, high availability, support for new crypto systems such as BLS, and enable 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-game. blockchain.

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