为什么Argus使用分片来构建全链游戏基础设施?

原标题: How I Learned to Stop Worrying & Love Execution Sharding

视频链接:

演讲人: Scott Sunarto (@smsunarto) on Research Day

文章编辑整理： Justin Zhao (@hiCaptainZ)

大家好，我是 Scott (@smsunarto)，Augus Labs（@ArgusLabs_）的创始人。今天，我要讨论一个我们已经有一段时间没有触及的话题。随着 roll-ups 成为时代的主流，我们对执行分片的讨论并不像对数据分片那样频繁。所以，让我们重新审视这个有些被忽视的话题 —— 执行分片。

这将是一次轻松的谈话。我知道大家已经听了一整天的复杂概念，所以我会尽量让这次讨论尽可能实用。我为这次演讲准备了合适的幻灯片设计。

对于不了解我的人，有趣的是，我在 Twitter 上被称为动漫女孩。我也为了来这里而错过了大学毕业典礼，这让我的父母非常不满。目前，我是 Argus Labs 的创始人。我们认为自己是一家游戏公司，而不是基础设施或加密货币公司。我最大的烦恼之一是，所有在加密游戏领域的人都想要构建工具，但没有人想要创造内容或应用。我们需要更多用户可以实际使用的应用。

之前，我和我的聪明朋友 Brian Gu (@gubsheep) 和 Alan Luo (@alanluo_0) 共同创造了 Dark Forest (@darkforest_eth)。Brian 现在正在运营 0xPARC (@0xPARC)，他比我聪明很多。

今天的讨论将集中在执行分片，但在一个大多数人对执行分片的讨论不熟悉的背景下。我们通常在 Layer1，如以太坊分片或 Near 分片的背景下讨论执行分片。但今天，我想改变一下背景。让我们思考一下在 roll-up 环境中分片会是什么样子。

这里的基本问题是，为什么一个游戏公司要构建自己的 roll-up，以及我们可以从《魔兽世界》中学到什么来设计 roll-ups。此外，我们将探讨 roll-ups 的设计空间如何远远超越当前的现实。

为了回答这些问题，让我们回到 2020 年，当时 Dark Forest 的想法首次被构想出来。我们问自己，如果我们创建一个每一个游戏动作都是链上交易的游戏，会怎样？那时候这个前提是荒谬的，对今天的许多人来说仍然是如此。但这是一个有趣的假设，所以我们构建了它，Dark Forest 就这样诞生了。

Dark Forest 是一个完全基于以太坊的全链空间探索 MMORTS 游戏，由 ZK-Snarks 驱动。回到 2020 年，ZK 并不像今天这样流行，因为几乎没有任何文档。Circom 的唯一可用文档是 Jordi Baylina's (@jbaylina) 的 Google Docs。尽管面临挑战，但我们从过程中学到了很多，Dark Forest 就是这些学习的体现。

Dark Forest 是一个比我们想象中更大的实验。我们有超过 10,000 名玩家，花费了数万亿的 gas，游戏中充满了混乱，人们在链上背后捅刀。关于 Dark Forest 和链上游戏最吸引人的事情是平台化的本质。通过拥有一个全链游戏，你打开了为新兴行为设计空间的大门，允许人们构建与游戏交互的智能合约，以及替代客户端和游戏模式，例如 Dark Forest Arena 和 GPU 矿工。

然而，伴随着巨大的力量，也有巨大的责任。当我们在现在被称为 Gnosis Chain 的 xDai 上启动 Dark Forest 时，我们最终填满了链的整个区块空间。这使得链对于其他任何事情，包括 DeFi、NFTs 或任何其他 xDAI 的事情，基本上都无法使用。

那么，现在怎么办？我们是不是到了死胡同？全链游戏永远不会成为现实吗？或者我们是否要回到制作只有 JPEG 小图片在链上的游戏，并说服人们钱是从树上长出来的？答案是，我们让软件做事情。我们中的许多人对区块链和 roll-ups 的看法非常僵化，好像没有太多的改进空间。但我不同意。我们可以进行实验，找出新的可能性。

