The Good Tech Companies - EIP-6110: Revamping Ethereum Validator Onboarding

Episode Date: January 21, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/eip-6110-revamping-ethereum-validator-onboarding. EIP-6110 simplifies Ethereum validator deposits by moving them on-chain, reducing technical debt, simplifying block validation, and enhancing network efficiency Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum, #ethereum-blockchain, #ethereum-developers, #ethereum-merge, #ethereum-rollups, #2077-research, #eip-6110, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. EIP-6110 proposes moving validator deposits directly onto the Ethereum Beacon Chain, eliminating the need for the current Eth1-Eth2 bridge. This change aims to simplify the deposit process, reduce technical debt, and enhance the efficiency of validator onboarding. By integrating deposits on-chain, it streamlines block validation and processing, potentially improving the overall performance and security of the network.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. EIP-6110, Revamping Ethereum Validator Onboarding, by 2077 Research. The beacon chain has undergone a lot of changes since the merge, a testament to an idea I described in the last article. With a complex, evolving protocol like the beacon chain, the work is never done and developers will always have something to fix. For context, the EIPs for Nerd series has covered two proposals that fix key issues, security of delegated staking, EIP-7002, and unchecked validator said growth, EIP-7251. Keeping up with the theme of discussing upgrades to Ethereum's consensus layer,

the next article in the EIP's For Nerd series focuses on EIP 6110. EIP 6110. Supply Validator Deposits on Chain as an Ethereum Improvement Proposal EIP. That reforms the beacon chain's validator deposit request mechanism and fixes a laundry list of issues currently affecting the security and efficiency of Ethereum's proof-of-stake protocol. These issues, which I'll go into later, stem from the reliance of deposit request processing on the ETH1-ETH2 bridge. The ETH1-ETH2 bridge is a one-way bridge that allows for sending ETH from Ethereum's execution layer to the consensus layer. Often described as the most secure bridge in the world, the ETH1-ETH2 bridge plays a critical role in the beacon

chain's operation and serves as the entry point for anyone interested in participating in Ethereum's consensus. More specifically, it creates a link between Ethereum's execution and consensus layers and enables processing of collateral deposit requests from prospective validators on Ethereum. Notwithstanding its lofty description, the ETH1-ETH2 bridge is still susceptible to issues that plague most bridges today—poor security, low efficiency, and high engineering complexity. These problems stem from the ETH1-ETH2 bridge's approach to validating and processing deposits, which I'll explore in subsequent sections of this article. EIP-6110 remedies the problem by deprecating the ETH1-ETH2 bridge and introducing a new means of delivering validator deposits to the beacon chain. This article provides a comprehensive overview of EIP-6110 and establishes the background for the proposed overhaul of the

beacon chain's deposit processing system. I'll also dive into the specification and discuss the various advantage-sanned potential drawbacks of implementing EIP-6110s in Protocol Deposit Requests feature. Let's dive in. A. Brief History of the ETH1-ETH2 Bridge The ETH1-ETH2 Bridge has proven to be a secure means of passing information about deposits between Ethereum's layers, but runs into several issues, such as the requirement for a delay on deposit processing and increased complexity for validators operating the bridge. But, before we start analyzing these issues in more detail, it is necessary to understand why the ETH1-ETH2 bridge exists in the first place. A one-way bridge for transferring assets, ETH deposited in the deposit contract, from the execution layer to the consensus layer was necessary before the

merge because the execution layer, FKA, Ethereum 1.0 inches, and the consensus layer, FKA, Ethereum 2.0 inches, were distinct blockchains operating independently. The ETH1 chain was a proof-of-work based chain secured by miners, while ETH2 was a proof-off stake chain secured by validators. Having a different set of consensus nodes for each chain had a number of implications, for example, the ETH2 chain couldn't operate based on information about the state of the ETH1 chain without introducing trust assumptions. As I mentioned in EIPs for Nerds No. 2, EIP-7002, trustlessness means you don't have to trust people to avoid dishonest behavior because there are strong, crypto-economic incentives to act honestly. Proof-of-stake protocols like the beacon chain incentivize honest behavior by requiring each

validator to pledge collateral before joining the consensus protocol. If some validators act dishonestly while participating in consensus, the protocol can identify and destroy the collateral of the offending validators. This is possible because a. The beacon chain has control of balances of validators participating in the protocol and can reduce this balance as punishment for bad behavior. With certain caveats, and, b. The beacon chain stores a mapping of validators' public keys that creates a cryptographic link between validators' actions in the protocol and enables the protocol to efficiently identify offenders. All of this means validators on the beacon chain John B. mostly trusted to attest to correct information while participating in the protocol. In contrast, the miners running the ETH1 chain couldn't be trusted to provide incorrect information about the ETH1 chain's state to validators running the ETH2 chain.

An example of ETH1 state the ETH2 beacon chain needed but couldn't trustlessly access was information about transactions sent to the deposit contract deployed on the ETH1 chain. For the uninitiated, the deposit contract is a system-level smart contract deployed on Ethereum's execution layer and has two functions. Receive and validate deposits from anyone that wants to activate a new validator or top up the balance of an existing validator on the beacon chain. Emit a deposit receipt using the EVM's event logging mechanism. The deposit receipt provides a record that the deposit occurred. The deposit contract stores information associated with deposits in a Merkle tree structure called

an incremental Merkle tree. The incremental Merkle tree behaves like a regular Merkle tree. Verkle trees for the rest of us has a reader-friendly introduction to Merkle trees, except for certain optimizations that make it useful for storing and updating information. For example, the deposit contract stores only one branch, a set of 32 leaves, necessary to calculate the route and avoid storing all leaf nodes on chain, which reduces the costs of storing and updating elements in the tree. Upgrading Ethereum has a great overview of the deposit contract's tree structure for those interested. Merkle trees have several nice properties, including the ability to prove, cryptographically, that a particular value is a part of a large set of data. The deposit contract creates a leaf in the Merkle tree for every deposit,

which allows a validator to create a Merkle proof that proves the existence of a deposit a particular position in the deposit tree. The Merkle proof, also called a Merkle branch, is the set of leaf hashes required to compute the path from a leaf to the root of the Merkle tree. As I explained in the Verkle trees article, the root is a succinct commitment to the tree's data, and anyone with the route can verify a Merkle proof asserting the inclusion of an element in the Merkle tree without storing the entire tree. In the original ETH1-ETH2 bridge design, proposers monitored the ETH1 chain for transactions sent to the deposit contract and delivered deposits to the ETH2 chain by including deposit operations in beacon blocks. Proposers included Merkle proofs proving that

deposit operations corresponded to leaves in the depository, which validators verified before processing deposits. The route of the deposit Merkle tree served as a source of truth for deposits made on the ETH1 chain, implying the security of the ETH1-ETH2 bridge depended heavily on the process for verifying the validity of the depository route. If validators had the wrong depository route, a malicious proposer could create Merkle proofs for non-existent deposits and activate new validators that failed to deposit the required collateral. To secure the bridging of deposits from the ETH1 chain, a process known as the ETH1 data pool was created for the beacon chain to arrive at a consensus on

the route of depository. ETH1 data represented the beacon chain's view of the execution layer, or more specifically, the state of the deposit contract at a particular block height. The pool, which I'll explore later, provided a wayforth ETH2 chain to derive information about deposits without placing too much faith in the honesty of miners validating the ETH1 chain. We couldn't trust miners on ETH1 chain to validate deposit transactions since miners weren't staked on the beacon chain and had weaker incentives to act honestly. Moreover, proof-of-work, unlike proof-of-stake, imposes an implicit cost on dishonest behavior like reverting past blocks and cannot reliably identify and punish dishonest consensus nodes. In other words, miners had nothing at stake and could jeopardize the ETH1

ETH2 bridge without incurring risk. Here's an example to illustrate. 1. Suppose a beacon block proposer receives the header of block number 10,000 from a miner that shows Alice depositing 32 ETH in the deposit contract. The validator pulls the deposit tree root from the block's state root. The block proposer, assured Alice's deposit is safely locked in the deposit contract, includes the deposit transaction in the proposed beacon block. A majority of validators approve the block containing Alice's deposit, after which the protocol creates a new validator, with a balance of 32 ETH, for Alice, too. Alice notices her validator's deposit has been created and bribes a mining pool with 51%

