 Dominic is also a PG student at our lab and Mustafa will be here in a second, this will be soon. So, the workshop is scheduled in two parts. We have one part where we'll talk about cross-chain communication. The principle will also explain why cross-chain communication is where it's not possible without a trusted third party. And then we'll also have a technical deep dive into chain relay, specifically BGC relay. And then we've prepared a game. So essentially, if you have ganache installed on your laptop, if not, you should download it now. You will get a broken PDC relay implementation and you get to fix small parts of it. Or we'll have a game server which tests attacks against your relay and then we'll have a leaderboard. So, this workshop is based on a paper we recently released. So we wrote up a systematization of knowledge on cross-chain communication. So it's on e-print if you want to have a look at that. I won't be presenting everything because it's just way too much content. But yeah, if you're interested, that's where you should look. So, I mean, I guess we can all agree on why interoperability is necessary, but let me just repeat this again. Today there exist over 2,000 cryptocurrencies. And I think we can agree that most of them differ in design purpose, not only from functionality but also the different views of the community of how these things should be used. So, we kind of need a way to find a path to communicate between these different blockchains because it's very unlikely that there will be one chain to rule them up. Now, historically seen, cross-chain communication, the principles of cross-chain communication date back to communications across distributed databases. However, the main difference here is that in databases, specifically within a single data center, you don't expect bits and dean or adversarial behavior, right? So, the reason that everyone's honest, you're a single admin, and the only thing that can happen to your processes which push and pull data from the databases, they can crash. So, basically, non-blocking atomic commits is a way, or so basically, there's a problem and there's solutions for that. And the problem is that you want to make sure that your process that is running correctly does not fail and does not get stuck even if other processes crashed. Now, in distributed ledgers and blockchains specifically, the difference is that we actually expect participants to misbehave. We can have selfish miners, we can have people who try to double-spend and just attack your protocol because anyone can join the system. And this is basically the major difference between these two things. So, if we briefly talk about the main scenarios of cross-chain communication, if we talk about the main scenarios of cross-chain communication, I guess the one that everyone knows about is exchange of assets, right? Swapping coins against each other and also trying to transfer coins from one chain to the other, right? Making a payment to a merchant who maybe only accepts Ethereum and you're only in the different. Now, there we have atomic swaps. We also have the concept of cryptocurrency-backed assets. We'll talk about this in more detail later. Now, another very important scenario where cross-chain communication occurs is synchronization in sharded systems. Specifically, the idea of sharding is that you separate the state of a system and each sharder is responsible to maintain and secure the state of the subset of the state. Now, the problem is it only makes sense if you can actually communicate between the shards because otherwise you have a system of isolated shards and then it's already sharded. So, we'll talk about the differences in the different use cases and assumptions between sharding and cross-chain transfers a bit later. Now, what I think not many people know is that cross-chain communication was actually the first time implemented to use something else. Basically, it was used to introduce merge mining and that's basically a boot-shaping technique to launch new blockchains. And the idea there is that you have one parent chain and you allow miners to reuse the proof-of-work solutions from the parent chain, for example, Bitcoin, to create blocks and other blockchains like Namecoin. And essentially there, that means that Namecoin can use the security assumptions of Bitcoin, but it also becomes dependent because of Bitcoin bills, so does Namecoin because it uses the same proof-of-work. And finally, and we try to cover this bit more in the paper, there is this term of side-chains. Now, side-chains have seen many, many different definitions over the years and it's become an umbrella term for blockchain capability in general. And I guess the most famous, too, that we have seen is side-chains are an approach to extend functionality of one blockchain which becomes a parent chain and you have small blockchains on the side which are dependent on the security model of the parent chain. But there are other definitions and also quite famous ones specifically in academia which suggest that side-chains basically refer to one blockchain verifying the state of the other. Now, in the paper, we'll try to clarify this and we try not to use this term at all because it's very confusing in general. So, again, we'll talk about these two things in more detail today. Now, maybe a question to the audience. How many of you think that cross-chain communication is possible in a trustless matter? Okay, they've seen our tweet before, okay. So, the answer is no. And I'll try to explain why this is the case. But before being academics, you know, before we explain something, we always have to make a system. You know, to be sure that we cover all cases and that we understand what we're talking about. So, in cross-chain communication, we, for simplicity, assume that we have two different legends, right? In this case, Bitcoin and Ethereum. Now, we also have two parties or processes as distributed systems. We have Alice on Bitcoin and Bob on Ethereum. Now, let's assume we have two transactions, right? Transaction one, the blue one is owned by Alice, so only she can push it to the blockchain. And transaction two is owned by Bob. Now, transaction one is a Bitcoin transaction. It can only go into the Bitcoin blockchain. Transaction two is valid on Ethereum. It can only go into Ethereum. So far so clear, right? Very simple. Now, the idea of cross-chain communication is that Alice wants that Bob writes transaction two to Ethereum and Bob would like that Alice writes transaction one to Bitcoin. Now, this, and basically this also implies that Alice knows exactly how transactions it looks like and the other way around. Bob knows what he actually wants to have. Now, if what reduces to practice, you can imagine this being an exchange, right? Transaction two gives Ethereum to Alice. Transaction one gives Bitcoin to Bob, right? And let's keep this in mind for the rest of the discussion. Now, the goal of cross-chain communication is to synchronize these two processes, right? We want to make sure that Alice writes transaction one to Bitcoin, but Bob also writes transaction two to Ethereum. And we actually want to ensure that they both write at the same time, or at least atomically. Now, we have three properties for cross-chain communication in the paper. I will not bore you with theoretical definitions here. I'll just try to give the intuition what each of them means. So, effectiveness basically states that if everything is all right, if Alice and Bob are honest, and the transactions are as they expect, then cross-chain communication will proceed correctly, right? So, this basically allows the process to be executed. Now, atomicity reduces the set of potential behaviors to ensure that either Alice and Bob write transactions to the respective blockchains. So, either ticks one goes into Bitcoin and ticks two goes into Ethereum or none of them do, right? Because otherwise Alice or Bob could be at disadvantage and this would break our goal. And finally, timeliness basically ensures that at some point the protocol proceeds. At some point Bob or Alice will initiate the process and then the protocol starts working. Now, let's recall again, we're looking at an exchange. And essentially, cross-chain communication to Alice and Bob can be seen as a fair exchange of assets, specifically using our example to emphasize this. Right? Because they want to make sure that Bob receives coins on Ethereum and Bob receives coins on Bitcoin atomically. Otherwise, one of them will be cheap. Now, the thing is that fair exchange is impossible without our trusted third party. And this is a result dating back to 1999. If you have an e-cument at a look, it's written in this paper, it's actually fairly easy to follow and there's a really good explanation also about discussion about trusted third parties and what this actually means. Well, questions? What do you consider trusted? True. Let's get back to that. This is, I will talk about it in a second. Because using cash and more contracts, he's possible. No. And I'll try to explain in a second. Well, then the question is what do you consider trusted? The definition before. So, I'll explain in a second. You won't get to that point. But, yeah, HGLCs allow you to reduce trust in the third party, but you don't have a guarantee that you took that. The exchange will actually be atomic. We'll get to that in a second. So, again, we conjecture right now that it's impossible, right? And there's basically a proof sketch in the paper and I'll try to give an intuition here right now because, obviously, I don't think you should just trust me by me saying it. So, let's assume, again, we have a smart contract in a fear. And the smart contract allows us to do way more things than just HGLCs. So, it kind of supersedes actual contracts in this case. And using this smart contract, what we can actually do is we can enforce that Bob behaves correctly if Alice writes transaction tx1 to Bitcoin, right? Because we can require Bob to lock in some coins in the contract and the contract will then release these coins if Alice can show that she's sent Bitcoin to Bob on the Bitcoin side. So, this is actually a very weak model. Using HGLCs becomes more complicated. In fact, we'll cover this in a few slides later on. Now, if Alice now writes transaction 1 to Bitcoin, she wants to be sure that she receives the coins in Ethereum. So, what she has to do is she has to submit a proof or somehow inform the smart contract on the Ethereum side that she actually rolled the transaction into the Bitcoin side. And the problem is, within a single chain, yes, this smart contract could actually verify, right? If Alice were to write to Ethereum and took all the function of the smart contract, the contract would become aware that, yes, something has happened. But since these are separate ledgers, this contract by itself, also being a program which reacts to submit, but it has no other way to verify that something happened a bit except if someone tells them that it's happened. And this is actually where the intuition of the visibility comes in. Because the only way we can solve this problem is we can make an assumption that either all parties that we have a synchronous model, that means Alice is also online and that we know that there's a bound on the message delay. So, basically, in this case, Alice is online, she's honest to herself, obviously, and she's an incentive to claim the coins on the Ethereum side after saying the Bitcoin. So, she's the one who submits the proof. But the problem is, if we do not want to make this assumption in a synchronous model, and we went without Alice to crash, which is a typical assumption we have to make, the only other way we can achieve actual correct crossing communication is by having a trusted third party, which then takes the transaction one proof and submits it to the smart contract or, once you have a trusted third party, you might as well trust the third party who locks the coins on the Ethereum side. Questions? Like, moving between blockchains will allow to make these rules. And then, moving like a state route is done by some game which allows not to be just a trusted party by like some momentum protocol and like a protocol. So, there's a certain... I'm just trying to understand that it means trust us in this way. So, a trusted third party in the sense of distributed systems I mean, obviously you want it to behave honestly. You make this assumption. But if you build a game around this trusted third party it doesn't guarantee you that this party will behave honestly. It just incentivizes. It could be a fee like a protocol. Exactly. So, if you say this party was a lot collateral and will reimburse you, you may not face financial damage but the protocol still failed. Right? You're still the actual... So, trust it will be mean like a pure mathematical trust and not like an economically bound... So, I'm not saying you're mathematical. Let's put it that way. Trustless in game theory is a greyish definition. Right? I mean, essentially if you... And we have their protocols which ensure that you don't face financial damage. I mean, one thing is based on like... Sure. But in all these protocols you have some timeouts and some timebooks and some synchrony assumptions because if you don't have a synchrony assumption it breaks. Well, we'll come to that in a bit. I mean, we'll discuss atomic swap, cryptocurrency-backed assets and you'll see where the synchrony assumption comes in, actually. So, your argument in this example was that Alice would not be able to do the transaction and that's why you use third party? So, the thing is, in this model you must allow Alice to crash, right? You cannot assume... If we assume that Alice is on the plane... It's only at the amount of time within a hash-time lock-on rate in which she can... Well, we'll get to hash-time lock-on rate in a second and I'll actually explain on an example why it is still the problem. But essentially... The option problem? I mean... Not exactly. That's also a problem. But in hash-time lock-on rate contracts they only ensure that you cannot steal or misbehave within a certain period of time. But if you crash and the time it expires it still fits. There's a specific example on this. Why don't we let him get through all the variables? Okay, sorry. Question? Yeah, can you talk a little bit about how important it is for us to not rely on a synchrony assumption and why that's important and... I mean, the thing is, so... When we design protocols often we make the assumption that we have a synchronism network model because it's way easier to design these things, right? We assume that if I send a message at some point you will receive it. However, if we cannot make this assumption then I do not know... And if we assume that nodes can be malicious then I do not know if you're malicious or you just do not get the message. And there's a really famous FOP impossibility result by Nancy Lynch where the consensus is impossible in a system where you have at least one call to know if it's a synchrony. Because again, I send you the message but if I cannot make an assumption I don't know whether you received it or not I don't know, maybe you're malicious and you're just pretending not to know it or the network actually has a huge delay. Usually this synchrony is a network assumption and not a participant assumption. It sounds like here it's an assumption regarding Alice so I was just wondering... Okay, yeah, fair. Which one is it? I mean, it's both. Because you need Alice to be online because she needs to send the message. Sure, but you can usually ensure that somehow but if the network you don't have a synchrony assumption then it's hard. Yes, so the problem is within a single system you can try to ensure that Alice sends the message or something. That's the timeless assumption, right? At some point Alice will write the message but here we kind of have two separate systems so you have two separate networks. But I see the point so the definitions are more clear in the paper hopefully. It's not an easy thing to just explain by intuition but I hope this kind of makes sense to everyone. Are there any more questions on this? Okay, so if you have questions you will just have to trust them a lot. So yeah, we conjecture that it's a cruel one and then there's a discussion in the 1999 where it's an impossibility result on why this is the case and they try to give a similar explanation of why actually having a synchronist as a model is very similar to having a trusted partner, right? Because then Alice, if she has to be online and we must expect the message to be delivered on time it's the same thing as if we had a trusted third party. The trusted third party is online and it ensures that the message is delivered on time and it ensures that the protocol progresses. If we assume synchrony, Alice is her own third party or she trusts herself because she knows she'll be online and that's what she'll be delivering. So basically it's the same thing whether you assume a trusted third party or you assume a synchronized reception from theory perspective. Now obviously assuming a trusted third party the trusted third party would steal your coins and everything but for the correct execution of the protocol and again this is where the game-threatening perspective comes in if you can ensure that the trusted third party cannot fraud you financially it still is the same thing as a synchronized reception from disability assistance perspective. Now Mustafa will take over the classification of the protocol and then we'll move on to the examples. Okay, so I'm going to talk a little bit about different types of protocols that you could use to do cross-chain communication and this is based on a paper that we wrote a systemization of knowledge paper that compares different cross-chain communication programs. So obviously as Alex said there's different use cases for cross-chain protocols side-chain, sharding and so forth So the first classification that we have is we basically separate all cross-chain communication protocols into two broad categories. Okay, the first category fire up to get is basically when you basically post a message on chain and there is no recovery So what we mean by that is in some cases if you're trying to swap an asset and you want that swap to be atomic or you want that transaction to be atomic in the sense that if you're trying to move x to chain y but if x cannot successfully move to chain y there's two different ways of dealing with that The first way is try and forget where you basically post a message on chain x say chain x will now be moved to chain y and there's no recovery process behind that so there's no way this can fail If you say I want to check the chain x to chain y then there's no a board phase or recovery process behind that But here with two phase commit protocols there is a board or recovery phase in the case where a transaction fails So you might move object x to chain y but you might realize but when you move object x to chain y it might be the case that you might have to undo that because the overall transaction that this process is part of has failed and this is where the abort comes in and it will become more clear when you actually go through the actual protocols but this is a classification a second classification is local verification so when you actually do cross-chain communication who is responsible for verifying that communication for some protocols use local verification which is basically when only the participants who are involved in that cross-chain communication are responsible for verifying that cross-chain communication for example hglc-based atomic swaps so for example if Alice wants to send money to Bob if only Bob is responsible for verifying that that money has been sent on the other hand with global verification you don't just need the two participants or the participants of the cross-chain communication protocol to be involved in the verification you also need the entire consensus to be involved with that verification or you need to verify the consensus you need to verify some consensus level header or object and one example of this is atomic swaps with transaction-inclusion groups so the transaction-inclusion group which from Bitcoin for example the Ethereum chain has to receive a block header from the Bitcoin chain and the Ethereum chain has to verify the proof of work of that block header and so that's global verification because the Ethereum chain is verifying the consensus of the Bitcoin chain so the entire Ethereum chain is basically involved in some way of verifying the communication I find the security model there's different security models for cross-chain communication there's homogenous and heterogeneous heterogeneous let's start with heterogeneous because that's more simple than that and heterogeneous is basically when you have different chains that aren't really kind of connected or directly connected to each other for example let's say you want to communicate from Bitcoin to Ethereum or any of these chains this is considered heterogeneous because these chains are built differently and have different security assumptions so you might not be able to necessarily make assumptions about the security of interlaced chains I could just create my own blockchain and communicate with Bitcoin for example using a timing swap but people in Bitcoin can't make assumptions about the security of my chain now with the homogenous with the homogenous security model it's due to the uniform level of security for example sharding in a sharded system there's multiple chains but those chains are part of the same system and they use the same consensus protocol and they design to be connected to each other so you can make assumptions about the security of those chains and usually sharded systems are designed in such a way that if one chain fails then so does the other because those chains rely on the state of each other so you might be familiar with Cosmos for example or Polkadot Polkadot and Cosmos for example have a heterogeneous security model for example when Cosmos or Polkadot you can create your own zone or chain with your own consensus where for example if you have two pointer sharding or any kind of protocol it's because it's to be homogenous so when I go through different protocols we're not going to go into them to do my detail but we're going to give it to Alex to first start with atomic swaps so yeah also just one thing on this figure we won't have time to go into detail about all of them but one thing that you may notice is that local verification so when only two of the participants were involved in the exchange have to do the checks it's actually a agnostic of the blockchain it's an agnostic of the security model obviously you need to make sure that the locking mechanism is available but otherwise you don't care about any consensus level details and so on because again only us to verify so let's talk about cross-legion I hope I'll be able to answer your question why HLCs may not solve your problem so again in atomic swaps sorry sure so in atomic swaps using symmetric locks the idea is that both parties Alice and Bob use the same locking condition on both chains an example are hash locks right so what Alice creates she generates a secret and creates a spending condition on bitcoin for example which says if you can provide me with a secret you can take these coins and Bob does the same thing so usually they'll have a setup phase they'll exchange verification transactions and so on but then they both know the hash of the secret so Bob makes the same lock now in the next step if Alice wants to spend Bob's coins she has to reveal the secret and this again ensures that Bob has a secret and can also take Alice's coins now typically you also have time locks to prevent that if one of the parties crashes or if the exchange never starts that your funds are locked up indefinitely but this bears a problem and this is I hope basically this is why HLCs don't solve the problem or the cross-stream communication problem because what can happen is that Bob can crash Alice spends the coins from Ethereum reveals a secret but Bob never sees it because he's crashed and what happens then is Alice can wait until the time limit expires and take her coins back on the bitcoin side but that's why you choose the time locks like this it doesn't matter Bob crashes before he saw that Bob never even sees the secret he's just offline he posted the lock and he crashed well that secret is still there just have to find it everything is public Bob the guy who could spend these coins because this is not just the hash lock it's hash lock and the Bob signature on the bitcoins this can only be spent by Alice this can only be spent by Bob so that's how you choose to construct and if Bob crashes and he never sees the secret and he does not come online and if the time lock of this thing expires Alice can withdraw that's why you choose the time locks in a way like this so he has enough time to still do it it's not a contradiction you choose the time locks but if he's offline indefinitely he crashes well if he's offline indefinitely of course but then he can only participate on blockchain solutions let's take this offline but that's an impossibility you're going to agree what if Bob dies it's bad but it's still impossible without any forcing that he stays online that's a result I don't say that you should participate in the exchange if you think you may crash that's where you can use watch stars but still now what you can also do is you can try to say well what if Bob actually is online the whole time and he can actually go offline because he uses a smart contract and that's the same example as we show using the disability result if Bob locks his coin and says okay well if you can prove to this contract or anyone that you send bitcoin to my account on the bitcoin side you can take these coins and now the responsibility is on Alice because she is the one who has to push the coins to bitcoin send the coins on bitcoin and push the proof the problem is so Bob can go offline but what if Alice crashes so Alice sends the bitcoin and then she goes offline and of course Bob could say well okay I'm a nice guy I'll give you I'll send the proof myself or anyone else could do it so it's already an improvement because now anyone can push the proof and the contract will give you the coins but it's again if you think about it it's the same thing as with HDLCs and furthermore if this time up expires again Bob can take the coins out so if Alice crashes and she is offline or Bob is the guy who actually as it runs a denial service attack against Alice he can actually steal coins so another approach and this is basically a different approach is to use cryptocurrency back assets so instead of trying to circumvent this impossibility result each time we exchange what we can do is we can create a representation of bitcoin on Ethereum and we have a whole paper describing this concept a term to explain but I'll try to give a very very brief overview so what you do is you send coins to a vault which is collateralized and insured through the union and stadiums so you have the game threat to guarantee that if nothing goes wrong if something goes wrong you'll get reimbursed so you still have to mitigate exchange rates now Alice then submits approved to the contract that she locked up the coins and receives Bitcoin back tokens and she can use these tokens to now make native atomic swaps with a better guarantee than it would optimize more we sell the impossibility result of fair exchange also the free option problem but at least we don't have to synchronize clocks and everything else across two chains and we also don't have to trust that at this point in time there is no attack on bitcoin which prevents transaction being included so you do the slow setup then cost the setup phase at once and then you can trade these tokens and use them with smart contracts sorry what's the options problem? let's say you don't have that much time but it's a fairness problem that I can cancel the exchange and basically get a free option because I know what your offer is but you don't know what my offer is so now when I want to go back I burn these coins and then the vault has to release these coins to me otherwise it will get slashed I'm skipping over this because we're running out of time but there's a whole paper describing this concept and we also have some code online a vault is a smart contract or is it a zone? no so the vault this thing was constructed in a way that you need smart contracts only at one chain a vault can be a smart contract or a participant it could be a human on the bitcoin side it just needs smart contracts on the side where you issue the tokens can you sell the vault at the third party too? sorry? is that the vault a trusted party? it's a trusted party from a distributed assistance perspective yes but from a financial perspective it's insured with collateral so if it fails I can get back collateral from the Ethereum side so the construction is if the exchange rates don't crash completely I as a participant do not face financial damage can we just put licenses from user to that's a different thing the vault can go offline but then the contract if I'm online and I can go to the contract and say wait a second this guy went offline trying to accuse him I have to then say well he didn't do it or in our case if the vault does not submit the proof on time I'm automatically reimbursed but if you think about it the communication actually failed because nothing happened on the bitcoin side I didn't actually trigger a process on the bitcoin side I just got reimbursed on the Ethereum side so cross check communication failed but I still because a protocol is constructed I got a reimbursement on the one chain that I'm on so there's two different aspects to this you have to be careful to separate cool now back to Gustav and Charlie okay so I'm going to give you a brief overview of our cross shard communications so I'm going to rehash the atomic transaction problem so what is the atomic transaction problem it can also be called a train and resolve problem so this is first Alice wants to book a trip and she needs a hotel room and a train seat to get to the hotel and let's suppose that there's a travel agent contract on the chain and what that contract basically does it books a hotel room and a train seat at the same time just like when you go to Expedia you can book a package with your flight and hotel at the same time that the hotel room object or contract is in shard 1 and the train seat is in shard 2 so that means the travel agent contract will have to communicate with both shards to execute this transaction where Alice wants to book a hotel room and a train seat at the same time okay but the key thing here is that Alice wants to book both the hotel room and the train seat we don't want to end up in a situation where one of those transactions fails because if the train seat transaction fails then Alice has a hotel room but nowhere to get to it or if the hotel fails then she has a train seat but nowhere to stay so let's suppose this transaction happens she tries to make this transaction and tries to book the same hotel room one second earlier but Alice has already submitted this transaction one second later we can end up in a situation where Bob ends up with the hotel room and Alice has a train seat but she has failed to book the hotel room so her transaction was an atomic okay now the goal of cross shard communication is to have atomic transactions so that it should be that either Alice gets the both the hotel room and the train seat or nothing it's all or nothing we don't want a half complete transaction so there's two kind of board categories of doing cross shard communication the first one cross is basically retext based Vitalik made a first part of his material research he called it cross shard janking but it's actually basically retexted in the 70s the idea is very simple basically what you do is you issue a yank command for the hotel room and what that does is you remove that hotel room from that shard and that shard generates a receipt that this has happened that the hotel room has been removed from this shard and that receipt is simply a message in the block and the receipt itself can be proven using a mail book proof and then what Alice does is she sends that receipt and that chart 2 reads this receipt and re-creates this hotel room in that shard and so now the hotel room and the train seats are now in the same shard and so now there's no cross shard communication even needed the transaction can all happen in the same shard so now so what I just prescribed was a fire and forget protocol so this was here it's a fire and forget protocol there's no recovery phase there's no ward phase there's no failure mode here the only potential failure mode here is during the time that Alice can move this hotel room to this shard but might move these train seats to shard 1 so then she has to move the hotel room back to shard 1 but in terms of the actual protocol the protocol itself does not have a built-in support or recovery phase now the other mechanism for doing cross shard communication is called two phase commit and there'll be two at all over one on this diagram I'll explain it two phase commit is a very old protocol definitely it's old it was used in distributed systems design but it could also be applied to sharding it's called two phase commit because there's two phases so let's suppose you have shard 1 and shard 2 shard 1 manages the hotel shard 2 manages the train the user sends the transaction to both shards and then what the shards do is they check that the transaction is valid and they run a Byzantine folklore protocol just like basically what blockchain is to agree that the transaction on the ordering of the transaction or that the transaction has taken place and then they lock they lock these objects that means that once these objects are locked no other transaction can come along and try to use these objects because these objects these objects will be locked through this transaction so it's like this transaction is reserving reserving these objects it's just like when you're at an event for example and you try to book a ticket it says this ticket has been reserved for seven minutes or something like that if you don't book it within seven minutes then you will lose your ticket so you're basically reserving these objects for this transaction and once all of the shards have locked all of the objects necessary as needed for this transaction they basically communicate with each other tell them that yes these objects have been locked to this transaction and then they can execute this transaction and unlock the objects or specifically actually just destroy the objects depending on how depending on your transaction model if it's a UTXO model you will destroy the object because UTXOs only spend once if it's a contract model then it's basically unlocked and so that's basically the principle now what could happen is if another transaction I have a diagram for this but if another transaction this block comes along and tries to reserve the same hotel this locking will fail and then both of the objects will be unlocked but the transaction will be aborted the transaction won't be committed it will be aborted so now we're going to talk quickly about quash-chain verification I don't know about that just do that out quash-chain verification validation and this I think we'll go and demo that one actually how many people actually have a laptop here and can't participate in the coding department can you can you raise like just so we see okay cool that's like 10-15 minutes so yeah let's just go through this okay so quash-chain verification and validation when you do quash-chain transactions it means you validate the messages that you're receiving quash-chain are actually valid and verified now there's different levels of verification for blockchain and specifically with quash-chain quash-chain communication first level state verification like I don't mean verifying that the state is correct I mean just verifying what the state is or what the consensus thinks the state is for example checking that some block header sorry state is just proof of work it's not checking the state it's valid checking what does the consensus what state does the consensus agree on so it's just taking the proof of work so if you have a hack a local or a block header then this indeed involves checking that the block header has proof of work has consensus so does the state have consensus actually maybe that's number two sorry I might stop that number two is does the state have consensus so number one is just checking that the hash of block has consensus number two is checking if the consensus agrees on what the state is okay simply like clients so SPV verification so one you download a mobile wallet for bitcoin for example an android that mobile wallet is only downloading a small piece of the block for the block header and it's not actually checking what the state is it's just checking that the state has consensus and in the third level it's checking that the blocks are included in the state that are relevant to you so not necessarily every transaction so for example you might want to check that someone sends you a transaction so you would ask a node to give you a proof that that transaction has been included in the block simple metal proof and number four is state validity so just because you know that the state has consensus doesn't mean that the state is valid okay so it's very possible that this on this majority of miners or stakers could produce a block that is invalid or even like a single miner to do that actually not a dominant size majority so in the bitcoin or Ethereum for a block to be valid it's not it's common misconception actually if people think for a block to be valid it needs to have it all needs to have its consensus but that's not true not only does it need to have consensus the actual transactions in the block have to be correct as well so at this on this majority of consensus participants should not be able to insert balances transactions into the block that steal people's money so that's why it's also important to actually validate the state and not just trust the consensus and that's basically the purpose of full nodes if you run a full node you're verifying the entire block chain you're checking every single transaction you're not just simply trusting the consensus and the fifth level which we're talking about is data availability which is basically checking I guess that's kind of coupled with checking validity checking that if all the block data is actually available for verification and this can be actually done as alternative to stability instead of checking instead of checking that the state is correct yourself you just assume that the state is correct and rely on something called fraud proofs to tell that all people can generate if the state is incorrect so they can prove to you that the state is incorrect so normally block chains use a guilty and central proof and innocent model where you assume that every block is incorrect as you proof otherwise whereas fraud proofs use an innocent proof and guilty model but we're not going to be talking about data availability and the green stuff is basically what light clients and there's data clients do which will be relevant to their workshop and there's other verification techniques so as I said direct observation, you run a full node yourself to check the validity of the chain watchtower so you can ask someone to run a full node on your behalf as a full back if you fail and there's many ways to do this that does not require trusting a watchtower that's not going to go into detail but it's going to go in the arrow just to fully trust someone or there's verification games so what some people do is the computation happens off chain but if the execution is correct you can challenge the execution result on chain and there's an interactive game that is played to challenge the verification result and basically the test needs to make the end result to reduce the money ok so we'll do a really quick technical detail into chain relays which is relevant for the practical part and then since not everyone has a laptop I suggest we split the room so one room can do the coding example we'll also provide this alignment afterwards so we have to prep the server and everything we'll have a UI and you can play the game later on so we'll make it available and then in the other side we want to discuss so we can continue ok but let's do another 5 minutes because that's kind of relevant for even if you're not already spending the day so as mentioned chain relays are basically to be so they allow us to verify the state the state agreement and state pollution of another project now state can also be considered just partially to transactional data you just know well you can parse the data on a big transaction but you have no clue where it's actually included or even now the thing is with SPV clients and that's a kind of a problem because it's not really being defined in practice I mean we have a lot of formal frameworks for this now the backbone model but I have not really seen a lot of clear definitions of what an SPV client should be I mean basically everyone knows but then we don't really write it down but if we build an SPV client that's when we actually start to think about it so what do we need to verify and the first thing is we need to be aware of what they're just because otherwise since we know that Bitcoin difficulty is switched every 2060 blocks and if you're it's different but we need to make sure that our chain relay program knows what the difficulty is expected at this point in time otherwise I could submit blocks which are too easy next we have to verify that they perform that's clear we have to check that each block that we submit is an ancestor right because they want to make sure it's a chain then we also have to make sure we can detect forks right we need to know if we have two chains which one is the main chain which is the shorter and finally we also want to make sure that we can check transaction inclusion proofs because that's the actual thing that you want to achieve when you do an SPV client you want to know if the transaction existed working of course now in our game today we've simplified the implementation we've dropped the difficult adjustment verification and we've removed 4CAM otherwise the cold base becomes too cold so we assume that with constant difficulty and with no force it's a simple model and yeah we were the testnet so you won't be able to preface so a question that people often ask is well what happens in proof of state blocks right because it seems similar but then there's there's a subtle difference to this because instead of checking and tracking the proof of work difficulty adjustment you need to track the state distribution of the chain because you need to know who is allowed to sign any track in proof of work you know the guy who found the proof of work and that the proof of work match the target he's the one in proof of state we even have a comment here but you need to know are they the ones who are allowed to sign the track and then you check signatures which is usually way efficient and verifiable for work at least if you have to do it cross-chain and the rest basically stays the same now practical challenges that we face when implementing obviously we need to make sure that we have a cryptographic primitive there so we need to be able to verify the proof of work of the chain we're checking right so this works for Bitcoin on Ethereum but if you try to do the same thing you run into major problems it costs around 100 blocks of worth of Ethereum gas to verify a single life of block so that doesn't really work and then you almost make sure that your chain related is a life right it's a single SPV client deployed in the chain and if no one provides the data well then it's a good use of it and the problem is you know that it costs us money to submit the blocks to the chain related theory you might have to pay the gas costs so if you come along to the PDC relay and the last time we checked it was around 90,000 blocks by the big main chain so if I don't want to use the original chain related deployment it's already feasible so your best goal is to redeploy it agree with your parties that you have a new block that you're aware of and then you start submitting again or one day maybe we'll have more efficient life clients that use flight clients or super flow people pause we have a discussion in the paper and we point to the links I won't go into detail because so we actually we looked at the PDC that was deployed originally and what we see here is that there's kind of a discrepancy between the time that the PDC block was generated and where it arrived in the Ethereum blockchain chain related and if we take a closer look we see that a lot of blocks were delayed around 3,000 hours which is not really practical you'd expect 6 hours to be delayed or maybe 10 because we're waiting for confirmations but then someone should push it so the problem is incentives someone has to pay for this and what we also saw that only 2 addresses submitted more than 90% of the blocks so essentially this was consensus running the PDC but in practice if you have an application you need to make sure you split the fees among participants otherwise you may have incentive problems and if the channel is not up to date it's not useful and you run into the problem that you can't submit the proofs and yeah unfortunately it seems that so the original PDC implementation is not normal running there's implementations by SUMA so they have a nice library we've also done implementations so in theory you can have an exploit if you need to use it but the original one is unfortunately dead so yeah finally the cost factor so we need to pay for submitting the blocks and what we need to do is we need to pay for each block to be pushed to the PDC meaning the cost thing is the same for SPV clients except that if it's your phone you can then delete the blocks if you don't need them anymore and the costing model is different storage is not that expensive on your mobile phone if you have a contract storage so what you can do then is you can try to improve this using sublinear light plan techniques but this requires changes to the actual blockchain you're verifying so both light plan and super block new profiles which I would have described on this slide but we don't have time but they basically allow you to only submit a logarithmic amount of blocks instead of linear but yeah another maybe practical challenge is if we want to deploy this on many chains what we end up doing is we submit block headers from n chains that we're going to verify to n chains that we're verifying out so it doesn't seem a bit of a problem so in the long term we probably want to find out how we can reduce this and maybe share data across multiple chains so yeah we don't cover everything and being academics we just please read our paper for everything else we discuss locking techniques to achieve atomicity HLCs, ECDC locks and so on we also talk about the implications of privacy security and the network threat models so when you design blockchain cross-chain communication borrow quality these are the things you must consider so yeah and now to the practical part are you going to post these slides in here? we will release them at some point