 This talk is about how you would implement or how you can implement smart contracts on the Plasma system. The Plasma system is a scalability solution and it makes some trade-offs and we will see that not every smart contract will be directly usable on Plasma, but yeah, let's press just a second. Okay, that thing doesn't work. Okay, Plasma is a scalability solution proposed by Joseph Poon and Vitalik Buterin I think in August this year. I will start at the very beginning and explain what blockchains are and what I mean when I say state and when I say transactions. And we will see that blockchains are a bad idea because they can only process a limited amount of transactions per time per second. And then we will see that payment channels are one way to take some load off a blockchain and we will see that the blockchains only act as verifiers and not as processing nodes and this is already a good start. And yeah, then we'll see how payment channels can be extended to be child blockchains and how this can be reiterated to create trees of blockchains and that's what the Plasma system is about. And then we'll see how we can implement or that the key to implementing scalable smart contracts on Plasma is to transform global invariance we want to have but which we cannot check in such a smart contract into local invariance which we can't check. And we'll see an example, so the source code of an example contract which implements a token on Plasma. Okay, blockchains. We start with the first part of the word blockchain which is block and let's just view it as a bunch of data. And then here comes the chain part. In the blockchain, each block references its predecessor using a hash pointer. So a block contains a cryptographic hash, so a fingerprint of its direct predecessor and that's how blocks form a chain. They can also form trees but we've known that for now. And I said blocks are just a bunch of data and more exactly they contain transactions. And in order to explain what transactions are I have to tell you what state is. And in the example of a blockchain that is used as a currency, the state is usually just a list of participants, a list of accounts and their respective balance at a certain point in time. So Alice has 10 tokens, Bob has seven tokens, Cindy has 12 tokens and David has 18 tokens. And then we have a transaction, is that large enough? So in a transaction always contains a signature. Here it's signed by Bob. And yeah, since only Bob can create such a signature we know that Bob sent the transaction. So Bob is the assumed sender of the transaction. And the transaction has basically calls a function, it runs an operation and this operation is transfer two to Alice. So Bob wants to transfer two tokens to Alice. And when this transaction is included in a block then its effect on the state is calculated and the effect is that Alice, the balance of Alice is increased by two and the balance of Bob is decreased by two. Okay, that's how blockchains work. Let's take a closer look at the transfer function. So Plasma requires a smart contract enabled blockchain. So, and it doesn't work on a special purpose blockchain like Bitcoin. And because of that we will always view these, so this transfer function is a function that's actually implemented in a smart contract on this blockchain. Smart contracts are just programs running on the blockchain. And here an example limitation of the transfer function. It has two arguments, amount and recipient. And right, we already used two properties that we usually assume a token system has. Two properties that a currency has. And one of these properties is that, okay, perhaps three. So people or accounts own amounts in these currencies or also tokens. And only the owner can send these tokens somewhere. So nobody can take away your tokens. Only you can send token somewhere. And that is basically realized by this signature here. And the second property, which not all tokens have, but most useful tokens have, is that your balance can never be negative. And this is the main check here that is performed in the transfer function example. So it checks that the balance of the sender is at least the amount the sender wants to send. And if that check works out, then we have the effect. The amount is reduced from the balance of the sender, removed from the balance of the sender, and it's added to the balance of the recipient. Okay, and yeah, as I already said, the main problem here is that we only have a small number of transactions per block and thus only a small number of transactions per second. And yeah, payment channels can help a little here. And the main idea of a payment channel is that if we have two people who constantly send money back and forth, then it doesn't really make too much sense to store this intermediate state on the blockchain. It's much better, I mean, if you already know that you will send money back and forth in the future, then it's much better to do that not on the blockchain but somewhere else and then just only once a day or whenever just store the current state on the blockchain. Okay, let's continue first. So we're gonna have a blockchain here, which we call the main chain and there's a special red transaction which calls a function called open channel and the transaction is sent by Alice and it initializes the channel with an initial balance for Alice of 10 and the initial balance for Bob of zero. And this is a channel between Alice and Bob. Only Alice and Bob participated in this thing. And of course the underlying smart contract would check that Alice's balance on the main chain is at least 10, otherwise she wouldn't be able to have this initial balance on the payment channel. Okay, and what happens now? So we get this payment channel and now we can send transactions inside this payment channel which do not reach the blockchain. So they only exist on this payment channel. So we have a transaction sent by Alice here. They're again signed and it calls the transfer function. That's the function we already know but now it's run on the payment channel and Alice wants to transfer three tokens to Bob. And what Alice also does, am I actually blocking the screen for some of you all the time? I'm sorry about that. What Alice also does, she denotes the state of the payment channel that is assumed after the transfer as part of the transaction. So Alice's initial balance was 10 and she sent three tokens to Bob. So now she has seven and Bob has three. And Alice basically signs this whole transaction, this whole transaction, which means she confirms that in her opinion, this is the current state of the payment channel. And she also adds a number to this transaction, the payment channel, which is a sequence number that is incremented with every transaction. Now, Bob can send a similar transaction where he transfers two tokens to Alice. He increments the sequence number, updates the state and also signs the transaction. Okay, perhaps you might ask that this is a quite stupid example if I have two people who send money back and forth all the time, why can't they just agree on how much everyone gets and that's about it. The idea is that, of course, these transactions here, they don't appear in isolation. There's always something happening in the real world or in the real digital world that triggers such a transaction. For example, Alice and Bob both have data storage and they just store data for other people, for example, for Bob, or so Alice stores some data for Bob or Bob stores some data for Alice and they request data from each other. And each time Alice requests, I don't know, 50 megabytes from Bob, Bob sends one token to Alice. And then at some later time, Bob needs data from Alice, so he pays for the data and so on. So that's one of the purposes of such a payment channel. Okay, now time goes on, the blockchain continues and also the state channel continues and at the transaction number 80, Alice has four tokens, Bob has six tokens. This is confirmed by Alice and at some point they decide, okay, let's close that connection and close the channel. And what happens now is that Bob creates a transaction on the blockchain. So this is the second transaction that happens on the blockchain. This was the first and this is the second and Bob calls the closed channel function and appends the current state of the channel as noted here and also the signature of Alice from this transaction. So this signature here is the signature of that transaction and he also signs the full blockchain transaction. And this means we have a confirmation from Alice that this is the current state of the channel and the confirmation from Bob that he wants to close the channel and he also confirms this state of the channel. So there's one thing that could go wrong now and so Bob does have a signature from Alice but the blockchain doesn't really know whether this is the most recent signature of Alice. So whether that's the most recent state of the state channel, of the payment channel. For example, Bob could have taken that, this signature here, I mean that wouldn't really be beneficial for Bob because here he gets six, here he gets only three but yeah, you get the idea I guess. And so Bob can do that but then Alice has the opportunity to also send a message to the blockchain and so okay, what I forgot to mention here is that of course we also have the sequence number here because that's also part of the transaction here. So Bob also sends the sequence number of this signed transaction and what Alice can now do is send a transaction signed by Bob with a higher sequence number than the one specified here. And if Alice can produce such a transaction then the blockchain knows, oh yeah, okay, there's actually more recent version of the state channel that was confirmed by Bob and now also confirmed by Alice and that's how the blockchain will close the channel. Yep, question. You are not allowed to be offline during while a state channel is open. Yeah, you have to watch the blockchain all the time because the other party could try to close the channel. So if one goes offline, the channel's immediately closed. Like it's a good connection. You should close the channel before going offline. And it doesn't always work like that. Sure, but someone is usually offline that could close the channel for you. So if you have, I mean, this also depends, I mean, the Alice loses at most 10 tokens when she doesn't close the, when she doesn't watch the blockchain. And depending on how much money is involved, how much money is involved, you can run different servers in different continents if you want to be extra secure. And so I think that should work out. Another question? Yeah, essentially it must be a gain only between zero to gain only from home. Yeah. It shouldn't be, the third player could cooperate and cheat the third. It shouldn't be possible in this game. Exactly, this is a channel only between two people. So there's, there are only two participants and they can send money to each other. That's it. It doesn't send or increase technology against it. You mean Bob could try to close the channel with Alice 10, Bob 10, is that what you mean? Yeah. So the closed channel function checks that the sum of these two balances equals the sum of the two balances here. Yes. Okay, we saw that some of the transactions here in the main chain were removed. That's why they are, so they were moved here. But the blocks are still quite full here. And the reason for that is we can use payment channel panels only between two people. And if we want to allow an arbitrary number of participants we have to go to something called yeah, side chains or child chains or whatever you wanna call it. Here, so these child chains are very similar to payment channels. The difference is that they run a full blockchain protocol instead of just this single payment channel. And you usually do not close them but instead at regular intervals you just post the current state of the chain into the main chain. Okay, let's take a look at that in detail. Okay, we again have a blockchain which we call the main chain and there is a special transaction that is called new child. And when this transaction is sent to the main chain you can, yeah, a child chain is created. And this depends on your setting but usually these child chains would not be operated using proof of work but for example using a fixed set of validators. So there are, I don't know, five accounts in the world and only these accounts can create the blocks. Yeah, they come together call this new child function on the main chain and they start creating their child chain and the first block here refers to this creation transaction in the main chain and after that the blocks just refer to their parents as in a regular blockchain. And they contain full transactions, they contain smart contracts, whatever you would like. Okay, and now, yeah, so as I said it's a full blockchain so it also has state and the way this reduces load from the main chain is that the state is only stored in the child chain and not in the main chain. Yeah, this is due to limited screen size. That's of course a bad example because usually the balances would start with zero but yeah, that's assumed that's the current state of the child chain. We have four accounts there. It's open to everyone so people can just go there and create new accounts. And currently we have these four and then we have a transaction. Cindy transfers two tokens to Bob. It's the same transaction we had in the previous example on the main chain and the effect of the state is that Cindy's balance is reduced by two and Bob's balance increases by two. And so now the interesting part is that we also have these special transactions on the main chain which call a function called store hash. These functions are called by the people responsible for managing the child chain and what it does is it just stores the hash of the recent block in the main chain. It does not store the full state just the hash of the block which also includes the hash of the state but it's yeah, very little information. And since the people that are responsible for the child chain could just store any hash here there is a mechanism where any user can object just as we had in the payment channel. So when Bob wants to close the channel Alice can object and then a process decides who's right and who's wrong. This is a bit more complicated. I will not go into detail here but there is a mechanism to object. It takes some time and you also have to yeah, provide a little time for people to react. So when someone calls store hash here on the main chain we don't really take that for granted immediately but only after some time. And these child chains also have special transactions and one of these special transactions is a transaction called to parent. This can be used by participants in the child chain to send tokens to the main chain. And here, so Cindy wants to send two tokens from the child chain to the main chain. This effectively reduces her balance and it looks like the tokens would vanish but that's not the case because she successfully executed the transaction and this means it's stored inside the history of the child chain forever. And what Cindy can now do, she waits until there's the next store hash call on the main chain. We have it here. And now we have a hash arrow pointing from this main chain block backwards in time to this child chain, to this child chain block and this child chain block in turn points to the block that contains the to parent transaction from Cindy. And this essentially means that the main chain at this point is aware of the fact that Cindy successfully initiated this token transfer to the main chain. Does it look like you're understanding what I'm... Are there any questions? Okay. So currently we only have this relation between the main chain and the child chain. If you have multiple parallel child chains, you can use this mechanism to send tokens to the main chain and then a reverse operation to send tokens from the main chain to this other child chain. Yeah, I mean, that was a bad example, as I said. So the state is usually empty. When you create a child chain, it starts with empty state. So no one has any balance there. And then you can start moving tokens from the main chain into the child chain. Question? You're asking who the sender of this transaction is? This one? Okay, it doesn't matter. It depends on the objection mechanism, but one way would be that this new child call would contain a list of addresses who are allowed to set the hash at a later point in time. So then I'll say a question. It depends on the setting. You could also use a proof of work chain here and verify the proof of work in the main chain. Okay, okay, that's depends on. I think there was another question. Well, how can you prevent, for example, as I said? So we saw that, yeah, probably I should have started explaining how you send tokens from the main chain to the child chain, not the other way around. Sorry about that. So, city had 10 tokens here and they disappear with this two-parent transaction. So they are completely gone and okay, perhaps let's continue here what happens in the main chain. Then I'll finish answering the question. So we have this store hash function here which means that the main chain can look into the history of the child chain and see this two-parent transaction. So Cindy's tokens become available at this point. This allows Cindy to actually spend these tokens. So, and yeah, perhaps this should not be called transfer but finish sending from child or something like that. So at this point the tokens reappear. Here they disappear and here they reappear in the main chain. So you, and in a similar way, if you send tokens from the main chain to the child chain, they completely disappear in the main chain and it's impossible to spend them because they are just gone. So, not at all. I mean, actually, so this is again due to lack of space. In reality, Cindy has to wait for some blocks to be added here because she has to wait that someone could object to this store hash operation here. And only after some timeout passes and nobody objected then this is assumed to be the current state of the child chain and people can use this thing. If these other people want to trade, want to transact with her in that child chain, you have to transfer it, yes. Sure, but I mean, it depends. So there could be special purpose child chains where for example, some child chain contains a decentralized exchange with very high volume. You move the tokens there, you transact there and you don't need to move it somewhere else. Yeah, yeah, sure, sure. I mean, it's always a trade-off. You don't get arbitrary scalability for free. But so the question is already put into that direction. How can we increase the number of child chains here? And the way you would do it is you create a tree of block chains. So in this diagram, there's no component of time. We have a main chain which would continue somewhere here and then this main chain has three child chains. Each of them would continue somewhere here and then these three child chains again have three child chains and again three. Of course, if you want to move tokens around here, this involves quite some jumps between chains. I do get your point, yes. But you could also, let me think. You could also create a payment channel between this chain and that chain. So you don't have to move up and down again. You only have to wait until the state of this chain got committed here and there and then into the main chain. And if nobody objects, then this payment channel between two chains is established. Okay, before I get more detail here. So what happens here is that we have this main chain and below that three child chains. And this means that this child chain regularly commits its current state into the main chain. And then below this child chain, we have another set of child chains who treat that parent chain as their kind of main chain. And so every child stores their current state at regular intervals in their relative parent. Am I right? Is it a little bit as if the chains divide into sub chains that each define their own domain? And while, for example, customers of an exchange service belong to this domain, it has quite a lot of advantages in terms of scalability. And while they can complex things around the entire system, that would be disadvantageous. Yes, so there is a kind of incentive to move common parts into the same child chain, yes. And I guess that is something that could be done. I mean, of course, so a smart contract blockchain always has special purpose smart contracts. And then it also has general, or then it has contracts which provide the glue between some special purpose contracts. And these glue contracts are, for example, token contracts. If you have a token, then you want to use it with all kinds of different smart contracts in different chains. And these tokens, you have to move between the chains but the special purpose contracts you don't have to move. Okay, and how well does it scale? So let's assume the main chain and also each child chain has 10 transactions per second. This is roughly the bandwidth of Ethereum and Bitcoin. We already told about the overhead that comes with moving tokens around and also committing the state hash and probably also objections and resolving these objections and so on. But since these child chains are a special purpose and since they are probably not proof of work, I think it's reasonable to have something like 100 transactions per second including this overhead. And so I think 10 transactions per second is a good estimate. So we have four levels in this tree on the left in the diagram. If we add two additional layers into that tree and we have 10 transactions per second, then we have 2,430 transactions per second in the whole system which is already above the number of transactions the visa system is said to be currently processing. And if we double the number of levels, I mean it's exponential, so perhaps we can't really double that, then we reach 1.7 million transactions per second which should be enough for everyone. Don't quote me on that. But... Yep, that again depends on the kind of child chain you have but the transaction sender pays for gas as well. Yeah, but if transaction sender is another chain, should he have account in all chains and essentially positive balance in all chains in order to be able to pay for gas in all... But you don't use all the chains. We'll get to that. Okay. There was another question here. Yeah. So it seems to me that basically it only makes sense if you can group similar transactions. Is that, do I understand it correctly? What do you mean by group? It might transact with my colleagues, you know? That should be in certain chain. I mean, it depends on how often you do that. I mean, moving, so the child chain is very, very far down or probably extremely cheap in terms of transaction costs. And the main chain is the most expensive. And so you kind of... So moving tokens around takes a little time because if you wait for these objections, but it's not too expensive. And so if you have to wait 10 minutes for the tokens to arrive decently. It depends. I mean, if you're fine with waiting, I mean, a SIPA transfer, we wait a day for that to settle. With six layers, we need six transactions to go up. How do you move them? So it has to be a built-in feature of the... Yeah. Basically it depends on the token, but with a generic token that is not built for that, it is just moved into a special account and is locked there until it will be used again. What do you mean by belong? So each line in this diagram means that the bottom part regularly posts its state to the upper part. In that sense, they do belong to the main chain. So there can't be a second main chain that has the same time. What I mean is like, are you chain forming this child's chain? These are completely independent blockchains which run on the peer-to-peer system, but are related, I mean, not completely independent, but it's a different system with a different Genesis block, but they are related to each other by regulators and different sections. Child chain? Yes. The chain in the middle has this climate deck and it fails. What happens to the chain after it? You mean below it? Yeah, below it. We'll get to that. Okay, because let's discuss how it is safe. So this system only scales if, I mean, the main problem of blockchains is that everybody has to verify every single transaction. And this system only scales if this is not the case anymore. And so the idea here is that people are interested in some chains, for example, Alice has tokens inside this tiny subchain here. And in order for this to be safe and safe here means nobody can steal her tokens. In order for that to work, she has to watch her chain, verify her chain, and all the parents of that chain. And so because if someone tries to sneak in an invalid state transition here, an invalid block, what Alice can do is that she can object in the parent chain. And because of that, coming to your question, if someone creates an invalid block in some of the chains on the way from Alice's chain to the main chain, then this also destroys the state in all of the chains below that. Because that is the point where you could object. So if you destroy the state here and someone attacks that chain here, then you can't object here anymore because this chain is already flawed. Anything can happen. That's why you should watch. I mean, okay, of course it's not always you have to watch. You can also ask others to watch for you. And so for example, Bob has tokens in these two subchains and he has to watch these chains. And here we already see. The closer the chain is to the main chain, the more likely it is that others are also watching that chain. So this in turn means the closer you are to the root chain, the safer it should be because more people are watching. So if Alice is the only one watching this chain here and somehow our computer breaks and she gets offline, then she's unprotected. But if she has tokens in this chain here, then Bob is still watching it. And I think Charlie, who will be later in the game, will not be able to modify it. Okay, now let's take a look at the specific example of a token. What does it mean to commit fraud in a token system? We already talked about that a little in the beginning. So one of the assumptions is that, so what should not be possible is that someone else moves your tokens. If someone else moves your tokens, this is fraud and you should be able to react to that. And we assume that you watch all the chains that contain your tokens. And since you can always object in the parent, nobody can move your tokens except you. Is that clear? And the second thing that is perhaps not so obvious is actually more complicated to ensure. And this is nobody should be able to create tokens out of thin air. Because if I have 10 tokens and someone is able to create one million tokens, then my tokens are basically worthless. And also that person can buy stuff from you without actually paying for it. So, but this is a problem here. So we assume that this token smart contract is deployed in all of these chains here. And let's see what the next slide is. Yes, Charlie for example, uses this chain here. And we assume that he's the only one using that chain. So he can try to create arbitrary amount of tokens. And if nobody watches, then he will actually have these tokens inside that chain. And the only way to prevent that is again everybody watching all chains, but that's exactly what we want to avoid, right? Okay, there is a, yeah. Kind of solution that does not solve this problem, but it solves a similar problem. And the idea is, okay, right. The idea is that, okay, Charlie can create tokens here, but he can't really use them because he has to move them to a chain where someone else is. Or he has to convince other people to come to his chain. And that's the key to this problem, the key to the solution. Because, yeah, moving these tokens will be difficult if we do an additional thing. If we track the balances of each direct subchain. So, let's see how that works. So in the token contract of the main chain, we store that inside this left branch, we have a total sum of nine tokens. In this middle branch, we have a total sum of eight tokens. In this right branch, we have a total sum of five tokens. And we do that in all chains. I just didn't write the numbers here because the font would have been too small. So, okay, you see that these numbers do not sum up to nine. And the reason is that some tokens are also stored directly in that chain. These numbers only track the sum of the tokens that are stored in the child chains. Okay, but these numbers have to be, that the sum of these numbers has to be smaller, or at least as large as the number on this line. And what Charlie can do now is he can try to move his one million tokens up to the main chain and down again to Ellis or Bob's chain. But the problem is, he won't be able to move it to the main chain. So let's assume he controls this chain, he also controls that chain, and he also controls that chain, he doesn't control the main chain. And he has to invoke this transfer to parent function. And in the parent chain, he has to invoke the complete transfer from child function. And this complete transfer from child function, basically he calls it and says, I want to transfer my one million tokens from this child chain to the parent chain. But the parent chain knows that the total sum of all tokens in this child chain is only five. So it's impossible to move one million tokens into the main chain because there are somehow only five tokens in this. Child chains are somewhere, something must have gone wrong, yeah? Child chain would be to have it in a special account where it's locked and then you only have five in this special console account sheet. So what you're talking about is only for special tokens that are designed to work with these child chains. Okay, what you're actually, what you just said is just a specific implementation of this concept. So if you lock the tokens somewhere, then this is basically counting the maximum that sum of that. So that's how you would have to do it on the token side or not. You want to avoid that because if you, okay, you have one single account where you lock all the tokens or do you have one account per person to lock the tokens? Because if you have one account per person and just declare them to be locked, then it doesn't scale. Yeah, you can just, like, when you lock the child chain, yeah, it doesn't work. Yes, but that's exactly how it works, yes. And, but I mean, yeah. So I mean, if you just use the generic token contract and deploy that, that wouldn't work. It has to have an additional functionality and that's what's implemented here. And so, yeah, but that's also something you have to realize. So Charlie, regardless of how you implement this mechanism, Charlie, if Charlie controls these chains here, then he is able to steal these five tokens from all the other persons because we assume that only this chain, only the main chain is secure. So if Charlie tries to move five tokens into the main chain, even though he doesn't really legitimately have them, he will be able to do that. So he can steal from other people, but if this theft is possible, then this in turn means that these people weren't watching their chains, right? Because if they watched their chains, then Charlie can't get that far up. You can only, yeah, get as far up as they would be changed easily, yeah? Can you just give me, like, a real world example? You run a blockchain client, that's it. It's, of course, it's all automatic, yeah. These are just these terms, yeah. That's out of scope of this, this. So that goes into details of the plasma system and it has to be solved with the economic incentives in the end. Sabotage the whole chain, basically. Charlie, so it will cost you to do such an objection and if you lose, you will lose some money. That's why, I mean, you can, you can spam the chain, but it will cost you money. That's not the same, I mean. We assume that they have identical code. So a token contract that tracks the same token has identical code on all these child chains. Is that the same protocol? You can ensure that when you create the chain. I mean, as I said, there are special contracts and then there are these glue contracts, for example, these tokens, and probably have a native token in the whole system and at the point you create the whole tree, the token contract is already there. The contract can change the state, is it a binary? Or somebody, so-called, in that state. In a sense, the contracts are linked to each other via these transfer to parent functions. Okay, where were we? Yes, and what essentially happened here is that we had these two conditions, nobody can steal from you and nobody can arbitrarily create money. And the first one was a local condition. The second one was a global condition, but we were able to transform it into a condition which is similar, but which is fully local or it's locally enforceable. And it's similar because people can steal money from you, they only can steal up to this amount, and they only can steal from you if you don't watch the chain. All right, no, sorry. People can, so we were talking about the second thing, so people can create arbitrary amount of tokens, but only up to a certain point and only if nobody is watching. Okay. Yes, and this is something that scalable smart contracts have to do. You have to, if you want to write a scalable smart contract that runs in such a plasma system, you have to convert global invariants into local invariants. And now let's take a look at a very specific example. This is how you could implement such a token contract very specifically in the plasma system. This is a slight variation of standard solidity, and we have a token contract here. It has a mapping of balances and it also has this special three integer values which track the sums of the balances in the chart chains or which are the, where the tokens are locked. And so, and this first function is the regular transfer function that is present for all regular tokens. So this can be used to transfer a token from one account to another account in the same chain. You specify a recipient and amount. It checks that you have the required balance and then it removes the balance from your account and adds it to the recipient's account. Okay. Now, so, and then we have these two functions, transfer to child and transfer to parent. These are special because they are marked with the edge keyword. And when functions are marched with an edge keyword, they are kind of executed on an edge inside this tree graph. And this means they are executed both on the parent and on the child. And on, so, this transfer function, when you run that in such a complex multi-blockchain system, you would specify which blockchain you send it to. That has to be part of interactions. Otherwise, people could just grab your transaction and send it to another blockchain. You want to avoid this. So every blockchain has a unique identifier and this has to be part of the transaction. And for an edge function, you send it to a relative parent and to a relative child at the same time. And what happens here is we have a section marked parent in this code. And this is the section that will be run on the parent. And we have a section marked with child and that's the section that will be run on the child. And they will run in sequence. So they will not run in parallel. And what happens on the parent part is that we again check that the balance of the sender is at least the amount. We remove the balance, the amount from the sender's balance and we add it to the sum of the balances in the child. And that's where it stops for the parent. And the parent will, using events, it will register that this happened on the parent and then the system has to wait for the child to acknowledge the block where this transaction is present in the parent. So it has to wait for the transfer of the state from the parent to the child. And then this part can be executed on the child. The client will send exactly the same transaction that it sent to the parent. It will send to the child. And because the child blockchain knows that it is the relative child, it will skip this parent part. But instead, it will verify that the parent part execution happened. So it will look into the state route of the parent blockchain and will request a Merkle proof to verify this implicit event that shows that the parent part was executed. After that, it will execute the child part. And here, yeah, the amount is just added to the balance of the center. So if the child blockchain would not verify the event in the parent blockchain, you could increase your balance arbitrarily because you just send the transaction. The parent part is skipped and this adds something to your balance. But because it actually checks that the parent part was executed and the amount was reduced from your balance here, this is safe. And we have a similar function that does transfer to parent. Here, the child part executes first. It checks that we have the balance. It removes our balance. The amount vanishes completely. But in the child chain, we will have an event that stores the fact that this part has successfully executed. And then at some point in the future, we have this store hash transaction that stores the current state hash from the child in the child, of the child chain in the parent chain. And at that point, the person that sent the transaction can prove that the child part was executed successfully in the child chain. And that means that the execution of the transaction in the parent can skip the child, verify that it was executed in the child, and then continue the execution in the parent part, which checks that the locked balance, that the sum of the balance of the child is at least the required amount, removes the amount from the child balance and adds the amount to the sender's balance in the parent chain. So balance here and balance there are two different things. So this is in the context of the child chain and this is in the context of the parent chain. But because the contracts that are identical, because they share the code, this works between the two chains. I'm going to second the function. The second edge function, the parent waits for the child to be done. How long will it take for something at the top of the chain, like the top chain to wait for all his children in recursive way? In the case you want to send a token from a child very down to the main chain. I mean, a single transfer from a child to a parent just requires, yeah, this period where the child chain stores its state hash in the parent plus the objection timeout. And if you do that multiple times, you multiply that by the depth. But you could also, I mean, yeah, you could perhaps take some shortcuts and look deeper in the go, look down multiple levels because you just have multiple levels of work approvals. Is it proposed specification or is it just an example of how it could look? Both? I hope you like, because it suggests that we only have three fixed channels, sub channels for three children for every channel. And then, yeah, I mean, yeah, the- How to choose a child, if he's not here. The proposed specification, I mean, the number of children doesn't really matter. You just have to know the topology of the system. And then, I mean, if you send such a, so a parent has to know who are its child children and the children have to know who is the parent, but you can also have a dynamic number of children per parent. Yep, this is, so the objections are part of the base layer, part of the blockchain itself and not part of the smart contract here. So this check that happens between these two sections that should also include the waiting time for the objection, perhaps, I don't really know. So that's abstracted away. We assume that we have a blockchain system that works with objections and transfer of information using these hashes. And perhaps we have to wait for the time out. Perhaps there's a possibility. More questions? Sorry if I don't understand too. Well, okay, basically, somebody actually need to pay the gas for this, for putting the hash marks on the regular intervals, you know? Yeah. So you basically, if you have a dedicated offer there, the dedicated group offer there, you are kind of creating a bank. So I'm kind of curious what's their objective for these chain maintenance or transaction fees? So, I don't know, there are certainly models. You can have intrinsic tokens that you can just create out of thin air to pay for that service like you do in proof of work blockchains or in some proof of state blockchains, too. Yeah? So who could start a child chain how would it be determined who can join the child? That again depends on the system, I mean. There's no reason why, I mean, that system can be implemented on Ethereum right now and anyone could start a child chain. So is there any, okay, so the proposition, but I actually planning to include it into Ethereum like as a functionality? I mean, there is a proposal by Vitalik to add a certain pre-compiler that would help here, but you don't really need it. I mean, there's no, so there's just an issue that these operations might consume too much gas, but you don't need a specific functionality. So you could just do it with a smart phone? Yeah. Or like a white paper or a plan, how long would it take to actually have this life on Ethereum? I can't really tell. No, you don't have years for... Probably not, but... Yeah, yeah. And one question looking from a greater distance to these developments, how does it present itself, this plasma project, in comparison to other approaches to scale the block chain, like Polkadot, for example? So, yeah. Polkadot, Scharding, Plasma, CK Snarex, Raiden as a specific, but also very different from specific, simplification of Plasma. Okay, so this system is tied to one specific main chain. It's weaker in security than Scharding because it depends on these timeouts, and anyone, yeah, but at the same time, it's also much more flexible because anyone could just create a child chained at any time. For Scharding, that's probably not the case. Polkadot is not tied to a specific chain. It tries rather to be a mediator between different chains. Raiden, in its current state, cannot be used for smart contracts, only for token transfers. There's this more general concept of state channels. But, yeah, does that answer your question? How would you prevent someone from just sending the same message twice and receiving the money quite so? So if I have five tokens on the main chain, I can use the transfer of the child with the amount of five, once, and then I can recent the same transaction and on the child chain, it would just check whether the transaction with their hash was executed in the main chain, which it was once, and so wouldn't you have to keep track of the already used? Yes. You have to keep track. So basically executing the first part creates an event, and then if you want to execute the second part, you have to prove that the event has happened and then that it was not used yet. This usage, you have to use such a usage counter. I think you said at the beginning that this is possible on Ethereum and not on Vectronus, right? Yes. More questions? Okay, yeah. Thanks a lot for telling me the talk and thanks a lot for attending the meetup. Yes, so we do not yet have a fixed date for the next meetup, also because there is this conference that has a lot of talks that have to be prepared, but perhaps we'll have the next meetup sometime in December. And if you want to give a talk, then please approach me. And yeah, I think this venue was a lot better than the office, and it also has some drawbacks, but having a lot of space and a clear view of the presentation, I think that's a good thing. So yeah, thanks a lot and see you next week.