區塊鏈安全：實現公鏈雙花攻擊的多種方法

針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞的案例，360 區塊鏈實驗室總結出了多種形成數字貨幣雙花攻擊的多種緣由，並提出了一種通用的安全減緩措施。各類大公鏈項目實際上都產生過可以產生雙花攻擊之類的嚴重安全問題，盜取加密貨幣對黑客來說不是難事。

而在幾個月的區塊鏈安全研究中，360 區塊鏈實驗室收到了來自各個項目方價值超過 30 萬美金的數字貨幣漏洞報告獎勵。

2008 年，中本聰提出了一種徹底經過點對點技術實現的電子現金系統（比特幣）。該方案的核心價值在於其提出了基於工做量證實的解決方案，使現金系統在點對點環境下運行，並可以防止雙花攻擊。現在比特幣已經誕生十年，無數種數字貨幣相應誕生，但人們對雙花攻擊的討論彷佛仍然停留在比特幣 51% 攻擊上。實際上，咱們的研究發現，實用的數字貨幣雙花攻擊還有不少種其餘形式。在本文中，咱們經過介紹咱們發現的針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞，總結出多種形成數字貨幣雙花攻擊的多種緣由，並提出一種高效的減緩措施。

1

工做量證實和雙花攻擊

2008 年，中本聰提出了一種徹底經過點對點技術實現的電子現金系統，它使得在線支付可以直接由一方發起並支付給另一方，中間不須要經過任何的金融機構。雖然數字簽名部分解決了這個問題，可是若是仍然須要第三方的支持才能防止雙重支付的話，那麼這種系統也就失去了存在的價值。比特幣的工做量證實機制 (PoW) 的本質，就是要使現金系統在點對點的環境下運行，並防止雙花攻擊。

工做量證實機制的原理以下：網絡中每個區塊都包含當前網絡中的交易和上一個區塊的區塊頭哈希。新區塊產生，其區塊頭哈希必須知足工做量證實條件（須要進行大量的哈希計算）。整個網絡將知足工做量證實的哈希鏈鏈接起來，從而造成區塊鏈。除非攻擊者從新完成所有的工做量證實，不然造成的交易記錄將不可更改。最長的區塊鏈不只將做爲被觀察到的交易序列的證實，並且被看作是來自算力最大的羣體的共識。只要整個網絡中大多數算力都沒有打算合做起來對全網進行攻擊，那麼誠實的節點將會生成最長的、超過攻擊者的鏈條，從而實現對雙花攻擊的抵抗。

雙花攻擊其實是一個結果。若是一個攻擊者 A 將同一個比特幣同時支付給 B 和 C 兩個用戶，而且 B 和 C 兩個用戶都承認了這筆交易。那麼咱們說 A 將該比特幣花了兩次，A 實現了一次雙花攻擊。針對工做量證實機制的雙花攻擊中，51% 攻擊是被討論的最多的一種攻擊形式。但針對工做量證實機制的雙花攻擊實際上有多種形式，包括芬妮攻擊、競爭攻擊、Vector76 攻擊等。這些攻擊實際上也獲得了充分的關注和討論，本文中不作贅述。實際上，實用的數字貨幣雙花攻擊還有不少種其餘形式。下文中，咱們將經過多個咱們發現的多個安全漏洞，討論多種數字貨幣雙花攻擊的多種緣由，並提出一種高效減的緩措施。

2

雙花攻擊的新分類

智能合約平臺，本質上是要在全網共享一個帳本。這能夠當作是一個分佈式狀態機複製問題。當前的帳本狀態，咱們能夠認爲是 State_n。當一個新交易 Tx_ 產生的時候，Tx_ 將對 State_n 產生一個做用。從而使 State_n 狀態過渡到 State_ 狀態。這個過程咱們能夠用公式表示：

State_n × Tx_{n+1} → State_{n+1}

智能合約平臺共識機制，本質上是將全部的交易【Tx_1 Tx_2 ……. Tx_n】按順序做用到初始 State_0 上，使全網始終保持相同的狀態。區塊鏈中的每個區塊，實際上將交易序列【Tx_1 Tx_2 ……. Tx_n】按順序拆分紅不一樣的區塊 Block1,Block2 並按順序連接起來。在全網狀態機複製的過程當中，若是一旦由於某些緣由產生了全網狀態不一致，則咱們能夠認爲全網產生了一個分叉。分叉被攻擊者利用，可進一步實現雙花攻擊。

