Distinct "sync phase" upon startup about chainweb-node HOT 6 OPEN

➤ lars commented:

We also have to do block header validation. Most of it is implied (i.e. checked) by inserting into the respective block header db. But adjacent parent verification isn’t. Currently it is done by recursively checking that all dependencies are available.

For an iterative approach one would have to ensure that blocks are added in the right order, so that all dependencies are added before the block itself.

I think there are two options:

1. Use the current recursive approach and just switch off/leave off mining (and possibly cut processing).
2. Use the (currently switched off) single-chain sync session to get all block headers (without parent validation and pact validation) and do a second path over all block in the db to run pact validation and adjacent parent validation.

The second is a little more tricky and possibly not worth it, because compared to a final solution, it’s just something like 50% feature wise but 90% in terms of dev costs, I guess.

With the first option there is a chance that we need some memory for storing the open tasks in the task queues during the recursive decent. There may even be some stack-build up (not sure, I would have to check the code). Still I propose to try that first and see how it performs.

from chainweb-node.

➤ lars commented:

So, a good way to start would be to run Chainweb.Chainweb with mining and cut-processing disabled and switch both components on only when we synced with the head of Chainweb.

I am not sure how much overhead cut processing causes. So we may first try to just leave the miner disabled, which is easier to do.

from chainweb-node.

➤ lars commented:

For turning off cut processing would would have to add a flag to the cut-Db queue processor to just drop new incoming cuts. However, we would still need to query a "starting" cut to start with. So it's most likely the easiest to leave cut-processing on.

from chainweb-node.

➤ Colin Woodbury commented:

This PR #92 addresses this task. It may already work as intended and need no further tweaks. I still need to test it a bit more.

from chainweb-node.

➤ [email protected] commented:

Efficiency has been addressed; priority has changed now

from chainweb-node.

➤ [email protected] commented:

Moved from v1 to v2

from chainweb-node.