Prysm Quarterly Update: Summer Recap and What’s Ahead
Hello Friends! We’re thrilled to bring you the latest in our series of quarterly updates for Prysm. Let’s dive into the highlights of the summer season and offer a glimpse into the exciting developments we have in store for the coming months.
Summer Recap
Welcome to a recap of the optimizations we’ve rolled out in our Q3 releases.
Speeding Up Slot 0 Block Construction
In Ethereum, each slot is 12 seconds long, with the first 4 seconds crucial for attestation. Blocks not attested within this 4-second window are at risk of being reorganized, making timely block proposals essential.
For the block proposal, a validator client does the following:
- Call to
GetBlock: The validator client initiates the block proposal via theGetBlockRPC endpoint. - Beacon Node’s Role: The beacon node constructs the block, packing in essential data and fetching execution payloads.
- Signing and Proposing: The validator signs the block and makes a
ProposeBlockRPC call. - Broadcast: The block is then broadcast to the network.
The bottleneck was in step 2, specifically, the GetDuties RPC call, which took up to 500ms. We've optimized proposer indices caching, reducing block construction time by 500ms.
Better Handle of State Field Trie
In Prysm, traditionally only one relevant set of beacon state field trie was stored in memory. This was aimed at conserving heap space. However, this approach had drawbacks, such as recomputing all tries for older states whenever needed for new block processing or slot advancement. This was especially problematic for late blocks. We’ve introduced the ability to copy all tries for late blocks. This enables the next slot cache to function more effectively, streamlines the processing of late blocks, and maintains manageable heap usage. This optimization specifically improves the time it takes for a proposer to propose a block under certain conditions, thus enhancing the efficiency of the entire network.
Boost in Attestation Aggregation Time
We have fantastic news if you’re running a beacon node with validators or subscribing to all beacon attestation subnets. We’ve reduced the attestation aggregation time by a whopping 75%. The key to this drastic improvement lies in introducing parallelization using Go routines. The system now utilizes the number of available CPUs to make the beacon node more CPU-efficient. This optimization speeds up the attestation process and frees up more time to pack efficient aggregate attestations. These are then broadcast at the 8-second mark.
Enhance Fork Choice Lock
Fork choice is a critical component in beacon nodes, responsible for consuming many attestations in parallel to determine the head of the blockchain accurately. Over the years, properly locking the inputs to the fork choice store has posed challenges, impacting both performance and safety. We’ve overhauled the fork choice lock logic to improve performance and security. This revamp has made the overall code safer and easier to maintain and has set a solid foundation for future developments.
Faster Hashing of Beacon State
Hash tree root calculations are integral for reaching consensus on state objects in Ethereum. Due to the large state size, especially with around 800k validators, this process was notably time-consuming. The amount of required hashing scaled linearly with the increasing number of validators. We introduced parallel hashing for the validator fields within the beacon state. This optimization allows for more efficient use of computational resources. The impact of this change has been significant. We’ve reduced the hashing time from 481ms to 143ms. Heap memory allocation has also been cut from 357.58 megabytes to just 101.86 megabytes for a mainnet state.
Parallel Validation of Consensus and Execution
A beacon block comprises two main types of data: consensus and execution data. Both are crucial for the proper functioning of the network. We now verify these two types of data in parallel. This leads to a significant reduction in block verification time. Faster block verification allows the beacon node to reach consensus on the canonical head more quickly. This results in timely attestation and better profitability for attesters. In our tests, we observed about a 200ms reduction in a regular slot, a benefit especially useful for low-power machines.
Many beacon-API improvements
Our main objective has been to improve the efficiency of different beacon-API endpoints. This includes making them faster, more reliable, and reducing code duplication in the codebase. Our ultimate goal is to transition to a pure REST solution, moving away from the use of gRPC. This transition will result in a smoother developer experience when maintaining existing APIs and creating new ones, fostering a more friendly environment for external contributors.
What’s Coming Up: Exciting Features in Q4
Welcome to a preview of the exciting developments we have planned for Q4. Here’s a glimpse of the features that are in the pipeline:
Deneb Features
We have successfully merged Deneb features into our main branch. These features will be part of our next release, with more testing in the background. Rest assured, these new features will not interfere with the regular, mission-critical Capella code.
Multi-Value Slices for Beacon State
We’re introducing multi-value slices to replace the current usage of slices in the beacon state. This change allows for more efficient storage and should significantly reduce the processing time for core code paths like balances, validators, and inactivity scores.
Deposit Contract Snapshot Deposit Trie
The upcoming release will include the integration of EIP4881 under a feature flag. This optimized data structure improves memory usage during block proposals by better handling deposits on the beacon node.
Backward Syncing
While not in our immediate next release, backward syncing is targeted for Q4. This feature will allow for quicker syncing of up to 4 months’ worth of historical blocks, requiring less verification. It lays the groundwork for future Deneb features, enabling the beacon node to sync up to 18 days from the finalized checkpoint.
Protocol Research
In addition to upcoming features, we’re deeply invested in research to fortify the Ethereum protocol. Below is a look at some of our ongoing research efforts. Ethereum’s existing censorship resistance mechanisms are relatively weak. For instance, censored transactions eventually get included but often with a degraded user experience. We aim to improve this chain aspect, with ongoing research to create more robust mechanisms. The inclusion list has been the subject of research to refine the methods by which transactions get included in the blockchain. About 95% of blocks are built using out-of-protocol methods like MEV-boost and relayer. While effective, these methods have challenges such as centralization and governance issues. Our ultimate goal is to internalize these roles within the protocol itself.
Embarking on ePBS is a massive undertaking with great complexity. Yet, it’s a challenge we are committed to taking on. The designs we have been spec’ing includes the following components:
- Staked Builders with Validator Duties
- Max Effective Balance and Dependencies
- Forced Inclusion List
- (Block, Slot) Voting Mechanisms from Attesters
- PTC (Proof of Transaction Consensus) Committee
We have ongoing work on consensus, validator, and network specifications. Expect to hear more from us on the local devnet soon!
Finally, thank you for reading. Your support is invaluable as we continue to advance the Ethereum network. Stay tuned for more updates!
Special thanks to James He for the feedback.
