前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Photon network无网安全性分析

Photon network无网安全性分析

作者头像
rectinajh
发布2018-12-07 17:33:26
4920
发布2018-12-07 17:33:26
举报

无网问题描述及安全性分析

SmartMesh重庆智能雷电部

1.背景知识:链接支付

图片 1.png

图片 2.png

链接支付基于hash时间锁(HTLC),依赖于一个简单的hash h=H(x)。

链接支付基于hash时间锁(HTLC),依赖于一个简单的hash h=H(x)。

条件支付场景:Alice打算给Dave转账30个token,Alice与Dave之间没有直接通道,Alice与Bob、Bob与Carol、Carol与Dave之间有直接通道。Alice给Bob一个条件支付,如果Bob在3天内告诉Alice h的原像x,就能拿到这笔钱,否则这个条件支付被取消。同样,Bob给Carol一个条件支付,如果Carol在2天内告诉Bob h的原像x,就能拿到这笔钱,否则这个条件支付被取消。依次,Carol给Dave一个条件支付,如果Dave在1天内告诉Carol h的原像x,就能拿到这笔钱,否则这个条件支付被取消。

Dave向Alice发送请求,得到x,1天内告诉Carol,拿到Carol的30 token。Carol得到x,2天内告诉Bob,拿到Bob的30 token。Bob得到x,3天内告诉Alice,拿到Alice的30 token。通过链接支付,实现Alice向Dave转账支付。

这里确保安全的关键是时间锁和hash锁

2.无网支付描述

无网交易是在不依赖互联网的条件下进行的链下的转账交易。以Alice 和Dave进行无网支付为例:Alice打算转账30个token给Dave。假定Alice和Bob、Bob和Carol、Carol和Dave在spectrum上 相互之间有通道,且均有存款。如果在有网(internet)的条件下,可以直接进行链下转账交易。但是假定在Alice打算给Dave转账时,连接互联网出现了问题。此时,如果Alice、Bob、Carol、Dave附近存在meshbox,且各自在meshbox上注册过,则Alice 、Bob、Carol、Dave都可以找到对方,且他们之间的通道依然有效。

Alice此时可以切换到无网状态,借助meshbox给Dave无网支付30token。

3.存在的安全性问题

Alice和Dave虽然在无网情况下可以进行链下支付,但Alice并不知道Dave是否真正无网,有可能Dave在接收支付时无网,但很快又有网; 又或者Dave不知道Alice是否无网。则链下交易的接收方在无网状态下安全性得不到合约的保证。

那么如何在一定限制条件下,使state channel 交易模型可以在条件概率情况下保证无网交易的安全。具体来说就是,在无网条件下能否为HTLC 加入更多的限制,从而保证任意一个节点在知道他自身没有连接公链,但是不知道其他节点有没有连接公链的情况下,安全地进行交易。包括自己发起交易,接收他人的交易,作为中间路由节点进行转发交易等。

4.限制无网安全性情况分析

根据无网的时间长短和发生的概率,可以将无网的场景进一步分为限定无网的场景随机无网(短时间无网)的场景

对于限定无网的场景,如深山、海岛、地下矿区等,该区域本身没有网络覆盖,无网的概率为100%,用户有可能在该区域内长时间工作和生活,只有在某个特定的时间才会返回到有网区域,因此,无网时间以天计算,以平均20天无网计。此种场景下,无网节点长时间与公链断开连接,对方节点可能已切换到有网,他可以随时关闭通道进行结算。为了保证双方的交易安全,在这种场景下,需要进行强制约束。该采用什么样的限制措施,我们先从可能的安全隐患进行分析。

我们对当前通道的生命周期对无网节点的影响进行分析。

1.通道不存在

通道不存在有两种情况:一种是从未存在,另一种是已经结算,通道及参与者的所有数据已经被移除。此种情况下,节点处于无网状态,没有资金的变动,没有安全隐患。

2、通道打开

