【開發入門】EOSIO智能合約實戰#3
節點專欄
11天前
3748

EOSIO smart contract exericse #3


接下來這一篇中,特別介紹一下這個實戰例子,為什麼特別提到這個例子呢?? 因為這個案例用到了 EOSIO 本身特有的共識機制以及本身自帶的黑名單功能,所以可以說,底下的方法也向 dAPP 開發項目方說明了,在設計智能合約時,最好可以懂得底層原理,不是只是照著範例 copy & paste。


在 EOS 中,使用到了 21 個 BP (block producer) 為驗證交易 (transaction) 以及打包區塊 (block) 為主要工作,至於其它的全節點 (API node) 是不具打包區塊功能但是會做幫忙交易推播 (relay),只要交易是合法同被驗證過,全節點是可以做推播到其對應的 p2p list 上的其它節點的。 可參考EOSIO 節點出塊流程


當交易並沒有被 2/3 以上 BP 確認過後,基本上都是暫時的資料,要一直到完成了二輪的 BFT 確認才是完全不可逆。


另外,,在 EOSIO 中有個特別的功能 : 黑名單功能(config.ini/actor-blocklist),這個黑名單主要是讓 BP 可以濾除掉黑名單中的帳號交易(也就是說由黑名單發起的交易是會被 BP 拒絕的),而這黑名單清單主要是由 ECAF 所發出的,也就是說只要在黑名單的帳戶都不能執行任何的交易。但一般來說,除了 BP 外,很少有項目方會去跟蹤 ECAF 所發出的禁令並把黑名單定期更新自已的 API node 的,所以造成攻擊方有機會利用這機會。整個流程如下:


eos-blacklist-attach.png


攻擊者 (attacker) 的帳號本身是被 ECAF 列入黑名單的,但是攻擊者利用了一乾淨且不是黑名單中的帳號布署一個中介合約 (Proxy contract),中介合約主要的動作就是發起下注的動作也就是轉帳動作,但是轉帳的動作中 (Action) 所發出的 from 是 proxy contract 帳號, 並非黑名單的帳號,另外再加上 Dapp 項目方並沒有更新黑名單,且是可以接受 push action 的狀態下,接受了此一下注交易。在接受下注交易後,如果中獎了就會另外發起中獎交易,並一起推播到 BP 上頭去。


簡單來說,當下注後,中獎或是不中獎,攻擊者的交易都會被拒絕且回滾,但是如果是中獎的話,項目方的交易會被正確執行 (因為項目方合約是合法帳號的) 所以在追蹤此一攻擊時,會發現在 history 資料中只看到項目方一直開獎並轉帳,但是沒有看到相應的下注交易,對攻擊者來說,都是無本攻擊,不會損失任何的代幣。



快速總結一下這一篇的要點:


(A) 利用黑名單的攻擊已被確認可行,這部份需要項目方在合約中: (1) 開獎的動作(action) 需要確認下注訂單要存在 (2) 可以利用 EOSIO 提供的 TAPOS 功能,利用 ref-block 建立起開奬和下注交易的依賴性,也就是當下注被回滾時,開獎動作也要一起被回滾。


(B) 如果可行,多利用 EOSIO DB read-only 模式,避免 Dapp 直接讀取是本地端的暫存資料,應該是讀取的數據是至少被一個以上 BP 驗證 及推播出來的區塊資料,避色使用本地暫存資料。



回顧【開發入門】EOSIO智能合約實戰#2


回顧【開發入門】EOSIO智能合約實戰#1

Chester,eosCity.io 共同創辦人、Novogo 共同創辦人、CLE 中文計劃成員。 早期挖礦玩家,開源碼貢獻者,近年致力於深度學習和區塊鏈整合,期望可以再度以複雜科技解決現實問題。
新聞排行
熱門新聞

© blocktimes——專業的區塊鏈媒體平臺