方案存在的问题

本方案目前能想到以下问题：

1. 序列号sn如何产生，如何更新，如何存储，如何公布，公布的sn如何保存？随机数如何产生？

• 序列号sn可根据账户地址、账户余额、当前时间、随机数等相关信息的哈希值生成唯一的系列号；
• 余额每变动一次，系列号相应发生改变；每个账户存储自身当前最新的序列号sn；
• 在公布cmt_s时会公布交易发起方A的序列号sn_A，在B账户执行Deposit交易时会公布B收款前的序列号sn_B，双方公布序列号后，各自根据自己的新的账户余额生成新的序列号；
• 为便于查询，公布的sn可使用一张表进行维护，该表需存储于区块链中。

2. 交易双方如何共享随机数？

• 交易发生之前，交易双方使用Diffie-Hellman密钥协商，交易发起方将交易中涉及的随机数（比如rs）进行加密，并存入交易中，后期交易会被共识打包上链；交易的接收方可以搜索交易，解密随机数；最终，交易双方都使用了同一个随机数。

3. 传统Ethereum产生一笔交易即可实现A到B的转账，现在需要通过三笔交易(Mint交易相对发生次数较少，不算在内)完成转账的同时保护交易隐私，且每笔交易均需产生一个proof。总的来说，该方案使得转账交易的时间和交易费均增加数倍，有无优化方案？

• 目前，未有有效可行方案。

4. 转账交易的发起方在Update操作中如何获取TxSend交易？转账交易的接收方在Deposit操作中如何获取TxSend交易？

• 由于交易双方可以链下通信，所以A可以直接将TxSend的hash发送给B，B从而可以检索到TxSend

5. 从PK_B'中将钱存入到PK_B中，仍然会泄露交易接收方的信息？

• 目前只能实现某笔转账交易隐藏交易双方和交易金额，其他用户会知道某个账户发生了交易，但是不知道交易的发起方和交易的金额。此外，针对Acount模型，仍然无法避免利用相邻区块中的MPT推断出某账户是否发生交易。

6. 零知识余额到明文余额的转换？

• 该功能为Mint的逆操作，可参考Mint操作。