Hive-engine light node

[primersion]

Description

This pull requests adds light node functionality to hive-engine. Instead of storing all data of the hive-engine blockchain, light nodes only store smart contract data and data required for block verification, but not the full chain (blocks, transactions are cleaned up periodically). This will allow for faster restoring / synchronizing and make the network / the witness block signing process more stable.

How to enable

Stop the node. Set lightNode: true in the config.json. Start the node and it will initially delete all transactions and blocks < lastVerifiedBlockNumber - blocksToKeep from the database. This process may take a few minutes - if you want to be faster you may want to use a lightnode snapshot and restore the database first. Ask me on discord for a snapshot or check out the following url:
https://snap.primersion.com/light/

Restoring process is the same as for full nodes:

• Download snapshot
• Drop database
• Restore snapshot using mongorestore
• Set startHiveBlock in config.json
• Set flag lightNode: true in config.json
• Start node

If switching from a full node you may need to run db.runCommand({compact: 'chain', force: true}) to free up storage consumed by mongodb.

Differences of light nodes

• getStatus request will return an additional parameter lightNode: true and blocksToKeep: 14400
• getBlockInfo rpc call will only work from block lastVerifiedBlockNumber - blocksToKeep up to the head block
• getTransactionInfo rpc call will only work from block lastVerifiedBlockNumber - blocksToKeep up to the head block
• find_divergent_block script only compares the hash of the head block to the head block hash of another node

Cons

• Not all transactions are stored in the database (only txs of the last blocksToKeep blocks)
• Blocks are only stored as long as >= lastVerifiedBlockNumber - blocksToKeep
• Can't switch back from light node to full node (need to restore from full node snapshot)

Pros

• Fast restore and dump (5 minutes, compared to > 2 hours for full node)
• Small dump size (360MB currently, compared to 40GB for full node)
• Nodes get less load
• 2GB of storage compared to 90GB of a full node

A few more details in the post over here: https://peakd.com/hiveengine/@primersion/hive-engine-light-nodes

[Rishi556]

Less memory is also required to run, and apps which only need current data to run(ex just care about current NFT inventory etc) can self host a node for a lot cheaper reducing the load on public infastructure.

[bt-cryptomancer]

I'm not completely comfortable with exposing cleanupBlocks to the smart contracts API. I also don't like the idea of modifying the witnesses contract to do that, because this is a breaking change which will force everyone to upgrade their node software. I'd rather have the next version release be an optional upgrade, so if you don't want to run a light node you don't need to upgrade.

Can you remove that from the witnesses contract and have it be done internally to the node software? It could be done as a maintenance operation every so often (maybe every 50 blocks, say) inside the produceBlock function of libs/Block.js. Also, please make sure that running a light node does not affect database hashes.

Can you merge the changes from this PR by @Rishi556 (which I've already approved) into your own branch: #145

That PR makes changes to the getStatus function, which may cause a conflict since you touch that function too. Would be convenient to have that resolved in your PR so I don't have to do conflict resolution when preparing the next release.

[eonwarped]

I'm not completely comfortable with exposing cleanupBlocks to the smart contracts API. I also don't like the idea of modifying the witnesses contract to do that, because this is a breaking change which will force everyone to upgrade their node software. I'd rather have the next version release be an optional upgrade, so if you don't want to run a light node you don't need to upgrade.

Can you remove that from the witnesses contract and have it be done internally to the node software? It could be done as a maintenance operation every so often (maybe every 50 blocks, say) inside the produceBlock function of libs/Block.js. Also, please make sure that running a light node does not affect database hashes.

Agree with this ask. Right now the witness contract changes wouldn't even work as is because it would need it to be deployed and all nodes would have to understand this action. But this isn't the right way to do the clean anyway, and @bt-cryptomancer suggestion is better to have it happen internally for light nodes in the appropriate location (produce block is sensible)

[primersion]

Thanks for the review and for your comments regarding the changes. Running a light node does not affect database hashes. Everything is the same as for full nodes, except that light nodes do not store all blocks / transactions.

I have now updated the code as follows:

• Merged @Rishi556 PR Visiting / will get status instead directing to a cannot get / page #145
• Removed the comment
• Moved the cleaning up of blocks / transactions to Block.js (done every 100 blocks)
• Added another param blocksToKeep, which defines how many blocks (and the corresponding txs) should be kept before cleaning up (default is currently 864,000 ~ 30 days)

[bt-cryptomancer]

Mostly looks good now, just a couple minor points that I'm concerned about (see comments below).

Also, can you put some comments in the code wherever it seems appropriate to indicate that blocksToKeep only applies in the event that lightNode is true?

[bt-cryptomancer]

This all looks good now, thanks for the revisions. Will include this PR in the next version release.