GCC 作为公共物品捐助基金,一直致力于在最早期支持最新的技术并推动该技术的商业化落地。对于 zkP2P 的资助是典型案例。
zkP2P 使用了一种名为 zkTLS 的底层技术,该技术是零知识证明(ZK)和 多方安全计算(MPC)技术的最新应用,该技术允许任何智能合约验证来自链下第三方 API 提供的数据,这意味着我们可以基于 zkTLS 技术创造一系列新的公共服务应用。但 zkTLS 诞生后,如同大部分密码学技术,大量的团队和 VC 都专注在支持基础设施的发展,而 GCC 意识到对于基础设施的支持是必要的,但对于可能的技术落地的支持也是必要的。
GCC 选择资助 zkP2P 不仅因为其技术创新性,更因为该项目的价值观与 GCC 的公共物品理念高度契合。zkP2P 高度 重视用户隐私,开源了所有的 相关代码库,致力于构建一个真正属于用户的去中心化金融基础设施。这种开放性和公共性正是 zkTLS 技术最珍贵的特质,也是 GCC 看好其未来前景的根本原因。在研究 zkTLS 过程中,GCC 与包括 zkP2P 创始人在内的很多 zkTLS 生态系统内的创业者进行了深入交流,本文旨在分享这些洞察,推动更多人认识到 zkTLS 作为 Web3 公共基础设施的巨大潜力。
本节内容主要为读者提供一些有关 zkTLS 的背景知识,特别是 zkTLS 是如何通过 zk 与 MPC 技术解决在链上验证来自链下第三方 API 数据的技术原理。
要了解 zkTLS 技术,那么我们首先需要知道 TLS 技术的具体原理。
当我们打开任何一个使用 https 开头的网站时,浏览器和与网站服务器进行一次密钥交换,密钥交换的结果是浏览器和服务器会协商获得一个共享密钥,之后浏览器和网站服务器所有通信都使用该共享密钥加密,所以即使有攻击者在通信过程中截获了数据,由于截获数据的攻击者没有浏览器和服务器协商获得的共享密钥,所以攻击者仍无法解密内容。简单来说,TLS 使用了密钥协商获得共享密钥加密流量实现了浏览器和服务器之间的安全通信。
但 TLS 技术没有提供 不可否认性 (non-repudiation),简单来说,就是接收数据的人无法确定数据确实来自于服务器。如图,以 Alice 与服务器之间的通信为例,虽然 Alice 与服务器之间的通信是使用密钥签名的,但是 Bob 仍无法相信 Alice 给自己的数据确实来自服务器,因为数据签名所使用的密钥是 Alice 和服务器之间协商获得的,Alice 知晓共享密钥,所以 Alice 可以任意构造数据并使用已知的共享密钥签名,然后将该数据发送给 Bob。此时 Bob 无法判断来自 Alice 的数据是真正来自服务器还是 Alice 自行篡改后签名的。

