Blockchain-based asset publishing method and device, and electronic device

Abstract

A blockchain-based asset issuance method, comprising: receiving an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction comprises: at least inputting the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value; initiating a zero-knowledge proof of the commitment value based on the zero-knowledge evidence, verifying whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer; if so, publishing the commitment value to the blockchain for evidence storage.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain-based asset issuance method and device, and electronic device. Background Art

[0002] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Blockchain technology has been widely used in many fields because of its decentralized, open and transparent characteristics, each computing device can participate in database records, and data can be quickly synchronized between computing devices. Summary of the invention

[0003] This specification proposes a blockchain-based asset issuance method, which is applied to a node device in the blockchain, including:

[0004] Receiving an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: inputting at least the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0005] Initiate a zero-knowledge proof of the commitment value based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer;

[0006] If so, the commitment value is published to the blockchain for evidence storage.

[0007] This specification also proposes an asset issuance device based on blockchain, which is applied to a node device in the blockchain, including:

[0008] A receiving module receives an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: inputting at least the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0009] A verification module, which initiates a zero-knowledge proof of the commitment value based on the zero-knowledge evidence, and verifies whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0010] The evidence storage module, if yes, publishes the commitment value to the blockchain for evidence storage.

[0011] This specification also proposes an electronic device, comprising:

[0012] processor;

[0013] memory for storing machine-executable instructions;

[0014] Wherein, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based asset issuance stored in the memory, the processor is prompted to:

[0015] Receive an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: inputting at least the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0016] Initiate a zero-knowledge proof of the commitment value based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer;

[0017] If so, the commitment value is published to the blockchain for evidence storage.

[0018] Through the above embodiments, on the one hand, since the asset issuance transaction only carries at least the asset type of the target asset object to be issued as input data to the commitment function to calculate the commitment value, and does not carry the asset type of the target asset object in plain text in the asset issuance transaction, the blockchain can hide the asset type of the target asset object issued by the asset issuer, thereby protecting the privacy of the asset issuer;

[0019] On the other hand, since the above-mentioned asset issuance transaction also carries zero-knowledge evidence for zero-knowledge proof of the above-mentioned commitment value, the node devices in the blockchain can perform zero-knowledge proof on the above-mentioned zero-knowledge evidence on the premise of hiding the asset type issued by the asset issuer to verify whether the asset type of the target asset object issued by the above-mentioned asset issuer is a legal asset type allowed to be issued by the asset issuer. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flowchart of a blockchain-based asset issuance method provided by an exemplary embodiment.

[0021] Figure 2 It is a schematic structural diagram of an electronic device provided by an exemplary embodiment.

[0022] Figure 3 It is a block diagram of a blockchain-based asset issuance device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0023] Zero Knowledge Proof is a cryptographic technique that allows a prover to convince one or more verifiers that a statement is correct without providing any sensitive information to the verifier.

[0024] The purpose of this specification is to disclose a technical solution that organically combines the Zero Knowledge Proof algorithm with the asset publishing mechanism of the blockchain, so that the node devices in the blockchain can normally verify whether the asset type published by the asset publisher is a legal asset type allowed to be published by the asset object under the premise of hiding the asset type published by the asset publisher.

[0025] In implementation, when the asset issuer needs to publish the created asset object on the blockchain, the asset type of the target asset object that the asset issuer wants to publish this time can be used as input data (the input data can also contain other types of information that need to be hidden; for example, the public key of the asset recipient), and input into the commitment function for calculation to obtain the commitment value; and based on the zero-knowledge proof algorithm carried by the blockchain, a zero-knowledge proof (proof) for zero-knowledge proof of the above commitment value can be generated. Then, the asset issuer can construct an asset release transaction based on the above commitment value and the above zero-knowledge proof, and publish the above target asset object by sending the above asset release transaction in the blockchain.

[0026] When the node device in the blockchain receives the above-mentioned asset issuance transaction, it can obtain the above-mentioned commitment value carried in the above-mentioned asset issuance transaction, as well as the above-mentioned zero-knowledge evidence, and then can initiate zero-knowledge proof of the above-mentioned commitment value based on the above-mentioned zero-knowledge evidence through the above-mentioned zero-knowledge proof algorithm to verify whether the asset type of the above-mentioned target asset object is a legal asset type allowed to be issued by the asset issuer.

[0027] If it is verified that the asset type of the target asset object is a legal asset type allowed to be released by the asset issuer, the commitment value can be published to the blockchain for evidence storage to complete the release process of the target asset object.

[0028] In the above technical solution, on the one hand, since the asset issuance transaction only carries at least the asset type of the target asset object to be issued as input data to the commitment function to calculate the commitment value, and does not carry the asset type of the target asset object in plain text in the asset issuance transaction, the blockchain can hide the asset type of the target asset object issued by the asset issuer and protect the privacy of the asset issuer;

[0029] On the other hand, since the above-mentioned asset issuance transaction also carries zero-knowledge evidence for zero-knowledge proof of the above-mentioned commitment value, the node devices in the blockchain can perform zero-knowledge proof on the above-mentioned zero-knowledge evidence on the premise of hiding the asset type issued by the asset issuer to verify whether the asset type of the target asset object issued by the above-mentioned asset issuer is a legal asset type allowed to be issued by the asset issuer.

