Security Audit of Ethereum 2.0 Specifications
The Least Authority team recently completed our audit of the Ethereum 2.0 Specifications. Read our full report here.
Ethereum 2.0 will be a significant network upgrade and is set to take place in 3 distinct phases — Phase 0: Beacon Chain, Phase 1: Shard Chains, and Phase 2: Execution Environments. It is one of the first Proof of Stake (PoS) / sharded protocol projects planned for production. As a result, there has been minimal opportunity to study the impacts of design decisions on real-world uses of such blockchain implementations, and none at the same scale. The long term stability of PoS blockchains is an area of active research that will need to be monitored over time as they are used in production.
Our team performed this review in preparation for Phase 0’s upcoming mainnet launch. Since no other large-scale implementations of a PoS system currently exist in production, auditing the Ethereum 2.0 Specifications presented our team with certain challenges and made this review particularly interesting. We had the opportunity to work closely with the Ethereum 2.0 team, whose close collaboration with our team contributed positively to our review effort.
Our audit consisted of reviewing a specification as opposed to a coded implementation and the attack vectors we identified were necessarily based on certain assumptions and theory. We identified seven issues and made three best practice suggestions. Our team found the specifications well thought out and comprehensive. It is clear that security was strongly considered by the Ethereum 2.0 team during the design phase.
In our report, we highlight two particular areas that would benefit from further review and additional documentation — the Peer-to-peer (P2P) networking layer and the ENR system — since laying the foundation of a strong network layer during Phase 0 is critical. We also called out areas of further consideration due to increased potential vulnerability for attack, including the block proposer election system and the P2P networking layer.
Block Proposer System
Without a Proof of Work (PoW) to verify which node should propose the next block, PoS systems like Ethereum 2.0 use a block proposer to choose what goes into the next block on the chain, allowing the block proposer to change the outcome of the block proposal process, and thus, the end result of the chain. If the observer can determine the block proposer, that creates an information leak that is nonexistent in PoW chains such as Bitcoin, since it is impossible to guess who is going to solve a PoW puzzle first.
We identified two different issues with the block proposer system during the audit (Issue C and D) and suggested a single mitigation strategy for both. Single Secret Leader Election (SSLE) keeps the selection secret and stops the leak of information to an observer, while still allowing the chosen block proposer a fast way to verify to others that it is, in fact, the proposer. With the information leak patched, the block proposer remains as protected as it would be in PoW chains, but without the computational overhead.
The Ethereum 2.0 team acknowledged the suggested mitigation, however, SSLE is still very much an active area of research. As a result, we expect more information and updates around these vectors to emerge as research on SSLE continues and Ethereum 2.0 reaches the Phase 1 and 2 milestones.
Peer-to-Peer Networking
Decentralized systems inherently rely on honest actions of strangers, as opposed to the system utilizing a “trusted” centralized authority. We carefully considered the P2P protocol presented in the specification and found attack vectors through the P2P messaging system (Issue A, Issue B and Issue E). Given that the project is still in the early phases of design and not yet in production, a comprehensive analysis of potential and present vulnerabilities will be prudent during later phases.
Gossip protocols generally suffer from the spam problem; without a centralized judge, it can be difficult to understand whether a message is legitimate or is spam that is meant to clog the network. This was one of our primary concerns in examining the networking layer. In Ethereum 2.0, when a node proposes a new finalized block, the block must be sent to the rest of the network. We identified an issue where a dishonest node is capable of sending an unlimited amount of older block messages to the rest of the network with minimal penalty, allowing them to overwhelm the network and block legitimate messages.
Similarly, when a node violates the rules, other nodes send out slashing messages to notify the rest of the network about who to penalize. We found a small loophole that allowed a node to send an unlimited amount of these types of messages with minimal penalty, causing the same message blocking if they sent enough of them.
Ultimately, we recommended implementing a fully BAR-resilient gossip protocol. BAR-resilient protocols prevent nodes from gossiping maliciously while still maintaining the benefits of gossip protocols. As with SSLE, this is an active area of research. The lack of specification here does not represent a deficiency in the Ethereum 2.0 design, but an opportunity for further improvement and application of a general best practice recommendation for these types of systems.
We encourage the Ethereum Foundation team to continue to engage in design discussions with the various stakeholders and the broader community and we hope this report will be a basis for them to do so.
_________
Learn more about our security consulting services & process.
If you would like to get in touch regarding a security audit, you can book a 30-minute meeting with us here: https://calendly.com/least-authority-security-consulting/info-session.
We can also be reached via email at contactus@leastauthority.com.