所以,在使用 TLS 技术的时候,我们需要引入一些机制来保证 Alice 在与服务器通信结束后无法篡改数据内容和数据的签名。目前常用的方案有三种:
下面我们会一一介绍每一个技术方案的实现。
方案一: 基于 可信执行环境(TEE)
可信执行环境(TEE)的技术方案是一种由硬件厂商提供的特殊的执行环境,在此执行环境内发生的所有运算都无法被外界所观察和篡改。而且 TEE 硬件内部包含来自硬件厂商的私钥,TEE 的所有输出都会使用该密钥签名,任何第三方都可以使用公钥对 TEE 的输出进行验证。
如果读者希望了解更多关于 TEE 的知识,可以阅读 Securing TEE Apps: A Developer's Guide。
从实现和效率角度来讲,使用 TEE 实现 zkTLS 方案是目前相对最为简单有效的一种方式。使用 TEE 硬件发起 https 请求,Alice 就可以向 Bob 证明请求数据是正确的,同时确实来自服务器并没有被篡改。
举一个简单的例子:
但是,相比于直接将账户和密码发送给 TEE 设备,更好的方案是 Alice 登录银行网站并把代表登录状态的 auth token 发送给 TEE,这样即使 TEE 被攻破,Alice 可以撤销 auth token 授权保证资产安全。
从用户体验的角度来讲,TEE 是用户体验最好的方案之一。我们可以开发 APP 要求用户在 APP 内登录某一个网站,APP 在登录过程中截获登录的 auth token,后续过程是不需要用户进一步介入的,TEE 硬件就自动抓取数据并生成签名。目前 zkP2P 开发团队正在构建基于 TEE 的 APP 以进一步优化用户体验。
方案二:基于 多方安全计算(MPC)
在本节的最初阶段,我们提到 Bob 无法相信 Alice 的原因是 Alice 与服务器之间交互获得的共享密钥是只有 Alice 和服务器知晓的,Bob 并没有参与密钥协商过程,所以 Bob 无法相信 Alice 使用共享密钥加密和签名的数据。
MPC 是一种多方安全计算的技术,该技术可以使得 Bob 参与 Alice 和服务器之间 TLS 密钥生成的过程。
基于 MPC 的 zkTLS 实现方案以 PSE 团队开发的 tlsnotary 为代表,后续所有的描述都以 tlsnotary 的实现为例。
在 tlsnotary 方案里,多加了一个「见证人」Notary:
假如 Alice 需要向 Bob 证明 TLS 通信结果,Alice 只需要提供服务器的响应数据和 Notray 的提供的证明。假如 Bob 认为 MPC 节点没有与 Alice 串通,那么 Bob 可以在验证 Notray 证明后相信 Alice 给定的输出。当然,假如 Alice 与 Notray 串通,那么 Bob 仍可能被欺骗。
但 MCP 方案有比较明显的劣势,根据 zkP2P 开发者反馈,使用 tlsnotary 构建协议存在用户体验较差的问题,首先 MPC 过程会产生较大的开销,用户可能面临长时间的延迟,同时协议过程也容易出现失败的情况。zkP2P 的开发者正在等待 tlsnotary 等基于 MPC 的 zkTLS 技术进一步发展。
方案三: 代理模型
代理模型也引入了第三方参与 TLS 过程,但不同于基于 MPC 的方案,参与 TLS 通信过程中的第三方比并不负责具体的共享密钥生成而是只负责转发 TLS 流量。
仍以 Alice 和 Bob 为例,Alice 访问服务器之间的所有交互都会通过代理服务器。代理服务器在通信结束后会生成证明,该证明用于确认 Alice 和服务器之间确实存在加密通信。Alice 在通信结束后需要创建一个 zkproof 来解密来自服务器的响应。zk 证明的内容是 “我知道一个解密 TLS 流量的共享密钥,但我不会告诉你共享密钥本身。”
假如 Alice 需要向 Bob 证明通信结果,Alice 需要发送给 Bob 以下几个数据:
对于 Bob 而言,Bob 可以相信 TLS 数据确实来自目标服务器,并且相信 Alice 给出的明文数据。而 Alice 在此过程中并没有暴露自己 TLS 通信过程中的共享密钥。
代理模型最著名的实现,也是目前最常被使用的基础设施提供商是 Reclaim Protocol。zkP2P 的开发者就使用了 Reclaim Protocol 作为目前 zkTLS 证明的默认提供者。zkP2P 开发者也认为目前进行 zkTLS 的开发使用代理模型是比较好的选择。
在上文中,我们提到的基于 TEE 和基于 MPC 的技术实现似乎都没有使用到 zk 技术,而基于代理模型的实现中使用了 zkproof 进行共享密钥的证明。实际上,基于 TEE 和基于 MPC 的技术在某些情况下也会使用 zk 技术,具体过程发生在 Alice 给 Bob 数据的过程中。显然,在某些情况下,Alice 在使用 zkTLS 调用 API 的情况下会产生一些数据,而这些数据可能涉及个人隐私,Alice 并不希望向 Bob 展示,在该情况下,Alice 需要 zk 技术来掩盖部分数据。
基于前文对 zkTLS 技术原理的介绍和 zkP2P 项目的成功实践,本节将深入分析 zkTLS 技术的公共属性以及由此衍生的广阔商业前景,以及我们将结合 zkP2P 和 P2P.me 等具体项目的实践经验,探讨 zkTLS 技术如何重塑数字信任基础设施。
zkTLS 技术最核心的公共性体现在其对传统中介依赖的颠覆性改变。zkTSL 使得用户不用再完全依赖平台的信用,而是可以用数学证明来让所有人都相信事情的真实性,这为用户提供了前所未有的自托管能力、隐私保护和安全保障,更重要的是,它从根本上实现了对权威平台信任的“民主化”访问。
传统的 C2C 交易中,由于交易双方缺乏直接信任机制,通常需要依赖 Binance 等交易所作为中介方提供托管服务。以及 Web2 环境中,我们总是要找个“大平台”做中介,来保证交易或交互的可信性,如在淘宝、闲鱼上买东西,钱要先交给平台托管,等确认收货后才给卖家。然而,从本质上分析,这些交易所并未真正参与核心交易过程:法币转移在链下进行,转账确认也是由法币接收者完成,交易所仅在接收到确认信息后释放相应的加密货币。zkTLS 技术为所有存在资金托管且托管解锁过程可通过第三方 API 验证的业务提供了革命性的解决方案。具体实现路径是:资金提供方将资金托管给智能合约,另一方完成业务后使用 zkTLS 调用相关 API 生成业务完成证明,最后将证明提交到智能合约以触发资金解锁。这种机制的前提是交易双方都需要信任 API 服务返回的结果。
zkTLS 技术最具革命性的贡献在于为所有应用提供了"平权"机会。传统模式下,应用开发者需要通过复杂繁琐的流程向大型平台证明自身的可靠性(如证明自己是合格企业,经过一大堆审核),最终只有少数企业才能获得 API 接入授权。zkTLS 技术使得开发者可以直接利用大型平台的 API、服务和已建立的信任体系,无需经过平台方的许可审核。好比说,以前你必须得到“银行”的批准才能证明账户里有钱,现在你能直接出示一个“数学证明”,让别人确认你确实有钱,而银行本身不需要为你背书。
前面介绍了 zkTLS 的技术和如何应用,而 zkP2P 作为 zkTLS 技术最成功的商业化应用,其实现机制充分展现了该技术的公共性,下面将详细介绍 zkP2P。
zkP2P 的业务流程:
两个创新点
这一过程使用 zkTLS 生成的链下转账证明取代了传统的人工确认机制,通过智能合约彻底改变了 C2C 交易中对可信中介的依赖。用户在整个交易流程中只需要信任汇款系统及其 API,只要汇款系统在 API 层面保持诚信,USDC 卖方的资产安全就能得到保障。
引入了 PeerAuth 浏览器插件。该插件用于生成汇款系统内的转账行为的 proof。你可以把它想象成一个“自动生成汇款凭证的打印机”,一旦在银行页面完成转账,PeerAuth 就能自动捕捉这个行为,生成一份零知识证明。
PeerAuth 是开放的,只要开发者提供了配置文件(比如说明某个银行的 API 是这样用的),PeerAuth 可以生成任意调用的 zkTLS 证明。具体可以参考 zkP2P providers 仓库,开发者可以编写一些配置文件使得 zkP2P 支持任意的带有 API 的汇款系统。同时 PeerAuth 是多 zkTLS 系统兼容的,任何成熟的 zkTLS 系统都可以被纳入 PeerAuth 插件。

