Alpenglow: Solana's New Consensus with Roger Wattenhofer | a16z crypto Research Series

Transcript

All right, welcome everyone to today's A16Z crypto uh research seminar. Very happy to welcome Roger Wadenhoer, longtime rockstar professor at ETHZurich, but recently joined Anza as the head of research and he's going to tell us about what's looking like the next generation of Salana consensus. So, Roger, >> thanks so much Tim. Yeah. Yeah. Hi everybody. Great to be here. Great honor to to talk with you guys about Alpenlow. Uh so this is really as Tim said the next the plan next consensus protocol uh for Solana. Uh I I'm Roger Rottenhoffer and I did this together with two of my uh colleagues Quentyn and Kobe should deserve a lot of credit for this.

So let's start with something a little bit of philosophy. So you might have heard uh this quote if you're like an older person then you have heard of this probably this is some what people talked in the 80s and 90s that in 1940 something the boss of IBM back then said that there's only going to be a market for maybe five computers in the world and actually when this quote got popular is when computers got popular many people got got personal computers at home and people laughed about this quote actually he probably never said this so this is just madeup uh thing by the internet but but people back in the day said these things and I'm going to fix this quote for you uh by just moving this one world worldwide to the proper

place okay so I think we're going to have maybe five worldwide computers in the world okay uh so this is what essentially a blockchain is a smart contract enabled blockchain where you basically want to have a world machine a world computer which not only serves data like the internet but does computation for you in a safe and secure way so that you can use it for all sorts of applications. When I think of applications in this domain, it's like maybe with quantum computers, right? I don't think that these world computers will do all the things. There will be still a lot of room to have personal computers, personal devices, but uh for some applications this is, you know,

sometimes the silver bullet to go there. And uh I think of things like for instance big financial systems. There was this GameStop case at some point where the rumor was at least that uh the people controlling the market kind of you know also had a some sort of their their hands in the game and uh then other people didn't like that. So we want to have something which is a safe machine uh where people can do transactions with that machine and they are you know not abused by those who actually run the machine. Uh so this is one example financial systems this is the current example where everything happens but other things other very big projects

might benefit from such a world computer for instance democracy right you can have something like uh even though XKCD makes fun of this but I actually believe that something like a blockchain or a world computer can help democracies and elections good uh so that that was my philosophy slide so we should go right back to Alenlow so uh this is to give you a bit of a backstory So we started this ANZA research. So Anza is sort of like the engineering firm of Solana and uh back in December just few months ago uh we started to have this research team. Uh that's myself and also Kobe and Quentin that I mentioned before. And

then if you look at this blog post here, you see that we are from ETH Zurich and like for crypto people actually that's a huge red flag. Okay, they immediately think of that as Ethereum Zurich. Okay, so I have to usually explain and this is what this slide is for that that actually means something else. Okay, basically means university. Uh and uh it's sometimes a it's quite a good university. I mean, you guys here in the audience know that because you're academics, but uh crypto people don't know that. So, I found this thing cherrypicked this uh this computer science uh you know by Wall Street Journal that they actually were top of the world at some point. I only found one of them. So, it's it's still cherrypicked.

Cool. Yeah. So, we're operating out of Zurich, Switzerland. Uh so, here you see our window back then and you see the actual album glow up here. That's where the name uh started. So what we care about is performance. Okay. So this is basically what we mostly want from from Alpenlow. So this is uh you know the end of the fun introduction. Let's go to what uh crypto people uh blockchain people really care about. So they have this uh saying here increase bandwidth reduce latency popular with the Solana folks. So let's first look at bandwidth.

Okay how does the state of bandwidth look like? I have this very scientific slide here. So bandwidth is how much how many transactions per second do you get through how many bits per second do you get through okay and Solana's turbine protocol the one we have right now is actually very good regarding bandwidth okay so they basically I would say nailed this they uh are sending the data you know the more bandwidth you add to your system the more machines you add to your blockchain the more bandwidth they bring to the blockchain this is actually helping the blockchain and it can even be heterogeneous so it's very more traditional conventional protocols, they would usually have this leader and the leader would do a lot of work. Okay,

so the leader would distribute the data basically to everybody else and that's essentially a bottleneck that you have. H or they would have some sort of gossip protocols which still means that the leader basically has to pump in the data into the gossip protocol and kind of usually hurts bandwidth in some sense. So you can see on my scientific slide here this is much worse than than this. uh then there's a bunch of modern I would say deck based protocols and you know don't think of this really as a upto-scale uh dimension here but I do believe that they probably cannot quite get to the point where Salana can get and this is a bit of bold statement and I don't have proof for it but the reason I'm saying this is that this is actually

working well with let's say heterogeneous environments so here you can have multiple machines which bring different bandwidth to the table you can basically sum it up and then divide it by the number of me machines which have to be served. Whereas here you sort of need I would say in the protocol at least we have today you sort of need a homogeneous environment that all the uh proposers are basically getting the same traffic. Okay that kind of balanced with traffic so that you can actually use the bandwidth that you have. Uh so I don't think it can get quite get here. So where's Alpenlow here? So I put it a little bit to the right of Salana but uh but not much. Okay. Uh so we maybe can uh make a few efficiency tweaks there

but uh it's not going to be much better than what we have today. So let's go back. Uh so I would say when it comes to bandwidth it's a little bit optimized but not much better. The big difference is in latency. Let's look at latency. So this is I can define latency now as something like when you put a transaction onto the chain how long does it take until it's finalized until it cannot be reverted anymore. So that's how I would define latency here. And Salana kind of claims to have finality in 12.8 seconds after something like 32 blocks. Each block being about 400 milliseconds. That's how you get this this time here. Uh but they also have something they call optimistic

confirmation. So this is just when you see enough votes for a block on the blockchain, they would consider it basically guaranteed to be in. Okay, even though it's not exactly like that. Okay, so at that point after 5 600 milliseconds, you don't really have a guarantee here. Uh but you kind of can be almost sure and when you talk to Salana people here, they would usually tell you that this is so sure that it almost never happened that this was reverted again to not being in the blockchain. But it's a bit an apples versus or oranges comparison, right?

Kind of like what do you really call finality? Alenlow here would have a very low finality would be super fast in terms of when you put a transaction in the block at what point is it confirmed. So we claim something like a median finality with 150 milliseconds. Uh this is with the current stake distribution of Solana. that has a some sort of favorable stake distribution that gets you this kind of finality and uh but you know there's a you know sometimes a bit faster sometimes a bit slower uh this is a simulated result when you just test our alpen glow code with the current uh system and well this I would say will be an applesto apples comparison here uh let's

look at the competition again so the you know some blockchains of course have really bad finality Right. So if you uh you know it would not be on the chart. It would be way this way downtown so to speak or uptown. I'm not sure. But the best known competition has something like 400 milliseconds. I would say self-reported finality. And even that is a bit difficult to compare. I would say this is an apples to apples comparison but it's kind of like a little bit a different apple. uh in in some sense uh you know in some sense I think these numbers here are reported a bit favorably for the competition when I look at them. So for instance they don't you know not every node has the same

finality. Some nodes see transactions faster than others or see the finality faster than others. So in some sense it's this is favorable for them but in sometimes it's also not favorable especially because Solana currently has a nice stake distribution where a lot of stake is somewhat concentrated geographically in similar places in Europe in particular whereas they don't have this. So to make comparisons here I would say scientifically that's not really fair. Okay. So it would be important that we actually compare the same things but I don't think there are actually scientific studies which do these things. But no matter what we're going to have a super fast uh latency that's uh for sure. Yeah.

>> Can can you mention what that competition is? >> So these will be like DAC uh so the question was what is the competition here? So these will be deck based protocols essentially. They are the ones which are reporting close to 400 milliseconds. So when it comes to latency we are actually much better. You know you could say no matter how we measure we set a new standard here. But but I think the more important thing is that we actually could probably see new applications based on this. Right? There are some applications which really demand very low latency and I think if you go to the 150 so so to speak domain millisecond domain then we can do other things like gaming was mentioned for instance or just you know better financial systems in general. But okay so performance is not everything. So let's look at

something which is also super important which is security. How can we make sure that this is actually you know a safe protocol? So for Solana Alpenlow we have uh something new something we call 20 plus 20 security or fall tolerance. So the traditional thing in distributed systems is to have this 33% fall tolerance against arbitrary malicious nodes. And research shows basically that this 33% is the best you can get. Okay. So you cannot really go lower than that. But we have 20 plus 20 which is uh when you do the math correct 40. So how can we get better than 33%.

And the answer is that we don't have security against arbitrary malicious attacks but we have security against you know uh different types of uh failures so to speak. So we only have 20% security against arbitrary malicious colluding uh enemies. So 20% up to less than 20% I should say of the stake can be uh controlled by the adversary which colludes in arbitrary malicious ways. But then we have an additional 20% uh fall tolerance against crash failures.

Okay. And you have combination of those two things and this actually happens quite a lot. So you have a misconfigurations of machines, maybe you have something like power outages like we just had that in Europe that all of Spain is basically out of power and you you're going to see this in my opinion this is going to you know much more of a real problem for blockchains than than this is in particular also because usually uh malicious attacks they can be you know we can discover that this is happening.

Okay, we can prove that this is happening and there could be some sort of slashing. Okay, so we could say we slash your stake if you're going to do this, okay, on purpose. Uh so we don't currently don't do that, but we could do that in the future and and so then of course immediately 20% of the stake at Salana currently something like 13 billion US dollars or something like that. So it's a really big number, right? So you you risk a lot of money uh if you if you do that. So people probably will not do that and they will rather see more more on the crash failure side. And then finally uh and that almost is the last uh simple slide I have and then I go a little bit deeper into the protocol is

