Proceedings on Starknet Consensus Protocol design - Jorik Schellekens

I think that's the first time anyone ever actually got my name correct uh ever on stage or or elsewhere than like Belgium and Holland um it's the last Talk of the day so I'm going to try and uh maybe like keep it a bit short um it's also well n is laughing at me because we allowed to get through um I'm going to change the format a little bit you can ask me questions in the middle if you want I'm really going as deep as you guys want or as not I kind of just want to make it interesting for you I hate speaking about things that are obvious is he pisses me off in the crowd like I know this and I know other people don't so just like set the pace tell me if you need some more time or something or if you're interested in a topic we can go for that uh the idea is um about Stark net if you're all familiar with the network uh it's one of the major l2s it's your knowledge Ro up um we're going to go through the major developments that are coming over the next year uh I'm not telling you any dates I'm not making any promises but I am telling you exactly what the state of play is right now who's involved how you can get involved if you're interested includes you guys um and uh yeah some of the Minor Details of the of the upcoming protocol changes uh the main thing is Stark net is decentralizing um is everyone here familiar with Ser knowledge rollups can I get like a show of hands like is this a very basic architecture do I need to go through the designs okay I'm going to go most people are then I won't go too deep into this but uh all the all the rollups I think it's still all are completely centralized um they use different security techniques to make sure that they are correct in the data that's put there so in the Stark net case we have a centralized sequencer um we also have a very expensive prover in the background which is running and producing a bunch of proofs that what this sequence is saying is correct and then those proofs of the correctness are being sent to ethereum which is doing the validation and that's giving you all of the basic crypto properties of uh sensitive resistance and basically uh correctness and availability right and liveness uh so you kind of trust one person and then you get your trust back later when uh when the the Watchdog comes and verifies all the work right that's the basic principle um that's that's reducing it a bit if uh if you start making actions based on what a sequencer says and then the sequencer turns around and just says l no there's nothing you can do about it and this is the case with all of the sequencers right it's only once the data is on a one that you are actually safe and then you're relying on other trust assumptions so the question is why do you decentralize and this is a basic crypto question I'm not going to get into it you're all here because of this reason but normally uh these are two of the main properties not all of them but you have censorship and correctness in the rollups case we actually only care about censorship uh or another way of looking at censorship is liveness and how you want to look at it um so we don't need to work on correctness this kind of changes the uh the picture a bit you just want to to make sure your transaction gets in that nobody else is blocking you not saying like Okay well the state has come and talk to me and said you're not like eligible to the honest Network right um so which parts of this picture do we actually want to decentralize well ethereum is fine obviously uh we want to decentralize the sequencer but to a certain extent we also want to decentralize the uh prover right we want everyone to have access to the ability to prove blocks um we don't want this to be in the hands of a single entity uh this was a major problem with like early ZK proving systems the the math was there the early implementations were there the uh the infra to run this at scale and at a reasonable price was not there right like it was in public information um so I think what the rups really have to do now and to make CK really successful is to make sure that these kind of uh proving systems are as public as possible that people can run on their own personal Hardware that they know exactly what the constraints are what the costs are and so right and uh as these Network decentralize we'll start finding out this information um everyone with me so far yeah cool I'm going to stop doing that um all right a lot of what I'm going to cover here is covered in ilas talk uh who is the designer of this protocol and is very detailed what I'm going to add to that talk is uh some of the like like more high level explanations of it and then more like what we are doing today like who is working on which parts what state of they in uh like what are the tradeoffs that we're trying to fight with um Ilia talk will give you a very good overview of what the actual structure of the of the system will look like um he's also really funny I recommend watching his things is a is a is a cool um right we're going to conceptualize Stark net into four layers and we're doing this intentionally we're trying to make them as simple as possible in each layer we have the proposal schedule we've got the L2 consensus and then the part that's unique to ZK rollups is you have the proving system and then someone needs to put all those proofs onto the L one right this basically the diagram I showed you before but we're going to tackle each one of these separate protocols the first one I'm not going to do any diagrams so just going to have to imagine uh mostly proposal selection is very simple we use uh uh some Randomness from the L1 um probably the block has I think we've settled on the Block hash now uh I say this very confidently I'm not the one doing designs I just look at the designs they come on um but uh we will be likely choosing the set of proposers to EPO in advance we're using tender I'll get to that in a second um this is actually quite long and there's a really good reason for that which I'll get to uh everything is kind of changed to decentralize approving so you get like all the normal consensus stuff I'm not going to go too deep into those parts because you can just like Lally just watch a thing about tendermint but I'm going to go through all of the changes that are there to make sure the proving is properly decentralized that the costs are aggregated across users very well and that this is like a functioning system um cool so we are using tenament uh this was actually a really hot topic a bunch of people were like let's do dags like dags are the hot new thing and uh no offense Cosmos and informal systems tenament is amazing and actually we decided to stick with tender as like a bunch of different research teams because we know his performance in in the real world and uh you've got to kind of factor in that with ZK rollups all of this stuff is so new like the ZK part itself is like issues that we're trying to squeeze into these protocols the last thing you want is an experimental consensus system underneath it just to make sure like you have it all so I think going down the faster consensus mechanisms is something that we definitely want to do uh in the future like maybe like 2 years from now but uh let's first get like a working decentralized ZK rollup going and then we go back to like patching up the holes um usual properties you know you've got the one3 security you've got attributability if people try to Fork the network you can slash them uh very long discussion going on right now about whether or not you should or should not be slashing nodes in this network and I'm very confused by that one and it's a very interesting one so I recommend reading the literature about it afterwards um and then the size like we're going to kind of take Le playable care uh you have a fundamental trade-off right if you're decentralizing the system you are actually just like slowing it down you're you're making your whole thing more latent right one of the trade-offs with the rollups is that you just have one node it is just doing thousands of transactions for you you don't have to worry about it too much it's really easy uh the moment you decentralize it you put Network liccy in there you slow down the whole network you have to you have a certain amount of time in which you can build valid block and then you have time to vote on it um if you pack all this stuff really closely together you can get basic the same speed but doing that is actually really hard so uh you are going to introduce latency issues and in the main big issue with tender is that uh one the slowest proposer is kind of like a major source of uh um delay in your network and two your your 1/3 plus one slowest validator is also a major delay in your network right because then you can come to consensus for a few rounds or whatever um or it takes too long in it's round uh so the network will be configured to expect really really high performance uh like characteristics from the notes you do this by just saying the blocks are huge the times are fast you're going to start missing uh rewards if you're not like keeping up with the network um is this okay is this sensorship resistant now you put it in like only a very few number of people I will talk about how we handle that later and why it's still like actually quite good in sensorship conditions but right now you definitely have some amount of sensorship resistance uh classify some with different metrics as you like and you also have um yeah I forgot I was going to say next but you have some nice properties from this reasonable life this guy most the cloud Cent have actually less than 100 copies so um right yeah so I covered this already right I'm not going to get into 10 minutes but uh does everyone know roughly how these kind of protocols work you all vote in one round you're like hey I just seen a block vot everybody no okay uh uh I'm going to say go watch the talk um but but roughly some guys send a block out and say I think this should be the next block and then uh you kind of say oh I I also had the same block or I've seen this block before or I've seen your vote for the block and then you say I'm going to send out to everybody that I've seen this block and then everyone says oh two3 of the network have seen this block in the last like bit of the round and you say okay cool at least two3 of the network has seen the block and committed to it we all agree that's it that's tender me like a very quick let showell um the thing is that in the round you might not come to consensus you might not get the 2/3 vote and you say there's probably some major latency of the network or there's an attacker and so I'm going to dump this block on the ground and I'm going to start a new round and we try to like come to consensus on a new block from a new proposer in a new round Z Works normally uh starnut changes this a little bit uh we say that in the first round you can come to consensus on a block and in the second round you can only come to consensus on an empty block super weird property like it causes weird Jitter in your network and the question is why the hell would you do this um and this is kind of like one of the really cool things about ZK systems or one of the really annoying ones is uh you have this relationship between sequencing transactions and proving them you can sequence them and like kind of lock onto them and then prove them afterwards like like ZK proofs are embarrassing L parallel right every block I can prove after I've already like kind of come to consensus on it um but we have this problem now that as I keep sequencing transactions if the prover is lagging behind and I don't have a proof for a block a long time ago I suddenly need to reorg that block if there's an issue right so we actually want to slow down the network so that we have fewer transactions that you're capable of reorg or doing into in a farious with uh by having uh the proofs U basically block the rate at which transaction is going this keeps these two things imbalanced uh does that all make sense now the other thing that you want to do is one proof of one block posted on ethereum is actually too expensive it's not that much in itself but if I'm doing it for thousands of blocks it becomes very expensive and the whole point of starks is that when we aggregate them all together it becomes much cheaper using recursion of the proofs I proof that two proofs are correct that all the way up to the top and so on Stark we have 30,000 blocks roughly in a batch I think that might changed in the last update but before that that was roughly the number so I take 30,000 L2 BS and just like send them all off in one go and I get some nice uh cost savings because of this agregation um but now you have one person who be responsible for approving 30,000 blocks that is really bad can anyone think of why because yeah it's expensive for the guy it's not the main reason it's problem what if one of the blocks can't be proven H yeah well it's it's more that the spends a bunch of money can't prove one of the blocks so the whole proof is invalid exactly and now we need to reorg shits on the blocks right there's no no one saw this coming so the aggregation of two blocks together is a really easy thing to test the full test of the correctness of the execution engine and the prover is really really hard so if there's one little proof right in the middle of this thing that is unprovable I suddenly wasted a whole bunch of effort and I need to reord network for like a crazy amount of time but nobody wants this so what we're doing now instead is every block gets proven in another Block in the chain which means that we're constantly producing small blocks that we're constantly producing small proofs for them which means like I'm consistently uh reassured that the proof will be able to be generated basically right like I okay so there's a specific parameter in here called the K parameter um which I don't think anyone's called the K parameter before but starkness K parameter is what we use and it means that K blocks ago needs to be proven in my block otherwise it's an invalid block and we come to on no block we move on right this creates a very strange structure this is one of il's favorite drawings a reference to that um this is a blockchain imagine each of these little squares is a little block and it goes like through um we've put this zigzag pattern in for a reason because it kind of like represents rounds and then you basically have these different proof chains that like overlay it the different uh alignments in each of these strands the block that is in that chain proves K blocks ago the correctness of that block right which means that one block should prove every Cape Block in a modular fashion all the way through the history um and if they don't compl sens you use have an empty block then your proof will technically contain the empty block proof which should be quite cheap right uh in this way we're consistently getting Pro for blocks we know that they're doable um and we're Distributing the cost of doing the proofs because every single person he produces a block is responsible for producing the proof Koo and this is the reason why we've got roughly two Epoch on the uh on the um like proposer selection because they need to know way in advance I need to prove a block blocks to go right so I need start producing the proof long before it's even my job to start sequencing my ACS do it all come together it's all making rough sense cool how much time have we got left all right uh right there's one last bit who the hell posts all this stuff to L1 uh we don't have an answer for that uh partially because it's really simple and maybe it's not and we need to do a bunch more work on it um but effectively you would just choose one entity somewhere in your system probably one of the proposers and you say okay you've got got so much time to choose three blocks or like the the heads of each of the proen strands put them all together stitch together all the state transitions because you just proven like State transition one state transition two State transition three you now you need to also prove that the ending of State transition one is the start of State transition to you need to like do all the stitching all along if you're understanding this from just my rough explanations you should really go talk to Il he also ask this talk people to come work with them um and uh then you post it on this proof should be really simple in some sense like the the structure of is very simple so we can we can be pretty sure that it won't fail uh and this like the whole point of like spining up these small little proofs all the complexity of proving is hidden these small blocks and then like it's kind easy and cheap and and verifiable that this intermediate step won't fail it's like a really important property right because if that fails then we are back to the problem of having 30,000 block reor which would be fors right um Q uh I think I covered all this in the discussion uh all right this is the question what if I can't prove a block what do we do like we come to consensus on the K blocks ago there's a block was unprovable we Tred to come to consensus no block comes there's specific thing with ZK proce uh which is solvable I'll talk about it later um but it's really hard to differentiate between a proof that is hard to generate and the just taking a really long time to come kind of like a networking failure or a proof that just doesn't prove right approver just says no you can't get a proof that the approver said no or maybe you can't but that's for the next slide you get the idea so like suddenly we're just getting empty block empty block empty block empty block and then you say okay well I've had like 10 empty blocks maybe we should reor and so one of the big discussions happening right now is like how many blocks should you wait how big of a reorg is acceptable um like how many how many like resources or fees should you lose for like producing the blocks whose responsibility is it to like say I think that this network is not producing a block that is provable this is like the disasterous scenario phys like prove systems this is what everyone's terrified of has it happened before yes it has happened before uh but it's usually a bug on the execution side that produces State update and then you can go and Patch it and do the proof and so it's solvable but uh there are definitely cases where if the pr is like got a mistake in it provs are very hard to get right so it could take days for someone to say like oh I'm this Pro and so now you've got like a liveness issue for days not okay um so the solution would be to just reor that block out uh but then the question is like how long do you want to make that reor window and stuff um or this is something that never mind research is working on and we're trying to see if it's feasible is one of the coolest little things that we've worked on a long time I'm not going to explain the whole diagram but this is courtesy of uh bisa um the idea is we use two ZK systems in conjunction and we assume that the likelihood of a mistake in both provs happening at the same time is significantly smaller than uh right this is not public work there will be a blog post about this so you guys can find it out link later um but you're more than welcome to take pictures of it does that make sense so I actually use two ZK systems from two different systems uh I'm not going to name your names but like you can imagine like Risk zero or something else it's another Pro and what you do is you yeah so if I understood you correctly those two uh provs that run uh in parallel they could have different uh times taken the different time taken for uh Computing proof for the same block why is that oh no I'm not saying that we run the same two provs on the same thing and there's the reason why we wouldn't do that so no no no no I'll get to that um but this has been a a proposal by a few other people as well I think it's uh fairly good but the problem is that if the bug is is actually in part of the stack like the virtual machine itself so you don't solve the problem right agreed and that's not a good Solution that's our conclusion um in the in our system what what the N is proposing very specifically is that you have one prover which is proving the blocks and then you have another prover which can prove mistakes in different parts of the stack so you say if there was a bug that caused that like the state transition done by some like optimized version of the runtime which is what we do we separate the actual execution from the proving so we do the execution we get the state differences then we re-trigger the execution for the pro knowing what the state differences are and this is how we parallelize so now you've got two different execution engines with different properties and like no formal semantic proof um of their equivalence uh and then in that they produce traces which are then checked by a different system called a trace Checker uh if that has a bug then the prover will fail to produce a proof or the proof might be producing a proof on a wrong Trace which means that theover has a bug right so you can kind of make a taxonomy of all the failure cases and you can wrap them all up in an alternative uh like each one of these pieces you can make quite small on like say on risk zero or something and each one of them you can prove that there was a bug at that point in time and therefore like raise a warning to the network and say hey this this block is like categorically unprovable here is the proof which is quite cool so you got this like two bits together it also means you can make sure that the execution is as fast as possible the proving for the execution is as light as possible and then like you can kind of leave the proving of the incorrectness to be as robust as possible you don't have to worry about the price of that as much if you can decouple these two things as well so you have more designs make anyway uh this may or may not be part of the protocol this is one of the big like current things um cool uh how much time do we have again five minutes valid set yeah so theun nodes uh basically the log with validator site will be maintained on the L2 itself because it's cheap to all information there and do the updates but you will basically be able to trigger a transaction on L1 to deposit into the validator set on the L2 and that will be Force included in the network which means that if you have assets on L1 you can rescue malicious L2 uh if you don't have assets on L1 and L2 goes malicious then you fit the major failure case and you have for the network to know the contract which is seriously B for anyse um this is a this is probably the stickiest issue um and this is not the case for Stu and this the case for all of them how do you how do you deal with this if you have a Mal Sal to network uh how do you control the L1 contracts if you have a malicious ownership of the L1 contract there's literally nothing you can do because all of your ERC 203 o which is the whole point of italic talk about don't overload ethereums like consensus um this is the area that needs the most research in my opinion outside of the consensus part we will build a consensus system it will work but this is the one where you need to reink hard about how to fix it um great I think yeah uh one of the reasons we don't like d protocols is because the M properties we don't know what they are uh there's not really great literature on what they are so that's a question to you the audience you're interested in this research topic and you can say what happens in the dag based system when my incentive to actually disseminate steps might not be same is just like getting the networks moved forward um it would be interesting to know that is great where are we uh nethermind which is our company uh and we've got some of the engineers here in the room are working on the consensus implementation uh in formal systems which design tendermint and this like the guys behind uh Cosmos they are working with starer a little bit on designing their tender implementation um all three of these entities are working on sequencers to be as fast as possible this is all ongoing work uh nether mind's impation is super early I thinkal systems is uh like quite a bit ahead of us um but it means that like we're really gunning to start getting the stuff in next year so we're talking about like I don't know I personally I want start to be the first decentralized like decentralized CK rollup maybe the first decentralized rollup other than like Tao um H yeah oh you know something I don't that's my my goal uh this is not a commitment from St Foundation NE minder anyone else this yeah yeah yeah yeah but I said it was my personal goal um so right uh I think we might be a little bit over time but since this is the last session if you guys don't mind I've got two more minutes um this is probably the biggest part and I think this should probably have been like mainly point to talk but the staking is coming to dark n it's coming very soon um yeah you might ask yo but you still haven't finished like the consensus part why are you doing staking uh what we want to do is we want to already start lining up the actors and basically get everything done in the same way that ethereum did where they launched like most of they taking uh infra before actually doing the consensus change it's a really difficult and complex transition and it involves having a lot of Buy in from different people so we're sort of like getting the Buy in now this is part of the alation here um what does it look like it's a little bit like Celestia so you've got a set of stakers who are responsible for doing the actual operations for the network um they will have some minimum buy in we are considering 20K uh anyone can delegate to them if you don't want to do the technical parts of the staking and just maintain the security of network with your tokens there is a particular curve which has been designed by Norm I think um yeah uh so tokens will be minted to the stakers uh you can find all of this on the community Forum I'll have a link at the end um the amount of rewards decreases the higher the staking set is this is to try and get a natural equilibrium tokens locked in the protocol and tokens are liquid to pay for the actual transaction fees on sarut um I think the games the aim is between 1.8 and two uh percent a year return uh this basically says that like if you have everybody in protocol theur is slightly Al they've changed the numbers a little bit um then uh maximum you be minting around uh 4% total uh extra dilution right um so the blue curve here is the total amount minted over the year the red curve is the amount of rewards per person per unit of time uh for a particular amount of St like total AET stake here that makes sense to everybody so this this keeps it in equilibrium and makes sure that like the staking the total mint a year doesn't range more than what this lowest value is here to up to use it we and the goal is to get surround by 2% um what are the responsibilities there to be announced and I actually can't talk about this um but uh they will be done incrementally so if you decide that you want to be Staker and not delegate you want to be sure that you can Implement whatever the protocol asks of you within the lockout period is if you can't you're losing that money maybe that's a bad idea um actually there's no slashing so you might not be using money for most of those things they just be sitting there not earning any Revenue uh it is every staker's choice to decide what the uh distribution of rewards is between the delegates and the state and so you have an open market of stakers and rates and things like this cool I am yorck my telegram handle is meol Surfer the person who's actually re knowledgeable about this is Dena Dy and this is her email and she's more than happy to answer any questions involved in the conversations um we're trying as hard as possible to get these things out in the open so it's like really easy to follow where they are um I think stet is one of the most amazingly designed criticals with some really beautiful things underneath it um and it's made by the stock team and uh they have been working day and night to get this done and get this out to people and we are now working to help them get it out to more people and so we're doing a few initiatives around this um every two weeks we have a call with all the full node development teams to talk about where the status is I would like to start doing this as well for the consensus one once we're in a more stable state but in the meantime um this is an open call you can come join uh if you want to ask questions you'd have to first message me um uh and then there's the community Forum where most of the updates are posted for like different technical changes and S that are happening um we're trying to shorten the window between design decisions Community for postings and like this sort of like conversations happening uh and then this is never mind I'm not going to give that whole Spiel because we are overtime thank you so much everybody for coming I hope you all learn a lot about l2s and uh we shall see you at another top I'm sure I just gave the nod to like turn off the camera yeah thanks for hello yeah yeah we can hear you so I I would like to thank thank you for this presentation uh if I would like to be a Staker uh what are estimated Hardware requirements and connection speed yeah um this is embarrassing I actually don't know that answer um it's a very important thing so this INF infrastructure has been run by by starware exclusively uh up M and they're talking about the decentralization um if you look at the Juno full node you can definitely see how much the storage requirement is uh which m y know what the current full node sizes and DD all right okay cool and then blanket Stam in probably top of the line execution oh he said 170 KS by the way um uh yeah I can't give you get answer but it would probably just be like as big as possible like pick your top OS like server like right now actually not that big because the demand on the network isn't that high like we have a peak TPS as of last week with 400 like transactions a second second um which is not close enough to what we needed to be but is definitely like going in the right direction um but like the actual like transaction usage is like much lower than that so you don't need top the line right now uh but uh I'm sure it will be quite High uh I would say bare metal top of the line something something something sorry not a very good answer but uh you should ask if you're interested in just make a post on the discussion forum and like call out starw directly and ask if they could share their specs that would be that would be cool I think now is the right time to start talking about the stuff any other questions nope okay then thank you cool thank you very much thank you