Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Karl Floersch: Plasma Cash and the Ethereum Roadmap

Episode Date: April 24, 2018

Ethereum Foundation researcher Karl Floersch joined us to discuss the main projects to upgrade Ethereum: Casper, Sharding and Plasma. Karl has been playing a key role in creating a new and simpler specification for Ethereum sidechains called Plasma Cash. We discussed the evolution of the Plasma project and what Ethereum’s evolution in the coming years could look like. Topics covered in this episode: How Karl originally became involved in Ethereum The role of Casper, Sharding and Plasma in the Ethereum roadmap The problems with the original Plasma concept How Plasma Cash provides a simple scalability solution The challenge of data availability Use cases and timeline for Plasma Episode links: Plasma Cash Simple Spec Ethereum Plasma MVP Overview Plasma Cash Discussion on Ethereum Research Cryptoeconomics: An Introduction Plasma & The Public Ethereum Chain - Joseph Poon (Ethereal Summit 2017) Plasma - Original Whitepaper This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/232

This is Epicenter Episode 232 with guest Carl Floresh. This episode of Epicenter is brought you by Knosus, an open platform for businesses to create their own prediction market applications on top of the Ethereum network. They recently launched KynosisX, a challenge inviting developers to build apps on top of the Knosis platform. To learn more, go to Epicenter.tv slash KnosisX. Hello and welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Brian Fabian Crane.

And I'm Meher Roy. Today, we are about to chat with Carl Flursh, who is a research scientist at the Ethereum Foundation. And Carl really explains topics really well, so we thought of having him on board, explain to us what the plasma project is all about. Carl, welcome to the show. Thank you so much. Happy to be here.

So before we start, tell us a bit about. your background and how you got to be involved in the blockchain space? So I have been interested in peer-to-peer technology for quite some time. I was doing stuff with like web torrent. I was into BitTorrent, but I wasn't so into Bitcoin because of all the kind of money talk. Money wasn't really my thing. But then when Ethereum came around and it was this kind of global, decentralized kind of computer sciencey problem, I was like, oh, this is the missing piece.

I see why this like economic stuff is actually really important. And so that kind of led me to work at consensus. I was working there for about a year and a half. And on the tail end of working at consensus, I met with Vlad and wanted to help out with some Casper stuff. And then I worked with him on that. And then I worked with Vitalik on even more Casper stuff. And eventually just went full Ethereum Foundation researcher. and now spend all my time on Casper, sharding, and plasma.

Cool. So there's these three projects, right? There's like Casper, there's sharding, and there's plasma. We'll cover plasma in depth during this episode. But could you give us a sense of what these three projects are and how they connect? Sure. So I guess I will start with Casper. Casper is a proof of stake protocol, which has been,

the works at the Ethereum Foundation for multiple years. And essentially what it does is it forms consensus on the root Ethereum chain. And what that means is it basically provides this guarantee around a transaction or block ordering. And it says, okay, this is the one history and reverting this one history is very costly. And so the kind of design space around this is, okay, let's make it so that we have the most quote unquote secure blockchain, aka this blockchain that resists, censorship the best and it also, you know, the history will not change under your feet. And

these are the kinds of, you know, concerns around Casper. So that is like the security side of things. Then sharding is where we take the kind of Casper protocol and we make it so that it secure as not just one like small bit of data. We make it secure a huge amount of information. So we basically pump up the, the throughput of this blockchain, you know, drastically. And so we want to, instead of, you know, doing 10, 15 transactions per second, we want 150 or 1,500 and, you know, continue from there. And then finally, we have plasma. And plasma is essentially a design pattern, a space of designs, which allow you to kind of create your own scalable blockchain and run it, you know, maintain it yourself, however you get the security benefits of the main Ethereum

chain. So that means that, you know, the current proof of work security, which is pretty good, and then eventually the proof of stake Casper security, which will be even better. And so you get the security of the main chain while being able to deploy your own. And so these are the kinds of three frontiers for Ethereum research these days and what I'm working on. And so with these, it seems like plasma is quite, plasma cash, right? We're going to talk about. We're going to talk what seems to be pretty close, right? And like in a, you know, reasonably time horizon. Casper, it's always hard to tell.

I mean, I think we have had Vitalik on here, I don't know, two and a half years ago or something, and it was like six months away or something like that. So, and of course, now it's Casper's in two stages, right? There's the fast finale gadget and then full Casper. Is that still the plan? Yes. So I can quickly do.

a little timeline stuff is impossible, so I'm not giving any guarantees. However, I can say the facts, and the facts are that we have a very reasonable plasma spec. So that's, of course, you know, that's coming very soon. Anyone can implement it. It's really, there are basically no barriers regarding plasma and implementing plasma. That's super simple. Regarding Casper, last January, my first thing that I was really focused on is implementing the Casper FFG test net, like a full implementation of Casper FFG. And that was released on January 1st. And since then, there is now a security audit that is underway of the Casper contract.

You can read it online, you know, formal verification and stuff. Like this is a really amazing security audit team. And there's also, you know, implementations that are being done for multiple clients. Currently, I think there's, you know, there's Pythereum and then there's the Java implementation. So while, you know, maybe last time you talked about Casper, it was like, quote unquote, six months away, this is like we are refining so that it can be deployed on the main net. And there is something that works. Like, you can download it and read the full spec. And I think people should be a little bit more excited about the hybrid friendly finality, Casper, than they maybe are currently. Because it turns out that you get a huge, number of the benefits of Casper when you just add in this friendly finality gadget. And that is you get this kind of economic finality after 20 minutes. And while that may seem like quite a long time, you can actually have guarantees even

sooner than 20 minutes using other mechanisms. So like Casper the friendly finality gadget is the kind of big, you know, step forward that that we've been waiting for in some ways. And so then we'll get full Casper eventually, but this is like, oh, this is so exciting. Friendly finality. And so what are the main things that this finality is so crucial for? So one thing I have, you know, spoken with some people about that makes sense to me, why finality is important there is having fast finality, right?

