Voting system #540
Voting system #540
Conversation
papers/yellow/voting.tex
Outdated
| If minimum value for parameter is not defined, it equals to zero. If maximum value is not defined, it equals to | ||
| 1,073,741,823. | ||
|
|
||
| All the monetary values in the table (storage fee factor, minimum box value) are in nanoErgs. All the sizes (block etc) |
There was a problem hiding this comment.
It is better to include Units in the table, when table will be bigger, it will be hard to read.
Also looks like that minimum box value and storage fee factor are in nanoErg/byte, not in nanoErg.
papers/yellow/voting.tex
Outdated
| \begin{tabular}{*{6}{l}} | ||
| Id & Description & Default & Step & Min & Max \\ | ||
| \hline | ||
| 1 & Storage fee factor (per byte per storage period) & 1250000 & 25000 & 0 & 5000000 \\ |
There was a problem hiding this comment.
Why 5000000 instead of previously discussed 2500000?
papers/yellow/voting.tex
Outdated
| Id & Description & Default & Step & Min & Max \\ | ||
| \hline | ||
| 1 & Storage fee factor (per byte per storage period) & 1250000 & 25000 & 0 & 5000000 \\ | ||
| 2 & Minimum monetary value of a box & 360 & 10 & 0 & 10000000 \\ |
There was a problem hiding this comment.
With step 10 maximum value will be achieved in 3896 years (if it will be increased every epoch).
I propose to remove limits, or set some realistic limit that can be achieved in several years, 10000000 does not make sense.
There was a problem hiding this comment.
Reduced by the factor of 1,000.
papers/yellow/voting.tex
Outdated
| 1 & Storage fee factor (per byte per storage period) & 1250000 & 25000 & 0 & 5000000 \\ | ||
| 2 & Minimum monetary value of a box & 360 & 10 & 0 & 10000000 \\ | ||
| 3 & Maximum block size & 524288 & - & - & - \\ | ||
| 4 & Maximum cumulative computational cost of a block & 1000000 & - & - & - \\ |
There was a problem hiding this comment.
I think it's better to add a minimal value here (and to block size), that will allow to include at least transaction that collects emission.
src/main/resources/application.conf
Outdated
| epochLength = 256 | ||
|
|
||
| # Length of an epoch in difficulty recalculation. 1 means difficulty recalculation every block |
There was a problem hiding this comment.
it is not Length of an epoch in difficulty recalculation
src/main/resources/application.conf
Outdated
| @@ -105,6 +114,10 @@ ergo { | |||
| # So we check from a queue only one box per "scanningInterval". | |||
| scanningInterval = 1s | |||
| } | |||
|
|
|||
| voting { | |||
| 1 = 2000000 | |||
There was a problem hiding this comment.
Let's specify all parameters (with comments, describing what does they mean) here and set them to default values first,
There was a problem hiding this comment.
Then a node will vote automatically to always adjust back to default values, which is not appropriate behavior.
| case class InfoRoute(statsCollector: ActorRef, | ||
| settings: RESTApiSettings, | ||
| timeProvider: NetworkTimeProvider) | ||
| (implicit val context: ActorRefFactory) extends ErgoBaseApiRoute { | ||
| override val route: Route = withCors { | ||
| info | ||
| info ~ params |
There was a problem hiding this comment.
Our previous API routes had the same prefix for all paths. Adding params here looks inconsistent, we may add common prefix for info and params or move params route to a separate class
There was a problem hiding this comment.
Fixed somehow: now parameters are under /info resulting object.
src/main/scala/org/ergoplatform/modifiers/history/Extension.scala
Outdated
Show resolved
Hide resolved
| @@ -28,6 +28,7 @@ import scala.util.Try | |||
| * bytes value size. | |||
| */ | |||
| case class Extension(headerId: ModifierId, | |||
| height: Int, | |||
There was a problem hiding this comment.
We already have height in Header, why to duplicate it here? I think we should only one height field, Header looks better option for it.
Also this change should be included in class comments and in openapi.yaml (but I propose to remove height from here).
Update sigmastate (Height is Int)
update sigma
Read sigmastate version from environment variable
Review comment fixes
Many parameters can be changed on-the-fly via miners voting, namely 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 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.