'CryptoYC'
研究|Celestia会成为DA模块的头牌吗?
🌿

研究|Celestia会成为DA模块的头牌吗?

我们回顾一个老生常谈的问题:目前来说公链扩容的瓶颈是什么?无论你的观点是什么,都不得不考虑数据可用性的问题(Data Availability, 后文我们称为DA )。绝大多数的扩容方案都是从“解耦功能层”去入手,这里面既有从0开始建立自己完整帝国的公链新贵,也诞生了一系列专精某一模块而组合性又贼强的基础设施(共识,数据可用,计算等,但是算不上完整的计算平台链)。Celestia就是其中的一个佼佼者。

Celestia是什么

Celestia前身叫LazyLedger。是一个专精于“数据可用性”的基础设施。当然它自己本身就是一条链,但是却不涉及状态计算的问题。所以,这里就衍生出一系列先验问题,例如:数据可用性的重要性以及和扩容的关系是什么。

这里就需要看下传统区块链的数据问题。以ETH为例,现在绝大多数的节点都是轻节点,本身不负责出块,而是验证区块。但是,由于验证的只是区块头,所以存在一种可能,就是区块生产者发布一个正确有效的区块头,但是没有包含/掩盖了交易数据时,就会出现数据可用性的问题,轻节点很容易被欺骗或者接受无效区块。同时,由于全节点无法为轻节点生成数据可用性证明,以及无效区块的欺诈证明,所以轻节点想要验证区块数据本身,就需要自己来进行。或者,假设绝大多数数据是诚实可信的。

明显看出,如果为了安全,绝大多数节点必须下载全部交易数据并验证数据可用性,这就进而引发了扩容问题。

说到这里,我们不难发现数据可用性的两个瓶颈:

  • 可用性证明:告诉其他节点,这个区块的数据都是真实可用的
  • 欺诈证明:区块是否是有效的

这就是Celestia想要解决的两个问题。

怎么做

那么,Celestia是如何解决这两个问题呢?很简单:放弃链上执行,放弃链上状态转换,只通过二维 Reed-Solomon纠删码以及专门的命名空间默克尔树结构来确保数据的可用性,而执行的部分则交给终端用户自己执行。所以,我们简单看下这两个东西。

二维 R-S纠删码

这个东西概括来说,就是传递某个信息,不止是传递信息本身,还会加入一些可以容错的冗余,举个简单的例子:

  • 例如我想要给别人传递一个信息 1 2 3,但是我知道在信息传递过程中可能出现信息部分丢失或错误的情况,所以我为了让别人能最大概率的正确确认我传递的信息,会选择传递 one two three。
  • 假如别人接受到的信息是on, to, thee,只要接受者知道内容格式是什么,这个例子里是数字,那就可以大概率确认原本的数据是1 2 3。

当然,这里面涉及到一个阈值问题,假设信息一共有n个片段,只要k个片段能够正确传输,则完整信息就可以被还原,即成功传递的信息比例>k/n就可以。如果按照标准的Reed-Solomon纠删码,这个阈值就是50%。

具体到celestia,他们提出了一个新的采样方式:二维采样。将信息切分成横纵数量一样的二维分片。在验证欺诈证明(数据可用性证明)的时候,轻节点只需要下载横向或纵向的数据即可,这样需要下载的数据量直接成了√N (假设数据分成n*n片)。当然,因为没有下载完整的数据,所以轻节点还需要下载每一行和每一列的默克尔树根作为区块头的一部分进行验证,以保证数据最大的可用性。这样,整个celestia网络就变成了一个基于P2P的种子下载网络。用很少的数据,就可以大概率确认数据的可用性。

命名空间默克尔树

我们都知道以太坊的状态更新是全局同步的,每次状态转换会更新所有地址的状态,举个不恰当的例子:假设我在以太坊上更新了www.cryptoyc.com的数据,节点在更新状态的时候不止是更新验证cryptoyc的数据,还会把不相干的数据(例如www.123.com的状态)也会更新和验证显然,这样是不合理的。

所以,Celestia在存储数据的时候用的是一种namespace merle tree,为的是终端节点在执行应用时只用下载自己应用相关的数据,而不是和以太坊一样需要下载全部区块数据。所以通过这种结构,对应功能的节点可以将只包含终端应用需要的数据状态返回给终端节点。有关这个默克尔树的详细结构和组成规则以后有兴趣的时候再说。概括来说,该结构是由命名空间hash(nsHash, 以namespace identifer为前缀的warpper hash)为基本数据,根节点包含了所有子节点的相关命名数据(相关这两个字很重要)。具体存的数据是json格式。而nsHah是由minNs, MaxNs, hash(x)三个元素组成。

  • minNs: 其根节点所属的子节点中的最小namespace identifier。
  • maxNs: 其根节点所属的子节点中的最大namespace identifier。
  • hash(x): 就是子节点的hash值,和普通区块的类似。

整个结构可以用这个例图来表示:

image

白皮书:https://arxiv.org/pdf/1905.09274.pdf

整个流程就和AR的smartwave很相似:链负责存储数据+共识,执行交给终端。不限开发语言,也没有执行瓶颈,同时,支持节点在下载数据的时候只下载自己应用相关的数据,而不用将整个区块数据都下载下来,提高效率。但是,二者的不同之处在于,celestia将存储和共识的角色再次分离,所以celestia网络里有三种角色:Consensus nodes, Storage nodes, Client nodes。

角色分工及基本流程

为了更好的理解Celestia角色分工和基本运作流程。我们需要从它想达到的目的来讲。

  • 首先,Celestia希望解耦数据可用性和状态转换/计算。为什么不说共识,是因为共识本身确认的就是数据可用性和真实性,所以很难和数据可用性再分开,否则也不算啥区块链了。
  • 其次,只下载自己要的信息用来计算。Celestia希望执行计算的节点在执行计算的时候只检索自己所需要的信息,而不用下载整个区块链的信息去做状态转换。
  • 数据完整性。能够发现数据被销毁会隐藏。
  • 应用状态的主权独立。和第二点类似,执行节点不需要执行其他不相关应用的信息,除非是该应用的依赖应用(例如一个应用需要调用另一个支付功能的应用)。

知道了它的目的,我们就可以来看它的分工

  • 为了保证区块链的共识,所以有专门的共识节点
  • 为了数据可用性,有专门的存储节点
  • 有了上面两个,执行的任务就交给了终端用户,这些都算执行节点。

这些节点以一种点对点的网状拓补结构构成整个celestia网络。需要注意的就是执行节点必须至少链接一个存储节点,以用来执行自己应用的状态转换。

这里需要提一下验证规则。通常来说分为两种:

  • 简单验证规则:通常区块链的验证方法,下载所有信息M,验证Root(M) = mRoot。一旦验证为true,就分发M和区块头h,并且需要存储该M数据至少一定时间t’(网络最大延迟),确保其他节点可以接受到信息(包括其他验证节点和存储节点)
  • 概率验证规则:这就是celestia主推的2D Reed-Solomon。基本原理在上面已经说过。这里再举个官方例子来看下效果。

如果纠删码阈值是1/4,一个块被分为4096片(64*64),则每个节点 只需要下载15个样本就可以有99%的概率确认数据是可用的(具体验证有另一篇纯数学论文来搞,我还没看)。意思是每个节点只用下载0.4%的原始数据片段就可以大概率推断数据是否可用。

当然,概率验证规则要求所有节点下载的数据加起来是必须超过这个纠删码阈值的。例如阈值是50%的话,所有节点下载的数据加起来必须达到原始数据片段的50%以上(非重复),该数据可用性才能被确认,并最终参与出块。

好了,基本的结构了解完毕,我们就需要来看下应用怎么跑在上面了。

应用节点如何工作

首先,我们上面讲过,执行应用是由终端客户来执行的。他们在这个网络中不止是用户,同时也是执行节点。通过传递参数,即对应的hash和nid(namespace id,上面特殊的数据结构,用来获取自己应用namespace相关的信息,而无需获取其他不相干的信息),来获取自己应用执行状态转换所需要的全部信息,在链下执行后将数据上传到链上,以方便其他执行节点获取执行。

当然,因为celestia不负责验证执行结果,所以可能出现违反应用逻辑的交易,所以,这里会加入一个新的函数transition, 应用可以调用这个函数,返回一个状态,以这个状态来确认交易的合法性。

如果交易违法,则整个交易会回滚到原始的state。只有合法的交易才会返回state’。

当然,这里就衍生出一个问题:应用升级。这点其实和smartwave的处理是一样的:

如果一个交易使用了和现有应用不同的逻辑,导致交易没有进行。这时候该节点执行的应用就会被算成一个新的应用,所以并不会影响其他使用原来应用的人。也就是说,不需要硬分叉,应用自己想要升级只要改变本地执行逻辑并且上传注册成新应用即可。不需要硬分叉也就不会影响到其他应用。

还有一个问题我们也需要解决:跨应用调用怎么办?

跨应用调用

想象一下,如果我们使用一个域名注册的合约,我们付费,然后购买域名。由于市面上的支付工具合约已经很多了,所以我们使用的域名注册合约会调用第三方的支付合约来一起完成这个业务流程。这时候,按照Celestia的方式,问题就出现了:由于应用的独立主权,各个应用的状态不会互相干涉,而我们的域名注册应用明显会干涉到其他应用,这时候应该怎么办呢?

  • 前置条件调用:在完成A合约之前,必须先完成B合约(相当于修改了B合约状态)才行。这个时候B合约可以设置专门的函数允许其他合约调用。上面的域名注册合约就属于这一种。对于这种情况,celestia规定在执行A合约的时候不止需要下载A需要的数据,同时还要下载B的数据,执行完B后再执行A。因为A的执行需要依赖B的状态。而执行B合约的节点则不需要下载A的数据,因为B的执行不依赖于A。
  • 后置条件调用:完成A合约之后,需要修改B合约。例如邮件订阅服务,订阅邮件后,需要其他合约来按照订阅服务的状态发送邮件。这个时候就需要B合约在执行的时候下载A合约,执行A合约后再执行B合约。这种调用在celestia的设想里应该很少才对,因为直接修改另一个应用的状态违背了独立主权的初衷。这里就不可避免的需要下载全部数据了。

小结

至此,celestia的主体已介绍完毕。我们可以发现,它和smartwave的高度相似,或者说这也是现在除了常见区块链结构的另一种结构,完全可组合结构。自己只保证数据可用性,不负责执行,也不验证执行,可以和U盘一样,即插即用,哪里需要去哪里(和中继链还不一样,中继链还负责状态转换),天生可跨链,甚至兼容各类跨链原子交互(因为特殊的默克尔树本身存的就是json信息,对内容无要求)。比AR强的一点在于验证有效性的数据量上要少很多,所以还是很有前途的。目前不确定的一点在于代币经济。不知道代币经济会怎么样。

当然,至于celestia+Optimint, Arweave+ KYVE这两者谁能笑到最后,还真不好说,毕竟这两者都是笔者非常喜欢的项目,突出一个Nice

最后的最后,我们来看下对比图,看下celestia的提升有多大。

image

白皮书:https://arxiv.org/pdf/1905.09274.pdf

果然Nice!