 Today's first speaker is Pierre Poloniat from Columbia University who will be discussing formal verification of blockchain Byzantine fault tolerance. Pierre. So actually it's Vincent who will be doing the presentation today. So yeah, Pierre used to be a student at University of Sydney. Before I joined Columbia and this is mostly his work that I'm going to be presenting, but unfortunately couldn't make it today. Okay, so is blockchain secure? You might know that some blockchain assumes synchrony, of course depending on the way you look at it, whether they don't ensure finality or they assume some synchrony in order to get this finality. So finality is necessary if you want to reach the classical notion of consensus that we find in distributed computing literature because we need a termination at some point. So there are a bunch of blockchains that would rely on this assumption for different things. And the problem is that if a hacker can delay messages while the system assumes synchrony, then it could potentially steal assets by for example double spending. So this is a key issue in blockchain systems as you can imagine. So just to cite a few attacks that appeared in the literature. You know there are several attacks that exploit this phenomenon of delaying messages right if for example you can delay messages in a blockchain like Ethereum, you could potentially reorder the transactions and this could lead to front running attacks for example. So there are other attacks that consist of trying to partition the network into two groups where the mining power is balanced right so that they have roughly the same amount of money power and this allow a hacker with a very small mining power to do a double spending attack and so on so forth you can imagine that you use bgp hijacking in order to create some delays in the network and this might affect Ethereum again. So there exists the attack of the clones that relies on the same idea where essentially you partition the group of validators in the proof of authority consensus in order to try to double spend right so it's not uncommon to see this kind of vulnerabilities that rely on this synchrony assumption and by synchrony here I mean maybe it's important to to clarify what I mean here is that there is a known bound on the time it takes to deliver any message in the network. All these attacks consist of trying to delay the messages such that the bound is exceeded. But there are some really interesting algorithms that were also motivated by the blockchain space and applications that tolerate a synchrony, which means that they do not assume synchrony. And for we can cite at least the honey badger of bft protocols and the beat protocol. Okay, so these do not assume synchrony which means that they are not vulnerable to this type of attacks. So this is interesting. However, they rely on the same randomized consensus algorithm. And these consensus algorithm was published at Potsky, which is one of the biggest, probably the biggest distributed computing conference and got the best paper work. But there is a liveness issue in this in this protocol that I will talk about in a minute. And this a synchronous randomized algorithms that I talked about rely on an underlying binary consensus that is randomized that is presented in this paper. Roughly speaking, and I won't go into too many detail here. I just want to online outline the execution of this algorithm it relies on on the wild true loop. Of course, at which point you can at some point you can exit the wild true loop applying 10 if you decide. But it is what you look consist of trying to refine an estimate that is called est that you can see online one for example, and it will do so by in each iteration of this one true loop by the broadcasting which is a broadcast primitive that is called binary value broadcasting. It does some very nice property. It's a random common coin right so a random common coin is a is a way to invoke so do random generator and output at any correct process the exact same value right so it can be invoked by multiple processes but it will return the same value at the same invocation. Right for all these correct processes. It's a very interesting algorithm. And, and it, and you can see on the right hand side the bv broadcast. But there is a problem in this algorithm. The problem is that it lacks termination, which means that there is a possible infinite execution where the consensus algorithm will never terminate. And a simple concert counter example that we present relies on four nodes where you have T equals one which means that you have one failure in the system. And the rest and in the rest of the talk I will refer to T as the maximum number of figures you can have in your system. These failures are Byzantines right there are arbitrary failures. And you have this n minus T processes that invoke the common coin and because of Byzantine for common coin implementation you need to return the common coin as to return when you have n minus T invocation. And then the Byzantine participants which is the faulty participants that can behave arbitrarily, which can represent the hacker if you want will exploit the outcome of the common coin in order to slow down selected messages. And if he does so, then he can make sure that the correct participants there are three of them right because we have four participants in this consensus will move from having estimates 001 to estimates 110 and so on so forth. So they will just loop in this from one round to another well they will change their estimate from 001 to 110 001 110 and so on so forth. Right, so there is a case where there is this infinite execution and this is enough to show that the termination cannot be insured. The nice thing is, and I want to highlight this. There exists provably correct alternatives to this protocol, right. And one that is remarkable is that the same author came up with an extended version of this paper this algorithm that they presented in Journal of the ACM in 2015, and this alternative protocol as the same asymptotic complexities as the original protocol but solves the issue. There is also a paper by cashier and Zalini is Zalini that was presented at this, this year, like yesterday I think, and that also has a provably correct alternatives. The only thing is that I'm not aware of any implementation of this algorithm. So what we decided to do is we decided to create a blockchain that we call the red belly blockchain. And the first thing we did is we focus on the consensus protocol. We wanted to tolerate periods of a synchrony. So for those who know it's more like a partially synchronous model. Because we didn't want to have the vulnerabilities I've mentioned in the beginning. The protocol works as follows so it's very similar to the randomized algorithm, except that we got rid of the random coin. Right. So what we used is the parity of the round to make sure that we would break symmetry and that the protocol would converge towards a single estimate that will be decided by all the correct processes. Okay, so we really wanted that we needed it in order to reach consensus. So that was key. So we have a blockchain on top of this algorithm that we call democratic BFT, and we people, we published it as IEEE security and privacy this year. The BFT is scalable, and it actually uses the same technique that was presented in dandelion, which is the idea of super block optimization. There are a lot of proposers that are proposing their block but instead of trying to accept the leader block, you just aggregate all the blocks that were proposed into a super block. Right, and that's how it scale as you can imagine it, you know, it commits a number of proposals that is linear in the number of notes that participate. I know that we published this year. But this is great, right, and there are a lot of blotching that, you know, reach very good performances on the paper, or, you know, on blog posts or you know online, but how to make sure that the consensus itself is correct. Right, it could be, could be wrong and that might be the reason why we have so good performances. But that leads to this work. So I'm going to go quickly through the related work just mentioning that there are a lot of very nice ideas that have been that came up since 1999, for example, that consists of exploiting machine assisted proof in order to prove in a safer way. I'm not saying that these techniques are completely safe, right, or completely secure as even a model checker needs to be proven correct, but they reduce considerably the risk of having mistakes in the proof of the consensus algorithm. Right, so it reduces the risk of having double spend. The way we achieve. We did the model checking of our consensus algorithm is as below we use a threshold automata representation of our algorithm. So just to have an example, this is a very simple binary value broadcast. You know, abstraction, which is simply broadcasting some estimate, if you receive, if you receive t plus one estimates, the same estimate from t plus one distinct processes or participants then you re broadcast so it is very similar to reliable broadcast for binary if you receive to T plus one identical values from sorry, yeah, identical values from to T plus one distinct processes, then you deliver right it means that the there is a BV delivery, if you want. And so what we can do is we can represent this algorithm at the bottom that is a good explaining sort of code as a threshold automaton with nodes and transitions, right. So you have local states that are locked V zero log V one that indicates that the process is as come as an input value zero log V zero or input value one log V one. And then depending on what happened in the system, you update shared variables that are for example B zero, which is a shared viable that counts the number of zeros that are being broadcast in this BV broadcast algorithm. If the guard is true, then the action might be taken. Okay, so you have these counters that are shared counters updated by all correct processes as they execute as they transition through this automata, or automaton in this case, and there's only one. What you can see is that this automaton is symmetrical. So I don't need to care that much about one side, and I will just focus on the side where you have the initial value zero. Okay, nothing has been broadcast when you were in lock be zero. The zero value has been broadcast and nothing has been a baby delivered when I reached lock be zero. I will reach lock be zero one which means that both values and zero and one have been broadcastness, but nothing has been delivered yet. And the earliest moment where we can transition is upon reception of ones from F faulty processes and after B one once were broadcast by correct processes, and this is modeled by B one plus F, which is the actual number of failures is greater than T the number of failures plus one log V log C zero indicates that zero has been broadcast and only zero has been be delivered, both zero and one have been broadcast and only zero has been be be delivered in log be zero. There is a self loop that will indicate the a synchrony. Both zero and one have been broadcast and both have been be delivered when we reach lock C zero. So you can see that it's quite simple to model algorithm distributed algorithm in threshold automaton. So you can express a beefy justification which is one of the property of these baby broadcast using linear temporal logic, right, as follows, I won't go into the detail because I'm running out of time. And what we did is we did the same thing for a consensus algorithm we obtained is very large threshold automaton on the right hand side that we decompose we split it into two to automata one for the baby broadcast and one for the rest. And what we could do is we could do the formal verification using parametrized model checking thanks to the bison team model checker that has been published at purple 2017. And for that we formally verify the agreement validity and termination which are the three properties of the consensus in less than 18 minutes. Right so on an MPI cluster of course we needed a bit of resources to do so. We believe that formal verification of consensus is important for watching adoption in secure applications. So I just wanted how to prove the safety of the DBFT consensus algorithm used in the red billy blockchain. For the liveness proof, I recommend you to look at the follow up work with my colleagues. And which you can scan here and for future work we would like to leverage this formally verify consensus algorithms mark contracts in order to obtain a more secure sharing economy. So I'm going to talk about the the MOOC where I talk about DBFT in more details and the red billy blockchain, if anyone is interested to know more. Thank you for your attention.