On The Brink with Castle Island - Steven Goldfeder (Offchain Labs) on Building Arbitrum (EP.351)

Episode Date: September 19, 2022

Steven Goldfeder is Co-Founder and Chief Executive Officer at Offchain Labs, the team building Arbitrum. In this episode we discuss:  Steven's academic background, and his work at Princeton University.  BlockSci, an early blockchain forensics/search product that Steven co-founded.  The evolution of MPC custody and the exciting developments in that category.  The Flash Boys 2.0 paper and the current state of MEV.  Steven's views on the evolution of L1 smart contract platforms and how L2 scaling is shaping up.  The design choices and considerations that went into the choice of optimistic vs. zero-knowledge rollups on Arbitrum.  The future of ZK systems on blockchains.    To learn more about Arbitrum and follow Steven visit www.offchainlabs.com

Today on the podcast, I sat down with Stephen Goldfetter, the founder and CEO of Offchain Labs, the company behind the Arbitrum Protocol. Stephen is a former academic who's been involved in some groundbreaking research that underpins some of the most important categories in the blockchain industry. That includes threshold signatures, multi-party computation, MEV, blockchain search, and more. This conversation was incredibly insightful, and I think you'll enjoy it. So without further ado, here's my conversation with Stephen Goldfetter. Matt Walsh and Nick Carter are partners at Castle Island Ventures. All of these expressed by them or the guests on this podcast are solely their opinions

and do not reflect the opinions of Castle Island Ventures. You should not treat any opinion expressed by anyone on this podcast as a specific inducement to make a particular investment or follow a particular strategy, but only as an expression of their personal opinion. This podcast is for informational purposes only. Brought down by bad mortgage investments, Lehman, which has 25,000 employees, will be liquidated. The federal government loans American International Group, AIG, $85 billion.

This is a different kind of market, and the Fed is asleep. The federal government is stepping it to stabilize Fannie Mae and Freddie Mac, the two mortgage giants that have been threatened by the housing crisis. The Bank of England has pumped 75 billion pounds more to Britain's ailing economy with a new round of quantitative easing. You print a couple trillion dollars, and all of a sudden, people start to worry. So out of this worry, we have something called the Bitcoin. Bitcoin.

So Stephen, thank you for joining the podcast today. Really excited to have you on. Absolutely great to be here. Thank you for having me. Before we started recording, we were talking about some of the projects that you've been involved in in the past. And it's just you've had a prolific history in this industry. How did you get started? How did crypto even get on your radar? I started my PhD at Princeton in about 2013. And even coming in, I was very interested in

in cryptography. And I had done a bunch of undergrad work, internships in crypto with some really, really well-known and great cryptographers. You know to Lindel did an internship with him. That was my first foray into crypto. And it's interesting because early on, the early people in crypto as cryptocurrency. And by the way, once upon a time, I would fight that battle. Crypto means cryptography, but I moved past that. The early people came from a few different areas. There was game theory.

There was cryptography. There was more traditional economics, finance backgrounds. And it was really like a new field that pulled from a lot of different directions. And I was particularly interested in cryptography and some of the cryptographic problems involved, particularly early on around key storage and storing key securely. in crypto. So I joined Princeton as a PhD student in 2013. My advisor at the time was Arvin the Ryanon and he was getting into this thing, into crypto. Back then it was Bitcoin. So really learning about Bitcoin and I went along with him for the ride together with him and Ed Felton,

my current co-founder and a few others. We actually authored a textbook, which was the first and maybe still only computer science textbook on crypto currencies. And basically I had the really the luxury at Princeton to explore various really interesting areas in the space. There must have been something in the water there because the amount of talent that has come out of Princeton in the cryptocurrency space is just unbelievable. Absolutely. It was really early on. It's funny.

So today, of course, I'm working on Arbitrum. And if you look on YouTube for the earliest video in Arbitrum, a few years ago I say, if you look at YouTube for Arbitram, you don't find one video. But now I have to say, you like filter by date and look for the earliest video. you'll find a fall 2014 semester video describing Arbitrim. Actually, this is before I was involved in the project. Ed Felton, my co-founder, Arbiton, was really his brainchild. And there was a computer science seminar on Bitcoin and cryptocurrencies, which was

itself unusual in fall 2014. And this was one of the projects that Ed led with some undergrad. And the funny thing about that video is it's about scaling smart contracts. And the video was published in January 2015. Ethereum went live six months later in July. So Ed was really thinking about scaling smart contracts before there was any smart contract platform at all. So definitely a lot of really, really early thinkers there. I remember those days I was at Fidelity and we were talking about things like the open assets protocol. We were talking about colored coins on top of Bitcoin. Did you guys have

a view on how this was going to evolve and a view on where you'd be building at some point in the future back then? So we came from it purely from the academic side of things, and we were really looking to just plug holes. Here was the view. This is really, really exciting technology, and we have an inkling that it's going to go somewhere, but we also understand that it's current form, or it's then current form, I should say, it won't be able to reach the masses and accomplish what people want from it without solving some of these other critical issues. And that's why Ed was thinking about scaling smart contracts before smart contracts were like, because it's like, hey, this is a really, really cool idea of smart contracts,

