1. 引言
Zpoken团队历时8个月开发了NEAR ZK Light Client，开源代码见：
- https://github.com/ZpokenWeb3/zk-light-client-implementation（Rust）
关键依赖为：
- 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应用程序提供支持。文章来源：https://www.toymoban.com/news/detail-500857.html
参考资料
[1] Zpoken团队 2023年6月博客 ZK Light Client. Introduction文章来源地址https://www.toymoban.com/news/detail-500857.html
附录 NEAR系列博客
- Rainbow Bridge：trustless bridge between NEAR and Ethereum
- NEAR Rainbow Bridge代码解析
- NEAR light client
- Aurora与NEAR的关系
- NEAR 智能合约开发
- NEAR协议简介
- NEAR未来两年路线图
- NEAR共识机制
到了这里，关于Zpoken：NEAR ZK Light Client的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