Because let's say you build some kind of user application and then something reverts and you have to roll back state. Like that obviously from a user experience perspective sounds like a nightmare, but then 20 minutes isn't really going to do that for you. So what does the 20 minute thing do for you? So I would think of finality maybe in terms of like, okay, what is the economic penalty for reverting a particular transaction? And so what we want to do is we want to make the economic penalty as high as possible. And so in terms of the kind of like 20 minute finality, you have this really, really high penalty for reverting. any previous history. And that is like the kind of, you know,

two chains get finalized, at least one third of all validators' stake gets slashed. So to revert history at all, or at least create a kind of conflict in the history, you need to spend, you know, one third of the total validators' stake. And that gets burned. So this is kind of like the really secure stuff.

And what Casper allows us to do is because we're using kind of these coins to secure the chain, we can now reduce the block rewards for proof of work miners because now they're limited in how much they can revert. They can only revert 20 minutes back. And so if you do wait for that finality, now you're able to say, okay, I know without a doubt that this block is included in the main chain. So that's kind of like your, you know, global finality. And that's slower to come about and, you know, has really strong security guarantees. I just wanted to ask one question on this point here. So you said, okay, because you have this 20 minute finale thing, you can reduce the block rewards for minors or proof of work minors. Do you mind explaining

the connection there? Like, why does that allow you to reduce block rewards? Yes. So, essentially, the thing that we pay miners to do is to essentially, like, secure a single chain that, you know, a single view of history that doesn't get changed, doesn't get reverted, that, you know, has a number of properties that we really like, right? And we pay them quite a lot. I mean, and the actual amount that we pay them is kind of this arbitrary thing because, you know, macroeconomics is hard. But we definitely, we're paying the millions of dollars a day.

And so that is, you know, an insane expense. Now, with proof of stake, what we do with this friendly finality gadget is we now limit the attack surface of these proof of work minors. we say, okay, you're able to revert, you know, blocks. However, you're not able to revert blocks past 20 minutes. So essentially you wait a certain period of time. Now you know that this, you know, this block is finalized will not be reverted. And no matter what, even if you had a, you know, proof of work, 51% attack, you know, 100% attack,

you still would not be able to revert that transaction. And so that means that now, okay, the actual like impact that paying these miners less will have is greatly reduced. even if we paid them nothing, you know, maybe it would work out. Who knows? These are probably good to pay the miners, but who knows? Maybe transactions are enough, and that's in the future. So basically the idea is before you had this like massive bounty in a way, right, if you successfully pull off an attack.

And now the bounce, and because of that, it made sense to pay them a lot because that means a lot of infrastructure and then also the cost is very high. But now if the fast-finaldi gadget, you're shrinking this dramatically. And so the benefit of pulling off an attack is also shrunk dramatically. So it doesn't make sense anymore to have this like massive, huge, expensive infrastructure protest like this attack surface. So you can, exactly, massive. Okay.

Explain towards the third piece, like sharding. Sure. So sharding, essentially right now, Ethereum can only process, you know, quote, unquote, 15 transactions per second. But basically, it doesn't do a lot of computation really quickly. Now, what we want to do is we want to say, okay, we have this one blockchain, and it's actually able to process transactions, like way more transactions. And the way that we actually do this is non-trivial. The thing is, okay, one way to shard or to scale a blockchain is to just, like,

pump up the transactions per second. And that works to some extent, right? You can say, okay, let's just add, you know, quote unquote, put bigger blocks or, you know, more throughput. That works to some extent. However, eventually you get to a point where normal laptops are no longer able to actually process the entire blockchain. And so you now limit who can actually run this, you know, consensus protocol.

And because we want to keep it decentralized, we want to make sure that, okay, a laptop is able to validate the blockchain. So the better way to scale and really hit high scale is, by sharding the blockchain. And that means that we allow different computers to validate different parts of the blockchain. So every computer is only validating a small slice of the full transaction throughput.

But because of essentially like, you know, probabilistic guarantees and, you know, clever constructions that we're working on, the actual sum effect is that the entirety of that, you know, large throughput is secured, is available and we can support many more transactions per second. And you can download only the parts of the blockchain

that you care about and you're validating only subsections of the full blockchain. But as a whole, it becomes this really high throughput consensus mechanism. So in terms of dependence, sharding depend on the friendly finality gadget or can it be implemented independently of it? So it can be implemented independently of it.

However, there is a kind of the full vision is that they all come together and the sharding and the Casper stuff is kind of merged into one. However, there are ways to implement it independently. And so, like, that's what we're doing right now is we have parallel tracks for Casper and sharding, where Casper is being implemented kind of, you know, the test ned that's going through these iterations to eventually be released. and then sharding, we have like clients that are working on sharding implementations in parallel. So they're building their own infrastructure

and then eventually, you know, we can merge them together later. So basically for development purposes and for simplicity, we kind of like solve each problem independently and then combine them later for the unified Ethereum vision. So the unified Ethereum vision now

is sort of becoming that there's Casper or Proof-Stake which is increasing the quality of security of the blockchain itself because one of the things it does as I see it does two things A it allows the punishment of validators whereas miners cannot be punished

so it improves the security of the game so to say and then it also allows Ethereum to have finance much better finality properties than what it currently has. So that's one piece. The second piece is sharding, which is to use Casper and proof of stake, to increase the transaction throughput through the Ethereum chain. And then the third piece is plasma, which is to allow the Ethereum system

to lend its security to some other blockchain that an entrepreneur created for their own purpose. So for example, the Gnosis people, they create their own chain which is specialized for prediction markets. The main Ethereum chain could lend its security, which is very high because the market cap of ether is very high. You could lend its security to the Gnosis chain and therefore have a sort of a win-win situation between the Ethereum community and all of these other coin communities that are springing up. And so all of these things would like kind of combine in order to make a highly secure and high throughput system that can presumably handle most of the decentralized applications being built. That's right. Awesome. Cool.

So let's let's now segue into plasma. Right. Now I think plasma as a concept came sometime last year when Vitalik and Joseph, Poon released a paper. And since then, the vision has undergone some iteration. So could you get into the history of plasma and how this idea came to be and how it has evolved? Sure. So, yeah, just as you said, Joseph Poon and Vitalik came up with this concept of plasma and the ability

to use a secure root chain to provide the guarantees around like exits. from the less secure chain. So essentially guarantee assets of a less secure chain and through this exit mechanism. And so we worked on that the white paper was released and people started getting interested. And then we started holding these plasma implementers calls and they're all on YouTube.

And we talked with the community. There are a lot of people who are excited about using this exit mechanism. a spec called Plasma MVP was created, which essentially is a kind of simple version of a like UTXO-based plasma chain where you can scale up a thousand transactions per second probably around there. And then later on, relatively recently, plasma cash was created or specced out.

And that took the original plasma idea, and it simplified it in a lot of ways. And it basically provided a very reasonable scaling solution for plasma. So instead, in plasma MVP, there were a couple problems. There was like a really bad mass exit vulnerability. Scalability was limited to about 1,000 transactions per second. But then when plasma cash came around, now, the mass exit vulnerability has was significantly mitigated

and we can now scale up pretty high I there without I don't I don't see any upper limit that jumps out at me that I want to say but but it's very scalable so one thing that stood out to me

is of course Joseph Foon many will be aware of was also the original author of the Lightning Network paper. And we did an episode on Epicenter with him and his co-author many years ago. There are a lot of similarities, right, between Plasma and Lightning Network. That connection is very obvious. But one of the big difference is that Lightning isn't actually a blockchain, right? So you don't have any more, like it's a very different network topology and like, we'll see how it works out.

But it's very radically different. Whereas plasma, you still have basically a blockchain that's just sort of inheriting the security. Do you have any idea why this shift and why didn't they try to build plasma also as not a blockchain, but something more akin to lightning network? Was that driven by the idea that, okay, lightning won't be able to do computation properly? or actually a blockchain structure will make more sense for that? I can't say that I know exactly the thought process for how this transformation happened.

I can say that the kind of concept of state channels more generally. So both of these technologies are within the kind of bucket of state channels, right? You have some kind of off-chain messages that are affecting the outcome of an on-chain game. And so this is kind of the overarching design space. And then the lightning network approach made a lot of sense. You're signing off-chain messages and you're transacting and you don't actually have to go on to the root chain all the time. And then plasma allowed for, it actually does simplify a lot of things.

So I don't know. Oftentimes what happens with creating these designs is you start off with one idea and then you kind of work with it and it makes a lot of sense. And then you kind of, you reconceptualize things and you actually end up with a much simpler design. And so that actually happened with Casper, FFG, and that also happened with sharding. And we're always like iterating to find the kind of like what is the most, you know, the simplest and most elegant solution to this problem. And so I think, you know, Joseph Poon, I can't speak for him, but I imagine that he was thinking

about this, he's like, okay, now I have the ability to use smart contracts and I can, you know, build on, why don't I take, make use of this smart contract platform instead of just this, you know, payment platform this, you know, with a simple scripting language in Bitcoin. And so he probably was like, okay, now here's our slightly changed design space. How can I make use of this as best as possible? And so, you know, plasma comes around. And it turns out plasma is super insanely simple. Yeah, I think that's an interesting point. Because I agree with you that, you know, reading about plasma and we'll get more into this but it's actually seems pretty pretty straightforward and easy to understand but lightning network i don't personally feel i really understand what it will be like

what you know these different hubs and lightning nodes and what will this network look like what are the risks associated with like there's so many questions that for me at least are unclear. So I agree with you. It does seem much simpler. So another question on this. So you mentioned plasma MEP and the Blasma MEP was UTXO based. And is that also true for plasma cache? And why was that UTXO based if, you know, Ethereum generally is not? So every plasma chain can have its own custom logic. And so that allows you to kind of get certain properties that, you know, if you want to have certain things be really, really fast to compute. Maybe you can have a plasma chain that is optimized for particular tasks.

And so it doesn't actually matter what the mechanism by which you're computing state transitions is, like in UTXOs or account-based or whatever it is, the plasma chain can use anything. And you just code in that mechanism into an Ethereum smart contract, and now the Ethereum smart contract can run those state transitions and immediate that chain. So in other words, those, the concerns are totally separate. You don't have to use any consensus protocol that looks like Ethereum's consensus protocol or any EVM that, you know, the Ethereum enshrines. So, so the plasma MVP and plasma cache, they are just, I don't know if it's super useful to talk about the UTXO bit, but the way that they kind of compute their, the way

that they structure their Merkel tree, the way that they structure the chain is just slightly different. And in Plasma Cash, it really lends itself to parallelization and being able to only compute or only keep track of coins that you care about. I can go into the difference between plasma and Plasma MVP if you want. Okay, sure. So essentially, Plasma MVP, you're keeping track of every single coin, and you're validating that every single coin on the network is, you know, like the state transitions are happening properly. And so you're pulling all the coins or all the transactions and you're saying, okay, I'm going to compute these locally.

And if there's any problem, then I'm going to submit a transaction to the main chain and take my coins out. Now, the difference with plasma cash is that you now only have to care about the coins that you particularly hold. So when you send coins to a plasma cash smart contract, those coins will be given specific IDs. And those IDs will correspond to branches in the Merkle tree,

in the whole plasma cash Merkle tree. And so what your job is, is your job is, okay, every time there's a block that's created on the root on the root chain, you're going to validate the branches of the Merkle tree for that block that you care about and make sure that your

coins have not been, you know, double spent or whatever. So essentially what that means is client-side validation is now way cheaper, because if you, you know, hold 100 coins, you're checking 100 branches in the, in the Merkel tree. And this is kind of where you get this parallelization because the, the, the, from a client's perspective, you are, you're, you have, you know, you can use your laptop to, to validate the transactions. And then from a block proposer's perspective, it doesn't really matter. They can,

