Perun通道将登陆Nervos CKB

对Nervos上Perun项目的深入描述。

Perun渠道框架可以用于提高交易的可扩展性，并使众多用例得以实现。然而，朝着更高级用例（如支付网络、区块链互操作性或应用通道）的第一步是一个支付通道。PolyCrypt获得了Nervos的资助，以在CKB上实现Perun。在本文中，我们概述了我们将如何实现这一目标，可能实现的功能以及您如何能很快使用这些通道！我们很高兴将Perun通道扩展到Nervos，并相信我们可以在这个蓬勃发展的生态系统中引起巨大反响。

作者：Jan Bormet, Norbert Dzikowski 和 Marcel Kaiser

为什么选择支付通道？

本节旨在为UTXO基础链（特别是Nervos）中支付通道的用途和好处提供简要概述，然后我们将深入探讨如何在Nervos第1层上实现Perun。

为了保持Nervos优雅地阐述的类比，请想象一个神经系统，除了让交互更加顺畅的髓鞘涂层外，还有超导分子或纳米级金颗粒的增强。信息吞吐量（即交易量）的增加提高了整个系统的性能。

Perun的支付通道应建立在CKB上高效的离线交易处理基础之上。虽然支付通道已经可以在EVM兼容的Godwoken上可用并且可以在上面使用，但本项目的目标也是将它们引入到Nervos第1层区块链。这将以以下方式使主层受益：

成本效益：支付通道可以显著降低交易费用，因为只有最终结算会记录在区块链上。

瞬时交易：支付通道可以在参与方之间快速进行交易，因为他们不需要等待CKB的确认。

增强隐私性：通过在链外进行交易，支付通道可以帮助保护参与方的隐私。

通道的进一步演进（应用通道、虚拟通道网络、跨链通道）当然会在功能集上大大增加。这些好处使得CKB在未来将围绕支付更多的用例做好准备。

微支付：支付通道可以促进在线游戏、内容共享平台和社交媒体平台等应用中的微支付。

在线市场：支付通道可以通过允许买卖双方在无费用的情况下进行多笔交易来促进在线市场的交易。

支付网关：支付通道可以作为电子商务平台中的支付网关，实现用户无缝且成本效益高的支付。

以下部分将为您提供关于我们如何使Perun通道在Nervos上成为现实的更深刻理解。

实施

本次资助旨在将Perun支付通道与CKB集成。这将促进在Nervos上的快速和安全的支付结算。作为本次资助的一部分，我们将调整go-perun框架，以便在Nervos上的用户之间创建、处理、关闭和争议双端单资产支付通道。

协议规范

以下协议规范将概述如何利用CKB单元模型调整和实现支付通道的Perun协议。我们要注意的是，如果对于以下任何子问题有多个解决方案，可以假设我们的初始实现将首先使用简单的解决方案，除非我们明确提到相反。这有助于我们专注于安全性，优化只会在后期进行。KISS设计原则适用。

初步

该图表将使用CKB单元模型的一些抽象，以简化协议调整的形式化和解释。例如，我们在此不讨论显式的交易结构，以及给定单元的数据实际上是存储在交易的并行数组中的事实。以下是所需抽象的解释。

假定读者对CKB的单元模型有基本理解。这包括对锁脚本、类型脚本及其执行上下文的了解。

单元：一个单元携带容量（CKBytes）、锁脚本、类型脚本和数据。

数据：任意字节。

Perun协议可以简化为五个步骤，每个步骤都有专门的部分展示我们在CKB上实现Perun的方式。

Perun部署

CKB独特的设计和可用性使我们能够将通道逻辑部署到包含智能合约/脚本代码的参考单元中。在撰写本文时，我们仍不确定是否会将智能合约的实现拆分为PerunLockScript和PerunTypeScript。从概念上讲，我们希望遵循CKB的最佳实践，将访问权限管理提取到自身的锁脚本中，该脚本在通道打开时与Perun类型脚本相关联。

我们将在以下内容中考虑此拆分，但想提到的是，如果有简化的理由，保持智能合约统一为单个类型脚本对我们来说也是可能的。

PerunLockScript

PerunLockScript应处理对通道活动单元的访问权限。它规定，任何通道参与者在能够向锁脚本证明其确实是该通道参与者的情况下，可以消费活动通道单元。

这通过在PerunLockScript.args字段中提交每个参与者的公共标识符来完成，因此任何尝试消费活动通道单元的链上交易都必须包含正确证明的见证。

为了使Perun协议正常工作，必须保证任何时候仅存在一个给定通道ID的活动单元。我们将使用PerunLockScript.args字段来存储通道ID以及所有相关方的参数和签名，以确保这一不变性在至少存在一个真实用户的情况下得以保持。

只有当每个参与者相互串通时，通道才可能创建相同ID。但这将导致每个参与方都是恶意的，这使得任何安全保证变得无效。

PerunTypeScript

PerunTypeScript应处理状态转换的验证逻辑。它与PerunLockScript协同工作，因为两个脚本都知道它们为其实例化的通道ID。此外，PerunTypeScript将确保管理的通道产生的输出中仅创建一个最多的活动单元。

状态转换的验证逻辑在此设计中不变。

通道资金

通道资金是安全地收集所有通道参与者资金的过程。这包括取消通道资金并补偿所有用户其已投入的投资的可能性。

在UTXO基础系统中，资金可以采用多种方式。我们将考虑两种逐渐增加复杂性的方案。

以预设顺序的通道资金。想要相互进行支付通道的用户在链上为通道筹款之前决定资金的顺序。该资金承诺反映在通道的开通参数中。