But if you just look at the technology, it's not able to do massive world scale. And one of two things is going to happen. Either this is going to go away or it's going to get popular and the piping just won't be able to handle all the traffic and demand that's going to come. And similarly, a lot of my early work was in threshold signatures or MPC around MPC is multi-party computation. So a way to have multiple people be involved in signing transactions, critical aspect that you need for security. because if you lose your keys or lose access to your keys somehow, then you just lose your money. It's something which is maybe okay for early hobbyists, but not something that's going to be, you'll need a little more redundancy and a little more protection for,

particularly when it reaches the masses and it reaches corporate corporations that will need a lot more control over that. And that's why we were really working on some of these problems early on around the things that we thought need to be solved before getting crypto to be made. mainstream. That's, I guess, a high level of the things that interested me and some of the others that I did a lot of work with. I definitely want to talk a lot about arbitram, but I'd love to spend a little bit of time talking about some of these projects you're involved in. So from a threshold signature as an MPC perspective, obviously you've seen just a growth in

that industry with the likes of fireblocks and copper and fortify. What's your view on just the current state of affairs for MPC and how that is going as an industry category? I think it's super exciting and critically important. When I picked up, this problem in 2013 with Rosario Gennaro and Arvin Aron, we just saw the need for threshold cryptography as a way to secure Bitcoin at the time, but really digital assets. And we just didn't know how to do it. The technology wasn't available. The last time this had been dealt with in an academic sense was a decade earlier. And it's fascinating because we had a large corpus of literature to build on, but people back there were building without an obvious immediate application of

these technologies. You know, there were some applications like signing updates, in the App Store, but things that were a bit further removed from direct monetary access. And it was just a really, really exciting problem. And we just didn't know how to solve it. And then it took years and years for us to do this. And it really became a blossoming industry, both in academia and also in industry. So seeing all these companies today was extremely, extremely exciting, building with the protocols that I worked on, as well as continuing to improve these protocols.

And you see some of the largest exchanges, putting out libraries for doing this and really supporting this. I think it's critically important. I think we've matured a lot. The fact that large organizations and corporations can use a service like fireblocks or Coinbase custody to secure their assets and some of these are using MPC is really, really important. It really speaks to the maturity of the industry.

I do think we're still early on, though. And when you speak to some of these large companies, some of them have gone over the border. Some of them still feel a little bit apprehensive. So I still think we have some work to do to really bring cryptocurrency to mainstream. But we've come definitely way, way further than I would have imagined. nine years ago and I started looking at this problem. I guess some of the hesitation around MPC and folks that have looked at it but not implemented it yet would come down to, I guess for lack of a better phrasing, just the perception that there

are very few people in the world that actually deeply understand this at a technical level. How do you think about that? And is there a risk here around implementations going wrong? So there's definitely absolutely a risk around implementations going wrong. The one thing I'll say is from a protocol perspective, these technologies are a lot easier to understand generally than like some of these like say ZK proving schemes. Back before we knew how to do them, they were very complicated hard problems, but they're used much more standard techniques for the most part. And I think the importance here is having tried and tested libraries that people can use and people trust. And rather than this happens

software in general, but we're seeing this consolidation around the libraries that people are using. So rather than every company trying to create their own company's open source needs. So, for example, I know that finance has an open source library around MPC using one of my protocols. And I know that's used pretty widely in the industry. I believe I've seen Coinbase has a library that they open source around MPC protocols as well. I'm not sure around if I've seen it in this live. I'm not sure around the exact production status of it. Take a look before you use it. But the idea is coming around and contributing to these libraries is critically important because that's how you gain confidence. If 10 people are

creating the same co-reasing resources, this is really a public good. And that's why it's so exciting to see some of the large industry players open sourcing that knowledge, which in your early on with new technology, it's a hard decision to make. And that's why I really commend the folks that say, finance for doing that because it's critically important to gain confidence in these more complex protocols. Yeah, just don't roll your own crypto, I guess would be a good advice. That is a really, really succinct way of saying the three-minute pi rate I just went on. So yes. Before we started recording, I was telling you that I was a huge fan of BlockSai back in the day.

And so there will probably be a lot of people that don't know what that is. But talk a little bit maybe for the data nerds out there and the on-chain nerds around your involvement in BlockSai in that project. Yeah. So BlockSai actually initially called BlockPi. There's a little bit of trivia. Was this blockchain analysis tool really focused on Bitcoin. And its primary author was Harry Kalladner, who is my current co-founder at Arbitrum and several others at Princeton,

you to myself, were involved in the project. And it was an early open source blockchain analysis tool that was really, really fast and really efficient compared to really other things on the market. So you can ask questions like around the blockchain state, really early data analysis tool. And of course, you know, we've come a long way with other companies and tooling that does similar things for Bitcoin, Ethereum and beyond. I think tools like chin analysis or new analytics. But back then, like you had a question on the blockchain, like, hey, I wonder what percentage of users are using multi-sig wallets? Like, you know, speaking, like, there wasn't a good tool they to give you that answer.

Or it might take days to get the right answer or you have to actually build custom scripts to get these answers. And BlockSai was a way to standardize this and give you a well-known, familiar query language to ask questions about the Bitcoin blockchain, Bitcoin and some others at the time. It was based on UTXO systems. So not Ethereum, but Bitcoin and several other blockchains were supported by BlockSai. And this was another example of early work that we did at Princeton, you know, How are we leading?

And that was commercialized by several others, but an important start and really showed the value in what you could do. Another really, really exciting problem. It's funny you mentioned it because, like, I haven't thought about that in a very long time, but it definitely was exciting work at the time. And something else, which is critically important. You need to be able to analyze these systems and ask, questions and understand what's going on.

