Bankless - Alpha Leak | The Bull Case for zkBTC

Episode Date: November 18, 2022

In this episode, David is joined by John Light of Sovryn and Eric Wall, who moonlights David on the Bitcoin technical details throughout the interview. The three go over the bull case for ZK-Rollups on Bitcoin. It’s undoubtedly the frontier. ------ 📣 Infura | Join the New Decentralized Infrastructure Network Early Access Program www.bankless.cc/infura  ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/?utm_source=banklessshowsyt  🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/  ------ BANKLESS SPONSOR TOOLS: ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum  👯 DESO | DECENTRALIZED SOCIAL BLOCKCHAIN https://bankless.cc/Deso  🦁 BRAVE | THE BROWSER NATIVE WALLET https://bankless.cc/Brave  📡 TRUEFI | CRYPTO FINANCIAL HUB https://bankless.cc/TrueFi  👾 SEQUENCE | ALL-IN-ONE PLATFORM https://bankless.cc/Sequence  ⚡️FUEL | THE MODULAR EXECUTION LAYER https://bankless.cc/fuel  ----- Topics Covered 0:00 Intro 5:10 John’s Background 8:24 How zkBTC Works? 11:00 Eric’s Interest 15:43 A Better Lightning Network? 21:33 Rollups on ETH vs. Lightning Network 25:50 Rollup Potential 29:24 Optimism 32:15 Expressivity 43:53 Limitless Bitcoin Applications 46:29 Layer 3 Protocols 50:25 What Needs to Happen 52:05 Forks & Flippening Effects 58:00 Proof Systems & Recursive Covenants 1:09:40 Next Steps 1:12:00 Research 1:14:12 Eric’s Thoughts on Bitcoin 1:16:50 Closing & Disclaimers ------ Resources: John Light https://twitter.com/lightcoin  Eric Wall https://twitter.com/ercwl  Validity Rollups on Bitcoin https://bitcoinrollups.org/  ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://www.bankless.com/disclosures 

Today on this AlphaLeak episode, we are exploring ZK Rollups on Bitcoin, which I didn't even know was possible until I stumbled upon this website called Bitcoinrollups.org, which is a research endeavor out of this man, John Light, who got a grant to go research, what can you do when you put a roll up on Bitcoin? Is that even possible? And so it turns out a lot as possible. Also in this episode, I bring on Eric Wall, who's also a bitcorner, a technical bitconer, to help me co-moderate this conversation, because this is something that Eric Wall, I know, is just. just very interested in and wants to see happen on Bitcoin. So we talk about roll-ups on Bitcoin, of course, what that means for the Lightning Network. What you can do on a roll-up on Bitcoin? Is it just a payments network that is a better Lightning Network, or is it the full suite of smart contracts, tokens, what's it take to put roll-ups on Bitcoin? Do we have to hard fork? Is it just a soft fork?

How, like, complex is this? How is the community going to receive this? Because the Bitcoin community is generally resistant to change. but we've kind of been seeing a tide shift in the Bitcoin community lately. Maybe there's more bitconers that are more interested in something like roll-ups on Bitcoin. And overall, I'm just really fascinated about this concept, roll-ups on Bitcoin. And it's kind of restored my interest in Bitcoin. It's one of the most innovative things I've seen out of the Bitcoin space in a really long time.

And so this is something that I hope to see coming for the future of Bitcoin. So I hope you enjoy this exploration into the world of ZK. Roll-Ups on Bitcoin with my two guests, John Light and Eric Wall, right after we talk to some of these fantastic sponsors that make the show possible. If you've been listening to Bankless, you know that we're fans of the modular blockchain thesis. The idea that blockchains will separate execution

from data availability and consensus, allowing all three to become the best versions of themselves. And Fuel has built the fastest modular execution layer in the industry. By supporting parallel transaction execution, fuel unlocks significantly faster throughput for the Web Free world. Fuel also goes beyond the limitations of the EVM

with its own Fuel VM, which is more efficient and optimized, opening up the design space for developers. And lastly, fuel brings a powerful developer experience with its own domain-specific language, sway, and a supportive tool chain called Fork. With Fuel, you can have the benefits of smart contract languages like Solidity, while adopting the improvements made by the Rust Tooling ecosystem, letting the fuel development environment go beyond the limitations of the EVM.

If you want to learn more, there's a link in the show notes to see how you can get involved with a Fuel Network. Sequence is the all-in-one developer platform you need to build Web3 games and applications. For your users, Sequence is a smart wallet, and it's the easiest, most intuitive onboarding your users will ever experience and comes with all the features users need to feel empowered in the Web3 world. Multi-chain support, NFT display, and users can buy SFTs, NFTs, and Qt, and crypto directly with a credit or debit card. For developers, Sequence is the plug-and-play platform for Web3 games and apps. Their APIs let you bring NFTs, and tokens into your game or application.

And a Sequence Relayer enables gaseous transactions for your users. Sequence already power some of the best Web3 games like Skyweaver, NFT projects like Cool Cats, and marketplaces like NiftySwap. And Sequence is compatible with all the EVM chains, including Ethereum, Polygon, Binance, Smart Chain, Arbitrum, optimism, and avalanche. So go to Sequence. dot, XYZ slash bankless to start building or speak with the Sequence team today. TrueFi is Defi's largest credit protocol, connecting global lenders with institutional-grade lending opportunities. TrueFi has completed over $1.7 billion in originations, and pay.

paid out nearly $35 million to lenders, proving that DFI is ready to take its next big leap into the $8 trillion credit market. Trufai gives lenders, like you, access to sustainable high-yield opportunities backed by real-world investments, usually reserved for high net worth individuals. At the same time, fund managers use Trufai's financial infrastructure to bring their portfolios on-chain, benefiting from the global liquidity, cost savings, and transparency of D-Fi. TrueFi is a decentralized financial utility. The protocol is owned and governed by the Trufai Dow, and Trufai is here to bring DeFi

into the golden age, bridging the power and access of crypto with institutional-grade lending opportunities and portfolio tooling. Explore the diverse financial opportunities available on TrueFi or launch your own portfolio at TruFi.io. Welcome Bankless Nation to a very special episode of AlphaLeak. Today I'm joined with John Light. And John Light currently works at the head of product for Sovereign, but also Moonlights as a Bitcoin researcher in his free time and recently got a grant from the Human Rights Foundation to do research on how, to do ZK roll-ups on Bitcoin. And this is what piqued my attention and why I wanted to do a show on this, because ZK. Roll-ups on Bitcoin. I didn't know that that was possible, but according to John's

research, it is possible. John, welcome to Bankless. Yeah, thanks so much for having me. And also, because I am not the always the best person to ask Bitcoin questions, we're bringing in some help. We're bringing in Eric Wall, who's going to be my technical co-host, my Bitcoiner, co-host to ask me and ask John some more, some better questions, more than just the higher level stuff. So Eric, thank you so much for helping me do the show today. Thanks for having me, David. Cheers. All right, John, let's get into it. Explain a little bit about yourself, give yourself our bio, and kind of how you came to be working on the intersection of ZK roll-ups and Bitcoin. Sure. So I'm a longtime bitcoiner. Bitcoin is my first love, you could say, in cryptocurrency.

