Method, device, apparatus and storage medium for verifying state transition of records

Abstract

Multiple methods, devices, and apparatus for verifying state transitions of records, and non-transitory computer-readable storage media, the apparatus comprising a computer program stored on the computer-readable storage medium. One method includes: receiving a transaction submitted by a user, the transaction comprising an identifier of the record, a protected operation value representing an operation to be performed on the record, a protected state value representing the state of the record after performing the operation, and a certificate prepared by the user (502); determining whether the certificate is acceptable based on whether the certificate indicates that the user possesses a secret input (504); refusing to process the transaction submitted by the user (506) in response to determining that the certificate is unacceptable; and setting the record state of the record to the protected state value (508) in response to determining that the certificate is acceptable.

Description

Technical Field

[0001] The present application relates generally to computer technology, and more particularly to a method, device, apparatus, and storage medium for verifying recorded state transitions. Background Art

[0002] Blockchain systems, also known as distributed ledger systems (DLSs) or consensus systems, enable data from various parties to be stored in a secure and immutable manner. Without specifying a specific use case, blockchain systems can include any DLS and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities, allowing them to use the system and participate in the consensus process. Private blockchain networks are targeted to specific entities, with read and write permissions centrally controlled. Consortium blockchain networks are targeted to a select group of entities, which control the consensus process and include an access control layer.

[0003] Blockchain systems are implemented using peer-to-peer (P2P) networks, where nodes communicate directly with each other, for example, without the need for a central server. Each node in a P2P network can initiate communication with another node in the network. Blockchain systems maintain one or more blockchains, which are data structures used to store data (e.g., transactions) that are resistant to tampering and manipulation by malicious parties.

[0004] Users of a blockchain system can utilize it to conduct various types of transactions. For example, Party A and Party B may both own assets recorded on a blockchain maintained within the system. Party A and Party B can enter into an agreement to redeem or exchange their assets on the blockchain. Such agreements are often executed using smart contracts, which are computer protocols implemented in computer code that are incorporated into the blockchain to facilitate, verify, or enforce the negotiation or performance of the contract. In another example, Party A can submit a document, such as an invoice, to the blockchain and request Party B to review or endorse the document on the blockchain.

[0005] Some blockchain applications can model the assets or documents recorded therein using various states, which can transition based on operations performed on the recorded assets or documents. For example, a newly submitted document can be assigned the "Submitted" state, which can transition to the "Endorsed" state when the document is endorsed. The owner of a document with the "Endorsed" state can use the document to complete tasks that might not be possible with a document with only the "Submitted" state. For example, suppose the document is an invoice, and the invoice owner wishes to use it to secure financing (e.g., to borrow against accounts receivable). If the invoice is only in the "Submitted" state, the financial institution may refuse to approve the invoice for financing purposes. For example, the financial institution can implement state transition rules that prohibit transitions directly from the "Submitted" state to the "Approved" state to prevent the document owner from circumventing the endorsement process.

[0006] Typically, the content of assets and documents recorded on a blockchain is encrypted to protect privacy. However, blockchain applications that use various states to model the assets or documents recorded therein typically record information about the states and the operations associated with those states in plain text.

[0007] Exposing information about status and operations in this way could provide a malicious party with an opportunity to gain insight into the assets and documents recorded on the blockchain. For example, if a malicious party could learn from the blockchain that a document recorded on the blockchain has passed the "Submitted" and "Endorsed" states and is currently "Under Review" by a financial institution, the malicious party could infer that the document may contain a description of an asset or invoice that can be used to secure financing. Summary of the Invention

[0008] In one aspect, a computer-implemented method for verifying a state transition of a record comprises: receiving a transaction submitted by a user, the transaction comprising an identification of the record, a protected operation value representing an operation to be performed on the record, a protected state value representing a state of the record after performing the operation, and a certificate prepared by the user; determining whether the certificate is acceptable by determining whether the certificate indicates that the user possesses information generated at least in part based on a plaintext value of the operation to be performed on the record and a plaintext value of the state of the record after performing the operation; refusing to process the transaction submitted by the user in response to determining that the certificate is unacceptable; and setting the record state of the record to the protected state value in response to determining that the certificate is acceptable.

