How to choose your validators in Arbitrum
When we talk about Arbitrum, people are intrigued by its performance and privacy. They want to move their smart contracts’ computation and storage offchain, to reduce cost and vastly improve scalability. But they often ask: how should I choose the validators who will track my contract?
For those newer to Arbitrum, it’s a Layer 2 solution that runs on top of Ethereum and interoperates with Ethereum. You can write your smart contracts in Solidity, just as you would on Ethereum, and use the Arbitrum open source software to run them on Arbitrum (on top of Ethereum) for beter performance and lower cost. Arbitrum contracts can interact with Ethereum contracts, exchanging data with them as well as payments of Ether and other tokens.
Validators in Arbitrum are the parties who take responsibility for keeping track of your smart contract and making sure it executes correctly. Anyone can be a validator, and each contract can choose its own validators. Arbitrum guarantees that as long as at least one validator of your contract is honest, your contract will run correctly. That means that if you can be a validator yourself, then the contract is trustless: you, acting alone, can force correct behavior, even if the whole world is against you.
There are two ways you can use Arbitrum. Which one is right for you will depend on what your contract does and who is using it. If your contract has a fixed set of participants that isn’t too large (say, 15 parties or fewer), or if you want to keep the internals of your contract secret, then you probably want to use an Arbitrum Channel. If you put more importance on openness and scale, and especially if you want trustless execution with many potential participants, then you want an Arbitrum Chain.
Arbitrum Channels
Arbitrum Channels are like state channels, only better. As with state channels, you identify in advance a fixed set of validators for your contract. If your contract has a fixed set of participants, you’ll probably make all of them validators — then the contract will execute trustlessly. Alternatively, you can pick a set of validators who are widely trusted, and rely on Arbitrum’s AnyTrust guarantee, which tells users that if they trust any one of the validators, they can trust the contract to execute correctly.
Channels are the most efficient way to use Arbitrum. Your contract’s storage and computation are both offchain, but Arbitrum guarantees trustlessness even for the offchain components. You’ll touch the chain only when your contract needs to make or receive onchain payments, or in rare cases if a validator goes offline or is defective. Your transactions will have instant finality.
Arbitrum Channels are better than state channels because they’re much more resilient against unavailable or defective validators. If a validator has any trouble, a traditional state channel solution would have to move your entire contract on-chain, which could be very expensive — so expensive that you can’t practically use traditional state channels except for contracts that fit on-chain. By contrast, Arbitrum Channels touch the chain only very lightly even if a validator has trouble. The vast majority of your computation and storage stays offchain, no matter what.
Arbitrum Chains
If Arbitrum Channels don’t meet the needs of your contract, you’ll probably want an Arbitrum Chain. In this approach, your set of validators isn’t fixed, and your contract’s activities are public. Anybody can become a validator, simply by submitting a stake to deter bad behavior. (A validator can quit and get their stake back at any time, although there might be a delay of an hour or less to get their stake back if they’re currently accused of bad behavior.)
With an Arbitrum Chain, your contract’s computation and storage are still handled offchain, but all messages to and from your contract (that is, the transactions requested of it, and their results) are on-chain message data. Anybody who follows the contract can keep up on its state. This requires the same trust assumptions as a normal Ethereum contract, but it’s more efficient because computation and storage are offchain.
Bottom Line
The attributes of the two modes are summed up in this table:
Both models are improvements over plain Ethereum contracts. So if you have an Ethereum contract, or you’re thinking of developing one, you should consider Arbitrum. One model or the other will work for you — and either way, your contract will be faster and cheaper.
Interested in developing with Arbitrum? Read the developer quickstart, or try out the code on Github. Oh, and we’re hiring at Offchain Labs.
