CBDC系列（5） - Inthonan-LionRock项目阶段 II (批发型CBDC跨境支付实验项目)

本文基于BIS于2021年9月发布的Inthonan-LionRock项目的二阶段报告Inthanon-LionRock to mBridge: building a multi CBDC platform for international payments。本阶段结束后，新增了中国大陆央行和阿联酋央行，项目也被重新命名为mBridge，也就是现在熟知的多边央行数字货币桥项目。

1. 二阶段由ConsenSys公司提供技术支持，区块链技术选型选择了企业级以太坊的Java实现客户端Hyperledger Besu。官方的说法是Hyperledger Besu was chosen, in order to assess how an Ethereum-inspired architecture could support the objectives of a single ledger multi-currency network. Features of Hyperledger Besu that were considered include privacy, flexible choice of the consensus mechanism, and support from the Hyperledger ecosystem and community。相比一阶段的R3 corda，单链的架构使涉及多币种的FX等交易的原子性更容易实现，这一切都通过链上智能合约来保证，不再需要类似于哈希时间锁等跨链技术来保证，简化技术架构，从而减少分布式事务的潜在风险。但同时由于是单链，所有参与方的交易数据都在链上，因此对于链上数据隐私保护的要求更高。所以引入了Orion transaction manager (The nodes maintain the public state for blockchain and a corresponding private state for each privacy group. 后续升级到TESSERA项目)，隐私数据加密签名后在orion网络peer-to-peer传输，交易哈希上链；引入privacy group，数据分组可见。

   There are three types of privacy groups:
   1. Public: main group for all members,
   2. Private: between central bank and each commercial bank, and
   3. Bilateral: peer-to-peer between commercial banks with the central bank as needed.

2. 角色权限等级。央行是验证节点，参与共识出块，共识算法可插板；商行/外汇交易中心是普通节点，只同步数据不参与共识，有提交交易的权限。还有一类权限是只有查看交易的权限，类似于只读，通常是金融科技公司等。央行可以看到其发行币种的所有交易，包括在岸和离岸的交易；而其他角色只能看到跟其自身相关的交易。另外，只有央行节点才有发行和注销其管辖币种的权限。这个的权限控制是在区块链本身实现的，而不是外层的后端应用等。这里涉及两组概念，共识，验证出块，这个是区块链共识节点的身份，偏技术层面；交易可见性，发行/注销，这个是央行角色身份，偏业务层面，例如可以通过智能合约来控制；两者并不完全重合，但现在方案里统一。本实验中是如何将这两者有机整合的，没有看到详细介绍，还有待研究。

3. Token合约使用了ConsenSys公司的Universal Token标准，扩展了ERC-20和ERC-1400（增强了合规管理，受控的强制支付等功能），这些是Ethereum领域里最普遍的合约规范，同时也支持了现在真实世界的金融场景。

4. LSM机制。The IL2 prototype uses the hybrid model, developed to support bilateral and multilateral net settlements in centralized queues. Each central bank is responsible for facilitating the LSM within their own currenc.。明确了流动性节约机制是在央行的中心化的队列里实现的。目前只是各央行单独解决其发行币种的流动性问题，缺乏多个币种间的最优化解决。另外在链上想要通过智能合约实现LSM机制，既要实现复杂的机制达到最优解，又要保证数据隐私，目前来说难度还是很大的。The central bank will periodically and automatically initiate the LSM process:

   The process contains four stages:
   1. Detect: The central bank asks banks to send in their pending transactions and balances for LSM planning calculations.
   2. Plan: After receiving the pending transactions and balances from the banks, the central node will calculate which transactions can be netted.
   3. Propose: With the results from the planning stage, the central bank will 
       - Send instructions of netted positions to resolve the cyclical gridlock, or 
       - Will inject liquidity in the situation of a transaction deadlock. 
   4. Execute: Banks then execute the transfers.

   央行的gridlock解决方案是插件式的，支持可插拔，方便各个央行自己定制开发。

5. 最后也提到了目前的几个不足和缺陷

   1. 隐私：In particular, the reliance on Privacy Groups to preserve privacy across multiple jurisdictions does not allow for fully atomic PvP transactions. 
   2. LSM机制：In addition, since there is no single entity or jurisdiction that can view the balance of all pending FX transactions; an optimal liquidity savings mechanism has yet to be found. 
   3. 性能：Lastly, the scalability and performance of DLT in handling large transaction volumes will need to be assessed further if more jurisdictions or currencies are added onto the platform. 
   4. 风控：Detailed risk governance procedures will also need to be created.

Ref.

1. Besu - Private transaction processing
2. Hyperledger Besu vs Go-Quorum
3. What Is Quorum Blockchain? A Platform for The Enterprise
4. 深度解析企业级区块链解决方案-Quorum

图1 Besu私有交易处理流程

1. Submit a private transaction using eea_sendRawTransaction. The signed transaction includes transaction parameters specific to private transactions, including:
   • privateFor or privacyGroupId, which specifies the list of recipients.
   • privateFrom, which specifies the sender.
   • restriction, which specifies the transaction is restricted to the transaction participants.
2. The JSON-RPC endpoint passes the private transaction to the Private Transaction Handler.
3. The Private Transaction Handler sends the private transaction to Tessera.
4. Tessera distributes the private transaction directly (that is, point-to-point) to the Tessera nodes specified in privateFor or belonging to the privacy group identified by privacyGroupId. All recipient Tessera nodes store the transaction. Tessera associates the stored transaction with the transaction hash and privacy group ID.
5. Tessera returns the transaction hash to the Private Transaction Handler.
6. The Private Transaction Handler creates a PMT for the private transaction. The Private Transaction Handler propagates the PMT using devP2P in the same way as any other public Ethereum transaction.
7. Besu mines the PMT into a block and the PMT is distributed to all Ethereum nodes in the network.
8. The Mainnet Transaction Processor processes the PMT in the same way as any other public transaction. On nodes containing the privacy precompile contract specified in the to attribute of the PMT, the Mainnet Transaction Processor passes the PMT to the privacy precompile contract.
9. The privacy precompile contract queries Tessera for the private transaction and privacy group ID using the transaction hash.
10. The privacy precompile contract passes the private transaction to the Private Transaction Processor. The privacy group ID specifies the private world state to use.
11. The Private Transaction Processor executes the transaction. The Private Transaction Processor can read and write to the private world state, and read from the public world state.