world and I have had a fascination with a cross-chain Bitcoin protocols. Even before side chain, the term side chain was even developed, I've been interested in this idea of like, you know, could you move Bitcoin into other chains that have different sets of rules? And the side chain's white paper came out in 2014. I was really excited about that. years went by and the best kind of side chains we've gotten so far are like federated multi-sigs that hold people's Bitcoin and I've always been interested to know like can we do better than that can we have permissionless trustless side chains or at least bridges to to other blockchains and a couple of years ago

ago, I was working on a project in the Ethereum world called Aragon. And this is a Dow creation tool. And it was also around the time of like, well, first there was CryptoKitties, which kind of caused a lot of congestion on the blockchain. And we were already starting to think about scalability around that time. So like late 2017, early 2018. But throughout that bear market, gas fees started coming down and it became less of an issue. But it was always something in the back of our mind.

So research was ongoing about how can we improve the scalability of this system so that it doesn't cost like $100 to cast a vote or something like that. And eventually, you know, ideas like plasma and state channels. and eventually roll-ups were invented in the Ethereum community as ways to reduce congestion, move transactions off-chain, make transactions cheaper, more scalable, so on and so forth. And so that's how I first became familiar with roll-ups. And eventually, these two interests of mine kind of converged, where, you know, I realize, okay, roll-ups are basically like trustless bridges that you can use to transfer coins to other blockchains. This is like, you know, kind of the original sidechains vision of like having, you know, trustless bridges to other blockchains and you can move your coins between different blockchains.

And I thought, you know, wouldn't this be cool to bring to Bitcoin? John, I think the most interesting thing about this for me is that ZK roll-ups are a technology that just makes sense to me in the Ethereum ecosystem. It's the logical progression of like state channels to plasma to roll-ups has always felt a very like a natural progression of scale for a blockchain. And so then when we talk about using this, which is just an inherently neutral technology, ZK. Roll-ups are just a neutral technology. The fact that we can, allegedly, which is what we're going to unpack today, that we can apply a ZK roll-up to Bitcoin gets me excited.

It's one of the first things I saw a lot of potential out of the Bitcoin space in a long time. Like, lightning has never really interested me. Liquid has always been a joke. But ZK roll-ups seem like if we can apply them to Bitcoin, it can open up a brand new world. And that's really what has gotten me excited here. is it is and so really just to define these terms we have zK roll-ups on ethereum is it simply as is it as simple as just taking the technology that we've gotten and started to roll out in the ethereum world and just applying it to bitcoin and then also it just like quote works is it is it really

that simple depending on how validity roll-ups are actually enabled on bitcoin layer one the smart contracts that secure the bridge between layer one and the layer two validity roll-up could be practically identical to the smart contracts that are used for validity roll-ups on other chains, or they could be quite different because Bitcoin uses a different state model than Ethereum, for example. So Ethereum uses a state model that's known as the account model. Bitcoin uses a state model that's known as the UTXO model. And this has implications for how you program smart contracts to interact with user funds, including in this use case enabling users to transfer their funds into a layer two protocol,

such as a validity roll-up. So while the roll-up features will be or could be identical between, roll-ups that you could build on Ethereum, for example, or roll-ups that you would build on Bitcoin, the actual mechanics of how the funds are secured on layer one could be quite different. Eric, I know you've always been an optimist about the future of Bitcoin innovation. I know that ZK. Roll-ups has been one of those things. When you saw this paper, and also for the listeners who have a computer handy, the Bitcoin rollups.org is a useful website, which is kind of the punchline of this whole show.

Eric, when you saw this paper, when you read this paper and saw it out of John Light, what did you see? What got sparked in your imagination? Yeah. So just to give some context on how the research project came to be, the sort of origin story here is that it was actually Udi Verkheimer that had some argument on Twitter that led to CMS holdings making 100,000, grant to a charity of Udi's choice. It might have been actually, it might have been the, the, the podcast that you guys did with him, the B&B, uh, B&B is sound money. Hyper sound money or something.

Yeah. Uh-huh. Right. So, CMS sent $100,000 grant to the Human Rights Foundation. Human Rights Foundation partnered with StarCorp, and Alex Gladstein, who's the chief strategy officer at Human Rights Foundation, has been, like, he has his own, like, he's, he's very idealistic with Bitcoin. and he really wants Bitcoin to succeed.

And he's very, I would say, in many cases, he's very intellectually honest about what the complications for Bitcoin is. And then he uses the Human Rights Foundation sometimes to create grants and create research projects to solve the bottlenecks that he's seeing. So Alex Stadstein, he has been interested in trying to understand, like, can we use something like CK Rollsups as a lot? alternative technology or as a complementary technology to the Lightning Network on Bitcoin. And then he did a combined grant between StarCware and the Human Rights Foundation to research this, basically. And I was helping Alex find the right candidate to do the research projects. We had a bunch of different applications.

And I've known John Light, like from Twitter from before, and I know that he's very clued in about what the technology stacks already. it looks like so it's not going to be completely new pieces to him so we chose him because he was the best candidate and the the work that he's done we're very happy with the work that john has done so from our from our end the the research project i would say has been a success and it's incredibly interesting to listen to john speak about this because john was previous to having done this work he He was a bit skeptical to whether or not roll-ups were actually a fitting technology on Bitcoin. I myself have been skeptical whether or not because one of the things that a roll-up does,

it allows you to segregate state from the main chain to a secondary layer. So one of the scalability bottlenecks in Ethereum is that the main chain state is so bloated, but the roll-up is a new state. And in Bitcoin, we don't really have, we have a UTXO set, which is, the closest equivalent to a state, the way that we have it in Ethereum. But the state in Bitcoin isn't really, you know, it's not tens of gigabytes or hundreds of gigabytes large as it is in Ethereum. It's much smaller.

It's much leaner. So for this reason, it hasn't been really clear, like, do we actually need roll-ups on Bitcoin? Does it solve the, I mean, Ethereum is an extremely computationally heavy product, right? Bitcoin doesn't really function in the same way. We don't really have the same type of skill. bottlenecks. So therefore, it really has been a question like, does ZK. Rolls on Bitcoin actually solve the correct type of scalability bottlenecks? And sort of the interesting thing that has come out

of John's research is that it does address those specific bottlenecks. It is something that we can use to reach like orders of magnitude more scale in Bitcoin. So when I hear a rollup on Bitcoin, two things come to mind. One is a better lightning net. One is a better lightning net. network. My opinion on the net lightning network is that the U.X is too difficult for it to be really adopted as a mainstream technology. And so with a ZK roll-up on Bitcoin, we might be able to have the scalability that we need in order to scale Bitcoin payments to the world. So I want to go down that rabbit hole. The other rabbit hole I want to go down is expressivity. It's like, okay, what other potential is unlocked by a ZK roll-up? Does it make Bitcoin more expressive

