What is Portal Network?
The Portal Network is building a new peer-to-peer protocol which runs alongside the existing DevP2P and LibP2P-based Ethereum protocols. This new protocol is designed to be free of the constraints that limit the DevP2P and LibP2P protocols to allow for a new class of lightweight Ethereum clients (for more background, check out the FAQ)
Our primary goal in avoiding centralization is to prevent single points of failure. We want a robust system to withstand pressure to shut down, and any point of centralization tends to be weak.
How does the Portal Network envision doing this?
The Portal Network is building the protocols that allow a more diverse set of functionality in our choices for Ethereum clients. The DevP2P protocol that Ethereum clients use today ends up constraining the design space for execution clients such that they are only able to run on high-end hardware. The Portal Network protocols have been designed to break free of this constraint, allowing low-end or resource-constrained devices to participate in the network and thus access the data necessary to interact with the core Ethereum protocol.
The Portal Network protocols are focused on the following things:
- Decentralization is a core value.
- Move the complexity out of the clients and into the network.
- Special purpose networks that "do one thing well".
- Accessible to resource-constrained devices.
- No assumption of "full nodes."
DevP2P can remain a simple and secure core component of Ethereum infrastructure, primarily used by clients focused on serving the protocol. The Portal Network can then focus on delivering functionality focused on different applications of the users of Ethereum. The Portal network breaks out a current full nodes role into five decentralized storage networks that serve all the data necessary to interact with Ethereum:
- Beacon light client
- State network
- Transaction gossip
- History network
- Canonical transaction index
Breaking out into five different storage networks allows for the heavy requirements (The growing 350GB chain history and 50GB canonical indices) plus the internet bandwidth needed to be reduced. Then resource-constrained devices can participate in serving information. Each of the Portal Network sub-protocols follows these design principles.
-
Isolation Participation in one network should not require participation in another network.
-
Distribution of Responsibility Normal operation of the network should result in a roughly even spread of responsibility across the individual nodes in the network.
-
Tunable Resource Requirements Individual nodes should be able to control the number of machine resources (HDD/CPU/RAM) they provide to the network.
These design principles ensure that participation in the Portal Network is feasible even on resource-constrained devices. Currently, Execution clients can take days to sync to the network. Portal Network is also building towards minimal sync time - this allows more research to be done as many researchers say they want to query the data but not run a node for days to sync for a simple query.
Light client implementations, such as Helios, are a promising advancement from a solutions perspective - verifiable, trustless access to Ethereum. However, it is achieved by being centralised.
Portal Network continues to build with decentralization at its core.
The potential outlook could be:
- Researchers looking to query data can sync data instantly rather than wait days
- Resource-constrained devices could participate in decentralizing the network.