让全链游戏开发在闪电网络上的成为现实

作者：Infinitas

引入

“全链游戏指完全在区块链上运行的游戏和 NFT 生态集合体，吸引着各路游戏巨头和投资机构的纷纷布局和尝试。”当前全链游戏在保证安全性、隐私性和去中心化的基础上，可扩展性始终没有找到最优解决方案。例如最热门的全链游戏引擎 Mud 和 Dojo，致力于帮助全链游戏实现更高的 TPS，但玩家每次操作仍需要 2 秒以上的缓冲。事实上，当前区块链上最高 TPS 的全链游戏可实现峰值在几千 TPS左右，与数十万级 TPS 的传统 Web2 3A 游戏存在巨大差距。在追求不损失区块链优势的前提下，全链游戏以克服的可扩展性。

所以“全链游戏之春” 终究无法实现吗？未必。本文由区块链底层基础设施项目 Infinitas 与游戏平台 CrystalFun合作，以其旗下Outerverse 原生4款游戏为例子，探讨比特币生态如何让全链游戏的落地和大规模普及成为可能。

By: Infinitas | CrystalFun

Author : echo | https://twitter.com/echoindahouse

闪电网络和RGB协议如何帮助解决全链游戏困境？

在全链游戏中，游戏的核心逻辑、规则和游戏内交互过程完全在区块链上（fully on-chain），通过智能合约实现规则的执行和验证。游戏资产和虚拟物品也以区块链的形式存在，玩家可以直接拥有、交易和转移这些资产，而无需依赖传统游戏公司的中心化服务器。游戏核心逻辑和游戏内资产的完全去中心化为玩家赋予更高的自主权和安全性。

闪电网络作为建立在比特币区块链网络之上的第 2 层扩展解决方案，通过将交易移至链外，扩展了链上游戏的设计空间，同时保留区块链的底层安全性和透明度，从而实现快速、廉价的交易。

闪电网络有助于在平衡区块链三角去中心化和可扩展性前提下，将游戏扩展到更多用户和使用范围。借助闪电网络进行全链游戏开发可以更好实现游戏内交易速度提升，改善游戏内用户体验。

但即使闪电网络解决了可扩展性问题，一些核心游戏逻辑仍然需要在链上进行，例如将不可变记录的最终结果或状态更改写入智能合约。闪电网络还未解决智能合约的问题，因此，闪电网络只是链上交互的补充，而不是完全替代。

RGB 则是在比特币生态系统第 2 层和第 3 层上运行的客户端验证状态和智能合约系统。抽象的来讲，RGB 在比特币区块链的基础上建立了一个由用户自管的合约管理系统，用户自行验证和执行状态变更，包括资产和合约。当用户发起交易并调用一个合约逻辑时，合约执行和资产状态的变更并不会全网共识，而是在交易双方之间验证并达成共识即可实现交易。

通过与闪电网络配合使用，RGB 协议在比特币交易链之上运行，但无比特币时间链拥塞的问题：交易仅保留相同状态承诺，无需额外链上存储。无论是来自比特币区块链还是闪电通道（或任何其他类型的状态通道），RGB 都可以在比特币之上作为第 2 层解决方案工作，也可以在闪电网络之上作为第 3 层解决方案工作。

助力全链游戏辅助工具

区块链本身作为一个链上资源珍贵的状态机，很难去单独处理游戏这类高频互动场景下的冗余调用需求。所以除了结合比特币二层闪电网络，要使游戏真正运行起来，还需要将游戏逻辑和资产写在比特币生态智能合约中，因此一些补充链上交互的辅助的技术栈和工具必不可少。

Ephemeral chain（临时链）

临时区块链可以定义为不会永远存在的区块链，一旦区块链的目的实现（例如记录交易），或者一旦其状态永久存储在其他地方，它们就会被销毁。临时链存储的终止状态只是有关临时链相关终止事实的数据，因此将所有内容压缩了相当大的数量级。临时链主要受区块链上交易延迟和吞吐量限制。

