WO2021223653A1 - Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement - Google Patents

Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement Download PDF

Info

Publication number
WO2021223653A1
WO2021223653A1 PCT/CN2021/091022 CN2021091022W WO2021223653A1 WO 2021223653 A1 WO2021223653 A1 WO 2021223653A1 CN 2021091022 W CN2021091022 W CN 2021091022W WO 2021223653 A1 WO2021223653 A1 WO 2021223653A1
Authority
WO
WIPO (PCT)
Prior art keywords
record
state
proof
blockchain
user
Prior art date
Application number
PCT/CN2021/091022
Other languages
English (en)
Inventor
Shengjiao CAO
Yuan Yuan
Hui Fang
Weitao YANG
Original Assignee
Alipay Labs (singapore) Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Labs (singapore) Pte. Ltd. filed Critical Alipay Labs (singapore) Pte. Ltd.
Priority to CN202180011181.6A priority Critical patent/CN115023721A/zh
Publication of WO2021223653A1 publication Critical patent/WO2021223653A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Definitions

  • the specification relates generally to computer technologies, and more particularly, to methods and devices for protecting and verifying state transition of a record.
  • Blockchain systems also known as distributed ledger systems (DLSs) or consensus systems, may enable participating parties to store data securely and immutably.
  • Blockchain systems may include any DLSs, without referencing any particular use case, and may be used for public, private, and consortium blockchain networks.
  • a public blockchain network is open for all entities to use the system and participate in the consensus process.
  • a private blockchain network is provided for a particular entity, which centrally controls read and write permissions.
  • a consortium blockchain network is provided for a select group of entities, which control the consensus process, and includes an access control layer.
  • a blockchain system is implemented using a peer-to-peer (P2P) network, in which the nodes communicate directly with each other, e.g., without the need of a fixed, central server. Each node in the P2P network may initiate communication with another node in the P2P network.
  • P2P peer-to-peer
  • a blockchain system maintains one or more blockchains.
  • a blockchain is a data structure for storing data, such as transactions, that may prevent tampering and manipulation of the data by malicious parties.
  • Users of a blockchain system may utilize the blockchain system to carry out various types of transactions.
  • two parties Party A and Party B
  • Parties A and B may both own assets recorded on a blockchain maintained in the blockchain system.
  • Parties A and B may enter into an agreement to exchange, or swap, their assets on the blockchain.
  • Such agreements are typically carried out using smart contracts, which are computer protocols implemented in the form of computer code that are incorporated into the blockchain, to facilitate, verify, or enforce the negotiation or performance of contracts.
  • Party A may submit a document, e.g., an invoice, to the blockchain and request Party B to review or endorse the document on the blockchain.
  • Some blockchain applications may model assets or documents recorded therein using various states, which may transition based on operations performed with respect to the recorded assets or documents. For example, a newly submitted document may be assigned a “submitted” state, which may transition to an “endorsed” state when the document becomes endorsed. The owner of the document with an “endorsed” state may use the document to accomplish certain tasks that may not be accomplished using a document with merely a “submitted” state. For example, suppose that the document is an invoice and the owner of the invoice wishes to use the invoice to secure financing (e.g., to borrow money against accounts receivable) , a financial institution may refuse to approve the invoice for financing purposes if the invoice is merely in a “submitted” state. For example, the financial institution may impose a state transition rule that prohibits a transition directly from a “submitted” state to an “approved” state to prevent the owner of the document from bypassing the endorsement process.
  • a state transition rule that prohibits a transition directly from a “submitted” state to an “approved” state
  • contents of assets and documents recorded on blockchains are encrypted to protect privacy.
  • blockchain applications that model assets or documents recorded therein using various states typically record information concerning the states and operations associated with such states in plaintext.
  • Exposing information concerning the states and operations in this manner may provide opportunities for malicious parties to gain insights into the assets and documents recorded on the blockchains. For example, if a malicious party can learn from a blockchain that a document recorded on the blockchain has been through a “submitted” state and an “endorsed” state, and is now “under review” by a financial institution, then the malicious party may deduce that the document likely contains a description of an asset or an invoice that can be used to secure financing.
  • a computer-implemented method for verifying state transition of a record includes: 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 with respect to the record, a protected state value representing a state of the record after performing the operation, and a proof prepared by the user; determining whether the proof is acceptable by determining whether the proof indicates that the user is in possession of information generated at least partially based on a plaintext value of the operation to be performed with respect to the record and a plaintext value of the state of the record after performing the operation; in response to a determination that the proof is unacceptable, refusing to process the transaction submitted by the user; and in response to a determination that the proof is acceptable, setting a recorded state of the record to the protected state value.
  • a device for verifying state transition of a record includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to: receive a transaction submitted by a user, the transaction comprising an identification of the record, a protected operation value representing an operation to be performed with respect to the record, a protected state value representing a state of the record after performing the operation, and a proof prepared by the user; determine whether the proof is acceptable by determining whether the proof indicates that the user is in possession of information generated at least partially based on a plaintext value of the operation to be performed with respect to the record and a plaintext value of the state of the record after performing the operation; in response to a determination that the proof is unacceptable, refuse to process the transaction submitted by the user; and in response to a determination that the proof is acceptable, set a recorded state of the record to the protected state value.
  • a non-transitory computer-readable medium has stored therein instructions that, when executed by a processor of a device, cause the device to perform a method for providing decentralized identity verification.
  • the method includes: 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 with respect to the record, a protected state value representing a state of the record after performing the operation, and a proof prepared by the user; determining whether the proof is acceptable by determining whether the proof indicates that the user is in possession of information generated at least partially based on a plaintext value of the operation to be performed with respect to the record and a plaintext value of the state of the record after performing the operation; in response to a determination that the proof is unacceptable, refusing to process the transaction submitted by the user; and in response to a determination that the proof is acceptable, setting a recorded state of the record to the protected state value.
  • FIG. 1 is a schematic diagram of a blockchain system, according to an embodiment.
  • FIG. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment.
  • FIG. 3 is an illustration depicting a sample state diagram according to an embodiment.
  • FIG. 4 is a flow chart of a method for protecting and verifying state transition of a record, according an embodiment.
  • FIG. 5 is a flow chart of a method for protecting and verifying state transition of a record, according an embodiment.
  • FIG. 6 is a block diagram of an apparatus for protecting and verifying state transition of a record, according to an embodiment.
  • Embodiments of the specification provide methods and devices for protecting and verifying state transition of records (e.g., recorded assets or documents) .
  • the methods and devices may utilize encryption schemes or commitment schemes to protect information concerning states of recorded records and operations performed on such records.
  • the methods and devices may also utilize blockchain systems to verify validities of state transitions concerning the recorded records. Invalid state transitions can be detected and fraudulent attempts to bypass certain states can be prevented. In this manner, the methods and devices can ensure that information concerning the states and operations are protected while simultaneously enforcing state transition rules imposed on the states and operations.
  • the methods and devices permit users to protect information concerning states of recorded records and operations performed on such records. This allows the methods and devices to preserve privacy of such information.
  • the methods and devices require users to submit proofs in order to validate the operations to be performed and the states to be transitioned to. This allows the methods and devices to detect invalid state transitions and prevent fraudulent attempts to bypass certain states.
  • the methods and devices support validation of state transitions using a blockchain system. This allows the methods and devices to store information concerning the states and operations in a data structure that can prevent tampering and manipulation by malicious parties. This also allows the methods and devices to utilize the blockchain system to validate state transitions in a public manner without revealing any private information to the public.
  • a blockchain is a data structure that stores data, e.g., transactions, in a way that may prevent tampering and manipulation of the data by malicious parties. The transactions stored in this manner may be immutable and subsequently verified.
  • a blockchain includes one or more blocks. Each block is linked to a previous block immediately before it in the blockchain by including a cryptographic hash of the previous block. Each block also may include a timestamp, its own cryptographic hash, and one or more transactions.
  • the transactions which generally have already been verified by the nodes of the blockchain system, may be hashed and encoded into a data structure, such as a Merkle tree.
  • a Merkle tree In a Merkle tree, data at leaf nodes of the tree is hashed, and all hashes in each branch of the tree may be concatenated at a root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all data in the tree. A hash purporting to be of a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.
  • a blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains.
  • the network may be a public blockchain network, a private blockchain network, or a consortium blockchain network.
  • numerous entities such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, and each of the entities operates at least one node in the public blockchain network.
  • the public blockchain network can be considered a public network with respect to the participating entities.
  • a majority of entities (nodes) must sign every block for the block to be valid and added to the blockchain of the blockchain network.
  • Examples of public blockchain networks include particular peer-to-peer payment networks that leverage a distributed ledger, referred to as blockchain.
  • a public blockchain network may support public transactions.
  • a public transaction is shared with all of the nodes in the public blockchain network, and is stored in a global blockchain.
  • a global blockchain is a blockchain replicated across all nodes, and all nodes are in perfect state consensus with respect to the global blockchain.
  • consensus protocols include proof-of-work (POW) (e.g., implemented in the some crypto-currency networks) , proof-of-stake (POS) , and proof-of-authority (POA) .
  • PW proof-of-work
  • POS proof-of-stake
  • POA proof-of-authority
  • a private blockchain network may be provided for a particular entity, which centrally controls read and write permissions.
  • the entity controls which nodes are able to participate in the blockchain network.
  • private blockchain networks are generally referred to as permissioned networks that place restrictions on who is allowed to participate in the network, and on their level of participation (e.g., only in certain transactions) .
  • Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, a regulatory authority can control admission) .
  • a consortium blockchain network may be private among the participating entities.
  • the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (e.g., a financial institution, insurance company) .
  • a consortium of ten (10) entities e.g., financial institutions, insurance companies
  • the consortium blockchain network can be considered a private network with respect to the participating entities.
  • each entity (node) must sign every block in order for the block to be valid, and added to the blockchain.
  • at least a sub-set of entities (nodes) e.g., at least 7 entities
  • FIG. 1 illustrates a schematic diagram of a blockchain system 100, according to an embodiment.
  • the blockchain system 100 may include a plurality of nodes, e.g., nodes 102-110, configured to operate on a blockchain 120.
  • the nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network.
  • P2P peer-to-peer
  • Each of the nodes 102-110 may be a computing device, such as a computer or a computer system, configured to store a copy of the blockchain 120, or may be software running on the computing device, such as a process or an application.
  • Each of the nodes 102-110 may have a unique identifier.
  • the blockchain 120 may include a growing list of records in the form of data blocks, such as blocks B1-B5 in FIG. 1.
  • Each of the blocks B1-B5 may include a timestamp, a cryptographic hash of a previous block, and data of the present block, which may be transactions such as monetary transactions.
  • block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data of block B5.
  • a hashing operation may be performed on the previous block to generate the cryptographic hash of the previous block.
  • the hashing operation may convert inputs of various lengths into cryptographic outputs of a fixed length through a hash algorithm, such as SHA-256.
  • the nodes 102-110 may be configured to perform an operation on the blockchain 120. For example, when a node, e.g., the node 102, wants to store new data onto the blockchain 120, that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112. Based on legitimacy of the new block, e.g., validity of its signature and transactions, the other nodes may determine to accept the new block, such that the node 102 and the other nodes may add the new block to their respective copies of the blockchain 120. As this process repeats, more and more blocks of data may be added to the blockchain 120.
  • a node e.g., the node 102
  • that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112.
  • the other nodes may determine to accept the new block, such that the
  • FIG. 2 illustrates a schematic diagram of a computing device 200 for implementing a node, e.g., the node 102 (FIG. 1) , in a blockchain system, according to an embodiment.
  • the computing device 200 may include a communication interface 202, a processor 204, and a memory 206.
  • the communication interface 202 may facilitate communications between the computing device 200 and devices implementing other nodes, e.g., nodes 104-110 (FIG. 1) , in the network.
  • the communication interface 202 is configured to support one or more communication standards, such as an Internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, etc.
  • 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 communications.
  • the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure.
  • 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 with the memory 206 and is configured to execute instructions stored in the memory 206.
  • the memory 206 may store processor-executable instructions and data, such as a copy of the blockchain 120 (FIG. 1) .
  • the memory 206 may include any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random-access memory (SRAM) , an electrically erasable programmable read-only memory (EEPROM) , an erasable programmable read-only memory (EPROM) , a programmable read-only memory (PROM) , a read-only memory (ROM) , a magnetic memory, a flash memory, or a magnetic or optical disk.
  • SRAM static random-access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic memory a magnetic memory
  • flash memory or a magnetic or optical disk.
  • Users of a blockchain system may utilize the blockchain system 100 to carry out various types of transactions.
  • users may own assets recorded on a blockchain, e.g., the blockchain 120, maintained in the blockchain system 100, and enter into agreements to exchange, or swap, their assets on the blockchain 120.
  • Users may also create and submit documents to the blockchain 120 for recordation and utilize the recorded documents for various purposes, including, e.g., invoice financing and the like.
  • the blockchain 120 may model assets or documents recorded therein using various states, which may transition from one to another based on the operations performed on the assets or documents.
  • the blockchain 120 may enforce a set of state transition rules defined for managing the state of a record (e.g., an asset or a document) recorded on the blockchain 120 if the user who created the record wants to obtain a certificate of origin for the record.
  • FIG. 3 illustrates a sample state diagram 300 depicting a process for obtaining such a certificate. It is to be understood that the state diagram 300 is merely provided as an example and is not meant to be limiting.
  • the state diagram 300 may include, e.g., seven states S0-S6 and nine operations F0-F8.
  • the state diagram 300 also defines transitions, which specify how certain operations can trigger certain transitions from one state to another.
  • a transition not defined in the state diagram 300 may be illegal. For example, a transition from S1 to S3 may be illegal because there is no applicable operation that can trigger such a transition.
  • applying operation F8 to state S0 may also be illegal because operation F8 is not applicable to state S0.
  • state diagram 300 For illustrative purposes, the states and operations defined in the state diagram 300 may be denoted as:
  • s and s * are the states before and after a transition, respectively, and f is the operation which triggers the transition from s to s * .
  • state diagrams such as the state diagram 300 may be utilized to verify validities of state transitions. If a user attempts to bypass certain operations or otherwise circumvent the transition rules defined in the state diagram 300, for example, the methods and devices disclosed herein can detect such attempts and prevent such attempts from being carried out on the blockchain 120. It is to be understood, however, that the references made to the state diagram 300 below are merely examples and are not meant to be limiting.
  • FIG. 4 illustrates a flow chart of a method 400 for protecting and verifying states transitions according to an embodiment.
  • a Blockchain e.g., the blockchain 120 (FIG. 1)
  • the Blockchain may be implemented to support various types of users, or parties, including, e.g., individuals, businesses, banks, financial institutions, hospitals, as well as other types of companies, organizations, and the like.
  • the Client may submit a record (e.g., an asset or a document) to the Blockchain for recordation.
  • the record may be of various formats and may contain various types of data.
  • the entire record submitted to the Blockchain may be encrypted.
  • the record submitted to the Blockchain may be partially encrypted.
  • the record submitted to the Blockchain may be in plaintext.
  • the Blockchain may require the Client to submit information concerning an operation f to be performed and indicate what the next state of the record, denoted as state s * , ought to be after the performance of the operation f.
  • the Blockchain may refuse to allow the Client to proceed.
  • the Blockchain may refuse to allow the Client to proceed.
  • the Blockchain may allow the Client to encrypt or otherwise protect the information concerning the current state s and the next state s * , and submit only the protected state information to the Blockchain. In this manner, the Blockchain can effectively reduce the likelihood of a malicious party being able to observe the state information associated with the record and gain insights into the record.
  • the Blockchain may also allow the Client to encrypt or otherwise protect the information concerning the operation f in addition to protecting that state information.
  • the Client may submit only the protected operation information and protected state information to the Blockchain. In this manner, the Blockchain can further reduce the likelihood of a malicious party being able to gain insights into the record because neither the state information nor the operation information is visible to the malicious party in plaintext.
  • 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 transition the current state s of the record to the next state s * .
  • the Blockchain may be willing to accept the proof without requiring the Client to disclose information concerning the operation f, the current state s, and the next state s * in plaintext, provided that the Client agrees to generate the proof in accordance with the process depicted in FIG. 4.
  • the Client may generate protected information concerning the current state s, the next state s * , and the operation f.
  • the Client may generate the protected information using an encryption scheme.
  • the Client may generate the protected information using a commitment scheme (e.g., Pedersen commitment) or a one-way function.
  • a commitment scheme e.g., Pedersen commitment
  • Hash functions such as SHA 256 and the like, are examples of one-way functions.
  • E () may represent an encryption or commitment scheme, or a one-way function chosen by the Client to protect information concerning the current state s, the next state s * , and the operation f. r 1 , r 2 , and r 3 may represent random numbers that may be used in E () .
  • the Client may also generate a proof at step 402.
  • the proof may be generated to prove to the Blockchain that the protected operation value F and the protected next state value S * correspond to a valid operation f that can transition the current state s to the next state s * .
  • the generation of this proof may depend on the set of transition rules defined in the state diagram, e.g., the state diagram 300, enforced by the Blockchain.
  • This set of transition rules denoted as ⁇ , may be expressed in the format of (s, f) ⁇ s * , representing application of operation f to the current state of s to transition the current state s to the next state s * .
  • the set of transition rules ⁇ defined in the state transition diagram 300 may be expressed as:
  • the Client may generate the proof as a zero-knowledge proof, which refers to techniques that allow 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 may attempt to prove this by indicating that: (1) the Client knows the plaintext value of the current state s, and if r 1 is used to generate the protected current state value S, the Client knows the plaintext value of r 1 ; (2) the Client knows the plaintext value of the next state s * , and if r 2 is used to generate the protected next state value S * , the Client knows the plaintext value of r 2 ; (3) the Client knows the plaintext value of the operation f, and if r 3 is used to generate the protected operation value F, the Client knows the plaintext value of r 3 ; and (4) the operation f is a valid transition that can transition the current state s to the next state s * .
  • the operation f is a valid transition that can transition the current state s to the next state s * .
  • the Client may prove to the Blockchain that (s, f) ⁇ s * is a member of the set of transition rules ⁇ .
  • 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) or the like.
  • the Client may prove to the Blockchain that the Client knows a secret input w such that for a public input x, a certain relationship between x and w holds true.
  • the relationship may be defined as an arithmetic circuit.
  • the arithmetic circuit may be defined based on an equation of polynomials that can be evaluated based on x and w.
  • a proving key and a verification key may be generated in a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof.
  • the setup phase may be executed by a trusted party, or by multiple independent parties collaboratively using a multi-party computation.
  • the Client may set the public input x to a value generated based on the protected values S, S * , and F, and set the secret input w to a value generated based on the plaintext values of s, s * , f, r 1 , r 2 , and r 3 .
  • the Client may set the value of x by concatenating S, S * , and F together and set the value of w by concatenating s, s * , f, r 1 , r 2 , and r 3 together.
  • the Client may generate the proof using the secret and public inputs as well as the proving key to prove to the Blockchain that the Client is in possession of the secret input w.
  • the Client may generate the proof by calculating the polynomial a (x) w (x) to prove to the Blockchain that the Client is in possession of the secret input w.
  • the polynomial equation, the proving key, and the verification key described above are merely presented as examples and are not meant 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 proving key and the verification key may be defined accordingly based on the relationship between the public input x and the secret input w. In some embodiments, the proof may also be translated into sigma protocols, which can be transformed into non-interactive zero-knowledge proofs of knowledge using Fiat-Shamir transform.
  • the Client may submit a transaction to the Blockchain with payload containing ⁇ record_ID, S * , F, proof ⁇ , where the record_ID is used to identify the record to be updated.
  • this transaction may be referred to as an “UPDATE” transaction, which may be used by the Client to update the state of the record identified by record_ID.
  • UPDATE UPDATE
  • the Client may also include additional data fields in the UPDATE transaction. Such data fields may include, e.g., the content of the record or updates to the content of the record.
  • the Blockchain may check the proof contained in the UPDATE transaction to determine whether the Client is in possession of the secret input w.
  • the Blockchain may utilize one or more smart contracts executing on the Blockchain to provide the determination.
  • Smart contracts are computer protocols implemented in the form of computer code that are incorporated into the Blockchain, to facilitate, verify, or enforce the negotiation or performance of contracts.
  • users of the Blockchain may program agreed terms into a smart contract using a programming language, such as C++, Java, Solidity, Python, etc., and when the terms are met, the smart contract may be automatically executed on the Blockchain, e.g., to perform a transaction.
  • the smart contract may include a plurality of subroutines or functions, each of which may be a sequence of program instructions that performs a specific task.
  • the smart contract may be operational code that is fully or partially executed without human interaction.
  • a smart contract may be incorporated into the Blockchain to determine whether the proof is acceptable.
  • the smart contract may verify the proof using the public input and the verification key. If the proof cannot be verified, the smart contract may refuse to allow the Client to proceed further. On the other hand, if the proof can be verified, then the smart contract may determine that the proof is acceptable and, at step 408, proceed to set the current state of the record recorded on the Blockchain to S * as specified by the Client. Subsequent to step 408, s * becomes the current state of the record and the protected value of s * , denoted as S * in the descriptions above, becomes the current state of the record as recorded on the Blockchain.
  • the process depicted in FIG. 4 may be repeated each time the Client attempts to update the state of the record.
  • the Blockchain can detect invalid state transitions and prevent fraudulent attempts by the Client to bypass certain states even if the states and operations are encrypted or otherwise protected by the Client.
  • the Blockchain may allow the public to verify the validity of state transitions performed on a record, but the public may not be able to decipher what the record’s current state is, nor its previous state or the operation being performed, thereby preserving the Client’s privacy.
  • FIG. 5 illustrates a flow chart of a method 500 for protecting and verifying state transition of a record, according to an embodiment.
  • the method 500 may be performed by one or more nodes in a blockchain system, e.g., the nodes 102-110 in the blockchain system 100 (FIG. 1) .
  • the nodes 102-110 in the blockchain system 100 may perform operations on a blockchain, e.g., the blockchain 120 (FIG. 1) .
  • the blockchain 120 may be implemented as the Blockchain in the examples described above.
  • a node may receive a transaction submitted by a user.
  • the user may be, e.g., the Client (FIG. 4)
  • the transaction submitted by the user may include an “UPDATE” transaction (FIG. 4) .
  • the transaction may include an identification of a record (e.g., the record_ID) , a protected operation value (e.g., F) representing an operation f to be performed with respect to the record, a protected state value (e.g., S * ) representing a state s * of the record after performing the operation f, and a proof prepared by the user.
  • the protected operation value F may be generated (e.g., using an encryption scheme, a commitment scheme, a one-way function, or the like) based on a plaintext value representing the operation f
  • the protected state value S * may be generated (e.g., using an encryption scheme, a commitment scheme, a one-way function, or the like) based on a plaintext value representing the state s *
  • the node 102 may not receive the plaintext value of the operation f and the plaintext value of the state s * from the user.
  • the node 102 may determine whether the proof is acceptable. In some embodiments, the node 102 may determine whether the proof is acceptable based on whether the proof indicates that the user is in possession of information, such as the secret input w, which is generated at least partially based on the plaintext value of the operation f and the plaintext value of the state s * . In some embodiments, the proof may be a zero-knowledge proof. In such embodiments, the node 102 may determine whether the proof is acceptable without accessing the plaintext value of the operation f and the plaintext value of the state s * .
  • the proof may be generated by the user to prove that the protected operation value F corresponds to a valid operation f that can transition the record from a first (current) state s to second (next) state s * , and that the protected state value S * represents the protected state value of the second (next) state s * .
  • the node 102 may determine whether the proof is acceptable based on whether the proof can show that the user has knowledge of the first state s of the record. The node 102 may also determine whether the proof is acceptable based on whether the proof can show that the user has knowledge of the second state s * of the record. The node 102 may further determine whether the proof is acceptable based on whether the proof can show that the user has knowledge of the operation f to be performed with respect to the record. The 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 that transitions the record from the first state s to the second state s * .
  • the user may prove to the 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 true.
  • the node 102 may determine whether the proof is acceptable by verifying the proof using the public input x and the verification key as described above. In some embodiments, if the node 102 accepts the user’s proof that the user is in possession of the secret input w, the node 102 may accept the user’s statements as true.
  • the node 102 may refuse to process the transaction submitted by the user. In this manner, the node 102 can detect invalid state transitions and prevent fraudulent attempts by users to bypass certain states.
  • the node 102 may set the recorded state of the record to the protected state value S * . In this manner, the node 102 can verify the validity of state transitions performed on the record without the need to decipher the plaintext value of the operation f and the plaintext value of the state s * . In some embodiments, the method 500 may be repeated each time the user attempts to update the state of the record.
  • FIG. 6 is a block diagram of a state transition verification apparatus 600, according to an embodiment.
  • the apparatus 600 may be an implementation of a software process, and may correspond to the method 500 (FIG. 5) .
  • the apparatus 600 may include a receiving module 602, a determination module 604, a rejection module 606, and a recording module 608.
  • the receiving module 602 may receive a transaction submitted by a user.
  • the transaction may include an “UPDATE” transaction (FIG. 4) , which may include an identification of a record (e.g., the record_ID) , a protected operation value (e.g., F) representing an operation f to be performed with respect to the record, a protected state value (e.g., S * ) representing a state s * of the record after performing the operation f, and a proof prepared by the user.
  • the receiving module 602 may provide the received transaction to the determining module 504.
  • the determining module 604 may determine whether the proof is acceptable. In response to a determination that the proof is unacceptable, the determining module 604 may request the rejection module 606 to refuse to process the transaction submitted by the user. Otherwise, the determining module 604 may provide the transaction to the recording module 608, which may set the recorded state of the record to the protected state value S * . In this manner, the state transition verification apparatus 600 can detect invalid state transitions and prevent fraudulent attempts by users to bypass certain states. The state transition verification apparatus 600 can also verify the validity of state transitions performed on the record without the need to decipher the plaintext value of the operation f and the plaintext value of the state s * , thereby preserving the user’s privacy.
  • each of the above described modules may be implemented as software, or hardware, or a combination of software and hardware.
  • each of the above described modules may be implemented using a processor executing instructions stored in a memory.
  • each the above described modules may be implemented with 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, micro-controllers, microprocessors, or other electronic components, for performing the described methods.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • controllers micro-controllers, microprocessors, or other electronic components, for performing the described methods.
  • each of the above described modules may be implemented by using a computer chip or an entity, or implemented by using a product having
  • the apparatus 600 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device, or any combination of these devices.
  • a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to carry out the above-described methods.
  • the computer-readable storage medium may be a tangible device that can store instructions for use by an instruction execution device.
  • the computer-readable storage medium may be, for example, but is 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 of the foregoing.
  • a non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, 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 mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • SRAM static random access memory
  • CD-ROM compact disc read-only memory
  • DVD digital versatile disk
  • memory stick a floppy disk
  • a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon
  • the computer-readable program instructions for carrying out the above-described methods may be assembler 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 an object oriented programming language, and conventional procedural programming languages.
  • the computer-readable program instructions may execute entirely on a computing device as a stand-alone software package, or partly on a first computing device and partly on a second computing device remote from the first computing device. In the latter scenario, the second, remote computing device may be connected to the first computing device through any type of network, including a local area network (LAN) or a wide area network (WAN) .
  • LAN local area network
  • WAN wide area network
  • the computer-readable program instructions may be provided to a processor of a general-purpose or special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the above-described methods.
  • a block in the flow charts or diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing specific functions.
  • the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
  • each block of the diagrams and/or flow charts, and combinations of blocks in the diagrams and flow charts may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un certain nombre de procédés, de dispositifs et d'appareils, y compris des programmes d'ordinateur stockés sur des supports lisibles par ordinateur, pour la vérification d'une transition d'état d'un enregistrement. L'un des procédés comprend : la réception d'une transaction soumise par un utilisateur, la transaction comprenant un identificateur de l'enregistrement, une valeur d'opération protégée représentant une opération à exécuter relativement à l'enregistrement, une valeur d'état protégée représentant un état de l'enregistrement après exécution de l'opération, et une preuve préparée par l'utilisateur (502); la détermination de l'acceptabilité ou non de la preuve sur la base du fait que la preuve indique ou non que l'utilisateur est en possession d'une entrée secrète (504); en réponse à une détermination du fait que la preuve est inacceptable, le refus de traitement de la transaction soumise par l'utilisateur (506); et en réponse à une détermination du fait que la preuve est acceptable, le réglage d'un état enregistré de l'enregistrement à la valeur d'état protégée (508).
