.svg)
.svg)
.svg)
This year, members of the Quantstamp team and some of our friends participated in the ETHDenver Hackathon. Our CEO Richard Ma, Poming Lee (myself), Nathan Frenette and Derek Alia entered the hackathon as “Beacon Thugs and Harmony” and hacked away at an implementation of the ETH 2.0 Beacon Chain.
The Beacon Chain is Core ETH2.0 Infrastructure
The beacon chain plays an integral role in ETH2.0 infrastructure and is scheduled to be the first part of ETH2.0 to be implemented. One of the functions of the beacon chain is to randomly select a “committee” of eligible validators that propose and validate blocks on both the beacon chain and shard chains. The beacon chain accomplishes this random selection by producing an unbiased, unpredictable and verifiable number through the RANDAO + VDF process.
ETH 1.0 Blockchain: Randomly Selecting Block Proposers in Proof of Work
Generating a truly random number is a challenging problem. It is important that block proposers are selected in a random fashion in order to prevent these same proposers from tampering with blockchain data. In proof of work, this is achieved through brute force. The only way to game the system and enhance your chances of selecting the “golden nonce” is to add more hashpower to the network.
In Ethereum’s planned 2.0 upgrade, Ethereum aims to eliminate proof of work in order to scale transactions and eliminate “redundant” computations by distributing computational work over shards. In order to fairly and securely select block producers without proof of work, Ethereum 2.0 is selecting validators using a random number generated by the RANDAO + VDF process.
ETH 2.0 Blockchain: Randomly Selecting Block Proposers in Proof of Stake With A Random Seed Generated Via the RANDAO + VDF process
In order to fairly select the next committee of validators for Ethereum 2.0, all of the active validators from the current committee participate in a random number generation process in order to produce an “unbiased” random number. The random number generation can be broken up into two parts: the RANDAO and the VDF.
The RANDAO
The RANDAO works via a commit reveal scheme. The current committee of validators each submits a hash of a locally produced secret to the beacon chain. After all hashes are collected, the reveal stage begins: validators submit their locally produced secret to the beacon chain in a predetermined sequence. After each secret is sequentially revealed, the beacon chain performs the XOR operation on the validators revealed secrets. If a validator chooses not to reveal their secret, the beacon chain XORs a 0 in place of their secret.
The Last Revealer Attack
If we just relied on the RANDAO for random number generation, we would be vulnerable to what is known as the last revealer attack. The RANDAO has entropy that can be biased by the last validator to submit their secret. The last validator can choose between one of two different random numbers by choosing to either reveal their secret or to hold it.
Using a Verifiable Delay Function to Counter the Last Revealer Attack
Without the Verifiable Delay Function (VDF), the last revealer can bias the selection of the next committee of validators that will finalize blockchain data. In order to prevent this attack, the beacon chain submits the entropy produced by the RANDAO algorithm into the VDF.
The VDF is an algorithm that uses the biasable random number generated by RANDAO as an input to generate an output that is a truly random number. The VDF accomplishes this by putting the RANDAO’s biasable random number through a series of computations that intentionally take a long time to generate the output. The VDF intentionally uses time-intensive computations to generate the output so that the last revealer in the RANDAO process can no longer bias the final result.
The Difficulties We Encountered Following the Specification
Initially, our goal was to implement a beacon chain simulator that was 100% based on the specification. However, after realizing that there is no single, complete, detailed algorithmic description to the beacon-chain, we decided to implement the simulator as faithfully as we could to the “spirit” of the information found in the documents.
It took our team, composed of one Computer Science PhD and three professionals in the field, over 50 cumulative hours to come up with a coherent idea of what a beacon-chain is and how it works. During this time, we traced the references listed below, had discussions, guessed the undescribed details, and solved conflicts between the references.
List of References that Helped Us Piece Together the Beacon Chain Spec:
- Devcon4 Mainstage - Justin Drake - YouTube
- Minimal VDF randomness beacon - Sharding - Ethereum Research
- Clearing Up Casper, Proof Of Stake, And Beacon Chain Confusion, Once And For All - ETHNews.com
- Serenity Handbook - Ethereum.org
- https://github.com/sigp/lighthouse/blob/master/docs/serenity.md
- eth2.0-specs/0_beacon-chain.md at dev · ethereum/eth2.0-spec
- ethereum/beacon_chain
- sigp/lighthouse: Ethereum Serenity Client
- eth2.0-pm/README.md at master · ethereum/eth2.0-pm
Presenting Quantstamp’s ETHDenver Beacon Chain Implementation
You can access our beacon chain simulator and the interactive front end we developed for it via the links below:
How to Use Our Implementation to Improve ETH2.0
The development of Ethereum 2.0 is a community effort. In that spirit, we have some suggestions on how you can carry the torch and use our implementation to conduct experiments that can improve Ethereum. Developers can experiment with the parameter set up in order to optimize it or to discover potential security issues. After spending a small period of time reviewing the code, developers can also add or change modules written in the simulator, or make significant modifications that cater to their own understanding of how the beacon-chain should function.
If you conduct an experiment and find anything interesting, please let us know.
Making It Easier for Others to Experiment with our Beacon Chain Implementation
Developers can also improve upon this implementation by making it easier for users to experiment with the parameters setup. This can be done by integrating the front end (GUI) we provided to the back end simulator so that they can work in an online fashion (currently the experimental result is generated offline and should be manually fed to the front end GUI). Improving the back end experimental logic would also be helpful. Adding an auto-setup script for running the entire project locally would also be ideal for experimentation. It will make the simulator a lot easier for developers to play with.
Written by Poming Lee, PhD and Security Auditor at Quantstamp
.svg){kind=small}
.png)
.svg)
.svg)
