A re-org limit in this proposal means an agreed upon number of blocks after which nodes will not switch over to a new chain. For example, if the re-org limit is 10 blocks and a node reaches block 100, that node will never change blocks previous to sequence 90. Blocks <= 90 are ‘locked in’. A hash-based checkpoint in this proposal means a block height with a hardcoded block hash. For example the block hash at height 100 must be
b42... Any other blocks at sequence 100 would be invalid.
Iron Fish currently has no concept of re-org limits or checkpoints but they have a number of advantages. Primarily they provide further guards against large 51% attacks. If a miner attempts a 51% attack that reorganizes to a chain further back than the re-org limit the 51% attack will fail.
With the upcoming switch to FishHash, mitigating 51% re-org attacks is of particular priority because there will be a large decrease in network difficulty at the hardfork. The FishHash algorithm produces considerably less difficulty blocks than blake3 because its a much slower algorithm. Consider the following situation:
- FishHash activates at block 100
- 100 FishHash blocks are mined at much lower total difficulty than blake3 blocks
- The total difficulty of the longest chain is now 100b + 100f, b being the average blake3 difficulty and f being the average FishHash difficulty
- A bad actor re-mines a blake3 block 100 at a higher difficulty such that the difficulty different between block 100 and block 100’ is greater than 100f. This is possible because the FishHash average difficulty is much lower than the blake3 average difficulty
- The bad actor can initiate a large re-org with very little hashpower
Without a re-org limit this attack could be viable for a very long period and indeterminate of time (until the FishHash blocks difficulty exceeds what reasonably could be overcome with blake3 hash power).
With a re-org limit however this attack would only be viable up to sequence
HARD_FORK_SEQUENCE + RE_ORG_LIMIT. Additionally at this point a hash-based checkpoint could be adopted for the first FishHash block to further solidify the canonical chain.
The downsides of a re-org limit are directly related to how large the limit is. If the re-org limit is say 10 blocks (~10 mins) then a network interruption of only 10 minutes could cause the network to split and be in an irrecoverable state. If the re-org limit is 1500 block (~1 day) its much less likely that a network disruption would last that long. The key is to add a sensible limit that balances a potential network split with a counteracting a potential 51% attack.
With the switch over to FishHash there is also some nuance around the block limit. With the difficulty adjustment it could take a while for the first few FishHash blocks to be mined. So 10 blocks could correspond to much more than 10 minutes (possibly hours). So choosing this re-org limit must take that into account as well.
The re-org limit could be coded into the consensus parameters of the network (hard limit), or it could be set as a config value for node runners to change if they wanted to (soft limit)
The benefit of a hard limit is that users will know that the network as a whole will not change at a certain block height. If a user has a transaction at that block height they can be very confident that it will never change. With a soft limit users do not know what other node operators have set their limits to. So there is no overall assurance at a network level.
The benefit of a soft limit is that it can be changed to either counteract a network split or allow specific users to change their tolerance to a re-org. Although again, setting a stricter soft limit does not give a network-level guarantee.
- adding a hard re-org limit with a default value of 3000 blocks (~2 days).
- add logic for both hard limit and soft limit hash-based checkpoints. Once users are reasonably sure of the first FishHash block they can manually add that block hash to the list of soft limit hash-based checkpoints stored in the node’s config. On the next release of IronFish, a hard limit with that block hash will also be added to the consensus parameters.
The hard re-org limit of 2 days is a very conservative number. It is meant as a fallback to finalize the hardfork if node runners don’t update their nodes with the hash-based checkpoints. Its also meant to limit the future impact of 51% attacks without having to periodically adopt more hash-based checkpoints. More aggressive finalization can happen manually with the soft hash-based checkpoint. This will allow FishHash block to quickly finalize with important node runners like mining pools, exchanges and block explorer nodes so that users can start sending transactions on the network again.