Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions

tl;dr: Today we’re announcing AnyTrust chains, an Arbitrum mode for ultra low-cost transactions with strong security guarantees. AnyTrust chains will operate alongside Arbitrum One.

We love optimistic rollups. They inherit the security of the underlying L1 chain, in our case Ethereum, while providing lower cost and higher throughput than the L1. And they do all of this trustlessly–anyone can force the chain to progress correctly. That’s why we built Arbitrum One as an optimistic rollup.

Yet some applications, in order to have viable blockchain-based businesses, particularly in the gaming sector, need to drive costs even lower, or make withdrawals of nonfungible assets faster. For those applications, we’ll be rolling out AnyTrust Chains, which allow for much lower cost and faster withdrawals, in exchange for a minimal extra trust assumption. The key advantage of AnyTrust, compared to sidechains, is that because it’s built on top of Ethereum, AnyTrust requires much less trust. (We’ll explain the details below.)

Before diving in, we want to emphasize that Arbitrum One will remain a trustless rollup, as it always has been. We’ll continue to dedicate our resources to improve the Arbitrum One protocol and ecosystem and will not be stopping those efforts in any way. For example, we’ll ship Arbitrum Nitro, and upgrade Arbitrum One to Nitro, before rolling out AnyTrust Chains. We are not pivoting away from trustless rollups–we’ll just be introducing another option for those who want it.

AnyTrust in a Nutshell

Here’s the gist of how AnyTrust works. A chain is operated by a committee of nodes, with a minimal assumption about how many committee members are honest. As an example, there might be 20 committee members and an assumption that at least two of them are honest.

This is a much easier trust assumption compared to conventional BFT sidechains, which require more than ⅔ of the members–that would be 14 out of 20–to be honest. We can reduce the trust requirement from 14 to 2 because of the “fallback to rollup” feature, built on top of Ethereum as explained below.

Assuming the trust assumption holds and the committee members participate, then users get two big advantages. First, there’s no need to record L2 transaction data on the L1 chain, because nodes can rely on the committee to provide data if needed. Instead, with the committee’s promise to provide data, it’s safe to simply record the hash of a transaction batch on the L1, saving the largest cost of running a rollup. Second, withdrawals to L1 can be executed immediately, as soon as the committee vouches for them.

It’s safe to do either of these two things as soon as 19 of the 20 committee members have promised (by signing) that that’s OK. The logic is that if there are at least 2 honest members, and 19 of 20 have signed, then at least one honest member must have signed.

Fallback to Rollup

What if the committee doesn’t sign anything? What if a bunch of committee members crash, or refuse to cooperate? Then the chain can still operate, by falling back to a standard rollup protocol. Data will be posted on the L1 Ethereum chain, and withdrawals will have a delay period, just like on a standard rollup–until the committee resumes operation, and then the chain will switch seamlessly back to the cheaper, faster mode.

Why It’s Safe (given the trust assumption)

With 20 committee members, and at least two of them honest, anything that is signed by a quorum of 19 committee members must be correct, because there are at least two honest members and only one member can be outside of the quorum, so the quorum must contain an honest member. (In general, with N members and K assumed honest, a quorum is any N+1-K members.)

So if a quorum signs a promise to provide the data backing a batch of transactions, we know that that data will be available to anyone who wants it–so we know it’s safe to post the hash of the data, rather than the full data, on the L1 chain.

Similarly, if a quorum signs a statement that a particular state transition is correct, the state transition can be accepted without waiting for a challenge period. That allows withdrawals to L1 to be processed immediately.

If there isn’t an active quorum that is willing to sign statements, then neither of those things can happen. But that’s OK, the chain can still operate and make progress by using the original Arbitrum rollup protocol, with transaction data posted on Ethereum, and new rollup states being confirmed after a challenge period. As soon as a quorum is operating again, the chain will switch seamlessly back to the more efficient, faster mode of operation.

To sum up, in our example, if at least two members are honest, the chain will operate correctly. If there are also 19 members available and cooperating, it will operate at minimum cost. In the in-between zone, the chain will operate at the cost of an Ethereum-based rollup–and it will be evident who the non-cooperating or unavailable members are, so they can eventually be replaced.

Return to our Roots

Are AnyTrust Chains a new idea? No, they’re basically the original Arbitrum design from our 2018 academic paper. That paper described a committee-based chain design with a fallback to what is now called an optimistic rollup. We later took that fallback mode, without the committee part, and improved it to create our current Arbitrum Rollup product.

We think the time is right to reintroduce the AnyTrust Chain alongside Arbitrum One, for use cases that are willing to make a minimal trust assumption in order to lower costs and speed up non-fungible withdrawals in the common case.

More to Come

We’ll have more to say in the future about the technical details and timeline, including things like bridging between AnyTrust and Arbitrum One, but we wanted to let our community know now that AnyTrust is on our roadmap. Feel free to reach out if you have questions, and as always we’re looking to expand our team, so please apply here.