Thread by @christine_dkim

Coming at you with another 🧵 for Day 3 of @EFDevconnect. Today, I attended the #LightClientsSummit and learned about the Portal Network. Before going into Portal and why it matters for Ethereum, here’s some context about light clients in general.

Light clients are nodes that can quickly sync to the Ethereum network to look up data or send a tx. They don’t require heavy computing power to run and are designed to operate directly from web browsers, mobile devices, and/or tablets.

In contrast, regular full nodes on Ethereum are costly to run and can take days to sync, which is why many users today rely on projects like @infura_io to interact with the network.

Storage requirements for a full node have increased as Eth’s dapp ecosystem and user base has grown. Some estimates put node requirements at 250GB for chain history, 175GB for chain state, and 50GB for canonical indices.

Right now, light clients are supported by the Light Ethereum Subprotocol (LES) but LES is not widely used because it’s not very reliable. github.com/ethereum/devp2…

The client/server model that LES uses makes it easy to overwhelm participating full nodes with a high volume of inbound data requests from light clients. The Portal Network is intended to be a more reliable version fo LES that is modeled after @BitTorrent.

Instead of clients pinging servers on the LES for easy and quick access to Ethereum mainnet, the Portal Network would support clients that not only receive information but also store data that can be shared to other nodes on the network.

When data is spread out like this across multiple clients on Portal, the way information is found is through distributed hash tables, which you can read more about here: medium.com/coinmonks/a-br…

The Portal Network does not guarantee the availability of data but it can scale to support many light clients, and the more participation there is in the network, the greater the scope and breadth becomes of available data.

This was a super high-level explanation of Portal. (Shout-out to @pipermerriam for breaking it down in a digestible way at the Summit today 🙌) You can read more about it here: github.com/ethereum/porta…

The rough timeline for the Portal Network is for it to be fully operational within 12-18months and parts of it ready for public use in 6-8. This would improve the UI significantly of running an Eth node and communicating with the network directly instead of thru 3rd parties.

Other topics that were hit today:
- light client support on the Beacon Chain ie Consensus layer (read more about this in my Altair report: docsend.com/view/ak2q58qut…)
- before Portal is ready, @ChainSafeth is working on a trustless json rpc for pinging Ethereum mainnet

- @ethnimbus on how to use a light client and only a CL or an EL node to sync to Ethereum post-merge (instead of needing both a CL and EL node)
- statelessness and Verkle trees on Ethereum

TLDR: R&D for light clients on Ethereum continues, one of the biggest projects to watch on this is Portal Network. Wrapping up my thread here ✌️
(@trent_vanepps be proud , this was under 20 tweets!)