[0030] The present specification is described below through specific embodiments and in combination with specific application scenarios.

[0031] Please refer to Figure 1 , Figure 1 This is a blockchain-based asset issuance method provided in an embodiment of this specification, which is applied to a node device in a blockchain and performs the following steps:

[0032] Step 102, receiving an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: inputting at least the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0033] Step 104, initiating a zero-knowledge proof of the commitment value based on the zero-knowledge evidence, and verifying whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0034] Step 106: If yes, publish the commitment value to the blockchain for evidence storage.

[0035] The blockchain described in this specification may specifically include any type of blockchain network that can cover asset objects among the supported objects.

[0036] For example, in a traditional blockchain, the supported objects usually only include account objects and contract objects. In this specification, the objects supported by the blockchain can be expanded, and an asset object can be further expanded based on the existing support of the blockchain such as account objects and contract objects.

[0037] It should be noted that the type of blockchain described in this specification is not specifically limited, and it can be a consortium chain or other types of blockchain other than the consortium chain (such as a private chain, a public chain, etc.).

[0038] The above-mentioned contract object may specifically include a smart contract program published by the target member in the blockchain and recorded in the distributed database of the blockchain (i.e., the blockchain ledger) for managing the asset objects supported by the blockchain. Users who access the blockchain can create an asset object on the blockchain by calling the above-mentioned contract object, and complete the online management of the asset objects held on the blockchain.

[0039] For example, in one example, the above blockchain can be a consortium chain composed of several financial institutions that are members of the consortium. In this case, the target member in the blockchain can be a financial institution that is a member of the consortium chain and has the authority to create asset objects. A distributed smart contract platform can be built through the consortium chain. The operator of the smart contract platform can expand the object types supported by the smart contract platform. On the basis of existing supported objects such as account objects and contract objects, an asset object can be further expanded, so that financial institutions that are members of the consortium can create a new asset type in the platform by publishing a smart contract (contract object) on the blockchain. Then, users who access the blockchain can create an asset object and complete the online management of the asset objects held by calling the smart contract.

[0040] The above-mentioned asset objects may include smart asset objects; smart asset objects are used to maintain smart assets, which correspond to any type of real assets of the user in the real world, and through smart asset objects, the smart assets can be applied to processing in the blockchain, such as being particularly suitable for processing the smart asset objects through smart contracts in the blockchain. Among them, the type of real assets corresponding to the user in the real world is not particularly limited in this specification;

[0041] For example, taking the above-mentioned blockchain as an alliance chain composed of several financial institutions, in actual applications, any form of user offline assets; for example, funds, real estate, stocks, loan contracts, bills, accounts receivable, etc. can be packaged into the form of digital assets by the financial institutions that manage the node devices on the alliance chain, created and published in the distributed database of the alliance chain.

[0042] The transaction described in this specification refers to a piece of data created by a user through a blockchain client and ultimately published to the distributed database of the blockchain.

[0043] Among them, transactions in the blockchain can be divided into transactions in a narrow sense and transactions in a broad sense. A transaction in a narrow sense refers to a value transfer published by a user to the blockchain; for example, in a traditional blockchain network, a transaction can be a transfer initiated by a user in the blockchain. A transaction in a broad sense refers to a business data with business intent published by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types of online businesses that are not related to value transfer (for example, virtual asset business, rental business, vehicle dispatch business, insurance claims business, credit services, medical services, etc.), and in this type of consortium chain, a transaction can be a business message or business request with business intent published by a user in the consortium chain.

[0044] It should be noted that the consensus algorithm carried by the above-mentioned blockchain is not specifically limited in this specification; in practical applications, a Byzantine Fault Tolerance series of algorithms can be used as a consensus algorithm, or a non-Byzantine Fault Tolerance series of algorithms can be used as a consensus algorithm.

[0045] Among them, the so-called Byzantine fault-tolerant algorithm refers to a distributed fault-tolerant algorithm that needs to consider Byzantine nodes (i.e., malicious nodes) in a distributed network composed of several node devices; for example, the pbft algorithm; if the Byzantine fault-tolerant algorithm is used for consensus processing in the blockchain network, it will be considered that there are both malicious nodes and faulty nodes in the blockchain. Correspondingly, the so-called non-Byzantine fault-tolerant algorithm refers to a distributed fault-tolerant algorithm that does not consider Byzantine nodes in a distributed network composed of several node devices; for example, the raft algorithm, etc.; if the non-Byzantine fault-tolerant algorithm is used for consensus processing in the blockchain network, it will be considered that there are no malicious nodes in the blockchain, but only faulty nodes.

[0046] In one embodiment shown, the blockchain can be a consortium chain consisting of several credible financial institutions as consortium members. Financial institutions with asset object publishing authority in the consortium chain can create a new asset type in the platform by publishing a smart contract (contract object) on the consortium chain, and can publicly publish the new asset type in the consortium chain.

[0047] The specific process of financial institutions issuing smart contracts in the alliance chain will not be described in detail in this manual. Those skilled in the art can refer to the records in the relevant technology.

