【硬核科普】隐私交易使用手册

PlatON 阅读 1906 2021-1-8 19:17

前言

目前的主流公链项目不管是基于账户模型还是 UTXO 模型，交易转账地址与金额都是公开信息，易于追踪。

Zcash, Monero 等实现了隐私Token，在主链实现隐私Token有几个痛点：

算法升级： 密码学算法发展较为迅速，新的算法应用到主链并且与现有系统适配需要很漫长的过程

漏洞修复： 主链的漏洞升级需要协调矿工或验证人来配合升级，影响范围较广，周期较长

基于智能合约的隐私Token则能做到灵活的算法方案，快速的漏洞修复，影响面较小，只影响到该隐私Token的用户，是实现隐私Token的良好的平台。

简介

隐私交易基于 Alaya 的 WASM 智能合约平台 PIP-13 提案构建的隐私Token项目。该项目意在解决日益剧增的交易匿名化需求。通过零知识证明算法达到隐匿身份，算法插件化来满足多种隐私的需求；支持隐私Token的独立发行以及 ARC20 资产的隐私化；利用插件机制，做到算法的在线升级，做到对用户的无感升级。

合约架构

合约架构的主要满足以下几个目标：

可扩展，整个框架能够适配更多的算法，扩展隐私交易的生态。

可升级，对于合约漏洞，如算法漏洞等，能够进行快速升级，及时避免漏洞导致经济损失。

易于发行，Token的发行方不需要具备对算法原理的了解，仅需要判断算法是否满足需求，就能发行隐私Token。

架构图

【硬核科普】隐私交易使用手册

上述架构图中由如下模块组成

ConfidentialToken 隐私Token合约，由Token发行方进行部署。

Registry 注册表合约，ACL 合约地址会注册在 Registry, ConfidentialToken 每次交易都是通过 Registry 获取 ACL 最新地址，这样 ACL 可以进行动态升级。

ACL 访问控制合约，负责管理隐私Token的注册信息，验证算法合约与存储合约版本。

TokenManager Token管理合约，ACL 关于 ARC20 合约存取操作都是通过 TokenManager 与 ARC20 合约进行交互。

Validator 验证合约，实现对各种算法的验证功能，每种验证合约可以根据算法自定义账户地址。

Storage 存储合约负责存储每笔转账的必要信息，用于验证是否存在双花操作。

ARC20 标准Token合约

从可扩展角度，开发者可以实现多种验证算法，注册到 ACL 合约中，就能供隐私Token发行方使用。

从可升级的角度，ACL，Validator，Storage 都可以进行动态升级，满足了功能扩展、漏洞修复等不同升级的需求。

从易于发行角度，项目方仅需要部署 ConfidentialToken，即可实现隐私Token。

算法原理

算法概念和定义

票据 note: 借鉴 Bitcoin 的 UTXO 模型，一个票据 "note" 即是一个 UTXO，其是对金额的加密后的表示，逻辑上包括金额 "value"、属主 "owner"。金额就是该票据的密文形式；属主信息是由该票据的 spending key 决定，在后续章节会进一步描述；

JoinSplit 交易（简称“交易”）：在本方案中，定义一个交易为多个票据和其他信息的集合。其他信息是指为验证交易逻辑包含的必要的数据，包括零知识证明等。

付款人payer，收款人payee: 在一个交易里，指花费了票据的人，和拥有花费新创建的票据的权利的人。这里付款人，需要与发送者 sender 进行区分，后者是发送了交易给区块链网络的人；因此，sender 可以与 payer 是同一个实体，也可以是被实际 payee 授权的一个第三方。

方案介绍

密钥和票据

借鉴 DKSAP（Dual-Key Stealth Address Protocol）协议，用户的钱包需要包括两个密钥对，spending key-pair 和 viewing key-pair：

a spending key-pair: , ; 用于授权一个交易。用户公开。

a viewing key-pair: , ; 用于审计 / 查看一个或者多个票据。用户公开。

当 payer 需要创建一个新的票据 (output note) 时，首先生成一个临时密钥 ephemeral key pair, ，用 payee 的 public viewing key 一起生成一个 shared secret （采用 Diffie-Hellman key agreement 原理）。随后，用 shared secret 和 payee 的一起生成一个该新票据的 spending key-pair，记为。注：每个票据都有一个独立的 spending key-pair，该 spending key-pair 定义了该票据的 ownership, 谁知道该 spending key-pair 的私钥部分，谁就具有花费该票据的权利。

