Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ed Felten: Arbitrum – The Layer 2 Scaling Solution Increasing Speed and Reducing Fees

Episode Date: June 17, 2022

Arbitrum is a Layer 2 scaling solution for the Ethereum blockchain which helps reduce high transaction gas fees. Arbitrum uses a multi-round optimistic rollup that regularly checks in with Ethereum’s main chain. OG cypherpunk and ex deputy CTO of the USA, Ed Felten, is one of the creators of Arbitrum. He joined us for an in depth chat about how transactions are processed on the protocol, who validates them, what the security guarantees are, and how the economics will work in the longer term.Topics covered in this episode:Ed's background (including his time as deputy CTO of the USA!) and what led him to creating ArbitrumA walk back to pre-blockchain cryptoWhy Arbitrum chose to build on top of EthereumWhat are roll-ups and what's the user experience with them on Arbitrum?A deep dive into how transactions work on ArbitrumHow nodes work on the platformTransaction fees on ArbitrumHow is Arbitrum designed differently to Optimism?Arbitrum and bridges to ETH and other assetsHow will different scaling solutions co-exist in the future?Episode links: ArbitrumArbitrum on TwitterEd on TwitterSponsors: Gnosis Safe: Gnosis Safe is a smart wallet for securely managing digital assets and allows you to define customized access permissions. - https://epicenter.rocks/gnosissafeTally Ho: Tally Ho is a new wallet for Web3 and DeFi that sees the wallet as a public good. Think of it like a community-owned alternative to MetaMask. - https://epicenter.rocks/tallycashSteakwallet: Steakwallet is your new favorite multi-chain, mobile wallet. Tired of having a different wallet for every chain? Get Steakwallet today and get the power of Web 3 across all chains right at your fingertips: https://steakwallet.fi/ -This episode is hosted by Brian Fabian Crain & Friederike Ernst. Show notes and listening options: epicenter.tv/448

This is Epicenter, Episode 448 with guest Ed Felton. Welcome to Epicenter, the show with shocks about technologies, project and people, driving decentralization and the blockchain revolution. I'm Friedricha Ernst and I'm here with Brian Fabian Crane. And today we're speaking with Ed Felton, who is the co-founder of Arbitrum, which is a roll-up solution on top of Ethereum. And we will talk about this in great detail in just a bit. But before we talk with Ed about Abitram, we would like to tell you about our sponsors this week.

So first of all, we have Gnosis Safe. So Gnosis Safe is a security standard for Web 3, reimagining the future of ownership and value coordination. It works as a multi-signature-based smart contract account and is compatible across popular EVM chains. It's totally programmable to give the power to, you know, customize permission and access, say, user limits, and ensure maximum security while doing so. Secures over $60 billion worth of assets and caters equally to individual dollars, institutions and enterprises. So try Gnosis safe out today to secure your asset.

It's available on Ethereum, Optimism, Polygon, BSE, Avalanche, Arbitrum, is it? Yes. Very good. And so to do that, go to Gnosis dash save.io. We are also brought to you by Teleho. Teleho is redefining the wallet as a public good. You can think of it like a community-owned alternative to Metamask. With Teleho, you can enter the Metaverse with a Web3 wallet that's fully community-owned

and operate, and it's the first wallet that's also a Dow. Teleho's commitment to community ownership and public goods stretches beyond the wallet. In January, they became the first sponsor of EtherJS and open-source JavaScript library helping developers connect to Ethereum. and they recently announced the pledge to commit 2.5% of their total token supply to Gitcoin acaduct. Head over to Teleho.cash to try the Teleho Community Edition and play around with its features before its upcoming version 1 launch and the launch of the Dow. And our last sponsor, Stake wallet.

Stake wallet is your new favorite multi-chain mobile wallet that puts the power of Web 3 at your fingertips. In just a few tabs, you can stake and manage your assets on over 22 built-in protocols, including all major EVMs, non-EVMs, and layer tools like Arbitrum. Stake wallet is adding new features at light speed, so you always have the best support across all chains. Just in the last weeks, they've shipped three-tab, B&B chain staking and harmony one staking. Stake wallet has also a pretty good NFT support on a mobile wallet, and you can view all your NFTs in one place.

And it's about to become the first mobile wallet with Arbitrum NFT support as well. watch out for an announcement at NFTA New York City on June 20th. You can download stake wallet today on iOS or Android at stakewallet.fI spelled steak like the meat. Fantastic. Ed, it is such a pleasure to have you on. Thanks for having me. Ed, you are an OG cypunk. You have been doing this longer than all of us.

Tell us a little bit about yourself and tell us about crypto pre-block chain. Sure. Yeah, so I've been working in, I've been playing around with software for a long time, actually, since the 1970s, believe it or not. and got involved in security and privacy and cryptography research going back to the 90s. I spent quite a few years teaching at Princeton University and Computer Science Department. And a lot of my research there was around cryptography and security and getting into ideas of digital money, even before this sort of explosion of cryptocurrency started with, you know, with Satoshi's original. Bitcoin paper. But I got interested in cryptocurrencies and blockchain really early and started doing

research in the area. And yeah, that's kind of what led up to Arbitrum. But, you know, over the years, I've been involved in a lot of different security things as a researcher and also maybe surprisingly to folks in this space as working in the government as well. So, Yeah. And I think a lot of that has really helped me get a perspective on what's happening now in the crypto space. You used to be the deputy CTO of the USA. So forgive me this question, but I'm not American. And what does the CTO and the deputy CTO get to do? Sure. So basically, as deputy CTO, I was a member of the White House staff and senior advisor to the president, then President Obama. And basically the job of the CTO and deputy CTO is to advise the president and the president's advisors about things having to do with technology. So we were not building stuff.

We weren't running systems. We weren't the ones whose pages would go off in the middle of the night if there was some kind of an incident. We were producing words and advice, but rooted in an understanding of technology. So if, you know, there was some kind of security breach somewhere or if there was a policy issue around technology, then we would work on it. So as an example, I worked some on encryption policy, you know, should the government regulate or ban end-to-end encryption. I worked on AI and machine learning. I was one of the folks who drove the national policy initiative on AI and machine learning back in those days. and things like that.

So basically advising senior government people and up to and including the president, kind of an amazing job to have. And did you do any crypto-related work as part of that as well? Yeah, I did some. You know, this was very early days in terms of government figuring out thinking about crypto. But one of the things I was working on

was trying to get people across the different departments of the U.S. government to start talking about crypto and what they should do, help make sure that the different parts of government of the executive branch understood what was going on. And we're starting down the road of thinking about what they should do, whether it's people thinking about should we have a central bank digital dollar, as well as people who did things like consumer protection and various kinds of regulation, make sure that they understood what was going on and we're going to take a thoughtful approach to it.

So I was involved in sort of early attempts to get that conversation going within the U.S. government. So I'm curious because you mentioned before that, like, you know, you had this sort of perspective on, on crypto and blockchain, you know, that was like maybe different because of, you know, the work you did before. I'm curious if you can talk a little bit more about that, sort of, you know, when you discover Bitcoin, like, what was your perspective and how has it changed as the, you know, industry has evolved. Yeah. So, yes, let me tell you a little bit about that, well, that particular, that comment of how my working government has, has affected my views on this. First of all, I have been a regulator or I've worked in a regulatory agency. I've worked at the Federal Trade Commission for a while, which was, as their chief technologist, which is in the U.S. government is the main agency that protects people against commercial fraud and scams.

And so, you know, that mindset of how do we make sure that companies are not just stealing from people, you know, the equivalent of something like what in the crypto world would be a rugpole or some kind of other, you know, really fraudulent activity. And sort of thinking about what do you need to do to help protect people against that and what is the role of government in trying to shut down the bad actors and try to get the money back and give it to the money back and give it to the money. the people who it was stolen from. And so I got some perspective from dealing with some of the types of fraud and scams that were going on online in those days. That was like 2011 and 12. So then I did that for a little while. Then I went back to being an academic. And during that academic time, starting around 2012, 13 is when I discovered Bitcoin and got really interested in this stuff as a research topic. And like questions of how people could protect themselves and how you could know that something that some software was telling you

was going to happen was actually going to happen was part of that. Plus just like understanding basic questions like is proof of work incentive compatible? That is like does it actually incent minors to behave in a cooperative way? Which turns out to be a much more complicated question than you might think. But anyway, then sometimes early on I learned about smart contracts and this idea that you could do run software on top of a blockchain. And I thought this was the coolest thing ever. And got really excited about the tech, especially what, you know, as a vehicle for building software.

Because I'd like been involved in and seen the development or sort of early development of internet and web technology and saw sort of that stuff go through its very early commercial birth and some growth and some growing pains. So I'm like, okay, this is. is going to happen with smart contracts. This is going to be huge as a software platform. That in turn led me to thinking about, well, like, what are the technical barriers to that technology actually getting used by a billion people? And, well, one of the big technical barriers that seemed obvious at the time was scalability. And that in turn is what led to the work that

and sort of the birth of Arbitrum in early 2014, sort of as an attempt to try to solve the problem of how to scale this technology up so that it could get the use that I figured that I think a lot of people did at the time that it was going to demand. So let's talk about Arbitrum in just a bit. But basically thinking back about the very early P2P community

or the pre-Blockchain P2P community, there are large reservations or holdouts that are very skeptical of blockchain technology as a whole. Why do you think that is? Well, so I think it's a bunch of things. And we saw some of this with the early web technologies. I mean, we have to admit that some of the things that go on in this space are basically just scams. They're people who are dishonest or people who think.

they're honest but are actually doing things that are really dangerous. So this idea that it's kind of a, you know, a wild west that people are doing all kinds of risky and scammy and dangerous things, along with a lot of legitimate and exciting building, that pretty much reminds me of the early internet days. And there was a bunch of skepticism there. But I think there's extra skepticism in our space of our space. And it's for a bunch of reasons. I think like, There's a natural skepticism about new tech areas, especially ones that have a lot of venture capital pouring into them. There's a natural skepticism about finance and finance as a field and the kind of people who hang out in that space and in the tech space. Like right now, tech people are kind of out of fashion, the idea that people who are building and running tech things are like dangerous and antisocial.

and that the tech industry might not be good for the world. Like, I don't buy that at all, but it is kind of a fashionable view. And I think we get some of that. Plus, we get some of what happens because we're new and people are trying a lot of things and some of them fail. And then I think there's this other dimension to it, which I can't quite explain, that it's kind of become fashionable in some circles to say that, like, everything happening in the blockchain space is just a giant, Ponzi scheme, which I think to anyone who's in the space and paying attention is obviously wrong. But, you know, I think it's become fashionable in some circles to say this is all bogus and nothing interesting going on, which, you know, I think could not be further from the truth.

There are some people in this space who are liars and dangerous and so on. But there's also a ton of people doing really interesting and solid work. And, you know, and that's what will last. Just like in the early Internet, there are a lot of people trying crazy things and nobody remembers them. But, you know, people do remember those who actually built valuable stuff over time. Yeah, absolutely. Well, let's talk. So you mentioned 2014, right?

You had this kind of early scaling work you did that, you know, kind of later became arbitrary. Can you talk a little bit about, you know, what was that 2014 project? Yeah. Well, so it started just with the idea, the idea of which I think today we would call layer two, which was that you could have something that was basically a chain, that if you had a base chain, which had smart contracts or something like it on the base chain, that you could build a chain above it or off on the side, and then anchor the security of that second chain,

sort of in the first chain. So you could have this thing where you could have a chain running off on the side, that it would use only a little bit of the capacity of the base chain, but if you did it right, you could sort of inherit the security of the base chain. So that was kind of the key idea to move almost all of the work off the main chain, but have just enough functionality on the main chain to maintain security. And the key idea that enabled that was what's now called interactive fraud proofs, which is basically a way of resolving a dispute between two parties about what is the correct

outcome of a computation and do that in a way that involves very little work sort of on the base layer. In early 2014 is when that idea sort of came along. And for most of 2014, I had a diagram on my whiteboard in my office at Princeton that was a diagram that sort of showed the steps of an interactive fraud proof. And then in the fall of 2014 semester, there was one of my colleagues, Arvin Naurianon, taught a course on blockchain tech. And all the students in the course had to do a course project where they would design or build something. So a group of, I think, six students got together and they, five or six,

and they decided to build a version of this thing that I had on my whiteboard. And one day sitting around the table, we came up with the name Arbitrum for it. And so they built a kind of very early proto-arbitrum, which didn't quite work and didn't have the features of anything like today's system. Obviously, over eight years, the system has evolved a lot. But basically the first version they built in fall of 2014, and you can actually go on YouTube, and if you search for something like Arbitrum Princeton students or something like that, you'll see a video of their course presentation at the end of that semester that they gave in January of 2015,

and they talk about basic ideas that you might still recognize in Arbitrum today. So that was the very first version of Arbitrum. What was the base layer that it was built on back then? Well, that was the funny thing. There wasn't really a base layer. we had to just assume that there would be one. So the idea back then is you had to build something that kind of simulated the base layer.

Yeah, so this was before Ethereum was, you know, was at the point where you could use it. So yeah, there wasn't really a base layer at that point. We knew there was going to be one and that, you know, we had a design that what could be sort of agnostic as to what base layer it was on. You know, much later, when we decided to commercialize the technology,

when we started our company, we said, okay, Ethereum is the place to go for a lot of reasons we could talk about later, maybe. Yeah, but initially it was agnostic, and we just had a kind of simulated base layer underneath. I'm curious, was this idea of like a kind of like a layer two, was this like the first time this came up? I mean, I know Lightning Network wasn't like that much later,

but I think it was maybe 2015 or something that the lightning, were there other ideas like this around? I mean, I don't know of the idea of a layer two being out there before. I would hesitate to claim I was the first one to think of it, but because good ideas pop up everywhere and repeatedly. There was something not too different from, there was a much less efficient and probably less practical thing that was related to the interactive fraud proofs that was in academic paper from 2011 by Ron Kennedy and some other people called referee delegation of computation. So I would say this sort of emerged out of a cloud of ideas that were out there.

And, you know, as a researcher, I often felt like there were ideas swimming around in my head trying to find the right way to latch onto each other to make a, you know, like a design or a solution. And I feel like that's kind of what happened, at least for me at that time, that there were ideas that people were talking and thinking about and like this particular combination of ideas and the way that it could, you could use it to scale smart contracts sort of jelled around that time. So anyway, so 2015, right, the students finished this project. And so we have this thing, which is where a sort of early pre-prototype proof of concepts, things sort of existed.

