作者：5p0rt5BEArD

翻译：MetaCat

排版：MetaCat

Playerchain 是一种游戏客户端架构，它整合了网络代码，用于形成点对点多人游戏会话，这些会话使用共识而不是服务器进行协调。会话共识建立在每个玩家维护的不可变历史记录之上。这些个人区块链以有向无环图（DAG）结构连接，并在会话之间持续存在，从而实现以玩家为中心、持久且相互关联的游戏世界。

构成 Playerchain 客户端的核心元素。 

游戏代码（图中的绿色块）遵循现有点对点多人游戏的熟悉模式：在每个客户端上运行确定性模拟，并通过网络共享玩家输入。

就输入达成一致是共识的工作（图中蓝色方块）。只要所有玩家都同意彼此输入的顺序和时间，那么游戏就会完美地复制给每个人。

只要存在核心要素，共识的实施就是游戏特定的：单个玩家区块链连接在一起形成一个区块链，从而产生完全有序的输入。本文重点介绍尽可能快速的最终性方法，但其他共识方法也是可行的，并且需要做出权衡。

我们的 Playerchain Demo [8]要求快速达成共识。请在 Github 上试玩并查看源代码。

https://github.com/playmint/playerchain-demo?tab=readme-ov-file#-

太空射击游戏等游戏类型需要尽可能快速的终结性，因为玩家必须快速对彼此的动作做出反应，而动作的纠正会对玩家的世界观产生很大影响。我们为演示应用程序选择了一款太空射击游戏，因此我们可以展示一个玩家链如何与要求最高的游戏类型配合使用。

许可组形成

任何人都可以创建 Playerchain ，但 Playerchain 的访问由群组控制。

在 Playerchain 会话开始之前，参与者必须找到彼此并共享一个密钥，以确保他们的群组是私密的。快速共识依赖于已知的固定群组，而不是基于时间或金钱的安全性，这会减慢无权限链上的共识速度。

单人区块链

每个输入都包含在其自己的区块结构中，该结构通过其哈希引用前一个区块，从而形成该玩家输入的不可变区块链。对于我们的快速最终性方法，每个时间段都会创建一个区块，因此区块还必须指示是否没有输入。这让其他玩家知道等待输入和没有输入需要等待之间的区别。

形成 Blocklace

Playerchain 中形成的 DAG 结构是一种区块链[1]；一种适合应用多种共识的 CRDT。Cordial Miners [2]协议提出了各种关于区块链共识的算法。 

每个玩家通过向当前 Playerchain 组中的所有对等点发送包含其最新区块的签名消息，来共享他们自己的区块链。

玩家将自己的链与远程玩家共享的链结合在一起。

当玩家分享自己的区块链时，他们也会分享对彼此区块的引用。根据 Cordial Miners [2] 论文中列出的传播算法，形成了一个区块结构。区块按轮次分组，在当前轮次收到三分之二的对等方的区块之前，无法开始新的区块。 

游戏特定的 Blocklace 形成将 DAG 轮次与游戏滴答相匹配。

为了使 Playerchain 游戏尽可能快速地完成，每一轮都可以被视为与游戏的模拟周期相匹配。因此，每一轮都包含每个玩家在特定游戏帧上的输入或明确的“无输入”。

输入排序

Playerchain 可以预先确定总体顺序以加快速度。

通过将 Blocklace 轮数与刻数（ticks）匹配，客户端可以为他们的区块添加刻数。结合确定性玩家顺序，每个区块实际上都有一个预先确定的总顺序。这在分布式共识中并不常见，因为总顺序需要进一步的输入才能在算法上确定区块的顺序。对于 Blocklace，这可以使用 Cordial Miners [2] 的 Tau 排序算法来完成，该算法经过优化，可以减少确定性所需的轮数，但与预订相比，它总是会增加更多时间。

预订假设了诚实客户端的典型情况，并允许游戏在收到输入后立即显示输入，而不是等待进一步的输入以算法方式确认顺序。通过含糊其辞（告诉两个对等方两个不同的输入）或声明更早的输入来进行不诚实的攻击将导致重新模拟，但游戏将保持一致。

预测与回滚

