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.
MEV-Boost update
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.
Proto-danksharding update
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2022. All rights reserved.