【论文笔记】boros协议的UC框架下安全性证明

4 UC框架下的形式化定义

协议安全性的定义

直观来讲，在理想的世界（ideal world）中，有理想函数和模拟器，分别对应现实世界中的协议和敌手。模拟器不但要模拟敌手，还要模拟parties，来和环境交互。在理想函数中，我们定义了哪些数据是可以泄露给模拟器的，根据环境所给的input， 模拟器根据泄露的数据模拟相应的操作，生成相应的output给环境。如果环境无法区分跟它交互的是现实中parties还是理想世界中的模拟器，那么，我们说现实世界的协议实现了该理想函数。

现实世界包含：协议$\pi$、敌手$\mathcal{A}$
理想世界包含：理想函数$\mathcal{F}$、模拟器$\mathcal{S}$

环境$\mathcal{Z}$可以向理想世界、现实世界的各方提供输入，读取所有输出，可以和敌手进行任意的通信

我们说协议$\pi$是安全的：环境无法分辨与它交互的是现实世界还是理想世界

通信模型假设

为简单起见，假设协议在一个同步网络运行，即满足以下条件：

1）所有节点一轮一轮地运行，且同时开始运行协议
2）所有在第i轮的消息，会在第i+1轮开始前到达目的地
3）假设理想函数的计算以及消息在网络中的传播时间为0

更详细的关于同步网络的参考在[16,17,20]

账本理想函数${\mathcal{F}}_{\mathcal{L}}$

借鉴[9]，使用一个账本函数${\mathcal{F}}_{\mathcal{L}}$，其中包含的内部状态（对象属性）就是一个map，key为地址（外部地址+合约地址），value为地址所持余额。

这个账本函数提供一个接口transfer，提供交易功能，通过发送消息(transfer, sid, αi, αj , p)可以将p数额的资金从${\alpha }_i$转移给${\alpha }_j$

简单来说，理想函数也有一个特殊的账户地址${\alpha }_f$，当之后的描述出现：“理想函数${\mathcal{F}}_f$收到了A的消息，消息携带了p数额的资金”或“理想函数${\mathcal{F}}_f$向A（不是敌手，就是一个通道内成员，向上面的例子一样）发送了携带p数额资金的消息”，都相当于${\mathcal{F}}_f$向${\mathcal{F}}_{\mathcal{L}}$发送消息，调用接口，实现资金在两个账户之间的转移，更多细节参考[22]

channel hub functionality ${\mathcal{F}}_{\mathcal{N}}$

内部状态也是一个map，key是支付通道对应地址（合约地址），value是这个通道的总余额，一个通道加入了这个channel hub，那么相应的k-v数据就加入了相应的map，退出就是删除了对应k-v

${\mathcal{F}}_{\mathcal{N}}$提供的接口：加入、退出、转账

${\mathcal{F}}_{\mathcal{N}}$：

文章解释了一下这几个接口的流程：
1）加入join：当${\mathcal{F}}_{\mathcal{N}}$收到一条来自一个理想函数的请求加入消息（携带了c数额的资金）时，$F_N$会标记上对应通道加入了hub，总余额为c
2）交易transfer：当${\mathcal{F}}_{\mathcal{N}}$收到一条来自A的iou请求消息$(iou,{\beta }_{AC},{\beta }_{BD},∆x)$和一个B发送的receipt时，${\mathcal{F}}_{\mathcal{N}}$会标记$△x$数额的资金从原通道转到另一个通道
3）退出withdraw：通过向${\mathcal{F}}_{\mathcal{N}}$发送退出请求消息，一个通道可以随时从hub中退出，${\mathcal{F}}_{\mathcal{N}}$会向通道的链上账户发送它的余额，并标记上他已经退出

contract functionality ${\mathcal{F}}_{\mathcal{C}}$

对应的是一个支付通道在链上的合约集合，他持有多个实例，对应着多个支付通道。一个通道打开，就加入这个集合，关闭就移除这个集合。包含的接口：open、join、withdraw、close

UC框架下的安全性定义

$EXE{C}_{boros,\mathcal{A},\mathcal{Z}}^{{\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}}}(\lambda ,x)$：boros和${\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}}$自由通信的协议，也可以和环境$\mathcal{Z}$和安全参数为$\lambda$的敌手$\mathcal{A}$进行通信，辅助的输入用$x$表示， x ∈ { 0 , 1 } ∗ x\in \{0,1\}^* x∈{0,1}∗

