I’d like to start a semi-regular update thread with the participants of our Constrained resource Clients ring. The purpose of these threads is to get a clear idea of what everyone’s goals are and where on the roadmap each project is. With any luck, this will help us find opportunities for better collaboration and interoperation.
Quick recap: We’re talking about Ethereum clients that can run under constrained resource conditions, such as on phones or browsers or even embedded devices.
What I plan to do with these updates:
As the contact person for this ring, I will:
Catalog and mention (or reach out) to founding participants for their own projects’ update.
Once all updates have been posted, I’ll collate action items across teams and follow up.
Repeat every few months (~quarterly?)
Anything else you’d like me to do?
What I’d like from the participants with each update:
Short summary: What is your project and its goal? (This can change over time)
Roadmap now: What is the currently working and available to try?
Roadmap next: What is being worked on over the next few months?
Current challenges and concerns: Do you need help with anything? Are there unknowns you’re accounting for that could be nailed down by another participant?
Participants
To all projects mentioned: Please post an update as described above.
Vipnode is building an economic incentive for running full Ethereum nodes which service light clients. It works by providing a coordinator (a vipnode pool) which connects paying clients with participating hosts.
Roadmap: Now
Beta just released this week. The demo pool is running for MainNet nodes with payments on Rinkeby.
Onboard some users and polish towards a stable release. Getting close!
Integrate with a wallet: The current demo is wallet-agnostic (working with geth/parity) which makes the whole user experience somewhat clumsy. A native wallet integration with vipnode could make the entire onboarding ~transparent.
Reduce trust in vipnode pools: Right now, the trust model of vipnode pools is the same as mining pools: The pool operator can run away with the deposit balance. Need to find a fee-efficient way to do many-to-many microtransactions. Traditional state/payment channels don’t work well here because there could be many pairs with very low balances but a non-trivial total balance.
Challenges and Concerns
Need help finding LES wallets to try integrating vipnode with. (Talking with WallETH and Status, but the more the merrier!)
Need to investigate if the LES/ULC protocol will “Just Work” with Vipnode out of the box. (Any here hints appreciated!)
Need to investigate about integrating the vipnode flow with other “constrained resource clients”. (Do vipnode pools even make sense for Mustekala? Or in3?)
(Any questions/suggestions are welcome, by the way!)
geth node doesn’t work well with just sporadic network connections (a mobile app is mostly offline/sleeping and “wakes up” just for a few minutes at a time).
we would love to hear ideas on how to incentivize both data availability in full nodes and well as adding security through incentivization to the KSN network, please share you’re thoughts here or in the issue above.
scalability of the browser based network
through our preliminary research and experiments have been very encouraging, scaling the network is one of the hardest and most critical parts of this project
LES (Light Ethereum Subprotocol) is the first “light client” protocol for Ethereum. Its most complete implementation is part of the Go Ethereum client (Geth) and this is also where the latest features are first introduced.
Roadmap now
A huge PR has just become ready for review which improves LES server mode significantly:
These improvements and rewrites prepare the servers for incentivized operation by improving performance, making bandwidth control more precise and introducing a private API to control individual client priorities. Though there are in-house plans for introducing an in-protocol payment mechanism, the API is intended to be usable by any project implementing any kind of incentivization or prioritization scheme for LES.
A proposal will also be released shortly that describes a simple and efficient many-to-many payment channel protocol that is based on a probabilistic approach, does not require a complex infrastructure and is easy to integrate into LES.
Roadmap next
The next step is to improve the “server pool” of the Geth light client with more sophisticated server performance estimates in order to be able to compare the value-for-money that different servers offer. These metrics will be used by the integrated automatic server selection algorithm and also exposed through the API to be usable by externally implemented strategies.
Also, the planned payment protocol should be reviewed and discussed. If we find it suitable then we can start experimenting with its implementation soon (the implementation itself is not extremely complicated).
Current challenges and concerns
We should definitely improve communication with other teams and find ways to converge efforts (hopefully this forum will help). Finding efficient ways to follow each other’s progress and catalyze collaboration is an important meta-problem itself because human attention capacity is limited and the number of great projects is growing quickly.
@dryajov I think that’s a good idea, I’m kind of waiting until all the participants respond before we plan further. I wanted to give everyone a chance to become aware of the different projects and do some offline research. I’d love to schedule a call in the new year though.
We (Infura) don’t have any explicit CRC projects we’ve gotten to the roadmap stage on yet, but are hopeful that CRCs can help offload some of the reliance on our RPC endpoints. We’re very interested in supporting these efforts, and in providing infrastructure for CRC-related services, and hope to have some more CRC-related related work we can announce later.
We are also targeting rolling out eth_getProof support later this month, and are particularly interested in more ways we can facilitate validation for CRC clients.
Denode is an incentive mechanism for running full nodes. It aims to provide both a free and a subscription-based service coordinated through a DAO. There is also a p2p layer that will be used to join the network.
Roadmap
I am currently working on the p2p layer based on libp2p. @ansermino is working on the DAO side of things. We’re finishing up our research and ideation and beginning to implement. We would like to have an alpha release sometime in the next few months once a bit more work has been done.
Challenges
Assignment of users to nodes, will likely try to solve this by having users connect to groups of nodes. Another issue that hasn’t really been solved is how to validate full node state. A way to validate the node could be to ask for some info only a full node has, but there isn’t a way to determine whether they got this info from another node or not.
As well, I think we definitely need to communicate more with other teams to see how we can collaborate. Definitely would be interested in having a call with everyone here at some point
Anyone have suggestions for tools to coordinate scheduling for a distributed group like us? Maybe the week of Feb 18, right after ETHDenver? (I won’t be there but if anyone else is going, feel free to meet up!)
It’s for the week of the 18th, times are in PST (California) so please adjust accordingly. I’ll DM/post a hangout link once we have something resembling consensus.
(Suggestions very welcome if there’s a better way to do this.)
Alright, I’m calling it: Thursday Feb 21, 2019 at 10am PST.
We have at least three people OK that time, I’ll try to coralle a couple more, but let’s see how this goes.
Please set a reminder for yourselves, I’ll post a call link here just before and/or I’ll try to send calendar invites for people whose emails I have. Feel free to DM me your email to get an invite!
