Author: Matt Corallo 2021-09-10 00:50:08
Published on: 2021-09-10T00:50:08+00:00
A proposal has been made to allow reorgs on SigNet, and feedback is being sought on the approach and parameters. One proposal is to use a version bit flag for blocks that won't end up in the most work chain, which users can choose to opt-out of if they wish to remain unaffected. Node operators could choose not to accept these blocks via a configuration argument. However, some argue that this is more complicated than simply having a different reorg signing key. The frequency of reorgs is also being discussed, with arguments for both frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The proposal suggests that the depth of reorgs should be deterministically random between a minimum and maximum, based on the block hash or nonce of the last block before the reorg. Two scenarios have been proposed for testing reorg handling: a race between two chains with different flags set, and a chain rollback scenario where miners invalidate a block and start mining on it again without the flag. Questions are being asked about how often reorgs should happen on default SigNet, how deep they should be on average, and how engineers currently test their applications' reorg handling. Overall, 6 confirmations is suggested as the standard confirmation window for mainnet, even though it may be too low for testing purposes.
Updated on: 2023-05-21T03:36:50.648296+00:00