Resilient Networking Hub - Building Resilient Ethereum

Transcript

is yours. >> Thank you. >> Hi everyone. Uh first of all a very warm good morning. Uh wish to share. Uh we have a number of slides ready. Would love to have questions. Let's make it interactive like a flip classroom. That is always uh our strategy for doing discussions. So let's uh get started. So essentially I have two of my very good friends coming to India for the first time. Shocki and Leo. Shocki is going to present one of the important areas.

He'll be ensuring that we are not in bunkers mode. Uh we are doing quantum research and doing it at scale. And second essentially is Leo who is touching on a very interesting and a key insight which is on formal security. Formal security I do wish to share is one of the key aspects that ETH labs friends from there just told me that we should have research going in formal security and Justin Drake my dear friend from uh PQ interop he specifically mentioned that we should have interesting work going on in the quantum resistance efforts. I'll be touching base on something very uh interesting on the Ethereum front which is uh basically uh the internet of agents. So as you are aware that we are heading towards an economy which is the agentic economy and

there are multiple initiatives one uh by Cisco on the internet of agents and the other by Google which is agent mesh uh and lip P2P essentially which is the uh you can say the networking layer for all the Ethereum consensus clients. We have also been used by number of internet of agent projects and our talk would essentially be around like how lippy and how the overall networking stack along with IPFS could enable the next paradigm shift and where Ethereum could be the trust layer for these internet of agents where the observability the attestation the uh signature scheme the verification and the overall uh you can say the trustbased ecosystem in the internet of agents what they're supposed to do what

they're not supposed to do what is the agent action capsule system for an agent? All of that is handled very nicely with liptop as a networking layer. So we would touch base on these aspects. I believe that a combination of these three goals will kind of empower what we'll call as the next superpower of Ethereum like the next key initiatives in Ethereum are going to be guided by these three efforts and we look forward to touching base more with all of you at the resilient networking hub and uh we'll get started with our session. First I would like to hand it over to Shocki my dear friend from Japan from Nyx. Uh he'll be sharing his discussion on uh postquantum interop and postquantum ethereum. You would like to get started. Thank you so much.

Hi everyone. I'm Shi from Nix Foundation. So today I want talking about the post down for Ethereum. Uh as you may know we should uh move on to the PQ ready which called the banker mode by Justin Drake and uh a lot of people talking about the postcon signature for uh execution layer or consensus layer which replace the ECDS and PS but uh nobody talk about the P2P. So I want to talk about this in session. Our goal is identify the PQ uh what is we should replace for and uh we should uh focus on just only for discovery file which is clients implementations and

specification and uh if we can do uh we want to make a EIP in this discussions. Okay, here is a quite uh kind of the diagram to explain the what is going on in its bel and the purple uh part is just uh defined in it spec and the blue part is defined in lipid lip is kind of the library in consensus layers and uh in this session we just focus on the purple part. Okay. So what first uh each client start their own node and they find uh which should connect to. So we can get a

peer by discovery five algorithm which is a kind of discovery algorithm is originating inium and uh at uh at that time we can find a node and they can connect with each nodes by uh discovery and after we find the own nodes they kickstart the repeat and which is based on quick protocols. Next slide give a 101 on what exactly is going on for a lot of our beginner friends who looked at soggy slides and they were interested in understanding what the overall concept is. So essentially quick is the transport layer. It is essentially used by all the Ethereum

consensus clients. And if you try and understand what's really going on at the networking layer, you have identity which is the identity layer. Then you have secure communication channel where you have TLS, auto TLS and noise. You have essentially the peer discovery mode. In the peer discovery, we have like four different modules essentially bootstrap, random vog, rondu and uh multiccast DNS. Multiccast DNS for local search and local peer discovery. Bootstrap is what we are using essentially. Then along with this uh there was some very interesting insights that was being shared with us yesterday and some questions like how are we doing peer communication. So in reference to peer communication we first need to understand that there are three different approaches. One is gossip

