比特幣:合約實現中的事與愿違——實現與設計不符_比特幣最新價格行情走勢

針對區塊鏈安全問題，成都鏈安科技團隊每一周都將出智能合約安全漏洞解析連載，希望能幫助程序員寫出更加安全牢固的合約，防患于未然。

引子：出塵花品愛池荷，零落秋風可奈何——《病中詠秋荷》清·蔡桓

本期話題

邏輯判斷失誤事與愿違，功能實現不周弄巧成拙

智能合約作為區塊鏈技術革命的核心，乘著以太坊興起的潮流，發展至今已經兩年有余。智能合約的理念最早可以追溯到1995年，幾乎與互聯網同時出現。廣受贊譽的密碼學家尼克薩博最早提出了這個術語，他也是為比特幣打下基礎的學者之一。隨著比特幣的出現和應用，讓智能合約的理念有了實現的機會。

從原理上來說，智能合約的執行依靠的是條件的觸發，也就是類似于程序中的if-then語句。也就是說，智能合約對于其中合同條款的執行取決于預先編譯好的邏輯判斷，進而與真實世界的資產進行交互。本期，我們歸納總結了一些在從設計到實現的過程中出現安全漏洞。

Aku項目方價值3,400萬美元ETH被永久鎖定，系合約實現邏輯問題:4月23日消息，NFT項目方Akutar的11,539.5 ETH（約合3,400萬美元）被永久鎖定在拍賣合約。

Aku采用的是類似荷蘭降價拍賣的形式，拍賣結束后會按照結束價格給用戶退還超過最低價格的部分，因此這涉及refund以及total bids統計兩個方面，而項目方在這兩個方面均存在實現邏輯問題。