PCT/CN2021/091022 2020-05-04 2021-04-29 Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement WO2021223653A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202180011181.6A CN115023721A (zh) 2020-05-04 2021-04-29 用于保护和验证记录的状态转换的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202004057Y 2020-05-04
SG10202004057YA SG10202004057YA (en) 2020-05-04 2020-05-04 Methods and Devices for Protecting and Verifying State Transition of Record

Publications (1)

Publication Number Publication Date
WO2021223653A1 true WO2021223653A1 (fr) 2021-11-11

Family

ID=72290711

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/091022 WO2021223653A1 (fr) 2020-05-04 2021-04-29 Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement

Country Status (3)

Country Link
CN (1) CN115023721A (fr)
SG (1) SG10202004057YA (fr)
WO (1) WO2021223653A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG10202004057YA (en) * 2020-05-04 2020-08-28 Alipay Labs Singapore Pte Ltd Methods and Devices for Protecting and Verifying State Transition of Record

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110008715A (zh) * 2019-01-31 2019-07-12 阿里巴巴集团控股有限公司 区块链中实现隐私保护的方法及节点、存储介质
CN110084068A (zh) * 2018-01-26 2019-08-02 阿里巴巴集团控股有限公司 区块链系统及用于区块链系统的数据处理方法
US20190243986A1 (en) * 2018-02-06 2019-08-08 Coinplug, Inc. Method for managing information using tree structure based on blockchain, server and terminal using the same
SG10202004057YA (en) * 2020-05-04 2020-08-28 Alipay Labs Singapore Pte Ltd Methods and Devices for Protecting and Verifying State Transition of Record

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110084068A (zh) * 2018-01-26 2019-08-02 阿里巴巴集团控股有限公司 区块链系统及用于区块链系统的数据处理方法
US20190243986A1 (en) * 2018-02-06 2019-08-08 Coinplug, Inc. Method for managing information using tree structure based on blockchain, server and terminal using the same
CN110008715A (zh) * 2019-01-31 2019-07-12 阿里巴巴集团控股有限公司 区块链中实现隐私保护的方法及节点、存储介质
SG10202004057YA (en) * 2020-05-04 2020-08-28 Alipay Labs Singapore Pte Ltd Methods and Devices for Protecting and Verifying State Transition of Record