[0048] For example, in actual applications, financial institutions can publish a transaction to the alliance chain based on the private key they hold, and publish the created smart contract to the alliance chain. When the alliance members in the alliance chain receive transactions issued by other financial institutions through the node devices they manage, they can use the consensus algorithm of the alliance chain to conduct consensus processing on the transactions issued in the alliance chain in the recent period, and after the consensus processing is completed, the smart contract issued by the transaction will be included in the distributed database of the alliance chain.

[0049] In the smart contract corresponding to the newly added asset type published in the alliance chain, the financial institution can pre-declare the execution program for creating the asset object. As the asset publisher, the financial institution can create one or more target asset objects to be published online by calling the execution program declared in the above smart contract, and then save the original information of the created target asset object locally;

[0050] For example, in actual applications, the asset publisher may save the original information of the created target asset object (such as asset type information, asset quantity, etc.) locally in the form of a voucher.

[0051] After completing the creation of the above-mentioned target asset object, the asset publisher can further construct an asset publishing transaction based on the original information of the above-mentioned target asset object stored locally, and then send the asset publishing transaction to the blockchain to publish the target asset object.

[0052] It should be noted that in actual applications, in some digital asset systems built on blockchain, usually only some trusted asset issuers are allowed to publish one or more specific types of asset objects;

[0053] For example, in a foreign exchange exchange system based on blockchain, digital assets that can be published on the blockchain may include multiple types of foreign exchange assets; and some reputable financial institutions can act as asset issuers and may only allow the publication of one or more specific foreign exchange assets on the blockchain to provide liquidity. For example, a bank's Hong Kong branch, as an asset issuer, may only allow the publication of Hong Kong onshore Hong Kong dollar assets and Hong Kong onshore US dollar assets in the foreign exchange exchange system.

[0054] Moreover, for the purpose of privacy protection, it may be necessary to hide the asset type of the published target asset object and other forms of private data related to the target asset object;

[0055] For example, in addition to hiding the asset type of the published target asset object, it may also be necessary to hide the asset quantity of the published target asset object and the identity of the asset publisher.

[0056] Based on this, in this specification, when the asset issuer publishes the above-mentioned target asset object that has been created on the blockchain, it is no longer necessary to directly carry the privacy data such as the asset type of the target asset object in the constructed asset publishing transaction. The above-mentioned asset issuer can act as the prover of the zero-knowledge proof, and at least take the asset type of the target asset object to be published as input data, input it into the commitment function to calculate the commitment value, and use the zero-knowledge proof algorithm carried by the blockchain to generate zero-knowledge evidence for zero-knowledge proof of the above-mentioned commitment value, and then carry the generated commitment value and the above-mentioned zero-knowledge evidence in the constructed asset publishing transaction and send them on the blockchain to publish the target asset object.

[0057] 1) Generation of Commitment Value

[0058] The above commitment function is a one-way function that is often used in the fields of cryptography, security, and privacy protection to commit to original data without leaking the original data. The output value of the commitment function is called the commitment value (or simply commitment). Based on the characteristics of the one-way function, after the original data is input into the commitment function to calculate the commitment value, the original data cannot be restored from the commitment value by reverse calculation. At the same time, it is impossible to find two different original data so that their commitment values ​​are equal.

[0059] For example, in one implementation shown, the commitment function may generally adopt a hash function; in this case, the commitment value may be a hash value obtained by inputting at least the asset type of the target asset object to be released as input data into the hash function for calculation.

[0060] It should be noted that, in this specification, the specific content of the input data used when calculating the above commitment value based on the commitment function usually depends on the content that needs to be hidden when publishing the target asset object.

[0061] In actual applications, the input data of the commitment function may include not only the asset type of the target asset object that needs to be hidden, but also the asset quantity of the target asset object, the public key of the recipient of the target asset object (the recipient can be the asset issuer or a third party), and a generated random number, etc., which will not be listed one by one in this manual.

[0062] 2) Generation of Zero-Knowledge Evidence

[0063] In this specification, the algorithm type of the zero-knowledge evidence algorithm carried by the blockchain is not specifically limited in this specification;

[0064] For example, in one embodiment shown, the blockchain can be equipped with general zero-knowledge proof algorithms such as the zksnark algorithm and the zkstark algorithm; for example, during implementation, the execution code related to the algorithmic logic of the zero-knowledge proof algorithm such as the zksnark algorithm and the zkstark algorithm can be embedded in the smart contract and published to the blockchain; then, the smart contract can be called to execute the execution code related to the algorithmic logic of the zero-knowledge proof algorithm embedded in the smart contract to complete the generation of the proof, as well as the zero-knowledge verification of the proof and other zero-knowledge proof processes.

[0065] Among them, the zero-knowledge algorithm carried by the blockchain can usually include a key generation algorithm, a proof generation algorithm, and a proof verification algorithm. The key generation algorithm is responsible for calculating and generating the proof key (which can be used as input data for generating proof) and the verification key (which can be used as input data for verifying proof); the proof generation algorithm is responsible for generating proof; and the proof verification algorithm is responsible for verifying proof and obtaining a true or false verification result.