you know, it can, a block proposer can be an exchange and they can have really beefy hardware. So you still get the, the, like, you get the, the, like, you get the, the transaction throughput of a beefy exchange with the client-side validation and the security guarantees requiring only a laptop. So this is like this, it's all about giving security to the users without limiting who can actually get that security and, you know, keep it on a laptop. Anyway. So let's zoom out a little and do some role playing to sort of understand plasma. So the way I understand plasma is Let's say I don't know

Brian and I are users on Eserium And We have Ecer and we want to Use this Ecer to To partake in some application Right So the way This would work is if I want to

And there's A plasma chain for that application Right So when I want to take part in that application, I have to deposit my Ether into some smart contract on the Ethereum system. And I'm going to get some coins on this plasma chain. So if I deposit 100 ether here, I might get 100 coins. And then I could take part in that application. And the same exists for Brian as a user.

So you deposit, you get these coins and you partake into that application. Now under the hood, this plasma child chain is being validated or mined by a bunch of validators that are continuously creating blocks on the child chain. Now when I'm on the child chain, my instinct is, oh, I need to now trust that these group of validators are going to validate correctly and they're not going to commit invalid blocks on these child chain. because if they can commit invalid blocks then I could lose my hundred coins

and these hundred coins stand for 100 ethers so I stand to lose a lot of money but what plasma allows conceptually is for me to not need to trust these validators even though I'm on a chain and they're being validated by these let's say these hundred parties and ordinarily you might think that you would need to trust the collection of these hundred parties

not to hit an invalid block the way plasma is structured is you remove that assumption of trust between me the user and the validators even if they cheat I can exit my hundred coins from the plasma child chain and back into the Ethereum system

no matter how strongly they cheat would you say that is correct yes that is absolutely correct and this this is the kind of the beauty of that security is actually now before you you probably had

70 validators so that you know you could like get better security around you know a decentralized consensus protocol like you get you get like stronger security properties and so that's why you had this more complicated consensus protocol however because you have this guarantee that even if you create an invalid block there's no real problem for the plasma chain you like a lot of plasma designs don't even need a really complicated and secure consensus protocol they can actually just use a centralized service to do that for them. And that centralized service is actually limited in the kind of bad impact they can have. They can't actually steal anyone's coins. So you can take any exchange today and you can turn that exchange into a plasma chain. And now

instead of having the problem where your exchange steals all your money, you now have this guarantee that your money will never be stolen. And you still get that high transaction throughput of the exchange. Thinking of this a little bit differently. Now, when I open coin market gap, right? So there's Bitcoin, there's Ethereum, and then there's 10,000 other coins. Right. Now, today, it might be the case that there might be some coin which is like, I don't

know, 20 or 30 on coin market cap. Let's say, I don't know, Steam or Zcash. and this individual coin might provide very interesting utility to me but so when I own ether and let's say I want to do private transactions I might need to go to Zcash which is number 27 or I might if I want to do steam like transactions I could need to go to steam which is number 31 these are much smaller than Ethereum so when I switch from ether to like to the Zcash system

what I'm really doing on the background is when I was holding ether I was in a chain that was more secure because the market cap is really large the chances of it the blockchain being messed around with or attacked is quite low but when I go from ether to Zcash

I've suddenly increased my risk to a chain reversion in a big way because Zcash is a much smaller blockchain so what a plasma world looks like is a Zcash-like application could be a child chain. And then I'm in I'm in Ethereum. I deposited my ether to a smart contract and I went to the Zcash like child chain. I can do these private transactions. But I have the security of the second of ether, which is second on the market cap. I don't need to dial down on my security as a user. But yet I

get access to the application and that is also scalable. So in theory, what it might mean is if this design succeeds, then a lot of the coin market gap, as we see, it might end up being rearranged because a lot of the smaller chains can now borrow security from this larger chain pretty trivially. Yeah, exactly. And this is, this is the, it is a like full design,

space of, you know, plasma is not a particular product or project. Plasma is a design space which allows you to do exactly what you just said, which is super exciting. So that's why we have a bunch of people working on their own plasma implementations, including people from multiple different blockchain implementations, like Cosmos. So this is interesting. So for me, a question that came up before was that, you know, You talked about how you have a plasma chain and then somebody will have to kind of report this and share some of this data and proofs about it on the main chain in the case of an attack.

Does that mean it won't be possible to have a plasma chain that's kind of a zero knowledge chain, something like a CCASH type thing? So you can do zero knowledge proofs on, you can check the validity of zero knowledge proofs on the main Ethereum. It is currently quite expensive, but this is where like the expense. the capabilities of the root chain is really critical. And so having something like sharding where you now get higher transactions, transaction throughput and lower gas cost, you now will be able to, you know, support the, not only the exits of any kind of chain architecture,

but also many, many exits at the same time. So all of these like three kind of pieces fit together really nicely, Casper sharding and plasma. This episode of Epicenter is brought to you by Gnosis. Gnosis is an open platform for businesses to create their own prediction markets on the Ethereum network. Prediction markets are powerful tools for aggregating information about the expected outcome of future events. So this can be used for things like information gathering, incentivizing behaviors, making governance decisions, or even creating insurance products. So in order to turn Gnosis into the most powerful

forecasting tool in the world, they recently launched Gnosis X. It's a chance. challenge that invites developers to build applications on top of the platform. And the best applications per category will be rewarded up to $100,000 in GNO tokens. So throughout the year, Gnosis will announce different categories for the challenge. And the current challenge has categories for science and R&D, token diligence, and blockchain project integration. Gnosis also provides the SDK, which allows you to easily get started with everything you need to get coding. And they also provide dedicated support channels throughout the challenge for teams and solar builders. Are you up for the challenge?

Get started now. To learn more and to sign up, go to epicenter.tv slash connoissex. We'd like to thank Canosis for their support of Epicenter. And at the other point where we are wanting to come back to briefly, so we talked about validators before and how, you know, you can have basically no reliance or no trust in those validators is required at least only a minimal one. And you know, you brought off the point that you could even have a central operator. So is there any benefit to having, you know, let's say 50 diverse parties validating such a plasma chain versus Coinbase or, you know, Mark Carpelle's or, you know, a particular party?

Yeah, for sure. So the first one is this like central operators, many central operators running plasma chains. Now, the other option is you take one of those central operators and first you add some validators. So you add a set, a group of, you know, people who will essentially take the blocks from the central operator and they'll validate that, you know, they're the correct state transitions and that they're available. And then those validators will sign and that will be posted to the main chain. And now you still have you, you now have better security because you have these validators. but you have a single block proposer. So now what you do is you say,

okay, let's replace that single block proposer with anyone who wants to propose blocks for this plasma chain. And so now you can rotate or randomly sample the block proposers, and those block proposers submit blocks to the validators, the validators check them, and it gets posted to the main chain. And so you now have this ability for a much larger plasma chain that is not controlled by a single exchange, but that is a kind of a open decentralized platform that kind of more closely resembles what we see today.

And so that is definitely a alternative vision. And that would mean there may be fewer plasma chains, but each plasma chain is much larger and its own ecosystem in some ways. Okay. I didn't totally understand the benefit here of having multiple values. validators, is, so what would, what is the downside of having, you know, a particular operator just running the chains? Could they, for example, engage in censorship? Yes, exactly. So they can engage in censorship. They can, you know, get shut down. And they also, if they do submit an invalid block, it's basically arguable, but you can, you can say that essentially there's less security

that protects the central operator from causing a mass exit. Although what you can do is you can actually add security deposits to your central operator so that if your central operator does submit an invalid block, they lose a whole bunch of money. Right. So yeah, sure, the invalid block thing, it sounds like you can protect against, right? But then the censorship thing that you probably can't. Yeah, okay. Thanks.

I mean, you can always take your money from that plasma chain and put it on the root chain. And so there's no censorship there. But it can still be censored within that plasma chain, which is annoying. Yeah. So as long as like we have validators that are in different jurisdiction. So I think like we can say that there is like diminishing returns to the number of validators. Like if you have just one central operator adding a second, well now now you need to shut down two in order to shut down this plasma chain better. can add in three, it still increases. But then once you have, I don't know, 30 or 40 and they're in

different nations, maybe adding five more may not matter much. So, but in order to have 30 or 40, you do need a consensus algorithm and, you know, it starts looking like a traditional blockchain. So give us a sense of what these consensus algorithms powering plasma chains would be like. Does Casper work there? Does tendermint work there? Or do we need to invent something? new. So the actual consensus protocols can be super duper simple. You just have a

normally what you want to do is you want to actually shard validation. So the cool thing about plasma cache is that you can have really huge blocks. But if you have really huge blocks, you're going to need to shard the actual validation of those blocks. You take one big

block, you split it into small subsections and you randomly sample a committee of a certain number of validators to say, okay, you guys sign off on the availability and validity of this subsection of the block. And so if everyone signs off on the availability and validity of this block,

then that block gets posted to the main chain. And so you can do this with like a BLS signature similar to how DFINITY is structured. You can do this with a cryptoeconomic threshold signature. There are a number of different ways, But essentially the overall strategy is you take one big block, split it into small blocks. You take a big set of validators. You randomly sample those validators to validate the subsections of the block.

Those validators sign off. If enough sign off, then it gets posted to the main chain. And we continue as normal. So it's a relatively simple consensus protocol, and you can add slashing pretty trivially. And that's slashing, you know, you can slash validators for, signing off on invalid blocks, you can slash block proposers for creating invalid blocks, and there are a number of things. And maybe something that I'll explain right now, which I actually meant to mention earlier,

is so you have this like 20 minute finality checkpointing mechanism, right? But that doesn't mean that you aren't able to provide economic guarantees around transaction inclusion even earlier than 20 minutes. So essentially what you can have is you can create. slashing conditions for these block proposers that say, okay, if you're a block proposer and you sign this message saying, I will include this transaction in my next block, and you don't include that transaction in your next block, then you can get slashed. So essentially what you can get is you can send a transaction and get an instant confirmation where either this transaction will be included

or the block proposer will lose a million dollars or, you know, $10 million. And so you're actually able to get kind of a gradient, different levels of economic finality, you know, at different periods of time. And this is kind of a, the way in which we have this like slow finality, which is really, really, really secure. And then per application or you can kind of get a much more rapid finality. So you mentioned before the idea that the different plasma chain should be able to interoperate how would that be possible and would that be possible in the sense that like tokens can be used to move between chains or that you have like full smart contract calls or like applications that are built spanning multiple plasma chains what's that going to look like

so this is definitely an open design space one possibility is that in the plasma chain you have a special transaction which says okay i'm going to move this coin from this chain to this other chain and then in the chain and a transaction is is included at that same like ID that says okay now I have this coin on this chain and you you know transact there so you don't actually have to touch the main chain it's just like you assume that the transaction gets included here and then it gets included in the in the other chain and then the the interesting part is when you want to exit you basically have to prove you actually like you supply the the kind of path of chains that your coin went through and they just like quickly validate that all of those

that that path is valid. So this is a way to support not just like atomic swaps cross-chain, but actual coins that kind of teleport to different plasma chains. But there are multiple different solutions for how to do this. And the actual design space of, you know, for instance, smart contracts on plasma chains, that is something that is an open research problem. And, you know, please get involved.

So the plasma white paper mentions that the fundamental challenge that must be solved to have a functioning plasma system is the problem of data availability. Give us an idea what this really is. Why is data availability a challenge? Data availability is the bane of blockchains. It's very, it's the hardest problem. And it's really the hardest problem that needs to be solved for plasma and it needs to be solved for sharding. It is terrifying. So here is the general kind of what data availability means is that if you have a data that is available,

that means that anyone who is interested in that data is able to download it. So available data is like data that is being gossiped on the gossip network. And anyone is able to pull that in. Now, data availability is incredibly difficult, but in the current blockchain architectures using like proof of work, it's not actually a big problem. And the reason why is because essentially you fork away from chains that are unavailable. So if you cannot actually download a block, then you just don't use that. You know, you don't follow that chain.