[0009] In another aspect, a device for verifying a state transition of a record comprises: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to: receive a transaction submitted by a user, the transaction comprising an identifier of the record, a protected operation value representing an operation to be performed on the record, a protected state value representing a state of the record after performing the operation, and a certificate prepared by the user; determine whether the certificate is acceptable by determining whether the certificate indicates that the user possesses information generated at least in part based on a plaintext value of the operation to be performed on the record and a plaintext value of the state of the record after performing the operation; in response to determining that the certificate is unacceptable, refuse to process the transaction submitted by the user; and in response to determining that the certificate is acceptable, set the record state of the record to the protected state value.

[0010] In yet another aspect, a non-transitory computer-readable storage medium stores instructions that, when executed by a processor of a device, cause the device to perform a method for verifying a state transition of a record. The method includes receiving a transaction submitted by a user, the transaction including an identifier of the record, a protected operation value representing an operation to be performed on the record, a protected state value representing a state of the record after performing the operation, and a certificate prepared by the user; determining whether the certificate is acceptable by determining whether the certificate indicates that the user possesses information generated at least in part based on a plaintext value of the operation to be performed on the record and a plaintext value of the state of the record after performing the operation; refusing to process the transaction submitted by the user in response to determining that the certificate is unacceptable; and setting the record state of the record to the protected state value in response to determining that the certificate is acceptable. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the accompanying drawings, like reference numerals in different drawings designate the same or similar elements unless otherwise specified.

[0012] Figure 1 is a schematic diagram of a blockchain system according to an embodiment.

[0013] Figure 2 is a schematic diagram of a computing device for implementing a node in a blockchain system according to an embodiment.

[0014] Figure 3 is a diagram depicting an example state diagram according to an embodiment.

[0015] Figure 4is a flow chart of a method for securing and verifying recorded state transitions according to an embodiment.

[0016] Figure 5 is a flow chart of a method for securing and verifying recorded state transitions according to an embodiment.

[0017] Figure 6 is a block diagram of an apparatus for protecting and verifying recorded state transitions according to an embodiment. DETAILED DESCRIPTION

[0018] Embodiments of the present specification provide methods and apparatus for protecting and verifying state transitions of records (e.g., recorded assets or documents). These methods and apparatus can utilize cryptographic schemes or commitment schemes to protect information about the record state of records and the operations performed on those records. These methods and apparatus can also utilize blockchain systems to verify the validity of state transitions of recorded records. Invalid state transitions can be detected, and fraudulent attempts to circumvent certain states can be prevented. In this way, these methods and apparatus can ensure that information about states and operations is protected while enforcing state transition rules imposed on states and operations.

[0019] The embodiments disclosed herein have one or more technical effects. In some embodiments, these methods and devices allow users to protect information about the record state of records and the operations performed on those records. This allows these methods and devices to protect the privacy of such information. In some embodiments, these methods and devices require users to submit proof to verify the operations to be performed and the states to be transitioned to. This allows these methods and devices to detect invalid state transitions and prevent fraudulent attempts to bypass certain states. In some embodiments, these methods and devices support the use of a blockchain system to verify state transitions. This allows these methods and devices to store information about states and operations in a data structure that is resistant to tampering and manipulation by malicious parties. This also allows these methods and devices to utilize a blockchain system to publicly verify state transitions without revealing any private information to the public.

[0020] A blockchain is a data structure that stores data (e.g., transactions) in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this way can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the previous block in the blockchain by including a cryptographic hash of the block immediately preceding it. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in a blockchain system can be hashed and encoded into a data structure, such as a Merkle tree. In a Merkle tree, the data at the leaf nodes of the tree are hashed, and all hash values in each branch of the tree can be concatenated at the root of that branch. This process continues along the tree until it reaches the root of the entire tree, which stores hash values representing all the data in the tree. Hash values purported to be transactions stored in the tree can be quickly verified by determining whether the hash value is consistent with the tree's structure.

[0021] A blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. This network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, numerous entities (such as hundreds, thousands, or even millions of entities) can operate in a public blockchain network, with each entity operating at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network with respect to participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain network's blockchain. Examples of public blockchain networks include specific peer-to-peer payment networks that utilize distributed ledgers (called blockchains).

[0022] Generally speaking, a public blockchain network can support public transactions. Public transactions are shared by all nodes in the public blockchain network and stored in a global blockchain. The global blockchain is a blockchain that is replicated across all nodes, with all nodes in full consensus on the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented in the public blockchain network. Examples of consensus protocols include Proof of Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof of Stake (PoS), and Proof of Authority (PoA).

