简介：区块链历史 API 是 EOS 主网很需要正视的一个问题。 DApps、区块浏览器和钱包必须查阅历史信息才能正常工作，而现在在 EOS 主网上运行完整的历史记录，非常昂贵、复杂且耗时。针对这个问题，EOS Rio 团队提出了 Hyperion History API 这个解决方案。
今天聊聊 EOS Rio 团队推出的一个全新 EOS 区块链历史数据 API 解决方案——Hyperion History API.
区块链历史 API 是 EOS 主网很需要正视的一个问题。 DApps、区块浏览器和钱包必须查阅历史信息才能正常工作，而现在在 EOS 主网上运行完整的历史记录，非常昂贵、复杂且耗时。相信最近这个话题大家也都有所耳闻。
EOS V1 History API，目前只有少数BP在提供，（Sw / eden，CryptoLions，EOS Tribe，Greymass，EOS Canada，EOS Asia和Oracle Chain），许多开发者为此付出了努力。
一些人认为这不是一个大问题，因为历史数据 API 最终可以形成商业模式。需要历史记录的 DApp、区块浏览器和钱包可以向提供 API 的 BP 付费。不过社区普遍认为，提供历史链数据的困难可能会妨碍 EOS 实现预期的可扩展性。
EOS 区块链截至2019年3月7日，包含大约4600万个块。一个新搭的节点需要获取所有这些块以及每秒附加到链上的另外两个块，目前这需要数周时间。 同步后，目前的 v1 History 插件需要超过 5Tb 的存储空间才能运行，查询数据库需要大量处理能力和网络带宽。因此，目前运行完整 EOS 区块链历史记录，可能至少需要花费15,000美元/月。
Hyperion History API
新的视角
几个月前，EOS Rio 团队开始就此问题的可能解决方案进行头脑风暴。 他们决定从头开始，不专注数据本身，而是分析可以采取哪些措施优化数据库大小。
V1 History API 其实存在很多冗余，比如存储了内联操作记录（inline action）。内联操作的主要作用是用作“事件”机制通知交易方，作用有限，实际上历史 API 没必要存储它。
EOS Rio 团队据此提出了 Hyperion History API，它实现了：
1.Actions 以一种扁平化格式存储；
2.将父字段添加到内联操作以指向父全局序列；
3.如果内联操作数据与父操作数据相同，则将其视为通知，从数据库中删除；
4.不存储区块或事务数据，但可以通过 actions 重建所有这些信息；
5.不存储交易验证信息，因为已经可以使用 Chain API 进行交易验证；
6.通过这些更改，API 缩短了响应时间，降低了带宽开销，也使UI / UX开发人员更易于使用。
存储的数据结构如图：
Hyperion History API 存储数据结构
更小但更强大
更改格式和减少数据冗余可以将数据库大小减少约85％，从近 5Tb 减少到约650 Gb。为进一步提高性能，EOS Rio 团队设计了一个多线程索引器，它从状态历史插件中提取数据，可以在大约72小时内通过适当的硬件优化来获取完整的 EOS 区块链，而当前的解决方案可能需要数周时间。
团队还引入了“ABI 历史缓存层”组件，以防止在 ABI 并行修改处理历史数据时出现反序列化失败。
对于数据库，团队部署了一个 Elasticsearch 集群，该集群在位于里约热内卢/巴西的一级基础架构上并置的两个定制组装裸机服务器上运行。
优化的数据结构减少了 CPU 和带宽消耗，使基础架构更具可扩展性。 运行完整历史 API 的 BP 已经在测试 Hyperion 并帮助其发展。
开源地址
EOS Rio 已经在 https://br.eosrio.io/v2/history 上提供使用 Hyperion 的 History API。
项目代码和初步设置说明：https://github.com/eosrio/Hyperion-History-API
官方文档：https://br.eosrio.io/v2/history/docsSource
Javascript 库：https://github.com/eoscafe/hyperion-api
参考资料：Hyperion History API Solution: https://medium.com/@eosriobrazil/presenting-hyperion-history-api-solution-f8a8fda5865b
网友评论