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

EIPS/eip-908.md

@@ -11,13 +11,13 @@ created: 2018-03-01
 
 ## A reward for running a full node is deprecated, but the proposal for a reward for clients remains
 
-While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper. In light of these two points, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Most mentions of a full node, including where not struck out, may be ignored. Given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile.
+While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper. In light of these two points, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile.
 
 ## Simple Summary
-When each transaction is validated, give a reward to clients for developing the client ~~and provide a reward to full nodes for validating the transaction.~~
+When each transaction is validated, give a reward to clients for developing the client.
 
 ## Abstract
-The tragedy of the commons is a phenomenon that is well known in many sectors, most notably in regard to sustainability. It involves the over-utilization of shared finite resources, which detriments all participants and stakeholders involved (which in the case of a global public good can be everyone, including future generations). Without proper management of public resources, a tragedy of the commons can occur. Internalizing externalities (where externalities can be broadly defined as effects that are not accounted for in the intrinsic price of a good, service or resource) is one way of incentivizing the proper management of resources, although other methods that actually properly manage them are necessary. This EIP proposes to make a change to the protocol to provide ~~a reward to full nodes for validating transactions, and thus providing extra security for the Ethereum network, and~~ a reward to clients for providing the software that enables Ethereum to function, where the reward can include a proportion of transaction fees (reducing the full proportion that the miner currently receives), and some newly minted ETH. Thus, ~~verifying full nodes and~~ clients are incentivized to maintain and improve the security and health of the Ethereum protocol and ecosystem. To summarize the mechanism in the proposal, a user agent is attached to a transaction, where this user agent contains a vector with the index of a client address in an access list~~, and the address of the verifying full node~~. 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. via Metamask, a GUI or command line prompt)~~. 
+The tragedy of the commons is a phenomenon that is well known in many sectors, most notably in regard to sustainability. It involves the over-utilization of shared finite resources, which detriments all participants and stakeholders involved (which in the case of a global public good can be everyone, including future generations). Without proper management of public resources, a tragedy of the commons can occur. Internalizing externalities (where externalities can be broadly defined as effects that are not accounted for in the intrinsic price of a good, service or resource) is one way of incentivizing the proper management of resources, although other methods that actually properly manage them are necessary. This EIP proposes to make a change to the protocol to providea reward to clients for providing the software that enables Ethereum to function, where the reward can include a proportion of transaction fees (reducing the full proportion that the miner currently receives), and some newly minted ETH. Thus, clients are incentivized to maintain and improve the security and health of the Ethereum protocol and ecosystem. To summarize the mechanism in the proposal, a user agent is attached to a transaction, where this user agent contains a vector with the index of a client address in an access list. 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. 
 
 Reward mechanisms that are external to being built in to the protocol are beyond the scope of this EIP. Such extra-protocol reward methods include state channel payments for extra services such as light client servers providing faster information such as receipts; state channel payments for buying state reads from full nodes; archival services (which is only applicable to future proposed versions of Ethereum with stateless clients); and tokens for the client and running full nodes.
 
