查看原文
其他

注意 !Finance Attack

Midsize Stafi 2020-02-12

PoS还不够安全?
2018-2019年,以链上借贷为主的DeFi项目蓬勃发展,越来越多的人将自己的加密资产,放在带有借贷合约的钱包中生息,也有越来越多的人将加密资产作为抵押品,放到借贷合约中。于是开始有人关注,如果上述两种获益方式更具有吸引力,那谁还会参与stake,维护网络安全呢?
 
Tarun Chitra在他的论文《质押与链上借贷的制衡》 (《Competitive equilibria between staking and on-chain lending》)中谈到一个结论:理性且没有恶意的参与者为了优化他们的资产收益,选择将他们的token从Stake合约中转移到借贷合约中,从而降低了PoS网络的安全性。Tarun通过蒙特卡罗法,详细模拟了这一情况是如何发生的。

In particular, we find that ‘bank runs’ can occur when many agents collectively move their tokens from staking contracts to lending contracts even when agents have indpendently drawn risk preferences. These attacks, which are coordinated only by rational optimization, show that the strictly Byzantine threat model is insufficient to describe security in PoS networks.



另外Tarun还提到更令人担心的情况,就是恶意破坏者,通过提供一个有吸引力的利率借到足够多的token,从而干扰共识过程,对系统实施攻击。PoS系统的威胁模型中,除了防范Nothing At stake问题和长程攻击(Long Range Attack),还需要留意一种新的攻击方式——金融攻击。

However, if there exist physically settled futures contracts on PoS tokens, then it is possible for an attacker to buy futures that allow for staking participants to sell their staked token in the future. This attacker can aggregate this stake and upon reaching an attack threshold, begin to perform a double spend or other malicious attack . As these derivatives can be settled off-chain (e.g. using a centralized exchange like BitMEX or Deribit), monitoring of this type of attack can be difficult.



 
有文章指出“DeFi正在侵蚀PoS系统的安全”,也对这一情况进行了论述。但“DeFi侵蚀PoS系统安全”的说法并不准确。遭遇金融攻击的可能性,是PoS的内生属性。在DeFi出现之前,token的借贷就已经存在。在PoS网络中,token本身承担了两重属性,既维护作为维护网络安全的载体,又要作为流通媒介,被赋予货币属性,因此很容易被衍生出更多金融用途。
 
攻击者如何实施金融攻击?

金融攻击的可怕在于,实施攻击的投入产出比,看起来非常划算。

攻击者不太可能通过买入token的方式实施攻击,因为买入的代价过大,而买入行为本身也会推高token价格,对于攻击者而言是不划算的,攻击者更有可能采用的是借入token来实施攻击,而且攻击者可以用期货交易的方式,把攻击后token贬值的损失转嫁出去,还从中赚一笔。
 
我们来推演一下,攻击者可能采用的步骤:

  • Step1:提供足够高的利率,吸收到足够多的token,超过临界值之后,参与到Stake中(我们假设攻击者的抵押资产足够大,有足够的借贷能力)。

    这个临界值,对于使用了BFT机制的PoS网络来说,是Staking token总量的1/3,对于没有采用BFT机制的PoS网络来说,一般认为是Staking token总量的1/2。(后面主要以采用了BFT的PoS网络为模型论述)


  • Step2:攻击者和其他市场主体签订期货合约,约定在未来某个时点,用现有的价格卖出手里的token。为了隐蔽,攻击者可能有多个身份ID,也可能找了多个互不关联的市场主体来签订期货合约。


  • Step3:实施对BFT的攻击,阻碍共识过程进行,使得系统瘫痪,或者,实施一笔双花,使得账本不再被信赖,无论哪种形式的攻击,只要攻击成功,都会导致token被抛售,价值大跌。


  • Step4:从市场上低价买入token,完成期货交易。


  • Step5:  受攻击的链会察觉到攻击,有可能会slash掉攻击者的token,没有关系,再低价买入一批token,偿还借来的token和利息,赎回抵押物。


我们来算一下攻击者的账:
攻击者借到的token,假设价值为V1 
攻击完成之后,攻击者的token价值跌到了V2 
攻击者借入V1 ,攻击者完成期货交易支出V2 ,攻击者偿还借出的token支出V2 
所以攻击者的毛利
 
ΔV=V1-2V2 

如果计算更细致些,还需要把攻击者承担的借入token的利息,还有攻击者借入token时的抵押物的资本成本计算进去。
 
