# Merge implementers call - 3 Jun
Quick notes by @protolambda.
## Impl updates
No active testnets, current focus after rayonism is on Altair/London hardforks
Geth, PR by Gary, tested during Rayonism (state sync discussion later): https://github.com/ethereum/go-ethereum/pull/22827
## Research updates
Merge transition process with computed transition total difficulty:
- See PR https://github.com/ethereum/eth2.0-specs/pull/2462
1. Based on eth1-data that is voted into the BeaconState [for current deposit processing],
estimate the total difficulty for the fork-transition
2. Set total difficulty based on estimate off-chain
- vitalik, questions:
1. When does the formula run?
- Put it into client code; it would be 3 weeks old at least. More risk
- Put it in-protocol, smaller delay. Difficulty could still be pushed down or up, vulnerable to attacks with surprise hashrate changes.
- Variant: the minimum of the above two
2. What will the formula be?
Fallback idea: If the merge is delayed due to a drop in hashrate and a minimum total-difficulty target,
clients can make it configurable, to tune it if necessary.
Micah: the command-line param idea would create a hurdle for non-cli users.
Jacek: if this is used only in emergency, users may not know how to use it if they never used it before.
Mikhail: review PR, continue conversation there.
## Consensus API
Mikhail: duplex communication channel is almost a requirement. Maybe some (web)socket, to be looked into later.
We may introduce a new type of message into the protocol that needs this.
Micah: trust on both ends?
Mikhail: it would be more complicated than what we have now, needs more thought. External service providers have different requirements around trust.
## ExecutionPayloadHeader or full ExecutionPayload in the state?
- State size concern: transactions are small relative to the validator registry
- State change concern: blocks are very frequent, swapping the payload in the state every slot can cause more duplication
- Multi-block processing: tracking latest transactions in the state could affect future ability to change transaction processing, potentially transaction masking against MEV.
## Difficulty opcode:
- Against all security advisory, `DIFFICULTY` is being used for randomness, same for the block-hash opcode.
- Default option: set it to some constant after it becomes irrelevant
- We want to minimize changes to the EVM during the merge
- We have more proper randomness from RANDAO, and could expose it via the `DIFFICULTY` opcode (and rename the opcode in docs, same byte-value)
- Breaking and then unbreaking in a later hardfork after the Merge is probably worse.
- Vitalik: pushing a constant could be abused as cheap-gas option to get 1 or 0 on the stack. Might be a good thing, but can break (different before merge, and maybe after another fork).
- Micah: options:
- Difficulty opcode exposes RANDAO
- Problem: difficulty value is different length, 64 bits in some places, block header possibly.
Returning 8 bytes of randao mix would not help actual randao uses.
Micah: the length difference in clients could be in the boat of technically unreachable consensus issue.
The opcode does 256 bits, but externally it may have different lengths.
- Difficulty opcode pushes 1 on the stack
- Mikhail: if anyone has comments, reach out on github or R&D discord
- TODO: Look into other EVM chains usage of difficulty opcode.
- Adrian S: difficulty opcode is hardcoded in clique.
- Block hash opcode will stay the same (hash of execution block)
- Vitalik: eventually retire RLP, that would break blockhash. Not a problem for initial merge.
- Mikhail: if we replace difficulty with randao, it will be part of the eth1 block header, and thus block hash.