# In-Protocol deposits PoC scope ## Specification * Execution Layer [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) * Conensus Layer [#3177](https://github.com/ethereum/consensus-specs/pull/3177) * Engine API [eip6110.md](https://github.com/ethereum/execution-apis/blob/main/src/engine/experimental/eip6110.md) ## Specification work * [x] Explore design space without `pending_queue` in the beacon state, [#08c728](https://github.com/ethereum/consensus-specs/pull/3177/commits/08c7287387d456b96bfe952ab4952c6be1af1612), [#23c10c](https://github.com/ethereum/consensus-specs/pull/3177/commits/23c10cfd7fc7c72127b2a7bc2f7e3561c978b511). * [x] Rebase spec with Deneb/Cancun * [ ] Confirm that a significant increase of a number of top ups per epoch is fine wrt WS period computation. * [ ] Confirm that CL client devs are fine with taking the `(pubkey, index)` cache complexity in favour of complexity related to `pending_queue`. * [x] Provide evaluation of a number of deposits per 30M gas block that advanced attacker can induce by making multiple deposits in one transaction. * [x] Reasses signature verification complexity after re-evaluating a cap on deposit number per block. * [x] Reshape specification documents: - use EIP as a high level specification with links to low level spec in `consensus-specs/specs/features` and `execution-specs/`. * [x] Provide consensus tests * [x] Figure out execution tests - Unit tests in Besu - [Bonus] Hive ## Execution layer * [x] Update block structure, [#5055](https://github.com/hyperledger/besu/pull/5055) * [x] Add new block validity rules, [#5295](https://github.com/hyperledger/besu/pull/5295) * [x] Add deposit parsing to payload build process, [#5295](https://github.com/hyperledger/besu/pull/5295) * [x] Expose new Engine API methods, [#5055](https://github.com/hyperledger/besu/pull/5055) * [x] Implement basic unit tests - Deposit encoder/decoder, [#5055](https://github.com/hyperledger/besu/pull/5055) - Block validity checks, [#5295](https://github.com/hyperledger/besu/pull/5295) - Payload building checks, [#5295](https://github.com/hyperledger/besu/pull/5295) ## Consensus layer * [x] Update payload, beacon block and beacon state structures, [#eip6110](https://github.com/kevinbogner/lighthouse/pull/3) - Do not add `pending_deposits` to the beacon state * [x] Add new deposit processing machinery * [x] Update block proposing with the new Eth1 deposits limitation (Eth1Data poll must not include deposits older or equal to the first in-protocol deposit) * [x] Update Engine API client * [x] Adopt new spec tests - Dependency: consensus spec tests * [x] Add a flag to disable `Eth1Data` poll - Disabled in the code * [ ] Bonus: support re-org handling, i.e. invalidation of `(pubkey, index)` cache entries affected by re-org ## Devnets: EL + CL + DevOps * [x] Local machine devnet - Preset = minimal, Genesis = Capella/Shanghai - Steps - Setup network with predefined validator set - Constantly submit deposits to the network (2-3 per block): top ups mixed with new validators - Run through the transition period - Turn off `Eth1Data` voting after the transition - Measurement of success - No deposits are lost during transition - Turning off `Eth1Data` poll doesn't affect deposit processing * [x] Private devnet - Preset = mainnet, Genesis = Capella/Shanghai - Steps - Setup network with predefined validator set - Constantly submit deposits to the network (2-3 per block): top ups mixed with new validators - Run through the transition period, two cases: 1. `Eth1Data` poll goes beyond `state.deposit_receipts_start_index` and in-protocol deposit is submitted after all deposits from the last voting period are included onchain. 1. In-protocol deposit is submitted alongside with deposits from the last voring period. - Gradually turn off `Eth1Data` voting after the transition - Sync up a fresh node - Block sync - State sync - Measurement of success - No deposits are lost during transition - Turning off `Eth1Data` poll doesn't affect deposit processing - Fresh node catches up with the head and imports new blocks * [x] Stress testing - Preset = mainnet, Genesis = Capella/Shanghai - Steps - Setup network with predefined validator set - Constantly submit deposits to fullfil blocks up to 30M gas with deposits: new validators only + use tricks to submit multiple deposits per one transaction to reduce the cost of a deposit - Run through the transition period - Measurements - Block processing time - Block size in bytes * [ ] Bonus: re-org testing - Preset = mainnet, Genesis = Capella/Shanghai - Steps - Setup network with predefined validator set - Constantly submit deposits to the network (2-3 per block): new validators followed by topups for each validator - Run through the transition period - Induce re-orgs with deliberate exclusion of a few deposit transactions creating new validators - Measurement of success - Top ups are processed correctly (i.e. `(pubkey, index)` cache entries were invaldiated correctly)
Last changed by  
 
Mikhail Kalinin
475

Read more

EIP-7549: On chain aggregation

This proposal extends the EIP-7549 change by optimising.

2/23/2024
Deprecate exchangeTransitionConfiguration

This document describes a procedure of deprecating engine_exchangeTransitionConfiguration method and tracks the progress on it.

11/12/2023
Deposit reform prototype

This document is a summary of EIP-6110 proof of concept project.

7/31/2023
In-Protocol deposits PoC sync calls

Call 10 Meeting Date/Time: Thursday 2023/6/29 at 15:30 UTC Meeting Duration: 45 minutes Testing :heavy_check_mark: Stage 1: Set sleep time to 1 second (about 12 deposits in 12 seconds).Sleep Time: 1 second Number of Deposits per Slot: ~12 Duration of the Test: At least 1 minute to observe sustained behavior. Total Number of Deposit Data Entries Needed: 12 * 5 + 5 = 65 (for 1 minute of testing with 5 additional deposits)

6/29/2023
Read more from Mikhail Kalinin
Published on HackMD