从 zkP2P 的实践来看,为用户提供 PeerAuth 插件提升了 zkTLS 的用户体验,可以预计未来大部分 zkTLS 应用都可能会采用在桌面端使用浏览器插件的形式。当然,目前 zkP2P 的开发者还在探讨更新的用户体验形式,他们希望构建一个 App 以简化用户在移动端的操作,进一步提高用户体验。
目前,zkP2P 正在开发的 react-native-webview-intercept 正是 App 构建过程中最重要的组件,该组件负责劫持 WebView 中的请求将其转化为 zkTLS 请求。
P2P.me 也是一个基于 zkTLS 协议构建的去中心化 P2P On/Off Ramps 服务商。该系统也依赖于银行服务商,用户在进行买入 USDC 或者卖出 USDC 时都需要进行银行转账并使用 zkTLS 技术生成 Proof,这部分机制基本与 zkP2P 一致。
但 P2P.me 构建了独特的链上信誉系统,该系统不仅建立用户信任和特权,还主动防范点对点交易环境中的欺诈行为。用户可以通过完成一系列链上任务提升信誉分数(RP),从完成匿名 KYC 到推荐朋友,每项新完成的任务都会加强用户在社区中的链上声誉,同时解锁更高的交易限额。
这种严格的信誉系统与协议的匿名特性相结合,大幅降低了买方实施身份欺诈的可能性,特别是考虑到新用户链上声誉较低时只能进行小额交易。该机制实际上消除了洗钱等恶意行为的风险。