节点与直接连接的对等方开始通道建立过程。打开通道方可以指定token地址,对方节点地址,想要存款的token数量,结算超时的时间。打开通道后,就可以通过通道进行转账交易。如果节点处于无网状态下,是不能进行打开通道操作的,无网交易的前提是要求有通道存在。通道打开这个过程需要在有网条件下建立,与无网本身无关,没有安全隐患。

3、通道存款

支付通道打开后,因为只有一个节点有token,所以只能这个节点向对方转账。可以通知另一个节点有一个通道已经向他打开,他也可以存钱进这个通道。如果节点处于无网状态,自己本身不能存款,对方节点如果有网,可以存款,但对无网节点的资金安全不造成影响(无网节点的资金没有变化)。

4、通道取款

支付通道打开后,如果通道双方余额充足,可以进行取款操作,前提是要双方签名认可。在这种情况下,如果节点处于无网状态,他无法提供签名,因此双方均不能进行取款操作,对无网节点的资金安全不造成影响。

5、通道转账

如果通道内节点有余额,节点可以直接转账token给通道对手方,如果想转账给间接节点,只要他们之间的间接通道相连,且间接通道中中转节点的余额充足,则转账可以进行。这个过程主要是在链下进行。在这种情况下,如果节点处于无网状态,分为两种情况:1)、所有的交易都正常完成,是一次正常的链下支付,不涉及链上操作,无网节点的链上资金无变化,没有安全隐患。

2)、某些交易失败,一部分转账金额被锁定,等待时间锁的过期或者secret的披露。在这种情况下,存在安全隐患,举例如下:

Alice---Bob----Carl-----Dave 四个节点,相互之间有通道

如果Bob处于有网状态,Carl处于无网状态,Alice通过Bob和Carl给Dave转账30token,Dave向Alice请求secret后,给Carl,拿到Carl的30token.Carl向Bob提供secret,请求它的钱。Bob知道Carl在无网状态,不给Carl交换unlock报文,Carl拿不到Bob的30token,但Bob 可以将secret给Alice,拿到Alice的30token.Carl虽然有secret,但是因为无网,不能到链上注册secret,等时间锁到期后,Bob给Carl的条件转账被退回,Bob不当得利。主要原因是无网时间不能连上公链,一旦交易失败,不能提交/或者知悉secret是否注册。

6、通道关闭

如果节点在任何时刻想要关闭一个特定的通道,可以用close。一旦关闭通道被调用,settle 超时开始计算。通道关闭方和非关闭方在结算窗口期内提交对方的余额证明。在这种情况下,有网节点关闭通道,无网节点不知道通道是否关闭。此时,如果对方在链下继续进行转账交易,但使用旧的余额证明进行结算,则无网节点不能提交证明,丢失对方转账给他的部分或全部token.有安全风险。

7、通道结算

当结算超时过后,通道最终被结算。在结算窗口期内,无网节点不能进行unlock,通道结算后,没有unlock的资金被返还,无网节点损失部分有密码不能解锁的资金。有安全风险。另外,通道已经结算,但无网节点不知道,继续接收交易,会损失额外的资金。

5.限制无网限制条件设想

通过以上分析,无网交易的风险在于四个方面(1)交易失败时不能提交secret (2)关闭通道时,不能提交余额证明(3)关闭通道时,不能unlock.(4)通道已经结算,继续接收转账造成的损失。

可以看出,主要的风险来自于通道结算期的无网以及交易失败的无网。核心是这两个时间段内无法联接到互联网。那解决的思路就是在这两个时间段内,让无网节点可以联接上互联网,保证资金的安全。

方案一限制条件:1、设置settletimeout 为20天

代码语言:javascript
复制
            2、设置每个锁的过期时间为20天

            3、通道unlock设置在settlechannel之后

            4、二次无网对secret特殊处理

