Proposal: Genesis Upgrade and Adaptive Core

[HDauven]

Summary

This proposal outlines a standardized procedure for upgrading Dusk node software and genesis contracts. It introduces a dual-path upgrade mechanism, distinguishing between binary upgrades (software-level changes) and genesis contract migrations (on-chain logic changes). Furthermore, it differentiates between additive, non-breaking upgrades and breaking upgrades. It also leverages a named upgrade system similar to other networks.

Outline

Named upgrades

Use named upgrades (e.g., upgrade_name_block) in the chain configuration, each associated with a specific block height. The upgrade activates new code paths at the predetermined block height.

Upgrade activation and testing

Provide a mechanism (e.g., is_upgrade_name function) to determine if an upgrade should be applied based on the current block height. This makes it easy to test transition and behavioral changes across block heights.

Considerations

Binary upgrades vs. Genesis contract migrations

Binary upgrades: Refers to modifications of the node software. This can be changes to the APIs, consensus, networking or chain.

In the case of a contract migration or named upgrade, an updated binary is first provided. This updated binary is responsible for handling an upcoming genesis contract migration for a given block height.

Genesis contract migrations: Involves changes to the genesis contracts that encapsulate core functionality of the blockchain, like the transfer and stake contracts.

Migrations are triggered by a previously updated binary, and is triggered on a specific block height.

Non-breaking vs Breaking upgrades

Non-breaking upgrades: Additive enhancements or optimizations that do not alter existing contracts or break processing of past blocks that could lead to different state roots. These upgrades ensure backward compatibility, allowed the network to get new features without impacting existing or historical operations.

Breaking upgrades: Changes that modify contract interfaces or alter the network's operational logic in a way that is not backward compatible. Such upgrades require coordinated transitions, thorough testing and replayability of past state.

Gas limits

The contract migration process should complete within a single block. The gas cost for migrating a large contract should be considered and tested. It could be that constraints around gas limits should be suspended for a large contract, as well as timeouts.

This could be achieved by introducing a specific upgrade/migration block.

Transaction suspension

Prohibit the execution of other transactions during migration blocks to maintain focus and predictability during the migration process.

Metadata and state migration

During migration of genesis contracts, ensure the complete transfer of both metadata and state, detailing the mechanism for state transformation or migration where needed.

Planned upgrades

Schedule migrations sufficiently in advance to allow node operators to upgrade, ensuring a large enough portion of operators has upgraded and are in a synchronous state when the upgrade or migration block executes.

Dry-Run testing

Mandate a pre-migration dry run to validate the feasibility of a migration, and aborting early in case of failure.

Community involvement and feedback

Proposed upgrades should be provided as a DIP and discussed in the wider Dusk community. Input from multiple stakeholders should be considered.

[autholykos]

Wrt the genesis contract migration, I think that together with the dry-run we should also add:

• a grace period commencing after the target migration block is accepted. The reason for such a grace period would be to avoid any surprise in terms of how many Provisioners did update the binary and are ready to migrate. During such a grace period, we could also run predictions over the probability that applying the migration might cause an async network (i.e. time to produce blocks).
• a way to detect the loss of the super-majority in case the migration would go through, and a procedure to abstain from migrating in that case.

Apart from those points, we should also think of some sort of commitment to an update/migration before we propagate one (unless it is an urgent patch for a critical issue), so that if the supermajority of coins commits to a change (perhaps through a vote of the active Provisioners?), we would have ground to slash those that don't follow through

[HDauven]

Apart from those points, we should also think of some sort of commitment to an update/migration before we propagate one (unless it is an urgent patch for a critical issue), so that if the supermajority of coins commits to a change (perhaps through a vote of the active Provisioners?), we would have ground to slash those that don't follow through

Flagging in favor of the upgrade, and making it available on the info endpoint would be a great addition.