And this is where this sort of story evolution of arbitram collides with my story about working in government because my sort of my life took a detour not long after that. which is I got invited to go work at the White House. And so I did. You don't say no to that kind of offer. And so arbitring just kind of got put on the shelf during the whole time. You know, being like a somewhat senior member of the White House staff is the most all-consuming job I've ever seen. And so there's no time for anything else. Afterwards, in January of 2017, at the end of that administration, they pushed all of us staff

is out the door. And I went back to being an academic. And while I was there trying to sort of get my bearings again and figure out what I was going to do for research, these two, one day these two grad students, Harry Kalladner and Stephen Goldfetter, walk into my office and say, hey, remember that arbitram thing from before you went off to the government? I'm like, oh, yeah, that was, I thought that was fun. And so they were, they said, let's do that again. So, like, they came to me and said they wanted to work on this project with me and like turn it into a more sort of mature and complete system. And a year and a half later, we were the three co-founders of, you know, of off-chain labs, which is a company that's built the commercial version of Arbitrum. So that was

sort of the revival of Arbitrum, which was sort of really came from the two of them, coming back and sort of reminding me of this and saying we should do this. And then one thing led to another. we had an academic paper that we published in 2018, summer of 2018, and then like almost immediately afterwards we formed the company because it looked like something that had commercial potential and we wanted to like actually get it out there into, you know, the hands of users. Yeah, super interesting. And basically, I think the stress level of being a crypto founder is put into perspective

by having, you know, an even more stressful job beforehand. And so I think you played this very well. Yeah. There's frankly no comparison because what we do today is important. It's important to us. It's important to a lot of other people. We take the responsibility of building this technology really seriously. But, you know, the stakes when you're an advisor to the president of the United States are higher.

That like many of the decisions that he made, or issues he worked on were literally life and death for other people. And being involved in responding to issues like terrorism and or even, you know, even discussions around economic policy where you're talking about do, you know, where the decisions that are getting made can affect whether tens or hundreds of thousands of people have jobs, whether people lose their homes and have health care. and all those sorts of things, right? Being around people who deal with those issues every day,

it makes the problems of a startup founders seem mild by comparison. I often tell people that that job completely recalibrated my sense of stress. So, you know, this seems like a breeze by comparison. I'm happy to hear that. I will try that in my next life. So let's talk about how you guys settled on using, Ethereum as a base layer. Yeah.

Yeah. So, you know, we knew we wanted to use, we wanted to pick a base layer. And Ethereum seemed like, so, and of course, this is one of the steps from being an academic prototype where you say, hey, look, this is a super general thing. It can run on top of any base layer that has, you know, basic smart contract functionality. But if it's going to be a product, it's got to run on an actual thing. And so Ethereum seemed like the obvious choice for a bunch of reasons. First of all, it had and still has the most developers and the most users and so on of smart contract-based technology.

We really liked the Ethereum community and sort of the way that it's governed and the openness of it. And we really liked it as a community. And we felt like it was a place where we could be comfortable where this sort of experience we were trying to build would be consistent with what the Ethereum community was going to do. And we've always from the beginning seen what we're doing as not as sort of as a compliment to Ethereum to try to make Ethereum better. So it seemed really obvious from the beginning the Ethereum was where we wanted to be that we had to focus on something and pretty much. much every criterion Ethereum looked like the best place to be. We also thought, you know, just from a pure sort of, in terms of like the need for what we were doing, that Ethereum was going to be the system that hit congestion and an increase in transaction

fees first, partly because of, you know, technical attributes of Ethereum, but also because just there were so many people there. And the community was growing in such a nice way. Cool. Yeah, that makes a lot of sense. But let's talk a little bit about roll-ups, because I think roll-ups is something that, you know, most listeners will, like, have some kind of awareness of, you know, they've heard of it, but at the same time, probably don't quite understand it. So can you explain what are roll-ups? Sure. Yeah. So a roll-up is a chain that operates as an independent chain, but that has its security anchored in an existing big chain, in our case, Ethereum. And so the key idea is that we keep the data, this sort of input data of the transactions. What are the transactions that users submit? And those get recorded on the Ethereum chain. But we move the computation and the storage, basically the heavy lifting of operating the chain off onto a separate place, onto the separate Arbitrum chain that has its own nodes and its own systems participating in it. But the key thing that makes roll-ups, I think, really nice, is that they, at least ones like ours, is that they can,

operate trustlessly, meaning that all the data that you need in order to be a first-class actor in the system in order to know exactly what the chain has done and participate fully in the protocol, that's all recorded on the Ethereum chain. And then the settlement of transactions that happen on the roll-up, those are also somehow settled back to the L-1 chain so that the Ethereum chain knows what is the state. root of our layer two chain. So what that means is you get better performance and lower cost because we move a lot of the stuff off the Ethereum chain where gas and transactions are pretty expensive because there's a lot of demand. But we still can anchor the security of the roll-up chain in Ethereum. So if you trust Ethereum and you believe at least one member of our community is honest, then you can trust our chain as well. So that's sort of the value proposition. not only of arbitram, but of roll-ups generally.

You can inherit the security of the layer one Ethereum chain, but at the same time, you can move most of the work off of it. And so transactions are a lot cheaper, and you can have more capacity. So just to kind of clarify this, so let's say today I'm sending a transaction on Ethereum, you know, I just send it on Ethereum. We can check on EtherScan. Okay, that's what my transaction. But in this case, I would send a transaction, you know, to a bunch of arbitrium nodes.

Well, to one, yeah, to one arbitram node. Yeah. So let me talk about the user experience of this, right? So if you're using Ethereum, right? Like you said, you're maybe using a wallet. And your wallet has the address of some nodes, a URL of some node in it. So that when you approve a transaction, your wallet puts your signature or your address's signature on it. your wallet will send that to an Ethereum node, right?

And then the Ethereum magic happens, and sometime later you get back or you see the result of your transaction. If you're using Arbitrum, it's basically the same user experience in a sense. You can use the same wallet. And instead of putting the address of an Ethereum node, instead of your wallet having the address of an Ethereum node and sending the transaction to the Ethereum node, your wallet has the address of an Ethereum node, your wallet has the address of an Arbitrum node, and it sends the transaction to the Arbitrum node. So we've done the work to make Arbitrum compatible with Ethereum so that the same transactions will run on it. You send literally the same bits that your wallet would have sent to the Ethereum node.

It can send to the Arbitrum node. And someone who's developing a smart contract to run on Arbitrum, they'll send literally the same bits that they would send to an Ethereum node in order to, deploy the contract. So you achieve a level of compatibility in the user experience. What happens after your transaction gets to that node is a bit different. And I can walk through kind of what are the steps if you like. But in terms of user experience or developer experience, it's designed to feel just like using Ethereum, except that transaction fees are lower and response time is shorter. So let me walk through what actually happens with your transaction. There's kind of a front end and a back end of a system like Arbitrum. There's sort of two phases. The first one is sequencing, and that's all about the system receiving your transaction, putting all the transactions into order, one in front of the other,

and then recording those ordered transactions. And then there's the second phase, which is the execution and settlement phase, which is the phase that figures out what is the result of executing those transactions in the sequence that came out of the first phase. But let's talk about a typical transaction. So user makes a transaction using some user interface on their wallet. Eventually they click that button on their wallet

