作者

Jason | Buidler DAO Co-founder

Twitter：@jason_chen998

本人与该项目没有任何利益相关，我不持有该项目，也未收取任何广告费，本文章仅为个人分析，无任何投资建议，且可能存在一些分析不到位甚至出现错误的情况。

全文 3200 字，预计阅读时间 8 分钟

文章速览：

01/ 背景介绍 02/ Web3 原生的关系表 03/ Web3 数据存储的两种选择 04/ Tableland 原理分析 05/ 总结

在当下市场环境下新发 NFT 项目并且达到 0.5 ETH 的地板价及上千 ETH 交易量，确实可以称为明星项目。

Tableland 是 NFT 项目吗？是的，但它又是不只是 NFT 项目，Tableland 号称要做原生 web3 的关系表。

好多人来问我：“陈老师，这个叫 Tableland 的项目到底能不能买，听着好像技术很牛，买两个会涨吗？”

貌似这个行业技术创新是推动 NFT 价格上涨的一个有效催化剂，比如 Azuki、Gh0stlyGh0st 等，但是今天我肯定不会讲这个 NFT 项目本身，而是来聊聊 Tableland 背后的技术驱动原理到底是怎么一回事，聊一聊为什么称它为一个很“鸡贼”的项目，注意在本文中鸡贼没有贬义。

*说明：如果你恰好看过 Vic Talk 的视频，请不要误会本文抄袭。Vic 是我的好朋友，我之前协助他对 Tableland 项目进行了分析，故本文会存在内容与其视频重合，特此说明避免读者产生不必要的误会。

因为目前该项目公开查到的资料比较少，所以本文主要以阅读其官方文档并给予一定的解读和推演，可能存在一定程度的局限性。

首先直接打开其官方文档，我们可以看到它称自己是 web3 原生的关系表。

这里面临一个对于普通人而言比较陌生的词汇：“关系表”。

我们平时使用的大部分软件背后都有一个数据库用来存储使用过程中产生的数据，这些数据都会以“表”的形式存储，你可以简单将其理解为 Excel。

关系表是什么？举个例子，比如美团外卖会有商家和用户这两个角色，也可以称之为实体。那么就需要有两个表分别存储商家和用户这两类角色的信息。

• 商家表：店名、电话、地址、营业时间等

• 用户表：姓名、性别、住址等

在表中，每一“行”就是一个具体的商家或者用户，每一“列”则是它对应的属性即姓名、地址等。

表中还有一个很重要的列，就是 ID。每个商家和用户都会有一个 ID 来标识唯一性，这个 ID 称之为主键，就像是身份证一样，这样即使有同名的也可以区分出来。

关系表顾名思义就是表和表之间是相关联的。比如，当我们思考商家和用户如何关联起来，第一时间想到的就是订单。当一个用户给某个商家下了一份订单，于是他们两之间就产生了关联。

同样的也有一个表来存储所有的订单信息，每一行就是一个订单，每一列则是其属性，包括下单人、接单商家、下单时间、金额等等。

这时候你会发现，这个订单里一定会有两个属性分别要存储商家与用户这两个角色，一般来说就是会把刚才说到的 ID 存进去，比如下单人的 ID 为 666，那我在订单表中进行查找时，看到一个叫 666 的订单，于是我就可以去用户表中检索 ID 为 666 的用户找到其具体信息。

为了让大家更直观的理解，粗糙的画了一张示例图，分别为用户表、商家表和订单表，当然在实际的生产开发过程中表的设计肯定不会这样粗糙，按照这样的表设计也肯定是执行不起来的，只是为了让大家更易于理解，此处请勿杠。   

现在你明白什么叫关系表了吧。所以 Tableland 为什么说自己要做 Web3 原生的关系表呢？我们接着往下看。

它提出了目前 web3 数据存储的问题是项目方有被迫有两种选择，要么是把所有的数据存在链上，不过这样 gas 肯定就炸了，而且链上数据结构也支撑不了我刚才给大家画的那种表关联的复杂结构，另一种则是混合存储，即一部分存在链上，一部分在链下，比如 NFT 则是把 NFT 的 ID、持有人等存在链上，而 NFT 的图片、属性等信息存在链下，可以放在 IPFS ，也甚至可以放在阿里云...

不过这个问题确实是存在的，我之前写的文章提到过如阿狸这种奇怪的项目可以直接把用户的 metadata  给改了的操作。

首先其实看到 Tableland 也不是纯链，而是将区块链、去中心化存储（还是在链下）等揉在了一起。可以看到图中有三层结构：

• 第一层是表现层：

  用户和前端的 NFT、DAO、Dapp 等进行交互

• 第二层是业务层：

  用来管理和鉴别所有权、数据交互以及计算

• 第三层是数据层：

  用来存取数据

其实这样看也没啥，很常规的三层架构，所以其在架构上是没有什么革命性创新的。

那我们再耐下心看看它的实现逻辑，它将数据库分为两部分，链上的访问控制 ACL 和链下存储表。

ACL 是啥呢？就是对组织身份角色权限的管理，谁有权限做什么事，所以按照它的说法是把这个管理放在了链上。然后正儿八经的数据存储还是在链下，只是相比于传统的多加了一道 ACL 的过程。

举个例子易于清晰理解，以前我做一套 NFT，把合约发上去后，然后把图片存在 IPFS，IPFS 是去中心化存储的，里面本身的内容不可修改，我如果想改就必须在合约留个后门，从而我可以重新发一套 IPFS 文件，然后把合约指向的链接替换了。

但是现在我可以在合约与 IPFS 中间加一层 ACL，去设置某些人可以增删改查某些数据。通过这张图也可以看到，用户是和合约先进行交互，检查其 ACL 与 owner 权限，然后合约将增删改查的请求发送给 Tableland 进行处理，图里还是描述的很简单的这里看不出很多细节。

这里重点来了，为什么我说它是一个“鸡贼”的项目呢？就是因为下面这句话，它的每个表都是一套 ERC721 的 NFT，妙，实在是妙啊！

到了这里你可能会有点懵，每个表是一套 ERC721 的 NFT ，这代表什么呢？

还记得我一开始花了很大力气讲的关系表概念吗？每个表是一类实体，每一行就是具体的一个实体，每一列就是这个实体的属性，并且会有一列 ID 用来标识该实体的唯一性。

我们想想 NFT，每个 NFT 都是独一无二的原因就是因为有着从1～9999的 tokenID 去标识唯一性，然后每个 NFT 又会有自己的 metadata 用来存储它的名字、描述、图片等信息，这从性质上不就是一个“表”吗？

只是之前的这套 NFT 存储方式不是以表的结构进行存储的，我画张草图易于理解，下图为目前 NFT 存储的结构，链上存了 ID 与持有人，链下则存了 metadata 对应着每个NFT的具体信息。

我们将其数据结构按照表的形式进行整理如下图所示，可见 ERC721 的 NFT 天然就是一张表呀！

所以 Tableland 巧妙的利用 NFT 的特性，将其链上表，如 ACL 等访问控制的方式都用 NFT 来解决，相当于每张表都是一套 NFT，这很巧妙是不是！巧妙到我用“鸡贼”来形容它。

我们再来看一个它给出的更完整的逻辑交互图，总共有4方，首先用户和前端进行交互，我们先看左边，对网关发起了查询请求，然后网管转发给 Tableland 后返回给数据，因为链上数据本来都公开所以查询这个路径没有什么特别的。

我们看右边的修改与写入数据的路径，对智能合约发起请求，然后 dapp 自身的合约与 Tableland 的合约进行鉴权，通过后发给 Tableland 进行数据处理，这里有趣的是它引入了传统的 SQL 来做数据处理，从而能够以极低的上手门槛吸引开发者进入。

以上就是对于 Tableland 这个项目的原理分析，我不评价其解决方案的优劣性，更不评价其 NFT 的投资价值，单纯从原理来看我觉得还是挺有趣的，用了取巧的方式，也在一定程度上可以解决目前 Web3 开发数据存储中所牵扯的很多杂七杂八的问题，至少是一个 buidl 行业的一步，值得鼓励！

Buidler DAO 聚集顶尖的 Web3 的实干家，在五个公会中共同协作：以孵化公会为首，组织工具、产品和基建项目的孵化；技术公会组织代码实践；投研公会输出深度文章与研报；教育公会生产 Web3 高质量课程；运营公会负责对内管理与对外宣发。

如果想参与到更多建设中请填写链接（或点击阅读原文）：https://tally.so/r/wA7LlN

文章：@Buidler DAO

设计：@Rui

排版：@Coucou

buidlerdao | Twitter | Linktree

建设成为最有影响力和生产力的 Web3 人才与项目孵化器

https://linktr.ee

作者

Jason | Buidler DAO Co-founder

Twitter：@jason_chen998

本人与该项目没有任何利益相关，我不持有该项目，也未收取任何广告费，本文章仅为个人分析，无任何投资建议，且可能存在一些分析不到位甚至出现错误的情况。

全文 3200 字，预计阅读时间 8 分钟

文章速览：

01/ 背景介绍 02/ Web3 原生的关系表 03/ Web3 数据存储的两种选择 04/ Tableland 原理分析 05/ 总结

在当下市场环境下新发 NFT 项目并且达到 0.5 ETH 的地板价及上千 ETH 交易量，确实可以称为明星项目。

Tableland 是 NFT 项目吗？是的，但它又是不只是 NFT 项目，Tableland 号称要做原生 web3 的关系表。

好多人来问我：“陈老师，这个叫 Tableland 的项目到底能不能买，听着好像技术很牛，买两个会涨吗？”

貌似这个行业技术创新是推动 NFT 价格上涨的一个有效催化剂，比如 Azuki、Gh0stlyGh0st 等，但是今天我肯定不会讲这个 NFT 项目本身，而是来聊聊 Tableland 背后的技术驱动原理到底是怎么一回事，聊一聊为什么称它为一个很“鸡贼”的项目，注意在本文中鸡贼没有贬义。

*说明：如果你恰好看过 Vic Talk 的视频，请不要误会本文抄袭。Vic 是我的好朋友，我之前协助他对 Tableland 项目进行了分析，故本文会存在内容与其视频重合，特此说明避免读者产生不必要的误会。

因为目前该项目公开查到的资料比较少，所以本文主要以阅读其官方文档并给予一定的解读和推演，可能存在一定程度的局限性。

首先直接打开其官方文档，我们可以看到它称自己是 web3 原生的关系表。

这里面临一个对于普通人而言比较陌生的词汇：“关系表”。

我们平时使用的大部分软件背后都有一个数据库用来存储使用过程中产生的数据，这些数据都会以“表”的形式存储，你可以简单将其理解为 Excel。

关系表是什么？举个例子，比如美团外卖会有商家和用户这两个角色，也可以称之为实体。那么就需要有两个表分别存储商家和用户这两类角色的信息。

• 商家表：店名、电话、地址、营业时间等

• 用户表：姓名、性别、住址等

在表中，每一“行”就是一个具体的商家或者用户，每一“列”则是它对应的属性即姓名、地址等。

表中还有一个很重要的列，就是 ID。每个商家和用户都会有一个 ID 来标识唯一性，这个 ID 称之为主键，就像是身份证一样，这样即使有同名的也可以区分出来。

关系表顾名思义就是表和表之间是相关联的。比如，当我们思考商家和用户如何关联起来，第一时间想到的就是订单。当一个用户给某个商家下了一份订单，于是他们两之间就产生了关联。

同样的也有一个表来存储所有的订单信息，每一行就是一个订单，每一列则是其属性，包括下单人、接单商家、下单时间、金额等等。

这时候你会发现，这个订单里一定会有两个属性分别要存储商家与用户这两个角色，一般来说就是会把刚才说到的 ID 存进去，比如下单人的 ID 为 666，那我在订单表中进行查找时，看到一个叫 666 的订单，于是我就可以去用户表中检索 ID 为 666 的用户找到其具体信息。

为了让大家更直观的理解，粗糙的画了一张示例图，分别为用户表、商家表和订单表，当然在实际的生产开发过程中表的设计肯定不会这样粗糙，按照这样的表设计也肯定是执行不起来的，只是为了让大家更易于理解，此处请勿杠。   

现在你明白什么叫关系表了吧。所以 Tableland 为什么说自己要做 Web3 原生的关系表呢？我们接着往下看。

它提出了目前 web3 数据存储的问题是项目方有被迫有两种选择，要么是把所有的数据存在链上，不过这样 gas 肯定就炸了，而且链上数据结构也支撑不了我刚才给大家画的那种表关联的复杂结构，另一种则是混合存储，即一部分存在链上，一部分在链下，比如 NFT 则是把 NFT 的 ID、持有人等存在链上，而 NFT 的图片、属性等信息存在链下，可以放在 IPFS ，也甚至可以放在阿里云...

不过这个问题确实是存在的，我之前写的文章提到过如阿狸这种奇怪的项目可以直接把用户的 metadata  给改了的操作。