I know people talk about the blockchain. It's all public, and that's true. But that's half the story. You also need the tools to make sense of that public data. And that was a first foray into that. And if you look even at the academic research papers, before that, they were basically every time someone wanted to write a data analysis paper on Bitcoin, they were rolling their own tools.

And after BlockSai, you saw a lot, a lot of papers saying, hey, we did this really cool analysis and we use BlockSai to do that. And that was a really validating future. Actually, it's funny because BlockSai didn't get published as a paper for quite a while, actually. And by the time that it did get published, it was published in a top-tier academic conference, there was this citation of like, I think, 10 plus other papers that have already been published and used this tool. So kind of a really, really funny, sometimes that happens in academia where you make your work public. Others get published first using your work. But it's very exciting, it validates that this is a really important tool and really important sector.

Even outlives the tool. Blockside today is not maintained, but I think it had a really profound impact on the industry of successor tools that still exist, both in the public and the private domain. Totally. It reminded me a lot of a search engine, or at least the primitives for a search engine. And it's hard to imagine a world where that idea is not going to be extensible to every blockchain. There's just going to be more things that are notarized down to blockchains and more data put on these things over time. So probably the birth of a category around search.

Absolutely. And it just speaks to how early we were. You always look back at literature and say, wow, I wish I would have been around 10 years ago. All these early easy ideas were there. But sometimes you lose sight because I'll tell you, even at the time, you always feel like you're late. I remember getting into Bitcoin in 2013. I think all the fun ideas, all the good ideas have already been done. Like Greg Maxwell, every time I had an idea, Greg Maxwell, I've written something up similar on the Bitcoin Forum. then. So it always feels early, but I think the lesson I would give from here is it's still really, really early. And looking forward 10 years, a lot of the fundamental projects we're

working on today, even things like arbitraim, Ethereum scaling will seem so basic and so obvious that someone needs to work on these things. So we're still so, so early on. And there's still so much opportunity for many people to make really, really profound impacts, impacts that in 20 years from now, you're going to look back and say, wow, I wish I was around in 2020. Do you to work on because there was just a gold mine of projects that low-hanging fruit that way as like really contribute to a movement that's going to last for, you know, I believe to be a very, very long time. I think that's well said. I remember I was at a MIT Bitcoin Expo years ago and I bumped into your co-founder, Harry, at a happy hour. And I think I told him he should commercialize Blockci.

Turns out you guys commercialize something else. I think it worked out well. But a lot of these ideas ended up seeing great commercial potential. Absolutely. That's actually one of the beauties of being an academic. At the same time, I was working on Arbitram, I was working on blocks. I was working on threshold. The need not to commercialize and really to just focus on doing things that you think are high impact and interesting is the academic environment is unique and that it allows you to do that. And the reason, by the way, which we decided Harry, Ed and myself to commercialize arbitram was like, well, we think this needs to be done right and we want to be the ones to do it. So at some point, you need to see things through and commercialize them. And I have no regrets doing that.

but there is particularly people sometimes ask me, what is the value of doing a PhD? It's that academic freedom right there. It's the ability to work on really, really important, meaningful problems and not have to worry about commercializing them. People have different flavors of what they enjoy. I always like to work on things that seem to have

a short-term production roadmap, things that we could solve. It would be useful now if we had it. But hey, I wouldn't have been able to do that if it wasn't for people decades earlier working on things with a long-term roadmap. So some of the tools that we use to build these FPC protocols have been developed over the past three decades. And so both long-term and short-term prizes are critically important in research.

And it's really a flavor of what people enjoy. Totally, totally. So maybe dovetailing here into Arbitrum, how would you describe Arbitrum just in the context of various categories of scaling opportunities within the Ethereum ecosystem, within blockchain space writ large? I'm curious how you guys just contextualize the different categories and then the, design decisions that you've made? So arbitram is, first, it's a roll-up. And what that means is, it's funny, actually, because when we first formed the company and wrote the paper, if you look at the arbitram academic paper, you won't find the term roll-up. Because this terminology didn't exist yet. We've come around to this technology. I'll answer your question. I'll just say, one

quick aside. I remember we were initially raising funds for the company. People would say, when I would pitch to investors, they say, okay, are you a state channel or are you plasma? up because those were the two scaling flavors at the time that people knew. And I would say, we're our own thing. I didn't have the word roll up. But it got to the point actually, no, no, no. So I was finally to say, okay, fine, we're a state channel. We're an optimized state channel. But anyway, to answer your question, we're not. We are a roll up. And what a roll up basically is, it's a way to use Ethereum or the underlying blockchain, but practically Ethereum as a consensus mechanism. So you don't have your own consensus mechanism. That means you don't have your own

minors or proof of stake. You rely on Ethereum for the correctness, but you compress what you're using Ethereum for us. You get a lot, a lot more mileage. So you compress, compress, compress where you put on Ethereum. You put just enough on Ethereum that Ethereum can understand what's correct and everything else is done off-chain. And so the hard question here is, okay, so how do we convince Ethereum of the correctness of what's done off-chain? Because the critical property of a roll-up, an arbitram, our core technology, arbitral one, is a roll-up. The critical question is, how do you convince Ethereum that what you did off-chain is correct? And the short answer that unifies all roll-ups is you prove to it.

