Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP: Reward for clients and full nodes validating transactions #908

Merged
merged 40 commits into from Apr 7, 2018

Conversation

Projects
None yet
5 participants
@jamesray1
Copy link
Contributor

commented Feb 28, 2018

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):

Maybe we could use a payment channel for buying state reads from full nodes, just like we need to pay gas for writing in ethereum state, full nodes could earn gas for providing the response to nodeless clients. We could have some judge system, like iExec is doing for offchain computation, so if one node sends invalid (signed) response, other could protest and information could be checked inchain (or through judges), if it was indeed a bad response than signer of bad response is penalized somehow (maybe a stake is required for participating).

Additionally Vitalik also suggested using state channel payments for light clients to light client servers to get information such as receipts more quickly:

[Commenting on Micah's proposal]: This seems like you’re just suggesting the idea of creating a client that charges users for every transactions they send with it, and hoping that most users don’t change the default (they quite possibly won’t if the fee is significantly less than the miner fee). That seems reasonable to me if users are willing to accept it. Another approach would be for the developers of the client to run their own light client servers, and have a light client protocol that uses channel payments to these servers to get information (eg. receipts) faster. There are plenty of microscopic goodies that you can provide and charge for of this form.

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.

jamesray1 added some commits Feb 28, 2018

@jamesray1 jamesray1 changed the title Create eip-Reward-full-nodes-validating-tx.md Create eip-Reward-for-clients-and-full-nodes-for-validating-txs.md Mar 1, 2018

@jamesray1 jamesray1 changed the title Create eip-Reward-for-clients-and-full-nodes-for-validating-txs.md EIP-Reward-for-clients-and-full-nodes-for-validating-txs.md Mar 1, 2018

@jamesray1 jamesray1 changed the title EIP-Reward-for-clients-and-full-nodes-for-validating-txs.md EIP Reward for clients and full nodes validating transactions Mar 1, 2018

@jamesray1 jamesray1 changed the title EIP Reward for clients and full nodes validating transactions EIP: Reward for clients and full nodes validating transactions Mar 1, 2018

jamesray1 added some commits Mar 2, 2018

@Arachnid
Copy link
Collaborator

left a comment

I'm concerned this would encourage miners to spam the chain, or at least fill any unused space in blocks, since it allows them to issue extra ether at no cost to themselves.

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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Mar 2, 2018

Collaborator

Validating a transaction requires executing it, just like the miner did.

This comment has been minimized.

Copy link
@jamesray1

jamesray1 Mar 2, 2018

Author Contributor

OK.


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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Mar 2, 2018

Collaborator

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?

This comment has been minimized.

Copy link
@jamesray1

jamesray1 Mar 2, 2018

Author Contributor

Fair point, there would have to be a way to make the tx fee worthwhile, but to prevent malicious behaviour.

This comment has been minimized.

Copy link
@MicahZoltu

MicahZoltu Mar 2, 2018

Contributor

@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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Mar 2, 2018

Collaborator

Can you elaborate? Why are these figures relevant?

This comment has been minimized.

Copy link
@jamesray1

jamesray1 Mar 2, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@Arachnid

Arachnid Mar 2, 2018

Collaborator

I know; I'm asking why the number of transactions in a block is relevant to deciding that figure.

This comment has been minimized.

Copy link
@jamesray1

jamesray1 Mar 2, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@jamesray1

jamesray1 Mar 2, 2018

Author Contributor

I updated this with bc58bef.

jamesray1 added some commits Mar 2, 2018

@jamesray1

This comment has been minimized.

Copy link
Contributor Author

commented Mar 2, 2018

I'm concerned this would encourage miners to spam the chain, or at least fill any unused space in blocks, since it allows them to issue extra ether at no cost to themselves.

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.

Add "One problem with this is that a miner could run a full node vali…
…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."
@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

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.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Apr 3, 2018

Anyone can donate to an open source project right now, though, without needing an in-protocol mechanism for it.

@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

The open source world is full of large, mature projects that don't have integrated funding mechanisms. They do just fine through existing means of sourcing funds.

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.

@jamesray1

This comment has been minimized.

Copy link
Contributor Author

commented Apr 3, 2018

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.)

jamesray1 added some commits Apr 5, 2018

@jamesray1

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2018

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.

jamesray1 added some commits Apr 7, 2018

@jamesray1

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2018

@Arachnid I keep getting the same build error:

  Liquid Exception: Liquid error (/home/travis/build/ethereum/EIPs/_includes/eiptable.html line 11): comparison of Array with Array failed included in all.html
jekyll 3.6.2 | Error:  Liquid error (/home/travis/build/ethereum/EIPs/_includes/eiptable.html line 11): comparison of Array with Array failed included 

I have made several changes to the header as you can see above to try to get the build to pass.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Apr 7, 2018

It won't pass until an EIP number is assigned. Please use 908.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Apr 7, 2018

You'll need to rename the file to eip-908.md, too.

@Arachnid Arachnid merged commit 0d658e9 into ethereum:master Apr 7, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jamesray1 jamesray1 referenced this pull request Apr 10, 2018

Merged

Add Github usernames #990

jamesray1 added a commit to jamesray1/EIPs that referenced this pull request Apr 10, 2018

Arachnid added a commit that referenced this pull request Apr 11, 2018

Add Github usernames (#990)
* 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 ,

Arachnid added a commit to Arachnid/EIPs that referenced this pull request May 2, 2018

EIP: Reward for clients and full nodes validating transactions (ether…
…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

Arachnid added a commit to Arachnid/EIPs that referenced this pull request May 2, 2018

Add Github usernames (ethereum#990)
* 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 ,

jamesray1 added a commit to jamesray1/EIPs that referenced this pull request May 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.