WO2020244238A1 - 多层块链式账本的数据存储方法、装置及设备 - Google Patents

多层块链式账本的数据存储方法、装置及设备 Download PDF

Info

Publication number
WO2020244238A1
WO2020244238A1 PCT/CN2020/071455 CN2020071455W WO2020244238A1 WO 2020244238 A1 WO2020244238 A1 WO 2020244238A1 CN 2020071455 W CN2020071455 W CN 2020071455W WO 2020244238 A1 WO2020244238 A1 WO 2020244238A1
Authority
WO
WIPO (PCT)
Prior art keywords
ledger
block
data
level
data record
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/CN2020/071455
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.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies 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 Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to US16/810,691 priority Critical patent/US10949118B2/en
Publication of WO2020244238A1 publication Critical patent/WO2020244238A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular to a data storage method, device and equipment for a multi-layer block chain ledger.
  • data storage is generally based on a sub-ledger, and it can also be used for certain data during verification.
  • Simple payment verification SPV is performed on the existence of the record, or serial integrity verification is performed on the entire ledger.
  • the purpose of the embodiments of the present application is to provide a method for realizing more effective data storage and verification in the blockchain.
  • a data storage method for multi-layer block chain ledgers which is applied to a server that stores data through one bottom ledger and M high-level ledgers. Both the bottom ledgers and the high-level ledgers are block-chain ledgers. M is a natural number. K high-level ledgers, 1 ⁇ K ⁇ M, the method includes:
  • the other data record is written into the data block of the Kth high-level ledger.
  • the embodiment of the present specification also provides a data storage device for a multi-layer block chain ledger, which is applied to a server that stores data through one bottom ledger and M high-level ledger. Both the bottom ledger and the high-level ledger are block chains.
  • the method includes:
  • a determining module determining the block height of the data block, and determining the root hash of the Merkel tree composed of data records in the data block;
  • the writing module writes the other data record into the data block of the Kth high-level ledger.
  • the embodiment of this specification also provides a data verification method based on the aforementioned multi-layer block chain ledger, which is applied to a system including a client and a server, wherein the server passes through one bottom ledger and M high-level ledger To store data, both the bottom-level ledgers and the high-level ledgers are block-chain ledgers, and the client stores block header information in the block-chain ledgers.
  • M is a natural number.
  • the client sends a verification instruction containing the hash value of the data record to the server;
  • the server determines the Merkel path that each ledger needs to provide for verification according to the hash value, and generates a set containing multiple Merkel path information, where each Merkel path information includes a ledger provided The Merkel path and the serial number of the ledger;
  • the client receives the set containing multiple Merkel path information, and based on the block header information, performs verification on each Merkel path in sequence according to the serial number.
  • the embodiment of the present specification also provides a data verification system based on the foregoing multi-layer block chain ledger, including a client and a server, wherein the server stores through one bottom-level ledger and M high-level ledger For data, both the bottom-level ledgers and the high-level ledgers are block-chain ledgers.
  • the client stores block header information in the block-chain ledgers, and M is a natural number.
  • the client sends a verification instruction containing the hash value of the data record to the server;
  • the server determines the Merkel path that each ledger needs to provide for verification according to the hash value, and generates a set containing multiple Merkel path information, where each Merkel path information includes a ledger provided The Merkel path and the serial number of the ledger;
  • the client receives the set containing multiple Merkel path information, and based on the block header information, performs verification on each Merkel path in sequence according to the serial number.
  • the bottom ledger is a conventional ledger
  • the high-level ledger stores the block height of the data block and the Merkel tree root of the data record.
  • the data record composed of hash, so that a data block in the high-level ledger contains a large amount of information of the underlying ledger.
  • the storage and verification of the high-level ledger increases the information capacity of the data block in the ledger, and can improve the verification during verification. effectiveness.
  • Figure 1 is a schematic diagram of the Merkel path in the current technology
  • Figure 2 is a data storage method for a multi-layer block chain ledger provided by an embodiment of this specification
  • FIG. 3 is a schematic diagram of the structure between a high-level account book and a bottom-level account book provided by an embodiment of this specification;
  • FIG. 4 is a schematic flowchart of a method for generating data blocks in a blockchain ledger provided by an embodiment of the specification
  • FIG. 5 is a schematic flowchart of a data verification method based on a multi-layer block chain ledger provided by an embodiment of this specification
  • FIG. 6 is a schematic diagram of the structure of a data storage device provided by an embodiment of the specification.
  • FIG. 7 is a schematic diagram of the hardware structure of a computing device adapted to an embodiment of the sub-specification
  • FIG. 8 is a schematic diagram of multiple Merkel paths provided in an embodiment of this specification.
  • the blockchain ledger includes a decentralized blockchain ledger and a centralized storage-like blockchain ledger. Regardless of the type of blockchain ledger, generally speaking, a ledger is used to store data records, and the data record can be verified on the client.
  • the way of storing data in the low-level ledgers and high-level ledgers is to include block headers and blocks in the ledgers.
  • the blocks store data record information
  • the block headers store related metadata information. For example, the hash value of the previous data block, the root hash value of the Merkel tree formed by the data records in the data block, and so on.
  • the size of the occupied space of the block header is much smaller than that of the block.
  • the occupied space of the block header is less than one thousandth of the block. Since the volume of the blockchain ledger is constantly increasing, the general client does not store the full amount of ledger information, but only the block header information.
  • one of the main methods in current verification is Simple Payment Verification (SPV).
  • SPV Simple Payment Verification
  • the client as a light node does not need to store the full amount of ledger data, but only needs to store the block header information in the ledger.
  • the server (the full node in the blockchain ledger) returns the corresponding Merkel path to the client.
  • Figure 1 is a schematic diagram of the Merkel path in the current technology.
  • the client when the client needs to perform SPV verification on transaction 1, it sends the hash value hash1 of transaction 1 to the server.
  • the server can find the corresponding data block according to the hash value hash1 of transaction 1, and Determine that the Merkel paths required to verify transaction 1 are hash2 and hash6, and return hash2 and hash6 to the client.
  • the client can recalculate a copy of the Merkel tree root based on hash2 and hash6, as well as the locally owned hash1 Hash, and compare with the Merkel tree root hash in the block header information stored locally, that is, it can be verified whether transaction 1 exists in the ledger and whether it has been changed.
  • the client verifies only one data record when performing SPV verification.
  • the embodiment of this specification provides a data storage method of a multi-layer block chain ledger to improve the information capacity of the data block and the efficiency of verification.
  • the multi-layer block chain ledger contains one bottom ledger and M high-level ledger. Both the bottom ledger and the high-level ledger are block chain ledger, and M is a natural number.
  • the bottom-level ledger is the current conventional blockchain ledger or similar blockchain ledger.
  • a bottom-level ledger contains multiple data blocks, and each data block consists of a block header and a block body. User data is stored in the data block of the underlying ledger in the form of data records.
  • the block header stores
  • Figure 2 is a data storage method for a multi-layer block chain ledger provided by an embodiment of this specification. The process specifically includes the following steps:
  • FIG. 3 is a schematic diagram of a structure between a high-level account book and a bottom-level account book provided by an embodiment of this specification.
  • the data stored in the high-level ledger is directly related to the data block in the previous ledger, but ultimately all directly or indirectly related to the data records in the low-level ledger.
  • the data block of the previous ledger can be obtained out of order.
  • the data blocks can also be obtained in sequence in the order of the data blocks in the previous ledger to generate data records of the high-level ledger.
  • S203 Determine the block height of the data block, and determine the root hash of the Merkel tree composed of data records in the data block.
  • the root hash of the Merkel tree formed by the data records in the data block can be obtained by querying the header of the data block, or can be recalculated according to the information in the data block body.
  • S205 Construct another data record including the root hash and block height.
  • the content of the data record in any high-level ledger includes the Merkel tree root hash (referred to as the transaction root hash in the figure) and the block height of a transaction of a data block of the previous ledger.
  • the specific number of layers of the high-level ledger can be set according to actual needs. Generally speaking, a high-level account book is sufficient to meet the needs of most situations.
  • both the bottom-level ledgers and the high-level ledgers are block chain ledgers, including blockchain ledgers and centralized blockchain-like ledgers.
  • the data blocks in the blockchain-like ledger can be generated in the following manner, as shown in Figure 4, which is the block chain type provided by the embodiment of this specification.
  • a schematic diagram of the process of generating data blocks in the ledger including:
  • S401 Receive a data record to be stored, and determine a hash value of each data record.
  • the data records to be stored here can be various consumption records of individual users of the client, or can be business results, intermediate states, and operation records generated when the application server executes business logic based on user instructions. Specific business scenarios can include consumption records, audit logs, supply chains, government supervision records, medical records, and so on.
  • the preset block conditions include: the number of data records to be stored reaches the number threshold, for example, every time one thousand data records are received, a new data block is generated and one thousand data records are written into the block; or , The time interval from the last block formation time reaches the time threshold, for example, every 5 minutes, a new data block is generated, and the data records received within these 5 minutes are written into the block.
  • the N here refers to the serial number of the data block.
  • the data block is in the form of a block chain, which is arranged sequentially based on the order of the block time, and has a strong timing characteristic.
  • the block height of the data block increases monotonically based on the sequence of the block time.
  • the block height can be a serial number, and the block height of the Nth data block is N; the block height can also be generated in other ways, for example, the block timestamp of the data block is converted into a monotonically increasing large integer data. Large integer data is the block height of the data block.
  • the data block at this time is the initial data block.
  • the current data block (the first data block) can be generated based on the hash value of the previous data block (that is, the N-1th data block). N data blocks) hash value.
  • the hash value of each data record to be written into the Nth block can be determined, and a Merkel tree is generated according to the sequence in the block, and the root hash value of the Merkel tree is summed
  • the hash value of the previous data block is spliced together, and the hash algorithm is used again to generate the hash value of the current block, and can also be based on the root hash value of the Merkel tree and some other metadata (such as version number, data Block generation timestamp, etc.) generate the current fast hash value.
  • the data record is written into the block body of the data block, and the root hash is written into the block header of the data block, wherein the block height of the data block increases monotonically based on the sequence of the block time
  • each data block is determined by a hash value
  • the hash value of the data block is determined by the content and sequence of the data records in the data block and the hash value of the previous data block.
  • the user can initiate verification based on the hash value of the data block or the hash value of the data record at any time. Any modification of the data block (including the modification of the data record content or sequence in the data block) will result in the calculation during verification.
  • the hash value of the data block is inconsistent with the hash value when the data block is generated, resulting in verification failure, thus realizing non-tampering under centralization.
  • the aforementioned centralized blockchain-like ledger can be adapted to both the bottom-level ledger and the high-level ledger.
  • FIG. 5 is a schematic flowchart of a data verification method based on a multi-layer blockchain ledger provided by an embodiment of this specification, including:
  • S501 The client sends a verification instruction including the hash value of the data record to the server.
  • the client is a light node, that is, it stores the block header information of the bottom-level ledger and the high-level ledger.
  • the server is a full node, which stores the full amount of information of the bottom-level and high-level ledgers.
  • S503 The server determines the Merkel path that each ledger needs to provide for verification according to the hash value, and generates a set containing multiple Merkel path information, where each Merkel path information includes one ledger The provided Merkel path and the serial number of the ledger.
  • an index table about the hash value and location information of the data record can be established first, and the index table may also contain the false height of the ledger corresponding to the hash value.
  • the serial number "0" represents the bottom-level ledger
  • the serial number "2" represents the second-level high-level ledger
  • the location information (2,10) represents the 10th data record in the data block with a block height of 2.
  • the index table can correspond to both the bottom-level ledger and the high-level ledger.
  • the server can quickly find the corresponding data record (the data record is in the underlying ledger) and the data block where the data record is located based on a hash value. At the same time, it should be noted that when there is no index table, the server can at least query the data record corresponding to a hash value by traversing the ledger.
  • the corresponding Merkel path in the underlying ledger can be determined first, that is, the underlying Merkel Path, the sequence number of the bottom Merkel path is 0. And, the Merkel tree root hash can be obtained from the block header of the data block or the data record in the data block can be recalculated to obtain the Merkel tree root hash.
  • the server can construct a data record data1 containing the block height of the data block and the Merkel tree root hash, and calculate the hash value hash( data1), which is another hash value. It is easy to understand that according to the structure of the data records in the high-level ledger mentioned above, the corresponding hash(data1) in the first high-level ledger can be obtained according to another hash value query (query from the aforementioned index table or through query). The data record and the data block corresponding to hash(data1) are recorded in the first high-level ledger. Therefore, the first high-level Merkel path required for verifying the data record corresponding to hash(data1) can be obtained from the data block;
  • FIG. 8 is a schematic diagram of multiple Merkel paths provided in the embodiment of this specification.
  • the Merkel tree path in each high layer is represented by a dashed box.
  • the data record corresponding to the hash value input by the user is data record 1 in data block j in the bottom ledger, and this data block is performed by a data record in the i-th data block in high-level ledger 1.
  • the bottom-level Merkel path in the bottom-level ledger is: hash2 and hash3 in the j-th data block in the bottom-level ledger; the Merkel path in the first-level high-level ledger is the first in the first high-level ledger.
  • the hash4 and hash5 in a data block, and so on.
  • any high-level ledger is associated with the previous ledger through the Merkel tree root hash contained in the data record, and this association relationship can continue to a certain data in the underlying ledger Block, and the data block is determined by the hash value entered by the user.
  • a copy of Merkel path information is composed of each Merkel path and its corresponding serial number, and multiple copies of Merkel information constitute a collection of Merkel path information.
  • S505 The client receives the set containing multiple Merkel path information, and based on the block header information, performs verification on each Merkel path in sequence according to the serial number.
  • the client can perform multiple SPV verifications in sequence starting from the Merkel path corresponding to the underlying ledger.
  • the first SPV is equivalent to completing the data record corresponding to the hash value
  • the subsequent M SPV verification is equivalent to sequentially verifying the integrity of some data blocks in the ledger.
  • n data blocks in the ledger stores n data records
  • the integrity of a data record is verified; further, according to the high-level ledger provided When performing the second SPV verification on the first Merkel path, it is equivalent to achieving the integrity verification of n data blocks (in the first high-level ledger, a data record corresponds to a data block in the underlying ledger) , That is, the time complexity of integrity verification for n ledgers is log(n).
  • the verification needs to be performed serially, and the time complexity is n.
  • the time complexity of the verification of the ledger can be reduced from n.
  • the server including the M-layer high-level ledger the time complexity of verification can be reduced from n to
  • the bottom ledger is a conventional ledger
  • the high-level ledger stores the block height of the data block and the Merkel tree root of the data record.
  • the data record composed of hash, so that a data block in the high-level ledger contains a large amount of information of the underlying ledger.
  • the storage and verification of the high-level ledger increases the information capacity of the data block in the ledger, and can improve the verification during verification. effectiveness.
  • the embodiment of the present specification also provides a data storage device for a multi-layer block chain ledger, which is applied to a server that stores data through one bottom ledger and M high-level ledger. Both the bottom ledger and the high-level ledger are block chains.
  • M is a natural number
  • K ⁇ K ⁇ M 1 ⁇ K ⁇ M
  • the acquiring module 601 acquires any data block in the previous ledger.
  • the previous ledger is the bottom ledger, and when K>1, the previous ledger is the K-1th high-level ledger;
  • the determining module 603 determines the block height of the data block, and determines the root hash of the Merkel tree composed of data records in the data block;
  • Constructing module 605 constructing another data record containing the root hash and block height
  • the writing module 607 writes the other data record into the data block of the Kth high-level ledger.
  • the block chain ledger includes a block chain ledger or a centralized storage-like blockchain ledger, wherein the device further includes a blockchain-like ledger for generating centralized storage
  • the hash value and block height of the initial data block are given based on a preset method
  • N>1 determine the root hash of the Merkel tree formed by each data record according to the hash value of each data record in the data block to be written, and write the data record into the data block In the block body, the root hash is written into the block header of the data block, where the block height of the data block increases monotonically based on the sequence of the block time.
  • the preset blocking condition includes: the number of data records to be stored reaches the number threshold; or, the time interval from the last blocking time reaches the time threshold.
  • the embodiment of this specification also provides a data verification system based on the above-mentioned multi-layer block chain ledger, including a client and a server, wherein the server stores one bottom-level ledger and M high-level ledger For data, both the bottom-level ledgers and the high-level ledgers are block-chain ledgers.
  • the client stores block header information in the block-chain ledgers, and M is a natural number.
  • the client sends a verification instruction containing the hash value of the data record to the server;
  • the server determines the Merkel path that each ledger needs to provide for verification according to the hash value, and generates a set containing multiple Merkel path information, where each Merkel path information includes a ledger provided The Merkel path and the serial number of the ledger;
  • the client receives the set containing multiple Merkel path information, and based on the block header information, performs verification on each Merkel path in sequence according to the serial number.
  • the server :
  • For the underlying ledger query the underlying ledger to obtain the data record corresponding to the hash value, and determine the block height of the data block where the data record is located, and obtain the underlying Merck required for verification of the data record Path
  • the K-th high-level ledger For the K-th high-level ledger, obtain the Merkel tree root hash and block height of the data block where the data record related to the hash value in the previous ledger is located, according to the Merkel tree root hash sum The block height generates another hash value, another data record corresponding to the another hash value is obtained by querying the K-th high-level ledger to determine the data block in which the other data record is located, and in the other The Kth high-level Merkel path corresponding to the other data record is determined in the data block where a data record is located;
  • the embodiments of this specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the data shown in FIG. 4 when the program is executed. Storage method.
  • FIG. 7 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification.
  • the device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050.
  • the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050.
  • the processor 1010 may be implemented in a general-purpose CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits for execution related Program to implement the technical solutions provided in the embodiments of this specification.
  • a general-purpose CPU Central Processing Unit, central processing unit
  • microprocessor microprocessor
  • application specific integrated circuit Application Specific Integrated Circuit, ASIC
  • ASIC Application Specific Integrated Circuit
  • the memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory, random access memory), static storage device, dynamic storage device, etc.
  • the memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of the present specification are implemented through software or firmware, related program codes are stored in the memory 1020 and called and executed by the processor 1010.
  • the input/output interface 1030 is used to connect an input/output module to realize information input and output.
  • the input/output/module can be configured in the device as a component (not shown in the figure), or can be connected to the device to provide corresponding functions.
  • the input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices.
  • the communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 1050 includes a path to transmit information between various components of the device (for example, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).
  • the device may also include the necessary equipment for normal operation.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than all the components shown in the figures.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the data storage method shown in FIG. 4 is implemented.
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Software Systems (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

一种多层块链式账本的数据存储方法、装置及设备，通过多层块链式账本进行数据存储，底层账本中即为常规的账本，高层账本中则存储由数据块的块高和数据记录的默克尔树根哈希所组成的数据记录，从而在高层账本中一个数据块包含了大量的底层账本的信息，通过高层账本进行存储和验证提高了账本中数据块的信息容量，以及在验证时可以提高验证效率。

Description

多层块链式账本的数据存储方法、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及多层块链式账本的数据存储方法、装置及设备。
背景技术
在当前的块链式账本中，无论是去中心化的区块链账本，还是中心化的类区块链账本，一般都是基于分账本进行数据存储，在进行验证时也可以针对某个数据记录的存在性进行简单支付验证SPV，或者，对整个账本进行串行式的完整性验证。
基于此，需要一种更有效的数据存储和验证的方案。
发明内容
本申请实施例的目的是提供一种区块链中实现更有效的数据存储和验证的方法。
为解决上述技术问题，本申请实施例是这样实现的：
一种多层块链式账本的数据存储方法，应用于通过1个底层账本和M个高层账本存储数据的服务端中，底层账本和高层账本均为块链式账本，M为自然数，针对第K个高层账本，1≤K≤M，所述方法包括：
获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本；
确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希；
构建包含所述根哈希和块高的另一数据记录；
将所述另一数据记录写入第K个高层账本的数据块中。
对应的，本说明书实施例还提供一种多层块链式账本的数据存储装置，应用于通过1个底层账本和M个高层账本存储数据的服务端中，底层账本和高层账本均为块链式账本，M为自然数，针对第K个高层账本，1≤K≤M，所述方法包括：
获取模块，获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本， 当K>1时，前一账本为第K-1个高层账本；
确定模块，确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希；
构建模块，构建包含所述根哈希和块高的另一数据记录；
写入模块，将所述另一数据记录写入第K个高层账本的数据块中。
另一方面，本说明书实施例还提供一种基于前述多层块链式账本的数据验证方法，应用于包括客户端和服务端的系统中，其中，服务端通过1个底层账本和M个高层账本存储数据，底层账本和高层账本均为块链式账本，客户端存储有块链式账本中的块头信息，M为自然数，所述方法包括：
客户端发送包含数据记录的哈希值的验证指令至服务端；
服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号；
客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序号，依序对每条默克尔路径执行验证。
与另一方面对应的，本说明书实施例还提供一种基于前述多层块链式账本的数据验证系统，包括客户端和服务端，其中，服务端通过1个底层账本和M个高层账本存储数据，底层账本和高层账本均为块链式账本，客户端存储有块链式账本中的块头信息，M为自然数，在所述系统中：
客户端发送包含数据记录的哈希值的验证指令至服务端；
服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号；
客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序号，依序对每条默克尔路径执行验证。
通过本说明书实施例所提供的方案，通过多层块链式账本进行数据存储，底层账本中即为常规的账本，高层账本中则存储由数据块的块高和数据记录的默克尔树根哈希所组成的数据记录，从而在高层账本中一个数据块包含了大量的底层账本的信息，通过高 层账本进行存储和验证提高了账本中数据块的的信息容量，以及在验证时可以提高验证效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为当前技术中的默克尔路径的示意图；
图2是本说明书实施例提供的一种多层块链式账本的数据存储方法；
图3为本说明书实施例所提供的一种高层账本和底层账本之间的结构示意图；
图4为本说明书实施例所提供的块链式账本中数据块的生成方式的流程示意图；
图5为本说明书实施例所提供的基于多层块链式账本的数据验证方法的流程示意图；
图6为本说明书实施例所提供的数据存储装置的结构示意图；
图7为适配分说明书实施例的一种计算设备硬件结构示意图；
图8为本说明书实施例中所提供的多条默克尔路径的示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
在块链式账本中包含去中心化的区块链账本以及中心化存储的类区块链账本。不论是哪一种块链式账本，一般而言通常是通过一个账本进行数据记录的存储，并且在客户端可以进行数据记录的验证。
在本说明书实施例中，底层账本和高层账本中的数据存储的方式即为在账本中包含块头和块体，块体中存储有数据记录的信息，块头中则存储有相关的元数据信息，例如，前一数据块的哈希值，数据块中的数据记录所构成的默克尔树的根哈希值等等。
在这种存储方式下，块头的占用空间大小要远小于块体的占用空间，一般而言，块头的占用空间不及块体的千分之一。由于块链式账本的体积是一直增长的，因此一般客户端中不会保存全量的账本信息，而仅仅保存块头信息。
基于当前的数据存储方式，当前验证中的一种主要方式即为简单支付验证(Simplified Payment Verification，SPV)。在这种验证方式下，作为轻节点的客户端无需存储有全量账本数据，只需存储有账本中的块头信息即可。在验证时，服务端(在区块链账本中即为全节点)返回给客户端相应的默克尔路径即可。
图1为当前技术中的默克尔路径的示意图。如图1所示，当客户端需要对交易1进行SPV验证时，发送交易1的哈希值hash1至服务端，服务端可以根据交易1的哈希值hash1，查找到相应的数据块，并且确定出验证交易1所需要的默克尔路径为hash2和hash6，从而返回hash2和hash6给客户端，客户端可以根据hash2和hash6，以及本地已经拥有的hash1重新计算得到一份默克尔树根哈希，并且与本地所保存的块头信息中的默克尔树根哈希进行对比，即可以验证出交易1是否存在于账本中，以及是否发生了改动。
在这种数据存储方式的验证，实际上客户端进行SPV验证时只验证了一条数据记录。基于此，本说明书实施例提供一种多层块链式账本的数据存储方法，以提高数据块的的信息容量和验证时的效率。
首先需要说明的是，在本说明书实施例中所提供的方案是基于多层块链式账本进行的。多层块链式账本中包含1个底层账本和M个高层账本，底层账本和高层账本均为块链式账本，M为自然数。
其中，底层账本即为当前常规的区块链账本或者类区块链账本，一个底层账本中包含多个数据块，每个数据块中由块头和块体组成。用户数据即以数据记录的形式存储在底层账本的数据块的块体中。块头中则存储有
以下结合附图，详细说明本说明书各实施例提供的技术方案。如图2所示，图2是本说明书实施例提供的一种多层块链式账本的数据存储方法，该流程具体包括如下步骤：
S201，获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本，当 K>1时，前一账本为第K-1个高层账本
如前所述，在本说明书实施例中，底层账本与常规技术中的账本相同。高层账本则以一种链式的方式对信息进行了层层压缩。如图3所示，图3为本说明书实施例所提供的一种高层账本和底层账本之间的结构示意图。
每一个高层账本有一个前一层账本，即，每个高层账号带有一个序号K，而K＝1的高层账本的前一账本即为底层账本。
从而可以看出，高层账本中存储的数据即与前一账本中的数据块直接相关，但是最终都与底层账本中的数据记录直接或者间接相关。
在获取前一账本的数据块时可以乱序获取。在一种实施例中，还可以按照前一账本中的数据块的顺序依次获取数据块以生成高层账本的数据记录。
S203，确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希。
数据块中的数据记录所组成的默克尔树的根哈希可以在该数据块的块头中查询得到，也可以根据数据块块体中的信息重新计算得到。
S205，构建包含所述根哈希和块高的另一数据记录。
具体而言，构建的方式可以是直接拼接所述根哈希和块高，即，另一数据记录＝根哈希+块高。
S207，将所述另一数据记录写入第K个高层账本的数据块中。
如图3所示，在任一高层账本中数据记录的内容即包含了前一账本的一个数据块的交易的默克尔树根哈希(在图中简称为交易根哈希)和块高。高层账本的具体层数可以根据实际需要设定。一般而言，一层高层账本已经足够满足大多数情况下的需求。
在本说明书实施例中，底层账本和高层账本均为块链式账本，包括区块链账本和中心化的类区块链账本。在本说明书实施例所涉及的中心化的数据库服务端中，类区块链账本中的数据块可以通过如下方式生成，如图4所示，图4为本说明书实施例所提供的块链式账本中数据块的生成方式的流程示意图，包括：
S401，接收待存储的数据记录，确定各数据记录的哈希值。此处的待存储的数据记录，可以是客户端个人用户的各种消费记录，也可以是应用服务器基于用户的指令，在执行业务逻辑时产生的业务结果、中间状态以及操作记录等等。具体的业务场景可以包 括消费记录、审计日志、供应链条、政府监管记录、医疗记录等等。
S403，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块。
所述预设的成块条件包括：待存储的数据记录数量达到数量阈值，例如，每接收到一千条数据记录时，生成一个新数据块，将一千条数据记录写入块中；或者，距离上一次成块时刻的时间间隔达到时间阈值，例如，每隔5分钟，生成一个新数据块，将在这5分钟内接收到的数据记录写入块中。
此处的N指的是数据块的序号，换言之，在本说明书实施例中，数据块是以块链的形式，基于成块时间的顺序先后排列，具有很强的时序特征。其中，数据块的块高基于成块时间的先后顺序单调递增。块高可以是序号，此时第N个数据块的块高即为N；块高也可以其它方式生成，例如，将数据块的成块时间戳转换为单调递增的大整型数据，以该大整型数据作为数据块的块高。
当N＝1时，即此时的数据块为为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如，初始数据块中不包含数据记录，哈希值则为任一给定的哈希值，块高blknum＝0；又例如，初始数据块的生成触发条件与其它数据块的触发条件一致，但是初始数据块的哈希值由对初始数据块中的所有内容取哈希确定。
当N>1时，由于前一数据块的内容和哈希值已经确定，则此时，可以基于前一数据块(即第N－1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值。
具体而言，可以确定每一条将要写入第N个块中的数据记录的哈希值，按照在块中的排列顺序，生成一个默克尔树，将默克尔树的根哈希值和前一数据块的哈希值拼接在一起，再次采用哈希算法，生成当前块的哈希值，以及还可以根据默克尔树的根哈希值和其它一些元数据(例如版本号、数据块的生成时间戳等等)生成当前快的哈希值。并且，将所述数据记录写入数据块的块体中，将所述根哈希写入数据块的块头中，其中，数据块的块高基于成块时间的先后顺序单调递增
通过前述的数据块的生成方式，每一个数据块通过哈希值确定，数据块的哈希值由数据块中的数据记录的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值或者数据记录的哈希值发起验证，对于数据块中任何内容(包括对于数据块中数据记录内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致，而导致验证失败，从而实现了中心化下的不可篡改。
需要说明的是，前述的中心化的类区块链账本，可以同时适应于底层账本和高层账本。
在通过前述方式生成了多层块链式账本后，本说明书实施例还提供一种基于前述多层块链式账本的数据记录验证方法，应用于包括客户端和服务端的系统中，如图5所示，图5为本说明书实施例所提供的基于多层块链式账本的数据验证方法的流程示意图，包括：
S501，客户端发送包含数据记录的哈希值的验证指令至服务端。
首先需要说明的是，在本说明书实施例中，客户端是一个轻节点，即，存储有底层账本和高层账本的块头信息。服务端是一个全节点，存储有底层账本和高层账本的全量信息。
S503，服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号。
在服务端中，可以先建立一个关于数据记录的哈希值和位置信息的索引表，在该索引表中，还可以包含该哈希值所对应的账本虚高。如表示1所示。在表1中，序号“0”表示底层账本，序号“2”表示为第2层高层账本；位置信息(2,10)表示块高为2的数据块中的第10条数据记录。该索引表可以同时对应于底层账本和高层账本。
哈希值 序号 位置信息
Hash1 0 (2,10)
Hash2 2 (3,100)
…… …… ……
表1
通过该索引表，服务端可以根据一个哈希值迅速查找到对应的数据记录(该数据记录处于底层账本中)，以及该数据记录所处的数据块。同时需要说明的是，在没有索引表的时候，服务端至少还可以通过遍历账本的方式查询得到一个哈希值所对应的数据记录。
在确定了该哈希值在底层账本中所对应的数据记录，以及该数据记录所处的数据块之后，即可以首先确定出该底层账本中所对应的默克尔路径，即底层默克尔路径，底层默克尔路径的序号为0。以及，可以从该数据块的块头中获取得到默克尔树根哈希或者 重新计算该数据块中的数据记录得到默克尔树根哈希。
进而，与前述构造另一数据的方式相同，服务端可以构造一个包含该数据块的块高和默克尔树根哈希的数据记录data1，并计算得到该数据记录data1的哈希值hash(data1)，即另一哈希值。容易理解，根据前述的高层账本中数据记录的构造方式，可以根据另一哈希值查询(从前述索引表中查询或者遍查询)得到在第1高层账本中所述hash(data1)所对应的数据记录，以及hash(data1)所对应的数据记录在第1高层账本中所处的数据块。从而，可以从该数据块中得到对hash(data1)所对应的数据记录进行验证时所需要的第1条高层默克尔路径；
同理类推，根据hash(data1)所对应的数据记录所处的数据块的块高和默克尔树根哈希，可以查询得到第2高层账本中所对应的第2条高层默克尔路径，直至最终的第M条高层默克尔路径。如图8所示，图8本说明书实施例中所提供的多条默克尔路径的示意图。
在该示意图中，每个高层中的默克尔树路径通过虚框表示。在该示意图中，假设用户输入的哈希值对应的数据记录在底层账本中为数据块j中的数据记录1，该数据块在高层账本1中通过第i个数据块中的一条数据记录进行关联，从而可以得到在底层账本中的底层默克尔路径为：底层账本中第j个数据块中的hash2和hash3；在第1高层账本中的默克尔路径为第1高层账本中的第一个数据块中的hash4和hash5，依次类推。
可以看出，在前述查询过程中，任一高层账本是通过数据记录中所包含的默克尔树根哈希与前一账本进行关联，这种关联关系可以延续到底层账本中的某个数据块，而该数据块正是由用户所输入的哈希值所确定。
同时需要说明的是，在前述查询过程中，如果任一中间产生的哈希值不能查询得到对应的数据记录，则说明数据记录可能发生了改动，验证失败。
一份默克尔路径信息由每条默克尔路径以及相应的序号构成，多份默克尔信息构成了默克尔路径信息的集合。
S505，客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序号，依序对每条默克尔路径执行验证。
由于客户端中存储有全量的块头信息，从而客户端可以从底层账本所对应的默克尔路径开始依序进行多次SPV验证。第一次SPV即相当于对哈希值所对应的数据记录进行了完整，后续的M次SPV验证则是相当于对账本中的部分数据块依序进行了完整性 验证。
例如，以最简单的两层账本为例，假设账本中一个数据块存储有n条数据记录，则在第1次SPV验证时，验证了一条数据记录的完整性；进而，根据高层账本所提供的第1默克尔路径进行第二次SPV验证时，相当于实现了对n个数据块(在第1高层账本中，一份数据记录对应于底层账本中的一个数据块)的完整性验证，即对于n个账本的完整性验证的时间复杂度为log(n)。
在当前进行n个数据块的完整性验证时，需要串行式的进行验证，时间复杂度为n。通过本说明书实施例所提供的方式，即可以将对于账本的验证的时间复杂度由n降低，对于包含M层高层账本的服务端而言，验证的时间复杂度由n降低为
Figure PCTCN2020071455-appb-000001
通过本说明书实施例所提供的方案，通过多层块链式账本进行数据存储，底层账本中即为常规的账本，高层账本中则存储由数据块的块高和数据记录的默克尔树根哈希所组成的数据记录，从而在高层账本中一个数据块包含了大量的底层账本的信息，通过高层账本进行存储和验证提高了账本中数据块的的信息容量，以及在验证时可以提高验证效率。
对应的，本说明书实施例还提供一种多层块链式账本的数据存储装置，应用于通过1个底层账本和M个高层账本存储数据的服务端中，底层账本和高层账本均为块链式账本，M为自然数，针对第K个高层账本，1≤K≤M，如图6所示，图6为本说明书实施例所提供的数据存储装置的结构示意图，所述装置包括：
获取模块601，获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本；
确定模块603，确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希；
构建模块605，构建包含所述根哈希和块高的另一数据记录；
写入模块607，将所述另一数据记录写入第K个高层账本的数据块中。
进一步地，在所述装置中，所述块链式账本包括区块链账本或者中心化存储的类区块链账本，其中，所述装置还包括用于生成中心化存储的类区块链账本的生成模块609：
接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含指定标识字段；当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据 块的哈希值和数据记录的第N个数据块，具体包括：
当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
当N>1时，根据待写入数据块中的各数据记录的哈希值，确定所述各数据记录所组成的默克尔树的根哈希，将所述数据记录写入数据块的块体中，将所述根哈希写入数据块的块头中，其中，数据块的块高基于成块时间的先后顺序单调递增。
进一步地，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
与另一方面对应的，本说明书实施例还提供一种基于上述多层块链式账本的数据验证系统，包括客户端和服务端，其中，服务端通过1个底层账本和M个高层账本存储数据，底层账本和高层账本均为块链式账本，客户端存储有块链式账本中的块头信息，M为自然数，在所述系统中：
客户端发送包含数据记录的哈希值的验证指令至服务端；
服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号；
客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序号，依序对每条默克尔路径执行验证。
进一步地，在所述系统中，服务端：
针对底层账本，从底层账本中查询得到所述哈希值所对应的数据记录，以及，确定所述数据记录所处数据块的块高，获取所述数据记录执行验证时所需的底层默克尔路径；
针对第K个高层账本，获取前一账本中与所述哈希值相关的数据记录所处的数据块的默克尔树根哈希和块高，根据所述默克尔树根哈希和块高生成另一哈希值，在第K个高层账本中查询得到所述另一哈希值所对应的另一数据记录，确定所述另一数据记录所处的数据块，在所述另一数据记录所处的数据块中确定出所述另一数据记录所对应的第K条高层默克尔路径；
其中，1≤K≤M，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图4所示的数据存储方法。
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图4所示的数据存储方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (11)

  1. 一种多层块链式账本的数据存储方法，应用于通过1个底层账本和M个高层账本存储数据的服务端中，底层账本和高层账本均为块链式账本，M为自然数，针对第K个高层账本，1≤K≤M，所述方法包括：
    获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本；
    确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希；
    构建包含所述根哈希和块高的另一数据记录；
    将所述另一数据记录写入第K个高层账本的数据块中。
  2. 如权利要求1所述的方法，所述块链式账本包括区块链账本或者中心化存储的类区块链账本，其中，中心化存储的类区块链账本通过如下方式生成：
    接收待存储的数据记录，确定各数据记录的哈希值；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录的哈希值，确定所述各数据记录所组成的默克尔树的根哈希，将所述数据记录写入数据块的块体中，将所述根哈希写入数据块的块头中，其中，数据块的块高基于成块时间的先后顺序单调递增。
  3. 如权利要求1所述的方法，所述预设的成块条件包括：
    待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
  4. 一种基于权利要求1至3任一所述的多层块链式账本的数据验证方法，应用于包括客户端和服务端的系统中，其中，服务端通过1个底层账本和M个高层账本存储数据，底层账本和高层账本均为块链式账本，客户端存储有块链式账本中的块头信息，M为自然数，所述方法包括：
    客户端发送包含数据记录的哈希值的验证指令至服务端；
    服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号；
    客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序 号，依序对每条默克尔路径执行验证。
  5. 如权利要求4所述的方法，服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，包括：
    针对底层账本，从底层账本中查询得到所述哈希值所对应的数据记录，以及，确定所述数据记录所处数据块的块高，获取所述数据记录执行验证时所需的底层默克尔路径；
    针对第K个高层账本，获取前一账本中与所述哈希值相关的数据记录所处的数据块的默克尔树根哈希和块高，根据所述默克尔树根哈希和块高生成另一哈希值，在第K个高层账本中查询得到所述另一哈希值所对应的另一数据记录，确定所述另一数据记录所处的数据块，在所述另一数据记录所处的数据块中确定出所述另一数据记录所对应的第K条高层默克尔路径；
    其中，1≤K≤M，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本。
  6. 一种多层块链式账本的数据存储装置，应用于通过1个底层账本和M个高层账本存储数据的服务端中，底层账本和高层账本均为块链式账本，M为自然数，针对第K个高层账本，1≤K≤M，所述装置包括：
    获取模块，获取前一账本中的任一数据块，其中，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本；
    确定模块，确定所述数据块的块高，以及，确定所述数据块中的数据记录所组成的默克尔树的根哈希；
    构建模块，构建包含所述根哈希和块高的另一数据记录；
    写入模块，将所述另一数据记录写入第K个高层账本的数据块中。
  7. 如权利要求6所述的装置，所述块链式账本包括区块链账本或者中心化存储的类区块链账本，其中，所述装置还包括用于生成中心化存储的类区块链账本的生成模块：
    接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含指定标识字段；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录的哈希值，确定所述各数据记录所组成的默克尔树的根哈希，将所述数据记录写入数据块的块体中，将所述根哈希写入数据块的块头中，其中，数据块的块高基于成块时间的先后顺序单调递增。
  8. 如权利要求7所述的装置，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
  9. 一种基于权利要求1至3任一所述的多层块链式账本的数据验证系统，包括客户端和服务端，其中，服务端通过1个底层账本和M个高层账本存储数据，底层账本和高层账本均为块链式账本，客户端存储有块链式账本中的块头信息，M为自然数，在所述系统中：
    客户端发送包含数据记录的哈希值的验证指令至服务端；
    服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，生成包含多条默克尔路径信息的集合，其中，每条默克尔路径信息中包含一个账本所提供的默克尔路径和该账本的序号；
    客户端接收所述包含多条默克尔路径信息的集合，基于所述块头信息，根据所述序号，依序对每条默克尔路径执行验证。
  10. 如权利要求9所述的系统，服务端根据所述哈希值确定进行验证时各账本所需提供的默克尔路径，包括：
    针对底层账本，从底层账本中查询得到所述哈希值所对应的数据记录，以及，确定所述数据记录所处数据块的块高，获取所述数据记录执行验证时所需的底层默克尔路径；
    针对第K个高层账本，获取前一账本中与所述哈希值相关的数据记录所处的数据块的默克尔树根哈希和块高，根据所述默克尔树根哈希和块高生成另一哈希值，在第K个高层账本中查询得到所述另一哈希值所对应的另一数据记录，确定所述另一数据记录所处的数据块，在所述另一数据记录所处的数据块中确定出所述另一数据记录所对应的第K条高层默克尔路径；
    其中，1≤K≤M，当K＝1时，前一账本为底层账本，当K>1时，前一账本为第K-1个高层账本。
  11. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至3任一项所述的方法。
PCT/CN2020/071455 2019-06-03 2020-01-10 多层块链式账本的数据存储方法、装置及设备 Ceased WO2020244238A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/810,691 US10949118B2 (en) 2019-06-03 2020-03-05 Data storage method, apparatus, and device for multi-layer blockchain-type ledger

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910475976.7 2019-06-03
CN201910475976.7A CN110347744B (zh) 2019-06-03 2019-06-03 多层块链式账本的数据存储方法、装置及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/810,691 Continuation US10949118B2 (en) 2019-06-03 2020-03-05 Data storage method, apparatus, and device for multi-layer blockchain-type ledger

Publications (1)

Publication Number Publication Date
WO2020244238A1 true WO2020244238A1 (zh) 2020-12-10

Family

ID=68181434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071455 Ceased WO2020244238A1 (zh) 2019-06-03 2020-01-10 多层块链式账本的数据存储方法、装置及设备

Country Status (2)

Country Link
CN (1) CN110347744B (zh)
WO (1) WO2020244238A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240414375A1 (en) * 2021-08-17 2024-12-12 Beijing Dajia Internet Information Technology Co., Ltd. Sign prediction for block-based video coding

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10949118B2 (en) 2019-06-03 2021-03-16 Advanced New Technologies Co., Ltd. Data storage method, apparatus, and device for multi-layer blockchain-type ledger
CN110347744B (zh) * 2019-06-03 2020-07-24 阿里巴巴集团控股有限公司 多层块链式账本的数据存储方法、装置及设备
CN111159286B (zh) * 2019-12-11 2023-05-16 支付宝(杭州)信息技术有限公司 用于生成多层块链式结构的方法及装置
CN111143381B (zh) * 2019-12-11 2023-05-19 支付宝(杭州)信息技术有限公司 用于更新多层块链式结构中的信任点的方法及装置
CN112286939B (zh) * 2020-06-12 2024-07-16 支付宝(杭州)信息技术有限公司 块链式账本中全局状态的哈希的生成方法、装置及设备
CN113657900B (zh) * 2021-07-13 2024-03-22 中国人民银行数字货币研究所 一种跨链交易验证方法、系统以及跨链交易系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108304478A (zh) * 2017-12-28 2018-07-20 深圳市轱辘车联数据技术有限公司 一种数据处理方法以及服务器
US20180316503A1 (en) * 2016-01-26 2018-11-01 Stampery Inc. Systems and methods for certification of data units and/or certification verification
CN109241357A (zh) * 2018-08-08 2019-01-18 深圳市金泽智联信息技术有限公司 链式结构模型及其构建方法、系统和终端设备
CN109299336A (zh) * 2018-09-30 2019-02-01 腾讯科技（深圳）有限公司 数据备份方法、装置、存储介质及计算设备
CN109447641A (zh) * 2018-10-26 2019-03-08 众安信息技术服务有限公司 向区块链浏览器传输区块链数据的方法和设备
CN109658099A (zh) * 2018-12-20 2019-04-19 莆田市烛火信息技术有限公司 一种基于区块链的账本记账方法
CN110347744A (zh) * 2019-06-03 2019-10-18 阿里巴巴集团控股有限公司 多层块链式账本的数据存储方法、装置及设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10848322B2 (en) * 2017-03-24 2020-11-24 Cable Television Laboratories, Inc System and method for distributed PKI root
CN107612988B (zh) * 2017-09-12 2024-02-02 北京泛融科技有限公司 一种基于物联网的账本同步系统及方法
CN107657438B (zh) * 2017-09-18 2020-12-04 联动优势科技有限公司 一种区块链生成方法、数据验证方法、节点及系统
CN108039943B (zh) * 2017-12-06 2020-10-30 清华大学深圳研究生院 一种可验证的加密搜索方法
CN109299833A (zh) * 2018-11-28 2019-02-01 国网山东省电力公司德州供电公司 基于区块链技术的快充站储能优化系统及其工作方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180316503A1 (en) * 2016-01-26 2018-11-01 Stampery Inc. Systems and methods for certification of data units and/or certification verification
CN108304478A (zh) * 2017-12-28 2018-07-20 深圳市轱辘车联数据技术有限公司 一种数据处理方法以及服务器
CN109241357A (zh) * 2018-08-08 2019-01-18 深圳市金泽智联信息技术有限公司 链式结构模型及其构建方法、系统和终端设备
CN109299336A (zh) * 2018-09-30 2019-02-01 腾讯科技（深圳）有限公司 数据备份方法、装置、存储介质及计算设备
CN109447641A (zh) * 2018-10-26 2019-03-08 众安信息技术服务有限公司 向区块链浏览器传输区块链数据的方法和设备
CN109658099A (zh) * 2018-12-20 2019-04-19 莆田市烛火信息技术有限公司 一种基于区块链的账本记账方法
CN110347744A (zh) * 2019-06-03 2019-10-18 阿里巴巴集团控股有限公司 多层块链式账本的数据存储方法、装置及设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240414375A1 (en) * 2021-08-17 2024-12-12 Beijing Dajia Internet Information Technology Co., Ltd. Sign prediction for block-based video coding
US12604039B2 (en) * 2021-08-17 2026-04-14 Beijing Dajia Internet Information Technology Co., Ltd. Sign prediction for block-based video coding

Also Published As

Publication number Publication date
CN110347744B (zh) 2020-07-24
CN110347744A (zh) 2019-10-18

Similar Documents

Publication Publication Date Title
WO2020244238A1 (zh) 多层块链式账本的数据存储方法、装置及设备
US10949118B2 (en) Data storage method, apparatus, and device for multi-layer blockchain-type ledger
WO2021073242A1 (zh) 索引创建和数据查询方法、装置及设备
WO2020211569A1 (zh) 一种数据记录的索引创建方法
CN110349019B (zh) 一种块链式账本中的验证方法、装置及设备
WO2021017422A1 (zh) 一种块链式账本中的索引创建方法、装置及设备
WO2020233146A1 (zh) 数据操作记录的存储方法、系统、装置及设备
WO2020244239A1 (zh) 一种基于业务标识的索引创建方法、装置及设备
WO2021073240A1 (zh) 一种块链式账本中的数据存储方法、装置及设备
CN110347679B (zh) 一种基于收据的数据存储方法、装置及设备
CN106897342B (zh) 一种数据校验方法和设备
CN110147410B (zh) 一种块链式账本中的数据验证方法、系统、装置及设备
CN110022315A (zh) 一种块链式账本中的权重管理方法、装置及设备
TW202040477A (zh) 個人資產變更記錄的儲存方法、系統、裝置及設備
WO2021073241A1 (zh) 一种基于磁盘存储的数据读取方法、装置及设备
WO2021093461A1 (zh) 一种块链式账本中的聚合计算方法、装置及设备
WO2021093462A1 (zh) 一种数据库中的操作记录存储方法、装置及设备
CN110362570B (zh) 一种数据存储方法、装置及设备
WO2021057127A1 (zh) 一种基于多条业务属性的数据存储方法、装置及设备
CN101763433A (zh) 一种数据存储系统及方法
CN111444197B (zh) 一种块链式账本中数据记录的验证方法、装置及设备
CN110717196A (zh) 一种证券交易数据的存储方法、装置及设备
CN111444194B (zh) 一种块链式账本中索引的清除方法、装置及设备
CN116644077A (zh) 一种数据核对的方法、装置、存储介质及电子设备
CN110636042B (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: 20818626

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20818626

Country of ref document: EP

Kind code of ref document: A1