SPV light-client support

[bobsummerwill]

Greetings!

You may have seen the video I made - https://www.youtube.com/watch?v=ghmSLvViqEo - of ethereumj-android running on my Samsung S6? That was just a step on my own path towards making a DAPP on the Samsung Gear S smartwatch (http://www.gsmarena.com/samsung_gear_s-6620.php) which is a pure HTML5 environment. That DAPP will be using web3.js at first and then ethereumjis-lib.

My first step will be to build out my functionality on the Gear S just using web3.js to communicate to a full node running on my Mac. I had hoped that node could be an ethereumj-android running on my tethered S6, but Jarrad tells me that ethereumj is currently missing json-rpc support, though that is coming very soon too (his team will be building that). But when I have a working app on the watch my real aim is to untether it - because the Gear S has Wifi and 3G data - by running a light client directly on the watch.

So ...

Phase I - Build UX on the watch, using web3.js to connect to a full node on my Mac via json-rpc Phase 2 - Switch to using web3.js to connect to an ethereumj-android service process running on my BLE tethered S6, still via json-rpc Phase 3 - Cut the tether, and use ethereumjs-lib in "SPV mode" to connect to the Ethereum network directly. The light node would be running in-process of my HTML5 app, right inside the web runtime (which is Webkit2) on device. That app will have access to 3G and Wifi connectivity.

Has any effort already been made towards SPV support in ethereumjs-lib? Or, indeed, in any of the other clients?

Any existing plans? Do you have a decent feel for that what might "smell like"? How hard it will be? How long it might take? Where it might fall in a priority list compared to other backlog items you may have?

How can I help you guys to achieve that aim?

George Hallam had suggested that it was probably DEV Grant worthy, and I have been chatting away in the dev grants forum for a couple of weeks now. As it stands, though, I cannot start on the application process because I have no "work in progress". I don't need the money, and would only tap into that process if the money could be used to accelerate the process (which would probably mean me spending the money to hire a contractor).

I can only contribute to the aim myself sporadically in the gaps which my day job and kids leave me. The DEV grant could help accelerate that process, so maybe YOU apply for the dev-grant, and have the contractor work directly on web3.js. But we will need to get some work-in-progress happening before the grant process can start.

Let's do this :-)

[bobsummerwill]

Previously mis-logged in web3.js, in ignorance. See https://github.com/ethereum/web3.js/issues/237

[wanderer]

Hi Bob!

Has any effort already been made towards SPV support in ethereumjs-lib? Or, indeed, in any of the other clients?

Python has. We have recently made changes to the trie to generate proofs but there is no API exposed yet.

Where it might fall in a priority list compared to other backlog items you may have?

Not high right now but, my priorities are driven in part by what you guys want ;)

How can I help you guys to achieve that aim?

There is several things you could do on the watch now 1) See if you can get this working https://github.com/ethereum/ethereumjs-tx on the watch. 2) then see if you can broadcast the tx using https://github.com/ethereum/node-devp2p

Also if you want to help with the SPV implemention that would be really cool. I would just look at how python did it and copy from there. You will need to know a bit about the trie so Feel free to post questions.

[sundbry]

Would love to be able to connect to the network just from a mobile! (Without proxying through!)

However, are you sure about phase 3, implementing the SPV API all in Javascript? I think the architecture would be better off keeping the RPC server present, allowing room for wallet apps etc to provide features & security in a native app that provides an RPC server.

Only if you wanted to make a wallet app in pure JS, then that would be very cool, and you should go for it. I don't think a browser could run it without a raw TCP sockets API- but apparently that's a work in progress.

[wanderer]

Yep you would need at least raw UDP or raw TCP. You could also you webRTC have have 'bridges' to the rest of the network. Going back to UDP. @mvayngrib is doing some cool work with http://jxcore.com/ which might be relevant here.

However, are you sure about phase 3, implementing the SPV API all in Javascript?

Yes implementing the SPV API all in Javascript/node.js is feasible. Weather it has advantages over other implementation depends on your usecase.

I think the architecture would be better off keeping the RPC server present, allowing room for wallet apps etc to provide features & security in a native app that provides an RPC server.

Depends on several things. How much is your app doing? if its just broadcast a couple of transaction to a single contract and reading the state of that single contract, you might you might not need the full RPC server. On there other hand if you have a general dapp browser that accesses many contracts then a RPC server makes sense. also storage/processing power should be considered. If the device specs are the constraining factor, the most minimalist thing you can do is just form and sign tx's on the device then given them to a server that you trust will broadcast it. And also use that server to read ethereum's state.

[bobsummerwill]

Tizen has additional JS APIs for all sorts of things which haven't been standardized yet. So does Firefox OS. I would hope these companies and are others are involved in the working groups aiming to standardize all this stuff.

https://developer.tizen.org/dev-guide/2.2.0/org.tizen.native.appprogramming/html/guide/net/sockets.htm

https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket

So I think that a standalone JS wallet on Gear S with no smartphone tether should be workable. And the same could run on the Samsung Z1 Tizen phone, and on Firefox OS phones. Just would need conditionals.

[bobsummerwill]

There is several things you could do on the watch now 1) See if you can get this working https://github.com/ethereum/ethereumjs-tx on the watch. 2) then see if you can broadcast the tx using https://github.com/ethereum/node-devp2p

Also if you want to help with the SPV implemention that would be really cool. I would just look at how python did it and copy from there. You will need to know a bit about the trie so Feel free to post questions.

Hokey dokey. I will start exploring these paths. Best wishes, guys!

[ethers]

hi @bobsummerwill how is the watch going with above?

[bobsummerwill]

Hi there! Practical coding progress would be ZERO. Progress of exploration of problem space, blogging and meeting people significantly better.

Main change since I started this thread is that Samsung has opened up Native API as well as Web API for the forthcoming Gear A circular watch, which will likely be revealed at one of the forthcoming Tizen events either in India or China (July and August).

What that means for me is that my client will now be C++, not JS, so that is now where I will take myself. Started with web3.js in ignorance, then ethereumjs-lib, and now I will head to cpp-ethereum to bother Gavin and friends!

No doubt I will be back in Web world later too :-)

[bobsummerwill]

See https://github.com/ethereum/cpp-ethereum/issues/2479

[kumavis]

@bobsummerwill -- awesome bob keep up the good work!

[bobsummerwill]

Hopefully, if we get SPV going in cpp-ethereum then the learning process and algorithms can be applied easily enough into the other clients. All the best, guys! Catch you around.

[bobsummerwill]

See https://gitter.im/bobsummerwill/ethereum-light-client for chat channel about light client support for Ethereum.

[bobsummerwill]

Hey @wanderer! Has the Python client progressed on Light Client since July? I'm assuming that ethereumjs-lib has not, and I am unaware of any work in the C++ Client.

Just chatting to @kumavis and looking back :-)

[bobsummerwill]

From what I can see, everybody is leaving the go team to implement (merging/refactoring ongoing) the first LES protocol, and then we can all try it out. Other clients would implement from there.

[bobsummerwill]

So geth is PoC for LES.