我们问自己一个问题：如果我们要从头开始为游戏且只为游戏设计一个区块链，它会是什么样子？我们需要高吞吐量，所以需要扩展读写。大多数区块链都设计成进行大量的写入。每秒交易数 TPS 是人们吹嘘的指标，但实际上，读取同样重要。如果你不能从区块链节点读取，你怎么知道玩家的位置呢？这实际上是我们在区块链构建中发现的第一个瓶颈。

Dark Forest 遇到了一个问题，即全节点被大量使用，I/O 爆炸，因为我们需要从链上状态读取数据。这导致了数千美元的服务器成本，这些成本由 xDAI 团队慷慨地为我们承担。然而，这对长期来说并不理想。我们需要高吞吐量，不仅对于每秒写入的交易，也对于读取，比如从区块链本身获取数据。

我们还需要一个水平可扩展的区块链，以避免 Noisy Neighbor 问题。我们不希望一个受欢迎的游戏突然开始在区块链上出问题，停止所有的工作。我们还需要灵活性和可定制性，以便我们可以修改状态机，使其为游戏设计。这包括有一个游戏循环，使其自我执行等等。

最后但并非最不重要的是，对于那些不熟悉在线游戏架构的人来说，这可能有些模糊，我们需要高 tick rate。Ticks 是游戏世界中的时间原子单位。在区块链的背景下，我们有区块作为时间的原子单位。在游戏中，我们有 ticks。这在你构建一个全链游戏时几乎是类似的，其中你的区块链的 tick 或区块产生的速度等于游戏本身的 tick。

所以，我们需要的是一个高吞吐量、水平可扩展、灵活可定制，并且具有高 tick rate 的区块链。这样的设计，才能满足我们为游戏从头开始设计的区块链的需求。

如果你有更高的 tick rate 或每秒更多的区块，游戏会感觉更加反应灵敏。相反，如果你的 tick rate 较低，游戏会感觉更加迟钝。需要记住的一件关键事情是，如果区块产生延迟，你会在游戏中感觉到明显的延迟。这是一种糟糕的体验。如果你曾经处理过因为输掉游戏而对着电脑大喊大叫的愤怒玩家，那是一种绝对糟糕的情况。

目前，我们的 rollups 每秒有一个区块，相当于一次 tick。如果我们想要有更酷的游戏，我们需要更高的 tick rate。例如，Minecraft，一个简单的像素艺术游戏，每秒有 26 次 tick。我们还有很长的路要走，才能建立出像 Minecraft 那样反应灵敏的游戏。

一个可能的解决方案是部署我们自己的 rollup。虽然表面上看起来解决了问题，但实际上并没有解决问题的根本原因。例如，你会有更高的写入吞吐量，但并不完全达到游戏需要的水平。当然，如果你的游戏有一百个玩家，这将是足够的。但是，如果你想要构建需要更高吞吐量的游戏，由于当前构建中的 I/O 方式，会有非常严格的限制。

在读取方面，你并没有真正得到性能的提升。你仍然需要依赖索引器。你并没有真正的水平可扩展性。如果你试图启动一个新的 rollup 来水平扩展你的游戏，你就会破坏你现有的智能合约生态系统。玩家部署的市场将无法与你为了水平扩展游戏而启动的其他链进行工作。这会引发很多问题。

最后，高 tick rate 和每秒区块数还是有点难度的，虽然我们可以尽力推动它，我们可能会得到每秒两个区块，也许三个，但这真的是这些区块链能走的最远的地方，因为有一堆像 re-marshalling 这样的事情非常依赖计算周期。

