AD
运行5年后，以太坊的现状如何？
运行5年后，以太坊的现状如何？来源于陀螺财经专栏作家陀螺精译，内容简述：回顾以太坊的那五年。
36小时内，眼看他起高楼，几分钟内，眼看他楼塌了。
%20北京时刻08月13日上午03时整，备受瞩目的%20DeFi%20项目%20YAM%20Finance%20宣告启动流动性挖矿，仅仅一天时刻锁仓资产代价就凌驾了6亿美圆，其锁定资产增量和增速都到达了近乎癫狂状况。且照此生长，一些初期给池子注入流动性的羊毛党年利率以至可迫近200倍，其猖獗水平可见一斑。
%20不过，合理人人都堕入挖矿狂欢的时刻，不测发作了。
%20北京时刻08月13日凌晨，YAM%20Finance发明其智能合约的弹性供给机制（rebase）存在破绽，以致合约第二次%20rebase%20触发时会锻造大批分外代币，这意味着将来社区将没法取得充足的代币来实行任何治理操纵，YAM%20将成为一个失控的机械，终究将完全落空社区用户的信托。
%20该如何挽救我们的%20YAM%20小红薯呢？
%20在发明破绽后，YAM%20团队发起了“挽救行为”，称他们须要16万托付投票才提交治理提案，因而向社区发起号令投票。很快，这场大张旗鼓的社区投票行为就完成了。
%20但是，就在人人认为只是虚惊一场的时刻，北京时刻08月13日下昼16时01分，YAM%20创始人%20Brock%20Elmore%20却发推特称，对不起人人，我失利了。这究竟是怎么回事呢？
%20PeckShield%20平安职员参与剖析后，敏捷定位到问题的实质在于：弹性供给机制（rebase）存在一个代码公式的毛病，以致第二次%20rebase%20触发时体系会自动增发10%20^%2018个新代币，假如行情一向坚持高位的话，那末今后的每次%20rebase%20触发时都邑举行指数级的增发，这将使小红薯%20YAM%20的数目变成一个恐怖的天文级数字。这意味着，不管后期社区如何托付投票，都没法取得充足的投票量对体系举行掌握，全部体系将堕入失控无主状况。
%20原本%20YAM%20官方召唤宽大%20YAM%20持有人经由历程代办投票的体式格局，一同完成此次投票“挽救行为”，以修复这个存在的破绽。但是，PeckShield%20平安职员进一步剖析发明，当YAM%20官方入手下手发出号令的时刻，此次挽救行为实在就已必定失利了。
%20缘由有二：
%201）时刻来不及：YAM%20官方也许疏忽了一点，在其提案投票挽救行为准备工作完成后，也须要最少12.5个小时才被实行见效，而依据现在的时刻节拍，当实在行见效时，第二次%20rebase%20早已触发。
%202）新布置治理合约没法被有用实行：由于第二次%20rebase%20触发，因而官方本来预期要实行的新治理合约到了实行时刻后，却发明由于投票总量远远没法到达合约商定的总量的4%，故而没法被有用实行。
%20究竟是为什么呢？接下来上手艺干货：
%20手艺提要
%20起首引见下%20YAM%20智能合约的弹性供给机制（rebase）：
%201）体系会依据市场价钱浮动来动态调解代币的供给量，当时价上涨时则按比例增发代币，以下降单元代币的代价，直至降至1美圆。
%202）天天离别实行两次%20rebase，每次%20rebase%20会转变代币供给量，依据市场现价增发或烧毁一定量的代币。
%20再说一个实行提案的症结因素：持有者举行托付投票，投票数凌驾总量的1%，则提案才可以举行实行分列，且按合约商定实行分列时长须要守候12.5小时，而提案实行时，则投票须要凌驾总量的4%。云云新治理合约才实行见效，项目才继承一般运转。
%20有了以上几个手艺要点的铺垫，我们再来看一下，YAM%20官方的跟进时刻表，就可以邃晓此次挽救行为为什么必定会失利。
%20如下图时刻线所示：
%20②是第一次%20rebase%20触发的时刻，由于合约的%20bug%20以致%20totalsupply%20资产发作非常狂涨，官方发明%20BUG%20存在并举行了表露。
%20③是官方宣告发起布置新治理合约的时刻，在此以后社区入手下手启动投票。
%20④是投票目的开端完成，新治理合约进入实行分列的时刻，自此守候实行12.5小时合约正式实行。
%20⑤是第二次%20rebase%20的触发时刻。
%20⑦是其新治理合约投票经由历程后正式实行的时刻。
%20⑥%20在第二次%20rebase%20触发后的第31分钟时，也许是项目方发明了已无力回天了，提案作废胜利，项目方正式宣告%20YAM%20失利。
%20①以后的绿色地区是投票和提案挽救行为可以胜利的“黄金抢救期”，须要全部挽救行为准备工作在第一次%20rebase%20触发之前半小时内完成。（即蓝色虚线应提前到绿色地区内）。
%20这意味着，YAM%20官方应在第一次%20rebase（北京时刻08月13日凌晨04:08)之前就应该发明这个破绽，而且留有充足的时刻完成新治理合约布置和投票。
%20但是适得其反，官方发明破绽并表露号令投票的时刻照样太晚了，错过了唯一可以胜利的黄金抢救期。而更蹩脚的是，依据官方的时刻节拍，当新治理合约到了⑦实行的时刻后，投票数要凌驾总量的4%才行，而现在的总量已扩展了10^18*10^18，此前积累的投票数已然杯水车薪，基础杯水车薪。
%20所以，此次挽救行为一入手下手就必定了会失利。
%20下面我们会对此次事宜做下细致剖析：（项目方github地点%20https://github.com/yam-finance/yam-protocol）
%20细致历程剖析
%20起首我们看下当第一次%20rebase%20发作了什么：
%20图1.%20第一次%20rebase%20资产变化
%20如上面链上信息（https://oko.palkeo.com/0x7b9017ec92b0200455e5269380195fbecfbf91c8acda30985cc1dc413d215076/）所示，当第一次%20rebase%20以后，totalSupply从3,500,000*%2010^18狂涨到一个极大值。
%20我们进一步剖析代码，看下在代码中发作了什么：起首从链上信息我们能看到%20rebase%20操纵挪用的是%20YAMRebaser%20合约的%20YAMRebaser::rebase()函数（我们先跳过这个函数稍后再讲），我们终究发明它经由历程挪用%20YAM合约（0xa923af6d05993495257a872ec69dbbf01501eb0e）的%20rebase()函数从新盘算totalSupply（代码逻辑如下图2中所示），在第340行的%20totalSupply%20赋值操纵可以看到，这一行代码有个显著的毛病——没有除%20BASE，从而以致%20totalSupply%20的值暴增了10^18倍。
%20YAM%20官方在第一次%20rebase%20今后发明了这个问题，因而表露%20rebase%20bug%20事宜启动了投票挽救行为。
%20图2.%20YAMToken::rebase()%20获得一个非常大的totalSupply值
%20而在12小时以后，YAM%20又触发了第二次%20rebase（https://oko.palkeo.com/0x32735e9e9aac51739b5725a225be6c7a3851f422be986d0f4f4bc0ec475ee286/），这个数据又是以基于毛病的%20totalSupply%20来盘算的，从而以致%20initSupply%20的数值一样涌现了非常。
%20图3.%20第二次%20rebase%20资产变化
%20我们继承剖析形成%20initSupply%20非常的成因，症结在上面提到过%20YAMRebaser::rebase()函数，这个函数完成的重要逻辑：先基于%20yam.totalSupply()%20盘算出本次%20rebase%20须要增发的%20YAM%20数额%20mintAmount，在%20afterRebase()函数经过数层挪用后进入%20YAM%20的_mint()函数，基于非常的%20mintAmount%20给%20initSupply%20举行赋值。由于在第一次%20rebase%20中，totalySupply%20已变成一个极大值，所以基于此非常值的后续一列操纵（如图4中赤色箭头所示）终究以致%20initSupply%20也盘算毛病，变成了一个天文级的数值。
%20图4.%20YAMRebaser::rebase()%20用毛病的totalSupply盘算initSupply
%20当第一次%20rebase%20涌现非常时，项目方已发明问题并决议提出一个修复体系的提案（proposal），愿望经由历程投票的体式格局将此提案排入实行行列而且实行。当此题案收到充足多的投票，治理合约（Governor）许可任何人经由历程挪用%20GovernorAlpha::queue()%20函数将此题案排入实行行列。但由于此治理合约代码逻辑的完成，以致不管是在第二次%20rebase之前或是以后举行修复，都没法准确实行这个挽救行为。
%20为什么说项目方准备工作完成的太晚了？
%20我们看下图中的%20GovernorAlpha::queue()%20代码，我们注重到了在挪用%20_queueOrRevert%20函数之前的第224行中设置变量%20eta%20=%20current%20timestamp%20+%20timelock.delay（12.5%20小时），这就使得见效时刻必定在到场行列的12.5小时今后，而第二个%20rebase%20时刻是与第一次距离12小时，这就意味着要实行胜利须要将挽救行为提前到第一次%20rebase%20之前最少半小时以上，否则将永远没法实行。
%20图5.%20GovernorAlpha::queue()%20函数设置eta（见效时刻）
%20又为什么说已做出的挽救行为，基础杯水车薪呢？
%20当触发合约%20GovernorAlpha::execute()时起首会先实行%20state%20函数来取得当前提案状况。
%20图6.%20GovernorAlpha::execute()%20检测提案状况
%20鄙人面的%20state()函数%20第330行，假如%20proposal.forVotes%20=%20againstVotes()%20，提案状况被设置为失利。
%20图7.%20GovernorAlpha::state()实行返回Defeated毛病
%20从代码中能看出来，项目方在设想体系时，投票数被设想为必需大于%20initSupply%20总量的4%，此提案才是正当的状况，如下图所示。但是，当第二次实行%20rebase%20今后，initSupply%20已被搞成一个极大值。这就以致了，投票票数（forVotes）永远不大概%20=%20quorumVotes()，从而老是返回%20Defeated。
%20图8.%20GovernorAlpha::quorumVotes()返回一个毛病的非常值
%20除了提案状况非常的问题以外，如图9、图10所示，当第二次%20rebase%20发作今后，由于%20GovernorAlpha%20::%20propose()%20搜检投票数必定小于%20proposalThreshold（1%的initSupply)，因而新的提案也再也没法被提出，更遑论要投票实行了。
%20图9.%20GovernorAlpha::propose()检测投票数是不是大于1%%20initSupply
%20图10.%20GovernorAlpha::proposalThreshold()%20返回1%%20initSupply
%20总结
%20此次YAM%20破绽事宜，终究形成治理合约中75万枚yCRV被永远锁定，而且短时刻内的急速狂跌和无力回天的局势，不知道有多少人被埋在了价钱高点，其猖獗水平成了现在%20DeFi%20流动性挖矿的最真实写照，其严酷魔幻水平何尝又不是？倘使项目方在布置合约之前凡是测试过一次%20rebase%20流程，必定能捕捉到破绽的存在。足以见得，DeFi%20项目做平安审计的重要性。
%20综上剖析，PeckShield（派盾）想借此劝戒诸君，在区块链天下里，务必要对每一行合约代码坚持畏敬，由于任何纤细的疏漏都大概形成没法挽回的局势。毕竟，代码是人写的，破绽也很难被完全防止，因而须要项目方在合约布置上线前就做好充足的测试和第三方平安审计工作，这会协助其更早发明并排查合约代码潜伏的平安破绽，不至于比及，破绽发作后，亡羊补牢，为时已晚。
%20 %20加入新手交流群：每天早盘分析、币种行情分析
添加助理微信，一对一专业指导：chengqing930520
上一篇：本日引荐 | 区块链巨子将降生在那里
加入新手交流群：每天早盘分析、币种行情分析，添加助理微信
一对一专业指导：chengqing930520
最新资讯
