洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

洒脱喜 发布在 技术指南 30362

写在前面:

想象一下,假设有3种生物,其中A现有体重500 KG,其每年增重50KG,B现有体重600 KG,其每年增重200 KG,C现有体重4.5 KG,并且其每年都恒定在这一数值,那在它们当中,你的第一反应是倾向于接受(A、B还是C)?

而在区块链世界里,比特币便相当于是A,以太坊就相当于B,而C就是本周我们要探讨的来自O(1) LABS的Coda区块链协议,一个被coinbase、Multicoin Capital、DragonFly Capital等圈内知名资本看好的一个区块链项目,其区块链的大小恒定为22 KB(注:不包括客户端)。

在硬核技术文章精选部分,我们还会看到关于比特币奇葩8问、隐私方案ZK² Rollup以及比特币技术周报的内容。

而在文章最后,我们则会分享关于以太坊1.X、以太坊2.0以及Layer 2的一些研发进展。

 

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB (图片来自:tuchong.com)

 

一、22 KB:永不“增肥”的Coda区块链协议是如何炼成的

 

对于比特币、以太坊等加密货币而言,“去中心化”属性是以牺牲“可扩展性”为代价的,因为每个节点在加入网络后都需要处理整个系统的历史记录。而随着时间的推移,验证区块链所有信息所需的时间就会变得非常长,在撰写本文时,比特币的区块链大小超过了270 GB,其包含超过5亿笔交易,而在笔记本上下载所有的比特币历史记录,一般要花费数天的时间。

而拥有大量状态数据的以太坊,则显得更为臃肿,目前一个以太坊档案节点的大小大约达到了4TB,而只保留完整交易历史的GETH全节点则大约达到了300 GB。

而这些资源需求,对于全节点的运行而言是很大的阻力,如下图所示,随着时间的推移,尽管比特币的用户群体在增长,但其全节点的数量并未出现明显增长,而以太坊的全节点数,则出现了明显的下滑趋势。

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

取而代之的是,大多数用户会去运行一个轻型节点(仅验证区块头而不验证交易),或者运行一个超轻节点(不验证任何内容,而依赖于可信服务器),而这对于区块链的去中心化属性而言,都是不利的。

而从以上数据来看,我们可以看到,这一问题对于比特币而言,似乎并没有那么紧迫(硬件和网络也会随时间而提升),但对于以太坊而言,这个问题却显得尤为紧迫,也因此,关于无状态客户端、零知识证明等方向的研究,包括V神在内众多以太坊研究者都是非常关注的。

1、1  关于区块链可扩展性的一些方案

通过比特币和以太坊的例子,我们可以发现,去中心化与可扩展性的权衡一直是一个关键的挑战。

而研究者们也提出了诸多解决方案,而这些方案也都存在着各种权衡,比如闪电网络、Plasma和Rollup方案,它们是将交易从主链转移至链外,然而,这依旧要求节点运行者下载整个区块链,而且闪电网络和Plasma也暴露出来了一些问题,这限制了它们的有效性。

而轻节点,则是另一种可能的解决方案,它们通过下载区块头(block header)来工作,以确定具有最强协议状态的数据库状态Merkle根。

分片,则是另一种增加容量的方案,但是,节点仅对拥有完整数据的分片具有完全确定性。在分片节点没有完整数据的情况下,这些节点本质上必须信任共识节点,并以此作为轻节点运行。此外,该技术的代价是,每次验证者更换时,都必须下载新的分片。

另一种提议的解决方案,是依赖第三方节点,本质上,这种方法需要信任第三方,而这对于抗审查和网络活性而言都是不利的。

1、2 Coda的简洁区块链设计

而来自O(1) Labs团队和纽约大学的研发者,则设计了一种称为Coda的简洁区块链系统,其可以不依赖第三方建议就可以有效地验证系统历史,而这是通过在每个区块中包含简洁证明SNARK来实现的这一目标。

据悉,Coda使用了帐户模型(而不是比特币使用的UTXO模型),其中区块链的当前状态是所有帐户余额的列表。

值得注意的是,Coda每个区块包含的是对此状态的承诺,而不是整个状态,因此,其全节点不必存储整个状态,而仅仅在最新区块头中仅给出状态承诺,而这足以有效验证帐户余额。

在Coda简洁区块链当中,主要存在着三种角色,它们分别是:

  1. 全节点:这一角色会跟踪并验证区块链摘要;
  2. 区块生产者:这一角色会负责生成区块;
  3. 区块链摘要生产者:这一角色会负责生成区块链摘要;
粗略地说,我们希望区块链摘要能够继承底层区块链的有效性。 也就是说,摘要在当且仅当底层区块链有效时才有效。此外,给定一个区块链摘要,我们可通过可提取性的概念得出其底层区块链。

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

 

1、3 基于SNARK的简洁区块链构造

Coda协议的核心,就是zk-SNARK的使用,其充当不可伪造的证书,用于证明计算是正确执行的,而不需要证明整个计算,而通过创建一个SNARK证明,就可以证明区块交易历史记录的准确性,这有效地将区块的大小减小到单个SNARK(大约1kB)。

