-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
wonder if you had the chance to read up on INCUBED - https://blog.slock.it/slock-it-iot-layer-f305601df963 |
@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. |
@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 That is interesting indeed. Please continue sharing what you learn! |
will do |
The text was updated successfully, but these errors were encountered: