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

@@ -17,9 +17,15 @@ When each transaction is validated, give a reward to clients for developing the
 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. To summarize the mechanism in the proposal, a user agent is attached to a transaction containing 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).) 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. With a supply cap the issuance can be prevented from increasing indefinitely.
 
 ## Motivation
-Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake, then full PoS. Additionally, providing a reward for clients gives a revenue stream that is independent of state channels, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) it provides.
+Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake, then full PoS. Additionally, providing a reward for clients gives a revenue stream that is independent of state channels, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) it provides. 
 
-Incentivizing client development and running full nodes would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons (see [here](https://eprint.iacr.org/2014/452.pdf#subsection.2.1) for an analysis in the context of Bitcoin and PoW) where there is an extreme lack of supply and excess demand leading to the protocol being unusable. Implementing this as a layer 2 solution may not ensure the sustainability of the protocol, since not everyone would use it; if the protocol doesn't have any cost for full nodes to validate transactions, then people will take advantage of that and not use the layer 2 solution. It seems that you should at least have the part where the reward is provided in protocol, but then that and the user agent signature doesn't really add anything else to the protocol, so doing some part in-protocol and some part e.g. the verification or a verification-game off-protocol could be done, but it's already done in protocol. Note also that some computationally expensive tasks are too challenging to feasibly do in protocol, e.g. due to not fitting in the gas limit, could be done with Truebit, where verifiers have an incentive. 
+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. 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.
+
+> The word “activity” in the phrase Proof of  Activity emphasizes the point that only active stakeholders who maintain a full online node get rewarded, in exchange for the vital services that they provide for the network.  This stands in contrast to earlier Proof  of  Stake schemes in which offline stake can accumulate weight over time, and may ultimately be utilized in double-spending attacks.
+
+We can also incentivize full nodes to propagate transactions and to store transactions or state, in addtition to verifying them. While these first two incentivizations are outside the scope of this EIP, there are proposals [here](https://ethresear.ch/t/incentivizing-a-robust-p2p-network-relay-layer/1438) and [here](https://ethresear.ch/t/incentivizing-full-state-nodes/1640), respectively.
+
+Implementing this as a layer 2 solution may not ensure the sustainability of the protocol, since not everyone would use it; if the protocol doesn't have any cost for full nodes to validate transactions, then people will take advantage of that and not use the layer 2 solution. It seems that you should at least have the part where the reward is provided in protocol, but then that and the user agent signature doesn't really add anything else to the protocol, so doing some part in-protocol and some part e.g. the verification or a verification-game off-protocol could be done, but it's already done in protocol. Note also that some computationally expensive tasks are too challenging to feasibly do in protocol, e.g. due to not fitting in the gas limit, could be done with Truebit, where verifiers have an incentive. 
 
 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. 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 mainstream computer to be a verifying full node, or at least a mainstream high-end desktop computer with GPUs in the case of PoW.