🤿 隐私支付
Manta 的愿景是为更广泛的区块链行业带来隐私保护，而让隐私变成现实中的应用一个很重要的部分就是构建简单实用的产品。我们早期构建的两个产品之一是 隐私支付 更具体地讲, 一个多资产去中心化匿名支付协议。
工作原理
我们近期发布了一期详细介绍隐私支付协议的视频:
你可以点击观看 视频, 下载ppt, 或者继续阅读接下来的内容，了解更多关于 隐私支付 的工作原理。
目前， 隐私支付 的 formal specification 尚未开源, 敬请期待我们在不久未来的发布!
公共帐本
大多数加密货币的去中心化系统使用 公共账本 来追踪资产的去向。 公共账本存储每位用户余额的当前状态，一旦他们想要花费账户的余额，区块链会就这笔转账是否有效达成共识，继而更新账户状态。然而，想要验证公共账本上的一笔交易需要知道发送者和接受者以及转账的金额信息。我们希望找到一种方式来避免这种信息泄露，保护交易参与者的信息，并隐藏金额。
去中心化匿名支付协议的特性
在设计一个 隐私账本的时候，我们希望它可以具有以下特征：
一笔交易不能改变一种资产的总供应量。只有未来能够花费资产的 所有权会改变。
账本读取不会泄漏交易或者现有用户的任何信息。
这两种特性看似互相矛盾，一方面我们希望验证某种资产总量保持不变，另一方面我们又不希望获取到交易的具体信息。
幸运的是，一些密码学协议找到了解决办法—— zkSNARKs, 简洁非交互式零知识证明. 我们之后会看到它们在隐私支付协议中起到了什么样的作用。
概览
我们会先描述一个相对简化的协议版本，假设有两个任务Alice 和 Bob, 我们希望能找到一种方法让Alice 用一个隐私 账本发送资产给 Bob 。我们会按照接下来的几个步骤来进行演示：
这个讨论并没有完整独立地描述整个协议，我们将尝试通过黑盒的方式来解释一些密码学的协议的接口和安全性保障。建议大家对以下的每个话题都进行更深入的了解。
参与者 (详细)
Alice(发送者): 已经获得了某种资产的所有权， 由账本保证她可以花费。Bob(接收者): 可以被其他 发送者识别，未来可以花费所接受到的资产 。- `账本: 代表所有公开信息 ( 状态) 和验证者网络 (区块链) ，验证者可以就 发送者和 接收者之间发生的隐私转账中的所有权转移达成共识。
发送和接收
当Alice 想要转账给 Bob, 她使用 账本 作为中介。账本 进行 异步处理 并被传播于整个网络。因此，很多计算机都可以获取 账本，并向整个网络发送信息或者从整个网络获取信息。 Alice会向账本发送一条转账信息，如果被接收，将在 账本中更新状态, 变动会向全网进行广播。 Bob 会向网络请求最新的状态。如果有新的账本状态，他将下载并分析是否收到了新的资产，以下为两个协议的详情:
发送
Alice 一开始需要构建一个特殊的数字叫作, 临时密钥, 可以用来代表本次独有的转账。这个是通过 Bob的 公钥, , 以及账本 中一部分公开数据，还有一些随机数来构建的:
承诺方案（commitment scheme） 通过 将 作为其随机数（A.K.A blinder，trapdoor）确保 （账本检查点）隐私安全：
临时密钥只会用一次。 Alice 之后需要证明她正确地构建了, 也叫 开启 了承诺。承诺被绑定意味着 Alice 不能改变主意，找到另外一个公钥或账本检查点来构建同样的临时密钥。Trapdoor 给予我们 可隐藏的特性，即便有人知道 和 ，他们也不能在不知道的情况下预测 是什么。
Alice 现在使用临时密钥 , 她自己的密钥 , 以及之前她从账本 所收到的资产，来构建一笔隐私资产。我们接下来来看下隐私资产具体是如何构造的。
接收
一旦Alice 完成了与账本 之间的通讯，账本接受了她的隐私资产，将会永久地储存隐私资产，并等待有人来领取。Bob 希望来领取，于是他向 账本 请求了所有最新的隐私资产。账本 将这些信息发送给Bob ，他可以用他的密钥 来对隐私资产进行扫描，找到属于他的那笔。
Bob 在扫描过程中使用的密钥必须是从Alice构建隐私资产所用的公钥所派生出来的。 这个 密钥派生 的过程必须是不可逆的，这样就没人可以发现 是来自于 的知识。
- 请注意: 因为
账本会存在相当长的一段时间，Bob可以等到任何想要领取的时候操作。
共享密钥
可 Bob怎么领取他的新资产？未来他如何花费这些资产？
我们可以用到的一个很重要的密码学工具是 共享密钥。本质上，我们向要找到一种方法来将信息包裹起来，只有两个人有解开的方法。 让某个人保守秘密是很容易的，只要他们不告诉其他人就可以了。但是如何才能将机密告诉另外一个人，而且只有你们两个人知道呢？
最常见的方法之一是使用 Diffie-Hellman Key Exchange 协议。 在这个协议中，我们采取了一个假设不可能逆转的操作（在有效时间内），我们称之为 ，以及一个所有人都同意的公共常量 。 我们令 和 具有以下属性：
我们通过 和 密钥并调用 和 方法生成公钥。 由于 是不可逆的，我们可以将公钥 和 公开提供给任何人，或者即使我们想要加密，我们仍然可以发送 或 给特定的人，且不必担心有人可以对我们的密钥进行逆向工程。
因为 函数具有上述属性，所以信息加密方法为：
因此，如果您与某人共享您的公钥 并获得他们的公钥 ，那么你们俩都可以进行传输加密 。 通过以上方法，Alice 和 Bob成功传输了几条加密信息。
加密和解密
Alice 和 Bob使用 _共享密钥 _加密方式的第一个步是共享 _加密公钥 _。 这些密钥用于将我们想要在秘密消息中传输的资产价值从Alice 发送给Bob。 这称为线上传递。
加密
为了让Alice将资产发送给Bob，她使用混合公钥加密方案来加密资产。 她通过获取Bob的公钥 和此特定交易 的临时密钥 并执行 Diffie-Hellman 交换（在这种情况下使用椭圆曲线定义 函数），以计算共享加密密钥 。
Alice然后使用 Blake2s密钥派生函数生成另一个密钥 ，这是标准AES-GCM具有消息身份验证的加密方案的正确方式。 Alice使用 加密资产，并将派生的公共临时密钥 附加到密文消息中。 这一步骤构成了Alice发送给账本的完整私有资产。
解密
收到加密资产后，Bob将从账本下载发给他的私有资产，并查看是否有任何新资产是他可以使用的，他将尝试通过Alice的公钥来解密它们。
在这种情况下，Bob使用他的密钥 和附加到私有资产的公共临时密钥 ，构建 Diffie-Hellman 共享密钥 ，然后使用相同的 Blake2s 函数推导出 $K^，然后执行 _AES-GCM_解密。* 解密将检查消息身份验证是否可以正确重建，如果密钥 $K^ 与用于构建消息的密钥不同，它将失败，并且Bob将知道资产不是他的。 如果加密成功，那么 Bob会获得私有资产。
确权
现在我们知道Alice如何向Bob发送资产了。 但是，账本必须只接受可以证明发送的资产是未来可消费的 ，同时保护所有相关方的隐私。 如果仅是Alice向Bob发送加密资产并不意味着她不能再次发送它，或者将它发送给其他人。 我们需要一种方法来跟踪谁拥有什么，并能够在有人花费资产后夺走这种权力。
为了满足这个约束， Alice 会生成两种证书，UTXOs 和 void numbers。
UTXO或 Unspent Transation Output是接收者未来可以花费的证书。 它以下列方式在公共账本协议中使用：
1.证明Alice 拥有当前UTXO
2.从账本中删除Alice的UTXO
3.为Bob创建一个新的UTXO
通过这种方式，当前的 UTXO 集合代表了所有拥有一定数量资产以及他们的用户。 为了让Alice 花费她的资产，她需要出示一个证明，它代表Alice 是过去交易的接收者。 她需要证明 账本 以前见过这个 UTXO。
要将资产转移给Bob，Alice 会为Bob 生成一个名为 的新 UTXO。 Alice需要以某种方式撤销她的旧 UTXO。 她通过生成一个 void number* 来做到这一点，这与她的 相关联，其方式如下：
1.相同的 将始终生成相同的 。
2.不同的生成不同的。
3.没有人知道 属于哪一个 。
4.只有Alice可以构造。
让我们看看 和 是如何构造的。
接收证书
为了让Alice 能够以Bob的名义创建 ，她需要计算了另一个共享密钥，称为 trapdoor， 并到 UTXO 发布 承诺证明。
承诺是由Alice想要转移的资产数量和trapdoor组成。 trapdoor是保证隐藏属性的随机部分。 承诺的binding 属性确保Alice不能将一些虚假信息放入承诺中，防止Bob最终得到一些他无法花费的资产。
发送方证明
为让Alice生成她的void number证明，需使用她的trapdoor 构建 ，并提交她的密钥 。
之所以与void number证明相关，因为它使用相同的 trapdoor，并且只有 Alice可以执行此计算，因为 $\textsf{SK}\textsf{A} $只有她知道。
为了证明她的 UTXO 已经在账本上，Alice 可以创建一个Merkle-Proof，，证明这一事实。
零知识转账证明
但Alice已经秘密完成了所有这些计算，并涉及大量秘密信息，如果她与任何人分享，这些信息将危及她的账户。账本`怎么能相信她诚实地进行这个计算呢？
Alice 可以利用 zkSNARKs，简洁非交互式零知识证明在自己的机器上进行完全的运算，zkSNARKs 的工作原理如下：
Alice和账本就验证的某种算法公开达成共识，他们共同决定算法中哪些变量是机密的，哪些是可以公开的。Alice在自己的机器上，用自己选择的机密和公开输入进行算法运算。使用运算的输出，
Alice构建了一个可以证明运算是正确的(因为简洁性，相比于算法大小，这只是一个很小的文件）Alice将 发送给账本，账本可以快速验证是否产生文件的运算就是之前两人达成共识的算法，以决定是否要接受还是拒绝。
Alice 可以使用 zkSNARKs 来运算以上 隐私支付协议中不同的 objects。当她在做这些的时候，通过可以获得以下的隐私保证：
**隐私发送者**: 因为 和 是机密的,
账本并不知道哪个 UTXO 属于Alice, 知道的只是储存于账本之中的其中一个。**隐私接收者**: 因为 的构建属于机密, 没有人知道它来自 。
**隐私资产**: 因为 , , 和资产金额都是机密，除了
Bob外，没有人可以对加密的资产进行解密。
这样，我们就成功地构建了一个隐私支付协议！
通用的 N-to-M 转账协议
一般来说, 如果想要拥有可用的钱，我们需要的不仅仅是一个1对1的转账，比如，如果 Alice 向 Bob 转了5个（代币），而Bob想向Carol 转3个, 他不能使用1对1，因为并不能分割资产。想要解决这一问题，我们将以上的协议类推到一个-to-协议。
我们可以为每个 发送者 and 接收者 重复这一构建，这样 Bob 就可以将他的3个（代币）发送给 Carol 并将2个发给自己。因为整个协议是隐私的，除了Bob ，没有人知道他是这样做的。
了解更多
想要构建一个真正的隐私支付体系，你还需要了解更多的细节，比如隐私钱包、费用代理等等。目前，这些想法还在构想中，但是很快会有一些很酷的东西，敬请期待！