IBFT 2.0: a robust PoA BFT consensus protocol for Ethereum

Transcript

so we have the last presentation before a panel discussion and so let's welcome onto stage Roberto Sal teeny lead consensus protocol researcher at Pegasus and he'll be talking about I I BFT 2.0 a robust POA BFT consensus protocol for aetherium thank you hello yeah today I will be speaking about high BFT 2.0 well actually my objective is a bit more ambitious just just speaking about this protocol what I want to do I

want to use this protocol as a case study to outline how to actually design a robust consensus protocol but before diving into it let's take a step back and let's look at what ibs-d is so i BF t is a is an etherium consensus blue chain consensus protocol which falls into the category of the proof of authority consensus protocol so only a subset of the nodes called validators are allowed to to produce blocks into to create blocks it has a dynamic validator set so basically the set of validators

can modify over time validators can vote other validators in other nodes in to become validators or they can vote validators out it is Byzantine fault tolerant which means that we can cope with up to one third of the nodes being malicious and finally it provides immediate finality which means basically any block that is added to the blockchain is final and in other words there are no Forks so why is a BFT actually useful well we saw the talk before that was speaking about clique and aura and this type of proof of authority consensus protocol don't provide a Byzantine fault tolerance so actually I BFT aerated this family with

a consensus protocol that this Byzantine fault-tolerance property it is well-suited for small and medium-sized networks where or not all of the nodes necessarily trust each other you can think you can think of applying these two side chains or private side chains that are then back to the maintain and finally allows for a dynamic network as I said before the set of validators can change over time so his network grows as the more validators the more nodes you are the more organization entered into the network the more validators you can add so now you are actually ready to to explain how

ibs-d works essentially ability can be considered as running successive instances of the ibf d-block finalization protocol and the aim of which of each of these instances is to create a block which is implicitly final so you can see on you can see on the left inside the general age instance of the idft block finalization protocol the aim of that instance is to create the block for high height 8 so through a series of message exchanges the block is eventually created as soon as one

validate or more than one validator create the block the block gets propagated to the other validators and at the same time another instance of the idft block finalization protocol started at this time for the next height so height h plus 1 and again through another series of message exchanges the block with height h plus 1 is created and the protocol proceeded in this way and always adding blocks to the block chain but now let's look at how each of these instances looks like it's essentially pbft protocol + block locking which is organized into around the aim of each round is to create the block and the flip if the block cannot

be creating that round then a new round started and the it in this new round it is attempted to create the block the length its round as a prefix length the length is a exponential two round number so in this case we have the standard three faces of pbft we have a block proposal in this case is validator one which proposes a block by sending a pre-prepared message which includes a block all other validators reply with the prepare messages per per message a valid a toes receive enough pre prepare and prepare messages they will lock on the block included in these messages and if they lock they will only send messages for these blocks this is done because these

the objective of this is that if a block is created in any round we were the protocol wants to be sure that that's the only block can never be created in successive rounds the next stage is the next phase is the commit phase as you can see here the commitment studies are delivered after the expiry of the round timer so we go through a round change phase where at the end of this round change phase the block proposal is now validate or two again we go through the same same three phases and at this this time the block is actually created and so the and then then you are after this you'll have the next instance of the

ability block your initiation protocol so stronger power definition we can proceed a look at the journey the journey from I B of T to a 52.0 so there are a few steps the first step is to what you need to do whenever you come across a consensus protocol that you want to implement you need to look if there is a mathematical analysis of this consensus protocol it isn't what you need to do one and if you find issues well you need to find a solution to this issue and then you need to mathematically analyze your solution not only one if you are any one to be sure that what you are specifying is correct you need to be the formal specification

and run a formal analysis of the protocol but this actually will only allow you to show and to be sure that the protocol is robust that not enough you also want a performant protocol so then you have a performance improvement phase and at which then and then you repeat the steps from step number three again you do the mathematical analysis the formal specification basically until you are satisfied that your protocol is performant enough let's start from the first point which is actually as for main sub steps so to do a mathematical analysis you need a mathematical definition of the protocol then you need to define the system model so you define

which is the system in which we want to deploy your protocol you define what robustness mean and finally only finally you can actually perform the analysis so let's look at the so in this case in the case of IP of T there was no mathematical definition of the protocol so we did create one and then we define the system model when you define the system model typically you want to define three sub models the network model the failure model and the you want to define the properties of the cryptographic primitives that you are going to use let's look at the network model the network model essentially describes which is the maximum message latency on the network and you in

