[Shipped] Automatically enable protocol update

Problems

Currently, in order to enable a new feature, we set a checkpoint and hope all nodes update its new code. There are two problems with this approach:

  1. When foundation nodes no longer hold majority slots in a committee, the chain may be stuck if ⅓ nodes in a committee don’t update new protocol.

  2. With backward-incompatible database changes, if a node runs old code, its database would be corrupted and required to resync from scratch with new code.

We’re proposing an approach that allows chains to enable a new feature if and only if majority nodes agree on that feature. In addition, outdated nodes might be aware of the newly enabled feature, then notify the node operators to update their nodes via system log.

Solution

Beacon proposers monitor the network, and when majority nodes run the new feature, the beacons will generate EnableFeature instruction, so that the new feature will be automatically enabled in the network. When an outdated node inserts a beacon block including the EnableFeature instruction, it will stop running and require the node operator to update new code.

Workflow

  • Each feature’s metadata will be configured in the config file, with a checkpoint and a threshold in percent of the number of nodes updated with the new feature’s code.

  • Validator nodes periodically broadcast metadata of its config file’s unenabled features to beacon nodes by sending a message called FeatureMsg.

  • Beacon nodes maintain a FeatureMsgPool and monitor the code update status (in %) of features from all validator nodes in committees and the Pending pool.

  • After checkpoint, if % of nodes updated a feature’s code > the unenabled feature’s threshold then the beacons would generate EnableFeature Instruction in the newly created beacon block.

  • The new EnableFeature instruction will enable the new feature in the current block.

  • A validator node that inserts the beacon block, does not recognize the new feature instruction (against its config file) will stop processing and require the node operator to update new code.

  • Nodes in the Sync pool will be required to send their latest FeatureMsg prior to joining the Pending pool.

Concrete example

Given configuration: “Feature1: 25,000, 90%”

This expresses that after block 25,000, if feature1 is not enabled and the number of updated nodes is greater than 90%, then the beacon would generate an EnableFeature instruction in a beacon block.

  • When shard chains confirm the beacon block, the feature will be enabled in the code flow of the shards’ nodes.
  • If a node does not recognize the feature name, the node would stop processing and require the node operator to update new code.

Conclusion

We are toward fixed node dominance reduction, which means foundation nodes won’t hold the majority of the network’s committees and leads to one requirement we need to address: how to keep the network stable while still actively releasing protocol updates for new features and improvements. Hope this proposal could help the protocol update process be safer.

Thank you.

11 Likes

Are nodes that do not recognize the new feature instruction slashed? Or is this a new state/cycle – Sync, Pending, Committee, Slash and now Stopped? Paused?

1 Like

When the network generate new feature, it means the majority of nodes is agreed and updated the new code. If your node is in the minority group that does not updated the code, then it will not participate in voting and will be slashed eventually.
There is not any new state, the node is required to stake again.

4 Likes