论文阅读《FairSwap: How to fairly exchange digital goods》报告

论文阅读《FairSwap: How to fairly exchange digital goods》报告

摘要信息

我们引入FairSwap-使用智能合约公平交换数字商品的有效协议。公平交换协议允许发送方S以固定价格p向接收方R出售数字商品x。如果R仅在收到正确的x时付款，则该协议被认为是安全的。我们的解决方案通过依赖在分散式加密货币上执行的智能合约来保证公平，在这种情况下，该合约将充当外部法官的角色，在发生分歧时完成交换。尽管过去有过一些关于在加密货币上建立公平交换协议的建议，但是我们的解决方案具有两个独特的功能，这使得它在用户处理大宗商品时特别有吸引力。这些优势是：（1）最小化在区块链上运行智能合约的成本，以及（2）避免使用昂贵的密码工具，例如零知识证明。除了我们的新协议，我们还为基于智能合约的公平交换提供了正式的安全定义，并证明了我们施工的安全性。最后，我们说明了基本协议的几种应用，并通过原型实现评估了我们方法的实用性，以通过加密货币以太坊公平出售大文件。

基本信息简介

该文章2018年发布在ACM SIGSAC会议上，作者是波兰华沙大学（ University of Warsaw）的教授Stefan Dziembowski，Ruhr University Bochum and TU Darmstadt学校应用密码学的博士生Lisa Eckey，Sebastian Faust三人。
文章主要解决的问题是在不可信的环境下如何完成数字商品（比如文件）的可信交换。在传统模式下需要依赖可信的第三方才能完成该操作，但第三方真的是可信吗？不一定。在脱离第三方的条件下如何完成该操作，文章创造性的提出用智能合约充当可信的第三方来完成数字资产的交换。主要贡献有：

1. 高效的公平交易
2. 行为不正确的证明
3. 对模型安全提出和定义提供了形式化验证
4. 完成了文件交换的应用实例
5. 加入惩罚机制
6. 文件的买卖

背景

买方R希望从卖方S手中购买得到数据x,双方协商的价格是p，为了防止S提供假数据，双方协商并对数据进行验证，x需要满足形式化条件$\varphi (x)=1$。当卖方所提供的数据x满足条件时，买方支付报酬给卖方支付p，然后获得数据；否则，交易失败。在不可信的环境中完成该交易需要第三方的参与，否则交易不可能达成，但现实中第三方不一定可信。在脱离第三方的条件下，不可能完成该操作。分布式加密技术给这个问题提供了解决的思路，利用矿工的操作来维持一个分布式的账本来使得交易双方脱离第三方完成交易，简而言之就是利用加密货币的智能合约来充当可信的第三方，卖家将数据缓存到分布式智能合约上，买家将报酬存到智能合约中，且买家支付钱以后才能获得数据，等买家验证数据正确后卖家方能收到报酬，若双方发生分歧，则由合约进行验证根据验证结果进行选择：

1. 若数据正确，即$\varphi (x)=1$。则S收到R支付的报酬p；
2. 数据不正确，即$\varphi (x)\ne 1$。则智能合约将冻结的报酬p返还给R。

若每次数据交换都由智能合约对x进行形式化验证，则会对智能合约带来巨大的挑战，尤其是x比较大时。为此，文章中中将验证过程交给S和R，只有当R提出异议时，智能合约才对X进行形式化验证，也就是论文中提到的proof of misbeahvior。为了将验证过程进一步简化，x被组织成一个merkle树的形式（根节点的哈希可以转换成其左右子节点的哈希，递归求解可以到叶子节点），这样当R提出异议时智能合约仅需要验证其中的一个叶子节点哈希值的正确性，大大降低了计算的复杂性，降低了智能合约的开销。

基本公式和操作

[n]:表示自然数集合 { 1 , … , n } \{1,\dots, n\} {1,…,n}
hash函数： { 0 , 1 } ∗ → { 0 , 1 } μ \{0,1\}^*\to\{0,1\}^\mu {0,1}∗→{0,1}μ,即无论输入多长总会映射成一个长度为$\mu$的字符串，且输入不同时hash函数的输出结果不同（更确切的说输出相同结果的概率非常小）。

$(c,d)=commit(x)$
x为需要加密的密文，c为加密后的密文，d为一个正数值。

o p e n ( c , d , x ) = { 0 , 1 } open(c,d,x)=\{0,1\} open(c,d,x)={0,1}
当密文与明文对应时输出结果为1，否则为0。
隐藏特性（hiding）：对于任意的明文$x$和$x^{\prime }$,$(c,d)=commit(x)$,$(c^{\prime },d^{\prime })=commit(x^{\prime })$有$c{\simeq }_c{c}^{\prime }$。
绑定特性（binding）：不可能发现一个三元组,满足$open(c,d,x)=1$，$open(c,d^{\prime },x^{\prime })=1$且$x\ne x^{\prime }$。

