Introduction
Quorum is an alliance chain solution, an enterprise-level distributed ledger and smart contract platform developed by JPMorgan Chase. It is developed on the basis of Ethereum (Ethereum), provides private smart contract execution solutions, and meets enterprise-level performance requirements . It is suitable for application scenarios that require high-speed transactions and high-throughput processing of private transactions between alliances. It is mainly designed to solve the special challenges of blockchain technology in financial and other industries.
Quorum is developed based on the go-ethereum of Ethereum, and some changes have been made on this basis. This article discusses the private part, mainly adding the privacy of transactions and contracts. For a transaction, only the transaction related Only parties can see the details of the transaction, and non-related parties cannot see the details of the transaction.
1.1 Composition
As can be seen from the above figure, Quorum’s privacy design implementation is mainly composed of two parts.
Transaction manager: Allows access to encrypted transaction data for private transactions, manages local data storage, and communicates with other transaction managers. It acts as the data layer of private data, provides secure access to data and uses Enclave to realize secure encryption of data.
Enclave: A module implemented to solve the authenticity and security of accounting in the blockchain. It provides parallel operations through transaction isolation and specific encryption measures, which greatly improves performance. The secure processing of private data is basically realized through Enclave.
1.2 Card
Tessera is an open source private transaction manager written in the Java language. Its main functions are:
生成和维护私钥/公钥对
自我管理和发现网络中的所有节点
提供用于在Tessera节点之间进行通信的API，以及用于与启用了隐私功能的以太坊客户端进行通信的API。
Quorum uses Tessera as a private transaction manager private transaction manager to implement private transactions, thereby achieving the following functions:
存储并允许访问加密的交易数据
与其他 Tessera 节点交换加密的有效负载
无权访问私钥，保护私钥的安全性
将Enclave用于加密功能，私有交易管理器本身可以选择托管给Enclave
可以进行负载均衡
1.2 Enclave
Enclave is a module implemented to solve the authenticity and security of accounting in the blockchain. It provides encryption functions for private transaction managers by isolating encryption and decryption management. Separation of duties between the private transaction manager and the enclave improves performance and enhances privacy.
1.3 Public/private state
There are two transaction states supported in Quorum:
公共状态，可由网络中的所有节点访问
私有状态，只能由具有相应权限的节点访问
Public state transactions have unencrypted payloads, while private state transactions have encrypted payloads.
Nodes can only execute private transactions if they can access and decrypt the payloads. All nodes share a public state database created through public transactions and have an independent private state database locally.
The above is just a theoretical concept. In fact, Quorum does not introduce new transaction types; it just expands on the basis of the Ethereum transaction model to include an optional privateFor parameter. This private parameter will make Quorum treat this type of transaction as private For transactions, add an IsPrivate method to identify whether the transaction is a private transaction type.
1.4 Private enhancements
In addition to the standard private (SP), Quorum offers three private enhancements:
Counter-party protection (PP)
Mandatory party protection (MPP)
Private state validation (PSV)
1.4.1 Counter-party protection
Counter-party protection prevents non-private transaction participants from interacting with private contracts without using access controls.
For example, a private contract is deployed between Node1 and Node2. In the absence of Counter-party protection, if node 3 finds the private contract address, it can send a transaction to node 2 with the privateFor parameter set. The transaction will not be applied to node 3's private state database because node 3 is not a participant in the private transaction, but will be applied to node 2's private state database.
1.4.2 Mandatory party protection
Mandatory party protection inherits all the functions of Counter-party protection, and also allows one or more recipients to be defined as mandatory recipients of private contracts. Mandatory receivers are included in all subsequent transactions of the contract and have fully private state, whereas normal receivers may only have partial state of the contract.
1.4.3 Private state validation
Private state validation prevents differences in transaction state by ensuring that any private transactions of a contract are sent to all participants.
For example, a private contract is deployed between Node1 and Node2. If there is no Private state validation, node 1 can send the transaction to the private contract, setting privateFor to []. The transaction changes node 1's private state database, but not node 2's private state database, which causes 1 and 2's private states to no longer match. When using Private state validation, a transaction from node 1 with privateFor of [] will be rejected, and will only be processed if privateFor includes both nodes 1 and 2.
Private state validation shares the full list of participants among all participants and validates against all subsequent transactions.
1.5 Private transaction process
There are two types of Quorum transactions, Public Transaction and Privat Transaction, that is, public transaction type and private transaction type. In actual transactions, the former is fully compatible with Ethereum transactions. In the latter private transaction, some modifications have been made on the original Ethereum transaction model.
This is the private transaction flow chart on the official website. In this figure, a transaction is related to node A and node B, but not to node C.
Here is a brief explanation:
1. User A sends the private transaction to the Quorum node, and the node specifies the payload of the transaction, and specifies the privateFor parameters for A and B as the public keys of A and B.
2. The node sends Tx to the corresponding transaction manager Tessera and stores the relevant transaction data.
3. Tessera calls related functions of the encrypted Enclave module to request encryption of Tx.
4. The enclave of node A checks the private key of A, and if the verification passes, the following actions are taken:
第一步，生成一个对称密钥和随机值（使用对称密钥的作用是为了加快速度）。
第二步，使上一步生成的密钥加密Tx及相关内容。
第三步，由SHA3-512来计算加密后的Tx的内容的hash值。
第四步，遍历交易方列表（此处为A和B）使用第一步中产生的密钥对第一步中的随机值加密，然后生成一个新的值。
第五步，将上述以、二、三、四步的结果返回给Tessera。
5. A's Tessera uses the hash value obtained from the Enclave as an index to save the encrypted Tx and the encrypted key locally. At the same time, the hash value, encrypted Tx, and key will be sent to B's transaction manager Tessera via HTTPS. After B receives the data, it will respond with ACK/NACK. If A does not receive a response, then the transaction will not propagate on the network, that is, the recipient stores the payload of the communication as a prerequisite for network propagation.
6. Once the transaction sent to B is successful, A's Tessera returns the hash value to its corresponding Quorum node. The node replaces the original Tx transaction content payload with the hash value. Modify the V value of Tx to 3 or 38 (identification of private transactions). Other nodes can use this V value to judge whether it is a related private transaction with encrypted transaction content.
7. Use the standard Ethereum communication protocol to broadcast the nodes to the entire network through P2P.
8. This transaction is packaged into a block and distributed to each network node.
9. After the node receives the block of this Tx, it finds that the V value of this Tx is 37 or 38. Indicates that this Tx is a private transaction, which needs to be decrypted, needs to call the local Tessera, and finally decides whether to agree to the transaction (use the hash index to find).
10. Because node C has nothing to do with the transaction, it will only receive a message of not a recipient, thus ignoring the transaction, that is, C will not update its private state database. A and B will look up the hash value in their own transaction manager Tessera, identify and agree to the transaction, and then they call the corresponding Enclave module, passing the encrypted transaction content and the encrypted system key and signature.
11. The Enclave module verifies the signature, then uses the user's private key stored in the Enclave to decrypt the symmetric key, uses the decrypted key to decrypt the transaction content, and then returns the decrypted transaction content to Tessera.
12. Tessera, the transaction manager of A and B, executes the decrypted Tx through EVM. After the execution is completed, the execution result is returned to the Quorum node, and the private state of the Quorum node is updated.