10 个稳定版本

3.14.0 2024 年 6 月 4 日
3.13.0 2024 年 4 月 26 日
3.7.0 2024 年 2 月 13 日
3.5.0 2024 年 1 月 26 日

#9#merkle-root

Download history 7/week @ 2024-04-29 6/week @ 2024-05-27 174/week @ 2024-06-03 8/week @ 2024-06-10 23/week @ 2024-07-01

854 每月下载量
用于 2 crates

Apache-2.0

52KB
1K SLoC

白名单 MerkleTree 合约

一个依赖于 MerkleTree 数据结构来验证地址是否在白名单中的白名单合约。

仅在状态中存储 Merkle 根(以及可选的树 URI)。可以通过提交用户地址和 Merkle 证明的十六进制编码列表来验证包含情况。这种方法在存储阶段可以显著减少 gas 使用量,但缺点是实际数据在链下,并且依赖于第三方提供包含证明。

与标准基于映射的白名单相比,包含操作稍微复杂且成本更高。合约使用 Sha256 对连接的证明进行哈希。在连接之前按字节级别对哈希进行排序,这通过不需要提交叶子位置显著简化了验证过程。

重要:请确保您构建 Merkle 树的算法也排序哈希。参见 rs-merkle 库的扩展示例在 tests/hasher.rs

Gas 使用量

将基于 MerkleTree 的白名单合约和更新后的 mint 合约都部署到了测试网,以测量生产环境中的实际 gas 使用量。合约使用了两种不同的白名单大小进行了实例化和测试:70391,750,400 条条目。

实例化

由于只需要在合约状态中存储默克尔树根,因此使用较小和较大列表大小的白名单之间没有区别,它们都消耗190,350单位气体。

铸造

检查地址是否包含在默克尔树中所需的哈希操作数最多为Math.ceil([ log₂N ]],在某些情况下甚至更少,具体取决于树中叶子的深度。

对于包含704条记录的较小树,我们不得不提交8个哈希证明,一个示例铸造交易消耗了635,345单位气体。

包含约9000万条记录的较大树使用了647,448单位气体,并且只需要24个证明(最多27个,如果叶子更深)。

从计算8个证明到计算24个证明(+16个)只额外消耗了8千单位气体。请注意,再增加16个证明可以使我们检查包含1万亿个地址的树中的包含情况。

依赖关系

~5.5–8MB
~185K SLoC