than the layer one. And so I'll take those one at a time. John, is a very simple like ZK roll up on Bitcoin, just a better lightning network? Is that something that we've unlocked here? By the way, could I just jump in here really quick? Yeah, sorry, let Eric hop in. He probably can ask the question better.

Yeah, so, no, I just want to mention something that I thought it was pretty funny. So I had a bet with the editor of Bitcoin magazine about whether or not the merge would happen this year. And the bet was for a tungsten cube. And as we know, the merge happened this year. So he was going to send me $333 over the Lightning Network yesterday. And I downloaded a wallet called the Wall of Satoshi.

And I sent him an invoice. And I wasn't sure it's going to work because the problem that you usually have with Lightning is that you don't have enough inbound liquidity. So in Lightning, you need liquidity locked up to be able to receive a payment, which is one of the most fundamental limitations of the Lightning Network. work. And in this case, it actually worked. I didn't have to do any setup. I just received the payment of $333. I was like, holy shit, lightning actually works. And I was this close to making, like, because I feel like I have to be intellectually honest when good things are happening with lightning.

Like if something really works and it impresses me, it would be intellectually dishonest if I said, you know, I'm not going to publish it. I'm not going to tweet about that. So as I'm writing the tweet, I thought, you know, I'll just, I just have to go and look up that this is actually like a non-custodial wallet and that it is a custodial wallet that handles all the lightning channels. Turns out the walls of Satoshi is a custodial lightning wallet. So this was all like done in a centralized fashion. And I was like, okay, well, that's the reason that, you know, this works. It wasn't this discovery that the lightning network suddenly works. So I think, you know, this issue with lightning is really, in my perspective, this is the reason why roll-ups has been such a huge interest for me. It's because

these channel limitations that you have the lightning and john you've looked at this um like you in your in your uh roll-ups paper you've gone through like the sort of user experience bottlenecks or quirks with the lightning networks and how roll-ups are sort of different so it would be super interesting to hear like how you compare those two technologies yeah yeah i think it from from what i could tell people's experience using lightning varies some people have a great experience all the time. Some people have problems in it. It's very set up dependent, like dependent on the wallet, dependent on what nodes you have channels open to, dependent on how much liquidity you have. Like I have used Phoenix wallet and Breeze wallet and Blue Wallet all for

lightning. I believe Blue Wallet's implementation of Lightning is custodial, but Breeze Wallet and Phoenix are mostly non-custodial. And I haven't had any problems with any of those wallets. I think I've had two or three outbound payments that have ever failed. And it was because the person I was sending it to just didn't have enough liquidity. And so whereas roll-ups, they're blockchains. So if you have funds on the chain, you can send it to any other address on the chain. and as long as your transaction gets included in a block,

like the payment is going to complete. The trade-off that you get is throughput. So lightning throughput on the network itself is not constrained in any way. You and I can pass back and forth, you know, a Satoshi millions of times. It's not constrained by data. It's not constrained. Yeah, it's not constrained by the base layer, you know, block size limit. Yeah, good clarification.

It is constrained by bandwidth and liquidity, but it's not constrained by the base layer transaction throughput. And the transactions on lightning have what is referred to as like local state. so only the parties to the transaction actually even know that really the transaction is happening and that that's like where you get lightning's massive throughput and scalability gains from because you don't need to tell your transaction

to the entire world you just keep those transaction details between the parties to a transaction whereas roll-ups have what is called global state where everybody who's using the protocol call knows about all of the transactions because just like with the base layer blockchain, you're broadcasting these transactions to a global network. Some nodes out there that are performing the role of block producers are bundling those

transactions into a block. And then that block has to get confirmed on the layer one or base layer blockchain. And so the amount of transactions that fits in a rollout block has to fit within the the L1 data availability capacity, whether that's within the layer one block itself or in some like data blob that's attached to the block. And so that's like kind of the fundamental tradeoff. You like you get these nice user experience benefits where it just feels like using any other blockchain.

But you're fundamentally constrained in throughput by the. data availability capacity on your base layer blockchain. Okay. So is it fair to say if I, that we've seen rollups grow in adoption on the Ethereum side of things. We haven't seen the Lightning network really become adopted on the Bitcoin side of things. Is it fair to say that like with rollups on Bitcoin, we would have a payments network that is superior in its adopt?

potential than Lightning Network. Is that a fair thing to say? Well, I don't know that a fair comparison can really be made between roll-ups on Ethereum today and Lightning on Bitcoin. One, they're used for very different things. So, you know, the amount of money that, say, circulates in a financial system for trading different types of assets is almost certainly going to different than the amount of money that's circulating through, say, a peer-to-peer payments application or something like that. Another thing that you have to look at is not just the liquidity, but the actual, like, amount of users. And there are thousands of lightning nodes on the network, and some of those are custodial. So they have, like, customers who are utilizing those nodes

that it's hard to even say how many users they have unless they advertise it since they're hidden behind like a custodial interface. And so even the throughput on the network, because it's not a global state, we don't know how many transactions are happening across the Lightning Network. So it's hard to make a comparison. And even if you could compare them, like I said, I don't think it's quite comparing apples to apples. With that having been said, I think that because of the UX benefits that you get from having this global state model and like being able to receive offline payments, being able to receive payments without requiring inbound liquidity, and having channel limitations and things like that, I think, though,

features do overall improve the user experience and so light roll-ups could be an alternative for certain use cases and not others like if you need really high capacity high volume low-value transactions like micro payments or nanop payments then you know a state channel network such a as lightning might still be the better option. But for simple Venmo like peer-to-peer payments or maybe even like business-to-business payments, roll-ups might be better, like a better user experience. The constraints or requirements of that type of payment just might be better suited to a roll-up. So there's a problem that meant here that we don't really know the

answer to, like, is the reason that the Lightning network is not taking off as quickly as, you know, other layers on Ethereum, for example? Is it because the user experience of Lightning is bad, or is it because people don't want to make payments with Bitcoin? We don't really know the answer to those questions. Like, I can speak for myself as a Bitcoiner, that I would probably make more transactions if the Lightning network was more reliable. Then I would have a wallet with some funds in it. I would go. I would use it. Whereas with Lightning, it's always like, I pull up my wallet, it sort of has to sync, my channels are not always configured, and then that sort of leads me to go and put it into a custodial wallet, but I don't want to put a sizable amount of funds in a custodial wallet, because I'm sort of worried that it's going to disappear. So it's not clear exactly what the reason is that people are not using, I think, whether it's user experience related or if it's something else. My perception is that it's the property that it's the roll up on Bitcoin,

A Bitcoin roll-up, or rolls in general, are this persistent thing that has 100% uptime is a big unlock. Whereas, like, the Lightning Network is this more nebulous thing where parts of the Lightning Network go offline, then they come off online later, and the Lightning Network is just this loosely connected network of nodes when some of those nodes go offline. Versus a roll-up where the roll-up is one single blockchain with 100% uptime. I think that's the unlock that I think really gets me excited about the potential of a new layer on Bitcoin that sees a lot of demand. Yeah, John, some thoughts on that. Yeah. Well, to draw another comparison, I think today, roll-ups don't actually fit the full vision of what we imagine a roll-up to be, right?

