Scaling Public Blockchains - State of the Art Layer 2 Solutions

HOST:  Hey, everybody.  Welcome back to The Unstoppable Podcast.  I’m your host, Diana Chen.  And I’m here today with my cohost Braden Pezeshki.  Braden is the cofounder and CTO at Unstoppable Domains and he’s here today to talk to me more about scaling on the blockchain and L2’s continuing no from our conversation from the previous weeks.  If you haven't listened to our podcast episode from last week and the week prior, make sure you go back and listen to that.  We talk about some of the problems that we face with scaling on the blockchain today as well as some of our state-of-the-art solutions that we have.  And today we’re going to continue that conversation.  Braden is going to go break everything down for us and tell us how we can fix some of the problems that a lot of you are experiencing with high gas fees and all the issues that are preventing you from making all the transactions that you want to make on the blockchain.  So, hey, Braden.  Thanks so much for being here.

BRADEN PEZESHKI:  It’s a pleasure to be here.

HOST:  Cool.  So to start us off, let’s just go ahead and talk about some of the state-of-the-art solutions.  In our last episode, we talked with Matt Gould about some of the solutions like state channel, side chains, plasma, optimistic rollups, ZK rollups.  Today we’re going to break that down.  So basically there are two questions that everybody needs to ask when designing an L2 or a layer 2 solution on the blockchain.  And what are those two questions?

BRADEN PEZESHKI:  Sure.  So the two questions are whether or not you want to verify the state of the L2 with cryptographic proofs on the L1.  And then the other question you want to ask is around data availability, which we can kind of cover what that is once we, once we group therapy there.

HOST:  Okay.  Cool.  Let’s just dive right in then.  It’s probably easier to talk about those things in context.  So the four that we’re going to talk about today are plasma, optimistic rollups, ZK rollups and validium, and each of these four are sort of placed into the four quadrants of answering the questions that you just stated yes or no.  So why don’t we start with--is plasma a good one to start with?

BRADEN PEZESHKI:  Yeah.  That’s actually fantastic.

HOST:  Great.  Let’s start with that.

BRADEN PEZESHKI:  So essentially plasma answered no and no to both of the questions.  And so let’s just kind of look what that means.  So L2’s--the basic kind of life cycle of an L2 and when someone like submits a transaction to the L2 is the user deposits their assets or locks their assets up on the L2.  And then the operators of the L2 like receive these transactions, process these transactions, and then submit commitments to the L1.  So these commitments are basically L2 blocks.  So users submit transactions to the L2.  These transactions are pending until the commitment on the L1 is made.  And so all the different L2’s basically have rules around like governing what these commitments look like, who can make these commitments.  And so on chain cryptographic verification is really verifying that these commitments are correct cryptographically.  So when you submit a transaction to the blockchain normally, the way it works is you sign up with a private/public key pair that proves that you own a private key.  Right?  And L2’s are basically designed as systems to kind of compress data.  So if you were going to do the same validation, it would cost like basically an equivalent amount of gas.  But the goal is to try and simplify what you’re committing to the L2 and, like, compress that data, and that’s where the cost saving comes in.  So the way ZK rollups and validium do this is they use zero knowledge proofs.  But plasma and other solutions that don't use on-chain cryptographic verification, use like crypto-economic games to enforce correctness. So the idea here is that the operators of the L2 when they take a bunch of transactions and they like bundle it up under these commitments and then put it on chain, they’re basically trusted by default.  And this is, like, this is the optimistic part both plasma and optimistic rollups.  We basically trust them by default but then users can submit fraud proofs and they have ways of slashing stakes that these L2 operators put up in order to run these blockchains.  And that’s kind of the general mindset around like not doing cryptographic verification.  And or course it’s much cheaper to do this way because if you don't have to verify that like some user sent some funds to somebody else then like it’s just cheaper on chain.  So you can get ridiculous speedups of like 1000x with these kinds of solutions.  And there’s really no limit in theory to throughput because you can just load more and more transactions and because you’re not doing any verification on the individual transactions, you’re just kind of checking if there’s fraud.  You can just get ridiculous speedups with that.