You prove it to it in some way where it's easy for it to verify. The easiest way for Ethereum to verify what's correct is having Ethereum just do all the work. But then we haven't scaled. We haven't taken anything off Ethereum. Our whole point is saying, hey, can we use Ethereum space more efficient? such that we can, in the same block space, accomplish more by putting some off chain and some on chain, but still having Ethereum verify the correctness of it all. And the way that you accomplishes is doing some off Ethereum, putting just enough data on

Ethereum that you can prove back to Ethereum that everything you did off chain is correct. And the critical point is proving should be a lot cheaper than Ethereum verifying it itself. So Ethereum should be able to verify a lot more than it can run natively. And just in one sentence, and then what is a difference? Some of the listeners may have heard about a ZK roll-off or an optimistic roll-up. It's all in how you prove back to Ethereum. That's where the difference lies. All roll-ups put the data on Ethereum, put enough data on Ethereum to be able to prove back,

and they have different techniques in how they prove back to Ethereum. And again, why are we proving these to Ethereum? Because you want the security of Ethereum. We want to rely on its consensus. We want Ethereum to say, hey, even though you did all that off Ethereum, I'm still putting my stamp on approval it. I am saying that that is correct. And in order to accomplish that, you need to prove to Ethereum that so it can itself

verify what happens not only on chain, but also off chain. And so that was a great explanation. How would you kind of go a step further on discussing the tradeoffs between zero knowledge roll-ups and optimistic roll-ups for the listener? A zero-knowledge roll-up, I'll start there because it's conceptually easier to understand. So we take all this execution, we take it off chain. Actually, let's step back for a second. A user is a transaction.

What is a transaction? You can do a transaction in two ways. It's like zeros and ones, just some blob of data. But it's also what those zeros and ones say, hey, add these numbers, store this value, compute this, mint this NFT. And that's the execution. Doing those instructions is the execution. So what a rollup does is it takes the core data, that was zero is one that puts it on chain, but then it takes the execution off chain.

Why does it put the data on chain? Because having access to the data is critically important. The data are the inputs. If we don't have agreement on what the instructions are, we can't have any hope to agree on what the outputs are, what the execution is. If we have agreement what the instructions are, everything from that point is deterministic.

Everything from that point has a correct answer. But if we're not an agreement of, hey, what is a set of transactions? Is there a transaction included? Then we can't have agreement. And actually, other solutions like plasma tried to even put these instructions, put them off chain, and get the security of Ethereum. And that turned out to be harder. And roll up space, you can say, hey, let's put all the data on chain and not even try to solve that problem. Because we can still accomplish so much scaling by putting the execution off chain.

So a ZK roll up, back to where I started, it takes all this execution, does it off chain and says, hey, Ethereum, here is the result of executing these, say, hundred transactions. And here is a validity proof, a proof that it is valid, a proof that the result I gave you matches those inputs. And now you might say to yourself, well, how do you create one of those proofs? That's where the cryptographic magic comes through. These ZK proofs are basically these cryptographic devices, these just things as magical things that take an input and an output and allow you to prove that the inputs lead to the output. And actually, to those that are familiar, so what is the word ZK mean? ZK means zero knowledge. These proofs were really initially used for sometimes used for zero knowledge, which is a different

protocol, which says, hey, I want to prove to you that this is correct without even telling you the answer. Actually, in ZK. Rillups is a misnomer. All the data is public. The property that ZK Relapse really uses succinct. So you may have heard the term snark. Snark is a type or stark. These are types of ZK proofs. These are acronyms. The S stands for succinct. And that's really the property that these ZK proofs use. And what succinct means is, in this context, is it doesn't matter how much data you're proving. You can be proving to me about 10 transactions or 100 transactions or 1,000 transactions.

The proof size will always be small. And that's really, really cool property. And pretty magical property. So that's how zero knowledge proofs work. Optimistic roll-ups use a different proving mechanism in which they use fraud proofs. As their names suggest, they're optimistic. So they say, hey, Ethereum, here's the result of that computation we did it off-chain. But optimistically, I'm just going to tell you, accept it, and I'm not even going to give you a proof.

But then a time window opens where anybody can challenge and say, hey, I disagree with that. That is wrong. And at that point, there's a very efficient fraud-proof mechanism. So whereas ZK proofs use validity proofs to on-submission say, hey, this is correct. Optimistic roll-ups use fraud proofs that they optimistically actually don't give a proofs. proof at all and just say accept this as correct. And by the way, if that time period, generally a week passes and no one challenges, Ethereum will accept it as correct. But anyone in the world can go ahead and challenge it. And that's a really cool property where you can have

everyone in the world saying A, one person saying B, but all you need is that one person doing the right thing. And Ethereum will referee and get to the right point. So that's the basic difference in how ZK and optimistic role of this work. I can get into the tradeoffs and benefits of how these are implemented and how efficient they are. But that's sort of, let me pause there because that's the high-level difference of least what they're trying to accomplish. That was really well explained. And I guess the obvious question is, why did you choose the path you chose? And so it'd be curious what you were thinking as you were thinking about launching this company and why you chose the optimistic path. It's an interesting question. Going back to my time at Princeton's, I mentioned that I

