Ethereum Portal Network
A Research and Development Project for Decentralized Ethereum Light Clients
The Portal Network aims to build a decentralized peer-to-peer network that enables lightweight protocol access to the Ethereum protocol.
Fast syncing
Basic hardware
Residential internet
Clients for this network will be able to enter the network and retrieve arbitrary data within a few seconds. Light clients can sync fast, run on resource-low hardware and use less bandwidth.
The Future is here...
...it's just not evenly distributed
To keep decentralizing Ethereum, the Portal Network has to overcome many challenges:
Reduce hardware and bandwidth requirements
No dependency on full nodes
Individually tunable resource requirements
Support for known retrieval patterns
No centralization points
FAQ
What is the Portal?
"Portal" is an in-progress effort to enable lightweight protocol access to resource-constrained devices. The term "portal" indicates that these networks provide a view into the protocol but are not critical to the operation of the core Ethereum protocol.
The Portal Network will be comprised of one or more decentralized peer-to-peer networks which together provide the data and functionality necessary to expose the standard JSON-RPC API. These networks are being specially designed to ensure that clients participating in these networks can do so with minimal expenditure of networking bandwidth, CPU, RAM, and HDD resources.
Why do we need the Portal network?
This effort is motivated by two overlapping goals.
Full Functionality for Stateless Clients
The core Ethereum protocol is moving towards a "stateless" model of block verification. Under this model a client will be able to fully verify the execution of a block using a witness. Such a client would no longer need to keep or maintain any of the Ethereum "state" data. Such a client is very valuable in the context of the core protocol, as it facilitates a cleaner merge of the Eth1 and Eth2 chains.
Additional reading on why stateless is so important to the Eth1/Eth2 merge.
Scalable Lightweight Clients
The term "light client" tends to refer to a client of the existing DevP2P LES network. This network is designed using a client/server architecture. The LES network has a total capacity dictated by the number of "servers" on the network. In order for this network to scale, the "server" capacity has to increase. This also means that at any point in time the network has some total capacity which if exceeded will cause service degradation across the network. Because of this the LES network is unreliable when operating near capacity.
The Portal Network aims to solve this problem by designing our networks so that each additional client that joints the network adds additional capacity to the network. The end result should be a network which becomes more robust and powerful as more nodes join the network.
Why aren't there financial incentives?
TLDR: Incorrectly implemented incentives lead to perverse incentives.
Using financial incentives is a natural choice for many crypto/blockchain protocols. Well-designed incentives can be a powerful tool to encourage proper use and discourage malicious behavior. Incentives might seem especially well-suited for the Portal Network, where the strength of the network is correlated to the number of participants and the amount of contributed computing resources. However, at the current point in time, Portal Network developers have opted out of implementing financial incentives.
The problem with financial incentives is they are complex and difficult to implement correctly. They also provide mechanisms for people to game the system and extract value rather than contribute towards overall network health. The Portal Network relies on producing a useful, lightweight client for developers, along with altruism and laziness, to encourage network adoption and sufficient computing resources.
"Never underestimate the power of laziness and software defaults" - Piper
Protocols like BitTorrent and IPFS are proof that this is a feasible strategy. Furthermore, protocols like Filecoin and The Graph Network already exist that use financial incentives to accomplish similar goals to the Portal Network.
How can you help contribute to ETH Portal Network development?
The ETH Portal Network development effort is an open, multi-team effort. If you're interested in helping contribute towards the design and implementation, join the ongoing discussion happening on the Discord server. There is also a weekly call Mondays @ 15.30 UTC, where we discuss the latest developments and open questions.
What happened to the original JSON-RPC API-based Portal Network use case?
The original pitch for Portal focused on delivering a network that allowed clients to serve JSON-RPC requests by fetching data on demand from Portal. Recently we've come to understand that this use case will likely be difficult based on network latencies, forcing us to re-evaluate our roadmap.
Portal is still building the same functionality needed to serve JSON-RPC but we expect the performance of the initial versions of the network to be too slow to compete with centralized providers.
Built with ❤️ by Eridian