CN114880320B

CN114880320B - Method for generating block state certification

Info

Publication number: CN114880320B
Application number: CN202210320521.XA
Authority: CN
Inventors: 陈�胜; 蒋步云
Original assignee: Beijing Lianqi Technology Co ltd
Current assignee: Beijing Lianqi Technology Co ltd
Priority date: 2021-12-30
Filing date: 2021-12-30
Publication date: 2023-02-17
Anticipated expiration: 2041-12-30
Also published as: CN114691686A; CN114003972B; CN114691686B; CN114003972A; CN114880320A; CN114691687A; CN114691687B

Abstract

The application provides a method for generating a block state certificate, which comprises the following steps: acquiring a state name; acquiring the latest version of the state; obtaining global non-existence commitments of subsequent versions of the state; the timeliness of the state in the global is proven based on the latest version of the state, and the absence commitment of subsequent versions of the state in the global. By organizing the state tree by taking the block as a unit, the scale of the state tree is small, and the overdue mechanism of the write-in state is combined, under the scene that the global state scale is huge but the active state scale is limited, the cost for calculating the state existence certification is greatly reduced, and the length of the state certification data is shortened.

Description

Method for generating block state certification

Technical Field

The present application relates to the field of blockchain security technologies, and in particular, to a method for generating block status commitment and certification and verifying block status certification.

Background

The state verification mode of the block chain can be divided into full node verification and light node verification. The system can verify the block validity according to the block height by locally storing all block data, execute signature transaction item by item according to the signature transaction sequence in the block, and automatically generate and verify the state of an account book; for the light nodes without local blocks and account book data, because the light nodes do not have state data required for executing signature transaction, the existence of the specified state at the specified block height can be verified only by the certification data generated by all the nodes.

The most representative state verification method at present is the global state-based mekel proof adopted by the etherhouse backbone. The method includes that after the execution of signature transaction in each block is finished, the root of the Merkel tree in the current global state (namely the existence promise of the global state) is included in the block head of each block, all nodes disclose the block head to the light node and provide the state value of the designated state name and the Merkel path of the state, and the light node can verify whether the designated state exists at the height of the block by self-verifying the block legality, calculating and comparing the root of the Merkel tree. This approach faces the "state data inflation" problem.

"state data expansion" means that because of the increasing of users and contracts and the increasing of state key-value pairs written in contract execution, more and more state data are stored at all nodes, so that the size of the global state tree is continuously enlarged, on one hand, the calculation amount of the root of the state tree is continuously increased, on the other hand, the data length of the mekerr path as the state proof is continuously increased, and therefore, the ethertorial proposes two solutions for this purpose:

1. the state is expired: the state proof follows the current Merkle Patricia Tree (MPT Tree for short) mode. The State that has not been accessed recently (e.g., last access or last year) is removed from the State and a State Proof of all nodes (State Proof) is required to restore the expired State. This would reduce the state that each person needs to store to about 20-50GB. The limitations of this approach are: a. the data scale of a single MPT tree is reduced within the recent state access time range, when a large number of non-repetitive state names are accessed in a short time, the reduction effect is limited, and the calculation amount of state certification and the certification data length are still too large; b. there is a security issue that for the state existing in the latest MPT tree, the full node can do "state timeliness spoofing," the latest state that the light node lies actually exists does not exist, and a proof of the expired state is generated from the historical MPT tree.

2. Weak and stateless: only the block proposer is required to store the state and allow all other nodes to verify the block stateless. Achieving this in practice requires switching to a wokerr Tree (Verkle Tree) to reduce the size of the proof data generated. The limitations of this approach are: a. the KZG commitment adopted by wacker trees demonstrates that although the data length is small, the computational load for generating the proof is large. b. Because the global state tree is still maintained, the computation amount of generating the proof will continuously increase along with the expansion of state data, and when the leaf nodes of the Wolk tree reach a certain number, the computation complexity of generating the proof is difficult to apply in engineering.

Disclosure of Invention

The present application is directed to a method for generating a block status commitment and certification and verifying a block status certification, so that a light node without block data and status data can verify the existence and timeliness of a block chain status.

According to an aspect of the present application, a method for generating a block status commitment is provided, comprising:

recording the version of the writing state each time the state is written in the block;

inputting the state name and the version of the writing state into a global filter to obtain a filter result, and recording the filter result in the block as an absence commitment;

organizing a state tree for the state names and the composite state values of all the writing states of the block, calculating, and taking the calculation result as a presence commitment;

recording the presence commitment in a block;

wherein the block contains all non-existent commitments of non-outdated write status for all blocks.

According to some embodiments, the aforementioned method comprises: said recording said filter results in said block as an absence commitment, comprising:

acquiring a write state set of the block;

acquiring a current version of the writing state according to the version naming rule of the writing state and a previous version;

encoding the state name and the current version of the written state to generate a composite state name;

inputting the composite state name of each written state into a global filter, and performing filter calculation to obtain a filter result as an absence commitment;

and establishing a block height-composite state name index for the input composite state name according to the current block height.

According to some embodiments, the aforementioned method further comprises:

acquiring a next version of the state according to the current version of the state and the version naming rule;

coding according to the state name of the written state and the next version to generate a composite state name of the next version;

performing independent filter calculation on the composite state name of the next version, comparing a calculation result with the non-existence commitment, and judging whether the composite state name of the next version exists or not;

if yes, switching the current version of the writing state to the next version;

repeating the steps until the current versions of all the writing states of the block are obtained;

and inputting the composite state name of each current version of the writing state into a global filter for calculation to obtain a filter result as an absence commitment.

According to some embodiments, the aforementioned method comprises:

deleting the composite state name of the last written version of the written state from the global filter, and updating the block height-composite state name index;

if the version of the write status is an initial version or the write status is an expired status, adding 1 to the total number of elements of the global filter;

if the total number of elements of the global filter exceeds a preset upper limit, deleting 1 earliest written composite state name from the global filter according to the block height-composite state name index, and updating the block height-composite state name index;

if the state list corresponding to the block height is not empty after deletion, recording the block height of the state as the height of the overdue block, otherwise, increasing the block height until a block height corresponding to the state list which is not empty is found, and recording the block height as the height of the overdue block.

According to some embodiments, the aforementioned method comprises: the independent filter and the global filter include: cuckoo filter.

According to some embodiments, the aforementioned method comprises: said recording said presence commitment in a block, comprising:

acquiring a writing state set of the block;

for each writing state of the block, encoding an original value of the writing state, a current version of the state and the height of the block to generate a composite state value;

writing all the written states of the block into a state database of a block chain by using the state name and the composite state value as key values;