[0023] Generally speaking, a private blockchain network can be provided to a specific entity, where read and write permissions are centrally controlled. This entity controls which nodes can participate in the blockchain network. For this reason, private blockchain networks are often referred to as permissioned networks, imposing restrictions on who is allowed to participate and the extent of their participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants voting on the addition of new entities, regulators controlling admission).

[0024] Generally speaking, a consortium blockchain network can be private between participating entities. In a consortium blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by the corresponding entity (e.g., a financial institution, an insurance company). For example, a consortium consisting of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node in the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign each block for the block to be valid and added to the blockchain. In some examples, at least a subset of entities (nodes) (e.g., at least 7 entities) must sign each block for the block to be valid and added to the blockchain.

[0025] Figure 1 FIG. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Figure 1 , the blockchain system 100 may include a plurality of nodes configured to operate on a blockchain 120, such as nodes 102 to 110. Nodes 102 to 110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102 to 110 may be a computing device configured to store a copy of the blockchain 120, such as a computer or computer system, or may be software running on a computing device, such as a process or application. Each of nodes 102 to 110 may have a unique identifier.

[0026] The blockchain 120 may include a continuously growing list of records in the form of data blocks, e.g. Figure 1 Each block in blocks B1-B5 may include a timestamp, a cryptographic hash value of the previous block, and data of the current block, which may be a transaction such as a currency transaction. For example, Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash value of block B4, and transaction data of block B5. Furthermore, for example, a hash operation may be performed on the previous block to generate a cryptographic hash value of the previous block. The hash operation may convert inputs of various lengths into encrypted outputs of fixed length using a hash algorithm (e.g., SHA-256).

[0027] Nodes 102 to 110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, the node can generate a new block to be added to blockchain 120 and broadcast the new block to other nodes (e.g., nodes 104 to 110) in network 112. Based on the legitimacy of the new block, for example, the validity of its signature and transactions, the other nodes can determine to accept the new block, so that node 102 and the other nodes can add the new block to their respective copies of blockchain 120. As this process is repeated, more and more blocks of data can be added to blockchain 120.

[0028] Figure 2 102 ( FIG. 103 ) is a block chain system according to an embodiment of the present invention. Figure 1 )) is a schematic diagram of a computing device 200. Figure 2 , computing device 200 may include a communication interface 202 , a processor 204 , and a memory 206 .

[0029] The communication interface 202 can facilitate communication between the computing device 200 and other nodes (eg, nodes 104 to 110 ( Figure 1 )) between devices. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, integrated services digital network (ISDN) standards, etc. In some embodiments, the communication interface 202 may include one or more of a local area network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP)-based communication device, or other communication devices for wired and / or wireless communication. In some embodiments, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, or a hybrid public / private cloud infrastructure.

[0030] The processor 204 may include one or more dedicated processing units, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

[0031] The memory 206 can store processor-executable instructions and data, such as the blockchain 120 ( Figure 1). Memory 206 may include any type of volatile or non-volatile memory device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or a magnetic or optical disk. When processor 204 executes instructions in memory 206, computing device 200 may perform operations on blockchain 120.

[0032] Users of a blockchain system (e.g., blockchain system 100) can conduct various types of transactions using blockchain system 100. For example, users can own assets recorded on a blockchain maintained in blockchain system 100 (e.g., blockchain 120) and enter into agreements to redeem or exchange their assets on blockchain 120. Users can also create documents and submit them to blockchain 120 for recording, and use the recorded documents for various purposes, including, for example, invoice financing.

[0033] In some embodiments, the blockchain 120 may model assets or documents recorded therein using various states that may transition from one state to another based on operations performed on the asset or document. For example, if a user who created a record wants to obtain a certificate of the record's origin, the blockchain 120 may implement a set of state transition rules defined to manage the state of records (e.g., assets or documents) recorded on the blockchain 120. Figure 3 An example state diagram 300 depicting a process for obtaining such a certificate is shown. It should be understood that state diagram 300 is provided by way of example only and is not meant to be limiting.

[0034] like Figure 3 As shown, state diagram 300 may include, for example, seven states S0-S6 and nine operations F0-F8. State diagram 300 also defines transitions, which specify how certain operations trigger certain transitions from one state to another. Transitions not defined in state diagram 300 may be illegal. For example, a transition from S1 to S3 may be illegal because there are no applicable operations that can trigger such a transition. Similarly, applying operation F8 to state S0 may also be illegal because operation F8 is not applicable to state S0.

