Opcode changes during the eth1/eth2 merge

Background

Given that core consensus is changing during the eth1/eth2 merge, it's valuable to understand which eth1 opcodes might change in behavior.

This document covers all of the opcodes that will change along with thoughts about how they should change given contracts running on eth1.

DIFFICULTY

DIFFICULTY is meaningless after the merge as such a notion doesn't exist in proof of stake.

Fortunately, there aren't public contracts that utilize DIFFICULTY meaningfully (i.e. see this github search). It's largely used as a seed for randomness in old lottery-style contracts.

To keep these contracts functional, we can re-name opcode 0x44 from DIFFICULTY to RANDOM and use the randao seed of a block to generate its value. This would need to be passed to the eth1-engine via RPC.

COINBASE/NUMBER/TIMESTAMP/BLOCKHASH

Each of these 3 will be handled locally within the eth1-engine:

COINBASE will be configured during startup (as the block producer address)
TIMESTAMP will be system time when the eth1-evm is processing the block
NUMBER will be the continuation of eth1 block number (i.e. max_pow_block_num + slot)
BLOCKHASH will be available within the eth1-engine during construction

So there's no change in behavior to worry about.

Two nuances to be mindful of:

whether or not to include empty slots in the total block number
the fact that BLOCKHASH is often used as a source of randomness in eth1 contracts and is much easier to grind in eth2

GASLIMIT

GASLIMIT will now be decided on by validators or will be the gas limit defined in EIP1559 (initially 2 * gas_target) if that's implemented in time. This will need to be passed to the eth1-engine via RPC.

Alex Stokes

2021/01/20 01:22:52

(i.e. max_pow_block_num + slot)

i'd suggest we remove the `FORK_SLOT` from the final number so there is no discontinuity in the block numbers: number := max_pow_block_num + current_slot - merge_fork_slot (Edited)

2021/01/20 01:40:23

whether or not to include *empty* slots in the total block number

i'd vote to _exclude_ empty slots. the rationale being that today's user space has contiguous block numbers so if there are any assumptions in dapps out there, we can seamless maintain that by only increasing the block number per eth1 block. if there is a skipped beacon/shard block then it does not count towards increasing the eth1 block number. see my comment above about adjusting the block number as well so that it is continuous w/ what will be the block number at the merge fork (Edited)

2021/01/20 01:45:00

the fact that `BLOCKHASH` is often used as a source of randomness in eth1 contracts and is much easier to grind in eth2

i’d say to just bite the bullet on this one. `BLOCKHASH` was already not a great source of randomness from a security perspective so we aren’t going from “secure” to “insecure”, just from “insecure” to even more “insecure” and the implementation to provide 256 beacon block roots as the recent block hashes is very straightforward otherwise we will need to strengthen the block hashes in some way, which doesn’t seem worth imo (Edited)

2021/01/20 01:46:15

the other option here is to compute the block hash like we would today from the data in each beacon block and provide this as the block hash... it is a bit more overhead for clients to compute but essentially keeps the exact same semantics (other than fields we are effectively deprecating outside the PoW context) (Edited)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.