基于「Attestation」的公共证明服务
最近以太坊开发者盛会ETHDenver正如火如荼地举行，一个略显陌生的词「Attestation」被很多开发者提起。与此同时，以太坊推出了EthereumAttestationService的公共物品标准框架，用于支持创建、验证、撤销各种类型的Attestation。略显绕口地说，Attestation是一个可以信赖的陈述——经由某个背书者认可的关于某个信息的真实性。Attestation框架里存在三类角色，Attestor、Verifier、User。其中，Attestor负责颁发/创建Attestations，这些Attestations的有效性可以由Verfier完成验证，以及被Users结合特定的业务场景使用。?
一个通俗的例子是，大学作为权威组织机构可以为学生颁发毕业证明，该条毕业证明可以被某个在线验证服务核验。核验通过后，某毕业生活动主办方可以根据核验结果用于减免相关的报名费用。进一步地，毕业证明包含了该学生的具体信息，经由大学的私钥签署，可以存放在以太坊链上，任何第三方应用都可以随时访问和查验；毕业证明或者也可以直接存放于链下，保护该学生的隐私。
图片来源于EAS官网文档
EAS的推出，无疑为包括DID、SBT、声誉系统、DeFi等在内的各类Web3.0应用提供了一个重要的公共基础设施，这包括：
任何人都可以定义一套业务模式，从而明确证明的数据类型、格式和组成；这套业务模式可以被其他任意的开发者或者用户使用；
任何人都可以作为Attestor来创建证明；任何人都可以验证一条满足特定模式的链上证明；证明可以存在链上，也可以存于链下；通过相对松散的范式——仅仅依靠两个Solidity合约，EAS即完成了一种去中心化的公共证明服务构建。在一个传统的中心化证明系统内，例如社区运营平台discord，其中心化服务器内存放了海量的关于用户角色的证明数据。这些证明数据不能被自由转移和跨平台使用，同时用户注销账户时也无法被自动撤销。相比之下，EAS的另一个显著好处自然是足够的去中心化，确保了任何链上应用都可以借助EAS的证明数据，提升自身的透明度以及可组合性。从架构上来看，EAS可以直接部署于以太坊主网络，也可以部署于Arbitrum等二层网络。
图片来源于EAS官网
从商业发展的视角看来，早期的EAS或者其他各种Attestation系统会侧重于对链上数据的证明和使用，例如针对空投猎人的反女巫机制，链上治理资格等，同时逐步扩展为与链下数据的交叉融合，实现更加复杂的应用场景，例如物理访问控制、用户增信以及碳足迹等。
数据真实性，一个无法忽视的问题
数据真实性，可以理解为是对数据接受者提供的数据可靠性确认，既包括了完整性确认，即数据在从数据源到接受者的传输过程中未被篡改，以及数据源确认，也就是保证了该数据确实是由特定的数据源提供。
Dataauthenticationconsistsofdataintegrityanddataoriginauthentication.Withdataintegritytherecipientcanbesurethatthedatahasnotchanged.Dataoriginauthenticationprovestotherecipientthatthestatedsenderhasoriginatedthedata.-Chapter3,ZigBeeandIEEE802.15.4ProtocolLayers链上数据证明的普及和推广并不困难，这得益于链上数据的真实性和完整性由区块链天然提供的保证。然而当开发者面对链下数据时，问题会变得有些复杂。一个可能的例子是，当Alice使用一个链上金融应用时，她希望通过提供个人金融信息，来获得链上金融应用给予折扣的借贷服务。核心问题在于，由谁来保证Alice的个人金融信息的真实性？
银行或者相关金融机构可以提供线下的盖戳证明，可是无法快速应用于链上；Alice可以承诺她提供的银行信息真实无误，可是在足够庞大的利益面前，本质上此类承诺并不牢靠；事实上，对于链下数据的核验问题，通常被我们有意或无意地回避了——我们几乎无法检查用户自我填报的数据是否属实，小到年龄和性别，大到用户的链下资产信息。
「zkDataAttestation」，链下数据亦可验证
幸运的是，开发者在处理此类问题时并非束手无策，如果允许引入一些新的密码学。尽管无法限定链下数据的载体形态——文本、图片、视频或者二进制的代码，但是我们可以合理地假设用户基于一些标准的渠道产生链下数据，例如HTTPS/TLS。
Hint:HTTPS是一个是以安全为目标的HTTP通道，在HTTP的基础上通过架设TLS协议层，为互联网应用的通信双方提供数据机密性和完整性保障。
设想这样一个场景，一位罕见病患者Bob在互联网医院存放了个人电子病历，他希望借助charityDAO获得一些救助，用于改善他当前的治疗困境。他可以采取如下步骤：
Bob通过互联网医院的应用程序提供的数据接口获得他的电子病历。Bob将该电子病历发送给CharityDAO的应用进行验证。CharityDAO的应用确认电子病历格式正确，医嘱信息具有专业医师的签名确认。CharityDAO的合约转出资金，发送给Bob的钱包地址。看上去这个过程非常简单，但是仍然存在一些问题：
数据接口通常是基于HTTPS/TLS标准协议，确实可以保障用户获得的电子病历的真实性——来自于这个特定的互联网医院，以及传输过程没有被修改。但是CharityDAO仍然会怀疑用户自己是否对电子病历进行了修改，甚至伪造了医师的签名。罕见病等隐私信息没有被妥善保护。一个直接的想法是，如果有一个「见证者」可以观察甚至参与Bob获取电子病历的全部流程，并且该见证者无法获得电子病历的细节，也许我们就有办法实现关于链下数据真实性的验证。基于零知识证明和安全多方计算的zkDataAttestation就提供了这样一种「见证人机制」。大体上讲，zkDataAttestation在上述模式里引入一个计算节点Pauli技术的话，可以视为一个常规的MPC节点），全流程地参与Bob和医院之间的会话，并对Bob从医院数据接口获取的信息进行「黑盒」式认证和签名。charityDAO可以对Pauli的签名进行验证，从而确认Bob的电子病历数据的真实性——来自于Pauli见证下的某次HTTPS会话。
其中的一些奥妙之处在于：
Pauli会与Bob一起通过特定的安全多方计算协议,来模拟一个TLS的客户端，与医院的数据服务进行通信——如果缺少了Pauli，Bob无法单独完成与医院的数据服务之间的HTTPS会话，既包括HTTPS通道的建立，也包括通信数据的发送和接收。言外之意在于，Pauli无死角地见证了数据获取的全部流程。此外，Pauli尽管深度参与了HTTPS协议通信，但是对医院而言并无感知。
Pauli可以与Bob一起执行一些特定的零知识证明协议，例如交互式零知识证明和非交互式零知识证明，来确保Pauli可以在不了解任何细节的前提下确认Bob的疾病特征满足一定的要求。
这种前置式的检查，极大提升了链下数据的可验证性，并且与当前的EAS框架完全兼容——升级计算节点成为一个标准的以太坊Attestor，通过EAS提供的模式注册服务，支持任何人使用这种特殊的Attestation——zkDataAttestation。在EAS或其他类似的公共证明框架下，将用户链下数据通过可验证和隐私友好的方式转化为标准化的数据证明，从而促进更多的创新应用，例如分布式信用借贷、慈善DAO等。从应用安全的视角来看，任何人都可以运行一个这样的计算节点，为任意的使用方提供链下数据真实性的背书，并且获取相应的服务收益。
受益于HTTPS/TLS协议足够成熟的商业化效应，几乎所有接入互联网的用户数据价值均可以被zkDataAttestation捕获，通过用户的自主授权，分享给链上应用。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。