$IDEA{L}_{{\mathcal{F}}_{\mathcal{H}},\mathcal{S},\mathcal{Z}}^{{\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}}}(\lambda ,x)$：对应理想世界

定义1：我们说协议boros实现了理想功能${\mathcal{F}}_{\mathcal{H}}$，当对于任意一个敌手$\mathcal{A}$，存在一个模拟器$\mathcal{S}$，使得在任何PPT环境下，$EXE{C}_{boros,\mathcal{A},\mathcal{Z}}^{{\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}}}(\lambda ,x)$和$IDEA{L}_{{\mathcal{F}}_{\mathcal{H}},\mathcal{S},\mathcal{Z}}^{{\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}}}(\lambda ,x)$在计算上不可区分。写成这个样子：

其中的约等于号即表示计算上不可区分 computational indistinguishability

A.Boros协议对应的理想函数${\mathcal{F}}_{\mathcal{H}}$

${\mathcal{F}}_{\mathcal{H}}$维护两个通道空间，一个是尚未加入channel hub的通道集合 B : β → { c , θ w } \mathcal{B}: \beta\rightarrow\{c,\theta_w\} B:β→{c,θw​}，其中的$\beta$是通道对应合约地址，c为通道总余额，${\theta }_w$为版本号为w的通道内部余额分布情况，可以将它看作一个函数，例如AC通道内A在第w歌版本的余额为${\theta }_w^{AC}(A)$，所以说$c={\theta }_w(A)+{\theta }_w(C)$且${\theta }_{w_i}(P)>=0$，版本号w单调递增，初值为1.

另一个通道空间为 B ⊄ : β → { c , θ w } \mathcal{B}_{\not\subset}: \beta\rightarrow\{c,\theta_w\} B⊂​:β→{c,θw​}，表示已经加入hub的通道，某通道加入hub就是将他的状态信息从$\mathcal{B}$移进${\mathcal{B}}_{\not\subset }$，反过来也一样

${\mathcal{F}}_{\mathcal{H}}$提供的接口：打开通道、通道内交易、加入hub、跨通道交易、退出hub、关闭通道

1）打开通道：${\mathcal{F}}_{\mathcal{H}}$收到来自A和C的打开请求，分别包含余额$x_a,x_c$，认为通道可以打开，${\mathcal{F}}_{\mathcal{H}}$本地存储相应状态信息
2）通道内交易：包含一个两阶段过程，接收A发送的更新请求，${\mathcal{F}}_{\mathcal{H}}$向C请求确认消息，C回复确认消息后，${\mathcal{F}}_{\mathcal{H}}$就更新相应通道的余额分布状态
3）加入hub：只有当一个通道内状态被2个通道成员达成共识，且此通道尚未加入任何hub时，它才能申请加入一个hub. 当${\mathcal{F}}_{\mathcal{H}}$接收到A发送的请求加入hub消息，${\mathcal{F}}_{\mathcal{H}}$向C请求确认加入消息，C回复确认消息后，${\mathcal{F}}_{\mathcal{H}}$就更新相应通道的加入状态
4）跨通道交易：只能在已经加入同一hub的2个通道之间发生。包括一个三阶段过程，准备阶段时两个通道对于交易的发生表示同意，余额转移阶段时${\mathcal{F}}_{\mathcal{H}}$收到来自A（交易发起方）的iou消息和来自B的receipt消息就更新通道余额状态，最后一个阶段由通道内交易请求触发，A和B分别在各自通道发起通道内余额分布更新请求，${\mathcal{F}}_{\mathcal{H}}$得到C和D的确认后就更新两通道内的余额分布状态
5）退出hub：只有已经加入hub的通道才能退出（这种废话必不可少），${\mathcal{F}}_{\mathcal{H}}$收到来自通道某一方的退出请求，标记其已退出，并输出退出成功消息（这里的输出理解为向环境输出，让环境知道当前系统的状态），理想函数保证一个诚实节点一定可以申请他所在通道再一段固定时长内成功退出hub
6）关闭通道：${\mathcal{F}}_{\mathcal{H}}$收到通道某一方的退出请求后，将节点资金在3轮之内退回链上账户，理想函数保证一个诚实节点一定可以在一段固定时长内成功退出所在支付通道

