零知识证明 - 一种新型的Merkle树(Shrubs)

区块链资讯星想法2019-10-11 11:11:26  阅读 -评论 0

这几天在日本大阪正在举办Devcon 5。议题中有个topic吸引我的眼球:

零知识证明 - 一种新型的Merkle树(Shrubs)

以太坊上,传统的Merkle树(深度为33)添加一个叶子节点,除了计算33次Hash函数外,还需要更新33个节点(也就是需要读并且更新33个存储空间)。而更新一个节点的存储费用是昂贵的。更新33个256bit的存储,大约需要180w的GAS费用。
Shrubs就提出了一种Merkle树的变种,每次添加一个叶子节点,只需要O(1)次存储更新。这种变种的Merkle树,不只是用一个树根节点来“代表”整棵树。而是用一系列节点(个数等于深度)来”代表“整棵树,保证所有的叶子节点都能”索引“到这些节点。在变种的Merkle上,每一层选择一个节点。在添加叶子节点的时候,在不破坏其他“子树”的根的前提下,只要更新到离该叶子节点最近的子树根即可。
可以想象成,Shrubs的变种Merkle树,其实是由一棵棵的子树的树根组成。这些子树能覆盖所有的已经添加的叶子节点。这些子树的树根可以代表一棵完整的Merkle树(唯一性)。而且通过子树的路径证明,就能证明某个叶子节点在这颗完整的Merkle树上。因为每次只需要更新子树的树根,所以,每次添加叶子节点只需要一次节点数据的更新。
这些子树的树根,又能推导出整个merkle树最右边的path。这也是,Shrubs的说明中,用merkle树的最右边path代表merkle树的原因。
1. 核心算法


Shrubs的变种Merkle树的算法原型昨天更新到Github上,地址如:https://github.com/celo-org/shrubs
核心算法逻辑在contracts/MerkleTreeLib.sol中的insert和verify函数。
1. 插入节点
insert函数实现了叶子节点的插入逻辑。filled_subtrees就是每个选择的子树的根。insert函数的主要逻辑,就是选择子树,更新子树的根。
     function insert(uint256 leaf) internal {
         uint32 leaf_index = next_index;
         uint32 current_index = next_index;
         next_index += 1;
 
         uint256 current_level_hash = leaf;
         uint256 left;
         uint256 right;
 
         bool all_were_right = true;
         for (uint8 i = 0; i < levels; i++) {
             if (current_index % 2 == 0) {
                 left = current_level_hash;
                 right = zeros[i];
                 filled_subtrees[i] = current_level_hash;
                 break;
             } else {
                 left = filled_subtrees[i];
                 right = current_level_hash;
             }
             current_level_hash = HashLeftRight(left, right);
             current_index /= 2;
         }
         tree_leaves.push(leaf);
     }
filled_subtrees采用空节点初始化。在新插入一个节点时,找到它最低的左节点作为选择的子树,并更新树根。current_index是每一层上节点的序号。选择左边节点是通过current_index%2==0实现。
以深度为4的Merkle树为例,添加第一个叶子节点后,各个子树的树根如下(青色节点是初始化的filled_subtrees节点,蓝色是更新的节点):
零知识证明 - 一种新型的Merkle树(Shrubs)

添加第二和三个叶子节点分别如下:

零知识证明 - 一种新型的Merkle树(Shrubs)

整个添加过程如下面动图效果(橙色连线代表hash计算):

零知识证明 - 一种新型的Merkle树(Shrubs)

1.2 验证节点
verify函数是验证某个叶子节点在Merkle树上的示例。只要能给定一条路径,能计算出一个子树根即可。
function verify(uint256 leaf, uint256[] memory path, uint32 leaf_index) internal {
       uint32 current_index = leaf_index;
       uint256 current_level_hash = leaf;
       uint256 left;
       uint256 right;
       for (uint8 i = 0; i < levels; i++) {
         if (mode == 0 && filled_subtrees[i] == current_level_hash) {
           emit LeafVerified(leaf, leaf_index, i, true);
           return;
         }
         if (current_index % 2 == 0) {
           left = current_level_hash;
           right = path[i];
         } else {
           left = path[i];
           right = current_level_hash;
         }
         current_level_hash = HashLeftRight(left, right);
         current_index /= 2;
       }
     }
 }
2. 性能分析
2.1 数据更新
Shrubs变种Merkle树,每次添加节点,只需要更新一个子树的树根。从数据更新角度,算法复杂度O(1)。
2.2 hash计算
从hash计算的角度,在添加左节点时,无需hash计算。在添加右节点时,hash计算和选择的子树深度相等。越靠右的节点,子树选择也高,hash计算也越多。即使这样,也比传统的Merkle树计算量小。
假设Merkle树的树高是n,则传统Merkle树添加所有的叶子节点,需要2^n*n次计算。Shrubs变种Merkle树添加所有的叶子节点,只需要(1+2+...+n) = (n*(n-1))/2次计算
3. 测试结果
在Devcon5上,Shrubs公开了变种Merkle树的测试结果。叶子插入的gas消耗,平均情况下,9.6w。
零知识证明 - 一种新型的Merkle树(Shrubs)

