# Merge implementers call - 3 Jun Quick notes by @protolambda. Agenda: https://github.com/ethereum/pm/issues/331 ## 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 - Options: 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.