Bitcoin-Compatible Virtual Channels
- 发表信息： S&P-2021
- UTXO： Unspent Transaction Output
- ledger channel（账本通道）： 作者将所有直接通过区块链建立的通道统称为账本通道。
- Abstract： 此前在基于UTXO模型的比特币里，只支持payment channel（支付通道）的链下扩展方案，而基于账户模型的以太坊上的Virtual channel（虚拟通道）无法兼容比特币。本文提出了第一个基于UTXO模型的虚拟通道协议，用于兼容与比特币相似的加密货币。
- 虚拟通道的第一篇论文： 2019-IEEE SP-Perun: Virtual Payment Hubs over Cryptocurrencies
- 作者给出了两种类型的虚拟通道：
- virtual channel with validity（VC-V）： 有时效性的虚拟通道（开放时间有限），中间人无法在有效时间内主动将虚拟通道转化为账本通道。
- virtual channels without validity（VC-NV）： 无时效性的虚拟通道（开放时间无时间限制，关闭时机由参与者决定）
背景介绍：
- t x ( t r a n s a c t i o n ) ： ( t x . t x i d , t x . I n p u t , t x . O u t p u t , t x . T i m e L o c k , t x . W i t n e s s ) tx(transaction)：(tx.txid,tx.Input,tx.Output,tx.TimeLock,tx.Witness) tx(transaction)：(tx.txid,tx.Input,tx.Output,tx.TimeLock,tx.Witness)
- 文中图形含义：
- 双线圆角方框： 表示已经在链上发布的交易
- 单边圆角方框：表示可以在链上公布但是还未公布的交易
- 圆角方框里的矩形方框：代表交易输出
- 矩形方框内：输出金额
- 输出箭头上的符号：输出条件
Payment Channel（支付通道）
- x A x_A xA x B x_B xB：A和B打开通道时放入的钱。
- T X f TX_f TXf（funding transaction）：用于通道创建。
- T X c TX_c TXc（commit transaction）：用于通道余额更新，代表两个用户对渠道新平衡的承诺。
Generalized channels（通用通道）
- 相关论文： 2020_Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures
- T X c TX_c TXc（commit transaction）：负责惩罚内容
-
T
X
s
TX_s
TXs（split transaction）：保存通道的实际输出
论文贡献：
- 基于UTXO模型构建了虚拟通道协议。
- 作者设计了两种不同的构造： 1.虚拟通道保证了在编码有效期周期内保持链下状态。2.打开虚拟通道的中间人可以自主选择是否退出，从而将虚拟通道转化为另外两个参与方的直接通道。
- 将虚拟通道的安全属性形式化为 uc 框架中的理想功能，并证明了协议的安全性。
- 作者分别在Lightning Network 和 Generalized channels上做了实验，展现了其协议的兼容性和优越性。
文中符号定义：
- 账本通道的定义元组：
γ
:
=
(
γ
.
i
d
,
γ
.
A
l
i
c
e
,
γ
.
B
o
b
,
γ
.
c
a
s
h
,
γ
.
s
t
)
γ := (γ.id, γ.Alice, γ.Bob, γ.cash, γ.st)
γ:=(γ.id,γ.Alice,γ.Bob,γ.cash,γ.st)
- γ . i d γ.id γ.id：通道标识符
- γ . A l i c e , γ . B o b ∈ P γ.Alice, γ.Bob ∈ P γ.Alice,γ.Bob∈P：通道双方身份
- γ . c a s h ∈ R ≥ 0 γ.cash ∈ R≥0 γ.cash∈R≥0：通道中锁定的金额
- γ . s t = ( θ 1 , . . . , θ n ) γ.st = (θ_1, . . . , θ_n) γ.st=(θ1,...,θn)：通道的状态
- 通道状态 θ i θ_i θi 由两个输出属性组成：
- θ i . c a s h ∈ R ≥ 0 θ_{i}.cash ∈ R≥0 θi.cash∈R≥0：输出金额
- θ i . φ : θ_{i}.\varphi: θi.φ: {0,1} ∗ × N × N → ^{∗}× N × N → ∗×N×N→ {0,1}：输出条件
- 虚拟通道定义元组：
γ
:
=
(
γ
.
i
d
,
γ
.
A
l
i
c
e
,
γ
.
B
o
b
,
γ
.
c
a
s
h
,
γ
.
s
t
,
γ
.
I
n
g
r
i
d
,
γ
.
s
u
b
c
h
a
n
,
γ
.
f
e
e
,
γ
.
v
a
l
)
γ := (γ.id, γ.Alice, γ.Bob, γ.cash, γ.st, γ.Ingrid, γ.subchan, γ.fee, γ.val)
γ:=(γ.id,γ.Alice,γ.Bob,γ.cash,γ.st,γ.Ingrid,γ.subchan,γ.fee,γ.val)
- γ . i d ∈ γ.id∈ γ.id∈ {0,1} ∗ ^∗ ∗：通道标识符
- γ . A l i c e , γ . B o b ∈ P γ.Alice, γ.Bob ∈ P γ.Alice,γ.Bob∈P：通道双方身份
- γ . c a s h ∈ R ≥ 0 γ.cash ∈ R≥0 γ.cash∈R≥0：通道中锁定的金额
- γ . s t = ( θ 1 , . . . , θ n ) γ.st = (θ_1, . . . , θ_n) γ.st=(θ1,...,θn)：通道的状态
- γ . I n g r i d ∈ P γ.Ingrid ∈ P γ.Ingrid∈P：表示虚拟通道构建的中间人
- γ . u s e r s : = γ.users := γ.users:= { γ . A l i c e , γ . B o b , γ . I n g r i d γ.Alice, γ.Bob, γ.Ingrid γ.Alice,γ.Bob,γ.Ingrid }：用户集合
- γ . s u b c h a n γ.subchan γ.subchan：1. γ . s u b c h a n ( γ . A l i c e ) γ.subchan(γ.Alice) γ.subchan(γ.Alice)表示 γ . A l i c e γ.Alice γ.Alice 和 γ . I n g r i d γ.Ingrid γ.Ingrid 之间的通道标识。2. γ . s u b c h a n ( γ . B o b ) γ.subchan(γ.Bob) γ.subchan(γ.Bob)表示 γ . B o b γ.Bob γ.Bob 和 γ . I n g r i d γ.Ingrid γ.Ingrid 之间的通道标识。
- γ . f e e ∈ R ≥ 0 γ.fee ∈ R≥0 γ.fee∈R≥0：中间节点Ingrid收取的费用
- virtual channel with validity（VC-V）： 有时效性的虚拟通道（开放时间有限），中间人无法主动将账本通道转化为虚拟通道。
- virtual channels without validity（VC-NV）： 无时效性的虚拟通道（开放时间无时间限制，关闭时机由参与者决定）
虚拟通道的安全属性：
- (V1) Balance security： 如果中间人 γ . I n g r i d γ.Ingrid γ.Ingrid是诚实的，那么即使 γ . A l i c e γ.Alice γ.Alice 和 γ . I n g r i d γ.Ingrid γ.Ingrid勾结， γ . I n g r i d γ.Ingrid γ.Ingrid也不会损失余额。
- (V2) Offload with punish： 如果选择构建的是无时效性虚拟通道，中间人可以主动把当前的虚拟通道转化为账本通道。
- (V3) Validity with punish： 如果选择构建的是有时效性虚拟通道， γ . A l i c e γ.Alice γ.Alice 需要在时效期内将虚拟通道转化为账本通道，如果在时效期内虚拟通道没有被转换或者关闭的话 γ . I n g r i d γ.Ingrid γ.Ingrid 和 γ . B o b γ.Bob γ.Bob将获得补偿
Virtual Channel的构建过程：
1）High level protocol description（理论方面的描述）
- θ A θ_A θA θ B θ_B θB：代表A和B在创建虚拟通道时请求更新的状态。
- Create：
- 步骤一： A A A 和 B B B 启动各自与 I I I 之间通道的更新， I I I 收到 A A A B B B 的请求后将检验双方的请求是否一致。
- 步骤二： A A A B B B 双方用他们子通道的标识符 t i d A tid_A tidA 和 t i d B tid_B tidB 来构建虚拟通道。
- 步骤三： A A A B B B I I I 三方都进入虚拟通道结构的设置阶段（setup virtual channel），三方都对这个虚拟通道的 funding transaction 达成共识，在区块链上发布后将虚拟渠道转换为账本渠道（ledger channel）。
- 步骤四： 虚拟通道设置完成，参与三方都完成了账本通道的更新程序。
- 步骤五： 中间人等待
A
A
A
B
B
B 双方的状态完全更新完成之后，才会发送给
A
A
A
B
B
B 最终的更新许可，完成虚拟通道的更新。
- Update：
- 虚拟通道的更新过程与账本通道基本相同。
- 虚拟通道解决争端的方法和账本通道的方法相似，诚实一方可以通过向链上发布最新的状态从而强制关闭通道拿回自己的钱。虚拟通道和账本通道的差别在于，虚拟通道不是直接在链上构建的。因此，发生争端时首先需要把交易信息发布到链上将虚拟通道转换为账本通道。 - Close：
关闭虚拟通道是通过更新账本通道 α \alpha α 和 β \beta β 上虚拟通道的最终状态来实现的。
P ∈ P\in P∈ { A , B A,B A,B } ：表示参与者集合
θ ⃗ P \vec{\theta}_P θP := { ( c P , O n e − S i g p k P ) , ( γ . c a s h − c P , O n e − S i g p k P ) (c_P,One-Sig_{{pk}_{P}}),(\gamma.cash-c_P,One-Sig_{{pk}_{P}}) (cP,One−SigpkP),(γ.cash−cP,One−SigpkP)} ： c P c_P cP表示参与者 A , B A,B A,B 在虚拟通道 γ \gamma γ 里的最后余额。
通道关闭的具体过程：- 参与双方更新各自的账本通道的状态 θ A \theta_A θA θ B \theta_B θB ,中间方 I I I 等待 A , B A,B A,B 更新状态。
- 中间方 I I I 接收 A , B A,B A,B 双方的更新状态 θ A \theta_A θA θ B \theta_B θB
- 中间方 I I I 同意更新他与 A , B A,B A,B 间的账本通道 α \alpha α 和 β \beta β 的状态。
- 最后所有参与者更新了账本通道的状态之后，虚拟通道将被关闭。
在不好的情况下，如果 A , B A,B A,B所更新的通道状态 θ A \theta_A θA θ B \theta_B θB 不一致，参与者需要发布funding transaction (offloading) ，先关闭其账本通道从而强制关闭虚拟通道。
- Offload： In a nutshell, during this procedure, parties try to publish the commit and split transactions of both underlying ledger channels and afterward the funding transaction of the virtual channel. In case offloading is prevented by some form of malicious behavior, parties can engage in the punishment procedure to ensure that they do not lose any funds.（通过将funding transaction提交到链上，将虚拟通道转变成账本通道）
- Punish（惩罚）： 和账本通道上一样，作恶的一方会失去虚拟通道上的所有钱。另外中间方不会有任何损失。If the funding transaction of the virtual channel is posted on the ledger, the virtual channel is transformed into a ledger channel and parties can execute the regular punishment protocol for ledger channels.
2）Concrete Instantiation Without Validity（具体构建过程）
- Create：
- T X f TX_f TXf：虚拟通道创建时产生的funding transaction
- T X S A TX_{S}^{A} TXSA（split transaction）：虚拟通道创建时 A A A 与 I I I 的账本通道 α \alpha α 的资金输入
- T X S B TX_{S}^{B} TXSB（split transaction）：虚拟通道创建时 B B B 与 I I I 的账本通道 β \beta β 的资金输入
- A A A 和 B B B 的两个通道分别贡献了 c + f / 2 c+f/2 c+f/2 的资金，总共 2 c + f 2c+f 2c+f，其中用资金c创建虚拟通道，另外的资金c用于当做 I I I的抵押品（是 I I I 的钱），资金 f f f 是付给 I I I 的服务费。
- 创建虚拟通道是通过创建 funding transaction、commit 和 split transactions来完成的。
- Offload：
- I I I 可以通过关闭与 A A A B B B 之间的账本通道并发布虚拟通道上的funding transaction来关闭他所参与构建的虚拟通道。
- 一个成功的通道关闭过程，需要发步两个账本通道上的 split transactions，以便最终可以发布虚拟渠道的融资交易，从而完成卸载过程。（个人理解： funding transaction的输入时split transaction的输出，所以想要将funding transaction放到链上就必须把split transaction一同放到链上，这样输入输出才是完整的）
- 而
A
A
A
B
B
B 任意一方都无法单独关闭通道，但是他们可以通过提交 commit 和 split transaction 去强制
I
I
I 关闭通道。（个人理解： 由于想要关闭通道必须得向链上发布两个split transaction 和一个funding transaction，而Ingrid作为中间人可以直接发布这三个transaction，而A和B无法发布对方的split transaction）
- Punish（惩罚）：
- 文中说如果B作恶，I会得到B在账本通道里所有的钱，而这样所导致的I的错误链上状态提交，也会让I与A通道里的钱全部赔偿给A。
- 文中说如果B作恶，I会得到B在账本通道里所有的钱，而这样所导致的I的错误链上状态提交，也会让I与A通道里的钱全部赔偿给A。
3）Further discussion regarding our constructions:
- Concurrency：
- 以往打开虚拟通道时账本通道会被锁定。作者提出通道分割技术加以解决，使得打开虚拟通道的同时，原本的账本通道也可正常使用。
- Virtual channels over Lightning：
- T X c A TX_{c}^{A} TXcA： Alice commit transaction
- T X c B TX_{c}^{B} TXcB：Bob commit transaction
- x A x_A xA：Alice 的钱
- x B x_B xB：Bob 的钱
- Δ \Delta Δ：发布交易到区块链上所需要的时间上限。
- ϱ A \varrho_A ϱA：the verification of A’ revocation secret
- ϱ B \varrho_B ϱB：the verification of B’ revocation secret.
- T X c A TX_{c}^{A} TXcA T X c I A TX_{c}^{IA} TXcIA：Alice 和 Ingrid 通道上的commit transactions
- T X c B TX_{c}^{B} TXcB T X c I B TX_{c}^{IB} TXcIB：Bob 和 Ingrid 通道上的commit transactions
- 闪电网络通道构成图：
- Virtual Channels With Validity： 前面说到的虚拟通道都是没有时效性的，需要构建通道的中间人一直监控通道，并且通道是否关闭由参与者决定。作者提出Virtual Channels With Validity，要求通道在有效期内无法关闭，这样中间人在有效期时间内就不需要时刻盯着通道防止通道的另外两方作弊。
Lightning Network：
个人理解：
- Alice 和 Ingrid建立支付通道是向链上发布 funding transaction，而Alice和Bob建立虚拟通道的时候，他们也是先创建一个funding transaction，这个funding transaction不向链上发布，在正常情况下，Alice和Bob在虚拟通道上还是跟账本通道上一样的方式更新余额，关闭通道的时候Alice和Bob把最新的余额更新信息发给Ingrid，然后Ingrid确定之后，Ingrid会按照最新的余额信息更新他与Alice Bob之间的账本通道余额。如果中间有了争议，他们就可以把funding transaction提交到链上，这样他们的虚拟通道就变成了账本通道，其争议解决办法按照支付通道的规则来办就好了。
virtual channel without validity 和 virtual channel with validity：
文中关键内容摘录：
- We present the first protocols for virtual channel hubs that are built for the UTXO-model and require a scripting language supporting only digital signature verification and timelock functionality，being thus compatible with virtually every cryptocurrency, including Bitcoin.
附录符号定义
- F V F_{V} FV：Ideal functionality for virtual channels
- F L F_{L} FL：ledger channel functionality
- S S S：simulator
- τ \tau τ：channel space
452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
