# Portal/Stateless EthCC Talk > Need to lock these in by July 2nd. DONE Title: Stateless Ethereum and The Portal Network Abstract: > "After years of dead ends, false starts and general disappointment with "light clients" we are finally on track to deliver lightweight decentralized access to the Ethereum network. Learn about the "Portal Network". What it is, How it relates to statelessness, and why this peer-to-peer infrastructure is a core pillar to statelessness and the future of our protocol." Abstract V2: > "After years of dead ends, false starts, and general disappointment with "light clients", we are finally on track to deliver lightweight decentralized access to Ethereum with the "Portal Network". What is it? How does it relate to statelessness? Why is this peer-to-peer infrastructure a core pillar to statelessness and the future of Ethereum?" Abstract V3: > ""After years of dead ends, false starts, and general disappointment with "light clients", we are finally on track to deliver reliable lightweight decentralized access to Ethereum with the "Portal Network". What is it? Why is this peer-to-peer infrastructure a core pillar to statelessness and the future of Ethereum?" ## Chat Notes The "story" I want to tell is still pretty fragmented. I want to paint a picture of statelessness, but from a user-facing perspective. This ends up centering around the portal network, which is awkwardly not actually core to statelessness at the protocol level, but it is the "sugar" needed to bring the benefits of stateless into user-land. I'd like someone leaving the talk to: - have a high level understanding of what "protocol support for statelessness" means. - have a concise picture of what the portal network is and how it compliments statelessness. - to paint a clear picture of what using a portal client will be like (no syncing, low resource consumption, it-just-works) - hint at the possible future where current clients adopt portal network functionality to improve client UX and the side-effects this will have on the existing DevP2P ETH network. This could end up being a forcing function for DevP2P ETH to evolve if enough clients choose to implement these UX improvements. (I haven't figured out how to tell this part of the story yet, but I think it is very important because I'm pretty sure it is real) - leave people with an appropriate sense of scale for what things can look like once stateless+portal are done. Ideally all of the above is part of a somewhat cohesive narrative of the last two years as we worked to figure out a viable path towards statelessness. ## Structure of the talk A rough sketch of how the talk can be laid out. - Introductions - Who are we - Roadmap - Tell them what we are going to tell them, ideally this contains some level of "hook". - What is "Stateless Ethereum" - High level and quick. Avoid getting into the weeds. Focus on objectively what this means. - Changes to the consensus and networking protocols to support the existence of ethereum clients which do full validation of new blocks without actually using any of the state. - Definitions: - Stateless client - Stateless block execution - Consensus protocol - Networking protocol - What problems did we need to solve? - Witness size - Witness gas accounting - "economic bounds" - Witness production - What are stateless clients - High level description of what they will do. This is the lead-in to why the Portal Network is being built. - Efficient explanation for why stateless clients aren't likely to be useful beyond protocol infrastructure needs. - What is the Portal Network - Focus on functionality, not implementation details. - "Combined contributions of many small clients" - Deliver the JSON-RPC functionality that web3 is built on directly from the network. - Possibly useful to get into some of the details of the "hard" things that current clients have to do which are being moved into the networking level. - State management and availability - Canonical Indices - Transaction Gossip - Chain history storage - What are portal clients - Focus on user experience. No syncing. Low resource consumption. Daemon. - Maybe contrast with a traditional client???? - Zoom back out - tiny portal clients embedded in wallet software.... - how does this interplay with stateless? how do we loop all the way back to stateless. - finishing with the DevP2P `ETH` network story below might be a good question to leave in everyone's mind, while also imparting the appropriate sense of scale. ## Stuff about the DevP2P `ETH` network Below is a long form of the "speculative" reasoning that I've had in my head for why the DevP2P network may find itself needing to evolve sometime in the coming few years. ### Axiom 1: Portal network can serve JSON-RPC Other than log filtering APIs, the portal network functionality includes the ability to serve all of the standard JSON-RPC methods. Looking at what an Ethereum client does for "users", the JSON-RPC API is the primary thing. ### Axiom 2: Ethereum client UX can be better if.... Dropping chain history frees up 100+ GB Dropping transaction index frees ~50GB?? Dropping canonical block index frees ~10GB Reducing Transaction pool responsibilities frees up non-trivial CPU Not serving `GetNodeData` reduces HDD usage No-Syncing is possible (beam sync, stateless sync) ### Axiom 3: DevP2P `ETH` network imposes difficult to enfore requirements Nodes on this network are implicitely required to: - Have the canonical block index - To serve `GetHeader` requests that address the headers by number. - Have all the blocks and receipts - To serve `GetBlockBodies` and `GetReceipts` - Have all the state - To serve `GetNodeData` - Process all transactions in the mempool - To participate in transaction gossip. These things cannot however be strictly enforced. A "bad network citizen" could choose to not store some of this data. When a request comes in for data they don't have they could: - **A:** Serve an empty response - **B:** Retrieve the data from a centralized provider (Infura) - **C:** Proxy the request to another connected peer. Approach **A** is likely to lead to poor peer connectivity since nodes are likely to drop peers that consistently provide empty responses. Approach **B** likely has complexities with things like rate limiting or needing to register API keys for the centralized service. It's unclear to me why someone would choose this option but it is likely viable. Approach **C** is relatively trivial to implement. A client that implements approach **C** would have greatly reduced storage requirements and slightly increased bandwidth usage. Such a client can still serve most of the JSON-RPC directly from DevP2P `ETH` protocol APIs. Detecting and policing this type of behavior is likely non-trivial. We will refer to this type of behavior as "cheating" ### Axiom 4: Minority client behavior doesn't matter much A minority client is one who's "market share" of the network is small. Such a client can "cheat" with very little negative impact on the network. All clients that are not go-ethereum are currently minority clients. ### Prediction 1: Minority DevP2P `ETH` clients are motivated to cheat and are likely to have no initial negative impact on the network. **If** the portal network can serve the majority of the JSON-RPC APIs (axiom 1) *and* clients can have improved UX through dropping locally stored data *and* the DevP2P network cannot reliably detect and police clients cheat *and* such "cheating" does not have any significant negative impact on the network **Then** it is reasonable to expect that some clients may choose to implement these UX improvements as a way to differentiate themselves from other clients. ### Prediction 2: Better UX may drive broader adoption A "cheating" client should be able to deliver better UX than honest clients. This better UX should drive increased adoption. Such a cheating client could begin as a minority client and quickly gain larger market share due to its superior UX. The end result of this is that all nodes on the DevP2P `ETH` network would begin experiencing degraded performance. "Cheater" clients that proxy peer requests would increasingly end up trying to proxy to another "cheater" client. This would continue until a request hit an honest client. This means that requests begin to have higher latency and that honest clients end up handling a disporportionate amount of the overally request load on the network. This dynamic extends until eventually reach a tipping point where clients are unable to reliably retrieve data because requests timeout while and fail due to the network being dominated by "cheating" nodes. ### Conclusion: Portal Network may serve as a forcing function to address long standing issues with DevP2P `ETH` network. The DevP2P `ETH` network design implicitely requires participants to the network to do multiple heavy/expensive things in order to be good citizens of that network. The Portal Network has been very intentionally designd to expose similar functionality without the heavy overhead. It may turn out that the DevP2P network may be forced to evolve if the Portal Network project is successful. This evolution is likely to involve: - TODO