 Hi, everyone. I'm Joseph Poon. I'm here to talk about plasma, and this is going to be sort of an overview for about the first 10 minutes. So if you've already seen the other presentation, a little bit of this might be a review. So the second half is going to be sort of exploring the narratives around, you know, data availability and the data availability problem. Vitalik has been talking about this data availability problem for the past several years, and it's very critical when it comes to Ethereum-based layer scalability such as sharding. And today I'm going to be talking about the implications of data availability when it comes to building transactions when we're talking about plasma in particular. So plasma is a project that right now is being architected and after that will be written and it's co-authored by me and Vitalik. And hopefully, you know, a lot of people in the Ethereum community can contribute because I think this can be, you know, this can be a lot of fun. So plasma at its core is about building a blockchain on top of a blockchain. So you write the smart contract inside Ethereum and you initialize it by basically taking a library and modifying it to whatever particular use you need. So for example, you can build, you know, some social network, some decentralized exchange, or even some private blockchain. I think the private blockchain example is pretty interesting because you can build a private system with your own rules, with your own participants, with whatever terms you want, but also enforceable on the public network. That's pretty effective because right now a lot of private blockchain systems are role-playing, right? A lot of the systems they're building today can be modified by the operators of these systems. If it's these five people, then you're sort of like, well, all my money is sort of at the whim of these five people. If you bond your activity in a private chain to a public network that allows everybody in the world to sort of say, okay, this allows the Ethereum network to sort of be this base layer for all of these private chains interacting in the future. And that could be an interesting aspect to develop on. And the way this works is that in the smart contract, you make it so that the consensus rules are defined inside Ethereum itself where you upload the smart contract and it's enforceable via fraud proofs. And each individual plasma chain has its own consensus mechanisms defined inside the smart contract and it could be written in solidity or in the future more likely viper. And the goal is to build decentralized applications at scale where you can create billions of transactions per second is sort of the goal given certain security constraints. The presumption is that you're not really trusting them. And the way you do that is that, let's say you're Alice, you have one ETH held inside this plasma chain and this plasma block periodically commit block hashes onto Ethereum. So it's very, very small measured in hundreds of bytes, which can encompass perhaps gigabytes of data. This is not proof of existence. Proof of existence is another form of like role playing that people use when it comes to building blockchains inside blockchains. This is actually enforceable. The notion is if you create an invalid block, if a block is invalid, it can be penalized and rolled back. And what this allows you to do is allows you to create a lot of transactions inside a system. This is of course assuming data availability and data availability is an interesting problem that we'll get into in greater detail later. And essentially this is an example if someone submits an incorrect transaction, an incorrect block rather. And then what happens is someone submits a proof onto Ethereum and you submit a Merkleized proof. And it's actually very similar to the previous presentation about Trubit, where you have Merkleized Enforcement and Merkleized Attestation. And by having Merkleized Attestation, you can represent information in a very, very compact way. So for example, if this very, very specific, let's say 100 bytes within a block inside this plasma block is invalid, you just say, okay, these 100 bytes are invalid, here's a proof that these 100 bytes were inside this plasma block and then you submit that inside Ethereum and it's very, very compact, that allows you to say, okay, one piece of this entire block is broken, let's roll it all back. And then in that moment, that individual, the individuals that created that block get penalized and that allows some measure of honesty when it comes to propagation. But the core notion of plasma is not around the notion of Merkleization of Information. The core notion is about exiting in the event of data unavailability. Data unavailability is an interesting problem because you can't prove when someone is withholding data. It's sort of like, if Alice and Bob says, oh, I gave the data to Bob and Bob says, no, Alice didn't give it to me, who do you know is right? You really can't be on having this trusted third party and in Ethereum, we try to reduce that as much as possible. And what you can do in Plasma, this core of Plasma's construction, is this allows you to exit in the event blocks are withheld, so Plasma blocks in this case. So it's saying that if you, if let's say block number four is committed, so this 100 plus bytes is committed onto Ethereum and it's like, wait, I don't have this data, I can't prove this as false, I can't prove this invalid. So then what you do is you then submit it and then when you, when you, not submit it, you exit and basically you exit from that chain because you're like, well, someone's not giving me the data, there could be bad data in there, there could be bad state transitions. It's sort of like, if a party starts sucking, you just leave. You don't try to make, you know, like, it's like a party's a disaster, you're just like, well, you can try to make it better, but you could just leave and join another party and it's much more fun that way for everybody. And the fun part is when you do blockchains and blockchains, you could do blockchains and blockchains and blockchains and blockchains, and that gives you even greater scalability where you could do like potentially billions at this point, representing a single use case, for example, you know, like fun posting in some live chat, you could, you could do that and like, you know, build a system where you could, you know, make that enforceable in some way. And that gives you a great deal of computational scaling. This is not just computational scaling of financial activity, but potential anything, you know, this could be a system where, you know, you, you move from, you know, centralized data services where, you know, like Reddit or Twitter or whatever it may be, and you can credibly decentralize this since capacity is significantly increased to an incredible degree. This also lets you do computation using MapReduce, so you go like, okay, map, and you so map out all the blockchains and blockchains, they do computation across many, many different blockchains, and you reduce the results back down, it's sort of like returning variables. So you just have one way of splitting up the work and one way of returning the work, and that's sort of how you reach incredible computational scale. So the design goals is, you know, one blockchain can encompass, you know, all worldwide computation, maybe not all is in everything, but all is in, like, you know, there's no necessary constraints given, given the security properties of the system. And the goal is to do trust minimization where you're not trusting the people operating these plasma chains because you can ultimately go to Ethereum and enforce invalid state transitions. And the goal is to payment and ledger scalability. Ledger scalability is interesting because ultimately you want records, and it's sort of like state channels get to you, like, you know, an X percent, X time scalability, this can give you, you know, many, many X, and, you know, Ethereum charting can give you many, many other Xs, and then at that point you can reach incredible scale. And I believe that, you know, this is very much in the near future, you know, measured in, you know, you know, very short time frames, not like 10 years plus, but closer to like low digits amount of years. But, you know, transaction data is, I think, can give you an example of the problems that we're dealing with. This may be a little bit, you know, more architecture. So if you're a little bit, you know, it may be a little bit hairy, this requires some knowledge in the way, you know, atomicity works. But basically what we're talking about is that, you know, you want to create a transaction, and you want it, you know, and let's say you just broadcast it inside this plasma block, you're done, right? Not really. You can't attest to this payment if the block is being withheld. Remember, like that block number four I was going over earlier? If that happens, then if, you know, there's, you make a payment, you don't really know if that payment is in there, and like, you don't know if the correct amount is in there, you don't know if the current state is correct, it's just being withheld from you. And you can't even prove that it's invalid. It's sort of like, all you can do is just say, well, maybe my payment is in there, maybe it isn't in there, or maybe it's wrong. And if it is in there, and you try to withdraw an old state, then you get penalized. If you try to withdraw and it isn't in there, well, that makes no sense, that won't work. And if it's incorrect, well, you have a big problem, right? And normally, when an incorrect state is attested to, you just exit. But in this case, you may not have enough information to exit. So that's sort of a problem that needs to be addressed within the context of data availability. And, you know, you're not sure if that, those funds are even, are spent even further, right? Someone, maybe that transaction went in to this plasma block, and maybe later it gets withheld because it gets spent, a separate transaction spends it. So that could be a big problem. And this problem also exists when you put funds into a plasma block as well. So how do you address this? You address this by creating this two phase commit process. This is a very different, different way to do it. This is not a hard necessity for a lot of problems. But if you want 100% certainty, this is sort of how you would do it in the event of data withholding. We don't have this problem on the Ethereum base chain, right? On Ethereum, all you do is use broadcast of transaction. It gets confirmed, you're done. The reason it's not a problem in Ethereum is because it has presumptions of everybody having the data available. Ethereum works by, I receive blocks. I don't trust anyone else, right? Anyone else on this network. And when I receive it, I compute it, I validate it, and I just make sure that it's true according to the consensus rules on my computer. And what happens is I can process the current state, but you could also do a full replay of the entire blockchain history in order to have 100% assurance. That's not necessary, but you're capable of doing that because you have the data available. In this case, when you split up into all these different plasma blocks that are only committing very small pieces of data onto the Ethereum main chain, what happens is, is that in this plasma block, there could be information you don't know about. And when someone's withholding, you could exit. But what happens if, you know, like, you don't have all the data? So in this case, what you do is you create and broadcast the transaction, much like you do normally. And in this case, the plasma block gets signed by a validator, so it gets included into a plasma block. And then step three is where it gets weird. Alice commits that she saw her transaction get submitted to a block and she can give that to Bob or she can submit it onto the plasma chain so that there's like a second record. So it's sort of like, I submit a transaction and I submit another transaction saying I saw the first one. And then at that point, when Bob sees that second step, whether it be directly from Alice or from the plasma chain, Bob now has assurance that the money is his. Why do we do this? Right? Alice needs to be sure that the transaction has occurred and she's able to reference it. Remember that Merkelized proof stuff? So Alice now is able to reference that that transaction existed and now Alice is able to be assured of it and now she's willing to test that, okay, this money is no longer mine. And this is sort of the one weird trick to make this all work. And as Bob, you're only willing to accept the funds when you receive that second step because at that point, Alice cannot claim the funds according to the consensus rules written in, you know, solidity or a viper on the base chain, on Ethereum, basically. It says, okay, once the second signature happens, Alice no longer has any claim to the funds. And essentially we're dealing with three parties here. Alice, Bob, and the plasma chain itself. So let's go over these four steps. There's Alice, there's Bob, this is the chain and that's sort of the state, so that's the third thing I was talking about. Alice has one ETH. The plasma chain is there and then Ethereum on the base layer which periodically gets commitments and exits and deposits. So Alice signs a payment. So this is like very similar to how Ethereum works. You just send a payment into the plasma chain. Ultimately, a plasma chain creates a block and then it sends a commitment onto Ethereum and it says, hey, I made a block. Here's a couple hundred bytes. Alice and Bob then get the data of that plasma block and it says, okay, I see this block is legit, okay, there is a payment going on. Alice and Bob both see that there has been a payment from Alice to Bob. Notice on the top right, it shows Alice or Bob because either Alice or Bob can claim this according to the chain itself. Step three, this gets a little bit tricky but it'll make sense. So Alice then submits a commitment signed by herself that she has seen that previous transaction and essentially she's able to prove it because she sort of can see the data there and sees the Merkleized commitments. So she's like, okay, cool. This money is no longer mine. She passes it off into the plasma chain and Bob and now from her perspective it's not her money anymore. If she tries to claim it that's bad news for her because she's not able to do that or gets penalized. For Bob, it's sort of like, well, okay, if he hasn't received it yet, oh, there's a slide skipped. Oh well, anyway. So for Bob, he, let's say Bob hasn't seen it yet. That should be a dash. Then Bob doesn't yet know whether it's Alice's or Bob's. From his perspective it should be Alice's and for the chain it sees it as Bob's because you know it received that transaction and confirmed. In this case now that should be a dash line to Bob, not dash, a solid line to Bob so we're correct here now. Bob now sees the funds as his because he has that commitment and the original transaction. So Alice now has no claim and in the top right you now see Bob has the one ETH. So creating this two-phase construction allows Bob to know that Alice no longer has any claim to the funds and Alice has assurance that she does not, she will have the funds available if the block is withheld at any point in time. So as an example, let's say Alice tries to maliciously withdraw the funds. If Alice tries to withdraw the funds during step three, what happens is that when it's not fully committed to Bob yet, she submits a transaction onto the Ethereum main chain, the Ethereum root chain, you know basically what we call Ethereum today and let's say the holding period is 14 days before she can correctly withdraw and she has to put up a bond. Assume that Bob believes that the money is his because he has the information available to prove that Alice has committed to the fact that she saw her original transaction. Then what Bob can do is take that proof that says Alice says hey I saw this transaction hit the block, here's a proof that this transaction hit the block and here's a commitment that I have submitted this transaction. Bob should say okay that money is mine now but if Alice tries to take that money, Bob can submit to Ethereum that says okay Alice tried to submit this, Bob sees it on the blockchain and he says okay Alice screwed up or is trying to take my money, here's a proof because Alice gave it to me and I saw it on the chain and now what happens is Bob is even happier because she takes her bond and it's his money back. So this type of construction by constructing a two-phase commit process, you're basically making attestation on information availability and this is going to be I believe be an emerging theme when you're dealing with states where not everybody in the world has information, right? We're not dealing with global state anymore, how do we deal with this, right? In channels the way we deal with it is we can only move forward if both parties have it available but you know we're dealing with perhaps thousands of parties, billions of parties maybe eventually and you know different people have different sets of data so you know the goal is to be able to make it so that you can have attestation correctly and to scale and you know perhaps you know the blockchain can be the ultimate arbiter in this case Ethereum can basically be the Supreme Court of computation across the world. Thank you.