Hi 游客

更多精彩,请登录!

比特池塘 区块链前沿 正文

菜鸟学习状态通道 广义状态通道

fzny61226
113 0 0
###什么是广义状态通道?
- h0 X; S+ y# c- i# a: m
# k5 S" q; D7 H: T$ Z广义状态通道的意思是,用户可以用同一个通道做多种不同的事情。
+ c' C9 J7 W! M# p4 d# q
. |7 M, c  a3 s% c, u  M###广义状态通道有何意义?9 F6 v' `7 Z% A( j: |% ~) ]
4 j. n: V% |9 Q: b: }% l
没有状态通道,任何以太坊上的 App 都必须承担高额手续费,忍受延迟,因为 App 高度依赖于链上交易。使用 App 定制型状态通道,我们可以创建更经济更高效的 App ,用户只要在启动和关闭 App 时支付就可以了。广义状态通道更进一步地改善了这种情况,用户只需要在关闭 App 时支付。4 ^! M* s% g( m2 c* ^
  T4 S6 k5 w  [7 i
注意:当我说“支付”的时候,我的意思是向链上提交交易。
& A' n  s3 |$ @
4 n/ E5 L1 l; f4 \9 e& C  n###广义状态通道
$ i6 Q2 W5 c( P8 E0 q. u0 Z( W: g9 y( a# @" e3 i+ G+ u
在技术上,要开启广义状态通道,所需要求与 App 定制型状态通道一般无二:一个足够强大的多签钱包就足够了,参与者用于锁住状态。区别在于,用户无需为每一个应用都“安装”链上组件——即便要使用多个应用,该多签钱包也将是用户所需的唯一链上组件。
6 N) ~, e6 E; r$ J0 F* m1 d3 F3 c" |1 P# y* r
App 定制型状态通道(回顾)
, |! g" k: B) O/ K; x
( ]9 r* K7 z3 {3 @- T+ I" L鉴于在部署链上组件这一点上差别极大,我们先回顾一下我们在前面的文章中讲到的内容。在前文中,我们遵循下列步骤在多方间打开一个 App 定制型状态通道:
2 b, n" r5 `, T8 `- S! t2 K6 h# w' D/ e6 H
与相关方一起,部署一个多签钱包,把规则集(用来解析发送给钱包的交易)加到链上。
1 p# l0 u7 T& I
7 v2 y) T. k5 H" T2 f$ D在他们进行不同的操作时,在参与者之间广播已签名的消息。
& q* c: T' u. ?$ x" x/ i2 x( B
( d- L: D  C/ Y7 T当参与者准备好开启或退出通道时,他们会把所有参与者签名的最新状态提交到多签钱包,多签钱包根据内置的规则集,决定如何在参与者之间分钱。
3 \9 |. m! z5 Z# k8 k
" s3 I* b0 B0 u2 g" j% ]- g这种配置看起来就是下图的样子:2 ^9 [& T0 Z/ y8 T

* u& T! T: D. b8 \, R# w( R; }-在任何时候,Bob 和 Alice 都可以把双方都签过名最新状态提交到多签钱包,来配置通道。-
, v+ M9 g7 J: h) b9 C/ O6 P5 [2 T& A: T' t1 x" ]
注意,上述过程所用的多签钱包只支持符合其内置规则集的 App 。再次强调,广义状态通道通过“反事实实例化(Counterfactual Instantiation)”扩展了 App 定制型状态通道的功能:允许新的 App 安装在现有的状态通道中。4 G7 _( J0 V  h- ~' ?( m* U
6 j/ W4 \6 f; \6 b$ [
###反事实实例化
) F- G/ c* M4 M8 Z5 N+ b6 r* J1 }  E0 F8 Q& W
反事实实例化是一个通道内成员同意接受链下智能合约约束过程。这是一个比较奇怪的概念,因为它意味着“链下代码即法律”(给 Liam Horne 点小费吧,这是他提出的),一下是一个简单的例子:! j% A# p. B- q  \+ r1 [
/ a4 E9 s( w' O1 ?! Z% C
So Easy (作者你是认真的吗?)-) }7 e) m2 s* k

, M: I" e. n4 o9 S4 ^% G2 b$ }要创建广义状态通道,我们唯一需要的就是一个多签钱包。我跟阿剑各往钱包了存了 5ETH,并且决定要在我们之间创建一个支付通道。所以,我们在链下创建了一个支付通道,并且都对合约代码签过了名,同意在关闭通道时部署它。我们同样也对基于已部署的支付通道的最终状态、发往多签钱包的条件支付请求签了名。
6 {8 @" `$ E4 A, e0 r
0 a3 |5 ?% f4 h% `那么,使用同样的方式——所有参与者都签名,我们不仅能保证状态的可信,也能保证代码的可信。所以,只要我们都签署了代码,我们就可以像该代码已在链上部署的那样,放心地签署相关的状态。两种方式最主要的不同就是,我们只需要在想要结算状态通道时部署代码。6 I( D0 \, X4 B- S. Y
# E0 c+ o& M. [# h$ B# A
那么,当我们想结算时的时候,我们需要:
2 @" P3 B4 l, N3 h% m3 ]
0 c: C; r" @+ j! J9 e部署支付通道合约
2 _) c7 U$ M/ N0 q2 h3 P7 C/ u7 H: f& M7 I
向该合约提交所有参与者签名的最新状态
. J: n+ l/ u+ c9 S
4 i0 A, I7 d! l( a: E: q(基于支付通道的余额)将条件支付请求提交给多签钱包
! }& I9 Z7 U1 E
. }1 h: l) o, E/ k多签钱包给各参与方支付
- O3 K7 f- f% K* O0 G
/ d7 T. w' v/ z: W8 P- D那么,反事实实例化使我们可以假设链下代码已经被部署到了链上,并据此行动;因为我们可以在任何时候部署上链并提交最新状态。但是,这就有个问题——我们如何在没有链上地址的情况下签署状态转换?这就是注册合约的用武之地!
' Z$ b* D6 D8 t* k0 C1 g3 h% A5 K! |+ I% X
###注册
$ T+ h8 b! O2 s9 D8 t; \* {
( e  X2 U: Z$ X1 u9 K从比较抽象的层面上讲,注册器智能合约允许我们做以下操作:
! w- q- ^* i+ O- _" s) o; u7 \" f! d1 N- D5 R
基于合约字节码,创建一个链下地址(cfAddress)6 \* B" b+ ?- _# k, B

2 ?* X9 `- Q  L3 e部署智能合约,并把 cfAddress 和链上地址进行映射
3 d2 U6 |+ D8 @. O8 P+ f  z# R! q/ Q% m4 c# O
通过 cfAddress 执行链上合约代理调用( w* r1 u' K/ G3 g  i# m
$ w! e7 n( ~3 d9 ^
注册合约伪代码:/ P9 [  O/ p9 t, |! q
- I4 f, i+ e% q5 X9 S" Y
contract Registry {
; Q4 W/ U$ C' H4 Y" u' C$ y
/ r7 d+ G( d. U5 h  mapping(bytes32 => address) resolver;9 p) E/ c* R( [2 E5 l2 Y; g, F
$ I: M0 T' U3 H  A1 r# F, N7 N
  function cfAddress(bytes code) returns (bytes32) { ... }
/ a3 k. m  |# ^4 ?0 Q! c3 q  _* P1 O! B/ i# e- b' O, d- _
  function deploy(bytes code) { ... }' }+ o, Y/ U  E, t: P2 U' Z3 c4 `
1 t7 Q0 c" n6 R; P9 E8 L* u& B( ?
  function proxyCall(Registry r, bytes32 addr, bytes data) { ... }, W; o5 T7 h7 Z# C
1 F, X7 k3 W; W8 c0 M  A2 f( F
}
2 \/ H' I2 `8 r5 M. G5 O6 ~$ M! m" q" r6 f
所以,如果你想部署一个合约,你需要用交易调用 deploy 函数,并以合约的 initcode(初始码)作为参数(一般来说,它是与 ABI 编码的构造函数参数连接的合约构造函数字节码)。这个函数把智能合约部署到链上,并且把合约地址加到注册映射表中。5 L' \* s% G* e: M

  m" ^4 U( g1 }) k- y* W以这种方式,你可以通过注册表中的解析器创建相互引用并互相依赖的链下合约。那么,要是想让我们上述例子中的通道运行起来,我们就得通过注册合约来部署支付通道,在多签钱包的条件支付中解析出支付通道的地址。
$ i( i1 O7 p4 d, l6 l" |& W
: [8 ^6 L9 Z) M, W) n, r% w) G###依赖
+ I7 T0 x" i5 U' K$ v  E# l' b7 R& l1 q
注册合约允许我们做的就是可以建立互相依赖的链下合约,就像合约 A 依赖于合约 B,只有在 B 最终确定之后,A 才能确定(条件层级确定性)。  ^# w  p# ]  ~
+ L) j5 X0 \; s0 e
-以上我们可以看到,除非 Nonce 合约确定了,否则 PC 合约无法确定。-
5 W' }% ]0 ]( f7 |6 x' {% R
; z# X5 d8 {  c# E1 @' W3 G& b你看,上面是一个比较基础的例子,我们要求当前合约基于另一个合约的布尔条件值。我们可以扩展这个条件,允许所谓的“原子状态转换”。
9 ]8 F  Y% O* x% n, u
5 Y6 y& V. k& I' c###原子状态转换( f: o( r, Y! [  I; F

3 v5 D4 x: r  ?- G2 P* e; D3 a根据这种层级的依赖结构,我们可以进行原子状态转换,转换的同时,伴随着一些合约生效,一些合约失效。下面例子表明,一个 10 ETH 的支付通道,基于 nonce 值,转换为一个 8 ETH 的支付通道,加一个 2 ETH 的扑克游戏。
- @/ Z1 h( |: Y
/ W- `! d) `5 N7 x8 X, w+ g-合约的有效性基于 nonce 值-
) C9 L9 V# n* G3 d
% w" L$ ]* v2 [如果支付通道的双方都同意用支付通道里的 2 ETH 来创建一个扑克游戏,他们可以签署支付通道的余额更新变化,从(5,5)到(4,4),同时签署一个内置 2 ETH 的扑克合约,nonce 合约的 nonce 值是 4 的时候,这两个合约才会生效。# }; e( X) d+ J8 n3 W  B' H9 }0 d
7 r- t' C3 ^% h; |5 s
-基于新 nonce 值的原子状态转换-
- d$ a) U5 C) X6 @2 ]7 g+ s3 ?$ B
当支付通道的双方都签署了支付通道和扑克合约的条件更新之后,他们可以签署 nonce 合约,使得 nonce 值加 1。一旦 nonce 值更新为 4,旧的支付通道状态就会失效,同时扑克合约和新的支付通道状态就会生效。
1 y& ]' F0 a7 Q
1 o  F# ^) r  `. u# [3 N& r+ G有原子状态转换,代码升级就会变得容易。如果之前支付通道的参与双方想修复代码中的 bug,他们可以在更新余额的时候修复代码。当更新 nonce 值后,之前有 bug 的代码就失效了。
: Z2 i& ~8 Y% M% C
6 \2 U$ y6 l1 G4 z5 u/ S, h7 M下面有个例子,这就是基于“根 nonce”合约的一系列反事实合约:
9 f- c) L: q$ l1 [" M7 P/ a/ J1 b1 g- D
根据这种架构,我们可以通过一个“根 nonce”合约有条件地更新所有链下合约的有效性。这允许我们可以根据参与方的需求,迭代地从状态通道中添加和删除链下合约。8 Z) G  f- w7 D; {" w

, G2 c' q9 C% l配置通道
8 L+ w" c! d/ W0 {* v3 G, @4 X( x
: i3 v0 i4 V2 h: O$ Y假设我和阿剑想玩四子连珠的游戏。我们将会这样做:, E( g. u; U, t$ Y8 L& M, M- c

' F+ F: D& U. `( `- W8 H部署根 nonce 合约、ETH 支付通道(PC)、ETH 条件支付通道(CPC)和四子连珠智能合约% U) ]( u  ]- s0 D
8 k" \' s1 M( q$ m. {
向四子连珠游戏提交最新的签过名的状态2 @' {4 k9 x! E6 U6 X6 d

1 T& B; I" t! ^. ?! ~基于四子连珠的游戏规则确定 CPC' x. h7 N( {8 O! _/ e' V7 ~
' l" v7 s# p( e  S8 m* p( @. B
基于 CPC 确定 PC6 q; p! E* c5 P3 [

; I0 G, N$ J; p/ G; J向多签钱包提交已签名的条件支付(基于 PC 的最终确定状态进行支付)# d( n, U3 P- N& T* l
2 h+ Z; B4 ~( s
因此,我们可以一直开启其他状态通道,甚至允许我们重用已经部署在链上的四子连珠游戏的代码。下一次我们想要玩游戏的时候,我们只需要对游戏状态进行签名,然后提交到已经部署好的智能合约上。唯一需要实现的是取消现有链上代码的确定性,这是一个实现细节。
. l- k2 H. ^% O+ T4 p1 i: i4 I& \/ E, u; o; j7 Z
###注意:你不需要像我展示的四子连珠、CPC 和 PC一样,为你的合约加上这么多的依赖。无论你希望怎么做,这都取决于你和你状态通道中的伙伴。
7 `. h, I" u8 D7 `3 ^- ~) \( j  y6 |$ X
现在,假设阿剑的朋友 Hunter 想跟阿剑玩四子连珠游戏,但是他只跟我开了一个状态通道,这时候 Metachannels 就可以派上用场啦。, B! I% D3 M3 [2 f$ R
; r% N+ M$ M6 U3 L5 w) X
###Metachannels; q: h! k/ {9 K% e" e7 M3 K
( r" c$ M3 U* e6 `5 A# S# Y
Metachannels 是状态通道上的虚拟通道(参见本系列 Part-4)。要创建一个 Metachannels,你需要两个想交互的参与者,他们各自有一个状态通道,并且通道的另一方是同一个人。两个参与者同意创建一个新的合约,通道另一方(即共同的中心)会与他们一起创建一个代理合约,指向两个参与者的新合约。看起来就像下面这张图:
( ?7 K2 L$ b7 ]. ]- e7 d7 w9 n# a5 e& k- Y
-广义虚拟状态通道 = Metachannels !-2 @! t1 a- h* n8 }; C

, O: o/ W5 U2 @8 |: E我们可以无限地扩展这个模型,让我们想跟谁玩四子连珠,就能跟谁玩。5 m! S& p2 a* K, e% E* x! G5 b

5 `: R2 x6 E. \/ G9 V+ @###广义状态通道的优点
, b# X1 B4 ]/ L% m; s% {' H/ w% I, Z/ l# p
引导——因为我们所需要的只有一个多签钱包,我们可以很容易在链上现有的多签钱包中选择一个开始开发。# r6 J. H( D* U0 k* g' t
# d7 d) V/ o7 l2 q, d( M: g9 j; @
隐私——除了参与者之外,没有人知道状态通道内发生了什么,对于外部世界来讲,参与者之间只有一个多签钱包。
3 l4 Q7 M( o: q. r2 g; {, S" p3 U9 g: [$ ~
可升级——如果链下代码中有 bug,所有参与者可以通过链下的操作修复 bug,不需要进行任何链上操作。7 v' w1 z& j) B" i

4 m4 j3 b9 R6 s3 m: ?可重用——这种方法有效地鼓励了通用链上库的形成,让所有状态通道都可以引用。/ m+ G* r( }, z' f, e3 V
8 `* i2 g, ~) G  ]1 D. Y9 S! i
###Part-6:反讹诈) [% q& m% i" b+ S
$ r+ |$ \$ U5 n2 P: \3 p9 b
在我下一篇博文中,我将会深入讲解状态通道中的反讹诈。讹诈即是说参与者向通道提交一个对自己更有利的较早状态。博文的焦点是 Pisa.
BitMere.com 比特池塘系信息发布平台,比特池塘仅提供信息存储空间服务。
声明:该文观点仅代表作者本人,本文不代表比特池塘立场,且不构成建议,请谨慎对待。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

成为第一个吐槽的人

fzny61226 初中生
  • 粉丝

    0

  • 关注

    0

  • 主题

    22