zk-Based Consensus Proofs: Making Stateless Ethereum Practical - Steffen Kux

Transcript

Ja, good evening. It's great to be here. What do you think is one of the biggest but ansehen risk in our wealth free world right now? Key management no is maybe the smart contract security is the future quantum computers which might break our cryptography all of things are not the biggest things are working on need to ja worked on but not the real biggest thing

I don't know if recognized what happened in the last days. Interesting attacks and hacks and I will talk little bit about things and then we go little bit deeper how we can prevent things from happening. are little bit scared not too much not to much that we are paralyzed but that we see what we need to do some days ago on the 18th of April not long ag itemed a normal day but in the background something happened which was jaing the def world and we see

it until now so what happened in on this day der info infamous hacker group lw back from North Korea did again an attack which was a very sophisticated attack so about 300 million dollars stolen not really stolen but created and removed from understand what was the problem actually

when I was talking about same topic one year ago at Depon in Berlin I talked about the attack vector people happening unfortun exactly what could happen in the futureaking protocol on le to move one chain to another chain in short it looks

cross message created verifier decent verifier network receiving message the new tokens created on side normally this works fine and we have to look a little bit at verifiers so verifiers need information connected services ask what is happening on chain and normally had

security idea used several different RBCs some own hosted RBCs external hosted RBC secure enough. So what happened? Die attackers manipulated had an attack to the internal structure and manipulated some ofc servers not fully.

did react as should react for almost all requests but for some special requests from this verifier in this verifier network information and to complete this attack the simply attack to all the othercs verifier was connected to the result only manipulated contacted and information based on information tokens created without the backing out chain.

So let's remove all the details let's remove capd let's remove Leo zero even there was a not optimal architecture. Let's put away all of things. So let's look what really was the problem in this attack. The attack was that the verifier did use data which had to rely and to trust and verify was not able to verify assumption is information and information correct verifying

problem. So internally it looked like everything was okay but externally it was not connected to reality. So nothing wrong but it was and there was no way for this verifier to detect what was wrong because the verifier was not verifying means the whole system did not fail because there was b in the contract b in the infrastructure also not fail because there was something wrong with the cryptocraphy it did fail

data party information correct means don't need protocol expected to be the tru and so in mind simply need to come to conclusion don't trust any information you receive always verify look in the eat from ethereum free

verify all information used understandbc are using today not source of truth handled this but are not so not bad not talking against but we have to think transport information but not more and not less so when we need data and we need to rely on data we have to verify it locally in

our application in our device of course we know when we run our own full note we can synchronizing network consensus synchronization what current block of the blockchain and also can pro all information state in the blocks because it has all information but also know that this is not possible for our applications cannot run web application inside the application full browser

tool browser inside browser it started synchroniz the first time you wait some minutes hours days until it was synchronized application work anymore computer laptop would handle the amount of data need run full beside run all other applications and also when we think about light

clients normally too heavy inside our applications have a smartphone users will not be happy because to much traffic battery will down very easily nothing so what we need stateless cli stateless client stateless client is a client not synchronizing information based on cryptographical

future talk about status cli road map often mentioned available now statilable works what proofs do we need to transform unverified data to trustless data types of proofs first the execution layer proof and second the consensus layer proof so i will go deeper into proof so that we can understand why we need

proofs and how work topic are using more efficient first execution layof why do we need executionof simply pro that information is linked to the block the block headers so that know value from the state and this belongs to this block have a transaction it belongs to this block an event log belongs to block execution we can prove that information part of a blockchain but what we don't

know at time is if this block is really part of the canonical chain it could be a manipulated block then even when the execution proofs work we don't know if this block is really part of the canonical chain secondof consensus proof consensus proof verif blockchain so rely onc servicely on any provider we just can verify and the good thing is with two proofs we are completely trustless we don't have to

rely on any other get information data providerc service but is simply data provider not a truth provider because I get both information and proof and can verify by myself deeper such consensus consensus start checkpoint

could somewh in the past and then we have to verify all the transitions from the validator committee until we come to the block we are interested in checkpoint signatures addresses correctly in the blocks.

