聊聊Tableland这个“鸡贼”的熊市明星项目 - Jason chen

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

在现在的市场环境下居然还能有新发NFT项目达到0.5ETH的地板价，上千ETH交易量，确实算得上是明星项目，Tableland是NFT项目吗？是的，但是不只是NFT项目，它号称要做原生web3的关系表。

好多人来问我陈老师这个叫Tableland的项目到底能不能买，听着好像技术挺牛逼的买两个能涨不？因为貌似在这个行业技术创新是推动NFT价格上涨的一个有效催化剂，比如Azuki、Gh0stlyGh0st等，但是今天我肯定不会讲这个NFT项目本身，而是来聊聊Tableland背后的技术驱动原理到底是咋回事，以及说说我为什么称这是一个很“鸡贼”的项目，注意在本文中鸡贼没有贬义。

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

我们直接打开其官方文档 https://docs.tableland.xyz/what-is-tableland，会看到它说自己是web3原生的关系表。

好了这里面临第一个普通人陌生的词汇，关系表是什么？我们平时使用的大部分软件背后都有一个数据库用来存储使用过程中产生的数据，这些数据都会以“表”的形式存储，对，你可以将其理解成就是Excel的表。

那关系表又是什么呢？举个例子，比如美团外卖，它会有商家和用户这两个角色，更专业的称之为实体。

那肯定要有两个表分别存储商家和用户这两类角色的信息。

商家表会有什么呢？店名，电话，地址，营业时间等等，用户表则会有姓名、性别、住址等。在表中，每一“行”就是一个具体的商家或者用户，每一“列”则是它对应的属性即姓名地址什么的。

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

那什么是关系表呢？就是表和表之间是有关联关系的，商家和用户怎么关联起来呢，我们第一时间想到的就是订单，当一个用户给某个商家下了一份订单，于是他们两之间就产生了关联。

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

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

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

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

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

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

接续看它的文档是如何解决该问题的。

首先其实看到它也不是纯链，而是将区块链、去中心化存储（还是在链下）等揉在了一起。可以看到图中有三层结构，第一层是表现层，用户和前端的NFT、DAO、Dapp等进行交互，第二层是业务层，用来管理和鉴别所有权、数据交互以及计算，第三层是数据层，用来存取数据。

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

那我们再耐下心看看它的实现逻辑，它将数据库分为两部分，链上的访问控制ACL和链下存储表。ACL是啥呢？就是对组织身份角色权限的管理，谁有权限做什么事，所以按照它的说法是把这个管理放在了链上。然后正儿八经的数据存储还是在链下，只是相比于传统的多加了一道ACL的过程。

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

但是现在我可以在合约与IPFS中间加一层ACL，去设置某些人可以增删改查某些数据。

通过这张图也可以看到，用户是和合约先进行交互，检查其ACL与owner权限，然后合约将增删改查的请求发送给Tableland进行处理。

以上内容均为个人研究分享，不构成任何投资建议，因个人视角与认知使得可能具有一定局限性和偏差，欢迎一起交流学习探讨，微信：cj350306878，请备注姓名公司和职位，谢谢。

未经允许，请勿将本文复制粘贴到自己的媒体平台，请具有媒体人的职业道德，拒绝白嫖。

往期文章：