It was a great honor to have Harry Kalodner, Co-founder & CTO of Arbitrum as our speaker to address the Scaling Summit on Solve Scaling without Compromise!
Overview
As Optimistic rollup scaling solution for Ethereum, Arbitrum is viewed to be one of the most promising ones. As our remarkable cohost, Harry was going to present a keynote on Solve Scaling without Compromise to showcase why Arbitrum is so awesome! We have attached the youtube video link and the whole transcription down below to make sure you get each and every point of view! Let’s dive right into this!
Hi, there, my name is Harry Kalodner. I’m co-founder and CTO of Offchain Labs, and I’m very excited to be here today to talk to you about Arbitrum rollup. Our optimistic rollup scaling solution for Ethereum that supports arbitrary solidity smart contracts being run in L2 today.
Before talking about Arbitrum, I just want to tell you a little bit about founding team behind it. Arbitrum was originally thought of. We were all at Princeton University and Ed working as a professor and Steven and I as PhD students. It was developed as a research paper, which we published together before deciding that Arbitrum itself needed to be built as a functioning product and going on to found the company, which we’ve all been working at full time for quite a while now.
Now, I just want to tell you a bit about why I think Arbitrum is awesome and why you should too. Arbitrum provides a number of properties that I think are really key to advancing the mainstream adoption of Ethereum as a secure, decentralized and efficient solution for deploying smart contracts. Arbitrum allows transactions to be much cheaper than Ethereum, while still achieving a high level of trustlessness. With security rooted in Ethereum. And with this, we also support drop in compatibility with Ethereum, which means that existing Ethereum tooling and smart contracts and all of the great work that’s been done to make Ethereum a great place to develop and use applications applies just as well right out of the box on Arbitrum.
This combination of factors means that existing Ethereum users and use cases have a great path to migrating to Arbitrum and lowering costs while keeping all the things that make Ethereum great. Arbitrum isn’t just an idea, it’s a launched product. We launched our mainnet beta back in August and ever since we have seen a large number of Dapps that you know and love from Ethereum deploying on Arbitrum, a large amount of value has already migrated and many, many transactions have occurred from a large number of users. This is something that we’re really excited about because above all else, what matters is having a practical solution to scaling that really works effectively for people. This isn’t just one Dapp. There are a whole variety of Dapps already deployed on Arbitrum and here, for example, a variety of DeFi markets all accruing value, all usable today and giving you a really wide experience.
Since it’s our belief that essentially the value of blockchain comes from a large number of interacting parts, and that’s something that’s really important to us and works great on Arbitrum with the open contract deployment. So now that I’ve told you about why you should care about Arbitrum and why it’s important, I want to really dig into the technology and how it works, because I think this is by far the most interesting part of the story.
Now I’m going to start by giving you a very broad idea of the system, and then I’m going to dig into a lot of interesting details about how we actually accomplish this.
There are a few main ideas I want to start with. One is the inbox, and this is basically just the list of transactions that were processed by the system. A lot like blocks themselves in Ethereum. Then there’s the chain state, and this is the current state of the chain, which is just derived from the transactions in the inbox that we process these transactions and we have a state. And then finally, there are set of outputs and this is kind of externally observable actions. And once again, I’ll dig in a little more into what that means, but you can think about this, for example, as withdrawals from Arbitrum back to Ethereum. Now that leaves a lot of questions. What is this inbox, who tracks it and what is the chain state as well? Where do these things exist? How do we know they’re correct? If I just kind of make some claims, how do you know if it’s true or not? How do users interact with the system? It’s through the inbox. But what does that mean and how does the system interoperate with Ethereum? I’ve described the system relatively one off, but how is it actually rooted and connected to Ethereum that it draws its security from? So I can give you quick answers to a lot of that.
Then the kind of details will come out through the rest of this presentation. So first of all, the inbox, all transaction data is posted on Ethereum, and since the complete state of the rollup is just derived from the transactions that are included in the chain. That means all of the data necessary to know what the state of the rollup is shows up on a Ethereum. And that’s really kind of one key component to being able to actually get our security fully from Ethereum. The state, though, which involves the execution and storage based on those transactions happens completely offchain. That’s done by nodes that are running against Arbitrum rather than actually showing up to Ethereum nodes at all. And then we have this execution, and I’m telling you we’re executing it off chain. So then how do you actually prove that this is correct and proving that it’s correct is critical for being able to trust the bridge?
The answer to that is as an optimistic rollup. Arbitrum rollup uses fraud proofs, which means that validators make claims about the correct state of the chain, which are then challengeable on Ethereum, Arbitrum specifically uses interactive fraud proofs, which means that there are multiple steps of back and forth between a validator and someone challenging the correctness of what they posted that are used to derive whether or not the original thing that they posted was correct or not.
All of this system is rooted in Ethereum, as I said a second ago, the inbox is on Ethereum. The entire system for mediating and resolving these fraud proofs is on Ethereum, which means all of it can achieve an Ethereum level of security.
So how does this protocol work that allows us to prove back to Ethereum that some execution occurred in L2? Well, the general idea is that there’s a chain of assertions about what the L2 state is. At one point when a new assertion is posted, it essentially says, Hey, well, the previous assertion was correct. If you executed even further, then the new state would be this. Now, if Alice has posted something like that, Bob can either agree with it, in which case he just builds on top of Alice’s assertion or just watches her make new ones. Or he can disagree, in which case he posts a conflicting assertion. And then the question is how do we actually settle the conflict between Alice and Bob? So now that we have this idea of Alice and Bob able to make claims about the chain state and we need to have some way of resolving these claims, we can talk in a little more detail about how that process works. First of all, all inputs involved in this process are posted directly to Ethereum. Now, these claims just come in the form of hashes.
So this is a very small amount of data that gets posted in order to represent the entirety of the Arbitrum chain state. Now, when these claims get posted, the validator is posting them also put down bonds, which means that they have money on the line that they’ll lose if those claims are wrong, which is important to provide proper incentives in the system. Now, if a wrong claim is posted, anyone in the world is able to put down their own bond and their own claim, that runs contrary to the posted one. In order to challenge it, which means that anyone in the world can force the correctness of the rollup chain, which is how we get such a strong security guarantee.
Now, once a challenge exists, the question is, how do we resolve it? After this, I’m going to talk to you more about how this interactive process works, where Alice and Bob go back and forth, and eventually it gets decided that one or the other of them was lying. The important component here is that we narrow down the challenge over a number of rounds until we finally reach a very small component of the original claim that was challenged. With that, we use what we call a one step proof where we actually evaluate that on Ethereum. In order to that, Ethereum should know definitively who was right and who was wrong. Now I want to really dig into the details of what this interactive challenge looks like.
I’m showing you here an image that kind of gives you the general idea of how this challenge works. So when we originally posted this claim, it’s over a whole bunch of execution. So let’s imagine I’m making the claim that if I execute the next thousand blocks, the new state will be something. So you can check off chain. You can check yourself if this is correct, but there’s no way we can actually prove this on Ethereum. This is a very large amount of computation. So what we instead do is we give an intermediate point. So we say, for example, well, how about after 500 blocks? What was the chain state then? In that case, the original claimant, the original person who made the claim, provides a midpoint. So then what we have is essentially two smaller claims that, when combined, are equivalent to the larger claim. And with this, we’ve narrowed down the dispute in half. And so you can probably see where we’re going here. We repeat this process of providing mid points over and over again until we reach this minimal component that can’t be split, and that’s where the one step proof comes in.
This is kind of from the very initial challenge all the way down to settling, settling it, how we resolve these disputes now in practice, the system is a fair amount more complicated than this. We do a lot in order to resolve these challenges much more quickly.
So, for example, rather than only splitting it in half, we split it in approximately two hundred chunks at a time, which allows us to cut down on the size of the challenge much more quickly. Now, there was a lot of complexity there and a lot to unpack. But the main idea I want to get across is that this complexity is really valuable because interactive proofing is an awesome technique with a lot of really major benefits that allow us to make Arbitrum rollup an extremely efficient protocol. Now, one thing is that we’re making these claims about execution and the vast majority of the time this challenge will never occur. And so being able to make these very large claims in extremely small amounts of data allows us to have a very, very efficient protocol in that common optimistic case. Further, even in disputes, the fact that we can cut this challenge down, the fact that we have a number of rounds but each round can be very, very small because we’re doing a very minimal amount of effort. All we’re doing is providing hashes to cut these disputes in half all the way down to the one step proof. We never actually run full transactions. We run very minimal amounts. And this means that we get much, much better gas and contract size limits than might otherwise be possible because we never actually need to run any contracts or any transaction on Ethereum at all.
We only run a very small step. And so on L2, we can have an arbitrarily large bound to gas and contract size limits that aren’t restricted by Ethereum. Even more than just providing compatibility with Ethereum, we have flexibility. A fraud proof where we just need to implement a single step of execution. We can allow a lot of really powerful stuff at L2 because it’s very minimally connected to Ethereum itself, which means that we’re most of the time not particularly constrained by what can actually be executed on Ethereum when we’re talking about what gets executed in L2.
So now that I’ve talked to you about how the protocol works and how it interacts with Ethereum, I want to jump over to talking about the L2 perspective. So from a user directly interacting with Arbitrum, what does this look like? And this basically consists of Arbitrum nodes, much like Ethereum nodes, contracts deployed on the arbitrary chain and a compatibility layer that we call ArbOS that I’m going to talk about in a few minutes.
So from a user perspective, using Arbitrum is a lot like using Ethereum. Arbitrum nodes provide the same standard JSON-RPC on endpoint as Ethereum nodes, which means that most tooling that works for Ethereum is just compatible out of the box with Arbitrum. So, for example, MetaMask worked with Arbitrum right off the bat because we’re able to provide that common interface. Users can use arbitrage in a trustless way because anyone can unilaterally force the rollup chain to run correctly, as I discussed earlier, and the fact that Arbitrum has full compatibility with the EVM means that users can deploy contracts using any version of Solidity or Vyper or any other language that allows you to deploy on Ethereum, and they can run their contracts on Arbitrum.
Along with that, even more than supporting everything that run on Ethereum, we can support many things that couldn’t even run on Ethereum because of their complexity that can still run on Arbitrum.
As I mentioned earlier, the one piece of magic to this is the system that we call ArbOS, which is the L2 operating system of Arbitrum. This is essentially what processes, transactions and performs the state update that we talked about in order to update the chain to a new state. This allows all sorts of cool features, along with supporting normal Ethereum functionality. We have a variety of generalized safe options for bridging between L1 and L2 transaction batching and BLS signature support, which allows you to compress data down a lot more. We provide EVM compatibility, as I said, and we can extend this at any point in order to easily add new transaction types and features to Arbitrum, which makes it a great layer to explore advanced new options for improving the Ethereum user experience. So now we’ve kind of talked through all of these components and the pieces now hopefully click a little bit better in this diagram that I started with.
We have our inbox on Ethereum where we have our transactions. We have our chain state being updated in L2 and then we have the outputs that are being claimed from this chain state that we can now prove back to L1 using the rollup protocol. Here we can see this sort of laid out altogether. We can have our user experience and then we can have our L2 system that I showed you built on top of this L1 system that I described earlier.
So now that I’ve talked to you about Arbitrum rollup today, I want to take a few minutes and talk to you about something I’m really excited about, which is the next iteration of Arbitrum rollup, which is a major upgrade we’re going to be launching next year, called Arbitrum Nitro. So other than the cool name, what is Arbitrum Nitro? The answer is that rather than doing interactive fraud proofs over a custom Assembly language that we created for Arbitrum called the Arbitrum virtual machine, we’re instead switching over to being able to prove over Web Assembly. And this gives us something very, very cool. It gives us the ability to compile an existing Ethereum client to be able to be proven on chain. So what we’re doing with Arbitrum Nitro is compiling Geth into Arbitrum so that when you sync to an Arbitrum chain so that when you process transactions of an Arbitrum machine, you can do this through a modified version of Geth.
We’re taking Geth and we’re building it into what we call our ArbOS 2.0, which is essentially the new version of all of the Arbitrum specific features built into this system. So that was a very technical description of what Arbitrum Nitro is, but I also just want to be excited about it because Nitro provides a lot of really great benefits to users.
First of all, because Nitro is building on top of Geth using the Geth code base, we’re going to be able to provide way more consistency with the Ethereum experience. Even more tooling will just work out of the box. For instance, we’ll be adding highly compatible tracing support, for example, that we don’t support right now. The gas model that we use with Arbitrum will become identical to the gas model of Ethereum, whereas now it’s significantly different because our underlying architecture has a lot of differences. But in order to take advantage of Arbitrum Nitro, all you need to do is use Arbitrum One. Since the Arbitrum One chain will be upgraded to Nitro when it’s ready to be launched, and Nitro really will just provide a better experience that should be noticeable for everybody. It’s going to use significantly less L1 call data on Ethereum, and this is because we’re able to roll out a lot more advanced compression than we were able to implement in Arbitrum today.
The nodes will be capable of more compute and lower storage costs because we’re able to do a lot more optimization in this model using the Geth code base using WASM than we were in Arbitrum as exists today. So to give you a little idea of what this looks like, and I think the main idea here is that it’s very similar to the system today, really, the main thing that we’re doing is swapping out how the L2 system works, replacing the ArbOS of today that runs on top of the Arbitrum virtual machine, with Geth running on top of WASM. The rule of protocol remains the same. The idea of challenges remains the same. But what we’re actually executing and making claims about is going to be undergoing a significant upgrade. Thanks so much for being here today. I really had a lot of fun telling you guys about Arbitrum, and I hope that you enjoyed it and feel like you understand how Arbitrum rollup works a little bit better than you did at the beginning of this talk. Thank you so much to IOSG for hosting, and I hope you have a great rest of your day. And if you’d like to learn more about Arbitrum, there are a variety of resources. Join our discord. Read our docs. Look us up on Twitter. If you’re really excited, our team is growing and we’d love to talk to you about joining our team, so reach out. Thanks.
About Co-hosts
IOSG Ventures, founded in 2017, is a community-friendly and research-driven early-stage venture firm. We focus on open finance, Web 3.0 and infrastructure for a decentralized economy. As a developer-friendly fund with long-term values, we launch the Kickstarter Program, which offers innovative and courageous developers capital and resources. Since we consistently cooperate with our partners and connect with communities, we work closely with our portfolio projects throughout their journey of entrepreneurship.
❄️ StarkWare
StarkWare invented, and continually develops, STARK-based Layer-2 Validity Proof scaling solutions over Ethereum. StarkWare’s solutions, which rely on Ethereum’s security, have settled over $250B, and over 60M transactions, serving hundreds of thousands of users. StarkNet, StarkWare’s permissionless general-purpose scaling solution, is live (Alpha) on Ethereum Mainnet. StarkEx, a custom standalone scaling service, has been powering applications since June 2020, including dYdX, Immutable X, Sorare, and DeversiFi.
❄️ imToken
imToken is a decentralized digital wallet used to manage and safeguard a wide range of blockchain- and token-based assets, identities, and data. Since its founding in 2016, it has helped its users transact and exchange billions of dollars in value across more than 150 countries around the world. imToken allows its users to manage assets on 12 mainstream blockchains and all EVM chains, it also supports decentralized token exchange and open DApp browser.
❄️ Arbitrum
Arbitrum is a leading Ethereum Layer-2 scaling solution developed by OffchainLabs. Based on the Optimistic Rollup scheme, Arbitrum enables ultrafast, low-cost transactions without sacrificing the security of the Ethereum ecosystem. Launched on August 31st, 2021, Arbitrum has attracted 100+ ecosystem projects. Arbitrum is currently EVM-compatible to the bytecode level. In the next upgrade, Arbitrum Nitro, Arbitrum will further increase developer experience by incorporating WASM support.