本文中，咱們將咱們發現的這些雙花攻擊漏洞分紅 3 類：

• 驗證不嚴格形成的雙花攻擊。

• 狀態機 State_n × Tx_{n+1}→State_{n+1}不一致執行形成的雙花攻擊。

• 共識機制形成的雙花攻擊。

驗證不嚴格形成的雙花攻擊，主要緣由在於具體實現邏輯校驗問題。比特幣的漏洞 CVE-2018-17144 實際上就是這樣一個漏洞。

狀態機不一致執行形成的雙花攻擊，主要是因爲智能合約虛擬機由於各類緣由致使直接結果不一致，從而在整個網絡中創造分叉，形成雙花攻擊。

共識機制漏洞可能產生整個網絡的分叉，從而進一步形成雙花攻擊。人們常說的 51% 攻擊，實際上就是 PoW 共識機制的分叉漏洞。

3

驗證不嚴格形成的雙花攻擊

驗證不嚴格形成的雙花攻擊，主要緣由在於具體實現邏輯校驗問題。這裏咱們介紹兩個關於區塊與交易綁定時校驗不嚴格，從而產生雙花攻擊的漏洞。

在區塊鏈項目中，一筆交易 Tx_1 被打包的某個區塊 Block_1 中的方式以下：首先計算交易 Tx_1 的哈希值 Hash_1，而後用 Hash_1 與其餘交易的哈希值 Hash_2…Hash_n 組合構成 Merkle Hash Tree。計算出哈希樹的根節點 root，而後將 root 打包到 Block_1 中。這樣即造成一筆交易與區塊的綁定。通常來說，除非攻擊者可以攻破哈希函數的抗碰撞性，不然沒法打破一筆交易與區塊的綁定。若是攻擊者可以打包交易與區塊的綁定，則攻擊者能經過形成全網的分叉從而實現雙花攻擊。下面咱們介紹兩個咱們在 NEO 上發現的雙花攻擊漏洞：

3.1 NEO 虛擬機 GetInvocationScript 雙花攻擊漏洞：

區塊鏈項目中，一個交易通常是由未簽名的部分（UnsignedTx，交易要執行的內容）和簽名的部分（交易的 witness）構成的。在如比特幣之類的區塊鏈項目中，交易的 hash 計算其實是包含了該交易的簽名部分的。而在如 NEO、ONT 等多種區塊鏈平臺中，交易的計算公式爲 hash=SHA256(UnsignedTx)。即交易的哈希是由未簽名的部分計算的來的，與交易的 witness 無關。而 NEO 智能合約在執行的時候，可以經過 Transaction_GetWitnesses 方法，從一個交易中得到該交易的 witnesses。其具體實現以下：

某個合約交易得到本身的 witness 以後，還可以經過 Witness_GetVerificationScript 方法得到該 witness 中的驗證腳本。若是攻擊者針對同一個未簽名交易 UnsignedTx1，能夠構造兩個不一樣的驗證腳本。則能夠形成該合約執行的不一致性。正常狀況下，合約的 VerificationScript 是由合約的輸入等信息決定的，攻擊者沒法構造不一樣的驗證腳本並經過驗證。可是咱們發如今 VerifyWitness 方法中，當 VerificationScript.length=0 的時候，系統會調用 EmitAppCall 來執行目標腳本 hash。

因此當 VerificationScript=0，或者 VerificationScript 等於目標腳本的時候，都可知足 witness 驗證條件。即攻擊者能夠對於同一個未簽名的交易 UnsignedTx_1，構造兩個不一樣的 VerificationScript。攻擊者利用這個性質，能夠對 NEO 智能合約上的全部代幣資產進行雙花攻擊，其具體攻擊場景以下：

步驟 1：攻擊者構造智能合約交易 Tx_1（未簽名內容 UnsignedTx_1, 驗證腳本爲 VerficationScript_1）。在 UnsignedTx_1 的合約執行中，合約判斷本身的 VerficationScript 是否爲 VerficationScript_1。若是爲 VerficationScript_1，擇發送代幣給 A 用戶。若是 VerficationScript 爲空，則發送代幣給 B 用戶。

步驟 2：Tx_1 被打包到區塊 Block_1 中。

步驟 3: 攻擊者收到 Block_1 後，將 Tx_1 替換成 Tx_2(Tx_1 具備與 Tx_1 相同的未簽名內容 UnsignedTx_1，但驗證腳本爲空) 從而造成 Block_2。攻擊者將 Block_1 發送給 A 用戶，將 Block_2 發送給 B 用戶。

