Update Erg Emission and Hardforks Policy

Community High-Level Discussions
1

I strongly believe that a new Policy regarding forks and emissions must be adopted. While the previous “Hardforking Policy” text from 2019 is referencing Hardforks (After-Launch Thoughts and Ergo Roadmap | Ergo), this needs to be made clear with us now exploring re-targeting of emissions.

Below is the rough example I wrote to show what I mean. Please critique and alter in anyway you see fit. Anything not in “quotes” describe my thought process and are not in my example Policy text.

I believe the policy should highlight Ergo’s long-term evolutionary design.

" Ergo’s Adaptability and Long-term
Survivability

•Ergo is a self-amendable decentralized network, where proposals can be introduced and changes approved via miner voting. Ergo is, by design, innovative and proactive, as opposed to stagnant and reactionary.
•While Ergo is focused on long term survivability, voting is structured to avoid network fragmentation stemming from unresolvable or outdated disputes.
Thus, voting requirements are limited and rather conservative in nature, requiring an overwhelming majority of miner support in a limited timeframe for approval: Voting for a softfork proposal lasts for 32 epochs (32,768 blocks ~ 46 days) and 90+% of node support is needed to activate the protocol upgrade."

The policy should also highlight Ergo’s stance towards Hardforks and clearly define what cannot be changed via soft forks. Some may know that soft forks don’t change original contract, but many do not and this needs to be made clear. More defining of re-emissions are needed imo & I again would like everyone’s critique and help here.

"Hardforks and Tokenomics Policy

•Hardforks are considered by Ergo to be unnecessarily disruptive, and even potentially harmful to the network and community. Hardforks are difficult and can lead to unforseen outcomes. This is why Ergo was designed to change and adapt overtime via painless soft/velvet-forks.

•What CAN be changed via soft/velvet-forks-

Block size, block time, network fees (transaction and storage rent), distribution of block rewards to miners securing the network, *+others I can’t think of…?

•What CANNOT be changed via softforks-

Total supply (97,739,925 erg)
Treasury allocation (4.43% erg total supply)
+More I can’t think of…?

•These basics of Ergo’s tokenomics must remain unaltered, as Ergo will never change or be dishonest about Erg supply. Changes made, or lies told to benefit current erg holders/team will NEVER be made at the expense of past buyers/team. Altering total Erg supply is not possible, as it would introduce unexpected inflation or deflation into the system and hurt the reputation of Ergo.
Anybody who says or does otherwise, E.g., an individual promoting a Hardfork to double total Erg supply is referencing a different project, and likely do not allign with Ergo’s core-values."

I love the ethos of this project and I’d hate to see FUD regarding past policies appear, when we have the chance to update these policies now. Also, my example policy helps educate on Ergo’s self-amendable nature. I enjoyed writing this but I know I’m too “wordy”, please contribute or if you think an updated policy isn’t needed, then simply say so! Thanks :blush:

Typo

7 Likes
2

I think this is much needed initiative indeed, as sometimes soft-forks can be not so soft in fact , or change a lot in the ecosystem.

I also think it can be good to have representatives from all the groups (users, miners, app developers) to discuss and vote on soft-forks (before miners voting takes place).

3 Likes
3

I think that it might be a good idea getting more opinions. Coming from a small miners perspective unless the price rises it could mean mining rewards could be less and push miners away to another chain. I really like ERGO so I’ll be mining it regardless and putting some GPU’s a side especially for ERGO mining because i would like to help secure the network.

Is there a way we could simulate some folking scenarios based on the data we currently have?.

2 Likes
4

And to be clear, I in no way expect my example text to be used. I just like to write & I like Ergo :sweat_smile:

My main point is the optics of re-targeting of emissions can, and will be spun in either a negative or a positive way.

Think of all the Ergo articles that mention “no long tail of emissions”, “8 year emissions schedule”, etc.

Although we may know that the original emissions contract is set in stone, the broader community needs to know this.

If we do this right Ergo’s brand image can improve, if we do this wrong it will not be pretty. Imagine the possible YouTube thumbnails and click bait titles. Especially on mining channels. :face_vomiting:

*Please move if high level discussions was wrong place to post this & thank you for the responses so far!

1 Like
5

I sometimes wonder if kushti is using Scorex to simulate & model possible changes.

I don’t know if that’s even possible to be honest but kushti is #1 contributor to Scorex, the “Modular blockchain framework” that Ergo was built with.

2 Likes
6

Wow, just wait until some grad student does a research project using Scorex. It’s so difficult to go from simulation to model precisely. ERG being designed using Scorex gives me confidence in this project.

1 Like
7

Okay to get back on track, let’s assume that EIP-0027 or similar EIP passes and a “re-emissions contract” is used to extend emissions schedule to some degree.

We need to, as a community, release a Policy regarding softforks, especially those that involve emission re-targeting.

Describing Ergo as Perpetual PoW with the natural ability to improve and evolve over time is great. But it just doesn’t mix well with older texts, like kushti’s Hardforking Policy from 2019 (specifically the bolded portion):

Blockquote

Hardforking policy

Ergo is trying to avoid hard-forks. Emission, proof-of-work, basics of transactional model and other core things should not be changed at all as any change about core parts of design means another chain. However, developers may propose hard-forks within first 12 months if (and only if):

  • a hard-fork is about security fixes only. The only exception is about making cost of particular instructions adjustable via miners voting, which was planned but not delivered in the current mainnet.
  • a hard-fork is supported by 90+% of miners.
  • a hard-fork is not breaking old contracts, freezing or moving any funds.

Blockquote

We have a (outdated) Hardforking policy, so we, at the minimum need a Softforking Policy. One that places limitations on changes that can be made via softfork, or simply describes the limitations already in place. Ideally, revising the Hardforking policy will be discussed as well.

TLDR; Extending emissions may be necessary, but we need a policy in place we can refer to when considering current & future softforks. Hardforking policy seems to contradict concept of Perpetual PoW.

2 Likes
8

Worth noting the above info in my example Policy text is incorrect.

Correction: There are two types of changes that can be implemented via miner voting.

First, are “everyday” changes (i.e., block size limit) which require only a simple majority (>50%) of YES votes to pass. The table below lists the everyday changes, each with specific limits.

Id & Description & Default & Step & Min & Max \\

1 & Storage fee factor (per byte per 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 cumulative 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 & - & - & - \\

Second, are “foundational” changes. Foundational changes are implemented via soft-fork and require an overwhelming majority (>90%) of YES votes to pass.

Implementing a foundational change increases the protocol version the network supports; EIP-0027 is a good example of this type of change.

Just wanted to clarify, hoping to minimize the unintended spread of false info. Check out Voting.tex from Yellow Paper to review what I’ve just shared, and to learn more detailed specifics regarding Ergo’s voting mechanism.

Any further corrections or info? PLEASE share :slight_smile:

Typo

1 Like