WO2020114278A1 - 区块链系统的数据管理方法、装置、介质及电子设备 - Google Patents

区块链系统的数据管理方法、装置、介质及电子设备 Download PDF

Info

Publication number
WO2020114278A1
WO2020114278A1 PCT/CN2019/120955 CN2019120955W WO2020114278A1 WO 2020114278 A1 WO2020114278 A1 WO 2020114278A1 CN 2019120955 W CN2019120955 W CN 2019120955W WO 2020114278 A1 WO2020114278 A1 WO 2020114278A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
data block
data
network
node
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2019/120955
Other languages
English (en)
French (fr)
Inventor
李茂材
王宗友
孔利
周开班
蓝虎
时一防
杨常青
张劲松
丁勇
朱耿良
刘区城
陈秋平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
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 Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Priority to EP19893257.6A priority Critical patent/EP3893455A4/en
Priority to JP2021510879A priority patent/JP7195684B2/ja
Publication of WO2020114278A1 publication Critical patent/WO2020114278A1/zh
Priority to US17/148,258 priority patent/US11968294B2/en
Anticipated expiration legal-status Critical
Priority to US18/610,127 priority patent/US12494902B2/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • This application relates to the field of computers and communication technologies, and in particular, to a data management method, device, medium, and electronic equipment of a blockchain system.
  • the data in the blockchain network may need to be sent to business nodes outside the blockchain network.
  • the data sent to the business node needs to be Signing, so that the business node can verify the data, and how to avoid the leakage of the signature key and cause the data to be insecure becomes an urgent technical problem to be solved.
  • the embodiments of the present application provide a data management method, device, medium and electronic equipment of a blockchain system, and at least to a certain extent can flexibly update the block header verification key to ensure the security of block header data Sex.
  • a data management method of a blockchain system includes an accounting node sub-network and a business node sub-network.
  • the accounting node sub-network includes accounting nodes.
  • the service node sub-network includes a service node, and the data management method includes: after a first data block is generated by a billing node in the billing node sub-network, add to the block header of the first data block The first key information used to verify the block header of the second data block generated after the first data block; generate a signature corresponding to the first data block, and set the first data area Add the signature corresponding to the block to the block header of the first data block; publish the block header of the first data block to the business node sub-network to enable business in the business node sub-network The node verifies the signature contained in the block header of the first data block, and obtains the first key information after verification to verify the block header of the second data block.
  • a data management method of a blockchain system includes an accounting node sub-network and a business node sub-network.
  • the accounting node sub-network includes accounting nodes.
  • the service node sub-network includes a service node, and the data management method is performed by a service node in the service node sub-network.
  • the data management method includes: receiving a first data block from the accounting node sub-network Block header of the first data block contains the signature and first key information used to verify the block header of the second data block generated after the first data block; Verify the signature contained in the block header of the first data block; after verifying the signature contained in the block header of the first data block, obtain the first key information to pass The first key information verifies the received block header of the second data block.
  • a data management device for a blockchain system includes an accounting node sub-network and a business node sub-network.
  • the accounting node sub-network includes accounting nodes.
  • the service node sub-network includes a service node, and the data management device includes: an adding unit for generating a first data block in the accounting node in the accounting node sub-network, after the first data block The first key information used to verify the block header of the second data block generated after the first data block is added to the block header of the; the generating unit is used to generate the corresponding Sign and add the signature corresponding to the first data block to the block header of the first data block; the sending unit is used to publish the block header of the first data block to the business node In the sub-network, the business node in the business node sub-network verifies the signature contained in the block header of the first data block, and obtains the first key information to verify the signature after passing the verification The block header of the second data block is verified.
  • a data management device for a blockchain system includes an accounting node sub-network and a business node sub-network.
  • the block header of the first data block contains a signature and first key information used to verify the block header of the second data block generated after the first data block;
  • the verification unit is used For verifying the signature contained in the block header of the first data block;
  • an acquiring unit is configured to acquire the first data block after verifying the signature contained in the block header of the first data block A key information to verify the block header of the received second data block through the first key information.
  • a computer-readable medium on which a computer program is stored, which when executed by a processor implements the data management method of the blockchain system as described in the above embodiments.
  • an electronic device including: one or more processors and a storage device; the storage device is used to store one or more programs when the one or more programs are When executed by one or more processors, the one or more processors implement the data management method of the blockchain system as described in the above embodiments.
  • the business node can obtain the first password used to verify the block header of the second data block from the block header of the first data block Key information, that is, the key information used to verify the block header of the next data block can be indicated by the block header of the previous data block, which achieves the purpose of flexibly updating the block header verification key and avoids the secret
  • the technical solution of the embodiment of the present application can obtain the key information used to verify the block header of the
  • FIG. 1 to 3 show schematic diagrams of the architecture of the blockchain system applied in the embodiments of the present application
  • FIG. 4 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application
  • FIG. 5 schematically shows a flowchart of consensus on data blocks according to an embodiment of the present application
  • FIG. 6 schematically shows a flowchart of generating a signature corresponding to a first data block according to an embodiment of the present application
  • FIG. 7 shows a schematic structural diagram of a block header of a data block according to an embodiment of the present application.
  • FIG. 8 schematically shows a flowchart of publishing the block header of the first data block to the service node sub-network according to an embodiment of the present application
  • FIG. 9 schematically shows a flowchart of publishing a block header of a first data block to a service node sub-network according to an embodiment of the present application
  • FIG. 10 schematically shows a flowchart of sending the block header of the first data block to the service node closest to the sending node according to an embodiment of the present application
  • FIG. 11 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application
  • FIG. 12 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application
  • FIG. 13 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application
  • FIG. 14 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application
  • FIG. 16 schematically shows a block diagram of a data management device of a blockchain system according to an embodiment of the present application
  • FIG. 17 shows a schematic structural diagram of a computer system suitable for implementing an electronic device according to an embodiment of the present application.
  • FIG. 1 shows an architecture of a blockchain system applied in embodiments of the present application.
  • the blockchain system includes an accounting node sub-network 2 and a business node sub-network 1.
  • the accounting node sub-network 2 includes an accounting node 21 that performs consensus on data blocks and records the data blocks on the blockchain.
  • the business node sub-network 1 includes a business node 11.
  • the business node 11 can verify the data block recorded on the blockchain by the accounting node, or can request corresponding transaction data from the accounting node.
  • the business node 11 verifying the data block recorded by the accounting node on the blockchain may include the following steps: an accounting node 21 in the accounting node sub-network uses a key specific to the accounting node, Generate a signature based on the transaction information to be included in a data block to be added to the blockchain; the accounting node 21 adds the transaction information and the generated signature to the data block and adds it to the blockchain; The accounting node 21 sends the signature to the business node in the business node sub-network, and the business node performs signature verification on the signature according to the key specific to the accounting node, so as to realize the business node 11 to the accounting node The data block recorded on the blockchain is verified.
  • the accounting node in the accounting node sub-network is responsible for recording data blocks to the blockchain, and the business node in the business node sub-network is responsible for witnessing the results recorded by the accounting node. Specifically, the accounting node generates a signature based on the transaction information to be included in a data block to be added to the blockchain, and then adds the transaction information and the generated signature to the data block to perform the chain. The signature is sent to a service node in the service node sub-network, so that the service node performs signature verification on the signature according to a key specific to the accounting node. Business nodes in the business node sub-network can witness the transaction data of the entire network by verifying the signature of the accounting node on the block.
  • the accounting network has a monopoly accounting right, but because the data block has a digital signature representing the identity of the bookkeeper, all actions are publicly traceable. If the accounting nodes collectively commit evil, then all the nodes that witness the transaction data of the entire network will retain evidence of the specific accounting nodes committing evil.
  • the operation of the system is more transparent in this scheme; compared with the traditional decentralized public chain scheme, this scheme is more controllable and easier to supervise.
  • the accounting node sub-network 2 and the business node sub-network 1 may be connected by a proxy node 12, and the proxy node 12 may be a business node of the business node sub-network 1, which is responsible for accounting
  • the information to be transferred by the node 21 to the service node 11 is transferred to the service node 11.
  • the business node 11 is a terminal of a transaction party that generates various transaction data that needs to be uploaded to the chain, or may be a terminal that queries transaction data from the accounting node sub-network 2.
  • the transaction data generated by the business node 11 is transmitted to the accounting node 21 through the proxy node 12, and then recorded on the blockchain after consensus, which is conducive to the unified processing and supervision of transaction data, and the business node 11 can also pass the accounting node 21
  • the information sent by the proxy node 12 is used to supervise and witness the transaction data on-chain, which is of great significance in certain scenarios that require unified supervision but are afraid that the supervised nodes collectively cheat and therefore need supervision.
  • the service node sub-network 1 adopts the P2P network mode.
  • P2P network is a distributed application architecture that distributes tasks and workloads among peers. It is a form of networking or network formed at the application layer by the peer-to-peer computing model, that is, "point-to-point" or "end-to-end”.
  • Peer network. It can be defined as: Participants of the network share part of their own hardware resources (processing power, storage capacity, network connection capabilities, printers, etc.). These shared resources provide services and content through the network and can be directly accessed by other peer nodes Without going through intermediate entities. Participants in this network are not only providers of resources, services and content, but also acquirers of resources, services and content.
  • the proxy node 12 when the proxy node 12 receives the message passed from the accounting node 21, it propagates to the surrounding business node 11, and the surrounding business node 11 receives the message and then sends it to the surrounding
  • the service node 11 of the server transmits the message between each service node 11 of the service node sub-network 1.
  • FIG. 2 shows an architecture of another blockchain system applied in the embodiments of the present application.
  • This system architecture differs from the system architecture shown in FIG. 1 in that the service node sub-network 1 does not adopt the P2P network mode, but adopts the broadcast network mode.
  • the proxy node 12 after receiving the message passed from the accounting node 21, the proxy node 12 broadcasts the message to other service nodes 11 in the service node sub-network 1. In this way, the propagation of the message between each service node 11 of the service node sub-network 1 is also achieved.
  • the accounting nodes that may record supply chain financial business transactions and the accounting nodes that record transactions in the invoice circulation process shall belong to different departments.
  • the accounting node that records transactions in the financial business of the supply chain is the accounting terminal set up by the bank
  • the accounting node that records the transactions in the invoice flow process is the accounting terminal set up by the National Taxation Bureau. Therefore, supply chain financial business transactions and transactions in the process of recording invoice circulation may eventually be recorded on the sub-network of accounting nodes in different branches.
  • the proxy node 12 sends the transaction information to the branch accounting node sub-network corresponding to the transaction type according to the transaction type carried in the transaction information sent from the service node 11.
  • the proxy node 12 is located in the business node sub-network 1. In other embodiments of the present application, the proxy node 12 may also be located in consensus In the node sub-network 2, or independent of the business node sub-network 1 and the consensus node sub-network 2.
  • the accounting nodes in the accounting node sub-network may be terminals of the General Administration of Taxation, for example, the terminals of the Administration of Taxation deployed in multiple regions are used as an accounting node to form an accounting node sub-network .
  • Each business node in the business node sub-network may be a terminal of a local tax bureau, an invoicing agency service terminal, an invoicing enterprise terminal, an individual user terminal, etc.
  • the block header of the generated data block can be published to the business node sub-network to The business node sub-network notifies the newly generated data block information, and at the same time can avoid directly sending the data block to the business node sub-network and causing the data in the data block to be role without access rights (for example, individual users cannot view It has nothing to do with invoice information, etc.) The problem of illegal theft.
  • the accounting node needs to sign the block header before publishing the block header to the business node sub-network, and can add the key information used to verify the next block header.
  • the business node in the business node sub-network After receiving the block header of the data block, the business node in the business node sub-network verifies the data block. After the verification is passed, the newly generated data block in the sub-network of the accounting node can be known, and at the same time Obtain the key information used to verify the next block header to verify the received next block header. After that, the business node may request the accounting node sub-network to obtain the transaction data contained in the specified data block (for example, a proxy node sends a transaction data acquisition request to the accounting node sub-network).
  • the accounting node in the sub-network of the accounting node can obtain the permission information of the business node that sends the acquisition request, and then specify the data area according to the permission information
  • the transaction data contained in the block that the business node is entitled to obtain is returned to the business node.
  • the provincial tax bureau can access invoice information related to the province
  • the municipal tax bureau can only access invoice information related to the city
  • the district tax bureau can only access invoice information related to the district
  • the billing agent service provider can only access its agent Invoice information related to your company.
  • FIG. 4 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application.
  • the blockchain system includes an accounting node sub-network 2 and services Node sub-network 1, accounting node sub-network 2 includes accounting node 21, and business node sub-network 1 includes business node 11.
  • the data management method of the blockchain system shown in FIG. 4 may be performed by the accounting node 21 in the accounting node sub-network 2 or may be an agent node (such as an agent node connected to the accounting node sub-network and the business sub-node network
  • the proxy nodes 12 shown in FIGS. 1 to 3, or nodes independent of the accounting node sub-network and the service node sub-network) are executed.
  • the data management method of the blockchain system includes at least steps S410 to S430, which are described in detail as follows:
  • the data block may be packaged according to transaction data to be uploaded (such as invoicing data, invoice flow data, etc., which may be sent by a business node in a business node sub-network) Generated. For example, when transaction data is received, it can be cached first. When at least one of the following packaging requirements is met, the cached transaction data can be packaged to generate a data block:
  • the total size of transaction data to be uploaded in the cache reaches a predetermined size threshold
  • the cache time of the earliest cached transaction data to be uploaded in the cache transaction data to be uploaded reaches the predetermined time threshold from the current time.
  • the block packaging requirement is that the total size of the transaction data to be uploaded in the cache exceeds a predetermined size threshold, for example, the predetermined size threshold is 4Mb
  • the predetermined size threshold is 4Mb
  • there are 2 transaction data in the cache Respectively, 0.8Mb and 1.5Mb
  • this 3 transaction data Generate a data block to avoid wasting resources for generating a data block for each transaction data.
  • the block packaging requirement is that the total number of transaction data to be uploaded in the cache exceeds a predetermined number threshold, for example, the predetermined number threshold is 5, and there are 4 in the cache.
  • a predetermined number threshold is 5, and there are 4 in the cache.
  • One transaction data if another transaction data to be uploaded is received at this time, a data block can be generated for these 5 transaction data, thus avoiding the waste of resources to generate one data block for each transaction data.
  • the cache time from the current time reaches a predetermined time threshold, for example, a predetermined The time threshold is 24 hours. If the pending transaction data is placed in the cache at 11:27:01 on April 25, 2018, a data can be generated for the pending transaction data at 11:27:01 on April 26. Blocks, so as to avoid excessive delay from the request to the chain to the real chain.
  • one or more of the above packaging requirements can be used in combination. For example, if the total size of the transaction data to be chained in the cache reaches a predetermined size threshold, or the earliest cached transaction data in the cache with the chained transaction data is cached from the current time to the predetermined time threshold, both A data block can be generated. In this way, it not only avoids waste of resources by generating a data block for a transaction data, but also avoids unrestricted waiting caused by insufficient transaction data received in a period of time.
  • the generated data block can be published to the accounting node sub-network for consensus by each accounting node.
  • the consensus is successful, the data block is added to On the blockchain.
  • the leader accounting node broadcasts the data block to other accounting nodes in the accounting node sub-network to perform a consensus process.
  • the client which may be the accounting node that forms the data block to be recorded on the blockchain
  • the leader accounting node A broadcasts the data block corresponding to the consensus request to other accounting nodes (accounting nodes B, C, D%) in the accounting node sub-network that are not in the leadership state; continue to enter
  • other accounting nodes broadcast the received consensus content to each other accounting node, and when the preset number (2f+1) of other accounting nodes broadcast the same consensus content, enter confirmation
  • each accounting node feeds back the confirmation result to the leading accounting node A.
  • the leading accounting node A When the leading accounting node A receives the preset number (2f+1) of feedback from other blockchain nodes, it will decide to complete the consensus and feed back the results of the consensus to the client.
  • f is the largest integer less than (N-1)/3, and N is the number of accounting nodes in the accounting node sub-network.
  • f is the number of malicious accounting nodes in the sub-network of accounting nodes that the algorithm can tolerate.
  • each accounting node in the accounting node sub-network can add data blocks to the blockchain, that is, complete the chain.
  • the certificate corresponding to the second data block can be obtained from the certification center, and the obtained certificate can be used as the first key information, so that the service node can use the certificate to verify the second data.
  • the encryption key of the block header of the block is verified.
  • the first key information and the key information for verifying the block header of the first data block may be the same, the above specified The field is set to blank. That is, if the key information for verifying the subsequent block header has not changed, the designated field used to indicate the key information in the block header may be set to blank.
  • step S420 a signature corresponding to the first data block is generated, and the signature corresponding to the first data block is added to the block header of the first data block.
  • generating the signature corresponding to the first data block in step S420 includes the following steps:
  • Step S610 Obtain the signature key corresponding to the first data block.
  • the signature key corresponding to the first data block may be predetermined key information; if the first data block is not a genesis block, Then the signature key corresponding to the first data block needs to correspond to the key information indicated in the previous data block.
  • the first block constructed in the blockchain is called the genesis block. Specifically, as shown in FIG.
  • the block header of the data block 1 indicates that the public key A is used when the block header of the data block 2 is verified, and the block header of the data block 2 indicates the area of the data block 3
  • the public key B is used
  • the block header of the data block 3 indicates that the public key C is used when the block header of the data block 4 is verified
  • the signature key corresponding to the data block 2 corresponds to the public key A.
  • the private key A is then signed with the private key A; similarly, the signature key corresponding to the data block 3 is the private key B corresponding to the public key B, and then the private key B is used to sign.
  • Step S620 Using a signature key corresponding to the first data block, implement a signature algorithm on the data contained in the first data block to generate a signature corresponding to the first data block.
  • the signature algorithm may be a message digest algorithm and an encryption method for digest.
  • the process of publishing the block header of the first data block to the service node sub-network in step S430 includes:
  • Step S810 Send the block header of the first data block to the designated service node in the service node sub-network.
  • Step S820 Broadcast the block header of the first data block to other service nodes in the service node sub-network through the designated service node.
  • This embodiment is applied to the architecture of the blockchain system shown in FIG. 2.
  • a business node in the business node sub-network can be used as a proxy node, and then the block header of the data block is sent to all business nodes in the business node sub-network by broadcast.
  • the advantage of this embodiment is that the block header can be quickly notified to all service nodes in the service node sub-network.
  • the service node sub-network can also adopt the P2P-type network communication method shown in FIGS. 1 and 3.
  • the proxy node can send the block hair to the surrounding business nodes, and the business node that receives the block header sends the block hair to other business nodes around the business node until the business node child All service nodes in the network have received the block header.
  • the process of publishing the block header of the first data block to the service node sub-network includes:
  • Step S910 Send the block header of the first data block to the designated service node in the service node sub-network.
  • Step S920 using the designated service node as a sending node to send the block header of the first data block to the business node closest to the sending node, and to receive the block header of the first data block
  • the service node as the sending node continues to send until all the service nodes in the service node sub-network receive the block header of the first data block.
  • step S920 since the business node that has received the block header repeatedly receives the same block header does not make sense, therefore, when each business node determines the next business node to send the block header, in addition to giving priority to sending to the nearest In addition to the business node (to reduce the transmission latency), it must also be considered to be transmitted to the business node that has not received the block header. In this way, each business node only needs to send the block to a business node. This business node is the closest business node to other business nodes that have not received the block header. In this way, the secure delivery of the block header node by node is completed, and at the same time, the burden of delivery is prevented from being concentrated on one business node, and load balancing is achieved.
  • sending the block header of the first data block to the business node closest to the sending node in step S920 may include the following steps:
  • Step S1010 Determine the distance between the service node other than the sending node and the sending node in the service node sub-network.
  • Step S1020 Send the block header of the first data block to the business node closest to the sending node, wherein, if the business node that receives the block header of the first data block has previously received the first The block header of the data block feeds a rejection message to the sending node.
  • Step S1030 if the rejection message is received, continue to send the block header of the first data block to other service nodes according to the order from the shortest to the farthest until the acceptance message is received.
  • determining the distance between the service node other than the sending node and the sending node in the service node sub-network may include: periodicity (for example, every Every 5 seconds) Receive the location information broadcast from other service nodes in the service node sub-network, calculate the location information of each other service node according to the location information broadcasted by each other service node and the location information of the sending node most recently received The distance of the sending node.
  • the positioning information is the location information of the service node obtained by each service node from its own positioning system (for example, a GPS system installed on the node).
  • the service node obtains its own positioning information from its installed positioning system, and then periodically (for example, every 5 seconds) broadcast to other service nodes in the service node sub-network.
  • the sending node can also obtain its own positioning information from its own positioning system. Since the broadcasting and updating of the positioning information are periodic and the period is relatively short, the positioning information broadcast by each other service node that the sending node last received can be regarded as the current positioning information of each other service node.
  • the location information broadcast by each other service node and the location information of the sending node received last time can calculate the distance between each other service node and the sending node.
  • the embodiment of the present application avoids sending the block header to a certain service node repeatedly by letting other service nodes that have received the block header send an accept message or a reject message.
  • the difference between accepting a message or rejecting a message is that one of its specific identification fields is set to a different character or character string to indicate that the message is accepted or rejected. In this way, the sending node can identify whether the received message accepts the message or rejects the message by identifying the specific identification field in the received message.
  • the message is accepted, it means that the business node that received the block header has not received the block header before, so the block header is accepted. If it is a rejection message, it means that the business node that received the block header has received the block header before, so the block header is rejected. If the sending node receives the rejection message, it must find the other business node closest to it, and then send the block header to it to determine whether the other business node returns a rejection message or an acceptance message. If it is still a rejection message, it is necessary Find the other business node that is the third closest to it, and then send the block header to it to judge whether the other business node feeds back the rejection message or the acceptance message. In other words, if a rejection message is received, it will continue to send the block header to other service nodes according to the order of distance from the sending node from near to far, until the acceptance message is received.
  • Another way to find the service node closest to the sending node among other service nodes that have not received the block header is to maintain a distribution progress record server.
  • another business node receives the block header, it sends a recording request to the distribution progress record server.
  • the recording request contains the identifier of the business node and the block header (such as the Merkel root), and the distribution progress
  • the record server stores the identifier of the service node and the identifier of the block header correspondingly.
  • the sending node When the sending node needs to determine the business node closest to the sending node among the other business nodes that have not received the block header, it first sends a request to the distribution progress record server, and the distribution progress record server queries that the service node has not received the The identifier of the business node of the block header (remove the identifier of the business node that has been stored corresponding to the identifier of the block header from the identifier list of all business nodes), and send it to the sending node. The sending node determines the service node with the smallest distance from the sending node among the service nodes that have not received the block header. In contrast, by sending the block header to the nearest other business node as described above, let other business nodes that have received the block header send an accept message or reject message according to whether they have previously received the block header, and set a less Server to save network resources and avoid network congestion.
  • the data management method of the blockchain system includes the following steps:
  • Step S1110 if the accounting node in the accounting node sub-network generates the second data block, then generate the second data block from the signature key corresponding to the first key information and the second data block The signature corresponding to the two data blocks.
  • the first key information is key information used to verify the second data block
  • the signature key corresponding to the first key information is to sign the second data block Key.
  • the signature key corresponding to the data block 2 is the private key A corresponding to the public key A
  • the signature key corresponding to the data block 3 is the private key B corresponding to the public key B.
  • Step S1120 add the signature corresponding to the second data block to the block header of the second data block, and publish the block header of the second data block to the service node sub-network.
  • the data management method of the blockchain system includes the following steps S1210 and S1220, detailed description as follows:
  • step S1210 if a target business node in the business node sub-network receives a request to acquire transaction data contained in a specified data block, the authority information of the target business node is acquired.
  • the permission information of the business node refers to information indicating which transaction data in the data block the business node is entitled to and which transaction data is not entitled to.
  • the authority in the authority information includes one or more of the following:
  • the request to view on-chain business nodes corresponding to the allowed transaction data refers to the permission to view which business nodes request the on-chain transaction data.
  • a business node can only view the transaction data requested by itself for on-chain.
  • the request-to-chain business node corresponding to the transaction data allowed to be viewed is the business node A itself, so that only the business node A itself requesting the data block on the chain can be used by the business node A view.
  • a business node can view the transaction data requested by the business node of itself and all subordinate units of its request to go up the chain.
  • the business node A there is a business node A, and the business nodes of its subordinate units are A1-A7.
  • the business node A allows the transaction information corresponding to the transaction information to be viewed to be the business node A and the business node A1-A7, and then the business The data blocks requested by any one of node A and service nodes A1-A7 to be uploaded to the chain can be viewed by service node A.
  • the transaction type corresponding to the transaction data allowed to view refers to the permission to view the transaction data of which transaction types are allowed.
  • the transaction type is carried in the transaction data of the data block.
  • the transaction type may be, for example, an invoice transaction, a supply chain financial transaction, or a legal digital currency transaction.
  • the business node of the local tax authority may be allowed to view all transaction data about invoices within its jurisdiction, so all transaction data about invoices in the data block can be returned to it.
  • supply chain financial transactions the business node of the bank may be allowed to view all transaction data about supply chain finance within its jurisdiction, so it can return all transaction data about supply chain finance in the data block to it.
  • the legal digital currency transaction the business node of the issuing agency of the legal digital currency may be allowed to view all transaction data about the circulation of legal digital currency within its jurisdiction, so the transaction data of the legal digital currency in the data block can be fully Return to it.
  • the on-chain time corresponding to the transaction data allowed to view refers to the permission of which time period the on-chain transaction data is allowed to be viewed. For example, it can be specified that the business node A can only view the transaction data on the chain within the last year.
  • the request-to-chain service node corresponding to the transaction data that is allowed to be viewed, and the corresponding uplink time of the transaction data that is allowed to be viewed may be used in combination.
  • the business nodes of its subordinate units have A1-A7
  • its authority data may stipulate that: business node A can obtain the transaction data of business node A and business node A1-A7 that have been on the chain within the last year .
  • the authentication information of the target business node may be obtained according to the identification information of the target business node included in the acquisition request sent by the target business node, and then the authority information of the target business node may be obtained based on the authentication information.
  • the authentication information of the business node may be information obtained by the business node through registration in advance, for example, the business node may send a registration request to the accounting node sub-network, and then the accounting node sub-network may obtain the network entry contract corresponding to the business node ,
  • the network access contract contains the authentication information and authority information of the business node, and then the network access contract is added to the data block and added to the blockchain.
  • Step S1220 According to the authority information of the target business node, return the transaction data included in the specified data block that the target business node is entitled to obtain to the target business node.
  • the accounting node after generating the data block, only sends the block to each business node in the business node sub-network, and each business node cannot obtain the block body in the data block.
  • the transaction data hides the transaction data.
  • the business node wants to obtain the transaction data in the data block, it needs to send an acquisition request for the transaction data in the data block to the accounting node, and the accounting node only takes the transaction data that the business node has the right to view (such as The transaction data related to it, or the transaction data related to its subordinate units) is sent to it for viewing.
  • the business node For those transaction data that are not authorized to be viewed (such as transaction data related to other business nodes), it is forbidden to view, so that the business node can both Knowing the transaction data related to it can avoid the leakage of transaction data related to other business nodes.
  • FIG. 13 schematically shows a flowchart of a data management method of a blockchain system according to an embodiment of the present application.
  • the blockchain system includes an accounting node sub-network 2 and services Node sub-network 1, the accounting node sub-network includes an accounting node that records a data block on the blockchain, and the business node sub-network includes performing an operation on the data block where the accounting node is recorded on the blockchain Verified business node.
  • the data management method of the blockchain system shown in FIG. 13 can be performed by business nodes in the business node sub-network.
  • the data management method of the blockchain system includes at least steps S1310 to S1330, which are described in detail as follows:
  • step S1310 a block header of a first data block from the accounting node sub-network is received.
  • the block header of the first data block includes a signature and a block for the first data block
  • the first key information of the block header of the second data block generated afterwards is verified.
  • the process of generating the first data block by the accounting node sub-network, and the process of publishing the block header of the first data block to the business node sub-network have been carried out in the above embodiments Elaborate, no more details.
  • step S1320 the signature contained in the block header of the first data block is verified.
  • the signature contained in the first data block may be verified based on predetermined key information. If the first data block is not a genesis block, then the block header of the third data block from the accounting node sub-network can be received, where the third data block is generated before the first data block; Obtain the second key information used to verify the block header of the first data block from the block header of the three data blocks, and then based on the second key information to the block header of the first data block Sign for verification.
  • step S1330 after verification of the signature contained in the block header of the first data block is passed, the first key information is acquired to pass the first key information to the received The block header of the second data block is verified.
  • the technical solution of the embodiment shown in FIG. 13 makes it possible to obtain the key information used to verify the block header of the next data block after passing the block header verification of the previous data block, thereby ensuring the block header Data security can also achieve the purpose of flexibly updating the block header verification key, avoiding the inconvenience caused by inflexible key replacement, and avoiding the problem of data insecurity due to the use of fixed keys.
  • the data management method of the blockchain system includes the following steps:
  • Step S1410 According to the block header issued by the accounting node sub-network, send an acquisition request for the transaction data contained in the specified data block to the target accounting node in the accounting node sub-network.
  • the business node may determine that a new data block has been generated in the accounting node sub-network according to the block header, and then may record to the target The accounting node sends a request to obtain transaction data contained in the specified data block.
  • the target accounting node may be any accounting node in the accounting node sub-network, or it may be the accounting node closest to the business node sending the acquisition request in the accounting node sub-network, or it may be the accounting node An accounting node corresponding to the requested business node.
  • Step S1420 Receive the transaction data that the target business node is entitled to obtain in the specified data block returned by the target accounting node according to the acquisition request.
  • the accounting node After receiving the acquisition request sent by the business node, the accounting node can obtain the authority information of the business node, and then obtain the transaction data that the business node has the right to acquire according to the authority information. This process has been performed in the above embodiment Has been elaborated in, so I won’t go into details.
  • FIG. 15 schematically shows a block diagram of a data management device of a blockchain system according to an embodiment of the present application.
  • the blockchain system includes an accounting node sub-network 2 and a business node sub-network 1.
  • the accounting node sub-network includes accounting nodes that record data blocks on the blockchain
  • the business node sub-network includes business nodes that verify the data blocks recorded by the accounting nodes on the blockchain.
  • the accounting node 21 in the accounting node sub-network 2 may include the data management device shown in FIG. 15 or a proxy node connected to the accounting node sub-network and the service sub-node network (such as in FIGS. 1 to 3)
  • the proxy node 12 shown, or a node independent of the accounting node sub-network and the service node sub-network may include the data management apparatus shown in FIG. 15.
  • a data management device 1500 of a blockchain system includes: an adding unit 1502, a generating unit 1504, and a sending unit 1506.
  • the adding unit 1502 is used to add a first data block to the first header of the first data block after generating the first data block in the accounting node in the accounting node sub-network
  • the first key information of the block header of the second data block generated after the block is verified
  • the generating unit 1504 is used to generate a signature corresponding to the first data block and convert the signature corresponding to the first data block Added to the block header of the first data block
  • the sending unit 1506 is used to publish the block header of the first data block to the business node sub-network, so that the business node sub-network
  • the business node verifies the signature contained in the block header of the first data block, and obtains the first key information after verification to verify the block header of the second data block.
  • the adding unit 1502 is configured to add the first key information in a designated field included in the block header of the first data block, to indicate that the first key information is passed The key information verifies the block header of the second data block.
  • the adding unit 1502 is configured to set the designated field if the first key information is the same as the key information for verifying the block header of the first data block Is empty.
  • the data management apparatus 1500 of the blockchain system further includes: a first obtaining unit, configured to obtain a certificate corresponding to the second data block from an authentication center, and obtain the obtained The certificate is used as the first key information; and/or the public key and the private key corresponding to the second data block are obtained from a certification center, and the obtained public key is used as the first key information .
  • the generating unit 1504 is configured to: obtain a signature key corresponding to the first data block; use the signature key corresponding to the first data block to perform a check on the first data area
  • the data contained in the block implements a signature algorithm to generate a signature corresponding to the first data block.
  • the generating unit 1504 is further configured to: after the accounting node in the accounting node sub-network generates the second data block, use the first key information corresponding to A signature key and the second data block generate a signature corresponding to the second data block; the adding unit is further used to add the signature corresponding to the second data block to the second data area In the block header of the block; the sending unit 1506 is also used to publish the block header of the second data block to the service node sub-network.
  • the data management apparatus 1500 of the blockchain system further includes: a second acquiring unit, configured to receive a specified data block from the target business node in the business node sub-network After acquiring the transaction data contained in the request, the authority information of the target business node is acquired; the sending unit 1506 is further configured to, according to the authority information of the target business node, include the The transaction data that the target business node is entitled to obtain is returned to the target business node.
  • FIG. 16 schematically shows a block diagram of a data management device of a blockchain system according to an embodiment of the present application.
  • the blockchain system includes an accounting node sub-network 2 and a business node sub-network 1
  • the accounting node sub-network 2 includes an accounting node 21
  • the business node sub-network 1 includes a business node 11.
  • the service node 11 in the service node sub-network 1 may include the data management device shown in FIG. 16.
  • a data management device 1600 of a blockchain system includes: a receiving unit 1602, a verification unit 1604, and an acquiring unit 1606.
  • the receiving unit 1602 is used to receive the block header of the first data block from the accounting node sub-network, and the block header of the first data block includes a signature and The first key information to verify the block header of the second data block generated after the block; the verification unit 1604 is used to verify the signature contained in the block header of the first data block; the acquisition unit 1606 uses After verification of the signature contained in the block header of the first data block is passed, the first key information is acquired to pass the first key information to the received second data area The block header of the block is verified.
  • the verification unit 1604 is configured to: receive a block header of a third data block from the accounting node sub-network, wherein the third data block is in the first data Generated before the block; obtaining the second key information for verifying the block header of the first data block from the block header of the third data block; based on the second key information The signature contained in the block header of the first data block is verified.
  • the verification unit 1604 is configured to: if the first data block is a genesis block, verify the signature contained in the first data block based on predetermined key information .
  • the data management device 1600 of the blockchain system further includes: a sending unit, configured to send the billing node to the billing node according to the block header issued by the billing node sub-network
  • the target accounting node in the sub-network sends an acquisition request for the transaction data contained in the specified data block
  • the receiving unit 1602 is further configured to receive the specified data returned by the target accounting node according to the acquisition request Transaction data contained in the block that the target business node is entitled to obtain.
  • FIG. 17 shows a schematic structural diagram of a computer system suitable for implementing an electronic device according to an embodiment of the present application.
  • the computer system 1700 includes a central processing unit (Central Processing Unit, CPU) 1701, which can be loaded into a random unit according to a program stored in a read-only memory (Read-Only Memory, ROM) 1702 or from the storage section 1708.
  • the program in the memory (Random Access Memory) 1703 is accessed to perform various appropriate actions and processes, for example, the method described in the above embodiment.
  • RAM 1703 various programs and data required for system operation are also stored.
  • the CPU 1701, ROM 1702, and RAM 1703 are connected to each other through a bus 1704.
  • An input/output (Input/Output, I/O) interface 1705 is also connected to the bus 1704.
  • Removable media 1711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like, are installed on the drive 1710 as needed, so that the computer program read out therefrom is installed into the storage portion 1708 as needed.
  • embodiments of the present application include a computer program product including a computer program carried on a computer-readable medium, the computer program containing program code for performing the method shown in the flowchart.
  • the computer program may be downloaded and installed from the network through the communication section 1709, and/or installed from the removable medium 1711.
  • CPU central processing unit
  • the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two.
  • the computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination of the above.
  • Computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable removable Erasable Programmable Read Only Memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), optical storage device, magnetic storage device, or any suitable of the above The combination.
  • the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or in combination with an instruction execution system, apparatus, or device.
  • the computer-readable signal medium may include a data signal that is propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried.
  • This propagated data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • the computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, and the computer-readable medium may send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. .
  • the program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
  • each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above-mentioned module, program segment, or part of code contains one or more for implementing a specified logical function Executable instructions.
  • the functions noted in the block may occur out of the order noted in the figures. For example, two blocks represented in succession may actually be executed in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.
  • each block in the block diagram or flowchart, and a combination of blocks in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a prescribed function or operation, or can be used It is realized by a combination of dedicated hardware and computer instructions.
  • the units described in the embodiments of the present application may be implemented in software or hardware, and the described units may also be provided in a processor. Among them, the names of these units do not constitute a limitation on the unit itself under certain circumstances.
  • the present application also provides a computer-readable medium, which may be contained in the electronic device described in the foregoing embodiments; or may exist alone without being assembled into the electronic device in.
  • the computer-readable medium carries one or more programs. When the one or more programs are executed by one of the electronic devices, the electronic device causes the electronic device to implement the method described in the foregoing embodiments.
  • the example embodiments described here can be implemented by software, or can be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, U disk, mobile hard disk, etc.) or on the network , Including several instructions to enable a computing device (which may be a personal computer, server, touch terminal, or network device, etc.) to perform the method according to the embodiments of the present application.
  • a computing device which may be a personal computer, server, touch terminal, or network device, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请的实施例提供了一种区块链系统的数据管理方法、装置、介质及电子设备。该区块链系统包括记账节点子网络和业务节点子网络，该数据管理方法包括：在记账节点生成第一数据区块后，在第一数据区块的区块头中添加用于对第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；生成第一数据区块对应的签名，并将第一数据区块对应的签名添加至第一数据区块的区块头中；将第一数据区块的区块头发布至业务节点子网络中，以使业务节点对第一数据区块的区块头中包含的签名进行验证，并在验证通过后获取第一密钥信息以对第二数据区块的区块头进行验证。本申请实施例的技术方案实现了灵活更新区块头验证密钥的目的，有效保证区块头数据的安全性。

Description

区块链系统的数据管理方法、装置、介质及电子设备
本申请要求于2018年12月7日提交中国专利局、申请号为201811497453.4、申请名称为“区块链系统的数据管理方法、装置、介质及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机及通信技术领域，具体而言，涉及一种区块链系统的数据管理方法、装置、介质及电子设备。
背景技术
区块链网络是由众多节点共同组成的一个端到端的去中心化网络，每个节点都允许获得一份完整的数据库拷贝，即节点间各信息完全共享，各节点之间基于一套共识机制来共同维护整个区块链。所谓共识机制，是通过特殊节点的投票，在很短的时间内完成对交易的验证和确认；对一笔交易，如果利益不相干的若干个节点能够达成共识，就可以认为全网对此也能够达成共识。
在区块链系统的一种应用场景中，可能需要将区块链网络中的数据发送至区块链网络之外的业务节点，在这种应用场景下，需要对发送至业务节点的数据进行签名，以便于业务节点对数据进行校验，而如何避免签名密钥发生泄漏而导致数据不安全成为亟待解决的技术问题。
发明内容
本申请的实施例提供了一种区块链系统的数据管理方法、装置、介质及电子设备，进而至少在一定程度上可以灵活地对区块头验证密钥进行更新，以保证区块头数据的安全性。
本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
根据本申请实施例，提供了一种区块链系统的数据管理方法，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理方法包括：在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块 头中；将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头中包含的签名进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
根据本申请实施例，提供了一种区块链系统的数据管理方法，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理方法由所述业务节点子网络中的业务节点执行，所述数据管理方法包括：接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；对所述第一数据区块的区块头中所包含的签名进行验证；在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
根据本申请实施例，提供了一种区块链系统的数据管理装置，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理装置包括：添加单元，用于在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；生成单元，用于生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块头中；发送单元，用于将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头中包含的签名进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
根据本申请实施例，提供了一种区块链系统的数据管理装置，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络记账节点，所述业务节点子网络包括业务节点，所述业务节点包括所述数据管理装置，所述数据管理装置包括：接收单元，用于接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；验证单元，用于对所述第一数据区块的区块头中所包含的签名进行验证；获取单元，用于在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
根据本申请实施例，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的区块链系统的数据管理方法。
根据本申请实施例，提供了一种电子设备，包括：一个或多个处理器和存储装置； 所述存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的区块链系统的数据管理方法。
在本申请的一些实施例所提供的技术方案中，通过在第一数据区块的区块头中添加用于对第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息，并将第一数据区块对应的签名添加至第一数据区块的区块头中后将第一数据区块的区块头发布至业务节点子网络中，使得业务节点子网络中的业务节点在对第一数据区块的区块头中包含的签名进行验证后，可以从第一数据区块的区块头中获取到用于对第二数据区块的区块头进行验证的第一密钥信息，即可以通过前一个数据区块的区块头来指示对下一个数据区块的区块头进行验证所采用的密钥信息，实现了灵活地更新区块头验证密钥的目的，避免了密钥更换不灵活带来的不便，也避免了使用固定的密钥而可能出现数据不安全的问题。此外，由于本申请实施例的技术方案只有在对前一个数据区块的区块头验证通过后，才能获取到对下一个数据区块的区块头进行验证所采用的密钥信息，因此也能够有效保证区块头数据的安全性。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图简要说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
图1至图3示出了本申请实施例所应用的区块链系统的体系构架示意图；
图4示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图；
图5示意性示出了根据本申请的一个实施例的对数据区块进行共识的流程图；
图6示意性示出了根据本申请的一个实施例的生成第一数据区块对应的签名的流程图；
图7示出了根据本申请的一个实施例的数据区块的区块头的结构示意图；
图8示意性示出了根据本申请的一个实施例的将第一数据区块的区块头发布至业务节点子网络中的流程图；
图9示意性示出了根据本申请的一个实施例的将第一数据区块的区块头发布至业务节点子网络中的流程图；
图10示意性示出了根据本申请的一个实施例的将第一数据区块的区块头发送至 离发送节点最近的业务节点的流程图；
图11示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图；
图12示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图；
图13示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图；
图14示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图；
图15示意性示出了根据本申请的一个实施例的区块链系统的数据管理装置的框图；
图16示意性示出了根据本申请的一个实施例的区块链系统的数据管理装置的框图；
图17示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
图1示出了本申请实施例所应用的一种区块链系统的体系构架。区块链系统包括记账节点子网络2和业务节点子网络1。记账节点子网络2包括对数据区块进行共识并将数据区块记录到区块链上的记账节点21。业务节点子网络1包括业务节点11，业 务节点11可以对记账节点记录到区块链上的数据区块进行验证，或者可以向记账节点请求相应的交易数据。
具体的，业务节点11对记账节点记录到区块链上的数据区块进行验证可以包括以下步骤：记账节点子网络中的一个记账节点21利用特定于该记账节点的密钥，基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成签名；记账节点21将所述交易信息和生成的签名加入所述数据区块，添加到区块链上；记账节点21将所述签名发往所述业务节点子网络中的业务节点，业务节点根据特定于该记账节点的密钥对所述签名进行签名验证，以实现业务节点11对记账节点记录到区块链上的数据区块进行验证。记账节点子网络中的记账节点负责向区块链记录数据区块，业务节点子网络中的业务节点负责见证记账节点记录的结果。具体地，记账节点基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成签名，然后将所述交易信息和生成的签名加入所述数据区块，进行上链。所述签名发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥对所述签名进行签名验证。业务节点子网络中的业务节点通过验证区块上记账节点签名可以对全网的交易数据进行见证。记账网络虽然拥有垄断的记账权，但是因为数据区块有了代表记账者身份的数字签名，所以一切行为都是公开可追溯的。如果记账节点集体作恶，那么对全网的交易数据进行见证的全部节点都将保留有具体记账节点作恶的证据。相比传统中心化系统和私有链，这个方案中，系统的运转更加透明；而相比传统的去中心化公链方案，本方案更可控也更便于监管。
在本申请的一个实施例中，记账节点子网络2和业务节点子网络1之间可以通过代理节点12连接，代理节点12可以是业务节点子网络1的一个业务节点，其负责将记账节点21要向业务节点11传递的信息传递给业务节点11。业务节点11是产生各种需上链的交易数据的交易方的终端，也可以是从记账节点子网络2中查询交易数据的终端。业务节点11产生的交易数据在通过代理节点12传输至记账节点21，然后经过共识后记录到区块链上，有利于交易数据的统一处理和监管，而业务节点11也可以通过记账节点21经由代理节点12发送来的信息进行交易数据上链的监督和见证，这在某些既需要统一监管、但又怕监管的节点集体作弊因而需要监督的场景中有十分重要的意义。
在图1所示的结构中，业务节点子网络1采用P2P网络模式。P2P网络是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式，即“点对点”或者“端对端”网络。其可以定义为：网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源通过网络提供服务和内容，能被其它对等节点直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者，又是资源、 服务和内容的获取者。因此，在业务节点子网络1中，当代理节点12接收到从记账节点21传递过来的消息后，向周围的业务节点11进行传播，周围的业务节点11接收到该消息，再向其周围的业务节点11传递，实现了该消息在业务节点子网络1的每个业务节点11之间的传播。
图2示出了本申请实施例所应用的另一种区块链系统的体系构架。该体系构架与图1中所示的体系构架的不同之处在于：在业务节点子网络1中没有采取P2P网络模式，而是采取广播网络的模式。具体地，代理节点12在接收到从记账节点21传递过来的消息后，将该消息广播到业务节点子网络1中的其它业务节点11。这样，也实现了该消息在业务节点子网络1的每个业务节点11之间的传播。
图3示出了本申请实施例所应用的另一种区块链系统的体系构架。该体系构架与图1所示的体系构架的不同之处在于：其记账节点子网络2分成了多个分支记账节点子网络。每个分支记账节点子网络可以负责某一种类型的交易信息的记录。例如，某一企业可能具有供应链金融业务，可能需要将供销过程中产生的合同信息、货款赊欠等信息记录到区块链上，同时该企业还要开具发票，也要把开票信息、发票报销信息等记录到区块链上。这时，为了满足记账节点被同一部门监管的需要，可能记录供应链金融业务交易的记账节点和记录发票流转过程中的交易的记账节点要分属于不同部门。例如，记录供应链金融业务交易的记账节点是银行设置的记账终端，而记录发票流转过程中的交易的记账节点是国税局设置的记账终端。因此供应链金融业务交易和记录发票流转过程中的交易可能也最终会记录在不同分支的记账节点子网络上。这时，代理节点12要根据从业务节点11发来的交易信息中携带的交易类型，将该交易信息发送到与该交易类型对应的分支记账节点子网络中。
需要说明的是，在图1至图3所示的区块链系统的体系构架中，代理节点12位于业务节点子网络1中，在本申请的其它实施例中，代理节点12也可以位于共识节点子网络2中，或者独立于业务节点子网络1和共识节点子网络2。
图1至3所示的区块链系统的体系架构可以应用在电子发票的应用场景中，以下详细进行阐述。
在本申请的一个实施例中，记账节点子网络中的记账节点可以是各个税务总局终端，比如由部署在多个地区的税务总局终端分别作为一个记账节点来构成记账节点子网络。业务节点子网络中的各个业务节点可以是地方税局终端、开票代理服务商终端、开票企业终端、个人用户终端等。
当记账节点子网络中的记账节点生成数据区块后(该数据区块中可能包含开具的发票信息等)，可以将生成的数据区块的区块头发布至业务节点子网络，以向业务节点子网络通知新生成的数据区块的信息，同时又可以避免直接将数据区块发送至业务节点子网络中而导致数据区块中的数据被无访问权限的角色(比如个人用户无法查看与 其无关的发票信息等)非法窃取的问题。同时，记账节点在将区块头发布至业务节点子网络之前，需要对区块头进行签名，并且可以添加对下一个区块头进行验证所采用的密钥信息。
业务节点子网络中的业务节点在接收到数据区块的区块头后，对该数据区块进行验证，当验证通过之后，可以得知记账节点子网络中新产生的数据区块，同时可以获得对下一个区块头进行验证所采用的密钥信息，以对接收到的下一个区块头进行验证。之后，业务节点可以向记账节点子网络请求获取指定数据区块中包含的交易数据(比如通过代理节点向记账节点子网络发送交易数据的获取请求)。记账节点子网络中的记账节点在接收到对指定数据区块中包含的交易数据的获取请求之后，可以获取到发送获取请求的业务节点的权限信息，然后根据该权限信息将指定数据区块中包含的该业务节点有权获取的交易数据返回给该业务节点。比如省税局能够访问与本省相关的发票信息、市税局只能访问与本市相关的发票信息、区税局只能访问与本区相关的发票信息、开票代理服务商只能访问其代理的企业相关的发票信息等。
以下对本申请实施例的区块链系统的数据管理方案的实现细节进行详细阐述。
图4示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图，如图1至图3所示，该区块链系统包括记账节点子网络2和业务节点子网络1，记账节点子网络2包括记账节点21，业务节点子网络1包括业务节点11。图4所示的区块链系统的数据管理方法可以由记账节点子网络2中的记账节点21来执行，也可以由与记账节点子网络和业务子节点网络相连的代理节点(比如图1至图3中所示的代理节点12，或者独立于记账节点子网络和业务节点子网络的节点)来执行。参照图4所示，该区块链系统的数据管理方法至少包括步骤S410至步骤S430，详细介绍如下：
在步骤S410中，在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息。
在本申请的一个实施例中，数据区块可以是根据待上链交易数据(比如开票数据，发票流转数据等，这些待上链交易数据可以是业务节点子网络中的业务节点发送的)打包生成的。比如当接收到交易数据后可以先缓存起来，当满足以下至少一项打包要求时可以对缓存的交易数据进行打包生成数据区块：
缓存中的待上链交易数据的总大小达到预定大小阈值；
缓存中的待上链交易数据的总条数达到预定条数阈值；
缓存中的待上链交易数据中最早缓存的一条待上链交易数据的缓存时间距离当前时间达到预定时间阈值。
在本申请的一个实施例中，在区块打包要求是缓存中的待上链交易数据的总大小超过预定大小阈值的情况下，例如，预定大小阈值为4Mb，缓存中原来有2条交易数 据，分别是0.8Mb和1.5Mb，如果这时又接收到一条待上链交易数据，大小为2Mb，这样0.8Mb+1.5Mb+2Mb＝4.3Mb>4Mb，此时就可以为这3条交易数据生成一个数据区块，从而避免为每一条交易数据生成一个数据区块的资源浪费。
在本申请的一个实施例中，在区块打包要求是缓存中的待上链交易数据的总条数超过预定条数阈值的情况下，例如，预定条数阈值为5，缓存中原来有4条交易数据，如果这时又接收到一条待上链交易数据，此时就可以为这5条交易数据生成一个数据区块，从而避免为每一条交易数据生成一个数据区块的资源浪费。
在本申请的一个实施例中，在区块打包要求是缓存中的待上链交易数据中最早缓存的一条待上链交易数据的缓存时间距离当前时间达到预定时间阈值的情况下，例如，预定时间阈值为24小时，如果待上链交易数据在2018年4月25日11:27:01放入缓存，在4月26日11:27:01就可以为该待上链交易数据生成一个数据区块，从而避免从请求上链到真正上链的时延过大。
在实践中，可以将上述中的一条或多条打包要求结合使用。例如，如果缓存中的待上链交易数据的总大小达到预定大小阈值，或者缓存中的待上链交易数据中最早缓存的一条带上链交易数据的缓存时间距离当前时间达到预定时间阈值，都可以生成一个数据区块。这样，既避免了为一个交易数据生成一个数据区块而造成资源浪费，又避免了在一段时间接收到的交易数据不够多而造成无限制的等待。
在本申请的一个实施例中，当生成数据区块后，可以将生成的数据区块发布至记账节点子网络中由各个记账节点进行共识，当共识成功之后，将数据区块添加在区块链上。
具体地，在本申请的一个实施例中，如图5所示为本申请实施例的由领导记账节点将数据区块广播到记账节点子网络中的其它记账节点进行共识的过程。其中，在请求阶段，客户端(可以是形成要记录在区块链上的数据区块的记账节点)发起共识请求，并将共识请求发送至处于领导状态的领导记账节点A；继续进入添加实体阶段，由领导记账节点A将共识请求所对应的数据区块广播至记账节点子网络中其它未处于领导状态的记账节点(记账节点B、C、D…)；继续进入追加响应阶段，由其它记账节点将接收到的共识内容广播至其它各记账节点，并在接收到预设数量(2f+1)的其它记账节点所广播的共识内容一致时，进入确认阶段，各记账节点再将确认结果反馈至领导记账节点A。领导记账节点A在接收到预设数量(2f+1)的其它区块链节点反馈确认通过时，则判定完成共识并向客户端反馈共识完成的结果。其中，f是小于(N-1)/3的最大整数，N是记账节点子网络中记账节点的数量。f是算法能容忍的记账节点子网络中作恶记账节点的数量。
当共识成功后，记账节点子网络中的各个记账节点就可以将数据区块添加到区块链上，即完成上链。
在本申请的一个实施例中，可以从认证中心获取第二数据区块对应的证书，将获取到的证书作为所述第一密钥信息，进而使得业务节点可以通过该证书来对第二数据区块的区块头的加密密钥进行验证。
在本申请的一个实施例中，可以从认证中心获取第二数据区块对应的公钥和私钥，将获取到的公钥作为所述第一密钥信息，进而使得业务节点可以通过该公钥来对第二数据区块的区块头进行验证。
在本申请的一个实施例中，在第一数据区块的区块头中添加第一密钥信息具体可以是在第一数据区块的区块头中所包含的指定字段添加该第一密钥信息，以指示业务节点通过该第一密钥信息对第二数据区块的区块头进行验证。
在本申请的一个实施例中，为了节省字节，降低区块头的数据量，可以在第一密钥信息与对第一数据区块的区块头进行验证的密钥信息相同时，将上述指定字段设置为空。即若对后续的区块头进行验证的密钥信息没有发生变化，则可以将区块头中用于指示密钥信息的指定字段设为空。
继续参照图4所示，在步骤S420中，生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块头中。
在本申请的一个实施例中，如图6所示，步骤S420中生成第一数据区块对应的签名，包括如下步骤：
步骤S610，获取所述第一数据区块对应的签名密钥。
在本申请的一个实施例中，若第一数据区块为创世块，则第一数据区块对应的签名密钥可以是预定的密钥信息；若第一数据区块不是创世块，那么第一数据区块对应的签名密钥需要与之前的数据区块中指示的密钥信息相对应。其中，区块链中第一个被构建的区块称为创世块。具体地，如图7所示，数据区块1的区块头指示了对数据区块2的区块头进行验证时采用公钥A，数据区块2的区块头指示了对数据区块3的区块头进行验证时采用公钥B，数据区块3的区块头指示了对数据区块4的区块头进行验证时采用公钥C，那么数据区块2对应的签名密钥即为公钥A对应的私钥A，进而用私钥A进行签名；类似地，数据区块3对应的签名密钥即为公钥B对应的私钥B，进而用私钥B进行签名。
步骤S620，利用所述第一数据区块对应的签名密钥，对所述第一数据区块中所包含的数据实施签名算法，以生成第一数据区块对应的签名。
在本申请的一个实施例中，签名算法可以是消息摘要算法和对摘要的加密方法等。
继续参照图4所示，在步骤S430中，将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
在本申请的一个实施例中，如图8所示，步骤S430中将第一数据区块的区块头发布至业务节点子网络中的过程，包括：
步骤S810，将第一数据区块的区块头发送至所述业务节点子网络中的指定业务节点。
步骤S820，通过所述指定业务节点将所述第一数据区块的区块头广播至所述业务节点子网络中的其它业务节点。
该实施例应用于图2中所示的区块链系统的体系构架。在该体系构架中，可以将业务节点子网络中的一个业务节点作为代理节点，然后通过广播的方式向业务节点子网络中的所有业务节点发送数据区块的区块头。该实施例的好处在于，可以快速将区块头通知到业务节点子网络中的所有业务节点。
业务节点子网络除了可以采用图2所示的广播消息的通信方式，还可以采用如图1和图3所示的P2P式的网络通信方式。在P2P的业务节点子网络中，代理节点可以将区块头发送到其周围的业务节点，接收到该区块头的业务节点再将区块头发送到该业务节点周围的其它业务节点，直到业务节点子网络中的所有业务节点都接收到该区块头为止。
在一个P2P组网形式的实施例中，如图9所示，将第一数据区块的区块头发布至业务节点子网络中的过程，包括：
步骤S910，将第一数据区块的区块头发送至所述业务节点子网络中的指定业务节点。
步骤S920，以所述指定业务节点作为发送节点将所述第一数据区块的区块头发送至离所述发送节点最近的业务节点，并将接收到所述第一数据区块的区块头的业务节点作为发送节点继续进行发送，直至所述业务节点子网络中的业务节点均接收到所述第一数据区块的区块头。
在步骤S920中，由于已经接收到区块头的业务节点重复接收同样的区块头没有意义，因此，每个业务节点确定要发送区块头的下一个业务节点时，除了要考虑优先发送给离其最近的业务节点(以减少传输等待时间)外，还要考虑要传送到还没有接收到该区块头的业务节点。这样，每个业务节点都只需要将区块头发送到一个业务节点，这个业务节点是未接收到该区块头的其它业务节点中离自己最近的业务节点。这样，就完成了区块头逐个节点的安全下发，同时避免下发负担集中在一个业务节点上，实现了负载均衡。
在本申请的一个实施例中，如图10所示，步骤S920中将第一数据区块的区块头发送至离发送节点最近的业务节点，可以包括如下步骤：
步骤S1010，确定所述业务节点子网络中除所述发送节点之外的其它业务节点与所述发送节点之间的距离。
步骤S1020，将所述第一数据区块的区块头发送至与所述发送节点最近的业务节点，其中，若接收到所述第一数据区块的区块头的业务节点之前已经接收到第一数据区块的区块头，则向所述发送节点反馈拒绝消息。
步骤S1030，若接收到所述拒绝消息，则根据所述距离由近至远的顺序继续将所述第一数据区块的区块头发送至其它业务节点，直至接收到接受消息。
在本申请的一个实施例中，在步骤S1010中，确定所述业务节点子网络中除所述发送节点之外的其它业务节点与所述发送节点之间的距离可以包括：周期性(例如每隔5秒)接收从业务节点子网络中的其它业务节点广播的定位信息，按照最近一次接收到的每个其它业务节点广播的定位信息、以及发送节点的定位信息，计算每个其它业务节点与所述发送节点的距离。
在本申请的一个实施例中，定位信息是各业务节点从自身的定位系统(例如节点上安装的GPS系统)获得的业务节点的位置信息。业务节点从其安装的定位系统上获得自己的定位信息，然后周期性(例如每隔5秒)广播到业务节点子网络中的其它业务节点。而发送节点也可以从自身的定位系统中获得其自身的定位信息。由于定位信息的广播和更新是周期性的，周期比较短，可以将发送节点最近一次接收到的每个其它业务节点广播的定位信息看成是每个其它业务节点的当前定位信息，这样，按照最近一次接收到的每个其它业务节点广播的定位信息、以及发送节点的定位信息，就可以计算出每个其它业务节点与所述发送节点的距离。
通过计算出的以上距离，可以找到所有其它业务节点中与发送节点距离最小的其它业务节点，但该其它业务节点有可能已经接到过该区块头。因此，本申请的实施例通过让接收到区块头的其它业务节点发送接受消息或拒绝消息来避免将区块头重复发给某个业务节点。其中，接受消息或拒绝消息的区别在于，其某一个特定标识字段设置为不同的字符或字符串，以表示接受消息或拒绝消息。这样，发送节点可以通过识别接收到的消息中的该特定标识字段，以识别接收到的消息是接受消息还是拒绝消息。如果是接受消息，就表示接收到该区块头的业务节点之前没有接收到过该区块头，因此接受了该区块头。如果是拒绝消息，就表示接收到该区块头的业务节点之前接收到过该区块头，因此拒绝了该区块头。如果发送节点接收到拒绝消息，就要找到距离其第二近的其它业务节点，再向其发送区块头并判断该其它业务节点反馈的是拒绝消息还是接受消息，如果仍然是拒绝消息，就要找到距离其第三近的其它业务节点，再向其发送区块头，进行该其它业务节点反馈的是拒绝消息还是接受消息的判断。也就是说，如果接收到拒绝消息，就根据与发送节点距离由近至远的顺序继续将区块头发送至其它业务节点，直到接收到接受消息。
找到尚未接收到该区块头的其它业务节点中、离发送节点最近的业务节点的另一种实施方式是维护一个分发进度记录服务器。每当一个其它业务节点接收到区块头后， 就向分发进度记录服务器发出一个记录请求，记录请求中含有该业务节点的标识和区块头的标识(例如其中的默克尔树根)，分发进度记录服务器将该业务节点的标识和区块头的标识对应存储。当发送节点需要确定尚未接收到该区块头的其它业务节点中、离发送节点最近的业务节点时，先向分发进度记录服务器发请求，由分发进度记录服务器查询业务节点子网络中未接收到该区块头的业务节点的标识(从所有业务节点的标识列表中去除已与区块头的标识对应存储的业务节点标识)，发送给发送节点。发送节点在这些未接收到该区块头的业务节点中确定离发送节点距离最小的业务节点。相比而言，通过上述向距离最近的其它业务节点发送区块头，让接收到区块头的其它业务节点根据自己是否之前接收到该区块头来发送接受消息或拒绝消息的方式，少设置了一个服务器，从而节省网络资源，避免网络拥塞。
基于前述实施例的技术方案，在本申请的一个实施例中，如图11所示，根据本申请的一个实施例的区块链系统的数据管理方法，包括如下步骤：
步骤S1110，若记账节点子网络中的记账节点生成了所述第二数据区块，则通过所述第一密钥信息对应的签名密钥和所述第二数据区块生成所述第二数据区块对应的签名。
在本申请的一个实施例中，第一密钥信息是用于对第二数据区块进行验证的密钥信息，第一密钥信息对应的签名密钥即为对第二数据区块进行签名的密钥。具体地，如图7所示，数据区块2对应的签名密钥即为公钥A对应的私钥A；数据区块3对应的签名密钥即为公钥B对应的私钥B。
其中，生成数据区块的过程和生成第二数据区块对应的签名的过程参照前述实施例的技术方案，不再赘述。
步骤S1120，将所述第二数据区块对应的签名添加至所述第二数据区块的区块头中，并将所述第二数据区块的区块头发布至所述业务节点子网络中。
其中，将第二数据区块对应的签名添加至第二数据区块的区块头中的过程以及将第二数据区块的区块头发布至业务节点子网络中的过程参照前述实施例的技术方案，不再赘述。
基于前述实施例的技术方案，在本申请的一个实施例中，如图12所示，根据本申请的一个实施例的区块链系统的数据管理方法，包括如下步骤S1210和步骤S1220，详细说明如下：
在步骤S1210中，若接收到所述业务节点子网络中的目标业务节点对指定数据区块中所包含的交易数据的获取请求，则获取所述目标业务节点的权限信息。
在本申请的实施例中，业务节点的权限信息是指表示业务节点有权获得数据区块中哪些交易数据、无权获得哪些交易数据的信息。在本申请的一个实施例中，权限信息中的权限包括以下中的一种或多种：
允许查看的交易数据所对应的请求上链业务节点；
允许查看的交易数据所对应的交易类型；
允许查看的交易数据所对应的上链时间。
其中，允许查看的交易数据所对应的请求上链业务节点是指允许查看哪些业务节点请求上链的交易数据的权限。在本申请的一个实施例中，可以规定一个业务节点只能查看自己请求上链的交易数据。假设有一个业务节点A，可能其权限消息中规定允许查看的交易数据所对应的请求上链业务节点就是业务节点A本身，这样只有业务节点A本身请求上链的数据区块才能够被业务节点A查看。在另一个实施例中，可以规定一个业务节点可以查看其自己及其下属所有单位的业务节点请求上链的交易数据。例如，有一个业务节点A，其下属单位的业务节点有A1-A7，这样，业务节点A允许查看的交易信息所对应的请求上链业务节点就是业务节点A和业务节点A1-A7，进而业务节点A和业务节点A1-A7中任一个业务节点请求上链的数据区块都能够被业务节点A查看。
允许查看的交易数据所对应的交易类型是指允许查看哪些交易类型的交易数据的权限。在数据区块的交易数据中携带有交易类型。交易类型例如可以是发票交易、供应链金融交易、法定数字货币交易等。在发票交易中，可能地方税务机构的业务节点被允许查看其管辖范围内的所有关于发票的交易数据，因此可以将数据区块中关于发票的交易数据全部向其返回。在供应链金融交易中，可能银行的业务节点被允许查看其管辖范围内的所有关于供应链金融的交易数据，因此可以将数据区块中关于供应链金融的交易数据全向其返回。在法定数字货币交易中，可能法定数字货币的发行机关的业务节点被允许查看其管辖范围内的所有关于法定数字货币流转的交易数据，因此可以将数据区块中关于法定数字货币的交易数据全向其返回。
允许查看的交易数据所对应的上链时间是指允许查看哪个时间段上链的交易数据的权限。例如，可以规定业务节点A只能查看最近一年之内上链的交易数据。
上述几种权限也可以组合使用。例如，可以将允许查看的交易数据所对应的请求上链业务节点、允许查看的交易数据所述对应的上链时间组合使用。假设有一个业务节点A，其下属单位的业务节点有A1-A7，其权限数据中可能规定：业务节点A可以获得最近一年之内上链的业务节点A、业务节点A1-A7的交易数据。
在本申请的一个实施例中，可以根据目标业务节点发送的获取请求中包含的目标业务节点的标识信息，获取目标业务节点的认证信息，然后基于该认证信息获取目标业务节点的权限信息。其中，业务节点的认证信息可以是业务节点事先通过注册获取到的信息，比如业务节点可以向记账节点子网络发送注册请求，然后记账节点子网络可以获取到与该业务节点对应的入网合约，该入网合约中含有该业务节点的认证信息及权限信息，进而将该入网合约加入数据区块并添加到区块链上。由于区块链上的数 据区块中所有内容对于记账节点都是完全可见的，因此记账节点在接收到业务节点对该数据区块中的交易数据的请求后，根据请求的业务节点的标识信息，就可以在区块链中找到与该业务节点的标识信息对应存储的入网合约，进而从中读取权限信息。
步骤S1220，根据目标业务节点的权限信息，将所述指定数据区块中包含的所述目标业务节点有权获取的交易数据返回至所述目标业务节点。
在本申请的实施例中，在生成数据区块后，记账节点仅把区块头发到业务节点子网络中的各业务节点，各业务节点无法获取到数据区块中的区块体中的各交易数据，实现了交易数据的隐藏。当业务节点想要获取到数据区块中的交易数据时，需要向记账节点发送对数据区块中的交易数据的获取请求，而记账节点只把业务节点有权查看的交易数据(例如与其相关的交易数据、或与其下属单位相关的交易数据)发送给其查看，对于那些无权查看的交易数据(例如与其它业务节点相关的交易数据)，禁止其查看，进而使得业务节点既能够获知与其相关的交易数据，又能够避免其它业务节点相关的交易数据遭到泄露的问题。
图13示意性示出了根据本申请的一个实施例的区块链系统的数据管理方法的流程图，如图1至图3所示，该区块链系统包括记账节点子网络2和业务节点子网络1，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点。图13所示的区块链系统的数据管理方法可以由业务节点子网络中的业务节点来执行。参照图13所示，该区块链系统的数据管理方法至少包括步骤S1310至步骤S1330，详细介绍如下：
在步骤S1310中，接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息。
在本申请的一个实施例中，记账节点子网络生成第一数据区块的过程，以及将第一数据区块的区块头发布至业务节点子网络中的过程已经在上述实施例中进行了详细阐述，不再赘述。
在步骤S1320中，对所述第一数据区块的区块头中所包含的签名进行验证。
在本申请的一个实施例中，如前述实施例中所述，若第一数据区块为创世块，则可以基于预定的密钥信息对第一数据区块中所包含的签名进行验证。若第一数据区块不是创世块，那么可以接收来自于记账节点子网络的第三数据区块的区块头，其中，第三数据区块在第一数据区块之前生成；然后从第三数据区块的区块头中获取用于对第一数据区块的区块头进行验证的第二密钥信息，进而基于该第二密钥信息对第一数据区块的区块头中所包含的签名进行验证。
具体地，如图7所示，数据区块1的区块头指示了对数据区块2的区块头进行验证时采用公钥A，数据区块2的区块头指示了对数据区块3的区块头进行验证时采用 公钥B，数据区块3的区块头指示了对数据区块4的区块头进行验证时采用公钥C，那么可以根据数据区块1的区块头中指示的公钥A来对数据区块2的区块头中包含的签名进行验证；类似地，根据数据区块2的区块头中指示的公钥B来对数据区块3的区块头中包含的签名进行验证。
在步骤S1330中，在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
图13所示实施例的技术方案使得在对前一个数据区块的区块头验证通过后，才能获取到对下一个数据区块的区块头进行验证所采用的密钥信息，进而能够保证区块头数据的安全性，同时也能够实现灵活地更新区块头验证密钥的目的，避免了密钥更换不灵活带来的不便，也避免了使用固定的密钥而可能出现数据不安全的问题。
基于前述实施例的技术方案，在本申请的一个实施例中，如图14所示，根据本申请的一个实施例的区块链系统的数据管理方法，包括如下步骤：
步骤S1410，根据所述记账节点子网络发布的所述区块头，向所述记账节点子网络中的目标记账节点发送对指定数据区块中包含的交易数据的获取请求。
在本申请的一个实施例中，业务节点在接收到记账节点子网络发布的区块头之后，可以根据该区块头确定记账节点子网络中产生了新的数据区块，进而可以向目标记账节点发送对指定数据区块中包含的交易数据的获取请求。其中，目标记账节点可以是记账节点子网络中的任意一个记账节点，也可以是记账节点子网络中距离发送获取请求的业务节点最近的一个记账节点，还可以是与发送获取请求的业务节点相对应的一个记账节点。
步骤S1420，接收所述目标记账节点根据所述获取请求返回的所述指定数据区块中包含的所述目标业务节点有权获取的交易数据。
其中，记账节点在接收到业务节点发送的获取请求之后，可以获取到该业务节点的权限信息，进而根据该权限信息获取到该业务节点有权获取的交易数据，这个过程已经在上述实施例中进行了阐述，因此不再赘述。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的区块链系统的数据管理方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的区块链系统的数据管理方法的实施例。
图15示意性示出了根据本申请的一个实施例的区块链系统的数据管理装置的框图。如图1至图3所示，该区块链系统包括记账节点子网络2和业务节点子网络1，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点。其中，记账节点子网络2中的记账节点21可以包括图15中所示的数据管理装置，或者与记账节点子 网络和业务子节点网络相连的代理节点(比如图1至图3中所示的代理节点12，或者独立于记账节点子网络和业务节点子网络的节点)可以包括图15中所示的数据管理装置。
参照图15所示，根据本申请的一个实施例的区块链系统的数据管理装置1500，包括：添加单元1502、生成单元1504和发送单元1506。
其中，添加单元1502用于在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；生成单元1504用于生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块头中；发送单元1506用于将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头中包含的签名进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
在本申请的一个实施例中，添加单元1502配置为：在所述第一数据区块的区块头中所包含的指定字段添加所述第一密钥信息，以用于指示通过所述第一密钥信息对所述第二数据区块的区块头进行验证。
在本申请的一个实施例中，添加单元1502配置为：若所述第一密钥信息与对所述第一数据区块的区块头进行验证的密钥信息相同，则将所述指定字段设置为空。
在本申请的一个实施例中，所述的区块链系统的数据管理装置1500还包括：第一获取单元，用于从认证中心获取所述第二数据区块对应的证书，将获取到的所述证书作为所述第一密钥信息；和/或从认证中心获取所述第二数据区块对应的公钥和私钥，将获取到的所述公钥作为所述第一密钥信息。
在本申请的一个实施例中，生成单元1504配置为：获取所述第一数据区块对应的签名密钥；利用所述第一数据区块对应的签名密钥，对所述第一数据区块中所包含的数据实施签名算法，以生成所述第一数据区块对应的签名。
在本申请的一个实施例中，生成单元1504还用于，在所述记账节点子网络中的记账节点生成了所述第二数据区块后，通过所述第一密钥信息对应的签名密钥和所述第二数据区块生成所述第二数据区块对应的签名；所述添加单元还用于，将所述第二数据区块对应的签名添加至所述第二数据区块的区块头中；所述发送单元1506还用于将所述第二数据区块的区块头发布至所述业务节点子网络中。
在本申请的一个实施例中，所述的区块链系统的数据管理装置1500还包括：第二获取单元，用于在接收到所述业务节点子网络中的目标业务节点对指定数据区块中所包含的交易数据的获取请求后，获取所述目标业务节点的权限信息；所述发送单元1506还用于，根据所述目标业务节点的权限信息，将所述指定数据区块中包含的所述目标业务节点有权获取的交易数据返回至所述目标业务节点。
图16示意性示出了根据本申请的一个实施例的区块链系统的数据管理装置的框图。如图1至图3所示，该区块链系统包括记账节点子网络2和业务节点子网络1，记账节点子网络2包括记账节点21，业务节点子网络1包括业务节点11。其中，业务节点子网络1中的业务节点11可以包括图16中所示的数据管理装置。
参照图16所示，根据本申请的一个实施例的区块链系统的数据管理装置1600，包括：接收单元1602、验证单元1604和获取单元1606。
其中，接收单元1602用于接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；验证单元1604用于对所述第一数据区块的区块头中所包含的签名进行验证；获取单元1606用于在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
在本申请的一个实施例中，验证单元1604配置为：接收来自于所述记账节点子网络的第三数据区块的区块头，其中，所述第三数据区块在所述第一数据区块之前生成；从所述第三数据区块的区块头中获取用于对所述第一数据区块的区块头进行验证的第二密钥信息；基于所述第二密钥信息对所述第一数据区块的区块头中所包含的签名进行验证。
在本申请的一个实施例中，验证单元1604配置为：若所述第一数据区块为创世块，则基于预定的密钥信息对所述第一数据区块中所包含的签名进行验证。
在本申请的一个实施例中，所述的区块链系统的数据管理装置1600还包括：发送单元，用于根据所述记账节点子网络发布的所述区块头，向所述记账节点子网络中的目标记账节点发送对指定数据区块中包含的交易数据的获取请求；所述接收单元1602还用于，接收所述目标记账节点根据所述获取请求返回的所述指定数据区块中包含的所述目标业务节点有权获取的交易数据。
图17示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图17示出的电子设备的计算机系统1700仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图17所示，计算机系统1700包括中央处理单元(Central Processing Unit，CPU)1701，其可以根据存储在只读存储器(Read-Only Memory，ROM)1702中的程序或者从存储部分1708加载到随机访问存储器(Random Access Memory，RAM)1703中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1703中，还存储有系统操作所需的各种程序和数据。CPU 1701、ROM 1702以及RAM 1703通过总线1704彼此相连。输入/输出(Input/Output，I/O)接口1705也连接至总线1704。
以下部件连接至I/O接口1705：包括键盘、鼠标等的输入部分1706；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1707；包括硬盘等的存储部分1708；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分1709。通信部分1709经由诸如因特网的网络执行通信处理。驱动器1710也根据需要连接至I/O接口1705。可拆卸介质1711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1710上，以便于从其上读出的计算机程序根据需要被安装入存储部分1708。
特别地，根据本申请的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1709从网络上被下载和安装，和/或从可拆卸介质1711被安装。在该计算机程序被中央处理单元(CPU)1701执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分 包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的申请后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (15)

  1. 一种区块链系统的数据管理方法，其中，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理方法包括：
    在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；
    生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块头中；
    将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头中包含的签名进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
  2. 根据权利要求1所述的区块链系统的数据管理方法，其中，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息，包括：
    在所述第一数据区块的区块头中所包含的指定字段添加所述第一密钥信息，以用于指示通过所述第一密钥信息对所述第二数据区块的区块头进行验证。
  3. 根据权利要求2所述的区块链系统的数据管理方法，还包括：
    若所述第一密钥信息与对所述第一数据区块的区块头进行验证的密钥信息相同，则将所述指定字段设置为空。
  4. 根据权利要求1所述的区块链系统的数据管理方法，其中，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息之前，所述数据管理方法还包括：
    从认证中心获取所述第二数据区块对应的证书，将获取到的所述证书作为所述第一密钥信息；和/或
    从认证中心获取所述第二数据区块对应的公钥和私钥，将获取到的所述公钥作为所述第一密钥信息。
  5. 根据权利要求1所述的区块链系统的数据管理方法，其中，生成所述第一数据区块对应的签名，包括：
    获取所述第一数据区块对应的签名密钥；
    利用所述第一数据区块对应的签名密钥，对所述第一数据区块中所包含的数据实施签名算法，以生成所述第一数据区块对应的签名。
  6. 根据权利要求1所述的区块链系统的数据管理方法，其中，在将所述第一数据 区块的区块头发布至所述业务节点子网络中之后，还包括：
    若所述记账节点子网络中的记账节点生成了所述第二数据区块，则通过所述第一密钥信息对应的签名密钥和所述第二数据区块生成所述第二数据区块对应的签名；
    将所述第二数据区块对应的签名添加至所述第二数据区块的区块头中，并将所述第二数据区块的区块头发布至所述业务节点子网络中。
  7. 根据权利要求1至6中任一项所述的区块链系统的数据管理方法，还包括：
    若接收到所述业务节点子网络中的目标业务节点对指定数据区块中所包含的交易数据的获取请求，则获取所述目标业务节点的权限信息；
    根据所述目标业务节点的权限信息，将所述指定数据区块中包含的所述目标业务节点有权获取的交易数据返回至所述目标业务节点。
  8. 一种区块链系统的数据管理方法，其中，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理方法由所述业务节点子网络中的业务节点执行，所述数据管理方法包括：
    接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；
    对所述第一数据区块的区块头中所包含的签名进行验证；
    在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
  9. 根据权利要求8所述的区块链系统的数据管理方法，其中，对所述第一数据区块的区块头中所包含的签名进行验证，包括：
    接收来自于所述记账节点子网络的第三数据区块的区块头，其中，所述第三数据区块在所述第一数据区块之前生成；
    从所述第三数据区块的区块头中获取用于对所述第一数据区块的区块头进行验证的第二密钥信息；
    基于所述第二密钥信息对所述第一数据区块的区块头中所包含的签名进行验证。
  10. 根据权利要求9所述的区块链系统的数据管理方法，还包括：
    若所述第一数据区块为创世块，则基于预定的密钥信息对所述第一数据区块中所包含的签名进行验证。
  11. 根据权利要求8至10中任一项所述的区块链系统的数据管理方法，还包括：
    根据所述记账节点子网络发布的所述区块头，向所述记账节点子网络中的目标记账节点发送对指定数据区块中包含的交易数据的获取请求；
    接收所述目标记账节点根据所述获取请求返回的所述指定数据区块中包含的所述 目标业务节点有权获取的交易数据。
  12. 一种区块链系统的数据管理装置，其中，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述数据管理装置包括：
    添加单元，用于在所述记账节点子网络中的记账节点生成第一数据区块后，在所述第一数据区块的区块头中添加用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；
    生成单元，用于生成所述第一数据区块对应的签名，并将所述第一数据区块对应的签名添加至所述第一数据区块的区块头中；
    发送单元，用于将所述第一数据区块的区块头发布至所述业务节点子网络中，以使所述业务节点子网络中的业务节点对所述第一数据区块的区块头进行验证，并在验证通过后获取所述第一密钥信息以对所述第二数据区块的区块头进行验证。
  13. 一种区块链系统的数据管理装置，其中，所述区块链系统包括记账节点子网络和业务节点子网络，所述记账节点子网络包括记账节点，所述业务节点子网络包括业务节点，所述业务节点包括所述数据管理装置，所述数据管理装置包括：
    接收单元，用于接收来自于所述记账节点子网络的第一数据区块的区块头，所述第一数据区块的区块头中包含有签名和用于对所述第一数据区块之后生成的第二数据区块的区块头进行验证的第一密钥信息；
    验证单元，用于对所述第一数据区块的区块头中所包含的签名进行验证；
    获取单元，用于在对所述第一数据区块的区块头中所包含的签名验证通过之后，获取所述第一密钥信息，以通过所述第一密钥信息对接收到的所述第二数据区块的区块头进行验证。
  14. 一种计算机可读介质，其上存储有计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的区块链系统的数据管理方法，或实现如权利要求8至11中任一项所述的区块链系统的数据管理方法。
  15. 一种电子设备，包括：
    一个或多个处理器和存储装置；
    所述存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至7中任一项所述的区块链系统的数据管理方法，或实现如权利要求8至11中任一项所述的区块链系统的数据管理方法。