假设利率为 r  ,攻击周期为, 攻击者的利息在期末支付,那么利息为 r*t*V2 
假设抵押时要求的超量抵押倍数为  ,那么抵押品的价值为  n*V1   ,抵押品的利率设为 u  ,则抵押品的资本成本为 u*t*n*V1  
 
攻击者的净收益为
 
ΔV = V1 - 2V2 - r*t*V2 - u*t*n*V1 

以上公式是个相对粗糙的计算,没有考虑以下两个要素,第一,如果攻击者更冒险,更贪婪一些,可以在Step2加大操作力度,卖空比持有token更多数量的token,实施成功的话,攻击者将得到更多的收益。
第二,攻击者可能自身有足够的信用以借到足量的token,而不用完全使用抵押物来借贷。
 
即便如此,我们依然看到,攻击者有巨大的获利空间。
 

PoW会遭遇金融攻击吗?

我们需要认识清楚PoS和PoW在经济学本质上的区别,PoW是一种惩罚前置的设计,不管你是不是对系统作恶,都需要先接受“惩罚”(消耗能源),只有在惩罚结束后,才有资格争夺获取奖励的资格。如果作恶,那么就有可能失去奖励。失去奖励,就意味着白白接受了惩罚。有点像中国古代的懒政官员审案的方式:不管原告被告,上来就是“何事叨扰公堂,先各打20大板”,打完了再论公道。

而PoS是一种惩罚后置的设计,质押的token只有在作恶后才会被Slash,所以攻击者可以先借入token,然后实施攻击。这种方式显然无法用于攻击PoW系统,因为能源首先要被消耗掉,攻击者无法通过借贷和做空的方式转嫁能源的成本。
 
这是不是证明PoS太过脆弱,我们还是得回到只有PoW一种共识机制选择的时候?
 

PoS机制如何克服金融攻击?

PoS共识机制从创生到现在,一路走来,不断完善,克服了很多问题,例如Slash机制的出现,克服了易分叉的问题,Jail机制解决了节点离线或者不出块的问题,委托机制的出现克服了共识效率的问题。金融攻击的问题,当然也并非无解。
 
防范金融攻击的思路,有多个角度,也会产生多个方法。

方法1动态响应的调整Stake收益率



PoS项目方通过强运营的方式,使得Stake的收益率始终相较于token的其他用途,具有相对优势。当面对攻击者吸储时,提高Stake收益率,可以直接和攻击者的吸储利率竞争,使得token向链内Stake合约流动。但提高stake收益率,会带来通货膨胀,使得人们对token价值的预期需要不断调整,不利于实现token在链上业务中本身需要承载的流通性。这不是一个可以无限制采用的方式。
 
方法2设置“熔断机制”

我们从攻击周期t入手,t是由两部分构成的,一部分是攻击者吸储的时间,一部分是实施攻击的时间。吸储的时间我们是可以干预的。项目方可以为Stake 中的token向外转移设置一个阈值,一个周期内,从Stake合约中移出token的数量有一个上限。(有点像股市熔断机制),这样一来,增加了攻击者吸储的时间,提升了攻击的成本。


方法3
项目方对链进行初期看护


项目最危险最脆弱的时候,往往是项目初期市值较小的时候,项目市值越大,借入足够多的token,需要的抵押物价值就越大,借入难度更高。项目方应该在项目初期的脆弱阶段,由自身和关联方控制大多数的token。这样做的弊端是可能会被诟病为中心化,或者是操纵市场。
 

方法4
增强市场信心的支撑要素

攻击者之所以能赚到钱是因为,预判成功攻击之后币价会迅速下跌,如果项目背后有一个积极活跃的应对团队,且有多方面的要素支撑市场的信心,那么攻击者实施攻击获利的可能性就相对较小,系统就越安全。我们看到很多PoS链和PoW有一点重要不同,PoW链成熟之后可以进入接近无人看管的自运行状态,而PoS则往往是强运营模式。
 

方法5
努力保持高Stake比例

保持高Stake比例是保障PoS网络安全最根本的措施。Stake比例越高,攻击者通过吸储来达到攻击阈值的难度就越大,周期(t)也越长,攻击意图暴露的可能性也越大。
我们假设攻击者的持币数量达到Staking总数量(包含攻击者即将参与stake的那部分token)的1/3时发起攻击。

