Offchain Labs’ Goldfeder talks Timeboost, transaction ordering and more
Steven Goldfeder believes that interoperability between Ethereum layer-2s is key
Offchain Labs co-founder Steven Goldfeder | Mike Lawrence for Blockworks
Offchain Labs, the research and development team behind Ethereum scaling protocol Arbitrum, has had a busy few months.
Recent milestones include the launch of tools for developers to launch their own Abitrum chains through Arbitrum Orbit, the introduction of a permissionless validation protocol and the release of programming environment Abitrum Stylus.
Today, Arbitrum is one of the largest Ethereum scaling platforms. It holds a market share of almost 55% and has a total value locked of $5.82 billion, according to L2beat.
Most recently, the team partnered with Espresso Systems, a decentralized sequencing layer, to further develop Timeboost — a transaction ordering technology optimized for improving first-come-first-serve tendencies in capturing maximum extractable value (MEV).
In an interview with Blockworks at Permissionless II, Offchain Labs co-founder Steven Goldfeder said that the decision to work with Espresso Systems was made so that credible, neutral third parties could help drive the scalability of Ethereum.
Blockworks: Tell me about Timeboost and the decision behind partnering with Espresso Systems to bring the tech to life.
Goldfeder: Timeboost was a proposal that we at Offchain Labs had put out in a few iterations on Arbitrum research forums and elsewhere. The idea comes down to MEV ordering. Historically, there are different schools of thought about how to order transactions. On Arbitrum today, there’s “first come, first serve” ordering, but others say everything should be auctioned — this is the other end of the extreme — which is that you completely pay for ordering transactions in a mempool. Timeboost is sort of an in-between of these two camps, which basically says there are intervals that allow you to bid for placement and have the privacy of transactions built in.
We’re partnering with Espresso. We’re going to provide key research, and they’re going to actually build it out in a way that is compatible with the Espresso sequencer. The reason why we’re not building this out ourselves is because we have to understand the realities of what we build, and how that’s perceived, and the biases that are associated with that. We need something that is more neutral.
When it comes to interoperability, if every different rollup stack is building its own megachain, you don’t really accomplish much. Whether we open source it or not, other chains will not use something we built. I think if you really want to get interoperability, it is by building an Ethereum super chain. The way to do that is to empower credibly neutral third parties, putting our biases down for a second, and I think that’s actually best for the Ethereum community.
Blockworks: There’s a lot of MEV discussion around time-sensitive transactions versus non-time-sensitive transactions. So, with Timeboost’s guaranteed inclusion, how do you determine what transaction should be included? It seems like it would be pretty difficult to choose a good middle ground.
Goldfeder: So even today, before we get Timeboost, there’s this concept of forced inclusion on Abritrum chains. The forced inclusion on Arbitrum chains today is 24 hours, what that means is you can’t censor indefinitely but the sequencer can real-time censor or delay. I think the parameters about transaction inclusion will be up to the different chains that choose to adopt this [technology]. If the Arbitrum DAO adopts it, it can choose to set these parameters.
If you ask me what I think about Timeboost, the parameters we think about are more in the realm of a few seconds. The idea is that what we have today — the chain forcing the sequencer to do something — is very different from Timeboost where a distributed party, the sequencer, has logically agreed to do something. I think that lends itself to much shorter intervals of guarantees.
In a, let’s say, two-second interval, you can bid for timing, but every user will guarantee that its transactions are being processed quickly. If the Timeboost committee is behaving according to its principles, then that transaction will be included. If this whole time this committee colludes against you, you still can go on-chain and get this other guaranteed inclusion from on-chain.
Blockworks: Do you think shared sequencing is a more pressing issue than permissionless fraud-proof systems?
Goldfeder: No, not really. A lot of people don’t really know what decentralized sequencing means. Say for example with Abirtrum the sequencer has very limited power because there are fraud proofs. Sequencers can’t do anything security-critical. It can’t actually go ahead and steal your money or take it and put it back in a transaction — that’s validators. Validators will challenge one another if they do the wrong thing. Sequencers give you fast confirmations, but those don’t hold any weight on-chain.
In a validation system that doesn’t have any fraud proofs of validators, then the sequencer is basically the dictator. It can submit whatever fraud or whatever state routes it wants In some ecosystems, that is true, but it’s really more about the progress of the sequencer. I think the most important thing here is that decentralizing the security of the system — which Arbitrum does today — among about a dozen different institutions submitting fraud proofs or having the ability to challenge different fraud proofs if necessary. I think that is number one. When we launched Arbitrum, having fraud proofs was non-negotiable.
So, going back to what can a sequencer do? It can’t do anything like include a bad transaction. It can order transactions, but it can’t censor a transaction. It can delay a transaction, but it can’t, as we discussed before, censor indefinitely because there are paths to guarantee a transaction on-chain — and that’s where the decentralizing sequencers come in.
I think that it’s an important problem, but I think that having live security proofs is more important, and that’s why we prioritize building the security proofs before the decentralization of ordering.
This interview has been edited for brevity and clarity.
Don’t miss the next big story – join our free daily newsletter.