that says to send the transaction, right? So that puts their digital signature on the transaction. The transaction gets sent to an arbitram node. the Arbitrum node will forward that transaction automatically to the Arbitrum Sequencer, which is a component that's receiving transactions from all over the place. And the sequencer emits an ordered sequence of transactions. So it publishes a feed of a real-time feed of transactions. And so the node that you sent your transaction to might be subscribed to that feed.

So the node will see your transaction in the feed. see what the result is and send that back to you immediately. It's usually around one second. And users love this, this part of the system, right? So then the sequence of the Arbitrum Sequencer will later take your transaction and a bunch of transactions that came in around the same time and put them all into a batch, which is just like a bunch of the data of all the different transactions packed one after the other. It will compress that batch using a common compression algorithm, and it will take that compressed batch and post it on the Ethereum chain as Ethereum call data.

And the reason that's important is that that data is that what the transactions were and what order the sequencer put them into is like fully recorded and notarized on the Ethereum chain. everyone has access to it. And there's no dispute about possible about what the transactions were or in what order. Tell us about the sequencer. Sure. So, yeah, so the sequencer right now is a centralized component that we, the arbitram team, run. And the sequencer follows a first come, first serve policy for putting the transactions into order. That is, first transaction to arrive. whichever transaction arrives earlier, gets to be earlier in the ordering. And And so currently it's the sequencer is trusted to establish an order on the transactions, but it's not trusted for any other purpose.

In particular, the sequencer can't create transactions out of nothing because transactions have to be signed by the user, right? And the sequencer can't forge those digital signatures. The sequencer could try to throw some transactions away, but there's an, there's an anti-censorship mechanism that people can use to force their transactions. into the sequence, even if the sequencer isn't cooperating. The sequencer currently is a centralized component. And we've, you know, it's in our roadmap to decentralize the sequencer so that you have a

committee of sequencers. And as long as a majority of those are honest, then you get a fair sequence. Yes, this is one question I have on this is. So the transaction information, right, it gets put into, I guess, each Ethereum, or it gets put into the Ethereum chain, you know, on some regularity. But as an Arbitrum user, does that mean I also have to sort of, you know, like the confirmation or like the finality of my transaction is like when it gets recorded on Ethereum or can I rely on it before that?

Yeah. So that you get definite finality when your transaction is recorded on Ethereum. And so the main time factor there is just the Ethereum finality time. So if you're going to wait for, say, 20 Ethereum blocks for finality, you know, that's about five minutes. So the sequencer also publishes this real-time feed of transactions. And that's the sequencer's promise that it will record the transactions in that order. And so if you trust that promise, then you can use the result. then you can use the sequencer's real-time feed to know what the result of your

transaction, what the ordering of transactions will be. And your transaction will show up in that feed in about a second. So most, in practice, most applications choose to have their UI rely on that sequencer feed. But you are trusting the sequencer's promise of order. But again, it's only ordering. It's not what the transactions are. that you'd be trusting there. So that's your choice, basically.

You can get one second soft finality, which means finality, unless the sequencer is lying to you. Sequencer is making you a promise to record the data in that order, and the sequencer always has the power to keep that promise. But fundamentally, you're relying on it to keep the promise if you're relying on that fee. Or you can wait until the transaction sequence is recorded on the Ethereum chain, and that is going to take as long as Ethereum finality does.

So the sequencer then sends the compressed data to the Ethereum main chain. So, I mean, it has to pay gas for that. And basically, there's no way of forcing validators or miners to include a transaction, right? So how do you guys make sure that you can definitely have that call data on every Ethereum block? Yeah. So the first, so this gets to what happens in the second sort of the back end phase or the execution phase of the protocol. And there's kind of two ways of thinking about this. But the key idea in the sort of the execution phase is that you have this sequence of transactions and everybody knows and agrees on what the sequence is because it's recorded on Ethereum. Right. Now, given that sequence of transactions, There's something called the state transition function.

The state transition function is a deterministic function, which takes the next transaction and the current state of the chain and produces some changes to the state of the chain, possibly, and then also possibly emits a block on the arbitram chain. So that's a fully deterministic function. And what that means is the result of it depends only on the current state and the next transaction. And of course, the current state only depends on the Genesis state and all of the transactions in between, right?

So the current state in any time is fully determinable from the sequence of transactions that have been recorded. And that's actually really important. One of the things that makes this a roll-up is that anybody can start with the Genesis state of the Arbitrum chain and replay all of the transactions just by themselves without needing to sink to anything and then know what the current state is. But also, if you're in real time, if you're a node and you're just watching to see which transactions arrive in the sequence, you can execute that state transition function yourself without needing to synchronize or get to consensus with anybody. And you can know what the correct result of executing that sequence of transactions is. And there is a single correct result because the state transition function is fully deterministic. So most of the time, what nodes do is they watch the sequence, and then they execute the state transition function themselves privately. And any honest party can do that by executing the protocol, and you could do that using software that we'll give to you for free, and you can look at the source code for and so on.

So that's how all honest parties can know what the result of executing the chain is. And that's sort of the common case of what happens. But at this point, every honest party in the universe in principle knows what the correct outcome of the chain is, except the Ethereum chain doesn't know. And the reason the Ethereum chain doesn't know is it doesn't have enough gas to execute all of the Arbitrum transactions. The whole point of something like Arbitrum is to be able to do more work than Ethereum can do. And sort of, you know, by definition follows from that that Ethereum can't emulate the full execution of the Arbitrum chain. So we have this other piece we call the roll-up protocol, which is how participants in the protocol can cooperatively convince or prove to the Ethereum chain what the result of executing these transaction is. In other words, like what is the block header hash of the next block of the arbitrum chain?

So we have the settlement protocol which does that. So does that sort of make sense? There's like two aspects of this. If you're an honest party, you can just watch the sequence and execute everything for yourself and you know what the unique correct answer is. But also on the side, there's this protocol going on to. convince the Ethereum chain what the result is. And that's necessary for things like bridging,

or if some party wants to be able to, wants to know the result without needing to emulate everything themselves. Right? You can go to the Ethereum chain and say, look, the Ethereum chain has confirmed or sort of notarized a particular block header hash for the Arbitrum chain, and so you know that that's good. And how do you make sure that the block header

hash is included in each Ethereum block. So I mean, basically, you have no control over the miners, right, or the validator. So in principle, they could exclude you. Right. So it's not included in every Ethereum block. It's just included periodically. In practice, it's every few hours. There's a checkpoint of the Arbitron chain will get recorded onto the Ethereum chain. And so you don't need to get it into every block. You just need to sort of get a checkpoint in periodically. Okay, so basically the hard finality is then not a minute, like the soft finality, but a couple of hours until it's included on the main chain. So, but no, actually, so finality, if by finality you mean that every honest party knows and agrees on what the result is, then you have that back in the beginning once your transaction is sequenced. right? Because once your transaction has been sequenced, then the result of your transaction is

deterministically knowable to everyone. That is, every honest party knows what can figure out for themselves what the result of your transaction is. And this sort of final recording of the checkpoint on Ethereum, this is just Ethereum finding out what the correct result is, which everyone else already new. The thing is basically if you say you inherit security from Ethereum, then basically you need to wait until it's been included in the main chain. So there's one more piece that I haven't said yet, which I hope will close this loop. And that is that the piece of the protocol that records these checkpoints back onto Ethereum,