DKSAP 的具体协议流程

假设 Bob (payee) 的密钥为：spending key-pair: , viewing key-pair: ；为椭圆曲线群的生成元。

Alice (payer) 先生成一个临时密钥对 , 然后将公钥部分与放入 Note 数据中进行公开。

Alice 计算一个 shared secret: , 是一个满足密码安全的哈希函数。这里由于采用了 ECDH 原理，另一方 Bob 也可以计算。Alice 计算本次交易中 Bob 的交易地址为：。

Bob 动态地检查链上交易，试图找到发送给他的 Note。他可以根据每个 Note 中的，计算出相应的 shared secret，然后计算对应的 Note 接收地址，与每个 Note 的接收地址进行比对，如果比对成功，则用背后的私钥部分进行花费（签名），这里。

Transfer 交易流程

假设 Alice 需要转账给 Bob 7 XATP，且 Alice 总共拥有票据包括 :5 XATP, :3 XATP。在一个明文的 JoinSplit 交易里，, 作为 input notes, Alice 会创建 :7 XATP, : 1 XATP, 且指定、属主信息分别为 Bob 和 Alice。

一、 payer Alice 创建一个交易临时密钥对，JoinSplit key-pair：{, }。

二、Alice 计算 input note commitments 如下：

, , 其中是指票据的 note spending key 的公钥部分。

Alice 计算每个 input note 的签名，以表示确实有权利花费。, 。其中是票据的 note spending key 的私钥部分。// 这里把也扔到单个票据的签名里，表示每个票据的属主都认可当前的 JoinSplit key-pair 的拥有者。这样，不会造成攻击者伪造一个新的 JoinSplit key-pair，在不改变交易数据的情况下，重新签名交易进行重放攻击。

三、Alice 计算 output note commitments 如下：

，，其中和是 Alice 通过 DKSAP 协议以及 Bob 的公钥生成的 note spending key 的公钥部分。

Alice 会将和的临时密钥的公钥部分也公开，方便 payee 从链上找到属于自己的票据。即公开 , .

四、Alice 计算 public value 。该变量是一个公开的数值，表示与外部账户系统 (ARC20 资产）的转入转出关系，即该值为正数时，表示有数量的Token转出到外部账户 (sender's address)，如果该值为负数时，表示有数量的Token从外部账户 (sender's address) 转入到隐私Token系统。例如一个典型的充值交易中的金额配平关系可能是形如：inputNotes = [], outputNotes = [1 XATP,2 XATP], publicValue = -3 ATP ，表示 sender 的 ATP 账户中会冻结 3 个Token，同时会创建 2 个 output Notes，其金额总和为 3 （假设 ATP : XATP = 1: 1)。

五、Alice 对上述数据进行签名，计算 . 其中为交易的完整数据，即。// 注意，本例中的，表示是一个隐私Token系统内部的纯粹转账。

六、Alice 创建一个零知识证明，需要证明以下逻辑：

和里隐藏的金额之和 = 和里隐藏的金额之和 + ;

所有票据承诺的隐藏金额都是在一个合理的正数区间内；// 防止越界攻击

和是正确的承诺代数结构。// 证明逻辑取决于具体的承诺方案。这里不用检查和，是因为一定会有一笔前续的交易会检查，否则 , 不会被写入 Note registry。

七、Alice 将 ( , ) 一起发送给合约。

八、合约开始验证交易，逻辑如下（可根据实际需要调整验证顺序），如果有任一项校验失败，则拒绝执行交易：

验签；

验签 , ；

检查 , 是否存在 Note registry 上；

检查 , 是否不存在 Note registry 上；

验证，如果验证失败，则拒绝执行交易；// 这里我们省略了 ZK proof 相关的 public inputs，取决于具体的算法细节；

九、如果上述验证均通过，则合约更新 Note registry 状态，即将销毁，并创建。每个票据要包括：票据承诺，该票据的 note spending key 的公钥部分 , 以及该票据的临时密钥的公钥部分。

十、如果上述验证均通过，还需要处理对应数量的Token情况。如果为正数，则合约将向 sender 的外部地址中解冻数量的 ATP Token；否则合约将从 sender 的外部地址冻结数量的 ATP Token。

模型定义

在UTXO模型的基础上，隐私Token支持 5 种主要的操作，铸币，销毁，转账，充值，提币。

铸币： 由Token的发行方发起的增发交易（一种没有 input 的特殊转账交易）。

