WO2020244237A1 - 一种块链式账本中的验证方法、装置及设备 - Google Patents

一种块链式账本中的验证方法、装置及设备 Download PDF

Info

Publication number
WO2020244237A1
WO2020244237A1 PCT/CN2020/071352 CN2020071352W WO2020244237A1 WO 2020244237 A1 WO2020244237 A1 WO 2020244237A1 CN 2020071352 W CN2020071352 W CN 2020071352W WO 2020244237 A1 WO2020244237 A1 WO 2020244237A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
block
data block
value
verification
Prior art date
Application number
PCT/CN2020/071352
Other languages
English (en)
French (fr)
Inventor
杨新颖
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/809,251 priority Critical patent/US11115189B2/en
Publication of WO2020244237A1 publication Critical patent/WO2020244237A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular to a verification method, device, and equipment in a blockchain ledger.
  • Blockchain ledgers (including blockchain ledgers and centralized blockchain-like ledgers) are usually verified against a transaction, a block, or a continuous block. In many scenarios, many transactions or blocks in verification are not what users care about.
  • the purpose of the embodiments of this application is to provide a method for realizing discontinuous verification in a block chain ledger.
  • a verification method in a block chain ledger which is applied to a server that stores data in a block chain ledger, and the method includes:
  • the embodiment of this specification also provides a verification device in a blockchain ledger, which is applied to a server that stores data in a blockchain ledger, and the device includes:
  • the receiving module receives a verification request, where the verification request contains the hash value to be verified;
  • the business attribute value acquisition module determines the data record corresponding to the hash value to be verified, and acquires the value of the business attribute contained in the data record, wherein the business attribute is used to identify the type of the data record;
  • a data block determination module which determines the set of data records corresponding to the value of the business attribute in the ledger, and determines the data block where each data record in the set of data records is located;
  • the verification module performs integrity verification on the data block where each data record is located.
  • the data record can be obtained based on the hash value, and the traceability can be initiated based on the business attribute value contained in the data record, and the The business attribute value is directly related to the set of data records, so that corresponding integrity verification can be performed on the data block where each data record in the set of data records is located, thereby improving verification efficiency and user experience.
  • Fig. 1 is a schematic diagram of a process of generating a blockchain-like ledger provided by an embodiment of the specification
  • Figure 2 shows a schematic diagram of a transaction format in Bitcoin
  • FIG. 3 is a schematic flowchart of the verification method in the blockchain ledger provided by the embodiment of the specification.
  • FIG. 4 is a schematic structural diagram of a verification device in a blockchain ledger provided by an embodiment of this specification
  • Figure 5 is a schematic structural diagram of a device for configuring the method of the embodiments of this specification.
  • FIG. 6 is a schematic diagram of the data block where each data record in the data record set provided by the embodiment of the specification is located.
  • the blockchain ledger can include blockchain ledger and blockchain-like ledger.
  • the structure and formation of blockchain ledgers are already very common, so I won’t repeat them here.
  • the embodiment of this specification also provides a blockchain-like ledger that stores data in a centralized manner.
  • data blocks can be generated in the following ways, as shown in Figure 1, which is a kind of generated blockchain provided by the embodiment of this specification. Schematic diagram of the ledger process, including:
  • S101 Receive a data record to be stored, and determine a hash value of each data record, where the data record contains business attributes.
  • 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.
  • Business attributes are based on different business scenarios, and can include user name, user ID number, driver's license number, mobile phone number, project unique number, etc.
  • the specific value of the business attribute can indicate the attribution or nature of the data record.
  • the data record is the user's consumption record
  • the business attribute at this time is the user ID (including mobile phone number, ID number, user name, etc.), or the user ID is hashed
  • the hash value obtained by the algorithm; or, for government agencies, the data record is the overhead flow of multiple public projects, then the business attribute at this time can be a unique number for each project.
  • the specific location of the item attribute in the data record can be negotiated in advance between the database server and the docking organization.
  • the designated identification field can be obtained from the specified offset in the data record, or the start and end positions can be identified by specific characters; or, the docking organization
  • the header containing business attributes can be directly spliced at the beginning of each data record when uploading by the docking agency, and the database server can directly obtain the designation of each data record from the header Identification field.
  • 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 sequence number, at this time the block height of the Nth data block is N; the block height can also be generated in other ways.
  • 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). For example, a feasible way is to determine the hash value of each data record to be written in the Nth block, and generate a Merck according to the sequence in the block. In the Er tree, the root hash value of the Merkel tree and the hash value of the previous data block are spliced together, and the hash algorithm is used again to generate the hash value of the current block.
  • the hash value of the corresponding data record and the hash value of the data block can be obtained and saved, and integrity verification can be initiated based on the hash value.
  • the specific verification method is to recalculate the hash value of the data record itself and the hash value of the data block in the database, and compare with the locally stored hash value.
  • each data block is determined by a hash value, and 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 at any time. Any modification of the data block (including the modification of the data record content or sequence in the data block) will cause the hash value of the data block calculated during verification and The hash value of the data block is inconsistent when it is generated, which causes the verification to fail, thus realizing the immutability under centralization.
  • a segment of data block is designated for continuous integrity verification, or continuous integrity verification starts from the initial data block.
  • the verification method is to obtain the hash value of the previous data block, and use the same algorithm as when generating the hash value of the data block, and recalculate its own data based on its own data record and the hash value of the previous data block. The hash value of the block.
  • Figure 2 shows a schematic diagram of the data format of a transaction in Bitcoin.
  • a transaction mainly includes two parts: input information and output information.
  • the input information records the source of the input funds pre-txhash (the source transaction hash in Figure 2), that is, the hash of the source transaction.
  • the value specifies a transaction in the global ledger, and the source transaction is the aforementioned UTXO.
  • the output information records the account information of the recipient of this transaction, including the output address and the output amount.
  • the account balance seen in the Bitcoin wallet is actually obtained by the wallet scanning the blockchain and aggregating all UTXOs belonging to the account (corresponding to the address).
  • the source can be traced based on the "previous hash value" contained in the transaction, and a link to the initial mining reward is obtained.
  • This link is based on multiple different transactions running through Between multiple users, and users themselves are difficult to perceive this link. But in fact, users are most interested in all transactions on the link and the data blocks at the exchanges on the link based on their own interests.
  • the transaction itself is also a kind of data record, that is, the data record involved in the specification itself can include transactions in the blockchain.
  • FIG. 3 is a schematic flow diagram of the verification method in a blockchain ledger provided by the embodiment of this specification, which is applied to In the server for storing data in a block chain ledger, the method includes:
  • S301 Receive a verification request, where the verification request includes a hash value to be verified.
  • S303 Determine the data record corresponding to the hash value to be verified, and obtain the value of the business attribute contained in the data record.
  • a blockchain-based ledger whether it is a blockchain ledger or a blockchain-like ledger, at least the data record corresponding to a hash value can be obtained by traversing the ledger (also called in the blockchain ledger) For transactions).
  • the corresponding first index may also be provided to facilitate query.
  • a first index about the hash value of the data record, the height of the block where the data record is located, and the offset of the data record in the block can be established, so that a hash value location can be easily obtained from the first index.
  • the value of the business attribute contained in the data record can be obtained from the specified location.
  • the value of the business attribute is the "pre-txhash" contained in the aforementioned transaction.
  • the value of the business attribute is the character string corresponding to the specified field.
  • the specific specified field can be agreed with the business party in advance.
  • the header of the data record is used as the business record
  • the designated field of the attribute, the business attribute can generally be such as user ID, user ID hash, item number, etc.
  • the header of the data record is spliced with the user ID (that is, the business attribute) and the data record format sent to the server is: user ID + data record.
  • S305 Determine a set of data records corresponding to the value of the business attribute in the ledger, and determine the data block in which each data record in the set of data records is located.
  • the data records corresponding to the value of the business attribute are multiple transactions on the same transaction link, through the "pre-" contained in each transaction in the link.
  • "txhash” that is, the hash value of the previous transaction can be traced back to the initial transaction of the virtual currency (in Bitcoin, it is Bitcoin).
  • the collection of data records is all transactions on the link.
  • multiple data records containing the value can be determined based on the value of the same business attribute, for example, consumption records belonging to the same user, or accounts belonging to the same project Running water and so on.
  • the set of data records is multiple data records containing the business attribute.
  • FIG. 6 is a schematic diagram of the data block where each data record is located in the data record set provided by the embodiment of the specification.
  • the data block where each data record is located can be determined separately.
  • a second index on the data record can be established based on the business attribute, and the index is an inverted index.
  • the primary key is the value of the business attribute contained in the data record.
  • the specific writing method is: when the primary key of the second index does not contain the value of the business attribute, an index record with the value of the business attribute as the primary key is created in the index table.
  • the location information of the data record is written into the record in the second index where the value of the specified business attribute is located. It should be noted that the writing here is not an overwriting writing, but the location information is added to the value of the index record, and it is stored in the index record alongside other location information.
  • Table 1 is an exemplary second index table provided in the embodiment of this specification.
  • the Key is the specific value of the business attribute, and each array in the Value part is a piece of position information.
  • the first part of each array is the block height, and the latter part is the serial number of the data recorded in the data block. Through the block height and The serial number can uniquely identify a data record. It is easy to understand that in the index table, a key can correspond to multiple location information.
  • the database can match from the index table according to the specific value of the business attribute. For example, after Table 1 is created, if the value of the business attribute contained in a data record is "0X123456", then the 4 data records corresponding to the value can be queried from Table 1, and can be obtained from the table
  • the block heights of the data blocks where the 4 data records are directly obtained are 2 and 300.
  • the way to verify the integrity of a data block is to recalculate the hash value of the data block based on the data record in the data block and the hash value of the previous data block (calculation method and calculation when the data block is generated)
  • the hash value of the data block is the same), and the hash value is compared with the hash value of the data block previously saved (for example, with the hash value of the data block stored in the index in advance). Contrast), if they are the same, the verification is passed, if they are different, the verification fails.
  • a data record for a verification request initiated by a user, can be obtained based on the hash value, and then traceability is initiated based on the business attribute value contained in the data record to obtain a collection of data records directly related to the business attribute value. Therefore, corresponding integrity verification can be performed on the data block where each data record in the data record set is located, and the verification efficiency and user experience can be improved.
  • the server when the server needs to traverse to obtain a collection of data records and verify it (for example, when obtaining a transaction related link in the Bitcoin system), the method used to obtain the link is string In line, at this time, you can take a single-threaded acquisition of transactions, multi-threaded verification.
  • a thread to serially trace the entire link obtain the block height of each transaction in the link, and write it into a state array or shared memory (that is, other verification threads can read from the shared memory In the block height), a status is given for each block height in the array to indicate the verification status of the data block, for example, 0 means not verified, 1 means verifying, and 2 means verified.
  • the form of the state array may be [2, 0], [300, 1], [1000, 2],....
  • multiple verification threads are created to take out corresponding data blocks for verification based on the unverified block heights in the array, and correspondingly modify the state values in the state array during verification and after verification.
  • the embodiment of this specification also provides a verification device in a block chain ledger, which is applied to a server that stores data in a block chain ledger, as shown in FIG. 4, which is an example provided by the embodiment of this specification.
  • a schematic diagram of the structure of a verification device in a blockchain ledger including:
  • the receiving module 401 receives a verification request, where the verification request contains a hash value to be verified;
  • the business attribute value acquiring module 403 determines the data record corresponding to the hash value to be verified, and acquires the value of the business attribute contained in the data record, wherein the business attribute is used to identify the type of the data record;
  • the data block determination module 405 determines the set of data records corresponding to the value of the business attribute in the ledger, and determines the data block where each data record in the set of data records is located;
  • the verification module 407 performs integrity verification on the data block where each data record is located.
  • the blockchain-like data storage ledger includes a blockchain ledger, or a blockchain-like ledger that stores data in a centralized manner; the device further includes a generation module 409 for generating a blockchain-like ledger , Receive the data records to be stored, and determine the hash value of each data record, where the data record contains the business attribute; when the preset block condition is reached, determine each data record to be written in the data block, and generate The hash value of the data block and the Nth data block of the data record include:
  • the hash value and block height of the initial data block are given based on a preset method
  • 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 data block determining module 405 queries and obtains the set of data records corresponding to the value of the business attribute according to a pre-established index, wherein the index contains the value of the business attribute and the location information of the data record Or, traverse the data records in the ledger, query and obtain the collection of data records corresponding to the value of the business attribute.
  • the data block determining module 405 writes the block height of the data block in which each data record is located into a pre-established array, wherein each element in the array contains the block height of the data block.
  • the verification status of the data block includes unverified, verifying, or verified; correspondingly, the verification module 407 creates multiple verification threads, obtains unverified data blocks from the array, The said unverified data block undergoes integrity verification.
  • 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 blocks shown in FIG. 3 when the program is executed.
  • the verification method in the chain ledger is not limited to 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 blocks shown in FIG. 3 when the program is executed.
  • FIG. 5 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 verification method in the block chain ledger shown in FIG. 3 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)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Databases & Information Systems (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

一种块链式账本中的验证方法、装置及设备，对于用户所发起的验证请求，可以基于哈希值得到数据记录，进而基于数据记录中所包含的业务属性值发起溯源，得到与该业务属性值直接相关数据记录的集合，从而可以对数据记录的集合中每条数据记录所处的数据块进行相应的完整性验证，提高验证效率和用户体验。

Description

一种块链式账本中的验证方法、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及一种块链式账本中的验证方法、装置及设备。
背景技术
块链式账本(包括区块链账本以及中心化下的类区块链账本)在验证时通常都是针对一个交易、一个区块或者一段连续区块进行验证。在很多场景下，验证中的很多交易或者区块并不是用户所关心的。
基于此，需要一种可以进行非连续验证的验证方案。
发明内容
本申请实施例的目的是提供一种块链式账本中实现非连续验证的方法。
为解决上述技术问题，本申请实施例是这样实现的：
一种块链式账本中的验证方法，应用于以块链式账本存储数据的服务端中，所述方法包括：
接收验证请求，所述验证请求中包含待验证的哈希值；
确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值，其中，所述业务属性用于标识数据记录的类别；
确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块；
对所述每个数据记录所各自所处的数据块进行完整性验证。
对应的，本说明书实施例还提供一种块链式账本中的验证装置，应用于以块链式账本存储数据的服务端中，所述装置包括：
接收模块，接收验证请求，所述验证请求中包含待验证的哈希值；
业务属性值获取模块，确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值，其中，所述业务属性用于标识数据记录的类别；
数据块确定模块，确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块；
验证模块，对所述每个数据记录所各自所处的数据块进行完整性验证。
由以上本申请实施例提供的技术方案可见，本申请实施例中对于用户所发起的验证请求，可以基于哈希值得到数据记录，进而基于数据记录中所包含的业务属性值发起溯源，得到与该业务属性值直接相关数据记录的集合，从而可以对数据记录的集合中每条数据记录所处的数据块进行相应的完整性验证，提高验证效率和用户体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为本说明书实施例所提供的一种生成类区块链账本的流程示意图；
图2给出了一种比特币中的交易的格式示意图；
图3为本说明书实施例所提供的块链式账本中的验证方法的流程示意图；
图4是本说明书实施例提供的一种块链式账本中的验证装置的结构示意图；
图5是用于配置本说明书实施例方法的一种设备的结构示意图；
图6为本说明书实施例所提供的数据记录的集合中各数据记录所处数据块的示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
在块链式账本中，可以包含区块链账本和类区块链账本。区块链账本的结构和形成方式已经很常见，此处不再赘述。在本说明书实施例中还提供一种中心化方式存储数据的类区块链账本。对于中心化方式存储数据的类区块链账本，在数据库服务端中，数据块可以通过如下方式生成，如图1所示，图1为本说明书实施例所提供的一种生成类区块链账本的流程示意图，包括：
S101，接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含业务属性。
此处的待存储的数据记录，可以是客户端个人用户的各种消费记录，也可以是应用服务器基于用户的指令，在执行业务逻辑时产生的业务结果、中间状态以及操作记录等等。具体的业务场景可以包括消费记录、审计日志、供应链条、政府监管记录、医疗记录等等。
业务属性基于不同的业务场景，可以包括用户名、用户身份证号、驾照编号、手机号、项目唯一编号等等。业务属性的具体值可以表明该数据记录的归属方或者性质等等类别。
例如，对于第三方支付机构而言，数据记录是用户的消费记录，此时的业务属性即为用户标识(包括手机号、身份证号、用户名等等)，或者对该用户标识进行哈希算法所得到的哈希值；或者，对于政府机构而言，数据记录为多个公共项目的开销流水，则此时的业务属性可以为每个项目的唯一编号。
项目属性在数据记录中的具***置可以是数据库服务端和对接机构事先协商。例如，对接机构所提供的数据记录为标准结构化的数据记录时，指定标识字段可以从数据记录中指定偏移量获取，或者由特定字符标识起始位置和结束位置；又或者，对接机构所提供的数据记录为非结构化的数据时，在对接机构上传时可以直接在每条数据记录的开头拼接上包含业务属性的头部，数据库服务方可以直接从头部获取每条数据记录的指定标识字段。
S103，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块。
所述预设的成块条件包括：待存储的数据记录数量达到数量阈值，例如，每接收到一千条数据记录时，生成一个新数据块，将一千条数据记录写入块中；或者，距离上一次成块时刻的时间间隔达到时间阈值，例如，每隔5分钟，生成一个新数据块，将在这5分钟内接收到的数据记录写入块中。
此处的N指的是数据块的序号，换言之，在本说明书实施例中，数据块是以块链的形式，基于成块时间的顺序先后排列，具有很强的时序特征。其中，数据块的块高基于成块时间的 先后顺序单调递增。块高可以是序号，此时第N个数据块的块高即为N；块高也可以其它方式生成。
当N＝1时，即此时的数据块为为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如，初始数据块中不包含数据记录，哈希值则为任一给定的哈希值，块高blknum＝0；又例如，初始数据块的生成触发条件与其它数据块的触发条件一致，但是初始数据块的哈希值由对初始数据块中的所有内容取哈希确定。
当N>1时，由于前一数据块的内容和哈希值已经确定，则此时，可以基于前一数据块(即第N－1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值，例如，一种可行的方式为，确定每一条将要写入第N个块中的数据记录的哈希值，按照在块中的排列顺序，生成一个默克尔树，将默克尔树的根哈希值和前一数据块的哈希值拼接在一起，再次采用哈希算法，生成当前块的哈希值。又例如，还可以按照块中数据记录的顺序进行拼接并取哈希得到整体数据记录的哈希值，拼接前一数据块的哈希值和整体数据记录的哈希值，并对拼接得到的字串进行哈希运算，生成数据块的哈希值。
用户在上传数据成功后，即可以得到对应的数据记录的哈希值以及所处的数据块的哈希值，并保存，并且可以基于该哈希值发起完整性验证。具体的验证方式即为在数据库中重新计算数据记录自身的哈希值以及所处的数据块的哈希值，与本地所保存的进行对比。
通过前述的数据块的生成方式，每一个数据块通过哈希值确定，数据块的哈希值由数据块中的数据记录的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值发起验证，对于数据块中任何内容(包括对于数据块中数据记录内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致，而导致验证失败，从而实现了中心化下的不可篡改。
在对于块链式的账本进行验证时，一般而言，即指定一段数据块进行连续的完整性验证，或者从初始数据块开始进行连续的完整性验证。验证的方式即为获取前一数据块的哈希值，并采用与生成数据块的哈希值时的同样算法，根据自身的数据记录和前一数据块的哈希值，重新计算一遍自身数据块的哈希值。
前述部分对于本说明书实施例所涉及的类区块链账本，以及类区块链账本中的业务属性的值进行了说明。
在区块链账本中，对于区块体的形成方式和结构，此处不再赘述。需要说明的是，在区块链账本中同样存在业务属性。以公开的比特币(Bitcoin)区块链为例(其他公开发行币种 的区块链***中也类似)，在比特币进行转账的过程中，是以未花费的交易输出(Unspent Transaction Outputs，UTXO)为核心开展比特币在用户间的流转的。比特币中规定了每一笔新的交易的输入必须是某笔UTXO。
换言之，所有合法的比特币交易都可以追溯到前向一个或多个交易的输出，这些链条的源头都是挖矿奖励，末尾则是当前未花费的交易输出UTXO。如图2所示，图2给出了一种比特币中的交易的数据格式示意图。
在比特币中，交易主要包括2个部分：输入信息和输出信息，输入信息中记录的是输入资金的来源pre-txhash(即图2中的来源交易哈希)，即通过来源交易的哈希值指定全局账本中的一条交易，来源交易即为前述的UTXO。输出信息中记录此次交易接收方的账户信息，包括输出地址和输出金额。
换言之，在比特币钱包中所看到的账户余额，实际上也是钱包通过扫描区块链并聚合所有属于该账户(与地址对应)的UTXO并相加得来的。
针对比特币中存在的任一交易，均可以基于交易中所包含的“前一哈希值”进行溯源，得到一条指向初始挖矿奖励的链路，该链路基于多个不同的交易贯穿于多个用户之间，而用户本身对于这条链路是难以感知的。但是实际上用户基于自身利益，恰恰是对该链路上的所有交易，以及，该链路上的交易所处的数据块最感兴趣。
需要说明的是，交易本身也是一种数据记录，即，在本身说明书中所涉及的数据记录可以包括区块链中的交易。
基于此，本说明书实施例提供一种块链式账本中的验证方法，如图3所示，图3为本说明书实施例所提供的块链式账本中的验证方法的流程示意图，应用于以块链式账本存储数据的服务端中，所述方法包括：
S301，接收验证请求，所述验证请求中包含待验证的哈希值。
S303，确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值。
在块链式的账本中，不论是区块链账本还是类区块链账本，均至少可以通过遍历账本的方式来查询获取一个哈希值所对应的数据记录(在区块链账本中也称为交易)。
在一种实施方式中，还可以提供相应的第一索引以方便查询。例如，可以建立关于数据记录的哈希值、数据记录所处的块高、数据记录在块中的偏移量的第一索引，从而可以从第 一索引中方便的查询得到一个哈希值所对应的数据记录。
在获取得到一条数据记录后，即可以从指定的位置获取得到该数据记录所包含的业务属性的值。在比特币式的区块链账本中，业务属性的值即为前述的交易中所包含的“pre-txhash”。
在块链式的账本中，业务属性的值即为在指定的字段所对应的字符串，具体的指定字段可以同对接的业务方事先协定即可，例如，以数据记录的头部作为记载业务属性的指定字段，业务属性一般可以是诸如用户标识、用户标识哈希、项目编号等等。例如，数据记录的头部拼接了用户标识(即业务属性)发送给服务端的数据记录格式为：用户标识+数据记录。
S305，确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块。
在类似比特币进行交易的区块链***中，业务属性的值所对应的数据记录即为处于同一交易链路上的多个交易，通过链路中的每条交易中所包含的“pre-txhash”，即前一交易的哈希值可以进行追溯，直至最初所产生虚拟币的交易(在比特币中即为比特币)。数据记录的集合即为该链路上的所有交易。
在本说明书实施例所提供的类区块链账本中，则可以基于同一业务属性的值确定出包含该值的多条数据记录，例如，属于同一用户的消费记录，或者，属于同一项目的账目流水等等。此时数据记录的集合即为包含该业务属性的多条数据记录。
容易理解，在数据记录的集合中，各数据记录经常存储在不同的数据块上，即，在以UTXO为基础进行交易的区块链***中，一份交易的前一交易往往在其它数据块中；在类区块链***中，包含同一业务属性的数据记录也往往是存储在不同的数据块上。如图6所示，图6为本说明书实施例所提供的数据记录的集合中各数据记录所处数据块的示意图。
在确定了数据记录的集合之后，即可以分别确定每个数据记录所处的数据块。
在类区块链账本中，当数据记录中包含业务属性时，则可以基于该业务属性建立起关于数据记录的第二索引，该索引即为一个倒排索引。在第二索引中，主键是数据记录中所包含的业务属性的值。
具体的写入方式为，当第二索引的主键中不包含所述业务属性的值时，在索引表中创建以所述业务属性的值为主键的索引记录。
当所述索引中的主键包含所述业务属性的值时，将数据记录的位置信息写入所述指定业务属性的值所处的第二索引中的记录。需要说明的是，此处的写入不是覆盖性的写入，而是 将位置信息添加到该索引记录的值中，与其它位置信息并列存在与该索引记录中。
如表1所示，表1为本说明书实施例所提供的一种示例性第二索引表。其中Key即为业务属性的具体值，Value部分的每个数组即为一条位置信息，每个数组中的前部分为块高，后部分为数据记录在该数据块中的序号，通过块高和序号即可以唯一的确定一条数据记录。容易理解，在索引表中，一个key可以对应于多个位置信息。
表1
Key Value
0X123456 (2,08)，(2,10)，(300,89)，(300,999)
344X0001 (5,01)，(8,22)
…… ……
从而，数据库可以根据业务属性的具体值，从索引表中进行匹配。例如，在表1被创建之后，若一个数据记录中所包含的业务属性的值为“0X123456”，则可以从表1中查询得到该值所对应的4条数据记录，并且，可以从表中直接获取4条数据记录所处的数据块的块高为2和300。
可以看出，通过前述方式所得到的数据记录，均为与用户所输入的哈希值直接相关的数据记录。
S307，对所述每个数据记录所各自所处的数据块进行完整性验证。
对一个数据块进行完整性验证的方式即为：根据该数据块中的数据记录与前一数据块的哈希值，重新计算出本数据块的哈希值(计算方式与生成数据块时计算数据块的哈希值的方式相同)，并且将该哈希值与之前所保存的该数据块的哈希值进行一致性对比(例如，与预先保存在索引中的该数据块的哈希值对比)，若相同，则验证通过，若不同，则验证失败。
本申请实施例中对于用户所发起的验证请求，可以基于哈希值得到数据记录，进而基于数据记录中所包含的业务属性值发起溯源，得到与该业务属性值直接相关的数据记录的集合，从而可以对数据记录的集合中每条数据记录所处的数据块进行相应的完整性验证，提高验证效率和用户体验。
在一种实施例中，当服务端需要遍历获取数据记录的集合并进行验证时(例如，在比特币***中获取一条交易的相关链路时)，由于获取链路时所采取的方式是串行式的，此时，可以采取单线程获取交易，多线程验证的方式。
即，创建一个线程用于串行式的追溯整条链路，获取链路中每个交易的块高，并写入一个状态数组或者共享内存(即其它验证线程均可以从共享内存中读取该块高)中，数组中对于每个块高给出一个状态，用于表明该数据块的验证状态，例如，0为未验证、1为验证中，2为已验证。从而，状态数组的形式可能是[2，0]，[300，1]，[1000，2]，……。
同时，创建多个验证线程用于根据数组中未验证的块高取出对应的数据块进行验证，验证中以及验证后均对状态数组中的状态值进行对应修改。在这种方式下，可以实现在串行确定待验证的数据块同时，通过多个验证线程对已经确定的待验证数据块进行并行验证，提高验证效率。
对应的，本说明书实施例还提供一种块链式账本中的验证装置，应用于以块链式账本存储数据的服务端中，如图4所示，图4是本说明书实施例提供的一种块链式账本中的验证装置的结构示意图，包括：
接收模块401，接收验证请求，所述验证请求中包含待验证的哈希值；
业务属性值获取模块403，确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值，其中，所述业务属性用于标识数据记录的类别；
数据块确定模块405，确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块；
验证模块407，对所述每个数据记录所各自所处的数据块进行完整性验证。
进一步地，所述块链式存储数据的账本包括区块链账本，或者，以中心化方式存储数据的类区块链账本；所述装置还包括用于生成类区块链账本的生成模块409，接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含业务属性；当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
进一步地，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
进一步地，所述数据块确定模块405，根据预先建立的索引，查询获取所述业务属性的值所对应的数据记录的集合，其中，所述索引中包含业务属性的值和数据记录的位置信息的对应关系；或者，遍历所述账本中的数据记录，查询获取业务属性的值所对应的数据记录的集合。
进一步地，所述数据块确定模块405，将所述每个数据记录所各自所处的数据块的块高写入预先建立的数组，其中，所述数组中每个元素包含数据块的块高和数据块的验证状态，所述验证状态包含未验证、验证中或者已验证；相应的，所述验证模块407，创建多个验证线程，从所述数组中获取未验证的数据块，对所述未验证的数据块进行完整性验证。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图3所示的块链式账本中的验证方法。
图5示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器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，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图3所示的块链式账本中的验证方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的***、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而 言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (11)

  1. 一种块链式账本中的验证方法，应用于以块链式账本存储数据的服务端中，所述方法包括：
    接收验证请求，所述验证请求中包含待验证的哈希值；
    确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值，其中，所述业务属性用于标识数据记录的类别；
    确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块；
    对所述每个数据记录所各自所处的数据块进行完整性验证。
  2. 如权利要求1所述的方法，所述块链式存储数据的账本包括区块链账本，或者，以中心化方式存储数据的类区块链账本；
    其中，所述以中心化方式存储数据的类区块链账本通过如下方式生成：
    接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含业务属性；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
  3. 如权利要求2所述的方法，，所述预设的成块条件包括：
    待存储的数据记录数量达到数量阈值；或者，
    距离上一次成块时刻的时间间隔达到时间阈值。
  4. 如权利要求1所述的方法，确定所述账本中所述业务属性的值所对应的数据记录的集合，包括：
    根据预先建立的索引，查询获取所述业务属性的值所对应的数据记录的集合，其中，所述索引中包含业务属性的值和数据记录的位置信息的对应关系；
    或者，遍历所述账本中的数据记录，查询获取业务属性的值所对应的数据记录的集合。
  5. 如权利要求1所述的方法，确定所述数据记录的集合中每个数据记录所各自所处的数据块，包括：
    将所述每个数据记录所各自所处的数据块的块高写入预先建立的数组，其中，所述数组中每个元素包含数据块的块高和数据块的验证状态，所述验证状态包含未验证、验证中或者已验证；
    相应的，对所述每个数据记录所各自所处的数据块进行验证，包括：
    创建多个验证线程，从所述数组中获取未验证的数据块，对所述未验证的数据块进行完整性验证。
  6. 一种块链式账本中的验证装置，应用于以块链式账本存储数据的服务端中，所述装置包括：
    接收模块，接收验证请求，所述验证请求中包含待验证的哈希值；
    业务属性值获取模块，确定所述待验证的哈希值所对应的数据记录，获取所述数据记录中所包含的业务属性的值，其中，所述业务属性用于标识数据记录的类别；
    数据块确定模块，确定所述账本中所述业务属性的值所对应的数据记录的集合，确定所述数据记录的集合中每个数据记录所各自所处的数据块；
    验证模块，对所述每个数据记录所各自所处的数据块进行完整性验证。
  7. 如权利要求6所述的装置，所述块链式存储数据的账本包括区块链账本，或者，以中心化方式存储数据的类区块链账本；
    所述装置还包括用于生成类区块链账本的生成模块，接收待存储的数据记录，确定各数据记录的哈希值，其中，数据记录中包含业务属性；当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
  8. 如权利要求7所述的装置，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
  9. 如权利要求6所述的装置，所述数据块确定模块，根据预先建立的索引，查询获取所述业务属性的值所对应的数据记录的集合，其中，所述索引中包含业务属性的值和数据记录的位置信息的对应关系；或者，遍历所述账本中的数据记录，查询获取业务属性的值所对应的数据记录的集合。
  10. 如权利要求6所述的装置，所述数据块确定模块，将所述每个数据记录所各自 所处的数据块的块高写入预先建立的数组，其中，所述数组中每个元素包含数据块的块高和数据块的验证状态，所述验证状态包含未验证、验证中或者已验证；
    相应的，所述验证模块，创建多个验证线程，从所述数组中获取未验证的数据块，对所述未验证的数据块进行完整性验证。
  11. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至5任一项所述的方法。
PCT/CN2020/071352 2019-06-03 2020-01-10 一种块链式账本中的验证方法、装置及设备 WO2020244237A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/809,251 US11115189B2 (en) 2019-06-03 2020-03-04 Verifying a blockchain-type ledger

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910476256.2A CN110349019B (zh) 2019-06-03 2019-06-03 一种块链式账本中的验证方法、装置及设备
CN201910476256.2 2019-06-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/809,251 Continuation US11115189B2 (en) 2019-06-03 2020-03-04 Verifying a blockchain-type ledger

Publications (1)

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

Family

ID=68181404

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071352 WO2020244237A1 (zh) 2019-06-03 2020-01-10 一种块链式账本中的验证方法、装置及设备

Country Status (2)

Country Link
CN (1) CN110349019B (zh)
WO (1) WO2020244237A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11115189B2 (en) 2019-06-03 2021-09-07 Advanced New Technologies Co., Ltd. Verifying a blockchain-type ledger
CN110349019B (zh) * 2019-06-03 2020-11-10 创新先进技术有限公司 一种块链式账本中的验证方法、装置及设备
CN111046069B (zh) * 2019-11-11 2021-05-07 蚂蚁区块链科技(上海)有限公司 一种块链式账本中的聚合计算方法、装置及设备
CN111709748B (zh) * 2020-06-11 2023-08-22 杭州溪塔科技有限公司 一种具有业务属性的交易执行方法、装置及电子设备
CN111798318B (zh) * 2020-07-07 2023-12-05 旻萌科技有限公司 一种极速持仓管理方法及***
CN111984615B (zh) * 2020-08-04 2024-05-28 中国人民银行数字货币研究所 一种共享文件的方法、装置及***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170091726A1 (en) * 2015-09-07 2017-03-30 NXT-ID, Inc. Low bandwidth crypto currency transaction execution and synchronization method and system
CN106600403A (zh) * 2016-11-07 2017-04-26 北京金股链科技有限公司 一种资产管理方法、装置和***
CN108416696A (zh) * 2018-02-28 2018-08-17 国网江苏省电力有限公司淮安供电分公司 基于区块链技术的区域电力自由交易方法
CN108510252A (zh) * 2018-03-24 2018-09-07 北京理工大学 一种基于区块链的智能电动汽车电网安全支付***及方法
CN109409136A (zh) * 2018-11-08 2019-03-01 中链科技有限公司 区块链存证内容的验证方法、装置及计算设备
CN109493043A (zh) * 2018-10-30 2019-03-19 广州品唯软件有限公司 交易记录区块化方法、装置、电子设备及存储介质
CN110349019A (zh) * 2019-06-03 2019-10-18 阿里巴巴集团控股有限公司 一种块链式账本中的验证方法、装置及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080031751A (ko) * 2005-06-29 2008-04-10 코닌클리케 필립스 일렉트로닉스 엔.브이. 키 블록 기반의 인증 시스템 및 방법
KR101680540B1 (ko) * 2015-06-18 2016-11-30 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
CN106899680B (zh) * 2017-03-09 2019-07-30 深圳壹账通智能科技有限公司 多区块链的分片处理方法和装置
CN108573381B (zh) * 2017-03-09 2020-06-05 北京京东尚科信息技术有限公司 数据处理方法以及装置
CN107464118A (zh) * 2017-08-16 2017-12-12 济南浪潮高新科技投资发展有限公司 一种基于区块链智能合约的数据交易方法
CN109087101B (zh) * 2018-08-07 2021-09-07 北京三快在线科技有限公司 交易校验方法、装置、存储介质及电子设备
CN109242500B (zh) * 2018-09-20 2021-07-02 百度在线网络技术（北京）有限公司 区块链交易有效性验证方法、装置及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170091726A1 (en) * 2015-09-07 2017-03-30 NXT-ID, Inc. Low bandwidth crypto currency transaction execution and synchronization method and system
CN106600403A (zh) * 2016-11-07 2017-04-26 北京金股链科技有限公司 一种资产管理方法、装置和***
CN108416696A (zh) * 2018-02-28 2018-08-17 国网江苏省电力有限公司淮安供电分公司 基于区块链技术的区域电力自由交易方法
CN108510252A (zh) * 2018-03-24 2018-09-07 北京理工大学 一种基于区块链的智能电动汽车电网安全支付***及方法
CN109493043A (zh) * 2018-10-30 2019-03-19 广州品唯软件有限公司 交易记录区块化方法、装置、电子设备及存储介质
CN109409136A (zh) * 2018-11-08 2019-03-01 中链科技有限公司 区块链存证内容的验证方法、装置及计算设备
CN110349019A (zh) * 2019-06-03 2019-10-18 阿里巴巴集团控股有限公司 一种块链式账本中的验证方法、装置及设备

Also Published As

Publication number Publication date
CN110349019A (zh) 2019-10-18
CN110349019B (zh) 2020-11-10

Similar Documents

Publication Publication Date Title
WO2020244237A1 (zh) 一种块链式账本中的验证方法、装置及设备
WO2021073242A1 (zh) 索引创建和数据查询方法、装置及设备
CN110188096B (zh) 一种数据记录的索引创建方法、装置及设备
WO2020211569A1 (zh) 一种数据记录的索引创建方法
WO2020093808A1 (zh) 一种构建梅克尔树、简单支付验证方法及装置
CN110162662B (zh) 一种块链式账本中数据记录的验证方法、装置及设备
WO2021017422A1 (zh) 一种块链式账本中的索引创建方法、装置及设备
WO2020244239A1 (zh) 一种基于业务标识的索引创建方法、装置及设备
CN110162526B (zh) 一种块链式账本中数据记录的查询方法、装置及设备
CN112286939B (zh) 块链式账本中全局状态的哈希的生成方法、装置及设备
WO2021073240A1 (zh) 一种块链式账本中的数据存储方法、装置及设备
WO2021093461A1 (zh) 一种块链式账本中的聚合计算方法、装置及设备
WO2020244238A1 (zh) 多层块链式账本的数据存储方法、装置及设备
WO2020253231A1 (zh) 一种基于收据的数据存储方法、装置及设备
WO2020211497A1 (zh) 一种个人资产变更记录的存储方法、***、装置及设备
WO2021073241A1 (zh) 一种基于磁盘存储的数据读取方法、装置及设备
WO2020093807A1 (zh) 一种对写入区块链的交易进行隐匿的方法及装置
WO2021057164A1 (zh) 一种块链式账本中的查询方法、装置及设备
WO2021000578A1 (zh) 一种块链式账本中的用户创建方法、装置及设备
WO2021093462A1 (zh) 一种数据库中的操作记录存储方法、装置及设备
WO2021057127A1 (zh) 一种基于多条业务属性的数据存储方法、装置及设备
CN110362570B (zh) 一种数据存储方法、装置及设备
CN110636042B (zh) 一种服务端已验证块高的更新方法、装置及设备
CN111444194B (zh) 一种块链式账本中索引的清除方法、装置及设备
US11115189B2 (en) Verifying a blockchain-type ledger

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

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

Country of ref document: EP

Kind code of ref document: A1