, 王强 东北大学 软件学院, 辽宁 沈阳 110169
收稿日期：2021-01-11
基金项目：国家自然科学基金资助项目(62072090，62173101)；中央高校基本科研业务费专项资金资助项目(N2217009, N2124002-13)。
作者简介：焦梓(1996 -)，男，辽宁沈阳人，东北大学博士研究生;
周福才(1964-)，男，辽宁沈阳人，东北大学教授，博士生导师。
摘要：针对已有的去中心化跨链交易方案存在的交易效率低、手续费开销大和难以扩展的问题, 提出了基于智能合约的跨链交易协议(CCE-SC).协议采用智能合约保证了跨链交易的去中心化和安全性, 通过策略制定、策略同步和区块链共识验证三大算法实现低成本且高效的跨链交易.协议中的每条链只需部署一个包含资金池模块、记录管理模块、链转发模块和汇率管理模块的智能合约, 就可实现多条链间的跨链交易, 解决了以往方案难以扩展的问题.通过实验测试对协议的性能进行分析, 实验结果表明该协议使跨链交易效率有了较大提升, 同时减少了手续费开销.
关键词：跨链交易智能合约去中心化区块链协议
Easily to Expand and Efficient Decentralized Cross Chain Exchange Protocol Based on Smart Contract
JIAO Zi, ZHOU Fu-cai
, WANG Qiang School of Software, Northeastern University, Shenyang 110169, China
Corresponding author: ZHOU Fu-cai, E-mail: fczhou@mail.neu.edu.cn.
Abstract: Aiming at the problems of low transaction efficiency, high handling fee, and difficulty in the expansion of existing decentralized cross chain exchange schemes, a cross chain exchange based on smart contract(CCE-SC)is proposed. The protocol uses smart contracts to ensure the decentralization and security of cross chain exchange. It implements low-cost and efficient cross-chain transactions through three algorithms, i.e., strategy formulation, strategy synchronization, and blockchain consensus verification. Each chain in the protocol only needs to deploy a smart contract that includes pool module, record management module, chain relay module and oracle module to realize cross chain exchange across multiple chains. The performance of the protocol is analyzed through experimental tests. The experimental results show that the protocol greatly improves the efficiency of cross chain exchange and reduces the handling fee overhead.
Key words: cross chain exchangesmart contractdecentralizedblockchainprotocol
随着区块链技术的蓬勃发展, 市面上出现了大量不同的区块链.一个现实世界的用户可能在多个链上拥有不同的数字资产.一旦需要将一条链上的数字资产转化为另一条链上的数字资产, 往往会因为这些区块链的共识协议或底层实现技术的不同, 引发跨链交易困难.
一种直观的解决方案是引入一个可信的第三方, 例如一个由机构提供的中心化服务器来进行跨链交易转换.如Shape shift[1]方案, 两个在不同链上的用户先将其交易请求发给可信第三方, 可信第三方不仅负责验证用户拥有足以进行交易的资产, 而且要确保这是一次等价交换的交易.随后, 在两条链上各发起一笔链上转账, 完成跨链交易.由于链上交易需要用户的交易私钥, 所以用户必须将用于链上交易的私钥发送给可信第三方.一旦可信第三方遭遇黑客攻击, 或者它本身存在交易欺诈和不诚实行为时, 攻击者可以利用交易私钥完成任何交易, 从而危害用户的资产安全.
去中心化的跨链交易方案不依赖于可信第三方.Tiernolan等[2]提出了基于哈希时间锁合约(HTLC)[3]的ACCS(atomic cross-chain swaps)方案, 该方案虽然是完全无第三方参与的, 但HTLC技术耗时较长, 且两个用户间完成一次跨链交易需要在两条链上各发生2笔交易, 这两方面的因素显著增加了跨链交易的手续费和时间开销.另外, ACCS要求所有用户在方案执行时必须都同时在线上进行, 这个限制对参与方案的用户是不友好的.Lerner[4]提出了利用侧链实现去中心化的RSK(root stock)方案, 但RSK方案为比特币专门构建了一个用于在矿工收益减半时保证比特币市场价格的侧链.方案中所提出的跨链发生在比特币和他的侧链RSK之间.显然, 两个现有的链无法利用这样的方案实现跨链交易.Zamyatin等[5]提出的XClaim方案虽然移除了中心化的可信第三方, 但却通过任何人都可以注册成为的见证人vault来监督跨链交易的过程.vault要提交抵押物以防止其不诚实.XClaim事实上仍然是基于第三方的方案, 此外用户利用XClaim完成一次跨链交易, 依然要在两个链上发生多于一次的交易, 这增加了交易时间并提高了交易手续费.
通过以上分析, 目前的去中心化跨链交易方案存在以下三个问题: ①多数方案往往是针对特定的两条链设计的, 难以适用到任意的两条链; ②虽然部分方案使用众多见证人替代中心化的第三方, 但见证人的本质依然是第三方, 没有实现真正意义的去中心化; ③跨链交易耗时长且手续费开销大.
针对以上三个问题, 论文提出了基于智能合约的跨链交易(cross chain exchange based on smart contract, CCE-SC)协议, 包括策略制定、策略同步和区块链共识验证三个主要算法.对于以往的方案难以扩展的问题, 参与CCE-SC协议的每条链只需部署一个包含资金池模块、记录管理模块、链转发模块和汇率管理模块的智能合约, 就可实现多条链间的跨链交易.为了实现跨链交易的去中心化, 在协议执行过程中, 没有第三方参与.通过实验与分析, CCE-SC在交易时间和手续费开销方面相较于传统方案均出现有效降低.
1 智能合约及链转发技术1.1 智能合约智能合约的概念最早由Szabo[6]于1997年提出, 最初被描述为一个由自动执行的计算机程序所组成的无需信任的系统.系统可以验证合约的合法性, 并执行合法合约中的指令.然而这个构想直到2015年以以太坊(Ethereum)[7]为代表的第二代区块链的出现才成为现实.智能合约与传统程序相比有诸多不同, 例如代码一旦被发布在区块链上以后就不可进行更改以及智能合约执行结果的正确性和可靠性由区块链保证.不同的区块链的智能合约有其对应的编程语言, 以太坊智能合约的开发语言以Solidity[8]为主.Solidity代码先经过编译转化成类似汇编的低级字节码, 随后以交易的形式发布到以太坊上, 一旦智能合约部署成功, 它将获得一个160位的地址标志.以太坊上的用户只要调用这个地址, 并辅以相关参数即可在EVM(ethereum virtual machine)[9]中执行智能合约.
1.2 链转发技术在交易结束前, 锁定用于跨链交易的资金是避免用户产生损失的通用方法.锁定操作在区块链上的具体实现形式是向一个确定的账户或智能合约地址转账.参与跨链交易的某条链需要利用链转发技术(chain relay)确认另一条链上用于此次交易的资产是否已经锁定完成.以BTCRelay[10]为代表的链转发技术需要部署一个智能合约, 合约上保存有另一条链上全部的区块头.
链转发合约的参与者包含转发者和验证者两种, 转发者负责提交另一条链的区块头信息, 验证者负责验证调用合约的用户提交的交易信息和交易对应的Merkle哈希树路径[11].验证者要进行两种验证: 交易包含验证和共识验证.交易包含验证的目的是验证用户提交的交易存在于特定区块中; 共识验证的目的是确保用户提交的交易所在的区块已经被另外一条链的共识机制所接纳.通过这两项验证的交易可认为是已被另一条链真实采纳的交易.链转发技术是一种去中心化的社区自治可信方案.
2 CCE-SC协议2.1 CCE-SC协议CCE-SC协议系统由3个实体构成: 区块链、智能合约和参与跨链交易的用户.
区块链: 底层区块链提供基础转账功能并保证转账的安全可靠.参与协议的两条区块链需要支持智能合约, 本协议的实现无需修改区块链本身.
智能合约: 参与协议的两条链各需部署一个智能合约, 负责为用户提交的跨链交易请求制定跨链交易策略; 另外, 智能合约通过链转发技术同步到另一条链上交易策略的执行状态和区块链共识情况以便为对应用户支付跨链资产.
用户: 协议运行后, 两条区块链上都有众多随时向智能合约提交跨链交易请求的用户, 用户在提交请求的同时, 还要提交用于交易的本链资产并提供另一条链上的收款地址.
基于智能合约的跨链交易(CCE-SC)协议系统交易流程如图 1所示.
图 1(Fig. 1)
 | 图 1 协议系统交易流程Fig.1 Protocol exchanging process |