This piece is fully trustless. What that means is any one honest party can force the correct result to be recorded. And so that means that you don't need to rely on anyone else to ensure that your transaction will be recorded back onto the Ethereum chain. You yourself can force that to happen. In fact, any party can force the recording of the correct result. So if you believe that Ethereum, it will operate securely, and if you believe that at least one participant in the Arbitrum Protocol is honest, then you have a guarantee that the correct result and only the correct result will be recorded on Ethereum.

And so you need there to be just one honest party, and that can be you. That's assuming the sequencer has given the honest, has sort of broadcast the honest ordering of transactions. Well, so the sequencer, in effect, the sequencers, the sequencer's ordering is, well, the sequencer's ordering is, by definition, the truth of the order of transactions. In other words, the sequencer decides the order, and then this execution layer determines what is the correct result of executing the transactions in that order. The sequencer doesn't make any claims about the results of execution. those transactions. It just says, here's this set of transactions. You can think of it like an ordered mempool if you're thinking in analogy to Ethereum, right? Ethereum has the mempool, which is all the transactions that have been submitted, but not yet executed. So the Arbitrum Sequencer produces something that's like an ordered mempool. It's a set of transactions

that have been submitted, and they're in some order. And then what the execution phase of the protocol does is it takes those transactions and runs them or tries to run them in order. So the sequencer has established an order. And then the job of the execution and settlement phase is to figure out what is the one correct result of executing those transactions in that order. Yeah. So that makes sense. But of course, you know, you said before, or the sequencer does, you know, sort of first in, you know, orders it by the order received. And of course, that's something they could lie about, no? Yes, that's right.

The sequencer can lie about ordering. We believe that a sequencer that does that regularly would get caught. But over time, you know, as we move to a distributed sequencer, The idea is you have a set of sequencers and you multi-cast your transaction to all of them. And then each of the sequencers publishes its order, which it claims was the order of arrival at it. And then there's a kind of, so then you have like the published sequence of each of the sequencer instances. And then there's a sort of fair merging algorithm which merges those sequences. And it produces a, the fair merge algorithm has this property, which,

which is roughly that if transaction A is ahead of transaction B in a super majority of those sequencer's outputs, then it will be ahead, A will be ahead of B in the merge. So if you believe that a super majority of the sequencer instances are honestly doing first come first served, then the sort of whole distributed sequencer part of the protocol will produce first come first served. And this will actually in effect solve the MEP issue, right? So basically currently in the centralized sequencer, in principle, the sequencer could extract everything

that would on main chain be known as MEP. It could in principle, yeah. I mean, I'll take your word for it that it currently doesn't, but basically if you have that sequencer competition where basically the relative ordering is kind of compared between lots of different sequences, that entire kind of worms is closed, right? That's right. That's exactly right. Both parts of that.

A dishonest sequencer could extract a lot of value, presumably, by reordering or by selling, auctioning off position and so on. It could. We currently run the sequencer, and we do not do that. but long run the solution is to move to a distributed sequencer. And that way, you don't have to trust any one party. It is the case now that the sequence we produce is visible to everyone. And so if we cheated blatantly, it would be evident.

Also, you know, we, the arbitram team, have a real incentive to not make our system terrible in that way by cheating our users. But nonetheless, right, obviously a distributed sequencer is better, and that is where we are headed. I'm curious, since we brought up the topic of MEP, which, you know, I think it's definitely become like a huge topic, right? That, like, lots of people think about, this does sound like pretty elegant, actually. But I'm curious, does that actually, you know, what Federica said, does that fully remove MEP or is there still some degree of MEP there? Well, that's a super deep question. Because it partly depends what you mean by MEV. Right.

Certainly timing matters. And there are circumstances where if Alice can see that the thing happens and get a transaction in reaction to it faster than Bob can, that Alice will be benefited. Right. And so the ability to react to. react quickly to events more quickly than other people and to get a transaction in faster than someone else actually does benefit people. And the thing about it, a first arrival policy is that, you know, someone can't get an advantage by being close in network distance to, to the sequencer. Of course, when you distribute the sequencer, if the instances are all over the world,

you know, that becomes a more complicated game. So there are issues around ordering. The other thing to say about MEV is that there, or the idea of sort of exploiting order for in order to get to make money, there are circumstances where people, where like a regular user can benefit from either reordering or from selling a position in the order. So here's a good example. Suppose that you want to do a trade in an AMM like say uniswap or an equivalent. And your trade is big enough that it would actually move the price in that, you know, in that automated market. So if the price was sort of at the sort of global market equilibrium price and your trade would move the price a little way away from that, there's an arbitrage opportunity that is available to whoever can get a transaction in immediately behind yours. Right. So if you're the person who's going to do this first trade, it sure would be nice.

So you might say, well, great, I'll do the first trade and then I'll exploit that arbitrage opportunity myself and make some profit. The thing is to exploit the arbitrage opportunity. You have to do the opposite of your initial trade. So if you wanted to do the initial trade, you're not going to do that. But there is a profitable opportunity to be right behind you in the sequence. And if you could sell that, then you could actually benefit from it, right? You, the end user. And in fact, the economics of this get a little complicated, but if you do a trade that is big enough to move the market, you've suffered a little bit of loss due to slippage in the jargon. And you can actually regain that by selling the position right behind you in the ordering. So there are cases where, like, clever ordering or bundling of transactions can be beneficial to users and not just a way to sort of a drain value away from users.

And so personally, I'm a believer in opt-in transaction bundling. And I think that's the direction this is going to go in systems that emphasize fairness. That is, you as a user can submit your transaction directly to the sequencer and get first-in, first-out, ordering. Or if you think that there's an, if you think that you might benefit from having your transaction bundled with other people, people's by some party you trust, you could submit your transaction through them, send it to them, and they produce a bundle in and submitting. So this gets kind of complicated. But the bottom line is that there are circumstances where it's beneficial to users to be able to do

bundling of transactions. And if that is purely voluntary, a thing that happens for you because you opt into it, I think that's a good thing. But the idea that someone is sitting there watching your transactions and like reordering it so that they can steal some, you know, some fractional eth from you every time you do a thing. That's really harmful. So, yeah, so, I mean, we've been thinking a lot about how can we minimize MEP and how could we make it so that people who want to opt in to transaction ordering can do it. And we've been trying to build a kind of ecosystem that allows that to happen. But a big part of that is this sort of first in, first out or first come first served approach to sequencing, which we think is really important, an important part of our model and makes it not completely resistant to MEV, but much more resistant than alternatives.

I think that's really commendable. So I think, I mean, in this space, there's this prevalent narrative that MEV is actually good because it secures the network. And I think this is a false narrative. and I don't understand why more people don't call it out because obviously it's the user who pays for it. If you actually do the analysis of how much is spent on MEP, it's around 1% of total transaction volume. So it's huge. It's actually, it's humongous. So basically, if you guys were to where to tweak your sequencer, you could be enormously rich with this.

