Decentralizing access to Ethereum utilizing Ethereum's Portal Networks

[Music] hi uh I'm Colby morage leel and I wanted to give a talk today on decentralized decentralizing access to ethereum utilizing ethereum's portal networks which might sound a little weird but it will make sense to the talk uh so the origins of ethereum is it's like was creating a program able 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 uh 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 of in Long running processes because if you turn off your laptop and turn it on you have to resync which is kind of hard if you want to send a transaction you have to wait a few hours uh 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 uh I would say one of the greatest inaccessibility to ethereum is knowledge being able to run a node is a a feet which all of us in the room can do but can your grandma do it and if 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 uh time you need to sync a node as I was saying like if you turn on a laptop like on and off sying 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 uh it's projected in the next four months by East stakers that that validators will need to update to 4 terab discs and my little picture of like the man holding the world which is like a GU 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 uh earlier when I said the origin it's something we didn't want so with the one of the main concerns being the storage requirements there is this Nifty thing called E4 fors or history expiry where in The Purge path this is basically What If instead of all node storing all the data we lowered the costs by not requiring them to store old data what's no longer reibly needed to run a validator uh this doesn't mean nodes can't store the history but it means they're not responsible for it all and but how do we achieve E4 fors and enter the portal network uh what is Portal instead of depending on phone loads which hold all like the whole pie of data uh what if it could only hold a slice of that data uh portal distributes this responsibility amongst numerous small nodes what 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 uh portal is also sustainable uh it's both a server and a client which is very important because this problem has been here for a very long time uh previously in the past there's been attempts at this for example Lees which the concept of it was an ultra 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 uh but how does this work uh portal uses a fundamentally different peer-to-peer model than ethereum today uh through distributed hash tables uh distributed hash tables and enables decent decentralized storage and lookup system uh where each piece of content is addressed by a unique identifier and stored at and stored in multiple nodes for redundancy uh dhts make it possible to be able to look up the data even if you don't sort 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 uh and as I was saying a totally different peer-to-peer model portals also a replacement for the Legacy Dev peer-to-peer network uh in that imag dead P top is this triangle where you have to you have to participate in everything to access anything uh portal breaks this up into different networks uh one of our first ones what we'll be launching is Portal history uh and then there's others uh but what does each Network do portal history contains headers bodies and receipts portal state allows you to access the state such as your trans such as your balances and Contra ract storage portal index is if you want to find which block body your transactions in and the portal transaction mol will be very interesting with fkl and stateless clients uh currently there's no hard solution for how we'll handle sending transactions in a stateless world and we believe that portals uniquely 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 you can basically run a p 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 need to run a GU node but to run a GU archival node that requires 20 terab of storage which is massive and it also takes like over a to sync which if you just want like quick access to this like 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 uh so portal is fully provable which is huge uh there's kind of two paths to do this uh so you could use our portal Beacon Network which will be very useful for w for wallet use cases where you could basically put port portal directly in place of a centralized provider uh portal Beacon network is an implementation of the consensus layer lik line 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 and it's proven uh a big use case though will as I said before will also be for uh 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 uh 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 no dependency but if you needed State you would have an additional one and by doing this you can you only need to run a portal network of what your requirements are for the use case uh how do portal clients initially get the data uh currently it's through Bridges bridges are basically full node 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 uh 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 CET blocks around the network but they'll only need to gossip us to a select few peers where if they have 50 peers now that nodes Only Store a slice it would they' only be required to gossip this data to maybe 10 or 5% which saves bandwidth uh incentives so why would people want to run a portal node uh well Financial incentives are hard uh 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 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 uh there are other projects trying to achieve this appro 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 uh e we believe that ethereum's protocol has innate value uh that that innate value is being able to send money uh 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 uh I we think the incentives are aligned for people to run these nodes uh use cases as I said earlier lighter full nodes uh with storage C with storage requirements increasing uh being able to add for Force while maintaining current day uxx uh ux by if you just implemented 44s your node would have no idea of what the pass history was with 44s your execution client it would be like you could fully respond to any request and it would be like nothing ever happened uh another thing is nearly instant think times for full archival 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 uh but what's the catch you may be asking I'm selling this this solution what seems too good to be true uh is it like so the trade-off is between latency and storage uh 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 tradeoff for a majority of use cases is correct is like actually there and like the only time you really need quick access as if you're block building and for mobile wallets if it's fast enough it's good enough uh so for the first time you can choose how you participate in ethereum's protocol uh I think this is kind of analogous to the infinite Garden analogy that is often told on ethereum's future uh 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 for full protocol it's finally a choice instead of a requirement to handle it all which is yeah really annoying uh who's building portal clients well the ethereum foundation has been at the center of this from the start but we have all but from the start we have also been assisted by status and ethereum Js which has been massive uh recently nethermind has been taking the stage and for execution layer clients they have been working the hardest on this from the from pretty recently like last year which is really cool there's open- Source teams from around the world who are building clients uh another client is being built by EPF members and I guess you guys could build portal clients as well uh we have clients being built in all the these languages so if you want to use portal you can uh I'm sure everybody would be like happy to answer questions and I think we covered like the whole stack which is cool uh portal history is ready for developers to start using and we have the data to back that up uh so we built a sta a statistics platform for like seeing if our stuff works and we call that GLaDOS uh for the past few months we have 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 uh 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 Tren desktop which is Hope hoping to Target everything but the browser so hopefully like ethereum Gs does that for us uh here's the front screen you turn it on and it's like woo stats but you can also you do eth get block by number get block by hash uh 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 uh and it's also as I was saying earlier you can configure your storage requirements so if you set 2 GB you'll only ever need to contribute 2 GB you won't need to buy a disc in a year which is really cool CU it sucks to buy a 4 tab disc when you already bought a 2 tbte one uh so now anybody can participate in ethereum's protocol uh as I was saying earlier you could just integrate that into a wallet and the user wouldn't 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 like invite which is really useful if you want to ask questions we have our website with guides and like blog posts and how to set up most of the clients already uh we have a Twitter which uh our team hates Twitter but it's like good for like getting people to know stuff and then we have specs so if you want to contribute every team is super open to it uh and they'd be like super happy uh we need to improve our issues a little bit but that can be fixed and yeah so uh thank you for coming to I guess this talk on Portal uh and yeah thank you okay so let's go through some questions I'm going to read them for you um can I use portal Network today to check my balance if not when same question for doing an eth transfer uh so you can check your balance if it's within the first million block so if you guys are if you guys used ethereum 9 years ago you can check your balance today uh we expect balance for like latest account for like checking balance for the head to be available in q1 or Q2 uh 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 uh I would say the biggest thing has been awareness two years ago people are like what portal and then it's like 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 like referencing portal like the 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 uh what is the minimum percentage of network data that a portal network is is expected to have uh so we have thrown numbers like 100 megabytes but that's fully configurable uh since the requirements are so low for our client at least we wouldn't be surprised if we set it to 1 Gaby because realistically someone 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 um and I think the next two questions can be combined how does portal Network compared to Classic uh peer-to-peer file sharing Network such as bit torrent uh so one of the problems with bit torrent is it doesn't have a inherent way to like 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 uh portal is different in that all the data you can fetch from the from the network is provable so it's much easier for a client to like let's say fetch any piece of data they 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 uh for writing a portal network node I guess like if you wanted to use it in your wallet and you used a language what wasn't there yet uh 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 backend uh yes so the idea is like portal would have all the act all the data that a 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 uh who do you think will be ready to operate these alter istically uh I think that the the top three execution layer clients would be running all these so by default so that's like a lot uh other than that like if you're running a wallet on your phone I guess that's like an Altru that's not really altruistic you're act you have actual utility in that uh so I think we can do quite fine with while 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 uh so some of the issues with ipfs is since they have no validity scheme uh 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 uh which isn't there with ipfs also they use TCP which has much higher latency we're I forgot to mention our talk but we're based off dis V5 which is the current day node Discovery protocol for ethereum and it uses UDP which is much quicker for like getting responses back especially like if you have to Ping multiple peers that adds up don't some nodes need to sacrifice for portal Network or in Portal Network for this to work not lots will run archival data but may Lots May query it and these might get spammed uh so a portal node would only need to hold a very small slice of the data so if a full node is only like storing like 1 gab for portal they probably wouldn't really notice it uh there is no real requirement that they like store all the archive on their node uh the idea is that all the like full nodes on ethereum store like way less and it's like they all contribute where currently it's like every node has to sort all the data what if we did this a little like more smart I guess well what are the guarantees that the data will not be lost over time uh I think the guarantees is kind of analogous to what I said earlier about validation uh any storage we have above the minimal requirement is used for redundancy uh but if worst case scenario there's other archival Solutions uh portal is really good for accessing the data but in a worst case scenario you can use archival formats such as era or era 1 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 uh what is the most resource constrained device that has been a here on Portal uh for us it's basically been I guess raspberry pies I know raspberry pies 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 f a run portal on and we haven't even optimized it yet does portal support websocket connections uh through the RPC uh that would be dependent on the implementation uh ours does but it's I guess the implementation's choice cool can we get another round of applause for Kobe thank you so much