[0066] For example, taking the zksnark algorithm as an example, the zksnark algorithm consists of three algorithms: G, P, and V. The G algorithm is a key generator responsible for generating proof keys and verification keys; the P algorithm is responsible for generating proofs, and the V algorithm is responsible for verifying the proofs generated by the P algorithm to obtain true or false verification results.

[0067] Among them, it should be noted that when the asset issuer calculates the proof based on the zero-knowledge evidence generation algorithm carried by the blockchain, the specific content of the input data used usually depends on the conclusion that ultimately needs to be zero-knowledge proved.

[0068] In this specification, the assertion that ultimately needs to be zero-knowledge proved may specifically include whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue.

[0069] Of course, the specific content of the assertion that ultimately needs to be zero-knowledge proved usually depends on the specific needs of the user. In practical applications, the assertion that ultimately needs to be zero-knowledge proved may also include other assertions in addition to the assertions described above, which will not be listed one by one in this manual.

[0070] (1) Proof generation method 1

[0071] In one embodiment shown, based on the above assertion that zero-knowledge proof is required, the specific content of the input data used by the asset issuer when calculating the proof based on the zero-knowledge evidence generation algorithm may at least include the commitment value calculated by the commitment function, and the legal asset types that the asset issuer is allowed to issue.

[0072] That is, the asset issuer needs to at least input the above commitment value and the legal asset type that the asset issuer is allowed to issue as input data into the zero-knowledge proof generation algorithm for calculation to generate a proof for zero-knowledge proof of the above commitment value.

[0073] (1) Proof generation method 2

[0074] In another embodiment shown, the node device may also locally maintain a verification rule for verifying whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0075] In this case, based on the above assertion that zero-knowledge proof is required, the specific content of the input data used by the asset issuer when calculating the proof based on the zero-knowledge evidence generation algorithm also needs to include verification data related to the above verification rules.

[0076] That is, the asset issuer needs to at least input the verification data related to the above verification rules into the zero-knowledge proof generation algorithm for calculation to generate a proof for zero-knowledge proof of the above commitment value.

[0077] It should be noted that when the above-mentioned asset issuer publishes the above-mentioned target asset object on the blockchain, in addition to hiding the asset type of the published target asset object in the transaction, in actual application, the above-mentioned blockchain can also selectively hide the identity information of the transaction issuer.

[0078] In one embodiment shown, if the blockchain does not support hiding the identity information of the transaction issuer, the identity of the asset issuer that issues the target asset object is completely public.

[0079] When a node device in the blockchain receives an asset publishing transaction sent by the above-mentioned asset issuer, it only needs to verify through zero-knowledge proof whether the asset type of the target asset object is a legal asset type allowed to be published by the asset issuer, and does not need to perform zero-knowledge proof on the identity of the asset issuer (i.e. verify that the asset issuer is one of all legal asset issuers).

[0080] In this case, the input data for calculating the above zero-knowledge proof does not need to include the additional private key of the asset issuer.

[0081] In one embodiment shown, if the above-mentioned blockchain supports hiding the identity information of the transaction issuer, the identity of the asset issuer who issues the above-mentioned target asset object is not completely public at this time; when the node device in the blockchain receives the asset issuance transaction sent by the above-mentioned asset issuer, in addition to verifying through zero-knowledge proof whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer, it is also necessary to further verify whether the above-mentioned asset issuer holds the private key corresponding to the public key of the legal asset issuer.

[0082] That is, in addition to the need for zero-knowledge proof that the asset type of the asset object published by the asset issuer is a legal asset type that the asset issuer is allowed to publish, it is also necessary to verify whether the asset issuer is one of all legal asset issuers.

[0083] In this case, the input data when calculating the above zero-knowledge proof needs to additionally include the private key of the asset issuer.

[0084] 3) Zero-knowledge verification of commitment value

[0085] When a node device in the blockchain (such as a node device participating in consensus) receives an asset release transaction sent by the above-mentioned asset issuer, it can obtain information such as the proof and commitment value carried in the above-mentioned asset release transaction, and initiate a zero-knowledge proof of the above-mentioned commitment value based on the above-mentioned proof to confirm whether the asset type of the above-mentioned target asset object is a legal asset type allowed to be released by the asset issuer.

[0086] Specifically, the node device, as the verifier of the zero-knowledge proof, at least inputs the proof and the commitment value as input data of the zero-knowledge verification algorithm into the zero-knowledge proof verification algorithm for calculation, and then determines whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer based on the output result of the zero-knowledge proof verification algorithm;

[0087] For example, taking the zksnark algorithm as an example, when performing zero-knowledge verification on the proof, the above proof and the above commitment value can be used as input data and input into the V algorithm in the zksnark algorithm for calculation; if the output result of the V algorithm is true, it means that the above assertion requiring zero-knowledge proof is true, and at this time, the asset type of the above target asset object is a legal asset type that the above asset issuer is allowed to publish; otherwise, the output result of the V algorithm is false, indicating that the above assertion requiring zero-knowledge proof is false, and at this time, the asset type of the above target asset object is an illegal asset type that the above asset issuer is not allowed to publish.

[0088] It should be pointed out that, in this specification, the node device in the blockchain, as the verifier of the zero-knowledge proof, can also locally configure the verification rules for the zero-knowledge proof of the above assertions.

