-
Notifications
You must be signed in to change notification settings - Fork 170
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
108 changed files
with
2,037 additions
and
869 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ branches: | |
| - v2.0 | ||
| - master | ||
| - /^\d\.\d+$/ | ||
| - height-as-int | ||
| jdk: | ||
| - oraclejdk9 | ||
| scala: | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,21 +1,78 @@ | ||
| Subjects to voting are instructions costs, computational cost limit, block size limit, | ||
| and the block version. Voting for the block version lasts for 16 epochs, and requires | ||
| 90 percent of the miners to vote for the change. | ||
|
|
||
| All other kinds of voting are organized in the following way. A miner who | ||
| successfully generates the first block in the epoch initiates the voting over one | ||
| of the parameters, stating explicitly whether a value of the parameter should be | ||
| decreased~(except the case when the current value is below $min\_step$) or increased from miner's | ||
| point of view. | ||
|
|
||
| The value of the change is predefined as $\max(\lceil0.01 \times current\_value\rceil, min\_step)$ with $min\_step$ | ||
| being the hard-coded value. The voting lasts for one epoch. Every miner | ||
| submitting the block during this epoch has two options: accept or reject the | ||
| proposal. Miner's vote must be written in the generated block. Change in the | ||
| value requires the majority of votes over the epoch. Every block contains the | ||
| vote of the miner who generated it. In case the proposal fails, the parameters | ||
| remain unchanged. | ||
|
|
||
| \knote{Foundation wallet address change via 90 percent voting?} | ||
|
|
||
| \knote{Foundation tax change after first years?} | ||
| \section{Voting} | ||
|
|
||
| Many parameters can be changed on-the-fly via miners voting, such as instruction costs, computational cost limit per block, | ||
| block size limit, storage fee factor, block version, and so on. Voting for the block version~(so for a soft-fork) | ||
| lasts for 32 epochs~(see epoch length below), and requires more than 90 percent of the miners to vote for the change. | ||
| For less critical changes~(such as block size limit), simple majority is enough. We will further refer to the changes | ||
| of the first kind as to foundational changes, we call the changes of the second kind as to everyday changes. | ||
| Per block, a miner can vote for two everyday changes and also one foundational change. | ||
|
|
||
| To vote "Yes"~("I'm agree on the change proposed"), a miner is publishing identifier of the change directly in a | ||
| block header. To vote "No" (or avoid voting at all, which is the same), a miner is simply writing zero value instead of | ||
| a corresponding byte (another option is to provide a vote identifier which is not being considered within the epoch). | ||
| To initialize a voting procedure, a miner is publishing change identifier in a first block of an epoch. | ||
|
|
||
| System constants: | ||
| \begin{itemize} | ||
| \item{} Voting epoch length = 1024 blocks. | ||
| \item{} Voting epochs per foundational change = 32 | ||
| \item{} Voting epochs before approved foundational change activation = 128 | ||
| \end{itemize} | ||
|
|
||
| \subsection{Parameters table} | ||
| \label{sec:params-table} | ||
|
|
||
| The following table describes vote identifiers, default value (during launch), possible step, minimum and maximum values. | ||
| If the step is not defined in the table, its value is defined as $\max(\lceil0.01 \times current\_value\rceil, 1)$. | ||
| If minimum value for a parameter is not defined, it equals to zero. If maximum value is not defined, it equals to | ||
| 1,073,741,823. | ||
|
|
||
| To propose or vote for increasing a parameter, a miner is inluding a parameter identifier ($id$) into a blockheader. | ||
| If miner is for decreasing parameter, the miner is including ($-id$) into a block header. | ||
|
|
||
| \begin{tabular}{| l | l | l | l | l | l |} | ||
| \hline | ||
| Id & Description & Default & Step & Min & Max \\ | ||
| \hline | ||
| \hline | ||
| 1 & Storage fee factor & 1250000 & 25000 & 0 & 5000000 \\ | ||
| & (in nanoErgs per byte per storage period) & & & & \\ | ||
| \hline | ||
| 2 & Minimum monetary value of a box (in nanoErgs) & 360 & 10 & 0 & 10000 \\ | ||
| \hline | ||
| 3 & Maximum block size & 524288 & - & 16384 & - \\ | ||
| \hline | ||
| 4 & Maximum cumulative computational cost of a block & 1000000 & - & 16384 & - \\ | ||
| \hline | ||
| \end{tabular} | ||
|
|
||
| Parameter values are to be written into extension section on first block of a voting epoch, that is, in the extension | ||
| of a block when its $height\,mod\,1024 = 0 \land height > 0$. Parameters for initial moment of time~$(height = 0)$ are simply | ||
| hardcoded. It is prohibited to start voting on $height = 0$. | ||
|
|
||
| \subsection{Proposing a change and voting for it} | ||
|
|
||
| To propose a change, in the first block of a voting epoch (of $1,024$ blocks, so in a block of | ||
| $height\,mod\,1024 = 0 \land height > 0$), a miner is posting vote for a change. There are three slots (three bytes) | ||
| in a block header for changes to propose, with two slots for everyday chanegs and third one to propose a softfork. Slot | ||
| not occuppied by a proposal is to be set to zero. Votes could come in any order. Examples of the bytes: | ||
| $(0, 1, 120)$, $(0, -3, 120)$. In the first case, a miner is proposing to increase storage fee factor ($id:1$), and | ||
| also proposes a soft-fork ($id:120$), In the second case, a miner is proposing to decrease block size ($id:-3$), and also | ||
| is proposing a soft-fork ($id:120$). | ||
|
|
||
| To vote for a proposal~(proposed in the first block of an epoch) within the epoch, a miner is including vote identifier | ||
| into the block header. Identifiers not proposed in the first block of the epoch are ignored. | ||
|
|
||
| If majority of votes within an epoch are supporting an everyday change (so at least 513 blocks are containing an | ||
| identifier), a new value of the parameter should be written into the extension section of the first block of the next | ||
| epoch. | ||
|
|
||
| \subsection{Voting for a soft-fork} | ||
|
|
||
| Soft-fork is when a protocol version supported by the network is being increased. This version is written in a block | ||
| header. | ||
|
|
||
| To start voting for a soft-fork, a miner needs to publish identifier $120$ in the first block of the epoch, consider, | ||
| for example, that its height is $h_s$. Next epoch, a miner should post height when start fork was proposed ($122: h_s$) | ||
| in the extension section of the block, and number of votes collected in the previous epochs $v_s$ should be written | ||
| there as well as $(121, v_s)$. |
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.