literature is generally have three main Network models that are considered yet the synchronous where you know the maximum message delay you know the value message it won't take more than that time to be delivered you have the synchronous one where basically the message delay is unbounded can be any value the values unknown and in this condition that is a prove the shows that no consensus protocol is guaranteed to terminate the deterministically and then we have the partially synchronous network model which can be divided in two sub modules some sub models the eventually delivery where basically you know the messages will be delivered there is a bounded

this is a bound of the message on the latency but this bound is unknown however it's constant and then you eventually synchronous network model basically we assume that there is a point in time called GST or Global Studies Asian time before this point in time the network is a synchros so you can lose messages but after GST the network acts synchronously and the model that we considered is this last one because it's the model that has the weakest assumption and then at the same time guarantees deterministically termination of the consensus protocol then you need to define the failure mode typically there are two failure mode

that are considered one is the fail stop failure mode where no that note that fails the stop sending messages and there is the Byzantine one where nodes can act maliciously again we chose this one because it's the model that has the weakest assumption or you can also say that is the one that has is the strongest failure mode fault model that's because we wanted to ensure that ibs-d is actually a protocol that performs in the wider possible number of cases and and is actually a general protocol so we didn't want to constrain the system to specific behavior we wanted to allow the the model to describe the widest possible number of environment condition

and lastly you need to define the properties of your of the cryptographic primitives that you are planning to use typically you use a collision collision resistant hash function you have a signature scheme which usually provides uniqueness and unforgeable 'ti before going to before actually doing the analysis there is something more you need to do which is to define what you mean by robustness in this case we relied on a definition provided by the vigor a at all which was provided when they did the analysis of the Bitcoin blockchain protocol and robustness in this case can be thought as a

conjunction of two different properties one is persistence persistence essentially says that if a validator creates a block at eight Heights another validator creates another block at eight right these two blocks must be the same not only there is another condition which says that if a validator adds a block to its own local blockchain then the block will eventually be added to the local blockchain of eronel any other validators and nodes and then you have liveness which says that if a transaction is sent to all validators well that transaction will eventually be added to the local block to the blockchain so strong of our system model and robustness definition we can proceed

to Dallas's so we did we discovered two interesting results the first one is that is that there is no optimal Byzantine fault tolerance the protocol doesn't guarantee opt-in or Byzantine fault tolerance especially for a network of size different from three plus one so different from 4 7 10 13 the Byzantine fault tolerance is not optimal and the termination is not guaranteed even if you consider that that only one validator my stop let's look at more detail into this result so the first one I give you an example you have a network of five nodes of I validate owes the optimal Byzantine fault tolerance in

this case is 1 but we see that the idft doesn't provide any Byzantine fault tolerance in this case so I B of T for a network of 5 validators consider the sense that basically it's enough for 3 validators to exchange messages we have a block finalized so what what can happen is that is the proposal proposal is malicious can basically clone itself and they can cooperate with two nodes to create block b1 and with other two nodes to create block b2 so we end up with two honnest node creating block b1 and to harness to the the other to harness node to create block b2 for the same heart so you in this way the persistence property is violated let's look at the

termination problem the termination problem is basically due to the locking mechanism so because of network latency some messages might not be delivered within a round I within the one the round number zero and so one of the proposal like v1 my lock on Block B on block b1 and then you have around change at this point and you proposal which is v2 it's not a lot so can propose whatever block it likes in my proposed block let's say b2 which is different from b1 and then at this stage this at this point the network is or synchronous so all three all three will lock on the same on the same block and

then eventually one validator stops and basically you are left with the maximum of two validators to be locked on the same block and considering that you need a minimum of three validators to agree on the same block to produce new blocks you end up in an innocent a sort of deadlock situation so we found two issues and now we need to identify a solution so for each of the issues identified basically what you need to do you need to identify the missing code properties if you see that there is more than one solution where you need to evaluate the pros and cons of each solution and then actually select one so let's look at the persistence issue what

we identified is that let's say the Q is the minimum number of validators that are required to collaborate in order to create a block if you can guarantee that any two set of cube early data always intersect in honnest validator then persistence can be guaranteed so this led basically to modifying the formula for calculating Q from the old one to the new one which is basically a sailing of two-thirds of the nodes just to give an idea basically this formula says that there is no change for a certain number of validators set but there is a actually for some numbers like 5 6 8 9 the number of validators is increased by the minimum number of validators is increased by 1 and this