However, this gets tricky when you start using like when you have some kind of, concept of finality and in particular when you have these chains that are being built up on a root chain so if you have a smart contract where and in that smart contract you're posting headers block headers then if one of those block headers corresponds to an unavailable block there is no way to like fork around it unless you build in a forking mechanism in your smart contract so either you like you have this forking which gets rid of your finality guarantees or you have finality, which is a problem if the data is unavailable. And so the core issue here is if you have a chain, and in that chain, one of the links is missing,

everything after that chain, I mean, after that missing link is essentially useless. It doesn't actually do anything. And so in very practical terms, where this comes into play in plasma is, let's say we have the simple plasma architecture with a central operator. that central operators committing block headers to the chain at a regular heartbeat. One of those times, they commit a block header for a block, which they then subsequently delete. So they submit a block header, but then they delete the actual block contents. Now, from that moment on, there is no way for a user to validate whether or not their transaction was double spent.

They have no information on what the actual state of the world is. and so they're forced to exit the chain. So you said delete, but you mean just they don't reveal it? Or like, what do you mean with delete? They either don't reveal it. They reveal it to, you know, their little coalition of, you know, sneaky people. Or they just, or they even commit a block header which doesn't even correspond to any block at all. Maybe it's the zero hash.

That one's pretty clear. It's pretty clear that your block, if it caches to zero, either you, you know, you know, broke the hashing function or your block doesn't exist? Or more pragmatically. So let's assume I build a central operator and I'm running it out of AWS. My data center is in Silicon Valley. And hey, like, there's a big massive power outage

in the West Coast and my server just doesn't work for the next two hours. But like prior to publishing the block I had posted something on the Ethereum chain. My server went offline and now the block data I cannot gossip it to the world because it's down and I cannot actually access the machine because the power is down.

So it could be malicious, right? Like, I'm not revealing data because I'm malicious as a central operator, but it could also be, I'm not revealing data because disaster struck me. Absolutely. What can happen in that scenario? So what would happen in that scenario is

your users would say, okay, now I can't download this block. the operator is, you know, it's been a week and they still haven't given me the data that I need, I'm going to have to exit. So I'm going to send a transaction to the main Ethereum network, and I'm going to pull my coins out of that plasma chain. And the plasma chain operator is going, like, assuming no malicious activity, that's just what will happen. They'll pull coins out of the plasma chain. Now, in the kind of bad case where the plasma operator actually does have the information, does have the data, but has, you know, maybe they've withheld it, and withheld data,

they kind of committed a double spend. And so there's actually invalid data, but no one can prove the invalidity because they don't have access to that data. Now, the operator, they can try to exit coins that they don't own because there's this, like, invalid spend. However, thankfully, do not fear the actual rightful owner of that coin can say, okay, I'm going to challenge that exit and, you know, basically block it. And their challenge is paid for and they receive a kind of a bounty for doing that.

So we're while, so block withholding, not only is it a problem because you have to exit, but it's also a problem because it makes it so that you can't prove misbehavior, like, bad behavior very easily. And so these are like, it is just such a tricky and annoying problem. Right. So can you just reiterate that again? So let's say we have a block. they want to steal people's coins, right?

So they publish a block header or the block hash on the main chain. They don't reveal this block. And then how do they try to exit coins that they don't actually own? So let's say they publish one block with an invalid state transition. Then they publish the next block with a valid state transition. So they say, okay, I'm going to invalidly say I'm going to appropriate Carl's coins. and I'm going to give them to Alice. And then the next block, Alice is going to send those coins to Bob.

Now, if the plasma operator is actually Bob, and so the plasma operator submits an exit saying, you see, I want to exit these coins, and the last time they were spent, I own them because Alice sent them to me. But then the real kind of annoying thing is that it turns out that Alice stole them from Carl. And so from the point of view of the main chain, the main chain isn't able to kind of like detect that problem. However, there is someone who can. The person who can is the person who anyone actually who knows about the prior history of that coin and knows that there was no spend to Alice.

And so they will challenge. They'll say, okay, you know, your block is unavailable. You know, you might have had an invalid block. You might have, you could have done anything. I'm going to challenge that because I know that you won't be able to provide a full history of valid spends. And so I'm going to provide the last valid spend of that coin. And then your job is to provide the next, you know, where I spent it. So you basically have to provide the point where Alice got the coins from Carl.

And that kind of link is actually a broken link. And so the challenge will succeed and the operator will, you know, be slashed and, you know, pay the person who challenged him. But Carl, doesn't they start to need like a panopticon, right? Like loads of people just watching like a hawk on whether the operators are cheating or not. How do you incentivize this panopticon? So it's just the main chain, right? So the main chain has this dispute period. You submit transactions on the main chain.

If you notice that one of those transactions is trying to withdraw a coin that you own, then you or anyone else just submit a challenge. And the cool thing is that these challenges are actually funded by the person who is trying to withdraw coins. So in other words, there's always, there is a bounty, basically, every time that you want to, that some invalid exit is submitted. So, you know, it kind of like is paid for by the person who's trying to exit. There's a different kind of problem here as well, which is, so the case is like this, right? Brian and

like Brian and Meher are users both of us put our money into the child chain the plasma chain and Carl's the operator the malicious operator of the plasma chain and he sort of

allocated Brian's coins to Meher did not publish that block and then and then in the next block he spent like Meher spent his coins but he

the card published that block and then like Meher is trying to withdraw the coins the Brian's coins essentially to the main chain and Carl is allowing that behavior to happen right that's the that's the essential nature of the problem now

wouldn't this problem become majorly worse if Carl is actually the biggest mining pool on the Ethereum network as well as the operator right now if if Carl is the biggest mining pool on the Ethereum network if let's say so Brian is protest

in some way. He's trying to prove that like Carl's been malicious, he has not published this data and he's trying to play this game essentially. But like if Carl is the biggest mining pool, then Carl could just censor Brian's efforts to prove that

on the main Ethereum chain and that's game over for Brian. So yes, what you're talking about is like censoring the main chain so that these exits don't actually get included or the malicious exits get included with no challenge. So there is, thankfully, some guarantees which proof of work provides, which are, you know, it is difficult, it is costly to censor a chain for the, you know, a period of three weeks and make sure that there is not a single minor that includes a, or a single block that includes the transaction which challenges that, you know, withdrawal.

