OpenBuild Ethereum Co-Learn #02

• The  Dencun (Cancun-Deneb) upgrade: EIP-4844 but not only EIP-4844
• Deneb - Consensus Layer upgrade
• Cancun - Execution Layer upgrade

EIP-7569: Hardfork Meta - Dencun（🔗链接：https://eips.ethereum.org/EIPS/eip-7569）

Dencun 升级总览

Dencun 升级包含 9 个 EIP，大致可以分为三类：

• 执行层的优化：
• EIP-1153: 为 EVM 的执行引入了第三种数据存储，临时存储 (Transient storage)。临时存储在交易执行中建立，交易执行结束之后释放。
• EIP-5656: 为 EVM 的执行引入了内存 copy opcode MCOPY (Memory copy)。
• EIP-4788: 将 Beacon block root 引入执行层，并将这些 roots 存储在一个合约中，引入一个 opcode 来读取数据。
• EIP-6780: 让 SELFDESTRUCT 只能在同一个（合约创建）交易中执行。为了完全丢弃 SELFDESTRUCT 做准备。
• 共识层的优化：
• EIP-7044: 让 validator 的 pre-signed 申请退出，在所有的时候都有效。
• EIP-7045: 增加 beacon block 里有效 attestation inclusion 范围。
• EIP-7514: 引入了 Max Epoch Churn Limit 限制 validator 增加的速度。
• Sharding:
• EIP-4844: 引入了一个新的 Shard Blob Transactions，这个类型的交易可以携带 blob 数据块，即所谓的 “blob-carrying transactions”，Blob 数据块存储在共识层，且不用在 EVM 中执行。
• EIP-7516: 引入了 BLOBBASEFEE opcode，让执行层更好的预估 gas cost。

EIP-1153

• 这个 EIP 给 EVM 引入了 Transient storage 临时存储，以及两个 Opcode:  TLOAD 和 TSTORE ，对该存储空间进行操作
• TLOAD 从栈顶弹出 32-byte 数据，将其视为内存地址，并以该地址作为起始，读取 32-byte 数据压入栈顶。
• TSTORE 从栈顶弹出两个 32-byte 数据，将第一个视为内存地址，第二个视为数据。 TSTORE 会将这个数据存储在对应的地址中。
• 为什么要引入呢？一个交易调用多个函数的时候，EVM 会在执行过程中建立不同的 frame，frame 之间互不共享数据，无法直接传递参数。
• Permanent Storage：SSTORE 和 SLOAD 贵！
• Memory：frame 内的临时参数，在函数执行结束之后就会被清空，无法传递给下一个函数。
• Transient Storage (EIP-1153)：可以视为 lifecycle 为整个 transaction 的 memory。

• 它最大的好处就是，便宜。

EIP-5656

• 引入了 MCOPY (Memory Copy) 操作，允许 EVM 直接 copy 内存中的数据。
• 在 MCOPY 之前的内存中数据 copy 操作，是非常贵的，例如，想要 copy 256 bytes 的数据：
• 在 EIP-2929 之前，通过调用 CALL 过程中产生的输入输出偏移来实现 memory copy，这一操作至少需要 757 gas。
• EIP-2929 之后，降低交易中重复访问地址数据的开销，减少到至少需要 157 gas。
• 使用 MLOAD 和 MSTORE 对内存数据先进行 offset，再复制的操作：<offset> MLOAD <offset> MSTORE ，至少需要 96 gas。
• 使用 MCOPY ，只需要指定复制 src 的 address，以及复制内容的 size，目标 address 即可，只需花费 27 gas 。

EIP-6780

• SELFDESTRUCT 一直是 EVM 中的老大难问题，因为大家对它的使用已经偏离了设计的初衷。
• SELFDESTRUCT 是唯一可以从 blockchain state 中删掉代码的工具（不是在 historical data 中删除），但是被开发者滥用了（合约升级，合约的紧急刹车）
• EVM 改进的最终目标是要去掉这个东西（EIP-6049），但是并不是一步到位的。这个 EIP 就是删掉它的第一步。
• EIP-6780 做的事情是限制 SELFDESTRUCT 生效的范围：只能在合约创建同一个交易中生效。
• 如果在同一个交易中调用 SELFDESTRUCT ：
• 删除所有的合约创建过程中生成的 data
• 将该合约的 balance 打给 target
• 如果不在同一个交易中调用 SELFDESTRUCT ：
• 不会删除任何 data
• 但同样会将合约的 balance 打给 target
• 在升级 Verkle Tree 之后（stateless client），节点只需要维护部分 state，所以不一定能够找到所有与该合约相关的 state 中的数据，更别说删除它了。
• 注意：合约的摧毁不再返回任何 refund (EIP-3529)，调用 SELFDESTRUCT 的交易所附带的 value 将会被 burnt 掉。