[0035] For illustration purposes, the states and operations defined in state diagram 300 may be represented as follows:

[0036]

[0037]

[0038] where s and s* are the states before and after the transition, respectively, and f is the action that triggers the transition from s to s*.

[0039] As will be described further below, state diagrams such as state diagram 300 can be used to verify the validity of state transitions. For example, if a user attempts to bypass certain operations or otherwise circumvent the transition rules defined in state diagram 300, the methods and devices disclosed herein can detect such an attempt and prevent such an attempt from being executed on blockchain 120. However, it should be understood that the following reference to state diagram 300 is merely an example and is not intended to be limiting.

[0040] Figure 4 4 shows a flow chart of a method 400 for securing and verifying state transitions according to an embodiment. Figure 4 A blockchain is shown in FIG. 1 , for example, blockchain 120 ( Figure 1 ). Blockchain can be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies, organizations, etc.

[0041] For illustrative purposes, Figure 4 , a user referred to as a client is shown. A client can submit records (e.g., assets or documents) to the blockchain for recording. Records can be in various formats and can contain various types of data. In some embodiments, the entire record submitted to the blockchain can be encrypted. In some embodiments, the record submitted to the blockchain can be partially encrypted. In some embodiments, the record submitted to the blockchain can be in plain text.

[0042] Continuing with the above example, assuming that the client is interested in obtaining a certificate of origin for a record, and further assuming that the blockchain implements the state transition rules defined in state diagram 300 to govern the state of the record during this authentication process, then each time the client attempts to change the current state of the record (denoted as state s), the blockchain can require the client to submit information about the operation f to be performed, as well as requiring the client to indicate what the next state of the record (denoted as state s*) should be after performing operation f. In this way, if the client submits information identifying an operation f that is not defined in state diagram 300, or if the identified operation f is not applicable to the current state s of the record (e.g., if the client identifies F4 as an operation when the current state of the record is S1), the blockchain can refuse to allow the client to proceed. Similarly, the blockchain may refuse to allow the client to proceed if there is no valid transition from the current state s to the next state s* (e.g., if the client indicates S5 as the next state when the recorded current state is S1), or if applying the identified operation f to the current state s does not transition the current state s to the next state s* (e.g., if the client identifies F1 as the operation and indicates S2 as the next state when the recorded current state is S1).

[0043] In some embodiments, to protect privacy, the blockchain can allow the client to encrypt or otherwise protect information about the current state s and the next state s*, and only submit protected state information to the blockchain. In this way, the blockchain can effectively reduce the possibility that a malicious party can observe the state information associated with a record and gain insight into the record.

[0044] In some embodiments, in addition to protecting state information, the blockchain can also allow the client to encrypt or otherwise protect information about the operation f. The client can submit only protected operation information and protected state information to the blockchain. In this way, the blockchain can further reduce the possibility of malicious parties gaining insight into the records, because neither the state information nor the operation information is visible in plain text to the malicious party.

[0045] However, allowing clients to submit only protected operational information and protected state information to the blockchain may make it relatively difficult for the blockchain to perform verification processing and enforce state transition rules as described above. The lack of the ability to enforce state transition rules may provide record owners with opportunities to manipulate the state of a record, for example, by unilaterally changing the state from "submitted" to "endorsed," thereby fraudulently bypassing Figure 3 Furthermore, since the information about the operation f, the current state s, and the next state s* is protected (e.g., encrypted), others may not be able to detect a fraudulent bypass performed by the owner.

[0046] Therefore, in some embodiments, if the client chooses to submit only protected operation information and protected state information to the blockchain, the blockchain may require the client to also submit a proof to the blockchain to prove that the protected operation information and protected state information correspond to a valid operation f that can transform the current state s of the record to the next state s*. In some embodiments, if the client agrees to Figure 4 If the process shown generates a proof, the blockchain may be willing to accept the proof without requiring the client to disclose information about the operation f, the current state s, and the next state s* in plaintext.

