 Good morning everyone. I think I'll get started and if other people walk in we'll hopefully they'll be able to catch up. So today's first talk is going to be on sidechains and proofs of proofs. You've heard about some of this by Agalos yesterday, discussing sidechains sort of all those fellows, proofs of proofs of work, proofs of proofs of stake. So I'm going to go into a little bit more depth about what these are. So this is a collaborative work. The side chains paper we are preparing now is with Peter Gasly and Agalos and the previous paper on proofs of proofs of work is something we have with Agalos and Andrew Miller. So what you're going to see here is collaborative work taking from both of these works. So this is the outline of what I'm going to talk about. It's basically two parts in the talk. The first is going to be about side chains in general and then the second part is going to be about proofs of proofs and specifically proofs of proofs of work. The first part of the talk, the side chains, I want everybody to be able to understand it. So you don't need any special knowledge, any technical knowledge. It's not going to be technical. So everybody should be able to follow. So if you have any questions during that part, feel free to ask. And then the second part, I wanted to also give some details for the technical people that have some knowledge of cryptography. So it's going to be a shorter part. I'm going to go into some technical details. Hopefully everybody will get a gist of what this looks like in general, but maybe not every technical detail. So don't worry if you don't follow everything. All right. So let's get started. So for side chains, that's the history of it. So in 2014, it was proposed by some people who are now mostly on Blockstream. So it's Adam back, Mark Friedenback and Andrew Miller and so on. They brought this paper called Enabling Blockchain Innovations with Peg Side Chains. And that was a high-level overview of what they wanted to achieve with side chains, the idea of what it is, which I'm going to go to immediately, but they didn't have any technical details of how to do it, and especially not for Bitcoin. Okay. So what is a side chain? We have here two blockchains. One is Bitcoin. One is Ethereum Classic. And they have two Genesis blocks that I have there with green. They're separate blocks. And these blockchains are, both of them are independent. They are standalone. And they are separate systems that work on their own. Now, the idea is that sometimes you want them to communicate. So I'm going to be using the Bitcoin example throughout these slides. Unfortunately, Bitcoin is unlikely to be able to work with these schemes. So take it with a grain of salt, because maybe it needs certain updates that Bitcoin is not willing to do. So let's see what a side chain is. Now, the blockchain is growing. So blocks are produced. Of course, maybe not at the same rate. It doesn't matter. And at some point, a certain event happens within the Bitcoin blockchain. Now, blocks keep getting produced, and that event is eventually confirmed after enough blocks are put upon that event. And then we want the Ethereum Classic to be aware of that. So the Ethereum Classic will learns about that event, and that event that happened on the Bitcoin blockchain becomes available to the Ethereum Classic blockchain as a piece of information that this thing took place. And then this, of course, also this gets confirmed. And the Bitcoin Classic blockchain here can react to that event. So it can have an action that is the result of an event in the Bitcoin blockchain. And if you're familiar with these systems, you'll notice that usually smart contracts are closed systems. They can't really interact with the network. They can't go on a website. They can only look at blockchain data. So this is something new, right? And the question is, how do we really do that? So there's two blockchains in the scheme, the source blockchain and the destination blockchain. The source blockchain is where the event happened here. And the destination is where we want to react to this event. And depending on the use cases, the same blockchain could be both a source and destination blockchain. So you could have also an event in the Ethereum Classic happening and Bitcoin reacting, for instance, right? So these roles can switch. And also another thing is that here I have just one event noted. But it's not impossible that you'll have multiple events going on in parallel. So multiple things happen on the Bitcoin blockchain. These events are propagated to the Ethereum Classic blockchain. And there's multiple reactions occurring at the bottom and vice versa. So this is just, I'm just giving you one event, a snapshot of one event to see, to study what's going on. But of course, there's going to be parallel events happening. All right. So for supporting these block chains, these side chains, we need certain features that we don't yet have in all blockchains. So one of them is about the source blockchain. We need, depending on its type, whether it's a stake blockchain or a work blockchain, we need something called proof of proof of work or proof of proof of stake. And we can likely build these. So this is going to be the second part of the talk. We know how to make proofs of proofs of work. And I guess I was working also on a proof of proof of stake scheme with Peter, right? So this is also something that's being worked on. And then the destination blockchain, it has to be smart. So it has to be able to run some code that can do a certain amount of verification. So we're a bit limited on what blockchains we can use for this. If we look into the situation right now, there is no serious support for side chains. There is no implementation that really works. There's maybe a few things. There's a drive chain, BTC relay, maybe a couple others, but they don't really work or they have security issues that are very serious. And in order to make it work, it's not sufficient to know how to build these proofs of proofs or to have smart contracts. We also need to start including certain pieces of metadata into the source blockchain. And this can be done with a series of different forks, so either hard fork or soft fork, or a new concept that we call a velvet fork. And the bottom one, the velvet fork is the least disruptive of these, and it can be user initiated. So the nice part about velvet forks is that users can do them. We don't need minor approval to do them. And hopefully, we will start in actually next week, we will start injecting this metadata into the Litecoin or the Bitcoin Cash blockchain just to experiment. So this is something we have planned. And then the destination blockchain, if it has smart contract support, it should work in principle. But the difficult part is that these algorithms to run within the smart contract, they can get quite complicated and gas heavy. So sometimes it may require some of the primitives of the smart contract to be implemented in the virtual machine itself. All right, so let's look at what kind of events can be supported and reacted to. So some of the events are here, I have some examples, but really you can react to anything that you would be able to react if it was your own blockchain. So if you're writing a smart contract for Ethereum Classic, and you can react to some event that happens in Ethereum Classic, a similar event that happens to Bitcoin, the source blockchain you can react to. For example, I was paid, a particular block was created. A certain account has a certain amount of money, or some money was moved out of an account, or a certain smart contract was executed. So these are kinds of things that we can react to on the destination blockchain. When things happen on the source blockchain. So that's, yeah, those are some things. In general, there's no, there's no particular limit. Like if it's part of your application layer, in a local blockchain, you can you can do it in a cross chain as well. So the challenge is, as I said, that miners don't really monitor block both blockchains, right? So if you have a miner that's running on Ethereum Classic, it doesn't really know about about Bitcoin, it can't go to the Bitcoin blockchain to learn what's happening. It only knows its local state. So the question is, how do we isolate these two networks, but still be able to verify that everything's okay here? And the way to do that is we do proofs of proofs. So what is a proof of proof? A proof of proof is takes this thing, which is the source blockchain, it looks at some event that has happened here, it has been confirmed. And then any full note that has this state locally, can take the local ledger state and compress it into a single piece of text, a small piece of text that we call a proof of proof. So what is this? This is a proof that this event happened, doesn't matter what it is, within the Bitcoin blockchain. And this thing, if I show it to anyone, they can look at it and be sure be certain that this event took place in the Bitcoin blockchain without interacting with the Bitcoin blockchain. So that's the key component that allows us to do this kind of isolation. Okay, so here is the protocol. So initially, Alice sees that this event has happened on the Bitcoin blockchain. So for example, Alice could make a payment, could initiate a payment herself on the Bitcoin blockchain and waits for it to be confirmed. Now, once it has been confirmed, Alice will generate this proof of proof. So for Bitcoin's case, it's a proof of proof of work, and then includes it in the destination blockchain. So it's put within that block. And then that's also waited to be confirmed. And then that can cause an event to happen on the target blockchain, depending on your smart contracts rules, right? So the smart contract within the Ethereum Classic blockchain here would be able to take that string, that proof as input, look at it, validate that it looks okay, validate that it's actually a true proof of what happened, an account of events, and then react to it in the way that the smart contract developer wishes. Okay. So some applications. The the obvious one, I guess, is atomic swaps. So this is perhaps already possible with other means, but this is one more way to do it. So the idea here is that Bob holds some Bitcoin, Alice holds some Ethereum, and then they want to exchange it, but nobody wants to transfer first, right? So how can we do that with with side chains? Well, one way is just to create a smart contract within the Ethereum blockchain, that waits for a Bitcoin transfer to happen on the Bitcoin blockchain. And once that happens, react by paying on the Ethereum blockchain. Okay, so the way that will work is if if Bob has Bitcoin, Alice has a theorem, Alice creates this Bitcoin address that she wants to receive the Bitcoin into. And then she also creates a smart contract paying her a theorem into that smart contract with a time lock, let's say, of two days, right? And then that smart contract has a rule that if Alice's account is paid on the Bitcoin blockchain, a certain amount of Bitcoin, it will release the amount of ether that Alice has locked into the Ethereum smart contract to Bob's address. So now Bob seeing this, seeing that the smart contract has been created and is confirmed and contains his address, pays into Alice's Bitcoin account with his Bitcoin on the Bitcoin blockchain. And then the the smart contract on the Ethereum blockchain releases Alice's Ethereum to Bob's address. So this is nice because it's atomic and they can exchange these coins at the same time, right? So this one application. Now, another application we're working on, and this is an implementation we are actively writing code on right now is to enable one way pegs. So I'm going to explain what these are with an example, a remote ICO. So here's the idea. It's possible that investors hold money in certain different blockchains like Litecoin, for example, or or Bitcoin in this slide, right? But they want to buy a certain tokens in the Ethereum blockchain, because it's a smart blockchain that enables the tokens to have all of these features. Interestingly, they don't really want to go to an exchange and pay the spread or pay the pay the volatility and so on. But they would like to be able to just immediately pay in Bitcoin and receive the token, right? So this is something that's possible now. And then the way the protocol works is that the company that's fundraising creates the Bitcoin account in which it will receive the funds. And it creates also a smart contract on the Ethereum blockchain. Doing the ERC 20 token creation. And then whenever somebody pays with Bitcoin into the company's account, then that person paying creates the proof of proof, and then puts it into the Ethereum smart contract to receive their fair share of of company tokens. And so that way it's possible to do ICOs in a smart contract blockchain with a unit of account that lives on a different blockchain. So this I think this will be very interesting to the community once it's possible. Now moving on to two way pegs. This is a natural extension of the one way peg. So in the same way that we moved basically payments from the Bitcoin blockchain into the Ethereum blockchain. Now we can try to move them back. So if both of these blockchains are smart enough, which which Bitcoin isn't, but let's just go with it. And then you can move tokens first from Bitcoin into Ethereum, and then back from Ethereum into Bitcoin. So in the first case, the Bitcoin blockchain functions as a source blockchain and the Ethereum as a destination blockchain. And in the second transfer, the destination blockchain is Bitcoin and the source blockchain is Ethereum. Okay, so let's let's look at what's happening here. So suppose we create a special account we call x within the the Bitcoin blockchain, and a special account called y within the Ethereum blockchain. Now we create within a theorem classic, we create this token that we call BTC 20. Now I will argue that BTC 20 are basically for all practical purposes, the same as Bitcoin. So they have the same value. And and they would be traded at exactly the same rate as Bitcoin itself. Now here's how it can work. First, when every whenever anybody is paying into the account that we call x within the Bitcoin blockchain, we have a smart contract in Ethereum, creating this ERC 20 token called BTC 20, and giving it to them handing it to them. So note that this is just a Bitcoin transfer. It's nobody has a theorem, right? But once you put money, Bitcoin money into the x account, you suddenly have BTC 20 tokens in the theorem blockchain. Now, anything that's within the x account cannot be spent. So it's not like somebody owns the keys to that account and can spend it. It's not owned by by company or an individual. But the the only way to spend a money that has been transferred to account x is to move BTC 20 tokens into the y account. Okay, so once you move BTC 20 into the y account, which is a transfer on the Ethereum classic blockchain, then those BTC 20 are destroyed. And you are given the similar value or the exact same value from the x account on the Bitcoin blockchain. So what we have done here is basically we've taken a Bitcoin, moved it to the Ethereum blockchain, and then moved it back. So let's see this in pictures. We have these two, two chains. You have here a Bitcoin, you put it to some account x that lives on the Bitcoin blockchain, nobody owns it, right? You create a proof of proof. And that gives you a BTC 20 token on the Ethereum blockchain. Now, you can trade this as a regular BTC 20 token, you can have fast, cheap and smart transactions. And then you move it to the y account over here, which just destroys the ERC 20 token when you move it there. But by using a proof of proof on this destruction, you can unlock that Bitcoin from the x account that it was originally placed into. And the person that's doing the original deposit to account x could be different from the person doing the withdrawal from the account x eventually. So it could be different owners, you could split it up and so on. That's all fine. So while in the Ethereum classic blockchain, we were calling it a BTC 20, because you can always turn it into a Bitcoin, it's really worth one Bitcoin. So it retains its asset nature. Okay, so here's the picture, right? At the top, you have BTC that's moved into a special account x and recovered from the special account x. And then at the bottom, you have the BTC 20 token that's exactly equal in value. And it's only created and destroyed based on these events, right? Yeah. No, no, no, it can be split. And you can you can transfer some of it back. So if you say you move 10 Bitcoin from the top to the bottom, right, then you pay your rent, right? So 0.1 Bitcoin. And then that the property owner can move that 0.1 Bitcoin back and receive their proportion from the locked amount. So the locked amount count x is collecting all the amount that has been deposited by all people and can unlock a certain amount, whatever was basically destroyed on this portion. So during the destruction, it records how much was destroyed and who is the rightful owner to receive it on the other side. And then you can receive that portion. Yeah, so it's completely divisible like a regular Bitcoin. Any other questions about this? Alright, so let's go to Cardano. So Cardano, the plan for Cardano is to have two layers, the settlement layer and the computational layer or contract layer. And these have different features, right? The settlement layer is the dump blockchain. It doesn't sound very nice, but it's actually a good property. Because it's, its features are limited. So we can argue about its security properties. The code base is certain amount and we can look at it and hopefully have some provable security on it, some audits on it and so on. But the computation layer has true incompleteness, which the settlement layer doesn't have. And all the nice things of the computation layer come with the cost that the code base is increased and the surface area of attack is potentially increased, which means that it cannot possibly be as secure as a settlement layer because just the code will have to be much more, much bigger, right? And this is similar maybe to Bitcoin versus Ethereum. Bitcoin has this like orthodox approach that we have only these limited features. We are very secure, but we don't add any new features. Ethereum is like innovate quickly, do all these things. Cardano is trying to do something that will preserve both of these. But then you need to separate the two chains. So in Cardano, these are going to be two separate blockchains and they're going to interface with each other using sidechain techniques. So this is how it's going to look. You are going to have EIDA on the settlement layer at the top. That's where EIDA is created. That's where EIDA is stored. That's where EIDA is kept, like today, right? And then when you want to do a computation in a smart contract like have a DAO or have a complex condition or a DAP, right? You can move it to the computation layer and then that asset can live for a few blocks in the computation layer and when you're ready, you can move it back. So the idea is that you can use the settlement layer as your store, your savings account, and the computation layer, you can use it as your current account, which has more features and it's, yeah, it's feature-rich, right? So you can maintain both the safety for your funds that the settlement layer gives you, which is really simple, and then also have the features of the computation layer. Hopefully both of these will be very secure and they're going to work great. So some of the challenges here in the Cardano blockchain, one of the issues is that the computation layer, when it will be created, when the genesis of the computation layer is computed, people will not have taken it. They will have stake in the settlement layer. So the question is then, how can you maintain the security of the computation layer if it doesn't have any stake? If it has very minimal stake? The problem would be an adversary could move some funds to the computation layer and then use that stake to disrupt the execution of that computation layer and breaking its security. So we want somehow to inherit the stake from the settlement layer to the computation layer and say that people, based on their ADA stake on the main chain, somehow we want them to inherit staking rights on the computation layer so that we can bootstrap this system in a safe manner. So this is ongoing research with Peter and Agalos. And then again, like before, ADA is the home asset of the settlement layer, but it can be moved around. The Cardano computation layer doesn't have its own coin. So in a similar way as before, you can think of ADA and ADA20. It's exactly the same token, essentially, because it's two way pegged. But a token living in Cardano computation layer is by nature a different asset than the asset living on the settlement layer in the sense that it has a different lane. It's on a different blockchain. But on the other hand, it's also the same asset because it has the same exact value and you can always turn it back. Right? So the Cardano computation layer is interesting in that it doesn't really have its own coin. It's not a standalone blockchain as before. It's only created as a side chain and it was always just meant to be a side chain. Now, one of the really, really nice properties about side chains that I like is the firewall. So the firewall says that if there is a catastrophic failure in the side chain, we are able to provide still some security properties on the main chain. So what that means, what does catastrophic failure mean? It is to say that perhaps the side chain was completely destroyed. Right? Somebody was able to create an infinite amount of money. Somebody was able to subvert the security features of that chain, take majority stake and do something bad and so on. Right? We don't want that bad event to affect the main chain. So hopefully both of the chains of Cardano will be very secure, but just in case something very bad happens on the side chain, we can still provide security properties on the main chain. And the way that we do that is we limit the amount of money that can be moved back from the side chain to the main chain to the amount that was moved out. So even if the side chain can create an infinite new amount of money, we will not allow it to move it back to the main chain. So the main chain will be secure in the sense that it will do some accounting and it will know how much money has moved out of it and how much money can be moved back from that particular chain. Okay. So one of the other visions is to have distant side chains in Cardano. So to be able to interface with other existing blockchains or new blockchains. So here's an example of Cardano interfacing with Ethereum Classic. Of course, none of this can happen yet, but this is open research, right? The idea here is that in the same way that we did before, you can move Ethereum Classic tokens into the Cardano blockchains and they can retain their nature as a theorem classic tokens, be moved around, use all the nice features of Cardano, and then eventually you can also move them back to a theorem classic or not. You can keep them on the Cardano blockchain. And hopefully also vice versa, you should be able to move Ada from the Cardano blockchains into the Ethereum Classic blockchains. Now, what exactly, which of these exactly we're going to do is business decision, but the technology is there to allow this kind of asset transfer. So what this achieves, if you think about it, is it disassociates the asset from the blockchain. A different blockchain can be used to contain any asset from other blockchains. So that's how it looks like. And then another idea that is very exciting is that these distant sidechains can also be more traditional systems. So it could be maybe a permissioned blockchain. So personally, I'm very against permissioned blockchains. I hate them. But the system uses permissions, right? That's the way it works. So you may want to interface with these. If somebody has Ada and it's stored in the Cardano blockchains, that's going to be a decentralized blockchain. So for me, I'm just going to keep my money there. If somebody wants to interface with a traditional legal system, and wants to put their money into a permissioned blockchain, then they can do so by sidechain interface, and then potentially satisfy regulators, or be happy with, make banks happy with satisfying laws and so on. And this could be, this could be opt-in. This will be opt-in if we ever do it for the person moving the money. And then on that traditional blockchain, maybe a private blockchain, you could have gatekeepers, you could have more closed systems that could say, okay, the bank needs to sign off your transaction in order to approve it and so on, right? So you basically take your decentralized money, move it into a more centralized currency, satisfy the auditing authorities, and then potentially you can move it back. So this is very exciting because it provides a smooth way of transitioning out of the old system and into a new system in a way that is gradual. Okay. So there's no reason why all these coins cannot interface with each other, right? So in the future, when we enable sidechains for all of these, all of these can be sidechains of each other. So settlement layer and computational layer can sit in the middle and be the sidechains of each other, but we don't have really a limit as long as the features of the underlying chains are there to make each chain, sidechain of another, right? And what interesting thing is that we don't really need a central layer for this. So hopefully this can be a peer-to-peer system between different blockchains. So in this case, for example, Monero can interface with a theorem classic, but also with the computational layer, but the computational layer can also interface with the theorem classic blockchain without moving through the Monero chain, right? So if you have some Monero on the Monero blockchain, you move it to a theorem classic, then you could potentially move that Monero to the Cardano computational layer without asking the Monero blockchain what's going on. And the question of how we can do this safely and how we can maintain the firewall property and what the firewall property in this case would have to be, what kind of trust assumptions exist between the different blockchains is something left to be defined. But hopefully this is something that we can aim for. Okay, so some of the things that sidechains enable in terms of features. One of the interesting or most interesting things in addition to the basic, like obvious features that I explained at the beginning is upgradeability. So this idea is that we could use a sidechain in the place of a soft fork or a hard fork. And this could have avoided the civil war that was happening the last two or three years. The idea is that instead of soft forking or hard forking, the developer who wants to add some new features simply creates a new blockchain off of the main chain. So it's a sidechain, has all the new features. But it doesn't need its own currency. So it doesn't need to face volatility crisis. There has to be no worry that the token is going to be worthless, right? Because it's always going to be two-way pegged. So if I wanted to create Bitcoin Cash with sidechains, what I would do is I would make Bitcoin Cash a sidechain of Bitcoin. And then I would make the Bitcoin Cash coin just pegged to the Bitcoin coin. It's a two-way peg. And I would be able to move it back and forth without ever going through exchanges, without buying or selling it, just on my own. And then if people eventually wanted to move their Bitcoin into Bitcoin Cash completely because it's faster or cheaper, then eventually all the value of the Bitcoin blockchain would be moved into Bitcoin Cash and the community could sunset the Bitcoin blockchain eventually. So that would be a more smooth upgrade mechanism. And it would be also a mechanism to abandon ship if we know that a blockchain is going to be eventually insecure. So for instance, if we at some point develop a serious vulnerability against the Bitcoin blockchain, but we don't know how to exploit it just yet, for example, a vulnerability against SHA-256, we could create a new sidechain that has a new hash function, move all the coins there, abandoning ship, and then sunset the old blockchain before there is a catastrophic failure. Yeah. Yeah, that's a difficult question, how you do it. So if you have stake, it's kind of easier because you can borrow a stake from the main chain and so on. In this case, usually what we do is we assume that there's honest majority in both for this proof, but it's not trivial to see how miners would behave in the real world. So I think what you're asking, Thomas, is that what happens if a miner moves their mining power from the main chain to the sidechain for a very weak sidechain in order to destroy it, for instance. Yeah, so that's a good question, but if the sidechain is an upgraded version of the system, they believe in it and they have their coins in it, and they could, and the sidechain could provide incentives as well, so the sidechain could allow miners to mine extra coins on it by securing it. Another way that was proposed was to do merge mining, to allow merge mining, but then again the question is what are the incentives, do you want miners to be able to have nothing at stake for attacking the sidechain? So in the Cardano case, for example, where the computational layer and the settlement layer, they play amicably together and they're nicely interoperable and people staking in one will be happy to stake in the other. This works nicely, but if the sidechain is maybe an enemy chain like the Bitcoin cash case, then that would be more complicated. Okay, and then here's another idea with sidechains to enable scalability. So here we have the settlement layer and the computational layer, but then we have created separate chains that are sidechains of the settlement layer and they are responsible for different industries. So here the idea is that you have a sidechain for electronics, for steel, for travel and so on, and each of these sidechains could keep transactions within the industry. So if you work in the electronics industry, you could, as a company, take your money from the settlement layer, move it to the electronics chain, transact with other electronics companies like your supplier and so on, and then when you want to transact with somebody outside your industry, you could move your money back into the settlement layer and then into some other industry, right? So the nice part about this is that most transactions hopefully would be within an industry and that would off offload the main chain off of these transactions because they are done completely separate, right? So that's one way to do it. Of course, this has challenges mostly in deciding what these are going to be or if you're going to have multiple per industry and so on, but one way to solve this is just to allow anybody to create a sidechain and work with it. But this is also an open problem that we're thinking about. Okay, moving on to proofs of proofs. So this is going to be a little bit more technical. So I just want to show you how these work from mathematical point of view, cryptographic point of view, just to have an idea about how the construction looks like. So most of you may be familiar with the proof of work equation where you hash a block and hash has to be below certain target value. Who here has seen this before is familiar with it? Okay, great. So you have the hash function, you have the metadata and the block, and also the proof of work target. Now we know from the work of Nikos and Agalos that we have a common prefix theorem. This is one of the security features of blockchains that you can't really have a situation where some blocks, you have a deviation from a certain block in the blockchain of more than K is equal to six, let's say blocks here and also there, right? So what this says is that if a block is confirmed, an adversary cannot really unconfirm it by creating a longer blockchain. So in the SPV protocol where you have a verifier that wants to receive some money, what you do is you have multiple provers that claim oh, here's the longest blockchain and they send the block headers. So the honest player will say, here's the honest chain and the adversarial player will say here's a fake chain, right? And in the SPV case, because we can look at block headers, let's say in Bitcoin's work case, for example, the verifier can really check the chain for work and then compare their lengths and decide that oh, the honest chain is okay, right? By doing this kind of comparison there. Now, this has problems in terms of size, right? So for Bitcoin, for example, the chain is 500,000 blocks, in Ethereum, it's 5 million now. The communication in general is linear to the size of the blockchain. So for every block, you don't have to communicate the whole block, but still you have to send the header. So the question here is can we can we convince a verifier that this is the right chain without ever sending the right chain? So can we convince them that the last portions, the last K blocks of the chain, of the currently honestly adopted chain, are these six blocks without ever sending the whole blockchain? And the answer is yes, we can do that and these are proof of work. So here's the gist of the idea. So if you look at this equation, all blocks have hashes below a certain target, but some blocks have hashes much below a certain target. So some blocks have a hash that's below T-hubs. Some blocks have hashes that's below T-fourths and so on. And specifically, all blocks are zero super blocks, half of the blocks are one super blocks, a quarter of the blocks are two super blocks and so on. So what's a super block? Well, a super block that we call new super block is a block that is below target T over 2 to the mu. So if you set mu to 2, for example, then the equation would say that the hash of the block is below T-quarters. And so that would be a quarter of the block. Now the inside here is that these super blocks somehow capture within them the fact that a lot of proof of work has happened around them without having to reveal all the blocks around. So here's how the work blockchain looks like. So this is the zero level blocks and some of them are one level blocks and some of them are two level blocks and even fewer of them are three level blocks. So you can see they're distributed very nicely. Of course, this is a probabilistic data structure. So it may be not exactly right, but it's going to look about that, about like that. Right. So here, the nice thing is that if I show you level two, if I just show you those blocks, I can convince you that this work here has happened without ever showing you all the zero level blocks because these blocks capture all the work that was done as super blocks. Right. So this idea with with proofs of proofs of work, instead of sending the whole blockchain, I set some parameter M to 128, for example. And then I take the Ethereum, for example, blockchain, which is four million. And then I say, if I go to level 15 of super blocks, then there I can find 128 blocks. And those are sufficient to to prove that work has happened. Right. So each of these super blocks captures the fact that a lot of work has happened around without showing all the blocks. It's a probabilistic method. Okay. So in the proof of proof of work protocol, the honest prover will provide a short proof, some sample of blocks that are super blocks to convince the verifier that this is the chain, right. And then the adversary will also provide a certain amount of super blocks. And then the verifier will check that each of these proofs, not only satisfies each of each of the blocks in these proofs, not only satisfies the proof of work condition, but it also satisfies the new super block condition, saying that these are only new super blocks. And then after I do that, the idea is that I will compare these two by length and see which of them has the most super blocks. And that's the one that would win. So as I showed it to you, the problem is that these are just in these proofs, they're just bags of blocks. So an adversary could just rearrange these blocks around and convince me that the chain has a different order, which is something I don't want. So it's really necessary to create pointers between the same level of blocks. So each two level block has to point back to the same two level block. So this is something that we call the interlink or the interconnected block chain. And this is exactly the metadata that I mentioned that we need to create sidechains. And this does not exist in current or most current block chains. For example, Bitcoin doesn't have it. And the challenge also here is that when you create this block, you will not know if it's going to be a two super block or one super block or just a zero level block before you mine it. So you don't really know which is the right arrow to include. If it becomes a two super block, you need this arrow. If it becomes a one super block, you need that arrow. Right? So the way we solve this is before mining this block, we create all of these arrows. We put them in here and then we mine it. And then one of them is going to be right. But the number of arrows is going to be just logarithmic in the number of blocks in the whole chain. So it doesn't really add up much space to the blockchain structure. Okay. So this is how proofs of proof of work look like. So the prover will show certain super blocks to show that a certain amount of proof of work has happened. So it will have to go back to Genesis, of course. And then eventually once it shows that the longest chain is here, then they also show the suffix here of the last K blocks that the verifier is interested about. So this is how it will be constructed. We call the prefix pi and we call the suffix he. And these are security parameters that are specified by the verifier. So you need at least a certain amount of blocks on the super block level and a certain amount of blocks at the suffix level. You just ask for one super block to just represent the whole blockchain. You have things like backpack attacks where you don't, you can be vulnerable to variants attacks. So the adversary could get lucky maybe once in creating a super block, but they can't get lucky end times, which could be 128. Okay, so I have here the protocol for anyone who wants to read it. I will upload the slides later. I don't want to go through it. It's a bit more complicated than what I described. And these are the interactive proofs. This is older work from two years ago. And then we also have non-interactive proofs, where the scheme is a bit more complicated. But in the end, these are just pieces of blocks, right? So just sets of blocks. In the non-interactive case, you have to include a few more blocks, but again, they're just logarithmic in the size of the chain. And if you collect all these blocks in the non-interactive case, which we also call NepoPowl, in the non-interactive case, what you do is you create these nice strings that allow you to create sidechains. So there are proofs that don't need any interaction between the verifier and the prover once the prover has constructed this proof. And these proofs are short and they're also succinct. And they allow you to prove anything that has happened from Genesis till now. So one of the interesting parts of this construction is if you have certain superblocks that are very high level, sometimes you want to prove that something happened between them. And this is the way to do it. So I'm just keeping this part of the construction as an interesting portion. So if you're proving something on level four, then normally this will point directly to this four. But if you want to prove that this block was included because a transaction is of interest to you, then you can do this nice trick where this contained the three pointer because of the construction I described before. This contained a two pointer, one pointer and then eventually you can go down in just a logarithmic number of steps. So it's like maybe if you're familiar with the lowest common ancestor problem or a heavy weighted composition in algorithms and such techniques, basically you just use a data structure which can do these jumps. So these jumps, like if this is a four block jump, then it becomes a two block jump and a one block jump. So you get really quickly down to the block that you need. OK, and one more application I want to mention before I close this talk is that we can have light SPV clients with these proofs. So in addition to having sidechains, light SPV clients are also enabled. So a light SPV client could be an embedded device or a mobile phone that doesn't really need to download all the blockchain headers. So we all know that we have SPV and we don't need to download the whole blockchain. But with this construction, we don't even need to download all the block headers. We just bootstrap it very quickly. So we have a mobile phone that has just the Genesis block and then it downloads 128 blocks and that's synced, right? Doesn't need to download all the intermediaries because it has enough of a representative sample of blocks to know what's going on. Yeah, sure. So a super block. So if you have a block, then its hash is below a certain target T. Some of the blocks would have a hash that's much less than T. So some blocks will be below T halves. These are called one super blocks. Some blocks will be below T quarters. These will be two super blocks. Some will be below T eighths. Those will be three super blocks. And in general, mu super blocks will be blocks that hash below T over 2 to the mu. OK? So this is why we have this nice distribution where you have powers of two. Does that make sense? OK. So this is how we do light SPV. And there's a couple blockchains that are being worked on. The most prominent, I think, is by Alex Chepournoy called Ergo, which has these proofs embedded into their system from the beginning and allows clients to prove things very quickly. So this is very interesting. OK, so for sidechains now, things are easy, right? Because we have these proofs of proofs of work. We can use these to say that something happened on the remote blockchain, right? So we just take this one. We keep a certain amount of blocks as a representative. And then we include the infix portion, as I described, to say that an event happened, right? We compress it into this nice string and then we put this into that other blockchain. And then the smart contract in the blockchain below can just check for syntactic correctors and proof of work, the proof of proof of work to say that it has enough superblocks and so on. So that's how it would work. And that's how you can achieve isolation as well. OK, so some future work. There's a lot of open questions in this area. One is proofs of proofs of stake that's being worked on. Another one is how we can do sidechains on all of our using some of these mechanisms, which is a paper we're writing now. Then another question is, how succinct are these really the proofs of proofs of work? Are they really short in every case or are there cases that are adversarial where they could be longer? And this is a problem we're exploring with Nikos and Aguilos in a new paper also. Another question that nobody I don't think is addressing is, can the small work in the variable difficulty setting where targets are adjusted? So our security proofs are just for targets that are constant. I think that this construction will work for every case, but we don't have a proof for that. So that's also an open question. And then, of course, there's also the question of actually implementing it and seeing it in the wild. And this is a project that's being done by Jodros Christoglu and Arthur Gehrweiss in Imperial. So they just started playing with this ICO example that I gave before between Litecoin and Ethereum Classic, hopefully. So this will allow cross-chain transactions to be realized for the first time. So this is very exciting to see. So here's some papers. I will put up the slides here or email them to you. I don't know. I'll talk to Tam, I guess. And then that's it. Thanks.