you want to keep things simple. Okay. So uh a simple protocol is a better protocol for various reasons. Uh we want to you know improve it and maintain it uh in the future and then of course simplicity helps. It's also easier to prove. So and I have a a little meme here as well. So these are like you know two recent uh rockets and like the current system of Salana is a very very complicated machine. Okay. And I would say our our system is a more efficient machine but it's also in some sense much simpler. It's still complicated. Okay don't get me wrong but uh but it's in some sense uh easier to understand.

Good. Uh I have now a few slides which just compare the current uh Solana system to our change and then I go deeper into the protocol. So the few slides are probably motivated with this meme video. You might have seen this. This is the Argentinian president MLE. He probably is popular among crypto people. Uh so this is him on the whiteboard basically ripping off uh ministries in Argent Argentina which he thinks are not necessary anymore. And so I did the same. Uh so this is basically our Salana whiteboard with the current I would say these are the main ingredients of the current consensus protocol. So in

particular we have this tower BFT the the consensus protocol itself. We don't do this anymore. this goes away of I would say if I was the Archini president uh we have a proof of history which was I would say a core concept of Salana but but now it's also history uh then we have gossip protocols so this is basically what many blockchain systems have that they send messages between nodes in a gossip style way where they have some sort of virtual network uh where the nodes talk to each other. So this might still stay for a while but the consensus part that we do actually doesn't need gossip anymore. So this is gone. And finally you have turbine which is a data dissemination protocol we really like. Uh that's

actually I would say the one of the main reasons Salana did so well so far. Uh and even that uh we're not going to remove that but we're going to replace it with something called rotor. Okay. Uh so that's our new uh data dissemination protocol in Solano and it's uh complemented with I would say voting style protocols and we looked into the research for that and we tried to get the best ideas of recent papers and in particular we looked at the simplex consensus protocol uh and versions of it I would say and we looked at something like Banon which has a a good fast path implementation and we looked at these things and we're basically motivated by these things. So what voter is is taking some of those

best ideas and I know now in the room there's many consensus experts uh which would say why didn't you this or that way but we had to make a decision at some point and this is sort of where we where we ended up. So voter and rotor are two systems uh the voting part and the data dissemination part and I'm going to explain them quickly to you. Uh so let's open up with first the rotor. Yeah that's nice. Uh so this is the data dissemination part. Uh so and as I said it basically comes out of turbine and the name rotor comes from this is a multi-layered protocol. So far the data dissemination it's kind of a tree where the leader would send data to other nodes which then on would send it

to other nodes and so on. It would be a real tree so far and we remove the tree part. We make a single layer. So we basically remove all this from this turbine and then it becomes a rotor like a rotor in a turbine. So how does it work? Okay, finally some technical slides. It doesn't get much more technical than this but that's that's how this works. So we have a single layer uh where we have a current leader. So we have a current node which collects uh transactions and puts the transactions in a block. I should say that this is already something that we do in a pipeline fashion. So the block is basically uh sliced into what we call slices and then we send slices out every so often. block takes about 400 milliseconds right now, but then each it

might consist of, you know, a dozen or so slices or maybe even more slices. And so the leader sends out one slice after the other of data. Now each slice and this is only the picture of a single slice is cons made of shreds. Okay, so we have these uh shreds. So here we have green shreds and red shreds in my picture. This is like the classic way how works. So you turn you use eraser coding and you split up the slice into shreds and these are the data shreds. So together if I just uh connect uh if I basically take the data shreds and just concatenate them then I would have the slice back again. But then there's also coding shreds which are basically just

the eraser coded other part of the slice. So what this means is that if you get half of these shreds um with the eraser coding then you can put the slice back together. Okay. So that's the idea. So you have a so sort of expansion rate of a factor of two roughly and then this is sent to relays. So now I'm talking about rotor again. So the leader sense makes these shreds makes the slices that makes the shreds and then sends the shreds to the relays. And then the relays are just nodes in the system which then forward the shreds to everybody else. And as I said before in turbine the shreds will be forwarded along a tree. And now the relays are sending the data these shreds just to

everybody in the system. Okay. We think of having something like in the paper at least we think of,500 nodes in the system. Currently I think it's less than 1,300 nodes in the system. But this is just essentially the simplest uh transmission. You can just a loop where you transmit your shred to everybody. Okay, so that's the simplest thing you can do. Uh this sounds like a huge overhead. When I first thought of these things, uh I thought this is actually a mistake, right? Why would you just send one shred to just everybody like this uh sequentially? But this can be done in a few milliseconds, right?