or the full potential of a roll-up. Like today, they're secured by multi-sigs, not by layer one consensus. Today, they have single block producers, not multiple block producers. And so there have been outages on roll-ups where users can't access their funds for 24, 48 hours or longer. And so similar to the way that, you know, the lightning, network, it's immature, people are still building out tools for managing liquidity and figuring out the user experience at rough edges. I think some of those rough edges are going to be able to be smoothed out. Some of them might, you know, might never be able to be smoothed out. Similarly,

you know, with roll-ups, I think there is a potential there to get to an ideal state of trustlessness, security, uptime, and we might never reach that full ideal in the same way that even with base layer blockchains today, there are bugs and there are U.S. challenges, but like we can move incrementally closer to that ideal. And I think the ideal state of a roll-up, again, for certain use cases is arguably superior than lightning or other layer two protocols that we can build on Bitcoin today. So that's one of the things that makes me excited about roll-ups is that I think they can fulfill particular use cases.

They can fulfill a particular potential that just isn't possible today. Yeah. And one example of that that I think is super interesting is that I can say to you, David, like, by the way, I just sent you $40. on the ZK Sync roll-up or on the Arbitrum roll-up. And you're like, oh, and you're like, okay, so do I go and claim it with my E&S name, like David Hoffman.3? And then you have access to those funds.

And we didn't have to coordinate on which layer, like, we didn't need to do any setup process before that. I just sent you those funds, like an email. Like, I just know your email address. You now have those assets. So that's something that you can do in a roll-up. You could do that when I roll-up on Bitcoin also, like you just send. them funds without them even downloading a roll-up wallet. You can send them funds.

And that's something that you cannot do with the Lightning Network the way that it's currently, the way that it currently exists. Right, because as a user, as a Lightning user, I need to initialize my Lightning node and then also maintain that Lightning node in order to have like my email address being able to receive emails, which is just like not a UX that people are used to and perhaps just like is insurmountably difficult for global adoption. But this idea where you have this persistent address that exists at any layer that works universally and you don't have to maintain a node or initialize a node in the first place to be able to access this, I think that's just a U.S. that is more resonant with the internet-going

people of the modern age. I don't know if this is a problem that could be solved, but you do have to be careful about that because I remember there was a problem with some tokens on optimism that the optimism team was distributed to, I think, an investor or something like that. Wintermute. It was a trading firm. But there was actually a nuance there is that it was a NOSIS multi-sig and it was a very early version of the NOSIS multi-sig. So it was a bit of software on top of a layer and that particular software. Right. It was a contract address. So it didn't actually have anything to do with the fact that it was on a new layer. It was a specific multi-sig implementation that created

a new address that was different from the address on the layer one. So that was more of an application layer difference than a protocol layer difference. I thought it was something like the case was like they had the contract address on layer one. The optimism team sent the tokens to the address on layer two and somebody else deployed the contract to the optimism roll up and was able to basically create a wallet with the same address and therefore like they had they they were the owners of those tokens that is what that is what happened that but that's an application layer thing not a blockchain

layer thing it was the specific code of the actual multi-sig that created that property that was allowed to be exploited rather than the actual like layer itself does that make sense yeah yeah yeah I just, I bring it up to say, like, I don't know if it's, it's, you can 100% assume that a user is going to, you know, have the same address on all layers. So you want to be careful about that. But, um, assuming, like I said at the beginning, like I don't know if that problem can be solved. Um, but if, you know, maybe when it can and you can reliably assume that, then, then you get to kind of this nirvana state where you can just like, you know somebody's address. you can send them money anywhere and just tell them like, hey, your money's over here, go get it. I think that would be a really great place to end up.

Certainly. Okay, so I think we've unpacked the differences between the payment properties of a Bitcoin roll-up versus lightning. I want to get into expressivity. And so when we get into a new layer on top of Bitcoin, that's a ZK roll-up, what other things can we do on a layer on top of Bitcoin that's a ZK roll-up that we can't actually do on the Bitcoin layer one. Like what kind of new features are unlocked for us? So are we getting like the full scope of like tokens and smart contracts and ENS names or is it something more more simple? Like what are we what is what are the new things that are unlocked here?

Um, potentially yeah, any, anything that you could do with a blockchain, um, you can Full, Turing complete expressivity. Yeah. Yeah. I mean you you, you need to have a very, a very verifier on layer one that is capable of verifying the proofs of that computation. And I discussed in the report that I wrote up about how if Bitcoin developers did not want to enable that level of expressivity for some reason, they could restrict the complexity or or power of the computations that are able to be verified on layer one, basically intentionally handicapping the verifier on layer one. But if you weren't to do that, then, yeah,

theoretically you could have any kind of blockchain converted to a roll-up. and layer one doesn't need to know how to execute those transactions, it just needs to know how to verify the proofs. And as long as it can verify the proofs, the state can be updated and users can safely make withdrawals and the roll-up just works. So this is one of the mind-blowing facts about roll-ups on Bitcoins that they actually enable fully turn complete virtual machine. So this was, I was interested in roll-up since 2019,

and it wasn't like a couple of years after that I realized actually wait, a stark proof can encode an entire virtual machine. It does that on Ethereum. And then, of course, you can also do the exact same thing on Bitcoin. So the way that you can think about the validity proofs that you implement on the main net is that they're almost like adapters, like they're almost like, power adapters that can change the entire virtual machine of the system that it's validating. So it opens up basically like limitless potential, any new type of virtual machine,

which is why the limitation, the comparison between the Lightning Network and a roll-up is sort of limp because it doesn't really even address this whole new paradigm of applications that the roll-up potentially unlocks. It would be interesting to think a little bit about, okay, so we've talked about the transaction throughput benefits when we're only talking about account-to-account transfers in a roll-up. If we're talking about like turn-complete smart contracts, would it even be feasible to run like one, like a uniswap or like could we even run one like smart contract application as a day exist on Ethereum without like breaking the scalability boundaries of Bitcoin? That I don't

know because we've only really looked at like account-to-account-strander. where the on-chain footprint is kind of is like small like 12 bytes for transaction. I would say so. I mean, if you look at if you look at the size of like even just a raw uncompressed un-swap transaction on-chain, it's, you know, not even kilobytes. Like it, you know, it's a very small amount of data to actually update the the state of the uniswap contract. So I think you could, the same way that we're able to confirm not just a single transaction, but batches of EVM compatible transactions within Ethereum blocks, which even accounting for call data are much smaller than Bitcoin blocks. Yeah, I think it shouldn't be a problem on Bitcoin.