对于通道结算期无网的情况处理,可将通道结算的时间延长,在打开通道时明确,如果需要支持无网交易,则开设的通道的settle timeout 时间设置为20天。一旦节点进入无网状态,则必须开始倒计时,在20天时间内,必须连接上互联网,查看对方是否关闭通道与结算通道,一旦对方关闭通道,在settletimeout过期之前,有时间提交证明,以及解锁注册的secret,得到应得的钱,并且不再会有结算后继续接收转账的风险。

对于交易失败的无网情况,可将每个交易的过期时间设定为20天。这个存在与settletimeout 的限制冲突,因此,调整流程,将unlock设置在结算通道之后,这样,即使通道结算,secret未过期,仍然可以解锁。

当然,此种限制只是针对一次无网,为了安全考虑,在第二次进入无网状态之前,进行特殊要求。正常情况下,收到secret时间应该很短,可以等待2个小时(一个缓冲期),查看是否未完成交易所有的锁都已注册,才允许再次进入无网状态。在第二次进入无网之前,有两种处理方案,一种将所有的锁处理完,才再次进入无网,要么注册,要么等过期;另一种是在第二次进入无网状态下,不再接受上一次无网状态下的secret.可以通过自己的新无网时间来衡量,如果接收的secret的过期块<小于新的剩余无网时间(20-x),就直接拒绝。这样就逼着违约方去链上注册,否则这个交易作废。这种方案,保证了任何人都有链上注册的机会,而且如果在较长时间内没有收到secret,选择让对方只能去注册。

直接无网交易场景描述

以Alice和Bob无网交易为例,Alice直接转账10个token给Bob。Bob收到转账,双方的balanceproof如下:

Alice:nonce为1,transferamount 10,locksroot 0;

Bob:nonce 0,transferamount 0,locksroot 0。

(交易后)

情况1:Alice 处于有网状态,Bob处于无网状态

Alice可以链接公链,有关闭通道的机会,Bob无网,不能关闭通道,settle timeout保障非关闭方的交易安全。

(1)Alice使用最新余额证明,关闭并结算通道

Alice: 1,10,0

Bob:0,0,0

在20天时间快到之前,Bob需要连接上互联网查看Alice有否关闭通道;显然,由于结算期settle timeout为20天,虽然Alice已经关闭通道,但Bob上线依然有时间提交余额证明(结算窗口没过),由于Alice提交的余额证明为最新,双方均得到应得的钱(Alice得到90token, Bob得到110token),Bob不存在风险。

(2)Alice使用旧余额证明,关闭并结算通道

Alice: 0,0,0

Bob:0,0,0

在20天时间快到之前,Bob需要连接上互联网查看Alice有否关闭通道;20天时间到,由于结算期settle timeout为20天,虽然Alice已经关闭通道,但Bob上线依然有时间提交余额证明(结算窗口没过),此时,由于Alice提交的余额证明不是最新,Bob提交最新的余额证明替换Alice的证明,双方均得到应得的钱(Alice得到90token, Bob得到110token),Bob不存在风险。

(3)Alice使用新余额证明((1,10,0)(0,0,0))关闭通道后,又继续在链下向Bob发送10 token

关闭通道:Alice:1,10,0

Bob:0,0,0

此时,Alice链上已关闭,但Bob处于无网状态,并不知道

Alice向Bob发送10token

Alice:2,20,0

Bob:0,0,0

在20天时间快到之前,Bob需要连接上互联网查看Alice有否关闭通道;20天时间到,由于结算期settle timeout为20天,虽然Alice已经关闭通道,但Bob上线依然有时间提交余额证明(结算窗口没过),Bob提交最新证明((2,20,0)(0,0,0))替换Alice旧证明,虽然Alice违规在关闭通道后继续在链下发送交易,但她并不能不当得利,Bob得到他应得的钱。

(4)Alice使用新余额证明((1,10,0)(0,0,0)),关闭结算通道后,Bob在链下向Alice发送10 token

关闭通道:Alice:1,10,0

Bob:0,0,0

