Hi 游客

更多精彩,请登录!

比特池塘 区块链前沿 正文

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

fzny61226
110 0 0
###什么是广义状态通道?
( }* {; ~% w# Z  R" i, x
* Y0 \1 c7 c  S  A+ ~5 e广义状态通道的意思是,用户可以用同一个通道做多种不同的事情。
/ D% n, d% v  r# E8 M
( V5 g+ ]! U% q/ j: O' d1 L0 k###广义状态通道有何意义?% j$ A) `* H2 \9 F6 J
/ ]+ T2 `. o4 h+ k. _
没有状态通道,任何以太坊上的 App 都必须承担高额手续费,忍受延迟,因为 App 高度依赖于链上交易。使用 App 定制型状态通道,我们可以创建更经济更高效的 App ,用户只要在启动和关闭 App 时支付就可以了。广义状态通道更进一步地改善了这种情况,用户只需要在关闭 App 时支付。
" {, ]2 @0 M; }- T" c% b( i
: S( l# p1 f( ]& }8 v3 J注意:当我说“支付”的时候,我的意思是向链上提交交易。. J  k1 n$ }- {
3 m) X8 J, X- F) N: {
###广义状态通道
* r% Q* v- n; T+ [
( K2 m6 ?' \5 X0 P1 t4 P1 s3 V在技术上,要开启广义状态通道,所需要求与 App 定制型状态通道一般无二:一个足够强大的多签钱包就足够了,参与者用于锁住状态。区别在于,用户无需为每一个应用都“安装”链上组件——即便要使用多个应用,该多签钱包也将是用户所需的唯一链上组件。
  R3 ^+ q2 B$ D0 K7 v' p2 g5 e& L  n% p8 C, V2 N
App 定制型状态通道(回顾)
0 v6 @0 A, j: N6 ~' i! J. J2 R4 O! n( v
鉴于在部署链上组件这一点上差别极大,我们先回顾一下我们在前面的文章中讲到的内容。在前文中,我们遵循下列步骤在多方间打开一个 App 定制型状态通道:
1 l$ W% u; c! M4 O- r7 `+ D. c/ |9 H6 t  W
与相关方一起,部署一个多签钱包,把规则集(用来解析发送给钱包的交易)加到链上。: c# X, o& V/ W$ _! g$ M7 o
6 {, h3 E( X% S4 P
在他们进行不同的操作时,在参与者之间广播已签名的消息。
! l" @5 c; u) h9 b( H/ o+ ]7 v* A$ y8 f8 R4 J, S5 v
当参与者准备好开启或退出通道时,他们会把所有参与者签名的最新状态提交到多签钱包,多签钱包根据内置的规则集,决定如何在参与者之间分钱。
$ a% e" |- n( o2 G! M
% ~! O$ i( ]8 @' Q这种配置看起来就是下图的样子:
! t% |5 b9 j0 J& B# A: d7 D( I$ F; h( F+ ]$ I2 i, [  w  B) g
-在任何时候,Bob 和 Alice 都可以把双方都签过名最新状态提交到多签钱包,来配置通道。-
0 `2 P6 L" w! W+ w) Y% C9 D
- h' D7 [$ l9 J$ P5 Z/ u, a注意,上述过程所用的多签钱包只支持符合其内置规则集的 App 。再次强调,广义状态通道通过“反事实实例化(Counterfactual Instantiation)”扩展了 App 定制型状态通道的功能:允许新的 App 安装在现有的状态通道中。; e9 k) m% \6 f( T9 n) O% f
  D. k5 v( W4 K4 z" ~
###反事实实例化
9 y$ H; v* ^  B* V5 {6 R% s" \8 f3 {7 i; z# W' j* u
反事实实例化是一个通道内成员同意接受链下智能合约约束过程。这是一个比较奇怪的概念,因为它意味着“链下代码即法律”(给 Liam Horne 点小费吧,这是他提出的),一下是一个简单的例子:
+ L4 V" M' p" K" p
$ F/ M/ w+ t. ?0 s/ l% }+ o$ ASo Easy (作者你是认真的吗?)-8 \, x  p( l5 f# J/ C8 ?, u
: t0 h. p, Y/ [+ i. P
要创建广义状态通道,我们唯一需要的就是一个多签钱包。我跟阿剑各往钱包了存了 5ETH,并且决定要在我们之间创建一个支付通道。所以,我们在链下创建了一个支付通道,并且都对合约代码签过了名,同意在关闭通道时部署它。我们同样也对基于已部署的支付通道的最终状态、发往多签钱包的条件支付请求签了名。& `' ?: _, n) j+ r

9 g. Q6 U3 ]  {' G$ [2 t; ]那么,使用同样的方式——所有参与者都签名,我们不仅能保证状态的可信,也能保证代码的可信。所以,只要我们都签署了代码,我们就可以像该代码已在链上部署的那样,放心地签署相关的状态。两种方式最主要的不同就是,我们只需要在想要结算状态通道时部署代码。( U. U" |5 U% f" A; E
& a  U; G& ]% j( u
那么,当我们想结算时的时候,我们需要:
& g+ Y( S! z4 g4 j; E# _' J  L
' I3 |/ r  F9 V9 D' m+ e1 m部署支付通道合约
8 g' g6 y" g3 O7 E. r% v
  G! f  n( e9 \5 X向该合约提交所有参与者签名的最新状态/ D3 [6 A8 [/ K0 o3 d8 }
9 O/ k) W3 C2 V$ i! ]* w& R
(基于支付通道的余额)将条件支付请求提交给多签钱包6 j% b0 E, V1 t" r' L( e& c

% K- A! U9 {+ [/ H8 k多签钱包给各参与方支付
6 s# e. x. ]2 T4 o! |2 o6 C) }1 z# e* X5 o; F+ r
那么,反事实实例化使我们可以假设链下代码已经被部署到了链上,并据此行动;因为我们可以在任何时候部署上链并提交最新状态。但是,这就有个问题——我们如何在没有链上地址的情况下签署状态转换?这就是注册合约的用武之地!
, x9 s4 P0 H- f, B9 g; x5 V% ^# H$ r4 p5 E5 ^% C
###注册
# k( e; @2 f/ d/ x( \( I( W9 r$ \
从比较抽象的层面上讲,注册器智能合约允许我们做以下操作:
9 f+ x# F# u$ {$ L# B- {
! g  y- [+ x2 u1 X, S& t基于合约字节码,创建一个链下地址(cfAddress): d( j0 S, O2 A. P& N8 x

* F% s% @2 P. C部署智能合约,并把 cfAddress 和链上地址进行映射
2 S2 Y, x  h: `: Y3 i" c' g+ T1 V) H
通过 cfAddress 执行链上合约代理调用
; @( }/ \- f) R" H* e  |' ?8 P  x+ t" j8 N2 z( o9 v
注册合约伪代码:
9 i5 p  G# \5 [4 h) A/ D' u/ s+ I. L- C# D7 h) P
contract Registry {
9 d! R4 O. q1 b* g  I0 e4 D* w1 o3 G$ G+ _1 p
  mapping(bytes32 => address) resolver;
6 ?0 L. {* O% w+ [( g7 m' C. C
! z+ U& c% c$ N* I$ M  function cfAddress(bytes code) returns (bytes32) { ... }# W( i& K! x9 \# u

7 O2 n& l5 s3 f! B- V3 \: R7 K  function deploy(bytes code) { ... }
, b  B6 N, B9 V9 M# z: G) U5 M' ~
1 a$ H% c) a4 h  function proxyCall(Registry r, bytes32 addr, bytes data) { ... }% F5 i: `" Z: s

" ~) C8 P: Y' B& b}) u9 Z* s7 T+ I1 ?
, f, V  ~+ t' n' K' H' G# C+ E
所以,如果你想部署一个合约,你需要用交易调用 deploy 函数,并以合约的 initcode(初始码)作为参数(一般来说,它是与 ABI 编码的构造函数参数连接的合约构造函数字节码)。这个函数把智能合约部署到链上,并且把合约地址加到注册映射表中。% z5 X, Z& o/ I5 R6 c
7 g  \+ w2 @! s* P3 [
以这种方式,你可以通过注册表中的解析器创建相互引用并互相依赖的链下合约。那么,要是想让我们上述例子中的通道运行起来,我们就得通过注册合约来部署支付通道,在多签钱包的条件支付中解析出支付通道的地址。
; ]3 B8 F: N4 B! e& r, A; o0 u7 H- i1 g! {: j# `# w! H5 f9 T
###依赖( q; k, t8 T$ W5 B8 U) ~
7 @) R5 S$ F/ q/ Z3 C! c" d
注册合约允许我们做的就是可以建立互相依赖的链下合约,就像合约 A 依赖于合约 B,只有在 B 最终确定之后,A 才能确定(条件层级确定性)。1 o8 S3 M5 O0 Q, _; Y% k5 F
) p: y  `. F. I- i
-以上我们可以看到,除非 Nonce 合约确定了,否则 PC 合约无法确定。-5 Y: C- }; Z& z0 z
  e. `! ]9 L' k; [$ S
你看,上面是一个比较基础的例子,我们要求当前合约基于另一个合约的布尔条件值。我们可以扩展这个条件,允许所谓的“原子状态转换”。
7 ~4 ?- }9 f! Q2 g4 u
2 @, u( ^: w) K) }) L- F& K###原子状态转换
  G9 Y% O# C7 L* x
# {6 r! ?/ g, e) ]' z( G根据这种层级的依赖结构,我们可以进行原子状态转换,转换的同时,伴随着一些合约生效,一些合约失效。下面例子表明,一个 10 ETH 的支付通道,基于 nonce 值,转换为一个 8 ETH 的支付通道,加一个 2 ETH 的扑克游戏。4 E  b. w! O* L. x8 s$ b
: c; ?" q. b1 B2 E
-合约的有效性基于 nonce 值-
, V6 G+ W# A, Q% E6 a# x$ G$ v% V' r1 G
如果支付通道的双方都同意用支付通道里的 2 ETH 来创建一个扑克游戏,他们可以签署支付通道的余额更新变化,从(5,5)到(4,4),同时签署一个内置 2 ETH 的扑克合约,nonce 合约的 nonce 值是 4 的时候,这两个合约才会生效。
  a) V4 l, S; p% J9 @. g6 m, I+ J& F: o! Y( d2 z
-基于新 nonce 值的原子状态转换-
6 O! Z- ~9 F! D" r" ?: D4 |3 D+ d% J& v. P) C+ {% g
当支付通道的双方都签署了支付通道和扑克合约的条件更新之后,他们可以签署 nonce 合约,使得 nonce 值加 1。一旦 nonce 值更新为 4,旧的支付通道状态就会失效,同时扑克合约和新的支付通道状态就会生效。2 b  C. k' x  S

, m9 q1 x: E" ?! J  r; T4 w) C有原子状态转换,代码升级就会变得容易。如果之前支付通道的参与双方想修复代码中的 bug,他们可以在更新余额的时候修复代码。当更新 nonce 值后,之前有 bug 的代码就失效了。
! Z9 F! D2 b9 |) D' G7 h3 ]/ A6 j, s  Y- ?! L0 K
下面有个例子,这就是基于“根 nonce”合约的一系列反事实合约:. y8 E& s! v" a) Y! F5 |
6 ^( S# f0 J" ^: F% k3 U
根据这种架构,我们可以通过一个“根 nonce”合约有条件地更新所有链下合约的有效性。这允许我们可以根据参与方的需求,迭代地从状态通道中添加和删除链下合约。( s6 x! y, }1 l; b

# w( d7 o% |" l配置通道- L- V" ^# |- W+ p

. w* t4 n# t1 l假设我和阿剑想玩四子连珠的游戏。我们将会这样做:( f$ ]) h& z2 o
- Z" z* F, ~$ X( |; a+ c
部署根 nonce 合约、ETH 支付通道(PC)、ETH 条件支付通道(CPC)和四子连珠智能合约/ m1 m2 ?  v7 @4 R

+ p, h0 q7 B, K/ O% S" z% a向四子连珠游戏提交最新的签过名的状态
" S9 i- @4 n7 j' p
4 S* ?0 e- i5 p' ^4 G基于四子连珠的游戏规则确定 CPC3 G3 |: O$ G4 K$ W1 r& a
2 N1 f5 L* k7 T8 S8 w) l5 Z
基于 CPC 确定 PC+ [* s* h" t3 F+ G! W+ z

2 x3 k( U( \  g- y# P向多签钱包提交已签名的条件支付(基于 PC 的最终确定状态进行支付)7 r7 `+ r0 P& J# l0 r- C

: j  Z: R9 F, `/ x' \因此,我们可以一直开启其他状态通道,甚至允许我们重用已经部署在链上的四子连珠游戏的代码。下一次我们想要玩游戏的时候,我们只需要对游戏状态进行签名,然后提交到已经部署好的智能合约上。唯一需要实现的是取消现有链上代码的确定性,这是一个实现细节。2 h0 Y& Z1 E2 ]% ^! h
, X5 f. ?% G, Y/ r3 z0 ^) k5 m
###注意:你不需要像我展示的四子连珠、CPC 和 PC一样,为你的合约加上这么多的依赖。无论你希望怎么做,这都取决于你和你状态通道中的伙伴。
& v) L  h& n. s+ U: h+ o( P
# z; s1 d/ @  h5 s8 e5 v现在,假设阿剑的朋友 Hunter 想跟阿剑玩四子连珠游戏,但是他只跟我开了一个状态通道,这时候 Metachannels 就可以派上用场啦。! [2 p" u0 u8 U

2 _) w5 b6 G5 ?5 X2 Y###Metachannels7 o3 W8 Q( n9 p! n) {% b
) O- B7 O/ H0 v# R6 e
Metachannels 是状态通道上的虚拟通道(参见本系列 Part-4)。要创建一个 Metachannels,你需要两个想交互的参与者,他们各自有一个状态通道,并且通道的另一方是同一个人。两个参与者同意创建一个新的合约,通道另一方(即共同的中心)会与他们一起创建一个代理合约,指向两个参与者的新合约。看起来就像下面这张图:4 l* ^/ ~) f+ h. I

  ]" U; g( ~$ M% C5 ~-广义虚拟状态通道 = Metachannels !-
$ P5 p5 d0 E! G) S& N3 G% V  }6 s/ }3 I
我们可以无限地扩展这个模型,让我们想跟谁玩四子连珠,就能跟谁玩。
4 E7 y9 W/ _( r/ R* F2 ?, i. Q3 Y9 h% ?1 i
###广义状态通道的优点
! @* S2 f1 o1 V; T, C; Q5 l
! q/ u5 h" B. R' }2 X引导——因为我们所需要的只有一个多签钱包,我们可以很容易在链上现有的多签钱包中选择一个开始开发。# ?* w; a; o/ O5 c7 D) D! `
6 I. J: j: a3 z6 e7 C( C
隐私——除了参与者之外,没有人知道状态通道内发生了什么,对于外部世界来讲,参与者之间只有一个多签钱包。5 s; W5 {  s0 l' z# K' Y7 _

+ n8 h/ _. M, J" u1 i8 o可升级——如果链下代码中有 bug,所有参与者可以通过链下的操作修复 bug,不需要进行任何链上操作。
4 Q8 G' G9 q# L
6 n# D: q. u: k可重用——这种方法有效地鼓励了通用链上库的形成,让所有状态通道都可以引用。; c5 q& k2 W. Q! c6 c) H6 B6 V9 c
( ]2 e; x  w$ j" _0 d# s
###Part-6:反讹诈
2 e; ~; E! u: R0 N+ u' q% L' T  E7 _+ n
在我下一篇博文中,我将会深入讲解状态通道中的反讹诈。讹诈即是说参与者向通道提交一个对自己更有利的较早状态。博文的焦点是 Pisa.
BitMere.com 比特池塘系信息发布平台,比特池塘仅提供信息存储空间服务。
声明:该文观点仅代表作者本人,本文不代表比特池塘立场,且不构成建议,请谨慎对待。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

成为第一个吐槽的人

fzny61226 初中生
  • 粉丝

    0

  • 关注

    0

  • 主题

    22