下面解释一下为什么这样的理想函数可以满足上面所提到的安全性，即：

Boros可以保证以下安全特性：
1、诚实节点们对于某通道或节点是否加入了channel hub总是能达成一致
2、诚实节点们对于某通道或节点在hub的余额总是能达成一致
3、诚实节点绝不会损失资金

1.${\mathcal{F}}_{\mathcal{H}}$会输出（广播）给所有节点通道加入或退出的结果，所以保证了hub内所有party的一致性视图
2.${\mathcal{F}}_{\mathcal{H}}$会输出（广播）给所有节点通道$m_{ct}$消息，保证所有节点对通道余额分布的一致性视图
3.诚实节点资金的安全性包含两方面，一方面是上面第二点，另一方面是通道内部余额分布状态的正确性，由版本号保证，使得节点退出通道时，其余额遵循最新版本状态，回归到链上账户中去

B. Boros协议

下面就是对Boros协议的形式化定义，它包括了图4所示的合约函数${\mathcal{F}}_{\mathcal{C}}$以及图5、6中的各个节点角色行为规范

图5展示的是和传统支付通道相同的部分。
1）打开通道：A使用$x_a$代币（在第一轮）部署合约实例${\mathcal{F}}_{\mathcal{C}}$，部署后，合约实例发送打开请求给C，一旦合约在下一轮之内（第三轮之前）收到C的确认消息以及代币$x_c$，则通道${\beta }_{AC}$打开成功，否则合约就要给A退款并且输出（给环境）打开失败的消息。
2）通道内交易：一旦通道打开，节点就可以在没有区块链的参与下进行通道内交易。首先A向C发送通道内更新请求，其中包含了一个新版本的余额分布函数${\theta }_{w+1}$，C收到此请求后，他会检查请求中包含的通道${\beta }_{AC}$的余额分布是否满足：${\theta }_{w+1}(A)+{\theta }_{w+1}(C)={\theta }_w(A)+{\theta }_w(C)$，若满足C就向环境$\mathcal{Z}$发送更新请求（update-request），问询其是否同意更新，若环境回复update-ok消息，则C向A发送确认消息，完成更新。其中的余额检查是十分必要的因为支付通道的余额变化只能由跨通道交易导致。
3）关闭通道：A向合约${\mathcal{F}}_{\mathcal{C}}$发送包含某版本（A若是诚实节点，就会发送其本地持有的最新版本）余额分布函数${\theta }_{w1}$的关闭请求，合约收到后转发给C，若在下一轮内C回复了某版本的余额分布函数${\theta }_{w2}$，那么合约计算最新版本号$w=max(w1,w2)$，根据此版本余额分布给A和C发送链上资金。

扩展功能在图6里
1）加入hub：A发送消息给C，消息包含（目标加入的hub实例${\mathcal{H}}_{\not\subset }$、通道资金c、通道最新版本状态${\theta }_w$、A对此消息的签名${\sigma }_A$），C收到后发送join-request给环境$\mathcal{Z}$，环境回复$join-ok$后，C向合约${\mathcal{F}}_{\mathcal{C}}$发送包含了A和C签名的加入请求，合约收到后在链上向hub${\mathcal{F}}_{\mathcal{N}}$发送c资金，加入hub就完成了
2）跨通道交易：3阶段过程。prepare阶段，A和B分别向C和D发送$m_{pcc}$消息，表明自己要和B或A在hub${\mathcal{H}}_{\not\subset }$内进行交易，交易金额为$△x$，若C或D验证通过（看A在通道$\beta AC$内的余额是否少于$△x$）并同意就向ABD或ABC发送$m_{gcc}$消息（包含C对$m_{pcc}$的签名），最终所有节点持有$m_{gc{c}_{AC}}$和$m_{gc{c}_{BD}}$消息；capacity transfer阶段，A代表通道${\beta }_{AC}$向hub${\mathcal{F}}_{\mathcal{N}}$（链下中心化服务器）发送iou消息，${\mathcal{F}}_{\mathcal{N}}$验证后传递给B，B验证后回复receipt（包含B的签名）给${\mathcal{F}}_{\mathcal{N}}$，然后${\mathcal{F}}_{\mathcal{N}}$更新本地账本里2个通道地址对应的余额，更新成功后回复A和B确认消息conf（$m_{ct}$）；in-channel update阶段，A向C发送icu（res）消息，包括上一阶段的执行结果（余额分布函数${\theta }_{w+1}$，即${\theta }_{w+1}(A)={\theta }_w(A)-△x且{\theta }_{w+1}(B)={\theta }_w(B)+△x$）和hub的服务中心对结果的签名，C收到后验证有效性，回复确认消息conf。B和D之间的消息交换类似
3）退出hub：A向合约${\mathcal{F}}_{\mathcal{C}}$发送包含最新版本余额分布和通道总余额的消息，合约通知C，C回复同意并签名后，合约发送退出hub请求给${\mathcal{H}}_{\not\subset }$