图中,Shrubs最坏情况下的GAS消耗应该不是168w,应该在40w左右。
如果使用Groth16零知识证明的话,大约需要不到50w的GAS(EIP1008情况下)。
零知识证明 - 一种新型的Merkle树(Shrubs)

值得一提的是,使用Groth16零知识证明,需要将所有的子树的树根作为public input。
总结:
为了解决以太坊智能合约中Merkle树更新存储开销较大的问题,Shrubs提出了一种新型的Merkle树变种。这种变种的Merkle树用多个子树的树根来代表一个Merkle树。每次添加一个叶子节点,只需要O(1)次存储更新,平均情况下,只需要9.6w的GAS。使用Groth16算法,证明叶子节点在树上,也只需要不到50w的GAS。

声明:链世界登载此文仅出于分享区块链知识,并不意味着赞同其观点或证实其描述。文章内容仅供参考,不构成投资建议。投资者据此操作,风险自担。此文如侵犯到您的合法权益,请联系我们kefu@lianshijie.com

参与讨论 (0 人参与讨论)

相关推荐

Filecoin - testnet3中Sector处理逻辑变化

目前测试网络也进入了testnet3阶段。Filecoin - Lotus存储证明了什么?本文介绍一下testnet3的Sector处理的逻辑。相关的接口函数在filecoin-proofs/src/api/seal.rs文件中的seal_pre_commit_phase1和seal_pre_commit_phase2函数。Filecoin - 为什么SDR这么慢?Sector证明过程和零知识证明的过程密切相关。

浅析Ethash共识算法

浅析Ethash共识算法

以 Ethereum 的 Ethash 为例,我们将从 Ethash 算法、DAG 的生成几个方面逐一介绍。Ethash 简介Ethash是 Ethereum 1.0基于 POW的共识引擎,也叫以太的挖矿算法。Ethash 算法需要区块头和 DAG,通过不停尝试不同的 nonce,来计算满足难度值要求的hash。

ETH 核心开发者会议讨论 ProgPow 漏洞问题,临时决定将挖矿算法重新定义为 Ethash 2.0

讨论最初以 ProgPow 的技术可行性为中心,并引用了独立审核员和研究人员概述的两个漏洞。一些开发人员认为,对 ProgPow 的异议足以证明完全否决该提案是合理的。

SHA-256算力激增:BCH增长4倍,BTC高达48 Exahash /s

SHA-256算力激增:BCH增长4倍,BTC高达48 Exahash /s

SHA-256是一种用于挖BCH/BTC及其他一些加密货币的挖矿算法,去年SHA-256挖矿的算力获得了指数级增长。2018年以来加密货币市场一直在下跌,但熊市似乎并没有影响到算力,算力反而出现了大幅增长。 去年SHA-256算力出现大幅增长 SHA-256挖矿指的是计算设备解决计算问题找到区块,并验证和打包最近发生的区块链交易的过程。挖到区块的矿工将会获得加密货币和

根本上实现 ASIC resistant:Truehash 算法简介

根本上实现 ASIC resistant:Truehash 算法简介

众所周知,Truechain 采取的是混合共识的共识机制,分为 PoW 运行的 snailchain 与 PBFT 运行的 fastchain。PBFT 主要负责处理交易,PoW 主要负责出块。 PoW 算法最初是由 Cynthia Dwork 与 Moni Naor 于 1993 年提出来的。当时主要的应用场景是反 ddos 攻击和反 email spam。1999 年,Jac

经典hash算法比较和C语言实现

经典hash算法比较和C语言实现

常用的字符串Hash函数还有ELFHash,APHash等等,都是十分简单有效的方法。这些函数使用位运算使得每一个字符都对最后的函数值产生影响。另外还有以MD5和SHA1为代表的杂凑函数,这些函数几乎不可能找到碰撞。 常用字符串哈希函数有BKDRHash,APHash,DJBHash,JSHash,RSHash,SDBMHash,PJWHash,ELFHash等等。对于以上几种哈希函数,我对其

hash16日:DICE 明天有望在测试网络发布

  DICE 的开发人员 Hash 16 日在论坛中说,明天有望在测试网络发布。   “It's nice to see so much interest!(很开心看到大家如此关心)   The dice is almost there.( DICE 已近在咫尺)   Tomorrow, hopefully, we'll release on testnet.(明天有望在测试

信息网站Longhash新增比特币地址查询功能

信息网站Longhash新增比特币地址查询功能

区块链和加密货币媒体和数据分析网站Longhash最近推出一个比特币地址查询功能。用户可以通过比特币地址,查询到这笔比特币的来源,目的是让投资者、监管者和公众可以更安心。 Longhash推出比特币地址查询功能 “与传统的金融系统相比,” Longhash解释说,“加密货币似乎是令人难以捉摸的。比特币的匿名性吸引了犯罪分子。虽然这样的说法可能会激怒比特币人,但是也许事实如此,该网站相信,加强透明化

麦妖榜
更新日期 2019-09-03
排名用户贡献值
1牛市来了30910
2BitettFan24187
3等待的宿命23810
4区块大康20369
5六叶树20310
6linjm122719429
7天下无双16192
8lizhen00215280
9让时间淡忘14586
10yelanyi050511349
返回顶部 ↑