此时,Alice链上已关闭,但Bob处于无网状态,并不知道

Bob向Alice发送10token

Alice 1,10,0

Bob 1,10,0

在20天时间快到之前,Bob需要连接上互联网查看Alice有否关闭通道;20天时间到,由于结算期settle timeout为20天,虽然Alice已经关闭通道,但Bob上线依然有时间提交余额证明(结算窗口没过),Bob提交最新证明((1,10,0)(1,10,0))替换Alice旧证明,虽然Alice在关闭通道后继续在链下接收交易,但因为Bob是发送方,Alice并不能不当得利,Bob得到他应得的钱。

(5)直接无网交易失败情况

Alice向Bob发送10个token, Alice 有网,Bob无网。如果Bob没有收到secret,则等待secret过期,因为直接交易,没有中间节点,不存在风险;如果Bob收到Alice Secret后,向Alice要求unlock,Alice不给unlock报文,由于secret过期时间为20天,在20天内Bob有时间连接上互联网进行链上注册,即使Alice关闭和结算通道,由于unlock在settle之后,Bob依然可以拿到钱,不存在风险。

间接无网交易(三个节点)

图片 3.png

Alice****通过Bob向Carl转账10token。假设Alice和Carl有网,Bob无网。

(1) ****情况1:

Alice发送Mediatertransfer(1,0,(10))给Bob,Bob发送Mediatertransfer(1,0,(10))给Carl,Carl收到Mediatertransfer,向Alice要secret给Bob,Bob再给Alice,链下支付完成,两个通道余额变成

Alice—Bob 90,110

代码语言:javascript
复制
  Bob—carl    90,110

通道一双方balanceproof:Alice (1,10,0) Bob(0,0,0)

通道二双方balanceproof:Bob(1,10,0) carl(0,0,0)

此时,无论Alice还是Carl选择结算通道,都有settle timeout保证Bob在这两个通道的金额安全,Bob有时间提交证明。

情况2:(Alice与Carl合谋)

Alice发送Mediatertransfer(1,0,(10))给Bob,Bob发送Mediatertransfer(1,0,(10))给Carl,Carl收到Mediatertransfer,向Alice要secret,不给Bob,选择链上注册,等通道结算后unlock拿到10token。

Bob没有secret给Alice,链下支付未完成,未结算前两个通道余额为

Alice—Bob 100(10),100

代码语言:javascript
复制
  Bob—carl     100(10),100

通道一双方:Alice (1,0,(10)) Bob(0,0,0)

通道二双方:Bob(1,0,(10)) carl(0,0,0)

此时,如果Alice选择结算通道,因为unlock在结算之后,并且Carl已经在链上注册了secret,所以她转账给Bob的10个token被锁定,她只能拿到90token.Bob在连接上网后,因为secret已注册,可以随时解锁10个token(不受通道结算的约束),保证Alice和Bob通道上Bob资金的安全。

如果Carl选择链上结算通道,因为Bob是发送方,它的金额安全不受Carl结算通道影响。

情况3:

Alice发送Mediatertransfer(1,0,(10))给Bob,Bob发送Mediatertransfer(1,0,(10))给Carl,Carl收到Mediatertransfer,向Alice要secret,但不给Bob,也不注册。

链下支付未完成,两个通道余额变成

Alice—Bob 100(10),100

代码语言:javascript
复制
  Bob—carl    100(10),100

通道一双方:Alice (1,0,(10)) Bob(0,0,0)

通道二双方:Bob(1,0,(10)) carl(0,0,0)

等secret过期后:

Alice—Bob 100,100

代码语言:javascript
复制
  Bob—carl    100,100

通道一双方:Alice (2,0,0) Bob(0,0,0)

通道二双方:Bob(2,0,0) carl(0,0,0)

a.如果Alice选择在secret过期之前结算通道,因为unlock在结算之后,通道结算前没有secret在链上注册,所以她转账给Bob的10个token被锁定,她先拿到90token,等过期后她能拿到余下的10token.