@@ -28,7 +28,7 @@ Additionally, providing a reward for clients gives a revenue stream that is inde
 
 While it may be argued that the funds raised by the Ethereum pre-mine (the pre-ICO and the ICO) can be used to fund client development, that argument is questionable, since Parity is VC-funded, and other clients such as Prysmatic Labs [1](https://medium.com/@XYOracleNetwork?source=search_post), [2](https://twitter.com/prylabs/status/996391036753666050), [3](https://medium.com/prysmatic-labs/biweekly-development-update-2-d29d0c91e7d0) and [exthereum](https://medium.com/compound-finance/introducing-exthereum-the-newest-ethereum-client-7a5e30d4d6aa) have received funding from other parties, whereas perhaps they would not have needed to do so if there was sufficient funding from the Ethereum pre-mine funds. [Drops of Diamond](https://github.com/Drops-of-Diamond/diamond_drops) is yet to receive any funding.
 
-Incentivizing client development ~~and running full nodes~~ would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons, where there is an extreme lack of supply and excess demand, leading to the protocol being unusable. 
+Incentivizing client development would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons, where there is an extreme lack of supply and excess demand, leading to the protocol being unusable. 
 
 See [here](https://eprint.iacr.org/2014/452.pdf#subsection.2.1) for an analysis in the context of Bitcoin, PoW, and a hybrid PoW/PoS protocol. While Ethereum has a gas limit, the section points out that this is not enough as the market cap increases and the incentive to attack the network increases, while the ratio of security costs to transaction fees does not, while PoS will further alleviate the problem. However, the section points out that PoS is not enough, since the costs of propagating, verifying and storing transactions are not incentivised. Note that the "Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake" paper also contains a scheme for incentivizing a target participation level.
 
@@ -43,13 +43,9 @@ Not providing incentives for clients is an issue now as there is less incentive
 Note that with a supply cap (as in [EIP 960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP 1015](http://eips.ethereum.org/EIPS/eip-1015), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders.
 
 ## Specification
-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, and the index of a client address in an access list (details are below)~~and the address of the verifying full node~~.
+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, and the index of a client address in an access list (details are below).
 
-~~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. ~~
-
-Send ~~0.000002852 ETH to the verifying full node and ~~0.15 ETH to the client (see the rationale below), when the block is processed. The amounts could include a proportion of transaction fees (while the miner would then receive less), which would reduce newly issued ETH. These amounts are specified in new ~~`VerifierReward` and ~~`ClientReward` fields in the block.
+Send 0.15 ETH to the client (see the rationale below), when the block is processed. The amounts could include a proportion of transaction fees (while the miner would then receive less), which would reduce newly issued ETH. These amounts are specified in new `ClientReward` fields in the block.
 
 ### More details on the access list
 
@@ -67,28 +63,6 @@ In order to only incentivize verifying recent blocks, assert that the block numb
 
 ### A rough qualitative analysis of fees 
 
-~~Let us assume that all but the last 400 blocks are valid (this provides room for [consensus bugs](https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/)). If this assumption is correct, then there is no additional value for all but the last 400 blocks to be verified. However, for a full state node to do a full sync, it must verify all the previous blocks. On the other hand, a full node can do a [fast](https://ethereum.stackexchange.com/questions/1161/what-is-geths-fast-sync-and-why-is-it-faster) or [warp](https://ethereum.stackexchange.com/questions/9991/what-is-paritys-warp-sync-and-why-is-it-faster-than-geth-fast) sync and verify blocks from there, while if it is able to do a full sync then it will also be able to mine, thus will be incentivised for that (although, whether the cost of storing the full state is fully incentivised is questionable). Let us not consider incentivizing the cost of downloading, for simplicity. Thus, let us consider to only incentivize fast or warp syncing nodes verifying recent blocks, which is why the assert exists to check that a verified block is less than 400 blocks ago.~~
-
-~~Suppose that 0.001 ETH is set for verifier rewards and 0.001 ETH for client rewards. Given an [average block rate of 15 s](https://etherscan.io/chart/blocktime), that's 2103840 blocks per year. So a verifier would be compensated ~2104 ETH per year. Now note that to warp sync not just any computer will do the job, one at the higher end is probably needed. So assuming that one doesn't already have a high end computer, or perhaps preferring to use a separate one to not impact performance for other uses. (The author is unable to finish warp syncing with Parity on his Intel Core i3-2130 desktop with 7.5 GiB of memory and a 120 GB INTEL SSDSC2CT120A3 SSD, nor on his Intel Core i5 laptop with 3.7 GB of memory and a 320 GB ST9320423AS HDD.)~~
-
-~~Costs:~~
-
-~~- capital cost of a high-end computer: [$500](https://www.ebay.com.au/itm/Intel-NUC-Kit-NUC7I7BNH-Mini-Computer-Desktop-PC-Barebone-Core-i7-M-2-USB-Type-C/232361857936?hash=item3619d89390:g:~6oAAOSwn55a581Y)–[$4000](https://www.ebay.com.au/sch/PC-Desktops-All-In-Ones/179/i.html?_from=R40&_nkw=AMD+threadripper+16+core)
-- electricity: [$45.55 per year](https://news.bitcoin.com/cost-full-bitcoin-node/)<!--assume [25-45 c/kWh](https://www.canstarblue.com.au/energy/electricity/electricity-costs-kwh/).--> 
-- internet (this could be not accounted for since a user may have unlimited internet anyway, so there is no marginal cost for using the internet more) [$0–$55 per month](https://news.bitcoin.com/cost-full-bitcoin-node/). $0–710/year.
-- human cost: assume $200/year.
-- total operating cost =  $250-960 per year.~~
-
-~~Assume an average price of ETH from $500–2000 USD/ETH. ssume that the computer lasts for 5 years. eglect the effect of inflation, opportunity cost and electricity prices increasing for simplicity.
-
-~~Simple Payback Time (best case) = `$500 / (2000 USD/ETH * 2104 ETH/year- 250 $/year)` = 0.001 years~~
-
-~~Clearly this is too short of a SPT. Let's assume that we aim for a SPT of 2 years, leaving 3 years to get surplus returns on investment.  Now let us assume a scenario that more approaches worst case.~~
-
-~~Simple Payback Time (more worse case) = `$4000/(6 ETH/year * $500/ETH - $960/year)` = ~ 2 years~~
-
-~~Thus, the reward for each block becomes `6 ETH year/(1 block / 15 s * 60 s / min * 60 min/ h * 24 h/d * 365.25 d/a = 6/(1/15*3600*24*365.25) = 0.000002852 ETH / block`.~~
-
 As of May 4 2018, there are [16428 nodes](https://web.archive.org/web/20180504051128/https://ethernodes.org/network/1). Assume that an annual cost for an average client developer organisation is $1 million per annum. Projecting forward (and noting that the number of nodes should increase substantially if this EIP was implemented, thus aiding Ethereum's goal of decentralizing everything) assume that there are 10 clients. Thus let us assume that the number of nodes doubles to 30000 nodes within 5 years (this assumption is probably conservative, even if it is forward looking). Assume for simplicity that the costs of a client are entirely covered by this block reward.
 
 Average cost per client = number of nodes * Block reward per client / number of clients
@@ -128,16 +102,6 @@ Note that while further quantitative analysis to specify fees should be done, so
 ### Security
 All of the below struck out information should be prevented via using an access list and verifying that the read-only address provided by the client matches with an address in the access list, as well as using a layer 2 solution such as a PoA network for censhorship resistance and minimization of centralization in the access list.
 
-~~[Micah stated](https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239/4):
-> The first most obvious caveat is that end-users would be incentivized to put an address of their own down as the user agent. Initial thinking on this is that there are few enough users advanced enough to run a custom client so the losses there would be minimal, and client developers are incentivized to not make the user agent string configurable because it is how they get paid. Also, presumably the per-transaction user-agent fee would be small enough such that the average user probably won’t care enough to hack their client to change it (or even switch clients to one that lets the user customize the user agent), usability and simplicity matter more to most. There is a concern that most transactions are coming in through third party Ethereum nodes like Infura or QuikNode and they have incentive and capability to change the user agent.~~ 
-
-~~Obviously, creating such an incentive to centralize full nodes is not desirable. zk-STARKs may help with this, where miners or Casper block proposers could submit a zk-STARK to prove that they executed the transaction, and reduce the cost of validation. However, zk-STARKs aren't performant enough yet to use in the blockchain. zk-SNARKs aren't transparent, so aren't suitable for including in-protocol on a public blockchain. Further research is needed to find a solution for this problem. Micah continued:
-
-> ~~I’m tempted to suggest “let's wait and see if user-agent spoofing becomes a meaningful problem before trying to fix it”, since the worst it can do is put is right back where we are now with no incentives for client development.
-Something to consider is that the user agent fee could be used to bribe miners by putting the miner address in instead. Once again, I’m tempted to try it out first (unless someone has better ideas) and see how things go because it is a very high coordination cost to actually bribe miners via user agent (since you don’t know who will mine the block your transaction ends up in), and there is no common infrastructure/protocol for broadcasting different transactions to different miners.
-
-~~One simple way to prevent bribing miners or miners attempting to validate the transaction in the blocks that they mine is to block miners receiving validation rewards for the blocks that they mine. One problem with this is that a miner could run a full node validator using a different address with the same computer, and just cache the result of their execution and use it for the full node validator. I'm not sure how you would prevent this, but perhaps you could using IP address tracking (similarly asserting that the IP address of a full node validator isn't the same as the miner) which would add additional complexity to the protocol, but this could also be hacked with dynamic IPs and VPNs.
-
 Further discussion is at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239.
 
 ## Backwards Compatibility