① 用户向原资产所在链发送跨链交易请求, 并同时提交用于跨链交易的资产;
② 用户使用另一条链上的收款地址接收跨链资产;
③ 智能合约为参与跨链交易的用户们制定跨链交易策略;
④ 智能合约使用链转发技术同步另一条链的状态及协议执行情况;
⑤ 智能合约使用链转发技术为制定好的跨链交易策略进行区块链共识验证.
2.2 协议模型本协议主要由策略制定算法、策略同步算法和区块链共识验证算法三个主要算法组成.CCE-SC协议可形式化描述为CCE-SC=(MkSTG, Syn, Cons).下面对协议的3个算法进行形式化定义.
1) 策略制定算法: STself←MkSTG(Reqself, Reqsyn)为确定性算法.输入本链用户请求Reqself和同步来的另一条链上尚未加入策略的用户请求Reqsyn, 输出本链策略表STself.
2) 策略同步算法: ST′←Syn(STsyn, Reqself, Reqsyn)为确定性算法.输入通过链转发技术同步来的由另一条链制定的策略表STsyn, 本链用户请求Reqself和同步来的另一条链的用户请求Reqsyn, 输出本链对STsyn的采纳结果ST′.
3) 区块链共识验证算法: tag←Cons(ST, KA, KB)为确定性算法.输入为两条链均认可的策略ST, 两条链的安全参数KA和KB, 输出策略ST是否已经安全包含在两条链上的判断布尔值tag∈{true, false}.
3 关键算法描述CCE-SC协议涉及的3个主要算法的实现依赖智能合约.为使算法描述更为清晰, 同时减少现实中协议实现代码的耦合性, 智能合约的设计应包含如图 2所示的4个模块: 资金池模块(pool)、记录管理模块(record manager)(简记为RM模块)、链转发模块(chain-relay)(简记为CR模块)和汇率管理模块(oracle).模块间的连接线表示在协议运行时存在交互.
图 2(Fig. 2)
 | 图 2 智能合约模块设计Fig.2 Modules in smart contract |