of the network's hashrate, total computational power contributed by miners, to create an alternative chain that discards the block containing the original deposit transaction. Now, proof-of-work chains have a longest chain rule, where nodes are expected to follow the chain with most amount of work, i.e. computational power dedicated to solving the cryptographic puzzles required to find a valid block. 3. Creating a longer chain is trivial for the mining pool because it controls 51% of the computational power and has an outsized probability of winning the race to find the next block that extends the chain. The new chain, without Alice's deposit transaction,

replaces the old chain, which includes Alice's deposit, as the canonical chain, erasing the record of Alice sending 32 ETH to the deposit contract from the chain's history. 4. Alice is now in a good position to eat her cake and have it. Her validator is already active on the beacon chain, with a withdrawable balance of 32 ETH, but the POW chain shows her as having the 32 ETH she deposited to fund the validator. Alice can then double-spend her funds by creating a new deposit transaction and activating another validator with a balance of 32 ETH on the beacon chain. 5. The next proposer on the beacon chain requests the latest block header from a miner and receives

the block containing Alice's second deposit transaction. The proposer, and indeed, the entire network, cannot discover the double spend attack because it doesn't process blocks from the POW chain. Specifically, the validator is a light node of the ETH1 chain. It can prove Alice made a deposit transaction by creating a Merkle proof showing Alice's transaction as part of the block, but it cannot know if the block itself is valid, i.e. the block updates the blockchain's state correctly. 6. Once the protocol, inevitably, creates a new validator for Alice, she will have a withdrawable balance of 64 ETH on the beacon chain. Provided the amount of the bribe paid to the mining pool

to execute the 51% attack is lower than Alice's withdrawable balance, the attack is profitable. Note that the miners in this example don't suffer any punishment for building a chain that reverses transactions. If the majority of miners are honest and follow a minority chain that keeps Alice's transactions intact, the mining pool will have wasted computational resources on mining an alternative chain. The cost of adversarial behavior is implied. In contrast, beacon chain validators shave an explicit financial cost to committing infractions, having their coins destroyed by the protocol. I describe this property, known as accountable safety, in a section from EIPs for nerds number 3. EIP 7251.

Increase max underscore effective underscore balance. This example shows why trust a miner to give you trusted info about deposit transactions was non-ideal for validators operating the ETH1-ETH2 bridge. It also highlights the importance of a secure mechanism for securely transmitting information about deposit transactions from the execution layer to the consensus layer. An ideal implementation of this mechanism will be secured by the beacon chain itself and avoid relying on the honesty of parties external to the protocol, e.g. miners, which is why the poll exists today. What is the ETH1 data poll and how does it work? The poll is a process by which a committee of beacon chain proposers come to a consensus on the state of the execution

layer, especially the state of the validator deposit contract. The poll occurs over 2048 slots and requires aproposer participating in voting to include an object that represents its view of the execution chain's state in a proposed block. The included in a beacon block comprises the hash of an ETH1 block, the root of the deposit Merkle tree, and the total number of deposits in the deposit contract and is a vote for the execution layer's state at a particular block height. The beacon chain uses uses a simple majority rule to decide the winner of the poll. An ETH1 underscore data must receive votes from more than half of proposers in the voting period

1024 or more to win the poll if a majority of proposers are in favor of one ETH1 state by the end of the voting period i.e. one half of proposers include the same, and in proposed block, the deposit tree is finalized and Beacon Chain updates the value of. Pending deposits included in the deposit tree at that time become eligible for processing, proposers create Merkle proofs to verify the inclusion of deposits in the deposit tree, which validators verify during the beacon chain state transitions. If no receives enough votes to meet the required threshold, a new voting period starts at the beginning of the next epoch. Pending deposits cannot be processed and must wait until

the majority of proposers are in a favor of one of one state. The security of the poll rests on the assumption that the majority of proposers greater than one half in the voting period are honest. That is, proposers include valid in blocks and vote for correct. A proposer isn't punished if it includes the wrong in a beacon block, but the requirement to have at least half of the voting committee include the same set of and in blocks proposed during the voting period provides strong guarantees of security. Having a large committee, 2048 proposers, reduces the odds a single adversarial actor can gain control the majority of proposers during polling. Given a large validator set, the probability of an adversary-controlled validator getting selected to propose a block in 1024 slots, out of a total

2048 slots in the voting period, depends on the adversary's capacity to control a supermajority of the validator's stakes. The infeasibility of one person owning two-thirds of staked ETH is the basis of the honest supermajority assumption, i.e. two-thirds N of staked validators are non-adversarial, which determines the security properties of the poll and the safety of the ETH 1 ETH 2 bridge. The N-honesty assumption also underpins the beacon chain's security model. For example, an attempt to revert finalized blocks will result in the slashing of at least one-third of validators, provided the other two-thirds of validators are honest.

Based on this analysis, the ETH 1 ETH 2 bridge has the semblance of being as secure as the core protocol. But this isn't the case, as we'll see in the next section analyzing the security weaknesses of the ETH1-ETH2 bridge. Analyzing security of the ETH1-ETH2 bridge, retrospective analysis of the ETH1 data pool has revealed weaknesses that allow an adversary controlling less than two-thirds, or 66%, of the active state to compromise polling and exploit the ETH1-ETH2 bridge. We'll analyze some potential attack vectors in this part of the article. Censoring deposits via the ETH1-ETH2 bridge an adversarial controlled minority of validators of can prevent the beacon chain from reaching consensus during the poll by deliberately voting incorrect or refusing to vote at all. Other, honest, proposers will ignore invalid ETH1 data, but the adversary can dilute committee votes such that no set of meets the required threshold

votes from 1024 proposers. This is a liveness failure. The beacon chain cannot process pending deposits until another round of voting, lasting 2048 slots or approximately 8 hours, ends with a clear winner. If the adversary's validators continue to vote incorrectly and prevent the beacon chain from reaching consensus on, it can censor processing of deposits and prevent onboarding of new validators for as long as possible. Note that censoring deposits is economically rational from a validator's perspective since the total rewards accruing to each validator reduces as the validator set grows. Greater than another factor to consider regarding GER, gross rewards rate, fluctuation is greater than validator dilution. The more validators contribute to the network,

the more greater than staking rewards are diluted among them, as validators are less likely to be greater-than-chosen as block proposers. With currently almost 500k active validators on the greater-than-beacon chain, the current consensus layer staking yield is 4.16%. With 800k greater-than-validators, that number falls to 3.29%. Emmanuel Nalipa, POS Ethereum, staking rewards, a deep dive. Exploiting the ETH1 ETH2 bridge and adversary with close to half, 47%, of the total validator stake can exploit the ETH1 ETH2 bridge by finalizing invalid. Finalization of requires the block that updates state ETH1 data with the set of and is confirmed by a super majority of validators over two epochs. This is a key part of the deposit processing mechanism that provides security.

Validators are expected to maintain a connection to an execution ETH1 node and verify that and belong to a block included in the canonical ETH1 chain. If an invalid deposit tree root is finalized, a malicious proposer can create fake proofs of deposits that verify against the fake deposit tree root. Their result, which I described in the example of Alice double spending validator deposits, is that we end up creating new validators on the beacon chain without those validators depositing 32 ETH to the deposit contract. An attack like this one has negative implications for the beacon chain security. The point of proof of stake is to make it as expensive to join the validator set as

possible, so it really hurts when the protocol destroys a validator's stake and ejects them from the consensus protocol. This is why we require every validator to lock up a minimum amount of collateral, 32 ETH, in the deposit contract before it starts validating transactions. But this security property breaks down when some validators are able to join the validator set without processing deposits. For example, if Alice is able to double spend her 32 ETH deposit multiple times, she will have a disproportionate amount of Ether staked on the beacon chain relative to validators that deposited once. This means Alice can afford to risk committing slashable offenses, e.g. voting invalid blocks or reverting blocks, because the protocol is taking money she got for free. The attack also

