Eth2 Security Overview — Secureum #1

PoS, Deposit Contract, Clients, Validators and Keys/Signatures.

Ethereum 2.0 Beacon Chain (Phase 0) launched on December 1st 2020 catapulting Ethereum towards a phased transition from Proof-of-Work (PoW) to a sharded Proof-of-Stake (PoS) network and thus laying the foundation for improved security, increased scalability and enhanced decentralization in coming years.

This post gives a high-level overview of Eth2 security by highlighting key aspects related to PoS, Deposit Contract, Clients, Validators and Keys/Signatures.

Proof-of-Stake (PoS)

The biggest improvement in Eth2 security compared to Eth1 is the transition to PoS from PoW. This has the most significant impact to Ethereum security as explained by Vitalik.

To summarize, PoS offers better security than PoW for the below three main reasons:

1. PoS offers more security for the same cost

2. Attacks are much easier to recover from in PoS

3. PoS is more decentralized than ASICs

Economic Security: In July 2020, a ConsenSys team analyzed Eth2’s cryptoeconomic security using economic modelling to arrive at the following conclusions:

1. Ethereum 2.0’s Proof of Stake is highly complex relative to Proof of Work

2. Security of the network in Eth2 is dependent upon three key variables: ETH staked, the price of ETH and volatility

3. Attacks on Eth2 are easier to scale than on Eth1

4. Capital efficient validators are more predictable

5. Targeting 13.8% ETH staked will match security levels of Eth1 at historical prices

6. Economies of Scale for validating exist but are reduced at higher ETH prices

7. 77.7% of the current ETH supply is in validator ‘qualified’ wallets (holding over 32 ETH)

8. Eth2 is paying significantly less for security than Eth1

9. Network security is heavily reliant on the price stability of ETH

10. The lack of liquidity in Phase 0 and 1 might cause unpredictability and centralization

11. Beware of Derivative attacks 

Statistics: Since the publishing of the above report, Eth2 Beacon Chain has launched with more than 2.3 million ETH staked, which represents ~2% of current total supply of ETH. 

The number of active validators has been steadily increasing with more than 54K active (~17K more waiting for activation) and participation rate close to 99%, as shown above.

The reward rate is now below 12% and the projected annual returns is 3.76 ETH (see here for statistics tracking), which adds up to more than USD $4000 at current rates.

It will be interesting to see these economic security aspects play out over time.

Deposit Contract

To become a validator on Eth2, one has to stake 32 ETH with the Eth2 Deposit Contract deployed at 0x00000000219ab540356cbb839cbe05303d7705fa. (There is an Eth2 Launchpad website dedicated to onboarding new validators.)

Value: The Eth2 Deposit Contract is currently fourth in “Top Accounts by ETH balance” ranking among all Ethereum contracts.

With more than 2.3 million ETH in balance, currently valued at more than USD $2.5B, the criticality of this contract cannot be overstated.

Authenticity: The Deposit Contract was deployed anonymously with social signalling to build confidence about it being the canonical deposit contract. One can however independently verify the authenticity of the deployed contract by following the below steps:

1. Check that the contract source code (182 lines) has been verified on Etherscan where it notes that the contract was compiled using Solidity compiler version v0.6.11+commit.5ef660b1 and optimization enabled with 5000000 runs

2. Get the bytecode at the contract's address on the Ethereum blockchain using the eth_getCode method (via Infura)

3. Clone the eth2.0-specs repository from https://github.com/ethereum/eth2.0-specs and follow the compilation instructions for the deposit contract

4. Download Solidity compiler version v0.6.11+commit.5ef660b1 for Linux from here

5. Compile deposit_contract.sol in the eth2.0-specs repository with this command: solc --optimize --optimize-runs 5000000 --metadata-literal --bin-runtime deposit_contract.sol which gives the runtime bytecode for this contract

6. Compare the bytecode obtained in Step (2) to the one in Step (5) and check that they are the same

The Deposit Contract was written by Alex Beregszaszi and formally verified by Runtime Verification. 

Language: This contract was earlier written in Vyper instead of Solidity for increased security reasons. Vyper is a Python-like smart contract language with emphasis on simplicity (minimal features), auditability (improved readability) and security (intrinsic checks). While the Vyper version of Deposit Contract was tested and reviewed, there were concerns around the safety of the Vyper compiler itself (based on reports from Trail of Bits and ConsenSys Diligence). Therefore, it was later abandoned for a rewrite in Solidity as explained in this blog post from Ethereum Foundation.

(On a side-note, I hope to cover Vyper in a future post. Curve and Yearn Vaults are two well-known projects using Vyper currently.)

Clients

There are four Eth2 validator clients actively being used: Lighthouse, Nimbus, Prysm and Teku. Their key highlights are below:

Lighthouse is an Eth2.0 client with a heavy focus on speed and security. The team behind it, Sigma Prime, is an information security and software engineering firm who have funded Lighthouse along with the Ethereum Foundation, Consensys, and private individuals. Lighthouse is built in Rust and offered under an Apache 2.0 License.

Nimbus is a research project and a client implementation for Ethereum 2.0 designed to perform well on embedded systems and personal mobile devices, including older smartphones with resource-restricted hardware. The Nimbus team are from Status the company best known for their messaging app/wallet/Web3 browser by the same name. Nimbus (Apache 2) is written in Nim, a language with Python-like syntax that compiles to C.

Prysm is a Go implementation of Ethereum 2.0 protocol with a focus on usability, security, and reliability. Prysm is developed by Prysmatic Labs, a company with the sole focus on the development of their client. Prysm is written in Go and released under a GPL-3.0 license.