got into this space by my interest in deep cryptography. A lot of my earlier work was involved in multi-party computation, these NPC protocols. I actually did some work in ZK proofs as well before Arbitrum. We had a paper, interestingly, which showed there was this system put out by some of the Zcash engineers that allowed you to sort of exchange values. And we had put out an attack in this proof system as well as a fix. So I had to look at a ZK, been very, very familiar with this. And probably those who don't know anything about Arbitrim and just know what I was working on at the time would probably assume that Arbitram is a ZK roll up because that sort of matches the technologies that I had been working on. But I think a critical thing about us, and by the way, I did look at ZK.

Rolves at the time with Ed and Harry, and we looked at ZK technology with this idea, and we decided that it just wasn't ready yet. And that's the critical thing about us, which is we come at the problem with scanning Ethereum, not around, hey, we have this particular tool that we need to use to solve this problem. That to me is the wrong approach. The approach that we come is, hey, there's this problem. We need to solve this problem with the best tools that we have available today. or the best tools that we can build today.

The problem here is scaling Ethereum. I don't come to this fight with a particular tool in hand that say, hey, I need to use this tool. As an analogy, you know, imagine you hire someone to fix a leak in your house and they come and say, I haven't looked at it yet, but I will use a hammer. But maybe I don't need a hammer to fix this leak. Maybe your hammer is not that optimized. Maybe we have a better tool now.

Maybe in a year or two or three, you'll have a different tool. But now what is the best tool we have? And that's how we approach us. We're not focused on the tool. We're focused on the results. And it was clear to us when looking at this problem that when you look at two metrics, well, all three metrics, which is throughput, cost, and also compatibility. So compatibility with existing tooling, with existing developer knowledge,

that optimistic roll-ups were a much, much more viable approach. And by the way, optimistic role, it wasn't like we were taking off-the-shelf things. We developed the technology using interactive fraud proofs and optimistic. roll-ups was something that we developed. Like I said, the term optimistic roll-ups didn't exist. The term role-ups didn't exist. We developed a lot of this core technology. But using the tool set around fraud-proofs and interactive fraud-proofs and developing that seemed like a lot, a lot more feasible approach to get to the low-cost and compatibility to us. But again, we're focused on the result, not the tool. And that's critically important. And just recently,

we launched the Arbitrum Nitro upgrade on Arbitrum 1. Nitro is a brand-new software stack and it actually changes a bunch of things from our original Arbitrum paper. The original Arbitram paper, one of the key innovations of it was what we call the Arbitrum Virtual Machine. We've sunsetted the Arbitrum virtual machine. The Arbitram Virtual Machine no longer exists in production. Now that we've upgraded to Nitro, Nitro uses WebAssembly, a different, more standard virtual machine, which we've managed to work inside a role. Back then, we didn't think that an Arbitrum Nitro design was possible. After years of research, we developed and now actually launched this design in production.

And why do I mention this? It's because, again, the focus is on the result, not the tool. If I came to this and said, hey, I spent years of my life, actually with Ed and Harry and others working on the AVM, I am not letting this thing go. We have to include this. That's, in my mind, a losing approach. Because, and it's losing approach not only for us, but for the ecosystem at large. We need people that have that academic mindset.

And don't say, I need to use what I develop, but they're going to use what I develop. They say, hey, I need to use the best tool available today. And I'm super happy that the AVM doesn't exist anymore, even though I created it. Because you know why? The AVM had served a great purpose. At its time, it was the most efficient and the most optimized way to build a roll-up. And now that we've had a few more years of experience, we have a better way to do that. And I think it would be a big downfall for us as a company and us as a community if we said,

if we had too close of a connection to the tool. And similarly, what will happen in a year or two or three from now? I can tell you this. I can tell you that we have other initiatives nitro-like that we're working on that will get us more and more optimized solutions and better. And we'll absolutely sunset a lot of the nitro design when it makes sense. Right now it's the best thing we have available. And do those solutions include ZK? Maybe, maybe not. But we're not married to the tool or married to the result and we'll use whatever tools is the right tool at a time. And we're confident that today, Arbitrum Nitro is that tool. You actually took the question right out of my mouth. I'm talking about,

is there a world where you guys will interface with ZK systems? And it sounds like a big part of this is just going to be what is the commercial demand for scaling on these platforms. And so maybe that's a good dovetail into some of the work that you guys have done with Reddit. And I'd just be curious what your conversations look like in terms of what customers are actually asking for and how deep they go on the various tradeoffs on implementation. Absolutely. And they think there are different types of customers that we work with. There's crypto-native folks that are really interested in building crypto products, Defi, and then there are also folks that are sitting at companies like Reddit that are saying, hey, how can we not a by nature of

crypto-native company, although Reddit is very, very forward thinking and how it embraces crypto for sure. When they say, how can we use crypto and incorporate it in our current technology stack to do something really that we couldn't do with just Web2? How do we think about these interactions? And of course, different types of teams need different. things, and different teams also have different amounts of resources. And that's one reason why compatibility is something which becomes very, very, very important. If you have a team that's looking to build something new today and they have dozens of engineers, then they might care less about the exact technology, how compatible it is with the theory. I'm like, well, we don't really care.

Maybe. We're building from the ground up. But if you're a team of one or two engineers and you know how to build solidity code, or even if you're a team of two founders that are looking to hire your first engineer. And you know where to hire a solidity engineer, but you don't really know where to hire a, say, custom engineer for some roll-up stack language. That's where compatibility becomes so important. It becomes important because the knowledge is there. The code is a large corpus of solidity code. I know on GitHub, open source code that you can read and learn from and potentially incorporate depending on what you're building. That's why it's so, so important to have that compatibility later. And the counterintuitive thing is even for those big companies that may have the resources

