# Merge call
Quick call notes, 1 July 2021
## Implementation updates
### Transition prototype
Teku prototype progress of the Merge transition: https://github.com/txrx-research/teku/pull/5
## Research updates
### New API
Food for thought, API to change. Listed known problems:
JSON-RPC from rayonism is sufficient for a prototype, not quite for production.
- Micah: Unidirectional vs Bidirectional, undecided:
- bidirectional is considered "highly desirable" (Mikhail)
- unidirectional was used in Rayonism
- Consensus block validity: Set-head and block-insertion have different meanings, validity must not rely on set-head only
- Independent message flow: Remove assumption of sequential messages in API
- HTTP overhead and HTTP asynchronous communication problem
- Failure recoverability
- Depends on bidirectional communication
- Danny: state-sync has requirements too
- HTTP 1: has keep-alive header, widely supported, but not a good candidate for bidirectional comms
- HTTP 2: can be persistent, but support may not be good
- Websockets: supports bi-directional, easy to use/support everywhere
Mikhail: encoding for another discussion, also to consider with new API
Remaining discussion: Payload size, compression, encoding, etc. relevant too.
Jacek: against complexity, too many connections / protocols (libp2p TCP, discv4 UDP, discv5 UDP, devp2p TCP, eth2 api JSON-REST, eth1 JSON-RPC http/ws, etc.).
Micah: Execution and Consensus clients will likely have separate API interfaces, even in far future, since they innovate/extend independently with non-standard API.
- State sync for Merge
- Consensus API (both exec/consensus teams to work on this)
- Testnets in later part of this quarter
- Include London in execution client
- Include Altair in consensus client
- Testing! Unified eth1/eth2 testing especially
- Merge call / Consensus/Execution calls may reorganize
Danny/Mikhail: prepared more detailed list of things to look into for Merge, will post to PM repo