Update proposals
Last updated
Last updated
Currently, and until the release of the Voltaire era (decentralized governance), Cardano operates under a federated governance mechanism that allows updating protocol parameters, including the addition of new features. These updates are carried out through an update proposal process. Only the holders of the genesis delegate keys have the authority to submit and vote on proposals.
Cardano has transitioned through different ledger eras: Byron, Shelley, Allegra, Mary, Alonzo, and the current era, Babbage. Each of these eras has brought forth a new set of functionalities, and there are more eras planned for the future, each introducing additional functionalities.
| Era | Key features | Consensus | Protocol versions (major/minor) | Hard fork event |
|---|---|---|---|---|
Byron | Proof of stake | Ouroboros Classic PBFT | 0.0 1.0 | Genesis Byron reboot |
Shelley | Decentralized block production Rewards | TPraos | 2.0 | Shelley |
Allegra | Token locking | TPraos | 3.0 | Allegra |
Mary | Native tokens | TPraos | 4.0 | Mary |
Alonzo | Plutus smart contracts | TPraos | 5.0 6.0 | Alonzo |
Babbage | Plutus v2 Reference inputs Inline datums Reference scripts Removal of d parameter | Praos | 7.0 8.0 | Vasil Valentine (secp) |
Transitioning from one era to the next is triggered by an update proposal that updates the protocol version.
The general mechanism for updating protocol parameters in Byron is as follows:
Update proposal is registered. An update proposal starts with a transaction that proposes new values for some protocol parameters or a new protocol version. This kind of transaction can only be initiated by a genesis key via its delegate.
Accumulating votes. Genesis key delegates vote for or against the proposal. The proposal must accumulate a sufficient number of votes before it can be confirmed. The threshold is determined by the minThd field of the softforkRule protocol parameter.
Confirmed (enough votes). The system records the 'SlotNo' of the slot in which the required threshold of votes was met. At this point, 2k slots (two times the security parameter k) need to pass before the update is stably confirmed and can be endorsed. Endorsements for proposals that are not yet stably confirmed are not invalid but rather silently ignored.
Stably-confirmed. The last required vote is 2k slots deep. Ready to accumulate endorsements. A block whose header's protocol version number is that of the proposal is interpreted as an endorsement. In other words, the nodes are ready for the upgrade. Once the number of endorsers satisfies a threshold (same as for voting), the confirmed proposal becomes a candidate proposal.
Candidate. Enough nodes have endorsed the proposal. At this point, a further 2k slots need to pass before the update becomes a stable candidate and can be adopted.
Stable candidate. The last required endorsement is 2k slots deep.
If there is no stable candidate proposal, then no changes occur. Everything is retained, including a candidate proposal whose threshold-satisfying endorsement was not yet stable and will be adopted in the subsequent epoch unless it gets surpassed in the meantime.
A 'null' update proposal is one that neither increases the protocol version nor the software version. Such update proposals are considered invalid according to the Byron specification.
The update mechanism in Shelley is simpler than in Byron. There is no distinction between votes and proposals. To 'vote' for a proposal, a genesis delegate submits the exact same proposal via a regular transaction signed by the delegate key. Additionally, there is no separate endorsement step:
The procedure is as follows:
Register the proposal. During each epoch, a genesis key can submit (via its delegates) zero, one, or many proposals; each submission overrides the previous one. Proposals can be explicitly marked for future epochs; in that case, they are simply not considered until that epoch is reached.
Voting. The window for submitting proposals ends 6k/f slots before the end of the epoch, where k is the security parameter and f is the active slot coefficient.
Quorum. At the end of the epoch, if the majority of nodes, determined by the Quorum specification constant (which must exceed half the total number of nodes), have most recently submitted the identical proposal, it becomes adopted.
Update. The update is applied at the epoch boundary.
Changing the values of the protocol parameters and global constants can be done via an update proposal.
Changing the values of the global constants always requires a software update, including an increase in the protocol version. An increase in the major version indicates a hard fork, while the minor version indicates a soft fork (meaning old software can validate but not produce new blocks).
On the other hand, updating protocol parameters can be done without a software update.
Until the Voltaire era is released, only the holders of the genesis delegate keys can submit and vote on proposals. From time to time, you will find it useful to deploy a local or private testnet. In that case, you will need to use the governance commands to upgrade your network to the desired era.
