Some proposed tweaks #8
Conversation
| ## 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. |
There was a problem hiding this comment.
The name EMISSION_SCHEDULE is misleading. I'd rename this constant something like REWARD_DURATION_IN_BLOCKS.
|
|
||
| ## 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 |
There was a problem hiding this comment.
Do you have any plans to provide an implementation?
There was a problem hiding this comment.
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.
|
|
||
| <!--"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. |
There was a problem hiding this comment.
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. | ||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
No description provided.