资金池模块主要用于对资产直接的操作, 并维护一个由资产组成的资金池.链转发模块用于同步另一条链的状态.汇率管理模块用于协商参与协议的两条链资产的兑换比例.记录管理模块用于记录用户请求及策略制定和执行情况, 利用record函数将请求记录在智能合约上, 记录的格式是{ timestamp, src, dst, amount, split_p, blocknum, hash, state}.参数依次代表请求时间戳, 请求发送者地址, B链上的收款地址, 用于交易的A链资产数量, 请求分割情况, 提出请求时A链的区块号, 请求哈希和请求执行状态.新请求的state为0.在关键算法描述中会对模块中包含的函数进行解释.算法涉及的符号定义如表 1所示.
表 1(Table 1)
 表 1 符号说明Table 1 Instructions of symbol
| 表 1 符号说明 Table 1 Instructions of symbol |
3.1 策略制定算法策略制定算法MkSTG(Reqself, Reqsyn): 请求发起链A上的用户提交跨链交易请求后由aSC调用.算法的主要工作是将A链提交的请求Reqself与链转发模块同步来的B链尚未加入交换策略的请求Reqsyn进行匹配, 以生成策略STself.具体算法执行步骤如下:
1) 将用户提交的请求加入到请求队列request_list中.
2) 验证B链是否生成了新块, 若产生了新块则通过CR模块将B链上尚未加入策略中的请求同步到request_list中.
3) 依据汇率管理模块提供的汇率, 对request_list中来自不同链的请求进行匹配以生成交易策略.因为现实世界中几乎找不到价值完全相同的请求, 所以需要对请求进行分割, 执行如下操作:
① aSC分别选取一个A链和B链请求ReqA, ReqB;
② 汇率管理模块计算ReqA和ReqB包含的价值, 假设计算结果显示ReqA包含的资产价值更高;
③ 在RM模块中追加一条记录ReqAp1, 其amount属性设置为ReqB包含的资产价值, 标志ReqA为有分割状态, 并设置ReqA的split_p属性指向ReqAp1.若ReqA在之后的匹配中又被分割出ReqAp2, 则设置ReqAp1的split_p属性指向ReqAp2.
4) A链的RM模块将经过以上步骤得到的包含相等资产价值的A链和B链请求的状态属性state设置为1, 表明它们被加入了策略STself.
5) A链持续为用户上传的请求制定策略, 当A链产生新块后, B链可同步到A链RM模块中记录及记录状态的变化.B链选取记录状态为1的请求构成集合STsyn后依据策略同步算法进行策略协商.对记录状态为0的请求, B链将进行策略制定.
策略制定算法伪代码:
| 01 | ??A链上的用户向aSC发送ReqA, 资金池模块锁定AssetA并记录ReqA; |
| 02 | ??Pool.getReq(ReqA, AssetA); |
| 03 | ??request_list < >←RM.record(ReqA); |
| 04 | ??若B链产生了新区块: |
| 05 | ??request_list < >←synchronize(B); |
| 06 | ??从两条链上各取一个请求, 分割包含资金较多的请求并制定交换策略STself; |
| 07 | ??ReqA←RM.from(request_list < >, A); |
| 08 | ??ReqB←RM.from(request_list < >, B); |
| 09 | ??ReqAp1←Pool.split(ReqA, ReqB); |
| 10 | ??ReqA. split_p=ReqAp1, |
| ??ReqAp1. split_p=NULL; | |
| 11 | ??STself← makeStrategy(ReqAp1, ReqB); |
| 12 | ??ReqAp1.state=1, ReqB.state=1; |
| 13 | ??request_list < >←RM.record(ReqAp1); |
| 14 | ??request_list < >←RM.record(ReqB). |
3.2 策略同步算法策略同步算法Syn(STsyn, Reqself, Reqsyn): A链用户提交请求后, CR模块调用此算法.算法的主要工作有两个: ①当B链产生新块后, 同步bSC中RM模块的记录以获取B链制定的策略STsyn, 并验证STsyn中的请求合法且策略满足等价交换原则; ②当B链产生新块后, 同步bSC中RM模块的记录以获取B链验证后的A链制定的策略ST′syn, 并最终生成两条链均认可的策略ST′.策略同步算法流程图如图 3所示.
图 3(Fig. 3)
 | 图 3 策略同步算法流程图Fig.3 Process of strategy synchronization |
