 A sidechain is a way for allowing two blockchains to communicate with each other. So we would like to create the ability for one blockchain to react to events that happen on another blockchain. And with this we can build more enhanced smart contracts that do not only depend on things that happen within one blockchain but also depend on things that happen on other blockchains as well. And what we would like to build is a network of blockchains essentially in the end. But thinking of just two blockchains, what you would like is to have one blockchain reacting to events that happen on another and also vice versa for these two to be a bi-directional pair. So the NipoPow is a cryptographic construction which we invented with Agelos Kiyayas and Andrew Miller. It stands for non-interactive proofs of proof of work. So it's maybe some sort of extension to proof of work. It's a way of proving that proof of work took place without actually showing all the proof of work. So it's like a proxy mechanism of illustrating that proof of work took place. This is a central primitive in the sidechain constructions or any kind of cross-chain constructions that we have. This cryptographic primitive is used to attest to the fact that an event happened on one chain and this attestation can be used in the other chain to achieve this cross-chain construction that I mentioned before. So I'd like to give maybe two simple examples of an application. The first example is a remote ICO in which you pay for an ICO in one blockchain. You receive the tokens in another blockchain. So for example, many investors have Bitcoin stored in the Bitcoin blockchain because they feel it's safer and they rely on it because it has less volatility than other blockchains. However, Bitcoin is not so feature-complete as other blockchains, let's say Ethereum Classic or Ethereum. And so you cannot build ERC-20 tokens on these platforms or any ICO really on Bitcoin. So it would be useful for investors to be able to pay in Bitcoin and receive their ERC-20 tokens in a chain like Ethereum Classic. And this is something that could potentially be accomplished with this scheme. One nice property of this as compared to requiring the investors to convert from Bitcoin to Ethereum Classic and then using Ethereum Classic to purchase the token is that you can denominate your ICO value per stock unit, let's say, in Bitcoin during the duration of the ICO itself. So if you say it's worth, you know, one Bitcoin gives you one token, this is going to be maintained throughout the one month, let's say, of the ICO even though the price, the relative price of Ethereum Classic with Bitcoin may change during this month. So that's one example application. The other application is that you can have a pegged sidechain in which you have some sort of two-way transfer. So the first example I gave is a one-way transfer where you have an event occurring in Bitcoin, a payment, and a reaction occurring in Ethereum Classic where you give out new tokens, you mint new tokens and you give them. One application of a two-way, a bi-directional transfer is a case where you would like to, let's say, allow Ethereum and Ethereum Classic to communicate with each other. And one application that you could use that for is you could take Ethereum units of money from the Ethereum chain, the native money of Ethereum, you could move it to Ethereum Classic and then it could retain its nature as Ethereum living within the Ethereum Classic chain. And then you can have Ethereum be within the Ethereum Classic chain, move it around using the Ethereum Classic blockchain, so any nice features that Ethereum Classic might have, you can make use of them and then you can move it, you can also transfer it to other people, split it, merge it, and so on. And then you can move it eventually back into the Ethereum chain originally with a one to one peg, always maintaining a one to one peg. So always one Ethereum gives you, or one Ethereum on the Ethereum chain gives you one Ethereum on the Ethereum Classic chain and one Ethereum on the Ethereum Classic chain gives you one Ethereum on the Ethereum chain. So we never, in this scheme, we never use any Ethereum Classic units, we just use the Ethereum Classic blockchain to hold value that is denominated in Ethereum. So that would be a two-way pegged currency and in the underlying technology would just be an ERC20 token that lives on the Ethereum Classic blockchain, which represents one unit of Ethereum per one unit of ERC20 token. So you can think of it as an Ethereum 20, let's say, a token living in a Ethereum Classic, which is ERC20, but represents always one unit of Ether. Thinking of the larger picture, I think there's three pillars that are enabled by sidechains that are central in blockchain research and open questions, I would say. One would be scalability, that's a difficult one. One would be interoperability, and the third one would be upgradeability. I think the central question that sidechain solves is interoperability, however it can also contribute to the other two. One way to contribute to scalability is that we can do some basic sharding of blockchains using some ideas from sidechains. For example, if we have a proof-of-stake-based blockchain like Cardano, then that blockchain network can be split into multiple blockchains that communicate with each other using cross chain methods, and each of them can have some transactions of the whole network. But other than their communication, they can be isolated, so this maybe gives some scalability benefits. As for upgradeability, I think Cross-Chain Transverse encourages innovation because if you have your unit of account being, let's say, a theorem and you rely on a theorem, but a theorem is not willing to do a hard fork to introduce new features, let's say, or they're difficult to convince or it takes a lot of time, if you have this cross-chain transfer and you work with a theorem classic, and for example, they would be willing to implement a feature faster, you allow people to use a theorem, the coin of the theorem chain in the theorem classic blockchain with the new features without actually having to exchange anything. They just transfer it in a decentralized manner on their own without the need of any markets. So that's very powerful and it encourages innovation and I think it allows the blockchain with the best features, essentially, to win. We have developed a lot of the theory on this, around this. Some publications are still pending. We are still ironing out the details of the theory, but we're publishing very soon also the stake side of things. On the implementation side, we're working with some software engineers to implement these. So on the work side of things, we're working with a master student called Costis Carantias who is doing an implementation at the beginning between Bitcoin Cash and a theorem classic. It's a one-way cross-chain implementation where you can have a theorem classic react to Bitcoin Cash events, so that would be proof of work-based. Eventually, we want to be able to interface between a theorem and a theorem classic in a bi-directional way. On the stake side of things, we're working with the Cardano team at IOHK who are implementing stake-based side chains, which are going to be a central part of the IOHK protocol and it will be a central part of the ADA ecosystem. So these constructions, we generally try to make them compatible with existing blockchains as much as we can. Unfortunately with Bitcoin, we are very limited in terms of op-codes, so it's very hard to do incoming transfers to Bitcoin. However, we can do maybe outgoing transfers from Bitcoin or Bitcoin Cash, but bi-directional communication will be possible in curing complete blockchains like a theorem and a theorem classic. Currently, what these blockchains offer us is sufficient to do these implementations, so we don't really need any changes. However, we could significantly reduce the gas costs of doing cross-chain transfers if we introduce some more useful op-codes. We are working with the theorem classic developers with an ECIP in which we recommend a pre-compiled smart contract which will reduce the gas costs of these operations. Hello, welcome to the afternoon session. So I'm going to be talking to you about side chains protocol for a theorem classic that we have been working on at the IOHK also at the University of Athens where I am a PhD candidate. So this is a nice slide that I like starting with. So here you see two blockchains. One is at the top, the other one is at the bottom, and something is happening between them. So this is what we want to do when we talk about side chains or cross-chain transfers. You have something going on at the top, like at the black block. So here you see a blockchain that is evolving with time, and something is occurring. There is some sort of event, a deposit, maybe a smart contract event. And we would like this kind of reaction to occur at the bottom. So this kind of sums up the whole idea. So what are we trying to do here? So here we have two blockchains. And in this talk I will use the example of a theorem and a theorem classic. But really you can have any two blockchains interface with each other as long as they have some sort of smart contract support. So a theorem and a theorem classic are the perfect example of this. So what we want to do is when something occurs, when some event happens on one of the blockchains, like the frog here, on the original chain, after a while this event is somehow propagated to the other chain. And the other chain learns about this event. And of course there have been some attempts to do that in the space. And one idea is to have some trusted parties attest to the fact that this event took place, like a committee or a federation or just one party or majority of signatures and so on. But the way we want to do that is in a decentralized manner, in a trustless manner in which you don't really need to trust someone to be telling the truth. So as long as these two chains are on their own, they're secure and honest and they operate safely, these events should be able to occur without the need of a trusted party. So this is the goal that we're trying to achieve here. So just some terminology before I go into the details of how we're making this happen is when we're making these kind of event transfers, we have a source blockchain and a destination blockchain. Here in this case it will be a theorem and a theorem classic. And this would allow interfacing between the two. And I will describe this as the top as the source and the bottom as the destination. However, this is just one event transfer. And if you have the ability to do that between two chains, both downwards and upwards, then when you're doing the upwards direction, the source and the destination chains are reversed essentially. And the bottom chain becomes the source chain and the top becomes the destination chain. So ideally you would want to have bi-directional communication between your blockchains. So in this case, we're talking about proof of work blockchains. We also have a way to allow proof of stake blockchain communication. We're working on this with Cardano specifically. But in general, it should be possible to work with any stake in any work blockchain as long as there is some smart contract support. So in this presentation, I will talk about just work communication. But one thing we also have the ability to do is to interface between work and stake so there can be also a hybrid protocol. Okay, so what kind of events can we transfer? What kind of events can we make known from one blockchain to another? So really, if you are a developer that writes smart contracts in Solidity or, yeah, if you're familiar with what you can do in Ethereum or Ethereum Classic in terms of firing events or calling smart contract methods, anything that you would be able to do within a blockchain, so calling into a smart contract method or firing an event, you can do that in cross-chain transfers. So you can have an event that a particular block was generated, or an account balance was changed in this way, or a particular smart contract method was called. So that's the goal here. And now I want to go into some details of how we do that. So now let me tell you what is the status of being able to do that and what kind of upgrades we need to the underlying change to be able to do that. So for Ethereum and Ethereum Classic specifically, we are working on implementing it first on Ethereum and Ethereum Classic, because these are two, two, two incomplete chains and this is convenient for us. So one of the things that we need is what we call a velvet fork, which will need to happen on the source chain. And this is something that can be user initiated and we're working on doing that. And then the other thing that we need is to have it be gas efficient on the destination chain, in which case we need some sort of op code. But this is not necessary for it to exist in general, just for it to be gas efficient. So this is a Ethereum Classic improvement proposal that we have put in earlier this year to make these smart contracts more efficient so that these events can be reacted to without spending too much gas. So right now, the implementation that we have is somewhat gas expensive, but it does work. Okay, so now let's go into the details of how this is done. All right, so really the challenge in making this happen is that we have these underlying chains. We have the Ethereum chain and the Ethereum Classic chain. And these two chains have miners that don't really want or care about monitoring the other chains, right? So if we wanted to make a hard fork, it would have been easy. We could have said to the, let's say to the Ethereum Classic miners, you guys, you need to look at the Ethereum blockchain as well and monitor this network as well. But this is not what we wanna do because this is impossible for it to happen. So we want this to be isolated. We want the miners at the top and the miners at the bottom to each maintain their own network and their own blockchain without being aware of the other chain at all. So that's really what is making this challenging. So the way we do that is we create these little things that we call proofs of proofs of work or non-interactive proofs of proofs of work, which is a primitive that we have invented with my advisor, Agilos Kiyas, back in Athens then in a collaboration with Andrew Miller as well. And what these do is they take a blockchain, so they can be generated by a full node or an SPV node, and they take a blockchain, and they compress it into a very short string that is just a piece of text. Then you can take that piece of text and post it on a different blockchain proving that something happened. So this is the underlying cryptographic primitive that you can use to make these things happen. So I will not go into details about how these are generated, but I will give a link to my paper at the end so you can take a read. So this is the basic building block there. So here is the recipe for doing this. Whenever something happens on the source blockchain at the top, then a user that has seen this event can generate this proof of proof of work that this event happened. Once this proof of proof is generated, this can be included in a smart contract called to the destination. And this call is not via the network, it's just something that you can do as a user as a regular transaction in which you just submit a string that can be independently verified on the destination chain. So the smart contract running in Ethereum Classic here can just check that this proof is legit, it's valid, and then react to this event accordingly. So with this, we can do some very interesting things. And my favorite example is a two-way peg in which we can create in Ethereum Classic an ERC20 token, which is pegged to one Ethereum. So then you can use all the Ethereum Classic features that you may want, but for units of Ethereum and not Ethereum Classic. So here's the idea. At the beginning, you have a smart contract living on Ethereum and a smart contract living on Ethereum Classic, and these are kind of sibling contracts. What you do is you deposit some money in the Ethereum smart contract. And once this money is locked up there, you use this, you create a proof-of-proof for this event, and you include that proof-of-proof in a call that you make to the smart contract that exists in the Ethereum Classic chain. And then this smart contract generates for you, it means some new units of an ERC20 token, which are exactly equal to the amount of units that you locked up in your Ethereum chain. So this is the generation of new tokens. And then these are classic ERC20 tokens, so you can move them around in the Ethereum Classic chain as if they were any kind of token. You can transfer them, you can delegate them, whatever you like. You can split them, you can merge them. And then eventually, as they change hands, somebody wants to bring them back into the Ethereum chain. So in that case, what they can do is they can deposit again to some sort of withdrawal function in the smart contract, which destroys the ERC20 tokens here and then provide a proof-of-proof that this distraction took place and then restore these tokens in the original Ethereum chain. So this allows you to have essentially bidirectional communication and because you can always bring money back and forth between Ethereum actual native units and the ERC20 token on the Ethereum Classic chain, these two tokens are essentially pegged to one another without the need of any central party ensuring the pegging. It's just a decentralized kind of pegging. Okay, so that describes what happens. So here I have a smart contract showing how we can do that and I know this is unreadable, but we will put up the slides on the website so you can take a read on your own. So it's a couple slides here. And then I'll also give you the references for our papers. So mainly, this is a paper with Agalos that is still unpublished, but we're working on publishing it very soon. And this is how to create proof-of-work sidechains. So the blockchains that communicate that are based on proof-of-work. We also have two more papers that are ongoing. One is for proof-of-stake blockchains in collaboration with Agalos and Peter Gadji, which is also unpublished, but we are also publishing this very soon. And also we have a paper that is already on ePrint since last year actually, but we have been updating it very actively, which is called the Non-Interactive Proof-of-Proof-of-Work, and this describes the underlying cryptographic primitive, which you can read to see how the construction exactly works. There's also this website here, nipopaus.com for Non-Interactive Proof-of-Work.com, and here we put up all the papers that are related to this kind of construction, so you can check back here and it has some nice descriptions as well for how this works. So that's it. I wanna leave some time for questions if any of you have questions, and thank you very much. Hi, great talk. Thanks. This may be a stupid question, but I was wondering if the Non-Interactive Proofs you've been talking about here were at all related to the Genesis Proofs in Uraboros Genesis? I don't know how to answer that, but we can take it offline, and I can check with Agalos who has invented Uraboros Genesis to see what exactly is the relation, but I don't know the answer to that. I don't think that's a stupid question. I wanna research that. Yes, Charles. Microphone? Hey, sorry for missing part of your presentation, but I know a little bit of the research. I have a question about light clients. Have you guys run any numbers of what type of efficiency gains NEPA POWs can provide to a proof-of-work light client? Yeah, so one of the applications of NEPA POWs because they can provide these short proofs that something happened on the blockchain is that they can basically compress the blockchain not only for cross-chain transfers, but also for light clients. So in theory, this allows what we call exponential gains. So instead of maintaining the whole blockchain, what you can do is you can maintain a small logarithmic part of it, and then this allows you to have a much lighter client, especially as the blockchain grows. So yeah, we have run some numbers on, for example, the Bitcoin blockchain. And in that case, we can reduce the blockchain from what it is to down to maybe a few hundred kilobytes, so that would be a concrete number there. And yeah, that's useful for replacing, let's say, SPV clients to make them even lighter. And I think the related work that we're doing in proof-of-stake is actually the first to be able to do that in the stake case. So that's also very interesting. Awesome, so I had a question too. You mentioned velvet forks. Yeah. Do you want to explain a little about how they work and how they might be different or somewhere in between soft forks and hard forks? Okay, yeah. So velvet forks are a kind of fork that we invented for non-interactive proofs-of-proofs of work to make them less intrusive. So in fact, a velvet fork sits not between a hard fork and a soft fork, but it's actually softer than a soft fork. And actually there's, if you go to this website here, nipopass.com, there's a follow-up paper by Zamiatin and his collaborators that was published in last year's Financial Crypto, which expands on these ideas and talks exactly about what a velvet fork is. The idea is that when you have a hard fork, you break backwards compatibility. When you make a soft fork, you have a backwards compatibility, but you break forwards compatibility. But with a velvet fork, you maintain both backwards compatibility and forwards compatibility, which means that the upgraded miners will need to inject some new information into the blockchain, but the old miners can still mine valid blocks that will be accepted by the new miners and vice versa. So every old miner will accept new miner blocks and every new miner will accept old miner blocks. So some blocks will have additional information and some blocks will not have additional information. And if we have some percentage of miners upgrading, even like 10%, we can still have this kind of construction. So we don't need majority miner approval to run this protocol. And actually you have also something called a user-initiated velvet fork, in which in fact we don't need any miner approval at all and the user can just inject this kind of data that we need in transactions that occur in blocks. And this is different from application data. It's kind of, it's consensus-related data that we inject into the blockchain. So, yeah. Does the user-activated one require like a certain amount of nodes to actually make the velvet fork work? Yeah, but they don't have to be mining nodes. They just need to run some full nodes. And the users that do this kind of injection, they don't have to be the ones that use the protocol either, so. Okay, great. Yeah. Do we have any other questions? Oh, back there. Hi, great talk. I really appreciate the work that you're doing. Thank you. Does the, do these ideas deal with the civil attack in any ways differently than a normal SPV-like client would? So, the way that we deal is comparable to an SPV client. So we compete, we, our security proofs that we do and our security theorems always achieve a most the same security that you would have in an SPV case. So you don't have a stronger security than that you would have in kind of a full-node scenario. So these are not, so if you've seen other protocols like Coda, for example, where they do a full zero-knowledge history attestation of what happened, this is different. And in their case, they provide some full-node security. This is SPV-node security. Also, how is it more compact than SPV-proofs? I just don't quite understand that. So in SPV-proof, what you do is you provide block headers but for the whole blockchain. In our case, you just provide some indicative blocks that you choose, a small sample of blocks, which is logarithmic to the size of the actual blockchain. So if the, if the blockchain serve as like 500,000, 500,000 elements like in Bitcoin, you would have to provide something like 20 sample blocks that illustrate, not 20, but maybe a few hundred just to illustrate what happened on the blockchain, but without replaying the whole blockchain. Interesting that you have the same level of security. So this is exactly the construction that we have in the NEPO pass paper. And this is exactly the reason why we need the velvet fork which basically allows the blockchain to be deeply connected and you don't just follow previous block pointers. Got it, thank you. Yeah, you're welcome. All right, great. Any more questions? Okay, thank you very much. Stay nice. Thank you.