serve. In gossip sub ethereum is using gossip subub 1.1 but we also have support for 1.2 1.3 which is partial messages at the newer approach which is used by lighthouse and prism. We also have gossip subub 2.0 and along with this we have flood sub and cred topology. So these are some of the peer communication channels one needs to understand when they are looking at the networking layer. On the routing front we use cadmia dht. So that is one of the key things you need to understand. There's a very interesting paper by David Mazerus which I would love that everyone uh in the uh like anyone who's attending this session would love to read about that paper. They'll get lot of knowledge on how routing is done.

This is also something which we are using in the internet of agents. And the final thing which everyone needs to understand uh and you should be like fully aware of what's really going on under the hood is that all of these things we combine together in a seamless manner like a modular stack and then we kind of build the consensus ecosystem and in reference to consensus ecosystem 100% of Ethereum clients they are using lip P2P at this juncture lighthouse is like 47% of the Ethereum consensus client market share that's using rust lip P2P prism which is around like 23 or 27% is using go lip p2p. Then teu which is an institutional ethereum client that's using java lip p2p. Trinity is using python lip p2p. Loadar nimbus uh

loadar is using zig and gsl lipp2p. Nimbus is using zig lip and then finally I also wish to share that if anyone is trying to develop a newer lean ethereum project we look forward to supporting you in reference to getting it going. And my dear friend is a maintainer of Haskell that we do. So let's continue with this but this is just a 101 for anyone trying to understand this. So as I mentioned we can get a P ID by ENR which is a data format and it's like a DNS table which contains the IP address and identity something like that and uh which is a more like fundamental things for each node's identity uh which is also signed by ECDSA like SCP K1 carb

uh so we should replace this part as well at first Sorry. >> Uh okay, we can skip this. Here is a quick diagram for discover. >> Yeah. Yeah. Yeah. Yeah. Yeah. >> Yeah. So, in reference to this specific diagram, you need to understand that bootstrap is the peer discovery method. Kadimia is the peer routing system that we are considering. You can also build your custom routing system. But I would recommend using Kadima DHT. It's already been used everywhere. I do also wish to share with you when you're using lookup, you're essentially using kadima dt. when you're doing bootstrap you are doing peer discovery and when you are iterating over so we are basically following this kind of a structure for ensuring we have a disk v5 peer discoveries.

>> Thank you so much. >> Sure. >> Uh yeah so uh after they discover on uh target node id we can uh connect by uh establish a discovery session. Okay. So at first they send their own random content to node B and node B respond with a challenge. After that node A make all session keys and uh send them for node B and after that we can make a encrypted uh secure channel with node A and B. So ENR is start very important for kick off and get us make a session keys.

So as I mentioned uh here is uh we we have a two type of uh target to replace the ECDSA or HDH. Uh one thing is ENR data format and the record signatures and the second part is a key exchanges part which is powered by discovery 5 and both of them it relies on ECDSA or HCDH. ECD is a kind of signature format and the ECD is a key exchange uh thing. Yeah.

>> Yeah. Just uh one specific thing we wish to add for anyone who is trying to understand what is really happening in reference to quickest TLS. Quick comes with its own multiplexer with its own TLS and it is think of it as a transport plus a mini P2P version with multiream select. If you just add multi seam select with quick, it is in itself a minimal viable stack for ensuring that we can run P2P. What we are essentially trying to do over here is we are trying to understand the classical schemes, the role of them and the component. Just a quick 101. If you're trying to use quick, you do not have to have a separate multiplexer. It comes with its own multiplexer. If you're not using quick, then we would like you to recommend two different multiplexor operations. One is Yamox, which is yet

another multiplexer. We also support mlex as we have in Nimlip P2P which is used in Nimbus client. So MLEX is used still over there. Although I do would recommend that anyone who is hacking and is doing development try out Yamox. If you're using quick then you do not have to worry about all these things. They're all coming together. And in reference to the key signature that shock is very nicely explaining I do wish to share that these this is kind of a combination for the secure communication channel. So have secure communication channel with the transport and you're ready to go in reference to peerto-peer.

>> Yeah, thanks so much. So we need the uh key exchange to make a secure channel as I mentioned before. Yeah, thanks so much. So yeah, we have a two type of threads. One thing is for key exchanges and the second thing is a key uh signature things. Both of them have open uh thread model. So key exchange is if we lost the attacked by quantum computer uh the adversary can decrypt the all of records. So we can uh uh decrypted by the adversary. So we can uh our communication data is opened by them. So a signature things is uh very easy to understand. We can uh adversely enable

