paint-brush
可编程隐私:如何更加合规友好 进入 Web3 世界by@sin7y
427
427

可编程隐私:如何更加合规友好 进入 Web3 世界

Sin7Y8m2023/11/29
Read on Terminal Reader

在这篇文章中,我们将更多地关注于解释 Ola 的合规性设计。正如 a16z 文章中所述,隐私必须同时包含两个属性: 实现原生隐私保护,保障用户信息安全。 确保遵守法规以追踪非法活动。
featured image - 可编程隐私:如何更加合规友好
进入 Web3 世界
Sin7Y HackerNoon profile picture

在Ola,我们非常同意a16z在他们的文章中的说法“ 实现加密隐私和监管合规“关于 web3:


“发展和监管 网络3 – 由加密技术驱动的互联网的演变 – 必须实现两个经常相互矛盾的目标。目标 1:尽管区块链默认透明,但仍保护消费者隐私。目标 2:为了国家安全降低非法金融风险。”


这一愿景与 Ola 在文章中所描述的一致“ Ola – 塑造您自己的 Web3 之旅另外,强调高吞吐量是Ola目前正在努力实现的一个功能。


无论是处理私有场景还是非私有场景,可编程性都是极其重要的属性。在可编程隐私领域,除了 Ola 之外,Aztec 和 Miden 都在朝着同一个目标努力。


奥拉的文章“ Sin7y 技术评论 (35):混合汇总 – 下一代基础设施 - HackMD ,”描述了这三种解决方案之间的差异。


在这篇文章中,我们将更多地关注于解释 Ola 的合规性友好设计。正如 a16z 文章中所述,隐私必须同时包含两个属性:


  1. 实现原生隐私保护,保障用户信息安全。


  2. 确保遵守法规以追踪非法活动。


第一点相对容易实现。关于第二点,每个项目都有自己的考虑和权衡。我们将主要深入研究 Ola 关于监管合规性的思维过程和设计。


从解决现实问题的角度出发,我们首先考察一下各种隐私项目在监管合规方面面临的挑战。正如文章“非自愿选择性去匿名化”一章中所述使用零知识证明的隐私保护监管解决方案:全文 - a16z crypto ”,关键问题是:“谁维护解锁可追溯性的私钥?

为什么我们需要私钥来解锁可追溯性?

私钥实现溯源的必要性与当前的隐私设计有关。


由于目前几乎所有基于 zk(零知识)技术的隐私解决方案都借鉴了 Zcash,因此我们直接讨论 Zcash 的设计,如下所示:



图。1。不可追溯原理和解锁可追溯性


在文章《 Sin7y 技术评论(33):私密交易原理和监管合规问题 - HackMD ”,您可以找到隐私交易背后的设计原则。我们将简要解释一下这种设计下如何维护隐私以及如何解决监管问题:


  1. 隐藏交易发起者或发送者:这是通过一次性签名来实现的,如 4.1.7.1 节所述。 zcash-树苗协议


  2. 隐藏交易接收者,或者说接收者:这分为两种情况:


ⅰ.通过使用接收者的公共地址对交易信息进行加密来实现对第三方的隐藏。参见第 4.19.1 节 zcash-树苗协议。然后,接收方使用私钥(称为传入查看密钥)筛选交易,以解密并过滤掉发送给他们的交易,如 4.19.2 节所述 zcash-树苗协议。交易内容本身不包含有关接收方的任何信息。


二.使用一次性公共地址可以实现对同一发件人的隐藏。


  1. 对于交易信息的隐藏:该方法涉及使用零知识证明和共享秘密方案。请参阅第 4.17 和 4.19 节 zcash-树苗协议


  2. 对于不可追踪的实现:该方法基于承诺(以下简称“CM”)树和无效(以下简称“NF”)树的设计。此设计有以下目的:


ⅰ.每一个UTXO(未花费的交易输出)对应一个CM和一个NF,但两者之间没有直接联系。


二. CM 树和 NF 树都是追加树。


ⅲ. CM树用于证明UTXO的有效性,而NF树则防止UTXO的双花。


基于上述隐私设计,用户可以受益于以下隐私保护功能:


  1. 每笔交易对外部各方都是不可见的。


  2. 交易之间的联系是无法追踪的。


这对用户来说似乎是一个完美的隐私保护设计。然而,从现实来看,并非每个用户的操作意图都是真实合法的。必须有适当的机制来披露部分或全部私人交易细节,以在必要时实现可追溯性。


这有助于监管机构对恶意用户采取行动。否则,这种形式的隐私可能成为恶意行为者伤害普通用户的工具。


上述隐私设计是否可以让监管部门方便地追踪交易并执行监管?答案是不。如所提供的图表(已引用但未显示)所示,当前的隐私设计需要视图密钥来解锁交易可追溯性。


