provable-eos-ptokens.md

Provable - pBTC on EOS

Architecture

Both EOS Mainnet and Jungle 3 have the same structure.

The ptokens machine are composed by 4 main elements:

• Mongo db, creates index as block num. two collections traces and blcoks. Tx are the redeems. Mongo problem just restarts. Db is very light. Not the bottleneck.

• Nodeos, check that is always in sync via cleos get info. history and state history plugins should never be used together, for now em4 is running with both on since the history plugin is needed not just for getting actions but also for the library that Alessandro wrote and Equilibrium is using it. Just restarts if block, delete blocks and state and statehistory only when starting from skeatch. Use snapshot from eos nation. Starts wirh —snapshot

• consumer & receiver, which is eos-chronicle receiver reading the state-history from the node and the consumer is saving blocks and redeems to mongodb. Needs nodeos and mongo to work.

• get-block-with-mongo ts-node express server, which returns data called from the syncer. Needs nodeos and mongo to work.

Troubleshooting

Mongo DB

Should be started with systemd, if crashes it should be able to restart it.

Nodeos

If crashed and history is not corrupted, just use the ./start.sh script to restart it.

If history is corrupted there will appear a trace error in the log, from here there are 2 cases:

• nodeos is still in sync, printing trace errors in the logs and still saving blocks to mongo correctly, but redeems and transactions in general are not seen. To recover a redeem don't touch nodeos but the chronicle-receiver needs to be started from the block where the redeem is. Very fast and not painful process.

• nodeos is blocked, not in sync and not saving blocks. History is corrupted and it won't restart. Delete blocks, state, state-history and start nodeos from a snapshost. Check the last block saved in mongo, use a snapshot that includes the next block. It may take some time to resync. It usually 150% faster in processing blocks but still it may take several hours depending on the snapshot.

Consumer & Receiver

Consumer must be always start before than receiver.

• Consumer crashes: restart it first with npm run start and then resume the receiver.

• Receiver crashes: to resume use the .sh file without the --start-block option. Otherwise to start from scratch, remove the option and remove the chronicle-data folder as well.

Get Block server

When the script crashes accidentally just restart it with npm run start.

Use the /ping endpoint to check that the get block is working.

You can also start it with while true; do npm run start; sleep 1; done;

Endpoints:

Endpoints available are:

❍ GET /ping

❍ GET /get-block-init

❍ GET /get-block/<block-num>

❍ GET /get-block-ids/<block-num-from>/<block-num-to>

❍ GET /get-block-ids-dfuse/<block-num-from>/<block-num-to> // works just for mainnet as backup

❍ GET /get-block-with-schedule/<schedule-num>

Next Steps

Dockerize the whole components via docker compose to allow a fast start and to restart every component automatically if something goes wrong. Please, note that some components require others to work, so dependiencies between dockers must be maneged efficiently.