Blobs, transient storage, & data availability: Tableland just became your cheap onchain SQL database

Today, the Dencun upgrade went live! This brings EIP-4844 (and others) to Ethereum mainnet and the long-awaited Proto-Danksharding aka “blob” support. Blobs are a new transient storage option that expires after ~2 weeks. Up to this point, L2 chains would post transaction data from the L2 back to Ethereum L1 as calldata at some interval to ensure the data is made available onchain. The Dencun changes how L2s interact with the L1; instead of posting rolled-up data as calldata, it’s now posted as a blob.

Since blobs are transient, they are significantly cheaper than calldata—around 10 times less. For example, someone posted the entire Bee Movie script to Ethereum L1 and only paid around $14 for it in transaction fees. Quite a significant cost reduction!

Let’s take a step back and think about Tableland before the Dencun upgrade. The basic flow is the following:

• A user or contract creates a table and has onchain ownership of it (ERC721 token), and the data is emitted as an event so that offchain Tableland validator nodes can index the data.

• SQL writes are made onchain to the table, and the SQL write data is passed only as calldata to a smart contract method—and the event is emitted for indexing purposes.

• This flow can occur on Ethereum L1 or any of the L2s that Tableland supports.

Now that Dencun is live, the flow is the same; however, since L2s are using blobs, that means the data L2s post onchain will expire. If it’s not indexed, the L2 data will go away…forever! The benefit is that L2 transactions get cheaper, thus, writing table data also gets cheaper.

Tableland naturally plays a role in making sure that any SQL data has been materialized and properly indexed. Whenever you write SQL to an L2 Tableland table, all event logs are stored in the validator’s local SQLite database. You can take any transaction hash of a Tableland SQL event and get the receipt of what happened for that transaction. Any successfully materialized SQL event will mutate the validator’s database—meaning once the L2 blob expires on the L1, the data is still available in Tableland.

Additionally, the indexing portion will become critical in the future once blobs have greater support (they’re currently only possible in low-level interactions or Solidity assembly. Let’s say you have a smart contract that’s using blob storage. In ~2 weeks, that data is gone. There’s no way to ever retrieve it unless someone has indexed the data.

Fundamentally, the idea behind blobs is the approach we took when designing Tableland. Onchain storage is too expensive, and offchain storage is, well, only offchain. The optimal middle ground was to use calldata so that the data is still executed and “stored” onchain, but the actual availability and functionality are available offchain at the Tableland validator/indexing layer. A dual-pronged approach.

If you’re using any supported L2 (Arbitrum, Optimism, or Polygon), you can take advantage of reduced write costs today!

Note that Tableland is still using calldata on its Ethereum L1 contracts, but over time, you could imagine how the protocol could adopt blob support for table writes to offer developers even more cost savings. The protocol’s native indexing feature would guarantee that data is available even after the transient storage period has ended!