Capitalisk feature overview: Multi-genesis
One of the unique features of Capitalisk which is not mentioned in the whitepaper is that it allows nodes in the network to start off from different genesis states — This allows each node to independently decide when to delete/prune old data without falling out of consensus with the rest of the network and without compromising the ability of other nodes to sync/catch up with the network. This feature is intended to make the blockchain (and all blockchains based on the ldpos-chain module) sustainable in the long term without requiring code changes or centralized, coordinated re-genesis events.
To understand why this feature is useful, we have to consider that transactions which are being created today may not be relevant to the majority of participants many years from now — For example, in 50 years, it wouldn’t make sense to force all new participants to sync their nodes with 50 years’ worth of ancient data. With Capitalisk’s multi-genesis feature, they won’t have to. Capitalisk allows its nodes to migrate to new genesis heights with limited coordination required — Ideally, a sufficient number of network participants should agree on the same genesis height but the timing of each migration doesn’t matter; each participant can migrate in their own time. Individual nodes can also drop support for old geneses in their own time.
When syncing with the network, a node will only request data from other nodes which support a genesis height that is less than or equal to their own minimum supported genesis height. This feature is achieved thanks to a P2P routing feature provided by the lisk-p2p module combined with the leasehold-interchain plugin.
In terms of incentives, nodes which have a longer history (support an older genesis height) are able to sync against a larger percentage of existing nodes in the network and so there is a natural incentive for nodes to hold onto as much history as possible (it provides better availability guarantees; especially if a new genesis height is not sufficiently popular yet). The downside of holding onto more history is that it requires more disk space and increases the sync time for new nodes; so as the amount of disk usage (and total sync time) goes up, it puts pressure on network participants to update their config files to define new genesis heights/milestones. As more new nodes start migrating to the new genesis height, it becomes increasingly viable for nodes to start dropping support for the earlier genesis height and to start to delete/prune old data. The benefit of this approach is that the transition to new genesis heights can be done gradually instead of all at once — And no code changes are necessary.
It’s likely (at least in the foreseeable future) that there will always be some percentage of nodes in the network which will hold onto the full history of the blockchain since the beginning of time and this means that anyone will still be able to sync with the entire blockchain from the beginning if they really want to — But it’s not going to be necessary in order to participate in the network.