So maybe it's fair to say that. So the hardest thing maybe to achieve here, Because when I read your research, you also looked at enabling Zcash style fully private transactions through a roll-up. And then the scalability of the system actually decreases. So you can't make as many Zcash-style transactions using a ZK roll-up on Bitcoin as the mainnet Bitcoin layer can do regular transaction itself. So if you go into like the ZK, the Zcash style paradigm through a rollup, then, so if Bitcoin does like four transactions per transaction, four transactions per second right now, it'll only be able to do like three transactions per second if it tried to do ZK, Zcash style transactions using a rollout, right? Yeah, yeah, shielded transactions because you have to in like the transactions end to end encrypted, it like, this is. blows up the size of the transaction. Even with, you know, the most efficient proofs that we have today, it, it ends up being

bite for byte about 20% bigger, 20, 25% bigger than a normal one input, two output, Bitcoin layer one transaction. I think, you know, that's not a huge hit, and you're getting a much better privacy profile. Like if you tried to have a similarly private Bitcoin transaction, like you just couldn't even do it. Like you could have fit enough inputs and outputs to match the anonymity set of like a shielded transaction.

So they're not completely comparable, but yeah, I think it's worth the additional 20, 25% size to get that strong level of privacy. But it's up to each user to decide, really. You could potentially also maybe run an application like Tornado Cash. Maybe that's not the one application that you'll see developer rushing into developing right now, but you could potentially run an application like that. also if you just want to get like a mixer that runs on Bitcoin. Because, I mean, we have coin joints on Bitcoin, but the privacy is not perfect.

The scalability is not very high. Maybe something like turnover cash through a ZK ruleup. Maybe that could be a use case for people that want to get better privacy. Or do you think that maybe Zcash style transactions are the better use case here? I think I think mixers have a lot of. footguns involved because there are a lot of like rules that you have to follow to use a mixer safely so you don't de-anonymize yourself and as a consequence damage the anonymity of everybody else using the mixer um so you know i would i would advocate you know if people want privacy

the direction that we need to move in is is getting people to store their money in shielded pools and to make shielded transactions. Simply depositing your money into a shielded pool and then taking it out a couple of days later, I don't, you know, I don't think that really solves the problem because then you have to... Staying inside a shield pool,

making all the transactions there is sort of more elegant solution to the privacy problem than going in and out of mixers all the time, right? Yeah, like you're less susceptible to timing attacks, your less your like questions about post-mix privacy are easier to reason about

and of course you know Z to Z, you know, fully shielded transactions are kind of the gold standard so I would hope that most peer-to-peer payments that don't need to have any kind of public component

move in that direction. The reality today is that five corporations control the entire world of social media. They own our names, they restrict our content, they monitor our every move. And their time is up. Thanks to our sponsor, DESO. DOSO is a layer one blockchain built from the ground up to decentralize and scale social networks. With DOSO, you can own your own identity, content, and social graph, and take it with you across hundreds of applications already built on the censorship resistant DESO blockchain. DESO's storage advantages make it finally possible to build

infinite state applications that can efficiently store and index large amounts of content and data fully on-chain. DeSo also offers multiple crypto-native monetization primitives for developers and creators, including social NFTs, social dows, social tokens, and social tipping. So in order to experience the social layer of Web3, go to DeSo.com and claim your username. That's d-e-s-o.com. The Brave Wallet is your secure, multi-chain on-ramp into Web3, and is built directly into the Brave Privacy Browse Browse.

Gone are the days of managing multiple wallet extensions that put you at at risk of fishing, spoofs, and tracker. With the Brave wallet, you can securely manage your crypto assets across more than 100 different chains, including Ethereum, layer twos, salana, and more, all without downloading risky extensions. The Brave wallet is easy to set up and removes the headache of jumping between wallets

and extensions. It's lightweight, but packed with great features, like built-in token swaps, buying and holding NFTs with a gallery view, and support for hardware wallets. But also much more than that, because Brave is shipping new features every single month, with a mission to make Web3 easier to navigate,

for its over 55 million users. Wall extensions are a thing of the past. So get started with Brave's Web3 Ready browser today and experience a decentralized web seamlessly without all the clutter. You can download the browser at brave.com slash bankless and click the wallet icon to get started. Arbitrum 1 is pioneering the world

of secure Ethereum scalability and is continuing to accelerate the Web 3 landscape. Hundreds of projects have already deployed on Arbitrum 1 producing flourishing defy and NFT ecosystems. With a recent addition of Arbitrum Nova, gaming and social daps like Reddit are also now calling Arbitrum home. Both Arbitrum 1 and Nova leverage the security and decentralization of Ethereum

and provide a builder experience that's intuitive, familiar, and fully EVM compatible. On Arbitrum, both builders and users will experience faster transaction speeds with significantly lower gas fees. With Arbitrum's recent migration to Arbitram Nitro, it's also now 10 times faster than before. Visit Arbitrum.io, where you can join the community, dive into the developer docs, bridge your assets and start building your first app. With Arbitrum, experience Web3 development the way it was meant to be. Secure, fast, cheap, and friction-free. So just to make sure that I'm tracking this conversation,

what we're talking about is there's various applications that we can do on a ZK roll-up, perhaps limitless, and it's really a function of the constraints of the Bitcoin Layer 1 block space. And so now we're talking about, all right, like, what applications are like high-priority, what applications on a ZK roll-up on Bitcoin? do we want to emphasize first? And I totally understand that private payments probably resonates with Bitcoin culture more than tokens.

And so maybe that's kind of where we start and kind of open up the design space for stuff that kind of resonates with Bitcoin culture. But in theory, so long as there's block space on the Bitcoin layer one, there is potential on a Bitcoin ZK roll-up on its own layer two. and that potential is really just only constrained by the imaginations of the developers that can build on it. This is my takeaway. Is that correct? Yeah. But it should be said, though, that Bitcoiners have recently, there are recently waking up to this idea that in order to win the payments use case for any blockchain system, it's a good idea to start out with stable coins. So if you can build a stable coin payments rails that becomes universally adopted, that'll be much easier to later introduce your own native token into that.

So if the Lightning Network, for example, becomes the leading solution to transfer stable coins around, then Bitcoin gets an edge relative to Ethereum. And if Roll-ups become the leading solution and they're based on Ethereum to transfer stable coins, it'll be easier to sort of sneak Ether into that mix and transfer those tokens. So, but I do think that transferring stable coins on the Lightning network is not that easy. They have a solution currently which involves swapping the stable coin in and out of Bitcoin multiple times just to complete the payment, which means that they're going to incur like multiple spreads on those payments. So they won't necessarily be very cheap. And the UX, as we know, isn't perfect with Lightning either. So something like a ZK roll up on Bitcoin where you make stablecoin payments will,

potentially be advantageous, even to the path to adoption that the Bitcoiners have already sort of understood is optimal. So the roll-ups could fill a use case there where you're using them to transfer tokens also, and I don't think that Bitcoiners necessarily would be against that idea. One of the things that we didn't mention that I think is interesting is like this idea of building layer three protocols on top of a layer two roll-up in order to compensate for any shortcomings that would be on the roll-up, such as, you know, transaction capacity due to layer one throughput limitations. So, like, you could have layer three protocols like validityms or

