doc: Add Portal Network wiki article#505
Open
bourdillion wants to merge 3 commits into
Open
Conversation
Contributor
taxmeifyoucan
left a comment
taxmeifyoucan
left a comment
There was a problem hiding this comment.
Thanks for the article, technical details are well written, only need to improve the flow of the text with overview using up to date references
|
|
||
| The Portal Network is a lightweight peer-to-peer network built on top of Discovery v5, where each participating node stores a small slice of Ethereum's data and serves it on request. The term "portal" is used to indicate that these networks provide a view into the protocol but are not critical to the operation of the core Ethereum protocol. | ||
|
|
||
| Before Portal, lightweight access to Ethereum relied on the **Light Ethereum Subprotocol** (LES) running on DevP2P. LES followed a client/server model, where a light client requests data from a full node, the server. It was ambitious but faced a real performance bottleneck as a LES client was just a consumer of full node's resources and didn't return anything back. Multiple LES clients relied on the far fewer full nodes who were willing to serve, and every new LES client that joined added demand to the same limited pool worsening the performance. The Trinity team at the Ethereum Foundation spent nearly three years attempting to build a functional light client without success, and the conclusion was that the bottleneck was not in their implementation but in the design itself. Portal Network came to flip that model by ensuring that every portal client contributes by storing a small part of Ethereum and serving it to other clients. |
Contributor
There was a problem hiding this comment.
I wouldn't focus on diving into LES comparison here, it's not that relevant and also has different scope. Better to preface with high level details of Portal -
It's its own network overlaying Ethereum
Provides current state, historical data
Clients can be integrated in small footprint.. browser extension, apps
It's currently stalled - this is what I would highlight because the article gives sense that it's live/ongoing
Contributor
Author
There was a problem hiding this comment.
I agree, the article went a bit off topic there. I have corrected it. Thanks!
|
|
||
| Although the four clients are still experimental and have not had a production release, the Portal Network developers have pursued client diversity from the start as a deliberate strategy in order to achieve a healthy distribution of clients. Cross-client interoperability is tested through portal-hive, a Portal-specific extension of the Ethereum [Hive](https://github.com/ethereum/hive) testing framework that runs automated integration tests between clients. Network-wide health is monitored through [GlaDOS](https://glados.ethportal.net/), which tracks content availability and retrieval success rates across all implementations. | ||
|
|
||
| ## Conclusion |
Contributor
There was a problem hiding this comment.
Conclusion isn't really fitting for technical documentation, the last part should be more overview of current state
Contributor
Author
There was a problem hiding this comment.
Thanks for the feedback, I have adjusted it.
|
|
||
| The Portal Network is directly tied to [The Purge](https://vitalik.eth.limo/general/2024/10/26/futures5.html), the stage of Ethereum's roadmap focused on reducing historical data storage and simplifying the protocol. One of the central proposals under The Purge is [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444), which allows execution clients to drop data that is older than a defined period. This reduces the storage burden on full nodes, but it raises an important question, where does the expired data go? Yes, the Portal Network is the answer. The Portal Network distributes that data across thousands of lightweight nodes, each storing a small slice and serving it on demand with full cryptographic verification. | ||
|
|
||
| The network is still in its early stages. The [History sub-network](https://ethportal.net/concepts/protocols/portal-sub-protocols/history) is the most mature sub-protocol and is live on the Portal mainnet, but it is [not yet fully production-ready](https://github.com/ethereum/portal-network-specs/issues/398). The Beacon sub-network is functional but still experimental, the State sub-network depends on bridge node infrastructure that is still being built, and several other sub-protocols like the Canonical Transaction Index and Transaction Gossip networks remain at the preliminary specification stage. The dissolution of the EF JavaScript team also leaves uncertainty around the Ultralight client and browser-based access to the network. |
Contributor
There was a problem hiding this comment.
It was worked on roughly 2021-2025 and now there is not active maintenance. Later part could discuss why it failed, what can be salvaged and alternative approach to history expiry
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a dedicated Portal Network article as a follow-up to the History Expiry page merged earlier.
Content covered includes the Portal Network architecture, sub-protocols, bridge nodes, content key storage model, Kademlia-based retrieval, cryptographic verification, and client implementations (Trin, Fluffy, Ultralight, Shisui).