and establishing a state tree for all the writing states of the block according to the state name and the composite state value, and calculating a state tree root as the existence promise of all the writing states.

According to some embodiments, the aforementioned method comprises: the establishing of the state tree comprises:

and obtaining the state tree through Meckel tree or Wokel tree calculation.

According to some embodiments, the aforementioned method comprises: the presence commitment is represented using a root of a Merkel tree or a Woker tree.

According to another aspect of the present application, there is provided a method of generating a block status attestation, comprising:

acquiring a state name;

acquiring the latest version of the state;

obtaining global non-existence commitments of subsequent versions of the state;

the timeliness of the state in the global is proven based on the latest version of the state, and the absence commitment of subsequent versions of the state in the global.

According to some embodiments, the aforementioned method comprises:

according to the appointed state name, obtaining the block head written in the state for the last time;

acquiring a block head with the latest height;

acquiring a state tree corresponding to a block which is written in the state for the last time;

obtaining a presence commitment in a block header that was last written to the state;

according to the specified state name and the state tree, calculating to obtain a Merkel path or a Wackel path of the specified state name in the state tree as a state existence proof;

calculating the composite state name of the subsequent version of the state according to the state name and the version naming rule of the state;

performing independent filter calculation on the composite state name, and comparing the composite state name with the non-existent commitment of the state contained in the block header with the latest height to obtain a comparison result;

and generating a state certificate according to the existence certificate of the state and the comparison result.

According to some embodiments, the aforementioned method comprises: the obtaining the block header written to the state last time comprises:

reading a composite state value from a key value database according to the specified state name;

decoding the composite state value to obtain an original value of the state, a current version of the state and the height of a block in which the state is located;

and acquiring the block head written in the state for the last time according to the height of the block.

According to some embodiments, the aforementioned method comprises: the generating of the state certificate according to the comparison result comprises:

judging whether the block height of the last written state is not greater than the height of an expired block, if so, calling a state updating contract, and switching the current version of the state to the next version as a new version of the state;

if the state is not expired, judging whether the composite state name of the subsequent version of the state is judged to exist by mistake;

if misjudgment exists, the full node calls a state updating contract through signature transaction, the current version of the state is switched to the next version,

generating a state certificate according to the block head, the state name and the new composite state value of the newly-out block containing the state updating transaction;

and if no misjudgment or overdue state is found, generating a state certificate according to the state name, the composite state value, the block header written into the state for the last time and the block header with the latest height.

According to another aspect of the present application, there is provided a method of verifying block status attestation, comprising:

acquiring a state certificate of a specified state;

acquiring a block head and a latest block head of a block corresponding to the specified state from the state certificate;

verifying the validity of the block header and the latest block header of the corresponding block so as to verify that the existence promise, the non-existence promise and the height of the expired block contained in the block header are not tampered or forged;

verifying the presence commitment;

verifying the non-existent commitment.

According to some embodiments, the aforementioned method comprises: the verifying the presence commitment comprises:

obtaining a state name, a composite state value and a presence certificate of the state from the state certificate;

extracting a presence commitment of a state from a current block header, calculating by adopting a Meckel tree or Wolk tree method, and verifying whether a state name and a composite state value exist in the presence commitment.

According to some embodiments, the aforementioned method comprises: the verifying the non-existence commitment comprises:

extracting the height of an expired block from the latest block head, and if the height of the expired block is not less than the height of the block written in the specified state for the last time, the verification is not passed;

if the verification is passed, extracting the non-existent promise of the state from the latest block header so as to verify that the block corresponding to the specified state is the block written in the specified state for the last time;

extracting a state version from the composite state value, and acquiring a next version of the state according to the state version and a version naming rule;

generating a composite state name of a next version according to the state name and the next version of the state;

performing independent filter calculation on the composite state name of the next version to obtain a calculation result;

and comparing the non-existent commitment in the latest block header with the calculation result, and if the comparison result shows that the composite state name does not exist in the global composite state name set, passing the verification.

According to some embodiments, the aforementioned method comprises: the independent filter includes: cuckoo filter.

According to another aspect of the present application, there is provided a node of a blockchain, including:

a recording unit that records a version of a state each time the state is written in a block;

the non-existence commitment generating unit is used for inputting the state name of the writing state and the version into a global filter to obtain a filter result, and recording the filter result in the block as a non-existence commitment;

and a presence acceptance generation unit for calculating the status names and the composite status values of all the writing statuses of the block, using the calculation result as a presence acceptance, and recording the presence acceptance in the block.

According to some embodiments, the aforementioned node comprises:

the non-existent commitment generating unit comprises:

the state set acquisition module is used for acquiring a writing state set of the block;

the current version acquisition module acquires the current version of the writing state according to the version naming rule of the writing state and the previous version;

the composite state name generating module is used for coding the state name of the written state and the current version to generate a composite state name;

the filter calculation module is used for inputting the composite state name into a filter and performing filter calculation to obtain a filter result;

and the composite state name index establishing module is used for establishing a block height-composite state name index for the input composite state name according to the current block height.

According to some embodiments, the aforementioned node comprises:

further comprising a determination unit configured to:

if so, switching the current version of the writing state to the next version;

According to some embodiments, the aforementioned node comprises:

the determination unit is further configured to:

if the version of the write status is the initial version or the write status is the expired status, adding 1 to the total number of elements of the global filter;

According to some embodiments, the aforementioned node comprises:

the presence commitment generating unit includes:

acquiring a write state set of the block;

writing the state name and the composite state value into a state database of a block chain by taking the state name and the composite state value as key values for all the writing states of the block;

and establishing a state tree for all the writing states of the block according to the state name and the composite state value, and calculating a tree root of the state tree as the existence commitment of all the writing states.

According to some embodiments, the aforementioned node comprises:

further comprising a timeliness proving unit configured to:

acquiring a state name;

acquiring the latest version of the state;

obtaining global non-existence commitments of subsequent versions of the state;

According to another aspect of the present application, there is provided a block link point comprising:

a state name acquisition unit for acquiring a state name;

an acquire version unit for acquiring the latest version of the state;

the device comprises an acquiring and non-existence commitment unit, a judging unit and a judging unit, wherein the acquiring and non-existence commitment unit is used for acquiring the non-existence commitment of a subsequent version of a state in the whole world;

and the timeliness proving unit is used for proving timeliness of the state in the whole situation based on the latest version of the state and the non-existence promise of the subsequent version of the state in the whole situation.

According to some embodiments, the aforementioned node comprises:

the timeliness proving unit includes:

acquiring a block head module, acquiring a block head written in the state for the last time and acquiring a block head with the latest height according to the specified state name;

the state tree obtaining module is used for obtaining a state tree corresponding to the block written with the state for the last time;

the existence certification calculation module is used for calculating and obtaining a Merkel path or a Wokel path of the specified state name in the state tree as the existence certification of the state according to the specified state name and the state tree;

the composite state name calculating module is used for calculating the composite state name of the subsequent version of the state according to the state name and the version naming rule of the state;

the filter calculation module is used for performing independent filter calculation on the composite state name and comparing the composite state name with the non-existence commitment of the state contained in the block header with the latest height to obtain a comparison result;

and the state certification generation module generates a state certification according to the existence certification of the state and the comparison result.

According to some embodiments, the aforementioned node comprises:

the acquisition block head module is configured to:

According to some embodiments, the aforementioned node comprises:

the generate state attestation module is configured to:

if the state is not expired, judging whether the composite state name of the subsequent version of the state is misjudged to exist or not;

if the judgment is wrong, calling a state updating contract, and switching the current version of the state to the next version;

generating a new composite state value according to the new version of the state;

generating a state certificate according to the block head, the state name and the new composite state value of the new block containing the state update;

an acquisition state proving unit that acquires a state proof of a specified state;

an acquisition block head unit which acquires a block head and a latest block head of a block corresponding to the specified state from the state certificate;

a verification block header unit, configured to verify validity of the block header and the latest block header of the corresponding block, so as to verify that the block header contains an existence promise, an absence promise, and an expired block height that have not been tampered or forged;

a verify presence commitment unit for verifying a presence commitment;

and the verification non-existence commitment unit is used for verifying the non-existence commitment.

According to some embodiments, the aforementioned node comprises:

the verify presence commitment unit is configured to:

According to some embodiments, the aforementioned node comprises:

the verification non-existence commitment unit is configured to:

if the verification is passed, extracting the non-existence promise of the state from the latest block header so as to verify that the block corresponding to the specified state is the block written in the specified state for the last time;

According to another aspect of the present application, there is provided an electronic device including:

a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method of any of the above methods when executing the computer program.

According to the embodiment of the application, the state tree is organized by taking the block as a unit, the scale of the state tree is small, the cost for calculating the state evidence is greatly reduced, and the length of the state evidence data is shortened.

According to the embodiment of the application, the cuckoo filter is combined with the state version naming rule to achieve the state nonexistence proof, and the problem of timeliness deception caused by 'the nonexistence of the latest state' of the existing scheme is solved.

According to the embodiment of the application, the adopted cuckoo filter has excellent performance under mass data, and compared with the proven calculation of the Wolk tree in the existing scheme, the method can support high-efficiency block output with extremely low calculation cost.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below.

Fig. 1 is a flowchart illustrating a method for generating a block status commitment according to an example embodiment of the present application.

Fig. 2 shows a flowchart of a method of generating a block status attestation according to an example embodiment of the present application.

Fig. 3 shows a flowchart of a method of verifying block status attestation according to an example embodiment of the present application.

Fig. 4 shows a schematic diagram of a node of a blockchain according to an example embodiment of the present application.

Fig. 5 shows a schematic diagram of a node of a blockchain according to another example embodiment of the present application.

Fig. 6 shows a schematic diagram of a node of a blockchain according to another example embodiment of the present application.

Fig. 7 illustrates a block data structure diagram according to an example embodiment of the present application.

Fig. 8 illustrates a status presence commitment and attestation diagram according to an example embodiment of the present application.

Fig. 9 illustrates a block-height composite state name index diagram according to an example embodiment of the present application.

Fig. 10 illustrates an immaterial commitment generation diagram according to an example embodiment of the present application.

Fig. 11 illustrates a generate status commitment flow diagram according to an example embodiment of the present application.

FIG. 12 illustrates a generate state attestation flow diagram, according to an example embodiment of the present application.

FIG. 13 illustrates a verify block status attestation flow diagram in accordance with an example embodiment of the present application.

FIG. 14 shows a block diagram of an electronic device according to an example embodiment.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flowcharts shown in the figures are illustrative only and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below may be termed a second component without departing from the teachings of the present concepts. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

It should be understood by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or flowchart illustrations in the drawings are not necessarily required to practice the present application and, therefore, should not be considered to limit the scope of the present application.

The application provides a verification of existence of the latest version of the state in a block, and the existence and timeliness of the state in the whole are verified by combining the verification of the absence of subsequent versions of the state in the whole. At each state writing, recording the state version and calculating the global cuckoo filter result of the state + version (the continuous writing of the state adopts the predictable state + version naming rule), including the existence commitment of all writing states of the block in the block, and including the cuckoo filter result of all non-outdated writing state + version of all blocks in the block.

When the state certification is issued, all nodes issue the following state names: a. the last time the block header of the state is written, wherein the block header comprises the existence promise of the state and the written version; b. the block header of the latest height, which contains the cuckoo filter results for all non-outdated write state + versions, may prove the global immaterial of subsequent versions of that state. The combination of the two proves the existence and the timeliness of the state.

Before describing the technical solution of the present application in detail, the term convention used in the present application is first introduced as follows:

hash algorithms, also commonly referred to as fingerprint (fingerprint) or digest (digest) algorithms, are a very basic and important class of algorithms. Binary plaintext data of arbitrary length can be mapped to shorter (usually fixed length) binary data (Hash value), and different plaintext is difficult to map to the same Hash value.

Signing: the signature in the application comprises an account identifier and a digital signature, wherein the digital signature is realized by using the technology in the field of public key encryption and is used for identifying digital information; the account identification is used for extracting the public key of the signer from the associated transaction so as to verify the digital signature of the signer;

signature transaction: structured data containing the signature of the transaction initiator represents the authorized behavior of the signer, and the called contract name, contract method and calling parameters are specified in the signature transaction.

All nodes: in the block chain networking, the networking nodes which are synchronous and have all block data and global states are responsible for carrying out consensus on the existence commitment and the non-existence commitment of the states in the block headers and providing state proofs for the light nodes.

And (3) light node: the method is a networking node without block data and state data, can communicate with all nodes, has the state tree calculation realization consistent with all nodes and the independent filter realization consistent with all nodes, and is responsible for verifying the state certification provided by all nodes in the application.

World State (World State): the external state of the block chain account book, referred to as the state for short, and all the states constitute the global state of the block chain. The contract container context interface provides a read-write state interface and supports reading and writing state key value pairs to the key-value database;

and (3) state certification: a proof that includes both presence and time-sensitive, presence proof to verify that the specified state name + state value exists in the global state of the blockchain; since the same state name can be written with different values multiple times, timeliness proves that the state value used to verify a specified state name was written last.

