Hi 游客

更多精彩,请登录!

比特池塘 区块链前沿 正文

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

fzny61226
60 0 0
###什么是广义状态通道?
. O' y+ V0 [. X/ @) ?! `
4 x! C( ]8 j: q广义状态通道的意思是,用户可以用同一个通道做多种不同的事情。
' p7 w: P! e" y0 T1 I; c; C
) e$ s( n5 L5 V( O###广义状态通道有何意义?
$ w! s. I) I$ Y+ b( O* @7 _6 h( S" Y! k& G% M# G
没有状态通道,任何以太坊上的 App 都必须承担高额手续费,忍受延迟,因为 App 高度依赖于链上交易。使用 App 定制型状态通道,我们可以创建更经济更高效的 App ,用户只要在启动和关闭 App 时支付就可以了。广义状态通道更进一步地改善了这种情况,用户只需要在关闭 App 时支付。/ U( l+ b/ Y' ]0 s7 S* k

6 e5 t5 T& E0 H- {7 q. ~注意:当我说“支付”的时候,我的意思是向链上提交交易。
) j$ J/ f+ E- v0 f8 V
( l& A2 f; J1 |  c2 g###广义状态通道0 R. J$ @* L/ \  x$ w

  E* |8 \. a+ F, W9 X2 n在技术上,要开启广义状态通道,所需要求与 App 定制型状态通道一般无二:一个足够强大的多签钱包就足够了,参与者用于锁住状态。区别在于,用户无需为每一个应用都“安装”链上组件——即便要使用多个应用,该多签钱包也将是用户所需的唯一链上组件。
2 d) J* v* v* F
4 R* M. U) x, R3 p+ \, \App 定制型状态通道(回顾)
& A9 I9 ~  ]+ m; p" u
/ s, l5 w2 `! u5 f7 n  A; x  G鉴于在部署链上组件这一点上差别极大,我们先回顾一下我们在前面的文章中讲到的内容。在前文中,我们遵循下列步骤在多方间打开一个 App 定制型状态通道:
! U" M* G, H2 d& m$ d; F4 I0 x8 s9 X0 M5 w& i, I; Z2 ?6 o: b
与相关方一起,部署一个多签钱包,把规则集(用来解析发送给钱包的交易)加到链上。9 `& k! S% J4 a' O& r2 C

( M. S! g, O" N% m# |2 x% T在他们进行不同的操作时,在参与者之间广播已签名的消息。
1 d8 m: p( {& j3 ?
3 H0 [$ }% J* y1 Y当参与者准备好开启或退出通道时,他们会把所有参与者签名的最新状态提交到多签钱包,多签钱包根据内置的规则集,决定如何在参与者之间分钱。
7 {. m/ `! Y, _: U* [9 K* ^( ^
( J  w5 V( m- W( R3 n, Y! Z这种配置看起来就是下图的样子:
0 j! N6 ]# `, G+ H
; h  T) m4 g" \( `9 o6 k8 c-在任何时候,Bob 和 Alice 都可以把双方都签过名最新状态提交到多签钱包,来配置通道。-4 |) ^: d# W2 c) x2 ^

$ V' w2 G1 H# o% D( _5 @注意,上述过程所用的多签钱包只支持符合其内置规则集的 App 。再次强调,广义状态通道通过“反事实实例化(Counterfactual Instantiation)”扩展了 App 定制型状态通道的功能:允许新的 App 安装在现有的状态通道中。3 c/ c" M, I1 F% {" K4 _

8 m1 [. @$ }( H: u+ U###反事实实例化8 T9 K+ ?1 y0 C" j* P
, D; x! J( `/ X4 ^6 r
反事实实例化是一个通道内成员同意接受链下智能合约约束过程。这是一个比较奇怪的概念,因为它意味着“链下代码即法律”(给 Liam Horne 点小费吧,这是他提出的),一下是一个简单的例子:
. m6 R: v" i0 b3 {: g
+ M$ p3 o. K* zSo Easy (作者你是认真的吗?)-
- _/ i8 V2 K# D* k5 s! h3 t) Y" F0 T. f
要创建广义状态通道,我们唯一需要的就是一个多签钱包。我跟阿剑各往钱包了存了 5ETH,并且决定要在我们之间创建一个支付通道。所以,我们在链下创建了一个支付通道,并且都对合约代码签过了名,同意在关闭通道时部署它。我们同样也对基于已部署的支付通道的最终状态、发往多签钱包的条件支付请求签了名。
8 n& j. c; R8 ?  Q  d" ~0 y. `! q+ o1 s$ W& d
那么,使用同样的方式——所有参与者都签名,我们不仅能保证状态的可信,也能保证代码的可信。所以,只要我们都签署了代码,我们就可以像该代码已在链上部署的那样,放心地签署相关的状态。两种方式最主要的不同就是,我们只需要在想要结算状态通道时部署代码。
8 L5 W: Y% P7 ^, O! {% Z8 I" b5 ]3 g# t: E0 o  [- x
那么,当我们想结算时的时候,我们需要:8 _5 C9 S) y* A) q) J

7 m& P0 `" W% P$ t  T部署支付通道合约
- ~% V9 N, {+ H' l! U' q' \/ t% x
; P: V8 |3 ?; z& i7 W向该合约提交所有参与者签名的最新状态
1 v& }; z! e( t  f5 U
, s) f8 o0 X. w0 ?7 q0 F& v(基于支付通道的余额)将条件支付请求提交给多签钱包
) G8 z, W( ?" m- S- f/ A
) \7 a5 a, M) l0 ]5 @% K* b0 I' q多签钱包给各参与方支付4 z. G6 v. E; ^" H" ~& b

+ B* @9 `( Z' q" E0 [' X& [' h2 E那么,反事实实例化使我们可以假设链下代码已经被部署到了链上,并据此行动;因为我们可以在任何时候部署上链并提交最新状态。但是,这就有个问题——我们如何在没有链上地址的情况下签署状态转换?这就是注册合约的用武之地!
* i7 J( ?% c( I' @9 h  K3 L' Z7 P, O5 \4 ?
###注册
0 _' L$ q' a; B/ z. k2 B5 M/ |3 @  @$ @, A7 o7 ~- K' w4 I
从比较抽象的层面上讲,注册器智能合约允许我们做以下操作:
& J! }  G7 k% n1 b  I2 v
' o* W9 n6 [8 i5 S基于合约字节码,创建一个链下地址(cfAddress)
' H+ H4 d1 p3 `8 l5 X- h4 ~# ?
: q$ `! \2 \, a; h部署智能合约,并把 cfAddress 和链上地址进行映射
& F* E6 _7 l  X$ s
4 Z' A8 S6 @2 c. ~6 z通过 cfAddress 执行链上合约代理调用
- m9 F# H' z2 l/ B
& W0 ~7 h! C% T注册合约伪代码:& f' W& [9 L6 p8 I
4 O6 s; v8 n, W" f1 E8 d
contract Registry {$ j: Q# y9 o6 t; M# X

# G& f2 e, v/ D1 a  mapping(bytes32 => address) resolver;/ q( P4 I) H2 e# C7 I0 t- ]

; ~* P0 b) A3 b  function cfAddress(bytes code) returns (bytes32) { ... }
8 ~; I  n. q4 t5 k  q% Y0 g# r) r4 e
- W7 g  M, k# g, I4 F5 A  function deploy(bytes code) { ... }" F( ]: o$ i4 u& b) p' t; }

: Q% A: A$ N: K4 Z9 M, q4 @  function proxyCall(Registry r, bytes32 addr, bytes data) { ... }' ?- @1 R! x- @. z: V9 ?

, h) V& @! J8 [) I) u6 z3 t& ]}
. P& m2 T$ N) e; v& F5 f* C* I& b& i' P- @2 q( a$ J& M' b
所以,如果你想部署一个合约,你需要用交易调用 deploy 函数,并以合约的 initcode(初始码)作为参数(一般来说,它是与 ABI 编码的构造函数参数连接的合约构造函数字节码)。这个函数把智能合约部署到链上,并且把合约地址加到注册映射表中。  {6 Q! b' d3 ]" J/ ^# r
9 ]9 Y: q8 w( s1 H
以这种方式,你可以通过注册表中的解析器创建相互引用并互相依赖的链下合约。那么,要是想让我们上述例子中的通道运行起来,我们就得通过注册合约来部署支付通道,在多签钱包的条件支付中解析出支付通道的地址。
2 m2 i& }6 `' m6 ]/ o; J9 ~/ Q2 I9 W. R/ g
###依赖
: q; k) H" q0 h* D% C. `3 q% T! }9 [0 X9 I+ }2 G; m
注册合约允许我们做的就是可以建立互相依赖的链下合约,就像合约 A 依赖于合约 B,只有在 B 最终确定之后,A 才能确定(条件层级确定性)。! c) `& A) w- n. A$ e2 P1 ^
2 ]) v5 b5 b4 n( _
-以上我们可以看到,除非 Nonce 合约确定了,否则 PC 合约无法确定。-+ b' T3 M+ V4 N' g

. @" Q& f9 Y6 R5 W你看,上面是一个比较基础的例子,我们要求当前合约基于另一个合约的布尔条件值。我们可以扩展这个条件,允许所谓的“原子状态转换”。
4 F1 M# ~/ r2 ?/ m2 d6 @
. C8 O( ?; F; _) n4 T6 z: O+ f/ O- k###原子状态转换
7 n: c+ m1 k# o9 m! d& f( p* c( P3 R2 E2 W; N. s1 |. v* I" i  J
根据这种层级的依赖结构,我们可以进行原子状态转换,转换的同时,伴随着一些合约生效,一些合约失效。下面例子表明,一个 10 ETH 的支付通道,基于 nonce 值,转换为一个 8 ETH 的支付通道,加一个 2 ETH 的扑克游戏。
. c+ Y) Z0 `+ `5 J# ]1 [. V# m$ x
-合约的有效性基于 nonce 值-! q2 }6 f) w2 L2 L  g' K
8 q! H& k1 G- K# D
如果支付通道的双方都同意用支付通道里的 2 ETH 来创建一个扑克游戏,他们可以签署支付通道的余额更新变化,从(5,5)到(4,4),同时签署一个内置 2 ETH 的扑克合约,nonce 合约的 nonce 值是 4 的时候,这两个合约才会生效。
8 P- R; Z3 b9 o
  G& ^/ Q% r. @, c-基于新 nonce 值的原子状态转换-
$ d  L$ [* Q: E# A" v0 Y& F* n1 J2 ^. A
当支付通道的双方都签署了支付通道和扑克合约的条件更新之后,他们可以签署 nonce 合约,使得 nonce 值加 1。一旦 nonce 值更新为 4,旧的支付通道状态就会失效,同时扑克合约和新的支付通道状态就会生效。
* I2 z. |& \, L, ]" g$ c; ?5 Z
% Q. \  u* v5 F2 ^% \+ }/ O; T有原子状态转换,代码升级就会变得容易。如果之前支付通道的参与双方想修复代码中的 bug,他们可以在更新余额的时候修复代码。当更新 nonce 值后,之前有 bug 的代码就失效了。
9 J  r: K5 u4 e; G9 n$ {0 F5 S* n( w, _6 h" ]* {; a' Y
下面有个例子,这就是基于“根 nonce”合约的一系列反事实合约:+ ~8 c% p. }/ {3 _! @
4 x& H; @$ h' T: B) Q- T
根据这种架构,我们可以通过一个“根 nonce”合约有条件地更新所有链下合约的有效性。这允许我们可以根据参与方的需求,迭代地从状态通道中添加和删除链下合约。& {; f  h+ L4 |
, Y/ U$ O5 s9 D/ _% p
配置通道- E) i1 z6 j, D  w  l

* M/ Q, L2 i2 R5 [假设我和阿剑想玩四子连珠的游戏。我们将会这样做:
; @/ `* _2 s  d  y) ~& [9 X3 r/ l
2 f9 b9 @7 t1 S+ e  T部署根 nonce 合约、ETH 支付通道(PC)、ETH 条件支付通道(CPC)和四子连珠智能合约
! b; i+ m0 O0 }' e0 n) u6 g; G: q7 J' T. K2 q* O8 N" y, i
向四子连珠游戏提交最新的签过名的状态7 ]$ H: s! a- l3 H0 a  E0 V! i

" j* x( p# h) o* G基于四子连珠的游戏规则确定 CPC
* J% k" `4 u$ m8 O4 A* b
& Z" Z7 s3 i4 X* j5 f1 n3 o  Z7 P基于 CPC 确定 PC5 n% p1 Z5 D  T0 l, G, X7 m

" R# K3 ^* e; d! ]) t9 Z向多签钱包提交已签名的条件支付(基于 PC 的最终确定状态进行支付), \' C0 Q+ [, g7 n

! z) s0 p& G# {( h1 K4 B因此,我们可以一直开启其他状态通道,甚至允许我们重用已经部署在链上的四子连珠游戏的代码。下一次我们想要玩游戏的时候,我们只需要对游戏状态进行签名,然后提交到已经部署好的智能合约上。唯一需要实现的是取消现有链上代码的确定性,这是一个实现细节。6 s$ a, U- w" `" A& P
6 c4 y) ~! w  Y$ m9 Y
###注意:你不需要像我展示的四子连珠、CPC 和 PC一样,为你的合约加上这么多的依赖。无论你希望怎么做,这都取决于你和你状态通道中的伙伴。) p, Q0 i& }/ g! H/ d9 C
: [# e% @8 P9 e
现在,假设阿剑的朋友 Hunter 想跟阿剑玩四子连珠游戏,但是他只跟我开了一个状态通道,这时候 Metachannels 就可以派上用场啦。
" D- m* X* K4 G2 U
, G& t8 e8 g. H7 ^, U% E; q###Metachannels1 w. B- |) H! K  V; g! ]& X& I
% M: g$ ]# d+ w- {9 K' q0 q. p
Metachannels 是状态通道上的虚拟通道(参见本系列 Part-4)。要创建一个 Metachannels,你需要两个想交互的参与者,他们各自有一个状态通道,并且通道的另一方是同一个人。两个参与者同意创建一个新的合约,通道另一方(即共同的中心)会与他们一起创建一个代理合约,指向两个参与者的新合约。看起来就像下面这张图:; N! |% K( F2 P+ ]

7 P1 R6 D' I0 G-广义虚拟状态通道 = Metachannels !-
5 Z: e: B. l3 ?0 G: I1 T
, b' v0 O6 I! v我们可以无限地扩展这个模型,让我们想跟谁玩四子连珠,就能跟谁玩。3 Q# t/ n2 ^8 s  U

3 O# `  d& t) k- j###广义状态通道的优点
' t( R2 ~3 S* q
4 q, k2 q$ o3 R' {7 E引导——因为我们所需要的只有一个多签钱包,我们可以很容易在链上现有的多签钱包中选择一个开始开发。
- Y/ ^8 ?/ H; `- h" y  c
' g3 H% C7 G2 p7 _# [& y5 ?8 R隐私——除了参与者之外,没有人知道状态通道内发生了什么,对于外部世界来讲,参与者之间只有一个多签钱包。3 u- F9 U6 H$ E) b; y
6 \2 `8 m, w3 ^  z
可升级——如果链下代码中有 bug,所有参与者可以通过链下的操作修复 bug,不需要进行任何链上操作。
0 C  ~* G0 _/ o4 ]. ?# Q: Q& o0 u; k# v4 A3 T
可重用——这种方法有效地鼓励了通用链上库的形成,让所有状态通道都可以引用。
) \$ Y8 ]5 G$ E7 O' Q' H7 M5 {& m, V; s0 m4 e* j
###Part-6:反讹诈& A1 q. @' U# B' V, B
  k. f$ D& @! k* L1 P- b, M6 M
在我下一篇博文中,我将会深入讲解状态通道中的反讹诈。讹诈即是说参与者向通道提交一个对自己更有利的较早状态。博文的焦点是 Pisa.
BitMere.com 比特池塘系信息发布平台,比特池塘仅提供信息存储空间服务。
声明:该文观点仅代表作者本人,本文不代表比特池塘立场,且不构成建议,请谨慎对待。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

成为第一个吐槽的人

fzny61226 初中生
  • 粉丝

    0

  • 关注

    0

  • 主题

    22