Governance#

Overview#

In Ergo, many network parameters are adjustable through a decentralized voting mechanism among miners. Such parameters include computational costs, block size limits, and storage fees. The long-term economic stability of the Ergo network is thus steered by miner consensus.

Miners can vote to change specific protocol parameters, as outlined in the table below. Soft-forking changes, requiring 90% miner support, can also alter many aspects of Ergo, barring critical elements like maximum supply.

Voting Cycles and Types of Changes#

Votes on foundational changes, such as block version, span 32 epochs and demand a 90% miner consensus. Everyday changes, like block size adjustments, require only a simple majority. Each block allows miners to cast votes for up to two everyday changes and one foundational change. These votes are included in the block's header.

Voting Mechanics#

Affirmative Votes#

To vote "Yes" for a change at the beginning of an epoch, a miner places the change's identifier directly into the block header.

Negative or Neutral Votes#

To vote "No" or abstain, a miner enters a zero value in place of the identifier byte in the block header.

System Constants#

Epoch length for voting: 1024 blocks
Epochs needed for foundational change: 32
Epochs before activating approved foundational change: 128

Current Network Settings#

Maximum block size: 1271009 bytes
Maximum box size: 4096 bytes
Maximum transaction size: 96kb

Parameters Table#

The following table describes vote identifiers, default values (during launch), possible steps, and minimum and maximum values.

If the step is not defined in the table, its value is defined as \(\max(\lfloor current\_value / 100 \rfloor, 1)\).
If the minimum value for a parameter is not defined, it equals zero.
If the maximum value is not defined, it equals 1,073,741,823.

A miner includes a parameter identifier (\(id\)) into the block header to propose or vote for increasing a parameter.

If the miner supports decreasing the parameter, they would include (\(-id\)) into the block header.

Try out these parameters on deadit.github.io/paizo/

ID	Description	Default	Step	Min	Max
1	Storage fee factor (per byte storage period)	1250000	25000	0	2500000
2	Minimum monetary value of a box	360	10	0	10000
3	Maximum block size	524288		16384
4	Maximum cummulative computational cost of a block	1000000		16384
5	Token access cost	100
6	Cost per one transaction input	2000
7	Cost per one data input	100
8	Cost per one transaction output	100
120	Soft-fork (increasing version of a block)

Parameter values are to be written into the extension section on the first block of a voting epoch, that is, in the extension of a block when its \(height\,mod\,1024 = 0\).

Parameters for the initial moment of time~\((height = 1)\) are hardcoded.

How to Propose and Vote for Changes#

To propose a change, a miner includes the vote identifier in the first block's header of a voting epoch. The header has three slots: two for everyday changes and one for soft forks. A zero should be set in any unoccupied slot. Votes can be arranged in any sequence.

For example, if a miner proposes to increase the storage fee factor and also initiate a soft-fork, they would input `(0, 1, 120) in the header slots.

Soft-Fork Mechanism in Ergo#

Soft forks allow for protocol updates that can introduce new rules or deactivate existing ones. The decision to implement a soft fork is made through a carefully designed voting process that involves miners and lasts 32 epochs. This article aims to explain the steps involved in implementing a soft fork, the rules surrounding it, and how the process unfolds.

Preconditions for a Soft Fork#

Software Update: A protocol developer releases an updated version of the software that could alter existing rules or introduce new ones.
Proposal: A miner flags the beginning of a soft-fork voting process by including a specific identifier (e.g., 120) in the first block of a new epoch.

Voting Process#

Duration: The voting phase spans 32 epochs.
Threshold: For a soft fork to be approved, it must garner at least 90% of the votes, which equates to at least 29,491 votes out of a possible 32,768 (32 epochs * 1024 blocks per epoch).
Negative Outcome: If the proposal fails to meet the 90% threshold, new proposals can be initiated in the following epoch.
Positive Outcome: If approved, an activation period of 32 epochs begins.

Activation and Implementation#

Activation Period: Following a successful vote, the network enters an activation phase lasting 32 epochs.
Activation Height: The first block after the activation period is termed the 'activation height.'
Block Versioning: The block version in the extension sections will increase from the first block of the activation period. The protocol version in headers will be updated at the activation height.

Technical Details#

To initiate a soft fork vote, a miner includes the identifier 120 in the first block of the epoch, denoted by height \(h_s\).
In the subsequent epoch, miners include the start height (\(122: h_s\)) and the votes collected in prior epochs (\(121: v_s\)) in the extension section of their blocks.

Examples#

Starting a Vote: Assume a vote is proposed in block #1024 by writing "120" into the extension. In that epoch, it gathers 500 votes. The next block, #2048, should include the pair \(122: 1024\) and \(121: 500\).
Counting Votes: If the new epoch starting at block #2048 gathers 600 additional votes, the next miner at block #3072 should include the pairs \(121: 1100\) and \(122: 1024\).
Vote Outcome: If the vote is unsuccessful, failing to gather more than 29,491 votes between blocks #1024 and #33791, the parameters are reset at block #34816. New voting can start in that epoch.
Vote Success and Activation: If the vote is successful, the activation period starts immediately at block #33792, lasting for 32 epochs. Voting for a new soft fork during this time is prohibited. Protocol versions are updated at the activation height.

For more practical examples, refer to this ergoforum post.