HOST:  And sort of to your security point about not using cryptographic on chain for plasma, I assume it’s a pretty safe assumption to assume that everything is safe already without having to use the cryptographic verification or is that something that we don't know.  Like how confident are we about that right now?

BRADEN PEZESHKI:  So essentially kind of the way it all works is you--like plasma operators submit commitments to their L2 and then there’s a period called a challenge period where users and any account on the system can go and say, hey, you know, I don’t believe that block.  Right?  And I want you to prove that you like created this block correctly and they have to respond within that week in order to see that the chain is valid.  It does require users to challenge and kind of be actively monitoring, but the idea is that these chains have rewards in place so there’s always going to be an economic incentive for someone to be watching the plasma chain and making sure that they submit challenges to bad blocks.  That’s kind of the general game theory around it.

HOST:  Okay.  Got you.  And so then the other part of plasma is that also does not use on chain data availability.  And so what does that mean?

BRADEN PEZESHKI:  So data availability is really where plasma kind of falls short.  So let’s take the case where the L2 operators are acting poorly.  They’re acting maliciously.  They’re not processing certain users’ transactions.  So in this case the only real recourse users have--and this is for all L2’s for the most part--is to exit the L2.  And so this is what’s called a mass exit.  And when you’re exiting the L2, you have to correlate.  Right?  Because there’s no state of the L2 directing stored on L1.  So you’ve got to prove that you own assets that are deposited on the L2.  So because it’s basically a black box, like, when you deposit your funds on the L2 they’re like locked in a vault, right, with all the other Ether.  But if someone says, you know, I want to withdrawal all this USDC or all this ERC20 or all of these NFT’s from the plasma chain, you need to prove that you actually own that asset on the L2, right, because someone might have transferred it to you or you might have deposited it but transferred it to someone else and are trying to take it back and run because you made some trade on L2.  Right?  So the proof of ownership is called witness data.  And so at the time of exit users need to be able to provide this witness data.  Right?  And this witness data you can derive it if you know the whole state of the L2.  So technically it’s a Merkle proof.  I don't know--have you guys talked about this or is this a little too in the weeds.

HOST:  No.  This is a new one.  So if you could break it down for us, that’d be great.

BRADEN PEZESHKI:  Sure.  So Merkle trees are--it’s a hash tree.  So I’ll explain what this means.  So you basically--what happens I you take a bunch of data and most data in the blockchain space is stored this way.  So say you’ve got a list of transactions.  Right?  The way a Merkle tree is constructed is you hash each of those transactions and then you build a tree where each node hashes the previous tree like sub-trees.  So what this means is that you can take an enormous bunch of data and you can hash it in such a way where if somebody messes with one of the values, like, deep in the tree, the hash at the very top of the tree is messed up.  So this is how blocks are formed.  Right?  They’re basically complex Merkle tree structures where, like, a transaction is part of the hash, the timestamp is part of the hash, and so what plasma chains do is--and like what they actually commit to the layer on is they commit the hashes.  So it’s just a series of hashes that represent the state of the plasma chain.  And so you have to provide a proof that you are one of the leads in that big hash tree.  So each block--each commitment represents a section of the state.  Right?  And so you have to prove that you own the leaf inside that specific state.  That’s generally how it works.  So you need this witness data in order to exit.  But the problem is that this witness data isn’t available on chain.  Right?  So, like, in Ethereum this Merkle state is store in every single node.  So they are--they have access to it and they can prove that you own these assets and you can execute smart contract transactions and stuff like that.  But for a layer two they just have the representation at the state.  And so if you don't have access to the Merkle tree then you can’t generate the proof that let’s you claim your asset.  And so the problem that plasma chains ran into is what’s called the data availability problem where users don’t have access to their data, specifically like their witness data to get out of the plasma chain.  So that’s kind of the general data availability problem.  You need this data, like, the Merkle tree data in order to exit the blockchain.  But it has to go through these plasma operators.  So there’s kind of a trust breakdown there. 

HOST:  Okay.  Got you.  And just to make this feel a little more tangible for our listeners, what would be a situation where a user would want to exit the blockchain and would need that witness data that they can’t get with plasma?

