A retrospective on Portal and a glimpse into the future

Transcript

[Music] [Music] down.

[Music] Hey [Music] [Music] Uh hello. Uh I guess I'm ready to go. Uh

so good. Okay. So, hi, my name's uh Colby ML. Uh I have two last names, Mos Lebo, and I'm going to give a talk today on a retrospective on portal and uh I guess a glimpse into the future. So, I guess the the original ethos of Ethereum was you basically had like a fully decentralized programmable network. uh where Bitcoin had very limited scripting ability. uh Ethereum you actually had something functional and you could use um originally users were all expected that they would all run their own full nodes but over time that expectation kind of

broke down uh just because over time the burden to running full nodes grew bigger every year uh due mostly to the state and block history but so the problem that spawned from that was centralized endpoints and over time the reliance on that basically grew and grew uh as the knowledge requirements grew bigger and bigger. So back before proof of work you would think you could just like run a GU node uh after the merge there's a lot more complicated setup. So over time uh it just got more and more tedious

and that spawned centralized endpoints which kind of eroded the a lot of the trust assumptions that people made in accessing Ethereum just because using a centralized endpoint like Infura you're basically just trusting their reputation but they can return you anything. So as the state continuously grows uh full node storage and maintenance grows as well and this is a barrier for uh like everyday users entering the ecosystem.

So early on it's like okay if this state's so big why do we need it at all? And then from that point it's like what if we had a stateless client? Uh stateless clients are interesting uh just in terms of like if you have no state, what does that really mean? Uh Ethereum's kind of known for its state. Uh anything built on Ethereum uses the state except like staking use cases. So I think it's like how do I access the state for example?

So some of the limitations of statelessness is like without having access to it, how do you how do you access balances, contracts, and what Ethereum is really known for? Uh Satanist clients uh trade independency for efficiency. Uh you're still able to verify blocks because every block would basically include a like a state diff. So you could execute to the next state. uh but you wouldn't be really storing any of that locally. So there would be potentially challenges if you wanted to build something like for example with like fossil inclusion. Uh a lot of those proposals assume that the user has like

a high level of state access. Uh so yo and then it's like if nobody's going to be storing this data who really provides it to you. uh there is I guess opportunities for centralized endpoints but do you really want to give up like your authority over your data to them and it's like what is Ethereum without its state well just consensus isn't really interesting uh I guess unless you're just staking and want an ROI on your token. So do like clients exist today? Uh I would say they really don't.

uh there are there are such thing as like light client provers like Helios which take two centralized endpoints and through that you're able to prove if the centralized endpoint is responding with the correct data but I'd say this has certain burdens with like wallet developers in that if you're a wallet developer you're often expected to basically be servicing these like full nodes for your users uh this could be through like paying through inferior yourself um or other things. But it would be really nice if you could just I guess run a wallet without needing to have a centralized endpoint. From a developer's perspective, what if you could just build a wallet which could

access a distributed network appears the same way you couldn't with a full node, but you didn't have like that burden of like running the node itself. So I guess like on a continuum you can think of a really heavy solution would be something like a full node. Uh in terms of something like GU I guess there's there's trade-offs depending on your use case. Uh if you just want to run the head of the chain well then you would probably only need two terabytes of storage. Uh and in that case you would only have like recent state accesses. But if you wanted to have like the state and have that verifiable for your users for the whole chain, that'd be around 20 terabytes of storage just because you would be storing uh like key

value key like key value pairs for like all the state that ever existed in a tree format. Uh on the extreme other end of the spectrum, you have infur instead of portal is supposed to write the word light there. Uh but inferior is insanely lightweight for users. Uh but you also have the problem of they could send you any data and you wouldn't really know. So um right next to that is basically like like pro like proving centralized endpoints. Uh but who's paying for this endpoint and who's setting it up? If you're requiring your user to provide this endpoint, uh that's a big knowledge requirement which which could prevent

them from like onboarding to your app. So it's like do we have something but it's light but it's also more aligned and that's kind of like the mystery mark I have there. So I would say that's kind of portal. So uh what if you had full JSON RPC access but you but your user only had to allocate 10 GB of storage instead of 2 to 20 terabytes and that would include all archival state. uh sync times would be instant instead of like three to seven days in like optimal cases. Uh you would just need to participate in a peer-to-peer network instead of like basically running like a full node yourself or paying for centralized infrastructure. So uh the

goal would be like extremely low resource usage uh just because it's like how else would you justify participating in this like distributed network. So uh the pain points of running a full node would be solved uh or are they? So in a solution like this you would be able to assume that there would be trade-offs between latency and also hardware requirements. So if you weren't a if you didn't store all the data yourself locally well then you need to look it up on a network uh which would have a latency attributeed to it. So how does it work?

uh we shared Ethereum's headers, block bodies and receipts and state over thousands and thousands of nodes. So uh each node source a very small chunk of the data. Uh so for like a header you would have a key where you could like look that content up on the network. Uh the idea would be we'd be using Cadmia distributed hashts. So you would basically be able to just like uh ask your peer do you know someone closer to this data I want? And then he would give you peers. You would then send another request being like uh do you know a closer node with with the data I want.

And eventually after like login lookups, you would be able to find the content you're interested in on the network. Uh which is so you could think of portal like every single node is just like a key value database and then you would just be like keep on like recursively looking for like the table that stores the data you want. So in portal all data would be provable provable by default. So for bodies and receipts you would just need to fetch the header and the header would include basically like a proof to an accumulator in like the beacon state for example. So historical summaries or historical roots uh and that's how we'd handle that for like the state you could