But, yeah, so it's, I mean, it's a huge, it's a huge market. And I think basically finding, finding ways that are provably fair and that kind of prick to that super important. I feel like I need to do a mini rant here because I think you're exactly right that this like MEV extraction is, it's a tax on users, but it's a tax that's hidden. You don't know how much was extracted from you or when. And I think that's not how fees, that's not how network should fund themselves. If you're going to fund your network, you should do it from fees that are visible to users so users know what they're paying so that it's in that wallet pop-up, that when you do this transaction, this is what you pay for the transaction, that it's visible.

And, you know, I'm a big believer in that the cost of transaction should be visible, they should be fair and they should be related to the cost of operating the network. And I think MEV is none of those things. MEV extraction is not visible. It's not designed with fairness in mind. And there's no reason to believe that it collects the right amount to fund the network, right? The right amount is enough to actually pay for operating the network, but not more. I just think MEV is a really poor way of funding anything.

Yeah. Sorry. And with apologies for that. No, we're totally on the same page here. This is exactly my stance. So, yeah. Let's back up a little bit and talk about the Arbitrum nodes, though. So basically, when I have a have a transaction, I will send it to a node.

Who is that node? What does it do? And how is it incentivized? Sure. The node could be anyone can run a node. You can run a node. You can just download the software and run it. We have some.

So, I mean, the answer of who is the node is it could be anybody. A lot of people will use a service provider. I think it's a lot like Ethereum. You can run a node yourself or you could use a big service provider, a confier or alchemy or any of the companies in that space. It's kind of up to you. In terms of how they get paid, there's different answers to that. If you run the node yourself, you know, you're running it. for your own reasons and you don't have to pay yourself.

If you're using a commercial service that runs nodes, then they're going to have some kind of business model. Maybe they have a free tier and you pay if you use it a lot. Maybe you use a node that's run by an application provider and their business model is they want you to use their application. They have some way of making money from their application and they're going to run a node to make that easier for you. So, I mean, it's essentially the same answer as on a,

Ethereum. There needs to be some reason for a person to run a node, and it might just be self-interest, or it might be part of either, it might be a part of a business model where they're, you know, they want people, they want to see this activity and happen more, and so they want to facilitate it. I know we run, we the arbitram team, we run, we run some nodes, node services ourselves. But if I run an Ethereum node, I make money off of it, right? Yeah, if you're mining, you do. Although it's not a great business to be in if you just have a regular computer, right? You can buy a mining rig and then maybe the economics of that work out.

Totally. But if I'm a staker, for instance, on East two. Yeah, you do make some money. And we don't have an incentive program for nodes. We found that we don't really need it as of yet. So the other thing to say is there are different, just like in Ethereum, there are different roles that a node can play. It can be a regular node, which is mostly servicing user requests, keeping track of the state. It could be what's called a validator, which means that it

participates in the protocol, the settlement protocol to settle the results of transactions to Ethereum, or it could play a special role like the sequencer. There's only one of those, and someday there'll be a limited committee of them someday. But most nodes are just like non, are like non-staking nodes in Ethereum. Okay. And the staking nodes? What about those? So the staking nodes currently, right, again, anyone can, let's see.

So the protocol allows anyone to run it. We currently have a limited list of parties who are doing it. But the direction we're going is toward a model where anyone can run a validator. and there are some parties who are invited to run a validator, and they are compensated for that with some funds that come from the user fees, from the transaction fees. Because it's trustless, and anyone can run a validator, we actually don't know who, in general,

you don't know and can't know who's running validators, and that's actually a feature that if you put your, in the shoes of a person who's thinking of cheating, and they're going to ask, they're asking, is there a validator who's going to call me out and, and take my stake? The fact that you can't know who might be running a validator is actually pretty valuable.

The sort of submarine validators are an important aspect of the security model. So what happens to the transaction fees that users pay? Because basically, sending transactions on arbitrariness. I mean, it's substantially cheaper than on main net, but it's not free. It's like on the order of like a dollar per transaction or so. Yeah. So the short answer is it goes to pay the costs of operating the chain.

But let me give you the long answer, which explains what those are. The biggest cost of operating the chain is recording that sequence of transactions on the Ethereum chain. It's Ethereum gas, right? And so the sequencer pays the biggest source of cost is the L1 gas that the sequencer has to pay to record the biggest part of the fees that you pay actually go to the sequencer to reimburse it for those costs. Other fees go to cover other parties' costs. And so basically that money all goes to pay for the sequencers' costs, it goes to validators, and it goes to sort of a core set of notes.

And over time, we're moving toward more transparency in where those fees go. The algorithm for determining the fees is, you know, we're fully transparent about what that is, and we've talked about why the fees are set the way they are. But basically, the short version of that is the fees, part of the fees go to reimbursing the sequencer for L1 gas costs. And the rest is L2 gas, which goes, which is paying for the sort of the core nodes and, and some validators. So if you think of like the transaction fees that users pay in arbitram, will these kind of be proportionate? to, you know, roughly the Ethereum transaction fees that, you know, like, you know, some kind of percentage. Well, roughly speaking, yes, that the component of transaction fees that is covering L1 gas, you know, how much you have to pay for the L1 cost of your transaction, that is going to depend on what is the L1 base fee, right?

If the L1 base fee goes up, then the sequencer has to pay more to record your transaction, and you're going to end up, you or other L2 transactions are going to end up paying for that. So because that's the biggest component in practice, when the Ethereum gas price base fee goes up, the cost of arbitram transactions goes up as well. It lags a little bit for some technical reasons. It takes a little while for the arbitram mechanism to adjust. but fundamentally the arbitram costs follow the Ethereum gas costs. And essentially, it's the cost of recording data.

Now, Ethereum is moving toward changing its data model in ways that reduce the cost of the kind of data that roll-ups need. And so this so-called, this is the dunk-sharding or proto-dunk-sharding stuff that people talk about in Ethereum research circles. And once that gets deployed on Ethereum, then the cost of recording roll-up data on Ethereum will get much lower, we think, and therefore that the cost of arbitram transactions and transactions on other roll-ups, too, will go down a lot. But that's basically right. The first approximation, most of your transaction fee goes to paying to record your transactions data on the L1 chain.

You said earlier that basically I can force a settlement. on L1 as a participant in L2. Is there any way I can actually grieve the synthesizer by forcing it to settle much more often than it usually would and thus driving up the fees? So if you can post more checkpoints as a validator, but that's only going to cost you. That's only going to cost you money

because as a validator, if you're getting paid as a validator, you're getting paid per time, not paid per post. So that's only going to raise your own costs. And if the checkpoints that you publish are honest, then it doesn't require anyone else to respond on chain. This is the optimistic part of Arbitrim is an optimistic roll-up, and the optimistic part is the idea that if somebody posts a correct, checkpoint that everyone else just does nothing. And the system after, then there's a challenge window, a window of time in which after someone posts a claim about what the checkpoint should be, there's a window of time in which anyone else can object, right?

The person who posted the initial claim is staked on that claim, and they will lose that stake if they're lying. But basically, there's a window of time in which anyone else can object to it. And if no one objects after that window of time challenge window has passed, then the system will accept it. And that's obviously the common case because as a validator, your incentive is to not post a false checkpoint. If you do, you're going to lose your stake. And so your incentive is to post a correct checkpoint. And then everyone else's incentive is to look at that checkpoint, say, yeah, it's correct.

