ZK Proof of Email：通往decentralized identity之路

1. 引言

由0xPARC内的Signed Data Group研究团队主导。
开源代码见：

• https://github.com/zk-email-verify（Rust+JavaScript）【借助Halo2/Circom/Snarkjs】

Demo体验见：

• https://zkemail.xyz/

主要文档见：

• https://zkemail.xyz/docs#/

2. 如何trustlessly verify identity on chain?

验证某data确实来源于某source的方法之一是：source端采用私钥签名，接收端采用相应的公钥进行验签。

对于emails，有名为DKIM的算法（用于email signatures），可用于链下信息验证。
你所收到的每封email均由sending domain签名，仅需在链上验证该签名，但是实际实现存在以下3方面的问题：

• 1）calldata太昂贵：受限于data规模，链上验证gas开销昂贵，因calldata每1个字节需16gas，对应50kB data的验证开销将难以承受。L2或侧链也并未解决该问题：无论如何，都需要向提交到L1的calldata支付费用。
• 2）想具有可控的隐私：签名中可能包含一些不想公开的私人信息，如仅想公开twitter账号，而不想公开邮箱地址。目前zk-EVM并未实现隐私策略。
• 3）算法本身太昂贵：验签算法的复杂度决定其是gas-intensive的，需在Solidity中做大量（不同于以太坊filed的）field exponentiations运算。不过，该问题可迁移在L2/L3层实现。

3. 构建ZK Proof of Email

实际实现ZK Proof of Email时，有2个关键要素：

• 1）constant time
• 2）space verification cost on-chain：类似zkEVM对calldata进行哈希压缩，并根据需要有选择的隐藏或公开任何数据。

3.1 DKIM email签名

DKIM email签名算法为：

• rsa_sign(sha256(from:<>, to:<>, subject:<>, ,…), @mit.edu key)

如用户y（邮箱为y@mit.edu），想确认其收到的声称为x@mit.edu的邮件，用户y仅需要提供相应的email header，然后获取mit.edu的public key（在DNS TXT中有形如publickey.mailserver.mit.edu），最后验签。

为实现ZK属性，要求”整个proof generation scripts + website“ 均100%运行在客户端。

3.2 ZK Circuit

构建的ZK Circuit：

• 1）ZK Proof Public:

  • sender domain and receiver domain
  • the RSA modulus
  • the masked message (can be domains, or part of message)
  • the DNS Public Key：每6个月到2年会轮换，需从DNS records中获取DNS keys。当前是将其以明文方式置于合约内，未来希望以DNSSEC websites的方式来trustlessly验证。

• 2）ZK Proof Private:

  • the DKIM signature from the mail server
  • the length of the pre-hashed message data
  • the raw message data

• 3）ZK Circuit Checks:

  • sha256 and RSA both verify
  • the message is well structured via regex
  • the chosen regex state matches the mask provided

• 4）Contract Checks:

  • sender domain == receiver domain
  • claimed RSA key == DNS-fetched/cached RSA key

注意，当前阶段，每个应用有各自的regex string，从而有各自的verifier function。如，若想要Twitter verification，则有不同于company domain verification的流程。

4. 技术创新

为高效进行ZK email verify，需确保：

• 1）适于所有email，只要具有合理的长度；
• 2）不可能通过黑客攻击系统来伪造email属性。

为此，实现了2种新的电路类型：

• 1）以circom实现了arbitrary length
• 2）以circom实现了regex

4.1 Arbitrary length SHA256 hashing

为让同一verifier circuit可验证任意length messages，从而适于任意可能的email length：

• 修改了circomlib SHA256电路，使其适于任意长度的messages。未来将开源并通过PR提交给circomlib。

不过，若email很长，则circuit也可能infeasibly long（所有的HTML tags也都作为signed body的一部分，这部分单独将增加800万约束）。

@viv_boop提示到：

• 若想要证明接近email end的某value，可提供该哈希函数的partial preimage，并在ZK-SNARK中运行最后少量几个hashing blocks。原因在于，需要知道the full pre-image来计算任意partial hash。【该技巧可用于任意sponge-based或Merkle-Damgard based哈希函数，使得验证knowledge of hash preimage更快。】

4.2 Regex (Deterministic Finite Automata) in ZK

如何阻止某人将自己的fields填充到电子邮件的主题，比如说，将主题发送为“subject: to: aayushg@mit.edu“–如何防止屏蔽解析器混淆真实收件地址？

因此，需在zk-SNARK内部按email client的方式对field进行解析，幸运的是\r\n是标准的fields分隔符，而用户若输入\r\n会仍显示为\r\n，因此，结合text matching可高效检查email field的有效性。

为支持在circom中做任意regex checks，最有效的方式是自动生成circom code。

regex的工作方式为deterministic finite automata：

• 为基于DAG的数据结构，通过traversing the right edge of the DFA at each character transition，来updates the regex “state” associated with each character in the string。若DFA最终有success state，则说明regex匹配。

参考资料

[1] 2022年12月博客 ZK Email