Deprecate light client

[vorot93]

Light client has been marked as experimental for quite some time. It is not used by any major user, per the polls on Twitter and Discord. And most importantly, current light client protocol may be deprecated by Stateless Ethereum.

Light client is essentially a separate client glued into the main codebase which complicates OpenEthereum with additional abstraction layers. Removing it will make maintenance easier and accelerate refactoring efforts.

[emilbayes]

Oh this sucks :( We built a fair bit of tooling around indexing relevant parts of the blockchain using the light client with good success. Especially the pubsub APIs combined with the light client has been of great use.

Here's our list of open source modules:

• Easy wrapper to download and verify the binary: https://github.com/hyperdivision/parity-binary
• Spawn a subprocess with defaults and manage it: https://github.com/hyperdivision/parity-spawn
• Run one-off scripts on the network (think ganache): https://github.com/hyperdivision/parity-run
• Index specific transactions from the blockchain in order: https://github.com/hyperdivision/eth-transaction-tail
• API client that also supports PubSub: https://github.com/hyperdivision/nanoeth

Over the last couple of months this setup has processed more than significant sums of Ethereum and is part of our P2P multisig wallet. The benefit of the light client is that all peers of the wallet can run their own node and query to verify results or index the blockchain themselves. Running a full node on a laptop would be prohibitive.

[vorot93]

@emilbayes Thanks for reaching out!

It’s unfortunate that our past polls did not get enough attention to cover use cases like yours. Note that while deprecated in 3.0.0 it still works albeit with a warning. Please do join our Discord to discuss the future though.

[emilbayes]

@vorot93 I am on discord, but joined on May 5th which may have been after this poll :) I didn't know Gnosis was taking over development, but thought it was under the DAO set up.

The light protocol works well for us, but has some issues, such as the one I filed about getting stuck on forks/reorgs and sometimes peers stop responding. Both can be fixed by restart, but it can be a pain for an online system, eg. you don't know if it's your network or parity/openethereum. There's also a good number of peers that accept PIP queries which is nice, but perhaps this will change with this announcement and as people upgrade.

The major pro of this over Geth was the PIP protocol, but do you know about plans for eg the stateless proposal mentioned above?

[jkilpatr]

I use the light client features as a request proxy RPC server.

Meaning I have lots of devices making lots of requests, but I load balance across many light clients placed in front of an actual full node. This dramatically reduces cloud hosting costs for my usecase.

IMO light client mode should be the default, so that developers can easily build their applications to rely on their own light clients instead of Infura. Using light client mode the $5/mo vm your webapp runs in can just contain it's own light client without ever causing you any issues.

In comparison hosting your own full node in the cloud costs at least $40/mo and requires regular attention to make sure it hasn't run out of space or stopped syncing.

[achal-singh]

@jkilpatr I'm just interested in knowing whether you were able to fetch transaction data (via JSON RPC calls like eth_getTransactionReceipt & eth_getTransactionByHash) through your light nodes, because none of the mentioned calls have ever given me a consistent response, which in my opinion is mainly due to the lack of a full fledged database store of the Ethereum Blockchain in the light client implementation.
I would love to know more about the kind of API calls you were able to achieve through your light nodes. Cheers!

[clearloop]

We are building a chain explorer(only the headers) in rust, really need the light client, it would be nice to separate the light client outside the main openethereum repo instead of depreciating it.

[jkilpatr]

I'm in agreement with @clearloop

And @achal-singh getTransactionByHash works fine, now it does take a lot of trying. We try every 5 seconds for 15 minutes to get a 100% success rate. You can probably do less but just one request won't cut it, the 'eventual consistency' is highly variable and takes significant clock time.

[wesrer]

Accidentally closed this, sorry!