原标题：我如何学会停止担忧并热爱执行分片
视频链接：https://www.youtube.com/watch?v=A0OXif6r-Qk
讲师：Scott Sunarto (@smsunarto) 在研究日
文章编辑：Justin Zhao (@hiCaptainZ)
大家好，我是 Scott (@smsunarto)，Augus Labs (@ArgusLabs_) 的创始人。今天，我将讨论一个我们很久没有触及的话题。随着卷积技术成为潮流，我们不常谈论执行分片，更多的是数据分片。所以，让我们重新审视这个有些被忽视的执行分片话题。
这将是一个轻松的演讲。我知道大家整天都在听复杂的概念，所以我会尽量保持实用。我为这次演讲准备了适当的幻灯片设计。
对于那些不认识我的人，一个有趣的事实是，我在推特上被称为动漫女孩。我还错过了我的大学毕业典礼来到这里，这让我的父母非常不满。目前，我是 Argus Labs 的创始人。我们自认为是一家游戏公司，而不是基础设施或加密公司。我最大的抱怨之一是，所有加密游戏的人都想构建工具，但没有人想创造内容或应用程序。我们需要更多用户可以实际使用的应用程序。
之前，我是 Dark Forest (@darkforest_eth) 的共同创作者，与我聪明的朋友 Brian Gu (@gubsheep) 和 Alan Luo (@alanluo_0) 一起。Brian 现在在运营 0xPARC (@0xPARC)，比我聪明得多。
今天的演讲将专注于执行分片，但在一个大多数关于执行分片的讨论中不太熟悉的背景下。我们通常在一层的背景下讨论执行分片，比如以太坊分片或 Near 分片。但今天，我想稍微改变一下背景。让我们想想在卷积环境中分片会是什么样子。
这里的根本问题是，为什么一家游戏公司要架构自己的卷积，以及我们可以从《魔兽世界》中学到什么来设计卷积。此外，我们还将探讨卷积的设计空间如何超越当前的现实。
为了回答这些问题，让我们回到 2020 年，当时 Dark Forest 的想法首次被提出。我们问自己，如果我们创建一个每个游戏动作都是链上交易的游戏会怎么样？当时这是一个荒谬的前提，今天对许多人来说仍然是。但这是一个有趣的假设，所以我们构建了它，Dark Forest 应运而生。
Dark Forest 是一个完全链上空间探索 MMORTS 游戏，运行在以太坊上，由 ZK-Snarks 提供支持。回到 2020 年，ZK 并不像今天那么流行，因为几乎没有文档。Circom 唯一可用的文档是 Jordi Baylina (@jbaylina) 的 Google 文档。尽管面临挑战，我们从这个过程中学到了很多，Dark Forest 就是这种学习的体现。
Dark Forest 是一个超出我们预期的实验。我们有超过 10,000 名玩家，消耗了数万亿的燃气，并且在游戏中发生了很多人们在链上互相背叛的混乱。Dark Forest 和链上游戏最迷人的地方在于平台化的性质。通过拥有一个链上游戏，你为新兴行为打开了设计空间，并允许人们构建与游戏互动的智能合约，以及替代客户端和游戏模式，例如 Dark Forest Arena 和 GPU 矿工。
然而，强大的力量伴随着巨大的责任。当我们在 xDai 上推出 Dark Forest 时，现在被称为 Gnosis Chain，我们最终填满了整个链的区块空间。这使得链几乎无法用于其他任何事情，包括 DeFi、NFT 或任何其他 xDAI 的东西。
那么，现在怎么办？我们是否到了死胡同？链上游戏是否永远不会成为现实？还是我们回到制作游戏，链上唯一的东西是 JPEG，并说服人们相信钱是从树上长出来的？答案是，我们让软件做事情。我们中的许多人以非常僵化的方式思考区块链和卷积，仿佛没有太多改进的空间。但我不同意。我们可以进行实验，发现新的可能性。
我们问自己这个问题：如果我们要从头开始为游戏设计一个区块链，它会是什么样子？我们需要高吞吐量，因此需要同时扩展读取和写入。大多数区块链都是为了进行大量写入而设计的。每秒交易数是人们所宣传的指标，但现实是，读取同样重要。如果你无法从区块链节点读取数据，你怎么知道你的位置在哪里？这实际上是我们在区块链构造中发现的第一个瓶颈。
Dark Forest 遇到了一个问题，完全节点被大量使用，I/O 爆炸，因为我们需要从链上状态读取数据。这导致了数千美元的服务器费用，xDAI 团队慷慨地为我们承担了这些费用。然而，这对长期来说并不理想。我们不仅需要每秒写入交易的高吞吐量，还需要读取，例如从区块链本身获取数据。
我们还需要一个水平可扩展的区块链，以避免噪声邻居问题。我们不希望一个受欢迎的游戏突然在区块链上崩溃，导致所有其他事情停止工作。我们还需要灵活性和可定制性，以便我们可以修改状态机，使其设计为游戏。这包括拥有游戏循环，使其自执行，等等。
最后但并非最不重要的是，这对那些不熟悉在线游戏架构的人来说可能有些模糊，我们需要一个高 tick 率。Tick 是游戏世界中的原子时间单位。在区块链上下文中，我们有区块作为原子时间单位。在游戏中，我们有 ticks。当你构建一个完全链上的游戏时，区块的速度或区块生产的速度等于游戏本身的 tick。
如果你有更高的 tick 或每秒更多的区块，游戏感觉更具响应性。相反，如果你有较低的 tick，游戏感觉更迟钝。需要记住的一点是，如果区块生产延迟，你会在游戏中感受到视觉上的延迟。这是一个糟糕的体验。如果你曾经处理过一个愤怒的玩家因为输掉比赛而对着电脑大喊，那绝对是一个糟糕的情况。
目前，我们的卷积每秒一个区块，这等于一个 tick 率。如果我们想要更酷的游戏，我们需要更高的 tick 率。例如，Minecraft，一个简单的像素艺术游戏，每秒有 26 个 ticks。我们还有很长的路要走，才能构建出像 Minecraft 一样响应迅速的游戏。
一个可能的解决方案是部署我们自己的卷积。虽然这似乎在表面上解决了问题，但实际上并没有解决问题的根本原因。例如，你的写入吞吐量会更高，但并没有达到游戏所需的水平。当然，如果你的游戏有一百名玩家，这就足够了。但如果你想构建需要更高吞吐量的游戏，由于当前构造中 I/O 的方式，会有非常严格的限制。
在读取方面，你并不会真正获得性能提升。你仍然需要依赖索引器。你并没有真正的水平可扩展性。如果你试图启动一个新的卷积来水平扩展你的游戏，你会使现有的智能合约生态系统碎片化。玩家部署的市场将无法与其他你启动的链兼容，以水平扩展你的游戏。这会带来很多问题。
最后，高 tick 率和每秒区块数根本不是一回事。我们可以尽力去推动它。我们可能会得到每秒两个区块，也许三个，但这就是这些区块链能达到的极限，因为有很多开销，比如重新编组等，这对计算周期非常有负担。
为了解决这个问题，我们回顾了 2000 年代初和 1990 年代末，当时在线游戏如 MMO 刚刚兴起。它们有分片的概念。这并不是一个新概念；它在过去就已经存在。我们在数据库架构中使用的 “分片” 一词实际上来自于《最终幻想在线》的参考。它们是最早使用 “分片” 一词来解释其不同服务器的游戏之一。
那么，分片在游戏中是如何工作的？这并不是一个适合所有人的解决方案。它是工具箱中的一个工具，如何将其适应你的游戏因上下文而异。例如，第一个分片构造是我喜欢称之为基于位置的分片。一个好的心理模型是想象一个被分成四个象限的笛卡尔图，每个象限都有自己的游戏分片。每当你想跨越一个分片时，你会与另一个分片进行通信，告诉它：“嘿，我想移动到那里”，然后你会被传送到你的分片，留下你之前的玩家身体。通过这样做，你将服务器的工作负载分配到多个物理实例，而不是强迫单个服务器为整个游戏世界进行所有计算。
第二种构造在今天更受欢迎。它被称为多元宇宙分片，其中你有多个相互镜像的游戏实例。你可以选择想要去的任何分片，并且默认情况下是负载均衡的，这样每个服务器不会过于拥挤。
现在，关键问题是如何将这个概念引入卷积？这就是我们创建世界引擎的原因。世界引擎是我们的旗舰基础设施，基本上是一个为启动而设计的有观点的分片序列器。与我们在过去几次演讲中看到的许多分片序列器设计不同，我们的设计不同，更适合我们的需求。我们优化的目标是：A、吞吐量，B、我们希望确保没有锁定阻塞运行时，以确保 tick 率和区块时间尽可能高效，因此它默认是同步的，我们设计序列器的方式是部分顺序，而不是强制完全排序，即每个交易需要在其他交易之后发生。
这里的关键组成部分是我们有两个主要的东西。我们有基于 EVM 的分片，它就像一个纯 EVM 链，玩家可以部署智能合约与游戏进行组合，创建带有税收的市场，等等。它将像一个普通的链，对吧？每秒一个区块或每秒一个事务，刚好足够你做所有典型的设备和市场事务。
这里的秘密成分是我们使用一个游戏分片，它本质上是一个高性能游戏服务器设计的迷你区块链。我们有一个自带实现的接口，以便你可以根据自己的喜好自定义这个分片。你可以构建自己的分片并注入到基础分片中。你只需要实现一组标准接口，就像如果你熟悉 Cosmos，Cosmos 有一个 ABC 接口。你基本上可以将其符合类似的规范，将自己的分片带入世界引擎堆栈。
这里的关键是我们有一个当前无法通过现有分片构造实现的高 tick 率。这就是我想介绍 Cardinal 的地方。Cardinal 是世界引擎的第一个游戏分片实现。它使用实体 - 组件 - 系统，具有面向数据的架构。这使我们能够并行化游戏并提高游戏计算的吞吐量。它的可配置 tick 率高达每秒 20 个 ticks。对于这里的区块链人士来说，这相当于每秒 20 个区块。
我们还可以进行地理定位以减少延迟。现在，你有可能位于美国的序列器，而亚洲的人们必须等待大约 300 毫秒的延迟，才能让交易到达序列器。这在游戏中是一个巨大的问题，因为 300 毫秒是很长的时间。如果你尝试在 200 毫秒延迟的情况下玩 FPS 游戏，那几乎是永远的，你已经死了。
另一个对我们也很重要的关键点是它是自索引的。我们不再需要外部索引器。我们不需要这些框架来缓存游戏中的状态。这也使我们能够构建更多实时的游戏，而不会出现延迟问题，因为索引器仍在试图跟上序列器的区块。
我们还有一个插件系统，允许人们并行化 ZK 验证等等。对我来说，最好的部分是，你可以用 Go 编写代码。不再需要与 Solidity 纠缠，试图让你的游戏工作。如果你曾经尝试用 Solidity 构建区块链游戏，那绝对是个噩梦。
但确实，我们的分片构造的关键是你可以将任何东西构建为分片。它们基本上是一个无限的设计空间，关于分片可以是什么。
假设你不喜欢用 GO 编写游戏代码，你可以选择退出，但我们正在开发一个 Solidity 游戏分片，允许你用 Solidity 编写游戏实现，同时保留 Cardinal 的许多好处。你还可以创建一个 NFT 铸造分片，具有独特的交易池和排序构造，解决基本铸造噪声邻居问题。你甚至可以拥有一个游戏身份分片，你可以使用 NFT 代表你的游戏身份，允许你轻松地使用 NFT 交易你的游戏身份，而不必给出你的私钥，这是不明智的。
这是一个高层次的构造，由于时间限制，我不会深入探讨。这里的关键是，我们允许 EVM 智能合约通过使用自定义选择和传递与游戏分片组合。我们在 Geth 周围创建一个包装，以允许它们之间的通信。这在双向上打开了很多设计空间。我们默认是同步的，并且在分片之间具有无锁的无缝可组合互操作性。
我们的共享序列器不同之处在于，它不使用共享序列构造，优先考虑总排序的原子捆绑，这需要锁定机制，并导致诸如阻塞主线程等问题，从而导致不可靠的 tick 率和区块时间，进而导致游戏延迟。它还对每个分片的区块时间施加限制，并需要各种加密经济学和构造来防止拒绝服务。此外，还有一个大象在房间里，我没有看到很多 VCR 序列器构造提到：如果你有不同的分片相互依赖并导致死锁，你如何解决死锁？通过异步设计，这些都不是问题，因为每个人都在做他们想做的事情，随意发射和忘记。
现实是，跨分片和卷积的原子捆绑通常不是必要的。对于我们的用例，我们不需要任何需要原子捆绑的东西，我们认为不应该围绕用例的纯度来设计我们的卷积。这也导致了许多其他有趣的属性。例如，每个游戏分片可以有一个单独的 DA 层用于基础链。例如，你可以使用基础分片将数据推送到以太坊，而游戏分片可以将数据推送到 Celestia，就像数据可用性委员会一样。你还可以减少运行完整节点的硬件要求，因为你可以单独运行基础分片 Geth 完整节点，而不必运行游戏分片节点，这使得你更容易与 Alchemy 等事物集成。
最后，我想在这里保持知识上的诚实。很多人想声称他们的构造解决了所有生活的问题，但对我们来说并非如此。我们认为我们的构造对我们有用，但也许对你的用例并不适用。假设我们的构造适用于每个人的用例并不现实。它满足了我们的需求，提供了高吞吐量、水平可扩展性、灵活性和高 tick 率，但并不能治愈癌症。如果你需要一个需要同步可组合性的 DeFi 协议，那么这个构造可能不适合你。
总之，我真的相信以人为本的区块链架构的概念。通过围绕特定用户角色和用例进行设计，你可以更好地导航权衡空间，而不是试图解决每个人的问题。文艺复兴的时代已经到来，每个人都可以设计自己的卷积以满足他们的特定需求，而不是依赖于通用解决方案。我相信我们应该拥抱寒武纪大爆发。不要像一层一刀切的方式构建卷积，因为它根本不是为了解决同样的问题而设计的。我个人期待看到更多人探索更多特定用例或行业的卷积设计空间。例如，专门为资产交换设计的卷积会是什么样子？它会是基于意图的吗？专门为链上 CLOB 设计的卷积会是什么样子？说完这些，我将把麦克风交还给 MJ。感谢大家的聆听。