# Portal Network and Protocol Guild Portal Network is included in protocol guild under the ["Research and implementation experiments related to potential protocol changes"](https://github.com/protocolguild/documentation/blob/6a5deb696e3f3130532fe98b0927fb14bf261968/docs/01-eligibility.md#L21) provision. There are currently three teams included in PG under Portal. - Trin - [7 Members](https://github.com/protocolguild/documentation/blob/6a5deb696e3f3130532fe98b0927fb14bf261968/docs/02-membership.md#L36-L42) - Fluffy - [2 Members](https://github.com/protocolguild/documentation/blob/6a5deb696e3f3130532fe98b0927fb14bf261968/docs/02-membership.md#L178-L179) - Ultralight - [1-2 Members](https://github.com/protocolguild/documentation/blob/6a5deb696e3f3130532fe98b0927fb14bf261968/docs/02-membership.md#L35) (Note they also work on EthereumJS) At present, there are two Portal network clients who are not part of PG - [Shisui](https://github.com/zen-eth/shisui) - ?3? Members - [Samba](https://github.com/meldsun0/samba) - 1-2 Members At present, there are three Execution teams working on integration of a Portal client into their codebase. - Go-ethereum and Shisui - Besu and Samba - Nimbus and Fluffy We would like to explore changing and more formally defining the inclusion criteria for Portal clients. - Client supports all official networks within the Portal protocol - currently three networks: beacon, history, and state - Client is in good standing with the Hive test suite - https://portal-hive.ethdevops.io/ - https://github.com/ethereum/hive/tree/5c0b70f953fe65ce6ec53191384e72c063e8b492/simulators/portal - Client has a sufficiently compelling use case and/or userbase - Intentionally subjective to allow both - Integral R&D focuses clients - Clients being used by the core protocol - Ultralight: Javascript ecosystem, browser R&D - Trin: Embeddable for wallets, Standalone client, Alternative Execution client architecture, Network infrastructure, protocol R&D - Fluffy: Network infrastructure, Execution client integration, protocol R&D - Shisui: Go-ethereum client integration - Samba: Besu client integration (not at a stage yet to be ready for consideration) We are not looking to change the rules today. We are seeking feedback on this idea. We are going to have some in-person discussions at the in-person Portal summit in Berlin about this. Expect an official proposal sometime a bit later this year. ## An Argument for Portal being Core The future Ethereum is headed towards is one where: - Clients only retaining a rolling window of 8192 blocks of data. - We have full stateless, with most clients do not hold a local copy of the state. Ethereum's data will no longer be managed and maintained by the majority of nodes on the network. Access to Ethereum's data becomes expensive and has prohibitively high cost to access. In this future, who's housing Ethereum's data? Ethereum's data is a critical part of the user facing ecosystem, the client development ecosystem, and the research ecosystem. Portal network is about making sure that access to Ethereum's data is easy. This is why we should include it in the "core protocol" umbrella. ### Stewardship of Ethereum's Historical Data TODO ## Arguments Against Portal ### Only the things strictly needed to run the chain > "Core protocol is the bare essential to run a node and continue the chain" > - funnygiulio > "if we remove feature/component X will the protocol keep running as expected (from a spec perspective)? If the answer is yes then X is not a core feature/component" > - Mehdi Aouadi The argument here is that we could define PG as only the things that are strictly needed to run the protocol. This definition precludes most of research ## Slippery Slope If we add Portal then we'll have to add X ## Just a dependency Portal is just a dependency..