如何正确的分析 EOS 区块数据
前言
随着大熊市的到来,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 来玩了。
还没有评论,来说两句吧...