 So I will try to make it as technical as possible. So apologies if it sounds like too deep of a dive, but I want everybody. So I have 20 minutes, so in 20 minutes, you'll learn what PlasmaCache is, how it works, where it works, where it doesn't, and why it's the most viable solution currently, at least at the current research levels, because all the other solutions I'm of the personal opinion that they're quite, let's say, optimistic and ambitious and it will take some time until we have them in production. So there's my slides. Yeah, so who knows here how PlasmaCache works, like has tried implementing it in a low level, essentially. Oh, shit. Okay. Okay, so the point is that the other Plasma constructions, the original Plasma paper, it was very, very important because it gave the notion of what Plasma is. It should be like the Satoshi's vision thing, Vitalik's vision, whatever you wanna call it. However, it was totally unrealistic. It has this whole map-reduced construction. It had a bunch of the dream of the tree of change and now everything communicating with each other, like the Supreme Court. I'm not of the opinion that it works, so this talk will be highly opinionated on what I'm thinking, how Plasma is and works. So take this with a grain of salt. This is not expressing the general, let's say, opinions of the Plasma community, I guess. So, yeah. Test, test, one, two. Yeah. And the point is, okay, anyway. The thing is that the Plasma, it works like with a classic side-change construction. You have a main chain, the side-chain. You deposit your funds, you do whatever you like on the side-chain, you can take them out. But the thing is that in order to get scalability, we actually need a consensus mechanism that advances faster than the normal mechanism, than the base-chain mechanism. And you cannot do that, in my opinion, by definition. You need to make some compromise on either decentralization or the security aspect. And so, what we're doing is that with Plasma, you construct essentially a non-custodial side-chain. Because at any given point in time, if there's some invalid state transition, you can go through this exit game and you can just get your money out within a certain challenge period. Yeah, maybe, how do you handle this? I'm not exactly sure. I have a bunch of nice shapes and all that to explain it. So, the whole difference between Plasma Cash and the other variants, it's because the Plasma Cash, it's non-fungible. It is in the family, let's say, of Plasma protocols, that it's the securities enforced by the non-fungibility of root-chain deposits. So each coin you deposit has a unique ID. It's different from each other. And you can use it to have a sort of a simple exit game where each coin is unique. You don't have to use the whole priority queue for the construction to go through your, what you call it, to make multiple exits. There is no need for the mass exit construction, which is very important because currently, all the other Plasma, non-Plasma Cash variants designs, they require mass exits. And they will make the claim that the mass exits currently aren't viable due to how, like, let's say primitive, like our signature aggregation works on the, we are not very fine enough. Even if you do a multi-signature and you compress it and you do a threshold signature on all of them, you cannot actually verify the whole thing on the EVM. Yeah, and like, okay, okay. So Jeff just said, like, explain why Starks are better than XT-based checkpoints and whatever our RSA accumulators. So first of all, quantum resistance. Okay, so the argument is Plasma Cash has a very big, let's say, disadvantage that whenever you're passing coins around and as the side-chain progresses, the coin history grows linearly. So I have 10 blocks. I need to pass around 10 blocks worth of proofs. And this sucks. So what we can do is, one, we can just pass around the proofs. Two, we can do checkpoints, but which is a very brilliant construction by Kelvin. However, this thing, it requires so much social coordination. It's like on the level of the mass exits and I'm not sure if it works. So on the contrary, what you can do is that you can use the RSA accumulator, the RSA accumulators recent construction, which you assign a unique prime number to each leaf and you make some black magic on it and you can somehow prove compactly that the coin history is valid. And the final, the very sexy alternative is that you can just take the whole history, you make a stark proof, you put it on a black box without any trusted setup or anything that you don't like and just have a compact proof that can be transmitted to your receiver. And actually in these cases, we never need a non-chain verifier to do that because I'm just, I want to prove like, let's say to Jeff, I just want to tell him that, you know, I have this coin, take it, and he proves it on his own and the verification is very fast. And yeah, quantum resistance because we need to be like anticipating the quantum computers, they're coming to get us. But where's my slides? Yeah. More, yeah, Q&A, exactly, more questions, please. So actually, yeah, I'm pretty sure I can answer like any technical question. So hit me with your best shot and if I don't answer, yeah. Why do we need to worry about quantum resistance if we're not even sure if the systems work yet? Like we're going to iterate multiple times. PlasmaCache is real. Is it because it's going to exist in perpetuity for a long period of time and then future quantum computers are ready? I mean that generally we need to be like looking ahead and like protecting against a, so to rephrase, if we can have a quantum resistance scheme in one year, I believe it's much better than investing six months in a non-quantum resistance scheme. So I'll just chime in for a second. So I think the danger is, is if we encrypt all this data and we have like our browser history encrypted and then somebody gets a quantum computer, we're all screwed, right? More Q&A, more Q&A. Okay, so how do you get started? Firstly, Kelvin and friends have done like a great, great amazing educational effort with the site called littleplusband.org, if I'm not mistaken. But I am of the opinion that, where's the timer going if I don't have slides? But I am of the opinion that, I literally cannot show you how one thing works if I give you 10 links, it doesn't work that way. So I've been writing a plasma paper, like okay, I will talk about my work, right? I've been writing a sort of plasma paper that it's like a 20-pager that you read in maybe two hours and you can like understand everything about plasma, this variant that I'm working on. So you read it and basically you should be having like a pretty good idea of what's going on. And implementing a plasma contract isn't actually the hard thing. Implementing the client software is the hardest thing because the smart contract, you define it like you give it, like you need to do this for exit, this to withdraw, this to deposit, that's all there is to it. And you add the submit block function to commit the Merkle route. And that's it. But the client software, it needs to watch, it needs to cash state because if you pull the Merkle proof, you need to save it. Because if you don't like, and you restart your client and you don't have the proofs, you assume that whatever entity is providing you the data, they will provide you the data. And if you do that, why even bother with plasma? Which is, I'm pretty sure there is some like plasma variants that assume some sort of data availability and you shouldn't ever assume any kind of it. So yeah, just read, learn plasma. Like I'll give a link to the paper at the end. Yeah, anything going on? More questions. Yeah, yeah. Anything, anything, seriously. Yeah. So I do not work on MVP, but again, my opinion, I don't think light client verification works on MVP. I'll put very contrary on your opinion, so always with a grain of salt. So MVP, it requires you to validate the side gene state, which by definition it contradicts the scalability because if you need to do full client validation on the light clients, you can never run like a secure plasma chain on your phone. You can never like validate the secure plasma chain on your phone. And you need to do that because otherwise you cannot be sure that the plasma chain is not a fractional reserve. Like if there is withdrawal from it and you didn't take note. So yeah, that's why I'm very bullish on the plasma cache because everything that happens on chain, you know it at that moment. So, okay, plasma cache, blah, blah, blah. Okay, so why is plasma, you have the main chain, the side chain, like you deposit some funds, you do the funds whatever you like. We talked about this already, so I will skip this through. The big detail that we need to insist on is that each block must be submitted and the gas costs for this, they kind of stack up. I actually really like this purple color, it's very satisfying. So you checkpoint each block and the moment you consider transaction finalized, this is like a security property that you consider transaction finalized once the block route has been committed and the witness data, the Merkle branch for that transaction that you're looking for is made available to you. Because if that data is not made available to you, you literally cannot know if the transaction was included or it was answered. So, just a moment to just say that plasma cache is real, it's working right now, it's live right now, you can do MPM install like this thing, you can run this command, these are two real addresses and you can connect to Rinkeby via Infura or your own node, but nobody runs their own nodes unfortunately, but yeah, shout out Bitcoin. And this is like how the thing looks from the inside, you type help, you have a bunch of commands. The user needs to do the very, very minimal amount of things, just need deposit, transfer, exit, withdraw, that's all you need to do. I'm of the opinion that you never should force the user to do anything we are even watching, it's all in the client software. And yeah, whatever, you can demo it if you want. I won't do a live demo because it's total hubris, it doesn't work. So, okay, I've written this thing, you should try to read it, give me feedback and so on. I'm basically trying to do what I said before, I'm trying to do a very concise overview of how PlasmaCache works and what's it about. And soon I will have some more formal notation of how the exit game and the finalizes and the state transitions work. So, first of all, why? It's real, we can do it in pretty realistic time frames, I believe that I started working on it on May and we had an implementation within a month and a half, so it's real. We have low data requirements for the live clients, okay, it's not really low, but it's lower than any other available solutions, I will claim it's low. And you can have this modular architecture where if anything that you don't like, you just add the plug-in, so this whole naming convention thing, yeah, I'll talk about it also. So, I believe that this is a very good quality slide to get people to understand what are the difference of each variant. So, the ones that we are working on and much thanks to Rangely for maybe I said the name wrong for all the discussion for this, is that whenever you deposit the coin on this variant of Plasma Cash, each coin is unique. So, you have this like, this gives you like a very simple exit game and it's very like, the security is tight. And what you can do is that, but it has some problems, it doesn't have like fungible payments, it doesn't have, it's a history good like hell. So, what you can do is that you can either like use some magic like RSA accumulator zero knowledge proofs to prove the coin's history in a more compact way. And the other thing is that we need to like, if you want to do like fungible payments with multiple ones, you can apply the other technique that you break a coin down in 100 pieces and you have the user transferring the sub pieces of it and whenever you're speaking about a coin, you're actually talking about a range of coins. Or just use state channels, yeah. I'm a very big fan of state channels from Plasma, but we'll talk about that later. So, the other variants, there are the Plasma MVP ones, which I argued earlier that they require too much data and they also require sort of priority queue construction for exits because if the operator is basically able to create a huge GTXO which exits the whole chain, which would make it a fractional reserve and you need a mass exit, which to my knowledge, there is no working mass exit scheme to date. And on top of it, you can add the more viable Plasma, which Kelvin has thought of to like solve you to make UX better and maybe most viable Plasma one day, I don't know. And yeah, you can use snarks to verify the state transitions from like one thing to another. So currently what we have is that we do transaction routes. So anytime you submit a block, you don't actually submit the state route. So it's not the latest state. So you need to like go literally through the whole block history. Well, in this case, you just have the state route and it's like, it's there. You know it's there because you have this, whatever black magic box that it proves your assumptions. So I'm pretty sure this is a good taxonomy on like which are the variants of Plasma. And there are, okay, to be fair, these are the variants that are based on payments. And the payment, the variants that are based on smart contracts, I'm not well informed on them. But they're very fun. So to do like a quick technology primer. So the main data structure that we use in Plasma cash, it's a sparse miracle tree. It's basically a tree which has all the, it has like whatever leaf amount you want. It's all pre-computed. So it's all like in the default values, it's the hash of zero or whatever null value you want. And to prove the inclusion of an element, you do it in the classic way that you just provide the miracle branch with the siblings and everything. I'm assuming that people know how a miracle tree works. And the fun part is that you can actually prove non-inclusion by giving an proof of inclusion of the zero hash of the hash of zero at this leaf. And this is very convenient because we can, this is what basically makes Plasma cash work. And you can actually have some very nice optimizations on top of this. So because all the values are pre-computed, when I'm giving the miracle proof, I do not need to give like 32 bytes every time. Whenever I want to give the default value for a sibling, I can just give a bit field. And this, like it's literally one bit where it's 32 bytes. And in this very simple example, so like in the, normally the miracle path could have been hash of zero and the higher level one. So it's 64 bytes. Well, with the optimization for the bitmap, it's two bits. And much love to the world team for thinking this up and having a working implementation. So the usual suspect. Alice deposited five ether was like the actual flow. So, pardon me. So Alice deposits like five ether to the smart contract. The smart contract emits some deposit event that the Plasma chain listens. The Plasma chain is supposed to create a new block. One new block per deposit. This is not a security requirement, but it makes proving like it's an optimization, basically. This has been asked a number of times, just deposit the coin and you get a new block. This isn't necessary, but it's better. And what it does is it creates a Plasma block and you get literally a five ether bill, if you will. And the thing is that the transaction flow, it's like UTXO based, but it's one input, one output. I cannot break a coin. I just say new owner and that's a new owner. Just like gosh, yeah. So I'll just go through a simple example of how the transaction flow works. So Alice deposited the five ether, like the five ether example. So five ether, it just appears. Alice gives the coin to Bob, but the thing is that at this moment, Bob must actually verify that the coin's history is valid. And now let's consider that there is a new block where Alice, where Bob, who is the latest valid owner of the coin, doesn't move the coin. And if Bob wants to give the coin to Charlie, Charlie must not only verify the inclusion block one and two, he must also verify the non-inclusion in block three, which is why I spoke before about the non-inclusion proofs in sparse medical trees. And he needs to do that because considering the fact that there might have been a transfer from two to three, the two to three would make the two to four a double spend and we don't want double spends. So yeah, and he does that and he exits by providing an ancestor. There has been some discussion lately that there might be a way to optimize this to not require an ancestor, but I'm not sure about the safety of it if you want to evaluate it, fine, but I haven't been able to evaluate it. But basically the thing that we know that works currently is you give it a coin and the parent coin and you use these to exit. And I will go over the exit games, the game that's played very soon. So the whole plasma constructions, they work based on a challenge period, like the classic dispute period where I make a claim, I put up a bond, I wait some amount of time, and if nobody challenges, yeah, my claim must probably be right. It's all crypto economics, I hate that word. So the time currently and the bond amounts are totally arbitrary. I'm of the opinion that somebody just wrote the first MVP implementation. Maybe it was David, actually. It just put seven days for an exit period and everybody said, that's it, the holy grail. Or maybe Vitalik said, I don't know. But the point is that currently there has been no game theoretic proper analysis on what the challenge period should be and what the bond amount should be. And I'm very interested in that. So if you have any research on that, please speak to me. And yeah, so this is like a good takeaway from the presentation that we model each coin as its own state machine. So state machines, like it's, yeah, we have the initial deposited state and basically you define a transition function that whenever you want to go from one state to another some certain things need to happen. And what you do, it's simply like whenever you want to go from deposited to exiting, you start an exit and you put up a bond. The start exit, you put whatever proofs you like with. That's another. And there are two types of challenges. The one type of challenge is the interactive one and the other is the non-interactive. So I'll speak about the non-interactive, which is simpler. So the non-interactive challenge, it is essentially I see a claim and I instantly challenge it and the exit goes home. Like it never happened, right? And it's a simple form of challenges. However, the interactive challenges, essentially in order to finalize an exit, it mustn't have any pending challenges, any outstanding challenges. So what you do is I start an exit, somebody else challenges my exit and in order for me to be able to finalize my exit, the word exit has been said many times, you need to actually respond to the exit. And like you have, let's say you have a counter, a challenge counter that goes up and down and the only way to finalize it is when it's at zero. I hope this slide is clear because it's like more or less the whole construction of how it works. And now I'll talk about the challenges. So I'm hoping things are clear so far because like this where we're going to the examples. Let's say that Alice has a coin at block M, whatever you like and Alice spends the coins, she gives it to Bob or whoever else and Bob maybe then gives it to Charlie. So the thing is that Alice isn't forced to exit from the latest stage. She can always go to a stale state and just say I'll exit. So yeah, she can do that, but the thing is that she needs to wait seven days or whatever to do the exit. And at that point, another entity, they can challenge by providing a spend. So Alice essentially makes the claim I'm the latest owner of the coin and then the challenger comes and says no, you're not. Basically, that's the whole thing that you need to know about it. And this is the one type of attack that you can do. And this shout out to Carl because he did like a very good like specification which explained all that stuff. I used it, you should use it. The other alternative is that you do double spend. So the example I was talking about before, I was considering the fact that Charlie the or Alice prime, not plasma prime, is actually like, it's not a colluding party. So what can happen in this case that Alice gives the coin to Bob and Alice in collusion with the operator, they double spend the coin. So they give it themselves, some other friend of them, whatever. And what happens in this case, if Charlie wants to exit the coin, he needs to provide the parent, as I said. And the whole like exit game here, it works that you need to provide the coin that is in between. And this actually proves that double spend because you say no, I owned it before you did. And yeah. And the final example of like the exit game is that when you're exiting a coin, you actually, so when you're receiving a coin, you actually validate the whole coin's history. But what if you don't? So I want to stress that in this example, like try to imagine that the red arrow doesn't exist. It exists, but it's like the response state. So let's say that Alice has a coin and that the operator, they collude with some party to give a coin to Bob. So they make an invalid state transition. So to say in Plasma MVP, if an invalid state transition happens, the whole chain has to leave, which isn't possible, seriously. So what you do is that if somehow Alice, somehow there's a transaction that gives the coin to Bob and Bob starts to transaction with this coin, there's an invalid state. And if Bob, Charlie, Dylan aren't malicious parties, they will check the coin's history, but they're trying to steal the coin. So Dylan tries to exit. And at this point at the seven day period, Alice can say, no, I am the latest of the owner of the coin. In this example, what you can do is that you can actually respond to the exit. So this is the interactive challenge. The previous two, they were non-interactive. In this one, when you make an exit, when you make a challenge, you leave also some amount of time to respond. Because if Alice made an invalid exit, an invalid challenge, somebody should be able to respond. So that's where the red arrow comes in. That you should be able to bridge, essentially. You should prove that there is actually a spend from Alice to Bob and it validates her challenge. And there can be a number of these. So you can have multiple challenges within valid histories. And the final result is that you want it to be, you can only finalize the exit when it has zero challenges. So from my experience, towards building a client, it has been a pain to actually keep, on the implementation part, has been a pain to actually keep the plasma contract and the plasma chain in sync because you have essentially a cron job which submits block to the main chain and to the Ethereum, whatever you wanna call it. And the thing is that you have to make, essentially, you mustn't make any synchrony assumptions. At any time, like any state that is in the chain, it must be checked point. But if there is a delay, or if for some reason the cron job submits a block twice, your chains are out of sync. So the main chain contract gets a block 10 and the plasma chain is a block nine. So that's bad. And that also relates to the second bullet point that whenever you're listening, so the plasma chain actually listens for mainnet events to actually modify the state and you need to apply them in the right order because if you don't, the state will be botched and so it's a problem. On the client side, so this was on the operator side, let's say it have a correct, honest operator or software. On the client side, you need to also, whenever you go offline, you need to save the block that you went offline and when you go back online, you need to check everything that happened while you were offline. It's like, it sounds like bad but it's like actually what happened with full nodes but I guess it's our approach towards full nodes but with like very light clients. And yeah, I'm very much of the opinion that you need to keep the client light if you need to store too much data on it, it's bad but also you need to be able like, yeah, just cache the state. So if you download some data, just keep it there and don't discard it. This may sound obvious but yeah. Yeah, so we should be able to do better. So currently this is like, better is the enemy of good. Good is good enough. Currently it is workable, it is done but we want to do better. We want to reduce the two main problems that we want to solve is reducing the coin history and making fungible payments. And this is pretty much what the Plasma Prime construction is. So I'll just give a brief overview of what happens. So the non-fungible coins, it's a double edged sword because it gives you this nice security problems but you cannot make the payments that you like. So the one approach is that you have a change provider. So I send Jeff like seven ether and it gives two back to me. But you need an atomic swap construction which before Plasma Prime, Plasma Prime, the dream, it didn't exist. And the other approach, it was the Plasma Debit by Dan who I love Dan but he's not here. Plasma Debit which basically like instead of a coin like having a certain value, you can have any value between zero and that value. And you can think of it as a liquid like a liquid that goes from zero to that to its max capacity. And essentially if you're able to reduce the one like liquid by a certain amount and increase the other one by another amount, essentially you have simulated a transfer from these two. It's very neat because it also has the notion of transferable payment channels because if I own a coin that is like with some balance and I transferred somebody else, it's essentially that guy who has the payment channel now. So it's very, very convenient. And the final approach, which is the cash flow defragmentation Prime, whatever, is that I deposit like one ether and instead of depositing one ether, I get a hundred 0.01 ether coins and I can move them around and so on. But the problem with that is that if I have let's say like 10 coins in a row and I send the middle coin, suddenly I have two, like I have two subtrees and the whole technique, the efficiency of this technique is that you can exit multiple coins by exiting the sub tree, by proving it with whatever magic. And yeah, and the other approaches, like how will we reduce the history, right? So firstly the checkpoints, TLDR it's like you have a coin and you instead of validating from its deposit, which is like 10 million blocks ago, you validate up to the last checkpoint. So you pick the checkpoint range to be like manageable. However, I claim that this requires too much social coordination because it involves the operator advertising, it's complicated. And the other approach is that you can like simply like make less frequent commitments, but this hits on your throughput and your capacity. Because if I have like, you basically say that if I have like one gigabyte of history and they commit one time every 15 seconds, it makes sense to say that if I commit one time every minute, the coin history goes down by one fourth, by up to the one fourth. The other approach to use the probabilistic structure with the Bloomfielders, but if the Bloomfielders has false positives and it was shown recently that you can actually like pollute the Bloomfielders, yeah. Another approach is the accumulators. So with the accumulators, what you do is that the goal with the accumulators is that you succinctly prove the inclusion or non-inclusion of something. And you use either RSA accumulators, which is the current like approach that people like, or there's another alternative which is paying based, which I would like to discuss at the Plasma call live later. And the final thing is that, yeah, that magic black box, the Snark Stark toolkit, which I was at the Stark presentation yesterday and I was informed that it is possible to actually do budget proofs and everything we need like with Starks in a realistic timeframe. So that will be like lovely if we can have it. And yeah, okay, there's this other thing. So currently, the UX sucks. You need to wait seven days to exit the coin if you need to exit the coin. My opinion is that you don't need to exit the coin, but it must be there. So what you can do is that you literally like tokenize the exit. So I make an exit, instead of like owning the exit, I can get an ERC721 or whatever, non-fungible and I can sell that around and whoever owns that coin, it's like a coupon and you can send it and you can, after the exit period has passed, you can withdraw it. And the whole construction is that this creates a whole market for exits where instead of like, if I'm exiting five-eath, essentially somebody else is probably willing to buy my coin for 4.95-eath because they have a lower temp preference. And this party, it makes sense to say that it will be the operator because they're running the chain and they don't care. And they also run a full node anyway so they know what's valid and not. And the second one is the optimistic exit. So instead of exiting, so when exiting, you need to provide miracle proof signatures, whole lot of stuff, it's a lot of data so that the gas can go from 100,000 to like 200,000 and maybe more depending on your proof size. Alternatively, what you can do is that you can assume that the exit will be valid and add one more challenge, the crypto-economic approach, which it's nice because you can essentially reduce the cost of an exit like 60K gas like for two store operations but you add another challenge. Yeah, so the final takeaway from this presentation, the technical stuff, it's solid, like you should look into it. It's not complicated and talk to me for learning about it. Plasma doesn't improve finality so this whole one million transaction per second dream, it's not real. What you do is that you increase the capacity that you can force per 15 seconds because currently if Ethereum can handle like, what is it, like nine million gas per block or eight, what you do is that you can put the whole information that happened on the Plasma chain in 32 bytes. In storing 32 bytes, it's cheap. So if we had like multiple Plasma chains, yeah, okay, the scalability it can be one million transaction per second but it still settles every 15 seconds if the data is made available. And yeah, essentially just think of it as a compression, literally. Maybe not because you assume a decompression mechanism but the thing is that you just take everything, you put very little data on it and if you follow some certain rules of the protocol, like watching, you're good. And yeah, it's a non-custodial side chain. Thank you very much. And these are the repositories, go check them, break it if you can, yeah. Yeah, and have it take any questions. Maybe is there a microphone? Thank you for your talk. What's the problem with allowing atomic, multiple transactions to be atomic within one Plasma block? Because you cannot force the operator to include both. So what you can do is that you can construct a game where one transaction is depend what you want in atomic swaps is that atomic is a bad word, actually. So either both happen or none happen. So this matches your exchange use case, I guess. So the operator, you need to force them if they include one transaction that either they must include the other one or if they include the one and they don't include the other one, that one is invalid. And you can do this by essentially doing a two-step game. We're just like similar in the classic atomic swap construction between chains. You just, you commit to a pre-image and you give the pre-image to each other and you reveal. But yeah, maybe Carl is better to ask like in depth on how the atomic swap works because I haven't been looking at the prime how it's been done. Quick, if it's quick. So I'm from dock, we are a data exchange protocol and we were trying to enable micropayments using Plasma Cache and we need a POC. So we came up with that book but I wanna know your thoughts. How do you think micropayments can be enabled using Plasma Cache? Why don't you want to use the payment channels? Is that a question? You have the engineering toolkit and you need to use the right tool. I do not believe that Plasma is the right tool. Okay, Plasma Cache, you know. It doesn't matter. Okay, so you're saying using the stair channels probably is a better way? Payment channels. Payment channels, yes. I think Giorgio's needs a lot more credit for actually implementing Plasma Cache, which is pretty amazing. So thank you, Giorgio's.