并行 EVM 的争论:Monad 和 MegaETH 探讨全节点定义

okex欧易平台Leave a Comment on 并行 EVM 的争论:Monad 和 MegaETH 探讨全节点定义

并行 EVM 的争论:Monad 和 MegaETH 探讨全节点定义

作者:0xNatalie 来源:ChainFeeds

在最新一期的 Bankless 播客中,Monad 创始人 Keone Hon 和 MegaETH 联合创始人 Lei Yang 探讨了 Monad 和 MegaETH 的架构以及它们将如何提升以太坊的性能。此次播客围绕以太坊虚拟机的未来展开,回答了一系列关键问题,包括 Monad 和 MegaETH 速度、去中心化程度和抗审查能力比较等。

但在节目后, Monad 创始人意犹未尽,继续在 X 上向 MegaETH 提出针对「全节点」定义的问题,最后还引来 Vitalik 参与讨论。

Monad 是一个通过并行执行技术和独特共识机制,实现每秒超过 10,000 笔交易吞吐量的 Layer 1 。

MegaETH 是一个利用并行执行技术实现毫秒级响应时间的 Layer 2,目标是每秒处理超过 100,000 次以太坊交易。

争议的核心:全节点是否应该执行所有交易

在播客中,Lei Yang 提到全节点在 MegaETH 中是指那些保持和更新最新区块链状态的节点,而不是执行和验证所有交易的节点。针对这一点,Keone Hon 在推特上发文质疑 MegaETH 对「全节点」的定义,因为传统意义上的全节点是指能够独立执行并验证所有交易的节点。而 MegaETH 提出的全节点只是从一个中心化的定序器接收状态更新,并不对交易进行独立验证。Keone 担心这种节点在处理真实世界中的大额交易时,可能无法提供足够的安全性。

如果全节点只是接收状态更新而不参与交易的实际执行和验证,这意味着节点必须完全信任中心化的定序器提供的状态。如果定序器出错、受到攻击或者故意作恶,节点可能无法及时发现问题。这在处理大额交易时尤其重要,因为这些交易涉及的金额巨大,任何错误都可能造成严重的经济损失。

Keone 提出了一个实际应用场景:假设一个交易所集成了 MegaETH 并运行这种全节点,那么交易所该如何确定用户的存款交易已经真正被确认?应该等待多长时间才能将款项存入用户账户?交易所是否需要等待长达 7 天的欺诈证明窗口,才能确保交易不会被回滚,从而保证存款的安全性?

Vitalik 的观点:重点在于交易确认的保障

以太坊创始人 Vitalik Buterin 也参与了这场讨论。他认为,重点不在于全节点是否执行所有交易,而在于用户是否能够获得足够的交易确认保障。Vitalik 认为,对于 L2 用户来说,最重要的是确认他们的交易是否被接受,而不是每个节点是否执行了所有交易。只要有适当的机制来保证这一点,用户不一定需要自己运行执行所有交易的全节点。

Vitalik 提到有两种交易确认机制:

  1. 绑定的定序器预确认(Bonded Sequencer Preconfirmation):这种机制下,定序器在处理交易时被绑定了一定数量的代币(如 ETH)。如果定序器作恶或未能正确处理交易,用户可以得到赔偿或补偿。这种机制提供了即时确认的保障,用户无需等待欺诈证明窗口即可获得交易的安全性保障。

  2. L1 确认:在 L2 的交易最终可以通过 L1(如以太坊)来确认。如果 L2 上的交易有问题,L1 可以回滚交易并纠正错误。即使在 L2 上存在风险,用户依然可以依赖 L1 的最终确认来获得安全保障。

Vitalik 还提到,欺诈证明窗口的长度可以根据用户的需求进行调整。例如,交易所可以根据交易金额的大小选择不同的欺诈证明窗口期。对于小额交易,可能只需较短的窗口期;对于大额交易,则可以选择较长的窗口期。此外,随着零知识证明(ZK)技术的发展,未来欺诈证明窗口的需求将大幅减少,甚至可能不再需要,从而在不牺牲安全性的前提下提供更快速的交易确认。

不过,Keone 觉得 MegaETH 在初期并不会使用 ZK 技术,ZK 技术虽然有着巨大的潜力,但目前它在性能方面仍然存在一定的限制。生成零知识证明的计算过程非常复杂且耗时,尤其是在需要处理大量交易时。因此,像 MegaETH 这样注重高性能和高吞吐量的区块链项目,在初期不会选择使用 ZK 技术,以避免性能问题影响用户体验。

MegaETH 回应:多种交易确认方式

随后 Lei Yang 发推文回应了关于 MegaETH 节点架构的讨论,澄清了一些误解。他指出,MegaETH 用户在确认交易时有三种选择:

  1. 只接收状态更新的节点:这种节点不验证任何交易,只从定序器接收状态更新。这种方式的安全性依赖于定序器的预确认机制和惩罚机制。适合于小额到中额交易,特别是在需要即时确认的场景下。

  2. 等待欺诈证明窗口到期的节点:与 1 相同,但用户需要等待欺诈证明窗口以及交易所在的 MegaETH 区块在以太坊上被最终确认。这个选项提供了「完整的以太坊安全性」(即受到与以太坊交易相同的安全性和不可逆性),适用于用户不希望本地验证交易但涉及大额交易的场景。这种用例较为罕见。

  3. 验证所有交易的全节点:这种全节点验证每一笔交易,并等待交易所在的 MegaETH 区块在以太坊上被最终确认。同样提供了「完整的以太坊安全性」,适用于定期处理大额交易并且希望快速确认的用户,比如交易所。

Lei Yang 强调,MegaETH 是支持能够验证每笔交易的全节点的。之前的讨论中可能产生了误解,认为 MegaETH 的节点只能接收状态更新而不能验证交易,这是错误的。并进一步解释,如果节点选择验证所有交易,它可以通过优化手段(如使用定序器提供的见证数据)来比定序器更高效地验证交易,不需要从头开始处理所有交易信息,从而降低硬件需求。用户可以根据自身需求在不同的确认方式之间做出选择。

这场争论相当精彩,正如 ABCDE 投研合伙人 Lao Bai 所说:「这种辩论有意义么? Absolutely!整个行业的技术演进就是在这一次次讨论中被推着缓慢向前的。谁赢谁输重要么?Absolutely Not!因为最终胜出方靠的是资源,开发者/用户体验,以及谁先跑出来 1-2 个爆款应用,而不是『全节点』的定义与职责到底是啥」。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

Back To Top