CN114691687A

CN114691687A - Method for verifying block state certification

Info

Publication number: CN114691687A
Application number: CN202210322924.8A
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: 2022-07-01
Anticipated expiration: 2041-12-30
Also published as: CN114691686A; CN114003972B; CN114003972A; CN114880320A; CN114880320B; CN114691686B; CN114691687B

Abstract

The application provides a method for verifying block state certification, which comprises the following steps: 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 absence commitment. By organizing the state tree by taking the block as a unit, the state tree is small in scale, and by combining an expiration mechanism of a write-in state, 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 state certification data is shortened.

Description

Method for verifying 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 ether house 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:

firstly, state expiration: 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-50 GB. The limitations of this approach are: a. the data scale of a single MPT tree is reduced in 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 and the certification data length of the state certification 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.

II, weak and stateless: only the block proposer is required to store the state and allow all other nodes to verify the block stateless. In practice, this is accomplished by switching to a Wolkel 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 is that although the proof data length is small, the computational load to generate 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 aims to provide a method for generating block status commitment and certification and verifying 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 block status commitments is provided, which includes:

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;

if so, 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 after deletion is not empty, recording the block height of the state as the height of the expired 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 expired 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 promise in a block, comprising:

acquiring a write 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 calculating through a Meckel tree or a Woker tree to obtain the state tree.

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;

acquiring global non-existence commitment 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 in 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 head written into the state for the last time and the block head 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 promise includes:

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-existent 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-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;

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, the verification is passed.

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 is used for acquiring 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 the 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;

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

According to some embodiments, the aforementioned node comprises:

the determination unit is further configured to:

According to some embodiments, the aforementioned node comprises:

the presence promise generation unit includes:

acquiring a write state set of the block;

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 the timeliness of the state in the global state based on the latest version of the state and the non-existent promise of the subsequent version of the state in the global state.

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 which is written in 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 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 promise unit is used for verifying the non-existence promise.

According to some embodiments, the aforementioned node comprises:

the verify presence commitment unit is configured to:

a presence commitment of state is extracted from a current chunk header, calculated using a Merkel tree or Vorkel tree approach, and a state name and a composite state value are verified as being present in the presence commitment.

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-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;

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 realize the absence certification of the state, and the problem of timeliness deception caused by the fact that the 'latest state does not exist' 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 flow charts shown in the drawings are merely illustrative 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 will be appreciated by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or processes shown in the drawings are not necessarily required to practice the present application and are, therefore, not intended 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 writing state, 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), the block contains the existence promise of all writing states of the block, and the block contains the cuckoo filter results of all non-expired writing states + versions of all blocks.

When the state certification is given, the full node is given as the specified state name: a. the block header of the state is written for the last time, 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.

Signature: 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: the 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 nodes: 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. An interface of a read-write state is provided in a context interface of the contract container, and the read-write of a state key value pair to a key-value database is supported;

and (3) state certification: a proof that includes both presence and time-effectiveness, the 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 a large data structure. For example, in a binary tree, the top node is called the root of the merkel tree (Merkle tree).

Merkel proof (Merkle proofs): a michael proof contains a block, the root hash of the michael tree in which the block resides, and all "branches" of the hash along the block to the root path. The verifier calculates the hash step by step along the provided branch path until the root of the Merkel tree is calculated, compares the root with the root of the credible Merkel 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): the model first proposed by Kuszmaul in the 2018 paper adopts vector Hash to replace single-valued Hash of a meiker tree, and compared with the meiker tree, does not need to provide sister nodes, so that the size of the proving 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 the block-out consensus, the block header contains the existence promise of the composite state consisting of the state name, the written version, the state value and the block height of all the written states of the block, and the block header contains the non-existence promise of the composite state consisting of the state name and the written version of all the written 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 commitment contained in the block header written into the state at last and the existence certification of the corresponding state, 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 given 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 the Cucko filter calculation on the composite state name of the next version according to the state non-existence commitment contained in the block header with the latest height, thereby judging that the written composite state value is the latest version.

The following description of example embodiments of the present application refers 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.

The generation of the state commitment and the block output are carried out synchronously, in the process of block output consensus, all nodes participating in consensus respectively calculate the state commitment locally and carry out consensus on the state commitment, and after the block output consensus, 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 to 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 current version is proved to be the latest version by 'the absence of the next version of the state'.

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

If yes, 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 head to form the status non-existence commitment of the block head. 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 name 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-existent commitments of non-outdated write status 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 composite state name of the last written version from the global filter, updating the block height-composite state name index, and deleting the composite state name of the last written version 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 stale 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 no greater than the stale 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 chunk 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 expired chunk height is written to the chunk header, participating in consensus, so that the verification stage can only reach the chunk interval where the global filter can prove non-existence.

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 a local block, a presence commitment for 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, a 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 commitment of a local Block write status, an absence commitment of a global non-outdated write status, an outdated Block height, a Block legitimacy 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 an endorsement of a signature of a consensus node on a 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 node 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, resulting in the tile height sn-cvh, state version sn-cvv, and original state value sn-v that was last written to the state; the block header bhs that was last written to this state is obtained based on the block heights sn-cvh.