With the kind of bandwidth that every Solana node has. And so a few milliseconds is actually much less time than just sending a packet to a geographically different location. Okay, so in some sense that's actually much faster to do it that way. However, we could use uh some other uh systems that basically give you something like a multiccast system and there's a uh close collaborator called D0ero which uh which gives you exactly this functionality. Uh so this is uh essentially how this works. We change a few things here. So one thing we change is we will not send these data shreds anymore. We just send

code shreds uh directly. Okay. So every shred that we have is coded. The reason for this is that if you send actual data shreds to somebody then this person gets in some sense an advantage because they see the actual data earlier than others. Now, with just sending coding shreds, you just need half of the coding shreds to get the data back together, and the game seems to be more fair at this point. Uh, we're also going to put rewards in here. So, so far this sort of job, even though it's the most by far the most bandwidth heavy job in the in the whole system, is not really rewarded. So in the future we really want that every part of the blockchain system every role you take in that

blockchain system also gets rewarded. Okay. And uh so we have to uh basically uh send some rewards there. So this is something which is not trivial I would say and let me spend a few words here even though I don't really have slides for this but uh so the idea is basically that we going to do reporting. So what we have is we have uh these blocks being sent and then what we have is our so-called epoch. So far these are two days roughly uh of blocks every two days we have an epoch. In the future we only will be something like two hours. So we have a two-hour epoch uh for which we say we send blocks out. We do this kind of job here and we report on other nodes at the end of this

of this epoch. every epoch everybody goes does some reporting. So how this works is that every node who gets these shreds from the relays just at the end of the epoch says from which node did that get did I get how many shreds. Okay. And so then this goes into uh a program uh which then does the rewards. Okay. So basically we want to make this as fall tolerant as we possibly can. And I think this is one of the places where there's still nice room for research. Uh because we don't quite know how to do that. Well, okay. So we of course there's an incentive in the system now to misreport, right? If you don't like

somebody, you just say I didn't get the shreds from that guy or or vice versa. If you like somebody very much, it's your friend or it's yourself even, right? Then you can uh misreport on the high side that he said I got much more than than I thought. Uh so we have to you know we can do many things here in particular. It doesn't make sense to report much more than you could have actually gotten. Of course you can only get as much as this guy sent and everybody knows how much how much was sent in the last epoch. But even reporting on the low side we want to discourage somehow and we have few ideas how to do that. One idea very simple is to just say let's look at the the median for instance when it comes to reporting like let's look at you know

how how how much how many shreds did the median stake for instance when you look at all the stake nodes uh got from that node. So that's one of the things we are doing but I think we're we're open for uh for for new ideas here. Another thing I can quickly mention here as sort of like a research question is how do we actually choose those relays right so the principle idea is that to choose these relays according to stake uh so if somebody has more stake then we choose this node more often and that would help security because uh if I make the counter argument then it's very easy to see if the relays have essentially no stake then uh that you choose then basically they they are not

really invested in the system right and So they have no no big incentive to forward the shreds but the high stake reates in some sense are invested in the system. So we we should choose them with a higher probability and the most secure thing we we can do is to choose everybody with the probability according to their stake. Okay but now there's still questions right do we want to uh do this with or without replacement okay for instance that these are two things which have exactly the same uh expected value. If you choose these relays with or without replacement that's you can do it with the same expected value but the variance would change right in particular if you do without replacement in some sense the variance will be uh

lower uh which is better because everybody's going to just be chosen once or zero times right if you have with replacement then it's then the then the the spread of how often you're chosen in some sense is higher and that also increases the variance. So, but we really want to have the lowest variance version here. And this is neither with or without replacement in the naive way. But we going to basically mix this up with something uh which is deterministic. This is an idea which has been done before with the fat are complete uh version of uh choosing such participants in such a system. And we looked a little bit into this and we felt that maybe even more is on the

table uh for this. Okay. So we haven't done we haven't written a paper here but I think this could be just an academic paper which is part of this Alpen glow uh you know system. We looked a little bit you know this is now the simplest thing we could do. We just looked at basically uh simulations of this system. So we have here uh two so whenever the background is white then this is basically very close to the paper I would say and close to research uh because I didn't care to make uh to make it nicer so far but these are just some simulations basically and we have here let's say 64 shreds in total of which you need 32 to uh build the block together right and now you can think of having nodes which don't forward their

shreds right you can have 40% of the nodes not forwarding the shreds 30% or 20% And we cannot have more than 40% no forwarding because we assume that 60% at least are not crashed and and actually correct. But we can have all these things in a very bad system case. And then is the question if the adversary now comes and corrupts some of these nodes uh with that much corruption power let's say what's the probability that you don't get the block together. Okay. And this a bit more complicated because you can basically every slice of the block could be corrupted and then the probability for the whole block to be corrupted is just if a single slice is corrupted. So you very quickly get very high numbers of corruption, surprisingly

