 I'm going to be talking about our past presence and future research on expected consensus. Let me quickly say that this work that I'm about to present was done jointly with our amazing intern, Shuei Xiaowang, who unfortunately is not here today, as well as Guy that you already know and Marco and ready lots of inputs from the rest of the team. Okay let me take like one step back and just think about like Filecoin. So Filecoin is like storage-based consensus protocol. So we can think of it as like in different layers, top layer. This is really like the Sibyl resistance mechanism. So in Filecoin like this is based on storage. So basically how we solve like Sibyl attacks is by asking participants to commit some storage to the chain. This is done using some really cool cryptography that my colleagues at CryptoNetLab are designing but we will not be talking about this today because this is consensus lab not CryptoNetLab but we are going to treat this as a black box and just assume that we have this Sibyl resistance mechanism that is based on storage. So basically what we get out of this layer is a list of weighted participants and then this list of weighted participants are going to rent expected consensus which is one consensus protocol. So you can think of this as like the output of this of like this consensus protocol that is run by this weighted list of participants is a list of order transactions. So today I'm going to be talking about three like the expected consensus part. So this consensus protocol so again you could like any set of like weighted participants could run this so I'm going to ignore storage but just know that in Filecoin participants are weighted according to their storage. Just to give you like a full picture today we talked about a lot about like subnets and IPC so basically like subnets there will be kind of like a different layer as expected consensus. So expected consensus you can see it as the consensus protocol that is run on the main chain. So if you remember all the slides where we saw you know all the different layers of consensus like expected consensus is the root chain. So now let me explain quickly how expected consensus work. So as I said we have a weighted list of participants we call this the power table and in Filecoin this set of participants is weighted according to storage. Now like in many consensus protocol Marco mentioned in his talk like earlier today that our consensus protocol if you ignore storage it's like very very similar to proof of stake consensus protocol. So there is a leader election mechanism. In order to have a leader election mechanism if you want this this mechanism to be random then you need to have a random beacon which is great because we have gerunds which is a decentralized random beacon. I'm not going to not going to touch this during this talk but just imagine that we have access to a perfect random beacon. This random beacon is fed to a VRF function a verifiable function. So basically each participant are going to compute their own VRF, put the random beacon as an input to the VRF, get a random value and then this is going to tell them where they are elected or not. So if you are familiar with proof of stake consensus protocol this is like very similar to leader election in proof of stake consensus protocol. So one difference between expected consensus and other type of consensus for example longest chain consensus protocols is that in expected consensus which by the way we abbreviate as EC they are on expectation five leaders that are elected in each round so they could be more they could be less but on expectation that five so that's different from most other protocols where there's only one leader elected each round. And so same like differently from longest chain consensus protocol in EC we consider tip sets. So tip sets they are a set of blocks that all have the same height so they were all created in the same round and they also have the same parents. So this is basically how tip sets work so if you think about ABC like this is one tip set one group of block, same height, same group of parents, same for DNE this is another subset a tip set excuse me and same for FGH. So you can see that instead of having like one block per epoch we have one tip set per epoch. So really you can think of expected consensus as a mixed between longest chain protocols if you are familiar with us and DAG based consensus. And then in the unfortunate case of FORX we use heaviest chain rule so to simplify things a bit we will choose like any chain any tip sets that has the most block in a sub die. So this is like a very high level introduction to expected consensus but really like if again if you are familiar with longest chain protocols which I'm sure everyone is like this is like just a variant of longest chain protocol where we have more than one block at each round but each blocks have to have the same parents. Okay so that being said let me quickly talk about the pros and cons of expected consensus. So we have five miners that are elected on average which is nice because it means that miners are elected more often than if there was only one miner that is elected on average. So this is nice to give like less variance in the leader election mechanism. We know that in proof of work actually having a high variance is something that is quite undesirable and especially it leads to centralization. So actually having less variance is nice yay. Also something that is nice is that private attacks are harder. So private attack is the most simple type of attack you can think of it as an adversary that will basically decide to like fork create an alternative chain that it will keep private so basically the adversary will work on its own chain at the bottom while the rest of the network will work on their own chain as well. So basically we have two chains that grow in parallel and you see that if you have more leaders that are elected in each round then basically the chain that the fork that has the more power will grow bigger than the chain that has less power and this will be the difference between the two chains will grow faster in the case of tip sets. So if you consider that one block is one tip set then the difference between the two chains will grow faster. So this is one one advantage of expected consensus but sadly we also have some inconvenience. So one of them is balance attacks. They were introduced in the context of block dag. I'm going to talk about this a bit more later. We also have like long finality so it means we need to have probabilistic finality. We need to wait a lot for a block to be finalized for transaction to be finalized again this is the same as bitcoin. We need to wait any longer chain protocols. Protocol has this problem and also we have some variants of long range attacks which I'm going to give more detail about now. I'm going to be talking about proof of stake system for ease of exposition but think of whatever I'm saying for proof of stake there is like a variant that exists in the context of proof of storage. So in a proof of stake system in order to create a block you just need like signatures from the miners which we also call the validators. So we can think of it as we need like a quorum let's say two-thirds of the signature of the validators in order to create a block. So now if you look at my slide imagine that we start with like the green validator we have like one key that basically represents the quorum of validators and let's imagine that after some time these green validators they decide to leave the system this happens people leave people join so then we have the blue validators and next we have the orange validators this is like a you know usual life cycle of a proof of stake system. So now what could happen is that these green validators they have left the system they have sold their stake they are not interested in the system anymore so they could like the adversary could like bribe them to and just buy their key at no cost because these keys have no values they have zero value at the present time and this is extremely problematic because as I said we are in the context of proof of stake so having access to these keys means that you can just create a block like instantaneously so the adversary gets the green key green key who are the keys from the past validators then with these keys the adversary is able to just rewrite an entire alternative chain maybe the adversary will simulate some you know change in the set of validators say like now there is like the red validators or like orange and pick one and the issue with this is that if we have some users Alice that has been asleep that wakes up and that see these two chains she has no way of knowing which chain is the correct one and which chain is the adversarial chain because both chains are actually valid both chains have like valid signatures so only the set of validators differ in these two chains but Alice cannot tell which one is which one so in order to solve this problem we propose a solution that consists in check pointing the stake of the proof of stake chain on to bitcoin so we have a paper like a protocol called Pikachu so I'm going to give a very high level description of this I'm going to later give a link to the paper so you can have a look if you want more detail but imagine that each CI here is configuration I so set of validator I so what will happen is like whenever there is like a new set of validators that join we will have a checkpoint on the bitcoin chain from the key pkm-1 of the previous validator that going to transfer all of whatever amounts they have in their associated with their public key to the new public key pki and here you can think like pki represents the sets of validator I and then when we have the configuration CI plus one we're going to have another transaction that is going to be from the key associated with CI to CI plus one and the way to think about it is that this transaction and this key pki-1 they represent threshold signature so in order for one of this transaction to be valid we need to have also a quorum of signature so all of the all of the validators all of the configuration need to agree to send this transaction to bitcoin and the idea is that then anyone can go on the bitcoin chain start from the initial public key pki-0 associated with the first set of validators follow the chain of transaction up to pki and then basically pki will give them like information about the current configuration CI so here is like the high level summary of the protocol we see that periodically we have new checkpoints that are pushed onto bitcoin for this we need a distributed key generation we need the configuration to create their key the key that represents like their set and we use schnor's threshold signature which is really cool because bitcoin recently had this upgrade that allows for schnor's signature so basically we can have threshold signature that just look like a normal transaction on bitcoin so this is great we also add a cid using the operator functionality of bitcoin so any participant can use this cid for example with ipfs in order to retrieve information relative to the current configuration so yeah this is a very high level description of our checkpointing mechanism i'm not going to go into more details but please if you are interested check the paper it is on archive on archive i'm also going to present it at consensus day in two weeks time um so great so this piece of research that we did with marco uh basically deal with uh longer attacks so one problem solved cool now what about the next problem balance attack so i said i was um going to explain very quickly what they were so again they were like discovered uh studied in the context of like dag chains so in the context where there is more than one block that is created in each round like we have in ec and the idea is like it's different from private attacks if you remember private attacks i told you that the adversary was creating an odd in its own chain privately in this case the adversary is actually sending blocks to the miners the the honest miners but he's doing so in a way to try and make and make them mine on different chains so basically the adversary is trying to confuse the honest miners um on mining on different chains such that they do not reach consensus so just two chains grow at the same time um and one way like the adversary could do that is by equivocation so if you look at this slide you see that the red blocks there are the blocks from the adversary you see that we have b1 and b2 and the idea is like the adversary was elected leader and in order to confuse the honest miner it equivocated so it created two blocks b1 b2 where um it shouldn't be like the adversary should only be able to create one block so that's balance attack very high level so one um one suggestion that's uh we are proposing that was led by guy um is to implement a consistent broadcast protocol and having a consistent broadcast protocol allows to prevent equivocation so basically what i've just talked about uh this scenario where an adversary create two blocks b1 b2 even though the adversary was elected only once um consistent broadcast prevents this so this is the current structure of one round in um in fight going so basically how it works um this is the beginning of the round which we call an epoch ill fight going and then after some time there will be like a cutoff and basically this cutoff will tell the honest validators um that's it um i stop accepting block for for this round i'm gonna you know build build my own block and broadcast it so what can what what happens with this like cutoff thing is like any block that is received before is uh accepted and any block that is received after the cutoff is rejected so if for example one node one node received like two equivocating block from an adversary is gonna accept one but maybe like reject the other one so how we um want to solve this is by having this um this consistent uh broadcast and basically we're gonna add a second cutoff so what this means is like before the first cutoff we're gonna tentatively accept block and uh then after this period after the first cutoff we're gonna be like stop we don't accept block but we keep like receiving them just to check if we receive any equivocation and because we are in a synchronous setting if there was some equivocation then you should like receive them before before cutoff too um so basically this is just giving you an extra an extra time period in order to check wait has there been any equivocation and uh if there has been then you will decide to not accept this block so this is uh this is an ongoing uh FIP that we are proposing so yeah we believe that this FIP uh I mean this proposal um really like mitigates balance attacks and all variants of balance attack so this is great now you can see on my slide we only have one like some down left um which is long finality so again I'm sure all of you know that's um this is the case with every blockchain like bitcoin any longest chain blockchain like we have to wait a long time for block to be finalized this is annoying so um so now what's what are we doing about this we are actually presenting a new protocol called starfish so I'm just gonna give you like the intuition behind this protocol so we want to stay as close as possible as easy because we don't want to have like a big sudden change in the in the protocol so what we want to do is like as before in one epoch there are you know multiple validators that are elected but unlike easy with starfish the validators that are elected they are not going to create a block they are just going to create a vote so they are just going to vote for a previous block and now we're going to have only um one person that is elected to create a block but they can create a block only if there can include in their block like enough votes for the same block so for example if you see my slide here we had like five blocks for like this block so basically anyone that is elected a proposer in the next round can just include all these five block and create a block and so the idea is like we have one block with five votes instead of having like five block then like numbers are just parameters that we are going to tweak so briefly why we do why we think like we should do this is that it's because it makes forks harder um again imagine we are in this scenario we have a fork like you know this can happen can be adversarial or or non-malicious and then we're going to have like multiple you know look the votes are going to be spread on the two blocks then like usually what we'll have in EC is like yeah you know we'll have a fork here however now with starfish because we have votes that are spread on two fork anyone that is elected leader in this epoch will not be able to create a block because in order to create a block you need to have like five votes for the same block so what's going to happen is that we need to wait for more votes you know in the next epoch to arrive and only in the next epoch will someone gather enough votes for one block and then be able to create a block so basically we give extra time for convergence and avoid fork um so this uh this idea like starfish was was um like inspired by a lot of similar work that has been done for example bobtail maybe is the closest one um bobtail was in the proof of work case there's also free chain that is kind of related and also in the proof of stake system there's a lot of a voting mechanism so so yeah there is quite quite some related work on this so this is great as i've said um it seems like uh having forks is harder with starfish than it is with expected consensus um so well i said that i will also present you know some future research and actually this is kind of some future research for us because we are currently looking at how to formally prove the security of starfish and um we we don't know yet how to do it we are actively researching this but um but for now our simulation really indicate that this is uh this has really this gives really good results really good finality so we are hoping to to have a formal proof soon so that's it for me thank you and let me know if you have questions can you talk about the scale so what is the number of nodes that you need to support in the protocol and what is the frequency with which you have to generate new blocks so uh at the moment in falcon we have over four thousand nodes and we create new block every 30 seconds and let me maybe just add something i've talked about like the protocol pikachu that is doing this checkpointing mechanism um this is also one open problem that we have is like at the moment our pikachu protocol does not really scale to like this four thousand work uh nodes sorry so uh so when it comes to the checkpointing to become this to bitcoin this is actually an open problem to make it scale to those four thousands nodes thank you in terms of the future what kind of scale do you envision that you will need to support um so i think foreign yeah so so so in terms of figure so we have this pikachu that we want to scale and i think like starfish um yeah like having having a formal proof of the security this is really our main our main goal for now because we really think that it improves a lot but we don't want to the question was like what kind of scale in the future would you like to support oh yes well you know ten thousand of hundreds of thousands of nodes sorry i missed your question um yeah yeah we really wanted to to to to scale to like tens of tens or hundreds of thousands of nodes and also this is like why we have um IPC um to help us uh scale and and actually also starfish i think this type of starfish or expected consensus this type of like longer chain where you don't really have like that much voting uh this scale much better than for example bft um so yes so we expect to scale too too many thank you thank you