临时链 VS 状态通道

就临时链而言，由于公共链上有状态，我们最终将拥有大量用户。需要插入公链的状态会通过剪枝/压缩/差异提取来减小大小，然后定期而不是不定期地保存在公链上。RGB 状态通道的设置有可能绕过临时链的性能约束，实现和临时链相同的功能。

状态通道迄今为止是为少数用户设计的。最值得注意的是，状态通道主要用于两个用户之间同时进行大量的链下交易而构建的。每个 RGB 智能合约由智能合约发行者（或者简单地说，发行者）创建，和以客户端验证形式保存的数据共同以“创世状态”存储在区块链上或闪电网络交易/通道状态内。该状态被称为“给未使用的比特币交易输出”（Unspent Bitcoin Transaction Outputs，简称 UTXO），过程被称作“一次性密封”。RGB 协议状态转换过程将状态分配给一组已定义的一次性密封件。每个智能合约可以维护不同形式的状态，并使用不同的验证规则定义不同类型的一次性密封件。除此之外，状态转换可能包含不同的元数据和脚本，这也是业务逻辑的一部分。

App-specific blockchains（特定应用程序区块链）

特定于应用程序的区块链是为运行单个去中心化应用程序（dapp）而创建的区块链。开发人员不是在现有区块链上构建，而是使用自定义虚拟机 (VM) 从头开始构建新的区块链，该虚拟机执行用户与应用程序交互的交易。开发人员还可以定制区块链网络堆栈的不同元素——共识、网络和执行——以满足特定的设计要求。提升智能合约执行速度，解决计算资源限制可以帮助特定应用程序区块链落地。允许开发人员为不同的用例定制基础设施，使开发变得更容易。同时允许 web3 开发人员构建强大的价值模型并扩展其 dapp 以满足指数级增长的需求，激发更多创新。

特定应用程序区块链 VS 比特币二层模具 “schema”

RGB 中有一个叫做 RGB Schema 的东西，它是一组定义合约状态如何随时间演变的规则。但与以太坊或任何基于区块链的智能合约平台不同，Schema 需要对操作算法进行编程。

状态转换中允许哪些类型的状态、密封、元数据以及哪些脚本扩展由“schema”定义。schema可以看作是客户端验证的验证规则；模式始终由发行者在状态起源中定义，包含图灵完备的脚本，为客户端验证定义部分业务逻辑。

来源：Infinitas 架构图

如图，左边箭头表示少数用户可以自建节点直接访问智能合约。右侧箭头是商业化节点，采用云计算技术保证安全可靠的运行，帮助用户管理大量链下智能合约计算数据及合约计算验证。

所有合约的业务逻辑和合约代码都存放在“schema”中，合约部署或项目方不需要自己写代码，只需要使用合适的“schema”进行参数配置，就可以发布合约；开发人员使用合适的模具为不同的用例定制基础设施，使开发变得更容易，实现和特定应用程序区块链相同的功能。

Battle rollup（战斗 Rollup）

战斗 Rollup 作为一种技术机制，主要用于简化全链游戏中的对战过程。通过将玩家之间的战斗行为批量处理后汇总到一个区块中，战斗 Rollup 可以减少交易的数量和成本，提高全链游戏的性能和可玩性。我们可以把玩家的好几个位移动作之后的总结果打包汇总到区块中，而不是每一步都记录进去。战斗 Rollup 主要受区块链上交易成本和区块链处理速度限制。

闪电网络帮助完成战斗 Rollup “打包”

• 可扩展性：闪电网络每秒能处理数百万至数十亿笔交易。容量比传统链上支付方式超出了许多数量级。现在可以在没有托管人的情况下为每次操作/点击附加付款。

• 低成本：通过区块链外的交易和结算，闪电网络可以收取极低的费用，从而可以实现即时小额支付等新兴用例。

Engine for On-Chain Games（全链游戏引擎）

全链游戏引擎是专门为全链游戏开发的引擎工具。它提供了一套开发框架和工具，帮助开发者在区块链上构建游戏逻辑和交互功能。更加通用的智能合约编程语言和开发工具帮助开发者进行全链游戏引擎开发。

