WO2022206431A1 - 查询Fabric区块链账本数据的方法和装置 - Google Patents

查询Fabric区块链账本数据的方法和装置 Download PDF

Info

Publication number
WO2022206431A1
WO2022206431A1 PCT/CN2022/081706 CN2022081706W WO2022206431A1 WO 2022206431 A1 WO2022206431 A1 WO 2022206431A1 CN 2022081706 W CN2022081706 W CN 2022081706W WO 2022206431 A1 WO2022206431 A1 WO 2022206431A1
Authority
WO
WIPO (PCT)
Prior art keywords
query
node
ledger data
transaction
endorsement
Prior art date
Application number
PCT/CN2022/081706
Other languages
English (en)
French (fr)
Inventor
余逸荣
Original Assignee
支付宝(杭州)信息技术有限公司
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2022206431A1 publication Critical patent/WO2022206431A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

  • the embodiments of this specification relate to the field of blockchain technology, and more particularly, to a method and apparatus for querying Fabric blockchain ledger data.
  • Hyperledger Fabric blockchain (hereinafter referred to as Fabric blockchain) is an enterprise-oriented consortium chain.
  • the Fabric blockchain includes the following types of nodes: client nodes, peer nodes, orderer nodes, and so on.
  • the peer nodes further include an endorsement (Endorsor) node, an management (Anchor) node, a commit (Committer) node, and the like.
  • the Fabric blockchain includes multiple channels, and each channel has its own closed ledger data and chaincode, which is the smart contract in the Fabric blockchain. Peers can choose which channels to join, and they can join the channel after being authenticated by peers already in the channel.
  • a client node can initiate a transaction proposal to a channel in the Fabirc blockchain, so that the client node sends a transaction proposal to at least two endorsing nodes in the channel.
  • the endorsement node in the channel has a transaction proposal system interface, so that the endorsement node can pre-execute and digitally sign the transaction proposal received from the client node by calling the system interface, and return the pre-execution result and digital signature after the pre-execution. to the client node.
  • the client node sends the transaction pre-execution result and signature to the ordering node after receiving it from each endorsement node.
  • the sorting node is used to sort transactions, and pack the sorted transactions into blocks at fixed time intervals and send them to the management node.
  • each peer node After receiving the block, the management node broadcasts the block to each submitting node. After the submitting node receives the block, it verifies the execution status of each transaction in the block, marks its execution status in each transaction of the block, and then adds the block to the node's ledger data (ie, submits the block).
  • each peer node is a commit node, that is, each peer node locally includes the ledger data of the channel.
  • the peer node has its own query chaincode (Query System Chaincode, qscc).
  • query System Chaincode qscc
  • the peer node can query the local ledger data by calling the qscc system chaincode, and the ledger data includes transaction data. , block data, etc.
  • FIG. 1 schematically shows a query operation process of a newly started peer node.
  • the top three boxes in Figure 1 represent multiple blocks in the ledger data initially acquired by the peer node, and block 0-block 2 are schematically shown here, where block 0 represents the creation block, and block 0 represents the genesis block. 0.
  • Block 1 and Block 2 are sequentially connected.
  • Each block consists of multiple transactions arranged in sequence (as shown by the pages in each box), and each transaction records the set of reads and writes that the transaction acquired when it was pre-executed.
  • the read-write set is the pre-execution result obtained by the endorsement node when pre-executing the transaction, and the pre-execution result includes the set of read operations for each parameter in the blockchain, and the data for each parameter in the blockchain.
  • the multiple transactions are not all executed successfully, but the initially acquired ledger data does not include the execution status of each transaction.
  • the peer node Since the transactions in each block in the ledger data in the channel need to be successfully executed based on the world state determined by the previous block, the peer node needs to execute after synchronizing the ledger data in the channel From the genesis block to the transactions in all blocks of the block where the target ledger data is located, the execution status of the target transaction can be obtained.
  • the block number) is linearly related, that is, the higher the height of the target block, the more time-consuming.
  • a user wishes to query a certain transaction in block 2
  • step 1 as shown by the arrow marked with 1 in the figure, the execution status of each transaction in block 0 is verified.
  • each transaction in block 0 it is verified whether the read-write set of each transaction can be successfully executed. Based on the ordering of each transaction, it is possible that the execution of the previous transaction has changed the value of a certain parameter, thus causing the subsequent transaction to fail to read and write. This subsequent transaction is marked as "0" to indicate that the transaction was unsuccessfully executed. If the read-write of the transaction does not conflict with the read-write of the previous transaction and can be executed successfully, the peer node marks the transaction as "1" to indicate that the transaction was successfully executed.
  • step 1 After completing step 1, that is, after verifying the execution status of each transaction in block 0, based on each parameter (ie, the world state) determined by the execution of each transaction in block 0, as shown in the figure marked with 2 As shown by the arrow, go to step 2.
  • the peer node sequentially verifies whether each transaction in block 1 can be successfully executed based on the current world state, and marks each transaction with "0" or "1" (such as the arrow marked with 2). pointed to in block 1).
  • the third step is performed.
  • the peer node sequentially verifies whether each transaction in block 2 can be successfully executed based on the current world state, and marks each transaction separately (as shown in block 2 pointed to by the arrow marked with 3). ) until the target transaction in block 2 that the user needs to query is executed.
  • the user's query requirements for the Fabric blockchain are low-frequency requirements. Therefore, after obtaining the execution status of the target transaction, in order not to occupy machine resources, the peer node configuration is usually deleted in the user device. Therefore, when the user needs to query Fabric again When the ledger data of the blockchain is stored, the whole process above still needs to be performed again.
  • the embodiments of this specification aim to provide a more efficient solution for querying the Fabric blockchain ledger data, so as to solve the deficiencies in the prior art.
  • one aspect of this specification provides a method for querying the ledger data of the Fabric blockchain, where the Fabric blockchain includes a client node and at least one endorsement node, and the method is executed by the client node, including: Send a transaction proposal to the at least one endorsement node, where the transaction proposal is used to request a query of the first ledger data; and respectively receive a query result from the at least one endorsement node to obtain the first ledger data.
  • respectively receiving a query result from the at least one endorsing node includes receiving, from the at least one endorsing node, a pre-execution result of the transaction proposal and a signature of each endorsing node on the pre-execution result, respectively.
  • the pre-execution result includes the query result
  • the method further includes: verifying the signature of each endorsement node.
  • the method further includes: before respectively sending transaction proposals to the at least one endorsing node, receiving a query request for the first ledger data from the user equipment of the user; determining whether the user has the right to query the first ledger data; the sending a transaction proposal to the at least one endorsement node respectively includes, in the case that it is determined that the user has the right to query the first ledger data, to the at least one endorsing node.
  • An endorsing node sends the transaction proposals respectively.
  • the Fabric blockchain includes at least two endorsement nodes, and the method further includes, after receiving the query results from the at least one endorsement node respectively, determining the authenticity of each query result based on a predetermined endorsement policy sex.
  • determining the authenticity of each query result based on the predetermined endorsement policy includes determining the number of identical query results in at least two query results received from the at least two endorsing nodes, thereby determining each query result authenticity.
  • the method further includes: in the case where it is determined that the at least two query results include a real query result, sending the real query result and the signature of the corresponding endorsing node to the user equipment .
  • the method further includes: in a case where it is determined that the at least two query results include real query results, signing the real query results to obtain a first signature, and applying the real query results to The result and the first signature are sent to the user equipment.
  • the first ledger data is block data or transaction data.
  • Another aspect of this specification provides a method for querying ledger data in a Fabric blockchain, where the Fabric blockchain includes a client node and at least one endorsement node, the method is executed by the endorsement node, and includes: receiving from the client node A transaction proposal, where the transaction proposal is used to request to query the first ledger data; pre-execute the transaction proposal to obtain the query result; and send the query result to the client node.
  • pre-executing the transaction proposal includes determining whether the initiating account of the transaction proposal has the right to query the first ledger data, and in the case of determining that the initiating account has the right to inquire, from The query result is read locally.
  • Another aspect of this specification provides an apparatus for querying ledger data of a Fabric blockchain, where the Fabric blockchain includes a client node and at least one endorsement node, the device is deployed on the client node, and includes: a first sending unit , configured to respectively send transaction proposals to the at least one endorsement node, where the transaction proposals are used to request to query the first ledger data; the first receiving unit is configured to respectively receive query results from the at least one endorsement node to Obtain the first ledger data.
  • the first receiving unit is further configured to receive, from the at least one endorsing node, a pre-execution result of the transaction proposal and a signature of each endorsing node on the pre-execution result, wherein, The pre-execution result includes the query result, and the apparatus further includes: a verification unit configured to verify the signature of each endorsement node.
  • the apparatus further includes: a second receiving unit configured to receive, from the user equipment of the user, a query for the first ledger data before respectively sending the transaction proposal to the at least one endorsing node request; a first determining unit configured to determine whether the user has the right to query the first ledger data; the first sending unit is further configured to, after determining that the user has access to the first ledger data In the case of the query authority of , send the transaction proposal to the at least one endorsement node respectively.
  • the Fabric blockchain includes at least two endorsement nodes
  • the apparatus further includes a second determination unit configured to, after respectively receiving the query results from the at least one endorsement node, determine based on a predetermined The endorsement policy determines the authenticity of each query result.
  • the second determining unit is further configured to determine the number of identical query results from at least two query results received from the at least two endorsing nodes, so as to determine the authenticity of each query result .
  • the apparatus further includes: a second sending unit, configured to, in a case where it is determined that the at least two query results include a real query result, send the real query result and the corresponding endorsement node The signature is sent to the user equipment.
  • a second sending unit configured to, in a case where it is determined that the at least two query results include a real query result, send the real query result and the corresponding endorsement node The signature is sent to the user equipment.
  • the apparatus further includes: a signature unit configured to, in a case where it is determined that the at least two query results include a real query result, sign the real query result to obtain a first signature , a third sending unit, configured to send the real query result and the first signature to the user equipment.
  • a signature unit configured to, in a case where it is determined that the at least two query results include a real query result, sign the real query result to obtain a first signature
  • a third sending unit configured to send the real query result and the first signature to the user equipment.
  • the Fabric blockchain includes a client node and at least one endorsement node, the device is deployed on the endorsement node, and includes: a receiving unit, configured as , receiving a transaction proposal from the client node, where the transaction proposal is used to request to query the first ledger data; the pre-execution unit, configured to pre-execute the transaction proposal to obtain the query result; the sending unit, configured to The query result is sent to the client node.
  • the pre-execution unit includes a determination subunit configured to determine whether the initiating account of the transaction proposal has the right to query the first ledger data, and the read subunit configured to: In the case that it is determined that the originating account has the query authority, the query result is read locally.
  • Another aspect of the present specification provides a computer-readable storage medium on which a computer program is stored, when the computer program is executed in a computer, the computer is made to execute any one of the above methods.
  • Another aspect of the present specification provides a computing device, including a memory and a processor, where executable code is stored in the memory, and when the processor executes the executable code, any one of the foregoing methods is implemented.
  • the query initiator can quickly and efficiently obtain the ledger data on the chain and verify the authenticity of the ledger data without running an independent peer node and waiting for the peer node to synchronize Verifying multiple blocks greatly saves the query time.
  • the query initiator only needs to obtain the data authorization of the target block or transaction to perform the query, and does not need to obtain the full account book authorization.
  • Fig. 1 schematically shows the query operation process of the newly started peer node
  • FIG. 2 shows a schematic diagram of a Fabric blockchain query system according to an embodiment of the present specification
  • FIG. 3 shows a flowchart of a method for querying Fabric blockchain ledger data according to an embodiment of the present specification
  • FIG. 4 shows a flowchart of a method for querying Fabric blockchain ledger data according to another embodiment of the present specification
  • FIG. 5 shows a flowchart of a method for querying Fabric blockchain ledger data according to another embodiment of the present specification
  • FIG. 6 shows an apparatus 600 for querying Fabric blockchain ledger data according to an embodiment of the present specification
  • FIG. 7 shows an apparatus 700 for querying Fabric blockchain ledger data according to an embodiment of the present specification.
  • FIG. 2 shows a schematic diagram of a Fabric blockchain query system according to an embodiment of the present specification.
  • the query system includes user equipment 21 , management equipment 22 and Fabric blockchain 23 .
  • the user equipment 21 may be an off-chain device of the Fabric blockchain, which may be a user's device of the Fabric blockchain, a node device of other blockchains, or used to transfer messages between multiple blockchains The repeater equipment, etc., are not limited here.
  • the management device 22 provides the user device 21 with a query service for the ledger data of the Fabric blockchain.
  • the management device 22 itself is a client node of the Fabric blockchain that has the permission to query the ledger data.
  • the Fabric blockchain 23 is shown schematically in Figure 2 as including peer nodes 1-4.
  • the management device 22 selects one or more peer nodes from the multiple peer nodes of the Fabric blockchain 23 as endorsement nodes, for example, selects node 1, node 2 and node 3 as the endorsement nodes Endorsement node. After making the selection, the management device 22 notifies the node 1, the node 2 and the node 3 respectively, so that the node 1 - the node 3 respectively enable the endorsement node authority. At the same time, the management device 22 records the connection information and public key information of Node 1 - Node 3 .
  • the user corresponding to the user equipment 21 applies to the management device 22 for the query permission of the ledger data before querying the ledger data (for example, the transaction m in the block n) of the Fabric blockchain 23, After verifying the application of user 1, the management device 22 authorizes the query authority to user 1, and records the authorization to user 1 locally. Authorized permissions.
  • the user 1 can send a query request to the management device 22 through the user equipment 21, so as to query, for example, the transaction m in the block n and the execution status of the transaction m.
  • the management device 22 After receiving the query request, the management device 22 first determines whether the user 1 has the query authority for the transaction m. After determining that user 1 has the right to query transaction m based on local records, a transaction proposal (eg transaction A proposal) is sent to a predetermined endorsement node (node 1 - node 3) for the transaction m in block n. Inquire.
  • a transaction proposal eg transaction A proposal
  • node 1-node 3 After receiving the transaction A proposal, node 1-node 3 respectively query the transaction data of transaction m in block n and the execution status of transaction m in their local ledger data as query results, and generate transactions based on the query results.
  • the pre-execution result of A For the pre-execution result of A, the pre-execution result of transaction A is signed, and the pre-execution result of transaction A and its signature are sent to the management device 22 .
  • the management device 22 After receiving the pre-execution results and signatures of transaction A from nodes 1 to 3, the management device 22 determines the real data in each query result based on a predetermined endorsement policy, and provides the real data to the user equipment 21 .
  • FIG. 3 shows a flowchart of a method for querying Fabric blockchain ledger data according to an embodiment of the present specification. As shown in FIG. 3 , the method is jointly performed by the user equipment 21 , the management device 22 and the nodes 1 - 3 in FIG. 2 , where the user equipment 21 is, for example, the equipment of the user 1 .
  • step S302 the user equipment 21 sends a query request to the management device 22, where the query request is used to request to query the ledger data in the Fabric blockchain.
  • the ledger data can be blocks or transactions.
  • the query request is used to query transaction m in block n in the Fabric blockchain.
  • the query request is for example issued by user 1 using his account 1 .
  • step S304 the management device 22 checks the inquiry authority of the account 1 .
  • the user 1 obtains in advance the query authority of the management device 22 for the predetermined account book data, and the management device 22 records the query authority corresponding to the account 1 locally. For example, it is recorded in the management device 22 that the account 1 has the inquiry authority to the transaction m. After receiving the above query request, the management device 22 locally reads the query authority of the account 1 to check whether the account 1 has the query authority for the transaction m.
  • step S306 the management device 22 sends transaction proposals to node 1, node 2 and node 3, respectively.
  • the transaction proposal (such as the transaction A proposal above) is used to invoke the qscc system chain code of the node to query the specified ledger data, such as querying transaction m in block n.
  • step S308 node 1, node 2 and node 3 obtain query results respectively.
  • node 1, node 2 and node 3 are all endorsement nodes, they perform the same process according to the preset process of the endorsement node after receiving the transaction A proposal, so as to obtain query results respectively. For example, node 1 - node 3 obtain query results respectively Result 1 - Query result 3.
  • node 1 is used as an example for description.
  • the node 1 pre-executes the transaction A.
  • the pre-execution is to simulate the execution of the transaction A, but does not store the acquired transaction execution result in the local ledger.
  • node 1 executes the qscc system chain code according to the transaction content of transaction A, reads transaction m in block n and the execution status of transaction m (that is, whether it is successfully executed) in the local ledger as query result 1, here, Node 1 has verified the execution status of each transaction in block n and recorded the execution status when submitting block n before.
  • the block representation includes the execution status of each transaction in the block.
  • node 1 can directly read the execution status of transaction m locally, without the need to execute each transaction in each block from the genesis block until transaction m as shown in Figure 1, thus greatly saving query time .
  • node 1 After obtaining the query result 1, node 1 records the query result 1 in the read-write set of the pre-execution process of transaction A, and signs the read-write set generated in the pre-execution process after the pre-execution ends.
  • step S310 Node 1 - Node 3 return their query results to the management device 22, respectively.
  • node 1 to node 3 respectively return the read-write sets and corresponding signatures obtained by pre-executing the transaction A to the management device 22, wherein each read-write set includes query result 1-query result 3 respectively.
  • step S312 the management device 22 verifies the query result.
  • the management device 22 After the management device 22 receives the respective read-write sets and their signatures from the nodes 1-3, it first verifies the respective signatures using the pre-recorded public keys of the nodes 1-3.
  • the management device 22 further verifies whether the query result included in each read-write set is the real data of the transaction m based on the preset endorsement policy.
  • a consistency threshold can be preset in the management device 22, and the consistency threshold is used to limit the minimum number of identical query results among multiple query results, so that the authenticity of the query results can be determined through the consistency threshold. sex.
  • the consistency threshold may be set to 2/3, that is, for 3 query results, if at least 2 of the query results are the same, it may be determined that the 2 query results are real query results, if the 3 query results are the same.
  • the total number of the same query results in the query results is less than 2 (that is, the 3 query results are different from each other), it can be determined that the 3 queries are not real.
  • the management device 22 may determine the endorsement policy based on the credibility of each endorsement node. For example, if the credibility of node 1 is higher, it can be set as long as the query between node 1 and any other node If the results are the same, it can be considered that the query result of node 1 is real, and the credibility of node 2 is low, so it can be set. Only when the query results of node 2 and node 1 and node 3 are the same, it can be The query result of node 2 is considered to be true.
  • step S314 the management device 22 returns the ledger data to the user device 21.
  • the management device 22 returns the real query result to the user equipment 21 after determining the real query result in the query result 1-query result 3, that is, the transaction content of the transaction m and the execution status of the transaction m.
  • the management device 22 determines that both the query result 1 and the query result 3 are real query results, that is, the query result 1 and the query result 3 are the same, so that the management device 22 can determine the real query result and the query result 3 Either node 1 or node 3 sends the signature of the real query result to the user equipment 21, so that the user equipment 21 can determine whether the query result data has not been tampered by verifying the signature of the query result.
  • the management device can use its own private key to sign the real query result, and send the real query result and the signature of the management device to the user device 21, so that the user device 21
  • the signature of the management device can be verified by using the pre-stored public key of the management device 22 to ensure the authenticity of the query result.
  • Fig. 4 shows a flowchart of a method for querying Fabric blockchain ledger data according to another embodiment of the present specification.
  • the method shown in FIG. 4 is different from the method shown in FIG. 3 in that the user equipment 21 can obtain the ledger data by directly sending a transaction proposal to the peer node of the Fabric blockchain instead of the management device 22 .
  • Node 1-Node 3 are set as endorsement nodes in the Fabric blockchain.
  • User 1 can apply for account book data query permission at each endorsement node (eg Node 1-Node 3) with Account 1, and the user equipment 21
  • the connection method and public key of each endorsement node can be obtained in advance.
  • step S402 the user equipment 21 sends a transaction proposal to node 1 to node 3, respectively, where the transaction proposal is used to call the ledger data provided in the channel to query the chain code.
  • the query chain code calls the qscc system chain code in the endorsement node to query the specified ledger data, such as querying the transaction m in block n.
  • the user equipment 21 sends the transaction proposal, eg, through the account 1 of the user 1 .
  • step S404 node 1 - node 3 check the query authority of account 1 respectively.
  • node 1 to node 3 pre-execute the transaction proposal, that is, pre-execute the ledger data query chain code.
  • node 1 first checks the query authority of account 1 according to the code of the ledger data query chain code.
  • each node authorizes the query authority to account 1 and records it locally.
  • nodes 1-3 respectively record that account 1 has the query authority for transaction m. Therefore, the node 1 can locally read the query authority of the account 1 to check whether the account 1 has the query authority for the transaction m.
  • node 1 determines that account 1 does not have the right to query transaction m, the pre-execution of the chain code for querying the ledger data ends, and "query failed" is returned, so that node 1's pre-execution of the above transaction ends, and the pre-execution of the chain code is terminated.
  • the result and its signature are sent to the user equipment 21 .
  • step S406 node 1, node 2 and node 3 obtain query results respectively.
  • node 1 querying the chain code of ledger data above, if node 1 determines that account 1 has the query authority for transaction m, it will query the call to the qscc system chain code in the chain code according to the ledger data, and execute the qscc system chain code, so as to read the transaction content and execution status of transaction m from the local ledger as query result 1, record the query result 1 in the read-write set of the pre-execution process, and sign the read-write set in the pre-execution process .
  • Node 2 and Node 3 obtain query result 2 and query result 3 similarly to Node 1, respectively.
  • step S408 node 1 - node 3 return their query results to user equipment 21 respectively.
  • node 1 to node 3 respectively return the read-write sets and corresponding signatures obtained by pre-executing the transaction to the user equipment 21, wherein each read-write set includes query result 1-query result 3 respectively.
  • step S410 the user equipment 21 verifies the query result.
  • step S312 The verification process can be described in the above-mentioned step S312, which is not repeated here.
  • FIG. 5 shows a flowchart of a method for querying Fabric blockchain ledger data according to another embodiment of the present specification.
  • the method shown in FIG. 5 differs from the method shown in FIG. 3 in that, in the method shown in FIG. 5, the management device 22 only sends the transaction proposal to one peer node (ie, node 1), in this case, the management device 22 considers that Node 1 is a trusted node, therefore, the query result received from node 1 is directly considered to be true, without the need to receive multiple query results from multiple nodes as shown in the figure, and to compare the multiple query results. Consistency verification is performed.
  • step S512 the management device 22 verifies the query result sent by the node 1 .
  • the management device 22 uses the node 1's public key pair after receiving the pre-executed read-write set for the transaction proposal and the node 1's signature on the read-write set from the node 1 The signature is verified, and after the verification is passed, it can be determined that the query result is true.
  • FIG. 6 shows an apparatus 600 for querying ledger data of a Fabric blockchain according to an embodiment of the present specification.
  • the Fabric blockchain includes a client node and at least one endorsement node.
  • the device is deployed on the client node and includes : the first sending unit 61 is configured to send transaction proposals to the at least one endorsement node respectively, where the transaction proposals are used to request the query of the first ledger data; the first receiving unit 62 is configured to send transaction proposals from the at least one endorsement node.
  • the nodes respectively receive the query results to obtain the first ledger data.
  • the first receiving unit 62 is further configured to receive, from the at least one endorsing node, a pre-execution result of the transaction proposal and a signature of each endorsing node on the pre-execution result, wherein , the pre-execution result includes the query result, and the apparatus 600 further includes: a verification unit 63 configured to verify the signature of each endorsement node.
  • the apparatus 600 further includes: a second receiving unit 64, configured to, before respectively sending a transaction proposal to the at least one endorsing node, receive from the user equipment of the user a response to the first ledger data
  • the first determining unit 65 is configured to determine whether the user has the right to query the first ledger data; the first sending unit is further configured to, after determining that the user has the right to query the first ledger data, the first sending unit is further configured to: In the case of a query permission for ledger data, the transaction proposal is sent to the at least one endorsement node respectively.
  • the Fabric blockchain includes at least two endorsement nodes
  • the apparatus 600 further includes a second determination unit 66 configured to, after receiving the query results from the at least one endorsement node respectively, The authenticity of each query result is determined based on a predetermined endorsement policy.
  • the second determining unit 66 is further configured to determine the number of the same query results from the at least two query results received from the at least two endorsing nodes, so as to determine the authenticity of each query result sex.
  • the apparatus 600 further includes: a second sending unit 67, configured to, in a case where it is determined that the at least two query results include real query results, send the real query results and corresponding The signature of the endorsing node is sent to the user equipment.
  • a second sending unit 67 configured to, in a case where it is determined that the at least two query results include real query results, send the real query results and corresponding The signature of the endorsing node is sent to the user equipment.
  • the apparatus 600 further includes: a signing unit 68, configured to, in a case where it is determined that the at least two query results include a real query result, sign the real query result to obtain the first query result.
  • a signature the third sending unit 69 is configured to send the real query result and the first signature to the user equipment.
  • FIG. 7 shows an apparatus 700 for querying ledger data of a Fabric blockchain according to an embodiment of the present specification.
  • the Fabric blockchain includes a client node and at least one endorsement node.
  • the device is deployed on the endorsement node, including:
  • the receiving unit 71 is configured to receive a transaction proposal from the client node, where the transaction proposal is used to request to query the first ledger data; the pre-executing unit 72 is configured to pre-execute the transaction proposal to obtain the query result; The sending unit 73 is configured to send the query result to the client node.
  • the pre-execution unit 72 includes a determination subunit 721 configured to determine whether the initiating account of the transaction proposal has the right to query the first ledger data, and the reading subunit 722, It is configured to read the query result locally when it is determined that the originating account has the query authority.
  • Another aspect of the present specification provides a computer-readable storage medium on which a computer program is stored, when the computer program is executed in a computer, the computer is made to execute any one of the above methods.
  • Another aspect of the present specification provides a computing device, including a memory and a processor, where executable code is stored in the memory, and when the processor executes the executable code, any one of the foregoing methods is implemented.
  • the query initiator can quickly and efficiently obtain the ledger data on the chain and verify the authenticity of the ledger data without running an independent peer node and waiting for the peer node to synchronize Verifying multiple blocks greatly saves the query time.
  • the query initiator only needs to obtain the data authorization of the target block or transaction to perform the query, and does not need to obtain the full account book authorization.
  • the software module can be placed in random access memory (RAM), internal memory, read only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or technical fields in any other form of storage medium known in the art.
  • RAM random access memory
  • ROM read only memory
  • electrically programmable ROM electrically erasable programmable ROM
  • registers hard disks, removable disks, CD-ROMs, or technical fields in any other form of storage medium known in the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种查询Fabric区块链账本数据的方法和装置，Fabric区块链中预设有至少一个背书节点，该方法由链下设备执行，包括：向至少一个背书节点分别发送交易提案，交易提案用于请求查询第一账本数据；从至少一个背书节点分别接收查询结果，以获取第一账本数据。

Description

查询Fabric区块链账本数据的方法和装置 技术领域
本说明书实施例涉及区块链技术领域，更具体地，涉及一种查询Fabric区块链账本数据的方法和装置。
背景技术
Hyperledger Fabric区块链(下文简称为Fabric区块链)是一种面向企业的联盟链。Fabric区块链中包括以下多种类型的节点：客户端节点、对等(Peer)节点、排序(orderer)节点等等。所述对等节点中又包括背书(Endorsor)节点、管理(Anchor)节点、提交(Committer)节点等。Fabric区块链中包括多个通道(channel)，每个通道具有自身封闭的账本数据和链码(chaincode)，所述链码即为Fabric区块链中的智能合约。对等节点可选择加入哪些通道，其在经过通道中已有的对等节点的身份验证之后可加入该通道。客户端节点可向Fabirc区块链中的某个通道发起交易提案，从而，客户端节点向该通道中的至少两个背书节点发送交易提案。通道中的背书节点具有交易提案系统接口，从而背书节点可通过调用该系统接口对从客户端节点接收的交易提案进行预执行并进行数字签名，并在预执行之后将预执行结果和数字签名返回给所述客户端节点。所述客户端节点在从各个背书节点接收到交易预执行结果和签名之后，将其发送给排序节点。排序节点用于对交易进行排序、并将经排序的交易按照固定的时间间隔打包成区块发送给管理节点。管理节点收到区块之后将区块广播给每个提交节点。提交节点收到区块之后验证区块中每个交易的执行状态，在区块的每个交易中标记其执行状态，然后将区块加入本节点的账本数据中(即，提交区块)。其中，每个对等节点都是提交节点，即，每个对等节点本地都包括通道的账本数据。
对等节点具有系统自带的查询链码(Query System Chaincode，qscc)，当对等节点需要查询账本数据时，可通过调用该qscc系统链码，查询本地账本数据，所述账本数据包括交易数据、区块数据等。
然而，当链下用户希望查询通道中的目标账本数据时，所述目标账本数据例如为交易，链下用户通常希望获取该交易的交易内容及该交易的执行状态。现有的方法是，用户获取Fabric区块链的全量账本数据的访问授权，启动一个对等节点，以该对等节点加入所述通道，同步通道中的账本数据。图1示意示出新启动的对等节点的查询操作过程。 图1中最上层的三个方框表示该对等节点初始获取的账本数据中的多个区块，这里示意示出区块0-区块2，其中区块0表示创世块，区块0、区块1和区块2是顺序相连的。每个区块中包括顺序排列的多个交易(如每个方框中的页面所示)，每个交易中记录有该交易在被预执行时获取的读写集。所述读写集即为背书节点在预执行交易时获取的预执行结果，所述预执行结果中包括对区块链中各个参数的读取操作的集合、以及对区块链中各个参数的写操作集合。该多个交易并不是都成功执行，但是在初始获取的账本数据中并不包括各个交易的执行状态。
由于通道中的账本数据中的各个区块中的交易需要基于前序区块确定的世界状态来确定是否能够成功执行，因此，该对等节点在同步所述通道中的账本数据之后，需要执行从创世块开始到目标账本数据所在区块的全部区块中的交易，才可以获取目标交易的执行状态，该执行过程的耗时与目标区块或交易所在区块链高度(即区块编号)线性相关，即，目标区块的高度越高，耗时越多。如图1中所示，假设用户希望查询区块2中的某个交易，其需要通过对等节点执行图1中的①、②、③三个计算步骤。首先，在第①步骤，如图中标注了①的箭头所示，验证区块0中各个交易的执行状态。具体是，按照区块0中的各个交易的顺序分别验证各个交易的读写集是否能成功执行。基于各个交易的排序，有可能前序交易的执行改变了某个参数的值，从而使得后续交易的读写失败，在该情况下，后续交易未能成功执行，该对等节点在验证时就将该后续交易标记为“0”，以指示该交易未能成功执行。如果交易的读写不与前序交易的读写冲突，可以成功执行，该对等节点就将该交易标记为“1”，以指示该交易成功执行。
在完成第①步骤，即，验证了区块0中各个交易的执行状态之后，基于由区块0中的各个交易的执行确定的各个参数(即世界状态)，如图中的以②标注的箭头所示，执行第②步骤。在该第②步骤中，对等节点基于当前的世界状态顺序验证区块1中各个交易是否能成功执行，并以“0”或“1”对各个交易分别进行标记(如以②标注的箭头指向的区块1中所示)。
之后，在完成第②步骤之后，类似地，如图中的以③标注的箭头所示，执行第③步骤。在该第③步骤中，对等节点基于当前的世界状态顺序验证区块2中各个交易是否能成功执行，并对各个交易分别进行标记(如以③标注的箭头指向的区块2中所示)，直到执行到用户需要查询的区块2中的目标交易。
通常，用户对Fabric区块链的查询需求是低频需求，因此，在获取目标交易的执行状态之后，为了不占用机器资源，用户设备中通常删除对等节点配置，从而，当用户再 次需要查询Fabric区块链的账本数据时，仍需要再次执行上述整个过程。
因此，需要一种更有效的查询Fabric区块链中账本数据的方案。
发明内容
本说明书实施例旨在提供一种更有效的查询Fabric区块链账本数据的方案，以解决现有技术中的不足。
为实现上述目的，本说明书一个方面提供一种查询Fabric区块链账本数据的方法，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述方法由客户端节点执行，包括：向所述至少一个背书节点分别发送交易提案，所述交易提案用于请求查询第一账本数据；从所述至少一个背书节点分别接收查询结果，以获取所述第一账本数据。
在一种实施方式中，从所述至少一个背书节点分别接收查询结果包括，从所述至少一个背书节点分别接收对所述交易提案的预执行结果及各个背书节点对所述预执行结果的签名，其中，所述预执行结果中包括所述查询结果，所述方法还包括：对各个背书节点的签名进行验证。
在一种实施方式中，所述方法还包括：在向所述至少一个背书节点分别发送交易提案之前，从用户的用户设备接收对所述第一账本数据的查询请求；确定所述用户是否具有对所述第一账本数据的查询权限；所述向所述至少一个背书节点分别发送交易提案包括，在确定所述用户具有对所述第一账本数据的查询权限的情况下，向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中，所述Fabric区块链中包括至少两个背书节点，所述方法还包括，从所述至少一个背书节点分别接收查询结果之后，基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中，基于预定背书策略确定各个查询结果的真实性包括，在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数，从而确定各个查询结果的真实性。
在一种实施方式中，所述方法还包括：在确定所述至少两个查询结果中包括真实查询结果的情况中，将所述真实查询结果及相应的背书节点的签名发送给所述用户设备。
在一种实施方式中，所述方法还包括：在确定所述至少两个查询结果中包括真实查询结果的情况中，对所述真实查询结果进行签名以获取第一签名，将所述真实查询结果 及所述第一签名发送给所述用户设备。
在一种实施方式中，所述第一账本数据为区块数据或交易数据。
本说明书另一方面提供一种查询Fabric区块链账本数据的方法，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述方法由背书节点执行，包括：从客户端节点接收交易提案，所述交易提案用于请求查询第一账本数据；预执行所述交易提案，以获取所述查询结果；将所述查询结果发送给所述客户端节点。
在一种实施方式中，预执行所述交易提案包括，确定所述交易提案的发起账户是否具有对所述第一账本数据的查询权限，在确定所述发起账户具有查询权限的情况中，从本地读取所述查询结果。
本说明书另一方面提供一种查询Fabric区块链账本数据的装置，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述装置部署于客户端节点，包括：第一发送单元，配置为，向所述至少一个背书节点分别发送交易提案，所述交易提案用于请求查询第一账本数据；第一接收单元，配置为，从所述至少一个背书节点分别接收查询结果，以获取所述第一账本数据。
在一种实施方式中，所述第一接收单元还配置为，从所述至少一个背书节点分别接收对所述交易提案的预执行结果及各个背书节点对所述预执行结果的签名，其中，所述预执行结果中包括所述查询结果，所述装置还包括：验证单元，配置为，对各个背书节点的签名进行验证。
在一种实施方式中，所述装置还包括：第二接收单元，配置为，在向所述至少一个背书节点分别发送交易提案之前，从用户的用户设备接收对所述第一账本数据的查询请求；第一确定单元，配置为，确定所述用户是否具有对所述第一账本数据的查询权限；所述第一发送单元还配置为，在确定所述用户具有对所述第一账本数据的查询权限的情况下，向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中，所述Fabric区块链中包括至少两个背书节点，所述装置还包括，第二确定单元，配置为，从所述至少一个背书节点分别接收查询结果之后，基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中，所述第二确定单元还配置为，在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数，从而确定各个查询结果的真实性。
在一种实施方式中，所述装置还包括：第二发送单元，配置为，在确定所述至少两 个查询结果中包括真实查询结果的情况中，将所述真实查询结果及相应的背书节点的签名发送给所述用户设备。
在一种实施方式中，所述装置还包括：签名单元，配置为，在确定所述至少两个查询结果中包括真实查询结果的情况中，对所述真实查询结果进行签名以获取第一签名，第三发送单元，配置为，将所述真实查询结果及所述第一签名发送给所述用户设备。
本说明书另一方面提供一种查询Fabric区块链账本数据的装置，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述装置部署于背书节点，包括：接收单元，配置为，从客户端节点接收交易提案，所述交易提案用于请求查询第一账本数据；预执行单元，配置为，预执行所述交易提案，以获取所述查询结果；发送单元，配置为，将所述查询结果发送给所述客户端节点。
在一种实施方式中，所述预执行单元包括，确定子单元，配置为，确定所述交易提案的发起账户是否具有对所述第一账本数据的查询权限，读取子单元，配置为，在确定所述发起账户具有查询权限的情况中，从本地读取所述查询结果。
本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。
通过本说明书实施例提供的Fabric区块链查询方案，查询发起方可快速高效地获取链上账本数据并可验证该账本数据的真实性，而无需运行独立的对等节点以及等待对等节点同步验证多个区块，大大节省了查询时间，另外，查询发起方只需要获取目标区块或交易的数据授权即可进行所述查询，而不需要获取全量账本授权。
附图说明
通过结合附图描述本说明书实施例，可以使得本说明书实施例更加清楚：
图1示意示出新启动的对等节点的查询操作过程；
图2示出根据本说明书实施例的Fabric区块链查询系统的示意图；
图3示出根据本说明书实施例的一种查询Fabric区块链账本数据的方法流程图；
图4示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图；
图5示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图；
图6示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置600；
图7示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置700。
具体实施方式
下面将结合附图描述本说明书实施例。
图2示出根据本说明书实施例的Fabric区块链查询系统的示意图。如图2中所示，所述查询系统中包括用户设备21、管理设备22和Fabric区块链23。其中，用户设备21可以为Fabric区块链的链下设备，其可以为Fabric区块链的使用用户的设备，其它区块链的节点设备、或者用于在多个区块链之间中转消息的中继器的设备等等，在此不作限定。管理设备22向用户设备21提供对Fabric区块链的账本数据的查询服务。管理设备22本身是Fabric区块链的具有账本数据查询权限的客户端节点。Fabric区块链23在图2中示意示出为包括对等节点1-4。
在执行本说明书实施例提供的方法之前，管理设备22从Fabric区块链23的多个对等节点中选取一个或多个对等节点作为背书节点，例如选择节点1、节点2和节点3作为背书节点。管理设备22在进行该选择之后分别通知节点1、节点2和节点3，从而使得节点1-节点3分别开启背书节点权限。同时，管理设备22记录节点1-节点3的连接信息和公钥信息。用户设备21对应的用户(例如用户1)在进行对Fabric区块链23的账本数据(例如区块n中的交易m)的查询之前，向管理设备22申请对所述账本数据的查询权限，管理设备22在对用户1的申请进行验证之后，对用户1授权所述查询权限，并在本地记录对用户1的授权，例如，可记录用户1的账户标识(如账户1)和用户1被授权的权限。
在进行上述准备工作之后，用户1可通过用户设备21向管理设备22发送查询请求，以用于查询例如区块n中的交易m及交易m的执行状态。管理设备22在接收到该查询请求之后，首先确定用户1是否具备对交易m的查询权限。在基于本地的记录确定用户1具有对交易m的查询权限之后，向预先确定的背书节点(节点1-节点3)发送交易提案(例如交易A提案)用于对区块n中的交易m进行查询。节点1-节点3在接收到交易A提案之后，分别在其本地的账本数据中查询到区块n中的交易m的交易数据和该交易m的执行状态作为查询结果，基于该查询结果生成交易A的预执行结果，对交易 A的预执行结果进行签名，并将交易A的预执行结果及其签名发送给管理设备22。管理设备22在接收到节点1-节点3对交易A的预执行结果和签名之后，基于预定背书策略确定各个查询结果中的真实数据，并将该真实数据提供给用户设备21。
下面将对上述查询过程进行详细描述。
图3示出根据本说明书实施例的一种查询Fabric区块链账本数据的方法流程图。如图3中所示，所述方法由图2中的用户设备21、管理设备22和节点1-3共同执行，其中用户设备21例如为用户1的设备。
首先在步骤S302，用户设备21向管理设备22发送查询请求，该查询请求用于请求查询Fabric区块链中的账本数据。
如上文所述，所述账本数据可以为区块或者交易。例如，所述查询请求用于查询Fabric区块链中区块n中的交易m。所述查询请求例如由用户1使用其账户1发出。
在步骤S304，管理设备22检查账户1的查询权限。
如上文所述的准备过程，用户1预先获取管理设备22的对预定账本数据的查询权限，并且，管理设备22在本地记录了账户1对应的查询权限。例如，管理设备22中记录了账户1具有对交易m的查询权限。管理设备22在接收到上述查询请求之后，在本地读取账户1的查询权限，以检查账户1是否具有对交易m的查询权限。
在步骤S306，管理设备22向节点1、节点2和节点3分别发送交易提案。
所述交易提案(例如上述交易A提案)用于调用节点的qscc系统链码，以查询指定账本数据，例如查询区块n中的交易m。
在步骤S308，节点1、节点2和节点3分别获取查询结果。
由于节点1、节点2和节点3都是背书节点，其在接收到交易A提案之后按照背书节点的预设流程执行相同的过程，从而分别获取查询结果，例如，节点1-节点3分别获取查询结果1-查询结果3。
这里以节点1为例进行描述。节点1在从管理设备22接收到上述交易提案之后，对该交易A进行预执行，所述预执行即模拟执行交易A，但是并不将获取的交易执行结果存入本地账本中。具体是，节点1根据交易A的交易内容执行qscc系统链码，在本地账本中读取区块n中的交易m及交易m的执行状态(即，是否成功执行)作为查询结果1，这里，节点1已经在之前对区块n的提交时验证了区块n中每个交易的执行状态 并记录了所述执行状态，即，节点1中记录的账本数据如图1中最下部的各个区块所示包括区块中各个交易的执行状态。因此，节点1可从本地直接读取交易m的执行状态，而不需要如图1中所示从创世块开始执行每个区块中的每个交易直到交易m，从而大大节省了查询时间。节点1在获取查询结果1之后，将该查询结果1记录到对交易A的预执行过程的读写集中，并在预执行结束之后对该预执行过程中产生的读写集进行签名。
在步骤S310，节点1-节点3分别将其查询结果返回给管理设备22。
也就是说，节点1-节点3分别将其预执行所述交易A获取的读写集以及相应的签名返回给管理设备22，其中，各个读写集中分别包括查询结果1-查询结果3。
在步骤S312，管理设备22验证查询结果。
管理设备22在从节点1-3分别接收到各个读写集及其签名之后，首先使用预先记录的节点1-3各自的公钥对各个签名进行验证。
在签名验证通过之后，管理设备22还基于预设的背书策略来验证各个读写集中包括的查询结果是否为交易m的真实数据。在一种实施方式中，管理设备22中可预设一致性阈值，该一致性阈值用于限定多个查询结果中的最少相同查询结果个数，从而通过该一致性阈值来确定查询结果的真实性。例如，所述一致性阈值可设定为2/3，即，对于3个查询结果，如果其中至少2个查询结果是相同的，则可确定该2个查询结果为真实查询结果，如果该3个查询结果中相同查询结果的总数小于2个(即3个查询结果互不相同)，则可确定该3个查询都不是真实的。
在一种实施方式中，管理设备22可基于各个背书节点的可信程度来确定背书策略，例如，节点1的可信程度较高，可设定，只要节点1与任一另一个节点的查询结果相同，则可认为节点1的查询结果是真实的，节点2的可信程度较低，则可以设定，仅在节点2与节点1、节点3的查询结果都相同的情况中，才可以认为节点2的查询结果是真实的。
在步骤S314，管理设备22将账本数据返回给用户设备21。
管理设备22在确定查询结果1-查询结果3中的真实查询结果之后，即交易m的交易内容和交易m的执行状态，将该真实查询结果返回给用户设备21。
在一种实施方式中，管理设备22例如确定查询结果1和查询结果3都为真实查询结果，即，查询结果1与查询结果3是相同的，从而，管理设备22可将该真实查询结果和节点1和节点3的任一个对所述真实查询结果的签名发送给用户设备21，从而用户设 备21可通过验证查询结果的签名确定查询结果数据是否未经篡改。
在一种实施方式中，管理设备在确定真实查询结果之后，可使用自己的私钥对该真实查询结果进行签名，并将真实查询结果及管理设备的签名发送给用户设备21，从而用户设备21可通过使用预先存储的管理设备22的公钥验证管理设备的签名，以确保查询结果的真实性。
图4示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图。
图4所示方法与图3所示方法不同在于，用户设备21可以不通过管理设备22，而是直接通过向Fabric区块链的对等节点发送交易提案，从而获取账本数据。在执行该方法之前，Fabric区块链中将节点1-节点3设定为背书节点，用户1可以以账户1在各个背书节点(例如节点1-节点3)申请账本数据查询权限，并且用户设备21可预先获取各个背书节点的连接方式和公钥。
在进行上述准备工作之后，首先，在步骤S402，用户设备21向节点1-节点3分别发送交易提案，该交易提案用于调用该通道中提供的账本数据查询链码。该查询链码中调用背书节点中的qscc系统链码，以查询指定账本数据，例如查询区块n中的交易m。用户设备21例如通过用户1的账户1发送所述交易提案。
在步骤S404，节点1-节点3分别检查账户1的查询权限。
节点1-节点3在接收到上述交易提案之后，预执行所述交易提案，即预执行所述账本数据查询链码。以节点1为例，在该预执行过程中，节点1根据账本数据查询链码的代码首先检查账户1的查询权限。如上文所述的准备过程，各个节点对账户1授权查询权限，会在本地进行记录，例如，节点1-3中分别记录了账户1具有对交易m的查询权限。从而，节点1可在本地读取账户1的查询权限，以检查账户1是否具有对交易m的查询权限。
如果节点1确定账户1不具有对交易m的查询权限，则对账本数据查询链码的预执行结束，并返回“查询失败”，从而节点1对上述交易的预执行结束，并将该预执行结果及对其的签名发送给用户设备21。
在步骤S406，节点1、节点2和节点3分别获取查询结果。
接着上文中节点1对账本数据查询链码的预执行过程，如果节点1确定账户1具有对交易m的查询权限，则根据账本数据查询链码中对qscc系统链码的调用，执行qscc系统链码，从而从本地账本中读取交易m的交易内容及执行状态作为查询结果1，在该 预执行过程的读写集中记录该查询结果1，并对该预执行过程中的读写集进行签名。
节点2和节点3分别与节点1类似地获取查询结果2和查询结果3。
在步骤S408，节点1-节点3分别将其查询结果返回给用户设备21。
也就是说，节点1-节点3分别将其预执行所述交易获取的读写集以及相应的签名返回给用户设备21，其中，各个读写集中分别包括查询结果1-查询结果3。
在步骤S410，用户设备21验证查询结果。
该验证过程可上文中对步骤S312的描述，在此不再赘述。
图5示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图。图5所示方法与图3所示方法不同在于，在图5所示方法中，管理设备22只将交易提案发送给一个对等节点(即节点1)，在该情况中，管理设备22认为节点1为可信节点，因此，直接将从节点1接收的查询结果认为是真实的，而不需要如图所示方法那样，从多个节点接收到多个查询结果，并对多个查询结果进行一致性验证。
在图5中，步骤S502-步骤S510和步骤S514可参考上文对步骤S302-步骤S310和步骤S314的描述，在此不再详述。
在步骤S512中，管理设备22验证由节点1发送的查询结果。
具体是，与上文描述类似地，管理设备22在从节点1接收到对所述交易提案的预执行读写集和节点1对所述读写集的签名之后，使用节点1的公钥对所述签名进行验证，在验证通过之后，可确定所述查询结果为真实的。
图6示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置600，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述装置部署于客户端节点，包括：第一发送单元61，配置为，向所述至少一个背书节点分别发送交易提案，所述交易提案用于请求查询第一账本数据；第一接收单元62，配置为，从所述至少一个背书节点分别接收查询结果，以获取所述第一账本数据。
在一种实施方式中，所述第一接收单元62还配置为，从所述至少一个背书节点分别接收对所述交易提案的预执行结果及各个背书节点对所述预执行结果的签名，其中，所述预执行结果中包括所述查询结果，所述装置600还包括：验证单元63，配置为，对各个背书节点的签名进行验证。
在一种实施方式中，所述装置600还包括：第二接收单元64，配置为，在向所述至 少一个背书节点分别发送交易提案之前，从用户的用户设备接收对所述第一账本数据的查询请求；第一确定单元65，配置为，确定所述用户是否具有对所述第一账本数据的查询权限；所述第一发送单元还配置为，在确定所述用户具有对所述第一账本数据的查询权限的情况下，向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中，所述Fabric区块链中包括至少两个背书节点，所述装置600还包括，第二确定单元66，配置为，从所述至少一个背书节点分别接收查询结果之后，基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中，所述第二确定单元66还配置为，在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数，从而确定各个查询结果的真实性。
在一种实施方式中，所述装置600还包括：第二发送单元67，配置为，在确定所述至少两个查询结果中包括真实查询结果的情况中，将所述真实查询结果及相应的背书节点的签名发送给所述用户设备。
在一种实施方式中，所述装置600还包括：签名单元68，配置为，在确定所述至少两个查询结果中包括真实查询结果的情况中，对所述真实查询结果进行签名以获取第一签名，第三发送单元69，配置为，将所述真实查询结果及所述第一签名发送给所述用户设备。
图7示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置700，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述装置部署于背书节点，包括：
接收单元71，配置为，从客户端节点接收交易提案，所述交易提案用于请求查询第一账本数据；预执行单元72，配置为，预执行所述交易提案，以获取所述查询结果；发送单元73，配置为，将所述查询结果发送给所述客户端节点。
在一种实施方式中，所述预执行单元72包括，确定子单元721，配置为，确定所述交易提案的发起账户是否具有对所述第一账本数据的查询权限，读取子单元722，配置为，在确定所述发起账户具有查询权限的情况中，从本地读取所述查询结果。
本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。
通过本说明书实施例提供的Fabric区块链查询方案，查询发起方可快速高效地获取链上账本数据并可验证该账本数据的真实性，而无需运行独立的对等节点以及等待对等节点同步验证多个区块，大大节省了查询时间，另外，查询发起方只需要获取目标区块或交易的数据授权即可进行所述查询，而不需要获取全量账本授权。
需要理解，本文中的“第一”，“第二”等描述，仅仅为了描述的简单而对相似概念进行区分，并不具有其他限定作用。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域普通技术人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。其中，软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

  1. 一种查询Fabric区块链账本数据的方法，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述方法由客户端节点执行，包括：
    从用户的用户设备接收对所述第一账本数据的查询请求；
    确定所述用户是否具有对所述第一账本数据的查询权限；
    在确定所述用户具有对所述第一账本数据的查询权限的情况下，向所述至少一个背书节点分别发送交易提案，所述交易提案用于请求查询第一账本数据；
    从所述至少一个背书节点分别接收查询结果，以获取所述第一账本数据；
    向所述用户设备返回所述第一账本数据。
  2. 根据权利要求1所述的方法，其中，从所述至少一个背书节点分别接收查询结果包括，从所述至少一个背书节点分别接收对所述交易提案的预执行结果及各个背书节点对所述预执行结果的签名，其中，所述预执行结果中包括所述查询结果，所述方法还包括：对各个背书节点的签名进行验证。
  3. 根据权利要求1所述的方法，其中，所述Fabric区块链中包括至少两个背书节点，所述方法还包括，从所述至少一个背书节点分别接收查询结果之后，基于预定背书策略确定各个查询结果的真实性。
  4. 根据权利要求3所述的方法，其中，基于预定背书策略确定各个查询结果的真实性包括，在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数，从而确定各个查询结果的真实性。
  5. 根据权利要求1至4中任一项所述的方法，还包括：
    在确定所述至少两个查询结果中包括真实查询结果的情况中，将所述真实查询结果及相应的背书节点的签名发送给所述用户设备。
  6. 根据权利要求1至4中任一项所述的方法，还包括：
    在确定所述至少两个查询结果中包括真实查询结果的情况中，对所述真实查询结果进行签名以获取第一签名，将所述真实查询结果及所述第一签名发送给所述用户设备。
  7. 根据权利要求1所述的方法，其中，所述第一账本数据为区块数据或交易数据。
  8. 一种查询Fabric区块链账本数据的方法，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述方法由背书节点执行，包括：
    从客户端节点接收交易提案，所述交易提案用于请求查询第一账本数据；
    确定所述交易提案的发起账户是否具有对所述第一账本数据的查询权限；
    在确定所述发起账户具有查询权限的情况中，预执行所述交易提案，以获取所述查 询结果；
    将所述查询结果发送给所述客户端节点。
  9. 一种查询Fabric区块链账本数据的装置，所述Fabric区块链中包括客户端节点和至少一个背书节点，所述装置部署于客户端节点，包括：
    第一接收单元，配置为，从用户的用户设备接收对所述第一账本数据的查询请求；
    第一确定单元，配置为，确定所述用户是否具有对所述第一账本数据的查询权限；
    第一发送单元，配置为，在确定所述用户具有对所述第一账本数据的查询权限的情况下，向所述至少一个背书节点分别发送交易提案，所述交易提案用于请求查询第一账本数据；
    第二接收单元，配置为，从所述至少一个背书节点分别接收查询结果，以获取所述第一账本数据；
    返回单元，配置为，向所述用户设备返回所述第一账本数据。
  10. 根据权利要求9所述的装置，其中，所述第二接收单元还配置为，从所述至少一个背书节点分别接收对所述交易提案的预执行结果及各个背书节点对所述预执行结果的签名，其中，所述预执行结果中包括所述查询结果，所述装置还包括：验证单元，配置为，对各个背书节点的签名进行验证。
  11. 根据权利要求9所述的装置，其中，所述Fabric区块链中包括至少两个背书节点，所述装置还包括，第二确定单元，配置为，从所述至少一个背书节点分别接收查询结果之后，基于预定背书策略确定各个查询结果的真实性。
  12. 根据权利要求11所述的装置，其中，所述第二确定单元还配置为，在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数，从而确定各个查询结果的真实性。
  13. 根据权利要求9至12中任一项所述的装置，还包括：
    第二发送单元，配置为，在确定所述至少两个查询结果中包括真实查询结果的情况中，将所述真实查询结果及相应的背书节点的签名发送给所述用户设备。
  14. 根据权利要求9至12中任一项所述的装置，还包括：
    签名单元，配置为，在确定所述至少两个查询结果中包括真实查询结果的情况中，对所述真实查询结果进行签名以获取第一签名，第三发送单元，配置为，将所述真实查询结果及所述第一签名发送给所述用户设备。
  15. 根据权利要求9所述的装置，其中，所述第一账本数据为区块数据或交易数据。
  16. 一种查询Fabric区块链账本数据的装置，所述Fabric区块链中包括客户端节点 和至少一个背书节点，所述装置部署于背书节点，包括：
    接收单元，配置为，从客户端节点接收交易提案，所述交易提案用于请求查询第一账本数据；
    确定单元，配置为，确定所述交易提案的发起账户是否具有对所述第一账本数据的查询权限；
    预执行单元，配置为，在确定所述发起账户具有查询权限的情况中，预执行所述交易提案，以获取所述查询结果；
    发送单元，配置为，将所述查询结果发送给所述客户端节点。
  17. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1至8中任一项的所述的方法。
  18. 一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1至8中任一项所述的方法。