Merkle树
由n个元素$x_1,x_2,\dots ,x_n$组成的Merkle树可以表示为一个带标签的二叉树M=$Mtree(x_1,\dots ,x_n)$,其中第i个叶节点表示$x_i$。并且非叶子节点$v_j$的值是其两个子节点$v_j^l$，$v_j^r$的哈希值，即$v_j:=H(v_j^l,v_j^r)$。
通过n个元素创建Merkle树的算法如下：

$Mproof$ 输入merkle树的叶子节点索引i，输出从i到根节点索引：

$Mvrfy$输入元素$x_i$验证$x_i$是否在Merkle树的根节点的指定路径上(这个算法理解不一定正确，没太懂）：

$\varphi$关于形式化验证的知识

协议的过程及分析

过程

1. 合约接受到来自S的消息$(init,id,p,c,r_{\varphi },r_z)$后将存储$r_{\varphi },r_z,p,c$，输出$(initialized,id,p,r_{\varphi },r_z,c)$并将状态设定为initializeed执行reveal阶段。
2. 在initialized状态下，合约接受到R的消息$(accept,id)$，相应的冻结R的资产为p，发送$(freeze,id,R,p)$并且等待回应。若R的账户余额小于p则冻结失败，协议结束；冻结成功即收到$(frozen,id,R,p)$,将状态设定为active并且输出$(accepted,i)
3. 在active状态下合约接收来自S的解密密钥，收到消息$(reveal,id,d,k)$并验证$open(c,d,k)=1$则将消息$(revealed,id,d,k)$发送给所有的参与者，合约状态更新为revealed，进入下一状态执行。若此时一直未收到S的解密消息，则将R中冻结的金额解锁并结束协议，解冻时给R发送消息$(unfreeze,id,p,R)$。
4. 合约在revealed状态下接受R的消息m，并将自身状态更新为finalized：
   此时若R对数据x提出异议，向合约发送$(conplain,id,\pi )$时,合约对数据进行验证，即计算$Judge(k,r_z,r_{\varphi },\pi )$的结果。若结果为1，证明数据不正确，则解冻R的资金并向S发送$(notsold,id)$消息；若结果为0，证明数据正确，异议无效，此时将冻结的报酬发送给S并且向S发送$(sold,id)$。
   当然，如果R对数据x没有异议的话，合约将冻结的报酬发送给S并且向S发送$(sold,id)$。
   交易过程结束。
5. 合约在状态revealed状态下，收到S发送的消息$(finialize,id)$后解冻的报酬并将报酬发送给S。交易过程结束，输出$(sold,id)$。

协议分析

可终止性

1. 若S和R都正常工作，协议在五步后终止；
2. 若在reveal状态，S异常退出没有提供正确的解密密钥，则合约将冻结的报酬解冻后退还给R，协议在第3步终止；
3. 若在payout状态，R资金锁定失败或者R拒绝支付报酬，则协议在第2步结束。

故程序始终是可终止的。

对于S的公平性

只要S发送正确的数据且提供正确的解密密钥，就会得到相应价格的酬金；且在数据解密之前酬金已被合约锁定，不会出现R得到解密后的数据不支付报酬的情况；且只要数据正确，即便R发出异议，最终验证结果S也会得到报酬。

对于R的公平性

R提供报酬后会得到正确的数据。数据的验证发生在合约给S支付报酬之前，R确认数据正确之前S不会得到报酬；另外，当S发送错误的数据以后，经过合约的判定报酬会最终返还给R。

实验及实验结果

论文中实现了文件的交易，代码保存在github上。（ps：试了下没有run起来，有大佬run起来的可以一起讨论下）

实验结果表明在乐观模型（双方都正常服务）下，文件传输的花费保持一个常量；悲观模型下，随着文件大小的增加，花费呈现指数形式增长。

论文总结

本文将智能合约充当可信的第三方来保证在不可信的环境下完成可信的交易，在智能合约运行的过程中设计proof of misbehaviors保证了合约负载和以太花费的最小化.理由跟TrueBit类似的挑战机制对发生的分歧进行判定，这个过程中由智能合约充当Verfier。协议的过程比较简单，但整体设计巧妙，细节描述的比较清楚，是一篇不错的值得学习的文章。读完有几个困惑与大家一起探讨：

1. 智能合约真的可以做到可信吗？虽然智能合约能够脱离第三方并、被部署以后独立运行，但协议的实现特别是解决纠纷的过程会不会因为一些其他异常而出错。
2. 貌似对R不公平。整体协议更加倾向于S，S退出后不接受惩罚；R退出后就会被罚款。感觉S有点白piao的感觉，如果我每次拿假数据给你，反正我也不会亏，而R每次都要验证，耗费资源不说而且闹心，起纠纷以后还是由合约来解决，我错了我也没有啥影响，反正我也不会扣钱。后期应该增加一个验证或者对S的惩罚机制。
3. github上的代码run不起来。

最后感谢大家看到这篇博客，本人实属一个菜鸟，写这篇博客也是为了加深对文章的印象，有不到位或者错误的地方欢迎大家批评指正。最后，有研究隐私保护与共享的同学可以一起交流学习。
感谢感谢！