b.如果Alice选择在secret过期之后结算通道,因为unlock在结算之后, secret已过期,所以她转账给Bob的10个token被返回,她能拿到100token.

Bob在连接上网后(肯定在secret过期之前),因为secret未注册,他的转账被锁定,Bob在两个通道上的金额没有安全问题(可以等Carl注册或等secret过期)。

如果Carl选择不注册secret在链上结算通道,那么不管secret是否过期,Carl结算通道也拿不到Bob转账给他的token,不能不当得利。

情况4:

关于Alice和carl无网,Bob有网的情况下,Bob不提供secret给carl的问题

如果Bob有网,Alice和Carl无网,Alice和Bob之间过期块20天,Bob carl之间过期块 20天。Alice通过Bob向Carl转账10token, Bob收到secret后,不给Carl回复unlock报文,使用unlock从Alice那拿到10个token.

由于Bob有网,Bob可以在链上结算Bob—carl通道,carl无网,不能注册secret,但由于过期块为20天,Carl可以在过期块之前连上互联网,注册secret拿到Bob给他的钱,不会造成损失。

间接无网交易(多个节点)

(1) ****多个节点情况下合谋的风险

图片 4.png

Alice Bob carl Dave

买家(发送方) 中间商 中间商 卖家(接收方)

图片 5.png

发送方本来就是要付钱的,所以发送方只要披露给了secret,就认为付了钱,东西拿到了。

a. Bob与Carl合谋骗Alice的钱

Bob与Carl有网,Alice无网。Alce通过Bob/Carl给Dave转账,可能存在的Bob收到转账或Carl收到转账不转给Dave,那么Dave就不会发送secretrequest给Alice,中间节点没有secret,无法拿到Alice的钱;如果Carl收到secret不给Secret报文,结果如上情况3所述,Dave能拿到钱,Alice的钱是正常付出,(Dave确定能收到钱,所以会把货给Alice)不存在被骗。

b. Bob与Carl合谋骗Dave的钱

Dave是接收方,手里有secret,有secret合约可以保证安全(只要在过期块之前连上网)。

c. Bob与Dave合谋骗Alice的钱

如果Dave收到secret给Bob,不给Carl,Bob能拿到Alice的钱,便Dave不能拿到Carl的钱,Dave可以说我没收到钱,我不给货吗?不能,因为Alilce拿到的secret,她只跟Bob有通道,而且secret只给了Dave,除非你给了Bob,其他途径得不到secret,所以Alice是正常付钱,Dave从利益角度,还是会将secret给Carl,得到Carl的钱。

d. Bob与Dave合谋骗carl的钱

Bob与Dave有网,Dave收到secret后,不给Carl,给Bob,Bob拿到钱,但Dave也拿不到Carl的钱,他可以选择到链上注册,拿到Carl的钱; Carl在过期块之前到链上拿到Bob的钱。因为Bob—Carl的过期块等于Carl—Dave的过期块,所以只要Dave注册,Carl一定能拿到Bob的钱,所以Carl不会有损失。

e. Carl和Dave合谋骗Bob的钱

