事件背景
與此同時，慢霧安全團隊對交易所和中心化錢包給出了暫時性的方案。此刻，攻擊手法依舊是乙個謎團。那麼，攻擊手段究竟是怎樣的呢？在進行攻擊回顧之前，需要先了解一點技術背景。
技術背景
1、我們知道 eos 採用的共識演算法是 dpos 演算法，採用的是 21 個超級節點輪流出塊的方式。除了 21 個超級節點外的其他全節點，並沒有出塊的許可權。起到的作用是將收到的交易廣播出去，然後超級節點將其進行打包。
說到這裡，很容易看出，如果一筆交易是發給除了超級節點外的其他全節點，這筆交易會經歷兩個過程。首先，這筆交易先被全節點接收，然後交易再被節點廣播出去進行打包。而一筆交易是需要超級節點中超過 2/3+1 的節點進行確認之後才是不可回滾的，也就是不可逆的。
這個過程大概需要 3 分鐘左右，也就是說，交易發到除了超級節點外的全節點的時候，由於全節點沒有打包的權利，此時此刻交易仍然處於可逆狀態（這裡假定節點資料庫的讀取模式為預設的 speculative，有關閱讀模式的參考： ）。這是乙個核心關鍵點。
2、每乙個 bp(超級節點)，都可以在自己的節點的 config.ini 檔案內進行黑名單的配置，在黑名單中的帳號是不能進行交易的，也就是說無論怎樣，黑名單的交易都會被回滾。
黑名單配置路徑：
mac os：
~/.local/share/eosio/nodeos/config/config.ini
配置方法：
將 config.ini 檔案內的 actor-blacklist 填入黑名單帳號，如下圖中，將 attacker 這個帳號作為黑名單帳號。
了解了以上的知識點之後，我們就可以進行整個攻擊事件的回顧了。
攻擊回顧
跟蹤攻擊者的其中乙個攻擊帳號，發現帳號合約內只有乙個 transfer 函式
同時，我們可以通過覆盤這個帳號的所有交易記錄發現，這個帳號只有開獎記錄，而沒有下注記錄，看起來就好像專案方故意給這個帳號進行開獎一樣。然而事實上並非如此。那為什麼會出現這樣的情況呢？這就需要上面的技術背景的知識了。以下是詳細的攻擊手法：
1、首先：攻擊者呼叫非黑名單合約的 transfer 函式，函式內部有乙個 inline action 進行下注，from 填寫的是攻擊者控制的非黑名單合約帳號，to 填寫的是遊戲合約帳號。這時，攻擊者傳送交易是發向遊戲合約自己的全節點伺服器。使用的是黑名單帳號進行。
2、遊戲節點讀取到了這筆交易，立刻進行開獎，如果中獎，將對攻擊者控制的非黑名單帳號傳送 eos。
3、在經歷了乙個 1，2 兩個操作之後。理論上攻擊者控制的非黑名單帳號是進行了餘額扣除。然後進行正常的開獎邏輯。到這裡之前，一切都是正常的。也許有讀者會問，為什麼配置了黑名單，交易還能正常發起？原因是這個黑名單生效範圍是在 bp 內，普通的全節點的 config.ini 內是沒有黑名單的配置的。所以攻擊者依然可以發起交易。
4、到此為止，攻擊正式開始，也到了最關鍵的地方，由於專案方節點在收到下注交易的時候已經立馬完成了開獎邏輯，而且採用的是線下開獎的模式，即下注交易和開獎交易是兩筆不同的交易。但是，這兩筆交易僅僅是在專案方的節點內完成，仍然是可逆的。當專案方節點向 bp 廣播這兩筆交易的時候，由於第一筆下注交易的發起者在 bp 節點的黑名單內，這一筆交易將被回滾，也就是打包失敗，而開獎交易的發起者是專案方，不在黑名單之內，會被正常打包。因此兩筆交易中的第一筆下注交易一定會被回滾，而開獎交易依舊會被打包，這也就解釋了為什麼只有開獎記錄，而沒有下注記錄。因為下注記錄都被回滾了。
攻擊復現
1、環境準備
（1）本地準備兩個節點，乙個出塊節點，乙個同步節點，出塊節點用於模擬真實 bp，而同步節點則用於模擬專案方，其中出塊節點需要開啟 history 外掛程式，方便後續的 debug，並且把 attacker 加入節點黑名單。方便後續的 debug。打包節點則需要開啟自動開獎外掛程式,自動開獎外掛程式配置詳見：
本次復現用到的**：
本地多節點配置方法官方參考：
（2）三個測試帳號，分別是 tobetioadmin,tobetiologs1,attackproxy1，分別為專案方帳號，專案方 log 帳號，和攻擊**帳號，其中 tobetioadmin 部署 tobet 遊戲合約，tobetiologs1 部署 logs 合約，attackproxy1 部署 attack 合約。注意除了攻擊**帳號外的其他兩個帳號不要改為其他帳號，如果改為其他帳號需要對自動開獎外掛程式進行修改，自動開獎外掛程式是攔截 tobetioadmin 這個帳號的。
（3）附上我的雙節點的配置：
其中 nodeos_main 為出塊節點，nodeos_second 為同步節點。
2、啟動節點
看到以上資訊則代表 dice_plugin 配置成功
3、首先對正常的邏輯進行測試。
使用 attackproxy1 對 tobetioadmin 帳號進行正常的轉賬交易
可以看到，攻擊**合約進行了正常的轉賬。
4、開始攻擊，使用黑名單帳號呼叫攻擊**合約，向專案方合約發起攻擊。
（1）查詢初始餘額
（2）為保證攻擊成功，連續向專案方發起 4 起攻擊
（3）再次查詢餘額
（4）查詢attacker帳號記錄
可見，並沒有 attacker 對 attackproxy1 的呼叫記錄，最後兩條記錄是我測試直接使用黑名單向 tobetadmin 發起攻擊的時候留下的記錄。與本次測試無關。但是通過查詢發現，本地記錄和鏈上記錄是相吻合的，即無下注記錄。
（5）查詢 attackproxy1 的帳號記錄
可以看到的是，這個也與鏈上記錄吻合，只有開獎記錄，就像 tobetadmio 故意給 attackproxy1 開獎一般。
通過以上的復現及和鏈上記錄的對比，我們可以證明上文說的攻擊手法，就是黑客本次進行攻擊的手法，採用的就是使用黑名單進行回滾的操作。
防禦建議
（1）節點開啟 read only 模式，防止節點伺服器上出現未確認的塊
（2）建立開獎依賴，如訂單依賴，開獎的時候判斷訂單是否存在，就算在節點伺服器上開獎成功，由於在 bp 上下注訂單被回滾，所以相應的開獎記錄也會被回滾。
2、針對交易所和中心化錢包的防禦建議
慢霧安全團隊建議 eos 交易所及中心化錢包在通過 rpc 介面 get_actions 查詢熱錢包充值記錄時，應檢查充值 transaction 所在的 block_num 是否小於 last_irreversible_block(最新不可逆區塊)，如果 block_num 大於 last_irreversible_block 則表示該區塊仍然是可逆的，存在「假充值」風險。
致謝
感謝 eos live 錢包團隊對本地復現過程中的技術解疑和復現**的提供。
事務回滾與手動回滾
一般我們在開發時，在方法或者類上加了 transactional事務註解，然後會用 try catch 將可能會出問題的 塊包起來，在catch裡面處理捕獲的異常，但是，如果在catch裡面沒有把異常丟擲去，此時事務是不會自動回滾的 比如這種情況 這裡既沒有丟擲異常，也沒有手動回滾，在插入流水表之後...
EOS 原始碼解析 區塊回滾對交易的影響
在主網上玩耍的小夥伴們肯定遇到過區塊回滾導致自己的交易沒有上鏈。這種情況讓有些人誤以為區塊回滾會丟棄交易。其實區塊回滾並不是導致交易沒上鏈的主要原因，主要原因是交易過期了才導致交易被丟棄。流程描述 每個交易是會被廣播到全網每個節點上面的 ps 當然傳播過程中過期的話，當我沒說哈 假如出塊節點 a 打...
mysql回滾命令 關於MySQL回滾機制
在事務中，每個正確的原子操作都會被順序執行，直到遇到錯誤的原子操作，此時事務會將之前的操作進行回滾。回滾的意思是如果之前是插入操作，那麼會執行刪 除插入的記錄，如果之前是update操作，也會執行update操作將之前的記錄還原 因此，正確的原子操作是真正被執行過的。是物理執行。在當前事務中確實能看...