Sogol Malek - efficient light client for stateless Verification

Transcript

uh hello everyone thanks for joining this conversation I'm uh very happy to walk you through my uh current uh contribution to the core ethereum from the State team and uh just walking you through the uh efficient like client for status verification and the uh you know vill three era afterwards so I have launched this uh POC last year at Dev connect in Istanbul November 2023 so the GitHub is often working if someone is interested to have like the look into the source code so let's jump into the motivation of this work so um I wish that everyone in the room um has uh heard that one of the

biggest problem by etherum um at the moment is like State bloat uh we have seen so far the monoton increase of block size and witness size as you can see for example in the picture uh we have uh seen we have hit actually 300K Byes of a block size uh just in the few past months and uh obviously we would face to the other problem of overhead of if um MPT with a large number of um input output operations uh which requires to sync a block so the big size of vickness is required obviously that must be transmitted over the network per block and as a conclusion uh increasing the number of uh input output operations

increases the block verification time as well as you can see also in the uh right hand side of you know the increase of number of operations increases the blocks in time which um reduces actually the efficiency of doing sort of you know um a block um verification uh at the moment there are a type of different light clients or at least the client types um as we are familiar with that they are full nod uh light clients and uh we entering to the era we would have like stateless light clients with cryptographic proofs here is a general overview of the efficiency and security of those client types so full node is the most um secure type of like clients in general uh with the

least efficiency grade they can um download and process entire U transactions and store the entire State and uh they demand uh significant resources and they are mostly the most impractical type of clients for mobile devices there are other uh type of flood clients that are um better in terms of efficiency but um you know um maybe less uh secure than the full notes LC's that we are are familiar with are sort of um you know burdening the full notes by incrementally requesting block state for example each state each like client just um you know just calls the full notes a piece by piece to gather data they want

to verify and imagine that alog together calling a full node makes a lot of of burden and also uh they could be more vulnerable to potential data manipulations or tampering during the verification progress and that's the motivation that we wanted to have sort of new state like clients that have sort of cryptographic proofs with them um at the end uh we have sort of uh stateless light clients um which uh are coming more type of those clients um after the era of vle tries but this work at least is um to show like how that era would look looks like they are more efficient uh because they don't uh need any type of you know hash roots of the entire block headers and of course they are

more secure due to the CRA extra cryptographic proofs they reducing the computational and IO requirements for transactions um they can validate transactions much efficient um comparing to other types with minimal data transfer uh they are ideal for low band with environments um like mobile phones for example and uh they can also ensure the Integrity of Fitness data resisting tampering and ensuring the authentic transaction validations so what's the goal as uh people at EF constantly speaking about this we want weak statelessness as like the most mature type of uh you know

statelessness at the moment and uh the state is not required to be fully validated notes um when we do have such a thing um even like it too validators would not need to have the full State and it allows for froud um froud proof protected like clients um they literally can validate single block as a fraud proof and that's it they don't need to do anything more so Vic means here uh block Builders or validators still need the state so it's not fully stateless and that content but it means that actually Dynamic State access isn't a problem anymore so for for more information on V statelessness I would

uh encourage you to check Dan rodice um writing uh in this uh uh Repro and um the goal of uh entire uh presentation today is H to introduce you to a client that um is able to verify the correctness of a Blog without any information extra information expect for small uh type of proof that uh you know gen every state holding note can generate and we call it as a witness the witness contains the portion of State accessed by the block along with the proof of correctness and that's like the general uh definition so um yeah stateless like client witness um

there is some numbers there I just wanted to uh give some insights of the size of the witness actually instead of a client uh just holding the state the client holds the state root witness the portion of state that are read and modifi IED along with the proof so um just to have some idea about the numbers total size uh total State size um um we can consider n typical n is 2 power to 30 and the K objects accessed by that block is typical um typically like um two power to 10 so the witness size we can uh calculate here easily is a sort of you know number of 600 bytes access in uh practice becomes like 100 kilobyte

block Fitness so obviously it's like the trunks plus the objects themselves that um you know are involved so uh let's have a look on the gas estimation of these stateless blocks so uh here is a general overview and calculations so um I just compared uh disk space and also uh the sort of um yeah the gas cost for both uh traditional uh Witnesses uh produced so far at thisum and also when we just compress them even further with Z snarks so um as you can see like the cost of um average um G gas sorry reduces when you

have like compressing your witness with the snark and also uh the space that is required um by a snark uh proof of witness is even less than the traditional witness so we can save a lot of this space as as theum so uh yeah in terms of having even more uh gas friendly um kind of um like clients um there are a type of different yeah snar proofs um but actually uh the Sha 56 is the most inefficient hash function for Z case in this example so um because um you know comparing to other type of hashing processes uh the

researchers came in with the idea of using uh poison T3 hashing so it has some good reasons to do so uh one is efficiently hashes to elements ideal for binal numerical trees which they are and faciles cryptographic proofs and data Integrity verifications um the gas cost by the way uh can also have sort of a trade-off compared to verle th uh it's not like the best option just replacing the verle pr it is like the um intermediary solution up to the point that we can have like veral Tri but at least is still more efficient than what it is so um it requires updating hashes from the new LIF to the route uh and also gas

cost increases linearly with its free depth due to the hash updates so again it's not like the uh better option than vle Tri but at least uh to compare um initialization cost uh for this type of uh snark uh is uh involves hashing and caching um zero leavs for each level and cost unfortunately grows uh linearly with the depth of the Tre the uh take key takea here is that poison t3s are more efficient in hashing and enable the scalable and secure incrementals um merel trees if you don't want to change um completely the architecture of uh ethereum as it is H with predictable gas

