EIP-1890: Commitment to Sustainable Ecosystem Funding

[lrettig]

Sample geth implementation: GregTheGreek/go-ethereum@a1ea205
Sample Trinity implementation: lrettig/py-evm@ee5a23f

(These reference an old EIP number, #1789, and can be updated.)

[localcryptosMichael]

I think this EIP is a very bad idea. Economic interactions in the Ethereum network are better kept voluntary.

This EIP lies on the assumption that a centralized group of people know better than the market as to what is "fair". It will, of course, also run into the economic calculation problem.

[kronosapiens]

I think that appeals to Mises and Hayek are a bit extreme in this case. We are not discussing granting a central entity general planning powers, but rather the idea of allocating a fixed amount of funding for the ecosystem. The key difference is that rather than giving these entities the ability to make absolute judgements (i.e. we should mint X additional ether), we limit them to relative judgments (i.e. we have X ether to give away, which projects/people should we prioritize). This distinction is important.

The way this EIP is being developed (seems to me) would cleanly separate the amount of ether being distributed from the decisions about where it should be distributed. The decision about the amount is made at the time of the hard fork via the current hard fork process (which requires a certain amount of general consensus). Only the decisions about the destinations are being delegated to (ideally multiple) other entities.

The separation of amount and destination allows us to reason much more clearly about the impact of this funding on the ether supply, as well as to limit the potential downside by allocating only small amounts of funding to start. Some inefficiency in the allocation is inevitable, and IMO not a grounds for aborting the endeavor.

[kronosapiens]

Separately, I would advocate for including the decay in this EIP. Lane you mention it's been omitted for simplicity but I expect that this sunsetting will do a lot to assuage the concerns of critics.

[owocki]

Economic interactions in the Ethereum network are better kept voluntary.

This EIP introduces no new economic interactions on the Ethereum network, and could not without a hard fork, so this comment is a bit out of scope @localethereumMichael . I think you should save your objections for an EIP that does.

Separately, I would advocate for including the decay in this EIP.

+1 @lrettig

[lrettig]

I would advocate for including the decay in this EIP

I didn't because, again, until the faucet is turned on it doesn't matter. I suppose, if we include it, then we could rename this from "Credible commitment to sustainable ecosystem funding" to "Credible commitment to ecosystem funding that turns off automatically after some time unless it's renewed"

[lrettig]

I want to say the following things explicitly:

• This EIP proposes no new funding, no new block rewards, and does not change the miners' incentive structure or rewards. No change to the economics. Such a change would require another EIP. (So in this respect, there is no economic argument to be made against this EIP.)
• I will not personally support any plan that raises any new funding, whether through block rewards, donations, or another mechanism, until we've come up with a reasonable plan for governing and using those funds, which we feel has at least a reasonable chance of garnering broad community support.
• The governance/stewardship/disposition of funds question is a difficult one and I will do everything I can to help solve it.

[bmann]

@Arachnid this EIP appears to be properly formatted, can you or another editor please merge?

[lookfirst]

I see this EIP as playing a game, much like the difficulty bomb does.

The game is that @lrettig wants to start the discussion around changing the block rewards, by putting in the mechanism to do so, but not actually enabling that mechanism until further discussions happen.

I will not personally support any plan that raises any new funding, whether through block rewards, donations, or another mechanism,

But that does not mean in the future that a group of people will support a plan and override @lrettig. Once this mechanism is in place, it encourages more discussions around changing things, simply because it exists. Not as effective as the difficulty bomb because its existence does not force a discussion.

until we've come up with a reasonable plan for governing and using those funds, which we feel has at least a reasonable chance of garnering broad community support.

I think a better solution, is to approach the governance with a plan vs. creating a discussion by adding some code that does not actually do anything today. If the governance is broken, fix the governance.

[ghost]

I see this EIP as playing a game, much like the difficulty bomb does.

The game is that @lrettig wants to start the discussion around changing the block rewards, by putting in the mechanism to do so, but not actually enabling that mechanism until further discussions happen

Fortunately, it's fairly transparent. The idea of adding a faucet without deciding who will turn it on is ridiculous on its face. I suppose the argument goes that "end users are protected by the necessity of a hard fork", but the EIP / HF process is easily gamed by incentivized parties of developers and other hangers-on.

If the standard for adding new features to Ethereum is "it's harmless without another HF", well, I have all sorts of ideas about where we could add faucets.

[lrettig]

without deciding who will turn it on

It can only be turned on via EIP, as you said, which means all core devs. The right question to ask is not "who" but "how."

[ghost]

The right question to ask is not "who" but "how."

Semantic tomfoolery. If there's no process for operating the faucet, and distributing the output, then why add the faucet first?

[lrettig]

If there's no process for operating the faucet, and distributing the output, then why add the faucet first?

Read the title of the EIP. To make a credible commitment to doing so in the future if it becomes necessary.

[ghost]

To make a credible commitment to doing so in the future if it becomes necessary.

From the EIP:

...this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to...

The core devs are making a commitment to fund themselves? This EIP gives "core devs" the power to award themselves arbitrary funding for any reason, whenever they can get another EIP through. Or maybe accidentally release a client with a "test" version of this function activated.

Also from the EIP:

Those talented researchers and developers deserve to be paid fairly for their work.

Do you consider yourself to be fairly paid? It's very direct question, but if this can of worms is opened, all of this and more will have to be laid out in public and discussed.

[owocki]

The core devs are making a commitment to fund themselves?

Two points:

1. Core devs are not some homogenous centralized group; They are spread throughout the world and have many different backgrounds, experiences, + ways of funding themselves (if funded at all)
2. Developers can decide what to put in their clients, but miners/stakers decide what version of the software to run. Its wholly incorrect to state that this EIP gives core devs the power to award themselves, as (b) the value is set to 0 and (2) there is still a check/balance from the stakers/miners, and also the wider community.

Do you consider yourself to be fairly paid? It's very direct question, but if this can of worms is opened, all of this and more will have to be laid out in public and discussed.

Seems like a good thing to discuss if/when someone submits another EIP on top of this to make a non-zero funding commitment.

[kronosapiens]

Seems like a good thing to discuss if/when someone submits another EIP on top of this to make a non-zero funding commitment.

I dunno... if following the discussion the last few weeks has revealed anything it's that you can't really separate the idea of a "faucet" from the specific mechanism(s) which it flows into. To insist otherwise seems inefficient at best and disingenuous at worst. I like the idea but it seems like there needs to be more clarity and confidence around who will eventually hold funds and how they will be distributed before this is going to get enough buy-in.

[owocki]

. if following the discussion the last few weeks has revealed anything

What are you talking about? how has the discussion over the last week revealed this specific point in any way?

To insist otherwise seems inefficient at best and disingenuous at worst

It's a two way street @kronosapiens . You didnt explain your assertion above, or cite any evidence at all. Seems inefficient at best.

seems like there needs to be more clarity and confidence around who will eventually hold funds

I agree that more clarity is needed, but disagree that it needs to be in EIP 1890. (and it appears the matter is settled, as the EIP is already merged anyhow)

[bmann]

Draft EIPs can continue to be edited, and it is suggested that discussion happens at the author’s indicated discussions-to. Additionally there is an entire GitHub repo with open issues around this topic.

[owocki]

the github board boris speaks of is here https://github.com/ethereum-funding/blockrewardsfunding/issues

[ghost]

Two points:

1. Core devs are not some homogenous centralized group; They are spread throughout the world and have many different backgrounds, experiences, + ways of funding themselves (if funded at all)
2. Developers can decide what to put in their clients, but miners/stakers decide what version of the software to run. Its wholly incorrect to state that this EIP gives core devs the power to award themselves, as (b) the value is set to 0 and (2) there is still a check/balance from the stakers/miners, and also the wider community.

So you're saying that if stakeholders don't like it, they can fork off? In response to your point 2, it literally does give them the power to award themselves funding. How many EIPs have been produced and implemented by non-core devs?

Do you consider yourself to be fairly paid? It's very direct question, but if this can of worms is opened, all of this and more will have to be laid out in public and discussed.

Seems like a good thing to discuss if/when someone submits another EIP on top of this to make a non-zero funding commitment.

I disagree here too. Given that the statement about fair funding was made in the section of this EIP that explained the motivation for writing it, I think here is the place to discuss it.

I agree that more clarity is needed, but disagree that it needs to be in EIP 1890. (and it appears the matter is settled, as the EIP is already merged anyhow)

"Merged" does not mean "settled". I really disagreed with the auto-merging of correctly-formatted EIPs when that process was introduced, as it gave legitimacy to EIPs that would otherwise be very contentious. This EIP in particular highlights this issue - the next stage of the process is for it to be discussed in an all core devs call, so control of this EIP has already passed to that group, who have a strong self-interest in passing this EIP.

[kronosapiens]

Lol @owocki don't sealion me bro. It's self-evident that this EIP is trying to kick the can down the road w.r.t. governing funds, which raises the question as to why it's so important to create a "credible commitment" absent any other details. It seems like the only reason one would do that is to create inertia around "doing something", but it's not clear why creating that inertia is important prior to building some consensus around a fund governance solution. So what's the point? My read is that this EIP is meant to get the conversation started around fund governance mechanisms, and that without this EIP it would be harder to get people coordinated around a specific problem. But as @consciousEntity observes, there are more critical reads.

[ghost]

My read is that this EIP is meant to get the conversation started around fund governance mechanisms, and that without this EIP it would be harder to get people coordinated around a specific problem.

That is one way to look at it, but the obvious flaw is that any discussion will be motivated by the presence of this faucet, with the "winners" getting control of it.

[owocki]

happy to discuss more on the github board or telegram. your feedback will get a wider audience there as the whole working group pays attention to those channels. ✌️

[ghost]

Meta: Is this even a valid EIP?

By design this EIP has no practical effect and therefore cannot be argued to be a net improvement but only a political pre-commitment, as such it would complicate the protocol unduly.

Allowing it to be considered would also seem to open the floodgates to further purely political and symbolic EIPs.

[scott-l-e-w-i-s]

This EIP would have no functional effect on ethereum, except to make the next hard fork more complicated.

It will set the stage for the community to tear itself apart if it goes in.

The ethereum community has 3 years of grind coming that will make or break the project. Our cohesiveness as a community will be critical as we face challenges and setbacks together. Most people just need a break. There is no urgency to do this contentious EIP right now, and all the reason to rest until the proposers can iterate to a proposal that would have a functional effect on the ethereum network.

[edsonayllon]

This EIP affects 2 parties: The decentralized group running the platform by confirming transactions, and the decentralized group advancing the platform forward.

Both sides should be considered thoroughly.