Incentives for running full Ethereum nodes

Another potential revenue stream under stateless clients is to have an archive service with archival data servers, however Swarm would compete with this, although the client could somehow integrate Swarm so that anyone can provide the service and if there was a token for the client the service could be transacted with this token, however I haven’t looked into how Swarm works in detail and whether there are any revenue streams there.

Hi Frank, if you see a way to improve something in documentation, feel free to make an edit (e.g. for a wiki), pull request, or raise an issue with the maintainers/author. That may help you to reinforce your understanding of the content in question, and help future readers.

This idea has been thought of and raised elsewhere, but a problem is that miners/validators could do a long range attack by creating a few contracts that they know a fast way of validating (or they’ve cached it), then validating them.

2 Likes

There is the Beige Paper initiative that may help.

2 Likes

I see … Great point!

In the scheme proposed though it seems that a block proposer will have less incentive to include fake-self-made-easy-to-validate transaction because she will not get paid transaction fees. It seems to be a tradeoff - if you include a fake transaction, than it is easy to validate but you will not get paid transaction fees, only the block reward, because you are essentially paying transaction fees to yourself.

as written also in the ethereum-research channel

as i understood it right, any of us could propose with an
eip to incentivise node-runners more active,
as somebody is worried about the quality of diversity in nodes
he would invest into a smart contract
dealing exactly this question-

something like “as you want to be rewarded for running your node,
subscribe your node here, with an ethereum-account for your reward”-

then the contract could “look” over all active nodes,
like

node is alive since (14-7-2days), score1
connections acceptance rate (10-20-100),score2
peering speed (kb, MB, GB), score3
reliance (just 4 hours per day, 8 hours, 24/7, 99,99%),score4

as there is no real time monitor for the “distribution level” of the chain,
we could work it out with dedicated submission to a certain “reward”-contract (s.a.) first,
and if it works like intended
to “scaled-up” this certain idea,
which is possible and easier to realize with code-

why overfreighting the etherum-protocoll itself, when information about
the peering node is continouusly given to peering “partners” by standards.

The ethereum protocoll standard defines some of the above mentioned “measure mechanisms”-
why not working with existing structures and information using the smartest techniques with smart contracts-
because if there is such a need like most of us describe, that we like fast peering,
fast “delivering” nodes- the smart contract will be subscribed (and paid) -
to avoid “fraud” in any way there could “put” be a kind of “randomization” into
payout-mechanism-

whereas i am not a coder but very experienced in running “sync” nodes with parity
as proven sometime with posting a picture to some people or into https://github.com/roninkaizen/recipes
there is a strong “wish” for transparency on rewarding, if there is a “real” need for it.

To be honest, it would be fine to get sort of “rewarded” for what people like me do-
the idea behind decentralization and scalability with ethereum is to
spread and interact with a certain “system”.

as we concentrate ourselfes in understanding decentralized networks it is about us to find
stable solutions to be defined by smart people.

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

2 Likes

True, but the block reward is still a significant incentive as of the moment—3 ETH is not a petty amount. I don’t know what miners receive on average for transaction fees at the moment.

1 Like

Micah I made an EIP here with your proposal as a potential option. I suggest that we have discussion specifically about rewarding clients and full nodes for validating transactions over there, and other incentive ideas such as state channel payments to light client serves can continue to be had here.

1 Like

