HyperSync Protocol Proposal
The following is a proposal to speed up Blockchain downloads, either of new client setups, or existing syncing, using Masternodes.
Current Methodology
Current technique follows a partial P2P approach to blockchain sync. The implementation has issues because of inefficient handling of duplicate blocks. Resending of blocks. Being lenient to slow, buggy, and/or corrupt clients.
Current systems sync the blockchain, then sync masternode data.
HyperSync Proposal
By utilizing Masternodes, we can be sure that:
- A masternode is always 100% synced
- Is running on dedicated hardware (virtual or otherwise).
By reversing the process (sync masternodes first, then blockchain). We can setup a HyperSync of the blockchain while maintaining backwards compatibility with old clients and avoid a hard fork.
If we sync the masternode data first. We can initiate http range queries to a REST post for blockchain parts. These background threads will begin download the blockchain from masternodes in parts. Masternodes who's REST ports are blocked, or who consistently throttle data can be purged from the reward queue.
With http range queries the blockchain can be downloaded in little time from existing masternodes. The client can be operational in a fraction of the time.
To avoid hijacking of the blockchain by errant masternodes, after the HyperSync protocol completes, we can revert back to a standard block verification from existing clients. This can run in the background, and will prevent sending transactions (but not viewing or receiving) until the verification completes.