1. 引言
Zpoken团队历时8个月开发了NEAR ZK Light Client，开源代码见：
关键依赖为：
- https://github.com/mir-protocol/plonky2（Rust）
- https://github.com/dalek-cryptography/curve25519-dalek（Rust）
NEAR Protocol由epoch组成，每个epoch都有 一个由100个validators和producers 组成的预设列表，这些validators和producers 被授权可产块、验证区块和固化区块。每个epoch由43,200个区块组成，每个区块会commit 用于第N+2个epoch的validator列表哈希值。因此，为了验证epoch N中农的某个区块是否由正确的validator列表签名，则必须参考N-2 epoch的区块，并验证其中的committed next_bp_hash（假设已在N epoch中已验证该（N-2 epoch的）区块已固化。）
当证明某epoch区块时，计算区块哈希时，需使用：
- 包含了前一区块哈希的区块头数据来
- next_bp_hash
- 该区块内关于状态转换的其它相关信息
同时，还需计算该区块的签名，并验证其公钥已在N-2 epoch commit。这些操作需将Plonky2电路分解为:
- SHA-256电路
- SHA-512电路
- Ed25519电路
当前https://github.com/ZpokenWeb3/zk-light-client-implementation的NEAR ZK Light Client可确保区块哈希计算的正确性：
- 证明了单个区块或一序列区块的哈希计算正确性
- 证明签名验证有效
- 证明 验证签名对应的validator已在epoch N-2的某区块内的committed validator列表内。
当前Zpoken团队正在致力于将所有签名证明合并到快中，并验证相应签名者是否包含在next_bp_hash中。一旦实现了该目标，将转而更新配置，以基于相同的epoch块证明方法来证明常规块，并转向链上验证，为具有可验证数据的web3应用程序提供支持。
参考资料
[1] Zpoken团队 2023年6月博客 ZK Light Client. Introduction
扫一扫
759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