PCT/CN2019/120955 2018-12-07 2019-11-26 区块链系统的数据管理方法、装置、介质及电子设备 Ceased WO2020114278A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP19893257.6A EP3893455A4 (en) 2018-12-07 2019-11-26 Data management method for blockchain system, device, medium, and electronic apparatus
JP2021510879A JP7195684B2 (ja) 2018-12-07 2019-11-26 ブロックチェーンシステムのデータ管理方法、装置、コンピュータプログラム、及び電子機器
US17/148,258 US11968294B2 (en) 2018-12-07 2021-01-13 Data management method and apparatus for blockchain system, medium, and electronic device
US18/610,127 US12494902B2 (en) 2018-12-07 2024-03-19 Data management method and apparatus for blockchain system, medium, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811497453.4A CN109379381B (zh) 2018-12-07 2018-12-07 区块链系统的数据管理方法、装置、介质及电子设备
CN201811497453.4 2018-12-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/148,258 Continuation US11968294B2 (en) 2018-12-07 2021-01-13 Data management method and apparatus for blockchain system, medium, and electronic device

Publications (1)

Publication Number Publication Date
WO2020114278A1 true WO2020114278A1 (zh) 2020-06-11

Family

ID=65373853

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/120955 Ceased WO2020114278A1 (zh) 2018-12-07 2019-11-26 区块链系统的数据管理方法、装置、介质及电子设备