And (3) state commitment: the binary data contained in the block header is divided into a presence commitment of state and a non-presence commitment of state. The presence commitment of state is used to verify the presence of the specified state name and state value within the block in which the block header is located; the imminence commitment of state is used to verify the global imminence of a specified version of a specified state name before the block in which the block header is located.

Merkel tree (Merkle tree): also known as a hash tree (hash tree), is a tree data structure in cryptography and computer science, in which each leaf node is tagged with the hash of a data block, and nodes other than the leaf node are tagged with the encrypted hashes of their child node tags. The mekerr tree can efficiently and securely verify the contents of large data structures. For example, in a binary tree, the top node is called the root of the merkel tree (Merkle tree).

Merkel proof (Merkle proofs): a mekerr proof contains a block, the root hash of the mekerr tree in which the block resides, and all "branches" along the block to root path hashes. The verifier calculates the hash step by step along the provided branch path until the root of the Meckel tree is calculated, compares the root with the root of the credible Meckel tree, and if the root is consistent with the root, the content of the data block can be proved to be credible.

Wacker tree (VerkleTree): in the model firstly proposed by Kuszmaul in the 2018 paper, the vector Hash is adopted to replace the single-value Hash of the Meckel tree, and compared with the Meckel tree, sister nodes do not need to be provided, so that the size of the certification data is shortened. The cost is that the computation to generate the proof is more complex.

Cuckoo filter: (English: cuckoo Filter) is described in the paper "Cuckoo Filter: an improvement to the Bloom filter proposed in Better Than Bloom supports the deletion of non-repeating elements, and the calculation results occupy less Than 40% of the latter below a 3% false positive rate.

The application provides a method for generating block state commitment and certification and verifying block state certification, so that a light node without block data and state data can verify existence and timeliness of a block chain state.

When the all-node is in block identification, the block head contains the existence promise of the composite state consisting of the state name, the writing version, the state value and the block height of all writing states of the block, and the block head contains the non-existence promise of the composite state consisting of the state name and the writing version of all writing states of the block.

And the full node provides state identification according to the state name specified by the light node, wherein the state identification comprises a block head of a block which is written into the state last, a written composite state value, the existence identification of the state and a block head of a block with the latest height.

The light node can verify the existence of the composite state value in the block according to the state existence promise and the corresponding state existence proof contained in the block header written into the state at last, can calculate the composite state name of the next version of the state according to the state version information contained in the composite state value and the set naming rule of the state version, and can determine that the next version of the state is not written in the global non-overdue state by performing cuckoo filter calculation on the composite state name of the next version according to the state non-existence promise contained in the block header with the latest height, thereby judging that the written composite state value is the latest version.

Exemplary embodiments of the present application will be described below with reference to the accompanying drawings.

The status commitment is a data item contained in the chunk header, including a presence commitment of status and an absence commitment of status.

And generating the state commitment and block output synchronously, wherein in the block output consensus process, all the nodes participating in consensus respectively calculate the state commitment locally and carry out consensus on the state commitment, and after the block output is disclosed, the block validity is verified to ensure that the state commitment cannot be modified or forged. The step of generating the status commitment is as follows.

Referring to fig. 1, in S101, each time a state is written in a block, a version of the state and a composite state value are recorded.

According to some embodiments, a sequence of signature transactions of blocks is performed sequentially, obtaining a set of write states.

And aiming at each writing state of the block, encoding the original value of the writing state, the current version of the state and the height of the block where the writing state is positioned to generate a composite state value.

And writing all the written states of the block into a state database of the block chain by taking the state name and the composite state value as key-value pairs. The storage of the composite state value utilizes a key-value database carried by a block chain system to bear state version and block height information, and the engineering implementation cost is low.

According to some embodiments, the composite status value data format and version naming rules are as follows:

according to some embodiments, the composite state name data format is as follows:

at S103, the state and the version of the state are input into a global filter to obtain a filter result, and the filter result is recorded in the block as an absence commitment.

And aiming at each writing state of the block, obtaining a current version according to a last version and a version naming rule, and coding the state name of the writing state and the current version to form a composite state name of the current version.

According to some embodiments, the writing state is version-managed, the version name adopts a computable naming rule, the next version name can be calculated according to the current version name, and so on. The version rule is to prove the timeliness of the state, and the absence of the next version of the state proves that the current version is the latest version.

For each write state of the block, the state name of the write state + the next version name are encoded to form a next version composite state name, an independent filter calculation is performed on the next version composite state name, such as a cuckoo filter (other types of filters or accumulators supporting element removal and non-member certification can be used, and the cuckoo filter is used as an example in the following description), the calculation result is compared with the last block head state absence commitment, and whether the next version composite state name is judged to be present by mistake is determined.

If so, switching the current version of the writing state to the next version, and repeating the steps until all the writing states of the block have no misjudgment. And obtaining the current version of each writing state of the block. And inputting the composite state name of each current version of the writing state into a global filter for calculation, and superposing the calculation result to the status non-existence commitment of the previous block header to form the status non-existence commitment of the block header. This step can eliminate the composite state name of miscarriage of cuckoo filter caused by the forward block of the block.

And establishing a block height-composite state name index for the input composite state names according to the current block height, and acquiring all composite state names and the writing sequence thereof under the specified block height through the index. Specifically, the structure and establishment of the block height-composite state name index can refer to the block height-composite state name index diagram shown in fig. 9.

Wherein the block contains all non-stale write status unavailability commitments for all blocks. The calculation cost of the cuckoo filter in the global non-overdue state is far lower than the cost of maintaining the global state tree and calculating the root of the state tree, so that the method can be applied to large-scale state data. For example, the process of generating an unavailability commitment through a cuckoo filter may refer to the embodiment shown in fig. 10.

And deleting the last written version composite state name from the global filter, updating the block height-composite state name index, and deleting the last written composite state name from the block height-composite state name index, so that the increase of the false judgment rate of the cuckoo filter caused by repeated writing in the same state is avoided. For the cuckoo filter, on the premise of a certain misjudgment rate, the more elements are contained, the longer the calculation result data is, and therefore, the element size needs to be restricted to a stable size.

If the version of the write status is the initial version, or the status of the write is the expired status (i.e., the write status version is not the initial version and the last written version of the write status is at a block height that is not greater than the expired block height), add 1 to the total number of elements of the global filter.

And if the total number of elements of the global filter exceeds a preset upper limit, deleting 1 earliest written composite state name from the global filter according to the block height-composite state name index, updating the block height-composite state name index, and deleting 1 earliest written composite state name from the block height-composite state name index.

The oldest written state is found from the above index, in ascending block height order, to find the head element of the first list that is not empty.

The state expiration is determined by a preset global filter element total limit, and as the global filter accommodates elements that increase, a state expiration mechanism is triggered when the total limit is exceeded. Each time a new element is added thereafter, the oldest written element managed by the index above must be removed. The removed state is referred to as an expired state.

The stale chunk height is recorded in a global variable of the full node, updated each time an element is removed. If the list is not empty after the element is removed, the block height corresponding to the list is still kept as the expired block height; if the list is empty after the element is removed, then it is necessary to find the next block height for which the list is not empty as the expired block height in ascending order along the block height.

The purpose of maintaining the stale block height is: since the global filter has a limited capacity and cannot really save the written state of all blocks, it is necessary to know when generating the proof: the current global filter maintains a written state from which chunk height (the next chunk of an expired chunk height) until the latest chunk height, and if not in this interval, the global filter does not prove to be non-existent and needs to enable a state update contract to activate the state.

The stale chunk height is written to the chunk header, participating in the consensus, so that the verification stage can reach the chunk interval where the global filter can prove the imminence.

When writing status, a list is established for the corresponding block height. There are two possible reasons for an empty list for a certain block height: the block has no status written to; this block is originally written with state, but all written state is overwritten by the new version state of the subsequent block (old version deleted from the index list).

At S105, a composite status value of all writing statuses of the block is calculated, and the calculation result is used as a presence commitment.

According to some embodiments, for all written states of the block, a presence commitment of the state is computed from the state name + the composite state value. The Merkel or Watcher proof can be adopted to maintain the state tree by taking the block as a unit, namely the Merkel or Watcher tree, so that the state tree is still maintained in a relatively stable small scale when the state is expanded, and the calculation cost of the existence commitment and the data length of the existence proof are greatly reduced. For example, the process of calculating a presence commitment is exemplified in the manner described below with reference to FIG. 11.

At S107, the presence commitment is recorded in a block.

According to some embodiments, stale obsolete chunk height, absence commitments and presence commitments for status are written to the chunk header, participate in the chunk Hash value (Hash) calculation with other chunk data items, and co-identify chunks to prevent commitments from being forged.

The block head is contained in the block, and the confirmation according to the consensus algorithm is carried out on all the consensus nodes of the block chain, and the commitment is placed in the block head so as to prevent the block head from being tampered or forged.

According to some embodiments, the Block (Block) is composed of a Block header (Block header) and a Block body (Block body), wherein the Block header contains a Block height, a Block hash value, a previous Block hash value, a presence acceptance of a local Block write status, an absence acceptance of a global non-stale write status, a stale Block height, and a Block validity certificate. The block validity proof is determined by the consensus algorithm used by the blockchain, which may be a workload proof, a rights proof, or a signature endorsement of the consensus node to the block. Referring to fig. 7, a block data structure diagram according to an example embodiment of the present application is shown.

The generation of the state attestation may occur at any time after the block is out of the block, and the step of generating the state attestation is as follows.

Referring to fig. 2, in S201, a status name is acquired.

According to some embodiments, the light nodes specify a state name sn, requiring that the full nodes provide a state attestation.

At S203, the latest version of the state is acquired.

According to some embodiments, the full node reads the composite state value sn-cv from the key-value database according to the original state name, decodes the composite state value, and obtains the block height sn-cvh, state version sn-cvv, and original state value sn-v that were written into the state last; and acquiring the block head bhs written into the state for the last time according to the block height sn-cvh.

At S205, a global absence commitment of subsequent versions of the state is obtained.

According to some embodiments, the full node obtains the block header bhs of the block last written in the specified state according to the block height.

The full node obtains the latest block header bhl according to the latest block height.

And calculating the composite state name of the subsequent version according to the version naming rule of the state, performing cuckoo filter calculation on the composite state name, and comparing the composite state name with the non-existent commitment contained in the latest block header until a version number sn-cvv' without the misjudgment of the cuckoo filter is found.

At S207, the timeliness of the state in the global is demonstrated based on the latest version of the state, and the absence commitment of subsequent versions of the state in the global.

According to some embodiments, attesting to the existence of a state comprises:

the full node first obtains the latest composite state value from the block chain state database according to the state name.

By decoding the composite state value, the block height of the last write to the state is obtained, and a corresponding block header is obtained based on the block height, the block header containing the state presence commitment (e.g., using the Merkel certificate to generate the root of the Merkel tree).

All nodes generate state existence proofs according to the Merkel path of the specified state in the block state tree.

The full node sends the state name, composite state value, block header, and state presence credentials to the light node.

According to some embodiments, a filter calculation is performed on the composite state name and compared to the absence commitment of state contained in the block header of the latest height, and a state attestation is generated based on the comparison.

In the comparison process, it is necessary to determine whether the state is expired first, and then determine whether the composite state name of the subsequent version of the state is determined to be present by mistake. Firstly, judging that if the block height of the last time of writing the state is not more than the height of an overdue block, the state is overdue, calling a state updating contract, and switching the current version of the state to the next version as the new version of the state. If the state is not expired, it is determined whether a composite state name of a subsequent version of the state is misjudged to have existed.

If misjudgment exists, the whole node calls a state updating contract through signature transaction, and the current version of the state is switched to the next version. And generating a state certificate according to the block head, the state name and the new composite state value of the newly-out block containing the state updating transaction.

Since there is no proof that only the past due block height to the latest block height can be proved, a new version of the state does not exist. For the state that the last write was before the expired block height (the expired state), a call to the state update contract reactivation is required. After this operation, the stale status is written to the newest block with the new version.

The filter misjudges and the state is not in the interval which can be proved by the filter (namely, the state is overdue), the filter is invalid due to the two conditions, and the two conditions are solved by calling a state updating contract.

If no misjudgment is found in the steps or the state is overdue, the full node integrates sn, sn-cv, bhs and bhl, generates a state certificate sn-proof and sends the state certificate sn-proof to the light node.

If the steps show misjudgment, the full node calls a state version updating contract through signature transaction, and generates a new version of composite state value sn-cv 'by using sn + sn-cvv' + current block height coding, so as to update the state version.

The block headers bhl ', sn-cv' of the new block containing the signature transaction are used as the state certificate sn _ proof 'to be sent to the light node, and since bhl' is the latest block, the timeliness certificate is no longer needed, and the above steps can eliminate the miscoording of the cuckoo filter caused by writing the state into the backward block of the block.

