Closed vicsn closed 5 months ago
I suspect if a restriction is added retroactively (on block ranges that have already been added to the ledger), it will corrupt the mappings for newly syncing nodes and result in a desync between those and currently synced nodes.
Caution indeed advised! But the above scenario is not possible because the node with updated list will not connect and sync blocks from nodes with other lists: https://github.com/AleoNet/snarkOS/pull/3306
But the above scenario is not possible because the node with updated list will not connect and sync blocks from nodes with other lists: AleoNet/snarkOS#3306
Thank you for explaining @Meshiest . Indeed that sounds like a serious UX issue.
To further my own understanding and documentation: given that validators frequently lag multiple blocks behind one another even in a healthy network, with the current design "social consensus" would have to enforce restrictions at least 10 blocks into the future when any network restart happens which updates the restrictions list. Enforcing such a delay in code is not possible because a validator can't know independently if its behind tip or not, especially because other validators might have already been switched off for the restart.
Approved under duress. I don't like allowing features which have not been tested. To me, If it doesn't have a test, it doesn't work.
Working on testing in canarynet now, per discussion with @damons
Motivation
Mirror of: https://github.com/ProvableHQ/snarkVM/pull/15 Passed review and CI.