I'm going to just wait until for the system to accept it. And then the system will accept it. That's sort of the common case. But if someone posts a false checkpoint, then you can come in and say, no, that's wrong. Here's the right result. And you can stake on that. And then there's going to be a challenge protocol that happens between the false staker and you, the honest staker.

You will win that challenge because an honest party can't always win the challenge protocol. That's sort of a guarantee of the protocol. And then you'll take half the stake of the loser and the other half gets burned. So you as an honest party can post a correct checkpoint. You can do that whether or not anyone else posts an incorrect one. And if anyone disagrees with you, assuming you're behaving honestly, you will defeat them and take their stake. Okay, fair enough.

But how as an honest validator am I incentivized to post a checkpoint? Do I get extra credits for that? Because I incur the gas fees, right? That's right. That's right. So whoever does that incurred a gas fee. And we don't currently have a mechanism to reimburse that gas fee. Currently, we post, our team post correct checkpoints ourselves and we just eat the cost of doing that. But if we don't, then someone else can do it and they would have to absorb the cost themselves of posting the checkpoint. The checkpoint gets posted every few hours. So it's not a large cost. It's a, it's a, it's a, medium-sized Ethereum transaction every few hours. The biggest cost of L1 gas cost of the system by far is the data recording that the sequencer does, and it does get reimbursed by fees. We will probably eventually move to a scheme where the system reimburses the gas costs

of someone who posts a checkpoint as long as they don't post it too often. you started talking about the optimistic part of the roll-up. So kind of putting this into the larger context. So we've actually had several other guests on before to talk about roll-ups. So basically we've spoken with Alec Lek Lukowski from CK. Sink and Eli Benson. And we've also had the optimism team on. So I understand the fundamental difference between ZK roll-ups. So basically, you post a fundamental proof and basically that proof is final. You get

innocent finality. It only doesn't work for all kinds of transactions, but whatever. And then you have the optimistic roll-up. So how is Arbitram designed differently from how optimism works? So there's a bunch of differences. One of the biggest differences with optimism, in particular is that Arbitrum has a fully working and integrated fraud-proof system. That is. And we've had that since the beginning, right? So we actually have the fraud-proof system in existence and turned on, and it's integrated with the rest of the system. So that's a pretty significant difference. You know, it's not something that we say we're going to integrate in the future. In fact, we're proud of this.

we are the only EVM-compatible roll-up system on Ethereum that actually has its security-proof mechanism turned on and working. This is one of the harder parts of not only just building a fraud-proof

or correctness-proof mechanism, but actually getting a complete protocol that includes it is pretty hard to do. And that's a reason why a lot of projects either haven't done it or are just promising it for the future. But we're proud of having every version of Arbitrum has had fully working and integrated fraud proofs. I think that's a significant difference.

You can talk about differences in design. For a long time, the biggest design difference between Arbitram and optimism was that we used interactive fraud proofs, and they used a non-interactive fraud proof mechanism. That is, they had it. It was an optimistic system, but if there was a dispute between parties, we would resolve it in different ways. But about six months ago, maybe a bit more optimism pivoted

and started using or said they would use interactive fraud proofs, which is the arbitram approach. I mean, I think there's some technical differences between how the system work. One of them is the first come, first served sequencing system, which we talked about a bunch before.

That's a thing that, Arbitrum does, and optimism has a different approach that involves auctioning off the right to reorder transactions. But probably the system that is closest in design to arbitram among the ones that are out there is optimism. And of course, other systems that, the other systems that you mentioned use ZK technology, which is a very different type of thing. And there the main difference is between optimistic and ZK is, in my mind, is cost. Optimistic systems are much cheaper by orders of magnitude to produce the proof. And the reason is that the whole part of the protocol where you generate a very complicated cryptographic proof. And the ZK folks always talk about how cheap it is to verify the proof, but producing a ZK proof is extremely expensive.

And an optimistic system, you don't have to do that. Even in the worst case, the optimistic system, the cost of proving is much, much lower. You could do proving on an ordinary machine for an optimistic system in the case of a dispute. But because of the optimistic nature of it, if there's not a dispute, you don't have to produce a proof at all. And that, of course, is the common case, and it's vastly cheaper. Cool. Thanks. That's very helpful. I wanted to kind of come back to the topic that we touched on a little bit before, which is sort of the topic of like economics of it.

So we, you know, we talked about that, you know, there's this fee, and most of the fee goes towards paying the L1 gas. But of course, there's also, you know, some additional fee, right? That's there. And so I'd love to maybe if you could speak a little bit about that. And then I'm also curious, for example, optimism, right? They launched an optimism token. I'm curious also if you have plans for, I don't know, arbitrium token or like, how do you see sort of the economic system evolve in the longer run?

Sure. Yeah, let me talk about the fees. You know, as I said before, the biggest component of fees is L1 cost. There is L2 gas. There has to be gas, right? Because you need the economic, you need to align incentives for users. because when a user submits a transaction, they are imposing cost on other parties.

And they're using a resource that's limited, namely the throughput of the chain. So you need to have some kind of gas or charging in order to align those incentives and in order to keep users from just spamming the chain with junk transactions. And so Arbitrum does that in a way that's pretty similar to Ethereum. We count gas and the gas,

S fee is normally low, it will go up if the chain is busy, it's congested. That is if people, if the transactions that are arriving are more than the chain's capacity, then just like Ethereum, we have this automatic mechanism that raises the base fee so that you get essentially use that price mechanism to ration the limited resource. but most of the time you're running at sort of the minimum base fee. So that's kind of how those fees are charged. And we believe in a scheme where the fees should correspond to the cost of operating the system. And that that's where that should go.

In terms of a token, we have not launched a token. We have not felt the need to do it. All the growth that we've gotten has been organic. We haven't paid anyone to use the system. We haven't done tokenomic stuff to try to get people to use the system. We've really focused on building a system that meets the needs of users and developers. The one thing we've said for sure is that if we do ever introduce a token, it's not going to be something that generates friction for users. It's not going to be something that every user of the system has to have or use or own.

We're not going to charge fees in an arbitram token. We think that, you know, there's huge advantages, both in compatibility and just practically for user experience to have the native token of our chain be ETH and to have fees charged in ETH. You know, we haven't found, we haven't seen the need to introduce a token. You know, we are thinking about decentralization and how governance could work going forward and what are the options there. But yeah, it's not, it's not a decision we've, you know, we've made to do. Because right now those fees basically go to like off-chain labs and then off-chain labs pays like the different parties. Yeah. Yeah. Right. Well, so the sequencer fees go directly to the sequencer's account. And then the rest, right, we distribute to those who are, who are involved in.

running in running the network. Yeah, over time, you know, we're moving toward more transparency about that as we, you know, as we line up, say, a suite of paid validators. And we're thinking through how to, what's the best way to have our community participate in this sort of decision making? And that's definitely the, you know, the endpoint that we're aiming for is community participation in this. And we need to have, there needs to be an economic model that's sustainable that covers the costs and so on. But, you know, we want the community to feel like they have a role in talking through these issues and getting to us in getting to an outcome that meets their needs. Okay.

So let's talk about the larger ecosystem and bridges. So obviously you didn't design arbitram as a standalone system. but it kind of works in conjunction with Ethereum. And there are also bridges between Arbitrum and Ethereum to kind of bridge assets. Also, I mean, basically there are no native assets that live on Arbitrum, right? So basically everything's bridged, I assume. Ah, there are some actually. Yeah, so there are some assets that were built natively on Arbitrum.

