Decentralizing access to Ethereum utilizing Ethereum's Portal Networks

Hi, I'm Colby Miroslibil and I wanted to give a talk today on decentralized access to Ethereum, utilizing Ethereum portal networks, which might sound a little weird, but it will make sense through the talk. So the origins of Ethereum is it's like... Was creating a programmable blockchain or a world computer. Instead of just having a simple ledger or colored coins, which were basically like coins with random features, you could program many features. And Ethereum's emphasis on this was decentralization and censorship resistance.

But how did people access Ethereum? This was done through full nodes, which provided you a gateway to the Ethereum protocol through the JSON RPC. Full nodes were often long-running processes, because if you turn off your laptop and turn it on, you have to re-sync, which is kind of hard if you want to send a transaction. You have to wait a few hours. So full nodes weren't always unaccessible.

At the start, you could spin up a node very fast. But then as requirements grew over time, it became harder. I would say one of the greatest inaccessibilities to Ethereum is knowledge. Being able to run a node is a feat which all of us in the room can do, but can your grandma do it? And for Ethereum to be accessible, you need it to be like you don't want to run this thing, but you need to know something.

Time, you need to sync a node. As I was saying, like, if you turn on a laptop, like, on and off, syncing a node to send a transaction is very unreasonable, and the IT costs associated with that. Updating your node for hard forks is kind of annoying when it's, like, repetitive every year. And then the biggest one, I guess, is hardware costs. It's projected in the next four months by eStakers that validators will need to update to four terabyte disks.

And my little picture of like the man holding the world, which is like a geth node, it's like pretty sizable and really annoying that you need to buy a SSD just to use Ethereum. So because Ethereum was unaccessible, this created WAVE for centralized providers, which took down the barrier of entry to access Ethereum, but it came with this consequence of centralization, which earlier when I said the origin, it's something we didn't want. So with one of the main concerns being the storage requirements, there is this nifty thing called EAP-4-4s or history expiry, where in the purge path, this is basically what if instead of all nodes storing all the data, we lowered the costs by not requiring them to store old data, what's no longer readily needed to run a validator? This doesn't mean nodes can't store the history, but it means they're not responsible for it all. But how do we achieve EAP-4-4s?

And enter the portal network. What is portal? Instead of depending on phone loads which hold all, like the whole pie of data, what if it could only hold a slice of that data? Portal distributes this responsibility amongst numerous small nodes that are independent of each other. So you could think of it as like a slice of a pie, but the whole pie is still accessible through Portal.

Portal is also sustainable. It's both a server and a client, which is very important because this problem has been here for a very long time. Previously in the past, there's been attempts at this. For example, LES, which the concept of it was an altruistic full node would host the server to a bunch of light nodes. But the problem that occurred was there was a bunch of users who wanted to run a light node, but not enough people who wanted to run a full node, so they were all overloaded.

Portal switches this up by making all the participants contribute back to it, so it's sustainable into the future. We also get the benefits before as having lower storage requirements and lighter CPU usage. But how does this work? Portal uses a fundamentally different peer-to-peer model than Ethereum today. Through distributed hash tables.

Distributed hash tables enables decentralized storage and lookup system, where each piece of content is addressed by a unique identifier and stored in multiple nodes for redundancy. DHTs make it possible to be able to look up the data even if you don't sort it yourself, which is what I was going by when I said you could sort a piece of the pie but still have access to the whole thing. And as I was saying, a totally different peer-to-peer model, Portal is also a replacement for the legacy dev peer-to-peer network. In that, imagine dev P2P is this triangle where you have to participate in everything to access anything. Portal breaks this up into different networks.

One of our first ones we'll be launching is Portal History. And then there's others. But what does each network do? Portal history contains headers, bodies, and receipts. Portal state allows you to access the state, such as your balances and contract storage.

Portal index is if you want to find which block body your transaction's in, and the portal transaction mempool will be very interesting with vertical and stateless clients. Currently, there's no hard solution for how we'll handle sending transactions in a stateless world, and we believe that portal is in a unique position to solve this problem. And we will solve this problem. But anyways, with having access to all that data, you also gain access to a full archival node but, like, distributed trademark. And the cool thing about that is it's, like, you can basically run a portal node and have instant access, which is massive, because in the past, if you wanted to have full archival access, which was provable, you would need to run a geth node.

But to run a geth archival node, that requires 20 terabytes of storage, which is massive, and it also takes over a month to sync, which if you just want quick access to archival Ethereum data, that sucks, especially if you're a researcher and you just want to research stuff instead of waiting a month to start your research. So portal is fully provable, which is huge. There's kind of two paths to do this. So you could use our portal beacon network, which will be very useful for wallet use cases, where you could basically put portal directly in place of a centralized provider. Portal beacon network is an implementation of the consensus layer likeline protocol, and it will be integrated in any implementation.

So if you want to use portal, you don't need to think of anything else. You just integrate our libraries libraries and it's proven. A big use case, though, as I said before, will also be for full nodes. And for that, they're already running an Ethereum consensus layer client, which they can just repurpose to prove this data. So as I was saying before, there's all these portal networks.