第一個漏洞，processRefunds() 會被惡意合約阻斷，實現DoS攻擊，也確有用戶使用惡意合約阻斷了processRefunds(）執行，但該名用戶表示只是讓項目方確認問題存在，隨即設置惡意合約變量，使得processRefunds(）順利執行完，因此該漏洞雖被利用，但已成功解決。

第二個漏洞，也就是真正導致項目方無法提款的關鍵所在，processRefunds(）是按照msg.sender的數量記錄在了refundProgress變量，拍賣結束項目方調用claimProjectFunds()取出合約內的ETH時，要求滿足refundProgress >= totalBids，而totalBids記錄的是NFT的數量，合約最終狀態refundProgress數值為3669，totalBids數值為5495，從而導致項目方無法提取合約內的11539.5 ETH。

需要指出的是，在執行processRefunds(）之前，參與拍賣的用戶可以在三天后通過emergencyWithdraw()將個人投入的ETH取回，但由于processRefunds(）的執行，導致用戶的拍賣狀態由未處理變為refund，從而不能再進行emergencyWithdraw()。[2022/4/23 14:43:41]

智能合約愈發復雜

Gate.io已上線THETA和 ZIL永續合約實盤交易:據官方公告，Gate.io已上線THETA/USDT和ZIL/USDT永續合約實盤交易，支持1-20倍做多和做空操作，杠桿率可以在下單時自行選擇。Gate.io永續合約是全球最活躍的區塊鏈資產合約市場之一，日交易量高達8億美金，結算類型分為“BTC結算永續合約”和“USDT結算永續合約”兩種。

Gate.io提示：請用戶務必在完全了解風險并能承擔風險的情況下參與，Gate.io平臺不對投資行為承擔擔保、賠償等責任。[2020/12/28 15:54:46]

我們都知道，一個智能合約包含兩部分：代碼邏輯和數據。

相比于比特幣的腳本語言，智能合約發展的一個終極目標就是“圖靈完備”，簡單來說，就是無論怎樣復雜的交易邏輯或功能都可以實現。

智能合約的開發經過一段時間的沉淀，已經由最初簡單的轉賬、付款等功能需求，向越來越多的交易功能和邏輯進化，比如凍結、暫停、中止、授權。根據復雜性理論，越復雜的系統越容易有出錯的可能。因此，越是功能強大的智能合約，其邏輯就越是復雜，也越容易出現邏輯上的漏洞。

火幣合約新增多個品種合約實時結算功能 盈利部分可隨時劃轉:據火幣合約官網公告，火幣合約已于新加坡時間2020年12月17日11:00上線LINK、TRX、XRP和ADA幣本位交割與幣本位永續合約實時結算功能。目前，這兩個產品已支持包括BTC、ETH和LTC在內的7大品種實時結算。

同時，火幣U本位永續合約也上線了TRX、DOT、ADA、EOS和BCH永續合約在全倉和逐倉模式下實時結算功能，加上此前已經上線的BTC、ETH、LINK、XRP和LTC，支持實時結算的品種擴展到了10個。

據悉，目前市場上合約的結算機制大多為周結算、日結算或每日三結，而實時結算功能需要強大的風控實力支持。火幣合約上線以來保持全品種合約“零分攤”，業界率先推出實時結算功能，用戶已實現盈利部分（扣除掉浮動虧損和占用擔保資產等）支持隨時提取，無需等到結算或交割后，從而有效提升資金使用效率。[2020/12/17 15:32:16]

開發合約也會言多必失？

火幣將BTC、ETH和LTC合約實時結算功能試行延長至今年12月:據官方公告，火幣合約平臺決定將BTC、ETH和LTC合約實時結算功能延長至2020年12月31日，其中涉及合約品種包括，交割合約：BTC、ETH、LTC，永續合約：BTC、ETH。[2020/6/30]

打個比方來說，邏輯更加復雜的代碼相當于更龐大的城池，在容納更多人口的同時，需要防守的地方也更多。有些精心設計而又容易忽視防范的地方，比如錯綜復雜的下水道系統，正是容易讓整個城池淪陷的重大隱患。

同樣，在智能合約中，開發者為自己的合約設計的特殊功能意在穩固代幣的市值或者項目的壽命，而正是在這些邏輯和功能中，一個細微的失誤，比如>、<、+、-這些符號的錯誤就可能導致整個邏輯與預想出現嚴重的偏差，留下致命的隱患。

代碼實現失誤漏洞總結

IBM旗下金融平臺測試智能合約實時交易:據Global Trade Review 消息，IBM旗下金融平臺Batavia成功測試智能合約實時交易，交易方包括奧迪。Batavia有IBM區塊鏈平臺科技和五大銀行財團作為支持。近期的平臺測試依賴分布式賬本智能合約。奧迪首席財務官表示：“我們為這項去中心化的數據庫的研發付出了大量的時間。通過Batavia平臺實現的區塊鏈交易讓我們獲得了重要的實操經驗。”[2018/4/30]

我們將代碼實現過程中產生的失誤分為兩種：

1.邏輯判斷錯誤

Solidity的if或者require等條件判斷表達式對合約代碼執行做出限制，開發者如果在編寫合約時寫出了錯誤的判斷條件，將會造成比較大的邏輯錯誤，影響合約正常使用。

a)transferFlaw

在transferFrom()函數中，當對allowance值做校驗的時，誤將校驗邏輯寫反，從而使得合約代碼的邏輯判斷錯誤。有可能造成溢出或者任何人都能轉出任何賬戶的余額。

我們來看一個案例

if(allowed>=value)returnfalse;此處校驗邏輯寫反了，導致只要授權值allowed小于轉出額度，那么都能轉賬成功，利用這個漏洞，可以不經授權就可以轉出他人賬戶中的代幣。

l漏洞修復

推薦使用require(allowed>=value);語句對授權額度進行判斷

b)pauseTransfer-anyone

以如下案例合約為例

onlyFromWallet中的判斷條件將==寫反了，寫成了!=，使得除了walletAddress以外，所有賬戶都可以調用enableTokenTransfer()和disableTokenTransfer()函數，這兩個函數可以開啟或者關閉合約的轉賬、授權以及燒幣功能，進而影響合約的正常使用。

l漏洞修復

使用正確的require判斷語句：

c)allowAnyone

分析如下案例合約

在transferFrom函數中，轉賬前未對allowed進行校驗，轉賬后對allow的計算也未使用SafeMath，使得任何賬戶都可可以不經授權就能夠轉出他人賬戶中的代幣，并且，如果轉賬額度_value大于allowed，allowed-=_value將發生溢出。

l漏洞修復

i.在轉賬前增加對allowed的檢查，require(allowed>=_value);;

ii.使用SafeMath對allow進行運算，

allowed=allowed.sub(_value);

d)approve-with-balance-verify

部分合約在函數approve()中，增加對被授權賬戶余額的校驗，要求授權的_amount小于或等于當前余額。

一方面，對余額的校驗并不能保證被授權賬戶一定可以轉出這個數量的金額:

i.在approve之后，token的所有者自己通過transfer函數，把token轉走，導致余額小于allowance。

ii.approve給多個人，其中一個人進行transferFrom操作后，可能導致余額小于之前給其他人approve過的值。

另一方面這個校驗可能導致外部合約無法正常調用，必須由Token項目方提前轉入一筆數額巨大的Token至中間賬戶才能繼續執行。

例如下面這個合約

l漏洞修復

去掉balances的校驗:

2.功能實現與設計不符

我們來詳細分析如下案例合約：

上述兩個函數重寫了ERC20標準中的transfer和transferFrom函數，添加了對凍結賬戶的檢查。

在transfer中，如果msg.sender被凍結，那么其不能進行代幣交易。

但是，我們注意到，在transferFrom中，并沒有對代幣轉出地址的檢查。

如此一來，一個被凍結的地址可以通過授權第三方，然后通過第三方地址向目標地址發送代幣，違背了設計中對凍結地址的限制。

l漏洞修復

在合約正式上鏈前，項目方應對合約進行充分的測試，確保其實現完全符合設計。

我本將心向明月，奈何明月照溝渠

以上的安全漏洞都是開發人員在實現某些功能需求時，出現低級錯誤或者只追求完成功能需求導致的。相信在漏洞被曝光或者被攻擊者利用時，開發者的內心也是崩潰的，感覺枉費了一番苦功夫。在沒有相關測試、審計團隊的協助下，對于此類實現與設計不符的漏洞可能真的束手無策，尤其是關于合約邏輯的檢測，可能需要用到形式化驗證運用數學建模的方法對于合約進行描述之后才能查遺補漏。但是，汲取他人教訓并且用于提高應該是每個先驅者在探索新領域時具備的素質，一個人可能會走的更快，而一群人，會走得更遠。

Tags：比特幣balance區塊鏈比特幣中國官網聯系方式40億比特幣能提現嗎比特幣最新價格行情走勢balance幣是什么幣區塊鏈工程專業學什么區塊鏈存證怎么弄區塊鏈技術發展現狀和趨勢

中幣