[0047] In step 402, the client may generate protected information about the current state s, the next state s*, and the operation f. In some embodiments, the client may generate the protected information using an encryption scheme. Alternatively or additionally, the client may generate the protected information using a commitment scheme (e.g., Pedersen commitment) or a one-way function. One of ordinary skill in the art will appreciate that the function is one-way, if a random element is given It is difficult to calculate So that g(y) = x. In other words, it is difficult to calculate the value of the input variable of a one-way function from the value of its output variable, making the function effectively impossible to invert, and therefore the function is called "one-way". Hash functions such as SHA 256 are examples of one-way functions.

[0048] For example, assuming that the blockchain implements the state transition rules defined in a state diagram defining a total of N states and M operations (e.g., state diagram 300 defines N=7 states and M=9 operations), the client can generate protected information about the current state s, the next state s*, and the operation f in step 402 as the protected current state value S=E(s,r1),s∈[0,N-1], the protected next state value S * =E(s * ,r2),s * ∈[0,N-1], and the protected operation value F = E(f,r3), f∈[0,M-1]. It should be understood that E() can represent an encryption scheme or commitment scheme selected by the client, or a one-way function to protect information about the current state s, the next state s*, and the operation f. r1, r2, and r3 can represent random numbers that can be used in E().

[0049] The client may also generate a proof at step 402. The proof may be generated to prove to the blockchain the protected operation value F and the protected next state value S * Corresponds to a valid operation f that can transition the current state s to the next state s*.

[0050] In some embodiments, the generation of this proof may depend on a set of transition rules defined in a state diagram, such as the state diagram 300 implemented by the blockchain. This set of transition rules, denoted as Ω, may be represented in the format (s, f) → s*, where operation f is applied to the current state s to transition the current state s to the next state s*. Thus, the set of transition rules Ω defined in the state transition diagram 300 may be represented as:

[0051]

[0052] In some embodiments, the client can generate the proof as a zero-knowledge proof, which refers to a technique that allows a prover to prove to a verifier that a statement is true without revealing any information beyond the validity of the statement itself. The client can attempt to prove this by indicating the following: (1) the client knows the plaintext value of the current state s, and if r1 is used to generate the protected current state value S, then the client knows the plaintext value of r1; (2) the client knows the plaintext value of the next state s*, and if r2 is used to generate the protected next state value S*, then the client knows the plaintext value of r2; (3) the client knows the plaintext value of the operation f, and if r3 is used to generate the protected operation value F, then the client knows the plaintext value of r3; (4) the operation f is a valid transformation that can transform the current state s to the next state s*.

[0053] In some embodiments, to prove that the client knows the plaintext values of s and r1, the client can prove to the blockchain that S=E(s,r1). To prove that the client knows the plaintext values of s* and r2, the client can prove to the blockchain that S * =E(s * ,r2). Similarly, to prove that the client knows the plaintext values of f and r3, the client can prove to the blockchain that F = E(f,r3). Furthermore, to prove that operation f is a valid transition that can transform the current state s to the next state s*, the client can prove to the blockchain that (s,f)→s* is a member of the transition rule set Ω.

[0054] In some embodiments, the client and the blockchain may agree to implement zero-knowledge proof techniques, such as zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK). The client can prove to the blockchain that it knows a secret input w such that, for a public input x, a certain relationship between x and w holds. In some embodiments, this relationship can be defined as an arithmetic circuit. In some embodiments, the arithmetic circuit can be defined based on a polynomial equation that can be evaluated based on x and w. In some embodiments, a proving key and a verification key can be generated during a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof. Those skilled in the art will appreciate that the setup phase can be performed by a trusted party or by multiple independent parties collaborating using multi-party computation.

[0055] In some embodiments, the client may set the public input x to be based on the protected values S, S * and F, and sets the secret input w to a value generated based on the plaintext values of s, s*, f, r1, r2, and r3. For example, the client can * The value of x is set by concatenating s, s*, f, r1, r2, and r3, and the value of w is set by concatenating s, s*, f, r1, r2, and r3. In this way, the client can use the secret input and public input along with the proving key to generate a proof to prove to the blockchain that the client possesses the secret input w. For example, if the relationship between the public input x and the secret input w can be defined based on a polynomial equation, such as a(x)w(x) = b(x)c(x), then a() can be set as the proving key and b()c() can be set as the verification key. The client can generate a proof to prove to the blockchain that the client possesses the secret input w by calculating the polynomial a(x)w(x).

