zkSharding: Scaling Ethereum with Sharded zkRollups - Handan Kilinc Alper

Transcript

[Music] hi everyone thanks for the introduction and thanks for uh seeing pces here because I was a bit worried it's one of the last talks so maybe there won't be a lot of people but I'm happy that you are here um so uh I'm working uh in Neil Foundation as a researcher and today I will talk uh about ZK sharding uh ZK sharding is a ZK rollup and uh it integrates sharding in its architecture and Beyond this I also want to talk about why sharding is a good um tool to actually scale layer tools and how it it

aligns with the ethereum vision actually okay um but before diving in detail all these um motivations and ZK Shing I just want to explain what is ZK rollup I'm sure most of you know but just uh as an introduction let me talk about this um so in ZK rollup system or in general we have ZK rollups because layer one wants to Outsource its execution and here ZK rollup gives that um service to layer one and basically it consists of um basic uh key components such as sequencer executor submitter and

Pro and here sequencer just gets transactions orders them and gives them to executor to execute executor executes the transactions according to State transition function and updates the state and we have submitter here that submitter just gives necessary data to layer one and here layer one is ethereum and since it's a zare up um there's a zero knowledge proof exe Generation by the prover that Prov shows that everything is executed correctly and eum verifies that and then it's done and when we look at um today's roll

up ecosystem what we see that most of them deploy actually centralized sequencer and why they choose this because it simplifies transaction ordering they don't need to build consensus mechanism on top of it to agree on the order or inclusion of a data it improves performance because that's obviously much more efficient to do that and easier to implement also but here centralized sequencer is just single entity and um all responsibility Bel belongs to that single entity to decide whether include or not include the transaction and when we look at etherum goals uh etherum goal is to be a global

censorship resistant permissionless blockchain and when you look at this layer TOS with centralized sequencer and etherum go actually they are they do not align obviously this is not sensorship resistant because uh that sequencer can decide to include or not include the transactions and it's not permissionless either um and this is not just about aligning with ethereum goals it's Al that that centralized Seer approach Pro gives um or introduces a lot of security risks but before talking about it I just want to show you this very famous blockchain trma I'm sure all of you know

that but it says that scalability security and decentralization together is very hard to achieve so if you want to achieve one of them or two of them you have to sacrifice the other a bit and but ethereum didn't want to sacrifice none of these properties so um they see that actually rollups can uh overcome this challenge that is uh defined by this blockchain trma and therefore um they decided to have that layer two Centric approach but when we look at at2 with a centralized Layer Two let's look what it achieves actually and it achieves scalability

because um the number of computations per second increases a lot obviously and when we look at security I here I want to just focus on safety and leness here because just for simplification we could extend that security definition but here when I want when I say safety I mean that only W transactions are going to be included uh to the state and liess means that uh all unest uh transactions are eventually uh be the part be part of the state and um for specifically when we talk about ZK rollups uh we actually eum guarantee safety because uh for ZK

rollups ZK rollup cannot lie about execution because there is a proof so etherum gives this safety and safety is still there but since this is centralized SEC solution obviously it's not decentralized anymore there's just one single entity and whenever you have such a centralized authorities automatically you cannot guarantee leness because if that Central entity fails then all execution stops and um and on transaction will not be uh on the state so we cannot guarantee that and this is not just Li is also uh there are some um there's there are other serious

security risks such as censorship resistance here we cannot rely on that centralized security consider that uh will always behave fairly so let's go back to beginning of the problem we wanted to scale etherum and ethereum see that uh rollups actually good solution for that and that they decided to Let's deploy Layer Two Solutions but the most of the layer tws have this centralized sequencer so in future they have to be decentralized otherwise it doesn't make sense because we want to be away from web web2 Centric Solutions so we shouldn't go back to

that and whenever we want to decentralize layer two layer TOS we will have the same problem how we will scale layer TOS then and it seems like it's a chicken and egg problem and the question is how we can scale their to and you know that scaling is not a new issue in blockchain uh world and it has been discussed for many years it's not a NE question and um the proposed Solutions usually fall into two categories we could have different categories but and for this talk I just choose these categories uh vertical scaling and horizontal scaling um so when you want to scale you just want to

increase the number of computations per second and vertical scaling just says that okay let's increase the hardware requirements of validators so we will we have a just single chain blockchain and validators in will increase their Hardware in order to do much faster compet computation um that definitely increases the throughput but there's a centralization risk because it reduces the accessibility not everyone can be a validator and uh the number of validators will be very limited and it's it's not going to be uh really permissionless yeah they need some uh a lot of they need a lot of investment and so on plus there is scalability limits

because we cannot we cannot ask validators to increase their Hardware infinitely there is a limit there and the other one is horizontal scaling um horizontal scaling uh is similar to parallel computation idea so if you want to increase uh your uh computation speed naturally you try to paralyze them as much as you can and this is also the same idea so we will have multiple blockchains and they are run by different set of validators and that's the solution basically so whenever you want to scan more you include more validators and more blockchains to the

system um however this is really hard to design um it requires a lot of thinking and especially when you uh because these blockchains are not just independent they have to communicate they should send trans sections to each other and when you um have that uh communication you have to be very careful because when you want to be scalable at uh you can also create some bul neck with this communication so this part especially very um important when you want to dise horizontal because it shouldn't be B NE but when we look at these two solutions or two categories horizont Al

scaling looks more ideal for web Vision in general and therefore we choose horizontal scaling to um decentralize our layer to um there are many horizontal scaling uh options as well but here we decided to uh deploy sharding what is sharding sharding is not a new um technique in databases uh it is used a lot because if instead of holding huge databases uh it better to divide it and like that it is easier to access the data or update the database and it is it is the same idea so if you think the state as a big database in our