具体来说,SNARK验证所有规则以达成共识,其确保:

  1. 交易是已签名的;
  2. 交易是有效的;
  3. 共识规则(PoS的可变随机函数等规则);
尽管每个区块大约1kB的数据量,似乎是非常小的,但由于区块链是动态的,就会有新的区块不断添加到链中,而O(1) Labs又希望该区块链在任何时间点都具有简洁性,因此,当区块链“增长”时,我们计算一个新的SNARK证明,它不仅验证新区块,而且还验证现有SNARK证明本身。

简单来说,它就是给多个SNARK创建一个SNARK,这便是用到了SNARK可用于验证任何计算的特性,我们将其称为递归SNARK。

我们可以将这些SNARK证书以递归结构链接在一起,并允许区块链保持约22 KB(SNARK +尾部Merkle路径)的恒定大小。

每次生成新区块时,都会创建一个新的SNARK证书,然后通过创建包含先前SNARK证书的单个SNARK证书,你就可以证明区块链的整个交易历史,也就是说,这允许你从创始区块跃迁至当前状态,同时保持单个SNARK证书的大小。

而一个递归合成zk-SNARK(1kB),它证明了区块链的整个过去历史,以及当前状态merkle根路径(20kB)的有效性,它们一起证明了用户余额的有效性。

从理论上来说,这种单纯的递归组合是可能的,但这存在一个较为致命的缺点,它是非常昂贵的,尽管SNARK验证程序的执行速度非常快(在台式计算机上仅花费几毫秒的时间),但生成SNARK证明却是非常昂贵的。

为了解决上面的这个问题,Coda采用了一种“椭圆曲线循环”(cycle of elliptic curves)技术,其中设计了两种SNARK结构(称为Tick和Tock),以便彼此可有效地验证彼此的证明。

其中,Tick SNARK用于在树的“基础”上验证状态转换,然后,为了使这些证明有效合并,可以使用Tock SNARK对每个证明进行“封装”,再然后,使用Tick SNARK合并两个Tock证明:

  1. 基础SNARK:用于验证单个状态转换的Tick SNARK,我们将其称为“基础”SNARK;
  2. 合并SNARK:用于合并两个Tock证明的Tick SNARK,我们将其称为“合并”SNARK;
  3. 封装SNARK:用于封装Tick证明的Tock SNARK,我们将其称为“封装”SNARK。
为了更好地理解这一点,我们通过一个转换系统来进行说明,在这个系统中,每个状态只是先前状态的哈希H。对于x0和x4,x4 = H(H(H(H(x0)))),SNARK证明树如下图所示:

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

直观上,可以将区块链更新视为状态转换系统,因此,增量可计算SNARK(Incrementally computable SNARK)可以构建简洁的区块链。

1、4 Snark 优化

在本节中,我们将介绍Coda协议采用的两种优化方案,它们分别是“并行扫描状态”和“证明激励”,而它们都是针对以下问题提出的:

问题:如下图所示,计算Si,我们就需要Si-1,因此,SNARK证明计算是存在顺序依赖性的,而结果便是,简单的实现,会遭受计算证明所需时间的阻碍,此外,由于高交易延迟(将交易汇总到SNARK证明中所需的时间)的问题,其对区块提议者的内存要求是很高的。

 洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

解决方案:设计使吞吐量最大化的技术,具体来说,Coda的目标是最大限度地提高网络进行交易处理和验证的速度,从而可吸引更多的用户。

优化技术1:并行扫描状态

我们知道,未经处理的区块链本质上是连续的(即通常不能并行化),但是,由于SNARK的增量可计算性,SNARK工作是可以并行化的。这是导致“并行扫描状态”概念的关键观察结果,在这种情况下,我们将生成区块与计算SNARK证明分离开来。

我们维护一个特殊的队列(称其为工作队列),在队列中,我们提议新的区块。换句话说,它是网络要执行的“ SNARK工作”的队列。

然后,网络会并行计算SNARK证明,计算一棵证明树,其中子叶对应于证明单个区块有效性的证明,而其他证明仅证明其子证明的正确性。最后,根证明认证了与树的子叶相对应的所有区块的正确性,正如下图所示,

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

通过仔细的并行设计,Coda可确保吞吐量完全跟上交易添加的速率。

优化技术2 : 激励证明者

我们把生成SNARK证明的一方,称为SNARK证明者(或简称为SNARKer),然后,为了实现尽可能最小的交易等待时间,就需要用到激励措施。

而Coda提议的激励结构如下:每个将区块推送到工作队列的区块生成者,都需要通过生成验证该区块的证明来弹出一个区块。它会发布一个费用请求以及它生成的SNARK证明,它还包括同一区块中的一笔交易,该交易向计算区块snark的证明者支付费用。通常,这些费用是从区块生产者可能收到的交易费用中支付的。