EIP-4788

• 现在的共识层与执行层之间的通信（Engine API），共识层从执行层请求的数据，要远多于执行层从共识层请求的数据。例如，共识层监听 deposit event，请求质押合约的数据等。
• EIP-4788 将共识层的 header root 放入执行层头部，是执行层最小化信任（trust-minimized）的方式读取共识层数据的入口。
• EIP-4788 给 execution block header 里塞了一个数据：parentbeaconblock_root

• 以后执行层在验证 block 的时候，就需要去验证共识层所绑定的 parentbeaconblock_root 是否正确了。
• 所以，该 EIP 也引入了一个 Beacon roots contract 的预编译合约，用来存储一定数量的 beacon block root。这个合约只有两个操作： get 和 set。
• 大概存储 1 天左右的 beacon block root，后来的 block root 会覆盖之前的

EIP-7044

• 让 signed voluntary exit 永远有效。
• 一个 staker 有两个私钥：在执行层，ETH Staker 有一个 withdraw key，该 staker 质押所得到的 validator 有一个 signing key。withdraw key 只在质押和提款的时候需要，所以，它的使用频率很低，signing key 对于 validator 来说，发送 attestation，propose block，随时都要用到。

• 这两个 key 一般情况下，是由同一个人掌握的（homestaker），但是，很多 staker 把自己的 validator 委托给第三方。然而，一个 validator 的 voluntary exit，需要 validator 使用 signing key 在共识层主动提出的，这就导致委托给第三方的 staker，无法主动退出。
• 所以，就有了 signed voluntary exit 。即，在委托的时候，签署一个合约，让 staker 可以通过 withdraw key 来主动提出 validator 的 voluntary exit。
• 它为什么只在两个 upgrade 里有效？
• 防止重复退出（风险依然存在）

EIP-7045

• 增加 max attestation inclusion slot。
• 目前，对一个 slot 来说，它所能接收的 attestation，只能延伸至 32 个 slot 之后，即， attestation.slot + SLOTS_PER_EPOCH 。在此之后，即便有收到 attestation，也是不算数的。
• EIP-7045 将这一范围扩大到 N+1 epoch 里， N 是当前 epoch
• 对于 checkpoint 来说，它有 64 个 slot 的时间来接收 attestation 了。对于 LMD-GHOST 算法来说，它可以计算更多的 attestation 了，增加了共识算法的稳定性。
• 它对于 block confirmation time ( 以 finality 为准 ) 没什么影响。该 EIP 本质上还是增强现有共识算法的稳定性。而以太坊的共识算法，最终会转向 Single slot finality 的，到时候这些 EIP 全都用不上。

EIP-7514

• 限制了  MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT = 8
• 以太坊的 churn limit 限制的是每个 epoch 可以加入 或者 退出 的 validator 的数量，该 EIP 主要限制的是 加入 validator 的数量。

EIP-4844

增加一种新的交易类型，这种交易可以附带额外的存储空间，Blobs

• 一个 Blob 是 128 KB 的额外存储空间
• 一个交易最多包含 2 个 Blob，即 256 KB 额外空间
• 一个 Block 内有一个目标存储数量（target），即 1MB，当包含的 Blob 数量大于 8 个的时候，blob 所消耗的 gas 就会成倍增加；最多包含 16 个 Blob，即 2MiB。
• Blob 以 KZG Commitment Hash 作为数据验证的 hash 值，作用和 Merkle tree 类似。
• 一个 blob transaction 头部有两个新的数据
• max_fee_per_blob_gas : 用户愿意为这个 blob 付出多少 gas。这也是一个拍卖的机制。这里跟 gas 的 base fee 类似，也有一个 blobbasefee。
• blob_versioned_hashes : 交易所附带 blob 的 KZG commitment list。
• 节点同步链上的 Blob Transaction 后，Blob 会在一段时间（4096 个 epoch，大概 18 天）后删除。

• 为以太坊提供了较大的存储空间（18 天，48 GB）
• 相当于区块链上的缓存，blob 数据便宜的原因是，它不在 EVM 里执行，节点为其付出的 cost 是有限的。

EIP-7516

• 增加了 BLOBBASEFEE opcode，执行层用户可以获得当前 block 的 blob base fee。
• rollups 可以更方便的计算 blob gas fee。

作者：陈玄