Access to Ethereum data using web browsers

[fjl]

It would be nice to access Ethereum data in a peer-to-peer way using a web browser. This is not possible today, and Ethereum service providers fill this role instead.

The Ethereum network and its full nodes use the eth protocol, and this protocol is inaccessible to the browser by design. This is because eth is a tit-for-tat system. Browsers cannot give any meaningful data back, and can generally not serve other clients in a meaningful way. There are workarounds for everything of course, but I'm quite happy we don't have to deal with browsers in the Ethereum core network.

We also have les, which is a client/server protocol and includes incentives. LES should work in the browser, but doesn't.

In its current form, LES is incompatible with browsers because it uses the RLPx protocol. But LES doesn't need RLPx and would work just as well over HTTP. It would be nice to have an implementation and spec for LES over HTTP, specifically using HTTPS.

The LES specification doesn't define how servers are actually found, it just describes the interaction between a single client and server. This is OK for the RLPx-based version of LES because it can use the discovery protocols we have. But those protocols are also incompatible with the browser. I think the right solution for this problem would be a server discovery protocol specifically for browsers.

[fjl]

A practical system which has already solved these issues is IN3 (formerly known as Incubed). Their system is different from LES because it removes the need to synchronize and validate the header chain, focusing only on the retrieval of state and receipts via HTTPS.

In IN3, access to the data is provided by HTTP servers which are registered in a smart contract. The servers receive payment in some way and also have a deposit, which can be slashed when the server provably misbehaves. Slashing is performed by other servers with access to the real chain.

Discovery of the servers is handled by performing a blockchain query through 'bootstrap nodes', giving the client access to the complete list of all servers.

[acolytec3]

In its current form, LES is incompatible with browsers because it uses the RLPx protocol. But LES doesn't need RLPx and would work just as well over HTTP. It would be nice to have an implementation and spec for LES over HTTP, specifically using HTTPS.

I know this is an old issue and probably not something worth chasing that seriously but the EthereumJS client does have a experimental "devp2p over libp2p" implementation that allows for exactly this sort of thing (and even this example on how to set it). It's a somewhat neglected part of our code base and I'm not aware of anyone using it actively but the proof of concept is done and works somewhat well.

[fjl]

I know that exists, but it's not a good solution.

[p-shahi]

Does the option exist for devp2p to move off of RLPx and utilizes libp2p's WebTransport or WebRTC (for browser-to-server and browser-to-browser connectivity)?

[arnetheduck]

@acolytec3 have you documented the "devp2p over libp2p" solution somewhere?

[acolytec3]

I'm not 100% confident it works right now (it did last summer which is the last time I touched it) but here is the write-up for how to get it working in the EthereumJS client.

The actual code is here for the browser specific build components for our clients and then here for the libp2p network layer stuff. None of this is actually devp2p specific since that's all just message layer stuff but the networking pieces are all found in here.

Note, our implementation predates my time on the team and hasn't been touched much in a long time. The libp2p version we're on is quite out of date and we have some big technical blockers related to Javascript :tm: that we need to take care of before we can update the code to modern libp2p.

[fjl]

https://drpc.org is another recent contender