# 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}]"}