affects Ethereum's execution layer negatively. If Alice starts withdrawing validator balances from the beacon chain to the execution layer withdrawal address, she can bypass the protocol-enforced issuance policy and print more money out of thin air than the Federal Reserve. This will, inevitably, crash the market value of ETH, which is tied to scarcity and supply, and then reduce the appeal of holding, spending, and using ETH, with implications for financial applications running on Ethereum. In theory, a safety attack on the ETH1-ETH2 bridge requires two-thirds of validators, 66% of state, to collude and finalize a beacon block that incorrectly updates state. ETH1 data, but an adversary with 47% of the total effective balance can achieve a similar goal 1.

If 47% of validators vote for a different block than the other 43% of validators, the beacon chain, which requires at least 66% of validators to agree on the validity of the same block cannot achieve finality. The beacon chain will thus split into two competing forks since we have close to equal halves of the validator set attesting to different blocks at the same height. 2. If neither chain finalize a block for more than a fixed number of epochs, the inactivity leak will kick in and reduce the balances of active validators that failed to attest on each fork. Decreasing the stakes of non-voting validators ensures the remaining set of validators on each fork can reach the threshold, two-thirds of the active stake,

required to finalize blocks. 3. The inactivity leak can ensure the minority of validators can finalize the chain with the correct ETH1 data. However, the attacker has the upper hand and requires just 21% of validators to double vote. Adversaries validators plus 21% double voting validators equals 66% supermajority to complete the attack. In normal circumstances, double voting, voting for two conflicting blocks in the same slot, is disincentivized. But it becomes easy, important even, for validators to hedge their bets by double voting during a contentious fork. Recall that the value of the ETH staked by a validator depends on which fork is considered canonical at the end. If Bob's 32 ETH is on fork A, but fork BIS accepted by exchanges, applications, and everyone else is the valid fork,

Bob's ETH loses value, except the fork a chain becomes the new Ethereum classic. Fizz makes double voting, voting on blocks on two chains, the dominant strategy for validators like Bob, a situation that plays nicely into the attacker's hands. Once fork B, which we consider the attacker's fork, becomes the canonical fork, it can finalize an invalid deposit underscore root and start processing fake deposits. The attacker can only process up to 16 deposits per block and 512 deposits per epoch, which is 16,384 ETH per epoch, 16,32 ETH per validator. But then, IT can keep processing invalid deposits as long as it takes to recoup all of the funds used to bribe validators and make a healthy profit from the attack. Analyzing the ETH1 ETH2 bridge's

performance and efficiency security problems aside, the design of the bridge also induces a couple of other issues in the area of performance and efficiency. These also have to do with the distinction between the execution, ETH1, chain and consensus, ETH2, chain before the merge. Suppose we trusted the majority of proposers to act honestly during polling, we still wouldn't be able to make the same assumption about miners running the ETH1 POW chain. The proposers voting in the poll might include valid ETH1 block routes but, as the example of Alice's deposit transaction showed, a set of colluding miners could revert the POW chain and allow malicious validators double-spent their deposits.

Since free entry into the beacon chain's validator set threatened economic security of Ethereum's proof-of-state protocol, it was necessary to isolate the ETH2 chain from failures in the ETH1 chain. E.G. Chainray Organizations. The solution? Impose a delay on the processing of deposits to make deposit processing resilient to reorgs. Known as the ETH-1 follow distance, this delay determined when the ETH-2 chain would even consider a set of deposits pending in the deposit contract. The ETH-1 follow distance was first set at 1024 blocks and later increased to 2048 blocks, and a proposer was expected to only consider blocks at a depth higher than this value when choosing blocks to vote for in the poll. For example, if the beacon chain was at block number 6144, the validator responsible for proposing beacon block number 6145 was expected

to consider only deposit contract data from ETH1 block number 4096 onward as eligible candidates for an vote. This ensured that deposits processed on the ETH2 chain never ended up in a reorg ETH1 block number 4096 onward as eligible candidates for Envote. This ensured that deposits processed on the ETH2 chain never ended up in a reorged ETH1 block, except the ETH1 chain reverted blocks for more than 8 hours. We derived the 8-hour window by multiplying 2048 blocks by 14 seconds. Besides making the ETH1-ETH2 bridge resilient to reorgs, the ETH1 follow distance gave meant protocol developers and the community had enough time to respond to major issues on the execution. ETH1, chain that might affect deposit processing on the consensus layer, E, G. A chain split, but the improvement in security came with a significant trade-off. Validators couldn't

process deposits instantly and would need to wait approximately 16 hours, 8 hours for ETH1 follow distance and 8 hours for voting period. Note that this calculation doesn't account for other delays, like the time a deposit transaction spends in the mempool before it is included in a block. But wait, there's more. Relying on the polling to import the execution layer state into the consensus layer before processing deposits also has more negative effects beyond delaying increasing onboarding friction for new validators. Inefficient deposit processing. The requirement for deposits to wait in the deposit contract for at least 8th or so distance already imposes a significant delay on processing of deposits in the consensus layer. But other factors can exacerbate this delay

and increase the time it takes to deliver a deposit to the beacon chain via the ETH1-ETH2 bridge. An example, proposers are restricted to including 16 deposit operations per beacon block to bound the size of blocks and avoid burdening validators with high resource requirements. As mentioned, deposits included in beacon blocks must be accompanied by a Merkle proof that each validator verifies against the root of the deposit Merkle tree stored in. Validators must perform a minimum of 32 hashing operations to compute the root of the deposit tree

from the Merkle branch received from proposer, which is extra computation on top of routine block processing on the consensus layer. Also note that the Merkle proof for each deposit, an array of hashes, adds extra data to the body of a beacon block, further necessitating a limit on the number of deposits that each block can include. Given this limit on deposit operations, a depositor may have to wait more than 17 hours before their deposit, or balance top-up, can be processed, depending on how many deposits

have been processed since the last polling period and the number of pending deposits. Increased engineering complexity. The complexity associated with maintaining the ETH1-ETH2 bridge comes from a number of areas. Retrieving and syncing ETH1 data consensus clients maintain an fetcher component that regularly queries the execution client using the JSON RPC API for information related to the deposit contract. For example, proposers rely on to perform the operation that calculates the root of the deposit contract's Merkle tree to extract deposit vents emitted by the deposit contract from transaction receipts. More on this later, and to retrieve the list of block hashes eligible for

voting in the poll. Validators are also required to hold a local copy of the deposit Merkle tree and verify that the route matches the from the winner of the poll. This requires running the operation to download event logs from previous logs and extracting deposit events from each block where a deposit was made and building a Merkle tree out of the list of extracted deposits. Unlike proposers, validators don't need to interact directly with the deposit contract and can perform this task by interacting with a local execution client using the JSON RPC API. The Fetcher component is, however, a complex piece of software to maintain and operate. That complexity probably explains why a decent number of node

operators have experienced issues with their nodes failing to pull deposit contract logs or returning incorrect deposit receipts and corrupting the deposit contract data in worst case scenarios. Some client developers suggest that inconsistencies in the implementation of the JSONRPC API may be contributing to the problem. Different clients use different methods to retrieve deposit receipts from blocks, which can create an issue IFA consensus client requests deposit contract data using a format that the attached execution client doesn't implement or support. Corrupted deposits history detected, loop, with basu, source. The complexity of the syncing process also affects the onboarding experience

for new validator node operators. Typically, a beacon node needs to sync the execution client from Genesys as part of the normal workflow before it can start validating and processing blocks. But it also needs to sync the deposit contract logs to extract and process historical deposits before it can fully catch up with the rest of the network and start proposing or testing blocks. Having to rebuild the state of the deposit contract from scratch adds to the workload for a new validator. The problem is more complicated for individuals who just want to run a beacon node to track Ethereum's consensus layer without it testing or proposing blocks. Some have called for consensus clients to implement an option to disable syncing of historical deposit logs for this reason. Lighthouse already has an option for non-staking beacon nodes to skip syncing of historical deposit receipts, but this doesn't

seem to be standardized across other client teams yet. Storing ETH1 data consensus clients are required to store a cache of historical deposit receipts, extending to the beacon chain's genesis, in order to validate new blocks necessary for rebuilding the deposit Merkle tree and verifying Merkle proofs of deposits as mentioned previously. While the deposit contract can theoretically store all the deposit data as leaves in a Merkle tree, storing deposits in evenlogs is cheaper for certain reasons and, importantly, reduces the on-chain footprint. The downside to storing historical deposits in logs is that it constrains validators from pruning parts of the chain's history dating back to the deployment of the deposit contract.

