mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

“披荆斩棘”合并之后 以太坊会面临哪些监管问题和应用层问题?

Collect
Share

点击阅读: 深度 | 以太坊“大合并”之后 能治好Web3的精神内耗吗?

在我们推出 “以太坊大合并”系列 的第一篇文章里,主要为大家介绍了以太坊升级的原因、路线和当前进展。

随着以太坊 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 秒,这提高了交易的速率。注意:如果智能合约中存在与特定平均出块时间相关的逻辑,则在计算时开发人员需要考虑到这一点。

好了,今天的分享就结束了, 下一篇,我们探讨以太坊合并之后将面临的安全问题,欢迎持续关注我们的分享

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content