第一个为 ETH 生态提供支持的是由 Lattice 推出的 MUD 引擎，随后，逐渐出现支持不同生态，使用不同编程语言的全链游戏引擎，如用于 starkware 的 DojoEngine。以 MUD 和 Dojo 为代表的全链游戏引擎简化了开发过程，提供了丰富的功能库和工具，使开发者能够更高效地创建全链游戏。

RGB “Contract Schema” 降低开发者门槛

在当前的智能合约世界中，要求智能合约创建者（发行资产的公司、DAO、DeFi 工程师团队）组织或自行执行智能合约代码的开发是很常见的。

这种开发组织方式最大的弊端是：导致更高的合约代码漏洞和多次黑客攻击。由于合同发布者不一定是经验丰富的开发人员，且发布每份合约时无法要求外包公司从头编写智能合约并对其结果进行审计。因此合约程序员和合约发行者的角色必须分开。RGB 引入“Contract Schema” 合约模式概念。合约模式是智能合约的实际代码，发行者可以将其用作“合约模板”，而无需他们对某个随机外包商为其编写的定制代码进行编码或审核。这样的设计大大简化开发者开发和维护智能合约的门槛。

Synchronization（同步机制）

另一个关注点是将链上状态与游戏状态同步。这对于确保游戏和交易的完整性非常重要。如果操作不当，可能会导致用户资产数据泄露、重复项目或各种其他问题。因此每一步交易顺序和交易时间的确认都至关重要。

举个例子，我们想象一个场景，有两个玩家，玩家 A 和玩家 B。玩家 A 想要用 20 倍的 DNA（某游戏内代币）交换玩家 B 的武器剑（以 NFT 表示）。链上和链下同步的示例如下：

1. 玩家A和玩家B同意交易20x DNA 以获得游戏中的武器剑

2. 交易在链上开始，数字资产被发布到链上托管合约

3. 游戏查询链上数据以了解活动情况

4. 游戏状态根据链上活动而改变

5. 管理游戏活动，在链下数据库中更新项目，并且交易出现在每个玩家的游戏帐户中

6. 托管合约将链上数字资产释放到玩家A和玩家B各自的钱包中

闪电网络实现交易同步性

闪电网络的同步性是通过使用交易的锁定机制来实现的。当两个节点之间建立了一个链下的支付通道时，它们可以在通道中进行多次交易，而不必每次都向区块链提交交易。这些交易被锁定在通道中，直到通道被关闭，交易结果被上传至链上。这种锁定机制确保了交易的同步性，无需担心区块确认时间，支付速度以毫秒到秒为单位。

通过上述针对全链游戏辅助工具：临时链、特定应用程序区块链、战斗 Rollup、全链游戏引擎、同步机制的不同角度深入探讨后，为了便于大家更好地畅想和理解，我们将继续分享Outerverse在Infinitas底层构建及体系结构中的多方面应用场景案例。

Outerverse

OUTERVERSE是Crystal Labs推出的以开放世界星战题材的大型多人在线角色扮演游戏（Massive Multiplayer Online Role-Playing Game，简称 MMORPG）《OUTER》为核心的一系列游戏的组合生态。旗下总共包含4款不同品类的游戏，分别是主游戏《OUTER》，外传游戏《OUTER：StarFall 2312》，衍生游戏《OUTER：Survivor》和《OUTER：Endless War》。

这 4 款游戏的背景设定将发生在同一个世界观体系下并且游戏之间经济生态也将打通。开发者希望通过不同品类的游戏来吸引不同喜好的游戏玩家。让我们一起从这 4 款不同类型的区块链游戏中，展望一下未来全链游戏在比特币生态中的解决方案。

OUTER

OUTER是一款太空星战题材的 MMORPG。在 MMORPG 中存在大量的战斗过程，而这些战斗都需要实时演算：比如A对B发起攻击，则B在受到攻击的瞬间就要反馈出受到的伤害值。这些运算过程极为复杂，需要从游戏角色上读取大量参数进行运算从获得实时的战斗结果。

