 Our next and final speaker for this session is Sarah Azubi who is a consensus researcher here at Protocol Labs. Sarah will be discussing securing membership and state checkpoints of BFT and proof of state blockchains by anchoring onto the Bitcoin blockchain. Sarah. Thank you for the intro. Hello everyone so I'm going to present a project that we are working on at Consensus Lab. Let me start by giving some motivation behind the project. The main motivation is that blockchains that are based on a reusable resource such as proof of stake or proof of space, proof of storage, they provide less security than those based on proof of work. We know this because there are a lot of attacks that have been discussed widely in the community. So for example, the long range attacks, stake building attacks, there's also grinding. So generally people, it's quite intuitive that this type of blockchain are less secure than the proof of work blockchain and also similar attacks as long range attack and stake building attacks also exist in the proof of space setting. So just to make sure that we are all on the same page I'm going to illustrate what is a long range attack. So the idea behind the long range attack is that we have a set of validators that are responsible for maintaining the proof of stake chain. But after some time this validator they will leave the system and other validators will take over that's like a natural like dynamic committee committees. In my slide we start with the green validators and then later on we move to the pink validator. What can happen is that an adversary will be able to corrupt the past keys. So the green keys. And the idea is like these keys at the present moment they have no values because you know all the money that was associated with these keys. They have been transferred that have been cashed out. So really like they are worthless so the adversary could get them for nothing. And what's problematic in the proof of stake setting is that creating a block is cost less and instantaneous. So with this case, the green keys the adversary could just like rewrite the entire history of the blockchain. And for example the adversary could also like simulate a change of committee like, you know, end up with like an orange committee. So we can see that these attacks are very problematic, because if we have some user, at least that has been offline for a long time, she will wake up come back online and she will see those two chains that looks both perfectly valid. And there's no way of telling which one is the right one, because they both look perfect perfectly. So the attacks that I'm going to mention quite quickly are power bleeding attack or stake the bleeding attack in the context of proof of stake. And in this case, the idea is that with each block that is minted, there are going to be new coins that that are going to be created so which sorry which is blocked each block that is created new coins are going to be minted. So the adversary will be if the adversary create a private chain an alternative check, then all the rewards are going to come to itself, and the adversary will be able to use this as its advantage to also be able to create a very long chain. This was originally proposed by this paper by Peter Gazi and his course. So yeah so that's just to mention two attacks in two series attack in the proof of stake setting. So one solution that has been widely discussed in order to solve this attack as the name of the session suggests is checkpointing. So they have been many paper proposed each proposed different setting different efficiency security guarantees and assumption. And in our case for this project, we are going to focus on this paper that is called BMS, and that was actually a co written by Marco and he's course or from IBM. Okay, so now let me start by presenting the intuition behind the solution. The intuition is to rely on the blockchain that is based on the burnable resource in order to secure the underlying proof of stake blockchain. So for example, the idea would be to rely on the proof of work block chains, blockchain, which does not suffer from the common attack that I have discussed. So what would happen is that we would anchor the proof of state membership and change points into the Bitcoin blockchain. So basically this is what this will look like. You can think that periodically there are going to be some blocks that are checkpointing so the checkpoint is sent and included in the Bitcoin blockchain. And we can assume that the checkpoint is going to contain the state of the chain, as well as the memberships membership of the proof of stake system. Like the idea is like here, the Bitcoin blockchain will really serve as a source of truth, right, because it's not vulnerable to long range attack. So everyone will be able to check the checkpoint on the Bitcoin blockchain. And very quickly, I'm going to mention that in the BMS paper that I mentioned previously, they do this model on a Serium, which actually doesn't really work. We will not work in the future because the Serium is planning to move to proof of stake and proof of stake are vulnerable to attacks. So basically this project consists in adapting this BMS paper in the Bitcoin city. So how do we do this? How do we do this checkpointing into the Bitcoin blockchain? And one of the main question that we can ask is who pushes the transaction, right? Because we need to ensure that the checkpoint is valid, not everyone can just say, oh, this is the checkpoint, obviously. And also we want it to be decentralized. We don't want to have like one party that's just updated checkpoints, you know, like, for example, the developers of the proof of stake, because that's not like decentralized enough. And we want to have a decentralized solution. So spoiler alert, we're going to use a threshold signing in order to do this checkpointing. And so the checkpointing is going to be done by the current validator, so the current members of the proof of stake system. So let me again illustrate the solution. First we're going to have an aggregated public key, PKI, that's going to be associated with the set of validators of the proof of stake blockchain at that time. So we call that set like the configuration and for example configuration. And then what's going to happen is that this aggregated public key is going to be the one that's like control the checkpoint. And so the transaction in the Bitcoin blockchain will come from this public key. And will include the checkpoint in the form of an opcode that's detailed, but basically it will include the checkpoint. And also on top of including the checkpoint. And this transaction will send all of its amounts to a new public PKI plus one and this new public key, it is meant to be controlled by the next set of validators. So basically this is how the change of membership is updated on the blockchain. We go from one aggregate, a great key to the other. So the transaction will need to be signed by at least F plus one minors, where F is the, you know, a number of adversaries so this is just because we don't want an adversary to be able to, to push a fake checkpoint. So we are going to leverage the taproot upgrade that is coming to Bitcoin in November and so we are going to use snore threshold signature in order to do this. So again, let me illustrate this. So here we see that the configuration I minus one will update the public key on the Bitcoin blockchain from PKI minus one to PKI. And later on the new configuration CI will do again the update from PKI to PKI plus one such that, you know, really we are rolling and, and the current configuration is in charge of pushing the checkpoints. So the idea is like now if we go back to the long range attack, at least Alice, she will see those two chains. And what she's going to do in that case is she can go to the Bitcoin blockchain, and then she can assuming that she knows PK zero. Follow the chain of transaction, find PKI, then she will have access to the, to the checkpoints like PKI is also a way to identify who are the right validator so basically using PKI she can decide is it the pink chain, or is it the orange chain, that is the correct one. In fact, we actually do even more than this. What we do is that we can on top of this use decentralized storage service, such as IPFS or Filecoin, that is going to keep the all the information about the configuration, such that basically Alice can just use the checkpoints to to recover all the information about the current members of the proof of state system. And so she knows where, where to ask for the, for the right chain. Now let's get to the high level protocol. So we assume that the protocol is going to be triggered periodically. For example, you know, once a day, or, you know, after, after some minutes. And then first what we need to do is that we need the new members of the members that are in the new configuration to create their key PKI plus one. So what's going to happen is that we're going to have a distributed key generation algorithm in order to first determine this key. And then we're going to elect one participant to create the transaction from PKI to PKI plus one, and also include the checkpoints. And then we're going to have the threshold sign in protocol that needs to take place. And at the end of this threshold sign in protocol, the transaction is signed and the leader can send the transaction to the Bitcoin blockchain. So that's the high level. One big question when we see this protocol is what's what threshold signature scheme should we use. There are many of them. There exists some multi six some thresholds thing that's gave different warranties have different properties. So for now, we have chosen first, which is quite a new new protocol that was proposed for efficient snore threshold signature. So the idea behind first is that it's optimally efficient. So assuming that nothing bad happens. And then the protocol is quite efficient. However, it also has the drawback of not being robust. So if we have one participants that misbehave or that abort, then the protocol cannot complete. However, misbehavior is detectable. So what will happen in this case is that we will remove the misbehaving participants and start again. As you can see, this is not the most scalable special sign scheme. So some ideas in order to help the stability because really free thinking about proof of state system or proof of space system. There could be like 1000 thousands of nodes. So what we could do is like pseudo randomly elect a subset of nodes to do the to do the signing instead of having everyone do it. This is an idea that was first presented in Algorand. There's also a paper called Smith thrill that presented a special signing that uses district. So one thing that we are limited by is that we want our special signing scheme to be Bitcoin compatible. So for example now there are a lot of special signing that use BLS that are very scalable, but to us they are useless because we cannot, you know, use the transaction on the Bitcoin blockchain. Bitcoin doesn't recognize BLS basically only on the store. So basically this is a work in progress. So we, we are happy, you know, there's a Q&A just after so we are really happy to to discuss this with you. So just to conclude, this is the end. The idea of this project is to anchor a proof of state of proof of state checkpoint to the Bitcoin blockchain to use threshold signature and to leverage taproot. We are thinking about using something to help with scalability. And we are really happy to share your ideas if you know schemes, signing schemes that are good to use feel free to reach out to me. And I think, and yet there's my email address and my Twitter so feel free to reach out to me and I'm looking forward to the Q&A. Thank you.