high numbers of corruption. So let's look at this one here for instance. So if 20% of the nodes of the stake are not forwarding their shreds then you can see if you look at uh if you look at the way turbine is doing it right now then you have this probability for the block to fail. So 10 to the minus 6 maybe roughly a little bit uh less even a bit worse or you can have a stake weighted just uh with replacement this is then you have the green curve then you have this fat dog complete the first version in that paper that we get that much they have a second version of the paper as well uh

which we did not implement so well I think but it's somewhere it's a little bit better but not much better than FA1 and then this our version here which chooses essentially uh does something similar to feta comply. Uh basically if a if a node has so much stake that it would be chosen multiple times uh as a as a relay in the system then we would choose it exactly deterministically that many times. So only for the remainder so to speak where it's not a full relay that makes sense then we start to use the probability and for that we do some sort of uh partitioning system that we take all the

probabilities we still have we have the number of roles we still need we have the probabilities and then we choose we bucket them uh and then we choose one one per bucket essentially randomly so that's a roughly high level idea there but I think there's still some things on the table it's clearly and be complete problem because even what we do would use partitioning which we cannot solve perfectly but I think it's an interesting question >> so so sorry so for the so for the validators who in expectation be chosen once or more you're saying you just round up or down >> yeah we round down like to let's say if somebody's chosen 1.7 times in expectation then we would always choose this node once and then

>> and then the seven goes into the second part >> and you're saying then you do bin packing on the things and choose one from each bin proportional to the okay >> yeah we bin pack then for these little percentages and then we choose that according to the proportion and that at least got us you know somewhat better but >> and these are experimental these are reports of experimental >> these are just yeah this is just simulation results we just simulated the system and uh we don't we don't have let's say uh uh you know uh yeah b real bound so far like how how good this actually is But uh and you can see the numbers get really bad if you have a a high uh attack angle. I mean we need 50% of the shreds, right? And if 40% is crashed, then there's still already a

chance that you don't get the 50% and then for each slice we need that, right? So that's why these numbers here basically become very bad and it would get better for instance if we keep like this copper here just means uh the same ratio between how many shreds we send and how many shreds we need. So we have a a factor of two overprovisioning still here and we have the worst case of crashes here. So that is the same. This is for 64 uh shreds. So the same as here. So this is the same curve as this one here. But then if we added more shreds then this would actually help our cause. But these are just you know two examples of uh of things we are currently still looking at like this uh

sampling strategy here on the one hand and at the other hand uh what I said before with the with the rewards right which are also not yet fully clear but I would say many blockchains have this problem still right that you as a node as a participant in blockchain have to put in work and not all the parts of the system are rewarded usually in blockchains okay let's say gossip is the most classic example right in gossip usually is not rewarded at all so why should you do it right so we actually have the ambition here to reward all the pieces so that there there's very difficult for for nodes not to do their job good uh so so far for rotor and now I go to voter so second part so the the voting part so many things change here

and this part in some is more complicated okay and I show you the main points here I would say this part I would really struggle to present everything in a short technical talk because things get hairy. So what we want uh on one slide essentially is we want you know a single leader blockchain where the leader is just rotating over time. So we basically want some leader to propose a bunch of blocks uh four blocks in my picture here and this is also the current parameter we have until before handing over to the next leader which then again proposes four blocks. Okay, so that's essentially what Solana has already today and what we will going to keep in the future. So

it's only a single there's no multiple leaders currently which propose blocks but just a single leader. Now this has been done with proof of history in the past uh but we want to change this to timeout. So how this works essentially is like this. So we have uh at the end of each block we have every node is a referee and the referee just says uh you know was this block in time or not. How this works is that uh every node essentially looks at the last block from the previous leader if it existed. Let's assume this for a moment. this is the case and then starts a local let's say system time timeout here and just checks

is this block here you know in the timeout assuming that this node here has roughly correct uh system clock doesn't have to be a perfect system clock but you know plus - 1% and then can vote yes this was in time or no this was not in time uh anymore if it was not in time it would be against this block essentially we don't do this for just the last block we do it actually for all the blocks but we start a timer here. So you now might say maybe this block here did not exist or something. Uh so we have a you know uh a little bit of a complication to make sure that there's always a timer which happens for the next uh leader window. We do this for all the blocks because let's say if a leader would not

play along the rules and would already the first block would be too late for instance we would download this. So then we have an opportunity to immediately skip that leader. Okay. So if we if we would have a strong agreement that the leader didn't do the job then there would be a down and we would change to the next leader much more quickly. And that's maybe one of the cases where our system Alpen Globe would be have more bandwidth usage than the current Salana system which does not change so quickly to the next leader. Okay. But we have this rapid failover uh idea. Okay. So we have this uh every note basically which then up or down votes every block independently.