Carl和Dave有网,Bob无网,如果Dave给了Carl secret, Carl 不给Bob,选择链上注册,拿到钱,Bob在块过期之前连上网,得到secret,从Alice拿到钱。(只考虑一次无网的情况,或者双方在无网之前处理完所有的锁,要么过期,要么注册

f. Carl和Dave合谋骗Alice的钱

Carl和Dave有网,Alice无网,这个没有Bob的合作行不通。

g. Alice和Dave合谋骗Bob和Carl的钱

Alice和Dave有网,Alice给Dave secret, Dave不给Carl,链上注册,那么Carl能从链上得到secret,Carl给Bob,Bob给Alice,因为已经注册,Alice如果不交换报文,Bob也能从链上拿到钱,所以Alice会给钱。Bob和Carl不会丢钱。

综合分析,采取以上限制,可以保证中转转账的安全。

这种方案本质上使用两个时间settletimeout和expire block保证transferamount和lockamount的安全。

二次无网的风险分析:

图片 6.png

Alice Bob carl Dave

买家(发送方) 中间商 中间商 卖家(接收方)

Alice通过Bob、Carl向Dave转账,Alice与Bob之间、Bob与Carl之间、Carl与Dave之间过期块均为20天,由于各个节点节点进入无网的时间不一致,假设Alice剩余8天,Bob剩余6天,carl剩余5天,Dave剩余18天。

如果Alice此时发送一个中转转账给Dave,过期块为20天,由于各个节点均可以以过期之前连上互联网,所以这个转账是安全的。假定,carl收到转账后,过了5天,他没收到secret,连上互联网后,也没发现有secret注册,如果过了一天他再次进入无网状态,那么,此时,他转账给Dave的交易将处理风险之中,Dave可以在链下过期前最后一天将Secret给carl,要求他付钱;Carl付了钱给Carl,拿secret向Bob要钱,Bob与Dave串谋,不给Carl交换unlock,由于Carl是二次无网,等待的时间要20天,在此期间该secret过期,Carl也不能上链上注册,他损失给Dave这笔钱。

所以为了安全考虑,在第二次进入无网状态之前,进行特殊要求。正常情况下,收到secret时间应该很短,可以等待2个小时(一个缓冲期),查看是否未完成交易所有的锁都已注册,才允许再次进入无网状态。第二次进入无网,有两种处理方案,一种将所有的锁处理完,才再次进入无网,要么注册,要么等过期;另一种是在第二次进入无网状态下,不再接受上一次无网状态下的secret.可以通过自己的新无网时间来衡量,如果接收的secret的过期块<小于新的剩余无网时间(20-x),就直接拒绝。这样就逼着违约方去链上注册,否则这个交易作废。这种方案,保证了任何人都有链上注册的机会,而且如果在较长时间内没有收到secret,选择让对方只能去注册。

6****随机无网安全性情况分析

为了提高随机无网安全性,我们从技术角度和经济学角度设计了几条原则来对无网支付进行限制,主要目的是降低节点获利概率,尽可能让节点不愿意去作恶。

1)无网限制原则

a. 提高恶意节点获利难度

b. 降低恶意节点获利程度

c. 见证人及保证金约束

d. 信誉惩罚:黑名单

根据条件概率原则,如果三个条件独立,则可以将三者概率相乘。

例如,假设提高获利难度,恶意节点获利概率降低为0.4.

代码语言:javascript
复制
  假设降低获利程度,恶意节点获利概率降低为0.4.

  假设使用见证人及保证金约束,恶意节点获利概率也降低为0.4.

  三者同时发生,恶意节点获利概率变为0.4*0.4*0.4=0.064

  即整体安全性从单个措施的0.6上升到0.936。 

2)随机无网交易的场景设定

无网交易是特殊的链下交易状态,不是所有场景都需要通过无网支付,特别是无网间接交易。目前,考虑的应用场景如下:

a. 网络信号不好(时而有网,时而无网)情况

主要是偏远地区以及网络连接不好的餐厅、零售店、加油站等

b. 一段时间内没有网络信号情况

主要地下停车场,矿区等特定环境下的支付需求

c. 一段时间内网络拥堵情况

体育场、大型集会、特定自然灾害下邻近基站损坏等网络拥堵条件下的支付需求。

3)随机无网交易限制的几种方案

为更好描述随机无网交易限制,下面以Alice、Bob、Carol、Dave四个smartraiden节点为例描述限制方案。

