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

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

Info

Publication number
WO2022206432A1
WO2022206432A1 PCT/CN2022/081713 CN2022081713W WO2022206432A1 WO 2022206432 A1 WO2022206432 A1 WO 2022206432A1 CN 2022081713 W CN2022081713 W CN 2022081713W WO 2022206432 A1 WO2022206432 A1 WO 2022206432A1
Authority
WO
WIPO (PCT)
Prior art keywords
query
node
tee
query result
transaction
Prior art date
Application number
PCT/CN2022/081713
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 WO2022206432A1 publication Critical patent/WO2022206432A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2458Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471Distributed queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

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 this system interface, and return the execution result and digital signature after the pre-execution. 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 page in each box), and each transaction records the read and write set acquired by the transaction during pre-execution.
  • 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 1 in Figure 1, 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 2 After completing the first step, that is, after verifying the execution status of each transaction in block 0, based on each parameter determined by the execution of each transaction in block 0 (ie, the world state), as marked with 2 in Figure 1 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 a Fabric blockchain, where the Fabric blockchain includes a client node and at least one endorsement node, the client node includes a TEE, and the The method is performed by a client node in the Fabric blockchain, and includes: respectively sending transaction proposals to the at least one endorsement node, where the transaction proposals are used to request query of the first ledger data; The pre-execution result of the transaction proposal and the signature of the corresponding endorsement node on the pre-execution result, wherein each pre-execution result includes the query result of the corresponding endorsement node; each pre-execution result and the corresponding signature are provided to the TEE ; Determine the authenticity of each query result through the TEE.
  • 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 determining the authenticity of each query result by the TEE includes determining the authenticity of each query result based on a predetermined endorsement policy by the TEE.
  • determining the authenticity of each query result by the TEE includes determining, by the TEE, the number of identical query results in at least two query results received from the at least two endorsing nodes, thereby Determine the authenticity of each query result.
  • determining the authenticity of each query result by the TEE includes verifying, by the TEE, a signature corresponding to the each query result to determine the authenticity of each query result.
  • the method further includes: in the case where it is determined by the TEE that each query result includes a real query result, signing the real query result to obtain a first signature, and converting the real query result The result and the first signature are sent to the user equipment.
  • the first ledger data is block data or transaction data.
  • the Fabric blockchain includes a client node and at least one endorsement node, the client node includes a TEE, and the device is deployed in the Fabric
  • the client node in the blockchain includes: a first sending unit, configured to send a transaction proposal to the at least one endorsement node respectively, where the transaction proposal is used to request to query the first ledger data; a first receiving unit, configured to In order to receive from the at least one endorsement node the pre-execution result of the transaction proposal and the corresponding endorsement node's signature on the pre-execution result, wherein each pre-execution result includes the query result of the corresponding endorsement node;
  • the providing unit is configured to provide each pre-execution result and the corresponding signature to the TEE; the first determining unit is configured to determine the authenticity of each query result through the TEE.
  • 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 second 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.
  • At least two endorsement nodes are preset in the Fabric blockchain, and the first determination unit is further configured to determine the authenticity of each query result based on a predetermined endorsement policy through the TEE.
  • the first determining unit is further configured to determine, by the TEE, the number of identical query results in at least two query results received from the at least two endorsing nodes, thereby determining each query authenticity of the results.
  • the first determining unit is further configured to verify the signature corresponding to each query result through the TEE, so as to determine the authenticity of each query result.
  • the apparatus further includes: a signature unit, configured to, in the case where it is determined by the TEE that each query result includes a real query result, sign the real query result to obtain a first signature , a second sending unit configured to send the real query result and the first signature to the user equipment.
  • a signature unit configured to, in the case where it is determined by the TEE that each query result includes a real query result, sign the real query result to obtain a first signature
  • a second sending unit configured to send the real query result and the first signature to the user equipment.
  • 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 verification Multiple blocks, which greatly saves the query time; the query initiator only needs to obtain the data authorization of the target block or transaction to carry out the query, and does not need to obtain the full account book authorization; in addition, the query initiator only needs to record the management equipment
  • the public key of the TEE in the blockchain is used to verify the signature of the ledger data sent from the management device without recording the respective public keys of multiple endorsing nodes in the blockchain.
  • 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 an apparatus 500 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 authority to query ledger data, including a Trusted Execution Environment (TEE).
  • the TEE can be, for example, a trusted execution environment generated by technologies such as SGX and Trust Zone.
  • 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, and provides the public key information of Node 1-Node 3 to the TEE.
  • the user equipment 21 may first verify the TEE in the management device 22. Specifically, the user equipment 21 may send an authentication request to the TEE. After receiving the verification request, the TEE generates authentication information based on its internal mechanism, and sends the authentication information and the hardware public key of the TEE to the user equipment 21 .
  • the authentication information includes, for example, signature information, hardware information, software information, and the like of the TEE.
  • the signature information is generated by, for example, the hardware key of the TEE; the hardware information includes, for example, various hardware indicators, such as CPU frequency, memory capacity, etc.; the software information includes the code hash value of each program , code name, version, run log, etc.
  • a TEE can perform "measurements" of a program running in it through memory hardware, such as obtaining a code hash of the program, a hash of the program's memory occupancy at a particular point of execution, etc.
  • the authentication information includes "measurement” information for the program, which is authentic and credible because the "measurement” information is executed by the TEE's own entity (memory hardware) without involving any software or operating system.
  • the user equipment 21 may send the authentication information to the remote authentication server of the TEE, so as to receive the verification result of the TEE from the server.
  • the verification result includes the identity verification of the TEE, the verification of the internal execution program of the TEE, and the like.
  • the user equipment 21 can determine that the TEE is credible, and the processing result of the TEE is credible. At the same time, the user equipment 21 locally saves the hardware public key of the TEE for subsequent verification of the signature of the TEE.
  • 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, and the management device 22 After verifying the user 1's application, authorize the user 1 with the query authority, and record the authorization to the user 1 locally, for example, the account identifier of the user 1 and the authorized authority of the user 1 can be recorded.
  • 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 the management device 22 receives the pre-execution results and signatures of the transaction A from nodes 1 to 3, it determines the real data in each query result based on the predetermined endorsement policy through the TEE, the TEE signs the real data, and the real data is signed by the TEE. and TEE signature are provided 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. After receiving the transaction A proposal from the management device 22, the node 1 pre-executes the transaction A, and the pre-execution executes the transaction A, but does not store the acquired transaction execution result in the local ledger. Specifically, 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 through the TEE.
  • the management device 22 After receiving the respective read-write sets and their signatures from the nodes 1-3, the management device 22 provides the respective read-write sets and their signatures to the TEE, that is, as input data of the TEE, to the TEE.
  • each endorsing node is pre-stored in the TEE, and a program for verifying each signature and verifying each query result through the corresponding public key is set in the TEE. Therefore, in the TEE, each signature is first verified using the pre-recorded public key of each node 1-3.
  • the TEE After the signature verification is passed, the TEE also verifies whether the query result included in each read-write set is the real data of transaction m based on the preset endorsement policy.
  • a consistency threshold may be preset in the TEE, and the consistency threshold is used to limit the minimum number of identical query results among the plurality of query results, so that the authenticity of the query result is determined by the consistency threshold.
  • 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 TEE may determine the endorsement policy based on the trustworthiness of each endorsement node. For example, the credibility of node 1 is relatively high, and it can be set that as long as the query results of node 1 and any other node are the same, the query results of node 1 can be considered to be true, and the credibility of node 2 is lower. Then, it can be set that only when the query results of node 2, node 1, and node 3 are the same, the query result of node 2 can be considered to be true.
  • step S314 the management device 22 signs the real query result through the TEE.
  • the TEE After the TEE performs the above verification process, if it is determined that the above three query results include real query results, it will use its own hardware public key to sign the real query results. Specifically, the TEE calculates the hash of the real query results. value, and encrypt the hash value with its own hardware private key, so as to obtain the signature (ie, digital signature) of the real query result. After signing, the TEE outputs the real query result and the signature to the management device 22 .
  • the signature ie, digital signature
  • step S316 the management device 22 returns the ledger data and the TEE signature to the user device 21.
  • the management device 22 After obtaining the real query result (ie the ledger data including the content of transaction m and the execution status of transaction m) and its TEE signature from the TEE, the management device 22 returns the ledger data and its TEE signature to the user equipment 21 .
  • the real query result ie the ledger data including the content of transaction m and the execution status of transaction m
  • the management device 22 After obtaining the real query result (ie the ledger data including the content of transaction m and the execution status of transaction m) and its TEE signature from the TEE, the management device 22 returns the ledger data and its TEE signature to the user equipment 21 .
  • step S318 the user equipment 21 verifies the TEE signature.
  • the user equipment 21 After receiving the ledger data and its TEE signature from the management device 22, the user equipment 21 uses the pre-acquired public key of the TEE to verify the TEE signature. Specifically, the user equipment 21 decrypts the TEE signature using the TEE public key, calculates the hash value of the ledger data, and compares whether the data obtained by decryption is consistent with the hash value of the ledger data. If they are consistent, the verification of the TEE signature is passed. . After the verification is passed, it can be confirmed that the ledger data is indeed the real ledger data determined by the TEE verification.
  • 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 differs from the method shown in FIG. 3 in that, in the method shown in FIG. 4, the management device 22 only sends the transaction proposal to one peer node (ie, node 1), in which 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.
  • steps S402 - S410 , S416 and S418 may refer to the above descriptions of steps S302 - S310 , S316 and S318 , which will not be described in detail here.
  • step S412 the management device 22 verifies the query result sent by the node 1 through the TEE.
  • the TEE uses the public key of node 1 to The signature is verified, and after the verification is passed, it can be determined that the query result is true.
  • step S414 the management device 22 signs the real query result through the TEE.
  • the TEE After the TEE performs the above verification process, if it is determined that the query result is the real query result, the TEE uses its own hardware public key to sign the real query result. After signing the real query result, the TEE outputs the real query data and its signature to the management device 22 .
  • FIG. 5 shows an apparatus 500 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, and the client node includes a TEE.
  • the device is deployed on a client node in the Fabric blockchain, including: a first sending unit 51, configured to send a transaction proposal to the at least one endorsement node, respectively, where the transaction proposal is used to request to query the first ledger data;
  • the first receiving unit 52 is configured to respectively receive, from the at least one endorsing node, a pre-execution result of the transaction proposal and a signature of the corresponding endorsing node on the pre-execution result, wherein each pre-execution result includes a corresponding pre-execution result.
  • the providing unit 53 is configured to provide each pre-execution result and the corresponding signature to the TEE; the first determining unit 54 is configured to determine the authenticity of each query result through the TEE.
  • the apparatus 500 further includes: a second receiving unit 55, configured to, before sending the transaction proposal to the at least one endorsing node respectively, receive from the user equipment of the user the first ledger data
  • the second determining unit 56 is configured to determine whether the user has the right to query the first ledger data
  • the first sending unit 51 is further configured to, after determining that the user has the right to query the first ledger data
  • the transaction proposals are respectively sent to the at least one endorsement node.
  • At least two endorsement nodes are preset in the Fabric blockchain, and the first determination unit 54 is further configured to determine the authenticity of each query result based on a predetermined endorsement policy through the TEE.
  • the first determining unit 54 is further configured to determine, by the TEE, the number of the same query results in at least two query results received from the at least two endorsing nodes, thereby determining each Authenticity of query results.
  • the first determining unit 54 is further configured to verify the signature corresponding to each query result through the TEE, so as to determine the authenticity of each query result.
  • the apparatus 500 further includes: a signing unit 57, configured to, in the case that each query result includes a real query result determined by the TEE, sign the real query result to obtain the first query result.
  • a signature the second sending unit 58 is configured to send the real query result and the first signature to the user equipment.
  • 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 verification Multiple blocks, which greatly saves the query time; the query initiator only needs to obtain the data authorization of the target block or transaction to carry out the query, and does not need to obtain the full account book authorization; in addition, the query initiator only needs to record the management equipment
  • the public key of the TEE in the blockchain is used to verify the signature of the ledger data sent from the management device without recording the respective public keys of multiple endorsing nodes in the blockchain.
  • 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)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Computational Linguistics (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Probability & Statistics with Applications (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Development Economics (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本说明书实施例提供了一种查询Fabric区块链账本数据的方法和装置,所述方法由Fabric区块链中的客户端节点执行,包括:向所述至少一个背书节点分别发送交易提案,所述交易提案用于请求查询第一账本数据;从所述至少一个背书节点分别接收对所述交易提案的预执行结果及相应的背书节点对所述预执行结果的签名,其中,各个预执行结果中包括相应的背书节点的查询结果;将各个预执行结果及相应的签名提供给TEE;通过所述TEE确定各个查询结果的真实性。

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中的①、②、③三个计算步骤。首先,在第①步骤,如图1中标注了①的箭头所示,验证区块0中各个交易的执行状态。具体是,按照区块0中的各个交易的顺序分别验证各个交易的读写集是否能成功执行。基于各个交易的排序,有可能前序交易的执行改变了某个参数的值,从而使得后续交易的读写失败,在该情况下,后续交易未能成功执行,该对等节点在验证时就将该后续交易标记为“0”,以指示该交易未能成功执行。如果交易的读写不与前序交易的读写冲突,可以成功执行,该对等节点就将该交易标记为“1”,以指示该交易成功执行。
在完成第①步骤,即,验证了区块0中各个交易的执行状态之后,基于由区块0中的各个交易的执行确定的各个参数(即世界状态),如图1中的以②标注的箭头所示,执行第②步骤。在该第②步骤中,对等节点基于当前的世界状态顺序验证区块1中各个交易是否能成功执行,并以“0”或“1”对各个交易分别进行标记(如以②标注的箭头指向的区块1中所示)。
之后,在完成第②步骤之后,类似地,如图1中的以③标注的箭头所示,执行第③步骤。在该第③步骤中,对等节点基于当前的世界状态顺序验证区块2中各个交易是否能成功执行,并对各个交易分别进行标记(如以③标注的箭头指向的区块2中所示),直到执行到用户需要查询的区块2中的目标交易。
通常,用户对Fabric区块链的查询需求是低频需求,因此,在获取目标交易的执行状态之后,为了不占用机器资源,用户设备中通常删除对等节点配置,从而,当用户再 次需要查询Fabric区块链的账本数据时,仍需要再次执行上述整个过程。
因此,需要一种更有效的查询Fabric区块链中账本数据的方案。
发明内容
本说明书实施例旨在提供一种更有效的查询Fabric区块链账本数据的方案,以解决现有技术中的不足。
为实现上述目的,本说明书一个方面提供一种查询Fabric区块链账本数据的方法,所述Fabric区块链中包括客户端节点和至少一个背书节点,所述客户端节点中包括TEE,所述方法由Fabric区块链中的客户端节点执行,包括:向所述至少一个背书节点分别发送交易提案,所述交易提案用于请求查询第一账本数据;从所述至少一个背书节点分别接收对所述交易提案的预执行结果及相应的背书节点对所述预执行结果的签名,其中,各个预执行结果中包括相应的背书节点的查询结果;将各个预执行结果及相应的签名提供给TEE;通过所述TEE确定各个查询结果的真实性。
在一种实施方式中,所述方法还包括:在向所述至少一个背书节点分别发送交易提案之前,从用户的用户设备接收对所述第一账本数据的查询请求;确定所述用户是否具有对所述第一账本数据的查询权限;所述向所述至少一个背书节点分别发送交易提案包括,在确定所述用户具有对所述第一账本数据的查询权限的情况下,向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中,所述Fabric区块链中包括至少两个背书节点,通过所述TEE确定各个查询结果的真实性包括,通过所述TEE基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中,通过所述TEE确定各个查询结果的真实性包括,通过所述TEE在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数,从而确定各个查询结果的真实性。
在一种实施方式中,通过所述TEE确定各个查询结果的真实性包括,通过所述TEE对所述各个查询结果对应的签名进行验证,以确定各个查询结果的真实性。
在一种实施方式中,所述方法还包括:在通过所述TEE确定各个查询结果中包括真实查询结果的情况中,对所述真实查询结果进行签名以获取第一签名,将所述真实查询结果及所述第一签名发送给所述用户设备。
在一种实施方式中,所述第一账本数据为区块数据或交易数据。
本说明书另一方面提供一种查询Fabric区块链账本数据的装置,所述Fabric区块链中包括客户端节点和至少一个背书节点,所述客户端节点中包括TEE,所述装置部署于Fabric区块链中的客户端节点,包括:第一发送单元,配置为,向所述至少一个背书节点分别发送交易提案,所述交易提案用于请求查询第一账本数据;第一接收单元,配置为,从所述至少一个背书节点分别接收对所述交易提案的预执行结果及相应的背书节点对所述预执行结果的签名,其中,各个预执行结果中包括相应的背书节点的查询结果;提供单元,配置为,将各个预执行结果及相应的签名提供给TEE;第一确定单元,配置为,通过所述TEE确定各个查询结果的真实性。
在一种实施方式中,所述装置还包括:第二接收单元,配置为,在向所述至少一个背书节点分别发送交易提案之前,从用户的用户设备接收对所述第一账本数据的查询请求;第二确定单元,配置为,确定所述用户是否具有对所述第一账本数据的查询权限;所述第一发送单元还配置为,在确定所述用户具有对所述第一账本数据的查询权限的情况下,向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中,所述Fabric区块链中预设有至少两个背书节点,所述第一确定单元还配置为,通过所述TEE基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中,所述第一确定单元还配置为,通过所述TEE在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数,从而确定各个查询结果的真实性。
在一种实施方式中,所述第一确定单元还配置为,通过所述TEE对所述各个查询结果对应的签名进行验证,以确定各个查询结果的真实性。
在一种实施方式中,所述装置还包括:签名单元,配置为,在通过所述TEE确定各个查询结果中包括真实查询结果的情况中,对所述真实查询结果进行签名以获取第一签名,第二发送单元,配置为,将所述真实查询结果及所述第一签名发送给所述用户设备。
本说明书另一方面提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现上述任一项方法。
通过本说明书实施例提供的Fabric区块链查询方案,查询发起方可快速高效地获取 链上账本数据并可验证该账本数据的真实性,无需运行独立的对等节点以及等待对等节点同步验证多个区块,大大节省了查询时间;查询发起方只需要获取目标区块或交易的数据授权即可进行所述查询,而不需要获取全量账本授权;另外,查询发起方只需要记录管理设备中TEE的公钥,以用于对从管理设备发送的账本数据的签名进行验证,而不需要记录区块链中多个背书节点各自的公钥。
附图说明
通过结合附图描述本说明书实施例,可以使得本说明书实施例更加清楚:
图1示意示出新启动的对等节点的查询操作过程;
图2示出根据本说明书实施例的Fabric区块链查询***的示意图;
图3示出根据本说明书实施例的一种查询Fabric区块链账本数据的方法流程图;
图4示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图;
图5示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置500。
具体实施方式
下面将结合附图描述本说明书实施例。
图2示出根据本说明书实施例的Fabric区块链查询***的示意图。如图2中所示,所述查询***中包括用户设备21、管理设备22和Fabric区块链23。其中,用户设备21可以为Fabric区块链的链下设备,其可以为Fabric区块链的使用用户的设备,其它区块链的节点设备、或者用于在多个区块链之间中转消息的中继器的设备等等,在此不作限定。管理设备22向用户设备21提供对Fabric区块链的账本数据的查询服务。管理设备22本身是Fabric区块链的具有账本数据查询权限的客户端节点,其中包括可信执行环境(Trusted Execution Environment,TEE)。所述TEE例如可以为通过SGX、Trust Zone等技术生成的可信执行环境。Fabric区块链23在图2中示意示出为包括对等节点1-4。
在执行本说明书实施例提供的方法之前,管理设备22从Fabric区块链23的多个对等节点中选取一个或多个对等节点作为背书节点,例如选择节点1、节点2和节点3作为背书节点。管理设备22在进行该选择之后分别通知节点1、节点2和节点3,从而使得节点1-节点3分别开启背书节点权限。同时,管理设备22记录节点1-节点3的连接 信息和公钥信息,并将节点1-节点3的公钥信息提供给TEE。
用户设备21在通过管理设备22查询区块链23账本数据之前,可首先对管理设备22中的TEE进行验证。具体是,用户设备21可向TEE发送验证请求。TEE在接收所述验证请求之后,基于其内部机制生成认证信息,并将该认证信息及TEE的硬件公钥发送给用户设备21。所述认证信息例如包括所述TEE的签名信息、硬件信息和软件信息等。其中,所述签名信息例如通过TEE的硬件密钥生成;所述硬件信息例如包括,各种硬件的指标,比如CPU主频,内存容量等等;所述软件信息包括各个程序的代码哈希值、代码名称、版本、运行日志等。如本领域技术人员所知,TEE可通过内存硬件执行对其中运行程序的“测量”,例如获取该程序的代码哈希值、该程序在特定执行点的内存占有的哈希值等等,并在所述认证信息中包括对所述程序的“测量”信息,由于该“测量”信息由该TEE自身实体(内存硬件)执行,而不涉及任何软件、操作***,因此是真实可信的。用户设备21在接收到所述认证信息之后,可把所述认证信息发送给TEE的远程认证服务器,从而从所述服务器接收到对所述TEE的验证结果。所述验证结果包括所述TEE的身份验证、及对所述TEE内部执行程序的验证等等。从而,用户设备21基于该验证结果可确定TEE是可信的,TEE的处理结果是可信的。同时,用户设备21在本地保存TEE的硬件公钥,以用于后续对TEE的签名的验证。
用户设备21对应的用户(例如用户1)在进行对Fabric区块链23的账本数据(例如区块n中的交易m)的查询之前,向管理设备22申请对账本数据的查询权限,管理设备22在对用户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的预执行结果和签名之后,通过TEE基于预定背书策略确定各个查询结果中的真实数据,由TEE对真实数据进行签名,并将该真 实数据及TEE签名提供给用户设备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进行预执行,所述预执行即执行交易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通过TEE验证查询结果。
管理设备22在从节点1-3分别接收到各个读写集及其签名之后,将各个读写集及其签名提供给TEE,即作为TEE的输入数据输入给TEE。
TEE中预先存储了各个背书节点的公钥,并且,TEE中设置了通过相应的公钥对各个签名进行验签、以及对各个查询结果进行验证的程序。因此,在TEE中,首先使用预先记录的节点1-3各自的公钥对各个签名进行验证。
在签名验证通过之后,TEE还基于预设的背书策略来验证各个读写集中包括的查询结果是否为交易m的真实数据。在一种实施方式中,TEE中可预设一致性阈值,该一致性阈值用于限定多个查询结果中的最少相同查询结果个数,从而通过该一致性阈值来确定查询结果的真实性。例如,所述一致性阈值可设定为2/3,即,对于3个查询结果,如果其中至少2个查询结果是相同的,则可确定该2个查询结果为真实查询结果,如果该3个查询结果中相同查询结果的总数小于2个(即3个查询结果互不相同),则可确定该3个查询都不是真实的。
在一种实施方式中,TEE可基于各个背书节点的可信程度来确定背书策略。例如,节点1的可信程度较高,可设定,只要节点1与任一另一个节点的查询结果相同,则可认为节点1的查询结果是真实的,节点2的可信程度较低,则可以设定,仅在节点2与节点1、节点3的查询结果都相同的情况中,才可以认为节点2的查询结果是真实的。
在步骤S314,管理设备22通过TEE对真实查询结果进行签名。
TEE在进行上述验证过程之后,如果确定上述三个查询结果中包括真实的查询结果,则使用自身的硬件公钥对该真实的查询结果进行签名,具体是,TEE计算该真实查询结果的哈希值,并使用自身的硬件私钥对该哈希值进行加密,从而获取对该真实的查询结果的签名(即数字签名)。TEE在进行签名之后将真实的查询结果及所述签名输出给管理设备22。
在步骤S316,管理设备22将账本数据及TEE签名返回给用户设备21。
管理设备22在从TEE获取真实的查询结果(即包括交易m的内容和交易m的执行状态的账本数据)及其TEE签名之后,将该账本数据及其TEE签名返回给用户设备21。
在步骤S318,用户设备21对TEE签名进行验证。
用户设备21在从管理设备22接收账本数据及其TEE签名之后,使用预先获取的TEE的公钥对该TEE签名进行验证。具体是,用户设备21使用TEE公钥对TEE签名进行解密,计算账本数据的哈希值,并比较解密获取的数据与账本数据的哈希值是否一致,如果一致,则对TEE签名的验证通过。在验证通过之后,可确认该账本数据确实是通过TEE的验证所确定的真实账本数据。
图4示出根据本说明书另一实施例的一种查询Fabric区块链账本数据的方法流程图。图4所示方法与图3所示方法不同在于,在图4所示方法中,管理设备22只将交易提案发送给一个对等节点(即节点1),在该情况中,管理设备22认为节点1为可信节点,因此,直接将从节点1接收的查询结果认为是真实的,而不需要如图所示方法那样,从多个节点接收到多个查询结果,并对多个查询结果进行一致性验证。
在图4中,步骤S402-步骤S410、步骤S416和步骤S418可参考上文对步骤S302-步骤S310、步骤S316和步骤S318的描述,在此不再详述。
在步骤S412中,管理设备22通过TEE验证由节点1发送的查询结果。
具体是,与上文描述类似地,TEE在从节点1接收到对所述交易A的预执行读写集和节点1对所述读写集的签名之后,使用节点1的公钥对所述签名进行验证,在验证通过之后,可确定所述查询结果为真实的。
在步骤S414,管理设备22通过TEE对真实查询结果进行签名。
TEE在进行上述验证过程之后,如果确定所述查询结果是真实的查询结果,则使用自身的硬件公钥对该真实的查询结果进行签名。TEE在对真实查询结果进行签名之后,将真实查询数据及其签名输出给管理设备22。
图5示出根据本说明书实施例的一种查询Fabric区块链账本数据的装置500,所述Fabric区块链中包括客户端节点和至少一个背书节点,所述客户端节点中包括TEE,所述装置部署于Fabric区块链中的客户端节点,包括:第一发送单元51,配置为,向所述至少一个背书节点分别发送交易提案,所述交易提案用于请求查询第一账本数据;第 一接收单元52,配置为,从所述至少一个背书节点分别接收对所述交易提案的预执行结果及相应的背书节点对所述预执行结果的签名,其中,各个预执行结果中包括相应的背书节点的查询结果;提供单元53,配置为,将各个预执行结果及相应的签名提供给TEE;第一确定单元54,配置为,通过所述TEE确定各个查询结果的真实性。
在一种实施方式中,所述装置500还包括:第二接收单元55,配置为,在向所述至少一个背书节点分别发送交易提案之前,从用户的用户设备接收对所述第一账本数据的查询请求;第二确定单元56,配置为,确定所述用户是否具有对所述第一账本数据的查询权限;所述第一发送单元51还配置为,在确定所述用户具有对所述第一账本数据的查询权限的情况下,向所述至少一个背书节点分别发送所述交易提案。
在一种实施方式中,所述Fabric区块链中预设有至少两个背书节点,所述第一确定单元54还配置为,通过所述TEE基于预定背书策略确定各个查询结果的真实性。
在一种实施方式中,所述第一确定单元54还配置为,通过所述TEE在从所述至少两个背书节点接收的至少两个查询结果中确定相同查询结果的个数,从而确定各个查询结果的真实性。
在一种实施方式中,所述第一确定单元54还配置为,通过所述TEE对所述各个查询结果对应的签名进行验证,以确定各个查询结果的真实性。
在一种实施方式中,所述装置500还包括:签名单元57,配置为,在通过所述TEE确定各个查询结果中包括真实查询结果的情况中,对所述真实查询结果进行签名以获取第一签名,第二发送单元58,配置为,将所述真实查询结果及所述第一签名发送给所述用户设备。
本说明书另一方面提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现上述任一项方法。
通过本说明书实施例提供的Fabric区块链查询方案,查询发起方可快速高效地获取链上账本数据并可验证该账本数据的真实性,无需运行独立的对等节点以及等待对等节点同步验证多个区块,大大节省了查询时间;查询发起方只需要获取目标区块或交易的数据授权即可进行所述查询,而不需要获取全量账本授权;另外,查询发起方只需要记录管理设备中TEE的公钥,以用于对从管理设备发送的账本数据的签名进行验证,而 不需要记录区块链中多个背书节点各自的公钥。
需要理解,本文中的“第一”,“第二”等描述,仅仅为了描述的简单而对相似概念进行区分,并不具有其他限定作用。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于***实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本领域普通技术人员应该还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。其中,软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (16)

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

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=75596146

Family Applications (1)

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

Country Status (2)

Country Link
CN (1) CN112732801B (zh)
WO (1) WO2022206432A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732801B (zh) * 2021-03-30 2021-08-20 支付宝(杭州)信息技术有限公司 查询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 联想(北京)有限公司 一种数据处理方法和设备
CN110933108A (zh) * 2019-09-26 2020-03-27 腾讯科技(深圳)有限公司 基于区块链网络的数据处理方法、装置、电子设备及存储介质
US20200233858A1 (en) * 2019-01-22 2020-07-23 International Business Machines Corporation Peer partitioning
CN111629039A (zh) * 2020-05-20 2020-09-04 ***股份有限公司 一种区块链共识方法及客户端、背书节点、排序节点
CN112734431A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置
CN112732801A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置
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
CN110399373B (zh) * 2019-06-26 2024-02-02 杭州慧牧科技有限公司 一种区块链账本存储***、存储查询方法及删除方法
CN111242620A (zh) * 2020-01-15 2020-06-05 阳光易购(湖南)科技有限公司 区块链交易***的数据缓存及查询方法、终端及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200233858A1 (en) * 2019-01-22 2020-07-23 International Business Machines Corporation Peer partitioning
CN110266659A (zh) * 2019-05-31 2019-09-20 联想(北京)有限公司 一种数据处理方法和设备
CN110933108A (zh) * 2019-09-26 2020-03-27 腾讯科技(深圳)有限公司 基于区块链网络的数据处理方法、装置、电子设备及存储介质
CN111629039A (zh) * 2020-05-20 2020-09-04 ***股份有限公司 一种区块链共识方法及客户端、背书节点、排序节点
CN112734431A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置
CN112732801A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置
CN112732799A (zh) * 2021-03-30 2021-04-30 支付宝(杭州)信息技术有限公司 查询Fabric区块链账本数据的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DING JIACHEN: "Research on Private Information Retrieval Based on Blockchain", INFORMATION SCIENCE AND TECHNOLOGY, CHINESE MASTER’S THESES FULL-TEXT DATABASE, no. 8, 15 August 2019 (2019-08-15), XP055973536 *

Also Published As

Publication number Publication date
CN112732801B (zh) 2021-08-20
CN112732801A (zh) 2021-04-30

Similar Documents

Publication Publication Date Title
US11651109B2 (en) Permission management method, permission verification method, and related apparatus
CN109409122B (zh) 文件存储方法及其电子设备、存储介质
WO2022206437A1 (zh) 查询Fabric区块链账本数据的方法和装置
US10491396B2 (en) Method and server for providing notary service for file and verifying file recorded by notary service
US10372942B1 (en) Method and server for providing notary service for file and verifying file recorded by notary service
US7698736B2 (en) Secure delegation using public key authentication
CN109377198A (zh) 一种基于联盟链多方共识的签约***
WO2018032377A1 (zh) 一种用于区块链的只读安全文件存储***及其方法
JP3272283B2 (ja) 電子データ保管装置
US8006084B2 (en) Apparatus and method for managing plurality of certificates
KR101937220B1 (ko) 키 관리가 필요없는 블록체인을 기반한 전자서명 또는 메시지 인증 코드를 생성 및 검증 방법
US11403417B2 (en) Managing group authority and access to a secured file system in a decentralized environment
CN106991298A (zh) 应用程序对接口的访问方法、授权请求方法及装置
US20220329446A1 (en) Enhanced asset management using an electronic ledger
WO2022206431A1 (zh) 查询Fabric区块链账本数据的方法和装置
CN112235260B (zh) 一种匿名数据存证方法、装置、设备和存储介质
WO2022206454A1 (zh) 提供跨链消息的方法和装置
US20190294762A1 (en) Computer implemented method and a system for tracking of certified documents lifecycle and computer programs thereof
CN113259311A (zh) 基于区块链的去中心化身份认证***
US20200349566A1 (en) Device control method and related device
CN108540447B (zh) 一种基于区块链的证书验证方法及***
WO2022206432A1 (zh) 查询Fabric区块链账本数据的方法和装置
CN110910110A (zh) 一种数据处理方法、装置及计算机存储介质
CN109698750A (zh) 区块链的区块生成方法、装置、设备及可读存储介质
JP5970193B2 (ja) 検索システム、検索方法および検索プログラム

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: 22778615

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: 22778615

Country of ref document: EP

Kind code of ref document: A1