Uh it's not randomly independently because they hopefully have the same roughly the same time. Let's assume the referee in our case says yes the block was in time and now we do the same thing as before. So the node just sends out the vote to everybody else. Okay. So that's for that. And uh what happens next? So now every node judged for themselves whether they got the block in time or not and sends out the vote and it sends it out again to all the let's say 1300 other nodes and then well this should also be rewarded. This is actually very sim very similar to before right so everybody in an epoch would just check how many votes

did they get from what other node right and report that at the end of the epoch for the previous epoch and then rewards will be granted based on that. Okay. So uh so finalization works like this then. So you get now the votes from the other nodes and let's say I just collect the votes based on stake. So the votes count how much stake they have. It's uh it's u like that before and you just check if you have let's say 80% of the votes being an up vote at least then you immediately think of the block as final. So what you do is you make a finalization certificate at this point uh putting this can be a BLS certificate here. So you put the

uh all the votes that you have seen all the plus votes uh all the okay votes or no notoriization votes are called really uh into this finalization certificate which will prove to anybody that this was a finalized block. Okay. So that's the idea here. Uh so this is in some sense on the one extreme of spectrum. You can also send this out again to everybody so that everybody also has the same information as you. This is also something we can probably improve a little bit uh here to make this actually uh you know slightly less bandwidth consuming. This is still this is still on the message and actually everything I said so far all the information so the shreds the votes this finalization certificates all of

them fit into a single UDP message right they're all very short you don't need uh more complicated networking than just maybe authenticated UDP messages or some sort of uh you know quick messages or something like that. So on the other extreme you get something like this that you get a lot of downloads um for for the the last block and in this case it's also clear what to do. Let's say if you have at least 60% of that downloads then you uh produce what is called a skip certificate and that just means that the block is considered to be skipped. Okay? So we don't do uh that block we just go back to the last block.

Uh so you can see it's not quite symmetric at this point. You might wonder why we have these things and of course there's a whole intermediate part also that we can send out to everybody. So when the votes are basically between these two extremes what do we do then right and the answer is for these mixed scenarios that it's kind of like more complicated in particular in all these uh varants in between we have one more round of round of voting okay so it's not immediately finalized so here we don't need more voting if you get 80% you're immediately done and here you're also immediately done but in this case you need one more round of voting so now in particular Maybe I want to make the talk a little bit deeper than I used to

make it. In particular, if this is, you know, 60% up vote, so very close to this scenario here, then it's basically already a not what we call notoriization certificate. We would say this is a block we want in, but we need one more round of voting like classic I would say consensus dial two rounds of voting to make it final. Okay. Uh that would be another typical case that we would have here. But there could be other cases. And it's a typical thing for for consensus protocols that you have to make sure that you have different buckets of what could happen, right? And since not everybody has the same view, you al have to make sure that if you see a bucket that also the neighboring bucket that somebody else could see that they don't conflict with each other.

That makes this thing somewhat difficult. Good. Uh well, this is the whole protocol. Okay. And uh this is the whole voting part that we have. So upon things happening we do things and uh so I'm not going to go through it with you guys I think uh but this is what you can see in the paper and you can can read if you want to this is the paper this this white paper but I want to go a little bit deeper for this talk uh since I have a few more minutes. So these are just basically all the votes we have. Okay. So the votes I already mentioned are the up vote. This was the notoriization vote. So you would say I vote in that slot. I have seen you know this this block the hash of this block essentially

or you can have a skip vote that you say I want to skip that slot. That would be typical and then you have these fallback votes that we have here which we borrow from other protocols before. Uh essentially when you notoriize something but uh but you see that nothing really can happen because uh because you know not not many nodes notorized it for instance you go into this middle ground then you can issue uh uh a fallback vote. Okay. uh of the other type to make sure that with these fallback votes we get enough uh you know uh votes of certain type to still make a

certificate. Okay, so that's the base idea here and you can have a finalization vote at the end. So if you have a not vote and you get 60% there you can get to a finalization vote. So this is actually the second part of this slide. So based on these votes that we have on the first round votes uh notoriization and skip vote and on the second round votes all the longer ones uh we can build up to five different certification types and one I already showed you on the previous slide was the fast finalization certificate. So that's just collecting all the initial notoriization votes and if you get a stake of 80% at least to do that then you know that this is finalized and you immediately get this

finalization certificate or more precisely a fast finalization certificate and then with 60% you get the notoriization certificate and then you can with a second round of voting of these final votes here you can get uh a finalization certificate with another 60% here or you can get the fallback cases that you say I take original notoriization votes or fallback votes and they together have to have 60% and that gives you these uh not fallback for instance certificate. So this is sort of like what makes the thing a bit complicated. I would say you know to prove to you that this is all correct you really have to to read like the

