Radix Foundation Protocol Update Candidate Policies

A core part of the Radix Foundation’s mission is to support continuous development of proposed updates and improvements to the Radix Network protocol and tools. It does this in two ways: through funding development work at RDX Works, and by open sourcing and publishing that code for the rest of the Radix community through its subsidiary Radix Publishing.

Any update to the Radix Network protocol that Radix Publishing may propose will only come into effect if adopted by the decentralized community of validator node runners. To provide an orderly process of adopting such updates, the protocol itself includes a mechanism called “coordinated protocol updates”. With this mechanism, validators can choose to run a new node and signal their readiness to adopt a protocol update candidate (PUC) that is embodied in that node. When a sufficient threshold of validators have signaled their readiness, the mechanism ensures a coordinated and simultaneous update.

The Radix Foundation is keenly aware of the fact that the Radix community looks to it to provide well-considered and professionally-built protocol update proposals. To live up to this expectation, it wishes to commit to a set of public policies for how PUCs are published for discussion and proposed for coordinated adoption.

These policies cover the timing and thresholds configured for PUCs proposed by Radix Publishing. They are intended to ensure updates can be adopted in a timely fashion to maintain a competitive pace of network development and security – while also ensuring that developers, business owners, and node runners have sufficient time to discuss, provide feedback, and prepare themselves for updates to the network.

The Radix Network protocol is complex and so there are many kinds of PUC with different levels of urgency and impact. Different policies are proposed for these different kinds of PUC to fit with their respective urgency and impact.

PUC Adoption Process

Before getting to the Foundation’s policies, it is important to understand how the PUC system works, and the parameters that define how signaling and adoption happen.

For each type of PUC, the process of adoption can be broken into three parts:

Announcement of the PUC to the community, with a description of its intended contents.
Publication of the PUC itself in a new Radix Network node version. Signaling by validators can begin.
Enactment of the PUC on the Radix Network as the new protocol version once one of the defined signaling thresholds has been met and maintained for the configured time period.

Here are the three parts in more detail.

Announcement

First, a description of the PUC is published. This is not part of the PUC or the “coordinated protocol update” system on the network. It is a description of the PUC intended to provide enough time for the community to flag any significant or urgent concerns that might cause a postponement to the publication of the PUC.

Announcements will be done on the official Radix Discord server #node-runner-announcements channel.

Proposal

Next, the PUC is published as part of a new node, beginning the on-network process.

Validators may immediately download and run the new node to be ready for the potential network update. They may then choose to submit a signal of their support for the network to adopt that update.

The PUC includes a set of parameters that the protocol uses to define how and when validator signals are evaluated and when the PUC should be enacted once it has sufficient support. These parameters are:

requiredStake / numEpochsBeforeEnacted

A given PUC may have one or more of this pair of parameters. Each pair effectively describes a signaling threshold that defines when a PUC has sufficient support to be enacted. The possibility of multiple pairs of these parameters mean that there may be more than one threshold, any of which allow enactment.

To meet a given threshold, the sum of stake represented by the validators that have signaled support must meet the requiredStake. Then that level of support must be maintained continuously for numEpochsBeforeEnacted. This means that once the requiredStake has been met, the numEpochsBeforeEnacted provides a period of time where validators are aware of the likely time of enactment.

minEpoch / maxEpoch

This pair of parameters determine the time bounds during which enactment can happen, using the Radix Network’s “epoch time”. Regardless of validator signaling, enactment cannot happen before minEpoch, and cannot happen after maxEpoch.

Enactment

If a signaling threshold (represented by a requiredStake / numEpochsBeforeEnacted pair) has been reached at an epoch change – and if the current epoch is between minEpoch and maxEpoch – the PUC is automatically enacted across all validators running the new node, and it becomes the new protocol of the Radix Network.

The process can be visualized like this:

(This assumes that minEpoch is always set to the time the PUC is published, which is typically how it will be used.)

Once a PUC is enacted, all validators running the new node version – including those that did not signal support – will automatically begin validating using that new version. Validators that did not install the new node version will no longer be able to make proposals and validate and the network will effectively consider them “offline”.