This increases disk requirements for execution nodes and also represents an obstacle to history expiry proposals Likeeip4444 designed to reduce the amount of archival data execution clients must process. To understand the difference between history and state, I encourage reading Ethereum org's page on statelessness, state expiry, and history expiry. Voting for eth1 data eth1 data voting seems straightforward on paper. 1. Query the attached execution node to retrieve a list of execution layer blocks that fall within the approved time window at the start of. The depth of each block in the list should trail the most recent beacon chain by 2048 blocks, and a block's depth cannot exceed. 2. Count up the valid votes for

ETH one block hashes seen so far by checking in the beacon chain state. Vote for the ETH one block hash with the most votes by including the root of the deposit Merkle tree at that block height, as well, number of pending deposits, and, block header hash, in the field of the beacon block. 3. If no ETH1 block hash satisfies the requirements from step number 1, cast a vote for the current ETH1 block hash and deposit route stored in the winner from the last voting period, if. If you're the first proposer in the voting period, cast a vote for the most recent ETH1 block hash that meets the requirement from step number one. I'm largely oversimplifying things here, but that's because the voting

mechanism is designed, in principle, to be simple. Even so, implementing polling has proven difficult for many client teams. This reduces the efficiency, effectiveness of the poll, as proposers cannot come to agreement quickly on a common view of the deposit contract and finalize pending deposits. Ben Edgington's analysis of ETH1 data votes on Medalla provides a pretty good overview of the issues client teams have faced with getting the implementation to work correctly. The analysis, which used data collected over 72 voting periods, 2,304 epics or approximately 10 days, on the Medalla testnet, points out a startling metric. The chain failed to agree on an ETH1 block hash in 22% of voting periods. Interestingly, there were no failures to reach

a 50% plus 1 majority on the root of the deposit's Merkle tree throughout the same period. According to the author, this discrepancy was likely because the deposit tree root changed less frequently than the block hash. There were 3 to 140 block hashes voted for during the same period. Since was, arguably, more important, it was suggested to have proposers come token census separately on in. The data suggested proposers found it easier to agree on deposit routes compared to block hashes, so removing the dependency between block hashes and deposit tree routes could significantly improve the efficiency of tracking deposits. You can see the code snippet of the proposed design below.

The proposed design altered the voting strategy to expedite finality for deposit routes and remove blockers to processing deposits and onboarding new validators. But it also introduced some unnecessary complexity in the specification. Unnecessary because the honest validator specification already proved is a straightforward mechanism for proposers to reach consensus on without issues. In theory, proposers can include different since and change according to the number of deposits from the previous block, which would make it difficult for a majority of proposers to agree on the same. However, if each proposer followed the honest validator specification, voting with the majority, we should have at least one half of proposers including the same in blocks before the voting period is over. Here's a reply to the suggestion

from Danny Ryan, core developer at the Ethereum Foundation, for context greater than. This seems like implementation errors rather than spec errors. Any failure to greater than agree on a block hash deposit root combo after the first epoch, assuming max one greater than agree on a block hash deposit root combo after the first epic assuming max one greater than epic latency is just a failure to follow the spec votes to consider should greater than be 100 in agreement amongst implementations if we assume there are no forks greater than in the eth1 chain 1000 plus blocks deep this is true in gorely 100 of the time greater than then if votes to consider is in agreement and I am looking at a handful of greater than blocks, my vote is entirely deterministic regardless of

client implementation greater than and should quickly solidify as the chain during that voting period grows greater than deeper. I'd like to better understand why the issue in conformance before we greater than go change the spec. Realworld data suggests Danny's position in the quote I included above has Soma merit. For example, the Prism consensus client merged a pull request, less than a month after Ben's post, to align the client's implementation of the majority voting algorithm with the official specification after a user pointed out discrepancies between the implementation code and the official spec in the implementation. TQ also made a similar patch to its consensus client after discovering subtle deviations from the honest validator

specification for running the poll. Can we improve ETH1 data polling and fix the ETH1-ETH2 bridge? So far we've identified two major categories of issues with the ETH1-ETH2 bridge and the deposit processing mechanism, security and performance. Different solutions have been proposed to remedy some of the problem. Adjusting winner thresholds and voting strategies for the ETH1-DATA poll after highlighting the possibility of an attacker with 47% of the total active stake exploiting the bridge, Mikhail Kalinin suggested increasing the winner threshold for the poll from 50% to 60%. An adversary could only gain a supermajority of proposers during the voting period,

1,228 proposers, if it controlled a supermajority of the total active state, bringing the security of the ETH1-ETH2 bridge in line with the security of the beacon chain. That said, this solution sacrificed some measure of safety for liveness. What do I mean? The new threshold required 60% of proposers in the voting period to attest to the same view of the execution chain's state, which increased the impact of a minority that, deliberately, refused to vote for ETH1 block hashes or cast incorrect votes on purpose. Another proposal, from the same post, was for attesters and proposers to share the responsibility of importing into the beacon chain. Attesting validators included an inattestations and was updated with the set of that received votes from two-thirds of validators. This solution

allowed the chain to finalize deposits much faster and, importantly, coupled the security of the ETH 1 ETH 2 bridge with the beacon chain's security, as long as two-thirds of validators are voting correctly, the chain couldn't be tricked into accepting invalid. However, the main concern with this approach at the time was the increased load on the networking layer. With validators attesting to every epoch, each attestation needed extra 64 bytes for and the size of an attestation message increased by nearly 50%. Reducing the ETH1 DATA voting period and ETH1 follow distance reducing was a fairly straightforward solution to the problem of delayed deposit processing. But the boost in efficiency of the ETH1 ETH2 bridge came at the expense of the safety of deposit processing. If the voting period was reduced, the probabilities of an attacker controlling a majority of proposers in the committee voting on would also increase.

Below is a table showing the probabilities of an adversarial takeover of the poll at different parameters for. Notice the differences in probabilities when voting period is decreased to 128 slots and 64 slots. Another proposal, from the same post, was to reduce AFRAM 2048 blocks to Asmaller figure. At the time, this was a risk for the reasons I explained previously, e.g. the risk of miners going rogue and executing short-term reorgs. This is no longer a risk in the status quo where the beacon chain finalizes the execution layer. But the question remains. Why should we try and FIX the ETH1 ETH2 bridge by adjusting parameters if it's already redundant? Sinking deposit receipts with deposit contract snapshots EIP-4881. Deposit contract snapshot interface

solves certain problems associated with the current deposit processing mechanism. New consensus nodes must download deposit receipts from historical blocks to process blocks when syncing the beacon chain, increasing syncing times and creating friction for onboarding validators. Active consensus nodes also need to maintain a cache of historical deposit receipts if they want to create valid Merkle proofs for deposit transactions when proposing new blocks. EIP-4881 solves this problem by creating an interface for consensus client implementations to bootstrap syncing by transmitting snapshots of the deposit contract's state at specific block heights. These snapshots contain finalized deposits and can be used to rebuild the deposit Merkle tree and verify Merkle proofs for new deposits without syncing historical deposit contract logs. This makes it easier to sync a new beacon node and provides a solution for

execution clients that wish to prune historical data from their local databases. While EIP-4881 is an improvement to Node Operator UX, it is a workaround, not a sustainable, long-term solution. Some reasons distributing EIP-4881-style deposit contract snapshots may prove unsustainable It places a burden on teams building consensus clients to create and maintain additional features. Ideally, client teams would only have to reason about sinking expensive engineering hours into designing and maintaining only the most critical components of a consensus client. Client development teams are implicitly trusted to provide correct deposit contract snapshots. A validator can choose to verify deposit contract snapshots against other sources, but this somewhat defeats the purpose of reducing the difficulty of syncing a new node. EIP-6110 and revamping the beacon chain's deposit request process like many aspects of the

beacon chain's design, the current mechanism for processing deposit requests is accumulated tech debt from the pre-merge days. If execution and consensus layers were connected, we wouldn't need a bridge mechanism to pass information about deposits as both protocols would be validated by the same set of consensus nodes. But things have changed rapidly since the merge. Ethereum's execution and consensus layers operate synchronously. Every beacon chain block includes execution layer data in the block body. This means deposit contract data, i.e. deposits receipts, required to process deposit transactions on the beacon chain is now available on-chain by