[0089] The following describes in detail the specific process of performing zero-knowledge proof of the above assertion when generating proof according to the proof generation method 1 and generation method 2 described above.

[0090] In this specification, if a node device generates a proof according to the proof generation method one described above, the node device, as the verifier of the zero-knowledge proof, shall use the zero-knowledge evidence verification algorithm to perform zero-knowledge proof on the above-mentioned commitment value. In addition to the above-mentioned commitment value and the above-mentioned proof, the specific content of the input data used may also include verification data related to the verification rules for performing zero-knowledge proof on the above-mentioned assertion locally configured by the above-mentioned node device as auxiliary data of the zero-knowledge proof.

[0091] Of course, in some scenarios, if the above commitment value and the above proof are used as input data, it is sufficient to complete the zero-knowledge proof of the above assertion. Then, in the input data used when the above zero-knowledge evidence verification algorithm is used to perform zero-knowledge proof on the above commitment value, the verification data related to the above verification rules can also be a null value.

[0092] It should be noted that the specific content of the verification rules described above for zero-knowledge proof of the above assertions is not particularly limited in this specification and is described below in conjunction with specific scenarios.

[0093] For the proof generation method 1 shown above, the node device, which serves as the verifier of the zero-knowledge proof, can verify the asset type of the target asset object by means of zero-knowledge proof to see whether it matches the legal asset type allowed to be published by the asset publisher, and confirm whether the asset type of the target asset object is the legal asset type allowed to be published by the asset publisher.

[0094] In one embodiment shown, a node device serving as a verifier of zero-knowledge proof may construct an asset type list based on the legal asset types that the asset issuer is allowed to publish, and maintain the asset type list locally.

[0095] The above validation rules may specifically include:

[0096] Verify whether the asset type of the target asset object is included in the asset type list; if so, confirm that the asset type of the target asset object is a legal asset type that the asset publisher is allowed to publish.

[0097] In this scenario, the verification data related to the above verification rules can be the above asset type list. That is, the above node device can use the above commitment value, proof and the above asset type list as input data and input them into the zero-knowledge proof verification algorithm for calculation to complete the zero-knowledge proof of the above commitment value.

[0098] In another embodiment shown, the node device serving as the verifier of the zero-knowledge proof may also construct a hash tree based on the hash values ​​of the legal asset types that the asset issuer is allowed to publish, and maintain the hash tree locally.

[0099] The above validation rules may specifically include:

[0100] Verify whether the hash value of the asset type of the target asset object is contained in the hash tree; if so, confirm that the asset type of the target asset object is a legal asset type that the asset publisher is allowed to publish.

[0101] In this scenario, the verification data related to the verification rule may be the hash tree. The node device may input the commitment value, proof and hash tree into the zero-knowledge proof verification algorithm for calculation to complete the zero-knowledge proof of the commitment value.

[0102] It should be noted that, in the two cases where the above-mentioned blockchain supports hiding the identity information of the transaction issuer and does not support hiding the identity information of the transaction issuer, there will be certain differences in the content format of the above-mentioned asset type list and the above-mentioned hash tree maintained locally by the above-mentioned node device.

[0103] On the one hand, if the blockchain supports hiding the identity information of the transaction issuer, the legal asset types that an asset issuer is allowed to issue can be represented in the form of a <asset issuer public key, legal asset type list> pair.

[0104] In this case, the node device can first generate the asset type list based on the <asset issuer public key, legal asset type list> pairs that all legal asset issuers are allowed to publish; secondly, it can also create the hash tree based on the hash value of the <asset issuer public key, legal asset type list> pairs that all legal asset issuers are allowed to publish.

[0105] Accordingly, in this case, the node device needs to prove zero-knowledge whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue, which can be specifically expressed as:

[0106] The above-mentioned asset issuer holds the private key corresponding to the public key of the legal asset issuer, the asset type of the above-mentioned target asset object is included in the <asset issuer public key, legal asset type list> pair corresponding to the public key of the asset issuer, and the <asset issuer public key, legal asset type list> pair corresponding to the public key of the above-mentioned asset issuer is included in the above-mentioned hash tree.

[0107] That is, in this case, when the node device performs zero-knowledge proof of whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue, it needs to prove that the asset issuer holds the private key corresponding to the public key of the legal asset issuer, that the asset type of the target asset object is included in the <asset issuer public key, legal asset type list> pair corresponding to the public key of the asset issuer, and that the <asset issuer public key, legal asset type list> pair corresponding to the public key of the asset issuer is included in the hash tree.

[0108] In addition, it should be noted that in this scenario, since the above hash tree is created based on the hash value of the <asset issuer public key, legal asset type list> pair allowed to be released by all legal asset issuers, it is no longer necessary to input the legal asset type list allowed to be released by the asset issuer into the zero-knowledge evidence generation algorithm to calculate the proof in the input data when calculating the proof. Instead, the hash value of the legal asset type list allowed to be released by the asset issuer and the path in the above hash tree are input as input data to the zero-knowledge evidence generation algorithm for calculation.