According to some embodiments, a state update contract is deployed on the blockchain, allowing all nodes to write state with the same state name, state value through signature transactions, resulting in state being written in higher versions in the new block. The contract is used for processing misjudgment of a cuckoo filter caused by the overdue state or the writing state contained in the backward block, the state to be proved is written into the latest height block to ensure the timeliness of the block, and the existence of the state can be directly proved in the latest block. For example, the process of generating a state attestation is illustrated in the manner described below with reference to FIG. 12.

After the light node has obtained the attestation sn-proof of the specified state sn, the following verify state steps are performed.

Referring to fig. 3, at S301, a state attestation of the specified state is obtained.

The light node obtains an attestation sn-proof of a specified state sn from the full node.

At S303, the current block header and the latest block header are acquired from the status certification.

The block header bhs, bhl is obtained from the state certificate sn-proof.

At S305, the validity of the current and latest block headers is verified to verify that the presence commitment and the non-presence commitment contained in the block headers have not been tampered or forged.

According to some embodiments, the validity of the block headers bhs and bhl is verified, and block validity verification rules, such as a POW verification workload certificate, a POS verification right certificate, etc., are determined according to different consensus algorithms, so as to verify that the block headers contain an existence commitment, an absence commitment, and an expired block height that are not tampered or forged.

At S307, the presence commitment is verified.

The state name and the composite state value are obtained from the state attestation.

The existence promise of the state is extracted from the block header, and the state name and the composite state value are verified to exist in the writing state set of the block by adopting a Meckel tree or Wolk tree method for calculation. Specifically, the existence promise of the state is extracted from the current block header bhs, and whether sn + sn-cv exists in the write state set of the block is verified.

At S309, the non-existent commitment is verified.

And extracting the height of the expired block from the newest block header, and if the height of the expired block is not less than the height of the block written in the specified state last time, the verification is not passed.

If the verification is passed, the non-existence promise of the status is extracted from the latest block header so as to verify that the block in which the current block header is located is the block in the last write-specified status.

And extracting a state version from the composite state value, and acquiring the next version of the state according to the state version and the version naming rule. And generating a composite state name of the next version according to the state name and the next version of the state, and performing filter calculation on the composite state name of the next version to obtain a calculation result.

And comparing the non-existent commitment in the latest block header with the calculation result, and if the comparison result shows that the composite state name does not exist in the global composite state name set, the verification is passed. For example, the process of verifying the block status attestation is exemplified in the manner described below with reference to fig. 13.

According to some embodiments, a block link point comprises: recording section 401, non-existence promise generating section 402, and existence promise generating section 403.

The recording unit 401 records a version of a state and a composite state value each time the state is written in a block.

The non-existent commitment generating unit 402 inputs the state and the version of the state into a global filter to obtain a filter result, and records the filter result in the block as a non-existent commitment.

According to some embodiments, the absence commitment generating unit 402 comprises:

and the state set acquisition module acquires the writing state set of the block.

And the current version acquiring module acquires the current version of the state according to the version naming rule of the state and the previous version.

And the composite state name generating module is used for encoding the state name and the current version of the written state to generate the composite state name.

And the filter calculation module is used for inputting the composite state name into the global filter and performing filter calculation to obtain a filter result.

The presence commitment generating unit 403 calculates a composite status value of all writing statuses of the block, takes the calculation result as a presence commitment, and records the presence commitment in the block.

According to some embodiments, the presence commitment generation unit comprises:

acquiring a writing state set of the block;

the presence commitment for the state is calculated from the state name and the composite state value.

According to some embodiments, further comprising a determination unit 404, the determination unit 404 configured to:

and acquiring the next version of the state according to the current version of the state and the version naming rule.

And coding according to the state name of the written state and the next version to generate a composite state name of the next version.

And performing independent filter calculation on the composite state name of the next version, comparing the calculation result with the non-existence commitment, and judging whether the composite state name of the next version is judged to exist by mistake.

If so, the current version of the write state is switched to the next version.

Repeating the above steps until current versions of all write states of the block are obtained.

According to some embodiments, the determining unit 404 is further configured to:

the last written version of the written state composite state name is deleted from the global filter and the block height-composite state name index is updated.

If the version of the write state is the initial version or the state of the write is the stale state, the total number of elements of the global filter is incremented by 1.

If the total number of elements of the global filter exceeds a preset upper limit, deleting 1 earliest written composite state name from the global filter according to the block height-composite state name index, and updating the block height-composite state name index.

According to some embodiments, further comprising a timeliness proving unit 405, the timeliness proving unit 405 configured to:

the state name is obtained.

The latest version of the state is obtained.

A global absence commitment of subsequent versions of the state is obtained.

The timeliness of the state in the global is justified based on the latest version of the state, and the absence commitment of subsequent versions of the state in the global.

According to some embodiments, a block link point comprises: a status name acquiring unit 501, a version acquiring unit 502, an absence commitment acquiring unit 503 and a timeliness proving unit 504.

A get status name unit 501 for getting the status name.

A get version unit 502 for getting the latest version of the state.

An obtain-unavailability commitment unit 503, configured to obtain an unavailability commitment that a subsequent version of the state is globally present.

The timeliness certification unit 504 certifies timeliness of a state in global based on the latest version of the state and the subsequent version of the state's absence commitment in global.

According to some embodiments, the timeliness certification unit 504 includes:

and acquiring a block head module, acquiring a block head which is written in the state for the last time and acquiring a block head with the latest height according to the specified state name.

According to some embodiments, the composite state value is read from the key value database according to the specified state name, the composite state value is decoded to obtain the original value of the state, the current version of the state and the height of the block where the state is located, and the block header written into the state at the last time is obtained according to the height of the block where the state is located.

And the composite state name calculating module is used for calculating the composite state name of the subsequent version of the state according to the version naming rule of the state.

And the filter calculation module is used for performing filter calculation on the composite state name and comparing the composite state name with the non-existence commitment of the state contained in the block header with the latest height.

And the state certification generation module generates a state certification according to the comparison result.

According to some embodiments, determining that the state is expired if the block height of the last written state is not greater than the expired block height, invoking a state update version, and switching the current version of the state to a next version as the new version of the state.

If the state is not expired, it is determined whether a composite state name of a subsequent version of the state is misjudged to have existed. If misjudgment exists, the whole node calls a state updating contract through signature transaction, and the current version of the state is switched to the next version. And generating a state certificate according to the block head, the state name and the new composite state value of the newly-out block containing the state updating transaction.

And generating a new composite state value according to the new version of the state, and generating a state certificate according to the block head, the state name and the new composite state value of the newly-out block containing the state update transaction.