a. 延长通道settletimeout时间和expire块时间。如果通道建立双方有随机无网支付需求(可选),在通道创建时即需要进行设定。例如:Alice与Bob打开通道,有网条件下settletimeout常规为600 block,则如果通道需要支持随机无网支付,则Alice打开通道时设定settletimeout不能小于2000block(这个可根据断网频率和时间测试统计计算)。按照spectrum每15秒一块的速度,2000block大约8个小时,如果通道节点方如Alice打算无网支付后在有网条件下单方关闭通道(此时假定Bob仍无网), 则Alice需要等待比通常有网情况下多一倍以上的时间,等待时间越长,则Bob重新有网的概率越大,Alice企图使用旧余额获利的难度越大,expire块时间设置同理。

概率分析:根据统计分析,随机无网可以类比为网络故障,服从泊松分布。即:在时间间隔T内有k个网络故障的概率为:[图片上传失败...(image-ed1076-1541755942197)] (故障率参数为λ(个/单位时间))。

根据某地运营商提供的数据,该地市公司全部800个基站和8个BSC,估计一天共需要处理的故障32个,其中6:00-24:00有27条,可得λ=27/18=1.5,修复时间0.5-2小时。

那么在8小时内,该地区发生网络故障的概率如下:

发生1个故障的概率12e-12=7.3710-5

发生2个故障的概率72* e-12=4.42*10-4

发生3个故障的概率288* e-12=0.0018

发生11个故障的概率18163 * e-12=0.1144,即11.4%

发生12个故障的概率18163 * e-12=0.1144,即11.4%

发生13个故障的概率17182 * e-12=0.1056,即10.56%

发生14个故障的概率14727 * e-12=0.0904,即9.04%

发生15个故障的概率11782 * e-12=0.0724,即7.24%

发生16个故障的概率8836 * e-12= 0.0543,即5.43%

发生17个故障的概率6237 * e-12= 0.0383,即3.83%

发生18个故障的概率1277 * e-12= 0.0078,即0.78%

通过计算,该地区8小时内发生11或12个网络故障的概率最大。以最大概率情况下,用户的网络故障率计算无网交易的安全性。

假设用户Bob关联总基站数的四分之一,则最多Bob会面临3个网络故障。按每个网络故障修复时间2小时计,则需要修复时间为6小时,此时间段Bob处于无网状态。如果第一个无网时间段Alice向Bob转账了30token,而后,Alice有网而Bob依然无网,Alice选择关闭通道,等待settle timeout(8小时),则即使三次故障时间相连,Bob仍然有剩余时间可以连接上互联网提交证据,所以交易可以认为是安全的。

b. 限制无网交易通道双方的交易次数及交易总金额,即最大可能的损失。以Alice和Bob转账为例,在有网条件下,Alice可以不断存钱,不断给Bob转账,只要Alice有可用余额,与Bob交易的次数和向Bob转账的总金额是不限的。为了降低通道节点在无网变有网情况下作恶获利的程度,可以根据通道价值对交易的次数和总金额进行限制(通道价值跟使用频率(通道一方或双方是枢纽,联接多个节点)、通道余额、通道收费金额有关,可类比公路交通衡量价值),作恶概率是通道价值的函数 P(Alice)=f(P(Value))。如获利总金额为10000时,如果通道价值为2000,Alice作恶的概率为100%,

获利总金额为1000时,如果通道价值为2000,Alice作恶的概率为0。因此,如果通道价值为1000,可限定在无网条件下转账次数不能大于5次,单次转账金额不能大于200token.这样,即使Alice在无网变有网条件下(假定Bob仍无网),单方关闭通道,最大获利金额为1000token,与通道价值相当,获利非常有限。这个可在在Alice与Bob调用SwithNetwork切换到无网状态时,设定交易计数器和金额上限,一旦达到上限,Bob APP拒绝接收转账请求。