At S205, a global non-existence commitment of a subsequent version of the state is obtained.

According to some embodiments, the full node obtains the block header bhs of the block that was last written to the designated state based on the block height.

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

According to the version naming rule of the state, the compound state name of the subsequent version is calculated, the cuckoo filter calculation is carried out on the compound state name, and the compound state name is compared with the non-existent commitment contained in the latest block header until a version number sn-cvv' which can not be misjudged by the cuckoo filter is found.

At S207, 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, 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).

And generating a state existence certification by all nodes 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, the composite state name is filter calculated and compared to the survivability commitments of states 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 written 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 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. And generating a state certificate according to the block header, the state name and the new composite state value of the new block containing the state updating transaction.

Since there is no proof that only the past to last chunk height can be certified from the past due chunk height, a new version of this state does not exist. For the state that the last write was before the expiration block height (the expired state), a state update contract reactivation needs to be invoked. After this operation, the stale status is written to the newest block in 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 expired), the filter is proved to be invalid by the two conditions, and the two conditions are solved by calling the 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 find misjudgment, the full node calls a state version updating contract through signature transaction, and a new version of the composite state value sn-cv 'is generated by sn + sn-cvv' + current block height coding, so that the state version is updated.

The block headers bhl ', sn-cv' of the newly-out block containing the signature transaction are used as the status certification sn _ proof 'to be sent to the light node, since bhl' is the latest block, the timeliness certification is no longer needed, and the above steps can eliminate the miscoording of the cuckoo filter caused by the backward block of the status-written 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 specifying a state is acquired.

The light node obtains a proof sn-proof of the 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, and the like, are determined according to different consensus algorithms, so as to verify that the block headers contain an existence acceptance, an absence acceptance, and an expired block height that is 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 presence commitment of state is extracted from the current chunk header bhs, verifying whether sn + sn-cv exists in the write state set of the chunk.

At S309, the absence commitment is verified.

And extracting the height of the expired block from the latest block header, 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, the non-existence promise of the state 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 state.

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 acquisition 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;

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;

a presence commitment for a state is computed based on the state name and the composite state value.

According to some embodiments, further comprising a judging unit 404, the judging 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.

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 non-existence commitment unit 503, configured to obtain a global non-existence commitment of a subsequent version of the state.

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 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. 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 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.

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.

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, so as to verify that the block headers include the presence commitment, the non-presence commitment and the expired block height that have not been 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 state 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 state. 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 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, then the result bloom _ sn is compared with the survivability 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, the 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, the 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 state are written into a block header, participate in block Hash value (Hash) calculation together with other block data items, and identify the block together.

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

The absence commitment in the newest block header bhl is extracted, the sn-next is subjected to a cuckoo filter computation, verifying if the sn-next exists in the non-outdated write state set of the global filter. If not, it indicates bhs is the last write to state sn of all blocks before bhl and after the expired block height, and the written value of the state is the latest state 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 the positions 1 are assigned according to the calculation.

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 certification, and compares whether the root of the Merkel tree is consistent with the state existence commitment in the block header.

The existence commitment of the state is extracted from the chunk header bhs of the write state, verifying whether sn + sn-cv exists in the write state set of the chunk. The state version sn-cvv is decoded and extracted from the sn-cv, and the composite state name sn-cv-next of the next version of the state is calculated according to the state name sn and the state version and version naming rules.

The surviving commitment in the latest block header bhl is extracted, a cuckoo filter calculation is performed on the sn-cv-next, and it is verified whether the sn-cv-next exists in the write state set of the global filter. If not, bhs is indicated to be the last write to state sn of all blocks before bhl after the expired block height, and the written value of the state is the latest state 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.

One skilled in the art will readily appreciate from the description of the example embodiments that the method of generating block status commitments and attestation and verifying block status attestation 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 time-dependent cheating caused by the fact that the 'latest state does not exist' 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 embodied 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 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 many 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 according to the description of the embodiments, or may be modified accordingly in one or more apparatuses 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 implementation described herein; on the contrary, the intention is to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method for verifying block status attestation, comprising:

acquiring a state certificate of a specified state;

verifying a presence commitment;

verifying the non-existent commitment.

2. The method of claim 1, wherein verifying the presence promise comprises:

3. The method of claim 2, wherein the verifying the non-existent commitment comprises:

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.

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

5. A block link point, comprising:

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.

6. The node according to claim 5, wherein the verification presence commitment unit is configured to:

7. The node according to claim 6, wherein the verification absence commitment unit is configured to:

8. 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-4 when executing the computer program.

9. A computer program product comprising computer programs/instructions, characterized in that the computer programs/instructions, when executed by a processor, implement the method according to claims 1-4.