There's some applications that are Arbitrum native that have chosen to mint their project's tokens on Arbitrum. So there are some of those. But most of the value on Arbitrum has been bridged over from Ethereum. And how does, so basically you guys build and operate a bridge? How does that bridge work? And how do you envisage the bridge landscape in the future? Yeah.

So we have a basic bridge that can bridge ETH and ERC20s back and forth. And to bridge from L1 to L2, it's a, I think, a pretty typical kind of architecture. So you make a call to a contract on L1. So if you're, say you're depositing ETH, I'll tell the story in terms of ETH, but it works pretty similarly if you're using a token. So you make a call to a bridging contract on L1, and you pay those ETH to that L1 contract.

It will hold those ETH. It will lock them up. And your call to do that transfer, you said what address on the L2 chain you wanted those ETH given to, usually your own address, right? So when that bridge contract receives those ETH, it will lock them up and then it will send a trusted message up to L2, which causes the same number of ETH to be minted up on the L2 chain by the Arbitrum Code and then deposited into the account that you asked it to go into. And then in the reverse direction, it's kind of a similar thing.

There is you make a call to a trusted pre-compile contract on the L2 arbitram chain saying that you want to transfer ETH that you own on the arbitram chain down to some address on L1. And that will cause a trusted message to get sent from the arbitram code on the arbitram chain to a contract on L1, which will cause those ETH that you deposited back at the beginning of my story to get unlocked and pay. out. So basically you lock the assets on L1, they get passed up to L2 and get minted up there, and then you can do the reverse operation as well. And we provide a bridge that does that. One of the things that's important, for ETH, the story is relatively simple. For EARC20s, you need to be a little bit careful to make sure that people don't, that each token address on L1 corresponds to a single token address on the layer two chain. And so, you know, we have some functionality that

lets people do that. But basically, we provide a basic bridge, and then other people can provide more advanced bridging services on top of that. And so we see, for example, one of the issues with an optimistic roll-up is that withdrawing assets from layer two back to layer one has a delay. And that's because of that challenge period that I talked about before in the protocol, which in practice is seven days. And so if you don't want to wait seven days for your assets to get from the Arbitrum chain back onto Ethereum, then there's a number of different fast-fraged services that you can use that will basically you can give them assets on the Layer 2 chain and they will right away emit those assets

back to you on the Layer 1 chain. Right. And so these third-party bridging services provide a bunch of value that people like, but they're kind of built on top of the basic bridge. bridge that we provide, which is the basic way that assets can be moved back and forth. In a way, the service that they're providing is a liquidity provision service and not a bridging service, right? Not so much bridging, yeah, but there are also people who build bridges between Arbitrum and other Layer 2 chains or between Arbitrum and other L1s besides Ethereum. What we provide in our basic bridge is just a bridge between Ethereum and the Arbitrum chain.

And then other people can build other things around it on top of that. And there's a lot of value for users in those sort of third-party bridgings and liquidity services. Yeah, absolutely. So I have an hour worth of questions about bridges at least. Unfortunately, we don't have an hour. So basically, I will kind of cut this down to one question. So in the future, how do you think about different scaling? solutions coexisting. Do you think that, I mean, will there be roll up to roll up bridges?

I mean, how do you see that working? Yeah, I think there will be. So, you know, there's a huge demand for scaling and we expect a large number of people to come into the space and some, you know, Web 2 companies and others to come in and bring a lot of demand. And, as much as we and everyone and a lot of other teams are doing to try to scale up what you can do on one chain, the demand is going to be more than that. And so we're going to see, I think, multiple chains that are coexisting. And some of them will be from the same technology, from the same provider, and some maybe different technologies from different providers. But anyway, there's going to be a need to bridge.

And so I think we're going to see more sophisticated bridging systems and more sophisticated thinking about bridge. I know that in our research team, we're thinking a lot about the multi-chain future and how bridging can work and what is the optimal way to do it without sacrificing security and so on. I think we're going to see a lot of innovation sort of at the protocol level in designing better bridging protocols. And that's going to provide a ton of value because I do think we're headed for a multi-chain, a future of multiple chains and not just like a single chain that wins. Cool. Well, I mean, we've covered a lot about arbitram, right? A lot of different aspects. I'm curious, maybe sort of as a final thing, can you talk a little bit about, you know, what are the biggest things that are left to do? What does the arbitram roadmap look like? So we have a few things that are coming up soon. The first one is our Nitro upgrade. So this is kind of a rewrite of our entire software stack, which is, which is going to lower costs and increase scalability by a large factor, and it's better in a bunch of ways.

And that's currently on TestNet, but we'll be migrating our Arbitrum 1, our sort of main chain over onto it, is a sort of seamless migration. And that's coming up pretty soon. We're not talking dates yet, but it won't be too long. After that, we're going to roll out another technology, which we call arbitram any trust, which is a way if you're willing to make a mild trust assumption in addition to trusting Ethereum,

in particular if you're willing to trust the two out of end members of a data availability committee are honest, then we can provide you with considerably lower cost by moving the recording of transaction data off of the Ethereum chain and onto a sort of replicated committee of data availability service. That's Arbitram Any Trust, and we're going to be rolling that out as well. Those two things are on our shorter-term roadmap. After that, it's really about driving scalability.

We have a bunch of cool things in the pipeline, which are going to drive scalability up further on a single chain. We're thinking a lot about cross-chain bridging, and we're thinking about, you know, ways of supporting a multi-chain world because we think the demand is going to be there. And I think there's going to be a lot of innovation in that area. That's kind of where we're headed. It's mostly about driving scale up and driving costs down. You know, I'm fundamentally a tech.

I'm fundamentally a tech person. Not everyone in our team is. You know, to be successful in the space, you need a lot of different, a lot of different, a lot of different, types of skill and activity. But for me, it's all about sort of driving the fundamentals of our technology forward. And that's really what I'm going to continue to be focused on. We have some really interesting things in the pipeline. Right now, we're heads down getting Nitro and any trust delivered.

And after that, I think it's an open field. We're going to do a lot. And I think we can drive cost down a lot and scalability up a lot. Perfect. Sounds exciting, Ed. where can people go to find out more about Arbitrum? Well, you can go to arbitram.io and to get information, if you're a developer,

it's developer.arbitrum.io. If you want to, you could look at the block explorer. Our block explorer, if you want to see what's happening on our main chain, it's Arbiscan.io. That's like the marriage of Arbitrum and EtherScan. It's the EtherScan's teams, a block explorer built by the EtherScan team that lets you follow Arbitrum.

You can follow us on Twitter at Arbitrum or Offchain Labs. Or if you're interested in the Nitro technology, you can probably just Google Arbitrum Nitro and get a bunch of information about that, including information on how to get on the test chain. That is our roll-up tech of the future and a roll-up tech of the near future. So, yeah, that's all available.

If you're interested in following me, I'm Ed Felton, F-E-L-T-E-N, on Twitter or, you know, you can find me online. Fantastic. Thank you, Ed. It's been an absolute pleasure to have you on. I learned a lot. Thanks a lot for having me. This has been fun.

Thank you so much. And thanks so much for our listeners as well, and we look forward to being back next week. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released.

If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.