to discover the uh message or how can I say uh sorry uh >> don't worry don't worry >> yeah yeah yeah pretend to more uh more like a honest party yeah >> sure so just wish to share one specific thing first of all was trying to visualize how we kind of ensure that these threats are taken care of in a proper manner so I think it's a very easy way for you to kind of visualize This try and see first of all quick this is first of all without ECH we have not added encrypted client hello to it this is a new addition which is going to happen lip P2P I would love that all of you you participate in the spec of lip P2P so there we have a proposal which is

using quick with EC what shock is saying is that if you have key exchange and you have quick and TLS you can do record now and decrypt later which is essentially the thread part which we are trying to handle and then signature forgery with a quantum computer I mean how you take care of it he's giving doing a full end to- end description. I would like to share with you there are at this juncture six spec proposals which are there on quantum resistance. I would definitely like some of you to participate. There's a very key proposal which is on PKIX support for lip P2P and that I feel is the right approach if you have to extend to different types of quantum research algorithms. Whether you want to do MLDDSA, whether you want to look for some other ecosystem like for example Algorand or Hideera bringing

their quantum signature approaches then we definitely are interoperable and supportive of all these approaches. We are used by all the blockchains. So we definitely feel at this juncture that having a support at a PKX level on the lip front. This will ensure that all the blockchains that we have they're quantum resistant. >> Yeah. Thank you so much. >> Yeah. So we uh Yeah. So we move on to the what is the problem for current spec in isium P2P layer. So one thing is a signature things we should replace the kind of ECDSA to more like a post quantum signature like hashbased or latis based I don't know but there is no correct answer for now. So we have a two

type of signature ENR and handshake signature. Okay. So one problem for ENR site is a cap of uh ENR sites. So currently they have just 300 bytes because you know a big uh big message would be more increase the uh bandwid make more complicated network things. However, uh current model like MLDDSA or something like that is more higher bigger than bigger signature and the public key size is more than one kilobyte or 2 kilobytes. So it's this is a problem for us right now.

>> So these are the current limits and the MLDDSA 44 example. If you wish to consider an case where you are exceeding the specific threshold limit that is also very well handled and we have like proper PC's proof of concepts on how to handle this. We would love to have discussion with you post the session on how we can ensure that if you are exceeding the limit how it is handled at the infrastructure layer. >> Yes, thank you so much. But we can I think we need a more kind of the zk things so to compress the size of signature to make a new zk proof which is a more smaller size I guess I think that is one of the solution for now.

So second part is discovery five ex uh key exchange problem. So we needd which is based on the cab and we should replace this part as well. So yeah uh I think we don't need this topic. I >> we uh let's uh I like to share one. >> So if you're talking of the communication part over here where you have node A and the node B section what this is basically sharing with you is a key exchange format. So key exchange is absolutely important. I mean if you're trying to have support. So think of it like this. you have a consensus client sitting at the top and below it is the infrastructure layer and the infrastructure layer is supporting the consensus clients. I'd like to give one

specific example where if this does not happen what kind of problems we can have. So recently there was an integer overflow uh that we found in one of our implementations. I would not like to name it because we just fixed that security issue and it got merged for the release. So I do wish to share that the next type of attacks which we are seeing in case of Ethereum is it's not like the key exchange problem. It is not like someone trying to figure out your wallet key or an application hack kind of attacks is like nodes not talking to each other. It's like seal attack, eclipse attack and network partition attack. So once you have those kind of attacks what you are basically having is like nodes going out of sync. Once nodes is going out of sync then all the D5 protocols which are built on Ethereum

they are at risk. So how do you handle all of that? So for this what we are trying to basically do is we are trying to ensure that the infrastructure layer has all the key ingredients and the support that enables that any of these attacks can be mitigated. We have an observability system to handle this and at the quantum level when it happens there I do wish to share we are building infrastructure pieces at the spec level which is one of our core spec initiative shocki is one of our key members in that and what we are trying to do essentially is if you are developing an algorithm it's like bring your quantum algorithm to lip p2p we love to support it and this is essentially the key exchange part that enables that >> yeah thanks so much so I think we can replace ecdsa as a Latis based or

