Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some proposed tweaks #8

Merged
merged 1 commit into from
May 25, 2019
Merged

Some proposed tweaks #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 22 additions & 31 deletions EIPS/eip-2025.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,25 +13,23 @@ requires: 1890
## Simple Summary
Add `0.044 ETH` per block for 18 months as a developer block reward reserved for funding Ethereum1.X development.

Currently, EIP 1890 is a proposal for a mechanism to capture Block Rewards for funding Development. That EIP has values and addresses set to zero. This proposal is to set those values to non-zero for 18 months focused on funding Ethereum 1.X working groups and organization efforts. The block reward will go towards paying back a loan with a small amount of interest to organizations in the Ethereum Community. After 18 months the block reward would again be set to zero.
Currently, EIP 1890 is a proposal for a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. That EIP sets values and addresses to zero and so does not actually collect any rewards. This proposal is to set those values to non-zero for 18 months in order to fund Ethereum 1.X working groups and organization efforts. The block reward will go towards paying back a loan with a small amount of interest to organizations in the Ethereum community. After 18 months the block reward would again reduce to zero.

<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->

## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->
This EIP extends the mechanism established in EIP-1890 to add `0.044 ETH` to the Block Reward for a specific distribution period of `3,100,000 BLOCKS`(≈18 months). The `RECIPIENT_ADDRESS` set to a smart contract with hardcoded denominations that distribute ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the inclusion of this EIP in a hard fork and continue until the end of the period `3,100,000 BLOCKS` (≈18 months) where the address and amount would again return to 0. Any further distribution will require a future hard fork.
This EIP extends the mechanism established in EIP-1890 to add `0.044 ETH` to the block reward for a specific distribution period of `3,100,000 BLOCKS`(≈ 18 months). The `RECIPIENT_ADDRESS` is set to a smart contract with hardcoded denominations that distributes incoming ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the hard fork block number and continue for `3,100,000 BLOCKS` (≈ 18 months) at which point the address and amount would again return to 0. Any further distribution would require a future hard fork.

## Motivation
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->