But is there a dependency to prove? And there is. So, for state, if you wanted to get your balance, you would get a proof to the state route, which would be in a header, but how do you know the header is real? There's accumulators in the beacon network, like consensus client, called historical summaries, which is in the beacon state. So depending on your use case, if you only needed historical data, well, then you would basically have this two-node dependency, but if you needed state, you would have an additional one.

And by doing this, you only need to run a portal network of what your requirements are for the use case. How do portal clients initially get the data? Currently, it's through bridges. Bridges are basically full nodes which have access to all the data. But as portal gets adopted in execution layer clients, which I probably can't talk about it, but like an announcement on the way.

But anyways, so execution layer clients already gossip blocks around the network. Portal is kind of the same in that execution layer clients will be able to gossip blocks around the network, but they'll only need to gossip to a select few peers. Where if they have 50 peers, now that nodes only store a slice, they'd only be required to gossip this data to maybe 10 or 5%, which saves bandwidth. Incentives. So why would people want to run a portal node?

Well, financial incentives are hard. It leads to a race to the bottom, and it's very easy to game. In that, let's say I want to maximize my income from running a portal node, well, then I could offer the worst service, but also allow for the most whatever metric you use to reward people. There are other projects trying to achieve this approach, and wouldn't it be really cool if everybody could participate in Ethereum's protocol for free? Because I don't want to pay someone to send a transaction or pay someone to get my balance when I open my wallet.

We believe that Ethereum's protocol has innate value. That innate value is being able to send money, fetch your balance, use L2s. And Portal gives you access to this on cheap hardware. So if the value of Ethereum is high enough and the cost of running a portal node is so minimally small, we think the incentives are aligned for people to run these nodes. Use cases, as I said earlier, lighter full nodes with storage requirements increasing.

Being able to add 4.4s while maintaining current day UX. UX by if you just implemented 4.4s, your node would have no idea of what the past history was. With 4.

4s, your execution client, it would be like you could fully respond to any request, and it would be like nothing ever happened. Another thing is nearly instant sync times for full archival node access. And the other is a replacement for centralized providers in use cases such as mobile wallets, which is pretty cool. But what's the catch, you may be asking? I'm selling this solution that seems too good to be true.

So the trade-off is between latency and storage. Nothing is as fast as having it on disk, but for most of the data, you don't actually need to access it that often. So we believe that the trade-off for a majority of use cases is correct, is actually there. And the only time you really need quick access is if you're block building. And for mobile wallets, if it's fast enough, it's good enough.

So for the first time, you can choose how you participate in Ethereum's protocol. I think this is kind of analogous to the infinite garden analogy that is often told on Ethereum's future. Instead of basically running a full node and requiring everything, there's tons of possibilities how Portal can change how you access Ethereum's protocol. Whether it's only subscribing to a few parts of the protocol, only history, or accessing the full protocol, it's finally a choice instead of a requirement to handle it all, which is, yeah, really annoying. Who's building portal clients?

Well, the Ethereum Foundation has been at the centre of this from the start, but from the start we have also been assisted by Status and Ethereum JS, which has been massive. Recently, Nethermind has been taking the stage. And for execution layer clients, they have been working the hardest on this from pretty recently, like last year, which is really cool. There's open source teams from around the world who are building clients. Another client's being built by EPF members.

And I guess you guys could build Portal clients as well. We have clients being built in all these languages, so if you want to use Portal, you can. I'm sure everybody would be happy to answer questions, and I think we covered the whole stack, which is cool. Portal history is ready for developers to start using, and we have the data to back that up. So we built a statistics platform for seeing if our stuff works, and we call that GLaDOS.

For the past few months, we had zero failed audits on our network, and what that means is the data is available on the network. And there hasn't been any case where we couldn't find it. So the system has been robust for months. And that's really exciting. There's a QR code there, but you should be able to find it on our website as well.

Another exciting use case I was talking about earlier is wallets. We're building Trin Desktop, which is hoping to target everything but the browser. So hopefully, like, Ethereum.js does that for us. Here's the front screen.

You turn it on, and it's like, woo, stats. But you can also do eth get block by number, get block by hash, get balance. But in the next few months, we're hoping to integrate a wallet as we want to be like the test bed to show people this actually works. And what better way to do that than do it yourself and show people? And it's also, as I was saying earlier, you can configure your storage requirements.

So if you set two gigabytes, you'll only ever need to contribute two gigabytes. You won't need to buy a disk in a year, which is really cool because it sucks to buy a four terabyte disk when you already bought a two terabyte one. So now anybody can participate in Ethereum's protocol. As I was saying earlier, you could just integrate that into a wallet and the user doesn't have to know it's running, which is really cool. And where to find out more?