步驟 4：當 A 用戶收到 Block_1 時，發現本身收到攻擊者發送的代幣。當 B 用戶收到 Block_2 時，也會發現本身收到了攻擊者發送的代幣。雙花攻擊完成。

可見，該漏洞的利用門檻很是低，且能夠對 NEO 智能合約上的全部代幣資產進行雙花攻擊。危害很是嚴重。

3.2 NEO MerlkeTree 綁定繞過形成交易雙花攻擊漏洞：

智能合約交易與區塊的綁定，一般經過 MerkleTree 來完成。若是攻擊者能繞過該綁定，則能實現對任意交易的雙花。這裏咱們看看 NEO 的 MerkleTree 的實現以下：

在 MerkleTreeNode 函數中，NEO 進行了 MerkleTree 葉節點到父節點的計算。但這裏存在一個問題，當 leaves.length 爲奇數 n 的時候。NEO 的 MerkleTree 會將最後一個葉節點複製一次，加入到 MerkleTree 的計算中。也就是說當 n 爲奇數時，如下兩組交易的 MerkleRoot 值會相等：

【Tx_1 Tx_2 …… Tx_n】

【Tx_1 Tx_2 …… Tx_n Tx_】其中 Tx_= Tx_n

利用這個特性，攻擊者能夠實現對任意 NEO 資產的雙花攻擊。其具體攻擊場景以下：

步驟 1：假設正常的一個合法 Block_1，包含的交易列表爲【Tx_1 Tx_2 … Tx_n】。攻擊者收到 Block_1 後，將交易列表替換爲【Tx_1 Tx_2 … Tx_n Tx_】，造成 Block_2。而後將 Block_2 發佈到網絡中去。

步驟 2：一個普通節點收到 Block_2 後，會對 Block_2 的合法性進行校驗。然而由於【Tx_1 Tx_2 … Tx_n Tx_】與【Tx_1 Tx_2 … Tx_n】具備相同的 MerkleRoot。因此 Block_2 可以經過區塊合法性校驗，從而進如區塊持久化流程。NEO 本地取消了普通節點對合法區塊中交易的驗證（信任幾個共識節點）。則 Tx_n 交易能夠被普通節點執行兩次，雙花攻擊執行成功。

可見，該漏洞的利用門檻很是低，且能夠對 NEO 上的全部資產進行雙花攻擊。危害很是嚴重。

4

虛擬機不一致性執行

智能合約平臺共識機制，本質上是將全部的交易【Tx_1 Tx_2 ……. Tx_n】按順序做用到初始 State_0 上，使全網始終保持相同的狀態。在狀態機複製過程當中，咱們要求 State_n × Tx_èState_ 是決定性的。State_n × Tx_èState_ 實質上就是智能合約虛擬機對 Tx_ 的執行過程，若是智能合約虛擬機中存在設計或者實現漏洞，致使虛擬機不一致性執行（對相同的輸入 State_n 和 Tx_，輸出 State_ 不一致）。則攻擊者能夠利用該問題在網絡中產生分叉和並進行雙花攻擊。下面咱們介紹多個 EOS 和 NEO 上咱們發現的虛擬機不一致執行漏洞和其產生緣由。

4.1 EOS 虛擬機內存破壞 RCE 漏洞:

此前，咱們公開了文章《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》(blogs.360.cn/post/eos-no…)。在該文中，咱們發現了一個 EOS WASM 虛擬機的一個內存越界寫漏洞，針對該漏洞咱們編寫的利用程序能夠成功利用該漏洞使 EOS 虛擬機執行任意指令，從而徹底控制 EOS 全部出塊和驗證節點。

究其本質而言，是在 State_n × Tx_{n+1} → State_{n+1}過程當中。攻擊者能讓 EOS 虛擬機徹底脫離本來執行路徑，執行任意指令，天然能夠完成雙花攻擊。其攻擊流程以下：

步驟 1：攻擊者構造可以實現 RCE 的惡意智能合約，並將該合約發佈到 EOS 網絡中。

步驟 2：EOS 超級節點解析到該合約後，觸發漏洞，執行攻擊者自定義的任意指令。

步驟 3：攻擊者實現雙花攻擊。

該漏洞的危害很是嚴重，且是第一次智能合約平臺受到遠程代碼執行攻擊事件。讀者能夠閱讀該文章瞭解相關細節，在此再也不贅述。

