A 2 / 3 multi-signature method for managing blockchain smart contract permissions

Abstract

The application provides a multi-signature method for managing blockchain smart contract authority, characterized in that a 2 / 3 (i.e. at least 3 signers, any 2 of which agree) signature mode is used for the authorized sending of transactions, a pre-contract for managing the authority of a business smart contract is published, and the pre-contract is used to manage the real business contract; the operation of the business contract by the pre-contract must meet the multi-signature requirement, i.e. the method for calling the business contract in the pre-contract must meet the multi-signature check, the signature is in the form of 2 / 3, and the pre-contract is universal and suitable for most business contracts; any 2 signers of the 3 signers can sign the operation of the business contract to be performed to execute the operation of the business contract. The application uses a blockchain smart contract technology, creates and deploys a pre-contract to manage the actual business layer contract, and thus improves the security of the business layer contract.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology and employs asymmetric encryption technology. Specifically, it relates to a two-thirds method for managing the permissions of blockchain smart contracts. Background Technology

[0002] Asymmetric encryption algorithms require two keys: a public key and a private key. The public and private keys are a pair; if data is encrypted using the public key, only the corresponding private key can decrypt it; conversely, if data is encrypted using the private key, only the corresponding public key can decrypt it. Because encryption and decryption use two different keys, this type of algorithm is called an asymmetric encryption algorithm. The basic process of exchanging confidential information using an asymmetric encryption algorithm is as follows: Party A generates a key pair and publishes one of them as the public key to other parties; Party B, having obtained the public key, uses it to encrypt confidential information and then sends it to Party A; Party A then uses its own private key to decrypt the encrypted information.

[0003] Peer-to-peer (P2P) networking, also known as peer-to-peer technology, is an internet system without a central server, relying on a group of users (peers) to exchange information. Its purpose is to reduce the number of nodes in traditional network transmission, thereby reducing the risk of data loss. Unlike centralized network systems with a central server, each user in a peer-to-peer network is both a node and a server. No single node can directly find other nodes; they must rely on their peer group for information exchange. Participants in the network share a portion of their hardware resources, which provide services and content through the network, directly accessible to other peers without intermediaries. Participants in this network are both providers and recipients of resources, services, and content.

[0004] The blockchain format was first used in Bitcoin as a solution to the problems of database security and trustless administrators. The first blockchain was conceptualized by Satoshi Nakamoto in 2008 and implemented the following year as a core component of the digital currency Bitcoin. Through the use of a peer-to-peer network and distributed timestamp servers, the blockchain database is autonomously managed. The invention of the Bitcoin blockchain made it the first digital currency to solve the double-spending problem, and Bitcoin's design has inspired other blockchain applications ever since. Blockchains are categorized into three types: public blockchains, consortium blockchains, and private blockchains. Cryptocurrencies like Bitcoin fall under the category of public blockchains. Consortium blockchains are often used between enterprises to ensure data sharing and access rights for data on the chain, thus facilitating collaboration while mitigating risk.

[0005] As a new technology with characteristics such as distribution, immutability, and traceability, blockchain plays an excellent role in preserving personal resume information. This patent combines asymmetric encryption and blockchain technology to propose a blockchain-based resume information sharing scheme design, which not only improves the sharing efficiency of resume information retrieval but also technically guarantees the privacy and security of information.

[0006] Smart contracts can be defined as applications or programs running on a blockchain. Typically, they function as digital protocols enforced according to specific rules. These rules are predefined by computer code and are replicated and executed by all network nodes. Blockchain smart contracts enable the creation of trustless protocols. This means that the two parties to a contract make commitments through the blockchain without needing to know or trust each other. Both parties agree that the contract will not execute if certain conditions are not met. Furthermore, using smart contracts eliminates the need for intermediaries, significantly reducing operating costs. Summary of the Invention

[0007] The purpose of this invention is to provide a 2 / 3 multi-signature method for managing blockchain smart contract permissions.

[0008] This invention proposes a multi-signature method for managing blockchain smart contract permissions. It employs a 2 / 3 signature method (meaning a transaction requires the consent of at least two of the three signers) for transaction authorization. A pre-contract is published to manage the permissions of the actual business smart contracts. Operations on the business contracts within the pre-contract must meet the multi-signature requirement; that is, all methods calling the business contracts within the pre-contract must satisfy the multi-signature check, using a 2 / 3 signature format. Furthermore, this pre-contract is universal and applicable to most business contracts. The business contract operation can be executed simply by any two of the three signers signing the required signature.

