随着以太坊 Merge 时间节点将至，今天我们将探讨以太坊合并之后会面临哪些监管问题和应用层问题。
2022 年 8 月 16 日，以太坊联合创始人 Vitalik Buterin（V 神）在推特上参与讨论「若监管通过某些协议（如 Lido、Coinbase 等）的验证者者对以太坊进行协议级别的审查，以太坊社区将如何反应」这一话题时表示，会将这种审查视为对以太坊的攻击，并选择通过更广泛共识（social consensus）将这些验证者的质押权益进行销毁。
引起这个讨论的导火索在于：近期，美国财政部海外资产控制办公室（OFAC） 将与 Tornado Cash 有关的以太坊地址添加到制裁实体的名单中。但是目前对其的制裁都是处于中心化层面的操作，对于涉及到去中心化的智能合约部分，尚无法进行技术制裁。
这表明如果美国要想要彻底制裁 Tornado cash ，就必须要控制底层的以太坊链。那么就引出一个问题，假如美国政府对以太坊进行监管，会面临什么？
如果美国政府要对以太坊进行监管，最大的可能是要求大型 PoS 质押服务商对以太坊进行协议级别的交易审查。这并不是验证者「作恶」，而是验证者对链上地址的「针对性制裁」。
简单来说，就是监控被制裁地址发出的所有请求，并将所有包含被制裁地址事务的区块进行拒绝出块即可，当一个区块无法通过 66% 以上权益验证投票通过时，该区块的所有事务请求将会进行回滚，这也就意味着被制裁的地址将无法进行任何操作，并且验证者不会面临任何惩罚。
截至目前，以太坊全网质押的以太币数量大约为 1300 多万 ETH，而通过 Lido 质押的以太币数量已经占了约 30.9%，Coinbase 占了约 14.7%，Kraken 占了约 8.5%。
如果美国政府要求 Lido、Coinabse、Kraken 为代表的大型节点验证者（服务商）对以太坊进行协议级别的交易审查，作为具有美国法律实体的质押服务商很难拒绝类似要求。
图源自 Dune Analytics
针对可能出现的上述情况，在以太坊社区在 Twitter 上发起了一项投票讨论，如果 OFAC 通过验证节点对以太坊实施监管该怎么做。V 神支持将上述情况视为对以太坊的攻击，并通过更广泛共识将这些节点的质押权益进行销毁。
下面，我们再来聊一聊应用层的问题。
我们在上一篇曾提到：按照计划，以太坊的 Merge 以「最小破坏」原则进行，使原来运行的应用客户端可以无感地切换到 PoS。也就是说，尽管是「最小破坏」，但在这个过程中，有一些小的变化仍然值得我们注意。本节就主要从应用开发的角度介绍在合并后，我们应该关注的方面。
合并后，当前的 Eth1 和 Eth2 客户端将成为以太坊的执行层和共识层（或引擎）。这意味着 Eth1 或信标链客户端的节点运营商将需要运行堆栈的「另一半」以获得完全验证的节点。下图显示了合并后完整的以太坊客户端架构。
客户端架构
合并后客户端架构. 图源自 Danny Ryan
区块结构
当合并发生时，信标节点将监视当前的 PoW 链并等待它达到预定义的 total difficulty 阈值，该值被称为 TERMINAL_TOTAL_DIFFICULTY。即一旦 PoW 链产生了一个带有 total difficulty >= TERMINAL_TOTAL_DIFFICULTY 的块，它将被视为链上最后的一个 PoW 块。
随后，PoW 块包含的数据将成为信标链块的数据组成部分，而信标链则可以被视作为以太坊新的 PoS 共识层，取代之前的 PoW 共识层。
同时在进行共识验证时，信标节点将与其执行引擎（升级前的以太坊客户端）通信，并要求它生成或验证 ExecutionPayloads。ExecutionPayloads 包含了父哈希、状态根、基本费用和要执行的交易列表等信息。
一旦这些数据被生成或验证，信标节点将与 p2p 网络上的其他节点共享它们。
而对于终端用户和应用程序开发人员来说，这些原来 PoW 链上的 ExecutionPayloads 仍然是他们与以太坊进行直接交互的位置，事务仍将由执行层客户端处理，这使得他们可以无感切换到 PoS 链。下图显示了这种关系：
图源自 Danny Ryan
执行引擎
合并之后，执行引擎主要负责状态管理，区块创建和验证功能，而不再包含与共识相关的任何操作。因此，执行引擎被进行了部分修改，这些修改在 EIP-3675 中进行了描述，主要包含以下三点：
首先，修改了区块的部分数据字段。将原有区块中几个仅与 PoW 相关的字段设置为 0（或其数据结构的等效项），具体包括与挖矿相关（difficulty, mixHash, nonce）、 叔块奖励相关（ommers, ommersHash）。此外，extraData 的长度在主网上也将被限制为 32 字节。
其次，由于只有合并后的信标链才能进行出块，因此执行引擎将停止处理区块和叔块奖励。但交易手续费仍由其进行处理，即当执行引擎创建一个 ExecutionPayload 时，需确保所有交易的发起者至少能够支付当前 baseFeePerGas 的费用，并且将剩余的交易手续费发送到 feeReceipient。注意，feeReceipient 指的是升级前的以太坊地址，而不是信标链验证者地址。
最后，一旦 PoS 取代 PoW，执行引擎将不再负责广播区块，但仍会通过 p2p 网络进行交易的广播。具体过程为，首先用户将交易通过本地的 RPC 请求发送到共识客户端，在那里它们将被打包到信标块中。然后，共识客户端将在他们的 p2p 网络中广播信标块。
下图表明了以太坊合并时的过程：首先停止 PoW 出块，其次信标链块在合并后开始持有 ExecutionPayload。
图源自 Danny Ryan
BLOCKHASH DIFFICULTY 操作码更改
合并后，BLOCKHASH 操作码仍可使用，但由于它不再通过工作量证明生成对应的 Hash 值，所以此操作码提供的伪随机性将被大大减弱。
与此同时， DIFFICULTY 操作码 (0x44) 将会更名为 RANDOM 并返回由信标链提供的随机数值。因此，该值将替代 BLOCKHASH 成为应用程序开发人员可使用的更好随机源（尽管仍然存在偏差）。
RANDOM 值将存储在 ExecutionPayload 中原有 mixHash 的位置，该值与工作量证明计算相关。升级后该值被重命名为 random。
下图解释了合并前后 DIFFICULTY 和 RANDOM 操作码的工作原理：
图源自 Danny Ryan
合并前，我们看到 0x44 操作码返回区块头里的 difficulty 字段。合并后，负责生成随机数的 RANDOM 操作码则指向原有 mixHash 字段，该字段被重名为 random。
出块时间
合并将影响以太坊的平均区块时间。目前在 PoW 下，平均每约 13 秒产出一个区块，但实际区块间隔时间会由于网络拥堵的情况，而存在相当大的差异。但在 PoS 下，区块间隔为固定的 12 秒，除非发生某些极端情况，如：验证者离线或未及时提交区块而错过了某个插槽。
综上，升级后网络的平均出块时间将减少近 1 秒，这提高了交易的速率。注意：如果智能合约中存在与特定平均出块时间相关的逻辑，则在计算时开发人员需要考虑到这一点。
参考文献：