为了解决这个问题，我们回顾了 21 世纪初和 20 世纪 90 年代末，像 MMOs 这样的在线游戏刚刚兴起的时候。他们有一个叫做分片的概念。这不是一个新的概念；它在过去已经存在。我们在数据库架构中使用的 "分片" 这个词实际上来自于 Ultima Online 的引用。他们最早使用 "分片" 这个词来解释他们的不同服务器。

那么，游戏中的分片是如何工作的呢？它不是一种一刀切的解决方案。它是工具箱中的一个工具，你如何将它适应到你的游戏中，取决于具体情况的不同。例如，第一个分片构造是我喜欢称之为基于位置的分片。一个很好的思维模型是想象一个笛卡尔坐标系被分割成四个象限，每个象限都有自己的游戏分片。每次你想要穿越一个分片，你都要向另一个分片发送一个通信，说 "嘿，我想要移动到那里"，然后你被传送到你的分片，留下你之前的玩家身体。通过这样做，你将服务器的工作负载分配到多个物理实例，而不是强迫一个服务器为整个游戏世界做所有的计算。第二种构造现在更受欢迎。它被称为多宇宙分片，你有多个游戏实例与彼此镜像。你可以选择你想要去的任何分片，它默认是负载均衡的，这样每个服务器都不会过于拥挤。

现在，关键的问题是，如何将这个概念带入 rollup？这就是为什么我们创建了 World Engine。World Engine 是我们的旗舰基础设施，基本上是一个为启动设计的有主见的分片排序器。与我们在过去几次讨论中看到的许多分片排序器设计相比，我们的设计不同，更适合我们的需求。我们优化的方向是：A，吞吐量，B，我们要确保没有锁阻止运行时间，以确保 tick rate 和区块时间尽可能高效，所以它默认是同步的，我们设计排序器的方式是部分排序，而不是强制总排序（每个交易需要在另一个交易之后发生）。

这里的关键组成部分是，我们有两个主要的东西。我们有基于 EVM 的分片，它就像一个纯粹的 EVM 链，玩家可以在上面部署智能合约，与游戏组合，创建带有税收的市场等等。它就像一个正常的链，对吧？像每秒一个区块或一件事，只是足够你做所有你的典型设备和市场的东西。

这里的秘密成分是，我们还使用一个游戏分片，它本质上是一个设计成高性能游戏服务器的迷你区块链。我们有一个 bring-your-own-implementation 接口，这样你可以根据你的喜好定制这个分片。你可以构建你自己的分片，注入到基础分片中。你只需要实现一套标准的接口，就像你熟悉的 Cosmos，Cosmos 有一个 ABC 接口。你基本上可以将这个整合成一个类似的规范，将你自己的分片带到 World Engine 堆栈中。

这里的关键是，我们有一个高 tick rate，我们目前无法用当前的分片构造实现。这就是我想要介绍 Cardinal 的地方。Cardinal 是 World Engine 的第一个游戏分片实现。它使用实体 – 组件 – 系统（ECS），具有面向数据的架构。这允许我们并行化游戏，并提高游戏计算的吞吐量。它有一个可配置的 tick rate，最高可达每秒 20 次 tick。对于这里的区块链人来说，那就是每秒 20 个区块。

我们还可以将其地理定位，以减少延迟。比如，你可能有在美国的排序器，然后亚洲人必须等待 300 毫秒的延迟，才能让 transaction 到达排序器。这在游戏中是一个巨大的问题，因为 300 毫秒是很长的时间。如果你试图玩一个有 200 毫秒延迟的 FPS 游戏，那基本上就是，你已经死了。

另一个对我们来说也很重要的关键点是，它是自我索引的。我们不再需要外部索引器。我们不需要这些框架来缓存游戏状态。这也使我们能够构建更多的实时游戏，不会因为索引器仍然在试图赶上排序器区块而有延迟问题。

我们还有一个插件系统，允许人们并行化 ZK 验证等。最好的部分，至少对我来说，是你可以用 Go 编写你的代码。不再需要用 Solidity 来让你的游戏工作。如果你曾经试图用 Solidity 构建一个区块链游戏，那简直是一场噩梦。

