Value Layering across L1 & L2

Value Layering across L1 & L2

Leverage a multi-chain table deployment approach for optimizing table create/write costs.

Value Layering across L1 & L2

Leverage a multi-chain table deployment approach for optimizing table create/write costs.

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.

Value Layering

Anytime you use Tableland, you should start with an exercise to understand the tradeoffs of choosing a chain, including costs, transaction speed, and transaction throughput. An L1 should be used for “high value” transactions. Decentralized Finance (DeFi) is a great example — Ethereum is a battle tested network and has stronger security assumptions in place as compared to newer L2 solutions being built on top of it. For L2s, “high volume” transactions should be considered. Namely, Ethereum is costly & slow, and if high transaction throughput is needed, the gas fees (paying to run transactions) will make a project infeasible for the end users.

Recall that a table being created or written to actually goes through a smart contract call. For each chain Tableland is live on, the same smart contract code exists. Meaning, the same functionality for using Tableland can be used seamlessly across each chain, but the aforementioned tradeoffs dictate which one should be used for a particular use case. Let’s take a simple example — say you want to launch an NFT collection. The NFT itself may be considered high value, and since an NFT mint event only happens once for each NFT, it might make sense to deploy this NFT on the L1.

Take another example — a global leaderboard for a game that is created as an NFT. The leaderboard would often change, which requires transactions to happen after the mint occurs. Does it make sense to deploy this leaderboard on L1? Probably not. Instead, it’s destined for an L2. It has lower value assumptions that allow it to be launched on the L2 and take advantage of lower costs and higher transaction speed/throughput.

Back to the NFT example — it might make sense for the NFT to exist on Ethereum L1, but where should the NFT’s metadata be published?

Cross Chain Metadata

What’s great about Tableland is that contracts are live across multiple networks (Ethereum, Polygon, Optimism, Arbitrum, etc.). Developers can choose to launch high value projects on L1 while deploying other related projects on L2 — and all of them can leverage Tableland’s native composability for a unified end user experience. In fact, the Tableland Rigs adopted this exact cross chain model!

Namely, a single NFT can leverage a multichain metadata approach. The ERC-721 token might be minted on Ethereum, but its static metadata is stored in a table stored on a cheap L2. Each L1 NFT’s metadata (tokenURI) points to a table deployed on a different chain (an L2). This is really powerful because developers can selectively decide which chain tables should be created on, reducing costs for metadata table deployment. When apps like OpenSea read the L1 NFT’s metadata, it performs a request to the Tableland gateway, returning the metadata for the table — which exists on the cheaper L2.

It’s important to note the use case above highlights static metadata; these are tables which won’t ever be updated (immutable). For dynamic metadata that’s governed by on-chain rules, a table must exist on the same chain in which access control checks occur. That is, if an NFT is launched on Ethereum, and writing to its mutable metadata table checks for some on-chain ACL rule (e.g., verifies owner of Ethereum token), then the table must also exist on Ethereum.

Polygon Benefits

Polygon is a popular L2 scaling solution (called a “sidechain”). It has a number of reputable companies building on it, including web2 natives such as Instagram and Stripe. Many web3 developers have followed the path of these tech giants (or preceded them) and often use Polygon to deploy low cost NFTs or gaming assets. Namely, Polygon 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. Companies like Adidas have chosen to launch NFTs to Polygon for this very reason, bypassing the L1 and going straight to L2.

For comparison, Polygon supports 7k tx/s compared to Ethereum’s 15 tx/s and ~10000x lower costs per transaction than Ethereum. Now, 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.