status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 908 

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
James Ray 2018-05-04 12:22:16 +10:00 committed by EIP Automerge Bot
parent 8f362abc37
commit 0355c87b8e
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
EIPS/eip-908.md
View File

@ -36,9 +36,13 @@ Implementing this as a layer 2 solution may not ensure the sustainability of the
Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node.
## Specification
When a transaction is validated by a client, the client attaches a user agent to another transaction. The user agent is a vector with the txhash of the transaction that is validated, the index of a client address in an access list and the address of the verifying full node. To ensure that the verification of the transaction is valid, the vector could contain an optional field for a zk-SNARK, or you could have Truebit interactive verification of the verification. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage, and the full node address could also be read in a more user-friendly way (e.g. a GUI or command line prompt).
Add a new field to each block called `PrevBlockVerifications`, which is an arbitrary, unlimited size byte array. When a client verifies that a previous block is [valid](https://ethereum.github.io/yellowpaper/paper.pdf#subsubsection.4.3.2), the client appends a user agent to PrevBlockVerifications. The user agent is a vector with the blockhash of the block that is validated, the index of a client address in an access list (details are below) and the address of the verifying full node.
To prevent the miner getting a double-dose of transaction fees, `assert` that the full node validator address is not the same as the miner's address. Some amounts of ETH (these amounts are not specified and would need further analysis as discussed qualitatively below) could be sent or added to the balance of the address in each vector, when the transaction is processed (similar to mining rewards). The amounts could include a proportion of transaction fees (while the miner would then receive less) as well as newly minted ETH.
To ensure that the verification of the transaction is valid, the vector could contain a field for a zk-SNARK, or you could have Truebit interactive verification of the verification. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage, and the full node address could also be read in a more user-friendly way (e.g. a GUI or command line prompt).
To prevent the miner getting a double-dose of transaction fees, `assert` that the full node validator address is not the same as the miner's address.
Some amounts of ETH (these amounts are not specified and would need further analysis as discussed qualitatively below) could be sent or added to the balance of the address in each vector, when the block is processed (similar to mining rewards). The amounts could include a proportion of transaction fees (while the miner would then receive less) as well as newly minted ETH. These amounts are specified in new `VerifierReward` and `ClientReward` fields in the block. It seems that these rewards should be very low, since every full node will need to verify every block, so cumulatively, the total reward will be substantial; whereas miners only receive rewards on average in proportion to their hash power. It is suggested to set 0.001 ETH for verifier rewards and 0.001 ETH for client reward, based on the rough analysis below, although these amounts are certainly subject to change with additional data analysis and experimentation once live.
### More details on the access list
@ -60,7 +64,7 @@ And as for the absolute amounts, this will require data analysis, but clearly a
Now, as to the ratio of rewards to the client vs the full node, as an initial guess I would suggest something like 99:1. Why such a big difference? Well, I would guess that clients spend roughly 99 times more time on developing and maintaining the client than a full node user spends running and maintaining a full node. During a week there might be several full-time people working on the client, but a full node might only spend half an hour (or less) initially setting it up, plus running it, plus electricity and internet costs. Full node operators probably don't need to upgrade their computer (and buying a mining rig isn't worth it with Casper PoS planning on being implemented soon).
However, on further analysis, clients would also get the benefit of a large volume of rewards from every full node running the client, so to incentivise full node operation further, the ratio could change to say, 4:1, and of course could be adjusted with even further actual data analysis, rather than speculation.
However, on further analysis, clients would also get the benefit of a large volume of rewards from every full node running the client, so to incentivise full node operation further, the ratio could change to say, 4:1, or even 1:1, and of course could be adjusted with even further actual data analysis, rather than speculation.
Providing rewards to full node validators and to clients would increase the issuance. In order to maintain the issuance at current levels, this EIP could also reduce the mining reward (despite being reduced previously with the Byzantium release in October 2017 from 5 ETH to 3 ETH), but that would generate more controversy and discusssion.