This article is meant to explain in simple terms how the beacon chain will work. In Ethereum 2.0 the beacon chain is the backbone of the entire network, coordinating everything in fairly complex ways, so the explanations below are oversimplified on purpose. For the sake of simplicity I will also consider the network and validators to function perfectly and ignore most of the bad stuff that will undoubtedly happen.
Things like penalties, slashings, orphaned blocks and reorgs will make the subject of another article.
For a glossary of terms look here https://medium.com/alethio/ethereum-2-0-terms-demystified-8398357429d7
If this article leaves you wanting for more technical details, a great but still accessible depiction of Phase 0 can be found at https://notes.ethereum.org/@djrtwo/Bkn3zpwxB?type=view
And finally, if you are a robot, you can read the official spec available at https://github.com/ethereum/eth2.0-specs
The beacon chain, being a blockchain, is in essence a chain of blocks linked together, but with a few surprises.
Our journey starts with an unwitting hero, the validator. A validator is someone who has locked their small treasure of 32ETH in the deposit contract on the current Ethereum 1.0 network in order to actively participate in the Ethereum 2.0 network by running a validator node.
Before he departs, there are some prerequisites. Ideally he would have access to an Ethereum 1 node and a beacon chain client node, both synced to date.
As soon as our hero deposits his ether in the deposit contract, his journey into the Ethereum 2.0 world is underway. Part of the deposit process is that he gets his public, hot and cold private keys for his beacon chain Ether. The public key can be used to view the validator stats and activity in an explorer. The hot key is used for voting and proposing and the cold key is that one that should be stored offline as that is the golden key that will later allow you access to your Ether later on.
One extremely important thing to note here is that once you sent your deposit, you have pledged to keep a validator client in running condition until you stop being a validator. Failing to do so will lead to you losing Ether. In phase 0, you will no longer be able to rejoin as a validator if you exited, nor will you be able to transfer your funds.
His second step is to wait ~7.5 hours(1024 Ethereum 1.0 blocks and 1024 Ethereum 2.0 slots, currently), to make sure that his deposit cannot be reverted. He uses this time to set up one of the validator clients available, add the hot keys and connect it to his previously set up beacon chain client.
Once that wait is over, the deposit should be recognized by the beacon chain and the validator gets added to the activation queue. In this queue, you guessed it, we wait some more, depending on how many other validators are in the queue. Until there are 327,680 validators active, only 4 validators can become active per epoch.
Epoch? What is an epoch I hear you asking. Well, dear readers, to tell you what an epoch is, I have to first tell you what a slot is. A slot is a time interval of 12 seconds for which a block can be proposed. This is a blockchain in the end so we had to get to blocks at some point. Empty slots can exist and they are called skip slots.
To keep things nice and tidy then, the slots are grouped together — 32 at a time in an epoch. This spreads apart some of the operations that the beacon chain clients need to do, which in turn should decrease computational load for the computers running said clients.
After his time in the queue, our validator is then activated. He gets a roster of duties before the start of each epoch. In that roster he sees that each epoch, together with some of his peers, he needs to vote for what block to include in one slot. In some epochs he sees that he also has the duty of proposing a block for a slot, that others can vote on.
Before each epoch, the beacon chain — using a specialized form of random number generation — chooses one validator per slot that should propose a block. It also takes the whole pool of available validators, splits them into the number of slots per epoch and then further splits them into the groups mentioned above, called committees, that can have their ballot of votes aggregated together. So in the end, for each epoch, each validator will need to vote only once as instructed, and, if selected, will need to propose a block.
Going back to our main character, the validator, we find his life is fairly monotonous. Like I mentioned, he spends his epochs asking the beacon chain client what he needs to do before every epoch and then tries to do it. Each epoch he then needs to vote (also called to attest or to validate) for one block someone else proposed to be included. It does so in good faith considering all the information it has available, and usually it should be a simple task of seeing just one proposed block with the correct information it.
Every now and then, something exciting happens and our validator gets elected to propose a block. Once the corresponding slot comes, it looks at what it can see from the network, what the previous block is (also called network head) and what attestations can it see waiting on the network to be included in a block. It then packages all this information into a new block that it sends to the network. The more information it can gather and send faster, the bigger the potential reward it can receive if the block is included in the canonical chain. After the submission of the block, assuming everything is correct, it will see its block validated by its peers in the following blocks, by the number of attestations it receives.
At the end of an epoch, the beacon chain also gives out Ether to validators that have performed their duties. A little to people that voted, a little more to people that proposed blocks, but it also takes some Ether from people that failed to perform their duties. Even worse, if validators either acted in bad faith or had some technical difficulties that led to something like proposing two blocks for the same slot, they could get slashed, which means losing a lot more money and getting booted off the chain.
The chain itself gets built block by block, each block looking at the blocks in the previous slots to anchor themselves to the chain by using the last available block as a parent. Because things in the real world are not as perfect as in a fairy tale, stuff like network latency can cause a lot of problems due to not all validators having the same picture. Latency means some validators can see some proposed blocks, others cannot. To help against this problem, a powerful entity called the fork choice had to be introduced in the validator client. Its purpose is kind of like a judge. At each slot, it checks all the available information it has and if there are multiple choices regarding the history of the chain, it tries to pick the one that has the most votes going backwards in time to build upon. This mechanism ensures that there is only one canonical chain, but it has the side effects of possibly rearranging the chain in the short term, an action known as a reorg. When a reorg happens, rewards and penalties can change as well to reflect the new chain history and duties performed.
If at least two thirds of the total validator pool vote for the same block to represent the head of an epoch, then that epoch is considered justified to be a valid part of the chain.
Justification provides a reasonable amount of certainty that the chain will not change anymore through a reorg. To be certain that the chain won’t change, the epoch will be considered finalized when it has another epoch in a row that is justified and builds on it. In other words, a finalized epoch is a justified epoch, where its child is justified as well.
All in all this is the journey of a validator through the beacon chain:
1. sync a beacon chain client
2. send 32ETH deposit to the deposit contract
3. spin up a validator client
4. wait until the deposit is recognized and it gets added to the validator activation queue
5. run and make sure the validator client keeps running to:
— vote/attest on blocks to be included on chain
— propose new blocks when requested
6. profit $$$
This article briefly mentions or outright ignores the following subjects which probably warrant one or more articles each:
- random number generation — RANDAO
- fork choice rule — Casper FFG
- finality
- how reward and penalties are calculated — https://www.attestant.io/posts/understanding-validator-effective-balance/
- slashings
- validator lifecycle including voluntary and forced exits — https://www.attestant.io/posts/understanding-the-validator-lifecycle/
- attestation aggregations
- anything related to phase 1+
- anything technical like BLS signatures, SSZ encodings or data structures
Note: I tried this silly format just because a lot of the content out there is so technical and dry and surgical in the information it delivers, albeit a lot more complete but also kind of off-putting for new not-so-technical people.
I would appreciate suggestions or even mentions if it helped you understand a tiny bit better or just made everything even fuzzier.
Thank you and also big thanks to Ben Edgington, Jim McDonald, Herman Junge
