# 关于引入 BFT 作为 Sequencer By [Untitled](https://paragraph.com/@0x4c749bd11001d9dd2998d8dea0a9ed2b95fc0f70) · 2023-04-07 --- * [Flashbots: The Future of MEV is SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave) * [MEV Auction by Optimism](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) * * [Keone: EIP-4844 Analysis of Optimism and Arbitrum](https://twitter.com/keoneHD/status/1641159901467607040) 以下为讨论的全文，因经过 OpenAI Whisper 转译，并通过 GPT-4 处理后形成，有部分调整和删减。 _话题一：EOF（以太坊对象格式）_ > Zhixiong Pan： > 以太坊对象格式（EOF）原本计划在上海升级中实现，但现在已经被推迟。EOF 的本质是为以太坊的自字节码提供一种前置的数据结构，有利于未来EVM的字节码特性和智能合约的升级。 > 请问此次升级是否会对整个 Layer 2 或 Rollup 生态产生更多影响？特别是 Rollup 生态本质上也会部署一些智能合约到以太坊 Layer 1 上，那么这次升级是否会影响到 Layer 2 相关的技术选择和路径？ > Dorothy Liu： > 在 AltLayer 团队看来，EOF 并不是一个非常重要的创新。尽管它对 EVM 的分装模式有重要的改进，但它对 Solidity 语言的编写并无直接影响。因此，从应用开发和普通开发的角度来看，这个改变对他们的影响不大，甚至很多开发人员可能不了解这个事情，也不会造成问题。 > 然而，对于 Rollup 来说，影响非常大，因为 Rollup 本质上是以太坊的执行层。当以太坊发生改变时，Rollup 也需要相应地进行调整。这个 EOF 的改变可能会对 zkEVM 产生更大的影响，因为 zkEVM 在技术难度上相对更高。它们在 EVM 兼容性分类中属于 Type-3，因此，在追求更高兼容性的过程中，他们需要付出更大的努力。甚至可能需要重写或进行非常大的改变。 > 然而，对于我们这些做 Optimistic Rollup 的项目，无论是使用 WASM 编写还是使用 EVM 编写，我们都是 Type-1 的兼容性，即完全与 EVM 兼容。因此，对我们来说，这个难度是很低的。尽管我们需要进行一定的修改，但难度相当低。另外，我们自己的生产证明都在 WASM 里面，所以对我们来说，实际影响并不大。 > Ye Zhang: > 首先，我认为 EOF 确实是一个重要的技术发展。之前有一个观点认为，由于 EVM 核心升级较少，因此 zkEVM 不需要频繁改动。但最近有了 EOF，之后可能还会有其他升级对 EVM 的核心逻辑进行改动，这确实会对 zkEVM 产生影响。然而，目前来看，因为 EOF 是前向兼容的，所以对之前的合约仍具有一定的兼容性。至少对我们现有的合约以及开发者来说，直接影响较小。可能之后会有一些需要注意的地方，但至少对我们 Layer 1 的合约来说，影响不会很大。在 Layer 2 上，影响程度取决于我们对 EOF 的支持程度。我们肯定会稍微滞后一些，因为如果我们想要与 Layer 1 的 EVM 完全一致，我们需要支持 EOF。 > 实际上，我们在开发 zkEVM 时，已经关注到了 EOF 的核心升级，这比预想的要容易一些。因为我们在构建整个 zkEVM 时，采用了模块化的设计，可以方便地更新 Opcode。对于 EOF 来说，主要的改动是添加了一些版本控制和 Opcode，我们只需要实现这些新的 Opcode，并在版本控制方面做好相应的工作，例如在电路中添加一些标签和变量。这些改动是在 Opcode 级别进行的，需要添加一些电路。另外，EOF 还对字节码部署进行了一些检查，这会影响到 zkEVM 的一个子电路，即字节码电路。在这个电路中，我们需要对输入的哈希进行检查，然后输出相应的字节码。如果需要在这个环节进行检查，我们可能需要在该电路中添加一些约束。 > 总体来看，我认为改动是必要的，但不会达到需要彻底重构的程度。以太坊现在将 zkEVM 提到了一个非常重要的地位，他们自己也在引领一些关键的技术发展。我知道 Vitalik 和一些 EIP 核心团队的成员也在关心 zkEVM 团队的进展，包括与我们进行交流，了解这次升级对 zkEVM 带来的影响。因为 Layer 1 的每次升级都会带来一定的风险，之前有观点认为，每次升级可能是不可逆的。因此，我们希望 Layer 1 尽可能稳定，结算层越稳定越好，这样对应用程序和现有技术的影响也会越小。在 Layer 2 上，我们可以进行各种创新。然而，如果 Layer 1 确实需要改动，我认为 Layer 2 也可以跟随进行相应的调整，而且改动不会特别大。但我确信会有一定的延迟，因为我们需要实现这些改动，可能还需要进行审计。审计过程可能需要额外的时间来完成，因此我们总体上希望改动尽可能少。不过，我认为这些改动并不会对整个系统产生致命性的影响，不会导致严重的问题。 > Qi Zhou： > 关于 EVM Object Format (EOF)，我注意到以太坊社区在之前的讨论中也涉及到很多相关话题。特别是在上海升级期间，我们可以看到以太坊对整个升级过程有一些不同的态度。例如，像 Danksharding 的创始人 Dankrad 就对 EOF 持有一定的质疑。他们认为，虽然 EOF 对开发者来说没有太大的变化，但主要是改进合约的安全性。在这方面，他们觉得现在不是以太坊扩容的最重要阶段。实际上，EOF 只是整个扩容计划中的一个非常小的部分，因此在这方面也产生了很大的争议。 > 然而，为什么现在想要将 EOF 纳入升级计划呢？这是因为 EOF 已经提出了非常长的时间，可能已经有四五年的时间了，而在之前的内部讨论中可能会有更长的时间。在对 EOF 进行分析之后，我们确实非常同意 Dankrad 的一些观点。虽然 EOF 为整个以太坊合约带来一定的安全性，比如取消动态跳转这个相对比较危险的操作，但实际上，在大量的以太坊实践操作和编写合约过程中，编译器已经把底层容易犯错的问题避免掉了。因此，我们在最近几年的开发过程中没有遇到过类似跳转导致的异常合约执行情况。 > 对于 EOF 是否会进入下一阶段的升级，例如坎昆，由于考虑到它可能对以太坊的 Layer 2 计算层产生一定的影响，我个人认为可能还会有一定的争议。相较于我们接下来要讨论的 EIP-4844，关于 EOF 的观点仍存在较多分歧。 > Jolestar: > 关于 EVM Object Format（EOF），它主要带来了两个优化。首先，它将智能合约代码的验证前置，在部署时进行验证。这对性能提升非常有效。目前，很多项目已经采用了这种方法，通过在部署阶段进行代码验证。其次，EOF 提供了一种扩展能力。虽然这次更新可能不会带来很大的改动，但是一旦提供了这种扩展机制，未来可能会面临很多扩展需求。这时候可能会面临一个抉择：是要创新的扩展还是兼容性。这实际上一直是所有软件系统要面临的一个困境。 > 通过这种方式，EOF 实际上为未来的变化打开了大门。例如，为了实现某个 Layer 2 特性，可以增加一个新版本并在智能合约代码中加入一些新的功能。这时候，与 Layer 1 的兼容性可能会受到影响。这种变化确实可能引发很大的争议。然而，从我的角度来看，我认为在这个阶段仍应将创新和演进作为优先考虑，还没有到完全冻结的情况。当然，对于 Layer 1 来说，这是另外一个维度，Layer 1 和 Layer 2 的判断可能不同。 \*话题二：去中心化 Sequencer（定序器）\*Zhixiong Pan： > 目前，大多数 Layer 2 网络的 Sequencer 仍处于较早阶段，大多数是单一 Sequencer。一些项目计划将来升级为去中心化的 Sequencer。 > 当前是否存在合理的去中心化 Sequencer 设计方案？ > Layer 2 的原生代币是否可能成为实现去中心化 Sequencer 的必要条件？如 Optimism/Arbitrum，虽然有自己的代币，但仅可用来作为治理代币。 > 所以还有哪些前沿或早期的去中心化 Sequencer 方案值得关注？ > Qi Zhou: > 最近我们研究了一些相关话题，例如 Arbitrum 的 Sequencer。Arbitrum 社区面临着一个大问题，即大量节点（如1万个连接）连接到 Sequencer 以获取最新的交易信息并从中套利。我们内部经常开玩笑说，这个 Sequencer 是否类似于纽约证券交易所，因为在纽约证券交易所附近有许多量化机器人通过光纤快速获取交易数据并进行量化操作。这种 Sequencer 模型是否会导致我们退化成为一种非常集中化的系统？ > 我认为如何实现 Sequencer 的去中心化是一个非常重要的问题。我能想到的一些解决方案是借鉴权益证明（POS）机制，并将 Layer 2 的原生代币用作权益证明。通过这种方式，我们可以实现 Sequencer 的轮换，类似于以太坊最近正在进行的安全领导人选举（secure leader election）。结合这些技术，我认为我们可以找到一些成熟的方式来解决这个问题。 > Dorothy Liu: > 这个问题，我可以分享一些我个人对 Arbitrum 和 Optimism 发展历史的观察。去年年初，我去阿姆斯特丹参加了 Chainlink 举办的关于 Rollup 的活动，当时请到了 Arbitrum、Optimism、zkSync 和 Metis 四个团队。他们讨论的重点主要在扩容和性能上。我私下询问了他们对共识层的看法以及 Rollup 是否需要加共识层。他们表示目前只考虑扩容。Optimism 最早并没有考虑到这个问题，导致现在想改也无法改变。 > 从我们的角度来看，我们从项目一开始就设计了去中心化的 Sequencer。我们曾经做过两次 Dark Forest 游戏和两次 NFT Minting 活动，这些活动都是直接在以太坊主网上进行的，使用了去中心化的 Sequencer。在我们看来，这不是一个技术问题，而是一个历史发展的遗留问题。他们如何在一个正在运行的系统中更换引擎会比新项目一开始就有完整规划更困难。 > 关于代币问题，Arbitrum 和 Optimism 已经证明，可以不需要自己的代币就可以运行。如果想要有代币，可能需要一些设计，例如 Slashing 等。我们将在下个月发布去中心化 Sequencer 网络，这将是市场上第一个去中心化 Sequencer 网络。届时，我们会有一些包括 Staking 和 Slashing 在内的设计。 > 最后关于 MEV，虽然它与 Sequencer 是两个议题，但它们之间存在关联。去中心化的 Sequencer 网络或许能在一定程度上解决MEV问题。然而，这个问题可能永远无法彻底解决。目前，Arbitrum 团队采用了一些方法，如增加随机性改善，但他们无法完全解决这些问题。我们也可能会在硬件或其他方面提出一些 MEV 解决方案，这将在未来公布。 > Ye Zhang: > 我们已经对 Sequencer 进行了大量研究，尽管目前尚未公布具体方案，但我们确实在努力设计。目前有两种主要方向。第一种是基于拜占庭容错（BFT）的方案，例如利用 Tendermint 等选择一个leader来代替之前的中心化 Sequencer。这种方法需要 staking 和 slash，可能需要发行自己的代币来实现 PoS，或者与其他重押或类似机制结合。BFT 的优势在于可以提供非常快的预确认，保持良好的用户体验。 > 第二种更有前景的方案是 MEV Auction（拍卖）。Optimism 最早提出了 MEV 拍卖的概念，即谁给出最高价格就能获得出块权。然而，这种方案的缺点在于用户可能会被 MEV 机器人疯狂加价。 > 类似的方案包括 Justin Drake 之前提出的 Base Rollup，其核心思想是重用 Layer 1 的验证器来出 Layer 2 的区块。这样一来，构建 Layer 1 和 Layer 2 的区块的验证器可以在构建 Layer 1 区块时将 Layer 2 的验证交易放入 Layer 1 的区块，从而使整个出价更大，Layer 1 的区块更先被包含。这种方案的优点在于它与 Layer 1 的激励机制高度一致，但缺点是它不像BFT那样具有预确认，用户体验可能会变得较差。 > 因此，目前最有前景的方向是基于重用 Layer 1 验证器的方案，以及基于 BFT 的方案。我们正在努力解决这些方向上的问题，例如在重用 Layer 1 验证器的同时提供预确认。 > 还有一些关于去中心化 Sequencer 的方向，例如 Flashbots 等提出了一个名为共享 Sequencer（Shared Sequencer）的方案，Optimism 的 Superchain 中也有相似的设计。共享 Sequencer 的核心思想是通过使用固定的 Sequencer 集合来处理多条链上的交易，实现跨链 MEV，提高跨链 UI 的体验等。然而，这种设计方案目前还处于早期阶段，尚未解决一些关键问题，如 Sequencer 节点压力问题以及跨链交易的原子性问题。 > 共享 Sequencer 可能在将来对于许多特定应用场景（如小型实时资产应用）有价值，因为这些应用可能没有足够的能力去运行去中心化网络。然而，对于大型实时资产应用而言，说服它们使用共享 Sequencer 可能是一项挑战。 > Flashbots 正在尝试通过构建一个隐私去中心化网络来实现共享 Sequencer，以解决信息获取带来的本质 MEV 问题，并为用户带来一定程度的价值。然而，由于该方案尚未完全公开，因此难以评估其是否能克服之前提到的问题。作为具有高正统性的 MEV 玩家，我们将在 Flashbots 公开其方案后对其进行详细评估。 > 关于是否需要 Token，我认为这主要取决于所使用的共识算法。如果采用 BFT 算法，很可能会需要 Token，但如果采用基于现有 Layer 1 验证器的方法，可能不一定需要 Token，因为可以重用其他人的资源。这样一来，价值来源就变成了谁在为你抵押，而 MEV 将直接流向网络验证器。因此，Layer 2 如何看待 MEV 的价值补充问题是决定因素。 > 关于 MEV 的处理方式，有一个观点认为公平排序可以在一定程度上解决 MEV 问题，但实际上它可能只是缓解了 MEV 问题。因为仍然可能有各种机器人在竞争优先权，这种情况类似于传统的交易公司。尽管已经引入了一些随机性，但目前还没有完全解决这个问题。事实上，有一项关于 MEV 的研究指出，公平排序并非公平。研究者通过构建一个攻击模型，证明了在公平排序情况下，用户的体验可能会更差。因此，为了实现真正的公平，可能需要针对不同的应用采用不同的排序策略。 > [![]({{DOMAIN}}/editor/youtube/play.png)](https://www.youtube.com/watch?v=M2YCPVInmzg) > 还有有很多有趣的尝试。例如，通过加密技术（如VDF）对交易进行加密，并在交易被确认后进行解密。这样一来，就无法提前预测交易的内容。此外，还有诸如时间锁定等方法。总之，我们也在关注并改进这些方案。虽然我们已经有了一些大致的方向，但每个方向都存在各种问题。因此，我们希望在确定方案之前进行严密的分析，以确保方案的稳定性。Sequencer 涉及到诸如价值流向等众多问题，因此我们认为目前尚无完美解决方案。这也是为什么我们将 Sequencer 的研究放在后面的原因。 > 现在大家普遍觉得去中心化 Sequencer 可能有利于抗审查。但正如我今天的讨论所提到的，实际上通过桥接的方式，可以确保在第二层强制执行交易。更重要的是，大部分桥接设计都会规定，如果你不包含某个交易，可能在一天内会受到某种影响。但是，大部分去中心化金融（DeFi）可能会在下一分钟就将你清算完毕，然后直接拒绝你的交易，可能会给用户带来糟糕的体验。因此，实时抗审查对用户和 DeFi 来说非常重要。 > 另一个问题是矿工可抽取价值（MEV）的问题。例如，Arbitrum 现在实施先到先得的策略，它采用中心化的序列器。大家之前的观点是，如果你发现我在 MEV 中被利用，我可能会离开这个网络，导致大家不相信该网络的合法性。但一个巨大的问题是，当你的网络起步，网络效应逐渐显现，例如单一序列器，一旦生态发展到一定规模，你开始收费或考虑 MEV 时，实际上用户已经对你产生很大的依赖，他们很难再转移到其他平台。所以我认为这个威胁可能会在几年后出现，他们突然开始实施 MEV，这是一个潜在的威胁。 > 此外，还有合规问题。如果你的代币和权益证明（PoS）有关联，你可能会面临一定的合规风险。例如，如果你实行中心化，某个国家要求你关闭序列器或解决某些问题，去中心化可能会带来一定的好处。 > 因此，我们已经进行了非常详尽的分析，并在这个方向投入了大量精力。如果听众中有人对协议研究感兴趣，欢迎加入我们。我们正在招聘这方面的人才，我们后续会有更详细的分析发布。 > Jolestar： > 关于引入 BFT 作为 Sequencer，大家已达成共识。实际上，我们需要在 Layer 2 中引入一个 BFT 共识。我们关注的是这个共识决定的内容。如果它直接决定了结果，那么我们可以让它直接决定。我们希望 Layer 2 提供扩展性，所以我们从另一个角度考虑 Sequencer。我们的主要目的是什么？一个是为了安全。在 Layer 2 方案中，Sequencer和 其他方案如 Proposer 或类似的 Prover 或 zk，它们是不同的角色。Sequencer 和 Proposer 在操作情况下是分开的，如果要作弊，它们必须联合作弊。例如，Sequencer 隐藏交易，Proposer 制造一个虚假的 root。如果它们的角色分开并由不同的组织承担，那么安全性就有保障。 > 在 Sequencer 提交到 Layer 1 之前，交易顺序可以被 Sequencer 调整，这里可能存在作弊空间。为了消除这个问题，我们让 Sequencer 提供一个类似于欺诈证明的证明，叫做 Sequence Prove。你证明把交易放在某个位置上，给出一个承诺。如果最后上链的顺序与承诺不一致，可以挑战并惩罚 Sequencer。 > 最后，如果我们真的要引入 BFT 投票，我们应该决定交易的顺序，而不是交易的结果。现有的共识机制决定的是最后执行的结果投票，并不决定区块链的交易顺序。因此，在这种情况下，我们可能需要引入一个对顺序或公平性敏感的共识，让大家投票决定交易的顺序。这是我们目前正在探索的一个方向和与 Sequencer 去中心化的一种方案。 --- *Originally published on [Untitled](https://paragraph.com/@0x4c749bd11001d9dd2998d8dea0a9ed2b95fc0f70/bft-sequencer-2)*