this solve the persistence issue but we are still left with solving the liveness issue so as I said before the liveness issue or termination is caused by the block locking so essentially you have two solution attend one is to allow relocking so you can allow relock on a different block and this hood will prevent a deadlock that we saw before but you need to be careful you need to be allowed relocking only third if you can be sure that the old block had never been created before otherwise he can end up in a vibrating the persistent persistence property that we defined before and that the solution is actually to remove the block locking but then you need to add more information to the messages to be

sure that if a block is created in in one round that's the only blocking that can be proposed in any successive round so we found the first solution is kind of more based on it's an alignment with tender mint the second solution is more in alignment with pbft so we have two solutions and now we need to evaluate the pros and cons of the two so the pros of the first solution is that when there is a round change phase the size of the messages is molar the price of the second solution is that it's actually possible to reduce the minimum number of phases from three down to two which actually it's actually means that you can improve the block latencies by one thought and he also in the second

solution also ensures a quicker recovery from us from a bad situation where you have a malicious validator or the network is unstable so in this case we have two solutions we need to select one we decided to select the second one and that's because our specific use case is to consider networks where typically was more medium sized network were typically nodes trust each other the network is synchronous and while we want to be a robust to a malicious node or a synchronous network we want to optimize for the standard condition which is all validated honest and the network is synchronous so the next so I just want to align the preferred solution

remove the both locking and we move the we had the pre prepare and prepare messages to the round change message and also had the round change message to the pre prepare message of the rounds higher than one and this basically in this way we can achieve both termination and persistence the next step in in on our journey is the mathematical analysis we did that the paper is not published yet the steps of that after this one is a formal specification and for analysis of the preferred solution we started our work using TLE Plus still under in still a work in progress so there is still work to be done on this on this front and this basically leads us to obviously 2.0 as

it is currently implemented in pencil but they said before robustness is not everything we also need to care about performance and this is where what I call IB ft to point task comes into play there are two important improvements the first one is I mentioned that before it is reducing the minimum number of phases from 3 down to 2 this is what I call very low block latency and the other one is about reducing the message size let's look at the first one so the first solution is based on the paper best-case complexities of a synchronous consensus from duty at all and in the condition where all validators are honnest and the network is synchronous you can actually

create a block after - only two phases and this is a pretty standard condition for our use case otherwise if this condition is not met and met then the protocol degrades gracefully to the previous condition so you mean - the 3 phase condition so graphically this is a BFT 2.0 and this is what the improvement allows allow us to basically decrease the late network latency the block lattice is by 1/3 I think is a very important improvement that cannot be for example applied if you had chosen the tender mint like solution now the problem is the message size which is the problem where as we said before the round change message requires to have a number of pre prepare and prepare

messages equal to the to 2/3 of the number of the total validators so in a network of 4 validators we have a 3 between pre prepare and prepare messages a deterrent to the round change messages and you have 3 around change messages added to the pre prepare message for round one how could we can solve this well we can take advantage of the property of the gossip network where if a messages that is a one-semester dis received is image immediately gossip to all to all of the other peers which means that if a message is received well then it's immediately transmitted and broadcasted to everybody else and is basically something that the mineralized zone so by bringing this in we actually bring some of the pros of

tendonman that we lost when it shows our PBT like solution and you can actually achieve the best of both worlds so in our example whenever round change messages received is actually immediately transmitted broadcasted to everybody else so we don't need to add the round change messages anymore in the pre-prepared message we can just add the hashes that is as important because we need to identify which of the four round change messages that we might have received we need only to select three we need to identify which of these three messages we are selecting the second the second improvement is basically having aggregated signatures in the round change messages to reduce the size of

the round change messages and with this one we basically completed our journey well actually not really there should be we should go back to the third stage but while we leave it we leave it for today I will actually go more in more details and this on the workshop you nest up your Monday on protocols and formal method I will ever more in that presentation on the same topic just a few links habibti 2.0 in Python the twitter handle for pegasus myself the p 650 where i BF d was originally described the correctness analysis our connect correctness analysis paper where we describe the issues that i presented here and the scatter solution and then

uh knowledge meant to that can organizes pegasus and take for the for wrapping with the diagrams thank you so what are the next things for your research and sort of what's in your purview so the next step for us is basically to go through the formal very to go through the formal verification process of the protocol and then to integrate the improvement that i've outlined and eventually to actually standardize the protocol so collaborating with other partners with other clients in the ecosystem to ensure that the protocol is

implemented by other clients so that we can achieve interoperability and we can build we can we can basically rely on multiple clients being deployed on on on this type of a network that's basically the the next step great thank you