10page proof that we have in the paper for for this. Yeah, let's uh look at uh two more little things. Yes, >> on the previous slide, >> yeah, >> some of the certificate consists of one type of message, right? Then you can use a BLS threshold signature or aggregate signature to represent it. But for the certificate that consists of two types of messages, uh can you how do you compress it? >> Oh yeah, that that would Okay. So the question is what about certificates which use two types of messages. how can how do you make a BLS certificate and uh so it would only be from each node only one type okay so you can say you have

either this or that and uh we hope that this works but it's a good question how to do that actually right we would have maybe have to mark it as a bit I'm not sure whether we would have to do that but what type it was yeah >> I mean usually we use a bit vector if we just have one type but I think maybe for uh for these we might have to mark which one it is yeah I'm not I'm actually I don't even know. Yeah. Okay. So this is uh to just show you again how this works in time uh for one round basically. So the leader sends out the slices or the shreds in this case to uh to these randomly chosen nodes to the

relays and then the relays at some point pick up the shreds send it to everybody. Uh so this is of course overlapping because uh maybe the last shred was not received by some relay before the first one is already sent out again. And then you get the notoriization votes and you see here at some point you have this notoriization point where you get 60% of the notoriization uh stake in and you can say this is now an notoriization case or you get the fast finalization and you already have 80%. You just continue collecting until you have 80%. And at that point you would have the fastest finalization or you have the actual finalization vote. So at some point whenever somebody gets to the 60% they would send the

finalization vote which gives you the slow finalization. Now surprisingly this is not always in this order. Right? So depending where you are sometimes uh it's actually faster to do this and then this than to add this part here. And this is particularly the case when you have uh many nodes together in let's say Europe which is currently the case. Uh then of course they have very low latency between them and it could happen that actually they see 60% notoriization votes very quickly from other European nodes for instance and then kind of immediately go for the finalization.

Yeah. One more thing I want to mention. So just a few you know things uh this is a wide slide but it's well hidden. uh so that it's not really white. So you might wonder about this part. So when you're actually in charge, when you're the current leader, then you send out your block and at the end when you're done, you immediately send out the next block. You send out the first slice of the next block because you you trust yourself that you do a good job and in case it didn't work, then you cannot do anything any anyway. Then the others will vote you down and look for a new leader. But but here there's no gap in some sense.

But here there's a little bit of a gap, right? because the last leader sends out uh the block and then the next leader has to send out the block. And what you really want to do here is essentially the simplest thing to do is that the next leader just waits until it sees either a finalization certificate or a skip certificate for the previous block because that gives the new leader uh the understanding on top of which previous block top of which parent block the block will be built. uh but at that point you maybe don't have it right you want to start building your block now but you don't see it but what we do is really we we do it optimistically in some sense here to make this as small as

possible so what we get is we get the previous block or the last I should say the last slice this is a slice now from the previous leader and we immediately start building optimistically a block assuming that this previous slice here would be confirmed confirmed. Okay. Uh would be uh you know finalized but uh and if this happens actually this is given by this parent ready uh event here that the previous block was actually finalized and we just continue building. But in case this is not happening we might start building a new block here. But at this point we get essentially from the system notification that the previous block didn't get through. Okay that this is skipped and this can happen you know

some slices in actually into the next block. And then we would say but at this point we know that the which previous block we actually can build on top of and that would change our system. So technically speaking, we we keep running we keep adding slices to the block here. But uh but at that point we put the parent pointer in here basically saying who is the parent and then these previous uh uh slices will not be used for uh for for the final block. So that's you know just something very technical. Oops, I'm actually running out of time which is something I didn't want to do. So let's just go to the last

slide I have uh which is this one. So this is basically just summarizing everything in one slide. Okay. So we have here what we call a latency histogram. Uh so we have 100% of the stake here uh of all the nodes in the system and this is just network latency from let's say if the leader was in New York. Okay. of what we are currently right now. So the leader is in New York and you can see here there's some other there's more stake which is basically in Salana right now which is actually also in New York. So these are validators in and around New York and then you see that the latency starts to pick up and yeah so here you have the 200 millisecond line if case this was a bit

too small and you can see that for instance here you have a well this network latency here you have a big plateau so these are the European essentially the stake in Europe uh nodes which have about that latency from New York and here you see like some other US uh nodes in the Solano system currently and that's sort of a lower bound you know that's just pure network latency just pure uh you know ping or just one not even a roundrip time just one lag of the distance for for sending a bit and that's the lower bound for how well you can get and now we can look at the rotor how fast can we actually disseminate these blocks based uh you

know how much slower is it and you can see that it's quite a bit slower for these notes initially because basically these are sent to random relays somewhere and then you have from half of them you have to hear it. So this takes some time here but it's not much worse actually than the lower bound. And then we have two more uh curves here. Uh so here we have the 60% curve which means at this point you get 60% of the notoriization votes is the red part and we have the finality the blue curve. So this can be multiple things. So it can be the 80% notoriization vote that you get that here and because of this you get fast finalization or it could be that you have a second round with the 60% and you get finalization like that

