# Ethereum Portal History Network 4444's FAQ --- #### **TL:DR what is the Ethereum Portal Network's** The Ethereum Portal Network's is a collection of seperate P2P DHT networks built on Discv5 with the current* goal of making excecution layer data accessible utilizing minimal system resources. Currently we are working on 3 different Portal sub-networks History, Beacon, and State. Each with there own timelines for when they are expected to be online. Portal has a verification first approach to Ethereum mainnet data, which plays a big part into our gurentees over generic solutions. --- #### **Does the Ethereum Portal Network have a website** Yes https://www.ethportal.net/ --- #### **Does the Ethereum Portal Network have a specification** Yes https://github.com/ethereum/portal-network-specs --- #### **How Many Portal Network implementations are being built?** Currently there are 3 Portal Network clients being built - Trin (Rust): <https://github.com/ethereum/trin> - Fluffy (Nim): <https://github.com/status-im/nimbus-eth1/tree/master/fluffy> - Ultralight (Typescript): <https://github.com/ethereumjs/ultralight> - Shisui (GoLang) <https://github.com/optimism-java/shisui> There have also been talks with other teams about building Portal clients in other languages. But time will tell what happens with those endeavours. --- #### **What is the timeline for the Portal History Network** The Ethereum histoical data will roll out in 3 Major releases. - ~(Q2 24) History network which validates all pre-merge block history - ~(Q3 24) Upgrade network to validate all pre-8192 latest blocks (Requires running Portal Beacon Client) - ~(Q1 25) Upgrade network to validate all Ethereum mainnet blocks (Requires running Portal Beacon Client) *dates are expectations not gurentees and will change under unexpected circumstances* --- #### **Is Portal the thing I turn on when I need history data or should it be run continuously** Users are expected to do both, but we hope they will keep their nodes on and run them in the background. Portal is built with resource constrained devices in mind, so keeping your Portal Client running in the background shouldn't be a issue. Running a long lived node improves the performance and health of the network for everyone. --- #### **Why is Portal a better solution then LES (Light Ethereum Subprotocol) for providing access to excution layer data** LES was a server client based model for allowing light weight access to Ethereum excution layer data. It required Ethereum Full-Nodes such as geth to opt-in. Because of this servers were often highly congested, well clients struggled to find avaliable LES servers. With the merge LES no longer works. Portal on the other hand embraces a distributed model, instead of only a decentralized model like LES had. All Portal clients act both as Servers and Clients. There is hence no 1 Portal node which has to store a full-node worth of data. Portal nodes store individual pieces of content which is closest to them using an `Xor` metric and can also look up content on the DHT using the same `Xor` metric. --- #### **What is the time complexity for Portal to find data on the network** Portal nodes lookup/store content based off a `Xor` Metric Using the `Xor` metric content look ups have `log(n)` time complexity. The key used to look up content is defined per subnetwork (history, beacon, state) specification. --- #### **Do individual Portal Network nodes store all the block history** In the normal case no. The amount of data each individual node stores can be configured on a node-by-node basis, and client defaults will tend to only allocated a small amount of disk towards portal storage. --- #### **What Protocol is the Portal Network built on top of** The Portal Network is built on top of [Discv5](https://github.com/ethereum/devp2p/blob/6eddaf50298d551a83bcc242e7ce7024c6cc8590/discv5/discv5.md) which is a UDP based protocol. --- #### **How will looking up historical data look** If you have a block hash you will be able to look up its corresponding header, block body, or receipt. Data will not be index by epoch, but by block hashes for get requests. So if you want a range of blocks you will have to request them by block hash. --- #### **Is The Portal History Network Robust what if a node leaves the network?** Portal mainly gets it's robustness from replications on the network. It is expected that data in the portal network will be replicated and stored across many nodes. Portal network is also built to quickly re-inject data when it is found to be missing. --- #### **IPFS is also a Distributed Hash Table storage network, why not use IPFS to solve this problem** Portal is unique in that it takes a validation first approach. This meaning all the data on Portal Networks should be validatable that they are indeed apart of the canonical Ethereum mainnet. Without this problems can occur. If you can't validate the data you are storing is real, how can you prevent the storage of spam. This `fake` data can then displace `valid` data. There is limited Ethereum historical data, but you can generate infinite fake data. So you can end up with an attack where you spam a network with fake data and since nodes prioritize storing the closest data, you will end up with a flushing affect where `real` data is removed and replace with the `fake` data. Having strong validation gurentees a situation like that can never happen. IPFS is a generic storage network and because of that there is no gurentees that if you store Ethereum mainnet data it wouldn't be flushed away by non-Ethereum mainnet data which gets gossiped to the network at a later date in time. Another reason is the main transport Protocol in IPFS is TCP. Wanting to have lower latencies we chose UDP. --- #### **Do you assume nodes will store the data altruistically?** The assumption is - there exists intrinsic value in Ethereum block history itself - there exists intrinsic value in having access to Ethereum block history - the cost to run a portal node being extremely low So the assumption is the value of Ethereum block history is greater than the cost to participate in Portal itself. A big part of that is Portal clients being super efficient So someone might want to have access to all the history and all it will realistically cost them is 100mb or however much storage they are willing to contribute back. --- #### **How does a Portal Network node decide what to store** A Portal Network node will prioritize storing content which is closest to the nodes `node_id` using a `Xor` metric Portal History has 4 Content Types - Headers - Block Bodies - Receipts - Header epoch accumulators (pre-merge only) With content ids 0, 1, 2, 3 respectively So the scheme for choosing what to store is roughly `Xor(node.id, sha256(content.id + content.block_hash) <= node.radius` --- #### **What is a node's Radius?** It is a number from 0 to 2^256 which indicates how much content a node is interested in --- #### **What is Portal's Beacon sub-network** A Portal sub-network of beacon chain light clients which provide beacon data --- #### **Why for post-merge history validation do we also need to run Portal's Beacon sub-network** To validate post-merge history we are using the beacon chain's baked in history accumulators - Post-Merge we will use historical_roots - Post-Capella we will historical_summaries These accumulators don't apply to the latest 8192 blocks. So we are thinking up validatable ephemeral solutions which should make this possible. --- #### **What are the proposed Portal sub-networks** To validate post-merge history we are using the beacon chain's baked in history accumulators - Execution History Network: [roadmap with eta's](https://notes.ethereum.org/qSpia3LmRLGyda9QXbzsKQ?both#What-is-the-timeline-for-the-Portal-History-Network) - Beacon Chain light client Network: currently in the implementation phase - Execution State Network: R&D phase - Execution Transaction Gossip Network: future TBD - Execution Canonical Indices Network: future TBD Portal is an extendable wire protocol so it is possible community Portal Network's could be made in the future --- #### **Does EIP 4444's include EIP 4844's blobs** No, Blobs are supposed to be transient. EIP 4444's is a proposal for the expiry of Ethereum Mainnet headers, block bodies, and receipts. History Expiry != Blob Expiry. --- #### **What is a DHT (Distributed Hash Table)** A distributed hash table (DHT) is a distributed system that provides a lookup service similar to a hash table. Key–value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. https://en.wikipedia.org/wiki/Distributed_hash_table --- #### **What DHT family is Portal based off of** The Ethereum Portal Network uses Kademlia the first DHT which came up with the idea of using `Xor` as a search metric to find content on a network. https://en.wikipedia.org/wiki/Kademlia ---