volitions or things like that, where you actually have off-chain data availability. you reduce the security model a little bit, it still ends up being a stronger security model than like your typical federated side chain and you're not constrained by the base layer throughput capacity. So if you wanted to say on board an entire country, like El Salvador to Bitcoin, you might say, well, we don't want just everybody to have custodial accounts because that's not the Bitcoin way.

But they're not all going to fit on layer one or maybe even layer two. Can we do something that's like in the middle? And I think a validityam built on top of a roll-up could be that sweet spot where it's still non-custodial. There's a strong guarantee that users can get their funds out with beta. if the data is available. And at the same time, you have basically unlimited throughput. I mean, just as much throughput as the sequencer or block producers are willing to allow for to produce their blocks. But yeah, that's, I think, an interesting way, as we were talking about those limitations of throughput on

the base layer, that's like an interesting way that you can use ZK rollups or validity rollups to enable these new protocols that aren't possible on Bitcoin today that offer interesting security and scalability tradeoffs. Yeah, and you mentioned in your paper, you mentioned the ability to build lightning network on top of a ZK roll-up. So in order to improve the scalability of the Lightning Network, you could run it on a ZK roll-up on Bitcoin. So that could be like a layer three.

But it's true that you point out that, I mean, the Lightning Network, the way that the Lightning Network is constructed, it's designed the way that it's designed because of the limitations of the Bitcoin base layer in the scripting language of Bitcoin. But if you have a ZK roll-up, you could build a little bit different, like a little bit different scripting language and build a little bit different lightning network that solve some. So for example, if you want L2 or other things that people are waiting for in lightning, you could sort of enable those things with a ZK roll-up module and then you could build more interesting or more user-friendly

or more secure perhaps even lightning networks on top of that roll-up. So that's a, do you agree with that assessment? Yeah, yeah, I think enabling developers to try more things more quickly without having to wait for base layer consensus changes. I think will help advance the state of L2 or like off-chain protocol development. And yeah, that's an exciting possibility. We sort of have to sort of get into what exactly needs to be done on the Bitcoin base layer to even enable this. I think this is a should we get? into that discussion maybe. Yeah, that's exactly where I was going to go next, because I've had this

discussion with other people who are familiar with building on the Bitcoin blockchain. It's like, all right, like, how do we get Bitcoin trustlessly over to Ethereum? How do we build, like, bridges that are trustless? And every time I like ask developer-minded friends, like, how do we do this thing on Bitcoin? They're like, well, we're going to need to change the op codes. And as as soon as I hear that line change the op codes, my mind just goes like, well, that's not going to happen because that means a hard fork. And that Bitcoin just doesn't hard for. fork, like, that's the vibe. That's the social contract. And so, John, what does it take to actually get a ZK roll-up into Bitcoin? Like, what changes do we need? How do we actually arrive at this,

at this future state that we all want for Bitcoin? So there will need to be new op-codes, but the good news is that it doesn't take a hard fork. Okay. So the way that op-codes have been added or disabled in Bitcoin over the years, pretty much since the Satoshi days is using a style of fork called a soft fork, which is considered backwards compatible. Okay. So old nodes don't need to update their software in order to remain on the network and in consensus and able to send and receive coins with other nodes that have upgraded and adopted the new op codes.

So this is how, for example, P2SH, which we use for multi-sig, uh, in favor. Bitcoin was adopted. This is how Segwit was adopted and most recently taproot. Okay, so Bitcoin does soft forks. It's very successful, has successfully implemented soft fork upgrades in its history. So it's reasonable to assume that we can do this again if the Bitcoin community wants ZK roll-ups. Yeah. Yeah, for sure.

Well, I mean, this still introduces, if, If we think about the risks that a ZK roll-up introduces on Bitcoin, I think a lot of people are afraid if you introduce a turning complete virtual machine module through a ZK roll-up on Bitcoin, then you can have very complex smart contract languages run basically on top of Bitcoin. And if there's an exploit above, like, let's say, like a Dow hack in that second layer, then it sort of becomes the base layer's problem. So now if you have to sort of save all the users in the second layer because there was a bug there,

then maybe you need to do that through a soft fork on the base layer. So the problems that can happen in these external layers can sort of trickle down to the base layer itself. And also issues like MEV, for example, if you have a role of generating lots and lots of MAV, and then the miners that get to include the proofs of the role, up on the mainnet. Maybe there's like getting to include those proofs pay way more than any other transactions do. So then miners are all of a sudden incentivized to sort of reorganize the blockchain to be the ones that get to include these proofs instead of just like mining the blockchain as usual. So the same similar this the same critiques or similar critiques that have been

levied against drive chains are theoretically, in my opinion, could be levied also against ZK roll-ups, but the advantage that ZK. Roll-ups sort of has here is that it's different. It doesn't have the same political baggage that drive-chains do. All the conflicts between the core developers and Paul Storch, who was the pioneer of drive-chains, is not relevant anymore, and ZK. Roll-ups also, they have stronger security guarantees, right? So it might be worthwhile actually doing this for ZK. roll-ups while for drive chains, it wasn't really worthwhile because you still, it was just a

merge mine side chain, basically. So I wouldn't, I think that there's still a conflict that would need, it's not just a matter of a technical improvement that when we have time, we will get it into Bitcoin. It's a whole ideological question of whether or not this upgrade makes sense to Bitcoiners. And I think, like, from my perspective, what really would need to happen for people in the Bitcoin ecosystem to seriously evaluate this is if Ethereum started to flip in Bitcoin, then it would be like, okay, you know, maybe we need to try something new. But unless that happens and Bitcoin just keeps this very dominant role, I think people will more think of ZK. Rob's as something for the future, maybe. I don't know. Those are my thoughts. I'm less convinced that Ethereum hypothetically flippinging Bitcoin would cause that deep of soul searching to say change the calculus of whether or not it would be worth implementing EVM or Turing complete Zika roll-ups on Bitcoin. I think there's a view.

in the Bitcoin community that Ethereum is like a tech platform. And so Ethereum flippinging Bitcoin would be no more noteworthy than a tech startup, you know, stock market cap post IPO flippinging Bitcoin or something like that. At least I'm sure people would try to explain it away in that way. And that might not even be that investment. valid of a viewpoint. But I think that part of the debate, it involves even more nuance. It's like we could enable ZK roll-ups on Bitcoin without enabling fully turning complete

EVM-compatible or other kinds of fully expressive ZK roll-ups. We could say, we're going to enable the verifier to verify. transactions that are no more complex than Bitcoin is today. Like you can't do, it just can't, it isn't capable of verifying computation heavier than that. And so you would be, you would be limited in the types of scripts that you could build on the layer two roll up. And, you know, Bitcoiners might say like, you know, we can start there and maybe in, you know a few years down the line after we've done more research on say cross-layer