PCT/CN2022/081706 2021-03-30 2022-03-18 查询Fabric区块链账本数据的方法和装置 WO2022206431A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110339686.7A CN112732799B (zh) 2021-03-30 2021-03-30 查询Fabric区块链账本数据的方法和装置
CN202110339686.7 2021-03-30

Publications (1)

Publication Number Publication Date
WO2022206431A1 true WO2022206431A1 (zh) 2022-10-06

Family

ID=75596192

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/081706 WO2022206431A1 (zh) 2021-03-30 2022-03-18 查询Fabric区块链账本数据的方法和装置

Country Status (2)

Country Link
CN (1) CN112732799B (zh)
WO (1) WO2022206431A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732801B (zh) * 2021-03-30 2021-08-20 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置
CN112732799B (zh) * 2021-03-30 2021-11-02 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110266659A (zh) * 2019-05-31 2019-09-20 联想(北京)有限公司 一种数据处理方法和设备
CN110599069A (zh) * 2019-09-29 2019-12-20 腾讯科技（深圳）有限公司 基于区块链网络的应用评价方法及装置
CN110602138A (zh) * 2019-09-26 2019-12-20 腾讯科技（深圳）有限公司 区块链网络的数据处理方法、装置、电子设备及存储介质
CN110874492A (zh) * 2018-08-29 2020-03-10 阿里巴巴集团控股有限公司 数据处理方法、装置、计算设备及系统
US20200233858A1 (en) * 2019-01-22 2020-07-23 International Business Machines Corporation Peer partitioning
CN111629039A (zh) * 2020-05-20 2020-09-04 中国银联股份有限公司 一种区块链共识方法及客户端、背书节点、排序节点
CN112732799A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110233868A (zh) * 2019-04-20 2019-09-13 北京工业大学 一种基于Fabric的边缘计算数据安全与隐私保护方法
CN110399373B (zh) * 2019-06-26 2024-02-02 杭州慧牧科技有限公司 一种区块链账本存储系统、存储查询方法及删除方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110874492A (zh) * 2018-08-29 2020-03-10 阿里巴巴集团控股有限公司 数据处理方法、装置、计算设备及系统
US20200233858A1 (en) * 2019-01-22 2020-07-23 International Business Machines Corporation Peer partitioning
CN110266659A (zh) * 2019-05-31 2019-09-20 联想(北京)有限公司 一种数据处理方法和设备
CN110602138A (zh) * 2019-09-26 2019-12-20 腾讯科技（深圳）有限公司 区块链网络的数据处理方法、装置、电子设备及存储介质
CN110599069A (zh) * 2019-09-29 2019-12-20 腾讯科技（深圳）有限公司 基于区块链网络的应用评价方法及装置
CN111629039A (zh) * 2020-05-20 2020-09-04 中国银联股份有限公司 一种区块链共识方法及客户端、背书节点、排序节点
CN112732799A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置