hashbased anyone anything I think but uh in term of the key exchange it is hard to replace by hash based I guess so one of the main option is a chem ML cm based approach which is latis based things and uh we can uh sorry uh we can cap encapsel with ML cm by or uh combine with current ECDSA1 so which is a hybrid model I think this is a main option for now I guess. So yeah uh we finished this my topic and what I mention is uh we should replace the two part key signatures and key exchanges and in term of the signature

we should focus on at first from the uh current ENR remit or discovery size five limits and for in term of the key exchanges we can choose just uh chem based approach I guess yeah so yeah that's it from me uh thank you so much. >> Well, thank you so much, Shi. This is fantastic. I really wish to share that this is one of the discussions where I would love to have participation from all of you. You can always reach out to us, join our bi-weekly spec meetings. We are discussing this almost I would say 70% of the spec meeting time these days is spent on this specific topic. And I do wish to share that we should get something out in this uh by the end of this year. Uh I mean we would love to

have something out. And uh if you also wish to reach out to us, you can reach out to us on uh discord that is lip discord. You can join us on telegram. We'll be more than happy to take this question and shi interestingly is a maintainer of lip p2p. So if you are working on hasll I mean this is one of the key approaches uh that you we would like you to join us with. >> Yeah sure. >> Yeah. So here are the details of shocki and I would also like to share some of the things that we have just for your learning purpose before I get started. I would not like to have my friend Leo waiting. So what we'll do is uh that I'll very quickly share the appendix.

I'll speak a bit on the internet of agents part and then I would like to hand it over to you. So uh we just wish to share that if you're trying to understand some of these things. It is not like in like uh one session or in 1 hour you'll be able to understand. So there's a way to understand all these things. I would strongly recommend you look at our spec guidelines the documentation. I'm just sharing with you some of the snapshots which you can carry in your mind when you're looking at the code bases. We are having all the maintainers over here. So if you have any questions, we are currently supporting 17 different implementation languages. So if you know uh say nim, dart, python, go, rust, uh javascript, net, you name it like C, C++. So we are covered in all the 17 languages and I do

wish to share that there are many more programming languages. Really appreciate that. If you are a new language developer, we would like to see an implementation of lip P2P. shock started hasll lip p2p implementation and I just shared with him that we need more functional languages uh support for lip. So uh these are some diagrams like lip P2P over quick I mean just go through this uh specific appendex uh this is a quick uh like a snapshot on connection key exchange would definitely like like you have an understanding of this if you have a set of questions you can always reach out to us I'm just sharing some of these uh appendix items uh so that uh we have some clarity this is on connection authentication connection authentication I mean how you make decision on the choices I do wish to share that we have

ITF27 coming in two weeks If you're planning to submit a proposal on quantum, we are definitely there. We would love to encourage uh more quantum algorithms making uh Ethereum quantum resistant. I think it starts from some of these conferences. So if you're planning to present over there, please reach out to us. More than happy to support you in this initiative. So uh we have uh some of the other explanations on how uh we do advertising of quick support and you can read through all these appendixes. Thanks so much Shi for adding all these slides. I mean they're fantastic and they will be available. Uh this gives you a very good understanding of how we really use the transport layer with the signature scheme that we are presenting and uh I'll get started with internet of agents. We have two more

sessions. Uh so yeah we'll get started like that. So uh before I begin uh let's do one thing uh if you can just transfer it over to Leo so that yeah he can be like the next >> yeah and I'll go forward with the internet of agents uh initiative. So thank you everyone for understanding and uh helping us out uh have a chart or a plan so that we are not in bunkers but we are actually ensuring that uh lip P2P or the infrastructure layer behind the consensus client that very well supports quantum resistance and there's a very interesting prize also if you're trying to do some research work over there we have poison prize by Stanford University it's a a million dollar prize this is essentially to prevent Ethereum from any

