Ethereum Consensus Layer Call #98 Writeup
On November 17, 2022, Ethereum developers gathered for their 98th Consensus Layer (CL) call. Chaired by the Ethereum Foundation’s Danny Ryan, the CL calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. This week, developers discussed updates to MEV-Boost software and progress on Ethereum Improvement Proposals (EIPs) for Shanghai related to staked ETH withdrawals and proto-danksharding. Developers also briefly discussed a new process for making updates and revisions to the Ethereum Engine API.
Chris Hager, also known as “MetaChris”, from the Flashbots team gave an update on MEV-Boost. MEV-Boost is the software that connects validators to multiple off-chain marketplaces called relays. Relays are where validators receive blocks that contain additional rewards in the form of maximal extractable value (MEV) from third-party block builders. A new version of MEV-Boost has been released this week which all validators are encouraged to use. The new version enables validators to set a minimum bid value to the blocks they receive from a relay. Flashbots is planning on publishing a blog post in the coming weeks about the implications and impacts of setting a minimum bid value on MEV-Boost blocks.
In addition, the latest version of MEV-Boost fixes a denial-of-service vulnerability that could have forced all validators to fall back on local block production. A full post-mortem of the bug can be found here. MetaChris stressed that the fix for the bug requires Consensus Layer (CL) client teams to implement a specific endpoint to the Beacon node API known as “getStateRandao”. This is an endpoint that only the CL client Teku has officially implemented, said MetaChris.
On the topic of relay competition, MetaChris highlighted that a new relay was picking up steam on the Ethereum blockchain. Relayooor.wtf has delivered 1.5% of all MEV-Boost blocks in the past 24 hours. Notably, relayooor.wtf is a permissionless, open-sourced, and non-censoring relay. On the topic of builder competition, the leading builder is an anonymous user known as “0x69”. 0x69 has built 2,000 MEV-Boost blocks in the last 24 hours. The second leading builder is the Flashbots builder, landing 1,200 MEV-Boost blocks on-chain. All these statistics can be found on the relayscan.io website.
Finally on the topic of MEV-Boost, developers reconfirmed on this call the strategy for implementing a way to calculate the value of locally built blocks. This was a topic of discussion during the last CL call, which you can read a full writeup of here. Developers agreed to calculate the block value as the sum of all transaction priority tips and not as the difference in a validator’s balance before and after building the block. Developers also confirmed that the calculation should be computer from the CL client instead of Execution Layer (EL). Further discussion on this topic about adding a block value to the Engine API, which is the API for easily communicating between the CL and EL clients of an Ethereum node, can be found here.
Staked ETH withdrawals update
Following up on the discussion from CL Call #97 about how to enable staked ETH withdrawals for Ethereum’s next upgrade, Shanghai, developers revisited the topic of adding a bound to the withdrawals sweep. Instead of processing withdrawals according to the ordering in a dedicated queue, developers agreed to process withdrawals according to the validator index number. Every block, the network will scan or sweep through the validator index and process as many withdrawals as possible, which is dictating by the churn limit.
In the unlikely scenario that no validators have initiated any withdrawals, Ethereum nodes may be required to scan through the entire validator set, which currently is comprised of close to 469,000 validators. Because this edge case may cause Ethereum nodes to become overworked, a proposal has been created by Ethereum Foundation researcher Alex Stokes to bound the maximum number of validators that can be scanned in one block for withdrawals. Chair of the CL calls Danny Ryan initially pushed back on the addition of a bound because it would add additional code complexity. During the call, he changed his mind after considering the other optimizations that CL client teams may be forced to add in the absence of a sweep bound. At present, the GitHub proposal by Stokes only creates a limit to the sweep but does not contain logic to ensure that the sweep progressively moves through the validator set every time it comes back empty, meaning without a single withdrawal to process. Ryan emphasized the importance of logic to move the sweep through the entire active validator set instead of re-scanning the same range of validators. Stokes agreed to continue polishing his proposal.
Developers discussed the need for additional cryptographic verifications to blob transactions, which are a new transaction type being developed for Ethereum that would significantly reduce the operational cost of Layer-2 rollups. Danny Ryan explained two different ways to introduce additional verification such that Ethereum nodes can confirm blobs are worth gossiping, that is communicating to other nodes in the Ethereum network. One of the operations requires validators verify the blob signature, while the other requires validators to complete a verification of the full blob. Two other developers on the call had run simulations to compare the verification time of both operations. The results of their simulation can be found here. Because the results suggest the verification times of both operations do not differ significantly, developers leaned towards doing the full verification rather than the signature verification as the former operation adds almost no additional code complexity. Ethereum Foundation Research Dankrad Feist did point out that the numbers from the simulations seemed erroneous and should be re-checked. Danny Ryan agreed and said that revisiting the number would likely reinforce the rationale for full blob verification over signature verification.
Engine API improvement process
Finally, developers talked on the call about new methods for introducing changes and versioning to the Ethereum Engine API. Mikhail Kalinin of the Teku (CL) client team presented his proposal on how to update Engine API documents and keep track of different Engine API methods or versions. First, there is the addition of a new call by the CL client. The “getcapabilities” call will return a list of the Engine API method supported by an EL client. Jacek Sieka, also known as “Arnetheduck”, a developer of the Nimbus (CL) client, suggested the standardization of error codes for deprecated and removed Engine API methods. Arnetheduck explained most node operators will upgrade their CL clients before their EL clients and instead of calling a list, will often try each Engine API method separately to see if they work. Kalinin expressed concern about creating backwards compatibility for all forked versions of the Engine API and their methods but agreed support for at least one forked version of the Engine API could be added to help client team engineers.
Kalinin also highlighted several method statuses to help differentiate between Engine API methods that are under development, final, optional, and deprecated. Because changes to the Engine API are introduced as part of a larger hard fork, Kalinin’s proposal organizes the documentation of method changes by hard fork. Pseudonymous Ethereum developer Lightclient suggested not organizing the methods by hard fork but by method type. Lightclient explained developers would find it easier to see all finalized changes, changes under development, and deprecated changes for a single method such as “newPayload” bundles in one file, instead of having to jump between hard fork version to track down API changes related to newPayload. Kalinin agreed that organizing the content of these documents by method, instead of hard fork was a good idea.
Danny Ryan asked Kalinin about the urgency for implementing his proposal on Engine API documentation and versioning. Kalinin said that his proposal wasn’t a blocker for Ethereum’s next upgrade Shanghai but that the sooner a defined process for updating Ethereum’s Engine API is agreed upon by developers, the better.