39 total views
Editor’s note: In one blockchain, it is not difficult to establish a consensus mechanism trust system, but in multiple blockchains, the consensus mechanism has not been established for a long time. Is there a technology that can realize multi-chain Of trust delivery?
In a blockchain, each participant in the chain establishes a trust system with the help of the blockchain consensus mechanism. So the question is, in the cross-chain scenario of multiple blockchains, how does the trust between chains pass? What is the trust between chains? How should such cross-chain trust be established?
What is the trust between chains?
Let me talk about the conclusion first: the trust between chains is based on trusting the execution mechanism of the other chain, and the trust is in line with the execution result of the execution mechanism .
The reason is to start with the basic operation of cross-chain.
The basic operation of cross-chain is: after the counterpart chain performs an operation, the local chain can perform another operation. As shown in the figure below: after blockchain A successfully executes operation X, blockchain B executes operation Y. The X operation is a precondition for the execution of the Y operation.
In the above operation, a request X is signed and turned into a transaction and sent to the blockchain A. After the consensus of the blockchain A, a block is generated. The block contains the block header, transaction list and other information, and the block header contains the consensus result information. The above information can be collectively referred to as the execution result of the blockchain. The specific process is shown in the following figure:
The execution result of Blockchain A is sent to Blockchain B. Blockchain B must first determine whether X is on the chain before executing request Y.
The method of judgment is to verify whether the execution results related to blockchain A and X are valid in the operating environment of blockchain B. If the verification is passed, it means that X is on the chain, and blockchain B can continue to perform the next steps: send request Y and upload on blockchain B.
It should be noted that this operation is based on a premise that blockchain B must trust the execution mechanism of blockchain A. The correct execution result on Blockchain A represents the wishes of all parties on Blockchain A. To verify whether a transaction on blockchain A is valid, blockchain B must trust the execution mechanism of blockchain A, and verify the execution result of blockchain A in accordance with the execution mechanism of blockchain A before the district can be judged. A certain transaction on Blockchain A has been put on the chain.
It can be seen that in the whole process, judging whether the request is on the chain by verifying the execution result of the counterparty chain is the core step in establishing cross-chain trust. Therefore, the trust between chains is based on trusting the execution mechanism of the other chain, and trust is consistent with the execution result of the execution mechanism .
Establishing inter-chain trust requires four layers of verification
Although the execution results have different implementation methods in different blockchains, they are inseparable. The core data structure of the blockchain is a chain structure with blocks as the unit, and transactions exist in blocks (this article does not discuss the DAG form Blockchain).
Therefore, we can divide the verification of execution results into the following four levels:
- Check block continuity: At the beginning of the verification, the source of the data needs to be confirmed. Based on the continuity of the block chain, it is verified whether the block belongs to the designated block chain to prevent attackers from using any block chain for forgery.
- Verify block consensus: After confirming the source, it is necessary to verify whether the block represents the overall willingness of the counterparty chain. This step verifies whether the consensus information of the block meets the requirements, and prevents attackers from using blocks that have not passed the consensus to forge.
- Verify transaction existence: After the block is verified as legal, it is necessary to verify whether the specified transaction belongs to this block. Different chains have different verification methods, which will be described in the next section.
- Verify that the transaction is correct: After the existence of the transaction is verified, it does not mean that the transaction is indeed the expected operation in the cross-chain scenario. It is also necessary to combine the business scenario to determine whether the specific content of the transaction meets expectations.
Only passing the above four levels will be considered as verified. After the verification is passed, it indicates that the operation has been chained on the counterparty chain, and the local chain can perform the subsequent steps.
Implementation schemes of verification mechanisms at various levels
The four-layer verification described in the previous section can be implemented in different ways on different blockchains. WeCross’s plug-in framework defines a common programming interface. Developers only need to implement four levels of verification logic according to the chain type.
Below, let’s take a look at the specific implementation schemes at each level.
The implementation on different blockchains is similar. The hash value of the previous block is recorded in the current block, and the hash value of the current block is recorded in the next block. Multiple blocks are connected in turn to form a blockchain. Different blockchains only differ in the hash algorithm and the fields used to calculate the block hash.
In WeCross, to verify the continuity of the blockchain, you only need to follow the implementation of the corresponding chain, and the verification blocks are connected to form a chain in turn.
Block verification consensus
Block consensus verification is to verify whether the consensus information of the block meets the corresponding algorithm conditions. Different algorithms have different implementations. Here are the two most representative consensus algorithms: POW (Proof of Work) and PBFT (Practical Byzantine Fault Tolerance).
POW is a final consensus consensus algorithm, which gradually converges consensus results through the longest chain and delayed confirmation. WeCross provides the steps required for POW verification:
- Difficulty of verification: verify whether the nonce of the block meets the proof-of-work conditions
- Inspection delay: verify whether the current block is lower than the highest known block N blocks (N can be taken as 10, which means the block 1 hour ago)
- Verify the longest chain: Introduce multiple parties to verify that the current block is on the longest chain to prevent unilaterally falsely fabricating the highest block height and forging the fork chain to commit evil
The PBFT algorithm reaches an agreement immediately after multi-party consensus, and there is no possibility of forks and rollbacks in the blockchain. In the algorithm, nodes broadcast signatures to each other multiple times to reach consensus.
In a block, a sufficient number of signatures represent the legitimacy of the block. Therefore, the verification of PBFT in WeCross is relatively simple:
- Configure public key: Configure the public key of the consensus node of the counterparty chain in advance
- Signature verification: Use the pre-configured public key to verify the validity of the signature in the block and determine whether the number of valid signatures meets the PBFT consensus conditions
Verify that the transaction exists
The existence of verification transactions also needs to be judged according to different implementations. The more representative ones are SPV (Simple Payment Verification) and endorsement strategies.
The original intention of SPV was to implement a light client, which is currently implemented on most blockchains. With the rise of cross-chain technology, this technology is also used to verify the existence of certain data in a block.
Taking transactions as an example, the block header records all transaction hashes in the current block to form the root of the Merkle tree, that is, the “transaction root”. Any transaction corresponds to a Merkle path leading to the transaction root. For transactions that do not exist in the block, the Merkle Path leading to the transaction root cannot be forged.
Therefore, in WeCross, you only need to verify the Merkle Path of a transaction to determine whether a transaction belongs to a certain block.
The endorsement strategy is adopted by Hyperledger Fabric. In Fabric, every transaction needs to satisfy a pre-defined endorsement strategy.
When the transaction is executed, it will be signed by multiple endorsing nodes. When the signatures of all parties meet the endorsement policy, the transaction is considered valid. Fabric stores the signature information of the endorsing node in the block as part of the transaction. Multiple transactions form the transaction list in the block. The transaction list calculates the hash value in binary form, and the hash value is recorded in the block header.
Therefore, in the current implementation of WeCross, it is only necessary to determine whether the transaction is in the transaction list (and the corresponding flag is valid) and verify the hash value of the transaction list to initially determine the existence of the transaction.
WeCross will subsequently combine the endorsement strategy to verify the signature of the endorsing node of the transaction to further enhance the validity of the transaction existence verification.
Verify that the transaction is correct
Verifying that the transaction is correct is to determine whether the transaction hash (or binary) of the first three steps of verification is the operation expected by the business based on the expected parameters of the business.
For example, if the expected operation is transfer(a, b, 100), the corresponding transaction content cannot be get(a). When verifying, it is necessary to verify whether the expected business parameters correspond to the transaction hash (or binary) according to the transaction encoding method and hash algorithm. The difference between different blockchain implementations is only reflected in the transaction encoding and hash algorithm, and the corresponding method can be used for verification according to the chain implementation.
Different chain plug-ins in WeCross implement different verification logic. The FISCO BCOS plug-in uses RLP encoding and SHA-256 hash algorithm to verify whether the transaction hash is correct; while the Fabric plug-in uses ProtoBuf encoding to verify whether the transaction binary is correct.
Examples of complete verification process
For a more intuitive explanation, the following figure shows the complete verification process of FISCO BCOS.
When a chain gets the execution result of the other chain, it can be verified locally.
In the verification of block continuity, FISCO BCOS verifies that this block is a block of the counterparty chain by comparing the hash of the parent block in the block header with the real parent block hash.
In the block verification consensus, by checking the signature list of the current block, it is judged whether the number of legal signatures meets the PBFT consensus conditions, and it is confirmed that the current block represents the overall willingness of the counterparty chain.
By verifying the correctness of the Merkle Path that the transaction hash leads to the transaction root, it can be determined that the transaction already exists on the blockchain.
By verifying the correspondence between business expectations, transaction binary, and transaction hash, it can be determined that the transaction is the operation expected by the business. After the four levels of verification are passed, it indicates that the expected operation of the business has been on the chain of the counterparty, and the verification is completed.
to sum up
The trust between chains is based on the premise of trusting the execution mechanism of the other chain, and the trust is in line with the execution result of the execution mechanism. Whether the execution result is correct, the four levels of data are verified. The verification mechanism has different implementations in different chains, and WeCross provides support in a plug-in manner.
Source: WeBank Blockchain