具体算法执行步骤如下:
1) A链CR模块在B链产生新块后, 将同步获得bSC中RM模块存储的请求记录.
2) 使用RM模块将STsyn使用的请求依据发起位置分为来自A链的请求RequestA和来自B链的请求RequestB两类.
3) 对于STsyn使用的每个来自B链的ReqB, 验证请求对应的TxReqB真实存在于B链区块中.若STsyn使用的请求来自分割后的请求, 还需要验证分割的合法性.
4) 调用汇率管理模块计算RequestA中全部请求对应B链资产价值是否等价于RequestB的资产价值.
5) aSC将STsyn使用的全部请求状态更改为2, 表示A链认同STsyn.
6) 将ST′self使用的全部请求状态更改为2, 生成两条链均认可的策略ST′.
策略同步算法伪代码:
| 01 | ??request_list < >← CR.synchronize(B) |
| 02 | ??for all i∈[request_list.length] |
| 03 | ????if request_list[i].state=2 and |
| ??????RMi.state=1 | |
| 04 | ????????RMi.state=2 |
| 05 | ??????if request_list[i].state=1 and |
| ????????(RMi=1 or not exist) | |
| 06 | ????????RequestA← RM.from(request_list[i], A) |
| 07 | ??????SumA +=request_list[i].amount |
| 08 | ??RequestB← RM.from(request_list[i], B) |
| 09 | ??????SumB +=request_list[i].amount |
| 10 | ??for all j∈[RequestB.length] and RMinot exists |
| 11 | ??????若RequestB[j]对应的交易TxReqB确实在B链上 |
| 12 | ??for all j∈[RequestB.length] and RMi=1 |
| 13 | ??????RM.verifySplit(RequestB[j]) |
| 14 | ??????汇率管理模块验证: |
| 15 | ??????Oracle.rate(SumA)=SumB |
| 16 | ??RMi.state=2 |
| 17 | ??else |
| ????????RM.changeStrategy(request_list < >) |
3.3 区块链共识验证算法区块链共识验证算法Cons(ST, KA, KB): CR模块执行该算法.判断两条链经协商产生的最终交换策略ST是否被安全包含在两条链上的依据是: A链与B链都达到了各自的安全参数KA和KB.安全参数[12]指第i个区块被认为安全的包含到区块链上直到第j个区块的产生, 其中j－i≥K.对于比特币[13]而言KBTC为6, 以太坊的安全参数KETH为12.具体算法执行步骤如下:
1) A链CR模块获取B链最新的区块.
2) CR模块判断ST′所在A链和B链区块是否均达到安全参数KA和KB.先判断出ST′已安全包含在两条区块链的链A(假设是A链).ST′内的请求state属性为3, 表明已确认待支付状态.
3) B链同步到ST′状态的变化后, B链资金池模块为ST′中ReqA支付对应资产.
4) B.RM模块设置ST′中包含的全部请求状态为已支付(state=4).
5) A链会在下一次同步后获悉B链已支付, 并执行步骤3)和步骤4).
6) 最终算法输出跨链交易完成判断标志tag∈{true, false}.
区块链共识验证算法伪代码:
| 01 | ??request_list < >← CR.synchronize(B) |
| 02 | ??if CR.reachK(A.ST′, A)=true and CR.reachK(B.ST′, B)=true |
| 03 | ??for any Req[i]in A.ST′ |
| 04 | ??????Req[i].state=3 |
| 05 | ????????bSC进行如下操作: |
| 06 | ??request_list < >← CR.synchronize(A) |
| 07 | ??if CR.reachK(A.ST′, A)=true AND CR.reachK(B.ST′, B)=true |
| 08 | ??Pool.pay(ST′) |
| 09 | ??????for any Req[i]in B.ST′ |
| 10 | ????????Req[i].state=4 |
| 11 | ??aSC进行如下操作: |
| 12 | ??Pool.pay(ST′) |
| 13 | ??for any Req[i]in A.ST′ |
| 14 | ??Req[i].state=4 |
| 15 | ??错误时处理: |
| ??Pool.rollback() |
4 协议测试与分析本协议在有2台实体机构建的实验环境中进行测试, 实体机硬件配置: Intel(R)Core(TM)i7 CPU 10510 @ 1.8 GHz处理器, 16 GB内存; 实体机软件环境: Windows 10 64位操作系统.跨链交易的两条区块链为经常被用来做跨链交易的以太坊(ETH)和以太坊经典(ETC).截止到2021年4月26日, ETH和ETC的平均出块时间、平均手续费和原生币的价值如表 2所示.理论上本方案与传统方案在交易时间效率和交易手续费开销的对比如表 3所示.
表 2(Table 2)
表 2 ETH和ETC基本信息Table 2 Basic information of ETH and ETC
| 表 2 ETH和ETC基本信息 Table 2 Basic information of ETH and ETC |
表 3(Table 3)
表 3 协议与传统方案的对比Table 3 Protocol compared with traditional schemes
| 表 3 协议与传统方案的对比 Table 3 Protocol compared with traditional schemes |
通过实验, 测试使用CCE-SC的用户将ETH资产与ETC资产交易的时间效率和手续费开销.实验中, 在ETH和ETC上使用Ganache随机生成400个用户地址和400个收款地址, 由coinbase为每个用户地址随机分配一定资产用于跨链交易.智能合约中汇率管理模块内的汇率rate(ETH, ETC)=79.411 783 44.由于ETH和ETC的现实价值差别较大, 每个ETH用户随机分配0.5~1个ETH, 每个ETC用户根据两条链的资产汇率比例随机分配39.7~79.4个ETC, 在进行跨链交易时假定每个用户投入全部资产.由于现实中区块链上的交易是随时涌进的, 为体现这一动态过程, 设置每条链上每秒有一名用户发起跨链交易请求.为保证测试中每个新块中包含12~19个本链请求, CR模块能同步到12~19个来自另一条的请求.
实验结果如图 4和图 5所示, 一个用户使用CCE-SC协议安全交换到另一条链资产所需时间平均为452 s, 手续费开销平均为28.378美元.CCE-SC相较于传统的ACCS[3]和XClaim[5]方案在交易时间和交易手续费方面都有下降.CCE-SC与XClaim方案在手续费开销方面较为接近的原因是: 实验采用的以太坊与以太坊经典的现实价值差距过大.理论上每进行一次跨链交易, CCE-SC比XClaim方案只少花费约0.005 2美元, 和XClaim方案一次跨链交易就需要约28.39美元相比, 手续费开销较为接近.
图 4(Fig. 4)
 | 图 4 三种方案交易手续费总开销与交易次数的关系Fig.4 Relationships between total fees and trade times |