default. Consensus nodes no longer need an Fetcher component because the deposit contract data is visible on-chain and accessible to a validator's attached execution client. The problem of reorg deposits has also ceased to exist. Ethereum's fork-choice rule enforces a tight coupling between the execution and consensus layers by requiring CL blocks to include the header and body of the latest execution block. This removes the possibility of reorging EL blocks containing deposits without reorging finalized CL blocks and implies that the delay on deposit processing, a consequence of an is surplus to requirement. The execution layer is now finalized and secured by the consensus layer.

Each validator is expected to verify the execution payload of a beacon block, which stores information about the L state, including the root of the deposit contract Merkle tree, meaning all honest nodes have the same view of the deposit contract at all times. This makes the ETH1 ETH2 bridge for importing block hashes into the beacon state and the pole for securing the process altogether unnecessary. These observations underpin EIP-6110, which proposes the most comprehensive overhaul of the beacon chain's deposit processing system to date. EIP-6110 removes pole and ETH1-ETH2 bridge and introduces a newer, more efficient mechanism for processing

deposits and onboarding validators to the beacon chain. I'll dive into EIP-6110's approach to reforming the deposit process, but first, let's take a detour to understand a concept that'll come up frequently in the discussion of EIP-6110, events and transaction receipts. Interlude. A crash course on smart contract events and transaction receipts. Events smart contracts fire or emit events during execution. For example, a token contract may fire an event if ownership of the token is transferred. An event is semantically equivalent to something that occurred on chain. Logs are used synonymously with events but have a different meaning. A log is generated when the contract emits an event and provides

details about the emitted event. Smart contracts generate logs by firing off events and logs describe the outcomes associated with the event. Anytime a transaction is processed, we can view the transaction's event logs by making a request to via the JSON RPC API to a full node and take further action based on the results of the transaction. For example, if a buyer is paying for a cup of coffee in DAI, we can call on the DAI ERC-20 token contract to confirm the buyer's payment before processing the order. Logs have a topic and data field. Log topics are 32-byte words that describe the inner workings of an event.

The EVM, Ethereum virtual machine, has five opcodes developers can use to emit events and create log records logs, and the opcodes describe how many topics can be included in a log. The deposit contract uses the opcode as it has only one topic 1. The first part of the log, topic topic contains an array of log topics describing the event and can hold up to five topics depending on the log opcode used the first topic usually stores the event signature a hash of the event name and parameters of the function whose execution emits an event the deposit contracts event log which uses the opcode has only one topic the signature the kecca k256 hash of deposit event is the name of the event emitted by the deposit contract when a deposit is processed

and the bytes refer to the hex encoding of the inputs to the function among other things a 48 byte value representing the public key of the validator the public key is derived from the private key generated from the validator's seed phrase or mnemonic and represents the validator. The public key is derived from the private key generated from the validator's seed phrase or mnemonic and represents the validator's cryptographic identity in the consensus protocol. The amount of ETH to deposit denominated in GUI, a subunit of Ether. A depositor can send the full deposit, 32 ETH, to register a new validator or top up the balance of an active validator. It can also build up the 32-ed deposit required to activate a validator over multiple deposits. The address to receive the validator's full, partial withdrawals from the beacon chain.

Withdrawal credentials start with 0x0 or 0x1 depending on whether the validator is using a BLS, BANA Lin-Sachman, withdrawal address or an execution layer address. See EIPs for NERDS number 2, EIP 7002 for a great introduction to different types of validator's withdrawal credentials. The signature generated by signing the previous three fields with the validator's signing key. The signature is required to protect against a rogue key attacks that can enable attackers to create invalid validators in the beacon chain. The signature is required to protect against a rogue key attacks that can enable attackers to create invalid validators in the beacon chain. The index is an output of the deposit operation and is assigned to each deposit processed by the deposit contract. A value that increases

each time a new deposit stored in the deposit contract. 1. The second part of the log, data, contains encoded data relevant to the event. This information can be indexed in the topics field, but log topics have a 32-byte limit, whereas data fields are unlimited storage. The data field can support storing complex types like strings and arrays, which makes it useful for our use case, storing an array of inputs to the deposit contracts function so that we can later extract it by parsing deposit contract event logs and record it in the beacon chain's state when processing a validator's deposit for the first time. Transaction receipts When a smart contract emits an event, the associated log data is written and recorded in a transaction receipt.

A receipt is a record of outcomes associated with a particular transaction and includes details like the logs generated during transaction execution and the transaction status code, E.G. Failed or successful, transaction receipts are stored in the receipts tree of a block, which isn't part of Ethereum's global state and receipt data as inaccessible to the smart contract. Nodes can extract receipts from historical blocks by running an archive mode or requesting the data from an archive node. In comparison, account storage can be accessed by the smart contract and ice-persisted in Ethereum's global state, but is more expensive to use because every node must hold state and the state grows indefinitely, which increases storage disk requirements. We need to make sure the cost of storing and accessing state data is enough to incentivize nodes and high enough to prevent abuse. This makes event logs cheaper for storing data compared to

saving information in a smart contract's storage. Log data costs 8 gas per byte and account storage costs 20,000 gas per 32 bytes. The deposit contract's event data is 576 byte ABI encoding of and below is a sample event data emitted by the deposit contract after a successful deposit. The application binary interface ABI specifies how to interact with a smart contract like the deposit contract whether from another or via an off-chain service. The ABI for a smart contract includes the contract's function names, input parameter, parameters, constants, event types, logs, and data structures. ABI encoded data is not human-readable, but we can implement ABI decoding using information from the ABI to translate the

result of a contract's execution into human-readable syntax. This overview of contract events and receipts is, admittedly, into the weeds, even I, had trouble grasping some of these concepts initially. But a basic understanding will make it easier to understand EIP-6110, which uses the terms, deposit events, and, deposit receipts, in many parts of the specification. With that out of the way, we can see how EIP-6110 works at a high level. An overview of EIP-6110. Supply validator deposit requests on chain. At a high level, EIP-6110 works as follows. 1. The execution client parses deposit request contract event logs and explicitly exposes deposit requests to the beacon chain by including deposit request data in the execution payload of a beacon block. When building the execution payload, the validator's execution

client scans for deposit request transactions that emit a deposit request event in the block and extracts the deposit request data and from the corresponding logs. The extraction of deposit requests from a block is order-sensitive, it must strictly follow the order in which deposit requests generate event logs and receipts appear during the block's execution. After extracting deposit requests from transaction receipts, the execution node's block production component populates the deposit requests field of the block with deposit request data. The block producer is expected to include all pending deposits, up to the maximum, in the execution payload before passing the payload to the beacon node via the engine API. 1. Upon receiving an execution request with a list of deposit requests, the validator passes the requests to its execution client to verify the deposits. The validator's execution client will proceed to extract deposit requests from the events emitted by deposit requests included in the block and compare the two sets of deposit requests. The extraction of deposit requests from a block is order sensitive. It must strictly follow the order in deposit

requests generate event logs and receipts appear during the block's execution. The validator's execution client is required to verify that the list of extracted deposit requests is equal to the deposit requests in the payload of the proposed beacon block. Besides having the same number and ordering of deposit requests, the values for each deposit request operation in the list of deposits must also be the same. Honest validators that detect conflicts between the extracted deposit request operations and the deposit requests supplied by the proposer are expected to reject the entire block. 1. After the validator's execution client has verified the deposit requests included in the execution request, the consensus client can securely read the deposit data from the beacon block and process each validator's deposit per

the normal workflow. The proposer isn't required to include a Merkle proof to verify inclusion of the deposit request transaction in the Merkle route as the execution layer already verifies the existence of deposit. You'll notice in this scheme that a validator's deposit request is processed in the same block where it appears. This instant inclusion of deposits is thanks to EIP-6110 deprecating the pole and surfacing deposits on-chain for validators to process immediately. EIP-6110 also fixes some of the problems I highlighted earlier, such as the reliance on the JSON-RPC API to fetch historical block hashes and sync deposit requests cache. Since the execution clients are already expected to download execution payloads,