kind of a quantum attack then you have $600 billion of assets on chain. So it makes sense to ensure that we prevent the quantum attack. So if you are planning to participate in it, please do reach out to us. More than happy to support you in the positon effort. So uh the next part of my uh session or discussion or I would say the next road map which is very important for Ethereum is that we're heading towards an agenting economy where a lot of internet is going to be run by agents and that's why we call it as the internet of agents and essentially if you have to build a resilient Ethereum or if you have to ensure that Ethereum becomes a trust layer for these uh agents which are uh out there at the uh different levels across different enterprises across different network boundaries across

different organization boundaries. So we have to start at a a specific place. So what I'll be doing is I'll be giving you a 101 on the architecture on how we can enable that. So there is some diagrams which I'll be sharing with you. There are some mind maps which I'd like to share and I would like you to do it as an exercise which means try and come up with ideas and uh we do have a production project. It is done in collaboration with Cisco. We call it as agency. you can check out it's under Linux foundation and there essentially what we are doing is we have an a specific directory an agency directory service which is using lip at the routing level at the discovery level and also at the communication level second essentially is a messaging layer uh which is built on that it's a low

latency messaging layer then we have identity interoperability where essentially the agents can talk across network and organizational boundaries and finally there's nothing without observability so we have like hotel open telemetry and also some of the other telemetry formats through which we are ensuring that these internet of agents they can be interoperable. So let's get started. If you have the layers of agentic ecosystem what you look at is at the layer 1 you have lip p2p and ethereum at layer two you have essentially the identity piece. So what I have done is I have shared a new identity system. It's not just a URI based system but it is essentially a pastio or a topology independent trust system. Uh we also have the discovery mode where we are using kadima dht for routing. uh we have when you do a

specific inferencing using agents so what you do is you have distributed consumer swarm so there what we are doing is we're trying to reduce your GPU cost and also the memory and token cost as you know that the if you're using one of the harnesses that are available at this juncture the use of any of these specific systems it has increased considerably and there is also a very uh clear increase in the memory cost so we have some architectures some systems to which you can reduce the overall GPU cost and token cost. We run lippy to in two modes. One is a worker mode, the other is a federated mode. Think of it as scaling uh the internet of agents ecosystem. And by doing this, we are able to considerably reduce the overall load on GPUs as well as we are able to

reduce the overall load on tokens. And finally, I do wish to share we also have the semantic layer. This is very very useful when you're trying to build an evidence system, an attestation system, a signature system or you just want to develop an agent action capsule. try and understand whether a specific like agent has actually done something within constrained efforts or within bounds and this is very very important because as we are heading or scaling up this initiative this needs to be understood in a thoughtful manner like how the observability is done in reference to the network piece we are currently supporting all the uh protocols in agency and even in number of other Ethereum agentic projects even in agent mesh by Google so here essentially the network substrate is lip p2p we do uh support uh there is one more system

which I wish to share along with this that is websocket secure which I do wish to share has just got added when the slide was being developed we had the support for these three systems but now we have a fourth system also which is websocket secure we are doing stream multiplexing and here we are using both yamox and nplex uh next I do wish to share we are preventing a different set of attacks which we see in agent so the agent attacks at the networking layer is a bit different than what you see at the application layer at the agent At the uh like infra layer what we notice essentially are three types of attacks.

One is the seable attack. The second is the eclipse attack and the third is the network partition attack. In order to ensure that Ethereum which is a trust layer is able to handle these attacks and is able to have the resistance so that the internet of agent economy can work properly. What we have done is we have ensured that this is simulated organized and also uh I I would say absorbed within the infrastructure layer. So we have built-in support at the infrastructure layer through which we are able to provide resistance for these set of attacks and there's a very good tool which I would like you to try out. It's called as luminar. It has been done by one of our core contributors yash who has developed specifically for preventing these set of attacks. Next I wish to share with you the topology or

the independent naming part for these systems. So if you are having agent so this essentially is the way to have the uh naming for an agent. I do wish to share we are supporting open ID. We are also supporting AOTH which is O 2.1. So that across the boundaries you can easily do communication. Here what we have is uh we have NAT traversal layer which means if you have to talk across network boundaries you can do whole punching and you can use web RTC direct v2 which is a transport system for doing communication across network boundaries which means if you're on a VPN or in a firewall I can still come my agent can still talk to your organization and to your agents and you can collectively work across different agent registries.