[0009] The aforementioned front-end contract provides a method for sending multi-signature transactions (sendMultiSigTx), which requires five parameters: businessContractAddress, value, data, expireTime, and signature. Each parameter specifically refers to:

[0010] businessContractAddress represents the address of the business layer contract managed by the preceding contract;

[0011] value represents the amount of native tokens attached when calling the business layer contract method;

[0012] `data` represents the valid methods in the business layer to be called, along with the parameters required by those methods.

[0013] expireTime represents the expiration timestamp of the multisignature transaction;

[0014] The signature indicates the signature made by any signer on the above four parameters, as well as the two parameters sequenceId and networkId maintained in the preceding contract.

[0015] The three signers are Signer 1, Signer 2, and Signer 3. Any two of the signers must perform the following operations, and upon successful completion, the business contract operation will be executed; details are as follows:

[0016] (A) Off-chain signature by signer 1

[0017] When business contract operations are required, first prepare the data that needs to be signed:

[0018] The network ID of the blockchain to which the preceding contract belongs;

[0019] Business layer contract address;

[0020] The optional amount of native tokens to be sent to the business layer contract;

[0021] Call the business layer contract method and specify the required parameters;

[0022] The expiration timestamp for this operation; the operation will fail if this time is exceeded.

[0023] The sequenceId maintained in the preceding contract starts from 0 and increments by 1 each time it is used.

[0024] (B) Signer 2 sends on-chain transaction

[0025] Signer 1 sends the business layer contract address from step (A); the optional number of native tokens to be sent to the business layer contract; the business layer contract method to be called and the required parameters; the expiration timestamp of this operation (the operation will fail if this time is exceeded); and the final signature to Signer 2. Signer 2 uses these five pieces of data as parameters to call the sendMultiSigTx method of the pre-contract. Among them, the network ID of the blockchain to which the pre-contract belongs and the sequenceId maintained in the pre-contract, which starts from 0 and increments by 1 each time it is used, are not used as parameters. These two parameters are maintained by the pre-contract to prevent replay attacks.

[0026] (C) Verify and execute the front-end contract and the business layer contract

[0027] The pre-contract verification process is as follows:

[0028] Concatenate all parameters, along with the networkId and sequenceId maintained by the preceding contract, and then perform a hash.

[0029] Use the hash value and the passed-in signature to reconstruct the signer account. If the signer account is one of the signers of the previous contract, continue the verification; otherwise, return an error.

[0030] Verify the expiration timestamp; if the expiration date has been reached, return an error.

[0031] The caller of this call must also be one of the signers of the preceding contract;

[0032] Verify that the caller of this call is not the signer's account;

[0033] If all the above validations pass, the value and data parameters are passed to the business layer contract, and the business layer contract operations are executed.

[0034] The beneficial effects of this invention are as follows: This invention uses a blockchain smart contract technology to manage the actual business layer contracts by creating and deploying a front-end contract, thereby improving the security of the business layer contracts. Attached Figure Description

[0035] Figure 1 This is a diagram illustrating the offline signature of signer 1 in this invention;

[0036] Figure 2 Send an on-chain transaction illustration to signer 2 of this invention;

[0037] Figure 3 This is a flowchart of the present invention. Detailed Implementation

[0038] The present invention will be further described below with reference to the embodiments and accompanying drawings. Example 1

[0039] Figure 1 The off-chain signing by signer 1, as shown, is performed as follows:

[0040] (1) Signer 1 obtains networkId, business contract address, value, data, expected expire time, and sequenceId parameters, where sequenceId is the latest value read from the previous contract;

[0041] (2) Encode the parameters in step (1) using ABI (Application Binary Interface). ABI encoding is a common encoding method for blockchain. Then, perform the keccak-256 (networkId||businesscontract address||value||data||expire time||sequenceID) operation on the encoded parameters.

[0042] (3) Perform ECDSA (Elliptic Curve Signature Algorithm) on the hash result of step (2), using secp256k1 as the curve, and generate a signature.

[0043] (4) Signer 1 transmits the parameter information from step (1) and the signature from step (3) to signer 2.

[0044] Signer 2 sends on-chain transaction diagram Figure 2 As shown, the specific operation is as follows:

