如何正確的分析 EOS 區塊數據

前言

隨着大熊市的到來，EOS 上被套住的韭菜們開始在各類菠菜 Dapp 中自娛自樂，長此以往 EOS 也變成了一條菠菜鏈。因而在 EOS 上作數據挖掘就成了頗有樂趣的事情，咱們能夠去分析賭徒們的行爲；項目方是如何發展、引爆的；以及整個 DApp 市場的走勢。

通過簡單的調研，咱們發現能夠經過分析區塊 Transaction 裏面的 actions 來獲得咱們想要的結果。可是問題來了，咱們如何拿到想要分析的那個合約的數據呢。又去搜了一下發現大概有這麼幾個方法：EOS RPC API、區塊鏈瀏覽器 API、跑個全節點。

RPC API

RPC API 很是粗暴，調研了一大圈發現基本上能用的就兩個 API：

1. 獲取當前區塊高度，即 get_info
2. 獲取區塊內容，即 get_blocks

這個時候咱們發現一個很是蛋疼的事情，咱們若想分析這一週某個合約的調用狀況，咱們就須要算出來這一週的區塊高度範圍，而後開始一個個的拿區塊信息。

好比說咱們想拿兩個月的數據，首先咱們知道 EOS 是每 0.5s 一個區塊，那麼兩個月就是 3600 * 24 * 60 * 2 這麼多個區塊，大概是一千萬左右。而後每一個區塊大小是 1MB，那麼這個請求尺寸可想而知。雖然說，EOS 不多有超過 100k 的區塊，但就 1000w 個 10KB 的區塊，這也要將近 100G 的數據量了。不過看起來好像還好？20M/s 的速度，100G 一天也就同步完了。

但最蛋疼的事情是，中國大陸沒有一個超級節點訪問起來很是友好的，常常有一個請求好幾秒的狀況，那麼咱們要爬這麼大的數據就吐血三升了。若是願意在境外服務器上作爬蟲，那麼就要堆服務器存儲，並且再搬回國內同樣的麻煩。

因而這條路基本上行不通，RPC API 仍是留着用追蹤區塊信息，作觸發器吧。

區塊鏈瀏覽器 API

RPC 撞牆了，倒也無所謂，由於咱們大部分研究區塊數據都是從瀏覽器裏面獲取的，並且瀏覽器的 API 擴展了不少方法。好比根據 account/合約地址查詢交易行爲、持幣量等等。

然而通過調研各大區塊鏈瀏覽器的 API 健壯程度，發現我真是太樂觀了，這簡直是刀耕火種。不是 API 動不動就超時，就是直接整個瀏覽器間歇性的服務掛了，服務器直接 503 。固然最不能理解的就是，這樣粗製濫造的 API，竟然是收費的！

因而對於區塊鏈瀏覽器，咱們作簡單分析還行，數據量大了實在是沒戲，這條路也行不通。

全節點

因而，看起來最複雜的方法也成了惟一的方法，只能跑全節點了。通過跑 BTC 全節點的經驗，咱們直接配一臺服務器，讓他慢慢同步就行了。

方法很接單：

• 下載安裝包，注意這是 18.04 的版本且不推薦在 Mac 下用 Docker 來運行它。由於 nodeos 是單線程的，沒法使用多核資源優化它，吃 CPU 主頻。

wget https://github.com/eosio/eos/releases/download/v1.5.0/eosio_1.5.0-1-ubuntu-18.04_amd64.deb
sudo apt install ./eosio_1.5.0-1-ubuntu-18.04_amd64.deb
複製代碼

• 下載主網創世區塊信息：

wget https://eosnodes.privex.io/static/genesis.json
複製代碼

• 生成 config.ini：

mkdir ~/.local/share/eosio/nodes/config/
 nodeos  --print-default-config > ~/.local/share/eosio/nodes/config/config.ini
複製代碼

• 配置 PEERS：

把 https://eosnodes.privex.io/?config=1 裏面的東西貼入 config.ini 文件中對應的位置。

• 運行：nodeos --genesis-json genesis.json 便可。

然而發現，這玩意跑起來每十分鐘大概同步 1w 個區塊，如今 EOS 已經到了 3000w，因而我須要 30000分鐘，也就是 20 多天才能同步完成。本着幣圈一日，人間一年的信念，這必需要研究有沒有更優雅的解決方案。

經過 Google，發現有個 BP 提供當日 backup 服務：https://eosnode.tools/blocks，截至聖誕節當天，壓縮包已經 85G，解壓後 150G 左右。咱們把它解壓好了，用 nodeos -d 指定到解壓目錄便可運行，這個時候 nodeos 會作這麼幾件事：

1. 重建 blocks.log 的索引
2. 重放每一個請求，恢復 ram 數據。
3. 因爲上面咱們修改過 config 裏面的 peers 信息，重放完了以後它會繼續同步區塊信息直到追上 BP。

這個時候狗血的事情就來了，重建索引這個事情還好，大概一小時就跑完了。然而重放 3000w 條區塊裏面每一個 transaction 的數據，刺激的很。

並且這個過程 不！可！以！停！止！ 一旦中止了，就會觸發 Dirty flag，官方提供的解決方法就是從新 hardreply！而後最欠抽的事情是，重放過程當中，RAM 是徹底堆在內存裏面的，哪怕沒有用過也不會換出去，咱們會看着內存從幾百M一直飆到將近 30G。

我以前是在 16G 的機器上跑的，結果到後面一分鐘也就只能重放 100 個區塊左右，由於時間全浪費在內存頁錯誤上了，CPU佔用率極低。因而只能淘寶又買了兩條內存插上，從頭重放！

過了 80 小時後，重放完成了，這個時候能夠中止 nodeos了，當咱們再次啓動的時候，內存使用量難以想象地回到了 1G 之內。但 ram 數據都在的，lazy 加載硬盤數據。因而，爲啥重放的時候不作個 LRU！？

重放完成後，又同步了 12小時，終於追上了 BP。

小結

從我有念頭作 EOS 數據分析，到能獲取到分析數據花了我兩週的時間，走了大量的彎路。這裏面不少東西都是官方文檔徹底沒提，須要本身 Google 或者看源碼去摸索的。

讓我有一種當初折騰 ubuntu 6.06 同樣的感受，徹底靠蒙。全部配套設施都不完善，不少東西感受都像是趕時間糊出來的。如此惡劣的環境，EOS 倒是當今開發最友好的公鏈，沒有之一，你敢信？

做爲韭菜，只能一遍遍的安慰本身這只是剛開始，正規軍還沒入場，麪包會有的，牛奶會有的，一切都會好起來的。

不過無論正規軍能不能入場，我終於有一套數據能夠丟給 map reduce 來玩了。