BRADEN PEZESHKI:  Sure.  Well, say the plasma operators won't publish any blocks.  Right?  So a lot of these plasma chains works by like operators staking in order to have the rights to get on.  So let’s say someone malicious staked money to become a plasma operator, published a block, but--and that block was valid.  They kept on proving it.  But they refused to publish that data.  Then those users are basically locked on the L2.  So you can use it to--you can use this attack vector to lock people on the L2.

HOST:  So that basically--for users that means that they can’t complete a transaction, whatever that transaction might be.  Is that right?

BRADEN PEZESHKI:  Yeah.  Well, what it really means is they can’t get off to the L1.  And because they control the funnel for publishing transactions on the L2--so I guess you’re right.  Yes.  They can’t publish transactions.

HOST:  Okay.

BRADEN PEZESHKI:  Yeah.  It’s like a denial-of-service attack basically.

HOST:  Got it.  Got it.  Okay.  Cool.  So that was a lot on plasma. 

BRADEN PEZESHKI:  Yeah.

HOST:  So just to sort of summarize a little bit, the--would it be fair to say that the biggest pro to using plasma is that it’s super fast.

BRADEN PEZESHKI:  Yes.

HOST:  And then the biggest con is that it’s hard for users to get off of the L2…

BRADEN PEZESHKI:  Yes.

HOST:  Because they can’t the witness data on chain.

BRADEN PEZESHKI:  Uh huh.  And there’s some other weird crypto-economic things where it’s hard to--for example it’s hard to store more value on a plasma than the plasma is secured with.  And so it makes operating a plasma very expensive because there’s always kind of this looming economic reason to just stop the plasma chain.  There all sorts of side cases that popped up when they were initially designing these protocols that caused people to look for other protocols.  So like optimistic rollups, which I think is what we’re tackling next.  Right?

HOST:  Yep.  Yeah.  We can roll into that.

BRADEN PEZESHKI:  Yeah.  So they basically were, like, I think--we’re okay with kind of no verification of state.  So users can--or sorry plasma operators--or sorry.  Optimistic rollup operators can just publish commitments as they want and we’re okay with this kind of fraud proof mechanism where there’s this challenge period and users monitor the rollup.  But we really want users to be able to withdraw.  And so they added that availability.  And that’s kind of the major innovation there. And then they--the optimistic rollup guys have also done some very smart things with--optimistic rollup chains are basically just like copies of Ethereum.  So smart contract and developers--like smart contracts work just as they do on the L1 is what I’m trying to say.  So developers can easily build applications.  They can--yeah.  It works just like Ethereum does, which is wonderful.

HOST:  So then what is the biggest con or the biggest problem with optimistic rollups?

BRADEN PEZESHKI:  The fact that there’s no on-chain verification, like, state transitions because, like, operators can still publish bad information and there’s no way to stoop that from happening.  Yeah.  So you end up with these complex economic games to stop it from happening.  And typically these economic games have holes or ways that they’re just a little more complex and they require users to be online all the time.  There’s just a lot of caveats. 

HOST:  Right, right.  So then I guess the solution to that is to build in the cryptographic verification and that bring us to ZK rollups, which--there’s actually a famous quote from Vitalik.  He said five-to-ten-year timelines ZK rollups will win all use cases.  So that’s a big statement.

BRADEN PEZESHKI:  Hyping it up.

HOST:  Yeah.  Lots of hype there.  So tell us more about what ZK rollups are and why there’s so much hype around it.