[0056] In some embodiments, the blockchain can verify the proof using the public input x and the verification key. Continuing with the example above, the blockchain can verify the proof by determining whether the polynomial equation a(x)w(x) = b(x)c(x) holds. For example, the blockchain can calculate the value of the polynomial b(x)c(x) and check whether this value is equal to the proof submitted by the client. If the equality holds, the blockchain can accept the client's proof that the client possesses the secret input w, and the blockchain can accept the client's statement as true. However, if the equality does not hold, the blockchain can reject the client's proof.

[0057] It should be understood that the polynomial equations, proof keys, and verification keys described above are presented as examples only and are not intended to be limiting. It is contemplated that the relationship between the public input x and the secret input w can be defined using various types of equations, and that the proof key and verification key can be defined accordingly based on the relationship between the public input x and the secret input w. In some embodiments, the proof can also be converted to a sigma protocol, which can be converted to a non-interactive zero-knowledge proof of knowledge using the Fiat-Shamir transform.

[0058] In step 404, the client may submit a record containing {record_ID, * ,F,certification} payload, where record_ID is used to identify the record to be updated. For illustration purposes, this transaction may be referred to as an "update" transaction, which a client may use to update the state of a record identified by record_ID. It is contemplated that a client may also include additional data fields in an update transaction. Such data fields may include, for example, the contents of the record or updates to the contents of the record.

[0059] In step 406, the blockchain can check the proof included in the update transaction to determine whether the client possesses the secret input w. In some embodiments, the blockchain can utilize one or more smart contracts executed on the blockchain to provide this determination. A smart contract is a computer protocol implemented in computer code that is incorporated into the blockchain to facilitate, verify, or enforce the negotiation or performance of a contract. For example, blockchain users can program agreed-upon terms into a smart contract using programming languages such as C++, Java, Solidity, and Python. When the terms are met, the smart contract can automatically execute on the blockchain, for example, executing the transaction. As another example, a smart contract can include multiple subroutines or functions, each of which can be a sequence of program instructions that performs a specific task. A smart contract can be an operational code that is executed in whole or in part without human interaction.

[0060] In some embodiments, a smart contract can be incorporated into the blockchain to determine whether the proof is acceptable. The smart contract can use the public input and verification key to verify the proof. If the proof cannot be verified, the smart contract can refuse to allow the client to proceed. On the other hand, if the proof can be verified, the smart contract can determine that the proof is acceptable and proceed to set the current state of the record recorded on the blockchain to S* specified by the client in step 408. After step 408, s* becomes the current state of the record, and the protected value of s* (denoted as S* in the description above) becomes the current state of the record recorded on the blockchain.

[0061] In some embodiments, each time a client attempts to update the status of a record, the Figure 4 The flow shown in Figure 1. In this way, even if states and operations are encrypted or otherwise protected by the client, the blockchain can detect invalid state transitions and prevent fraudulent attempts by clients to bypass certain states. Furthermore, in this way, the blockchain can allow the public to verify the validity of state transitions performed on a record, but the public may not be able to decipher the record's current state, nor the record's previous state or the operation being performed, thereby protecting the client's privacy.

[0062] Figure 5 1 shows a flow chart of a method 500 for protecting and verifying state transitions of records according to an embodiment. The method 500 may be performed by one or more nodes in a blockchain system (e.g., blockchain system 100 ( Figure 1 ) in the blockchain system 100). The nodes 102 to 110 in the blockchain system 100 can perform operations on the blockchain (e.g., the blockchain 120 ( Figure 1 )) performs operations. The blockchain 120 can be implemented as the blockchain in the above example.

