https://bihu.com/article/1263470421
EOS 的DAPP查詢數據，主要是通過訪問完整歷史節點來進行的。但是隨着EOS網絡的快速增長，歷史插件變得越來越難以維護。
與歷史插件相關的問題，未來會出現更多。如果現在不採取行動，最終會對網絡造成嚴重影響。爲了改善當前基礎設施的脆弱性，提高網絡的壽命，EOS42正與其他社區成員合作，爲完整的歷史節點提供一個可擴展的解決方案。
EOS42 發文總結了當前的各種解決方式，並提出了一個可擴展的解決方案。EOS42 節點是首個安裝並運行了狀態歷史插件的EOS API節點，併爲BlockOne所創建的狀態歷史插件提供了一個開源RPC API。EOS社區將很快能夠使用我們的API來查詢歷史數據。
爲了對EOS網絡中常用的插件進行標準化，會確保API的響應與當前的實現相匹配，以便現有的dApps能夠無縫地接入我們的解決方案。
如下爲正文。
EOS完整歷史節點的問題
EOS的應用程序，非常依賴於區塊鏈上的數據。歷史插件可以使得應用程序對存儲在區塊鏈上的任意的歷史信息進行查詢。然而，實現這一重要功能的各種機制之間，會存在一些差別。事實上，最初的歷史插件，在2018年8月14日的EOSIO 1.2.0更新中已經被棄用。
不出所料，由於EOS網絡的快速增長，歷史插件變得越來越難以支持。
在2018年11月初同步和運行一個完整的歷史節點大約需要800 GB RAM。在不到一個月的時間裏，歷史插件現在需要超過1.5 TB的ram，在幾周內幾乎翻了一番!
使用歷史插件來運行完整的歷史節點現在需要花費大約3萬美元。按照這種速度，歷史插件既不具有可持續性，也不具有成本效益。
此外，BPs通過過濾掉“高流量”賬戶來降低存儲成本。因此，EOS 主網沒有“真正完整的歷史”節點來存儲EOS區塊鏈上的所有內容。例如，由於過多的事務(許多人認爲是垃圾郵件)，許多BPs不爲blocktwitter保存任何事務歷史。此外，在11月14日的那一週發生了短暫的問題，所有完整的歷史節點都崩潰了。如果沒有任何可公開訪問的端點，就無法查詢區塊鏈的完整狀態。由於維護完整的歷史節點非常昂貴、耗時和技術要求，dApps利用了BP API節點。結果，像DEXEOS這樣的dapp和Lynx這樣的錢包暫時無法完成它們的用戶請求。
雖然EOS網絡今天沒有遭遇危機，但我們預測，與歷史插件相關的問題，未來會出現更多。如果現在不採取行動，最終會對網絡造成嚴重影響。爲了改善當前基礎設施的脆弱性，提高網絡的壽命，EOS42正與其他社區成員合作，爲完整的歷史節點提供一個可擴展的解決方案。
可能的解決方案
歷史插件通常被認爲是一個短期的解決方案，需要切換爲更有效的解決方案。此外，EOS社區一直在努力開發更好的解決方案，讓每個人都可以使用。首先，讓我們探討一下當前的解決方案。
MongoDB插件
blockone開發了MongoDB插件。MongoDB插件允許將區塊鏈數據存儲在MongoDB數據庫中，這樣可以更有效地索引和查詢數據。MongoDB插件是一個很好的選擇，可以彌補歷史插件危機。
然而，MongoDB插件有許多挑戰。
例如，MongoDB插件本身並不是一個完整的解決方案。雖然MongoDB插件將用區塊鏈信息填充MongoDB數據庫，但它不允許外部用戶以與歷史插件相同的方式查詢數據庫中的信息。
社區必須創建API接口，以允許MongoDB插件“接入”到許多dApps現在依賴的經典API接口。Cryptolions已經開發並維護了一個很棒的開源解決方案，稱爲EOS Mongo 歷史 API。
此外，目前的MongoDB插件還沒有最終確定，我們已經看到了EOS.io軟件所發佈的多個更新版本之間數據結構(schema)的變化。每當結構發生變化時，任何維護MongoDB節點的人都需要完全重新同步他們的節點，以構建新的數據結構。根據所使用的硬件，完全同步一個節點可能需要幾天或幾周的時間。重新同步也造成了許多挫折和時間損失。許多人反饋說，需要多次同步，才能夠最終成功。
一旦同步完成，還有其他需要克服的挑戰。如果MongoDB實例被太多的請求造成了溢出，數據庫會崩潰，NodeOS將繼續實時接收塊，並嘗試將信息插入數據庫。如果數據庫本身停機了幾分鐘，就會在數據庫中出現缺口。在這種情況下，唯一的解決方案是完全重播(replay)/重新同步節點。
MongoDB插件的另一個問題是，可能會爲相同的事件插入重複的數據。這個問題可能會增加存儲需求，並在管理數據庫時增加額外的複雜性。最值得注意的是，重複的數據必須手動刪除。
EOS Light API
EOS Light API是一個由BP贊助的開源插件和API。被稱爲cc32d9的開發人員創建了這個項目，並開發了最初的ZeroMQ插件。ZeroMQ插件在Chintai的開發中發揮了至關重要的作用。
事實上，ZeroMQ是我們在Chintai中使用的開源插件的基礎。EOS Light API在插件級別使用ZeroMQ和MySQL作爲數據庫存儲。EOS Light API已經準備好進行公開測試，更多信息可以在這裏找到。
Elastic Search插件+ API
Elastic Search 是分析大型數據集的一種常用方法。EOSLaoMao已經爲Nodeos開發了一個開源插件來支持對Elasticsearch集羣中的EOSIO 主網中的歷史數據進行索引。此解決方案的優點是，能夠快速搜索並關聯區塊鏈的完整歷史上的數據指標。目前，EOSLaoMao和EOS Rio正在爲這一方案和其他數據歷史解決方案，開發一個開源API，以及新的API標準。
DFuse
DFuse是EOS Canada開發的新解決方案。DFuse允許dApp開發人員從區塊鏈獲取歷史數據和實時事件。雖然Dfuse這一解決方案並未開源，但是對於EOS社區dApp開發人員來說，在構建應用程序時從區塊鏈獲取歷史信息的多一個選擇，也同樣重要。
狀態歷史插件(state history plugin)
來自BlockOne的Todd Fleming 開發了名爲State history Plugin(狀態歷史插件)的這一歷史解決方案。狀態歷史插件解決了MongoDB插件遇到的一些問題:
- 自動處理分叉，不會存儲任何重複的數據。
- 數據庫存儲與節點解耦。因此，如果數據庫宕機，可以很容易地進行同步，而無需停止節點或需要重播區塊鏈。
- 其他以前無法實現的功能。這些功能包括，在某個智能合約所有相關區塊中，獲得該智能合約的數據表中的記錄。
- 由於採用瞭解耦設計，未來對任何數據表結構的更改都不需要重放Nodeos(注意：這一功能會包含在未來的更新中)。
Todd還開發了一個實用程序 fill-postgresql，它會用新的歷史信息填充Postgresql數據庫。未來會開發出許多其他向數據庫填充數據的程序，而不只侷限於一個數據庫。
這對MongoDB插件意味着什麼
據Todd所說，BlockOne在並行開發State History插件和MongoDB插件，並計劃同時支持這兩個插件。Todd設想未來可以使用多種歷史方式和存儲機制，允許社區成員自由選擇適合他們需求、預算和專業知識的解決方案。
狀態歷史API
狀態歷史插件目前已經可以使用了，但是沒有像Cryptolions EOS Mongo History API這樣的API。幸運的是，情況已不再如此。
最近，EOS42成爲了第一個安裝並運行狀態歷史插件的EOS API節點。這標誌着一個新的完整歷史解決方案之旅中，一個重要里程碑。EOS42提供了第一個正式環境下運行的系統，在EOS主網上測試和運行了狀態歷史插件。
我們還激動地宣佈，我們已經爲狀態歷史插件創建了一個開源RPC API，稱爲EOS狀態歷史API。EOS社區將很快能夠使用我們的API來查詢歷史數據，這進一步增加了社區完整歷史API的冗餘性和靈活性。
爲了對EOS網絡中常用的插件進行標準化，我們確保API的響應與當前的實現匹配，以便現有的dApps能夠無縫地插入我們的解決方案。此外，作爲Elasticsearch插件項目持續開發的一部分，EOS Rio和EOSLaoMao發起了開發新API標準的倡議，我們也會進行緊密的合作。
最後,爲了使狀態歷史插件更容易使用, EOS42正與(blockmatrix)(https://blockmatrix.network/)一起，提供針對日常歷史狀態數據的快照數據文件, 這可以讓任何人都能夠在幾分鐘內創建起來一個全新的歷史節點, 不用花費數週時間等待數據同步。
如果更多的問題，想法，或者評論，您可以通過電報羣，微信羣，或者其他社交媒體渠道聯繫我們。
EOS42 開創去中心化的未來
EOS42的賬號爲: eos42freedom。