Initial cut height limit and private flag #674
Conversation
|
This should go in after #677 . |
| @@ -376,6 +380,9 @@ pChainwebConfiguration = id | |||
| <*< configCutFetchTimeout .:: option auto | |||
| % long "cut-fetch-timeout" | |||
| <> help "After this many microseconds, give up trying to sync a particular Cut" | |||
| <*< configInitialCutHeightLimit .:: fmap (Just . BlockHeight) % option auto | |||
There was a problem hiding this comment.
should this even be configurable? This sounds like best practice for catchup. We should poll our bootstraps for their most recent highest cut to determine this number on startup and defer to 0 otherwise.
There was a problem hiding this comment.
For this to be effective, we need an estimate of the height of the fork point. The better the estimate, the better the performance. 0 is always a valid estimate, but it's inefficient, because pact replay takes a long time -- in particular once we have transactions in the system.
To me it seems that those extreme scenarios with very deep forks are best resolved by manually switching to an "repair" mode. This options plus the --private flag would be such a "repair" mode.
Co-Authored-By: Emily Pillmore <[email protected]>
larskuhtz
changed the title
Co-Authored-By: Colin Woodbury <[email protected]>
private: true: prevents the addition of any new peers to the PeerDb. The only peers that a private node connects to are the configured known peers. With this PR other nodes can still push cuts to a private node. PR require cut origin to be known #681 prevents unknown peers from pushing cuts.initialCutHeightLimit: When switching between forks, long rewinds are very expensive. Another issue is that a node that switches from forkAtoBwill go toBat a height larger than the current height anA. If the fork point is deep down it will attempt to do this in a single step, which might cause timeouts during rewind or pact replay (which doesn't cache intermediate states).This PR allows the user to provide an estimate of the fork point or any lower bound (0 is always a safe, but inefficient choice), to cause he node to start cut processing at a block height blow the fork point.
Another benefit of this option is, that it allows a node to re-validate the history of the block chain from some point onwards. This verifies the consistency of the database and the chain.