当stake比例为30%时,攻击者需要从市场上借到70%中的15%时,可以发起攻击。当stake比例为50%时,攻击者需要从市场上借到50%中的25%时,可以发起攻击。当stake比例为66.6%时,攻击者需要从市场上借到剩余全部token时,才有可能发起攻击。
倘若如此,当Stake比例超过2/3时,系统几乎是“绝对安全”的。
 
攻击难度与Stake比例的关系

攻击难度系数我们用攻击者需要借到的token占非Staking的token数量比例来表示,数值最大为1,数值大于等于1时代表攻击不可能实现。

我们从图中可以看到,提高Stake比例对于提升PoS系统安全性有显著作用。
 
我前面提到的方法1,方法2,方法3,都可以作用于提高Stake比例。另外,我们还可以想到,有一种偏金融方式,可以更加彻底的保持高Staking比例。不少文章和业内朋友也都提过,那就是架构一层协议,发行基于Staking资产的债券。

在持币者将token参与到stake中时,给持币者发放一个债券(bond),这个债券代表了对token的赎回权,持币者随时可以归还债券,然后申请将stake中的token取回,在stake锁定期结束后,token回归到持币人的账户。当然持币人也可以将债券卖出。债券买卖带来的流通性解决了stake锁定中的token不能流通的问题。
 
这是Stafi采取的方法,早在人们关注token借贷行为侵蚀PoS网络安全的问题之前,Stafi就已经在做这样的事情,立足于解决Stakeing资产的缺乏流动性的问题。我们姑且称之为Stafi方法(Stafi way)。

 
Stafi 方法

 Stafi 方法可以极大的提升Stake比例。Stake和token的链外用途,将不是竞争关系,而是可以同时实现,对于借出生息行为,可以使用bond来代替原生token进行生息,原生token参与stake获取收益,双重收益,同时享受。对于作为抵押品借贷,也可以使用bond来代替原生token作为抵押品。参与stake获益,和作为抵押品借贷,两种用途,同时实现。
 
对于恶意攻击,我们来做一个推演。恶意攻击者可能会采取2种方式:

一种是不接受bond,坚持只愿意为原生token提供更高的利率

这种方式会面临两大障碍,首先是吸储的利率成本变大,攻击者提供的利率必须大于Stake收益和bond的市场利率之和,才有可能有效吸储,其次,由于Stafi方法极大的提高的初始的Stake比例,再结合我们之前提到的“熔断机制”,可以让攻击者的吸储周期变的很长,攻击成本增大的同时,不确定性也大幅度增加,因为项目方必然采取措施应对。
 
攻击者的第二种方式,是直接针对bond发动攻击

攻击者提供更高的利率给bond,从而吸引bond持有人将bond放在攻击者手里生息,汇集大量bond之后,攻击者未经持有人同意,私自将bond赎回为原生token,然后再发动攻击。我认为这种成功率也非常低,因为攻击者将bond集中赎回的过程,也会触发“熔断机制”,项目方可以采取措施应对。项目方能够采取的最激烈的措施,便是按下暂停键,冻结出块。此时,攻击者除了等待无计可施,而攻击者承担的金融成本随着时间推移,越来越大。虽然这种做法杀敌一千自损八百,但是只要这样的手段存在,攻击者就不会轻易下手,因此,达成了一种威慑平衡。
 

Stafi 方法,是PoS 安全生态演化的终局吗?

金融世界何其复杂,以后可能还会有更新的攻击方式出现。不过,无论我们对未来还有什么样的顾虑,Stafi方法的普及是必然会发生的事情。
 
因为用Bond来代替token承担链外流通的作用,与其说是Stafi的创造,不如说是人们想获取Stake收益,又不想放弃token的其他用途的需求催生的,是Staking生态的必然产物。这也是Stafi强调“Staking Finance”这一概念的主要原因。
 
更值得思考的是,当Stafi方法普及之时,还会有什么样的新的攻击方式威胁到PoS系统的安全。如果新的攻击方式出现了,我们还需要新的智慧去应对。
 

By 卡咩 & Middle  Stafi 区块链研究员(转载请注明出处)


系列文章


DeFi兴起,套利和未来 以太坊的杀手级应用?|MakerDAO和Bitshares | ABS Staking资产流动性 | 抵押资产 | Token估值模型




关注Stafi_Protocol
Stafi.io


Modified on

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存