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

v3 ideas #13

Open
shazow opened this Issue Jun 26, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@shazow
Member

shazow commented Jun 26, 2018

  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

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 2, 2018

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

ligi commented Aug 2, 2018

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

@shazow

This comment has been minimized.

Show comment
Hide comment
@shazow

shazow Aug 2, 2018

Member

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

Member

shazow commented Aug 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 2, 2018

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

ligi commented Aug 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@shazow

shazow Aug 2, 2018

Member

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

Member

shazow commented Aug 2, 2018

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

@ligi

This comment has been minimized.

Show comment
Hide comment
@ligi

ligi Aug 2, 2018

will do

ligi commented Aug 2, 2018

will do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment