Skip to main content

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 the database'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. This page explains general chain related concepts; the following chains are supported and described in more detail in the subsequent pages:

  • ethereum
  • optimism
  • arbitrum one
  • arbitrum nova
  • polygon
  • filecoin
tip

Review the cost estimation table that compares the costs of creates and writes across each chain.

Chain information​

If would like to dive straight into chain-specific overviews, with decision considerations and other chain information (chain ID, contracts, block explorers, faucets, etc.), head to one of the pages 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.

There is plenty of research and resources that describe considerations and differences between optimistic rollups, zk-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.

Sidechains​

  • 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.

Be sure to use https://tableland.network on mainnets, and https://testnets.tableland.network on testnets. Learn more about why in the gateway docs.

Providers​

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, and note that the Tableland SDK and CLI are both compatible with whatever ethers can support:

Infura​

Alchemy​

Etherscan​