PegaSys Teku (formerly known as Artemis) is a Java-based Ethereum 2.0 client designed & built to meet institutional needs and security requirements. PegaSys is an arm of ConsenSys dedicated to building enterprise-ready clients and tools for interacting with the core Ethereum platform. Teku is Apache 2 licensed and written in Java, a language notable for its maturity & ubiquity.

Diversity: A key goal with Eth2 clients is diversity. Monocultures of infrastructure deployments are bad for security because of centralisation risk. If there is a vulnerability in that single (or dominant) software then all its deployments are exploitable. 

All Eth2 clients have been security audited by reputable audit firms (Lighthouse, Nimbus, Prysm, Teku) while Ethereum Foundation also has a running bug bounty program that covers Eth2 clients (except Nimbus) and the Beacon Chain specification.

In Vitalik’s categorisation of decentralization, client diversity applies to both architectural and political categories. Different Eth2 validator nodes running different client software, written in different languages and built by independent teams using their unique technical skills and internal processes reduces the probability of the same vulnerabilities being introduced in all the clients (unless it’s related to the specification). Even if some of them have problems, a network running a good mix of different clients will be resistant to a complete network failure. Heterogeneity reduces risk from single points of failure.

Carl Beekhuizen explains why this particularly matters for Eth2 clients by motivating with the clock failure incident on Medalla testnet because of Prysm nodes’ dominance (> 60%) of the network. Specifically, if more than 1/3 of the validators are offline/malicious then it breaks the security of Eth2 (because of BFT requirements). So if any one particular Eth2 client is used by more than 33% of nodes then the security/liveness of Eth2 network would depend on that particular client's implementation.

With the four different active validator clients written in four different languages (Rust, Nim, Go and Java) by four different teams, we have a reasonable diversity of choice now. But it remains to be seen if this effectively translates to good runtime diversity over time because it may still be the case that Prysm continues to dominate deployment significantly. (While clients have a default graffiti text that logs client type and build on the Beacon Chain, clients may replace that text which makes it hard to reliably know about client distribution.)

Eth2 is aiming for much better client diversity than Eth1 where Geth continues to dominate more than 80% of the network.

Validators: Penalties & Slashing

PoS validators get rewarded (in ETH) for securing the Eth2 network by proposing new Beacon Chain blocks and attesting to proposals from others. They however get penalized for being offline or “slashed” for protocol inconsistent behavior triggered either by accident (e.g. misconfiguration) or malice.

Penalties: The penalties for being offline are relatively small when a supermajority (2/3) of validators is still online. But otherwise (being offline when more than 1/3 of the total number of validators is also offline), the penalties get bigger because that prevents the chain from finalising new blocks.

Slashing: Proposing or attesting to conflicting blocks is considered as an attempt to adversely impact the integrity of the Eth2 network and the offending validator’s stake is significantly reduced over a period of time after which the validator is forced to exit the Eth2 network permanently. This is known as slashing.

Prysmatic Labs has an in-depth article that explains the slashing rationale, causes, types, impacts and prevention tips. To summarize the key points, slashing is caused in three scenarios: (1) Double Vote: A validator attests two conflicting blocks at the same slot (2) Surrounding Vote: A validator attests two conflicting blocks at the same slot with different roots (3) Surrounded Vote: A validator attests a block which “surrounds” or is “surrounded” by a previous attestation. 

The impact on the slashed validator is it will be: (1) Penalized in the epoch where its slashing is confirmed (2) Penalized significantly after ~18 days which is proportional to how many other validators have also been slashed over that period (3) Penalized continuously for ~36 days (4)  Forced to exit the network irreversibly.

Slashing detection is incentivized by rewarding validators ~0.1 ETH when they include a valid slashing in a proposed block.

The most important slashing prevention tips are to: (1) Always run a single instance of a validator for a particular validator key. Configuring multiple instances with the same validator key for redundancy (to reduce penalties for potentially being offline) will certainly trigger slashing if both validators somehow happen to run simultaneously due to a misconfiguration (2) Confirm the copying over of the Eth2 client’s slashing protection or signing history database when migrating the validator to a new machine or a different Eth2 client.

There have been 35 slashings incidents so far.

Keys & Signatures

Cryptographic keys and digital signatures are fundamental to how Ethereum works. Eth1 (like Bitcoin) uses keys and signatures based on Elliptic Curve Digital Signature Algorithm (ECDSA) secp256k1 curve. Eth2 makes a major departure from this to introduce the use of aggregatable Boneh-Lynn-Shacham (BLS) signatures based on Barreto-Lynn-Scott (BLS again, but different from the BLS in signatures) curve BLS12-381.

In Eth2, every validator has two keys: Signing Key and Withdrawal Key. The signing key is used in Phase 0 to sign block proposals and attestations whereas the withdrawal key will be required to withdraw/transfer the validator’s funds (stake+rewards) in future phases when this functionality is enabled. 

This two-key design choice is based on the premise that while signing key is required by the Internet-connected validator node at all times, the withdrawal key is only required (in the future) at times when the validator needs to transfer funds. So the withdrawal key can be safely stored in cold storage (offline) until required.

While Eth1 keys are based on mnemonics and hierarchical derivations as specified in BIP39 and BIP32/BIP44 respectively, Eth2 keys are based on BIP39 mnemonics but key generation and derivation are different as proposed in EIP-2333 and EIP-2334.

Summary

Eth2 is the biggest upgrade to Ethereum network since its launch and is off to a fantastic start with the recent launch of its Beacon Chain.

This post only scratches the surface of Eth2 security by touching upon the topics of PoS, Deposit Contract, Clients, Validators and Keys/Signatures. I plan to deep-dive into some of these in the future.

I hope you found this somewhat useful. Thanks for reading and look forward to your comments and feedback.