传统web2游戏为了提高运算效率，会将整体运算在中心化服务器中进行，这种方案确实提高了运算效率，但对运算的安全性和透明度并没有保证。玩家只能默认官方的服务器不会出错或者无法作恶。

如在OUTER中玩家A和B两艘飞船遭遇战时，需要获取双方飞船十多个战斗属性。如飞船的生命值、火力、装甲、穿透等。对这些属性进行运算最终得到双方飞船在这场战斗中产生的伤害和各自飞船的损失。最终将受到损失后的飞船状态记录到中心化数据库中。

我们来简化一下游戏中战斗模型：“A和B发生战斗，A对B能产生x点伤害，B受到伤害后还剩y点血量”。我们可以看到，x是一个中间值，需要通过实时运算产生，y是运算之后产生的结果值，需要回写到游戏数据中。在传统web2游戏中，x值的计算过程是在中心化服务器中内存中进行，计算完毕后生成y值，然后将y值回写到服务器的数据库中。

而如果将OUTER中实时运算的部分运用闪电网络，此时游戏中需要实时运算过程我们通过闪电网络运算后即可产生x值，即A对B产生的伤害值。然后得到的最终结果y值写入链上。采用类似“链下计算+链上账本”的结合的方式，可以实现一些在链上速度太慢或成本太高的游戏机制。这样既保留底层区块链的安全性和透明度，又在不牺牲去中心化的情况下将游戏扩展到更多用户和使用范围。

另外，对于OUTER这种大型多人在线游戏，由于游戏生态的复杂性和道具的多样性，玩家之间的交易也将是非常频繁（如OUTER中存在近千种不同的道具）。而比特币闪电网络的结算性能，也许是MMO区块链游戏玩家之间支付结算的很好解决方式。

STARFALL 2312

我们再来看OUTERVERSE旗下的第二款游戏STARFALL 2312，这是一款卡牌RTS区块链游戏。与OUTER这种大型多人在线游戏类型不同，STARFALL是一款单局匹配竞技玩法的游戏。无论是1vs1或者2vs2，玩家都是匹配后进入到单局内战斗，类似于《星际争霸》。单局竞技类游戏对即时演算和多人在线负载的要求不高，反而对游戏的反作弊有着极强的要求。

从早期的局域网匹配到现在的战网匹配，竞技类游戏作弊一直是个长期的痛点。想象一下，你还在老家采矿发展科技建造机枪兵，而对手已经舰船打炮成型，杀的你根本没有一点招架之力。而此时你最想知道的一定是对手是否开启外挂作弊。很多玩家在玩竞技游戏后有观看replay录像的习惯，而replay的原理即为将玩家在战局中的操作全部打包记录到文件中，再通过客户端进行还原。但很多replay都是本地文件，基本无法确保透明性和不可篡改性。

Synchronization（同步机制）是确保玩家之间操作和状态的一致性的重要机制。同步机制可以借助区块链和智能合约来确保玩家之间的操作和状态的同步，并保证游戏的公正性和可信度。如果将玩家的每一步在游戏中的操作都可以写入链上存储，这样即可确保任何玩家所有的操作都是公开透明并且可溯源的。这也许是解决竞技类游戏的反作弊问题的一个方案。

Survivor

Survivor是OUTERVERSE旗下星际Roguelike割草类区块链游戏。这是一款轻度单人休闲游戏，玩家只需10秒即可上手游戏。玩家对该类型的游戏最大的诉求就是操作简单和爽快。当玩家冒险开始时，驾驶的飞船会被加载进一个预设的关卡中进行闯关冒险。若让这部分游戏内容可以做到去中心化上链，智能合约中的预编译器（App-specific precompile）或许是个不错的选择。