4.2 EOS 虛擬機內存未初始化形成雙花攻擊：

咱們在編寫《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》的利用程序的過程當中，還利用了 EOS 中當時的一個未公開的內存未初始化漏洞。在內存破壞攻擊中，內存未初始化漏洞一般可以形成信息泄露、類型混淆等進一步問題，從而輔助咱們繞過如 ASLR 之類的現代二進制程序的緩解措施，進一步實現攻擊。然而在智能合約虛擬機中，內存未初始化漏洞有更直接的利用方式，能夠直接形成雙花攻擊。如下爲咱們在 EOS RCE 中利用的一個內存未初始化漏洞的細節，其能夠被用來直接實現 EOS 智能合約代幣資產雙花攻擊。

當 WASM 虛擬機經過 grow_memory 僞代碼來申請內存新的內存。在 EOS WASM grow_memory 最初的實現中，未對申請到的內存進行清零操做。該塊內存的空間其實是隨機的（依賴於合約執行機器的內存狀態）。則攻擊者能夠構造惡意合約，實現對 EOS 上任意合約資產的雙花攻擊。其攻擊流程以下：

步驟 1： 攻擊者構造惡意智能合約。合約中經過 grow_memory 得到一塊新的內存地址。

步驟 2：合約中讀取該地址中的某個 bit 內容（此時該 bit 可能爲 0，也可能爲 1，依賴於合約執行機器的狀態）。

步驟 3：合約判斷該 bit 的內容，若是爲 1 則發送代幣給 A 用戶，若是爲 0 則發送代幣給 B 用戶，從而實現雙花攻擊。

4.3 EOS 虛擬機內存越界讀形成雙花攻擊:

在傳統的內存破壞中，內存越界讀漏洞主要將會致使信息泄露，從而輔助咱們繞過如 ASLR 之類的現代二進制程序的緩解措施，進一步與其餘漏洞一塊兒實現攻擊。然而在智能合約虛擬機中，內存越界讀漏洞有更直接的利用方式，能夠直接形成雙花攻擊。下面爲一個咱們發現的 EOS 內存越界讀漏洞，咱們能夠利用該漏洞實現雙花攻擊。

當 EOS WASM 將一個 offset 轉換內 WASM 內存地址時，其邊界檢查過程以下：

在這裏|ptr|的類型其實是一個 I32 類型，它能夠是一個負數。那麼當：

-sizeof(T) < ptr < 0
複製代碼

的時候，ptr+sizeof(T) 是一個很小的數能夠經過該邊界檢查。在以後的尋址中，咱們看到代碼：

T &base = (T)(getMemoryBaseAddress(mem)+ptr);
複製代碼

|base|的地址將會超過 WASM 的內存基址，從而讓智能合約實現內存越界讀（讀到的內存地址內容取決於虛擬機當前執行狀態，可被認爲使隨機的）。攻擊者能夠利用該漏洞實現雙花攻擊。其攻擊過程以下：

步驟 1： 攻擊者構造惡意智能合約。合約中利用內存越界讀漏洞，讀取超越 WASM 內存基址的某個 bit）此時該 bit 可能爲 0，也可能爲 1，依賴於合約執行機器的狀態）。

步驟 2：合約判斷該 bit 的內容，若是爲 1 則發送代幣給 A 用戶，若是爲 0 則發送代幣給 B 用戶，從而實現雙花攻擊。

4.4 標準函數實現不一致形成雙花攻擊：

總結上面雙花攻擊兩個例子的本質，其實是 EOS 合約在執行過程當中由於某些內存漏洞緣由讀取到了隨機變量，從而打破了本來虛擬機執行的一致性，形成了雙花攻擊。事實上，合約執行的不一致性，不必定徹底依賴於隨機性。這裏咱們介紹一個由於各個平臺（版本）對標準 C 函數實現不一致形成的雙花攻擊。

在 C 語言標準定義中，memcmp 函數的返回時被要求爲：小於 0，等於 0，或者大於 0。然而各類不一樣的 C 版本實現中，具體返回的可能不同（但依然符合 C 標準）。攻擊者能夠利用該標準實現的不一致性，形成運行在不一樣系統上的 EOS 虛擬機執行結果不一致，進而實現雙花攻擊。其攻擊流程以下：

步驟 1：攻擊者構造惡意智能合約，在合約中調用 memcmp 函數，並獲取返回值。

