EIP: Reward for clients and full nodes validating transactions #908
Conversation
jamesray1
changed the title
jamesray1
changed the title
jamesray1
changed the title
jamesray1
changed the title
…d-full-nodes-and-clients.md
| I’m tempted to suggest “lets 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. | ||
|
|
||
| The amount of computation to validate a transaction should be relatively constant, AIUI it just involves computing a verification of the signature (e.g. with ECDSA). Thus, the transaction reward to the validator and client could be fixed. |
There was a problem hiding this comment.
Validating a transaction requires executing it, just like the miner did.
|
|
||
| Discussion began at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239/20. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
If the per transaction fee is low enough people won't bother to cheat, doesn't that also mean this will only effectively incentivise running large centralised nodes like infura?
There was a problem hiding this comment.
Fair point, there would have to be a way to make the tx fee worthwhile, but to prevent malicious behaviour.
There was a problem hiding this comment.
@Arachnid The fee would be going (presumably) to the client developer, not the node owner, unless the node owner hacks their client to set themselves as the client author.
|
|
||
| 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. | ||
|
|
||
| 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 transactions in a block and 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. |
There was a problem hiding this comment.
Can you elaborate? Why are these figures relevant?
There was a problem hiding this comment.
Well, you need to think about the amounts that you would set as a reward, so rather than pulling figures out of the air, data analysis is necessary.
There was a problem hiding this comment.
I know; I'm asking why the number of transactions in a block is relevant to deciding that figure.
There was a problem hiding this comment.
Ah, you're right, it isn't relevant. The transaction fee can be calculated in the same way as gas costs are calculated for miners now.
There was a problem hiding this comment.
I updated this with bc58bef.
True, the EIP didn't address how to prevent that, and there should be something to prevent all possible forms of maliciousness. You could process the transaction rewards after the block is verified by other full nodes, and prevent miners from being able to verify the transactions in their own blocks, both of which are points that I've added to the EIP. One problem with this that I just realized 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, which would add additional complexity to the protocol. |
…dator 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."
|
My original thinking (note: I realize my thoughts do not paint a complete solution) was that the fee would come from the transaction submitter. Perhaps charged as a flat rate or percentage of gas or something. Thus, miners do not benefit from filling blocks with their own transactions as at best they would break even. |
|
That's true, but I was thinking that an in-protocol mechanism would be a more decentralized way for the client to operate, since anyone can invest in it, not just VCs, angels, accredited investors, institutional investors, etc. |
|
Anyone can donate to an open source project right now, though, without needing an in-protocol mechanism for it. |
In my experience (and some amount of opinion) "just fine" here means "functions" at best and " functions sometimes" on average. In my experience, OSS rarely (never?) delights customers. This is in comparison to projects with an actual business model that often delight customers to the point of excitement at rumors of upcoming features, products, etc. Some of this can be accounted for by marketing, but I believe a large portion of it is due to proper incentive alignment between customer desires and R&D spending. As a customer, I tend to prefer software/solutions I can pay for because they tend to have better UX (using the term UX broadly here) than free (OSS) alternatives. |
|
There is a tradeoff. Higher fees means you may cut out poor people and people who just don't want to pay fees. But if a laptop can run a full node and get paid for it then that would offset the fees through usage. Full nodes do provide a security benefit, so the total fees given could at least be some fraction of this benefit. Fees that go towards client development incentivise a higher quality client. To me, I think it makes more sense to internalize costs as much as possible: for computation, storage, bandwidth, I/O, client development, running full nodes, mining/validating, etc. You avoid a tragedy of the commons through externalizing costs. The more you internalize costs, the more sustainable it is, and the less you rely on rich people being generous, etc. (Although, getting philosophical, ultimately you can't force rich people to be generous, they have to do so out of the kindness of their hearts.) |
|
Regarding rewards for full nodes, in the draft phase 1 sharding spec proposers acting as full nodes have rewards for proposing blobs (without execution) or later in phase 3 transactions (with execution) to be included into collations/blocks. So that would help. |
|
@Arachnid I keep getting the same build error: I have made several changes to the header as you can see above to try to get the build to pass. |
|
It won't pass until an EIP number is assigned. Please use 908. |
|
You'll need to rename the file to eip-908.md, too. |
…ent from the original PR. ethereum#908
* Add Github usernames * Remove about.me link from triangular brackets * Add @ before usernames, also note the previous commit was adding content from the original PR. #908 * parentheses instead of triangular brackets: (@githubusername) * replace and with ,
…eum#908) * Create eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update and rename eip-Reward-full-nodes-validating-tx.md to eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Quotes for Micah * The amount of computation to validate a transaction will be the same as a miner... * Add comments on Micah's suggestions and give further specification details * Further commentary on transaction fee amount for full nodes vs miner tx fees * Add "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." * he user agent would contain the information needed to send an amount of ETH to the full node and the client, which are the addresses of these parties and the amounts to add. I think full nodes would need to add to their set up to add the address to receive ETH after validating transactions. These fields could be read-only, or immutable, so that someone can't overwrite them with another address, thus preventing one possible attack. * Add a missing T * Update frontmatter * Comment out implementation, add backwards incompatibility * Update the specification, rewording and moving content * Update the header, Test Cases and Implementation * Update eip-Reward-full-nodes-and-clients.md * Chamge the category to Core * to be assigned => <to be assigned> * discussions-to: https://gitter.im/ethereum/topics/topic/5ac8574227c509a774e7901a/eip-reward-full-nodes-and-clients * Move around fields in the header * Add an extra line to see if that will get the build to pass * Assign eip number 908 * Rename eip-Reward-full-nodes-and-clients.md to eip-908.md
* Add Github usernames * Remove about.me link from triangular brackets * Add @ before usernames, also note the previous commit was adding content from the original PR. ethereum#908 * parentheses instead of triangular brackets: (@githubusername) * replace and with ,
At the moment there is a concern that there are insufficient incentives for clients to be developed and used, as well as for full nodes. Clients are essential for the Ethereum ecosystem, while full nodes add security, so there should be sufficient incentives to build and maintain both.
Note that this proposal is not fully specified, e.g. exact reward amounts and implementation details. Discussion began on Gitter and at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239/20. Further discussion here can be had on whether to reward clients and full nodes for validating transactions on-chain, and how exactly.
State channel proposals (related but outside the scope of this EIP)
A state-channel payment proposal is here by Ricardo Schmidt (@3esmit):
Additionally Vitalik also suggested using state channel payments for light clients to light client servers to get information such as receipts more quickly:
It would be good to weigh up the pros and cons of having an in-protocol reward mechanism vs state channel payment mechanisms. State channels have the benefit of being faster, but are also less secure than on-chain transactions. The security risk can be offset by mechanisms such as insurance and bonded payments. At any rate, any state channel payment proposals are outside the scope of EIPs, so discussion here can be limited to this particular EIP.