实质上,每个SNARK都有一个最低价格的拍卖,区块生产者希望尽可能少地向SNARKer支付证明费用,而SNARKer则希望尽可能多地为其证明收取费用。

因此,强制一个区块生产者同时成为另一个区块的SNARK证明者,对于系统的稳定性而言是有帮助的。

而对于给定证明和相关的费用请求,我们就要求对手不能欺骗费用请求,否则,攻击者就可以假扮另一方的证明,以此作为自己的证明或修改某人的费用请求,而知识签名是使其能够实现的密码学原语,在Coda中,其使用了一种基于Bowe–Gabizon模拟可提取SNARK的构造。

1、5 Coda的实验结果和未来的工作

根据论文介绍,Coda协议是通过OCaml语言编写的,而其SNARK则是通过一种称为Snarky的特殊语言编写,其底层gossip协议则是基于libp2p,目前其测试网客户端的大小则大约为900 MB。

而在测试网阶段,一共有85位独立参与者参与了测试,其中有49位是区块生产者,有8个是独立的SNARK证明者。在此期间,共诞生了24826笔交易(其中有17256笔来自社区成员),并生成了53120个区块SNARK证明,总的来说,Coda全节点可实现恒定大小的目标,并且保持在一个可接受的范围之内。

洒脱喜一周评 | 永不“增肥”的区块链,Coda如何将数据压缩成22KB

就目前而言,Coda协议的研究只针对了支付系统,但其概念,理论上也可以扩展至任何图灵完备的功能。例如,可以扩展该框架以支持用户定义的代币和多重签名账户,此外,Coda的路线图还包括升级底层SNARK系统,如具有通用设置的研究。
洒脱喜简评:Coda利用零知识证明技术来实现简洁区块链的思路,固然是值得探索的,但其底层实现却非常复杂,这无疑也会引入一些新的技术问题,因此,要真正安全、可靠地实现一个永远不会长胖的区块链,可能还需要进行大量的研究及实验验证。
 

参考资料

  1. https://codaprotocol.com/blog/coda-protocol-a-succinct-blockchain
  2. Coda: Decentralized Cryptocurrency at Scale  https://eprint.iacr.org/2020/352.pdf
  3. https://github.com/CodaProtocol/coda/releases/tag/0.0.11-beta5
 

二、硬核技术文章一周精选

 

2、1 比特币奇葩8问:为何区块620826比区块620825早1秒诞生

关于比特币,我们有时会遇到一些难以理解的技术问题,例如“新区块比旧区块早1秒诞生”、“同一时间不同全节点的大小不同”等奇葩现象,对于这些问题,就需要求助专业的开发者来帮忙解惑,在本文中,译者便选取了8个相对较有趣的问题,而来自比特币开发社区的大神们也给出了精彩的答案。

文章链接:https://www.8btc.com/article/577324

2、2 隐私方案ZK² Rollup:如何在以太坊上实现高速、廉价的隐私交易

隐私协议团队Aztec正在研发ZK-ZK rollup方案,以在以太坊主网上实现每秒数百笔的隐私交易,同时可降低每笔隐私交易的成本,这篇文章介绍了ZK² Rollup的概念,以及实现它的难点。

文章链接:https://www.8btc.com/article/576962

2、3 比特币技术周报:状态链(statechain)、Schnorr 签名和BIP322三大更新

在这周的比特币技术简报中,我们首先描述了一个旨在将statechain(状态链)部署在比特币上而无需进行共识层变更的提案,然后总结了有关有助于防止差分功耗分析(DPA)攻击的Schnorr nonce生成函数的讨论,以及关于BIP322 通用signmessage的拟议更新。最后,我们还会介绍一些流行比特币基础设施项目的更新内容。

文章链接:https://www.8btc.com/article/577891

 

三、以太坊一周研发更新进展

 

以太坊1.X更新内容:

  1. Alex Stokes解释了以太坊2.0如何从EIP2537中受益;
  2. OpenEthereum有了一个初始Alpha版本;
  3. 无状态以太坊的更新技术树:包括替代同步协议、Witness规范原型、EVM以及二叉树转换;
以太坊2.0更新内容:
  1. Ben Edgington发布关于以太坊2.0的最新更新内容;
  2. Danny Ryan撰写的以太坊2.0进展更新;
  3. 以太坊2.0 第一阶段的漏洞赏金活动已经开始;
  4. 最新的Prysmatic客户端更新,重启测试网以运行最新的规范;
  5. 最新的Lighthouse客户端更新:3倍同步加速,修改规范错误,为多客户端测试网做准备;
  6. 关于以太坊2.0 staking 的用户体验(UX)报告
Layer2更新内容:
  1. 什么是Zeropool?一种以专注隐私的optimistic rollup,其功能类似于混币器;
  2. Dharma正使用ethresearch上发布的规范部署一个rollup链;
本期的分享就到这里啦,下周再见~

本文链接:https://www.8btc.com/article/579234
转载请注明文章出处

评论(1)
登录 账号发表你的看法,还没有账号?立即免费 注册