And so basically what we rely on is we rely on the security properties of the root chain. to provide security of these child chain. So the child chain might be censorshipful, and it may commit an invalid block, but we have to make sure that our root chain is as resistant to censorship and as resistant to reversion as humanly possible. And so that is like the entire design space

of these consensus protocols, Casper, Proof of Work, and this is like part of the three kind of front of research. And that's basically what we're doing, is making sure that it is very, very, very costly to the point where it's basically impossible to, you know, censor or revert the main chain in a way that hurts the network. Yeah, I mean, I think in the scenario I may have described, you would actually need to have a 51% attack, right? You need to have a majority of the hashing power. And then, you know, even if, let's say you have 80% dashing power, somebody else

gets a block in, well, you're going to have to orphan that block. I mean, it would be a completely obvious full-scale attack on the network. So, yeah, of course, if that happens, all bets are off. Exactly. Or a very popular ICO is going on on the main chain. For two weeks, spamming the entire network completely. Like the status ICO spammed the network for a day. So part of it is actually when you submit your exit, you are going to fund the gas price of the challenge, right? So if it's not a problem with, you know, censorship, like actual 51% attack, and it's just a problem where you don't, you know, have enough money to, like, challenge because your gas price is too low, you're actually okay in that circumstance

because the cost of the challenge, the cost of that gas price is computed within the, or is included in the exit. So, like, when you exit, if gas price is, you know, 100 G-Way, then maybe there'll be a security factor of 10 or 100. So you now have this extra bond, which pays for the gas. So you'll be fine, even in a congested network. And you'd have to exit for each one of these coins. So it just gets, like, impractical.

And we don't actually have this problem, thankfully. The coins are stuck. That is the problem. It's not that they can be stolen. They are just stuck. And that is annoying. But that's why we have more secure. consensus protocols or, you know,

slashing of central operators that misbehave. A separate related question, though, is let's say I'm a user and I'm on the child chain, I'm doing the transactions. Now, do I start to need a bot that's always going to watch

what the operator of this child chain is doing and be prepared, like, and have an automated script that as soon as my bot perceives this data availability problem, withdraw and do this gas price management, or is it the same? Like basically what I'm trying to ask is one of the criticisms of the Lightning Network is

the Lightning Network pushes a lot of responsibility on the user who we are expecting to be an average Joe that doesn't understand any of it, right? So on the Lightning Network, I always have to keep a full-on node that's like watching the Lightning transactions to make sure I got the money. That's fine for a power user, but that wouldn't work for an average Joe. Does plasma have a similar problem where if I'm a normal user, I start to need these bots to keep watching on honesty of the operators? So someone does need to challenge invalid transactions.

Now, the actual extent of this problem, I would say, is not so high, at least in the case of plasma cash, because, number one, a invalid, transaction will essentially not be a problem until your particular coins are trying to be stolen, right? And when your coins are trying to, you know, there's an attempt to steal your particular coins, there is a bounty that anyone can win for blocking that transaction, blocking that challenge. So the only thing that would keep someone else from blocking, you know, and that invalid exit

and getting the bounty themselves is a, you know, is data availability, basically. If you are the only one who has information about your coin, then you're the only one who can challenge your coin. But in reality, there are going to be people who are probably going to store the information of other people's coins for probably not too much money, I would imagine. And then whenever there's an invalid exit or whenever there's an exit in general, they just check against their database. they say, is this valid or is this not valid?

And if it's not valid, then they submit a challenge and, you know, make a whole bunch of money. So there is a kind of, like, inbuilt incentive for doing these invalid challenges. And, you know, you could even do a mechanism similar to how, like, Trubit was explaining, where you have, like, intentionally invalid exits so that people are incentivized to randomly store coins. So you can, like, do fun things. It's not a huge issue. I don't see it as a huge issue. and it should be, you know, it's part of the network,

kind of name of the game in some ways for these state channels to have this challenge response thing. So let's talk a little bit about where we're at and what the timeline on roadmap is. So what are the main things that still need to be built for Plasma Cash to go live? And what are the biggest open questions or problems that need to be solved?

Yeah, so first, plasma cache, plasma, all of these designs are just a design. And anyone can implement them. And currently, I am not personally implementing a huge amount of it. Actually, I, but there are a number of teams that are working on these things. Now, in terms of, like, research problems that need to be solved, there are definitely kind of open questions. So there's one of those open questions. is doing splits in plasma cash.

So essentially you have a particular coin and you want to make it, you want to subdivide it into a smaller kind of unit of transaction. Anyway, that's one kind of open question. There isn't a lot of consensus around the best way to do that. Another issue is there are actually ways to exit coins,

even if there's an invalid state transition in the history. You can actually like still use that coin. Now this makes the exit process, is much more complicated, but if there was some kind of magical wand that we could use to kind of like make the exit really simple while including an invalid transaction, that would be awesome. So that's another open research question. However, none of these things are kind of games show stoppers for anyone who does want to implement plasma chain as it is right now. We already get huge transaction throughput increase with these plasma chain.

and they're not that hard to implement. So I'm actually working on a course on cryptoeconomics, you know, cryptoeconomics. That study, check it out. But that course will go through building a, you know, centralized payment processor with like PayPal, then turn it into a Bitcoin kind of chain with its own consensus protocol,

and then add to its security by turning that into a plasma chain. And so throughout that actual course, like I am going to be implementing a plasma a plasma chain and you know you can implement it too as you know as you know we follow along and so so this is actually and this this course is not going to take you know years to create it will be it's it's coming it's it's on its way and being worked on actively you know in the next few months and so this is plasma is coming soon

and can be implemented today there are no blockers and so you should implement it it's it's an exciting research area. Do you think there's a business model for a private company to implement plasma chains? Absolutely. I mean, any kind of business model which you are, you know, any protocol, any application which like desires this higher level of security than a centralized service can provide, anything like that can fit very nicely into a plasma chain.

