Block Rewards Threaten Ethereum's Entire Economic Model: Eric Conner

Happy Friday defiers! I’m introducing occasional outside columnist on The Defiant as a way to offer you different perspectives on decentralized finance, Ethereum, and smart contracts platforms, and today is the first one. My idea is to have guests that can...

Happy Friday defiers! I’m introducing occasional outside columnist on The Defiant as a way to offer you different perspectives on decentralized finance, Ethereum, and smart contracts platforms, and today is the first one. My idea is to have guests that can help us go deeper into the week’s most interesting developments.

This week’s discussion around raising block rewards in Ethereum to fund specific groups is worth further thought. EthHub co-founder Eric Conner helped spark the debate by strongly opposing EIP 2025, which proposed that change to the protocol. In the following column he explains why he thinks the proposal is a slippery slope and threatens Ethereum’s economic model. He also proposes a way to improve the Ethereum Improvement Proposal process itself.

On 2025

by Eric Conner, EthHub co-founder

999, 1890 and now 2025. These numbers are meaningless when an author submits an EIP but they become symbolic for the ideas and debates they raise in the Ethereum community afterwards. In this article, I discuss the EIP workflow and observe some of its potential weakness, particularly in the wake of the recent case of 2025.

Trust the process?

It’s first important to begin by taking a step back and explaining what exactly an EIP is. According to EIP-1, which lays out the rules for the process, “EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment.”

James Hancock helps us visualize the overall workflow:


Because Ethereum is decentralized, anyone can go to the Ethereum Github repository and submit an EIP. To be clear, this is a good thing! At the same time, however, this openness raises a number of important questions: If anyone can submit an EIP, how do we make sure that threat vectors outside of technical compatibility or exploitable code are caught during this process and don’t make it onto the network?

Let’s for a moment agree that EIP-X is generally a bad idea and introduces some non-technical threat, such as incentive breakdowns or legal liability. Theoretically a deficient EIP could be stopped at the “Rough Consensus among All Core Devs” step or the client teams themselves could refuse to implement it. At what point would EIP-X be caught in the process? What if the core developers aren’t versed in economics or law enough to identify a threat existing beyond code review?

The final step is the network refusing to run the new fork with the EIP implemented. However, disagreement between nodes is something that is best avoided because at this point we are talking about a chain split, which devalues the chain overall.

Rightfully so, the core developers do not want every single EIP to have a floor for large debate. After all, most EIPs that go through are technical by nature and really have no reason to be contentious.

2025, a case study

The weakness with the process as it currently stands have been demonstrated with EIP-2025. A few days ago I was reading the notes from the latest All Core Devs call and they were going through the steps of reviewing draft EIPs, which includes reference implementation (see above) for EIPs to be considered in the next Ethereum hard fork, Istanbul.

The notes for EIP-2025 state:

2025: Developer Block Reward - has a reference implementation for the one that it depends on. This is mine so I would need someone else to make this call. I think that it is simple enough that it's okay to not need one. And maybe we can come back to that one Tim, when I head back off to you.”When I opened EIP-2025 the first line read “Add a Developer Block Reward to Ethereum”.

I read the notes to suggest that EIP was good on the reference implementation front and would move onto the next step. At this point, I opened up EIP-2025 to find that it was titled “Block Rewards Proposal for Independent Ethereum Research”. I ended up reading the whole thing but in all honesty I could have stopped there.

The EIP is essentially asking that the network raise the block reward (currently at 2 ETH per block) and use those funds to fund Eth1.x development efforts. I think the Eth1.x efforts are important but that’s beside the point. I want to focus on the idea of block reward funding in general and why I think using the Ethereum block reward mechanism to fund development efforts is a dangerous idea.

To me, the only thing that block rewards (on ETH or BTC) should be used for is securing the chain. From there, it should be a neutral and secure protocol for anyone to build applications on and it should not play favorites. People trust in and build on Ethereum for many reasons but one of the reasons is the assumption that it has strong economic principles of a predictable and low issuance schedule. This means that your holdings cannot be easily diluted by inflation.By allowing increases in block rewards for purposes other than explicitly securing the network, the incentive scheme is opened up to possible corruption or capture. If at any point, the issuance schedule can be altered UP outside of a reason for security, that confidence is shaken.

It’s important to keep in mind that all of these assumptions and theses are important because as ETH price rises, the chain becomes more costly to attack.

Beyond that, the most dangerous part to me is the fact we’d be embarking on a slippery slope. If we set a precedent that one team can get funding via block rewards, why not more? There are plenty of teams out there deserving of more funding. Why is it just this team? Surely we should just keep going. Do you get where I’m going with this? It’s a door we never want to open as block rewards are not meant to be a honeypot. Especially when there is no legitimate mechanism for governing the distribution in a fair and fully transparent manner. Beyond that, it shakes confidence in the protocol from a stabilization perspective. If the issuance can be altered UP, what else can be altered simply based on developer wishes.

I want to be very clear that I’m all for finding ways to fund crucial development efforts on Ethereum. I’ve personally led Gitcoin Grant matching efforts, am part of MolochDAO and am working on an idea to leverage DeFi for funding Ethereum public goods. Finding funding via block rewards is just not the way to go and instead will threaten the entire economic model of Ethereum, ensuring that it destroys more funding potential than it creates.

To me and to others in the community, this sounds like the EIP-X example discussed earlier. Many people told me that I was raising concern over this EIP too early, but I’m not convinced that is true. Now that the community has raised valid concerns, I expect the EIP to be cut down in the “rough consensus among ACD” step of the flow chart. Would it have been cut down there if we didn’t first speak up? I don’t know.

One major flaw I saw with this EIP is that it skipped the steps of gathering community feedback and consensus around the idea. We at a minimum need to follow the basic guidelines put forth.

Improving the process

I would like to propose that we consider minor changes to the EIP process and enforce guidelines already in place to address these issues. There ought to be a formal way to identify an EIP that may be technically sound, but arguably weakens Ethereum from another perspective. For example, an EIP may exhibit good behavior at the code level but would lead to negative economic implications.

It’s been suggested that we add an “Economic considerations” section to the EIP template. Under this section, the author would have to state if the EIP directly results in a state change for economic benefit, has a change to the network fee process or changes the current issuance schedule.

I also suggest we stick to what EIP-1 states as a requirement for the author, “The EIP author is responsible for building consensus within the community and documenting dissenting opinions.”

It is the responsibility of the author to prove that they’ve at least made an attempt to gather feedback and consensus on their issue before they propose it as an EIP. The formal EIP process is not meant to be a playground for ideas. They should be properly thought out and vetted before they even get to being a formal EIP. There are plenty of avenues to at least prove that this was attempted, including but not limited to: Ethereum Magicians forum, /r/ethereum subreddit and yes, even Twitter ;).

Moving forward

So, where does this put us? I think Ethereum is growing up and in doing so is starting to formalize its processes, establish meaningful precedents, and formalize the values of its community. It would seem after EIP-999 that we’ve made a clear stance on fund recovery. Are we making the same stance on block rewards after 1890 and 2025? Only time will tell.

Subscribe now