which provides real-time access to transaction receipts, is no longer necessary. We'll go over more of EIP-6110's benefits after looking at the changes introduced by EIP-6110 based on the specification. Execution Layer Changes 1. Define a new deposit request structure based on EIP-7685 and modify T-H-E-E-N-G-I-N-E API to include deposits requests in execution REQUESTSEIP6110 defines a new deposit operation and modifies the engine API to include deposit request operations in execution requests via new deposits field. The deposit object is the same as the signed by validators when making a deposit transaction, the deposit contract emits the deposit data A. The new deposit request

operation has the following structure the deposit object forms the basis of EIP-6110's objective of supplying validator deposit requests on-chain. Beacon nodes already have access to deposit request transactions via the execution engine, but a consensus client cannot parse deposit request contract logs and decode ABI-encoded deposit data. Execution clients, however, support ABI decoding and provide access to deposit request data by including deposit request data in the execution requests in a format that consensus clients can translate. EIP-6110's deposit object includes an index, an unsigned integer value assigned to each deposit that's accepted by the deposit request contract, as mentioned previously. The index functions like

a transaction nonce and ensures deposit requests can be processed once. The index is also stored in the beacon chain state, which ensures deposit requests are processed sequentially and proposers cannot skip pending deposit requests. More on this later. 2. Modify execution request headers to take a list of log events of Depositrix TS and update the execution engine to validate deposit request operations after extracting deposit requests. Sequentially, from deposit request contract logs, the execution engine creates a list of log events of deposit request operations. The list of the deposit requests object is included in the header of the execution request

as a hash and acts as a cryptographic commitment to the list of deposit request operations in the block. A validator's execution node performs a similar routine, computing the hash of the deposit request list that encodes deposit request operations as hash commitments, and compares the hash with the deposit request list in the header of a beacon block's execution payload. Honest validators are expected to reject a proposed block if the commitment conflict. The code for extracting deposits from deposit request events looks like this. 3. Add the deposit request contract address to the engine. A PCONFIGURATIONFILEA transaction can perform multiple actions and generate different logs, so we need a mechanism to identify logs that refer to deposit events in a block. A logis associated with a deposit event

if the log address, the address of the smart contract that generated the log, is the deposit contract's address. EIP-6110 introduces a object into the engine API's configuration file to ensure execution clients extract deposits requests from the correct event logs. Consensus layer changes. 1. Modify beacon block structure to include deposit requests. The structure of beacon beacon block structure to include deposit requests. The structure of beacon block is modified to include a new object. The object is the same as the deposit object included in. A separate name is used for EIP-6110 style deposit operations on the beacon chain to avoid a conflict with the existing deposit operation. The object has the

following structure. Beacon blocks can include a number of deposit requests up to. Note that is an implied limit on deposit operations and is equal to the number of deposits that can be packed into an execution block given the gas limit 30 million gas. In comparison, the current that currently limits deposit request operations is explicit. A validator is expected to confirm that a proposed block doesn't include more than 1,271 deposit requests during beacon block processing. The beacon block also takes new deposit requests, list of the deposit requests sparsed from the block's logs, that is similar to deposits hash. The deposit requests field is the commitment to the list

of deposit requests from a beacon block and should equal the deposits hash computed by a validator's execution engine after extracting deposit requests from a beacon block and hashing them together to create a. Note, the term deposit request may be a misnomer since we're including data from event logs contained in block logs. Some will describe the deposit request contract as emitting a deposit requests for accepted deposits, which is slightly inaccurate a transactions log can include multiple logs, and not all logs have to contain a topic and data associated with a deposit request event. This is why EIP-6110 specifies a deposit request contract address to help identify deposit request event logos from a block's logs. 2. Extend process underscore operations. With process underscore deposit underscore request, the process underscore operations function covers the tasks a validator must perform to process a

newly proposed beacon block and update the beacon chain's state. Thistodue list includes processing slashing of proposers and attestations, voluntary withdrawal operations, deposits requests, and balance top-ups. EIP-6110 modifiesto include operation to accommodate the new deposit request operations. A couple of things are happening in this function. First initializes the in the beacon state, is, unset, as at the fork block, by setting to the when the first deposit request is processed under the new mechanism. This tracks the number of deposit requests that have been processed so far more on this later. Applies the deposit to the beacon state to either

create a new validator in the beacon state or top up an existing validator via the function is already implemented in consensus clients which helps with code reuse. The function is already implemented in consensus clients, which helps with code reuse. The operation is where the validator's signature is checked for the first time. The deposit contract doesn't verify the signature in the because the EVM doesn't currently have support for verifying BLS 12-381 signatures. EIP-2537 is a proposal to add a precompile for BLS 12-381 signature verification, which may change the situation. An implication is that an attacker can send fake deposit request transactions that are doomed to fail on the consensus layer and perform a dose, denial of service, attack by

causing consensus nodes to waste resources on validating bad deposits. 3. Extend BEACONSTATE with deposit underscore requests underscore start underscore index consensus clients save a value in the beacon chain's state that tracks the total number of deposits processed by the protocol. The is incremented by one for each processed deposit request and equals the index assigned to the most recent validator deposit by the deposit request contract when the deposit request was made on the execution layer. Recall index is part of the event data emitted by the deposit request contract. By saving the in the beacon state, we can prevent proposers from accidentally, deliberately excluding pending deposit requests. For example,

if the current is 1000, the next validator deposit request should have an index of 1001. If the deposit request instead comes with an index of 1002, a validator knows that at least one pending deposit request was skipped and should reject the block. EIP6110 introduces a to serve a similar purpose as the tracks the number of deposit request operations that have been processed by the beacon chain UNDERIP 6110 and ensures deposits requests are processed sequentially. If a proposed block skips one or more deposit requests from the deposit request contract, the end state will diverge from the resulting state obtained by an honest note applying deposit requests in the correct order. 4. Deprecating ETH1 DATA poll by adding deposit underscore requests underscore start underscore index ANDETH1 underscore deposit underscore index limit the length of ETH1 follow distance means there will be a transition period

during which deposit requests approved in the poll are yet to be processed, but validators on the beacon chain have upgraded consensus clients to start using EIP-6110s in protocol deposit request processing mechanism. During this transition period, validators have to maintain different sets of deposit request operations. Deposits to be processed using the old operation and deposit requests to be processed using the new operation. EIP-6110 makes some modifications to ensure a smooth transition period and prevent old deposits from conflicting with new deposit requests 1. The object is modified to include a new field that stores the index of the first deposit request

included on chain per EIP-6110 specifications. The value is initialized by the block that activates EIP-6110 and works with the to facilitate the deprecation of the pole and ETH1-ETH2 bridge mechanism. 2. A new value is added to the function to disable the former deposit mechanism once all pending deposits are processed. The will be the lesser of the number of deposits pending in the deposit request contract or the index of the first on-chain deposit request. Here's how the transition period works. 1. When processing a new deposit request, we check whether is greater than. If the index of the current deposit is lower than, we know that the transition period is still ongoing and there are pending deposit requests from the pole.

2. After confirming the status of the transition period, we check that the number of deposit requests is the lesser of 1,024 or. This check is crucial for confirming that a proposer has included all pending ETH1 ETH2 bridge deposit requests up to the maximum limit, 1,024 deposit requests per block. 3. If a new block arrives and at a specific deposit request is equal to, we know that this deposit request is the last deposit request from the pole. We disable processing of deposits under the ETH1 ETH2 bridge mechanism and deprecate the pole at this point. This means the is underscore valid underscore Merkle underscore branch check that

is performed when applying a deposit request. Verifying the Merkle proof against the stored-in is no longer necessary. 5. Modify process underscore execution underscore request to use deposit REQUESTSA's explained execution requests. Formerly ETH1 blocks and execution payloads now form a part of proposed beacon blocks. Beacon nodes do minimal processing on execution requests and leave most of the verification to execution clients. However, a beacon node must check that the of a new block is valid in the view of its execution node. This is where comes into the picture. Perform sanity checks on the request,

