Sventimir
commented
1 year ago As explained by Nathan on Slack, it appears that the behaviour I observed was caused by setting too low slot_window_duration. This parameter controls how often the blockchain is supposed to produce another block. If it is too low, nodes don't have enough time to validate incoming blocks and hence are forced to use some older one. In practice it looks something like this:
- Node produces a block for slot 2 and starts validating it.
- Because validation takes time, meanwhile it's time to produce block for slot 3. Because block from slot 2 is not considered valid, the node decides to append the new block to the genesis block, creating a fork.
- Slot 4 comes, and block from slot 2 is now validated, but block from slot 3 is not. Thus the node appends the new block to the one from slot 2.And so forth.
Indeed, if I remember correctly, this happened when I set block_window_durartion to 5 seconds. Later I increased the time and could not reproduce the issue ever since.
The recommended minimum block_window_duration at the moment is 45 seconds.
kantp
While working on Rosetta API I was running a single-node sandboxed network. In it I sometimes observed the node to produce two competing blockchains from the start for a couple dozen blocks until one of those blockchains eventually won over. This does not happen always and seems dependent on configuration. Still, this is an alarming behaviour, so it'd be godd to understand why this happens as it might be sympthom of a bug.