Choosing a Chain

Choosing a Chain

Selecting a base chain is an important step in any application’s design and, especially, for tables.



Chain selection makes a significant impact on a table’s usability. Choose a chain that’s too slow or expensive, and it won’t be feasible for table writes to occur frequently. Deploy a cross-chain data model for value layering purposes, and certain on-chain access control features are lost.


Read the primers on

Considerations & Tradeoffs
to gain an understanding of how Tableland works with EVM events and various considerations for what data should exist in tables.

Recall the following chains are currently supported and described in more detail in the sections below:

Layer 1 vs. Layer 2

Ethereum (Layer 1, “L1”) can be expensive. Tableland extends a base chain’s functionality so that writing data to the blockchain is cheap (stored in event logs) while the Tableland network makes this data functional. But, Ethereum will always be more expensive as well as slower when compared to its scaling solutions (Layer 2, “L2”) — these technologies exist for a reason! There is a ton of information on why L2s are needed to the point where these solutions are part of Ethereum’s future roadmap. Thus, choosing the right ETH L2 variant is important since Tableland is an extension of the base chain and depends on the base chain’s execution, consensus, and security, which determine the speed of creating or writing to tables.

L2 Variants

The most commonly used L2 types come in two flavors: rollups and sidechains. Currently, Tableland supports rollups like Optimism & Arbitrum, which are both “optimistic” rollups. For reference, there also exists “zero knowledge” (”zk”) rollups. The primary difference between the two is that optimistic rollups are optimistic; batches of transactions are posted on-chain and assumed valid (unless challenged via fraud proofs). Zk-rollups provide the validity proof by design but are still nascent.

Both rollups and sidechains operate an off-chain network. L2 nodes are running the same execution layer as Ethereum (”EVM”) and allow users to “bridge” assets to the L2 network using a bridging contract, which locks the assets up on the L1. As users are leveraging an app deployed on L2 for its scaling and associated cost benefits, the L2 data is posted back to Ethereum L1, periodically.

The following notes some considerations on the considerations and differences between optimistic rollups and sidechains:

Optimistic Rollups

  • Off-chain network of nodes running the EVM.
  • On-chain smart contract bridge.
  • Inherits L1 security.
  • Actors periodically post batched transaction data (as calldata) to the L1, using the bridge contract.
  • The bridge contract self-enforces L2 transaction validity with fraud proofs where anyone can make a challenge to the data posted to L1 — if successful, the L2 re-executes the txs and updates the L2 state.


  • Off-chain network of nodes running the EVM.
  • On-chain smart contract bridge.
  • Partially inherits L1 security but uses a separate consensus mechanism.
  • Actors periodically post batched L2 transaction data (as calldata) to the L1, using the bridge contract.
  • The correctness of the batched data posted to L1 is not openly challengeable nor self-enforcing but is managed by a set of trusted parties.

The main difference is whether the bridge contract can self-enforce the validity of transactions on the other network or if it must rely upon a trusted set of parties to attest that it is valid. For more information, check out the following article (by Infura).

EVM Compatibility

Solutions that Tableland supports are all “EVM compatible.” These are layers including or built on top of Ethereum that can still leverage Solidity smart contracts, wallets/addresses, and Ethereum-related libraries. For example, using a wallet on one EVM-compatible chain is possible on another, without much additional setup, besides configuring wallet settings and (likely) bridging assets from the L1 to the L2. Tableland only supports EVM-compatible chains.

Mainnets vs. Testnets

In general, all chains have both a mainnet and testnet. Developers should first use a testnet to validate everything is working as expected, and once ready, move everything to production on mainnet. Testnet chains use testnet currency with no inherent value such that developers can request testnet currency for free from faucets. Mainnets require real currency to help provide the proper incentivization mechanisms and payment to nodes for computation and state management.

Mainnets vs. Testnets Gateway

Be sure to use on mainnets, and on testnets.

At the protocol level, the Tableland network is separated such that nodes process and respond to SQL queries relative to each environment. If you were to use the testnets gateway on a mainnet chain / contract, this would lead to issues. The testnets gateway only queries tables that exist on testnet chains, whereas the gateway only queries tables that exist on mainnet chains.


To interact with a chain, developers must run their own node or have access to one. Providers like Infura, Alchemy, and Etherscan operate a large pool of decentralized nodes and provide an API (centralized gateway) to them. They make it extremely easy to get started and develop web3 applications without needing to personally manage the hardware and software for a dedicated node.

Check out the following resources for each of these providers:





Ethereum is the most popular and secure smart contract blockchain. All L2 solutions are built on top of Ethereum and run its virtual machine, called the EVM. Transaction costs are much higher on Ethereum and take longer to get included in a block, so many applications use L2s, depending on the use case.

Because of its security, data can be viewed as more valuable on this chain. A highly secure, battle-tested environment translates to greater reliability, so applications may choose to pay a premium for this. Thus, deploying tables here is best used in higher value use cases and/or if on-chain access controls specific to Ethereum are needed (e.g., verifying ownership of an Ethereum-based NFT).

Goerli Testnet



Polygon is a popular L2 scaling solution called a sidechain. It has low transaction costs and high transaction speed & throughput, so many developers choose Polygon when designing cost effective applications that require a high transaction throughput or speed.

For comparison, Polygon supports 7k tx/s compared to Ethereum’s 15 tx/s and ~10000x lower costs per transaction than Ethereum. It’s important to note that sidechains do use different security assumptions than the L1; it’s what allows Polygon to architect its network in a way that enables all of these benefits for developers. Nevertheless, it’s a great scaling solution.

Mumbai Testnet



Optimism is an optimistic rollup built on top of Ethereum. It is a sidechain that inherits the Ethereum’s security but operates as a separate protocol with its own set of nodes running. Rollups sequencers batch transactions onto the LI at various intervals and leverage fraud proofs for self-enforced validation of the offchain transaction.

Offchain, the transactions happen much quicker than the batching. Note that developers must bridge assets from Ethereum to Optimism to take advantage of the faster transaction confirmation speeds and low costs.

Goerli Testnet



Arbitrum is a rollup scaling solution that works by batching transactions from L2 to L1 at various intervals. Off-chain transactions happen much more frequently and allow for very low costs and fast transaction confirmation times. Arbitrum operates a network of EVM-compatible nodes and uses fraud proofs to validate if the off-chain transaction are valid, doing so in a way that inherits Ethereum’s security.

One key difference to note between Arbitrum and Optimism is that Arbitrum uses multi-round fraud proofs and single transaction disputes. This differs from single-round fraud proofs (e.g., Optimism) that execute the entire rollup on Ethereum if a challenge is made.

Goerli Testnet

Mainnet (Arbitrum One)

← Previous