change all transitions works but might quite a lot of information lot of work done to make proof introduced proof for usof compress signature verification information in the be block into one proof so that we have one single proof for transition and then recursively put together all proofs from the

trusted checkpoint until we arrive the interest one single proof and makes very efficient because then if I need to proof my information I get the execution proof and I get one single proof and completely sure and trustless this information is correct information so that means about 260 bytes are enough to prove Konsensus.

So why does it work efficiently? Only needed every 27 hours that means we don't need to do it in in real time. We have enough time to produce proofs. Don't need all sophisticated methods paralyzation. You can run it on simple laptop. it might take about 30 minutes because BLS signature is hard to prove use network using SP1 about

a minute little bit more than minut some sense and we can produce proofs very efficiently so that means proofs client small run inside my application I do verification always need works internet connection do proving offlin Cent

blockchain state open door send information and Bluetooth lock verifi interaction device software blockchain do in one means wallet application use verified information new normal

99 x% alls using convenient easy because C providers bad all applications also not better Google, Adobe, Apple hacked at the one use mechanism in all applications

different ways to do it one way could be locally client can generate directly asking all informationcely trustless but it takes a lot of effort because it needs for instance for the consensus needlect all service still trustless but more efficient waycable RBC service not only providing data but data in cou

improves. So means don't trust verify if don't verify we don't know what data we are using. So let's recap. So it must be very clear for all of us the problem is not using RBC. The problem is using RBC and not verifying the data. So as I said before every application we are building should verify the data for instance col is about 250 kb so no application which cannot run such

a client the overhead only in the range of the latency for generating the proofs also verifying the proofs it doesn't Thank you very much. I hope that you are aware now so important to verify and the technology to verify is available. Interested check out Kib stateless. Ja. Any questions? Do have time we have just like for you anyone has a question.

Thank you. So, thank you for the presentation and this is probably gna be a stupid question new to this and I underst the need for proof the two types of proofs. What I would need more help with is understanding why those need to be zero knowledge. As far as I understand what we are proving public knowledge in the first place. Yeah. Okay. We don't need zero at this point because we don't need to hide something. But knowledge proofs have another very interesting characteristics. They can compress the a whole process and data into a proof. Also as I said when I can do the consensus proof step by step I

start from the checkpoint and do transition by transition by transition verifying the signatures verifying that the information in the beaking blocks correct and so on. This could be complicated act and if I use a zero proof I can compress this into a one single proof. I have 260 bytes left which give me the same security doing the big chain of proofs using not to hide something using more efficient question

another one question Are you familiar with Starknet? Yes. How does this compare to how Starknet works? So for st exactly layer so using anchor information layer in layer one problem if using stnet clientation also need verification on the end always bad

verifiable data fine do in the same way more complicated additional to the consensus execution layer proof you have a rollup proof which shows that information is in one of the anchors of the roll but otherwise Thank you.

Ja, thank you very much. I think we time for like we have minutes if last question. So according to you the problem as faulty RPCs and the web to nature of RPCs in general the RPCs that we use the RPC let say UNICE for instance so we cannot rely 100% on even in Fura which was acquired by Meta we can relay on centralized nature of RPCs so the whole idea here is that when you try assign an EVM transaction you're basically signing against a nons value. instead of doing that why not just sign it against snck checkpoint instead would all the issue straight up if you only use a signature

we have also this included in the protocol because some information you cannot prove but also additional trust vector need to trust designer makes better nothingum trust of the protocol which uses just 24 KB final constant size blockchain the protocol mea protocol the mean blockchain okay so the idea here is that if it's deterministic then it's probable that the current state is derived from

the previous states by merging the snacks all together and the final ch plan will make much easier because don't need complicated execution proofs but we cannot wait until finish will take years 5 years 10 years But here we can use what is existing right now and make it fully trustless.

But sorry again you still not making a transac against so maybe you are able to verify like with the architecture youowing but the issue here is maybe theof is valid but the blockchain state is outdated maybe there is a new transac that was blot or a new block that was mined in that case mbb or other other problemistic scenarios can rise so the even to we can now rely on rpcs rpcs might mald outdated information

block one so and then I have to prove that this is the correct information in this block so what I don't know at point might could make blog need information.

Thank you for presentation อ