如何正确的分析 EOS 区块数据

港控/mmm° 2021-09-18 08:02 405阅读 0赞

## 前言 ##

随着大熊市的到来，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。