有成熟的技术 [3][4][5][6]，如预测和回滚，可确保基于输入的多人游戏获得良好的游戏体验。在远程玩家到达之前预测他们的输入可以让游戏继续进行，而无需等待网络延迟。逻辑模拟继续运行，将本地玩家的实际输入与远程玩家的预测输入混合在一起。当远程玩家的输入与预测不同时，模拟将回滚到这些输入之前的状态，并使用正确的输入重播。允许更正预测输入的过去时间是“回滚窗口”。

Fightin' Words [4] 上的网络代码文章很好地演示了在格斗游戏中使用预测和回滚。

回滚后的重新模拟发生在单个渲染帧中。如果新输入没有影响本地玩家，他们可能不会注意到。如果新输入导致影响本地玩家的状态变化，他们可能会看到游戏实体突然移动、消失或出现。

在以下游戏中，这些副作用会更加严重：

• 玩家可能会相互互动； 

• 预测很难做出； 

• 微小的输入变化会对未来状态产生巨大影响。 
  
  

（这些都是太空射击游戏的特点）。 

可以通过限制回滚窗口来减少重新模拟。但如果回滚窗口时间已到且并非所有输入都已到达，游戏必须暂停或继续，然后忽略任何迟到的输入。

Playerchain 中的预测和回滚

预测和回滚可能由服务器支持的网络中的中继处理，但在 Playerchain 中，它必须通过共识来处理。回滚窗口的大小、暂停的决定以及要放弃的输入都必须可预测地完成。不同的游戏可以使用不同的算法。下面我们逐步介绍为太空射击游戏开发的尽可能快速的最终性共识算法：

以下圆形图表的要点

第 0 轮。小组分组

所有客户端在组队时都会被确定地分配一个玩家索引，因此可以预测每个未来区块的总体顺序。

第 1 轮。等待共识 

我们，本地玩家，已经输入了，但还没有收到其他输入。在收到至少一个其他玩家输入之前，无法生成其他块。（请参阅下面的调整，了解如何降低此暂停的可能性）。

第二轮。继续预测

我们已经收到了“远程 1”的第 1 轮输入。这获得了继续处理第 2 轮区块所需的三分之二多数票。请注意，任何未收到的区块都必须进行预测（虚线），在本例中被预测为“无输入”。

第三轮。回滚

我们收到了“远程 1”的第 2 轮输入，这是我们没有预测到的输入。游戏在下一个渲染帧之前从第 2 轮倒回并重新模拟。

第四轮。决赛

本地我们已经进入第 4 轮，因为我们有第 3 轮的三分之二的区块。现在第 1 轮已经完成，因为我们在上一轮中确认了足够的第 1 轮输入。第 1 轮收到的任何未来区块都将被忽略。

第五轮。输入丢失

我们终于收到了来自远程 2 的一些输入。第 1 轮和第 2 轮的输入被忽略，因为它们错过了回滚窗口。所有客户端（包括远程 2 客户端本身）都会出现这种情况，远程 2 客户端将丢弃自己的输入并重新模拟以保持同步。

每个对等体都会尝试以目标游戏滴答速率（tick rates）发送新块，因此按照上述步骤，只要所有对等体都在彼此的两个滴答（tick）内接收所有远程输入，那么游戏就会以每个人的目标帧速率运行。这是对网络的严格限制，因此需要对一些元素进行一些游戏特定的调整，尤其是获得最佳大小的回滚窗口。

调整回滚窗口

平衡回滚窗口是调整预测和回滚用户体验的关键部分。如果回滚窗口太短，落后的玩家不到三分之一，落后的玩家将丢失输入，体验不佳。如果落后超过三分之一，其他人将暂停游戏，等待至少三分之二的玩家赶上来。如果窗口太大，那么与预测不同的远程输入更有可能导致每个人的视图不流畅。平衡窗口必须考虑许多其他因素，并且并非 Playerchain 所独有。然而，增加区块链中的回滚窗口是一个新问题，我们通过交错轮次集来解决这个问题：

将集合引入到 blocklace 中以增加回滚窗口。

Blocklace 传播算法要求轮次均匀进行，要求每个对等方等待上一轮的三分之二被看到后再创建新的区块。这相当于一个小的两帧回滚窗口。

可以通过增加每个本地客户端可以进行的轮数来增加回滚窗口，但算法要求块等待上一轮的引用。我们通过引入交错的轮次集来进一步提前处理。当一组轮次正在等待时，下一组轮次可以继续，直到我们用完所有轮次（见上图）。

Ticks 比延迟更快