[0109] In this way, compared with directly inputting the above-mentioned list of legal asset types, or a hash tree created based on the hash values ​​of the legal asset types allowed to be released by the asset issuer as input data into the zero-knowledge evidence generation algorithm for calculation, the amount of input data can be reduced and the calculation efficiency can be improved.

[0110] On the other hand, if the blockchain does not support hiding the identity information of the transaction issuer, the above-mentioned node device can directly generate the above-mentioned asset type list based on the legal asset types that the asset issuer is allowed to publish; or, create the above-mentioned hash tree based on the hash value of the legal asset type that the asset issuer is allowed to publish.

[0111] In this case, the node device needs zero-knowledge proof of whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue. This does not need to be specially represented. Zero-knowledge proof can be used to verify whether the asset type of the target asset object is included in the asset type list; or, the hash value of the asset type of the target asset object can be verified to be included in the hash tree. No further details are required.

[0112] In this specification, if the node device generates proof according to the second proof generation method described above, the node device, as the verifier of the zero-knowledge proof, may include verification data related to the above-mentioned verification rules when using the zero-knowledge evidence verification algorithm to perform zero-knowledge proof on the above-mentioned commitment value.

[0113] Among them, when using the proof generation method 1 and generation method 2 shown above, the specific content of the above verification rules will be different to a certain extent.

[0114] Regarding the second proof generation method shown above, in addition to verifying whether the asset type of the target asset object matches the legal asset type allowed to be released by the asset issuer, the node device as the verifier of the zero-knowledge proof can also verify whether the asset type of the target asset object and the public key of the target asset issuer meet specific adaptation rules to confirm whether the asset type of the target asset object is a legal asset type allowed to be released by the asset issuer.

[0115] For example, for each asset issuer, a prefix or suffix that is completely identical to the public key of a legitimate asset issuer, or to the prefix or suffix of the public key of a legitimate asset issuer, or to the hash value of the public key of the above-mentioned legitimate asset issuer, or to the prefix or suffix of the hash value of the public key of the above-mentioned legitimate asset issuer can be set for the ID of the asset type that can allow the asset issuer; thus, once it is verified that the prefix or suffix of the asset type of the above-mentioned target asset object completely matches the public key of the legitimate asset issuer, or to the prefix or suffix of the public key of the legitimate asset issuer, or to the hash value of the public key of the legitimate asset issuer, or to the prefix or suffix of the hash value of the public key of the legitimate asset issuer, it can be confirmed that the target asset object is a legitimate asset type that the above-mentioned asset issuer is allowed to publish.

[0116] In one embodiment shown, a node device serving as a verifier of zero-knowledge proof may construct an asset type list based on the public keys of all legal asset issuers, and maintain the asset type list locally.

[0117] The above validation rules may include:

[0118] Verify whether the prefix (or suffix) of the asset type of the target asset object matches the public key of the legal asset issuer, or the prefix (or suffix) of the public key of the legal asset issuer, or the hash value of the public key of the legal asset issuer, or the prefix (or suffix) of the hash value of the public key of the legal asset issuer; if so, confirm that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to publish.

[0119] In this scenario, the verification data related to the verification rule may be the public key list or the hash tree. The node device may use the public key list or the hash tree as input data and input it into the zero-knowledge proof verification algorithm for calculation to complete the zero-knowledge proof of the commitment value.

[0120] It should be noted that if the blockchain does not support hiding the identity information of the transaction issuer, since the identity information of the transaction issuer is completely public, the node device only needs to verify whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer through zero-knowledge proof, and does not need to verify whether the asset issuer holds the private key corresponding to the public key of the legal asset issuer.

[0121] Therefore, in this scenario, the algorithm logic of the above verification rules can be implanted into the above zero-knowledge evidence proof algorithm, and then based on the public identity information of the transaction publisher, it is sufficient to complete the zero-knowledge proof of the above assertion. At this time, the verification data related to the above verification rules in the input data used by the above node device when performing zero-knowledge proof of the above commitment value can be a null value.

[0122] 4) Promise value release certificate

[0123] In this specification, when the node device determines through zero-knowledge proof that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue, the node device can publish the commitment value to the blockchain for evidence storage. For example, the node device can record the commitment value in the distributed database of the blockchain.

[0124] Of course, if the node device determines through zero-knowledge proof that the asset type of the target asset object is not a legal asset type allowed to be published by the asset publisher, the node device can directly discard the asset publishing transaction and return a failed publishing prompt message to the asset publisher; for example, the prompt message can be a text prompt that "You do not have the authority to publish this type of asset".

[0125] In the above technical solution, on the one hand, since the above asset issuance transaction only carries at least the asset type of the target asset object to be issued as input data to the commitment function to calculate the commitment value, and does not carry the asset type of the target asset object in plain text in the asset issuance transaction, the blockchain can hide the asset type of the target asset object issued by the asset issuer and protect the privacy of the asset issuer;

[0126] On the other hand, since the above-mentioned asset issuance transaction also carries zero-knowledge evidence for zero-knowledge proof of the above-mentioned commitment value, the node devices in the blockchain can perform zero-knowledge proof on the above-mentioned zero-knowledge evidence on the premise of hiding the asset type issued by the asset issuer to verify whether the asset type of the target asset object issued by the above-mentioned asset issuer is a legal asset type allowed to be issued by the asset issuer.

