Tableland is a SQL database supporting on-chain data processes.

Preface

Today’s smart contracts are complicated. They support more complex applications. Smart contracts need to store, query, and process more complicated and larger data. Smart contracts are highly coupled with data. Thus these complicated data process scenarios make smart contracts complex and hard to maintain. Developers need to add data-related logic to their contracts, like data queries, data updates, and data filtering. For different data structures, developers need to write different functions.

Besides extra complexity, another problem is flexibility. When developers need to query data with complex filters, developers need to add custom query functions to the contracts. Developers cannot directly read and filter the data.

In the Web2 world, the database takes all data-related work. Applications store clean and structured data in the database. Developers can read desired data with SQL. Data are decoupled with applications.

Tableland is born to solve these problems. Tableland call itself, Web3 native database.

Mechanism

Because on-chain data storage is expansive, Tableland uses the off-chain database and on-chain smart contracts for privilege checks and data modification.

1. Dapp smart contracts send data update requests to Tableland smart contracts

2. Tableland smart contracts check the caller’s privilege and emit events with query

3. Tableland off-chain validator network monitor on-chain event and execute SQL

4. Sync Tableland off-chain validator network

function runSQL(
        address caller,
        uint256 tableId,
        string memory statement
    ) external payable override whenNotPaused nonReentrant {
        if (
            !_exists(tableId) ||
            !(caller == _msgSenderERC721A() || owner() == _msgSenderERC721A())
        ) {
            revert Unauthorized();
        }

        uint256 querySize = bytes(statement).length;
        if (querySize > QUERY_MAX_SIZE) {
            revert MaxQuerySizeExceeded(querySize, QUERY_MAX_SIZE);
        }

        emit RunSQL(
            caller,
            ownerOf(tableId) == caller,
            tableId,
            statement,
            _getPolicy(caller, tableId)
        );
    }

Tableland solves this problem with a dapp frontend, dapp smart contracts, and Tableland three parties interaction. The dapp frontend reads data and dapp smart contracts update data.

Dapp frontend reads data from Tableland gateway. Tableland gateway can directly interact with Tableland off-chain validator network. The function of the Tableland gateway is similar to the function of blockchain RPC. With the gateway, developers don’t need to build their own network nodes.

If the dapp frontend sends a data update request to the gateway, the gateway will relay the request to the Tableland smart contacts.

Limitation

As a "Web3 native database", Tableland still has lots of limitations:

• Dapp smart contracts cannot read data and receive execution results. Developers cannot put all data-related logic into smart contracts
• One table is limited to 100k lines row, 24 columns
• One data cell is limited to 1kb
• Only support a subset of SQL, CREATE TABLE, INSERT, UPDATE, DELETE, SELECT, GRANT, REVOKE
• Only support some types, INT, REAL, TEXT, BLOB, ANY

Application

Tableland names itself "Web3 native database". This is a little exaggerated because of the bad composability between contracts and data. Now Tableland can be applied to games and NFT.

Tableland has great support for NFT. After creating the table and inserting NFT metadata, developers get a gateway link. Developers can use this link as URI.

function _baseURI() internal pure override returns (string memory) {
    return "https://testnet.tableland.network/chain/5/tables/79/id/";
}

Later developers can use Tableland CLI to update NFT metadata.

Roadmap

Tableland will release its NFT in July. NFT holders can access more development functions. In the future, Tableland will make improvements in the following areas:

• Support more SQL
• Decentralize the validator network
• Release tokens and use tokens to secure the validator network
• Database admin panel

Future

Tableland is not the end of the Web3 native database. A truly Web3 native database should satisfy the following requirements:

• Separate contracts and data
• Composability between contracts and data
• Censorship resistance
• Support Web3 data types, like address and transaction
• Users have data ownership

If your project satisfies the above points, feel free to DM me on Twitter.