注意：为了简洁起见，我们省略了显示辅助输入和输出，这些输出包含被资助和重新分配的资产。

上面的图表显示了一个开通通道的状态，其容量CN和初始通道状态CS存储在单元的数据部分，通过交易TX进行消费，以生成输出单元，容量为CN'，转换后的通道状态为CS'。容量可能增加，因为通道可能使用CKBytes作为资金来源。

显然，PerunLockScript和PerunTypeScript已经事先部署，TX的输入单元源自第一参与者进行的通道开通。这也导致CN包含第一参与者的资金承诺，而CN'包含第一和后续用户的资金承诺。关于Perun通道中单元容量的处理将在下面的_通道开通_部分讨论。

在后续轮中为通道资金需要时间锁，以便没有用户能够通过忽略其资金轮来阻塞已为通道提供资金的其他用户的资金。

CKB允许创建多重签名交易。从概念上讲，想要参与通道的用户可以创建共享的链外交易，该交易可以由所有参与者一起签署，利用他们各自的访问权限在链上一次性资助和开通通道。或者，多个用户可以同时创建资金自己的交易。PerunTypeScript将确保只有在所有参与者资助了正确金额的情况下，这些交易才有效。在包含超过两个参与者的通道中，这加快了过程，但需要激励考虑来决定_谁_提交交易。

通道开通

每个支付通道在链上都必须是唯一可识别的。由于我们计划在代码单元中预先部署Perun智能合约，因此我们需要一种方法对智能合约进行参数化。CKB单元模型的一个便捷特性有效地允许通过将适当参数传递到Script.args字段来实例化智能合约实例。CKB的执行引擎使用此功能对输入和输出单元进行分组，并在不必要时删除冗余脚本执行。巧合的是，这使我们能够通过将ChannelID作为脚本参数传递，轻松确保活动支付通道的唯一性和链上识别。CKB的执行上下文则允许对输入和输出进行分组，以确保不会创建活动通道的分叉。

关于单元容量的问题。CKBytes不仅作为可以用于支付的本地资产，而且需要保证一个单元始终包含至少与单元存储所占用的CKBytes相同的数额。创建通道时必须考虑此CKBytes的下限，并且可以提前考虑。通道状态的数据结构的大小以及单元中的哈希在创建时是常量，并持久到通道关闭和结束。最初，我们将让通道的初始资助者承担容量成本。这将在PerunTypeScript中反映，从而确保初始资助者能够回收其投资。

通道更新

通道更新完全在链外进行。由于CKB没有强制性的编码规则，这对协议实施本身没有特殊关注的要求。

通道争议

CKB允许链上代码访问区块头。保证在给定的TX中引用的所有区块头都存在并且已在链上提交。如果没有满足先前条件，则TX无法被验证。

对于Perun通道，我们需要相对时间锁，附加能力是在链上争议被解决或正在进行时更新它们。在CKB中，从上面提到的所需TX中方便地访问时间，这使得处理通道争议变得简单。我们可能会对相对时间锁采用基于时间戳的方法，但一般而言，也可以使用纪元或区块高度。

具体来说，我们将通过其引用的区块头bn_o访问输入单元的时间。结合添加到消费TX的另一个区块头bn_n，我们可以将bn_o中的原始时间与bh_n中的时间进行比较。

关于交易since字段的注释：TX的since字段不能用于这种情况，因为输入可能需要在时间锁结束之前被消费。所讨论的时间锁只是Perun用户的保证，最终可以强制关闭通道，如果其他方未作回应。

通道关闭

在CKB上关闭通道有着额外的复杂性，即正确处理和重新分配在通道开通中使用的CKBytes给正确的各方。

成功的通道关闭

在愉快的情况下，所有方达成了最终状态。这个最终状态可以由其中一方使用以提交执行PerunTypeScript的close功能的链上交易。关闭通道将根据最终通道状态重新分配所有所需的资金。

此外，我们需要一种方法来补偿所有方借出的CKBytes，以用于链上通道状态的维护。存储此信息的确切性质仍有待商榷，但可能的选择是PerunLockScript.args字段与通道ID一起使用，或者更改通道状态并保留在那里。

最终决定可能取决于我们是否能找到一个适合存放_静态_脚本信息的好地方，该信息在通道生命周期内是不应更改的。目前，PerunLockScript.args似乎是理想的选择。

关闭通道不会创建新的带有PerunLockScript和PerunTypeScript的活动单元。只会创建包含正确资产的活动单元。

强制关闭通道

强制关闭通道在CKByte考虑上与愉快的通道关闭相同，附加检查时间锁是否过期。协议层不需要其他适应。

实施步骤

链上

Perun通道合约将使用Capsule SDK在CKB上以Rust实现为脚本。实施该脚本需要对Perun协议进行调整，以便与CKB使用的单元模型兼容。在了解Capsule及其工作流的过程中，需要解决的挑战包括与单元模型兼容的资金协议、链上状态处理和唯一的链上通道识别。

链下

我们的链下部分包括合约绑定和perun-nervos-backend，实现与我们的go-perun核心连接的必要接口。我们计划使用ckb-sdk-go为此。

附注

本项目由CKB提供资金资助。有关该项目的更多信息，请点击这里！

我们希望我们能激励您使用通道技术的用例和潜在私用！我们始终乐意接受反馈并与新的社区联系。如果我们引起了您的兴趣，请在Medium上关注我们，在LinkedIn、Twitter或加入我们的Discord频道！如果您更愿意给我们发一封传统邮件，我们也非常欢迎。hi@polycry.pt

• 原文链接： medium.com/perunnetwork/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～