EOS REX 安全系列之從源碼開始玩轉 REX(二)_ORD

BySlowMistTeam前言

上一篇文章粗略分析了整個買賣rex的流程，由于篇幅的原因，剩下有一些細節沒有分析到位。所以，這篇文章將在上一篇文章的基礎上對一些細節進行深入的分析。前情回顧

上一篇介紹了買賣rex的流程，涉及到了幾個函數，我們一起回顧下：1、deposit：用于充值，將EOS變成SEOS，也叫預備金。2、withdraw：用于提現，將SEOS換回EOS。3、buyrex：用于從用戶的預備金中扣除相應的份額，并用于rex的購買。4、sellrex：用于賣出已經結束鎖定的rex，并將本金連帶收益一起放進用戶的預備金賬戶中。5、add_to_rex_pool：用于將用戶購買的rex放進rex_pool中，并根據rex_pool中的相關信息計算出用戶能夠購買的rex的數量，被buyrex函數調用。6、fill_rex_order：處理用戶賣單，計算收益。以上幾個函數除了sell_rex和fill_rex_order其他函數都介紹得差不多了，本文將重點介紹這兩個函數的細節。sellrex函數

分析 | PeckShield：黑客利用EOS系統合約無限挖礦漏洞已完成修復:據IMEOS報道，隨著EIDOS挖礦的持續火熱，PeckShield全程跟蹤監控，黑客從DApp到交易所再到EOSIO系統合約進行惡意挖礦的行為，并向社區發出預警。今天，EOSIO新升級V1.8.1版本修復了短賬號競拍系統存在的無限挖礦漏洞。另PeckShield安全人員進一步分析認為，昨天黑客利用onerror特性挖礦消耗的僅為個人賬戶CPU，并不能無限制使用系統CPU資源，經官方修復短賬號系統缺陷后，黑客通過EOS系統惡意挖礦的預警已暫時解除，但DApp開發者和交易所仍要持續關注實時CPU消耗情況，應過濾合約賬戶避免被惡意竊取CPU資源。[2019/11/13]

以上為sellrex函數的具體實現，從開頭開始一步一步進行分析。首先拋開runrex這個函數，這個函數并不屬于本次討論的范圍，runrex函數主要用于處理rex_pool的信息，包括處理到期的資源租賃訂單，回收用戶資源，處理用戶的rex賣單等，有興趣的同學可以先自行研究，以后的文章也會進行單獨的分析。接上篇分析，sellrex函數我們分析到了fill_rex_order函數就沒有繼續往下分析了，fill_rex_order函數也只是講了最核心的收益公式，這次我們來仔細進行分析。sellrex流程如下：1、經過了一系列的檢查之后，獲取用于已經解鎖的rex的數量，調用fill_rex_order獲取用戶的賣單。2、賣單攜帶著訂單的完成狀態，這是一個flag，分為成功和失敗兩種狀態，當狀態為失敗的時候，進入上文的if條件。2.1、訂單狀態成功訂單狀態成功的時候current_order.proceed的值大于0，這個時候通過update_rex_account將賣rex的所得轉至用戶的儲備金賬戶。用戶就可以直接進行提現或者繼續下一輪的購買了。2.2、訂單狀態為失敗這個時候創建一個order，我們這里為了不混淆，不說賣單，而是說為欠條，是一個REX平臺給你的借條。什么意思呢？打個比方，你去商店訂購商品，商品存貨不足，這時候怎么辦呢？這時候商店就會給你打一個單，這個單記錄了你是誰，你要買多少的商品，買的時間等信息，等有貨了就會根據這個單給你補上商品。REX也是同樣的道理，用戶在賣rex的時候，由于rex_pool中的資金不足以支付用戶的本金+收益，就會將用戶的訂單暫時掛起。這就是REX給你打的欠條，當REX資金充足的時候，就會把錢還你。當sellrex失敗的時候，這個借條記錄了以下信息:賣rex的用戶。要賣的rex的數量(記錄在rex_requested字段中)。用戶的收益，此時為0，因為rex沒有賣出去，收益是不存在的。抵押狀態，這個抵押狀態是由于buyrex的時候，根據購買的數量會產生的相應的票權。這個欠條創建的時間。3、最后，檢查掛起的金額有沒有超過已經解鎖的rex的數量。以上就把sellrex完整的講完了，但是還有一個疑問，就是為什么會存在資金不足的情況，以及如何判定資金不足？這些秘密都在fill_rex_order里面。下面就詳細的分析fill_rex_order函數。