Also Published As

Publication number Publication date
CN112732799A (zh) 2021-04-30
CN112732799B (zh) 2021-11-02

Similar Documents

Publication Publication Date Title
US11651109B2 (en) Permission management method, permission verification method, and related apparatus
US10944570B2 (en) Method and server for providing notary service for file and verifying file recorded by notary service
CN110096857B (zh) 区块链系统的权限管理方法、装置、设备和介质
US10372942B1 (en) Method and server for providing notary service for file and verifying file recorded by notary service
WO2022206437A1 (zh) 查询Fabric区块链账本数据的方法和装置
JP2020511017A (ja) ブロックチェーンベースのデジタル証明書を実装するためのシステム及び方法
JP6574168B2 (ja) 端末識別方法、ならびにマシン識別コードを登録する方法、システム及び装置
US20210006410A1 (en) Method for providing virtual asset service based on decentralized identifier and virtual asset service providing server using them
JP2020511018A (ja) デジタル・マークを生成するためのシステム及び方法
CN110069908A (zh) 一种区块链的权限控制方法及装置
US20220329446A1 (en) Enhanced asset management using an electronic ledger
Tate et al. Multi-user dynamic proofs of data possession using trusted hardware
WO2022206431A1 (zh) 查询Fabric区块链账本数据的方法和装置
WO2023045617A1 (zh) 一种交易数据处理方法、装置、设备以及介质
JP2023542681A (ja) ブロックチェーンの許可フレームワークへのデバイスアイデンティティの統合
WO2022206454A1 (zh) 提供跨链消息的方法和装置
WO2023207086A1 (zh) 一种基于区块链的用户数据流转方法、装置及设备
CN109491965A (zh) 购售电合同的存储方法及其网络和电子设备
CN110910110A (zh) 一种数据处理方法、装置及计算机存储介质
US20200349566A1 (en) Device control method and related device
CN109388923B (zh) 一种程序执行方法及装置
WO2022206433A1 (zh) 一种在Fabric区块链中预执行链码的方法和装置
WO2022206432A1 (zh) 查询Fabric区块链账本数据的方法和装置
KR102294569B1 (ko) 블록체인 네트워크를 구축할 수 있는 블록체인 관리시스템
CN115412253B (zh) 基于区块链技术的数字证书制备方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22778614

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22778614

Country of ref document: EP

Kind code of ref document: A1