# R&D workshop. Eth2 part of the Merge --- ## Affected parts _Intro_ _Say about allowing to move execution to a shard as the main design consideration_ - Data structures - Validator - State transition --- ## Data structures _A bit of elaboration on each. Should be straightforward_ - ExecutableData - BeaconBlockBody - Briefly say that state is affected (eth1_data_votes are removed) but more on that later (in the deposit processing section) - Mention that state has no new fields as the need of this is not yet identified, but it could be changed in the future, for convenience (e.g. finalized_eth1_hash could be added but we don't want to bring execution bits to the consensus, only one direction as execution may migrate to a shard) - Eth1Data.block_hash _Questions?_ --- ## Validator _Does not cover deposits and Eth1Data (it comes later)_ - How to obtain ExecutableData - Briefly mention call to eth1-engine _Discussion_ --- ## State transition - Explain process_executable_data - Briefly mention call to eth1-engine - Mention parallel processing possibility - Mention mainnet block processing time and its potential impact _Discussion_ --- ## Deposit processing - Current approach (with Eth1Data verified in the fork choice) - votes are removed from state - Ideal approach (with the proof linked to eth1 state root) and why it's not taken yet _Discussion_ _If someone asks about options that requires more tight beacon chain and execution interaction give the details, otherwise, not._ --- ## Eth1-Eth2 communication _The last slide_ - A list of methods on the screen that represents the communication protocol - Briefly speak about `eth2_finalizeBlock` (recently added to the communication protocol and the spec) _Turn to Guillaume_ ---
{"metaMigratedAt":"2023-06-15T19:09:01.610Z","metaMigratedFrom":"Content","title":"R&D workshop. Eth2 part of the Merge","breaks":true,"contributors":"[{\"id\":\"b18958fc-b669-4081-a016-685dbfabd5f8\",\"add\":2070,\"del\":291}]"}
    439 views