And if no misjudgment or overdue state is found, generating a state certificate according to the state name, the composite state value, the block head written into the state for the last time and the block head with the latest height.

According to some embodiments, a block link point comprises: an acquiring status proving unit 601, an acquiring block header unit 602, a verifying block header unit 603, a verifying existence acceptance unit 604, and a verifying non-existence acceptance unit 605.

The acquisition state certification unit 601 acquires state certification of a specified state.

An acquire block header unit 602 acquires the current block header and the latest block header from the status certificate.

The verification block header unit 603 is used for verifying the validity of the current block header and the latest block header to verify that the block headers include the presence promise, the absence promise, and the height of the expired block are not tampered or forged.

A verify presence commitment unit 604 for verifying presence commitments.

A verify non-existence commitment unit 605 for verifying a non-existence commitment.

According to some embodiments, the verify presence commitment package unit 604 is configured to:

a state name, a composite state value, and a presence credential for the state are obtained from the state credential.

The existence promise of the state is extracted from the current block header, and the state name and the composite state value are verified to exist in the writing state set of the block by adopting a Meckel tree or Wolk tree method for calculation.

According to some embodiments, the verification of absence commitment unit 605 is configured to:

If the verification is passed, the non-existence promise of the status is extracted from the latest block header so as to verify that the block in which the current block header is located is the block in the last write-specified status. And extracting a state version from the composite state value, and acquiring the next version of the state according to the state version and a version naming rule.

And generating a composite state name of the next version according to the state name and the next version of the state. And carrying out independent filter calculation on the composite state name of the next version to obtain a calculation result.

According to some embodiments, the presence commitment of the state may be a meikel tree or a wakel tree, and the meikel tree is taken as an example to generate the presence commitment of the block writing state, as shown in fig. 8, the writing state set with a certain block height (e.g. 100) is obtained through the above steps, the hash value is obtained from the state name + state composite value, then the hash values are obtained by combining layer by layer, and a meikel root Habcdefgh is obtained, and the meikel root, i.e. the presence commitment of the block writing state, is stored at the head of the block as the "presence commitment of the block writing state".

Fig. 9 illustrates an immaterial commitment generation diagram according to an example embodiment of the present application.

According to some embodiments, the immaterial commitment of a state, namely the cuckoo filter computation result bloom _ gn of the composite state name set gn (state name + version number) of the global state. The result is a sequence of binary bits, each composite state name is subjected to cuckoo filter calculations, and some of them are positioned 1 according to the calculation results.

For an input composite state name sn, whether the composite state name sn exists in a composite state name set of a global state or not needs to be judged, the same cuckoo filter calculation is only needed to be carried out on the composite state name sn to obtain a result bloom _ sn, and then the result bloom _ sn is compared with an absence commitment of the state, if all bits of the bloom _ sn are set to be 1, the corresponding bit of the bloom _ gn is 1, which indicates that sn has a very high probability to exist in gn, and if all the bits of the bloom _ sn are set to be 1, at least 1 bit of the corresponding bit of the bloom _ gn is not 1, which indicates that sn does not exist in gn.

Fig. 10 illustrates a block height composite state name index according to an exemplary embodiment of the present application, when a composite state name is input to a global filter, an index pointing to the composite state name from a block height is established according to the block height of a block in which a write state is located, a data structure of the index is an array using the block height as a subscript, an array element is a list type supporting tail addition, head removal, and middle removal, and a list element is the composite state name input to the global filter. The following operations may be supported by the index:

adding elements: when the composite state name is input into the global filter, a list corresponding to the block height is found according to the block height of the block where the state is located, and the composite state name is added to the tail of the list;

deleting the specified element: when the composite state name is deleted from the global filter, a list corresponding to the block height is found according to the block height of the state, and the composite state name is removed from the list;

deleting the head element: and finding a list corresponding to the block height according to the block height of the block in which the state is positioned, and removing the head element from the list.

Fig. 11 illustrates a flow diagram for generating a status commitment according to an example embodiment of the present application.

And aiming at each writing state of the block, coding the state name of the writing state plus the current version name according to the last version number and the current version of the version naming rule to form a current version composite state name.

And aiming at each writing state of the block, coding the state name of the writing state and the next version name to form a next version composite state name, performing cuckoo filter calculation on the next version composite state name, comparing the calculation result with the state non-existence commitment, and judging whether the next version composite state name is judged to exist by mistake.

If so, switching the current version of the writing state to the next version, and repeating the steps until all the writing states of the block have no misjudgment. And obtaining the current version of each writing state of the block. And removing the composite state name of the last written version of each writing state of the block from the global filter, inputting the composite state name of the current version of each writing state into the global filter, and overlapping the calculation result to the non-existence commitment of the last block to generate the non-existence commitment of the cost block.

And writing the state name and the composite state value into a state database of the block chain as a key-value pair for all the written states of the block, and calculating the existence commitment of the state according to the state name and the composite state value.

The absence commitment and the presence commitment of the status are written into a block header, participate in block Hash value (Hash) calculation together with other block data items, and identify the block.

According to some embodiments, a state version sn-cvv is decoded and extracted from a composite state name sn-cv, and a composite name sn-next for a next version of the state is computed from the state name sn and the state version and from version naming rules.

And extracting an absence commitment in a latest block header bhl, performing a cuckoo filter calculation on the sn-next, and verifying whether the sn-next exists in a non-outdated writing state set of the global filter. If not, the status sn is written by the last time after the expired block height of all blocks before bhl, which indicates that the block where the bhs is located is the latest status value.

The immaterial commitment of a state, namely the cuckoo filter computation result bloom _ gn of the composite state name set gn (state name + version number) of the global state. The result is a sequence of binary bits, each composite state name is subjected to cuckoo filter calculations, and some of them are positioned 1 according to the calculation results.

For an input composite state name sn, whether the input composite state name sn exists in a composite state name set of a global state or not needs to be calculated only by performing the same cuckoo filter calculation on the input composite state name sn, wherein the single filter calculation is adopted, the single filter and the global filter are the same program, the same algorithm is to perform multiple hash calculation on input elements, and the corresponding bit is set to be 1 according to the result. The difference is that the global filter means: the result is a superposition of all non-outdated composite state name input computation results globally. And the individual filters are the result of calculations on one composite state name input.

And obtaining the result bloom _ sn of the individual filter, and then comparing the result bloom _ sn with the non-existent commitment of the state, namely the result bloom _ gn of the global filter, wherein if all the bits of the bloom _ sn are set to be 1, the corresponding bit of the bloom _ gn is 1, which indicates that the composite state name sn has a great probability of existing in the composite state name set gn of the global state, and if all the bits of the bloom _ sn are set to be 1, at least 1 bit of the corresponding bit of the bloom _ gn is not 1, which indicates that the sn does not exist in gn.