MEV or these other like more subtle economic game theoretical concerns you know we'll we'll make a decision about whether we want to enable these more expressive roll-ups so I do think that we could see validity roll-up on Bitcoin before we even have answers to like those those questions about the more expressive roll-ups. So the perspective that I'm seeing here is that like in the Ethereum land, anyone can build a roll-up and deploy it at any time. There's no like changes to the base layer.

Like we can have a bigillion different roll-ups of a different, a billion different, a billion different varieties. What I'm seeing here, John, is that like that's not true in the Bitcoin land. the Bitcoin social contract needs to come to consensus about what flavor of roll-up they want to enable. And that kind of makes that future roll-up more enshrined than Ethereum roll-ups, where Ethereum roll-ups are all kind of commercial. They're all built as like a second layer to Ethereum, and they don't really impact the base layer because they don't have requirements upon the base layer. A Bitcoin ZK roll-up would require things of the Bitcoin layer one. And if

the Bitcoin layer one changed itself via a soft fork to enable a specific kind of roll-up that kind of enshrines that roll-up as like a more of a first-class citizen to Bitcoin than Ethereum does to its own roll-ups. Eric, did that make sense? And do you agree with that? I agree with that. And also one of the things that I think that you almost touched on is that in the Bitcoin world, we don't have the ability to plug in any type of roll-up into the Bitcoin system.

we have to decide on a specific proof system and then enable that specific proof system. And this is one of the big complications of it. Like how do we even decide which proof system we want to enable? Like there's plongs, there's redshift, there's growth, there's all these different types of cryptographic mechanisms. I mean, we know in Bitcoin that we sort of prefer cryptographic systems with the least amount of new assurance, least amount of assumptions. So we want something that is maybe stark based. you can go into this also, John. So we want something that creates the least amount of risk

by using something that is as tested as possible, and we don't want any trusted setups. But we still have to choose a specific proof system, and then we have to stick to that. And then if there's a new one that comes along, then that would involve a new soft fork. So this makes the way to enable roll-ups on Bitcoin, like we have to be way more thoughtful,

and we can't just be willy-nilly about it. Go ahead, John. Yeah, I mean, there might be ways in which you could, say, enable proofs such that, like, the miners verify them, but the rest of the full node network doesn't have to, so it's still kind of like a soft fork, but the rest of the network doesn't have to. so it's still kind of like a soft fork, but the rest of the network doesn't have to verify it, and it becomes almost like an SPV security model. But yeah, if you want the full network to verify it,

for each new proving system you enable, you might need to, if you don't kind of have like a very generic system from the start, you're yeah you're going to have to do a sequence of of soft forks um and if we get to the point where like bitcoin ossifies and like can never fork again because coordination is just too difficult then we're stuck with what we've got and you know good enough will have to be good enough i think at that point we might see uh the innovation is shift to higher layers um but uh Yeah, it's, there is some path dependency there that the community is going to have to think about,

you know, really think far down the line, like how much can we future proof this without enabling things that we might consider dangerous. And so, yeah, there are a bunch of decisions to make here. and it's an open question as to how the community would actually make those decisions. How the community actually enables soft forks in general is kind of an ongoing conversation in the Bitcoin community. Because with Taproot, we had speedy trial. With Segwit, we had, you know, the lock-in plus like the UASF. like there you know bitcoin has has tried all of these different things and there's not really consensus on on what is the best way to to go about soft forks yet let alone soft forks with so

many different options that that have to be considered along with them and i noticed that we didn't fully really respond to what needs to there's more things than just enabling a proof system on in on bitcoin that you need to enable for ezekiel rule up to exist. So there's two parts to it that people usually talk about. The first one is being able to validate a validity proof, a ZK proof, and the second one is the covenant, right? And you talk in your paper about recursive covenants. Maybe we should also mention, like, talk about what's this other part that needs to be enabled? Why does it need to be enabled and what exactly is it? Yeah. So we talked about the proof systems. And yeah, the other,

major pieces enabling recursive covenants. And a covenant for those who aren't familiar is a type of smart contract that restricts the outputs of your transaction. So for example, you could have, you could lock your coins in a covenant that says you can only spend those coins to a specific address. And then when you go to spend those coins, you can only spend them to the address that's defined in the covenant. And a recursive covenant is where you are able to apply restriction to the outputs of your outputs, of your outputs, like almost or actually potentially indefinitely restrict how

a coin could be spent and we use recursive covenants for validity roll-ups basically to enforce that when the state of the roll-up is

updated that all of the coins that are currently held in the roll-up remain in the roll-up script as those coins are being basically spent in the roll-up state transition transaction, they're rolling over into the same script, always, unless there's a valid withdrawal transaction coming out of the roll-up, in which case the covenant is restricting the script such that users can only spend to a valid withdrawal.

address that has been validated using the validity proof. So like if a user deposit some funds into the rollup, it's going into a script on layer one. Then the block producer on the roll up produces a rollup block. So updates the state of the roll up. They basically spend all of the coins that are in the roll up script to an identical copy of the roll up script. So they're like moving the coins from the roll-up script at state A into the roll-up script at state

B. And they're including a validity proof that says, you know, this state transition is valid. And then a user comes along and they say, I want to make a withdrawal from the roll-up. So then the roll-up block producer, again, is going to produce another block. They're going to roll over the coins from the script at state B to state C. and then they're also going to specify, well, some of the coins are going to come out of the script and be sent to this destination address. And the script is going to consider that valid because there's a validity proof which proves to the layer one full notes. You know, everything about this transaction, including this withdrawal, is valid according to the rules of the roll-up.

So the recursive covenant is basically needed just because of how the mechanics of like a Bitcoin transaction works with the UTXO model. So it's not like the most sexy part of a role of the covenant part, but it's sort of a required element because an easier way to sort of explain it would be like in Bitcoin you can't have a variable that you update. So you don't really have a persistent state that you can update. Let's say you want X to be four. then some transactions happen.

Now you want X to be six and you sort of want to store that variable. You can't really do that in Bitcoin because there's no way to store a variable. There's no way to store a state on Bitcoin. But the covenant would sort of allow that. And it also is worthwhile pointing out that the covenant that has been discussed in Bitcoin, the OPCTV, the check time, what's it called? Check time verify. Check template.

Check template where verify. Yeah, this one isn't sufficiently general to enable something like ZK. Roll-ups on Bitcoin because it's sort of a very specific type of covenant. So that thing doesn't allow us to get to the roll-up vision. Yeah, yeah. You need the fully recursive covenants because you need to be able to restrict essentially forever. Like as long as the roll-up is an operation, you need to go. be able to enforce this rolling over of the UTXO from the script from one state to the next.

And the only way to do that is with recursive covenants, unless you change, you know, you were to change like the state model of Bitcoin completely to like an account model. But like I said, that would probably be too radical of a change. I don't know if that would fare it very well politically. We both need to decide on which covenant do we want and which proof system do we want before we can enable Ziki relaps on Bitcoin. And both those things are sort of complex questions for implementation-wise for Bitcoin, for the Bitcoin system and community to sort of decide on.