including checking that the header of the execution block stores the correct hash of the previous block's header. The hash is stored in the beacon chain state as and the timestamp on the execution request matches the current slow timestamp. Also stores header data from the current execution request in the under EIP-6110 is modified to store an additional piece of header data. This way, a consensus node validating the execution request of a new beacon block can confirm that a newly proposed block is correct with respect to the previous block, E, G. It includes the correct value for the previous blocks. This enforces a link between deposit

requests processed in blocks and prevents some of the edge cases described previously such as double spending of old deposits. Y E I-6110? The case for on-chain validator deposit requests. The benefits of implementing on-chain validator deposits requests per EIP-6110 may already be obvious from the discussion of the specification. However, this section will provide a more focused explanation of the advantages of reforming the current process for handling deposits. 1. Better security for deposit processing The security of the ETH1-ETH2 bridge is based on the calculated probabilities of a single actor controlling is greater than or equal to one-half of the validators selected to vote on during the poll. If a majority of proposers vote in invalid,

the ETH1-ETH2 bridge risks processing fake deposits or permitting validators to double spend deposits. Previous analyses reveal low probabilities of an adversary controlling the majority of proposers voting in the poll, suggesting the ETH1-ETH2 bridge is, mostly, secure in its current form. But we also noticed that the safety of the bridge can be compromised if a slightly lower fraction of the active validator set is dishonest. In other words, the ETH1 ETH2 bridge is not secured by the core protocol and doesn't derive safety properties from the beacon chains finality gadget, Casper FFG. EIP-6110 introduces an in-protocol deposit requests processing mechanism that requires all validators to validate deposit request transactions originating from the execution layer.

This increases the threshold of validators that an adversary must corrupt to exploit the deposit request processing mechanism from 47% to 66%. Two-thirds of validators weighted by stake and ensures deposit request processing is as secure as the beacon chain itself. If two-thirds of validators are acting correctly, i.e. validating deposit requests from execution requests, a block containing invalid deposit operations will be rejected by the protocol. It also takes just one honest whistleblower to publish evidence of a block including invalid deposit operations to slash the end validators

that attested to that block. The honest majority security model also improves the liveness of deposit request processing. In the current ETH1 ETH2 bridge, a dishonest minority of proposers can vote incorrectly or refuse to vote to block processing of deposit requests. In protocol, deposit processing eliminates the need for an poll so that deposit processing can only halt if two-thirds of validators collude to finalize blocks that fail to include deposits supplied by the deposit request contract. 2. Lower onboarding friction and better deposit UX for Node-OPERATORSFEWER delays on deposit inclusion since the merge, the execution and consensus layers operate synchronously. Beacon blocks include execution requests and validity of a beacon block is tied to the validity of the L request, preventing attackers from reorganizing blocks to erase records of deposit requests sent to the deposit

request contract. Thus a delay of to secure deposit processing against the possibility of long-term rewards on the execution chain is no longer necessary and we can process deposits instantly instead of waiting approximately 16 hours or more to onboard new validators. It is theoretically possible for longer reorgs spanning several blocks such that an already active validator has the opportunity to resubmit a deposit request transaction using EDS sent in an historical block. This is, however, very difficult to pull off in practice since it requires reverting beacon blocks per stone or more finalized checkpoints. An edge case that can only occur in the following cases the attacker controls two-thirds of the total stake death. A supermajority of dishonest

validators can collude to finalize a block that reverts previous blocks, which may contain deposits from the execution layer, and block a mass slashing event. Slashing requires two-thirds of validators, weighted by stake, to approve the slashing operation. The attacker is willing to burn ETH to perform a safety attack. Reorganizing finalized deposits requires building an alternative chain that reverts canonical blocks and convincing new nodes to join the non-canonical chain. Since validators staked on the other chain will be inactive, the inactivity leak will leak those validators' balances until both chains finalize separately. The above analysis implies that, within protocol deposit processing, the security of the deposit request's handling

mechanism is now tightly coupled with the security of the beacon chain itself. This allows for reducing the delay on deposit request processing without introducing any of the security issues that the previous design was supposed to correct. Another reason we can shorten the processing time for deposit transactions, besides removing the ETH1 follow distance and voting period, is Thetan protocol deposit requesting removes the need for complex verification of deposit data by validators on the consensus layer. Currently, each validator is required to maintain a copy of the deposit Merkle tree and verify Merkle proofs proving inclusion of deposits against the root of the Merkle tree. Under EIP-6110, the responsibility for verifying the inclusion of deposit requests in the deposit request contract

shifts to the execution client and validators aren't required to verify Merkle proofs to process deposit requests. This creates an opportunity to, safely, increase the number of deposit requests that can be processed per block. EIP-6110 deprecates the preset and specifies using the block's gas limit token-strained deposit request operations in blocks. According to analyses from the specification document, the maximum number of deposit requests that can be processed under EIP-6110 is approximately 1,271, given the current gas limit which is a massive increase from the previous limit of 16 deposit operations per block. Faster sync T-I-M-E-S-E-I-P 6110 reduces onboarding friction for new validators by making participation in beacon

chain duties independent of the syncing of historical data on the execution layer. As mentioned previously, block proposers are required to include all pending deposit requests. Attesters also need to concatenate the requests to the deposit request list in order to process blocks and verify the requests for deposit operations included in a proposed block. EIP-6110 removes the need for validators to process historical deposits before proposing blocks on the beacon chain. The consensus layer doesn't require Merkle proof verification for deposit requests, so a validator, once it has successfully synced the beacon state, can start proposing blocks and serving up deposit requests to the rest of the network without having to wait for the

attached execution client to sync the deposit request contract's history. Eliminating requirements to store and distribute deposit requests CONTRACTSNAPSHOTSEIP4881. Deposit Snapshots Interface is a solution to the problem of downloading historical deposit transaction receipts and rebuilding the deposit request contracts Merkle tree from scratch before processing beacon blocks. EIP4881 introduces a mechanism for clients to store and transmit the minimal amount of Merkle tree hashes required to rebuild the root of the depository auto-particular, finalized, block height. This reduces syncing times for new validators and frees up execution

clients to prune parts of the chain's history not relevant to processing blocks and transactions. However, EIP-4881 introduces additional complexity for node operators by forcing the requirements to store and update deposit contract snapshots. This itself can turn out to be a fairly complicated task, and a number of node operators have run into issues with properly syncing the deposit contract snapshot cache, sometimes leading to the creation of invalid blocks. Blocks can be invalid if a proposer is creating invalid Merkle proofs for deposits. Plus, not every client uses EIP-4881. Some are still using JSON-RPC API to rebuild historical states, which is painfully slow and prone to errors. By eliminating the need for proposers to create Merkle proofs for deposits, in protocol deposit

processing, VAE IP 6110 allows full nodes to avoid storing deposit request Merkle tree data. Attesting validators also don't need to keep a local copy of the deposit tree to validate blocks. Finally, newly onboarded consensus nodes only have to reason about importing the execution layer's state and can safely skip on downloading deposit contract event logs during the syncing process. 3. Reduced engineering complexity for consensus clients with the ETH1-ETH2 bridge as the de facto mechanism for processing deposit requests. Consensus clients have to dedicate time to maintaining the following components fetcher. To query the execution client for deposit contract event logs. Deposit contract logs cache to reduce the difficulty of rebuilding the deposit tree. Polling algorithm to implement ETH1 data voting for proposers. Deposit contract

snapshots cache to speed up syncing new nodes. EIP-6110's deprecation of the ETH1-ETH2 bridge and poll removes the burden on client teams to maintain the aforementioned components. Besides saving on valuable engineering hours debugging issues, clients can also reduce the surface area for software bugs by writing less code and reducing complexity in implementations. Are there potential drawbacks to implementing EIP-6110? 1. Breaking the VALIDATORINDEX invariant The beacon chain's validator registry stores a mapping of validator public keys to validator indices. The is different from the index described earlier.

The index is associated with a deposit request and is assigned to each deposit sent to the deposit request contract. Two deposit requests from the same validator will thus have different values in the index field. The is associated with a validator or more accurately the validator's public key and is assigned when the beacon chain processes the deposit request and creates a validator record that saves important information about the validator in the beacon state. The set of information stored per validator record for each validator includes the and indicating if the validator has been slashed

