以太坊中，每個區塊交易執行後，會更新狀態資料並生成一個merkle root(可以看成是狀態資料摘要)，同時這個state merkle root也會儲存在BlockHeader裡，也就說以太坊的狀態資料是上鍊的。所以後面節點在replay block交易時可以很容易驗證出本地的狀態資料是否和全網的狀態資料一致。

    但是EOS不一樣，EOS只有transaction和action merkle，並沒有state(狀態)merkle。EOS的狀態資料(資料庫表裡的資料)儲存在資料庫中，執行區塊交易並更新狀態後，並沒有將這個狀態資料儲存在鏈上。因而網路中的節點在replay 交易後，並不知道本地的狀態資料是否和BP及其他節點的狀態資料一致。

    總結為一句話就是EOS狀態資料不上鍊。

• 狀態不一致為何出現

    正常來說，對於相同的輸入(交易資料), 所有節點(包括21個超節點)通過執行這些交易應該會輸出相同的狀態資料。但是有程式碼，就有可能有BUG，當出現BUG時就有可能“同步節點”生成了和“生產節點”不一樣的的輸出，由於缺失狀態資料檢驗，同步節點並不知道出現了這種不一致性錯誤，因而這個BUG就沒法及時發現，進而可能隱藏很久，最後可能會導致很嚴重的問題。

    比如A發起一個交易，A給RAM購買登記合約轉賬1000EOS購買RAM，生產節點在執行這次轉賬交易並沒有真正轉賬，但是如果EOS系統存在BUG或者同步節點eosflare.io本身的BUG，eosflare.io的同步節點在同步交易資料並執行該交易時卻真正轉賬了。然後，B通過查詢eosflare.io的轉賬記錄，確認成功了，然後就給A買了相應量的RAM。然而事實上，資料以超級節點為準，由於這個不一致性，B白白損失了替A購買RAM的資產。如果在以太坊等有狀態默克樹的系統中，eosflare.io在執行完後通過檢測本地狀態資料merkle root即可發現，本地資料和超級節點的狀態資料不一致，就會顯示A轉賬給B的交易異常，並會上報EOS社群及時修復這個BUG。

• 狀態不一致怎麼解決

    到了這裡，你可能會說，這種不一致性應該直接歸類到程式碼的BUG啊，程式碼就應該保證所有機器執行相同交易得到相同結果，不能算到缺失merkle驗證機制上。這種說法也對，但是在一般的分散式系統中，執行環境是可控(基本都是發行方部署的)，即程式碼的測試環境相對可模擬，因而測試基本能cover大部分case，但是區塊鏈中，任何裝置都可以成同步節點參與這個過程，靠EOS開發人在釋出前測試各種環境是不現實的，且缺失狀態merkle機制後，整個系統缺乏錯誤發現機制，會很難發現這類錯誤，相當於保護了BUG。正常情況下，此類BUG發生的機率是極低的，但是一旦發生，這些BUG可能長時間隱藏和被利用，更何況目前EOS發展初期，這種BUG可能性也許並沒有那麼極低。那麼，如何主動發現不一致性呢？首先超級節點們可以週期性的檢測各自狀態資料是否一致，也許EOS BP們早就已經這樣做了。然後，EOS社群可以開發一個狀態比較工具並每隔一段時間公佈一下當前網路的狀態資料(相當於checkpoint)，同步節點們就可以使用這個工具來比對本地狀態資料和公開發布的正確狀態資料，進而儘早發現不一致性問題。當然這些都只是一種臨時方案，最終還是需要其他的正規的自動化的檢測機制。

• 痛苦的EOS資料同步

    以上只是狀態驗證機制缺失的一個副作用，其實還有另外一個負面影響就是不容易實現快速同步。

    隨著EOS的不斷執行，資料量是越來越大了，資料同步經常掛掉是常有的事，這個問題的一個核心原因是EOS缺少類似以太坊fast sync機制。fast sync模式下，本地節點是不需要replay交易的，而是直接從其他任意節點下載狀態資料(資料庫資料)，同步節點的負載大大降低。而EOS因為缺失狀態資料檢測機制，同步節點沒法相信其他節點的狀態資料，因此需要親力親為執行每個交易來獲取狀態資料，因而負載是很大的。這不，最近EOS已經提出了可信節點的概念，就是說社群會列出一些可信任的節點名單，這樣同步節點不需要執行交易而是直接從可信節點下載狀態資料即可，大大提高同步速度。但是這會導致海量同步節點同時連線這些可信節點，進而會導致這些節點壓力山大，同時區塊鏈行業，這種中心化的理念還是越少越好，一個本可以用程式碼來保證(merkle驗證)的機制非得用人治來解決。 

    當然，我相信EOS社群最後肯定會也正在嘗試解決這兩個問題，只是希望能夠快一點。

作者個人技術能力有限，如有錯誤請指點

嘗試長按二維碼關注公眾號吧（^_^)

公眾號:區塊鏈斜槓青年

歡迎大家加我微信:itleaks