预编译器类似传统游戏中的“预加载”原理，通俗来说就是提前把资源做好，需要时读取。针对特定应用场景而设计的智能合约预编译器，在全链游戏中提供特定功能和计算能力。通过提前设计关卡资源，在实时游戏过程中读取，从而加快游戏逻辑的执行速度和降低交易成本，为全链游戏带来了更高的可扩展性和效率。

Endless War

Endless War是OUTERVERSE旗下的全链游戏。玩家将从某个星球上开始，利用现有的资源发展经济和科技，打造属于自己的舰队，对外星系发起殖民获得收益。玩家在游戏中的战斗的过程是组建自己的舰队进行战斗，所有的战斗都会发生在链上。Battle rollup技术可用于简化游戏中的对战过程：通过将玩家之间的战斗行为批量处理并汇总到一个区块中，战斗 Rollup 可以减少交易的数量和成本，提高游戏的性能和可玩性。

全链游戏在BTC生态落地的其他挑战

用户 Onboarding

由于游戏完全在链上，游戏者很可能不得不为每一个游戏中的行动的弹出窗口签名，这将使得用户体验很糟糕。更安全的钱包解决这个问题的最简办法，但存在潜在的安全隐患。目前的游戏开发者并不希望玩家在他们的钱包中持有高价值的物品。但随着越来越多的玩家涌入，全链游戏钱包问题迟早得解决。

在未来，全链游戏可能会与账户抽象等技术相结合，例如批量交易处理、签名和委托签名等能力。这意味着游戏中的一些常规操作，如游戏中接下来的20步不需要签名或可以使用委托签名来简化。这种整合将为游戏带来更高效的交互和操作体验。

另一个方面是开发人员的 onboarding，以鼓励和吸引游戏改装者贡献和扩展游戏，这会增加游戏中自主世界的价值。这主要是通过为开发者提供适当的工具，以及给予开发者适当的激励来实现的。

经济变现

RGB 对客户端验证规则的社会共识还可以确保资产的每个其他所有者都将应用相同的验证规则——每个资产/状态验证规则都是由 Schema 在创世级别定义的，这意味着资产的每个进一步所有者仍然使用相同的 Schema 来验证历史记录。因此，这里的Schema 实际上是保证验证上共识，分发激励的手段。

随着 RGB 经济激励的推动，全链游戏内经济激励将会变得更加清晰。采用社会化共识，通过 token 代币投票的方式选举出最优秀的 schema，项目方进行支付，授权使用，Schema 项目方获得分成。更清晰的激励机制还将有助于提升全链游戏开发质量，确保玩家在游戏中获得乐趣。

结语      

RGB 架构的设计深刻地重新定义了共识规则，为新时代的区块链生态注入了强大的动力。在这一创新的共识框架下，RGB 实现了卓越的执行效率和卓越的隐私性，成功突破了传统的不可能三角困境。这一突破性设计不仅为区块链技术带来了质的飞跃，同时也为全链游戏的大规模普及创造了理想的条件。更为引人注目的是，RGB 扩展方案的推出不仅将 RGB 架构与闪电网络相融合，还为开发者提供了更为便利的工具、轻客户端以及全新的BTC生态经济模型。这一综合性的扩展方案使得 RGB 不仅仅是一项技术创新，更是一项全面的去中心化基础设施的升级。在这一优化之下，受阻于以太坊的全链游戏有望在比特币生态体系中找到新的蓬勃发展的机遇。

这种融合将为全链游戏的未来发展打开崭新的篇章，带来更多应用形态和商业模式的可能性。因此，我们对 RGB 架构及其扩展方案充满信心，相信其将为区块链行业带来深远的影响，推动全链游戏走向更加繁荣的未来。

参考

https://www.rgbfaq.com/faq/what-is-rgb

https://www.kaleido.io/blockchain-blog/web3-gaming-on-and-off-chain-considerations

https://www.infura.io/blog/post/the-benefits-and-tradeoffs-of-application-specific-blockchainshttps://medium.com/hackernoon/ephemeral-%C2%B5blockchains-the-mayflies-tackling-data-storage-limitations-on-the-blockchain-f38bfdad51b