c.安全定义

篇幅原因，写在附录里了

定理：boros协议安全地实现了 $({\mathcal{F}}_{\mathcal{L}},{\mathcal{F}}_{\mathcal{N}},{\mathcal{F}}_{\mathcal{C}})$混合模型中的理想函数${\mathcal{F}}_{\mathcal{H}}$

证明：

环境Z的任何输入都被转发到敌手$\mathcal{A}$，$\mathcal{A}$的任何输出都被复制成为$\mathcal{S}$的输出

$\mathcal{S}$是这样模拟的：

1）打开通道：\mathcal{S}来模拟${\mathcal{F}}_{\mathcal{C}}$和诚实节点的行为。1.环境$\mathcal{Z}$向A发送$(open,sid,{\beta }_{AC},x_a)$，向C发送$(open,sid,{\beta }_{AC},x_c)$；（上帝指示A和C进行交易）2.若A没有腐败，则在第一轮向${\mathcal{F}}_{\mathcal{C}}$发送$(open,sid,{\beta }_{AC},x_a)$，以及$x_a$量的代币（A发起通道建立请求）；若A腐败了，整个过程终止；3.$\mathcal{S}$向${\mathcal{F}}_{\mathcal{L}}$发送$(transfer,sid,A,{\alpha }_{\mathcal{C}},x_a)$（A的锁定资金锁入合约内部），以${\mathcal{F}}_{\mathcal{C}}$的名义向C发送$(opening,sid,{\beta }_{AC})$（通知C，A已经锁钱了，通道正在打开中）；4.下一轮，若C向${\mathcal{F}}_{\mathcal{C}}$发送$(open,sid,{\beta }_{AC},x_c)$以及代币$x_c$（C也锁定资金），则$\mathcal{S}$向${\mathcal{F}}_{\mathcal{L}}$发送$(transfer,sid,C,{\alpha }_{\mathcal{C}},x_c)$（C的资金锁入合约），并以${\mathcal{F}}_{\mathcal{C}}$的名义输出$(opened,sid,{\beta }_{AC},c)$（通知通道打开成功）；若C腐败了，没有向${\mathcal{F}}_{\mathcal{C}}$发送$(open,sid,{\beta }_{AC},x_c)$以及代币$x_c$，那么$\mathcal{S}$以${\mathcal{F}}_{\mathcal{C}}$的名义向${\mathcal{F}}_{\mathcal{L}}$发送$(transfer,sid,{\alpha }_{\mathcal{C}},A,x_a)$（退款给A），并在第三轮输出open-failed消息

2）通道内交易：让$\mathcal{S}$模拟诚实节点行为。1.$\mathcal{Z}$向A发送$(update,sid,{\beta }_{AC},\theta )$（上帝指示）；2.若A向C发送了$(updating,sid,{\beta }_{AC},\theta )$，那么$mathcalS$以A的名义向${\mathcal{F}}_{\mathcal{H}}$发送$(update,sid,{\beta }_{AC},\theta )（链下中心化节点接收A的交易请求）$；3.若C未被侵入，并且在下一轮向A发送$(update-ok,sid,{\beta }_{AC},\theta )$（更新消息），那么$mathcalS$以C的名义向${\mathcal{F}}_{\mathcal{H}}$发送$(update-ok,sid,{\beta }_{AC},\theta )$（模拟）；4.若C被入侵，不发送update-ok消息，$\mathcal{S}$怎么模拟呢？分析一下，由于诚实节点不会响应任何非诚实节点参与的更新过程，所以C和A诚实情况下都会发起退出hub和支付通道，当C诚实时就会在退出过程中发送链下状态，此时$\mathcal{S}$以C的名义向${\mathcal{F}}_{\mathcal{H}}$发送$(update-ok,sid,{\beta }_{AC},\theta )$，让这个更新正常发生；当C不诚实，就不响应退出，$\mathcal{S}$向${\mathcal{F}}_{\mathcal{L}}$发送消息，将C的锁定资金转给A

