CN109934593B - Design method and device for realizing block chain system supporting multiple signatures - Google Patents
Design method and device for realizing block chain system supporting multiple signatures Download PDFInfo
- Publication number
- CN109934593B CN109934593B CN201910231373.2A CN201910231373A CN109934593B CN 109934593 B CN109934593 B CN 109934593B CN 201910231373 A CN201910231373 A CN 201910231373A CN 109934593 B CN109934593 B CN 109934593B
- Authority
- CN
- China
- Prior art keywords
- transaction
- signature
- smart contract
- rule
- contract
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The present disclosure discloses a design method and apparatus for implementing a blockchain system supporting multiple signatures, the design method comprising: receiving a first transaction, wherein the first transaction is used for deploying an intelligent contract, the first transaction at least comprises an intelligent contract to be deployed, a first multi-signature rule associated with the intelligent contract and a first transaction identifier, the first multi-signature rule comprises a set first public key set, a first signature threshold value and first identification information comprising a first identification rule; deploying the intelligent contract and generating a contract address of the intelligent contract; storing a first transaction credential, the first transaction credential including a contract address, a first multi-signature rule, and a first transaction identification; the contract address of the smart contract is returned. The disclosed method and apparatus will reduce the code burden of the smart contract to reduce the local ledger size and complexity, support changing the multi-signature rules without modifying the original smart contract data, and reduce the resource consumption caused by smart contract redeployment.
Description
Technical Field
The disclosure belongs to the technical field of blockchain, and particularly relates to a design method for realizing a blockchain system supporting multiple signatures and design equipment for realizing the blockchain system supporting multiple signatures.
Background
The Blockchain (Blockchain) is a distributed database system capable of safely storing data, and is characterized in that the information is protected from being maliciously counterfeited or tampered by utilizing the cryptography principle while all transaction information is recorded, so that the authenticity of the data is ensured. Due to the characteristics of decentralization, non-falsification and the like of the blockchain, the technology is widely applied to scenes such as digital assets, decentralization exchanges, financial derivatives, electronic commerce, intelligent assets, anti-counterfeiting traceability and the like.
Intelligent contracts refer to a decentralised protocol that implements business function requirements on the blockchain. Firstly, the service function requirements are written by using a high-level language, then the service function requirements are converted into executable codes through a corresponding compiler to be deployed on a blockchain, and finally, corresponding functions are realized through interaction between the provided interfaces and deployed contracts. The intelligent contract has the characteristic of decentralization, does not need the participation of a third party agent, and improves the efficiency of transaction execution. The intelligent contract can not be tampered after deployment, any party can not interfere with the execution of the contract and the execution result, and the authenticity of the execution result is ensured.
Multiple signatures refer to a technique in which multiple users sign and authenticate the same information. In blockchain systems, multiple signature techniques require multiple users to sign and authenticate the same transaction using their own private keys. In real life, a document often needs to be signed by a plurality of departments, and the multiple signature technology solves the problems of complex flow and time consumption. Large exchanges often encounter the event that a user account is hacked to cause theft of the asset, and multiple signature techniques can protect the user asset to a great extent, and even if a key is obtained, the asset cannot be successfully stolen.
In existing blockchain systems, multiple signature techniques are typically implemented through smart contracts. And defining account addresses needing to provide signatures and required signature quantity thresholds in the intelligent contracts, calling an interface to transfer the signatures into the intelligent contracts after a user finishes the signatures under the chain to verify the signatures, and executing the transaction after the quantity of the signatures to be collected meets the threshold requirements.
In the prior art, the multiple signature technology realized by intelligent contracts can solve the security problem caused by malicious attack of accounts, but has the defects: the logic complex signing-off and signing-checking requirements cause the increase of the code burden of the intelligent contract, and the increase of the complexity of the intelligent contract causes easy error; because the intelligent contract cannot be modified once deployed, the contract can only be redeployed under the condition that the generation rule of the signature needs to be updated; the expansibility is low, only a signature method provided by the intelligent contract can be used, and various signature algorithms cannot be supported.
Disclosure of Invention
Because the block chain system in the prior art is basically based on the intelligent contracts to realize the multi-signature technology, the problems of complex logic of signing releasing and signing checking, heavy code burden of the intelligent contracts, high complexity of the intelligent contracts and the like exist, and in addition, if signature rules need to be replaced in actual use, the intelligent contracts can only be redeployed, so that the problem of low expansion performance of the multi-signature technology exists.
In view of the foregoing, a first aspect of the present disclosure proposes a design method for implementing a blockchain system supporting multiple signatures, the design method comprising:
receiving a first transaction, wherein the first transaction is used for deploying a smart contract, and the first transaction comprises at least a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identification, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
deploying the smart contract and generating a contract address of the smart contract;
storing a first transaction credential, wherein the first transaction credential includes the contract address, the first multi-signature rule, and a first transaction identification; and
And returning the contract address of the intelligent contract.
In an embodiment according to the first aspect of the present disclosure, the design method further comprises:
receiving a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction includes at least a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature includes a signature of the second transaction by a respective user using its private key and second consensus information;
determining whether to invoke a multi-signature authenticated smart contract based on the contract address;
determining whether the second transaction satisfies the first multi-signature rule in the event that it is determined to invoke the multi-signature authenticated smart contract; and
in the event that the second transaction is determined to satisfy the first multi-signature rule, executing a smart contract corresponding to the contract address.
In an embodiment according to the first aspect of the present disclosure, determining whether to invoke a multi-signed authenticated smart contract based on the contract address further comprises:
determining a corresponding first transaction credential based on the contract address;
querying whether the first transaction identifier in the first transaction credential is a multi-signature rule identifier; and
And determining to invoke the smart contract for the multi-signature authentication in the case that the first transaction identification is determined to be the multi-signature rule identification.
In an embodiment according to the first aspect of the present disclosure, in the case of determining to invoke the multi-signature authenticated smart contract, determining whether the second transaction satisfies the first multi-signature rule further comprises:
each signature in the second transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
In an embodiment according to the first aspect of the present disclosure, where the first multi-signature rule in the first transaction further includes one or more methods in the smart contract and the second transaction further includes any of the methods in the smart contract, determining whether the second transaction satisfies the first multi-signature rule further includes:
Querying the first transaction credential for whether a method of the smart contract included in the second transaction exists in the first multi-signature rule;
if the method for determining the intelligent contract exists in the first multi-signature rule, at least signing each signature in the second transaction by utilizing the first identification rule included in the first identification information and the public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
In an embodiment according to the first aspect of the present disclosure, the design method further comprises:
receiving a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identification serving as an updated signature rule identification, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction using their private key and fourth consensus information;
Validating the third transaction;
storing a second transaction credential if the third transaction is validated, wherein the second transaction credential includes a contract address of the smart contract, the second multi-signature rule, and a first transaction identification that is a multi-signature rule identification; and
and returning the contract address of the intelligent contract.
In an embodiment according to the first aspect of the present disclosure, verifying the third transaction further comprises:
each signature in the third transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing releasing is successful, verifying whether the number of signatures capable of signing releasing in the third transaction is larger than or equal to the first signature threshold value; and
and determining that the third transaction is verified in the condition that the number of signatures capable of being signed is greater than or equal to the first signature threshold.
In view of the foregoing, a second aspect of the present disclosure proposes a design method for implementing a blockchain system supporting multiple signatures, the design method comprising:
Initiating a first transaction, wherein the first transaction is for deploying a smart contract, and the first transaction comprises a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identity, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
a contract address of the smart contract is received in the event that deployment of the smart contract in the blockchain system is successful, wherein the contract address of the smart contract is associated with the first multi-signature rule and the first transaction identification.
In an embodiment according to the second aspect of the present disclosure, the design method further comprises:
initiating a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction comprises a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature comprises a signature of the second transaction by the respective user with its private key and second consensus information.
In an embodiment according to the second aspect of the present disclosure, the design method further comprises:
Initiating a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identity that serves as an updated signature rule identity, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction with its private key and fourth consensus information;
and receiving a contract address of the smart contract in the case that the third transaction is verified, wherein the contract address of the smart contract is associated with the second multi-signature rule and a first transaction identification that is an identification of the multi-signature rule.
In view of the foregoing, a third aspect of the present disclosure proposes a design apparatus for implementing a blockchain system supporting multiple signatures, the design apparatus comprising:
a processor; and
a memory for storing instructions that, when executed, cause the processor to:
Receiving a first transaction, wherein the first transaction is used for deploying a smart contract, and the first transaction comprises at least a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identification, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
deploying the smart contract and generating a contract address of the smart contract;
storing a first transaction credential, wherein the first transaction credential includes the contract address, the first multi-signature rule, and a first transaction identification; and
and returning the contract address of the intelligent contract.
In an embodiment according to the third aspect of the present disclosure, the instructions, when executed, cause the processor to further:
receiving a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction includes at least a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature includes a signature of the second transaction by a respective user using its private key and second consensus information;
Determining whether to invoke a multi-signature authenticated smart contract based on the contract address;
determining whether the second transaction satisfies the first multi-signature rule in the event that it is determined to invoke the multi-signature authenticated smart contract; and
in the event that the second transaction is determined to satisfy the first multi-signature rule, executing a smart contract corresponding to the contract address.
In an embodiment according to the third aspect of the present disclosure, determining whether to invoke a multi-signature authenticated smart contract based on the contract address further comprises:
determining a corresponding first transaction credential based on the contract address;
querying whether the first transaction identifier in the first transaction credential is a multi-signature rule identifier; and
and determining to invoke the smart contract for the multi-signature authentication in the case that the first transaction identification is determined to be the multi-signature rule identification.
In an embodiment according to the third aspect of the present disclosure, in the case of determining to invoke the multi-signature authenticated smart contract, determining whether the second transaction satisfies the first multi-signature rule further comprises:
Each signature in the second transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
In an embodiment according to the third aspect of the present disclosure, where the first multi-signature rule in the first transaction further includes one or more methods in the smart contract and the second transaction further includes any of the methods in the smart contract, determining whether the second transaction satisfies the first multi-signature rule further includes:
querying the first transaction credential for whether a method of the smart contract included in the second transaction exists in the first multi-signature rule;
if the method for determining the intelligent contract exists in the first multi-signature rule, at least signing each signature in the second transaction by utilizing the first identification rule included in the first identification information and the public key in the first public key set;
Under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
In an embodiment according to the third aspect of the present disclosure, the instructions, when executed, cause the processor to further:
receiving a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identification serving as an updated signature rule identification, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction using their private key and fourth consensus information;
validating the third transaction;
Storing a second transaction credential if the third transaction is validated, wherein the second transaction credential includes a contract address of the smart contract, the second multi-signature rule, and a first transaction identification that is a multi-signature rule identification; and
and returning the contract address of the intelligent contract.
In an embodiment according to the third aspect of the present disclosure, verifying the third transaction further comprises:
each signature in the third transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing releasing is successful, verifying whether the number of signatures capable of signing releasing in the third transaction is larger than or equal to the first signature threshold value; and
and determining that the third transaction is verified in the condition that the number of signatures capable of being signed is greater than or equal to the first signature threshold.
In view of the foregoing, a fourth aspect of the present disclosure proposes a design apparatus for implementing a blockchain system supporting multiple signatures, the design apparatus comprising:
a processor; and
a memory for storing instructions that, when executed, cause the processor to:
Initiating a first transaction, wherein the first transaction is for deploying a smart contract, and the first transaction comprises a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identity, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
a contract address of the smart contract is received in the event that deployment of the smart contract in the blockchain system is successful, wherein the contract address of the smart contract is associated with the first multi-signature rule and the first transaction identification.
In an embodiment according to the fourth aspect of the present disclosure, the instructions, when executed, cause the processor to further:
initiating a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction comprises a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature comprises a signature of the second transaction by the respective user with its private key and second consensus information.
In an embodiment according to the fourth aspect of the present disclosure, the instructions, when executed, cause the processor to further:
initiating a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identity that serves as an updated signature rule identity, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction with its private key and fourth consensus information;
and receiving a contract address of the smart contract in the case that the third transaction is verified, wherein the contract address of the smart contract is associated with the second multi-signature rule and a first transaction identification that is an identification of the multi-signature rule.
According to the design method and the device for realizing the blockchain system supporting multiple signatures, the multiple signature rules can be stored as transaction certificates while the intelligent contracts are deployed, and a user can initiate a transaction for changing the multiple signature rules so as to update the multiple signature rules corresponding to the intelligent contracts. The design method and the device disclosed by the invention can realize multiple signature verification of the transaction without depending on the intelligent contract, thereby reducing the burden of intelligent contract codes; the multi-signature rule can be updated on the basis of not modifying the original intelligent contract data, so that the resource consumption caused by redeployment of the intelligent contract is reduced; in addition, the present disclosure further supports multiple signature verification of the intelligent contract as a whole or one or more methods within the intelligent contract, increasing the flexibility of multiple signature verification.
Drawings
Features, advantages, and other aspects of embodiments of the disclosure will become more apparent upon reference to the following detailed description, taken in conjunction with the accompanying drawings, wherein several embodiments of the disclosure are shown by way of illustration, and not limitation, in which:
FIG. 1 is a flow chart of one embodiment of a design method for implementing a blockchain system that supports multiple signatures in accordance with the present disclosure;
FIG. 2 is a flow chart of a second embodiment of a design method for implementing a blockchain system that supports multiple signatures in accordance with the present disclosure;
FIG. 3 is a flow chart of a third embodiment of a design method for implementing a blockchain system that supports multiple signatures in accordance with the present disclosure; and
fig. 4 shows a schematic diagram of a design apparatus 400 for implementing a blockchain system supporting multiple signatures in accordance with the present disclosure.
Detailed Description
Various exemplary embodiments of the present disclosure are described in detail below with reference to the drawings. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of methods and systems according to various embodiments of the present disclosure. It should be noted that each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the logical functions specified in the various embodiments. It should also be noted that, in some alternative implementations, the functions noted in the block 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. It will also be noted that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by special purpose hardware-based systems which perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.
Embodiments of the present disclosure focus mainly on the following technical problems: how to implement a blockchain system that supports multiple signature verification techniques without relying on smart contracts.
In order to solve the above problems, disclosed herein are a design method and apparatus for implementing a blockchain system supporting multiple signatures, transmitting an intelligent contract to be deployed and multiple signature rules and transaction identifications regarding the intelligent contract as transactions to a blockchain node, so that the blockchain node can deploy the intelligent contract therein and store the contract address, multiple signature rules and transaction identifications of the intelligent contract as transaction certificates; thereby reducing the code burden of the smart contract. In addition, the technical scheme disclosed herein can also support multiple signature verification on the whole intelligent contract or one or more methods therein, change multiple signature rules on the basis of not modifying the original intelligent contract data, reduce the resource consumption caused by redeployment of the intelligent contract and improve the expansibility of the multiple signature technology.
Example 1
FIG. 1 illustrates a flow chart of one embodiment of a design method for implementing a blockchain system that supports multiple signatures. In this embodiment, the client side of the blockchain system and the blockchain link point jointly implement the method shown in fig. 1, specifically as follows:
Step 110: a client of a blockchain system initiates a first transaction, wherein the first transaction is for deploying a smart contract, and the first transaction includes a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identification, and wherein the first multi-signature rule includes a set first public key set, a first signature threshold, and first consensus information including a first consensus rule.
In this step, the set first public key set includes public keys that allow invoking multiple accounts of the smart contract, the first signature threshold being the minimum number of signatures required to be collected. When the smart contract to be deployed requires multiple signature techniques to verify, the first transaction identifier is a multiple signature rule identifier.
For example, when setting a rule, a public key set (pk 1 ,pk 2 ,…,pk n ) And a threshold (t, t.ltoreq.n).
In addition, in the present embodiment, when the user needs to design one or more methods in the smart contract to require multiple signature verification, the first multiple signature rule in the first transaction initiated by the client further includes one or more methods in the smart contract.
Step 120: the block link point receives the first transaction.
Step 130: the blockchain node deploys the smart contract in the first transaction and generates a contract address for the smart contract.
Step 140: the block link point stores the first transaction credential. Specifically, the block link associates the contract address of the smart contract with the first multi-signature rule, the first transaction identification such that the contract address of the smart contract, the first multi-signature rule, and the first transaction identification are stored as a first transaction credential.
In this embodiment, step 140 is not required if the smart contract is one that does not require multiple signature verification.
Step 150: the block link point returns the contract address of the smart contract.
Step 160: in the event that the smart contract is successfully deployed in the blockchain system, a client receives a contract address of the smart contract, wherein the contract address of the smart contract is associated with the first multi-signature rule and the first transaction identity.
Embodiment 1 discloses how multiple signature rules and related information about a smart contract can be stored as a transaction proof without relying on the smart contract so that the related multiple signature rules need to be satisfied at the same time later to be able to invoke the smart contract.
Example 2
FIG. 2 illustrates a flow chart of a second embodiment of a design methodology for implementing a blockchain system that supports multiple signatures. In this embodiment, the client side of the blockchain system and the blockchain link point jointly implement the method shown in fig. 2, specifically as follows:
step 210: a client of the blockchain system (which may be the same as or different from the client in embodiment 1) initiates a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction includes a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature includes a signature of the second transaction by the respective user using its private key and second consensus information.
In addition, when the first multi-signature rule of the first transaction in embodiment 1 further includes one or more methods in the smart contract, the second transaction further needs to include any method in the smart contract.
Step 220: the blockchain node receives a second transaction.
Step 230: the block link point determines whether to invoke a multi-signature authenticated intelligent contract based on the contract address. In this embodiment, the blockchain node specifically operates as follows:
Firstly, determining corresponding first transaction credentials based on the contract address;
secondly, inquiring whether the first transaction identifier in the first transaction certificate is a multi-signature rule identifier or not;
again, in the event that the first transaction identity is determined to be the multi-signature rule identity, a smart contract invoking the multi-signature authentication is determined.
Step 240: in the event that a determination is made to invoke the multi-signature authenticated smart contract, the blockchain node determines whether the second transaction satisfies the first multi-signature rule. In this embodiment, the blockchain node specifically operates as follows:
first, each signature in the second transaction is signed using at least a first consensus rule included in the first consensus information, a public key in the first public key set.
In this step, the first set of public keys (e.g., the public key set (pk in example 1 1 ,pk 2 ,…,pk n ) If the public key in the first public key set and the first consensus rule can sign the signature, the signature verification is successful.
For example, the first consensus rule included in the first consensus information in embodiment 1 is "format of consensus information: the source account+the contract address ", and the second common information in this embodiment is" source account a ", and when the block link point signs the signature of the second transaction by using the first common rule included in the first common information, a certain public key in the first public key set, and the transaction content (for example, the specific basic transaction information such as the source account address) in the second transaction, verification fails; if the second common information in this embodiment is "the source account a+ calls the contract address of the smart contract", when the block link point signs the signature of the second transaction by using the first common rule included in the first common information, a certain public key in the first public key set, and the transaction content in the second transaction (for example, the specific source account address, the contract address of the smart contract to be called, and the like, and the certain public key in the first public key set can sign the signature of the second transaction, the verification is successful, and the next action is continued.
And under the condition that the signing-off is successful, determining whether the number of signatures capable of signing off in the second transaction is larger than or equal to the first signature threshold value.
For example, in this embodiment, the second transaction may include a plurality of signatures (sig 1 ,sig 2 ,…,sig k ) The method comprises the steps of carrying out a first treatment on the surface of the When the number of signatures v (v.ltoreq.k). Gtoreq.t (as disclosed in example 1) that pass the verification, the next step is performed.
Finally, in the case that the number of signatures capable of being signed is determined to be greater than or equal to the first signature threshold, the second transaction is determined to satisfy the first multiple signature rule.
In addition, in the case where the first multi-signature rule of the first transaction in embodiment 1 further includes one or more methods in the smart contract and the second transaction further includes any method in the smart contract, the blockchain node specifically operates as follows with respect to step 240:
first, whether a method of querying the smart contract included in the second transaction in the first transaction credential exists in the first multi-signature rule.
For example, the first multiple signature rule includes method 1, method 2 and method 3, if method 2 is included in the second transaction, then it is indicated that method 2 in the second transaction is also applicable to the first multiple signature rule, and the next step is continued; if method 4 is included in the second transaction, it is indicated that method 4 in the second transaction does not apply the first multiple signature rule and the verification fails.
Second, in the case where the method of determining the smart contract exists in the first multi-signature rule, each signature in the second transaction is signed with at least a public key in the first public key set, the public key in the public key set, and the public rule included in the first public information.
Third, if the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold.
Fourth, in a case where it is determined that the number of signatures that can be signed is greater than or equal to the first signature threshold, it is determined that the second transaction satisfies the first multiple signature rule.
In this case, the second to fourth steps are the same as the detailed description of step 240, and are not repeated here.
In the above case, multiple signature verification of a single method within the smart contract can be supported.
Step 250: in the event that the second transaction is determined to satisfy the first multi-signature rule, a block link point executes a smart contract corresponding to the contract address.
Embodiment 2 discloses a technical solution of how to invoke an intelligent contract requiring multiple signature authentication, first it can be determined whether the second transaction can be verified by multiple signatures, and in case the second transaction can be verified by multiple signatures, the intelligent contract in the second transaction is executed.
Example 3
FIG. 3 illustrates a flow chart of a third embodiment of a design methodology for implementing a blockchain system that supports multiple signatures. In this embodiment, the client side of the blockchain system and the blockchain link point jointly implement the method shown in fig. 3, specifically as follows:
step 310: a client (which may be the same as or different from the client of embodiments 1, 2) initiates a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identity serving as an updated signature rule identity, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising the second consensus rule, each signature comprising a signature of the respective user on the third transaction with its private key and fourth consensus information.
In this embodiment, the fourth consensus information includes source account information for the third transaction and a contract address for the smart contract. The second consensus rule included in the third consensus information may be the same or different from the first consensus rule and is related to a specific requirement of the second multiple signature rule.
Step 320: the block link point receives a third transaction.
Step 330: the blockchain node validates the third transaction. In this embodiment, the specific operation of step 330 by the blockchain node is as follows:
first, each signature in the third transaction is signed using at least a first consensus rule included in the first consensus information, a public key in the first public key set.
Secondly, under the condition that the signing-off is successful, verifying whether the number of signatures capable of signing off in the third transaction is larger than or equal to the first signature threshold.
Finally, determining that the third transaction passes verification in the case that the number of signatures capable of being signed is verified to be greater than or equal to the first signature threshold.
In this embodiment, the method of verifying the third transaction is the same as the method (i.e., step) of verifying the first transaction in embodiment 2, and a description thereof will not be repeated.
Step 340: in the event that the third transaction is validated, the blockchain node stores a second transaction credential, wherein the second transaction credential includes a contract address of the smart contract, the second multi-signature rule, and a first transaction identification that is a multi-signature rule identification.
Step 350: the block link returns the contract address of the smart contract to the client.
Step 360: in the event that the third transaction is validated, the client receives a contract address for the smart contract, wherein the contract address for the smart contract is associated with the second multi-signature rule and the first transaction identification.
In this embodiment, when any blockchain node of the blockchain system receives a transaction regarding the above-described smart contract to be executed thereafter, in the process of executing the technical solution shown in embodiment 2 by the blockchain node, the newly generated second transaction ticket (instead of the first transaction ticket) will be found based on the contract address of the smart contract to execute the smart contract that determines whether to invoke multi-signature authentication.
The technical solution disclosed in embodiment 3 can associate the contract address of the deployed smart contract with the updated multi-signature rule (e.g., the second multi-signature rule), thereby updating the multi-signature rule. The technical scheme disclosed in embodiment 3 can realize supporting different multiple signature rules, thereby improving the expansibility of the blockchain system.
As shown in fig. 4, a design apparatus 400 for implementing a blockchain system supporting multiple signatures as disclosed herein, the apparatus 400 includes at least a processor 410 and a memory 420, wherein the memory 420 is configured to store instructions such that the processor 410 executes the stored instructions. The apparatus 400 may implement the portion performed by the client in the design method for implementing the blockchain system supporting multiple signatures shown in fig. 1-3 as a client, or may implement the portion performed by the blockchain node in the design method for implementing the blockchain system supporting multiple signatures shown in fig. 1-3 as a blockchain node, which is not described herein.
The design apparatus for implementing a blockchain system supporting multiple signatures disclosed herein is capable of associating multiple signature rules with contract addresses of smart contracts and storing them as transaction credentials, thereby reducing code burden caused by writing multiple signature rules into smart contracts, reducing local ledger size, and reducing storage requirements. In addition, the disclosed design device can design multiple signature rules for the whole intelligent contract or a single method in the intelligent contract, and further flexibly realize support of multiple signature verification for the whole intelligent contract or the single method in the intelligent contract. In addition, the disclosed design equipment can also support different multiple signature rules, and can improve the expansibility of a blockchain system.
The foregoing is merely an alternative embodiment of the present disclosure, and is not intended to limit the embodiments of the present disclosure, so that those skilled in the art may make various modifications and changes to the embodiments of the present disclosure without departing from the spirit and principles of the embodiments of the present disclosure.
Although embodiments of the present disclosure have been described with reference to a number of specific embodiments, it should be understood that embodiments of the present disclosure are not limited to the specific embodiments disclosed. The embodiments of the disclosure are intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.
Claims (16)
1. A design method for implementing a blockchain system supporting multiple signatures, the design method comprising:
receiving a first transaction, wherein the first transaction is used for deploying a smart contract, and the first transaction comprises at least a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identification, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
deploying the smart contract and generating a contract address of the smart contract;
storing a first transaction credential, wherein the first transaction credential includes the contract address, the first multi-signature rule, and a first transaction identification;
returning a contract address of the smart contract;
receiving a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identification serving as an updated signature rule identification, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction using their private key and fourth consensus information;
Validating the third transaction;
storing a second transaction credential if the third transaction is validated, wherein the second transaction credential includes a contract address of the smart contract, the second multi-signature rule, and a first transaction identification that is a multi-signature rule identification; and
and returning the contract address of the intelligent contract.
2. The design method according to claim 1, wherein the design method further comprises:
receiving a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction includes at least a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature includes a signature of the second transaction by a respective user using its private key and second consensus information;
determining whether to invoke a multi-signature authenticated smart contract based on the contract address;
determining whether the second transaction satisfies the first multi-signature rule in the event that it is determined to invoke the multi-signature authenticated smart contract; and
in the event that the second transaction is determined to satisfy the first multi-signature rule, executing a smart contract corresponding to the contract address.
3. The design method of claim 2, wherein determining whether to invoke the multi-signature authenticated smart contract based on the contract address further comprises:
determining a corresponding first transaction credential based on the contract address;
querying whether the first transaction identifier in the first transaction credential is a multi-signature rule identifier; and
and determining to invoke the smart contract for the multi-signature authentication in the case that the first transaction identification is determined to be the multi-signature rule identification.
4. The design method of claim 2, wherein determining whether the second transaction satisfies the first multi-signature rule in the event that it is determined to invoke the multi-signature authenticated smart contract further comprises:
each signature in the second transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
5. The design method of claim 2, wherein, in a case where the first multi-signature rule in the first transaction further includes one or more methods in the smart contract and the second transaction further includes any method in the smart contract, determining whether the second transaction satisfies the first multi-signature rule further comprises:
querying the first transaction credential for whether a method of the smart contract included in the second transaction exists in the first multi-signature rule;
if the method for determining the intelligent contract exists in the first multi-signature rule, at least signing each signature in the second transaction by utilizing the first identification rule included in the first identification information and the public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
6. The design method of claim 1, wherein verifying the third transaction further comprises:
each signature in the third transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing releasing is successful, verifying whether the number of signatures capable of signing releasing in the third transaction is larger than or equal to the first signature threshold value; and
and determining that the third transaction is verified in the condition that the number of signatures capable of being signed is greater than or equal to the first signature threshold.
7. A design method for implementing a blockchain system supporting multiple signatures, the design method comprising:
initiating a first transaction, wherein the first transaction is for deploying a smart contract, and the first transaction comprises a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identity, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
receiving a contract address of the smart contract if the smart contract is successfully deployed in the blockchain system, wherein the contract address of the smart contract is associated with the first multi-signature rule and the first transaction identity;
Initiating a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identity that serves as an updated signature rule identity, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction with its private key and fourth consensus information; and
and receiving a contract address of the smart contract in the case that the third transaction is verified, wherein the contract address of the smart contract is associated with the second multi-signature rule and a first transaction identification that is an identification of the multi-signature rule.
8. The design method according to claim 7, wherein the design method further comprises:
initiating a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction comprises a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature comprises a signature of the second transaction by the respective user with its private key and second consensus information.
9. A design apparatus for implementing a blockchain system that supports multiple signatures, the design apparatus comprising:
a processor; and
a memory for storing instructions that, when executed, cause the processor to:
receiving a first transaction, wherein the first transaction is used for deploying a smart contract, and the first transaction comprises at least a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identification, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
deploying the smart contract and generating a contract address of the smart contract;
storing a first transaction credential, wherein the first transaction credential includes the contract address, the first multi-signature rule, and a first transaction identification;
returning a contract address of the smart contract;
receiving a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identification serving as an updated signature rule identification, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction using their private key and fourth consensus information;
Validating the third transaction;
storing a second transaction credential if the third transaction is validated, wherein the second transaction credential includes a contract address of the smart contract, the second multi-signature rule, and a first transaction identification that is a multi-signature rule identification; and
and returning the contract address of the intelligent contract.
10. The design apparatus of claim 9, wherein the instructions, when executed, cause the processor to further:
receiving a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction includes at least a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature includes a signature of the second transaction by a respective user using its private key and second consensus information;
determining whether to invoke a multi-signature authenticated smart contract based on the contract address;
determining whether the second transaction satisfies the first multi-signature rule in the event that it is determined to invoke the multi-signature authenticated smart contract; and
in the event that the second transaction is determined to satisfy the first multi-signature rule, executing a smart contract corresponding to the contract address.
11. The design apparatus of claim 10, wherein determining whether to invoke the multi-signature authenticated smart contract based on the contract address further comprises:
determining a corresponding first transaction credential based on the contract address;
querying whether the first transaction identifier in the first transaction credential is a multi-signature rule identifier; and
and determining to invoke the smart contract for the multi-signature authentication in the case that the first transaction identification is determined to be the multi-signature rule identification.
12. The design apparatus of claim 10, wherein determining whether the second transaction satisfies the first multi-signature rule in a case where it is determined to invoke the multi-signature authenticated smart contract further comprises:
each signature in the second transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
13. The design apparatus of claim 10, wherein, where a first multi-signature rule in the first transaction further includes one or more methods in the smart contract and the second transaction further includes any method in the smart contract, determining whether the second transaction satisfies the first multi-signature rule further comprises:
querying the first transaction credential for whether a method of the smart contract included in the second transaction exists in the first multi-signature rule;
if the method for determining the intelligent contract exists in the first multi-signature rule, at least signing each signature in the second transaction by utilizing the first identification rule included in the first identification information and the public key in the first public key set;
under the condition that the signing is successful, determining whether the number of signatures capable of signing in the second transaction is greater than or equal to the first signature threshold; and
and determining that the second transaction meets the first multiple signature rule under the condition that the number of signatures capable of being signed is larger than or equal to the first signature threshold.
14. The design apparatus of claim 9, wherein verifying the third transaction further comprises:
each signature in the third transaction is signed by at least utilizing a first consensus rule included in the first consensus information and a public key in the first public key set;
under the condition that the signing releasing is successful, verifying whether the number of signatures capable of signing releasing in the third transaction is larger than or equal to the first signature threshold value; and
and determining that the third transaction is verified in the condition that the number of signatures capable of being signed is greater than or equal to the first signature threshold.
15. A design apparatus for implementing a blockchain system that supports multiple signatures, the design apparatus comprising:
a processor; and
a memory for storing instructions that, when executed, cause the processor to:
initiating a first transaction, wherein the first transaction is for deploying a smart contract, and the first transaction comprises a smart contract to be deployed, a first multi-signature rule associated with the smart contract, and a first transaction identity, and wherein the first multi-signature rule comprises a set first public key set, a first signature threshold, and first identification information comprising a first identification rule;
Receiving a contract address of the smart contract if the smart contract is successfully deployed in the blockchain system, wherein the contract address of the smart contract is associated with the first multi-signature rule and the first transaction identity;
initiating a third transaction, wherein the third transaction is for updating a signature rule of the smart contract, and the third transaction comprises a contract address of the smart contract, a plurality of signatures, a second multiple signature rule regarding the smart contract, and a second transaction identity that serves as an updated signature rule identity, and wherein the second multiple signature rule comprises a set second public key set, a second signature threshold, and third consensus information comprising a second consensus rule, each signature comprising a signature of a respective user on the third transaction with its private key and fourth consensus information; and
and receiving a contract address of the smart contract in the case that the third transaction is verified, wherein the contract address of the smart contract is associated with the second multi-signature rule and a first transaction identification that is an identification of the multi-signature rule.
16. The design apparatus of claim 15, wherein the instructions, when executed, cause the processor to further:
initiating a second transaction, wherein the second transaction is for invoking the smart contract, and the second transaction comprises a contract address of the smart contract to be invoked and a plurality of signatures, and wherein each signature comprises a signature of the second transaction by the respective user with its private key and second consensus information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910231373.2A CN109934593B (en) | 2019-03-26 | 2019-03-26 | Design method and device for realizing block chain system supporting multiple signatures |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910231373.2A CN109934593B (en) | 2019-03-26 | 2019-03-26 | Design method and device for realizing block chain system supporting multiple signatures |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109934593A CN109934593A (en) | 2019-06-25 |
| CN109934593B true CN109934593B (en) | 2023-07-04 |
Family
ID=66988240
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910231373.2A Active CN109934593B (en) | 2019-03-26 | 2019-03-26 | Design method and device for realizing block chain system supporting multiple signatures |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109934593B (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111010282B (en) * | 2019-12-12 | 2022-07-12 | 腾讯科技（深圳）有限公司 | Block chain-based information processing method, related device and storage medium |
| CN111327426B (en) * | 2020-01-21 | 2021-06-25 | 腾讯科技（深圳）有限公司 | Data sharing method and related device, equipment and system |
| CN112150148A (en) * | 2020-09-24 | 2020-12-29 | 普华云创科技(北京)有限公司 | Enterprise asset protection method and system based on block chain technology |
| CN112184960B (en) * | 2020-09-28 | 2022-08-02 | 杭州安恒信息技术股份有限公司 | Intelligent lock control method and device, intelligent lock system and storage medium |
| CN112381543A (en) * | 2020-12-09 | 2021-02-19 | 杭州复杂美科技有限公司 | Multiple signature transaction method, device and storage medium |
| CN112541764B (en) * | 2020-12-17 | 2023-11-28 | 成都知道创宇信息技术有限公司 | Asset management method, device and system based on intelligent contract |
| CN113112268A (en) * | 2021-03-19 | 2021-07-13 | 杭州复杂美科技有限公司 | Anonymous multiple signature method, computer device, and storage medium |
| CN113362064B (en) * | 2021-06-04 | 2022-09-16 | 杭州复杂美科技有限公司 | Multiple signature method, computer device, and storage medium |
| CN113259125A (en) * | 2021-06-10 | 2021-08-13 | 国网浙江省电力有限公司物资分公司 | Block chain-based national network digital certificate management method and device and electronic equipment |
| CN115277008B (en) * | 2022-07-01 | 2024-04-12 | 浪潮软件股份有限公司 | Method and system for managing document signature based on blockchain |
| CN115913576B (en) * | 2022-12-08 | 2024-09-03 | 网易（杭州）网络有限公司 | Method, device, electronic equipment and storage medium for associating multiple blockchain addresses |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20180041050A (en) * | 2017-09-04 | 2018-04-23 | 주식회사 코인플러그 | Method for providing certificate service based on m of n multiple signatures in use of merkle tree structure and server using the same |
| CN108632045A (en) * | 2018-05-10 | 2018-10-09 | 阿里巴巴集团控股有限公司 | A kind of block chain data processing method, device, processing equipment and system |
| CN108647946A (en) * | 2018-05-16 | 2018-10-12 | 深圳市网心科技有限公司 | Intelligent contract processing method and system, audiomonitor and storage medium |
| CN108805562A (en) * | 2017-04-27 | 2018-11-13 | 中思博安科技（北京）有限公司 | The execution method and system of intelligent contract |
| CN108833398A (en) * | 2018-06-08 | 2018-11-16 | 浙江超脑时空科技有限公司 | A kind of block chain intelligence contract update method, device and equipment |
| CN109003185A (en) * | 2018-06-29 | 2018-12-14 | 中国银联股份有限公司 | A kind of method for building up, device, calculating equipment and the storage medium of intelligence contract |
| CN109325359A (en) * | 2018-09-03 | 2019-02-12 | 平安科技（深圳）有限公司 | System of account setting method, system, computer equipment and storage medium |
| CN109376541A (en) * | 2018-09-21 | 2019-02-22 | 上海点融信息科技有限责任公司 | For running the method, apparatus and computer storage medium of intelligent contract |
-
2019
- 2019-03-26 CN CN201910231373.2A patent/CN109934593B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108805562A (en) * | 2017-04-27 | 2018-11-13 | 中思博安科技（北京）有限公司 | The execution method and system of intelligent contract |
| KR20180041050A (en) * | 2017-09-04 | 2018-04-23 | 주식회사 코인플러그 | Method for providing certificate service based on m of n multiple signatures in use of merkle tree structure and server using the same |
| CN108632045A (en) * | 2018-05-10 | 2018-10-09 | 阿里巴巴集团控股有限公司 | A kind of block chain data processing method, device, processing equipment and system |
| CN108647946A (en) * | 2018-05-16 | 2018-10-12 | 深圳市网心科技有限公司 | Intelligent contract processing method and system, audiomonitor and storage medium |
| CN108833398A (en) * | 2018-06-08 | 2018-11-16 | 浙江超脑时空科技有限公司 | A kind of block chain intelligence contract update method, device and equipment |
| CN109003185A (en) * | 2018-06-29 | 2018-12-14 | 中国银联股份有限公司 | A kind of method for building up, device, calculating equipment and the storage medium of intelligence contract |
| CN109325359A (en) * | 2018-09-03 | 2019-02-12 | 平安科技（深圳）有限公司 | System of account setting method, system, computer equipment and storage medium |
| CN109376541A (en) * | 2018-09-21 | 2019-02-22 | 上海点融信息科技有限责任公司 | For running the method, apparatus and computer storage medium of intelligent contract |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109934593A (en) | 2019-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109934593B (en) | Design method and device for realizing block chain system supporting multiple signatures | |
| US11451400B2 (en) | Blockchain transaction method and apparatus | |
| US10700861B2 (en) | System and method for generating a recovery key and managing credentials using a smart blockchain contract | |
| CN107342867B (en) | Signature verification method and device | |
| CN106960165B (en) | Method for realizing multi-party electronic contract countersigning based on block chain intelligent contract | |
| CN113271211B (en) | Digital identity verification system, method, electronic device and storage medium | |
| CN113239382A (en) | Credible identity model based on block chain intelligent contract | |
| JP4681554B2 (en) | How to use reliable hardware-based identity credentials in runtime package signing for secure mobile communications and expensive transaction execution | |
| EP3684005A1 (en) | Method and system for recovering cryptographic keys of a blockchain network | |
| US20120324229A1 (en) | System and method for generating keyless digital multi-signatures | |
| GB2539430A (en) | Digital token exchange system | |
| US20070136574A1 (en) | Apparatus and method for managing plurality of certificates | |
| CN111355592B (en) | Ethernet intelligent contract electronic signature system and method based on block chain | |
| CN111383114A (en) | Asset information management method and device based on block chain | |
| CN111770112B (en) | Information sharing method, device and equipment | |
| CN113301022A (en) | Internet of things equipment identity security authentication method based on block chain and fog calculation | |
| CN111402033A (en) | Asset information management method and device based on block chain | |
| CN109981287A (en) | A kind of code signature method and its storage medium | |
| CN111062059B (en) | Method and device for service processing | |
| CN114239080B (en) | Software multilayer signature method and system based on digital certificate | |
| CN112580112B (en) | Intelligent contract implementation method and device based on full-chain consensus and local deployment | |
| CN114365134A (en) | Secure identity card using unclonable functions | |
| CN114944937A (en) | Distributed digital identity verification method, system, electronic device and storage medium | |
| Poettering et al. | Sequential digital signatures for cryptographic software-update authentication | |
| CN111046443B (en) | Hard disk anti-counterfeiting realization method, hard disk and CA server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |