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:
2 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.
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
It seems relevant to mention a non-profit open source project Jordi Baylina is pushing called DAppNode, which makes it easy for someone to run their own personal server and host various P2P nodes.
https://alpha.giveth.io/campaigns/OcKJryNwjeidMXi9
The idea here would be that there are lots of DApps that could benefit from a decentralized node set up and if DApps had an easy way to get their users to install these nodes, they could create various incentive mechanisms and Ethereum would benefit as well with more nodes (that the dapps would need to run their helper services).
4 Likes
I think a problem with extra-protocol approaches for incentivizing full nodes is that another client can undercut with no or lower fees. But if it can be made to work, by all means! If the nodes have a niche purpose e.g. for specific dapps, then that would help to avoid competition.
I’ve updated EIP-908. I would be interested to see what @vladzamfir has to say on incentivizing verifications, propagations and storage, since he works more with long-term approaches.
I think there’s an alternative approach that could be taken as well, which would incentivize end users to have more of a reason to use a node without needing to take the time to explain the payment mechanisms to end users: larger, more full fledged applications built on the network.
Having larger applications would mean that the time saved from downloading data from another machine or server would be non-negligible, and could provide other benefits such as the ability to use portions of applications that don’t need an active network connection from your own node by reading data from it.
I just developed a dapp that serves a full library. Using this dapp as an example, if one were taking a plane to travel and finished a book they brought with them, if you ran a local node on your computer you could pull another book from this library without an active network connection. Of course, when you weren’t traveling, you would want to keep your node in sync to ensure you have as many books as possible. Obviously data could be pulled whenever network connections are interrupted too, which could allow dapps that serve information like this to become really useful in areas with high latency or frequent interruptions as well.
Benefits like this could extend to other pieces of software that benefit from updating data, but also function fully solely with existing data.
A really interesting concept would be the development of node software that runs on a cell phone. You could set it to only sync when it’s on wifi or charging at night or something like that. This could allow users to use apps that wouldn’t need minute to minute data, but would still be useful to have and be able to use without a connection, or without wasting your data.
I would like to just echo the sentiment that there are serious problems trying to run a back end node. Here are some examples:
- I have to restart the geth daily that ships with Emerald Wallet or the blocks stop syncing
- I tried running geth in vain with Ethereum for about 6 months, and constantly had memory leaks/bloats, so I finally switched to Parity
- Parity still occasionally uses up all system memory, and so does Mist/Eth wallet (which is also buggy)
- The latest version of parity 10.6.4 does not work well with Mist wallet anymore, so I switched to Parity UI Browser/wallet
- Parity is now going to a very low node connection count daily, and never used to…
Anyway, the point is, I agree it should “just run” like any server service does like DNS,DHCP, etc. I am sure some of these problems are localized, but for the most part they are not as others also have these issues.
I am not sure what I can do to help, but I can relate to the frustration voiced by the author as someone trying to keep full nodes running since 2016.
3 Likes
Dear chipbit,
sorry to hear about your experiences with ethereum.
since 01.2017 i am running continously 3-4 parity nodes 24/7 in various constellations without
any trouble.
Meanwhile some data-center nodes also came to them, little tricky, but after a practise of 2 days with any “big-player” like amzn and g.gle as well as “smaller” carriers even that worked fine until today.
the version you mentioned which is unfortunately outdated-
you could give parity as node software in combination with it`s new parity-ui-
a chance when you are interested in disc-space keeping.
as some of the described mem-usage questions were found better working since weeks.
depending on a standard network connection with 8MB/s
and a 4core/4GB/1100gb (archive +Fat +Trace) discspace free- system
it still should be possible to run full-nodes as described by
afri (https://dev.to/5chdn/the-ethereum-blockchain-size-will-not-exceed-1tb-anytime-soon-58a) -
as you need assistance or help
i personally found their gitter channel always very helpful
https://gitter.im/paritytech/parity
as i exactly try to work like you
i personally stopped working with geth since hf which was also in 2016,
tested and worked out on any other node software until late 2016
and came to the personal sort of “decision” to deep-learn about parity to have and actively operate at least one node.
nice to meet you!
we do allmost “the same”- let`s exchange in detail, what to do and how to gain better experience for you again
see you on gitter?