Why Light Clients matter
Light clients allow users to interact with blockchains without having to run a full node. This provides greater security, privacy, and resiliency compared to a traditional client-server model. For a blockchain to support light clients, it needs to have a consensus mechanism that allows users with limited hardware resources to accurately maintain a view of the chain. Additionally, at the networking layer, full nodes must be able to respond to requests from light clients in a peer-to-peer manner.
However, with this design, an issue arises when the number of light clients in the network increases. With more light clients requesting data, there would be a greater burden on full nodes to serve those additional requests. As a result, this could potentially deteriorate the network's overall health. In practice, this was a noticeable scalability problem that was inherent with the design of LES (Light Ethereum Subprotocol). While full nodes can choose to serve requests from light clients, they lack any incentive to do so, given that light clients do not contribute (only request data) to the network.
To allow users to interact with Ethereum on resource constrained devices without sacrificing decentralisation, a fundamentally different approach needs to be applied. This article explores problems in the ecosystem concerning access to Ethereum, and the development efforts happening to address these.
Problems in the Ecosystem
If users want to interact with Ethereum in a decentralised manner, they have no option other than running a full node. For the majority, this would be a large undertaking because it involves running both an execution client and a consensus client. The necessary hardware for this setup demands enough storage space and RAM. These requirements will only continue to increase until Ethereum has completed its migration to statelessness.
However, assuming these requirements have been met, the node then needs to catch up with the network’s view of the chain. It does this by verifying individual blocks until it reaches the most recent one. This process is called syncing and it can take a long time to complete, depending on the chosen method. There have been advancements made by client teams to provide alternative methods for syncing that are faster and usually take a couple of hours.
Even so, this approach doesn't provide a comparable user experience to traditional apps and services. This is primarily the reason why centralised RPCs have been very useful. They enable users to interact with Ethereum by abstracting away the need for setting up a node. However, this convenience comes at the cost of decentralization. By losing decentralization, other key benefits that empower users with sovereignty, such as unrestricted access and privacy, are also lost. It is entirely possible for the RPC provider to limit or reject any number of queries.
These are the problems that are highly worth pursuing solutions for. By having a local solution which allows direct access to Ethereum, the protocol becomes available to anyone globally with just a smartphone device and access to internet. This not only democratizes access but it also paves the way towards a reality where applications can operate in a truly peer-to-peer fashion, utilizing Ethereum as a fundamental source of truth.
What is Portal Network?
This is the direction being taken by Piper Merriam who is leading the efforts to build the Portal Network. The Portal Network’s goal is to allow users to access Ethereum-related data on devices with as little computational resources as possible. It is designed to be scalable in a way that as more participants join, the overall network benefits rather than degrades. In terms of the underlying architecture, it consists of four sub-protocols, where each is independent of one another. This includes:
- History Network - Access to historical data such as previous blocks, headers, and receipts
- State Network - Account balances, and smart contract storage
- Transaction Gossip Network - Broadcasting transactions to be included in future blocks
- Canonical Transaction Index Network - Retrieving a transaction based on its hash value
It is important to highlight that participants are not restricted to just one network but are free to join any number of the above mentioned based on their needs and preferences. They would also have full control over how much resources (e.g. RAM, CPU, and storage space) they want to contribute to the network.
The construction of these sub-protocols is possible using the Discv5 protocol which is a peer-to-peer mechanism used by nodes for discovering other nodes within the network. The Discv5 protocol is relatively lightweight and allows for building custom protocols. For more information about how Discv5 works, there is a three-part explainer dedicated for this, accessible using the link here.
Stateless Roadmap
As mentioned previously, Ethereum will be transitioning to a stateless model in the future. Under this model, nodes will have flexibility to decide how much “state” they want to store. For reference, the state size in Mainnet is approximately 900GB and is increasing as users deploy more smart contracts, or as existing contracts occupy more storage slots. To address this indefinite growth, this is a much needed upgrade as it can reduce burden of storage requirement on full nodes.
Under this model, however, if a node is fully stateless, it will be unable to fulfil queries from applications for retrieving account balances or smart contract related data. This opens a path for Portal Network clients that are participating in individual sub-protocols to act as state providers. Furthermore, when a new node wants to sync with the network, it can rely on the history sub-protocol for fetching historical data.
How Lantern can fit into this?
In an effort to expand access to light clients, and provide redundancy, the ongoing efforts out of Portal Network are exciting. Today, there are teams working on three different implementations, including Trin (Rust), Fluffy (Nim), and Ultralight (Typescript).
Diversity of programming languages helps to expand developer ecosystems that are part of that language. Having redundancy across implementations also promotes optimisations and helps discover new ways to approach designs. This is where Lantern comes in. To support the development of Portal Network, there can be another implementation built in C# that would focus on allowing users to interact with Ethereum (e.g. verifying on-chain information and sending transactions) without needing centralised RPCs. This implementation would exist as an open-source project.
It's universally agreed that UX in the space needs improvement. This will be a core focus of Lantern. An effort to improve the UX of interacting with Ethereum without sacrificing decentralisation. And some of that work has begun. Pier Two have implemented Discv5 in C#, as a library that can be used for implementing the Portal Network specs. The goal will be to expand and fully support all four sub-protocols.
Much of the mindshare today tends to focus on common examples, where problems related to finance, collectibles, assets or identity are being addressed, in fully developed nations. Where energy, compute and political agendas are relatively consistent. As we zoom out, and think about what Ethereum has the potential to unlock, we must also think about scalability, resources and scarcity. Light clients will play a really pivotal role in realising that potential, and providing access to everyone with an Internet connection. Specifically, to provide the maximum number of people direct access to the network, as seamlessly as possible.