[0063] At step 502, a node (e.g., node 102) may receive a transaction submitted by a user. The user may be, for example, a client ( Figure 4 ), and user-submitted transactions can include "update" transactions ( Figure 4 In some embodiments, a transaction may include an identifier of a record (e.g., record_ID), a protected operation value (e.g., F) representing the operation f to be performed on the record, a protected state value (e.g., S*) representing the state s* of the record after performing the operation f, and a protected state value (e.g., S * ) and the proof prepared by the user. In some embodiments, a protected operation value F can be generated (e.g., using an encryption scheme, a commitment scheme, a one-way function, etc.) based on the plaintext value representing the operation f, and a protected state value S can be generated (e.g., using an encryption scheme, a commitment scheme, a one-way function, etc.) based on the plaintext value representing the state s*. * In some embodiments, node 102 may not receive the plaintext value of operation f and the plaintext value of state s* from the user.

[0064] In step 504, node 102 may determine whether the proof is acceptable. In some embodiments, node 102 may determine whether the proof is acceptable based on whether the proof indicates that the user possesses a secret input w (based at least in part on the plaintext value of operation f and state s) such as the secret input w. * In some embodiments, the proof may be a zero-knowledge proof. In these embodiments, node 102 may generate the proof without access to the plaintext value of operation f and the state s. *In some embodiments, the proof may be generated by a user to prove that the protected operation value F corresponds to a value capable of transforming the record from a first (current) state s to a second (next) state s. * Valid operation f, and prove the protected state value S * Indicates the second (next) state s * The protected status value of .

[0065] In some embodiments, node 102 may determine whether a certificate is acceptable based on whether the certificate can show that the user knows the first state s of the record. Node 102 may also determine whether the certificate is acceptable based on whether the certificate can show that the user knows the second state s of the record. * To determine whether the proof is acceptable. Node 102 may also determine whether the proof is acceptable based on whether the proof can show that the user knows the operation f to be performed on the record. Node 102 may also determine whether the proof is acceptable based on whether the proof can show that the operation f is a valid operation to transition the record from the first state s to the second state s*.

[0066] In some embodiments, a user can prove to node 102 that the user knows a secret input w such that, for a public input x, a certain relationship between x and w holds. As described above, node 102 can determine whether the proof is acceptable by verifying the proof using the public input x and the verification key. In some embodiments, if node 102 accepts the user's proof that the user possesses the secret input w, then node 102 can accept the user's statement as true.

[0067] In response to determining that the proof is unacceptable, node 102 may refuse to process the transaction submitted by the user at step 506. In this way, node 102 may detect invalid state transitions and prevent fraudulent attempts by users to bypass certain states.

[0068] In step 508, in response to determining that the proof is acceptable, node 102 may set the record state of the record to a protected state value S * In this manner, node 102 can verify the validity of a state transition performed on a record without having to decipher the plaintext value of operation f and the plaintext value of state s*. In some embodiments, method 500 can be repeated each time a user attempts to update the state of a record.

[0069] Figure 6 6 is a block diagram of a state transition verification device 600 according to an embodiment. The state transition verification device 600 may be implemented by software processing and may correspond to the method 500 ( Figure 5 ). Reference Figure 6 The state transition verification device 600 may include a receiving module 602 , a determining module 604 , a rejecting module 606 and a recording module 608 .

[0070] The receiving module 602 can receive transactions submitted by users. Transactions can include "update" transactions ( Figure 4 ), which may include an identifier of the record (e.g., record_ID), a protected operation value (e.g., F) representing the operation f to be performed on the record, a protected state value (e.g., S*) representing the state of the record after performing the operation f. * ) and the proof prepared by the user. The receiving module 602 can provide the received transaction to the determining module 504.

[0071] The determination module 604 may determine whether the proof is acceptable. In response to determining that the proof is unacceptable, the determination module 604 may request the rejection module 606 to reject the transaction submitted by the user. Otherwise, the determination module 604 may provide the transaction to the recording module 608, and the recording module 608 may set the record status of the record to the protected state value S * In this way, the state transition verification device 600 can detect invalid state transitions and prevent fraudulent attempts by users to bypass certain states. The state transition verification device 600 can also verify the validity of state transitions performed on records without deciphering the plaintext value of the operation f and the plaintext value of the state s*, thereby protecting the privacy of the user.

[0072] Each of the above modules can be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor that executes instructions stored in a memory. In addition, for example, each of the above modules can be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the method. For further example, each of the above modules can be implemented using a computer chip or entity, or implemented by using a product with a specific function. In one embodiment, device 600 can be a computer, and the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0073] For the implementation process of the functions and effects of each module in the apparatus 600, reference may be made to the corresponding steps in the above method. For the sake of simplicity, the details are omitted here.

[0074] In some embodiments, a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute the above-described method.

[0075] A computer-readable storage medium may be a tangible device that can store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (e.g., a punched card or a raised structure in a slot on which instructions are recorded), and any suitable combination thereof.

[0076] The computer-readable program instructions for performing the above method can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages (including object-oriented programming languages) and conventional process programming languages. The computer-readable program instructions can be executed completely on a computing device as an independent software package, or partly executed on a first computing device and partly executed on a second computing device away from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device by any type of network including a local area network (LAN) or a wide area network (WAN).

