如何正确的分析 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 来玩了。