zkPass 是一个主打“隐私可验证数据”的基础协议，核心目标是在不上传、不泄露原始敏感信息的前提下，让用户可以把来自传统 Web2 网站的数据，安全、可信地用于 Web3 世界。
在 zkPass 的体系中，用户是“证明者”(Prover)，从 HTTPS 网站获取数据;协议把数据的真实性、来源、完整性转化为加密证明;验证方只检查证明是否成立，而看不到真实数据内容。
融资方面，zkPass 在 2023 年 8 月完成约 250 万美元种子轮，2024 年 10 月又完成 1250 万美元 A 轮融资，整体估值接近 1 亿美元。
整体定位可以总结为一句话，zkPass 试图成为 Web2 数据进入 Web3 世界时的“隐私守门人”。
技术架构：三层机制保障“可验不可见”
zkPass 的技术并不是单一方案，而是由三种核心技术叠加构成：
三方 TLS、多方计算、零知识证明。
1. 三方 TLS：验证数据“从哪来”
普通 HTTPS 只涉及用户和网站两方通信。
zkPass 引入第三方节点，形成“用户—节点—网站”的三方握手结构。
这样做的目的有两个：
确保数据确实来自指定网站，而非用户伪造;
密钥由多方共同生成，避免节点单独窥探用户数据。
也就是说，节点参与验证，但无法单独解密用户内容。
2. 多方计算：让任何一方都“不知道全部秘密”
多方计算(MPC)的作用，是把密钥拆分给多方持有。
即使节点参与过程，也拿不到完整密钥，自然无法还原用户数据。
这样就实现了一个微妙平衡：
系统能验证数据真实性;
却没有任何一方能掌握完整隐私。
3. 零知识证明：只证明结论，不暴露过程
当用户获取原始数据后，会在本地生成零知识证明：
比如证明“我的余额 ≥ X”“我注册时间 ≥ 一年”。
zkPass 采用“混合 ZK”方案：
结合交互式零知识技术(如 VOLE-ZK);
以及非交互式证明(如 SNARK);
在效率和安全之间取得平衡。
最终效果是：验证者只看到“条件成立”，但永远不知道具体数据是多少。
4. 反作弊与模板机制
虽然理论上支持任意 HTTPS 网站，但必须为网页结构建立“模板”：
规定 URL、页面结构、目标字段位置等。
同时协议内置多重校验机制：
请求必须匹配模板;
返回内容需满足断言条件;
防止用户构造假页面或篡改数据。
目标只有一个：
保证“既保护隐私，又不牺牲可信度”。
应用场景与生态布局
1. 主要应用方向
zkPass 的使用场景，几乎覆盖所有“需要验证但不想泄露”的领域：
身份与 KYC：证明年龄、国籍、身份状态，但不交原件;
DeFi 与信用：证明资产、账户、信用条件，不展示细节;
教育与资质：证明学历、证书、经历，但不公开档案;
医疗与社交：验证行为或数据真实性，同时保持隐私。
2. 生态发展情况
官方数据显示：
已支持 70+ 个网页数据源;
生成超过 200 万份可验证证明;
正在推广 TransGate SDK，方便开发者接入。
生态已涉及：金融、教育、社交、游戏、Web3 身份等多个领域。
3. 商业价值逻辑
从三方角度看：
对平台：减少用户资料存储压力，降低数据泄露风险;
对用户：真正掌控自己的数据;
对 Web3 项目：获得可靠的链下数据来源。
在“数据合规”和“隐私监管”越来越严格的时代，这种模式具备现实需求基础。
机遇与挑战并存
机遇
1.隐私监管趋势明确
GDPR、CCPA 等法规强化后，“少收集、多验证”成为方向，zkPass 正踩中风口。
2.Web2 数据进入 Web3 是刚需
身份、资产、信用、社交关系，都需要被“可信地搬上链”。
3.技术门槛高
三方 TLS + MPC + ZKP 的组合，本身就构成技术护城河。
挑战
1.数据源适配难度
不同网站结构差异大，模板维护成本高，影响规模化落地。
2.节点去中心化问题
若节点过于集中，隐私与可信承诺会被削弱。
3.商业化进度不确定
技术强不等于采用快，生态扩张仍需时间验证。
4.监管风险
身份、金融、医疗数据本身就是高敏领域，合规成本不低。
5.代币与经济模型尚不清晰
融资已完成，但代币用途、激励机制仍需市场检验。
相关文章