I suggested payment channels but could be done without it, but I think would be smart to use them, because the answer of the call will also not be safe, so both things relay on a judging mechanism, where for payments we use timelocks as security and the answer we use a verifier contract (that could be able to inchain verify that the result is incorrect. The problem with the inchain verification is that a storage could change in the meantime, so probably a judge system would be necessary. Maybe if the contract proves is equal it does not goes to judging, and if is different then goes to judging?

1 Like

@jamesray1
good to have an eip about it.
@3esmit
the “judging” could be done as well with smart contract measurement,
based on the given parameters from your idea or other parameters suggested

as we talk about stabity, synchronisity (i do not know if the word exist, but it descirbes it best, coming from germany, not knowing better yet, apologies here) and scalability of the ethereum network today,
the best way of improvement&incentivation
should be “plugable and testable”-

as any contract could “measure and decide”
i did not propose the “backward-channel” yet-
described above, the subscriber to a contract could be “kind of rewarded” for his subscription

with activation/renew of the “plug-in” telling the node
a)to measure itself and to update
b)try to peer to some of the fastest node around.
c)report the results of the (peerchecks) changes back to the smart contract (if wanted->reverse quality measurement)

gathering the parts together,
we could have one or various contracts truly measuring the nodes with parameters given-

collecting
as a contract is subscribed, it will “run and measure and decide”
who is running a node, at which quality level and interested in being rewarded for that.

computing
as the above proposed contracts are cross-referring or not, the single “measure”-contract gives out informations gathered and sort of decision “fulfilling certain quality- levels” with yes/no
could be “given” it out to the contract-subscribers,
that is how payment for the measure agent is organzied and how feedback could be directed

refeeding
With such a “structure” running permanently measuring every “subscribed” node,
we see some kind of “quality”-graph different from the various locations on the planet.
this information needs to “flow back” into the ethereum node itself, running geth or any other software is concerned.

as the “subscription” ends for “some” reason, the “plug” is deinitialized and the node operates like before as if “nothing happened”.

as we try to defined standards for rewarding running a node
without deciding (and describing why in detail) how to measure “differences” between A and B
we unfortunately cannot come to better results than we have.

i took part in ethereum because
i saw a strong will and enthusiasm for change-
and i am now more confident,
because this “room” exists.
thanks for that as well.

2 Likes

@roninkaizen interesting ideas, I encourage you to pursue further R&D with them. I think EWasm will help with metering.

We could imagine that those metrics and other smart metrics like that being hard coded on the most popular clients (geth, parity…) and optionally be shown as a public data. This is the easy part (ore not the so difficult part)

The main problem is how the nodes could optionally verify other nodes and being verified as a “good” nodes (according to those metrics) avoiding frauds.

Related: Sharding phase 1 spec (RETIRED)

Passed along to me
https://vipnode.shazow.net

“a friend of mine just launched an amazing tool called VIPNode which allows lite clients to reserve spots on full nodes and the full nodes to get paid for this – right now there are too few full nodes and lite clients sometimes need to wait for hours to get access

Can you please share with developers on your team using lite clients or running geth nodes – they are doing testing now”

1 Like

This seems a bit naive - imho not going to work unless there is a way to measure performance of full nodes that get paid. What prevents me from e.g. doing a man-in-the-middle attack and creating a proxy to an existing node?

1 Like

Hey there, I made vipnode. Haven’t had a chance to catch up on the conversation above yet, but a quick comment on the project: it was just a quick prototype to solve today’s problems. Even though it’s naive, I believe it’s effective today. I don’t feel that a MITM would make the availability of connection slots worse, but it may drive the prices up. If anything, I’d categorize it under “good problems to have” as opposed to some clients waiting hours to connect.

For a future version, I have a design where vipnodes can require a specific ethstats server (for premium clients) which provider nodes can confirm that the client is indeed advertising that they’re being served by the provider. This will allow for more complex billing schemes, like charge-per-use. I believe this will help with the MITM situation. It would also allow for vipnode pools, where any full node can join and start accepting premium clients and earn a proportional income for serving them.

3 Likes

Cross-referencing a suggestion that storage fees could be used to incentivize the running of full nodes:

3 Likes

I think the title of this post should be “Incentives for building clients and running full nodes”. It would be good to continue discussion and development of such incentives.

1 Like

I created a new topic discussing a potential mild incentive for running a full state node (though not incentive for actually sharing access to the data): Incentivizing full state nodes

1 Like