including projects that are run by private operators. So anyone who's doing a kind of like enterprisey blockchain, for instance, might as well get the security of a public decentralized blockchain by adding this plasma chain linking. And you don't really get too many downsides. It's actually not super hard to implement. However, and you get this massive upside where the people who use your chain are now, you know, they can feel safe.

They can say, okay, no matter what, happens to this central operator, my assets are in fact safe. And so it kind of just changes the name of the game, changes the trust model, and provides good opportunities for everybody. So I understand that point when it comes to, let's say you have a private chain that's some sort of exchange custody thing, right? And you take assets from, you know, Bitcoin, Ethereum, you know, that live on a blockchain or I guess Ethereum assets. And you move them all. onto that chain and then the plasma chain runs there and you can exit. But I mean, I guess many or if not most enterprise or private blockchain use cases

don't necessarily involve crypto assets or tokens. So then is there still any point to this linking? And because what does exiting mean in that scenario? That is a fantastic question. So the actual like what does exiting mean for your application can mean different things. So in plasma cash, it's very clear what exiting means. Exiting means taking your token and putting it onto the root chain. However, in a general, like a plasma chain that uses smart contracts,

exiting might mean something different. It may mean exiting some level, some amount of state and putting that onto the root chain. There may be other, you know, you may not have a lot of things that you want to exit necessarily, but you still want guarantees around ordering, like, lock ordering that can't be reverted. So like there's, there are, this is the kind of, unfortunately, because the space is so young, there are, there's, you know, buzzwords that people throw around and they say, okay, this is, you know, a plasma chain, this is a state channel, this is a lightning network, this rating,

whatever. And then people assume that those, those designs are like static and they exist in this kind of vacuum of possible, you know, applications that you can build. in fact, there is an entire space, you know, crypto economics, which has these fundamental building blocks, which plasma was created out of, which all these state channel solutions, and even, you know, Sharding and Casper, they are, the fundamental building blocks are what you really need to understand to get the kind of decentralized security properties and decentralized guarantees that we're looking for. And so, so like, you can take a,

your, you know, you can take the kind of plasma design and you can alter it in some way that fits your application using this, you know, set of tools, these crypto-economic tools, and then, you know, produce a, you know, private blockchain, which provides the guarantees that you're looking for, for your specific application. And as the space matures, the things that we're going to focus on are not the kind of buzzword design, you know, kind of spaces, but instead, just a fundamental understanding of how these systems get built. And that's what I'm hoping that we can get to, you know, this year. You have mentioned a couple of times during this recording that plasma is relatively easy to implement.

And I get a sense that plasma is easy to implement because it is basically a set of smart contracts that are quite simple, right? They need to accept money and they need to accept block hashes and they need to implement this challenge response game. Right. So that's a smart contract. And then once there's a plasma chain, there's validators on the chain and they can use a consensus mechanism. mechanism and lo and behold, lots of different consensus mechanisms are being developed. There's tendermint, there's like DFINITY, there's the Polka dot school, and then there's Casper.

So you could presumably like borrow from a lot of work. So it's basically like forking a consensus client and writing a smart contract and having a profitable application. So I'm curious what Ethereum Foundation's approach here is going to be. Is your approach going to be, hey, we guys are the like thought leaders here. we make the spec and let any commercial partner go and actually make the integration. Or is it going to be that the Ethereum Foundation will dedicate some person from the Go Ethereum team to actually implement the first working plasma chain?

So it will be the first thing that you said. So essentially we are kind of thinking about these designs and coming up with architectures that makes sense and design patterns, this whole space of crypto-economics, and then we publicize our results, and then anyone in the community can pick that stuff up and either contribute back to the research, or they can implement it themselves. And so, like, Ethereum Foundation and Ethereum community

is a very weird and decentralized, you know, a kind of group of people. And that basically just means there's some people who have good ideas, and that doesn't mean that they're even from the Ethereum Foundation, You know, Joseph Poon is not an official Ethereum Foundation researcher. And they come up with, like, good ideas, publish those good ideas, anyone who wants to picks those things up and runs with it. And everyone kind of like lives together and is in a big, happy community that's all brought

together by these crypto economic incentives. So it's like this, it's a, it's this interesting process of basically idea propagation, meme propagation, and then people pick up on those ideas, pick up on those memes, implemented themselves. And, you know, you can make all your money. and do all your, you know, fancy, you know, community building and good stuff and contribute back. And even the research process is open for anyone. Go on ETH research and, you know, write up a plasma spec and criticize our designs because they're not perfect.

So that's do as you will. So before we wrap up, one important question I'm sure is on the mind of many listeners. So when is the ICO happening and how can people reach out to you if they want to get in on the pre-season? sale. No ICO, clearly. This is a design. This is a space. ICOs are just one little thing you can do with this incredible consensus forming smart

contract blockchain. So, you know, it'll be a lot of fun. We can, you know, not make a big deal about, oh, God, make our little landing pages with our flashy buzzwords, crypto economic security verification. Oh, God. cheese, let's calm down, let's make the space and the world a better place. Okay, cool. Well, thanks so much for joining us today, Carl.

This sounds super exciting. I mean, I think this is a really coherent and interesting vision for Ethereum, and I'm extremely excited to see when what of this is actually going to get built and implemented and be usable, and it sounds like it's not far away. So thanks so much for joining us today. Thank you so much. And of course, we'll have links to a bunch of stuff like the Plasma Cash specification that Carl published or his crypto economics course and other things that people can check out if they're going to learn more. So yeah.

So we'll have that on the show note and people can check that out. Yeah, so thanks for once again tuning in. So we're putting out new episodes of Epicenter every week. You can get the audio on iTunes, SoundCloud or any other podcast application or you can get the videos on YouTube.com. slash Epicenter Bitcoin. And we also have this Gitter community, which have some little bit of activities. So you can check that out.

That's at app center.tv.tvs. And otherwise, if you want to support the show, you can leave us an iTunes review that helps new people find the show and you can let us know what you like and what we can still do better. But thanks so much, and we look forward to being back next week.