You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just came across this repo and I'm super excited about this it. It's what I was looking for for a while. I explored similar ideas in the past [1, 2].
I was wondering: Are there specific plans for the structure of the p2p network already. Since most of my problems with building scalable (web) dapps resulted in using centralized infrastructure for querying and caching Ethereum data, I'd find it quite useful to span the network across the web too. To serve my dapp today, I'm having to rent a 110 EUR Eth full node. I do so in the cloud :(
Hence, in most of my prior work, I looked mostly into two domains:
What type of data requests can be cached by trusting the full node? I attempted to build a browser-based service worker cache and identified some RPC methods that return immutable data [2]. I'm now realizing that technically most eth_calls could also be cached, assuming the latest tag is always replaced with the block number.
How could the number of requests to an Ethereum full node be reduced on the overall network? Yes (1) caching is one solution. But then also I thought that syndicating state data via webtorrent would be interesting.
I haven't done much research on (2), but I'd imagine that if enough nodes ran a p2p webtorrent network that is compatible both for system-level applications and browsers, much of the traffic that's currently directed to e.g. Infura could simply be served through torrent. In [1] I did a tiny tec spike to see if RPC requests could be treated as single webtorrent links - and concluded it was possible.
I'd find it quite exciting if web browsers became part of the Ethereum network. Suddenly, not only deliberate network participants would help to host the network: but all users too. Surely, browsers wouldn't raise to the service quality of dedicated servers. However, I imagine still lots of load could just be distributed.
Anyways, these are just some ideas that I have had in the past and that I wanted to contribute to this repository. I'm happy to iterate on them further if there's interest. Also: since this issue isn't really actionable, feel free to close it.
Hi,
I just came across this repo and I'm super excited about this it. It's what I was looking for for a while. I explored similar ideas in the past [1, 2].
I was wondering: Are there specific plans for the structure of the p2p network already. Since most of my problems with building scalable (web) dapps resulted in using centralized infrastructure for querying and caching Ethereum data, I'd find it quite useful to span the network across the web too. To serve my dapp today, I'm having to rent a 110 EUR Eth full node. I do so in the cloud :(
Hence, in most of my prior work, I looked mostly into two domains:
eth_call
s could also be cached, assuming thelatest
tag is always replaced with the block number.I haven't done much research on (2), but I'd imagine that if enough nodes ran a p2p webtorrent network that is compatible both for system-level applications and browsers, much of the traffic that's currently directed to e.g. Infura could simply be served through torrent. In [1] I did a tiny tec spike to see if RPC requests could be treated as single webtorrent links - and concluded it was possible.
I'd find it quite exciting if web browsers became part of the Ethereum network. Suddenly, not only deliberate network participants would help to host the network: but all users too. Surely, browsers wouldn't raise to the service quality of dedicated servers. However, I imagine still lots of load could just be distributed.
Anyways, these are just some ideas that I have had in the past and that I wanted to contribute to this repository. I'm happy to iterate on them further if there's interest. Also: since this issue isn't really actionable, feel free to close it.
Best,
Tim
References
The text was updated successfully, but these errors were encountered: