Luke Schoen / DCxPrague

Transcript

and then um so we investigated that um and then eventually we discovered that there was the portal Network so the portal Network um I guess the idea is that it's you're going to be having um uh instead of just just running a full node or an archive node or or or or a light client you can you can choose um I guess Sub sub networks so you could say I want to I want to run um a node in the the portal Network which is um covers the history Network or the state Network and things like that so um yeah and and and that's where we'll I'll start with the slide so um so just as a bit of background so um like clients

they use this light light ethereum sub protocol um they downloaded um only the latest block headers as they appear and and then they um execut execute that as part of their own evm and then if they want any additional information they um um they request that on demand from Full nodes or archive nodes um so then if you for example if you if you're running a a like if you're a like client user and you want to interact with um a smart contract um that hasn't been used in the last 100 blocks um then then then you'll have to do an add additional request for the state for that smart contract um and so that's that's part of the contract

State um so when we initially going through um using uh ZK proofs um we also discovered Axiom and and I was fortunate I got to speak with with one of their their leads and and he he sort of went through and said yeah they can actually cover everything that we need um later on we actually looked at adopting um ZK evm as an alternative as well which was interesting um uh yeah but I guess what what we generally found was that um was the the the full and archive nodes they've already got the state so that you don't necessarily need these ZK proofs whereas in for example the portal Network where

you might be having like clients interacting with other like clients or just more peer-to-peer rather than like client to full node um then that might be an application for ZK proofs um so just a quick summary of the PO Network they've got great docs um but I've just sort of tried to summarize it on one page so they split the the ethereum data into different types um and they um they basically run Json IPC Json IPC servers so you can you can gossip information from well you can run a you can run a a node uh they've got different implementations that you can

run a a rust implementation a go implementation a typescript typescript implementation and you can specify whether you want that to be running u a dedicated sub Network so it could be the history history Network their state Network their transa transaction gossip Network or canonical indices Network and they're in different stages of development since it's quite early stage um and you can choose how many megabytes of storage you want to use on your on your device and so forth um yeah so the the main goal a couple of their main goals is to spread the ethereum data instead of just being on the full nodes or archive nodes you can um split

that amongst multiple uh portal network node peers and and there's this EIP uh 4444 which is proposing to limit the I guess the the cost of participating in the ethereum network so the idea is that maybe data that's more than one year old that could be something that you you could be cering a a PO network node whereas other nodes might only have to they could prune certain amount of blocks and only um focus on more more more recent information um yeah and so if you wanted to access information in these portal Network nodes they have like key value pirs so you got content Keys you can um so you could uh you can gossip

information you there's a a a method called gossip so you can say I want to gossip um a a string of data and you it sends it to um within a certain radius that you can specify nodes that are around you and then you could you could um I think there's a fine content method so you can check that check that they've that those nodes have received it you can check how many nodes actually received it as well um yeah and the different implementation so Trin is the the rust implementation of the portal Network and the other ones there's ultral light which is the typescript implementation and there's others as well um so so I guess some of the solutions that Port Network provides is they allow

allows you to uh request um request um ethereum data from another light a light client Pier or um whatever Trend Trend node um sub Network that you're running um that those those um like clients can run as both a client and a server instead of just only a client so they can interact in a distributed fashion so there's um some great YouTube videos from pip mirium that you know shows it's distributed rather than just decentralized um and it's yeah it's I'm not necessarily saying it's few years from completion but um yeah it's not not uh it's in in

progression uh and yeah it's also said that it's going to be solving the light client Pro problem um which I've already mentioned in terms of the burden on the Fallen archive nodes and yeah so the benefit of zero knowledge proof so I guess that's um a question that I still sort of ask myself because I'm not quite sure um and so I guess the zero knowledge proofs the idea is that with zero knowledge proofs is you be able to prove to a verify that you know some information without disclosing all that information so for example you might have the you might retrieve the block header from from a block and and then you might generate a zero knowledge proof um based on certain information in

that blocka um and then share that with with other nodes um and the the size of that inform the size of the zero knowledge proof might be um more might be more succinct than um a mircle proof or other other ways that you might be able to to verify that you've got the latest information um so that's something to investigate further um um but yeah in terms of the those we progressed different through different um ways of um generate the ZK proof so initially looking through Axiom um we we had some mentors that were helping us go through

this whole process as well um so basically obtaining the the the idea that we that we'd query for the latest finalized block header um which was uh the the pre-state that would serve as what they call the witness uh in the zero zero knowledge proof um terminology um so we for example we might use the get block by hash method um uh and if you if you're running many of the like clients they they often have to um like for example helus you you need to um if you're interacting with a with a node it has to be supporting the the get proof method um to be able to get that that latest

block hash um um with all the information that you need um with all the transactions um yeah so we only we're only interested in in the latest state so the latest um like for example you might might want just all the accounts that that we need to execute the transaction in the latest finalized block not the full history and then the the idea is that we'd filter that pre-state to only include um what we were interested in and that would be what we'd use to generate the proof and and distribute that proof and then there's in in axiim they have um uh you can generate a a pro a backend server to to generate the proof and then they have

onchain Smart contracts where you could um verify that the proof so might distribute that proof to various nodes and then they can um check on chain whether it's um ver to use use that as a way of verifying it and then there's another another approach that the team were looking into which was uh ZK evm so privacy and scaling Solutions has got a repository ZK evm circuits which has got a lot of Open Source tools which we can use um I didn't really I didn't really go um deepen up into that that was something that other team members working on so yeah I'm just going to quickly go through um what what I eventually got to work so initially I