just like walk the state. So if you have like the header that's proven then you could walk the Merkel Patricia tree to your account and that's how you would basically build a proof yourself. Uh and the solution would be like fully distributed. Uh there's no like real cost from like the users perspective. So you could think like for a Java a Java like wallet for Android you could just embed portal and then you could have your like fully uh decentralized uh wallet where you don't really need to think about these infrastructure costs.

So the vision of portal was uh sharded blocks, headers and state access for lightweight nodes uh near access sync times with minimal hardware and just a few gigabytes of storage and a single CPU core hopefully like 10% usage. So the philosophy behind this infrastructure uh wasn't just technical, it was ideological. Uh so you think like I guess to opt into this of course there'd be trade-offs. uh I don't think you would ever really be able to compete with like a centralized provider or a full node you ran yourself uh just because those responses can be made as quickly as like a web two response. Uh but it's like if you if you believe in

like the technology and you want like the sovereignty of like running a full node but without all the hassle, uh this would be a great solution. And I guess it's kind of like an answer to Ethereum's like centralization drift of like more and more users every year uh using centralized providers. So uh recently I guess what I just talked about kind of died. Uh so the Ethereum Foundation recently had a restructuring and a change in leadership. So portal scope was greatly and really heavily reduced to basically only include bodies and receipts for E4 for its use cases.

Uh so you can basically think in this case if you're running like GU or any other full node you'll be able to do like prune history and you'll be able to get like probably like 60% of your disc space back which is pretty nice but a lot limited than the original scope of having a fully provable JSON RPC in the distributed manner. Um so a question to the future uh as statelessness inches ever so closer whether this isn't something like uh vertical or binary trees or I guess like zk proofs it's like how will nodes access the state uh in a lot of like talks I I like attend

it's like uh there's always like oh we'll we'll do all this with zk proofs but there's never really talks about like how we'll like manage this data in a zk or postquantum world. Uh so I think like over time uh like as a lot of solutions like uh fossil like inclusion lists uh so like people aren't censored it's like how will how will users actually access the state in a decentralized manner which is aligned and I think in like one to two years uh something like this project will probably be revived for a use case like that or just like bootstrapping a stateless node uh of course like you'd be getting uh state updates every block, but you would still

need to initialize your account. So getting that state somehow is really important. How will it be done? Who knows? But so I guess it's like what's the point of knowing the head of the chain if you have access to none of the data to build your transaction. I I have no clue. So I'd say the dream lives on. Uh universal uncompromising access to Ethereum's data I think is really appealing. uh especially like why I got in like running a full node. Uh seeing how like it got like worse and worse to run over time. Uh I thought that was really cool and I'd like to have a future where that's accessible again. Uh decentralization with all without heavy burdens. Uh

ideally a user doesn't need any technical knowledge to like run a node. It should be like embedded in their app they're using which is what like portal was being built for and a vision uh worth continuing. So uh I really believe that a solution like this will be continued in 2 years as I said earlier. So uh I'd say thank you and I guess if anybody has questions I'd be happy to answer them. Uh now that this project's dead I'm going to be working on I guess snarkifying the the consensus layer. So like the beam project and yeah so that's cool. If anyone has any questions I guess like put up their hand. I'd be happy to answer them.

[Applause] Are there any questions? Uh you mentioned that the scope was reduced but you also said earlier that um in a way portal nodes are just key value stores. Um, so does it really matter which data they store and in which way like um like how much easier got it did it go to implementing a portal note like this? Uh yeah so in terms of like I guess they could store any data in terms of portal basically like the idea would be like every piece

of content is provable and if the node couldn't prove it it wouldn't store it. So for the case of like history, normally we would like be storing like every single like header and then if like someone offered you a receipt, you would like try to fetch the header from the network. If you couldn't do that, you would probably like say this appears malicious. Uh so I would say because you can prove like any piece of data your node is offered and you would only accept data you could prove. Uh we're kind of fine in that case if I answered your question. Yeah, makes sense. Thanks.

[Music] Yep. Thanks for the talk. Uh yeah, I think portal is a real cool project. So was because you mentioned it's dead but um is there no chance that I don't know for example offchain lips bought prism right? Is there no chance that someday or two or something picks up and the the work continues? I mean I know there is no money to make with portal probably right but it's all about the ethers but u maybe if some layer tooth listening I mean they make a lot of money with with ethereum where while running the sequencer maybe they can pick up and uh you can continue would be awesome. Yeah.

So I think there is like two potential clients who would have a lot of buying for this. So portal was built on discovery v5 which is like how ethereum nodes like discover peers that was built by Felix the head of the GU team. He's like super interested in Portal. Uh so I think in that way the project could be extended. Uh but early on portal got a lot of buyin from like uh Nimbus or like the if the free like technology foundation I forget their name. They rebranded. They used to be Status. Uh Status is really big fans of Portal and like what it was like working on. Uh to my knowledge, they're still funding the development on the strip down version.

And I believe if like if it actually does well over the next 2 years, I assume they'd probably boot up state because it's like kind of like what's the what's the point of just having like block history? I think state was like a really big challenging problem which would would have provided a lot of value. I think we're we were pretty close to shipping it. We were about to show uh ship like latest like headers, bodies and receipts with the delay of one receipt about 2 weeks. Uh like a lot of the uh testing and like specification work was done. We were just like finishing implementing it on the client side. Uh so yeah, I think it might potentially like depending what happens with like history expiry and like how

that's adopted, but I think it's somewhat of a low priority as well. Uh just because there's like easier ways to do history expiry like having like an Amazon like S3 bucket which not just download from which seems like a really like quick solution that a lot of people will start with. Thanks. Uh if no more questions uh thank you very much for everyone who attended and uh yeah uh have a good day. Thank you very much.

[Music] [Applause] [Music] Thank you. [Music] Uh, so when I started out, I applied for like [Music] two years really [Music] So [Music] great project

[Music] was really looking forward.