Also Published As

Publication number Publication date
SG10202004057YA (en) 2020-08-28
CN115023721A (zh) 2022-09-06

Similar Documents

Publication Publication Date Title
US20240152884A1 (en) Digital currency minting in a system of network nodes implementing a distributed ledger
EP3937050B1 (fr) Gestion de transactions dans de multiples réseaux de chaîne de blocs
EP3665595B1 (fr) Procédé et dispositif pour traversée de données
US20220311611A1 (en) Reputation profile propagation on blockchain networks
US11804950B2 (en) Parallel processing of blockchain procedures
WO2021139391A1 (fr) Procédés et dispositifs pour réduire la fraude de financement de facture
WO2020182233A2 (fr) Procédés et dispositifs d'exécution de contrats à swaps multiples anonymes à chaînes croisées
US11374755B1 (en) Entangled token structure for blockchain networks
WO2021223653A1 (fr) Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement
WO2020182234A2 (fr) Procédés et dispositifs d'appariement de transactions basés sur un système de chaîne de blocs
WO2021139605A1 (fr) Procédés et dispositifs de fourniture de vérification d'identité décentralisée
WO2021139543A1 (fr) Procédés et dispositifs de gestion de lettre de crédit de soutien
WO2021139544A1 (fr) Procédés et dispositifs pour atténuer la fraude de financement de facture
WO2023099357A1 (fr) Chaînes de blocs compressibles
US20230188353A1 (en) Multi-issuer anonymous credentials for permissioned blockchains
WO2021139545A1 (fr) Procédés et dispositifs destiné à faciliter le financement scindé de factures
US20220399988A1 (en) Linking blockchain operations
US11956360B2 (en) Provable trade secrets on blockchain networks
WO2021223661A1 (fr) Procédés et dispositifs de protection et de vérification d'informations d'état d'enregistrement
WO2021023094A1 (fr) Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois
US20220036355A1 (en) Methods and devices for privacy-preserving verification of profit-sharing between users
US12010226B2 (en) Blockchain data segregation
WO2022193920A1 (fr) Ségrégation de données de chaîne de blocs
US20230403161A1 (en) Aggregate anonymous credentials for decentralized identity in blockchain
WO2021139392A1 (fr) Procédés et dispositifs de fourniture de transaction atomique sur une chaîne de blocs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21799860

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21799860

Country of ref document: EP

Kind code of ref document: A1