So this is something which you definitely need to understand because this will enable organizations to reuse agents. Do not have to have like a meto agent agentic startup to build your own set of agents. You can do collaboration and you can essentially scale these efforts across different organization across boundaries. Ethereum could be the trust layer for ensuring that a lot of these things could be synced up properly. Next we have a zero trust at at a station. This is very very important at the observability level. This needs to be understood because uh one of the key things we are noticing is that lot of agents are running in the wild and if you have to ensure that you have proper identity and you're not taking them down one after the other you need to have the right kind of attestation service and you have to

maintain the audit logs. So this is one of our proposals which we are sharing at ITF and uh would love to have more discussions and uh more talks on this. Uh I do also wish to share very quickly uh about capability discovery. So in reference to capability discovery, what we are trying to do is we're trying to make improvements on the existing peer discovery methods plus come up with newer peer discovery methods. So existing peer discovery methods are the following. So if you are running a global environment, we use the bootstrap node. For example, IPFS project is using the bootstrap node across all their uh live nodes. Then I do wish to and Ethereum is also using bootstrap node.

Uh along with this, we have multiccast DNS for the local environment. So that is very very important when you are doing a local peer discovery search. We also have uh if you're trying to do search via namespace when you're doing peer discovery then I would strongly recommend you use randu which is a very popular peer discovery method and then also uh if you're trying to do some of the other algorithms and you want to figure out okay I'm good in data structures and algorithms and I want to create my own peer discovery system then I would strongly recommend you try out random box algorithm and see whether you can handle this for agents. This is something which I would like to leave it as an exercise also for the audience that have capability based discovery.

Try and see agents can work according to certain thematic areas and you can meet the space and time complex. You're not like trying to be a token maximalist. You want to be a token minimalist when you work on some of these initiatives. Uh next I do wish to share is a very quick diagram on distributed compute. This is a moling diagram. This is essentially I I do wish to share that we want to keep it operating system agnostic all the efforts. I did realize that we started with Linux but we had friends uh on Windows we had friends on Mac they wanted that we should have distributed compute supported across devices. So this is essentially our architecture for supporting distributed compute across uh different devices and this also enables that we are saving on

the GPU costs. We are not buying new new GPUs for running our own inference systems and pipelines. And the final thing that I do wish to share is the semantic layer over lip P2P. We are supporting two different types of protocols which are very well accepted standards. One is model context protocol. Second is A2A. Both of them are a part of Linux foundation. And I do wish to share that we can do it over HTTP also and as far as over P2P connections also which means if your organization excuse me if it blocks lip P2P then we have the support for HTTP but if your organization is friendly and wants to do peer-to-peer connections then we definitely are supporting that as well. Finally I do wish to share that uh there are a couple of key learnings we would like to derive from agent

capabilities and agent research that let agents discover their environment and act accordingly. We know that agents have not been trained on sane data. They have been trained on internet data and internet data is not sane data. It has both the edges. It's like a knife. It can be used to cut fruits. It can be used to hurt someone. So I do wish to share that we would like agents to learn appropriately, discover their environment and act responsibly. I think that's the new age of responsible AI and that is something we could cover using the internet of agents initiative. So before I uh yeah I just wish to share that we have uh Leo as our next speaker.

This is just a snapshot. I would not like to take uh his time and I would like him to get started. Uh Leo, you like to come over? Yeah. >> Okay. >> Yeah. >> Yeah. These are some uh links. You can definitely reach out to us on these links and I would like to hand it over to my friend Leo. Thanks. >> Okay. Thank you. Manu. Hello everyone. Um I'm Leo I'm Leola. I'm going to talk about Ethereum. There is another project about the resilience on of Ethereum. This this kind of focusing now at the protocol level at the consensus protocol level. So um Ethereum currently we are building Ethereum Ethereum ah

Ethereum Ethereum components in lim 4 and we started like we have now the the consensus layer completely and that's like we have done it with a frameware mindset so this can be used by many projects uh and we are kind of like making this that we the link kernel is a piece of code is a is a system that can prove mathematical things about code. So this way by having Ethereum Ethereum implemented in lin 4 we can uh kind of prove mathematical properties of Ethereum. This is a kind of the primary

goal like we improve the Ethereum protocol security by having