PPIO 的状态通道设计

PPIO 的定位不仅仅是做存储,还有数据分发和数据传输。在数据传输的时候,如何保证数据传输的流量也采用一种公正的,不可抵赖的方式来实现的。这就是我这篇文章要讲解的状态通道。PPIO 就是通过状态通道的机制来实现数据传输的公正计量。

传统意义的状态通道机制

状态通道在区块链领域是个已经存在的名字,主要应用于高频交易和微支付。因为在这两个场景下,交易吞吐量会非常大, 如果所有的操作都是在需要共识的去中心化的链上操作,性能低会成为重要问题。

状态通道的解决思路,本质是在交易高吞吐量和验证者的去中心化之间做一个平衡。具体来说,就是把两两交易的细节,放在链下去协商完成,当多步交易完成后,或者交易发生争议,再通过区块链来进行“仲裁”。

为了说明状态通过,我们先做个假设,两个人 Alice 和 Bob,后面也可能简称 A 和 B。假设 Alice 在一开始的资产是10,Bob 在一开始的资产也是10,他们之间即将发生一系列高频的微支付。我们开始模拟这个状态通道。

图: Alice 和 Bob 使用状态通道交易的示意图

整个过程大概分为以下几步:

1. Alice 或者 Bob 创建于一个状态通道智能合约 Contract,后面会简称 C,此时状态通道处于 opening。这个过程是要上链的。

2. Alice 将10个资产打入到合约中,接着 Bob 也将10个资产打入到合约之中,此时状态通道就算是开启,进入 open 状态。这个过程中也是要上链的。这时候的分配方案是【A:10, B:10】。(分配方式是指交易双方都能够在链下都认可的资产分配方式,总量是一样的的,要么 A 多,要么 B 多,如果这个时候合约终止,就会按照分配方案的资产打回到各自的账户上)

3. 此后,由于 A 和 B 之间的状态通道处于 Open 的状态,A和B之间可以开始交易。如果 A 向 B 转了1个资产,则分配方案为【A:9; B:11;N:1】,这时 B 拿到了 A 对分配状态的签名;而接着 B 又向 A 转了3个资产,这时的分配方案变为【A:12; B:8; N:2】,这时 A 拿到了 B 对分配状态。这里 N 表示 Nonce。每次链下双方按照约定改变资产分配,则双方都要自增一次 Nonce 值。诚实的交易者都会以 Nonce 最大的分配方案作为当前的分配方案,而 Nonce 值较小的分配方案都是失效的方案,可以随时抛弃。

4. 状态提交,在交易的过程中,交易双方,A 或者 B都可以随时向智能合约 C 发起状态提交,如果 A 发起了状态提交,C 会验证 B 的签名;反之如果 B 发起了状态的提交,C 会验证 A 的签名,同时也会验证 Nonce 值。智能合约 C 只接收比上次链上分配的 nonce 值更大的方案,如果新提交的分配方案的 Nonce 和签名都合法,则 C 接收新的分配方案,并更新合约中的 Nonce 值为新分配方案的 Nonce 值。双方持续交易,... … 直到最后的分配方案,假设是【A:1; B: 19; N:50】,下面称为最终状态。假设该方案已被提交到智能合约 C,且被智能合约所接受。

5. 关闭状态通道请求,这时候可由任一方发起关闭状态通道,即按照合约中的链上分配方案进行分配。一旦合约 C 接收到关闭通道的请求,合约会进入 Closing 状态并维持一定的有效期,在该状态下且在有效期内,另一方依然可以提交新的有效的分配方案来将状态通道置回 Open 状态。如果在有效期内另一方未能将状态通道置回 Open 状态,则状态通道会在有效期过后,进入 Closed 状态。比如,在这个案例中,B 是受益方,一般来说,是由 B 在这时候发起关闭状态通道请求,然后状态通道进入 Closing 状态,并在一定有效期后按照链上最后的有效分配方案【A:1; B: 19; N:50】进行分配。此时,若B是一个作恶者,虽然现在链上的分配方案为【A:1; B: 19; N:50】,但其实链下最新的分配方案已是【A:4; B: 16; N:55】,但 B 尝试用老的分配方案来分配资产,使自己获益增大。此时由于合约在 Closing 状态,只要A及时发现 B 的链上关闭通道请求的交易,则 A 可以立刻将更新的分配方案【A:4; B: 16; N:55】提交到合约,从而使得合约被置回到 Open 状态,防止 B 的恶意提款。之后 A 如果想关闭合约,则可重新向合约发起关闭状态通道的请求。之后只要 B 无法再给出比 N:55 更新的分配方案,那么状态通道最终将在有效期过后,进入 Close 状态。(注:具体实现时也可以将”状态提交”和“关闭状态通道请求”合并成一步)

6. 最终资产分配:当合约 C 进入 Closed 状态后,任何一方都可以触发最终的资产分配,即按照链上已确定的最后有效的分配方案进行实际的资产分配。

回顾整个过程,需要写入区块链的步骤,只是和链上智能合约 C 相关的部分,分别是开始创建的时候和分配方案的提交以及最终状态的提交。其余都是在链下操作,所以在状态通道的设计中,项目一般设计为 只向区块链智能合约 C 提交一次,从而做到最高的性能。

PPIO 的状态通道机制的设计

· PPIO 支持三个核心模块


POSS 是 P2P Object Storage Service,对标 AWS 的 S3 存储。


· PCDN 是 P2P Content Delivery Network,对标传统的 CDN,就像 AWS 的CloudFront。


· PRoute,是基于 P2P 的自适应网络智能路由,做到两个节点之间,以最合理路径到达,从而速度最快,延迟最低 。这是协议层的实现,在 AWS 中没有对标的产品。

其中除去 POSS 模块外,PCDN 和 PRoute 都是更多激励带宽的贡献,其网络数据的传递非常频繁且实时。如果每个 Piece 的传输,都要写入区块链,这将是非常大的浪费 。其实,网络数据高速传输激励,本质上是高频交易和微支付,所以在设计 PPIO 的时候,我们借鉴了传统的传统的状态通道机制,来实现带宽的激励。

1. U 创建了区块链上的智能合约 Contract(后面简称C)。然后 U 往 C 中转入资产,假设转入了10个资产。由于 PPIO 设计的是单向通道,只有 U 转入资产后,即可进入Open 状态,其分配方案是【U:10; M:0】

2. 开始进行数据传输,U 向 M 请求数据,M 向 U 返回正确的数据后,U 会给予 M 一个 Voucher,即带有 U 签名的新的状态分配方案。由于网络传输的实时性要求非常高,M 需要先给数据,再拿 Voucher。此时分配方案逐步变成 了【U:9; M:1】。

3. 继续传输数据,状态通道的分配方案,U 的资产越来越少,M 的资产越来越多。直到U 把之前存入状态通道的资产用完,即【U:0; M:10】; 

4. 最终状态提交:此时 M 用最新的 Voucher 去区块链上的智能合约用 Voucher 去提款。C 在验证 Voucher 中有 U 的正确签名后,接受了 M 的提款。之后状态通道关闭,标记为 Close 状态,之后该状态通道不能再进行交易。

5. 之后 U 在 M 请求数据,由于资产已经用完,M 将不再提供服务。除非 U 创建新的状态通道合约 C1,再转一定的资产进去,才能再次向 M 请求数据。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
区块链
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论