编者按：本文来自PlatON，Odaily星球日报经授权转载。前言
目前的主流公链项目不管是基于账户模型还是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的注册信息，验证算法合约与存储合约版本。TokenManagerToken管理合约，ACL关于ARC20合约存取操作都是通过TokenManager与ARC20合约进行交互。Validator验证合约，实现对各种算法的验证功能，每种验证合约可以根据算法自定义账户地址。Storage存储合约负责存储每笔转账的必要信息，用于验证是否存在双花操作。ARC20标准Token合约从可扩展角度，开发者可以实现多种验证算法，注册到ACL合约中，就能供隐私Token发行方使用。从可升级的角度，ACL，Validator，Storage都可以进行动态升级，满足了功能扩展、漏洞修复等不同升级的需求。从易于发行角度，项目方仅需要部署ConfidentialToken，即可实现隐私Token。算法原理
Celsius：重组不受与美国达成47亿美元和解的影响:金色财经报道，Celsius Network表示，其与美国就欺诈指控达成的47亿美元和解协议不会影响其重组或为客户追回的金额。
Celsius在周四提交给法庭的一份声明中表示，该公司“继续追求成功的第11章计划”。“Celsius的特别委员会和高级领导层仍然致力于与监管机构和政府机构进行持续合作，因为公司仍然专注于为利益相关者实现价值最大化。”[2023/7/14 10:54:05]
算法概念和定义
票据note:借鉴Bitcoin的UTXO模型，一个票据"note"即是一个UTXO，其是对金额的加密后的表示，逻辑上包括金额"value"、属主"owner"。金额就是该票据的密文形式；属主信息是由该票据的spendingkey决定，在后续章节会进一步描述；JoinSplit交易：在本方案中，定义一个交易为多个票据和其他信息的集合。其他信息是指为验证交易逻辑包含的必要的数据，包括零知识证明等。付款人payer，收款人payee:在一个交易里，指花费了票据的人，和拥有花费新创建的票据的权利的人。这里付款人，需要与发送者sender进行区分，后者是发送了交易给区块链网络的人；因此，sender可以与payer是同一个实体，也可以是被实际payee授权的一个第三方。方案介绍
密钥和票据借鉴DKSAP协议，用户的钱包需要包括两个密钥对，spendingkey-pair和viewingkey-pair：aspendingkey-pair:,;用于授权一个交易。用户公开。aviewingkey-pair:,;用于审计/查看一个或者多个票据。用户公开。当payer需要创建一个新的票据(outputnote)时，首先生成一个临时密钥ephemeralkeypair,，用payee的publicviewingkey一起生成一个sharedsecret。随后，用sharedsecret和payee的一起生成一个该新票据的spendingkey-pair，记为。注：每个票据都有一个独立的spendingkey-pair，该spendingkey-pair定义了该票据的ownership,谁知道该spendingkey-pair的私钥部分，谁就具有花费该票据的权利。DKSAP的具体协议流程假设Bob(payee)的密钥为：spendingkey-pair:,viewingkey-pair:；为椭圆曲线群的生成元。Alice(payer)先生成一个临时密钥对,然后将公钥部分与放入Note数据中进行公开。Alice计算一个sharedsecret:,是一个满足密码安全的哈希函数。这里由于采用了ECDH原理，另一方Bob也可以计算。Alice计算本次交易中Bob的交易地址为：。Bob动态地检查链上交易，试图找到发送给他的Note。他可以根据每个Note中的，计算出相应的sharedsecret，然后计算对应的Note接收地址，与每个Note的接收地址进行比对，如果比对成功，则用背后的私钥部分进行花费，这里。Transfer交易流程假设Alice需要转账给Bob7XATP，且Alice总共拥有票据包括:5XATP,:3XATP。在一个明文的JoinSplit交易里，,作为inputnotes,Alice会创建:7XATP,:1XATP,且指定、属主信息分别为Bob和Alice。一、payerAlice创建一个交易临时密钥对，JoinSplitkey-pair：{,}。二、Alice计算inputnotecommitments如下：,,其中是指票据的notespendingkey的公钥部分。Alice计算每个inputnote的签名，以表示确实有权利花费。,。其中是票据的notespendingkey的私钥部分。//这里把也扔到单个票据的签名里，表示每个票据的属主都认可当前的JoinSplitkey-pair的拥有者。这样，不会造成攻击者伪造一个新的JoinSplitkey-pair，在不改变交易数据的情况下，重新签名交易进行重放攻击。三、Alice计算outputnotecommitments如下：其中和是Alice通过DKSAP协议以及Bob的公钥生成的notespendingkey的公钥部分。Alice会将和的临时密钥的公钥部分也公开，方便payee从链上找到属于自己的票据。即公开,.四、Alice计算publicvalue。该变量是一个公开的数值，表示与外部账户系统(ARC20资产）的转入转出关系，即该值为正数时，表示有数量的Token转出到外部账户(sender'saddress)，如果该值为负数时，表示有数量的Token从外部账户(sender'saddress)转入到隐私Token系统。例如一个典型的充值交易中的金额配平关系可能是形如：inputNotes=,outputNotes=,publicValue=-3ATP，表示sender的ATP账户中会冻结3个Token，同时会创建2个outputNotes，其金额总和为3，如果有任一项校验失败，则拒绝执行交易：验签；验签,；检查,是否存在Noteregistry上；检查,是否不存在Noteregistry上；验证，如果验证失败，则拒绝执行交易；//这里我们省略了ZKproof相关的publicinputs，取决于具体的算法细节；九、如果上述验证均通过，则合约更新Noteregistry状态，即将销毁，并创建。每个票据要包括：票据承诺，该票据的notespendingkey的公钥部分,以及该票据的临时密钥的公钥部分。十、如果上述验证均通过，还需要处理对应数量的Token情况。如果为正数，则合约将向sender的外部地址中解冻数量的ATPToken；否则合约将从sender的外部地址冻结数量的ATPToken。模型定义
在UTXO模型的基础上，隐私Token支持5种主要的操作，铸币，销毁，转账，充值，提币。铸币：由Token的发行方发起的增发交易。
销毁：由Token发行方发起的销毁一定数量的Token的交易。
转账：由普通用户发起的input总和与output总和相等的交易。
充值：充值，由普通用户发起的input总和小于output总和的特殊转账交易。差值经Token缩放因子处理后为实际从ARC20转入到隐私账户的Token数量，充值交易内部会从交易指定公开账户转账ARC20token到TokenManager合约账户。
提款：由普通用户发起的input总和大于output总和的特殊转账交易。差值经Token缩放因子处理后为实际从隐私账户转出到ARC20Token数量，提款交易内部会从TokenManager合约账户转账ARC20token到交易指定的公开账户。
合约交易交易结构
交易分为Proof,ExtraData,Signature三部分，Proof中保护有对UTXO证明与本次授权交易地址，ExtraData为明文数据，Signature为授权地址私钥进行签名，保证交易信息的完整性。
合约交易证明构造过程
一、构造证明数据，证明数据交给零知识证明处理。数据结构如下：
根据证明入参，生成如下证明结果作为交易证明入参：
二、不同类型的交易对应不同的附加数据，增加相应的附加数据，附加数据经过RLP编码后得到附加数据字节流。TransferExtra对应转账、充值、提款三种类型交易。着重说下depositSignature，其是防止交易发送者不拥有publicOwner私钥，就将其ARC20Token转走。三、构造完整的机密交易信息，RLP编码，授权地址对RLP编码后数据签名，进而得到完整的证明。合约执行流程
用户发送上述几种类型交易ConfidentialToken合约从注册表中找到ACL的地址ConfidentialToken向ACL发送交易信息ACL根据ConfidentialToken注册的信息找到验证合约进行证明验证Validator进行ZK验证Validator校验授权签名如果是Deposit交易，Validator检查depositsignatureValidator根据具体的算法产生CreateNoteDetailEvent事件ACL根据注册的存储合约进行更新数据Storage更新input,将inputnote进行删除Storage更新output,创建outputnote如果是Deposit/Withdraw交易，调用TokenManager进行存取操作TokenManager调用ARC20进行转账操作ConfidentialToken对outputnote创建CreateNoteEvent事件ConfidentialToken对inputnote创建DestroyNoteEvent事件如果是Mint交易，创建MintEvent事件如果是Burn交易，创建BurnEvent事件合约事件
上一次mint数据的hash；上一次burn数据的hash；完整的note信息；note的产生；note的销毁；更改note备注；这些信息都需要通过事件获取。MintEvent属性类型索引描述mintHashh256否铸币交易的hashvalueu128否铸币金额描述：发行方需要记录每次铸币的hash，下一次发行方铸币时需要前一次铸币的hash。第一次铸币时上一次铸币的hash为空。BurnEvent属性类型索引描述burnHashh256否销毁交易的hashvalueu128否铸币金额描述：发行方需要记录每次销毁的hash，下一次发行方销毁时需要前一次销毁的hash。第一次销毁时上一次销毁的hash为空。CreateNoteDetailEvent属性类型索引描述noteHashh256是notehash值noteOwnerbytes否note属主noteCipherbytes否note的金额和绑定数据用viewingpk加密之后的数据noteMetabytes否note的备注信息描述：属主信息是ephemeralPk和signPk组成结构体的RLP值，用户用私有的viewingSk和spendingSk判断自己是否为属主。判断成功之后，用私有的viewingSk从noteCipher中解密出note的blinding和quantity。CreateNoteEvent属性类型索引描述noteOwnerbytes是note属主的hashnoteHashh256是note的hash值ownerbytes否note属主描述：和CreateNoteDetailEvent是一一对应产生的。DestroyNoteEvent属性类型索引描述noteOwnerbytes是note属主的hashnoteHashh256是note的hash值ownerbytes否note属主描述：每花费一个note就会触发一个DestroyNoteEvent，用户需要监听此事件删除已经花费的note。MetaDataEvent属性类型索引描述noteHashh256是note的hash值noteMetabytes否note的备注信息描述：产生新的note备注和更改note备注时会触发此事件。部署升级
合约概念和定义
委员会：有权批准多签交易的地址，在多签交易规定的时间内，只有收集到不少于阈值的委员会签名，多签交易才算被批准，才能被发送到区块链网络。提案交易：需要委员会批准的多签交易，规定时间内，委员会批准通过，发送到区块链网络执行交易，未批准通过，交易超时被删除。模板合约：由于部署交易内容包括合约代码，代码量较大造成交易过大，所以采用模板合约，区块链底层直接复制模板合约代码。Clone创建合约：Clone创建时复制模板合约代码，用新的初始化参数初始化合约，创建成功之后获取新创建的合约的地址。合约升级：复制模板合约代码，产生新的合约地址，旧合约的数据迁到新合约地址，旧合约销毁。官方合约部署
一、部署Registry注册表合约，用来管理ACL地址，每次ACL升级的同时向Registry注册新地址。注册表合约采用无私钥地址部署，保证后续没有人可以更改此合约。注册表合约不支持合约升级。
二、部署MultiSign多签合约，此合约用来管理ACL合约，后续升级都将通过多签合约进行。确认多签委员会名单和提案生效人数阈值，部署合约初始化时传入确定好的值。三、部署ACL控制管理合约，部署过程中会clone出TokenManager合约。TokenManager合约和ARC20合约交互，转入转出token到TokenManager合约。
四、部署Validator验证合约或者Storage存储合约，这两个合约的部署流程是一样的，部署后都需要在ACL进行版本注册。
官方合约升级
ACL合约升级
委员会通过MultiSign合约进行升级的部署，部署通过先部署模板合约以Clone方式进行合约的升级，升级的ACL合约数据也一并迁移过去。升级后ACL会更新在Registry的注册信息，升级的过程是一笔交易，所以升级过程不会影响交易到调用方的使用。
Validator/Storage合约升级ACL合约对Validator和Storage合约进行版本控制，针对新特性、漏洞升级都会向ACL注册新版本，使用方可以根据自行需要，进行升级。一个新版本注册过程如图：
委员会确定新版本，通过MultiSign对Validator/Storage合约进行注册，注册信息存储ACL，供使用方查找。后面章节会讲用户如何升级。注册版本信息注册信息包括Verion,Address,Description三部分Verion由3个字段表示类型+主版本+子版本组成Address模板合约地址Description版本信息描述隐私Token合约部署
隐私Token合约是由用户或项目发行方来发起部署的。
发布者向注册合约请求获取ACL最新地址发布者从ACL获取验证合约与存储合约版本，选择相应版本发布者将验证合约与存储合约版本及其它信息作为初始化信息部署隐私Token合约隐私Token合约向ACL合约进行注册ACL根据隐私Token合约指定的版本号进行验证合约部署ACL根据隐私Token合约指定的版本号进行存储合约部署隐私Token合约升级
升级方向注册合约请求获取ACL最新地址升级方向ACL获取升级合约版本升级方调用隐私Token合约的升级接口隐私Token合约会调用ACL的升级接口ACL找到隐私Token合约对应的验证合约，调用验证合约的迁移接口验证合约根据升级模板合约进行合约升级ACL将升级后的验证合约地址更新注册信息底层：https://github.com/PlatONnetwork/PlatON-Go/tree/alaya-dev/feature-confidential-token隐私合约开源仓库：https://github.com/PlatONnetwork/confidential-transaction
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。