Country Status (5)

Country Link
US (2) US11968294B2 (zh)
EP (1) EP3893455A4 (zh)
JP (1) JP7195684B2 (zh)
CN (1) CN109379381B (zh)
WO (1) WO2020114278A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114726736A (zh) * 2020-12-18 2022-07-08 中国联合网络通信集团有限公司 数据监管方法、第一监管节点、被监管节点、区块链
JP2023019673A (ja) * 2021-07-29 2023-02-09 株式会社東芝 電子契約方法、電子契約システムおよびプログラム

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109379381B (zh) * 2018-12-07 2021-06-15 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备
CN112003703B (zh) * 2019-06-28 2023-08-22 创新先进技术有限公司 一种跨链发送可认证消息的方法和装置
US11251966B2 (en) 2019-06-28 2022-02-15 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages
US11356282B2 (en) 2019-06-28 2022-06-07 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages
JPWO2021010092A1 (zh) * 2019-07-18 2021-01-21
CN111597567B (zh) * 2020-05-14 2022-03-04 腾讯科技（深圳）有限公司 数据处理方法、装置、节点设备及存储介质
CN112702354B (zh) * 2020-12-29 2023-08-11 国家电网有限公司大数据中心 一种基于区块链技术的数据资源共享追溯方法及装置
CN113923232B (zh) * 2021-06-02 2024-03-19 支付宝(杭州)信息技术有限公司 区块链子网的信息同步方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107292621A (zh) * 2017-06-22 2017-10-24 丁江 海量数据确权存证方法和节点
CN107819582A (zh) * 2016-09-14 2018-03-20 陈新 智能区块链互联系统
US20180293553A1 (en) * 2017-04-06 2018-10-11 Stronghold Labs, Llc Account platform for a distributed network of nodes
CN109379381A (zh) * 2018-12-07 2019-02-22 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3651721B2 (ja) 1996-11-01 2005-05-25 株式会社東芝 移動計算機装置、パケット処理装置及び通信制御方法
JP4193380B2 (ja) * 2001-07-05 2008-12-10 Ｋｄｄｉ株式会社 ストリーム転送における電子署名システム
JP2005217679A (ja) * 2004-01-29 2005-08-11 Hitachi Ltd 通信相手の認証を行う認証サーバ
US8503681B1 (en) * 2005-11-04 2013-08-06 Cisco Technology, Inc. Method and system to securely transport data encryption keys
US20180331832A1 (en) * 2015-11-05 2018-11-15 Allen Pulsifer Cryptographic Transactions System
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
US10305694B2 (en) * 2016-05-27 2019-05-28 Mastercard International Incorporated Method and system for efficient distribution of configuration data utilizing permissioned blockchain technology
WO2017218983A1 (en) * 2016-06-16 2017-12-21 The Bank Of New York Mellon Distributed, centrally authored block chain network
CN106411503B (zh) * 2016-11-28 2019-11-08 中国银行股份有限公司 区块链投票记账模式的记账方法及系统、投票及记账节点
WO2018120121A1 (zh) * 2016-12-30 2018-07-05 深圳前海达闼云端智能科技有限公司 区块链权限控制方法、装置及节点设备
CN107018125B (zh) * 2017-02-17 2019-08-09 阿里巴巴集团控股有限公司 一种区块链系统、数据存储方法及装置
WO2018161007A1 (en) * 2017-03-03 2018-09-07 Mastercard International Incorporated Method and system for storage and transfer of verified data via blockhain
US10878342B2 (en) * 2017-03-30 2020-12-29 Intel Corporation Cloud assisted machine learning
CN107733966A (zh) 2017-06-14 2018-02-23 广东网金控股股份有限公司 一种区块链系统与传统中心化it系统的连接装置
CN107733651B (zh) * 2017-09-11 2020-06-19 联动优势科技有限公司 一种区块链生成方法、节点及系统
WO2019127153A1 (zh) * 2017-12-27 2019-07-04 深圳达闼科技控股有限公司 区块生成方法、装置、存储介质、区块链网络
CN108765240B (zh) * 2018-07-16 2022-08-16 创新先进技术有限公司 基于区块链的机构间客户验证方法、交易监管方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107819582A (zh) * 2016-09-14 2018-03-20 陈新 智能区块链互联系统
US20180293553A1 (en) * 2017-04-06 2018-10-11 Stronghold Labs, Llc Account platform for a distributed network of nodes
CN107292621A (zh) * 2017-06-22 2017-10-24 丁江 海量数据确权存证方法和节点
CN109379381A (zh) * 2018-12-07 2019-02-22 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3893455A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114726736A (zh) * 2020-12-18 2022-07-08 中国联合网络通信集团有限公司 数据监管方法、第一监管节点、被监管节点、区块链
CN114726736B (zh) * 2020-12-18 2023-12-05 中国联合网络通信集团有限公司 数据监管方法、第一监管节点、被监管节点、数据监管装置
JP2023019673A (ja) * 2021-07-29 2023-02-09 株式会社東芝 電子契約方法、電子契約システムおよびプログラム
JP7680900B2 (ja) 2021-07-29 2025-05-21 株式会社東芝 電子契約方法、電子契約システムおよびプログラム

