vipnode / vipnode.org

Connect instantly with your Ethereum Light Client to a premium vipnode.
https://vipnode.org/
MIT License
45 stars 6 forks source link

v3 ideas #13

Open shazow opened 6 years ago

shazow commented 6 years ago
  1. Remove trust from the pool operator:
    • State Channels: Use direct state channels from light clients to full nodes for payments, instead of trusting pools to track balances and disburse payments periodically. This would reduce the trust surface of pools to be matchmakers.
    • (Maybe simpler alternative?) Use signed micropayment messages that bounce from the client -> host -> pool operator, which get merged on-chain eventually. Kind-of ghetto payment channels.
  2. Pool RPC Frontend: Pools can provide a JSONRPC proxy that load balances the member pools, similar to Infura or MyCrypto etc, but each pool becomes a mini-Infura.
  3. Something with stateless clients, if that's going to be a thing anytime soon?
  4. Extended API gateway, maybe for something like https://thegraph.com/
ligi commented 6 years ago

wonder if you had the chance to read up on INCUBED - https://blog.slock.it/slock-it-iot-layer-f305601df963

shazow commented 6 years ago

@ligi That does look interesting, and definitely a lot of overlap. Do you know what the status of the project is? Is there a working prototype/code/anything (I am having trouble find it)?

Also, I wonder if the slashing risk would exceed the micropayment incentive?

One challenge I've run into as I'm designing the payment component of vipnode is that N:M micropayments can be economically nonviable for sufficiently small values.

Example: Say I'm a client and I talk to 20 hosts over the span of a month. In total, I spent $5 this month which is a non-trivial total amount to settle on-chain. But at the same time, each host has only received 25 cents on average--maybe some hosts received 5 cents, some hosts received 75 cents, who knows what the variance is. If you have a 5 cent balance in a 1:1 channel, settling that on-chain starts to hurt when the fees could exceed it. A similar situation happens on the host side: You might earn $100 from serving 400 clients over a month, but many channel balances could be tiny.

One solution is to use collateralized hubs to aggregate micropayments (similar to what Lightning Network does), but this substantially increases the complexity and the total amount of collateral required. Another hypothesis is perhaps we can use zero-knowledge proofs as substitutes for collateralized hubs, but the tooling and research for this is still early.

The v2 vipnode solution essentially uses the pool as a trusted non-collateralized hub, so the number of on-chain transactions is fairly efficient by sacrificing trustlessness. For v3, I'm not sure what the best path forward is yet.

ligi commented 6 years ago

@CJentzsch told me at dAppCon that a release is planned for DevCon 4

Unfortunately I don't feel comfortable yet to answer your questions - I really want to dig in deep when the code is released. So far I only have seen one talk about it ( https://www.youtube.com/watch?v=_vodQubed2A ) and was reading the blog post from above. In the talk he was mentioning the payment problem and mentioned probabilistic micropayments - but to be hones I was hearing about this concept the first time in this talk - another thing I will need to read up on then ..

shazow commented 6 years ago

@ligi That is interesting indeed. Please continue sharing what you learn!

ligi commented 6 years ago

will do