to not use that, it becomes important because the value of crypto is largely in the broad ecosystem and the synchronous interactions that you can have. So the fact that you can have a defy transaction that in a single transaction, autonomically calls three others and does something that the sum of these is more than you can do in any one of these protocols is really, really, really important. So you might be really, really well-funded as a startup. You're still going to want to be where all that innovation layer is. If you're a uniswap, you might have a lot, a lot of resources, but you're going to want to make sure you have a platform that other startups and other protocols can tap into, and those protocols may be less resource as well. And that's why compatibility

is something which we focus on so, so much, because it's fascinating and it's really, really important, even counterintuitively, even if you don't need any, you're well-resourced. And so when we look at different teams, one thing which we try to do is give all teams the same level of love and the same level of respect. One thing we did when we launched Arbitrum 1 was we did a fair launch. And what that said is we did the same thing with Nova. We basically, in the case of Arbitram 1, a few months before the launch date, we said, hey, we're going to launch Arbitron 1. If you want early access, developers only tell us now because on day 1, all of you are going to have the opportunity to go live together. We're not choosing winners.

We're not saying, oh, you're a number one protocol so you can go live first. We're saying everyone is invited to go live together and put in the same foot. That's the importance of crypto. There's no gatekeeper. And when it comes around launches, when there are gatekeepers and you have the ability to gatekeepers, I think it's important to really, really let that mentality sink in and not be gatekeepers and allow everyone fair and equal access. That's something which we've done.

And by the way, it's something which you do because of values, but it's also really, really, it works out quite well because I know who the number one. protocols today are, I don't know who the number ones tomorrow are. One of the really, really big success towards our arbitrage is GMX. They're doing quite amazing today. We love them from the very beginning. We supported them from the very beginning, not because we had a guess that they were going to be as successful as they were, because that's the same support we give everyone. And we're doing that today with protocols. Some will become the next GMX. Some won't. And that's okay. We get that sort of support to everyone. So I guess to answer your question, there's a lot of support that we like to give to people.

people have different needs. Compatibility is a really, really important one. And a lot of the support we like to do is on the tooling side to give people these compatible tools so that they can then use the skills that they already know or that they can pick up easily or hire for easily to build an arbitram really, really effectively. It's fascinating. The compatibility in the social layer of Ethereum have really been very friendly towards layer two scaling and just the broad ecosystem of participants that have popped up. I'm curious your perspective on Bitcoin, because you'd mentioned Greg Maxwell, there are old Bitcoin talk lists where he's talking about zero knowledge scaling on Bitcoin and things that he didn't use the word roll up, but things

that sort of looked roll up in nature way back in the day. Obviously, Bitcoin didn't go that direction. I'm curious your perspective on why and whether or not there are technical reasons or if it was social in terms of why that protocol did not scale up the same way. I think it's a largely social. Ethereum has moved to proof of stake is a great example of the ability to reinvent yourself and the ability to innovate. And sometimes it's controversy, sometimes without controversy, but that's really, really strong and powerful. I think that's, of course, strength of Ethereum.

I think Bitcoin's approach is also, or what it's become today, is much more, I say, ossified and resisting any large-scale change. It's also a very respectable approach and has a lot of values to it. So I think this is a core difference in Bitcoin and Ethereum. Obviously, I am very, very aligned with Ethereum's approach, but that doesn't mean that I don't see value. in Bitcoin's approaches as well. But one thing that I'll say that it was funny, which you may remember, Zcash, I'll take,

was first proposed as zero coin beforehand. It was really proposed as something to add on to Bitcoin. This was like the initial thought. And back in 2013, people thought that might be feasible. So that's why I say it's really, really the way that the community and the social, like today you say, hey, let's add ZK to Bitcoin in a core protocol way. There are things you can do with like operative. There are things you can probably do in sort of,

of a building on the current design, but like, let's change Bitcoin. Like, it just becomes obvious that that would never happen. But back early on, these things were not set in stone. So I think it's really a way that the communities have developed. And I think ultimately, like I said before, we're early, early on. These are two very, very different approaches. And I don't know. I think there's definitely value to both them.

And I also think over time, even Ethereum, like, Ethereum is making some very, very, very important changes now. but I imagine that looking forward a decade, that the pace of change may slow down as we get to more optimal designs as well. And if that happens, do you imagine a world where Arbitrum is building things on top of Salana or another L1 in the future? How do you think about the emergence of just net new chains to the world? That's another great question. I definitely think we're early on.

And a lot of the difference change. It's a matter of experimentation. Bitcoin makes certain decisions, Ethereum makes certain decisions. And other questions to those decisions and say, maybe we should do other things and they put actually some code out in that point of the design space because it's a vast, vast space that you can explore. My personal belief is in the longevity of Ethereum and the Ethereum really winning out long term in the smart contract space. And the reason why I believe that is both the tech and the ability to technically innovate. I think that's very,

very important as well, but also the community. I'll tell you this. I don't think there's anyone in the world today that would say, hey, if I design the EVM today, if I design a thing, Ethereum today, I would design exactly like it is. That's not a controversial statement because there's so many EIPs that so many people would just EIPs or Ethereum improvement proposals, that there are so many changes to Ethereum that so many people would love to make. So if you had a clean slate design, there are definitely in seven years of learnings, obviously things we would change, but this is as true with all software, but as the community builds, as the knowledge around it builds, it becomes harder and harder to change software. So certainly, it's non-consum controversial to say