or not, among others. The validator index is assigned to a validator irrespective of the amount of ETH deposited. Deposit requests less than 1 ETH fail by default before reaching the consensus layer. Other deposit requests to the same validator will increase the validator's effective balance and don't create a new validator index. You can see this process in action in the current deposit processing workflow, where we confirm that a validator's pubkey isn't included in the set of public keys awful deposited validators. When processing a deposit, a validator's index remains the same throughout the deposit

lifecycle in the status quo and doesn't change when chain reorganizations occur. As we finalize appending deposits, during the ETH1 data poll, before processing any deposits, a validator is unlikely to have different values for in different branches of the block tree. However, EIP6110 removes the ETH1 follow distance and deprecates the pole. This means pending deposits no longer have the notion of finality at the time validator index is first created. Hence, the same validator can have a different validator index mapped to its pubkey in two competing blocks. This can create issues for clients that rely on the pubkey index cache to perform fast lookups of validator indices

when participating in consensus. The PubKey index cache has many uses, such as confirming a proposer as part of the active validator set when processing a new block. I encourage reading Novichan's PubKey cache analysis for a comprehensive overview of the usage of the PubKey index mapping. However, EIP-6110 breaks the invariant that a single PubKey index cache will cover all lookups of validator indices at every point in the beacon chain's state transitions. Take, for example, the validator index lookup that happens when we want to process a new deposit for a previously deposited validator. Here, we cannot really on a singleton PubKey index cache because it only captures validator

indices from one branch of the block tree. A validator's index can, however, change, making the old validator index redundant, if the block that processed the initial deposit is reorged and replaced by a new block that assigns a different index to the same validator. The solution EIP-6110's authors propose is for client teams to maintain two PubKey index mappings. A. Cache, containing indices of validators whose initial deposits have been finalized and an. Cache containing indices of validators whose initial deposit requests are yet to be finalized. The cache is maintained for different blocks in the block tree so that, irrespective of which block IS finalized first, the client has a mapping of for each validator, which it can use to update

the cache later. An alternative is to have a queue that accumulates deposit requests from unfinalized blocks and require beacon nodes to finalize blocks before processing deposit request operations from the queue. This strategy adds some complexity since each deposit request transaction from the same validator will create a fresh deposit in the queue and carry a different. In comparison, all deposit requests to the same validator are accumulated to the validator's index until the validator is eligible to join the activation queue, removing the need to maintain a separate record for every deposit request to the same validator. 2. Growth in chain data Currently, deposit data supplied by the deposit request contract is stored in historical logs

and doesn't induce additional state growth. EIP-6110 requires validators to include deposit request data in execution layer L blocks, however, which may trigger the fear that execution clients will require more disk space to store blockchain data post-EIP-6110. EIP-6110 has a section to address concerns around chain data growth and downplays the long-term impact of introducing on-chain deposit data. This is based on analysis of the size of each deposit operation, roughly 212 bytes per deposit request, 48 bytes for, 32 bytes for, 20 bytes for, 92 bytes for, and 20 bytes for. Accordingly, the increase in chain data from including deposit request data in execution requests is estimated

to be around 60 mebybytes per year. Here's a relevant quote from the specification greater than at the time of the latest update of this a relevant quote from the specification greater than at the time of the latest update of this document. The total number of greater than submitted deposits is 824,598 which is 164 megabytes of deposit data. Assuming greater than frequency of deposit transactions remains the same, historic chain data greater than complexity induced by this EIP can be estimated as 60 megabytes per year which is greater than negligible in this EIP can be estimated as 60 MB per year which is greater than negligible in comparison to other historical data. It's also important to note that removing the need to store deposit requests will offset some of the state growth from storing

deposit request data on-chain. While EIP-4881 already allows full nodes to prune parts of the execution chain's history, EIP-6110 takes it one step further by totally removing the requirement for validators to run execution nodes in archive mode and preserve archival data. 3. Denial of Service, DOS, ATTACK VECTORSCONSENSUSLAYEREIP6110 increases the number of deposit requests processed per block by removing the hard cap of. The maximum number of deposit request operations per block is now governed solely by the block size limit. In theory, removing the limit on deposit request operations can widen the surface area for denial of service, DOS, attacks on the consensus layer.

For example, a malicious validator can send deposit request transactions with invalid signatures. Consensus nodes must verify each signature before processing a deposit request because the deposit request contract cannot verify BLS 12 to 381 signatures. This will change with EIP-2537 which will be included in the Pectra upgrade and slow down block processing. That said, EIP-6110's authors note that a DOS attack exploiting the high limit for deposit request operations is unsustainable for a simple reason. The deposit request contract only accepts transactions that deposit one ETH or more as a non-T-spam measure. This places a significant cost on DOS attacks if an attacker

would slow down block processing by 1.2 seconds by packing 1,271 deposits with invalid signatures into a block. It needs to spend a 12.71 ETH on deposit transactions. Note that this doesn't account for the cost of gas for including each deposit request transaction in the execution layer block. Execution layer the 1 ETH per deposit request transaction rule protects the consensus layer from DOS attacks after EIP-6110 is activated. But it doesn't protect the execution layer from attackers that spam the deposit request contract with invalid transactions. Does this mean DOS attacks are viable on the execution layer? Not really. As the EIP-6110 specification explains, anyone interacting with the deposit request contract will incur certain fixed costs, e.g. the base fee of 21,000 gas, which should deter potential abuse. Batching deposit request transactions,

which large staking pools already do today, may reduce the cost of interacting with the deposit request contract. For example, writing to warm storage slots IE. Storage slots modified during a transaction's execution is cheaper than writing to cold storage slots IE. Storage slots that haven't been touched during a transaction's execution. This, economies of scale, can be exploited by a savvy attacker and create a dose vector that exploits the higher limit for deposit request transactions on the execution layer. Nevertheless, we can derive some fundamental limits on how cheap deposit request transactions can get and how many deposit request transactions can be packed on a block by evaluating a number of factors like the gas limit cost of gas per byte of MSG

data and call data and the total bytes consumed by a deposit request transactions deposit data. Current estimates from the EIP-6110's security considerations section suggest the lowest cost of a deposit request transaction based on this analysis is enough for security against dose vectors. 4. Impact on block validation and PROCESSINGIP6110 permits execution requests to include up to 1,271 deposit request operations, which may have some impact on the time it takes to validate and process blocks. However, data from early attempts to stress test execution clients by simulating blocks with a high number of deposit requests reveals a moderate impact on block processing and validation. Specifically, the

performance of execution clients like Lodestar and Basu when processing blocks with greater than 700 deposits doesn't deviate too sharply from established baselines as discussed in a section of the deposit reform prototype document authored by the EIP-6110 team. Below is a relevant quote from the document greater than compared with the current mainnet profiling. Some overhead is associated with greater than the method noticed within block body validation. However, this increase isn't greater than alarming. Block body validation is estimated to take about two to three times longer greater than with EIP-6110 deposit requests than on the current mainnet, yet it's still a greater than minor part of the overall block processing

in Basu. Consensus clients may be required to handle higher deposit requests processing workloads once EIP-6110 is active since the constant, though. Particularly, the authors of EIP-6110 suggest client developers should aim to support up to 1,900 deposit requests per block for robustness. Conclusion, EIP-6110 is part of the overall drive to reduce tech debt accumulated from the early years of the beacon chain's design and pave the way for a robust, secure, and simple proof-of-state consensus on Ethereum. The proposal introduces in-protocol processing of deposit requests and deprecates the ETH1 data pool and ETH1-ETH2 bridge, which promises to improve the deposit request UX for solo stakers and professional node operators alike. In addition to simplifying

things for teams maintaining consensus clients. More importantly, EIP-6110 increases the safety threshold of the deposit request processing mechanism and improves the beacon chain's economic security. Validator deposit requests are now secured by the core protocol and derive liveness and safety properties from the beacon chain's finality gadget, which resolves long-standing debates around the weakness of the ETH1-ETH2 bridge. As a wise man, yours truly, once said, the best bridge is no bridge at all. If you've enjoyed reading this article, consider sharing it with someone who may find it informative. We will be back with a deep dive on EIP-7503, Zero Knowledge Wormholes, an attempt to bring Xenonymous Transactions' Tothirium's base layer and fix the weaknesses of Tornado Cash and other

application layer approaches to financial privacy. Tipa version of this article was originally published here. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.