While PUC parameters will be chosen to give validators an appropriate amount of time to be ready, the protocol’s “liveness jailing” feature will ensure that once a PUC has been enacted, remaining validators that have not updated will not slow down the network. They will simply be removed from the validator set until they update and are ready to validate once again. More on the timing of “liveness jailing” is below.

The Radix Foundation's policies for PUCs can be described in terms of the durations of time for Announcement and Proposal it commits to respect for different types of PUC.

PUC Types

Protocol updates can be classified in three broad categories of different PUC types:

Network economics updates

Standard fee & emissions update - An update to either change the current network USD:XRD rate used to calculate network fees (and, if chosen by the developer, USD-based royalty fees) based on substantial market price movement, or to re-calibrate the network's rate of XRD emissions based on real average epoch time. Proposal of these updates are triggered according to an existing policy of tracking market price movement. In short, these should be predictable updates to keep fees and emissions within predictable bounds.
Fee table modification - An update to adjust the network’s table that defines the incremental cost of various on-ledger operations and storage. The aim is to tune the cost of these fees to be commensurate with their burden on validator node-runners in transaction processing such that transaction submitters adequately pay for the network service they enjoy.

Network bug fix updates

Critical bug fix - An update to address a bug that poses a risk to the orderly and correct operation of the network. The update is urgent, and is expected to be widely supported. This policy would however apply to publicly known bugs that must be fixed right away. See the exception below for bugs that are not yet publicly known.
Non-critical bug fix - An update to address a bug that does not post a risk to the orderly and correct operation of the network, but nonetheless should be addressed. Again, this is expected to be widely supported, but less urgent.

Network feature updates

Additive feature release - An update to add new functionality to the network, Radix Engine, or Scrypto. The update does not change existing behavior and so while developers will want to be aware, it poses a low risk.
Modifying feature release -An update that modifies existing functionality of the network, Radix Engine, or Scrypto. This is of course expected to be of keen interest to developers and so requires ample time for discussion and preparation.

When choosing announcement period and PUC parameters to be used for each of these types, the Radix Foundation has considered both the urgency to the network that an update be enacted, as well as the impact to stakeholders of the network like developers and validators.

Impact drives the selection of the PUC announcement period of the PUC.

A PUC with broader impact to stakeholders is set with a longer announcement period (up to 28 days). This is to ensure that stakeholders can identify any issues of concern with the PUC before it is published, providing time to reconsider if it should in fact be published, as well as provide appropriate time for community deliberation before the period of signaling support begins.

Urgency drives selection of the requiredStake / numEpochsBeforeEnacted threshold(s). A PUC of higher urgency to the smooth, reliable operation of the network will have a 95% requiredStake threshold that allows for quick enactment (including potentially no delay at all). A 75% requiredStake threshold allows for enactment with a longer delay if a minimum, but safe, majority (well above the 66.6% BFT level) of validators are in support.

A PUC with less network urgency can safely have a longer numEpochsBeforeEnacted to ensure the maximum number of validators are ready for the update, and even have only a 95% requiredStake threshold, dropping the additional fallback 75% threshold.

‍

If updates of different types are combined into one PUC, as may often occur for larger updates, the policy for the type with the longer time periods will be used.

There is one important exception to this policy: if a critical bug is discovered and is not publicly known, the fix may be silently combined with an unrelated PUC to avoid making potential attackers aware of it before it is fixed. In this circumstance, the bug fix will be announced after the PUC fixing it has been enacted.

Summary of PUC Policies

Here is a summary of the Radix Foundation's policies for PUC proposals.

Implementation of Policies

The Radix Foundation will adopt the minimum announcement period policies for all PUC types right away.

Adoption of the full PUC threshold policies must wait until the addition of a coming feature for the Radix Network: liveness jailing.

Liveness jailing is a mechanism that will allow the Radix Network to automatically remove offline validators from the validator set for a time to avoid network slow-down or risk of a liveness break. With that mechanism in place, the requiredStake thresholds may be chosen to focus mostly on giving validators sufficient time to update their node and avoid appearing offline and being "jailed" after the update. Even if a lazy validator with significant stake fails to be ready for an update, liveness jailing will greatly mitigate any resulting network slowdown.

Until liveness jailing is available, any proposed PUCs must have thresholds chosen more conservatively, and so updates will generally be adopted more slowly.

Further reading:

‍