cost scaling linearly with the three deps as a stade off here so this uh table just shows a little bit sort of U overview of the cost um of uh this type of uh snark um and just that just to give you like some sense how you know how much are the gas costs um when you have sort of capacity to insert values into the binary incremental Market U Merk trees um so yeah uh we are moving towards stateless ethereum from traditional light Lanes to stateless light CES and to recal Tri I just uh recently published um sort of article on ethereum Research if You' like to check

it out I just discuss it more in details and uh comes uh time to explain about the apx uh which is a proposal of mine under the supervision of gum Bella the lead of FAL TR and uh Piper mirium the lead of uh portal Network um and we thought that this can at least be more uh production ready rather vle tries um meanwhile so um I said like there are diversity of light light clients so in this case when you have sort of stateless light clients you will end up having like more uh type of clients just running uh and thinking with the entire network faster so instead of running um

minority clients uh you will end up having multiple clients um that are less expensive uh we can run sort of a stateless peer-to-peer clients and ask validators to cross validate the zki proof with other clients stateless which is the goal of this uh architecture design um we can also have sort of enhancing blockchain security and efficiency uh the current progress um is um as follow so you execute a bundle of transactions and compare the results with expected outcome in the block Heather but uh in the proposed uh architecture you can have uh you know during the execution you can create a witness for the block and after the execution You intro you add sort of

extra step which is a cross validation um of the peer-to-peer and you can send the witness uh to various clients for slatest verifications the benefit is that increasing the security um by validating transaction across multiple clients and just because again it's a super simple and super fast to get synced within rest of the network it increases the uh diversity and also ensures accuracy and integrity of the blockchain without heavy resources being used uh due to the uh cryptographic proof of the so this is uh the uh high level overview of the uh workflow and so um we actually um have implemented sort of a

um architect as a follow so uh we have a chain event uh so we subscribe to the bacon chain events and whenever the block has been generated the notes there are responsible to generate a witness alongside with the transactions so we subscribe and uh also listen to the chain events uh whenever a new blog produced the witness will be generated as well uh we generate the uh Z proof of the witness for each block header basically and through the um sort of uh protocol communication protocol um over etherum we just propagated at one call to all uh clients that participating so uh the

clients that already uh we made them stateless are based on three TR is um sort of like clients at portal at the moment and um if we can have like the sort of a peer-to-peer communication between them to cross check the uh proof of uh the headers that every note just received recently so this is a screenshot of our code currently uh so generating the witness uh and Z proof for random block um it is not the most efficient block that we generated not neither in terms of generation time nor in the size but at least it's like an example of proof of concept how it

works and then uh this shows the propagation progress over uh dis V5 protocol um so through this uh we are able to um remove the burden from uh clients to you know just actually have sort of a one call to receive all the necessary uh witness data they want instead of you know like clients just calling full noes so yeah um with that I would jump into the conclusion about talking about like applications and the road map of this work so uh that can be a diverse type of applications here uh you can have a more enhanced security in staking operations for example a validators

could uh quickly verify the set of block without need to the entire blockchain history it can be used for example for efficient uh reaking mechanisms um in protocols like ion layer for example uh which enables reaking uh the stateless like client could be very efficient um by verifying the delegation of transactions and uh you know proving the Integrity of the real estate assets um you know at a very short time um and last but not least uh we can have have sort of new type of on thefly verifications uh for daps that allows daps to operate more efficient by reducing the need uh for constant synchronization with the block State um

and also we can enhance the user experience and scalability so uh this is the timeline for our work so far uh we have uh initially um made a proof of concept and uh it just generates the ZK proof of the blog header and propagates it across TR uh at the moment uh TR has like 50 uh peer-to-peer uh clients um and joining the network but uh obviously the more of clients just joining this uh protocol design the better for the ecosystem of course um we are going to next improving the PC with CK um generation time and of course implementing new sub Network

layer in Portal Network for uh storing sort of ZK proof messages and uh introducing new RPC call method to um you know facilate that kind of peer-to-peer um cross check and last but not least we can have sort of a surface like mobile app which everyone can be a verifier and uh you know just U verify the state of etherum in a more diverse way and we are also exploring the Synergy with protocols like I fire and other staking protocols just to to uh use this type of clients yeah and I really appreciate uh our mentors of course and other uh people that have

made this event and uh thank you so much for listening uh Soo thank you very much for all the um insights I think we have time for one question from the audience anyone oh uh isn't the witness generation also taking a lot of gas and uh also producing more uh time delay in uh block to prop uh propagate on the disk obviously uh for the gas it makes it much efficient than it is at the moment so generating a witness um consumes not much gas as already you

know we just have for each transaction uh to be involved in a block but in terms of delay uh depends on which type of uh you know ZK snark or other type of um proofs you just use as I mentioned uh there is the one option um poision at T3 which is the least uh um um delayed type of ZK proof generator but obviously this is something that uh we can you know investigate in terms of ZK proofs how we can U you know just increase the time of U proof generation decrease the time of the proof generation and reduce the cost for the moment but again it's not the uh replacement of vle Tri uh it is just some intermediary

step toward that and comparing to the current solution is the best architector we came up with the reason is of course is like the update of uh each Leaf whenever the transactions just you know are changed from one state to another so obviously this one would not be that efficient in terms of gas and everything else just to reproduce your ZK after each transaction States change one addition question on top of it what is the witness size now the witness size at the moment I guess uh is about uh 30k uh sorry 60 kilobyte which we produced here but it's not obviously like the uh best

option it's a PC amazing thank you again sure I appreciate you thank you