 Hello everyone. I'm going to start by introducing our projects and then this will be followed by a really cool demo done by our partners. So first, this project is about securing membership and state checkpoints or proof of stakes slash proof of space blockchains by anchoring into the Bitcoin box. Okay. So first, let me start by giving some motivation behind the project. The motivation behind the project is that blockchains that are based on a reusable resource, for example, proof of stake or proof of storage, they are less secure than the blockchain that are based on proof of storage. We know it because there exists a lot of attacks that have been studied in the literature. For example, long range attacks or state leading attacks that have been studied a lot in proof of stage. And we also have found that similar attacks exist on proof of space blockchain. So I'm going to illustrate first a long range attacks so people understand what is the severity of the attack. I'm going to be giving all my explanation in a proof of stake context, just because it's easier to understand and to talk about. But as I said, very similar attacks would exist on like find coin, proof of storage, proof of space, but they are a bit more tedious to expect. So in a proof of stake setting, we have each block that is created only by what we call the validators. So basically, we have some validators that are going to, you know, one way of seeing it is that they're just going to sign the blocks. And then, you know, maybe like some value, the set of validator will change, some data will leave the network or the rejoin. And for example, here on my site, we see that we start with a set that is represented by this green check mark. And then later on, they have all left the system and you have new validators that are pink. So the attack that is possible in this setting is to have an adversary that corrupts the validator from the past. So in this case, the adversary, for example, will go and see the green validators, which are not in the system anymore. They don't care, they don't have money in it, they have cashed out. So the adversary will be like, hey, how about you sell me your previous keys that have absolutely no value. And, you know, because there are no value like that that should be easy to bribe people to do so. But the problem is that once the adversary managed to get the keys from the previous validators, because in this process setting, you don't need any resource, you only need keys to create blocks. What it means is that the adversary could use those keys in order to just create an alternative chain that is as long as the honesty, because creating blocks does not take any time. And even the adversary could pretend as if there were new validators that joined the system, for example, like there would be like orange validators in this setting. Because once you have the keys, you can basically do anything. You only need the keys to create a chain. So as you can imagine, this is a very problematic attack because all our users that have been offline for a long period of time and they will, you know, wake up, they can see two chains. And they know that, you know, in the past, the validator, the great validators were honest, but then they don't know which chain is the honest one is in the pink or the orange validator. And because like the two chains look perfectly valid, and the only difference between the two is the set of validator, there is no way of knowing of make what change is the is the right. So it's a very serious attack. And this has been like a very concerning attack in the proof of stake currency. Another attack, again, on the first take, it's called a power power bleeding attack. And the idea is that in each block, new coins are minted. And if you think of a proof of stake system, where your power depends on the amount of coins that you have, if you are an adversary and you create an alternative chain, then for each block that you create, you're going to be able to get all the minted coins to yourself. And basically, you're going to be able to inflate your stake much more than you should if you were not mining on an adversary. So this is a paper called stake bleeding attacks. So basically, in order to solve like this attacks in the proof of stake community, like the solution that is often presented is to have some form of checkpointing. So just even if an adversary managed to do that to change, to change, we have a checkpointing that allows to detect which is the ownership. And for us in this paper, so different paper gives different guarantees, efficiency and security and assumptions. But we will be using this paper that is called BMS, which was done by Marco and his co-author from IBM. And so I'm going to present it basically right now. So basically, this solution consists in relying on a blockchain based on a burnable resource, so for example, proof of work in order to secure the underlying proof of stake blockchain. And the reason to do this is because the proof of work blockchain, they are not vulnerable to the attacks I have just described because in order to create blocks, it takes time, it takes money, it takes computation, you cannot like, you know, just create a chain as long as you want in an instant of time just because you got some keys like that's not possible. So the idea would be to encode the proof of stake membership into the Bitcoin blockchain. So if we illustrated this way, we have our blue proof of stake blockchain and our orange Bitcoin blockchain. And basically, we will push like checkpoints to the Bitcoin blockchain such that we can use this checkpoints to verify which chain is the right one. And here, one difference that we have in comparison to the original BMS paper is that they were using the Ethereum blockchain to do this checkpointing, which has a lot of advantage because it has a very, you know, like extensive smart contract platform. However, because the Ethereum is moving to proof of stake, then this approach is not viable anymore because proof of stake is vulnerable to the exact same attack. So basically, our work is to implement this like BMS paper that was done on Ethereum, but do it on Bitcoin. And this is more challenging because Bitcoin doesn't have the same properties in terms of smart contracts. Okay, so I think the main question when we talk about the checkpointing to the Bitcoin blockchain is who is going to push the transaction to the Bitcoin blockchain, right? We don't want anyone to be able to push it because otherwise, obviously an adversary can push like wrong checkpoints. Also, we want this to be decentralized because we are doing a decentralized network. So we don't want just one person that is designated to just push the check. So what we are going to do is like we're going to have a threshold signing and basically the current validators of the chain will be the one responsible for creating the transaction and pushing it to the Bitcoin blockchain using threshold signature. We want to use threshold signature because we know that some of the validators of the chain will be malicious, but following the usual assumption, there will be only like a small portion of them. And so threshold signing should guarantee that the right checkpoints are pushed to the Bitcoin blockchain. Okay, so in this case, what we're going to have is that we're going to have the sets of validators that are represented by their aggregated public key, PKI, which basically is the aggregated public key that correspond to the threshold sign. And then what does the checkpoint look like? The checkpoint will look like a transaction from one set of miners from the PKI to a new key PKI plus one, which will represent the new set of miners because as I said in the beginning, we will consider that maybe the set of validators will change over time. So basically this need to be incorporated in the transaction and also a checkpoints that correspond to the state of the chain. So for example, you can see like the hash of the chain. This will be integrated in the up return code of Bitcoin. So as I said, the transaction will need to be signed by at least F plus one of the proof of stake miners, where F is correspond to the proportion that the adversary can get. We will use Schnorr's threshold signature, and especially we will use the Bitcoin tab foot upgrade that allows for Schnorr's threshold signature. So it means that we can do threshold signature in an efficient way. So again, basically this will kind of look like that. So here like CI minus one, CI inside plus one, they represent the configuration. So by configuration, I mean the sets of validator. So the set of validator will change from CI minus one then to CI, then to CI plus one. And this change will be translated in the blockchain by this like public key that will change. So configuration I minus one will do a transaction from PKI minus one to PKI. And then basically from this point on is that configuration I associated with PKI that will be in charge of pushing the checkpoints to the Bitcoin network and to update their key whenever there's new miners, new validators, sorry, that's calling the system. And the idea is that doing this basically any users that goes offline and then wake up will be able to go to the Bitcoin blockchain and follow the chain of transaction and be able to differentiate. Is it the pink or the orange validators that are the correct one? And then she will be able to use the Bitcoin blockchain to differentiate, which change is the correct one. So something else that we will have in our protocol is that, so as I said, we will add some data in the return of Bitcoin. And basically this data can then be used in conjunction with storage service. So for example, IPFS or even Fikern in order to retrieve information about the configuration. So it means that if a user like he's confused, doesn't have the right state of the blockchain has been attacked by an adversary, then they can find like the rightful identity of the validators using this storage provider, decentralized storage provider. And then this user, at least she will be able to ask the right person for the right chain and not be fooled by the adversary. So basically using IPFS or Fikern, we can ensure that any user has every data that they need to have in order to find the right. So the high level protocol works as follows. So it will happen like periodically. So first what we need is we need the members of the new configuration to generate their aggregated property. So this is done using like a distributed key generation algorithm that is compatible with Snore signature. Then once this key has been computed by the new configuration, what we will have, if you remember the scheme in my previous slides, we will have the current configuration. So configuration I will then push a transaction to Bitcoin that basically transfer whatever amount is on their key to the new key, PKI plus one. So you can think of it as like giving the membership to configuration I plus one. Now they are in charge of the checkpointing. And then some additional data that can be used to retrieve information about the chain, some checkpoints, and the identities of the course. And then this transaction will need to be signed using like special signing. And we use the recent PROS protocol to do this because it's quite like an efficient protocol. That's why we decided to use this. And then this transaction will be sent to the Bitcoin section. So before we move on to the demo, in case someone just joined, missed the beginning of the talk, here is a quick like explanatory scheme to understand what's going on. We have, you know, our proof of stake blockchain. And basically, we will have like periodically like when enough, when the configuration has changed enough, when enough new validators have joined, like we will have a new distributed key generation that will take place. And then we'll have a transaction that is put to the Bitcoin network that will effectively like change the key from PKI to PKI plus one, and also include some additional data that can be used in order to retrieve information about the current configuration. And so now we will give you a quick demo. So it's a kind of like small scale demo just to show how this work. And basically, this will happen on Udiko, which is the kind of like Lotus Playgrounds. And I'll leave the door to Lola, who has been working with some of her collaborators from Zontax on the demo. So I'll just stop sharing. So Lola, if you want to... Okay, thank you. Can everyone hear me? Yes, we can hear you. Awesome. I didn't ask, by the way, if there was some questions. Sorry, maybe before we start the demo. Speak now if you have some questions. Okay. Can everyone see my screen? Yes, we can see. Okay. So first I'm going to start the Bitcoin node. I'm running a Bitcoin node in Red Test node. So it's a bit faster. So what I'm going to do is I'm going to start free nodes that have a pre-configure key that I've already been generated before. So we can start checkpointing right away. And we are running Udiko on Dedicated in Mode. So we have one miner, which will be on the left side bottom of the screen. Okay. So we have the free node, which has started. You can see the eight. Here, this is a mining node. And every 25 blocks is going to do a checkpoint on this demo. So at 50, we should see something happening. So some communication here. So we have exchanges, messages between nodes, and we have the signature here that has been used to sign the Bitcoin transaction. And it has been pushed to the Bitcoin Red Test node. Okay. Let's see for another one. Okay. And here's a second checkpoint. Now I'm going to run a script that is going to start a new node. And they are going to verify this. So here it was quite fast. We can see we are synced. And we have a checkpoint and it gives us eight. So it can verify the actual, that's the checkpoint that he has retrieved in Bitcoin is actually fit his chain on Udiko. Now we can try to generate a new key with our new participants. So this query actually triggered a new actor generation. And here we can see the action of message. And here we have a result with new actors, with a new actor and new share. So that's the new configuration. That's a new configuration. Exactly. So here on the fourth node, we can see we, so it's doing the checkpoints, but it doesn't, it has, like the new configuration is not yet used. We need to sign one more transaction. And then we can, our new participant is going to be able to use his newly generated key to sign more transaction, right? There is always one step. And we should see it now here. Our new node that's participating into the signing. Okay, maybe I can stop the node. So for the storage, we are actually, for the demo, we are actually using a mini IO, which is a S3 bucket, not yet IPFS of icon. We can check and see that we actually, we actually saved our checkpoints. And we have the PRID of the node who signed this checkpoint that has been pushed to, pushed to Bitcoin. So here we see we are free. And we have our key set that has been used for the verification. And if I go back and I look at the last one, you can see that this time we have four, because we had four nodes, we have generated a new key, and we have four signer and with our checkpoint. So that's all. Okay, great. Cool. Can you give me back the, oh yeah, the sharing. Okay, I will just Okay, so let's see. Okay, so that was, that was pretty cool. It works. That's nice for, for demo, right? So again, what we saw with Lola was, so again, the blue chain was the UD code chain. So this kind of like Lotus playground where we had the initial validator like pushing this checkpoint to Bitcoin. Then later on Lola created some new, some new validators that joined. And then they did the distributed key generation. And then we had this kind of like of change of configurations of this transaction that was pushed onto Bitcoin from the, the initial key, PK0 to the new key, PK1. So we used Bitcoin REC test. Then as Lola showed, like not as in my slide, we didn't use IPFS all five coins for now. This will be done in the later stage of the project. We just use S3 to store all the information like needed for retrieving everything. So that was, that was pretty cool. I think that's the main thing that is missing from now. So first is like scaling as we saw with Lola, like we had like a relatively small network. So what we want to do next is first have this demo, but with much more nodes. So Lola is actually currently working on it. And we will be using Kubernetes in order to achieve this. But then there is also the kind of like theoretical work, even though we will have sooner demo using Kubernetes with much more nodes, there are still some theoretical limitation. And we are also looking at how to, to make our protocol more scalable on the theoretical ground. So for example, using some aggregations technique or using, you know, some new type of distributed signing, like this is an active, very active area of research for now. Also, as we saw now in the demo, kind of like everything worked well, every one was being honest and participating. And actually our protocol is designed such that even if we have a small fraction of the participants that fail or misbehave, like this should be detectable. And we should be able to complete the protocol even despite this failure. So this is also the next step that we will implement and that is already on paper. Also for now, we have used Bitcoin rec tests, which was, which was run locally for maybe the next demo, we will want to do it on this Bitcoin testnet. And ideally, maybe also have some nice like visualizations, so maybe have some kind of like Bitcoin explorer. So we can see the checkpoints in a nice format, although the terminal works as well, but it will be nice. And same for you, Nico, maybe you have some kind of like nice networks in how many nodes we have and the interaction, that's what we are watching. So that's it for now. And hopefully there will be more in the new year with everything that is on this list. Does anyone have any question or? I have one question. Yes. In this demo, did you implement the weights or is it just one one? One one for now. Yeah. So the weight is actually one of our biggest like scaling problem. Yeah, we discussed it, I think. Yeah, recently. So I have a question related to that. So actually, I'm going to send you a document that Nicola and I have been working on about specifically about the weights. Is there a, I mean, I understand that anchoring to Bitcoin is probably the best thing to do, but is there another proof of work chain that has some sort of more complex language in terms of transactions? Because we can come up with a pretty efficient weighted threshold scheme, but it's not snore, right? We create a new scheme, right? So if it were possible to anchor somewhere else, then we could use that one. Yeah, that was Marco, but we've lost you, Marco. I was already, can you hear me now? Yeah. No, I pressed the mute on, like, on our purpose. So it's still interesting. Let's understand what you guys have. Whatever can scale is interesting. It's very interesting. So of course, it would scale much, much, much, much. It would even solve the, the, the DKG quadratic communication problem. But yeah, let's, I'll send you the right. Yeah, let's, let's look at, let's look at that even if it's not snore, of course. I doubt that you could use, I doubt that you could use Ethereum for that, but let's look at it. Yeah, I mean, Ethereum is moving to proof of stake too, right? Yeah, yeah. No, I mean, so, so I mean, you're having Ethereum classic, another thing. I mean, they're not so the danger with those, the danger with those protocols is that their hashing power just won't give you enough security, right? So this is the thing with proof of work, right? Because it tends to, tends to converge to a single protocol. Like this is the tendency of the thing. So, but let's look at it. Let's, let's, by all means. Yeah, okay. Yes, yes, yes. Yeah, no, and just, just to add another word on this is that maybe something I haven't made explicit during my presentation is that in this work, we are kind of like, let's say, assuming that the security of the underlying like, like a proof of work change. So also, that was kind of like an argument in using Bitcoin, as opposed to, for example, I don't know if there was some, like, as Marko says, Ethereum classic or even some other like new proof of work blockchain, like the protocol is as secure as the underlying proof of work blockchain would be and Bitcoin being the biggest network and the one with the most hashing power that's in terms of security, that's kind of like one, one, one of the arguments in favor of, of using it. So that our security definitely depends on the security of the underlying proof of work, proof of watching. Did anyone else wanted to ask about the demo or the project or are we done? Okay, well, if there isn't any more questions, sharing and yeah, I mean, feel like, yeah, feel free to, yeah, feel free to, to get in touch with, with us with any, any other sets that you have, as you've seen, like we are actively, actively working on this and improving this. So any, any feedback is very, very welcome. And otherwise, have a happy holiday, I guess.