According to some embodiments, after the light node has obtained the attestation sn-proof of the specified state sn, the following verify state steps are performed:

the light node firstly verifies the validity of the block header and ensures that the existence commitment and the non-existence commitment of the state are not tampered.

And the light node calculates the hash value of the state name and the composite state value to obtain whether the composite state value is consistent or not through comparison.

And the light node calculates the root of the Merkel tree according to the state existence proof, and compares whether the root of the Merkel tree is consistent with the state existence promise in the block header.

The existence promise of the state is extracted from the block header bhs of the written state, and whether sn + sn-cv exists in the written state set of the block is verified. And decoding and extracting the state version sn-cvv from the sn-cv, and calculating the composite state name sn-cv-next of the next version of the state according to the state name sn and the state version and version naming rules.

And extracting an existential commitment in a latest block header bhl, performing a cuckoo filter calculation on the sn-cv-next, and verifying whether the sn-cv-next exists in a write state set of the global filter. If not, the status sn is written by the last time after the expired block height of all blocks before bhl, which indicates that the block where the bhs is located is the latest status value.

It should be clearly understood that this application describes how to make and use particular examples, but the application is not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. When the computer program is executed by the CPU, the program for executing the above-mentioned functions defined by the above-mentioned methods provided in the present application may be stored in a computer-readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the present application and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

As will be readily appreciated by those of ordinary skill in the art from the description of the example embodiments, the method of generating a block status commitment and certification and verifying a block status certification according to embodiments of the present application may have at least one or more of the following advantages.

According to an exemplary embodiment, by organizing the state tree in units of blocks according to an exemplary embodiment of the present application, the size of the state tree is small, the cost for calculating the state proof is greatly reduced, and the length of the state proof data is shortened.

According to the embodiment, the cuckoo filter is combined with the state version naming rule to realize the absence certification of the state, and the problem of timeliness deception caused by the absence of the latest state of the existing scheme is solved.

According to an example embodiment, the adopted cuckoo filter has excellent performance under mass data, and compared with the proven calculation of the Wolk tree of the existing scheme, the method can support efficient block output at extremely low calculation cost.

An electronic apparatus 200 according to this embodiment of the present application is described below with reference to fig. 14. The electronic device 200 shown in fig. 14 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 14, the electronic device 200 is in the form of a general purpose computing device. The components of the electronic device 200 may include, but are not limited to: at least one processing unit 210, at least one memory unit 220, a bus 230 connecting different system components (including the memory unit 220 and the processing unit 210), a display unit 240, and the like.

Wherein the storage unit stores program code that can be executed by the processing unit 210 such that the processing unit 210 performs the methods according to various exemplary embodiments of the present application described herein.

The storage unit 220 may include readable media in the form of volatile storage units, such as a random access memory unit (RAM) 2201 and/or a cache memory unit 2202, and may further include a read only memory unit (ROM) 2203.

The storage unit 220 may also include a program/utility 2204 having a set (at least one) of program modules 2205, such program modules 2205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination thereof may comprise an implementation of a network environment.

Bus 230 may be any bus representing one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 200 may also communicate with one or more external devices 300 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 200, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 200 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 250. Also, the electronic device 200 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the Internet) via the network adapter 260. The network adapter 260 may communicate with other modules of the electronic device 200 via the bus 230. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. The technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiments of the present application.

The software product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable storage medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable storage medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

Those skilled in the art will appreciate that the modules described above may be distributed in the apparatus as described in the embodiments, and that corresponding changes may be made in one or more apparatus that are unique from the embodiments. The modules of the above embodiments may be combined into one module, or further split into multiple sub-modules.

Exemplary embodiments of the present application are specifically illustrated and described above. It is to be understood that the application is not limited to the details of construction, arrangement or method of operation set forth herein; on the contrary, the application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method of generating a block status attestation, comprising:

acquiring a state name, wherein the light node specifies the state name and requires the whole node to provide state certification;

acquiring the latest version of the state;

obtaining global non-existence commitments of subsequent versions of the state;

certifying timeliness of a state in a global context based on a latest version of the state and an absence commitment of subsequent versions of the state in the global context, comprising:

acquiring a block head with the latest height;

according to the specified state name and the state tree, calculating to obtain a Merkel path or a Vockel path of the specified state name in the state tree as a state existence certificate;

generating a state certificate according to the existence certificate of the state and the comparison result, wherein the state certificate comprises:

if the judgment is wrong, the whole node calls a state updating contract through signature transaction, and the current version of the state is switched to the next version;

if no misjudgment or overdue state is found, generating a state certificate according to the state name, the composite state value, the block head written in the state for the last time and the block head with the latest height, and sending the state certificate to the light node by the full node.

2. The method of claim 1, wherein obtaining the block header last written to the status comprises:

decoding the composite state value to obtain an original value of the state, a current version of the state and the height of the block;

3. The method of claim 2, wherein the stand-alone filter comprises: cuckoo filter.

4. A block link point, comprising:

the state name acquisition unit is used for acquiring a state name, appointing the state name by the light node and requiring the whole node to provide state certification;

an acquire version unit for acquiring the latest version of the state;

the device comprises an obtaining and non-existence commitment unit, a judging unit and a judging unit, wherein the obtaining and non-existence commitment unit is used for obtaining the non-existence commitment of a subsequent version of a state in the whole world;

the timeliness proving unit is used for proving the timeliness of the state in the whole situation based on the latest version of the state and the non-existent promise of the subsequent version of the state in the whole situation; the timeliness proving unit includes:

acquiring a block head module, acquiring a block head which is written in the state for the last time and acquiring a block head with the latest height according to the specified state name;

the composite state name calculating module is used for calculating a composite state name of a subsequent version of the state according to the state name and the version naming rule of the state;

the filter calculation module is used for performing independent filter calculation on the composite state name and comparing the composite state name with the non-existent commitment of the state contained in the block header with the latest height to obtain a comparison result;

a state generation proof module which generates a state proof according to the existence proof of the state and the comparison result;

the generate state attestation module is configured to:

5. The node of claim 4, wherein the acquisition block head module is configured to:

6. An electronic device, comprising:

memory, processor and computer program stored in the memory and executable on the processor, characterized in that the processor implements the method of any of the preceding claims 1-3 when executing the computer program.

7. A computer readable storage medium having computer readable instructions stored thereon which, when executed by a processor, cause the processor to perform the method of any one of claims 1-3.