Case study To Focus on the Discrepency with syncing #24
Description
The below case study will give the rationale to continue development however spend a large amount of time on the syncmanager.
Sync times on blockchains take a relatively large amount of time, however with NEO it seems to be more pronounced.
Bitcoin Core had seen a massive increase in this in release 0.14.0 . Except for the IBD that bitcoin uses, this is where NEO and BTC's syncing algorithms started to fork.
0.14 Release notes: https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md
Article on changes: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#ibd
The main reason for this was due to Bitcoin replacing checkpoints with "Assumed Valid Block".
The article states that Bitcoin Core 0.13.2 took 1 day, 12 hours, and 40 minutes to complete and Bitcoin Core 0.14.0 took 0 days, 6 hours, and 24 minutes to complete
At the time of the article, Bitcoin had ~250Million transactions. https://www.blockchain.com/charts/n-transactions-total
NEO had ~15 million: https://neodepot.org/charts/transactions-count-total
The average size of a bitcoin tx in 2017 ~ 600bytes. https://tradeblock.com/bitcoin/historical/1w-f-tsize_per_avg-01101
The average size of a NEO transaction in 2017 was roughly 225 bytes.
Noting that all things are not equal; Bitcoin's scripting language and smart contract support is much more limited, therefore Bitcoin will always sync faster than NEO if all other variables are equal. The gap should however be reasonable and this unfortunately is a subjective matter.
With all this in mind, the syncing process for NEO to get to block 1.5Million should only take a day at max, because tx size was almost a third of Bitcoin, while BTC had roughly 15 times more tx's, this should negate the fact that NEO has a more expressive smart contract language(s).
From syncing I have done in the past, it takes a couple of days at least to get to this number and increasingly slows down as time goes by for NEO. Note that the comparison is being done with bitcoin 0.3.2 when assumed-valid-block was off.
In order to match or possibly beat the bitcoin 0.4.2 benchmark, assumed-valid-block would be a beneficial feature to have. Assume-valid-block is not the same as a checkmark.
Article on assumed-valid-block: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
In addition to this:
- The modified IBD would need to be altered to monitor block times and not peer stalling times. One reason why bitcoin can have a better syncing process is because the software has a better monitoring process for when a peer dies or is stalling. This allows the syncing algorithm which relies on peers to be more efficient.
Notes
- Assumed valid will have to be done around block 1.8Million.
Critique of this case study is welcomed.