Constrained Resource Clients: Dec 2018 Update

#1

Greetings!

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.

If you’re hit with a link/mention limit, format the excess ones in plaintext.

If you’d like to join this list, please go ahead and post your update and I’ll make sure to explicitly include you next time.

(Won’t let me post with everyone mentioned, so some people aren’t.)

#2

I’ll go first,

Short Summary

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.

Roadmap: Next

Roughly in order of priority:

  • 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!)

#3

(had to trim links due to “only 2 links/post” rule)

Short Summary

[Status] — a mobile Ethereum OS for iOS an Android.

Roadmap: Now

This week:

Roadmap: Next

  • Bugfixing, a lot of it.
  • ULC mode.

Challenges and Concerns

  • Initial sync speed of LES
  • Battery consumption on sync
  • 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).
  • …and many more bugs to squash
#4

Short Summary

mustekala is a light client and a libp2p based network for browser based or otherwise resource constrained environments.

Status

  • We just announced the project at devcon4
  • Have an initial prototype that demonstrates overall pipeline
    • can query account balances
    • can execute vm calls and run contracts in browser
    • retrieval and parsing of slices
      • new slice related RPC calls in full clients
      • slice propagation in the libp2p based KSN network
    • initial implementation of the KSN network and high level pubsub protocol

Roadmap

  • build out the KSN network and deploying to a subset of live users (metamask)
    • currently we have a scaled down version running over real browser nodes
  • tuning and scaling KSN
  • cleaning up and polishing the PoC

Challenges and Concerns

  • Incentivization in the KSN network as well as full nodes - https://github.com/MetaMask/kitsunet-docs/issues/4
    • 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
#5

Short summary

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.