# Portal Team Work on 4444s This document is intended to be a rough collection of the work that the Portal team has done to advance EIP-4444 implementations in execution clients. This *also* documents the work we've done to encourage adoption of Portal network by execution clients. > Worth noting that 4444s and Portal adoption are not the same thing and we've worked to keep them separate. We believe that Portal is the best solution, but we also recognize that to be effective facilitators of the 4444s discussion, we can't intrinsicly link Portal and 4444s as the same thing. In this document, we start the timeline in May of 2024. If anyone wants to dig back further in time, I'm happy to go on that journey with them. ## A bit of "meta" > In this section I have made some assumptions about other peoples perspectives. I'm very open to corrections here. My goal isn't to put words in other people's mouths, but rather to put some words down so that we can refine them if needed to get a clear understanding of the situation. Please please please provide me with corrections if I've gotten some of this wrong which I'm sure I have > -Piper In the recent call with Josh Stark and the budget team about the Portal project, there was a lot of discussion about the Portal roadmap. - Budget team felt Portal's priorities were wrong, focused too much on state network and not focused enough on 4444s. - Budget team's views coming into this call were informed by Portal's roadmap document which did not contain much related to 4444s and which was written prior to Devcon. - At Devcon, execution client teams came to agreement on 4444s implementation, and most execution teams committed to a plan to also adopt Portal as a backend for their data. - Devcon events elevated 4444s priority for Portal team. This was not refleccted in our roadmap document. In the call with budget, I (piper) attempted to convey the following points. - Advancing 4444s and execution client adoption of Portal is our top priority. - Almost all of the work that my team needs to do to support this was already planned or in progress or simply done. - None of the work my team is doing on this in 2025 has been blocking execution client teams. - Portal history network has been ready for execution client team adoption for a while. - The work to support 4444s and adoption only represents a small portion of what we are doing in 2025. The response from budget was roughly that: - History network adoption and 4444s by execution client teams should be our top priority. (we agree) - If execution client teams fail to implement 4444s (and portal) it would reflect poorly on Portal. (we disagree) - Note that this is my interpretation of the sentiment in that call and not any kind of direct quote. - We do fully agree that failure of execution teams to adopt would be lame. There seemed to be a perception that - Portal wasn't prioritizing this work, or considering it important. - That we were not doing enough to support adoption or 4444s - That we are spending our time on other efforts within portal to the detriment of 4444s and adoption - That our focus on state network and alternate execution client design in addition to 4444s and adoption are misguided, wasteful, or low value. - Again, my interpretation. There was pushback in the call and I'm interested in understanding these perspectives more. My goal in this document is to dispell these perceptions by showing that we are both prioritizing the 4444s and client adoption work **and** that the work beyond this is relevant and important. ## May 2024 After the interop event in Kenya, I got word from Kev that there had been a discussion around Portal & 4444s. Nobody from the Portal team was at Kenya (because we were explicitely not invited). The [notes from the conversation in Kenya](https://hackmd.io/@6iQDuIePQjyYBqDChYw_jg/BkgzJ3EmR) were confusing and also promising. Over the next week, I pieced together that: - Nobody who was part of this conversation had any dept of understanding of Portal network. - They did not know that history network was a ready to go solution that did exactly what they needed. - They assumed they needed to "fork" the protocol in some way to remove un-needed functionality. Over the next weeks we participated in discussions on the R&D discord as well as the ACD call in an attempt to correct any misconceptions people had, inform them on the current state of readiness of the history network, and support them in moving forward. We encouraged teams to get started with implementations so that we could have informed conversations by the time that Devcon arrived. We invited them to join our implementation call. We provided links and information to our documentation. We pointed them to the correct places to get started with integration. We outlined the scope of effort it would take for them to implement a client. We highlighted the existing clients that were available for direct integration. We made it clear that we are available to answer questions. We brought the issue up on ACD multiple times. None of the teams engaged. They didn't seem to actually care about prioritizing it and we can't make them. After a few weeks of calls with uncomfortable silence we went back to work on the things we had agency over. ## Devcon 2024 ACD in-person After the false start on May, I contacted Tim and made sure that he knew that Portal wanted to be present in two capacities. - We wanted to lead the 4444s discussion - We wanted to present our plans for alternative execution client designs based on Portal. At the ACD in-person we led the 4444s discussion. At the end of the first session we had not come to an agreement but were very close. We scheduled a second ad-hoc session on the second day. I (piper) was in telegram chats with every execution client team, making sure that they would be present for the day-2 session. Leading into the day-2 session, I had private conversations with every team to make sure I understood their position and knew what they cared about and what they would agree to and what they were against. By the end of the day-2 session we had reached broad agreement on moving forward with 4444s, a timeline for doing so, and an understanding of the approach that each team was taking. ## Devcon 2024: during the event The Portal team met with every client team except Erigon > Erigon's expressed position was that they didn't need what Portal provided and so meeting with them was un-necessary. - Geth - Besu - Nethermind - Reth - Nimbus During these meetings we made sure to understand what their implementation plans were for 4444s. If they were planning to adopt Portal as well, we got into details with their developers about how they planned to do that. We gave and in depth presentation on the current state of History network and all of the Portal project's tools and infrastructure. We answered questions and gave suggestions on their implementation plans. ## After Devcon: 4444s Following up from Devcon, we created [this document outlining the 4444s implementation plan](https://notes.ethereum.org/M41Oj3WyRVSC36Rr0c-Tjg) and disceminated to the execution client teams. We presented the document on the Execution layer ACD calls and facilitated the discussion around the specifics of the rollout plan. In these discussions, there was ambiguity around what changes *if any* needed to be made to the DevP2P protocol. Over the following weeks I facilitated and [summarized](https://notes.ethereum.org/JdRsfhU5Qz27THubjkstcA) and helped the teams come to agreement on the path forward for DevP2P. At present there is clear agreement on the path forward for 4444s. All execution teams have agency to move 4444s forward. ## After Devcon: Portal The Geth, Besu, Nethermind and Nimbus teams are all planning to adopt 4444s. For Geth, I have been communicating with Felix. They are currently our biggest supporters as it seems they see the significant power that Portal offers. [This github issue](https://github.com/ethereum/go-ethereum/issues/30908) represents their plans to move forward with this. They are going to be integrating the existing [Shisui](https://github.com/zen-eth/shisui) client into the go-ethereum client. I've been having regular check ins with the Shisui team to make sure they are on track to deliver the pre-requisite work that the go-ethereum team needs to move this forward. The Shisui team and the go-ethereum team met during Devcon to make these integration plans. For Besu, I'm in regular communication with Justin Florentine. He's been our biggest advocate on that team. They are also looking to integrate the existing [Samba](https://github.com/biafra23/samba) client. Them seeing that Geth is going the integration route seems to give them more confidence. For Reth, they have not expressed an immediate interest in Portal. This seems to be mainly due to them not having looked into it with any detail. They were also the team that had the least plans in place for how they'd approach 4444s. For Nethermind, we continue to be in discussions with "Smartprogrammer, aka Ahmad" about their ongoing integration with Portal. They have chosen to write their own implementation. The work on this had started before Devcon in 2024 but seems to have stalled out. We are continuing to communicate with them to try and support them. They are strong advocates for 4444s. For Nimbus, they are strong allies. They are also building their client towards being fully independent of DevP2P using Portal as a primary data layer. I (piper) continue to have regular conversations with members of each of these teams, checking in with them on their progress, and doing everything I can to make sure they are moving forward. ## In-Person Interop in March I am in communication with Afaf from the Berlin office who is helping me with the on-site parts for doing an in-person event in Berlin on March 10th-11th. I'm in communication with each client team to make sure that somemone from their team will be present at this event. ## Erigon I've been continuing to have conversations with Erigon about Portal. While they have expressed clearly that they were not interested in adopting Portal, they also are the team who's done the most work on understanding the problem that Portal solves. They have implemented their own solution using torrents, which is well suited for their "large" client. Recently, I finally got them to take a closer look at our protocol. Their tone immediately changed and they are suddenly interested in our work on state network and the potential uses for stateless clients. ## Nimbus The nimbus team is now actively moving away from the DevP2P based architecture and towards a client design that is founded on Portal. Here is their blog post on the topic: https://blog.nimbus.team/lightweight-ethereum-validators-with-nimbus-execution-and-portal-client/ ## Meta Take-Aways Here are the main points I'm trying to drive home and support with evidence. ### We are doing the work We are and have been prioritizing 4444s **and** adoption of history network in execution clients. This was happening prior to the call with budget. ### Alternative execution client design is valuable The work we are doing with respect to shipping an alternatively designed execution client is valuable and important. On the budget call, Tim expressed skepticism around us building an execution client. He seemed to feel that every client thinks they are "doing something novel and different" and that we were another iteration of the same trope. I believe I understand Tim's perspective and why he has it and it is my opinion that he is wrong about Portal. Geth, Besu, and Nethermind are all the same. Erigon and Reth are both going more towards heavy archive node architecture. All of them are fundamentally based on DevP2P and have similar core architecture. Portal based execution clients are fundamentally different than all of these clients. Within the next few years, I expect to see Portal become a fundamental layer for all Execution clients. The DevP2P network cannot compete with the data layer that Portal offers. The execution client teams have only just now taken a close look into what we've built. The shift towards Portal is building momentum and I believe that it is accelerating. Geth, Besu and Nethermind adopting Portal is a move in this direction. Nimbus client and blog post outline a major move in this direction. Erigon's interest in our state network for stateless client design signals that our direction is correct. Our own work on trin-execution validates the alternative design is viable. ### There is more All of this is in the domain of execution clients and 4444s. There is even more to Portal than this. We're within about 1-month of having state-network serving near-HEAD state. When this is live, we'll be able to serve `eth_call` or `eth_estimateGas` from a client that takes up less than a GB of hard drive space and requires no syncing time. A truly light ethereum client. This enables wallets that don't need to be hooked up to backend infrastructure, and we have people waiting to hook our clients up to their wallets to experiment with this.