BRADEN PEZESHKI:  Sure.  So ZK rollups use cryptographic verification in order to make these state changes on chain.  And they also--I don't think we mentioned this, but the term rollup specifically--so anytime you hear the word rollup in the context of an L2 means that they have data availability on chain.  So they actually publish the data inside the, inside the call data of a solidity contract.  So they don’t--so when people say they store the data on chain what they actually mean is they don't store it inside the contract because everyone kind of knows that storing stuff on Ethereum is expensive.  But there’s, like, actually--there’s cheaper ways than actually putting it inside the EVM storage.  You can keep it inside the transaction receipts.  And that’s the way all these rollups work.  But let’s go back to rollups real quick.  So they do--the use zero knowledge proofs.  That’s where the ZK comes from.  And then they also store all the data on chain inside the call data.  So that means that, like, if you were server, you can recreate the state of the L2 by just looking at the Ethereum blockchain and like looking at the transaction receipts, which is really nice because it means that, like, anybody can do decentralized reading of these rollups.  So it has like nice censorship qualities.  And it also--because like each state is verified cryptographically it means that you can--like you’re never going to run into a situation where like the state might be wrong or there’s some challenge period around the state.  Right?  Like the--as soon as it gets processed, it’s valid.  Like this is the beauty of zero knowledge rollups.  So it’s much simpler from, like, a conceptual standpoint because basically what happens is, like, a user sends their transaction over to the L2 operator.  The L2 operator makes a cryptographic proof, publishes it on chain along with all the data and you know as soon as that transaction published that it’s set in stone.  So it’s much simpler and as a result there’s, like, less edge cases around it, which is why it’s so nice.  And Ethereum also last year got a major price saving, like, EIP in.  So an Ethereum improvement proposal that, like, cut the gas cost down.  So it's literally like a fourth the cost to store call data inside the receipts.  So there are, like, lots of things going for it and also Vitalik has been pretty insistent that he wants to kind of prioritize this kind of scaling solution when Eth 2.0 comes out.  So there’s going to be cost saving there. 

HOST:  Got it.  So when you’re storing everything on chain, wouldn't that slow things down or how…

BRADEN PEZESHKI:  It does.

HOST:  How do they maintain speed?

BRADEN PEZESHKI:  So, well--yeah.  So this is what I was trying to get at earlier is you don't store in the same way that you store like your ERC20 token on chain.  So that storage that you’re accessing when you’re storing the ERC20 token is actually--it’s storage that smart contracts can access and modify.  But the storage that we’re storing it on is--let’s actually take a step back here.  So when you’re writing a solidity program, which is the smart contract language on Ethereum, you basically--you write this contract, which is like a class and it's got all these methods on it that say, like, you should transfer from A to B.  You should--you can withdraw.  You can do whatever.  Right?  So you write this function call.  Right?  And these function--this function call has arguments.  So it has like--you can put an integer in the first slot.  You can put an address in the second slot.  Right?  The way these zero knowledge proofs get stored is they stored as arguments to the function.  So typically when you put an argument inside the function, the way like an ERC20 token is stored is it takes that argument and then it puts inside like the smart contract storage and it can modify it or do whatever.  But if you just like leave it there inside the function call, like, and you don’t do anything with that argument you just consider it additional data that comes in along with the function call.  You can actually access that data by scanning the transaction receipts because when you submit a transaction you are also submitting that big, long list of, like, this is who owns what on the L2.  That’s kind of the way it works.  So you just discard the function argument.  That’s like really technical.  But it’s different and it’s much cheaper and you still get like a hundred XPFs with zero knowledge proofs.  But it’s not like thousands of times speed up.  Right?  So you can still get fast, much more efficient, like, blockchain transactions, but it’s like--yeah.  You’re absolutely right.  It’s not as fast because you’ve got to verify those cryptographic proofs on chain.

HOST:  Got it.  So if I were to relate the sort of back to like something that we’re all familiar with like a traditional contract.  Like you see a piece of paper.  It’s got all this--all these words on it and it’s got blanks where you can fill in the key information that differ from one agreement to the next and so with--how you’re describing this data being stored--it’s like instead of with ever transaction, you have to store this entire contract with, you know, a thousand words or how ever many words are in the contract.  You only have to store the blanks--the words in the blanks that you’re filling in, like, the things that are different from transaction to transaction. 

BRADEN PEZESHKI:  Kind of.  The cost associated with storing stuff on Ethereum is, like, storing it in this special memory that you--that like smart contract can access.  But you don't store it there.  You store it in like the cheaper transaction receipt memory, which is like the same way that balances are stored.  It’s just cheaper and it’s a little hacky, but it’s just cheaper.  Yeah. 

HOST:  Got it.  Okay.  So the main problem with ZK rollups is that it’s not as fast as some other solutions but otherwise it’s a pretty solid solution. 