[0127] Corresponding to the above method embodiments, this specification also provides an embodiment of an asset issuance device based on blockchain. The embodiment of the asset issuance device based on blockchain in this specification can be applied to electronic devices. The device embodiment can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, if Figure 2 As shown in the figure, it is a hardware structure diagram of the electronic device where the asset issuance device based on blockchain in this specification is located, except Figure 2 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0128] Figure 3 It is a block diagram of an asset issuance device based on blockchain shown in an exemplary embodiment of this specification.

[0129] Please refer to Figure 3 The asset issuance device 30 based on blockchain can be applied in the aforementioned Figure 3 The electronic device shown includes: a receiving module 301, a verification module 302 and a proof storage module 303.

[0130] The receiving module 301 receives an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: at least the asset type of the target asset object issued by the asset issuer is input as input data into the commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0131] A verification module 302 initiates a zero-knowledge proof of the commitment value based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0132] If yes, the evidence storage module 303 publishes the commitment value to the blockchain for evidence storage.

[0133] In this embodiment, the zero-knowledge evidence is generated by the asset issuer using at least the commitment value and the legal asset type that the asset issuer is allowed to issue as input data to the zero-knowledge evidence generation algorithm carried by the blockchain for calculation.

[0134] In this embodiment, the node device maintains a verification rule for verifying whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0135] The zero-knowledge evidence is generated by the asset issuer using at least verification data related to the verification rule as input data to the zero-knowledge evidence generation algorithm carried by the blockchain for calculation.

[0136] In this embodiment, if the blockchain supports hiding the identity information of the transaction issuer, the input data of the zero-knowledge evidence generation algorithm also includes the private key of the asset issuer.

[0137] In this embodiment, the verification module 302:

[0138] If the blockchain does not support hiding the identity information of the transaction issuer, a zero-knowledge proof of the commitment value is initiated based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0139] If the blockchain supports hiding the identity information of the transaction issuer, a zero-knowledge proof of the commitment value is initiated based on the zero-knowledge evidence to verify whether the asset issuer holds a private key corresponding to the public key of the legal asset issuer; and to verify whether the asset type of the target asset object is a legal asset type that the legal asset issuer is allowed to issue.

[0140] In this embodiment, the verification module 302:

[0141] At least the zero-knowledge evidence and the commitment value are input as input data of the zero-knowledge evidence verification algorithm to the zero-knowledge evidence verification algorithm for calculation;

[0142] Based on the output result of the zero-knowledge evidence verification algorithm, it is confirmed whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue.

[0143] In this embodiment, the node device is configured with a verification rule for verifying whether the asset type of the target asset object is a legal asset type allowed to be published by the asset publisher; the input data also includes verification data related to the verification rule.

[0144] In this embodiment, the node device maintains an asset type list constructed by legal asset types that the asset issuer is allowed to issue;

[0145] The verification rule includes: verifying whether the asset type of the target asset object is included in the asset type list; if so, confirming that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0146] The verification data includes: the asset type list.

[0147] In this embodiment, the node device maintains a hash tree constructed by hash values ​​of legal asset types that the asset issuer is allowed to issue;

[0148] The verification rule includes: verifying whether the hash value of the asset type of the target asset object is contained in the hash tree; if so, confirming that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0149] The verification data includes: the hash tree.

[0150] In this embodiment, the node device maintains a public key list constructed by the public keys of all legal asset issuers; or a hash tree constructed by the hash values ​​of the public keys of all legal asset issuers;

[0151] The validation rules include:

[0152] Verify whether the prefix or suffix of the asset type of the target asset object matches the public key of the legal asset issuer, or the prefix or suffix of the public key of the legal asset issuer, or the hash value of the public key of the legal asset issuer, or the prefix or suffix of the hash value of the public key of the legal asset issuer; if so, confirm that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to publish;

[0153] The verification data includes the public key list, or the hash tree.

[0154] In this embodiment, the commitment function is a hash function; the zero-knowledge proof algorithm built on the blockchain is a zksnark algorithm or a zkstark algorithm.

[0155] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

[0156] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0157] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of 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 a combination of any of these devices.

[0158] Corresponding to the above method embodiment, this specification also provides an embodiment of an electronic device. The electronic device includes: a processor and a memory for storing machine executable instructions; wherein the processor and the memory are usually connected to each other through an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0159] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based asset issuance stored in the memory, the processor is prompted to:

[0160] Receiving an asset issuance transaction sent by an asset issuer; wherein the asset issuance transaction includes: inputting at least the asset type of the target asset object issued by the asset issuer as input data into a commitment function to calculate and generate a commitment value; and a zero-knowledge evidence for zero-knowledge proof of the commitment value;

[0161] Initiate a zero-knowledge proof of the commitment value based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer;

[0162] If so, the commitment value is published to the blockchain for evidence storage.

[0163] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based asset issuance stored in the memory, the processor is further prompted to:

[0164] If the blockchain does not support hiding the identity information of the transaction issuer, a zero-knowledge proof of the commitment value is initiated based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue;