there are changes to Ethereum that could be beneficial, but you have to look at the full picture. If there's an Ethereum community that's really, really engaged and really, really innovated, really, really devoted, that's just as powerful as the technology behind it. And these two things together, I think, are a very, very powerful force. And so to the question of arbitrar in building another layer ones, today, if I have to ask myself the question of, should we put resources on another layer one or should we make the Ethereum experience better. Because of our belief in Ethereum, it's obvious that we should put those resources into Ethereum. And I expect that to remain so for a long time. The Arbitrum code base

could be adapted relatively easily for other chains, particularly EVM chains, even non-EVM chains relatively easily. We just don't think that that's a good use of our time. If I'm like totally wrong and Ethereum collapses tomorrow and something else emerges victorious, could Arbitrum adapt to that? Of course, yes, it definitely could, but that's not the series of events that we believe happens and we are very, very connected to Ethereum based on our beliefs. But again, we're not tied at the hip. It's a decision that we, in a renewed way, we make every day. Every day we believe that Ethereum continues to be the leader. And I expect that to be the case for really a long-term future. And do you think that we'll live in a world where there's a progression from being an L2

and to being your own L-1? Is that going to be a dynamic of this market that we'll continue to see? I don't really think so, to be honest. Are there some people out there? that may have this view, it could be, that's not Arbitram's view. The value of Arbitrum is that it's a layer two. Ethereum is so valuable, that community, that decentralized as security, and we're able to inherit that, but also provide scalability. That is the core value of Arbitrum. And that's why I love the fact that we're not competitive to Ethereum. We are part of Ethereum. We're a core part of Ethereum story. And that to me is very, very important. So we definitely have no intentions of bootstrapping into a layer one. That would be against what we're trying to build.

here. And I think any layer two that does do that, then they're just going to be in the same category as others where they're not going to have the decentralization of Ethereum. They're not going to be able to recreate that security of Ethereum. And then they're just going to be an alternative layer one. The magic of layer two is that you're able to get that security from Ethereum. And to us, that's the whole reason we're doing what we're doing. That makes a ton of sense. You know, I was going back and looking at your academic papers and I had forgot that you were a co-author on the Flash Boys 2.0 paper. And that has to be a fascinating thing to look at just given everything that's happened in the MEV space. And so how do you think about

what's going on in that space and how does it impact Arbitrum? That's an incredibly, incredibly exciting space. And also a paper, I remember in some of the early conversations around that paper with Phil and Ari. And we appreciated how important this was. And I remember a conversation we were saying, I hope others appreciate this. This may not be the most cited or important paper to many people, but we think it's critically valuable. And it turns out that others agreed with that. It did become a very, very important paper and really feel now, M.V. And of course, Phil's went on to do really great work at FlashBots, continuing to really build solutions to many of the biggest problems posed by MVV and really think about the long-term effects of MV. How does it affect arbitrum is a great question.

So the history is, so that paper after the Flash Boy's paper, so this is, by the way, after I graduate from Princeton, I did a postdoc at Cornell under Arijoules there. And this was a paper that I was fortunate to collaborate on, you know, primarily Phil's work, but I was fortunate to be involved in that paper. We went on to write another paper as well around fear ordering protocols for consensus protocols that had fear ordering. So what does that mean? Your typical consensus protocol, think about Bitcoin or any proof of stake protocol. They care about agreement. So some minor proposes a block or someone proposes a block, and we all agree to that block, and then we're all happy. As long as that block has valid transactions on it, the ordering of those transactions

doesn't matter, which transactions were included or excluded is up to that particular minor, minors even mind empty blocks. And that's true of basically all consensus protocols pre-2020. The notion of some fair ordering or first-in, first-out ordering, that the ordering that your consensus blocks produce should match the ordering of the way that these transactions came in was not something that was addressed in consensus. And this is another problem, which I worked on in Cornell with Ari. And this was a paper that was led by Mahimna Kalklar and said, hey, can we build a consensus protocol that actually has a fairness notion involved?

And how does this affect a roll-up? Well, roll-ups have a sequencer. The sequencer, so basically a user submits a transaction. And the sequencer includes that transaction. And it's censorship resistant in the sense that you can post a transaction on chain to force the sequencer to include it. But the fastest path onto the roll-up is to use a sequencer. The sequencer can't damage.

It can't include false transactions. It can't censor. It can't really do much. But the only thing that it can do is it can reorder transactions. It can extract MEV, as you may say. And this is a place where Arbitrum and others differ a lot when it comes to our approach to MEV. So again, you have this sequencer, which is this piece of software that accepts transactions and has the ability to reorder. And when run in a centralized way,

we say, hey, we don't reorder these transactions. And every role that's operating, whoever's operating them basically is giving you the guarantee of saying, hey, we don't reorder these transactions. What is the long-term approach to this? There are two approaches. The arbitram approach is to use a fair consensus protocol for the sequencer. So, to decentralize the sequencer by distributing it amongst many nodes, all of whom are running this protocol, and now you have fairness guarantee. So it's not me telling you, hey, we're not reordering transactions.