步驟 2：此時，不一樣的平臺和版本實現 Memcmp 的返回值不一致（即便 EOS 虛擬機的二進制代碼是相同的）。惡意合約判斷 Memcmp 的返回值，決定轉帳給 A 或 B，從而完成雙花。

該漏洞的具體修復以下：

EOS 強制將 memcmp 的返回值轉換爲 0，-1 或者 1，從而抵抗這種不一致執行。

Memcmp 這個問題，是同一種語言對相同標準實現的不一致性形成的。事實上，同一個區塊鏈項目常常會有多個不一樣版本語言的實現。

不一樣語言對相同標準的實現一般也會有誤差，好比一個咱們發現的因標準定義實現不一致形成不一致執行是 ECDSA 函數。ECDSA 簽名標準中要求私鑰 x 不爲 0。如 python、JS 中的多個密碼學庫中對該標準由嚴格執行，可是咱們發現部分 golang 的 ECDSA 庫容許私鑰 x=0 進行簽名和驗證計算，惡意攻擊者利用該問題能夠對同一個區塊鏈平臺的不一樣版本實現（好比 golang 實現和 python 實現）構造不一致執行惡意合約，從而進一步完成雙花攻擊。

4.5 版本實現不一致形成雙花攻擊：

同一個區塊鏈項目常常會有多個不一樣版本編程語言的實現。不一樣編程語言的實現一樣存在着各類這樣的不一致執行的可能性。上面 ECDSA 是一個例子。大整數運算也是一個常見的例子。好比在曾經的 NEO 的 C# 版本實現和 python 版本實現中，大整數 (BigInteger) 除法運算可致使不一樣編程語言實現版本見的不一致執行現象，從而形成雙花攻擊。相似的現象在多個區塊鏈項目中產生過。

4.6 其餘問題不一致性問題

系統時間、隨機數、浮點數計算等因素也是能夠形成虛擬機不一致執行的緣由。可是在咱們的審計中，並無發現此類漏洞在大公鏈項目中出現。多數區塊鏈項目在設計之初就會考慮到這些明顯可能形成的問題。

但可能形成不一致執行的因素可能遠遠超過咱們上面發現的這些問題。事實上，一些主觀因素（取決於機器當前運行狀態的因素，咱們稱之爲主觀因素）均可能形成虛擬機的不一致執行。舉個例子，好比在 4G 內存，8G 內存的機器在執行過程當中產生內存溢出 (OOM) 的主觀邊界就不同，攻擊者利用 OOM 可能形成虛擬機的不一致執行。

5

共識機制形成的雙花攻擊

共識機制形成的雙花攻擊其實是在業界中得到充分討論的一個問題，然而各類公鏈方案在共識機制實現上仍然可能存在分叉問題，從而形成雙花攻擊。

5.1 ONT vBFT VRF 隨機數繞過漏洞

Long range attack 是目前全部 PoS 共識機制都面臨的一種分叉攻擊方法。攻擊者能夠選擇不去分叉現有的鏈，而實回到某個好久以前的鏈狀態（攻擊者在這個狀態曾佔有大量貨幣），造一跳更長的新鏈出來讓網絡誤覺得是主鏈，從而完成雙花。目前業界針對 Long range attack 並無根本的解決辦法，只能保證在「Weak Subjectivity」不發生的狀況下，防止分叉發生。

ONT 的 vBFT 共識算法提出了一種依靠可驗證隨機函數（VRF）來防止惡意分叉擴展的方法。網絡首先基於 VRF 在共識網絡中依次選擇出一輪共識的備選區塊提案節點集，區塊驗證節點集和區塊確認節點集，而後由選出的節點集完成共識。因爲每一個區塊都是由 VRF 肯定節點的優先級順序的，對於惡意產生的分叉，攻擊者很難持續維持本身的高優先級（若是攻擊者沒有控制絕大多數股權的話），所以惡意產生的分叉將很快消亡，從而使 vBFT 擁有快速的狀態終局性。

然而咱們發現 vBFT 中的 VRF 實現存在一個漏洞，致使私鑰爲 0 的用戶的可對任意區塊數據生成相同的 vrfValue。具體的，vBFT 中的 vrf 是對由波士頓大學提出的 VRF 標準草稿 (hdl.handle.net/2144/29225) 的一個實現。具體在該草案的 5.1 和 5.2 章節中，咱們能夠看到證實生成，和隨機數計算的算法。如圖：

