Provide up to date snapshots to support IBC and history nodes

4 min readJun 20, 2019

We will provide snapshots that are currently updated every 12 hours for EOS and every 24h for BOS, Meetone and Worbli.
BOS: https://snapshots.bossweden.org
EOS: https://snapshots.eossweden.org
Worbli: https://snapshots.worblisweden.org
Meetone: https://snapshots.meetsweden.org

Link to our proposal

https://boswps.io/#/poll_detail?proposal=bossnapshots

Problem — Troubleshooting IBC and supporting history nodes

As described in this article:

One of the issues with IBC that needs to be solved is to provide a solution for when relay nodes lack specific data.

“Fault description: Let’s take the transfer from Chain A to Chain B as an example. Assuming that a cross-chain transfer transaction occurs in the 10000 blocks, Chain B’s relay (relay B) requests a bunch of headers from Chain A’s relay (relay A), for example, requests headers 10000–10085, a total of 86 headers.
According to the BP signature verification logic in EOSIO, relay A needs to get blockroot_merkle of block 10000, but on ordinary nodes, only blockroot_merkle of blocks in forkdb can be obtained, so ibc_plugin uses the block’s extension to record blockroot_merkle for some blocks. If in the process of using IBC, if for some reason, such as the administrator change a normal fullnode to a relay node at header_num greater than 10000, relay A may failed to obtain blockroot_merkle of block 10000, then the subsequent cross-chain behavior can not be carried out.
Restoration:
First: Look for a snapshot whose block num of the head is less than 10000, for example 9000, and then start the relay node with this snapshot. At this time, the relay node can get the blockroot_merkle of the 10000 blocks. Second: reinitialize the IBC system (see below for details).”

Each time the IBC system needs to be reinitialized you will need a place to fetch an up to date snapshot. This is to quick and efficiently get everything back in order.

We as a community are working towards the goal of phasing out v1 history (the plugin has been deprecated by block.one). The most probable way ahead is that we go through state-history and use that plugin to index an external database, i.e. Hyperion which uses elastic search.

Solution — Providing a tool that increase efficiency of IBC and history nodes.

Our solution is to bring an convenient place to download an up to date snapshot of the chain.

You will find updated snapshots every 6 hours for EOS, BOS, Worbli and Meetone to optimize the recovery of the IBC protocol.

There are multiple ideas to solve the history issue and currently it is most likely that the state-history solution will be used. The availability of snapshots will ease the process of keeping a state-history node synced. Which means it will be more reliable for everyone wanting to use it. By using a new history solution we can get back in sync faster, use less storage and provide better indexing.

Execution Plan

We have already built and executed the plan, and it is open and available for anyone and everyone to use. For the coming future our work is to make sure they stay up to date with little to no issues along the way.

To develop our snapshot portals we have involved 3 people in our team, and for the future it will most likely involve one of us couple of hours per month.

You find our snapshots platforms here:

EOS Snapshots
BOS Snapshots
Meetone Snapshots
Worbli Snapshots

Fund Release Plan

We provide the snapshot platform for the community to use however they deem fit. This proposal is an open letter to find out if the community value our solution to one of the current IBC and history problems.

Our request comes in at a symbolic sum of 50,000 BOS per chain we initiated a snapshot portal for.<br>
This amount is thought to re compensate the time we spent putting it together and to cover parts of the future expenses involving the snapshot platforms.

We kindly ask for 200,000 BOS to compensate for building and maintaining this project.

This will cover our costs for the coming 8 months — Until February 2020.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

提供最新的快照以支持IBC（跨链通信）和历史节点

我们节点目前为EOS主网提供每12小时更新一次的快照，并为BOS、Meetone和Worbli提供每24小时更新一次的快照。
BOS: https://snapshots.bossweden.org/
EOS: https://snapshots.eossweden.org/
Worbli: https://snapshots.worblisweden.org/
Meetone: https://snapshots.meetsweden.org/

挑战 — IBC的故障排查；历史节点的支持

如本文所述：

目前需要解决的IBC问题之一，是为中继节点上特定数据的缺失提供解决方案。

故障描述：例如，我们需要将数据从链A转移到链B。假设在10000个区块中发起跨链转移事务，链B的中继（中继B）从链A的中继（中继A）请求一些区块头，例如，请求区块头10000–10085，总共86个区块头。
根据EOSIO中的BP签名验证逻辑，中继A需要获取第10000个区块的blockroot_merkle（默克尔树区块根），但是在普通节点上，只有forkdb中区块的blockroot_merkle（默克尔树区块根）可被获得，因此ibc_plugin只能使用区块的扩展来记录某些区块的blockroot_merkle（默克尔树区块根）。如果在使用IBC的过程中，如果由于某种原因，管理员将一个正常的完整节点更改为header_num（区块头数）大于10000的中继节点，那么中继A可能无法获得第10000个区块的blockroot_merkle（默克尔树区块根），那么后续的跨链行为则可以不被执行。
恢复：
第一步：查找区块头的区块数小于10000的快照，例如9000，然后使用此快照启动中继节点。此时，中继节点可以获得这10000个区块的blockroot_merkle（默克尔树区块根）。
第二步：重新初始化IBC系统（详见下文）。

每次需要重新初始化IBC系统时，我们都需要一个地方来获取最新的快照。这是为了快速有效地将所有内容整理回来。

我们作为一个社区正在努力实现逐步淘汰v1历史的目标（该插件已被Block.One弃用）。最可能的方法是我们通过状态历史并使用该插件来索引外部数据库，比如，使用弹性搜索的hyperion。

解决方案 — 提供可提高IBC和历史节点效率的工具

我们的解决方案是为链上的最新快照提供一个易下载的地方。

我们将提供每6小时更新一次的EOS，BOS，Worbli和Meetone快照，以优化IBC协议的恢复。

解决历史问题有多种想法，目前很可能会使用状态历史解决方案。快照的可用性将简化保持状态历史节点同步的过程。这意味着它对每个用户来说都更可靠。通过使用新的历史解决方案，我们可以更快地恢复同步、使用更少的存储并提供更好的索引。

执行计划

我们已经制定并执行了该计划，并保持开放，让任何人都可以使用。我们未来的工作，是确保它们始终保持更新，不出现或极少出现问题，来保证最少停机时间。

为了开发我们的快照门户，需要我们团队的三位成员参与。未来，我们需要每月花费几小时来维护它们。

以下我们的快照平台：

EOS Snapshots
BOS Snapshots
Meetone Snapshots
Worbli Snapshots

基金使用计划

我们提供快照平台供社区随意使用。该提案是一封看社区是否重视我们对当前IBC和历史问题解决方案的公开信。

我们的诉求是为每个开发快照的链申请50,000个BOS的基金。<br>
该金额包括我们开发和维护快照门户所用的时间成本，并涵盖了涉及快照平台的未来部分费用。

所以，我们总共申请200,000个BOS来支持建设和维护这个项目。

这会涵盖未来8个月的成本 — 直到2020年2月。

团队

Team

Eric — CTO — Telegram — https://t.me/xebb82/
Vahid — CEO — Telegram — https://t.me/vahidtoosi1/
Henrik — Tech wizard — Telegram — https://t.me/pnxmode/
Anders — Daily operations — Telegram — https://t.me/orcus/
Gunnar — Tech Genious — Telegram — https://t.me/gunnarpope/
Javier — APP developer — Telegram — https://t.me/javierjmc/
Alex — Community — Telegram — https://t.me/alexfengshuo/