图 5(Fig. 5)
 | 图 5 三种方案总交易时间与交易次数的关系Fig.5 Relationships between total time and trade times |
ETH用户利用CCE-SC协议提交的跨链请求在经历策略制定算法、策略同步算法和区块链共识算法后, 最终在ETC上完成支付.策略制定和策略同步的总时间最短为2ΔETH, 受到网络延时或者两条链出块顺序排列的影响, 最长为4ΔETH.区块链共识到智能合约支付最短时间为12ΔETH, 最长为14ΔETH.再加上支付所需要的安全时间12ΔETH, ETH上的用户自发起跨链交易请求到能安全收到ETC资产的总时间最短为2ΔETH+12ΔETH+12ΔETH=26ΔETH.最长时间为4ΔETH +14ΔETH +12ΔETH=30ΔETH.
在协议安全性方面, 区块链网络中各节点间是不可信的, 定义敌手Eve可能对协议进行攻击的2个事件:
event1: 敌手篡改伪造请求或交换策略.
event2: 敌手在交换策略协商阶段中断请求.
对于event1, 假设A链上一个合法的请求是request0, 敌手使用算法E篡改或伪造后的请求是request1.敌手随机选择b←{0, 1}, 并将requestb提交给协议的智能合约(SC).智能合约输出b′∈{0, 1}表示其采纳了request0或request1.
定义安全游戏: ?b=0, 1:Wb: =[event: b′=1], 则SC相对于攻击算法E的执行安全优势(ES)是: AdvES[SC, E]=|Pr[W0]－Pr[W1]|.因为A链上的智能合约的安全性由区块链共识机制保证, 所以A链不接受event1.即智能合约相较于攻击算法的优势为: |Pr[W0]－Pr[W1]|=
对于event2, 若敌手在交换策略协商阶段中断了请求, 则在制定交换策略时对应请求就会被移除.所以CCE-SC协议可以保证诚实的参与者在敌手的攻击下不蒙受任何损失.
5 结语本文在研究了去中心化传统跨链交易方案的基础上, 通过在参与跨链交易的两条区块链各自部署一个智能合约, 解决了传统方案难以推广的问题.在协议运行的全过程中无第三方参与, 实现了真正意义上的去中心化跨链交易.同时, 因为用户仅需要向原资产所在链发送一次跨链交易请求就能在另一条链上收到对应价值的资产, 使得交易时间和手续费开销相较于传统方案均出现有效降低.
参考文献
| [1] | Voorhees E. Shape shift[EB/OL]. (2019-07-01)[2021-04-25]. https://shapeshift.io/. |
| [2] | Tiernolan B. Alt chains and atomic transfers[EB/OL]. (2013-03-02)[2021-04-18]. https://bitcointalk.org/index.php?topic=193281.msg2224949. |
| [3] | Poon J, Dryja T. The bitcoin lightning network: scalable off-chain instant payments[EB/OL]. (2016-02-16)[2021-05-03]. https://lightning.network/lightningnetwork-paper.pdf |
| [4] | Lerner S D. Rootstock: bitcoin powered smart contracts[EB/OL]. (2015-11-19)[2021-05-13]. https://docs.rsk.co/RSKWhitePaper-Overview.pdf. |
| [5] | Zamyatin A, Harz D, Lind J, et al. XCLAIM: trustless, interoperable, cryptocurrency-backed assets[C]//2019 IEEE Symposium on Security and Privacy. San Francisco: IEEE, 2019: 193-210. |
| [6] | Szabo N. Formalizing and securing relationships on public networks[J]. First Monday, 1997, 2(9): 1-21. |
| [7] | Wood G. Ethereum: a secure decentralized generalised transaction ledger[J/OL]. Ethereum Project Yellow Paper, 2014, 151: 1-32. |
| [8] | Wood G. Solidity 0.5.1 documentation[EB/OL]. (2018-12-17)[2021-03-23]. https://solidity.readthedocs.io/en/v0.5.1/. |
| [9] | Torres C F, Steichen M, State R. The art of the scam: demystifying honeypots in ethereum smart contracts[C]//Proceedings of the 28th USENIX Conference on Security Symposium. Santa Clara: ACM, 2019: 1591-1607. |
| [10] | Joseph A. Btcrelay[EB/OL]. (2017-10-26)[2021-02-18]. https://github.com/ethereum/Btcrelay. |
| [11] | Babu V J, Jose M V. Improved merkle Hash tree-based one-time signature scheme for capability-enhanced security enforcing architecture for named data networking[J]. Wireless Personal Communications, 2020, 115(11): 557-574. |
| [12] | Pass R, Seeman L, Shelat A. Analysis of the blockchain protocol in asynchronous networks[J]. Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2017, 102(2): 643-673. |
| [13] | Nakamoto S. Bitcoin: a peer-to-peer electronic cash system[EB/OL]. [2021-04-03]. http://www.bitcoin.org. |
