# The Portal Network by Piper Merriam | Devcon Bogotá

- Speakers: [Piper Merriam](https://streameth.org/speakers/piper-merriam)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 24:51
- Watch: https://streameth.org/watch/yt-0stc9jnQLXA
- YouTube: https://www.youtube.com/watch?v=0stc9jnQLXA

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/the-portal-network/

The Portal Network is the culmination of five years of development and research targeting lightweight access to the Ethereum Protocol.  Learn what the Portal Network is, how it works, and what it will mean for Ethereum to have a reliable decentralized network tailor made for end users to interact with the Ethereum protocol.

Speaker(s): Piper Merriam
Skill level: Beginner
Track: Layer 1 Protocol
Keywords: Portal Network,Light Client,Protocol

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] um I'm Piper as she said and I'm here to talk to you guys about the portal Network um so let's just get right into it um the I work for the ethereum foundation I already got introduced um so this is about actually finally bringing lightweight decentralized access to the protocol and uh and yes this has been kind of a a long-term project to get us to where we're at um here we go so let's like dive into kind of at this high level what the portal network is uh for me it's a giant white whale that I've been hunting for a long time and hopefully doesn't eat me in the end um but the portal network is uh five new decentralized special purpose storage networks uh that serve all of the data that is necessary for interacting with the ethereum protocol and this has been a long road to get to here uh we spent time way back trying to build lightweight clients on the existing networks and where we ended up was that the existing networks don't give us what we need to actually deliver lightweight protocol access and thus we have these five special purpose storage networks that we are building out to serve this data and to essentially realize this uh this dream of lightweight access to the protocol um the project has kind of these highlevel design goals that kind of informed what we needed to build and how it needed to get built um and one of the main things is that the portal network is really user focused um all of the clients that you hear about today uh uh geff Basu Lighthouse all of that stuff right it's infrastructure for the protocol and and those clients are built with the protocol in mind and and the user facing stuff right the Json RPC API they're not the lowest priority but at the end of the day those clients serve the protocol and not the users um one way to look at this is that if you want to interact with the ethereum protocol today you have two choices right it's the we upper right or lower leftand corner of this graph you can run a full node they're very heavy and they're also awesomely decentralized our there's a number of choices for what to run but in general when we're talking execution layer you're talking about very heavy pieces of software we'll get into the details of this in a minute um on the other end of the spectrum you've got lightweight but centralized options like Alchemy or infura things like that um somebody at the last conference told me that I was a boomer for calling it in fura I thought that was awesome um so anyways you've got these lightweight options but they're also centralized and they can do things like correlating your IP address with the transactions you send or selling your data and things like that right we the there are two options at the far opposite ends of the spectrum and we want to build this thing in the upper leftand corner this kind of adorable pink smart car that is both lightweight and decentralized which supposedly we care about um this brings us to this lightweight concept um like I said ethereum clients are and we want we need a network that allows lightweight devices um to participate um ethereum clients are heavy today because they have to do a lot of things uh evm execution is CPU intensive running the transaction pool is CPU intensive and there's gigabytes upon gigabytes of history and state data and things like that that they need to do um this means that running a traditional ethereum client is a inherently heavy thing and you generally can't do it on things like raspberry pies or phones um over here on the left we've got this nice little strong guy who can hold it all up that's your like traditional execution layer client our goal is building out a network that lets you spread things out that takes all of the load for all of this data and distribute it around all of the participants of the network in a nice kind of even way um the other thing that we focus on is kind of removing some of these height rest restrictions and by height restrictions I mean essentially Hardware restrictions that keep you from joining the network um this is one of the things that blocked us from Building light a lightweight client years ago was that you've got these sort of you must be this tall to ride things um you are not allowed as a uh as a participant in the the dev PTP Network that's the network that supports execution layer clients you can't be part of this unless you have all of the state and all of the history and enough processing power to process every block and enough processing power to run the transaction men poool right if you aren't tall enough you're not allowed into that Network um we focused on a different model we wanted people to to be able people clients computers whatever we needed a network that allowed you to show up with whatever you had and to contribute it to the network if you're so willing the idea is that all of these networks operate on this exact same principle which is that as a client to the network you can tune some parameters that dictate how much storage space the network is going to ask of you that dictate how much processing power the network is going to ask from you and one of the other major things that we focused on is kind of this ux thing which means to me elimination of sync times uh traditional clients have bad ux in terms of like the user facing stuff and that's because you either have to when you start it up you've got hours or days to wait for it to sink and if you go offline for some period of time you often have additional time to catch back up to the tip of the chain these sync times make ux for kind of like enduser um interactions kind of basically unbearable this is why almost all of the userland traffic goes through services like Alchemy or infura um we've designed a system where all that you need to do is have a view of what you think what you trust as the front of the chain and from there all of the data is accessible to you which means the difference between hours or days of sync time from from zero to being able to actually inter interact with the network to being able to be interacting with the network in a matter of seconds or at the worst network conditions a minute or two as it has to peer with some some other peers in the network so um really focusing on on user facing things like this uh the other piece that we needed was something that was scalable um and we're not talking this scaling this isn't sharting scaling or transactions per second scaling this is a number of of network participants this is M having potentially millions of nodes be part of this network some of the past work towards uh ethereum like clients is Lees that's the light ethereum subprotocol um and this has been around for 5 years maybe um and it is never really delivered on this goal and the main reason here is that it exists in this client server architecture um L nodes on the network are dependent on full nodes serving them the data and what happens over time is that a full node who's serving this data uh ends up getting kind of just assaulted by all of these Lees noes constantly asking them for information and they're expensive requests that these nodes are making um and it hasn't turned out super well um Lees has not proven uh has has not delivered a reliable like light protocol access and the main reason is this imbalance between client server stuff um that there's no incentive there aren't incentives to run Lees servers running an Lees server just costs you something and so the ones that are out there are being run by the goodness of hobbyists and other people's hearts or people who misconfigured their client on accident or something but either way it it is it is a uh it it cost you something and the clients in this network are not able to contribute back as an Lees client you are purely taking from the network and that is just the way the network is designed in fura alchemy they're this centralized model right their servers go down everything stops working at Lees is this decentralized model which we like but because there aren't enough incentives or anything for people to run Lees servers uh it hasn't worked out super well um we've moved all the way into this distributed model where we have a homogeneous Network where everybody in the network is a client and everybody in the network is a server uh one way to think about this is very akin to bit torrent where the in Lees you have this like kind of degenerative thing where the more nodes you add into the system they take up a limited amount of capacity and once you exceed that it degrades service for everybody in the portal Network context we have built these networks around this idea that the more nodes you throw at it the more powerful it gets and that's kind of the whole core part of this all right um let's look at a practical example of what uh uh how you would serve this um uh essentially a balance inquiry uh from the portal Network I'll remind you we've got a number of different networks here the idea is that they're all sort of special purpose partitioned off from each other um clients can be part of any number of them that they want um this example is going to touch three of our networks so what we're going to do here it's a very simple example we're looking up your ether balance in a tradition so this is our traditional client you've got databases over here on the right where they're storing information it's running this jsonrpc server a request comes in to query my balance the jsonrpc server is going to do a couple of things here it's going to reach into an index to figure out what the client thinks the head of the chain is it's going to look up the header for that header from it store uh from whatever database it stores headers in once it gets that back it can look at a field inside of that to see the state route and then it reaches into the state database to actually read your account balance right this all happens very quickly under the hood and the reason that a traditional ethereum client can do this is because it is maintaining these three these databases that it is constantly online and it is constantly keeping these things populated the portal Network concept is very similar right there's very little right this is like oh God did no wrong direction too much uh so in the portal Network context when this ethit balance uh request comes in instead of reading from local data bases what a client's going to do is it's going to actually reach out into this these networks that it's part of to get the data um we have a network for essentially tracking the head of the chain that provides uh the uh Beacon Light protocol data uh your client's going to reach into there to know what the front of the chain looks like which uh what the head of the chain is it's going to use that to pull the header from the history Network which stores all of the historical block bodies headers receipts things like that um and once it has that it can look up what state route it's supposed to be looking up things under and it can reach into the state Network to grab that state look up your balance and return it to you uh this is a very simplistic example but this is very representative of what the majority of requests are going to look like there'll be a little bit of sampling of data from different networks in order to get the information that you need before it's returned to the user all right where are we at um like I said this has been a long road to get here we had to build some of the wrong things to figure out what the right thing to build was um and and at and at this stage this uh we're we are we are past the research stage we are purely in the get it built and get it out the door stage uh we have three different imple client implementations um this is fantastic I'm so happy about this because we wanted to build a protocol not a singular client we wanted to build something that had many clients to it and that would instead of just one reference implementation we've got Tren written in Rust by my team at the ethereum foundation we've got ultralight written by in JavaScript by the JavaScript team at the ethereum foundation and we've got fluffy written by the Nimbus team run by status and um and here we are uh so here's our rough timeline right now um software estimates are garbage uh imminently we are right at the edge of getting our first Network really fully up and running that's the history Network um in parallel to this the merge has sort of kicked off us having this Beacon Light Network and that's sort of like our next major priority and after that over the course of 2023 we are going to be getting the remaining networks online uh the zero to one is a lot harder than than building the subsequent networks that come after that and we've spent a lot of R&D uh getting to this stage where we almost have the history Network up and running um that is what I've got for you today um if you want to get involved we are are findable on the internet like Danny has often said the doors are all wide open and unlocked if this is a project you'd like to get involved and uh please feel free to reach out to me and I've got some time for questions if uh that's something we can do I think we've got a guy with a mic walking around uh I have a question related to like the API endpoints which the portal Network can s will it be able to serve like ebug end points that like need like a whole archival stories on notes if I understand correctly you're asking about the debug spaced jsonrpc endpoints yeah uh not initially um all of the data to do things with those will in theory be present um in the network but we are really focused on like um human driven wallet interactions that's kind of like our primary use case that we're that we're focused on delivering and the debug in points just don't play a role in that um and in general are going to involve a much heavier level of requests and like data access than is uh traditionally involved in in kind of standard wallet interaction so no the debug name spaced in points are not officially supported thanks from the perspective of a application layer client is the thinking that an application would be like speaking directly to like an application would want to run one of these like clients itself and speak to that or is the thinking that for some reason you would bundle the client itself into the application or neither of those things just trying to Gro what the use case is I I think I understand the question um so the the there's a lot of ideas on the table and exactly which ones are going to stick and which ones aren't is right we'll find out as time goes on but the general idea was to build a network where the clients can be lightweight enough that you might have two or three of them actually running on your machine at any given time because in theory they're lightweight enough to actually embed so if you're you know downloading a desktop wallet um and the portal Network's up and secure you know uh uh up and live and production ready there's it's entirely likely that it might just bake the client right into the into the application that you're running and there might be two or three others running alongside of it um one of the things that my team's going to be focusing on is sort of like a system level process that's really easy to download and install that just runs the thing in the background which makes it easy for you to do things like connect metamask up to it or things like that so I don't think that there there's one model here I think some applications might embed it some might treat it as an external dependency there y there we go yeah so something that I'm from with the ls client that um is that when you want to execute for like a smart contract call you might need to do several run trips because you are basically every time that you need to query State you are going to uh go to the full node and ask for something right and that maybe creates like again several round trips which increase the latency of like whatever you're trying to do so is with the portal Network you kind of have some solution for that like trying to kind of batch that uh I think the question is because the requests are going out to the network there's going to be some inherent latency overheads that come with that um not that precisely but that you're going to do multiple requests so for example if you want to do rc20 balance off you need to download the smart contract then you need to start executing and every time you need to access some part of like the state uh database you're going to just go again and make a query and so you are basically doing multiple request multiple current Json RPC request that's the the kind of concept here yeah I think currently you you do that sequentially and so basically you are increasing the total leny of like balance off um but if you can find a way of like doing that concurrently or batch now that you only do a single request I think that's going to be a thing that uh individual portal clients figure out on their own there's nothing inherent about the networks that keep you from looking up large swats of data in parallel at the same time um and any anything that can be parallelized at that networking level will definitely benefit um total amounts of latency that users experience uh where do you or do you see Zero knowledge being used in an implementation of a like client for the portal network uh currently it isn't part of any piece of our road map it's uh not my expertise um so I don't know I think is the concise answer there okay thank you um just had one quick question uh what what prevents me from running a light client and making it like making it a freeloader that does no work how do you prevent against uh we don't um so there's two things that I'll say here um one is that we had to pick some cfff points for what we were building because this is big like like I I I I took a lot of stabs at making lightweight protocol access in smaller ways and this is what came out of Really Trying a bunch of things and then not working so so in order to deliver this we needed to build something that was much bigger than I originally thought we were going to have to build and in that we had to like kind of cut it off at a point um the thing that we're building is attackable there is a attack surface that we that that that that exists and the general idea here is that those are solvable problems and we're not going to focus on absolutely trying to make sure that we have them all solved on Day Zero uh the portal network is not core infrastructure not at the protocol level the protocol as as we know it does not depend on the portal Network for anything and so if the portal Network Falls over ethereum does just fine and initially it's possible that somebody attacks it and that probably means we're doing something that's working because it's worth attacking so that's the one piece which is that we have built something that we know we are going to have to hone and fine-tune and work on the security part of it I have a second question that might be leading kind of also curious if uh if I choose to make my L client act maliciously and you asked me for the E Bal go Freo got uh the network is designed to like like if there are too many freeloaders it'll degrade performance for everybody um I'm relying on essentially two things which are uh the laziness of people so people are inherently lazy and so going and configuring your client differently than how it ships is like something that people often won't do if it's working just fine and if we ship it with sensible defaults that aren't running your fan speeds at full speed and aren't filling up your hard disk the chances of you taking the time to go in and tweak those settings are pretty small and there's a and and and you can call it altruism or you can call it laziness but we're fundamentally built on this idea that these small contributions of lots and lots of people add up to it a lot right bit torrent works you can download things pretty fast on it because there's a lot of people doing it and most of them aren't screwing with their settings too much to just Leech from the network so um can we get the mic over sorry yes I'll get you next uh yeah just a small question you mentioned the beacon line light client Network as well so what sort of data are you planning to distribute in the beacon date CLI Network that you talk about um there's I believe three data types that we'll be working with um I am going to potentially botch this if I list it off the top of my head um Kim on the uh fluffy team is the one kind of leading the like R&D or the the specification for what that Network serves but it's the like client update objects um and there's like one or two more but essentially it's the minimal objects that we need to be able to do the Beacon Light protocol to jump to the head of the beacon chain I can't hear you I'll repeat your question I was just wondering um when you're testing on a day-to-day uh what user flows are you using for your tests well so we are designing at the Json RPC API level so we're not necessarily building interfaces for people we're taking the Json RPC API which is like the standard API that execution layer client Expos to users right this is what Alchemy generally exposes these are the things that metamask is like calling to um and so while we are user focused we are building out clients that can serve the Json RPC API which is still a low-level thing right you're still talking about computers talking to computers um the wallets and things that get built on top of this um that's I think the type of user testing you're potentially asking about and that's kind of like outside of our purview um are I I guess you could say that the wallets are our primary clients and that the users are the wallet's client uh two questions are we talking about one: one Json RPC compatibility and then the second question is what does the road map look like for l2s because light clients are inherently very useful uh for cheap operations and that's kind of where stuff is going so that's it I think you asked whether we're building out a like one: one to the Json RPC API we are not trying to redefine the Json RPC API it is established and has been successful and is generally the backbone of any kind of ethereum interactions that wallets and things are making and so we are building off of the existing standard um I don't have an answer answer for you on the L2 thing um it's an open question we'll see how it goes and that is all of my time thank you all