c. 设计无网第三方节点,接受无网条件下的委托(难度较大,仅参考)。无网第三方为可信任第三方,主要工作是在无网条件下接受节点委托,帮助提交委托(有网情况下)或中转委托(无网情况下);无网第三方节点需要在多个meshbox下注册(防止单个meshbox崩溃以及便于联系到注册在其他meshbox上的第三方)。以Alice和Bob为例,第三方接受Bob委托后,如果可以切换到有网,帮助Bob监控Alice和Bob通道,一旦Alice关闭通道,第三方等待1/2settletimeout观察Bob有无提交证明,没有则帮助Bob提交证明,并记录作为收费依据;如果不能切换到有网,中转给其他meshbox上注册的无网第三方,由其他无网第三方节点监控该通道。第三方无网中转转发提交证明由smartmesh公司统一支付服务费(较低),代理Bob提交证明由Bob付费(第三方收费采用后付费方式,如果Bob不付费,列入黑名单,广播至所有Meshbox,并通知与Bob有直接通道对方;如果有可能,此种情况下smartmesh公司可以进行适当补贴)。

d.保证金(不完善)。无网支付发送方要求预存发送金额的十分之一给meshbox作为保证金(大额转账比例更高)。如果Alice打算给Dave转账30个token(通过Bob、Carol),则Alice发送间接转账给Bob时,还需要额外发送直接转账3个token给meshbox作为保证金(需要标记发送方address、通道ID、nonce区分不同的交易),meshbox收到保证金通知Bob可以接收此笔转账。同样,Bob和Carol中转这笔交易时,也需要额外转账3个token给mesbox作为保证金。保证金数据定期汇总至smartmesh公司服务器(以防meshbox崩溃)。当Alice在有网条件下关闭通道结算后,如果Alice在链上使用旧余额被第三方或Bob证实,Alice保证金将转给Bob作为补偿。有以下几种情况:

l 第三方或Bob有网时观察到Alice结算时使用了旧余额,提交证明给meshbox,得到Alice的保证金。

l 如果Alice结算时提交了正确的余额证明,第三方或Bob有网时验证无误后通知meshbox,保证金退还给Alice(还需要考虑锁的情况

l 如果Bob或第三方一直不通知meshbox,则Alice在结算通道后等待1000块,向meshbox提交自己的结算证据(包含结算事件),由meshbox向Bob核实后,可取回保证金(Bob如拒绝,需提交自己最新的证明给meshbox,待meshbox有网后由meshbox核实决定)。

l Alice和Bob如果均恢复有网,可协商并提交双方签名请求meshbox退还双方保证金,meshbox核实无误后,将双方保证金返还。

e.信誉惩罚:黑名单(提高作恶方的成本)。在第三方或委托方有网的情况下,一旦证实关闭方节点作恶,提交证明给meshbox。meshbox将该节点列入黑名单,并通知与该节点有直接通道的对手方,揭示风险。以Alice和Bob为例,Bob无网状态下委托第三方监控Alice和Bob之间的通道。假设第三方或Bob均没有在Alice结算通道之前恢复有网,Alice使用了旧的余额证明,不当得利。当第三方或Bob有网时,发现Alice作恶,为防止Alice继续作恶,将Alice不当得利的证据提交给meshbox,meshbox通知Alice申诉。如果Alice不能有效证明自己,则meshbox将Alice列入不诚信黑名单。列入黑名单的节点将不被允许使用meshbox无网支付,同时meshbox在有网状态下通知与Alice有直接相连通道的对手方,与该节点相连可能存在风险。与Alice直接相连的通道对手方可能出于安全考虑关闭通道,Alice链下支付的机会将大减。虽然,Alice可以放弃这个账号重新与其他节点建立通道,但由于切换账号(将一个账号内的token转给另一个账号)需要成本和时间,也可以大大减少其作恶的动力。

随机无网支付要求高,接受限制条件下才允许执行,需要APP预先告知用户如何更好的使用才能保证安全(如果用户有把握8小时之内能联接上网,或者能够委托到有网的第三方,那么放心的接收支付)。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018.11.09 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.背景知识:链接支付
  • 2.无网支付描述
  • 3.存在的安全性问题
  • 4.限制无网安全性情况分析
  • 5.限制无网限制条件设想
  • 直接无网交易场景描述
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档