以太坊 EAS 框架的发布，为链上应用发展提供了标准化和开放式的链下 / 链上证明数据。相比链上数据天然被信任，链下数据的采纳需要结合 ZK 和 MPC 等技术提供真实性保证。

撰文：PADO Labs

基于「Attestation」的公共证明服务

最近以太坊开发者盛会 ETHDenver 正如火如荼地举行，一个略显陌生的词 「Attestation」（证明）被很多开发者提起。与此同时，以太坊推出了 Ethereum Attestation Service（EAS，以太坊证明服务）的公共物品标准框架，用于支持创建、验证、撤销各种类型的 Attestation。略显绕口地说，Attestation 是一个可以信赖的陈述——经由某个背书者认可的关于某个信息的真实性。 Attestation 框架里存在三类角色，Attestor、Verifier、User。其中，Attestor 负责颁发 / 创建 Attestations，这些 Attestations 的有效性可以由 Verfier 完成验证，以及被 Users 结合特定的业务场景使用。 

一个通俗的例子是，大学（Attestor）作为权威组织机构可以为学生（Recepient）颁发毕业证明（Attesation），该条毕业证明可以被某个在线验证服务（Verifier）核验。核验通过后，某毕业生活动主办方（User）可以根据核验结果用于减免相关的报名费用。进一步地，毕业证明包含了该学生的具体信息，经由大学的私钥签署，可以存放在以太坊链上（详见此处），任何第三方应用都可以随时访问和查验；毕业证明或者也可以直接存放于链下，保护该学生的隐私。

图片来源于 EAS 官网文档

EAS 的推出，无疑为包括 DID、SBT、声誉系统、DeFi 等在内的各类 Web 3.0 应用提供了一个重要的公共基础设施，这包括：

任何人都可以定义一套业务模式（Schema），从而明确证明的数据类型、格式和组成；这套业务模式可以被其他任意的开发者或者用户使用；

• 任何人都可以作为 Attestor 来创建证明；

• 任何人都可以验证一条满足特定模式的链上证明（On-chain Attestation）；

• 证明可以存在链上，也可以存于链下；

通过相对松散的范式——仅仅依靠两个 Solidity 合约（模版注册合约 + 证明合约），EAS 即完成了一种去中心化的公共证明服务构建。在一个传统的中心化证明系统内，例如社区运营平台 discord，其中心化服务器内存放了海量的关于用户角色的证明数据。这些证明数据不能被自由转移和跨平台使用，同时用户注销账户时也无法被自动撤销。相比之下 ，EAS 的另一个显著好处自然是足够的去中心化，确保了任何链上应用都可以借助 EAS 的证明数据，提升自身的透明度以及可组合性。从架构上来看，EAS 可以直接部署于以太坊主网络（L1），也可以部署于 Arbitrum 等二层网络。

图片来源于 EAS 官网

从商业发展的视角看来，早期的 EAS 或者其他各种 Attestation 系统会侧重于对链上数据的证明和使用，例如针对空投猎人的反女巫（sybil resistance）机制，链上治理资格（eligibility）等，同时逐步扩展为与链下数据的交叉融合，实现更加复杂的应用场景，例如物理访问控制、用户增信以及碳足迹等。

数据真实性，一个无法忽视的问题

数据真实性，可以理解为是对数据接受者提供的数据可靠性确认，既包括了完整性确认，即数据在从数据源到接受者的传输过程中未被篡改，以及数据源确认，也就是保证了该数据确实是由特定的数据源提供。

Data authentication consists of data integrity and data origin authentication. With data integrity the recipient can be sure that the data has not changed. Data origin authentication proves to the recipient that the stated sender has originated the data. - Chapter 3, ZigBee and IEEE 802.15.4 Protocol Layers

链上数据证明的普及和推广并不困难，这得益于链上数据的真实性和完整性由区块链天然提供的保证。然而当开发者面对链下数据时，问题会变得有些复杂。一个可能的例子是，当 Alice 使用一个链上金融应用时，她希望通过提供个人金融信息（例如开户银行、开户时间以及账户流水），来获得链上金融应用给予折扣的借贷服务。核心问题在于，由谁来保证 Alice 的个人金融信息的真实性？

• 银行或者相关金融机构可以提供线下的盖戳证明，可是无法快速应用于链上；

• Alice 可以承诺她提供的银行信息真实无误，可是在足够庞大的利益面前（例如假冒他人身份借助闪电贷实现非法获利），本质上此类承诺并不牢靠；