Also Published As

Publication number Publication date
US20210135848A1 (en) 2021-05-06
JP7195684B2 (ja) 2022-12-26
JP2021535680A (ja) 2021-12-16
EP3893455A1 (en) 2021-10-13
CN109379381A (zh) 2019-02-22
US11968294B2 (en) 2024-04-23
CN109379381B (zh) 2021-06-15
US20240223358A1 (en) 2024-07-04
EP3893455A4 (en) 2021-12-29
US12494902B2 (en) 2025-12-09

Similar Documents

Publication Publication Date Title
CN109379382B (zh) 区块链系统的数据管理方法、装置、介质及电子设备
US11943224B2 (en) Blockchain-based admission processes for protected entities
CN109636492B (zh) 基于区块链系统的税务管理方法、装置、介质及电子设备
CN112733174B (zh) 区块链系统的认证管理方法、系统及电子设备
US12494902B2 (en) Data management method and apparatus for blockchain system, medium, and electronic device
CN109447648B (zh) 在区块链网络中记录数据区块的方法、记账节点和介质
CN109658097B (zh) 区块链系统的认证管理方法、装置、介质及电子设备
JP7808404B2 (ja) プライバシーを維持した監査可能アカウントのためのコンピュータ実装方法、コンピュータシステム及びコンピュータプログラム（プライバシーを維持した監査可能アカウント）
US11941464B2 (en) Systems and methods for fetching, securing, and controlling private credentials over a disparate communication network without recompiling source code
Abadi et al. Anylog: a grand unification of the internet of things
CN112231741A (zh) 基于区块链系统的数据处理方法、装置、介质及电子设备
HK40042051B (zh) 区块链系统的认证管理方法、系统及电子设备
HK40042051A (zh) 区块链系统的认证管理方法、系统及电子设备
HK40022020A (zh) 基於区块链系统的税务管理方法、装置、介质及电子设备
HK40015523B (zh) 基於区块链系统的税务管理方法、装置、介质及电子设备
HK40015523A (zh) 基於区块链系统的税务管理方法、装置、介质及电子设备
HK40022020B (zh) 基於区块链系统的税务管理方法、装置、介质及电子设备
HK40015524A (zh) 区块链系统的数据管理方法、装置、介质及电子设备
HK40015524B (zh) 区块链系统的数据管理方法、装置、介质及电子设备
CN116010371A (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: 19893257

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021510879

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019893257

Country of ref document: EP

Effective date: 20210707