Devs on Devs: tdot 和 Ben Jones 对谈

在这期特别的 Devs on Devs 节目中，我们邀请到了 Plasma Mode 的核心协议开发者 tdot(同时也是 Redstone 的开发者)和 Optimism 的联合创始人 Ben Jones。Optimism 是 OP Stack 的核心推动者。Plasma Mode 允许开发者在 OP Stack 上构建，但无需将数据发布到 L1，而是可以灵活地切换到链下数据提供者，从而节省成本并提高可扩展性。在对话中，他们讨论了 Redstone 和 Optimism 合作的起源、复兴 Plasma 的重要性、将实验性协议引入生产环境的必要性、Plasma Mode 和 OP Stack 的未来路线图，以及他们对全链游戏领域发展的兴奋之情。

如何使用 Plasma 模式改进 OP Stack

Ben: 开始改进 OP Stack 的过程是什么样的？

tdot: 我大约一年前加入 Lattice，专门负责 Plasma Mode。目标很明确:我们有很多 MUD 应用程序消耗大量 gas，同时我们试图将大量数据放到链上，所以需要一种既支持这些需求又便宜的解决方案。Lattice 团队已经在 OP Stack 上做了一些试验，比如原型化一些链上世界并部署在 OP Stack 上。我们发现 OP Stack 已经非常好用了。

于是我们问自己，"怎么才能让它更便宜？" 基本假设是，"我们认为 OP Stack 是最符合以太坊理念且完全兼容 EVM 的框架。" 在主网上运行的东西可以同样在 OP Stack 上运行，这是理想的解决方案。但我们希望它更便宜。

当时，calldata 仍然是 OP Stack 链的数据可用性(DA)来源，这非常昂贵。所以我们显然无法用 calldata 来启动一个 L2，因为我们的全链游戏和 MUD 世界需要更高的吞吐量。因此，我们决定开始尝试其他数据可用性(Alt DA)方案。实际上，在最初的 OP Stack 文档中已经提到要探索 Alt DA。

于是我们问自己，"如果从链下 DA 开始会怎么样？" 我们希望整个安全模型和所有内容都能依赖 L1 以太坊。因此我们避开了其他 Alt DA 解决方案，决定将数据存储在中心化 DA 存储中，然后在 L1 上找到一个有效的安全模型。

这就是我们为何要重新使用一些旧的 Plasma 概念并将其放在 rollup 之上。这里有一些不同。最大的疑问是，如何在现有的 OP Stack 上实现链下 DA 和链上数据挑战？我们的目标是尽量少改动 OP Stack，对 rollup 路径没有任何影响，因为我们不想影响使用 OP Stack 的其他 rollup 链的安全性。

在设计 rollup 时，你不会想着，"如果有人改变了数据生成流程以从其他地方存储数据会发生什么？" 即使有这些改动，OP Stack 仍然非常强大，开箱即用效果很好。这是我们所做的第一个改动。

之后，我们需要编写合约来创建这些挑战。有用于强制将数据上链的 DA 挑战。这是第二步，将合约集成到流程中。我们必须在派生过程中构建整个集成系统，这样你就可以从一个链外的 DA 来源以及一个 L1 DA 挑战合约中派生数据，以防数据在挑战解决过程中提交到链上。

这就是事情的要点。很复杂，因为我们希望保持事情的优雅和稳健。同时，这是一个相对简单的概念。我们没有尝试重新发明一切或改变整个 OP Stack，而是尝试在一个复杂的环境中保持事情的简单。所以总体来说，这是一段非常酷的工程旅程。

Ben: 我可以从 OP 的角度来谈谈。你提到了一些 Lattice 早期的工作。恰好在同一时间，我们 Optimism 几乎对整个 OP Stack 进行了端到端的重写，这次发布我们称之为 Bedrock。

基本上，在构建 rollup 两年之后，我们退后一步，反思说："好吧，如果我们要把学到的所有经验都用到极致，这会是什么样子？" 这演变成了最终被称为 Bedrock 的代码库，这是我们对网络进行的最大升级。

在那个时候，我们与你们合作了一个叫 OPCraft 的项目，我认为 Biomes 是它的精神继承者，这是我们在链上玩得最开心的一次。同时，我们也松了一口气，因为其他人也可以使用 OP Stack 进行开发。我认为在过去几年里，扩容的另一个重要转折点是很多人可以运行链。

并不是只有那些开发了庞大复杂代码库的人才能做到这一点。当我们开始合作时，看到别人能够接手这个代码库并做出一些非常了不起的事情，这是一种极大的肯定。然后看到这种情况在实际应用中扩展到 Plasma 上，真是太酷了。我甚至可以稍微谈谈那段历史。

在 Optimism 成为 Optimism 之前，我们实际上在研究一个叫 Plasma 的技术。当时我们承担的任务远超当时扩容社区的能力。你在早期的 Plasma 设计中看到的设计，可能与今天的 Plasma 并没有直接的对应关系。

今天的 Plasma 要简单得多。我们将状态验证的证明和挑战与数据的挑战分开来看。最终，我们几年前认识到 Rollups 比 Plasma 要简单得多。我认为，当时社区的结论是"Plasma 已死"。这是那个时期以太坊扩容史上的一个梗。