事实上，对于链下数据的核验问题，通常被我们有意或无意地回避了 —— 我们几乎无法检查用户自我填报的数据是否属实，小到年龄和性别，大到用户的链下资产信息。

「zkData Attestation」，链下数据亦可验证

幸运的是，开发者在处理此类问题时并非束手无策，如果允许引入一些新的密码学。尽管无法限定链下数据的载体形态——文本、图片、视频或者二进制的代码，但是我们可以合理地假设用户基于一些标准的渠道产生链下数据，例如 HTTPS/TLS。

Hint: HTTPS 是一个是以安全为目标的 HTTP 通道，在 HTTP 的基础上通过架设 TLS 协议层，为互联网应用的通信双方提供数据机密性和完整性保障。

设想这样一个场景，一位罕见病患者 Bob 在互联网医院存放了个人电子病历，他希望借助 charityDAO 获得一些救助，用于改善他当前的治疗困境。他可以采取如下步骤：

• Bob 通过互联网医院的应用程序提供的数据接口获得他的电子病历。

• Bob 将该电子病历发送给 CharityDAO 的应用进行验证。

• CharityDAO 的应用确认电子病历格式正确，医嘱信息具有专业医师的签名确认。

• CharityDAO 的合约转出资金，发送给 Bob 的钱包地址。

看上去这个过程非常简单，但是仍然存在一些问题：

• 数据接口通常是基于 HTTPS/TLS 标准协议，确实可以保障用户获得的电子病历的真实性——来自于这个特定的互联网医院，以及传输过程没有被修改。但是 CharityDAO 仍然会怀疑用户自己是否对电子病历进行了修改，甚至伪造了医师的签名。

• 罕见病等隐私信息没有被妥善保护。

一个直接的想法是，如果有一个「见证者」可以观察甚至参与 Bob 获取电子病历的全部流程，并且该见证者无法获得电子病历的细节，也许我们就有办法实现关于链下数据真实性的验证。基于零知识证明和安全多方计算的 zkData Attestation 就提供了这样一种「见证人机制」。大体上讲，zkData Attestation 在上述模式里引入一个计算节点 Pauli（如果读者了解安全多方计算（MPC）技术的话，可以视为一个常规的 MPC 节点），全流程地参与 Bob 和医院之间的会话，并对 Bob 从医院数据接口获取的信息进行「黑盒」式认证和签名。charityDAO 可以对 Pauli 的签名进行验证，从而确认 Bob 的电子病历数据的真实性——来自于 Pauli 见证下的某次 HTTPS 会话。

其中的一些奥妙之处在于：

Pauli 会与 Bob 一起通过特定的安全多方计算协议, 来模拟一个 TLS 的客户端，与医院的数据服务进行通信——如果缺少了 Pauli，Bob 无法单独完成与医院的数据服务之间的 HTTPS 会话，既包括 HTTPS 通道的建立，也包括通信数据的发送和接收。言外之意在于，Pauli 无死角地见证了数据获取的全部流程。此外，Pauli 尽管深度参与了 HTTPS 协议通信，但是对医院而言并无感知。

Pauli 可以与 Bob 一起执行一些特定的零知识证明协议，例如交互式零知识证明（interactive zero-knowledge proofs, iZK）和非交互式零知识证明（non-interactive zero-knowledge proofs, NIZK），来确保 Pauli 可以在不了解任何细节的前提下确认 Bob 的疾病特征满足一定的要求。

这种前置式的检查，极大提升了链下数据的可验证性，并且与当前的 EAS 框架完全兼容 —— 升级计算节点成为一个标准的以太坊 Attestor，通过 EAS 提供的模式注册服务，支持任何人使用这种特殊的 Attestation——zkData Attestation。在 EAS 或其他类似的公共证明框架下，将用户链下数据通过可验证和隐私友好的方式转化为标准化的数据证明，从而促进更多的创新应用，例如分布式信用借贷、慈善 DAO 等。从应用安全的视角来看，任何人都可以运行一个这样的计算节点，为任意的使用方（个人、合约或在线服务等）提供链下数据真实性的背书，并且获取相应的服务收益。

受益于 HTTPS/TLS 协议足够成熟的商业化效应，几乎所有接入互联网的用户数据价值均可以被 zkData Attestation 捕获，通过用户的自主授权，分享给链上应用。