如何正确的分析 EOS 区块数据-CSDN博客

前言

随着大熊市的到来，EOS 上被套住的韭菜们开始在各种菠菜 Dapp 中自娱自乐，久而久之 EOS 也变成了一条菠菜链。于是在 EOS 上做数据挖掘就成了很有乐趣的事情，我们可以去分析赌徒们的行为；项目方是如何发展、引爆的；以及整个 DApp 市场的走势。

经过简单的调研，我们发现可以通过分析区块 Transaction 里面的 actions 来得到我们想要的结果。但是问题来了，我们如何拿到想要分析的那个合约的数据呢。又去搜了一下发现大概有这么几个方法：EOS RPC API、区块链浏览器 API、跑个全节点。

RPC API

RPC API 非常粗暴，调研了一大圈发现基本上能用的就两个 API：

获取当前区块高度，即 get_info
获取区块内容，即 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 会做这么几件事：

重建 blocks.log 的索引
重放每个请求，恢复 ram 数据。
由于上面我们修改过 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 来玩了。