Midnight 黑客松项目展示私密网络数据与凭证验证

来自 Buenos Aires 的 Midnight 黑客松的开发者展示了两个围绕外部数据与数字凭证构建的可用隐私原型。

其一将 ZK Fetch 与 Reclaim 的认证结合 Midnight Compact，用于确定网络数据的来源。KEEP 通过 Ward 采取不同路径，这是一款移动应用，旨在在不传输持有者全部个人记录的情况下签发并验证凭证。

ZK Fetch Brings Proven Web Data Into Compact

第一个项目解决了当智能合约依赖从外部 API 获取的信息时的常见问题。

HTTPS 保障客户端与服务器之间的通信安全，但接收该信息的合约并不参与最初的连接。因此，开发者使用 ZK Fetch 与 Reclaim Protocol 创建密码学证据，以证明该 HTTPS 交互确实发生在所声明的来源处。

Reclaim 的证明系统与 Midnight Compact 并不直接兼容，因此团队在两者之间加入了公证人层。公证人负责检查并签署证明，而 Compact 内的 Schnorr 签名实现要求至少两名公证人确认，之后该信息才可被接受为合约输入。

该架构以 Strava 数据进行演示。两个账户分别提交了约 3.5 公里与 15 公里的跑步结果，使应用能够在不公开更大数据集的情况下判定胜者。

团队称，外部证明流程耗时约三到四秒，随后还需正常的 Midnight 交易时间。该 Compact 实现仍是 MVP，并计划进行进一步重构。

KEEP Stores Credentials on the Holder’s Device

KEEP 将隐私应用于由大学、学校或公共机构等签发的凭证。

其 Ward 移动应用同时支持持有者与验证方角色。凭证不会分散在多个系统中，而是保留在用户手机上，持有者只需披露特定核验所需的信息。

该系统使用 Merkle 树实现选择性披露，在保持密码学完整性的同时，只需揭示凭证的某个要素。开发者还引入了 Schnorr 签名与 Capacity Exchange 以支持赞助交易，旨在降低终端用户可见的区块链复杂度。

在演示中，一部手机充当验证方并显示 QR 挑战，另一部手机持有凭证。持有者扫描挑战后，流程经由 Midnight 执行并返回凭证有效的确认。

团队报告的处理时间约为 20 秒。验证方获得结果时并未收到持有者的完整凭证记录。

Two Privacy Prototypes Target Different Data Problems

这两个项目针对不同的信息来源。

ZK Fetch 的实现聚焦于来自现有网络服务的数据，为 Compact 合约提供一种方法，用以确认外部声明确实来自预期的 HTTPS 来源。

KEEP 聚焦于直接向个人签发的凭证，使持有者可在本地保留记录，只披露验证方所需的信息。

二者仍处于黑客松阶段的实现。KEEP 团队表示，其 24 小时的构建尚无法完全去中心化，目前使用的 Capacity Exchange 节点在一定程度上是中心化的。开发者称，该节点并不持有为用户 Midnight 交易签名所需的持有者密钥。

这些演示为 Midnight 留下了两种不同的可用原型：其一能够将已被证明的 HTTPS 信息传入 Compact 合约，另一种可以向移动设备签发凭证，并在不向验证方交付完整个人记录的情况下确认某项声明。