然而,该视图密钥由用户持有,因此监管机构无法直接访问。这与文章“自愿选择性去匿名化”和“非自愿选择性去匿名化”第 13/14 节中描述的问题相关。 使用零知识证明的隐私保护监管解决方案:全文 - a16z crypto。


让我们更深入地研究一下。为什么视图密钥如此敏感以至于用户不愿意将其提供给监管机构?


  1. 首先,需要澄清的是,查看密钥并不是用于交易签名的私钥;它不能用于直接签署交易,因此不能用于窃取用户资产。


  2. 一旦查看密钥暴露,监管机构就可以以明文形式查看用户发起的所有私人交易。用户必须相信监管机构:(1)查看密钥不会泄露; (2) 交易细节不会被披露。


  3. 怀有恶意的用户当然不会愿意提供自己的查看密钥,让监管机构无能为力。


基于以上分析,理想的隐私解决方案应该


  1. 继续隐藏每笔交易的内容,确保用户隐私完好无损。


  2. 实现交易之间无需许可的可追溯性,意味着无需强制提供额外信息即可实现可追溯性


这就是 Ola 努力实现的愿景:原生融入可追溯性的可编程隐私!

Ola 如何将原生可追溯性引入可编程隐私?

针对上述隐私解决方案所遇到的监管挑战,Ola大胆进行了尝试,并给出了具体的设计方案。其核心技术点可概括为:


  1. 不再引入无效树来实现交易的不可追踪。在 Ola 的设计中,交易是可追踪的,但这是在加密的情况下完成的,不会损害交易本身的隐私属性。


  2. 剩余的承诺树通过引入额外的证明语句从原始的仅追加模式转变为可更新模式,以防止对同一承诺的双重支出攻击。图 2 对此进行了说明:



图2.可追溯性示例



  1. 合并可更新的视图密钥机制。这意味着当视图密钥暴露时,用户可以更新视图密钥,以确保密钥更新后创建的后续私有交易无法被解密。如图3所示:


图3. Ola的密钥系统


zkDID/zkKYC 有效平衡隐私与监管

零知识去中心化标识符(zkDID)在隐私平台中发挥着至关重要的作用。他们有能力将用户的合法身份(Legal ID)转换为 zkDID。例如,在PSE项目中 阿农·阿德哈尔,拥有Aadhaar卡的人可以生成zkDID。


对于其他人来说,zkDID 是匿名的,不会泄露用户的真实身份信息。这种双重特性为隐私保护提供了有力的工具。


关于 zkDID 的实现级别,它可以发生在各个级别,具体取决于平台的设计和要求:


  1. 平台级实现:如果平台需要管理和验证所有用户的身份以确保安全性和合规性,那么在平台级实现 zkDID 可能是更合适的选择。这样,平台可以直接将zkDID集成到其身份管理系统中,从而实现用户身份验证和授权。


    这种方法可以在整个平台上实现一致的身份保护和隐私控制。


  2. 应用程序级实现:如果平台优先考虑用户控制和灵活性,那么在平台上层应用程序中实现 zkDID 可能会更好。该方法允许用户选择是否使用zkDID并根据需要管理自己的身份。


    用户可以决定何时使用 zkDID,以平衡隐私和便利性。这种方法可能更适合那些想要更主动地控制自己身份的用户。 (非母语)。


基于上述设计,Ola的隐私解决方案具有以下优势:


  1. 可追溯性:基于交易中的CM信息,任何第三方都可以追踪CM的流向,如图2所示。


  2. 隐私:每笔交易的隐私保持完整;有关发送者、接收者和其他方面的信息仍然保密。


  3. 效率:通过维护更少的树,可以减少 zk-proof 系统的开销。


  4. 可更新的视图密钥:支持视图密钥的更新,确保在视图密钥暴露时交易隐私不会受到损害。


  5. 合规友好:无需不可执行的信息,监管机构就可以追踪目标的谱系,例如 CM 集合的来源。虽然监管机构可能暂时缺乏对这些 CM 所有者的了解,但他们有两种选择:


  6. A。等待 CM 被消耗并转移到公共地址,这是可行的,因为在 Ola 的设计中,所有私有状态都必须在退出生态系统之前过渡到公共状态。


    b.获取查看密钥信息进行解密,这是隐私保护解决方案中用于可追溯性的传统方法,如 Zcash、Aleo、Aztec、Miden 等系统中所见。


除了这些技术优势之外,Ola 还可以与诸如“ 实现加密隐私和监管合规性 - a16z crypto “ 和 ”区块链隐私和监管合规:迈向实际平衡”纳入黑名单机制和其他早期约束,完善整个可编程隐私系统的设计。


也发布在这里