Yeah, there have been a number of different proposals for how to get, even like recursive covenants specifically into Bitcoin. Some developers have talked about like OpTX. Some have talked about or simplicity, like just enabling the simplicity language. There was a suggestion for Chiolisp. So, yeah, there's a lot of ideas floating around, but no consensus yet of how to enable these kinds of generalized or recursive covenants. Well, amazing, guys. I feel very, very educated to the way the Bitcoin works a little bit better in how ZK. Rolts might actually get there. John, are there like clear next steps? Like, what are the next steps for getting this done if the Bitcoin community agrees that this is the next step? Well, I think it's going to take experimentation with those different options to see what makes sense.

maybe some more research to find out what is the minimal set of changes that would be required if we wanted to enable only validity roll-ups. I think there tends to be a preference in the Bitcoin developer community that if we're going to make a soft fork, it should be usable for multiple different kinds of use cases and not just a single use case. So you might be able to argue like validity roll-ups enable a bunch of different. different use cases. So even if we were to soft fork only for validity rollups, we unlock all of these other use cases. And so that kind of specialized soft fork might be justifiable.

You might also say, well, if your validity roll-up can only do Bitcoin-style transactions anyways, then, you know, it would be nice if the op codes that we enabled for validity roll-ups were also useful for other use cases. and so then we might have a bit of a conversation about the tradeoffs there. But yeah, I think more research, more experimentation. There are already some developers that are like working towards an MVP, just getting like a basic Bitcoin style validity rollup, working on a test network somewhere.

And so I'm sure they'll be thinking through these questions. But yeah, I would encourage. like there have to be multiple work streams, multiple different experiments going on. And we can all compare notes and see what works, see what doesn't, where are the tradeoffs, and eventually hopefully come to consensus on something so we can bring this to Bitcoin and allow users to experience the benefits. I have to ask one last question here. So in your paper, you talk about how roll-ups enable potentially 50 times more transactional throughput

with similar security guarantees that Bitcoin has on its base layer. So this is, I mean, this is a pretty staggering result, right? But why do you think that this research is coming from like the Human Rights Foundation and we found like a non-core Bitcoin developer to do this research. And why isn't this type of very interesting research coming from within the Bitcoin core, like the regular, the traditional Bitcoin developer ecosystem itself? Like why did it have to come from this like satellite route like of Ethereum interested people in order to explore this area?

I don't know if I could answer that question. I mean, everybody's got their own projects going on. there have been a number of different research papers that have come out pertaining Bitcoin specifically through non you know not directly from from Bitcoin core contributors for example like BitMix sponsors a bunch of interesting research there's a bunch of interesting research that has historically come out of like academia so yeah I think just people you know certain people get interested in in certain things and and and and the research bubbles up from from those domains.

So yeah, it's it would be hard to answer that question any other way because like I said, I think everybody's interested in in different aspects of the Bitcoin system and just because of my own unique, you know, personal and professional history, I happen to have a background in in both EVM and roll-up research as well as Bitcoin cross-chain protocols. And it just made sense for me to combine those areas of research and see what was possible with Bitcoin. And Eric, I think this story of roll-ups on Bitcoin is like personal for you. Because I consider you like a frustrated bitcoiner or you're a bitcoiner who wants Bitcoin to do more.

Just like, can you put me in the shoes of Eric Wall, like when you see, ZK roll-ups on Bitcoin, like, does it make you optimistic for Bitcoin? Like, what's it like to be you in the middle of this discussion? Yeah, I mean, this is the role of discussion that I tried to bring to Bitcoin back in 2019 was one of the things that led to, like, my departure from the Bitcoin community, because I had built up this reputation within the Bitcoin ecosystem for a very long time as the old coin slayer, like someone that was extremely, critical to technologies built on altcoins. So I thought that when I discovered roll-ups and I

looked at them and I thought, holy shit, this architecture, like this way of architecting a scalability solution on top of a base layer is actually generally interesting. So now that I've built up over these years, now that I've built up this social capital, can I just get my Bitcoin peers to look at this technology and think, oh, like maybe we should explore that way of architecting layer two and discuss how to implement that on Bitcoin. But the whole conversation got completely derailed when people discovered, like, Eric, are you proposing that we even accept that research is happening on the Ethereum side is actually valid?

Like, aren't you, don't you know that everything that comes out of Ethereum is a scam? I'm like, it doesn't matter what it comes from. It doesn't matter, like, who made it? Just look at how it's constructed, and then we can have a technical conversation around that. But I completely failed to make that conversation happen in 2019. And that was like when I started to entertain the idea that the intellectual center was sort of leaving Bitcoin and moving into other, like the Ethereum ecosystem more. And that's why I've been spending so much time in the Ethereum ecosystem is because that's where I can have like stimulating conversations around this. But I am happy, though, that now at long last, we are starting to see interest in the Bitcoin ecosystem.

These ideas are starting to become accepted, and we can discuss them again in Bitcoin. So I'm happy about that, but it's been like three years out in the cold, like being called an idiot than a shitpointer. When in reality, you know, like we've done the research now for Zika roll-ups, there is validity to those ideas. And we can probably for the first time entertain that you don't have to be an evil person just to say, maybe we should do this on Bitcoin. Well, I have even less social capital in the Bitcoin space than you, probably far less. Yet, ZK roll-ups on Bitcoin, what we're seeing out of Johns here is research on, and again, Bitcoinrollups.org to learn more, is probably the most interesting and exciting thing

I've seen out of Bitcoin since I've been in crypto. And so I'm hoping this conversation continues. and I definitely want to be a part of a part of that story as well because Bitcoin can be more expressive and deserves to be expressed more. And I see ZK. Roll-ups as the first legitimate path to getting that done. So, John, thank you for all of your research and also coming on the show and talking to me and Eric about it here. Yeah, definitely. Thank you so much for your interests. And Eric, thank you for helping me navigate an area that a muscle that I don't flex very often.

so I needed some help on that one. So thank you so much for your help. Thanks for having me. All right, cheers, guys. Bankless Nation, risks and disclaimers. Of course, Eath is risky, crypto is risky, DFI is risky, ZK roll-ups on Bitcoin, are perhaps the new frontier.

You could lose what you put in. We are headed west. This is the frontier. It's not for everyone, but we are glad you are with us on the bankless journey. Thanks a lot. Hey, we hope you enjoyed the video. If you did, head over to Bankless HQ right now

to develop your crypto investing skills and learn how to free yourself from banks and gain your financial independence. We recommend joining our daily newsletter, podcast, and community as a bankless premium subscriber to get the most out of your bankless experience. You'll get access to our market analysis, our alpha leaks, and exclusive content,

and even the bankless token for airdrops, raffles, and unlocks. If you're interested in crypto, the bankless community is where you want to be. Click the link in the description to become a bankless premium subscriber today. Also, don't forget to subscribe to the channel. for in-depth interviews with industry leaders, Ask Me Anythings, and weekly roll-ups, where we summarize the Week in Crypto

and other fantastic content. Thanks everyone for watching and being on the journey as we build out the Bankless Nation.