[0045] Signer 2 obtains the parameters and signature from signer 1.

[0046] (1) Signer 2 calls the sendMultiSigTx method of the preceding contract.

[0047] (2) The required parameters are business contract address, value, data, expireTime, and signature. This information is obtained from step (1). The sequenceId is no longer needed for this step.

[0048] (3) The sendMultiSigTx method of the preceding contract verifies the parameters in step 2.

[0049] (3.1) First, encode the parameters (business contract address, value, data, expireTime) in step (2) and the sequenceId of the record in the contract;

[0050] (3.2) Then use the signature verification in step (2) to verify the encoded result in a;

[0051] (3.3) After step (3.2) is completed, an operation to be performed will be sent to the business contract address. The operation content is obtained from the data in step (2).

[0052] (3.4) If the verification in step (3.2) fails, the transaction will fail and terminate.

[0053] like Figure 3 As shown, the specific steps are as follows:

[0054] (1) Deploy and publish the pre-contract, and simultaneously designate three signer accounts and write them into the pre-contract;

[0055] (2) Set the administrator account of the business layer contract to the multisignature address published in step (1);

[0056] (3) Signer 1 organizes the parameters of the business contract to be operated and signs them, and then sends these parameters and signatures to Signer 2;

[0057] (4) Signer 2 uses the parameters and signature provided by Signer 1 to initiate a contract call to the forward contract;

[0058] (5) The preceding contract verifies the parameters provided by signer 2, and verifies whether signer 1 and 2 belong to the three signers set in step (1). If not, the verification fails and the transaction is terminated.

[0059] (6) After the verification is passed, the front-end contract initiates an operation on the business layer contract, and the business layer contract executes the specific operation.

Claims

1. A method for managing 2 / 3 of the permissions of blockchain smart contracts, characterized in that... The system employs a 2 / 3 signature method, requiring at least two out of three signers to agree on a transaction before authorization is sent. A pre-contract is published to manage the permissions of the business smart contracts, and this pre-contract manages the actual business contracts. Operations on the business contracts by the pre-contract must meet the multi-signature requirement; that is, all methods calling the business contracts in the pre-contract must satisfy the multi-signature check, and the signature is in the 2 / 3 form. Moreover, this pre-contract is universal and applicable to most business contracts. The business contract operation can be executed by having any two of the three signers sign it. The aforementioned front-end contract provides a method for sending multi-signature transactions. This method requires five parameters: the business layer contract address managed by the front-end contract (businessContractAddress), the amount of native tokens (value) attached when calling the business layer contract method, the legal business layer method to be called and the parameters required by the method (data), the expiration time stamp (expireTime) of the multi-signature transaction, and the signature (signature) performed by any signer on the above four parameters and the two parameters (sequenceId and networkId) maintained in the front-end contract. The three signers are Signer 1, Signer 2, and Signer 3. Any two of the signers must perform the following operations, and upon successful completion, the business contract operation will be executed; details are as follows: (A) Off-chain signature by signer 1 When business contract operations are required, first prepare the data that needs to be signed: The network ID of the blockchain to which the preceding contract belongs; Business layer contract address; The optional amount of native tokens to be sent to the business layer contract; Call the business layer contract method and specify the required parameters; The expiration timestamp for this operation; the operation will fail if this time is exceeded. The sequenceId maintained in the preceding contract starts from 0 and increments by 1 each time it is used. (B) Signer 2 sends on-chain transaction Signer 1 sends the business layer contract address from step (A); the optional number of native tokens to be sent to the business layer contract; the business layer contract method to be called and the required parameters; the expiration time stamp of this operation, which will fail if the operation exceeds this time; and the final signature to Signer 2. Signer 2 uses these five pieces of data as parameters to call the sendMultiSigTx method of the preceding contract. (C) Verify and execute the front-end contract and the business layer contract The pre-contract verification process is as follows: Concatenate all parameters, along with the networkId and sequenceId maintained by the preceding contract, and then perform a hash. Use the hash value and the passed-in signature to reconstruct the signer account. If the signer account is a signer of the previous contract... If one of the names is correct, continue the verification; otherwise, return an error. Verify the expiration timestamp; if the expiration date has been reached, return an error. The caller of this call must also be one of the signers of the preceding contract; Verify that the caller of this call is not the signer's account; If all the above validations pass, the value and data parameters are passed to the business layer contract, and the business layer contract operations are executed.

Images