was trying to use Trin I set up a couple of nodes I was getting request timeouts um I couldn't quite work out how to you know what I was doing wrong um some they got some great support uh they said oh maybe you something wrong with the external IP addresses and I I couldn't work it out and then I thought I well well if I run there it's in Rust so I could run kogo test and all their tests would pass I thought well their test their test cases were essentially exactly the same as what I'm doing when i'm running two nodes so I thought well at least I can make some progress just um getting stuck into their test so I um yeah I was just a bit by bit and that was what other team

members were doing as well just writing short simple scripts to understand understand the code base so uh this this is this is just um basically some of the um uh some Rust Cod like rust test code so Target one um um but anyway if you can read what that's basically saying it's saying um there's a I'm basically going to be sending gossiping some information from Target one to Target two so that they're both they're both um client Trend clients um they're both running a client a version of Trin um so I want to make

sure I want to check what those versions are they've both got an enr um uh it's ethereum name I can't remember what it stands for actually um something resource ethereum name resource or something um it's got the node ID which has got various information about the node and you can get the the enr which is of of this certain form enr colon and so forth so that's just information about the the nodes and then you're essentially just sending some string information so in their existing test they were already sending sending across proofs which was string string values so um I guess you could just send Zer

knowledge proofs um in a similar form so you could in your test cases you can set up a fixture that just generates that just obtains some a string um and then at the bottom of bottom of this screen here you can see um I'm calling the store method to to store um some some store a Content value under a Content key on on the original on the the original Target um then I'm at the bottom of the screen you can see I'm calling wait for history content so um waiting for that content to be stored on the local uh on the the originating node and this is just so you can see in

this um that's sort of a more it's all all it's doing is calling the client and calling local content and just checking that it's there and it just retries if it doesn't find it straight away um and then and then you can verify do an assertion to verify that it's present or not um so it's was it possible possible history content value the content's either present or so there's a match you doing a match a match case like a switch statement checking if it's present or not and if it's present then you return that is the result to to receive content value otherwise it's absent in Panic or um file your test case and then

you assert that it's the same um and and then you can use this gossip method so gossiping the the the proof from the say TRN client one to tr client two if there were other nodes it it could do the same only tried it with one um so yeah so Target one is calling the gossip method um providing that the content key and the the value which we we the DK Pro um and and is it whether whether there was whether it was um gossip to one other node or not um and if that passes then that's great uh and then you can call well I created this um wait for history content

from remote which is pretty much the same as what they already had but I'm calling um this was based on feedback from the trend team saying that we needed to call um that that's just doing lots of assertions but the all it's doing is calling fine content so you're providing the client the remote BNR and checking that it that it's it's been received and stored there yeah and then and then after that the um the trend client to could use axium Smart contracts to verify whether it's received um a valid zero knowledge proof or

not yeah so that's the presentation any questions yeah um I guess initially the um initially was working out which tools were how how to get them running uh so initially I thought well I'm going to use helas just a light client I need to get the block headers from somewhere and I I was using rust I thought I could use load star or or typescript which I'm probably more familiar with but I

thought I'll I'll try and put a bit more energy into rust because the other team members were using rust too and I've got I'm familiar with that too and helus had um I was you know it had some good documentation I tried it and I was getting issues and I'd create create issues on the repo the maintainer is really responsive so I kind of felt really that made me feel good that um you know now feel more comfortable using the helus um repository you know um so yeah that and that um that uses this what they call them the the checkpoints so when you can when you want to run a helus node you you basically specify a a um is it a consensus a consensus um URI

API key and a and a um ex execution API key so you can use alchemy or or you know um just to configure it and then you you go on to the different block explorers and you get the one of the the oldest finalized block headers and you specifies that as the checkpoint and then run the node and it syncs and then you can query that node to get the latest block headers so that was what I was doing initially and and then Tren was Tren we were going to do that as a second stage because although the I guess the the code base was really nice and you know it was easy to understand I thought uh in terms of a prototype you know is it

is it going to be something that we can is it going to be something that we'll be able to show I thought if we've got the the the light client maybe we could um modify it to share you know to share to gossip some information I thought well you know maybe that's going to be a lot more work than uh using Tren and and all the work's already been done on Tren it's just there's there's just it's it's still early stage and it's it's already going to be solving so many of those other problems so yeah so in terms of setting things up it was I was using Docker initially just creating Docker containers to quickly spin up helus and quickly spin up Trend thinking oh I can quickly all do it in Docker and just do

a one single command and and then I ended up just writing some simple test cases to and that gave me the peace of mind that I needed so I think the I think the the main the main um learning was you know start with the tests yeah I think that's what you said in your presentation that you you got um carried away with the test because I guess you get a lot more confident with your own work or other people's work same with GitHub issues you know once you're comfortable going through the go through their open source issues you know feel comfortable with what the state of that repository is and then you you know you want to keep working on it you know

you'll make new connections and yeah I think we already can working working like client I I haven't uh I haven't tried it but I I can't see why you couldn't um why you couldn't run run helus and then you just go into metamask and just add whatever Local Host 8545 or are yeah

yeah yeah uh I don't know if that's the problem that I'll be solving um I guess yeah I guess you know for Mass adoption If Everyone likes using metam mask or they feel more comfortable doing that than from the command line um yeah uh I I don't really know how to answer that question I you know in terms of even signing transactions you using metam mask and seeing what transactions you're signing I guess you know seeing those things grass or different different wallets um you know protecting the consumers so they can see what's going on um

yeah any other questions right all right thanks very much