【硬核科普】隐私交易使用手册

销毁： 由Token发行方发起的销毁一定数量的Token的交易（一种没有 output 的特殊转账交易）。

【硬核科普】隐私交易使用手册

转账： 由普通用户发起的input总和与output总和相等的交易。

【硬核科普】隐私交易使用手册

充值： 充值，由普通用户发起的 input 总和小于 output 总和的特殊转账交易。差值经Token缩放因子处理后为实际从 ARC20 转入到隐私账户的Token数量，充值交易内部会从交易指定公开账户转账 ARC20 token 到 TokenManager 合约账户。

【硬核科普】隐私交易使用手册

提款： 由普通用户发起的 input 总和大于 output 总和的特殊转账交易。差值经Token缩放因子处理后为实际从隐私账户转出到 ARC20 Token数量，提款交易内部会从 TokenManager 合约账户转账 ARC20 token 到交易指定的公开账户。

【硬核科普】隐私交易使用手册

合约交易

交易结构

交易分为 Proof, ExtraData, Signature 三部分，Proof 中保护有对 UTXO 证明与本次授权交易地址，ExtraData 为明文数据，Signature 为授权地址私钥进行签名，保证交易信息的完整性。

【硬核科普】隐私交易使用手册

合约交易证明构造过程

一、构造证明数据，证明数据交给零知识证明处理。数据结构如下：

【硬核科普】隐私交易使用手册

根据证明入参，生成如下证明结果作为交易证明入参：

【硬核科普】隐私交易使用手册

二、不同类型的交易对应不同的附加数据，增加相应的附加数据，附加数据经过 RLP 编码后得到附加数据字节流。

TransferExtra 对应转账、充值、提款三种类型交易。着重说下 depositSignature ，其是防止交易发送者不拥有 publicOwner 私钥，就将其 ARC20 Token转走。

【硬核科普】隐私交易使用手册

三、构造完整的机密交易信息，RLP 编码，授权地址对 RLP 编码后数据签名，进而得到完整的证明。

【硬核科普】隐私交易使用手册

合约执行流程

【硬核科普】隐私交易使用手册

用户发送上述几种类型交易

ConfidentialToken 合约从注册表中找到 ACL 的地址

ConfidentialToken 向 ACL 发送交易信息

ACL 根据 ConfidentialToken 注册的信息找到验证合约进行证明验证

Validator 进行 ZK 验证

Validator 校验授权签名

如果是 Deposit 交易，Validator 检查 deposit signature

Validator 根据具体的算法产生 CreateNoteDetailEvent 事件

ACL 根据注册的存储合约进行更新数据

Storage 更新 input, 将 input note 进行删除

Storage 更新 output, 创建 output note

如果是 Deposit/Withdraw 交易，调用 TokenManager 进行存取操作

TokenManager 调用 ARC20 进行转账操作

ConfidentialToken 对 output note 创建 CreateNoteEvent 事件

ConfidentialToken 对 input note 创建 DestroyNoteEvent 事件

如果是 Mint 交易，创建 MintEvent 事件

如果是 Burn 交易，创建 BurnEvent 事件

合约事件

上一次 mint 数据的 hash；上一次 burn 数据的 hash；完整的 note 信息；note 的产生；note 的销毁；更改 note 备注；这些信息都需要通过事件获取。

MintEvent

属性	类型	索引	描述
mintHash	h256	否	铸币交易的 hash
value	u128	否	铸币金额

描述：发行方需要记录每次铸币的 hash，下一次发行方铸币时需要前一次铸币的 hash。第一次铸币时上一次铸币的 hash 为空。

BurnEvent

属性	类型	索引	描述
burnHash	h256	否	销毁交易的 hash
value	u128	否	铸币金额

描述：发行方需要记录每次销毁的 hash，下一次发行方销毁时需要前一次销毁的 hash。第一次销毁时上一次销毁的 hash 为空。

CreateNoteDetailEvent

属性	类型	索引	描述
noteHash	h256	是	note hash 值
noteOwner	bytes	否	note 属主
noteCipher	bytes	否	note 的金额和绑定数据用 viewing pk 加密之后的数据
noteMeta	bytes	否	note 的备注信息

描述：属主信息是 ephemeralPk 和 signPk 组成结构体的 RLP 值，用户用私有的 viewingSk 和 spendingSk 判断自己是否为属主。判断成功之后，用私有的 viewingSk 从 noteCipher 中解密出 note 的 blinding 和 quantity。