or it could even be that you get a finalization certificate from a third party that you see that one first right and it's actually a mix of these things that we see here. I mean maybe not the last one but you definitely see 60% and 80% here. Good. Yeah. And so this is maybe the last real slide timeline. So this is kind of you know we re revealed this album glow just a few weeks back how this should work. What we have now to do is in the Salon universe we have to ask for so-called SIMD where we have to ask for permission to do this from the nodes which have stake in the system and then there will be bunch of testing to make sure that this actually works and the hope is to you know at the end of 2025

or maybe beginning of 2026 to actually ship this thing and that's actually Salana language for shipping things. Good. Yeah. With that, I want to thank you for your attention and uh yeah, thanks also to my co co-authors. This is the link to the white paper. >> Sorry, this is from a little bit back. So, you're talking about this deterministic leader election protocol, right? Sorry, relay election protocol, right? So, you know, I've been elected to be the relay for now and I'm just supposed to be elected once the Solana is different from the Solana that's staked by somebody else because that Solana plus the right to get elected as the leader. Do you think this difference between the different Solana tokens

would make a difference somehow? >> Uh, okay. I think I didn't quite understand the question. So you're talking about the the relay part where you are chosen what is currently done right now and what we do in the future or >> no no like so what what's to be in the future is like um you know so if I hold 1% of the stake I deterministically get elected 1% of the time >> not deter yeah deterministically by some random function uh yes and uh with 1% let's say in 64 shreds you would usually not you know it's there still a random process how often you would get in or Not right. Only if you have a higher stake than let's say one over 64, then you're going to be deterministically in

there for sure once. >> Sure. Like I'm one over 64. Yeah. >> And then I got in once. >> Yeah. >> So I know I'm not going to get in again until other people get in once again. >> I know it's not that deterministic. It's really always just random like each for each slice basically or for each block it's random. But Oh no, actually really for each slice it's random. But uh uh to make sure that in in expectation you get what you have as a as a stake, right? >> Oh, it's still too low random. >> Yeah. Yeah. Still in expectation is still the same. Yeah.

>> We only look at the variance. Actually, the only thing we change is the variance that you you don't have such a high variance. how you got in. Yeah. >> I wonder how do the fallback votes and certificates uh come into the picture of like both the network effects and the lines you had like the uh arrows like where does that fit in there >> and do I consider a block finalized if I see a note or a fallback certificate for it? >> Yes. Yes. Good question. And so what did I didn't say that right? So the question is when do I skip and when do I fall back and in some case I could even do both right? So I didn't really say that at all. So it could be that you can get multiple certificate types for a block

and then in some sense the next leader could even choose >> whether they keep that block or actually they skip that block. In some some cases you really can have both. Right. saying I could have both a note a note or fallback and a skip fallback certificate for the same block and then it's up to the next leader to choose whether the one they want to block in or not. >> Yeah. In particular, this is very I would say not very common but it's kind of the common fallback thing that if you see let's say 50% say yes and 50% say no then basically both sides could now say I fall back to the other side and then you would get basically both the both the certificates. So these things that I showed here, they're always just showing the happy case, which we expect to be

the normal case. But uh but of course it could be that you know you you get the relays and then you don't really send notoriization votes out but you send let's say skip votes out here and then and then this would would happen essentially in this part right that you have a different execution part. This is I would say tricky and there's uh say the conditions that you have whether you can send such a fallback they can be quite uh complicated and uh well I would refer to the paper for that I think it's too complicated to explain here >> and so is this is this sort of like multiple paths is that's part of what's like inspired by banyan or is that >> uh the the banyan has something like

this as well uh so banyan I would say has really the multiple paths which started At the same time I think that was maybe the first protocol the fast path this was something that happened before right that people would say let's try something fast if it doesn't work then let's try something slow but banyan has uh was maybe the first paper which goes forward with both things banyan in some sense is not practical it's a it's an academic protocol but we I would say we kind of made this uh more practical there's also this kuzu paper now uh which is by a subset of the same authors and because they also started talking about this. So in some sense uh this is sort of like both both things I would say have this idea.

>> And why uh why the leader proposes four blocks in a row. >> Uh why why the four blocks in a row? That's a good question. That's actually also people would maybe not agree. So currently this is just what Salana has been doing. So we just keep up the tradition I would say. Uh so it helps a little bit of course to have shorter times between leaders uh or or not have that that often but uh but some people would say let's just do one block per uh per liter and then go to the next block. I think that that would be valid uh valid thing as well. It's a trade-off between performance and maybe uh you know some sort of maybe opportunities because of that as well. All right.

Let's think again. >> Yeah. Thanks.