这个方案更多是在composer层面做修改。有很大的局限性。在这里记录一下思路。

composer实现资产匿名

目的： 参考比特币匿名机制，为composer内置资产提供匿名支持

composer智能合约工作方式：

1. 定义资产、参与者等
2. 远程部署智能合约
3. 通过compsoer-rest-server启动接口
4. 调用restful接口，调用智能合约(背书确认、orderer排序等)
5. 产生交易->产生块->改变世界状态

在整个执行过程中，composer提供直接的方式指定资产的所有者。所以可以直接获取资产的所有者。

比特币：

1. 钱包提供地址，获取到比特币(此刻，这个地址就代表了比特币)。有了这个地址和对应的私钥，就可以执行交易。比特币钱包使用派生密钥方式，可以确保使用不同的地址保证相对匿名性)

钱包
[图片上传失败...(image-56c946-1516866050248)]

2. 交易。 对上一次交易信息和交易目标地址做签名，其他节点使用当前所有者公钥验签，如通过，则交易合法，记录在下一块区块上面，记录在大多数peer节点之后，交易完成。

实现composer资产匿名：

1. 参与者创建之后，可以通过PKI获取到密钥对（可以采用派生密钥的方式，实现多个密钥）。
2. 资产将作为独立部分存在。和比特币一样，一个密钥就可以标志所有权。
3. 资产交易：对上一次交易信息和交易目标地址做签名，在交易执行时，通过对当前所有者验签结果，判断交易合法性。

参考

sequenceDiagram
交易者1-->资产:i. 交易者1拥有资产
交易者1->>资产:ii. 将资产和交易者2的公钥做签名，然后验签、执行交易
资产->>资产:iii. 验证交易正确性
交易者2-->资产: iv: 交易完成,资产所有者变更

composer修改

1. 提供参与者和资产的基类。
2. 提供签名、验签的方法。
3. 提供PKI模块
4. 交易需要做签名。签名操作是放在外层的，还是内置在composer层面？
5. PKI会作为一个模块独立存在。一个参与者新建之后，就会有一个类似钱包概念的和其绑定。钱包管理密钥，密钥对应资产。

资产和参与者逻辑架构

graph TD
    A(参与者) --> B[钱包]
    C(PKI) --> B
    B -->|PK1 | D[资产1]
    B -->|PK2 | E[资产2]
    B -->|PK3 | F[资产3]

当前composer架构

1. 开发智能合约

   graph TD
       A(.cto)-->E[.bna]
       B(.js)-->E[.bna]
       C(.acl)-->E[.bna]
       D(.qry)-->E[.bna]
       E-->F(ChainCode)
   

2. 运行智能合约

   graph TD
       A[restful请求]-->B{Transaction}
       B-->|success|C(交易成功)
       B-->|fail|D(交易失败)
   

目标架构

1. 开发智能合约

   graph TD
       A(.cto)-->E[temp .bna]
       B(.js)-->E[temp .bna]
       C(.acl)-->E[temp .bna]
       D(.qry)-->E[temp .bna]
       S[加密衍生的扩展类型]-->F[temp .bna]
       E-->F[.bna]
       F-->G(ChainCode)
   

   应用开发层面无侵入

2. 运行智能合约

   1. 独立处理创建参与者。提供新的命令行或restful接口。

   graph TD
       A[restful请求]-->C{创建用户}
       B[command方式]-->C{创建用户}
       C-->D[新用户]
       E[钱包]-->D
       F[PKI]-->E
   

   2. 一般资产交易

   graph TD
      A[restful请求]-->C{验签}
      C-->|success|B{交易内容}
      C-->|fail|F(交易失败)
      B-->|success|E(交易成功)
      B-->|fail|F
   

   3. test

   graph TD
      A[Fabric]-->B[Composer1]
      A-->C[Composer2]
      A-->E[Composer3]
      B-->F[User1]
      
      G[监管]-->A
     A-->G
     
      B-->I[User2]
      I-->J[资产1]
      I-->K1[资产2]
      
      
   

开发工作预估

• [ ] 定义符合要求的参与者和资产。(修改composer-cli部分代码)
• [ ] 开发钱包模块。
• [ ] 研究、开发PKI模块
• [ ] 修改composer 内置 transaction 执行方式。嵌入签名、验签操作
• [ ] 开发新建用户命令行工具。舍弃composer participant 指令。开发参与者和钱包绑定的模块
• [ ] 待定...