但我们一直认为"Plasma 并没有死，只是我们可以先尝试一个更简单的任务"。现在我们使用不同的术语。比如，当时有退出(exits)等概念，现在你可以回过头来看，说"哦，那是一个带有一些额外步骤的数据可用性挑战"。所以看到不仅 OP Stack 被其他人使用，还被演化成我们最初尝试但以非常混乱和不成熟的抽象方式做的事情，真是令人惊叹。我们已经完成了一个完整的循环，你们围绕它们做了非常棒的抽象，并使其以一种合理和理智的方式工作。这真的很酷。

最重要的是尽快进入生产环境

tdot: Plasma 模式仍然存在一些挑战和未解决的问题，我们还在努力解决。关键是如何避免耗费长达十年的时间？你懂我的意思吧？我们需要尽快达到可以交付成果的阶段。

这就是我们的想法。我们已经有很多基于 MUD 开发的应用想要立即上线主网。我们需要尽快为这些游戏准备一个主网。人们已经在等待，并且准备好了。你需要一个快速上线并能运行的链，来运行所有这些应用程序，这样这些应用可以在我们解决问题的同时并行发展，变得更好。从研发到实现生产稳定性需要很长时间。

要将某个东西上线主网，使其无许可、稳健和安全，需要耗费大量时间。看到我们实现这一目标的整个过程已经很令人惊叹了。这就是为什么我们需要保持高度的敏捷，因为事情太多了。整个生态系统发展得非常快。我认为每个人都在交付大量的创新。这就是为什么你必须跟上，但你也不能在安全性和性能上妥协，否则系统就无法运行。

Ben： 或者说是技术负担。你提到的最小改动原则，这是我们进行 Bedrock 重写时的核心理念之一。我谈到了整个端到端的重写，但更重要的是，我们减少了大约 50,000 行代码，这本身就非常有力。因为你说得对，这些事情确实很难。

每增加一行代码都会让你离生产环境更远，使得事情更难以经过实战测试，并引入更多的错误机会。所以，我们非常感谢你们在推动这一过程中的所有努力，尤其是为 OP Stack 的新操作模式做出的贡献。

tdot： OP Stack 确实创造了一种方式，使你可以在这类事情上快速推进。协调大家非常困难，因为我们显然是两家不同的公司。在 Lattice，我们正在构建一个游戏，一个游戏引擎，以及一条链。

而你们正在构建成百上千的东西，并且定期交付所有这些产品。从协调方面来看，这确实非常不易。

Ben: 是的，确实还有很长的路要走。但这正是模块化的核心魅力所在。对我来说，从 OP Stack 的角度来看，这是最令人兴奋的事情之一，暂且不提现在在 Redstone 上构建的那些令人惊叹的游戏和虚拟世界。纯粹从 OP Stack 的角度来看，这是一个非常有力的例子，证明了很多优秀的核心开发者已经加入进来并对这个栈进行了改进，这非常了不起。

这是第一次，你可以通过一个关键的布尔值显著改变系统的属性。能够彻底做到这一点，正如你所说，确实还有很长的路要走。但即使是接近有效地做到这一点，也需要模块化的支持，对吧？对我们来说，看到你们实现了这一点，而不需要例如重写 L2 Geth，真是让人松了一口气。对我来说，这证明了模块化正在发挥作用。

tdot: 现在情况变得更好了。从这个例子来看，你们把所有东西都变成了独立的小模块，可以进行调整和改变属性。所以我非常期待看到还有哪些新功能会被集成进来。我记得我们曾经担心的是，我们有一个分叉，包含所有对 OP Stack 的改动，需要将其合并到主干中。我们当时想，"天啊，要审查所有内容会很疯狂。"

我们不得不将其分解成更小的部分，但整个过程进行得非常顺利。我们和团队的合作氛围非常好，所以审查过程也很愉快。这感觉非常自然。而且我认为在审查和解决一些潜在问题方面，这个过程进行得非常快。一切都出乎意料地顺利。

Ben: 这真是太好了。今年我们的一个重点是为 OP Stack 创建贡献路径。所以我非常感谢你们参与测试，推动这些流程。我很高兴这些流程并没有让人难以承受，并且我们取得了一些成果。说到这，我很好奇，从你的角度来看，接下来这项工作会如何发展？你接下来最期待开发的是什么？

tdot: 有很多不同的工作方向。主要是与故障证明机制的集成。我们采用一种渐进的方法来去中心化整个技术栈，并增加其无许可特性，最终目标是实现无许可和强制退出等功能。

我们有这个终极目标，并在保持安全性的同时逐步实现。一个挑战是，有时候不上主网会更容易，因为这样就不需要进行硬分叉。你可能会想，"哦，我只要等到一切都完全准备好再发布，这样就不需要进行硬分叉，也没有技术负担。"但是，如果你想快速上线主网，就必须处理这些复杂的升级，并且频繁发布。做到这一点并保持高可用性总是一个挑战。

我认为在故障证明机制和所有这些部分都准备好之后，Plasma 模式方面会有很多升级。我认为在批量提交 commitment 方面仍有一些优化空间。现在我们做得很简单，每笔交易一个 commitment。而 commitment 只是链下存储的输入数据的哈希值。

我们暂时保持尽可能的简单，这样审查起来便可以简单且快速，并且对 OP Stack 没有大的差异。但是现在有一些优化可以使其更便宜，比如将 commitment 进行批处理或者将它们提交到 blob 中，或者采用其他