行情 | EOS在15分鐘內上漲2%:據Huobi數據顯示，EOS在15分鐘內快速上漲，漲幅超2%，波動較大，請做好風險控制。[2018/12/12]

上一篇文章我們分析了核心的收益公式是怎么計算出來的。這次從11行開始，看看這個函數做了什么：1、首先獲取unlent_lower_bound的值，即最低未出租rex_pool中的EOS的數量。這個字段等于用戶從rex_pool中借用資源的總量，是以EOS為單位的。2、計算available_unlent的值，這個值有可能為負數，為什么呢？假設一個場景，你是一個投資經理，你手上有很多投資人的錢，然后你把投資人的錢拿出去放貸收取利息，那么請問，這個時候你手上的資金還有多少？答案自然是：投資人的錢-放貸資金+放貸收益。REX相當于這個投資經理，用戶可以用少量的成本(EOS)換取大量的貸款(資源)，這個時候，REX的資金池中的資金就就變成了：用戶的資金-租用的金額+租用收益。根據前面的描述，用于租用資源的資金總是小于REX平臺出租出去的資金，也就是說在持續出租資源的時候，rex_pool中的資金總是不斷變少的(這里不討論系統收益的情況)。想清楚這一點，就能明白為什么available_unlent的值為負數了，當出租出去的資金大于rex_pool中當前資金+收益的時候，這個值就會為負數。3、判斷用戶出售的rex獲得的收益是否小于rex_pool中的剩余資金，相當于投資人想要回自己的錢，這個時候分兩種情況：3.1、如果資金不夠，那么這個訂單就會掛起，此時由sellrex函數創建一個欠條，這就是訂單失敗的由來。3.2、如果夠的話，則從rex_pool資金池中減去用戶收回的資金，更新相關的表字段，更新用戶的rex_balance賬戶，扣除相應的rex解鎖金額。那么到這里，整個sellrex的流程都講清楚了，流程圖是這樣子的：

動態 | EOS DApp24小時活躍度報告:根據SpiderStore的數據顯示，過去24小時EOS DApp按用戶數排名前五名是：BetDice，Endless Dice，Endless Game，PRA糖果盒，EOS騎士，其中第一名BetDice，用戶量達36540。按交易量排名，前五名是：BetDice，EOSFaker，Newdex，EOS Max，EOSBet，其中第一名BetDice，交易量達1992390 EOS。[2018/12/2]

安全性分析

由于本次沒有拓展新的函數，所以安全結論是和上篇是一樣的，但是這次我們可以對上次說的安全問題有更深的了解。在原先版本的rex合約中，是沒有check(pending_sell_order.amount<=bitr->matured_rex,"insufficientfundsforcurrentandscheduledorders")這一個校驗的，這會導致什么呢？我們知道，當資金池中的資金不足以支付用于的賣單的時候，將跳過if判斷下的所有步驟，直接由sellrex函數掛起訂單，在這種情況下，惡意用戶在系統資金池資金不足的時候，就可以一直賣rex，疊加掛起訂單的rex金額，直到資金池有足夠的資金支付，出售比購買rex數量更多的rex。但是這樣操作還是會賣不出去，因為最后更改用戶rex_balance的時候由于asset結構體自帶的溢出檢測，是不能成功賣出去的。但是這就會讓這個訂單成為一筆壞賬，在這種情況下，因為有未完成的sellrexorder，整個REX系統將停止運行。具體原因是什么可以自己去發現，答案會在下一篇文章揭曉。文章可能有說得不對或說得不夠好的地方，歡迎討論交流。詳情參考：https://eosauthority.com/blog/REX_progress_with_testing_and_implementation_details往期文章

行情 | EOS 15分鐘跌幅超過1.00%:據Bitfinex數據顯示，EOS 15分鐘內跌幅超過1.00%，現報價5.12美元[2018/8/12]

EOSREX安全系列之從源碼開始玩轉REX(一)聲明

本文僅用作技術參考，不構成任何投資建議。投資者應在充分了解相關風險的基礎上進行理性投資。

EOS領漲市值前20加密貨幣:據coinmarketcap數據，在市值前20加密貨幣中多數下跌，只有EOS、以太坊和Tether上漲，其中EOS漲幅最大，漲1.77%。[2018/6/10]

Tags：REXEOSSELORDDeFireXleos幣雷石鏈SellTokenLord Arena

FIL幣