We have a QR code for our Discord invite, which is really useful if you want to ask questions. We have our website with guides and blog posts and how to set up most of the clients already. We have a Twitter, which our team hates Twitter, but it's good for getting people to know stuff. And then we have specs, so if you wanna contribute, every team is super open to it, and they'd be super happy. We need to improve our issues a little bit, but that can be fixed.

And yeah. So thank you for coming to, I guess, this talk on Portal. And yeah, thank you. Okay, so let's go through some questions. I'm going to read them for you.

Can I use Portal Network today to check my balance? If not, when? Same question for doing an ETH transfer. So you can check your balance if it's within the first million blocks. So if you guys used Ethereum nine years ago, you can check your balance today.

We expect balance for latest account, for checking balance for the head to be available in Q1 or Q2. We just need to finish some infrastructure to support that. What is the biggest hurdle to getting all clients to adopt the portal network, and how can the community help portal get adopted? I would say the biggest thing has been awareness. Two years ago, people were like, what portal?

And then it's like a minimal implementation. And all these questions, what never really made sense. But especially this year, people actually know what portal is, and it's really cool to see people referencing portal, like actually about it, and we don't have to do all the talking ourselves. So I think just talking to people about it is awesome. Awesome.

What is the minimum percentage of network data that a portal network is expected to have? So we have thrown numbers like 100 megabytes, but that's fully configurable. Since the requirements are so low, for our client at least, we wouldn't be surprised if we set it to one gigabyte because realistically someone wouldn't notice. Most apps are 500 megabytes on their phone. So it's like if we use a gigabyte, they probably wouldn't notice.

Like most apps are 500 megabytes on their phone. So it's like if we use like a gigabyte, like they probably wouldn't notice, but it's configurable. And I think the next two questions can be combined. How does portal network compared to classic peer-to-peer file sharing networks such as BitTorrent? So one of the problems with BitTorrent is it doesn't have an inherent way to prove the data or validate it.

So you run into problems of you need to download this huge section of data and it's very uninformed. Portal is different in that all the data you can fetch from the network is provable, so it's much easier for a client to, let's say, fetch any piece of data they want, where through torrent, they would probably have to index this data and do some kind of, like, out-of-band proof, which would be a lot more complex and have a much worse UX experience. And you answered this one in your presentation, but it was asked before. So is there incentive model for running a portal network node? For writing a portal network node, I guess if you wanted to use it in your wallet and you used a language that wasn't there yet, I guess that would be the incentive.

Like accessing Ethereum with instant sync times. Decentralized. Very cool. Could one implement an archive node using portal as a back end? Yes.

So the idea is like portal would have all the data that an archival node would have. So you could just use portal as your archival node. It would be a little slow. But you could. What are the expected hardware and network specs in gigabits for running portal nodes, and who do you think will be ready to operate these altruistically?

I think that the top three execution layer clients would be running all these by default, so that's a lot. Other than that, if you're running a wallet on your phone, I guess that's like an ultra, that's not really altruistic. You have actual utility in that. So I think we can do quite fine with, well, ignoring altruistic use cases. Has there been engagement with IPFS community?

It sounds like there's a lot of overlap with DHTs, accessing content, address data, etc. So some of the issues with IPFS is since they have no validity scheme, one of the things is data is constantly cycled off the network. And because of our strong validation conditions, it basically means if we have enough storage, it's on the network and it won't be flushed off, which is really important for the longevity and robustness of portal, which isn't there with IPFS. Also, they use TCP, which has much higher latency. I forgot to mention our talk, but we're based off disk v5, which is the current day node discovery protocol for Ethereum.

And it uses UDP, which is much quicker for getting responses back. Especially if you have to ping multiple peers, that adds up. Don't some nodes need to sacrifice in portal network for this to work? Not lots will run archival data, but lots may query it and these might get spammed. So a portal node would only need to hold a very small slice of the data.

So if a full node is only storing one gigabyte per portal, they probably wouldn't really notice it. There is no real requirement that they store all the archive on their node. The idea is that all the full nodes on Ethereum store way less. And it's like they all contribute, where currently it's like every node has to store all the data. What if we did this a little more smart, I guess?

What are the guarantees that the data will not be lost over time? I think the guarantees is kind of analogous to what I said earlier about validation. Any storage we have above the minimal requirement is used for redundancy. But if worst case scenario, there's other archival solutions, Portal is really good for accessing the data, but in a worst case scenario, you can use archival formats such as ERA or ERA1. So the data wouldn't be lost if it wasn't on Portal.

There's optimized formats for archival. Portal is really good if you want to access it. What is the most resource constrained device that has been a peer on portal? For us, it's basically been, I guess, Raspberry Pis. I know Raspberry Pis have gone a little strong, but I don't, like, when we run it, we don't even use a core, and we use, like, 300 megabytes of RAM, so, like, something with maybe, like, 500 megabytes of RAM would be fine to run Portal on, and we haven't even optimized it yet.

Does Portal support WebSocket connections? Through the RPC? That would be dependent on the implementation. Ours does, but it's, I guess, the implementation's choice. Cool.

Can we get another round of applause for Colby? Thank you so much.