使用 Cordial Miners 传播的区块链形成不需要等待消息确认，因此对等节点可以不受延迟限制地发送区块，游戏可以以高于延迟的滴答速率（Tick Rate）运行。无需等待最后一条消息的确认，每个新输入都会与其他对等节点的最新已知输入的引用相结合，作为确认。 

将消息轮次与游戏滴答（Tick）相匹配，并设定固定帧速率，这样就可以设定任意滴答速率，包括每秒 30 甚至 60 个滴答（Tick）。在这些速率下，糟糕的网络条件会导致回滚窗口频繁被破坏，因此用户体验不佳，因为某些玩家输入会丢失或游戏会暂停。因此，对于设计为在临时网络环境中运行的 Playerchain 演示游戏，我们将滴答速率设置为每秒 10 个滴答 (Tick)（请注意，渲染通常为 60fps）。

全局 Blocklace

Playerchain Demo 专注于展示响应式多人游戏会话的尽可能快的共识。Tashi 共识网络 [9] 实现了类似的架构（实时游戏输入的 DAG 共识）作为临时侧链。作为侧链，可验证会话可以连接到公共区块链，这对于 Playerchain 会话也是如此。Playerchain 的愿景是它们也可以以自己的方式持久和连接，这是选择 Blocklace 结构的原因。

在 Playerchain Demo [8] 中，每个会话都会为每个玩家创建一个新的密钥对，该密钥对在结束时与区块链的任何记录一起被丢弃。通过引入在游戏之间持续存在的玩家身份，每个玩家的区块链及其上一次会话交互也可以被持久保存。当玩家加入新群组并玩新游戏时，会形成一个全局区块链，每个玩家都有一个跟踪其进度的部分视图。 

彩色补丁代表 Playerchain；这是各团体在玩游戏时同意共同进步的全局区块链的部分视图。

实际上，所有游戏中所有玩家历史记录的全局区块链都会遇到存储问题，以及从不断增长的历史记录中恢复状态的时间限制。这些问题在区块链世界中已经得到很好的解决，可以使用可证明状态检查点和内容可寻址存储等技术，但要使全局区块链成为现实，还有很多工作要做。

有了全局区块链，玩家和团体之间的信任就会随着他们之间的互动而建立起来。例如，来自同一游戏的两个 Playerchain 世界同意交易资源，因为他们可以验证彼此对区块链的部分看法。与公共区块链版本的状态不同，不存在单一的公共视图。全局状态来自许多以玩家为中心的部分观点。

为什么要使用 Playerchain？

所提出的架构允许多人游戏无需第三方基础设施即可运行。从成本或维护方便的角度来看，这可能很有用。然而，Playmint 开发 Playerchain 的主要原因是制作用于玩耍而不是投机的去中心化游戏。你可以在此处阅读更多关于我们的动机的信息[7]。

参考

[1] Blocklace：一种通用的、拜占庭容错的、无冲突的复制数据类型；Paulo Sérgio Almeida、Ehud Shapiro

https://arxiv.org/abs/2402.08068

[2] Cordial Miners：针对各种可能发生的情况快速而有效地达成共识；Idit Keidar、Oded Naor、Ouri Poupko、Ehud Shapiro ； 

https://arxiv.org/abs/2205.09174

[3] Photon Engine 的 Quantum；Exit Games

https://www.photonengine.com/quantum

[4]网络代码：解释格斗游戏如何使用基于延迟和回滚的网络代码；Infil，Fightin' Words

https://words.infil.net/w02-netcode.html

[5] 1500 Archers on a 28.8：帝国时代及其他时代的网络编程；Paul Bettner

https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond

[6] GGPO；回滚网络 SDK；pond3r

https://github.com/pond3r/ggpo

[7]为什么我们需要玩家链；5p0rt5BEArD

https://open.substack.com/pub/5p0rt5beard/p/why-we-need-playerchains?r=slids&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

[8] Playerchain 演示；Playmint 团队

https://github.com/playmint/playerchain-demo?tab=readme-ov-file#-

[9] Tashi 协议：适用于多人游戏的可行共识引擎；Bobby Bhatia、Ken Anderson、Steve Marshall、Sean Tedrow、Austin Bonander

https://docs.tashi.gg/developers/gaming-protocol-paper

原文链接：https://5p0rt5beard.substack.com/p/playerchain-architecture