[0165] If the blockchain supports hiding the identity information of the transaction issuer, a zero-knowledge proof of the commitment value is initiated based on the zero-knowledge evidence to verify whether the asset issuer holds a private key corresponding to the public key of the legal asset issuer; and to verify whether the asset type of the target asset object is a legal asset type that the legal asset issuer is allowed to issue.

[0166] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based asset issuance stored in the memory, the processor is further prompted to:

[0167] At least the zero-knowledge evidence and the commitment value are input as input data of the zero-knowledge evidence verification algorithm to the zero-knowledge evidence verification algorithm for calculation;

[0168] Based on the output result of the zero-knowledge evidence verification algorithm, it is confirmed whether the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue.

[0169] Those skilled in the art will readily appreciate other embodiments of the specification after considering the specification and practicing the invention disclosed herein. The specification is intended to cover any variations, uses, or adaptations of the specification that follow the general principles of the specification and include common knowledge or customary techniques in the art that are not disclosed in the specification. The specification and examples are to be considered exemplary only, and the true scope and spirit of the specification are indicated by the following claims.

[0170] It should be understood that the present description is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

[0171] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A blockchain-based asset issuance method, comprising: Receive an asset release transaction; wherein the asset release transaction includes: a hash value corresponding to the asset type of the target asset object; and a zero-knowledge evidence for zero-knowledge proof of the hash value; the zero-knowledge evidence is generated by inputting the hash value and the legal asset type into a zero-knowledge evidence generation algorithm carried by the blockchain for calculation; Input the zero-knowledge evidence and the hash value into a zero-knowledge evidence verification algorithm for calculation to confirm whether the asset type of the target asset object is a legal asset type; If so, the hash value is published to the blockchain for evidence storage.

2. According to the method of claim 1, the node device in the blockchain maintains a verification rule for verifying whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer; The zero-knowledge evidence is generated by inputting the verification data related to the verification rule as input data into the zero-knowledge evidence generation algorithm carried by the blockchain for calculation.

3. According to the method of claim 1 or 2, if the blockchain supports hiding the identity information of the transaction issuer, the input data of the zero-knowledge evidence generation algorithm also includes the private key of the asset issuer who sends the asset issuance transaction.

4. The method according to claim 1, further comprising: If the blockchain does not support hiding the identity information of the transaction issuer, a zero-knowledge proof of the hash value is initiated based on the zero-knowledge evidence to verify whether the asset type of the target asset object is a legal asset type; If the blockchain supports hiding the identity information of the transaction issuer, a zero-knowledge proof of the hash value is initiated based on the zero-knowledge evidence to verify whether the asset issuer who sent the asset issuance transaction holds the private key corresponding to the public key of the legal asset issuer; and to verify whether the asset type of the target asset object is a legal asset type that is allowed to be issued by the legal asset issuer.

5. According to the method of claim 1, the node device in the blockchain maintains a verification rule for verifying whether the asset type of the target asset object is a legal asset type allowed to be issued by the asset issuer; The input to the zero-knowledge evidence generation algorithm carried by the blockchain for calculation also includes verification data related to the verification rules.

6. The method according to claim 5, wherein the node device maintains an asset type list constructed by legal asset types that the asset issuer is allowed to issue; The validation rules include: Verify whether the asset type of the target asset object is included in the asset type list; If yes, confirm that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue; The verification data includes: the asset type list.

7. The method according to claim 5, wherein the node device maintains a hash tree constructed by hash values ​​of legal asset types that the asset issuer is allowed to issue; The verification rule includes: verifying whether the hash value of the asset type of the target asset object is contained in the hash tree; if so, confirming that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to issue; The verification data includes: the hash tree.

8. According to the method of claim 2, the node device maintains a public key list constructed by the public keys of all legal asset issuers; Alternatively, a hash tree constructed from the hash values ​​of the public keys of all legitimate asset issuers; The validation rules include: Verify whether the prefix or suffix of the asset type of the target asset object matches the public key of the legal asset issuer, or the prefix or suffix of the public key of the legal asset issuer, or the hash value of the public key of the legal asset issuer, or the prefix or suffix of the hash value of the public key of the legal asset issuer; if so, confirm that the asset type of the target asset object is a legal asset type that the asset issuer is allowed to publish; The verification data includes the public key list, or the hash tree.

9. According to the method of claim 1, the zero-knowledge proof algorithm used to build the blockchain is a zksnark algorithm or a zkstark algorithm.

10. An asset issuance device based on blockchain, comprising: A receiving module receives an asset issuance transaction; wherein the asset issuance transaction includes: a hash value corresponding to the asset type of the target asset object; and a zero-knowledge evidence for zero-knowledge proof of the hash value; the zero-knowledge evidence is generated by inputting the hash value and the legal asset type into a zero-knowledge evidence generation algorithm carried by the blockchain for calculation; A verification module, inputting the zero-knowledge evidence and the hash value into a zero-knowledge evidence verification algorithm for calculation to confirm whether the asset type of the target asset object is a legal asset type; The evidence storage module, if yes, publishes the hash value to the blockchain for evidence storage.

11. An electronic device, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing machine executable instructions corresponding to the control logic of blockchain-based asset issuance stored in the memory, the processor is prompted to execute the method of any one of claims 1 to 9 above.

Images