漏洞在於 x=0 時候，此時從計算上 y 仍然爲一個合法的公鑰，且能經過 vBFT 實現中 ValidatePublicKey 的校驗。gamma 爲橢圓曲線上固定的點（無窮遠點）。即對任意輸入 alpha，該 vrf 產生的值爲固定一個值。徹底沒有隨機性。該問題可致使攻擊者利用固定 vrf 破壞共識算法隨機性，從而長期控制節點選舉。

5.2 NEO dBFT 共識分叉

NEO 的 dBFT 共識機制，本質上能夠當作是一個 POS+pBFT 方案。在原版 NEO 代碼中，咱們發現 NEO 和 ONT 在實現其 dBFT 共識機制的時候存在分叉問題。惡意的共識節點能夠產生一個分叉塊，從而形成雙花的發生。具體細節能夠參考咱們以前的文章：《Analysis and Improvement of NEO’s dBFT Consensus Mechanism》(blogs.360.cn/post/NEO_dB…)，在此咱們不作贅述。

6

一種針對虛擬機執行不一致雙花問題的高效減緩措施

對於校驗繞過之類的邏輯漏洞和共識機制問題產生的雙花漏洞，仍是須要深刻到業務邏輯中具體問題具體分析。這裏咱們提出一種針對虛擬機執行不一致的減緩措施。

一種簡單的解決虛擬機執行不一致形成的雙花問題的方法是由出塊者將運行完交易後的全局狀態 State_ 進行哈希散列，而後將該散列打包到區塊中。普通節點在收到區塊後，將本地運行完交易後的狀態 State’_ 的哈希散列與 State_ 的哈希散列進行對比。若是相等，則說明沒有分叉產生。然而因爲本地數據是先行增加的，因此每次對全局狀態進行散列計算的開銷極大。針對這個問題，以太坊使用了 MekleTree 的結構來提升性能，同時應對分叉回滾問題。但以太坊的方案並不適用於採用其餘數據結構存儲狀態信息的區塊鏈項目。這裏咱們提出一種新的解決方案，其工做流程以下：

• 區塊生產者在區塊打包階段，將該區塊中全部的交易運行過程當中的對數據庫的寫操做序列【write_db_1 write_db_2 …. write_db_n】記錄下來，並計算該序列的哈希值 write_db_hash。

• 普通節點收到新的區塊後，對區塊進行校驗。而後在虛擬機中執行交易。同時本地記錄這些交易對數據庫的寫操做序列【write_db_1’ write_db_2’ …. write_db_n’】，而後計算 write_db_hash’。判斷其與 write_db_hash 是否相等。若是相等，則認爲沒有不一致執行發生。若是不等，則拒絕對該寫操做序列進行 commit。

本方法的核心思路在於，智能合約平臺虛擬機執行不一致產生的緣由在於：合約中各類功能函數和圖靈完備性的支持中，可能引入多種不肯定因素，從而形成執行不一致。各類各樣複雜的小緣由，可能致使這種不一致執行防不勝防。可是咱們退一步看，雙花攻擊的本質是要對全局狀態 State_ 進行修改，本質上就是一系列的簡單寫操做（簡單的寫操做每每並不會產生二義性）。要防止雙花，只須要對全部的寫操做序列進行匹配校驗即可。本地對這些寫操做進行匹配和記錄的開銷很是小，同時本地記錄這些寫操做序列，也方便應對分叉回滾等其餘因素。

7

後記

在本文中，咱們經過介紹咱們發現的針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞的案例發現，總結出多種形成數字貨幣雙花攻擊的多種緣由，並提出了一種通用的安全減緩措施。從上面的分析中，咱們能夠看到，區塊鏈安全目前的形式仍然十分嚴峻。各類大公鏈項目實際上都產生過可以產生雙花攻擊之類的嚴重安全問題。咱們的職業道德經受住了無數次的考驗。 make a billion or work hard? Of course, work hard. 不過幸運的是，在幾個月的區塊鏈安全研究中，咱們收到了來自各個項目方價值超過 30 萬美金的數字貨幣漏洞報告獎勵，感謝。hard work pay off。

本文中全部提到的漏洞均已被修復。在漏洞報告和解決的過程當中咱們發現 EOS 與 NEO 項目方對於安全問題處理專業高效，反應及時。項目安全性也一步一步獲得完善。咱們會繼續關注和研究區塊鏈相關技術的安全問題，推進區塊鏈技術向前發展。

內容來源：360區塊鏈實驗室

做者:Zhiniang Peng

課程推薦