[0077] Computer-readable program instructions may be provided to a processor of a general or special-purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the above-described methods.

[0078] The flowcharts and diagrams in the accompanying drawings illustrate the possible architectures, functions and operations of the devices, methods and computer program products according to various embodiments of the present specification. In this regard, the blocks in the flowcharts or schematics can represent software programs, segments or portions of code that include one or more executable instructions for implementing a particular function. It should also be noted that in some alternative embodiments, the functions recorded in the blocks may not conform to the order recorded in the figures. For example, two blocks shown in succession can actually be executed substantially simultaneously, or sometimes the blocks can be executed in reverse order depending on the functions involved. It will also be noted that each block of the schematics and / or flowcharts and the combination of blocks in the schematics and flowcharts can be implemented by a dedicated hardware-based system that performs the specified function or action or a combination of dedicated hardware and computer instructions.

[0079] It should be understood that certain features described in this specification in the context of separate embodiments for the sake of clarity may also be provided in combination in a single embodiment. Conversely, various features described in this specification in the context of a single embodiment for the sake of brevity may also be provided individually or in any suitable subcombination, or as appropriate in any other described embodiment of this specification. Certain features described in the context of various embodiments are not essential features of those embodiments unless so indicated.

[0080] Although the present specification has been described in conjunction with specific embodiments, many alternatives, modifications and variations will be apparent to those skilled in the art. It is therefore intended that the appended claims encompass all such alternatives, modifications and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for verifying a recorded state transition, comprising: receiving a transaction submitted by a user, the transaction comprising an identifier of the record, a protected operation value representing an operation to be performed on the record, a protected state value representing a state of the record after performing the operation, and a certificate prepared by the user; Verifying, by a smart contract of the blockchain system, whether the proof indicates that the user possesses information generated at least in part based on a plaintext value of the operation to be performed on the record and a plaintext value of the state of the record after the operation is performed, to determine whether the proof is acceptable; wherein, when the proof is acceptable, the proof is used to prove to the blockchain system that the protected operation value of the operation and the protected state value of the state correspond to a valid operation capable of transitioning the current state of the record to a next state; In response to determining that the certification is unacceptable, refusing to process the transaction submitted by the user; and In response to determining that the certification is acceptable, setting a record status of the record to the protected status value.

2. The method according to claim 1, wherein The method is executed by one or more nodes in the blockchain system.

3. The method according to claim 2, wherein: The record includes an asset or document recorded on the blockchain system.

4. The method according to claim 2, wherein: The plaintext value of the operation to be performed and the plaintext value of the state of the record after performing the operation are not received by the blockchain system.

5. The method according to claim 4, wherein Determining whether the attestation is acceptable includes determining whether the attestation is acceptable without access to the plaintext value of the operation to be performed and the plaintext value of the state of the record after performing the operation.

6. The method according to claim 1, wherein The proof is a zero-knowledge proof.

7. The method according to claim 1, wherein The protected operation value is generated based on the plaintext value representing the operation to be performed on the record.

8. The method according to claim 1, wherein The protected state value is generated based on the plaintext value representing the state of the record after performing the operation.

9. The method according to any one of claims 1 to 8, wherein The certification is prepared by the user to certify that the user is aware of a first state of the record, the first state of the record being a state of the record before performing the operation.

10. The method according to claim 9, wherein: The proof is prepared by the user to further prove that the user is aware of a second state of the record, the second state of the record being the state of the record after performing the operation.

11. The method according to claim 10, wherein: The proof is prepared by the user to further prove that the user is aware of the operation to be performed on the record.

12. The method according to claim 11, wherein The proof is prepared by the user to further prove that the operation is a valid operation to transition the record from the first state to the second state.

13. An apparatus for verifying a state transition of a record, comprising: one or more processors; as well as One or more computer-readable memories coupled to the one or more processors and having stored thereon instructions executable by the one or more processors to perform the method according to any one of claims 1 to 12.

14. An apparatus for verifying recorded state transitions, the apparatus comprising a plurality of modules for executing the method according to any one of claims 1 to 12. 15 . A non-transitory computer-readable storage medium storing instructions, which, when executed by a processor of a device, cause the device to perform the method according to claim 1 .

Images