P2P.me 的健全链上声誉管理与交易限制相结合,不仅推动了去中心化货币和交易的大规模采用,还为传统银行系统服务不足的群体提供了新的金融接入机会。
对于 zkTLS 的商业前景,zkP2P 开发者提出了一个极具前瞻性的应用方向:将 zkTLS 技术应用于现有的 Web2 验证业务。以 Plum 平台为例,该平台的核心业务是帮助用户利用银行资产进行投资理财。早期阶段,平台要求用户直接输入银行账户和密码,Plum 获得用户凭证后可以使用用户银行资金进行理财操作。
然而,欧盟 GDPR 标准实施后,直接使用用户账户密码的业务模式面临合规挑战。zkTLS 技术的引入为这类业务提供了新的解决路径,因为该技术可以通过零知识证明有效保护用户隐私,避免用户敏感数据被不当获取。
通过结合银行 API 接口和 zkTLS 技术,金融应用开发者可以在符合 GDPR 标准的前提下使用用户银行数据,而无需经过复杂的流程获取银行认证或对接银行服务系统,可以通过 zkTLS 技术绕过银行限制直接构建创新金融应用。
即使考虑 Web3 的业务场景,zkTLS 技术也为 DeFi 系统的开发者提供了重要的帮助。zkTLS 技术使得开发者能够构建真正意义上的无许可金融应用,而不再局限于传统的 DeFi 系统。例如,Gianluca Minoprio 尝试直接连接 Venmo 与 AAVE,允许用户使用 Web2 资产赚取 Web3 收益,这种跨越传统界限的创新应用展现了 zkTLS 技术的无限可能性。这种技术架构为金融创新开辟了全新的道路,使得传统 Web2 平台的用户群体和资产可以无缝接入 Web3 生态系统,同时保持用户隐私和资产安全。
通过对 zkTLS 技术及其代表性应用的深入分析,我们可以看到该技术在重塑数字信任基础设施方面的巨大潜力。zkTLS 不仅仅是一项技术创新,更是一种具有深远公共价值的基础设施,它为用户提供了自托管等核心权利。
相比于其他 zk 技术,当前 zkTLS 技术已经具备了实际应用的可行性,从基于 TEE 的简洁方案,到基于 MPC 的去信任化架构,再到代理模型的实用性平衡,各种技术路径都在不断成熟。zkP2P 和 P2P.me 等项目的成功实践证明了该技术在商业化应用中的可行性和价值。
GCC 认为 zkTLS 的公共性体现在以下三个方面:
展望未来,zkTLS 技术有望成为连接 Web2 和 Web3 世界的重要桥梁,推动更加开放、平等和去中心化的数字经济生态的建立。
💡GCC (Global Chinese Community of Universal Digital Commons)支持那些以未来方式重塑公共物品的人与项目。我们立足华语,共连全球,共同驶向一个自由、开放、可持续的未来。在过去两年时间里,GCC 直接捐赠支持了 45+ 公共物品项目,100+ 建设者,累计捐赠金额超过 100 万美金。
GCC 对各种数字公共物品项目都感兴趣,但主要是与全球华语社区相关的抗审查和加密隐私、全球公共人才网络建设、自由开源软件、治理研究与实验等项目,我们希望我们的支持最终能对世界范围内公共产品的质量和数量产生积极和变革性的影响。
X:@GCCofCommons
官方网站:https://gccofficial.org/
为把华语区建设者与全球伙伴更好地汇聚在一起,促进知识的碰撞与协作,并资助那些能为社区带来实际价值的公共物品,我们将原本的常态化滚动申请调整为周期性申请,推出 GCC Public Goods Grant 计划,对项目进行集中的审核和评审。其他不变与原申请制度相同。本期申请我们聚焦抗审查 / 隐私、开源、教育与安全主题,资助相关主题的项目、社区、活动和个人建设者。
本期申请时间为:2025 年 10 月 1 日到 11 月 2 日,采用线上滚动受理与统一评审,本期预计资助总额为 10w U。
👉申请链接:https://www.gccofficial.org/application/public
注:如果你有更紧迫小额的资金需求,如申请高校链协赞助和 ETH 城市,或机票活动相关,请直接申请【专项基金】,选择“高校 Web3 兴趣小组和 ETH City 资助计划”或“Buidler 免费机票计划”,👉申请链接:https://www.gccofficial.org/application/special
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。
