EIP 908: Update amount reward rationale

EIPS/eip-908.md

@@ -42,7 +42,7 @@ To ensure that the verification of the transaction is valid, the vector could co
 
 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.
+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.
 
 ### More details on the access list
 
@@ -52,12 +52,58 @@ However, another alternative to managing the access list would be to have decent
 
 Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could `assert` that the address found at that index matches that which can be read by the client (where the latter would be a read-only address).
 
+In order to only incentivize verifying recent blocks, assert that the block number corresponding to a blockhash is less than 400 blocks ago.
+
 ## 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.-->
 
 ### 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.
+
+Assume that the computer lasts for 5 years.
+
+Neglect 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
+
+Block reward per client (worse case for ETH price) = Average revenue per client * number of clients / (ETH exchange rate * number of nodes)
+
+= $2,000,000 * 10 / (500 * 30,000)
+
+= 1.333333333 ETH
+
+Block reward per client (better case) = $1,000,000 * 10 / (2000 * 30,000) = 0.166666667 ETH
+
+Suppose that we use a block reward of 0.15 ETH for clients.
+
+<!--There are more than 5552465 blocks and counting. With a reward of 0.001 ETH for each block, a full state node that verified every block would receive 5552.465 ETH. However, the difficulty of verifying blocks increases over time, so-->
+
+### More rationale (outdated by above)
+
 The amount of computation to validate a transaction will be the same as a miner, since the transaction will need to be executed. Thus, if there would be transaction fees for validating full nodes and clients, and transactions need to be executed by validators just like miners have to, it makes sense to have them calculated in the same way as gas fees for miners. This would controversially increase the amount of transaction fees a lot, since there can be many validators for a transaction. In other words, it is controversial whether to provide the same amount of transaction fee for a full node validator as for a miner (which in one respect is fair, since the validator has to do the same amount of computation), or prevent transaction fees from rising much higher, and have a transaction fee for a full node as, say, the transaction fee for a miner, divided by the average number of full nodes validating a transaction. The latter option seems even more controversial (but is still better than the status quo), since while there would be more of an incentive to run a full node than there is now with no incentive, validators would be paid less for performing the same amount of computation.
 
 And as for the absolute amounts, this will require data analysis, but clearly a full node should receive much less than a miner for processing a transaction in a block, since there are many transactions in a block, and there are many confirmations of a block. Data analysis could involve calculating the average number of full nodes verifying transactions in a block. Macroeconomic analysis could entail the economic security benefit that full nodes provide to the network.