charts we just divide these states into uh to be maintained in our execution shart so we have many execution sharts and they have their specific set of validators and um they are just responsible from that state holding that state or maintaining that state and we have also main Shard U main Shard is just there uh to synchronize these execution charts and it's also run by all W dator since we are um ZK rollup we have we have also our approver Network and um our syn committee which is each which is an interface between our shards proven

Network and ethereum and we have of ethereum so what ethereum provides here is the safety so ethereum uh is our settlement layer it means that when something is verified by ethereum then all transactions are going to be finalized and let's look at in more detail our architectures as I said we have execution sharts and they are just you can just consider them as a blockchain they manage set of accounts and in our design each account is managed by smart contract and it is run by uh specific set of validators and they when they are

running this blockchain they run their local consensus algorithm on top of it and I said that these charts needs to communicate because um they they should be able to send messages to each other otherwise it it doesn't make sense because it's not whole then it's not a whole system therefore we need to introduce cross Shard communication but we had to be very careful that because we don't want to create a bottleneck here and therefore we uh did some design choices in our cross Shard Communication System um first decision that we made is that uh our cross Shard transactions are

not non automic what it means that transactions on destination chart uh can fail or revert it and we give um the responsibility to handle such errors to the smart contract that's uh that gives a lot of complex complex City to the smart contracts smart contract developers but I mean it's not impossible to do uh they just it just it just needs more um attention than usual implementation but it's a trade-off that we had to make to have efficient uh uh process here and also here we choose optimistic approach what we mean by

optimistic approach um validators in destination Shard uh don't need any proof from um from The Source chart to execute the uh transaction so they don't need any proof that shows that that trans section actually valid uh so they just believe whatever comes from the source and Source chart and execute the transaction accordingly um In classical sharted blockchain systems which are not rollups uh that might not be the best option to be optimistic because um they their shs needs to understand if they are executing the

correct data but in our case uh we in we integrate zero knowledge proofs to our system so uh if some Shard gets malicious and send some uh wrong data then it may it will not be proven and etherum will never verify that uh therefore that's um okay to Pro have that optimistic approach given that we incentivized our our validators to behave mostly correctly and also our communication is permissions it means that uh sharts can send messages to each other easily it's not that complic at it's the same as sending the transaction in its own

chart and let me also talk about our interchain structure um I said that execution shs are just blockchain but here we also they are also connected with dag um why we have that uh we have that because when a chart execu when an exe execution chart sends a message to another sharts we want to to guarantee that this uh message will not be censored by the other Shard and it will it will be executed uh fast and therefore we have that deck that in that that deck just um enforces some order of execution of transactions and um with this deck

structure that we call Shard deck um we actually uh have sensorship resistant cross Shard communication and here as in classical blockchain each block links to the previous Block in its chain also each block references to a main shart block and also it links to set of uh blocks from other sharts okay also as I said we have a main shart and that main chart is run by all validators and this main shart idea is just very typical uh to have in all charted uh systems because uh

they these execution sharts uh has some authority to understand what is the final state in uh or what is the final data that we can trust and therefore we have our main chart it is mostly uh responsible from operational executions such as randoms Generations taking slashing finalizing the execution shart blocks and and um so there's no uh smart there's no dab or uh other uh type of smart contracts or tokens on it it's just for there for operational ex executions and it is run by all

validators and that Global consensus says that what is Final in the execution sharts until now I just explain classical sharded blockchain structure but since we are roll up as I said we are uh connect we are connecting um ourself uh to ethereum with a zero knowledge proofs and uh when we whenever um so we have a sync committee here that sync Committee just observes all shars and uh just gathers the data for Prov Network prover Network proves the transactions executions and so on and think Committee just submits the data to

the ethereum and eum then validates the state with the proof so when the state is verified then we uh we say that all transactions that belongs to that state actually finalized you see that we have here local consensus and Global consensus that finality is not actually directly related to etherum finaly it is just a mechanism uh here for internal safety actually our internal safety uh internal safety uh provides us to be live at the ethereum level because if we were not safe internally then of course the trans Erin will not validate the proofs and

just uh we cannot guarantee the liveness therefore it was important to have that uh safety okay so this is my last slide just I want to uh give you our properties uh in the last slide and but we achieved that so we achieved sensorship resistant cross chart communication by um this DC based enforc CST inclusions with DC and we decided uh some key design choices in our communication Channel such as optimistic permissions and nonatomic and that is the cross shart communication performance and we just uh back up that

with zkps and in the end we have just trusts parallel computations and um that's the end of my talk I know that I give very high overview of our design but if you have detailed questions you can ask me from telegram or if you have questions right now also I'm happy to answer them great speech uh thanks a lot any questions one more question so um can you just go one slide

back actually one more sorry this one yeah in this one so I I'm wondering how this PR network is working because when you find a malicious uh transaction or something happened in the in the layer two and I think Pro Network should catch it and need to correct it right so uh maybe it's my lack of knowledge about ZK how Pro network is correcting the malicious and not proved data in in the in the layer two actually yeah so in such occasions uh we have um State inv validity proves uh this is also

generated by our Prov Network and if it happens we have to roll back to the correct state so that's a lot of work uh but uh under this uh with our security assumptions we just don't expect that it happens all the time uh given that we incentivize validators and we have uh secure consensus mechanisms uh but in general the idea is just that ined proofs will come and then main Shard will decide to roll back to the correct state but nothing we be verified on ethereum till uh correction yeah yeah thank you

great one last question no okay thanks a lot [Applause] [Music]