首先其实看到 Tableland 也不是纯链，而是将区块链、去中心化存储（还是在链下）等揉在了一起。可以看到图中有三层结构：

• 第一层是表现层：

  用户和前端的 NFT、DAO、Dapp 等进行交互

• 第二层是业务层：

  用来管理和鉴别所有权、数据交互以及计算

• 第三层是数据层：

  用来存取数据

其实这样看也没啥，很常规的三层架构，所以其在架构上是没有什么革命性创新的。

那我们再耐下心看看它的实现逻辑，它将数据库分为两部分，链上的访问控制 ACL 和链下存储表。

ACL 是啥呢？就是对组织身份角色权限的管理，谁有权限做什么事，所以按照它的说法是把这个管理放在了链上。然后正儿八经的数据存储还是在链下，只是相比于传统的多加了一道 ACL 的过程。

举个例子易于清晰理解，以前我做一套 NFT，把合约发上去后，然后把图片存在 IPFS，IPFS 是去中心化存储的，里面本身的内容不可修改，我如果想改就必须在合约留个后门，从而我可以重新发一套 IPFS 文件，然后把合约指向的链接替换了。

但是现在我可以在合约与 IPFS 中间加一层 ACL，去设置某些人可以增删改查某些数据。通过这张图也可以看到，用户是和合约先进行交互，检查其 ACL 与 owner 权限，然后合约将增删改查的请求发送给 Tableland 进行处理，图里还是描述的很简单的这里看不出很多细节。

这里重点来了，为什么我说它是一个“鸡贼”的项目呢？就是因为下面这句话，它的每个表都是一套 ERC721 的 NFT，妙，实在是妙啊！

到了这里你可能会有点懵，每个表是一套 ERC721 的 NFT ，这代表什么呢？

还记得我一开始花了很大力气讲的关系表概念吗？每个表是一类实体，每一行就是具体的一个实体，每一列就是这个实体的属性，并且会有一列 ID 用来标识该实体的唯一性。

我们想想 NFT，每个 NFT 都是独一无二的原因就是因为有着从1～9999的 tokenID 去标识唯一性，然后每个 NFT 又会有自己的 metadata 用来存储它的名字、描述、图片等信息，这从性质上不就是一个“表”吗？

只是之前的这套 NFT 存储方式不是以表的结构进行存储的，我画张草图易于理解，下图为目前 NFT 存储的结构，链上存了 ID 与持有人，链下则存了 metadata 对应着每个NFT的具体信息。

我们将其数据结构按照表的形式进行整理如下图所示，可见 ERC721 的 NFT 天然就是一张表呀！

所以 Tableland 巧妙的利用 NFT 的特性，将其链上表，如 ACL 等访问控制的方式都用 NFT 来解决，相当于每张表都是一套 NFT，这很巧妙是不是！巧妙到我用“鸡贼”来形容它。

我们再来看一个它给出的更完整的逻辑交互图，总共有4方，首先用户和前端进行交互，我们先看左边，对网关发起了查询请求，然后网管转发给 Tableland 后返回给数据，因为链上数据本来都公开所以查询这个路径没有什么特别的。

我们看右边的修改与写入数据的路径，对智能合约发起请求，然后 dapp 自身的合约与 Tableland 的合约进行鉴权，通过后发给 Tableland 进行数据处理，这里有趣的是它引入了传统的 SQL 来做数据处理，从而能够以极低的上手门槛吸引开发者进入。

以上就是对于 Tableland 这个项目的原理分析，我不评价其解决方案的优劣性，更不评价其 NFT 的投资价值，单纯从原理来看我觉得还是挺有趣的，用了取巧的方式，也在一定程度上可以解决目前 Web3 开发数据存储中所牵扯的很多杂七杂八的问题，至少是一个 buidl 行业的一步，值得鼓励！

Buidler DAO 聚集顶尖的 Web3 的实干家，在五个公会中共同协作：以孵化公会为首，组织工具、产品和基建项目的孵化；技术公会组织代码实践；投研公会输出深度文章与研报；教育公会生产 Web3 高质量课程；运营公会负责对内管理与对外宣发。

如果想参与到更多建设中请填写链接（或点击阅读原文）：https://tally.so/r/wA7LlN

文章：@Buidler DAO

设计：@Rui

排版：@Coucou

buidlerdao | Twitter | Linktree

建设成为最有影响力和生产力的 Web3 人才与项目孵化器

https://linktr.ee