It's the distributed protocol that's not reordering transactions. Again, the sequencer is relatively low power, has relatively little power to do anything on chain. It can't get false transactions and as it is. It can't censor as it is. But taking away its reordering power by tying its hand saying, now, hey, sequencer, you are forced, by the way, it means of this protocol to include transactions in the order that you receive them. Other roll-ups actually take a different approach here, and they say, hey, the sequencer is very

valuable. It can reorder transactions and make a lot of money doing that. So let's auction off the right to be the sequencer, and now someone will buy that and actually reorder it. Transactions, and then the price will be high, and then they say, okay, and we'll take the proceeds for that and donate it to public goods or give it back to users. we don't believe in that. We believe that we should minimize MV to the extent possible. To the extent that MVs exist, we should democratize it and just like things like FlashBots are doing

really, really well. I think they're doing really important work. But we believe that we should not sell the right to extract MV, but try to minimize it. Yeah, even if that's leaving value on the table, but that's value that's coming directly from the users of our chain. And we think overall, it'll be a much better experience for the users of our chain. It's such a fascinating space because you think about blockchains becoming more scalable. You'll probably have more central limit order books. Maybe the AMM model becomes less of a pervasive model. But you'll probably still have other mechanisms that more closely resemble the centralized infrastructure where you have like co-location and things like that. It's a problem that is probably never fully fixable, I guess.

It just continues to permutate. Absolutely. There are people out there. Some of the flashbots teams, for example, Phil's written about this. They don't want to. like this first in, first out fair order model. He's say, okay, so it leads to other issues of co-location, which is true. People will try to, if it's a first and first out model, people will now optimize being first. That's true, but we view that in a protocol level as fair. Everyone's on the same footing.

They can optimize being first, but from the protocols perspective, it's not reordering. It's not trying to extract value from users, and others are on the general same footing there. But there is an argument there was exactly like you say, we're not eliminating MEV. people are going to try to be first and do creative things to minimize their latency. And so there's a lot of, there's definitely a design space here. Our goal is basically twofold, two prongs here. Number one, minimize MEP to the extent possible. Number two, democratize access to what's available.

I don't think we're going to get down to MV zero, but I do think that from a protocol perspective, fair ordering does minimize a lot of the effects of MEP, knowing that the transactions come in in the order that they come out, it's really, really valuable. And then we think about what else can we layer on top of this to solve some of the remaining issues? Because yeah, absolutely, they don't go away. This is a fascinating conversation. I could definitely keep you on here for another hour. But I know we're wrapping up here. So we'd love to just hear what's on the horizon for Arbitrum and where can we send people to learn more. So really, really exciting month for us last month. We launched Arbitram Nova.

which is our chain that's optimized for gaming and social. That's the chain which Reddit launched, which we touched on a bit earlier. Also, we have Arbitrum Nitro now running on Arbitram 1 main net. We did the big Nitro migration on August 31st, which was a really, really critical moment for us. It was also, by the way, Arbitron 1's first birthday. So that's been running for over a year now,

and quite a year it's been. So for those that are looking to build on the chain, we have Arbitron 1, which is a home for Defi, and lots of NFT projects, Arbitrum Nova, which is home for social and gaming applications. And we think we have a really good solution for basically all blockchain applications at this point. If you want to learn more, following us on Twitter at Arbitrum is a good place to learn about the various builders, various projects building on the chain, as well as other initiatives. Our Discord is also a great place to not only listen, but also interact and ask questions.

It's friendly. Ask your questions. There are no dumb questions. Please feel free to come and engage. with the community. And we also recently launched the Arbitram Nitro white paper, which is a place if you want to dive more deeply into some of these details, a really, really good place to look. And we also, together with the Nitro launch, released a new developer site. It's at developer. That offchain labs.com. Offchain Labs is the name of the company, by the way, that develops

arbitram. And you can find a lot more there. Some of it a bit more accessible to developers than the white paper, which is targeted more at a research audience. So a lot, a lot of resources. is there. But again, Discord is your friend here. If anything's not clear, if have any questions, reach out there. And hey, if this stuff sounds really interesting and you're like, I just need to get into this full time, we are also hiring and both for engineers and non-engineers. It's a young space. There's so much to do. And we need basically all the help we can across every vertical. One of the questions people ask me all the time, people reach out to me on Twitter and say, hey, is it too late for me to learn solidity? This old is it too late. And usually I'll say,

it's probably not too late for you to learn solidity, but you might have a skill set that you contribute to this space a lot without learning solidity. So there's a lot, a lot you can do, even if you're not a developer, to help Web3 progress and really, really get mainstream adoption. And I think those are some of our core resources. I might just start telling people to go read some of your old papers. Turns out a lot of these things end up being companies. So that's another good resource to go back and just brush up on the academic literature.

Yes, and that's one thing which I have found myself. with not enough time to do it to keep current on the academic literature. So I'm with you on that. There's so, so much value happening there, continuing to be produced in the academic literature. And if you want to get a sense of what companies will be doing in a year or two or three, there's some really, really good alpha of what's coming out of academia. Totally. Awesome, Stephen. Well, thanks so much for joining us today on the podcast. Absolutely. Thanks for having me. Thanks for listening to another episode of On the Brink with Castle Island.

To find out more about Castle Island, visit Castle Island.V.C. To listen to all of our podcast episodes, please go to On the Brink-Podcast.com or just click on the tab in our website. Thanks for listening.