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应用程序提供支持。

参考资料

[1] Zpoken团队 2023年6月博客 ZK Light Client. Introduction

附录 NEAR系列博客

• Rainbow Bridge：trustless bridge between NEAR and Ethereum
• NEAR Rainbow Bridge代码解析
• NEAR light client
• Aurora与NEAR的关系
• NEAR 智能合约开发
• NEAR协议简介
• NEAR未来两年路线图
• NEAR共识机制