3）加入channel hub：模拟器去模拟诚实节点、${\mathcal{F}}_{\mathcal{C}}$、${\mathcal{F}}_{\mathcal{N}}$的行为。1.$\mathcal{Z}$向A发送$(join,sid,{\beta }_{AC},{\mathcal{H}}_{\not\subset })$（上帝指示）；2.A未被入侵，则在接下来的第1轮向C发送$(join,sid,{\beta }_{AC},{\mathcal{H}}_{\not\subset },c,{\theta }_w,{\sigma }_A)$，则$\mathcal{S}$以A的名义向${\mathcal{F}}_{\mathcal{H}}$发送$(join,sid,{\beta }_{AC},{\mathcal{H}}_{\not\subset })$；若A被入侵，则$\mathcal{S}$终止进程；3.下一轮，C向${\mathcal{F}}_{\mathcal{C}}$发送$(join,sid,{\beta }_{AC},{\mathcal{H}}_{\not\subset },c,{\theta }_w,{\sigma }_A,{\sigma }_C)$，$\mathcal{S}$以${\mathcal{F}}_{\mathcal{C}}$的名义向${\mathcal{F}}_{\mathcal{N}}$发送$(join,sid,{\beta }_{AC},c)$，以${\mathcal{F}}_{\mathcal{N}}$的名义向${\mathcal{F}}_{\mathcal{L}}$发送$(transfer,sid,{\alpha }_{\mathcal{C}},{\alpha }_{\mathcal{N}},c)$，并且输出joined

4）hub内的跨通道交易：模拟器去模拟诚实节点、${\mathcal{F}}_{\mathcal{N}}$的行为。
阶段一：1.$\mathcal{Z}$向A和B发送$(cc-transfer,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset })$（上帝指示）；2.A未被入侵，则在接下来的第1轮向C发送$(pcc,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset })$，则$\mathcal{S}$以A的名义向${\mathcal{F}}_{\mathcal{H}}$发送$(cc-transfer,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset })$；若A被入侵，则$\mathcal{S}$终止进程；3.下一轮，C广播(pcc,sid,\beta_{AC},\beta_{BD},\triangle x,\mathcal{H}_{\not\subset})，，$\mathcal{S}$以C的名义向${\mathcal{F}}_{\mathcal{H}}$发送gcc-ok消息；否则，若C恶意不同意交易，模拟器就终止该进程
阶段二：资金被转入${\mathcal{F}}_{\mathcal{N}}$，模拟器去模拟诚实节点、${\mathcal{F}}_{\mathcal{N}}$的行为。1.A在第3轮向${\mathcal{F}}_{\mathcal{N}}$发送$(iou,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset },m_{gcc}^{AC},m_{gcc}^{BD})$，则$\mathcal{S}$以${\mathcal{F}}_{\mathcal{N}}$的名义向B发送次iou消息；否则，模拟器就终止该进程；3.下一轮，B向${\mathcal{F}}_{\mathcal{N}}$回复$(receipt,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset },m_{gcc}^{AC},m_{gcc}^{BD})$，$\mathcal{S}$以${\mathcal{F}}_{\mathcal{N}}$的名义向A,C,B,D发送$(transferred,sid,{\beta }_{AC},{\beta }_{BD},△x,{\mathcal{H}}_{\not\subset },m_{gcc}^{AC},m_{gcc}^{BD})$
阶段三：1.A向C发送$(inChannelUpdate,sid,{\beta }_{AC},m_{ct},{\theta }_{w+1})$，$\mathcal{S}$以A的名义向${\mathcal{F}}_{\mathcal{H}}$发送icu-request消息；2.下一轮C回复A$(confirm,sid,m_{ct},{\theta }_{w+1})$，S以C (conf-ok) to FH in the name of C.