The context for this proposal came from attending the [Core Dev Eth1.X Meeting](https://www.youtube.com/watch?v=Au1Qll-86v0) in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted within the context of working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a lack of funding is the primary barrier to this work

It would be good to provide concrete evidence of this, e.g., testimonials from others.




## Specification
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->

Two constants will be introduced DEVFUND_BLOCK_REWARD, the total amount of rewards specified in Eth, and `EMISSION_SCHEDULE` which will terminate the block rewards after `CURRENT_BLOCK - ISTANBUL_BLOCK_HEIGHT <= EMISSION_SCHEDULE`. Also, `BENEFICIARY_ADDRESSES` is introduced which is a list of tuples containing the address and the amount to be deposited. These amounts will be determined as the loan is collected from participating organizations and the addresses for repayment will be specified by them. At the end of `EMISSION_SCHEDULE` the loan will be completely repaid.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name EMISSION_SCHEDULE is misleading. I'd rename this constant something like REWARD_DURATION_IN_BLOCKS.

Two constants will be introduced: `DEVFUND_BLOCK_REWARD`, the total amount of rewards specified in Eth, and `EMISSION_SCHEDULE` which will terminate the block rewards at block height `ISTANBUL_BLOCK_HEIGHT + EMISSION_SCHEDULE`. Also, `BENEFICIARY_ADDRESSES` is introduced which is a list of tuples containing the address and the amount to be deposited. These amounts will be determined as the loan is collected from participating organizations and the addresses for repayment will be specified by them. At the end of `EMISSION_SCHEDULE` the loan will be completely repaid.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd lean towards putting most of this logic, especially BENEFICIARY_ADDRESSES, into a smart contract, and just specifying that single contract as the beneficiary here in protocol.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As raw and not pretty as it is to do the repayment in the client code it also strikes me as being much more secure. With tests written and the tests passing there should be no issue. I don't know enough about the difference of it being a smart contract. Can you help me see the trade-offs of doing it either way?

The biggest downside I see is that it is the least elegant solution and the extra code would continue to exist after the duration of block rewards is paid, but that can be cleaned up in a further fork which returns to the code back to what is in EIP-1890. Perhaps it can even be deleted from the clients after the REWARD_DURATION_IN_BLOCKS has passed?


```
DEVFUND_BLOCK_REWARD = 0.044
Expand All @@ -52,30 +50,27 @@ FOR BENEFICIARY in BENEFICIARY_ADDRESSES:

```

`DEVFUND_BLOCK_REWARD` is used in testing to verify that the sum of Eth distributed to `BENEFICIARY_ADDRESSES` is not greater than `DEVFUND_BLOCK_REWARD`

`DEVFUND_BLOCK_REWARD` is used in testing to verify that the sum of Eth distributed to `BENEFICIARY_ADDRESSES` is not greater than `DEVFUND_BLOCK_REWARD`.

## Rewards Distribution Rationale
```
Development Loan: 0.04 - 124,000 ETH
Development Loan Interest 10%: 0.004 - 12,400 ETH
Development Loan: 0.04 ETH per block: 124,000 ETH total
Development Loan Interest 10%: 0.004 ETH per block: 12,400 ETH total

Total Block Reward Increase = `0.044` ETH Per Block - 136,400 ETH Total
Total Block Reward Increase = `0.044` ETH per block: 136,400 ETH Total
```

*With a current price of Etheruem at $200.00 this will raise 25 million USD for developing Eth1.X over the next 18 months.*
*With a current price of Etheruem at $200.00 this will raise approx USD $25 million for developing Eth1.X over the next 18 months.*

![Block Rewards Distribution](https://docs.google.com/drawings/d/e/2PACX-1vRzpcFXvkftqEduftfCnNeJmjxQAyBjD1RMkuFt0JeURxSZ2oUSGA1HQ1-v5rjGeim2cn8IwF4UFH18/pub?w=873 "Logo Title Text 1") *Specific Addresses to be determined

* [FAQ - Why hardcoded values?]( #why-hardcoded-values )



## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

There has been great debate on Twitter concerning EIP-1890, and one of the primary concerns is that it is difficult to come to a conclusion without the other half of the proposal, or more specifically, how much and where to allocate Block Reward funds. There is a need for funding Eth1.x development and it is currently unclear from where those funds will come. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is funded I will withdraw this EIP that would render it obsolete. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work.

There has been great debate on Twitter concerning EIP-1890, and one of the primary concerns is that it is difficult to come to a conclusion without the other half of the proposal, or more specifically, how much and where to allocate block reward funds. There is a need for funding Eth1.x development and it is currently unclear where those funds will come from. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is funded I will withdraw this EIP that would render it obsolete. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work.

### Why a Loan?

Expand All @@ -92,10 +87,10 @@ There is a risk for the Funding Organizations to lose part of their deposit in t
`Development Loan: 0.04` over 3.1 Million blocks = 124,000 ETH

**Funding Working Groups on 1.X**
* Funding Contractors, Coordinators, and project mangers.
* Working Groups defined with clear mandates at the time of creation before allocating funds
* Funding Contractors, Coordinators, and project managers
* Working Groups defined with clear mandates at the time of creation before allocating funds
* Membership and creation managed by the Core Devs (i.e., I would not choose them)
* 30-50 Core Devs is sufficient to work on ETH1.X
* 30-50 Core Devs is sufficient to work on ETH1.X
* 7-8 Working groups with a Membership size of 3-7 is ideal from a coordination perspective.

**ETH1.X Core Dev Gatherings**
Expand All @@ -104,35 +99,31 @@ Funding hosting, traveling, and accomodations for neccesary in person gatherings
**Client Teams**
Any research completed by ETH1.X working groups will need to be integrated into core clients before the network can adopt any changes. It is anticipated some of these funds will go to support the existing client teams in this effort.

At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of unstructuredness forming within.
At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of structurelessness forming within.


* [FAQ - How will the funding of the Devs be organized?]( #how-will-funding-the-devs-be-organized)

![Eth1.x Working Groups Status](https://docs.google.com/drawings/d/e/2PACX-1vRzaZFh4fZS0mksfyfJs1AsXNoqgfMmyJMYLHXEVariN-S9YsI43_FhHl1K_iO4rrqDsSy-tX4-MWws/pub?w=548&h=423)



## Personal Notes and Disclosure
I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I would seek the following conditions.

1) Funding for my work will not come from the loan meant for the Eth1.X Working Groups.

Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal
Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal.

### COI
Previously I was PM for Tennagraph, a Signalling solution for Ethereum. An Aragon Grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project past this Grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly.
Previously I was PM for Tennagraph, a Signalling solution for Ethereum. An Aragon grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project past this grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly.

### Disclaimer

I do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. I welcome feedback and will listen carefully, but any adaptations are according to my judgment. This is an honest reflection. This is as fair of a proposal as I can personally conceive. If the community rejects it then so be it, I am satisfied with the submission.

## Backwards Compatibility
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
None
This EIP has no impact on backwards compatibility.

## Test Cases
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
Not Implemented

## Implementation
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have any plans to provide an implementation?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could use help on this. I know there have been 3 references done for EIP-1890. To change these to a value and a smart contract address should be easy enough for me. If the logic is handled in a smart contract as you suggest below then I don't know how to do that.

Expand All @@ -142,7 +133,7 @@ Not Implemented

## FAQ

### Why Hardcoded Values
### Why Hardcoded Values?

Why not us a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective?

Expand All @@ -166,19 +157,19 @@ Criticisms or support aside, there is a system that governs ethereum today. It i

I do not aim to change ethereum governance. Because this EIP has hardcoded values, it must go through the existing governance process, whatever that is, before it will be implemented in the network. It will then continue until as decided until the end of the emission schedule. This is intentional. This makes it uncapturable. No party other then the ecosystem itself can modify the contract once it has been deployed.

This EIP is not about Governance Reform
This EIP is not about governance reform.

### Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...)

Historically there has been a precedent that the Ethereum foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguci observed in a recent [coindesk article](https://www.coindesk.com/ethereum-foundation-director-sets-new-vision-for-blockchain-non-profit). “it really is not only Ethereum Foundation people who are building [ethereum,]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum the Network is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.
Historically there has been a precedent that the Ethereum foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguci observed in a recent [coindesk article](https://www.coindesk.com/ethereum-foundation-director-sets-new-vision-for-blockchain-non-profit), “it really is not only Ethereum Foundation people who are building [ethereum,]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum the Network is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.

### How Will Funding the Devs be Organized

I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a [recent medium article](https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60).
I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a [recent medium article](https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60):

>“Going from funding a few implementation teams continuously and letting them do “their stuff” to funding more specific and temporary initiatives requires looking at funding through different lenses. How much “due diligence” and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post).
>“Going from funding a few implementation teams continuously and letting them do 'their stuff' to funding more specific and temporary initiatives requires looking at funding through different lenses. How much 'due diligence' and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post)."

My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate memberhips and payment of the CoreDevs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now.
My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate membership and payment of the CoreDevs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now.

### Isn't a loan considered a security, or is it?

Expand Down