BRADEN PEZESHKI:  It is pretty solid.  So one of the big--there’s two technical limitations and kind of things that dictate how efficient like ZK rollups are.  So it’s the cost to verify proofs on chain.  So these rollups are very--or sorry.  These zero knowledge proofs are very expensive to verify on chain.  So it’s like five million gas, which comes out to be like half an eighth or something like that each time you verify.  So it’s very expensive to verify these proofs on chain.  But it is like--depending on your zero knowledge proof, it is, it is almost fixed cost.  But the problem is that, like, in order to generate these proofs, it takes a lot of computation like off chain.  So there’s actually--you can generate these proofs in pretty close to linear time, which means that if you give me ten transactions it might take me ten seconds to make a proof.  And if you give me 100 transactions it will take me 100 seconds to make a proof.  But that--there’s like kind of problem there where if--like you’re limited by how fast you can--like if you can make a proof for one transaction in one second, that means you’re maximum transaction throughput for the blockchain is never going to be faster than one second per transaction.  Right?  So currently has stands at least for Unstoppable that number is around like 2.7.  This is kind of like an estimate.  But it’s around 2.7 per second.  So it’s great.  Right?  But it’s still not perfect and there’s no way to overcome this other that like making special chips and stuff, which I mean maybe will happen.  But we need some more traction in order for that to work.  So you’re always going to be limited by the complexity of generating these zero knowledge proofs. 

HOST:  Got it.  Okay.  Let’s move on and talk about the one, which is validium.  So this solution--it does use cryptographic verification on chain, but it does not use on-chain availability.  So talk more about validium.

BRADEN PEZESHKI:  Sure.  So the idea here is that we want all those properties like that cryptographic verification on-chain provide us and that’s most that there’s never going to be an incorrect state on chain.  Right?  So you never have to worry about bogus state updates.  Right?  So users can see that like the Merkle root is what it is and it makes sense and it’s never going to be invalid.  Right?  And this is big from, like, a useability perspective especially for like an application like blockchain domains because it would really suck if you transacted with somebody or you--and you wanted to send it to their name and cryptocurrency to their name.  And you saw that there was a pending update on that domain and it was going to take a week to resolve.  Right?  That would be, like, a non-optimal user experience.  So it’s really nice that this cryptographic verification happens on chain because you get finality within minutes, which you don't get with these other options.  But validium basically takes the stance that it’s too expensive to store all this data on chain.  So you can--for some perspective, if you submitted like 10,000 transactions using a ZK rollup, let’s say you spend five million gas on the proof.  You’re going to spend an additional 16 million publishing the call data for the data availability.  So it’s actually extremely expensive at scale to do this data availability.  And especially for like--yeah.  So validium basically says, hey, we’re not going to store the data directly on chain, but we are going to give user ways to punish the blockchain if they don’t publish the data.  So validium uses a committee of accounts that can basically say, hey, we’re going stop the blockchain or we’re going to slash funds or we’re going to punish the L2 operators if they don't publish the data within a reasonable timeframe.  And there’s other mechanisms that validium solutions could use to sort of mitigate the withdrawal problems associated with not having data available on chain.

HOST:  Got it.  And then isn’t there also some weird signature with validium or something like that?

BRADEN PEZESHKI:  For ZK rollups and validium, you’re using the same virtual machine so to speak on the L2.  So they’re both going to have those issues although it’s not a given.  So there’s zero knowledge proof systems that use Ethereum private keys and stuff like that.  But it’s not a given.  They’re called circuit builders.  I don't know if anyone wants to look this up.  But zero knowledge circuit builders.  And there’s open-source ones.  Zero knowledge proofs have been out for a while and so there’s a variety of project there.

HOST:  Got it.  Okay.  Cool.  So that was a lot that we just went through.  I’m going to summarize real quick.  Basically, when you’re building an L2 solution, the two main questions that you’re asking is whether or not to use on chain cryptographic verification and then whether or not to use on chain data availability.  The four solutions we went through are plasma, optimistic rollups, ZK rollups and validium, which fall into the four different quadrants of those two questions.  Any final thoughts on this, Braden before we close out? 

BRADEN PEZESHKI:  No.  But it’s great to work on blockchain.

HOST:  Awesome.  I love that.  Okay.  Well, thanks so much, Braden, for explaining all of these scaling state-of-the-art solutions to use today and thank you listeners for tuning in.  I hope you learned something new.  We’ll be back soon with another episode of The Unstoppable Podcast.