但是，我们的分片构造的关键点是，你可以构建任何东西作为分片。它们就像基本上是一个无限的设计空间，像一个分片可以是什么。

假设你并不喜欢用 Go 编写你的游戏代码，那你完全可以选择其他方式。不过，我们正在研发一种可以让你用 Solidity 实现游戏的 Solidity 游戏分片，这种方式在保留 Cardinal 的许多优点的同时，也提供了代码编写的可能性。你还可以创建一个具有独特内存池和排序构造的 NFT 铸造分片，解决类似于基本铸造的 Noisy Neighbor 问题。你甚至可以创建一个游戏身份分片，用 NFT 表示你的游戏身份，这样你可以轻松地通过 NFT 而不是分享私钥的方式进行游戏身份交易。

这是一个高级架构，今天由于时间关系我不会讲过多深入的细节。关键是，我们允许 EVM 智能合约通过使用自定义的挑选和传递（pick and pass）与游戏分片进行组合。我们围绕 Geth 创建了一个 wrapper，允许它们之间进行通信，这在双向上打开了大量的设计空间。我们默认是同步的，并且可以在分片之间无缝可组合地进行互操作，而无需锁定。

我们的共享排序器与众不同，因为它不使用优先考虑全局排序的原子束的共享序列构造，这需要一个锁定机制，并导致了像阻塞主线程这样的问题，从而导致不稳定的 tick rate 和区块时间，结果就是游戏出现延迟。它还对每个分片的区块时间进行了限制，并需要各种加密经济学和构造来防止服务拒绝。还有一个我在许多 VCR 排序器构造中没有看到提到的大问题：如果你有不同的分片互相依赖并造成死锁，你应该如何解决呢？通过异步设计，这都不是问题，因为每个人都在做他们想做的事情，然后放下不管。

事实上，跨分片的原子束和 roll-ups 通常并不必要。对于我们的使用案例，我们不需要任何需要原子束的东西，我们也不认为这是我们应该围绕使用案例纯度来设计我们的 Roll-Ups 的东西。这也带来了许多其他有趣的特性。例如，每个游戏分片可以有一个单独的 DA 层用于基链。例如，你可以使用基础分片将数据推送到以太坊，游戏分片可以将数据推送到的 Celestia（类似数据可用性委员会）。你还可以减少运行全节点的硬件需求，因为你可以单独运行基础分片 Geth 全节点，而无需运行游戏分片节点，这使得你更容易与 Alchemy 等事物集成。

总结一下，我想在这里坦诚地说，很多人都希望他们的构造能解决所有的问题，但我们并非如此。我们认为我们的构造对我们有用，但可能对你的使用案例并不适用。假设我们的构造可以适用于所有人是不现实的。对我们来说，它符合我们的需求，提供了高吞吐量、水平可扩展性、灵活性和高 tick rate，但它并不能治愈癌症。如果你需要一个需要同步可组合性的 DeFi 协议，那么这种构造可能不适合你。

总的来说，我真心相信人本（human-centric）区块链架构的概念。通过围绕特定的用户角色和使用案例进行设计，你可以更好地进行权衡，而不是试图解决所有人的问题。文艺复兴时代已经到来，每个人都可以设计自己的 Roll-Ups 来满足自己的特定需求，而不是依赖通用的解决方案。我认为我们应该拥抱寒武纪大爆发。不要像 one-size-fits-all 的 layer one 那样构建 roll-ups，因为它根本就没有用来解决同样的问题。我个人很期待看到更多的人探索更多的 Roll-Up 设计空间，这些设计空间是针对使用案例的。例如，一个专门为资产交换设计的 Roll-Up 会是什么样子？它会基于意图吗？一个专门为链上 CLOBs（中央限价订单薄）设计的 Roll-Up 会是什么样子？在此，我将麦克风交给 MJ。感谢你的邀请。

English Version: