Multi-party fair contract signing system and method based on off-chain protocol and on-chain contract

Abstract

The invention relates to the technical field of computers, discloses a multi-party fair contract signing system and method based on an off-chain protocol and an on-chain contract, and aims to improve the safety and efficiency of contract signing. The system comprises a contract signing party, a key generation center, a signature aggregator, an intelligent contract and a block chain. The contract is encrypted by generating the shared key under the chain, and digital signature and verification are executed on the chain, so that privacy is effectively protected, and the transaction cost is reduced. The key generation center provides public parameters, the signature aggregator aggregates part of signatures of all parties into multiple signatures, and the smart contract verifies the validity of the signatures and executes contract terms. According to the scheme, the non-tampering property of the record is ensured through the block chain, meanwhile, the fairness is maintained by utilizing a punishment mechanism, and the method is suitable for multi-party contract signing scenes such as cross-border trade.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and specifically relates to a multi-party fair contract signing system and method based on off-chain protocols and on-chain contracts. Background Art

[0002] The popularity of electronic contracts has significantly improved the efficiency of contract signing and management, especially in the signing of cross-border trade contracts, but it has also brought challenges to security and fairness. The traditional signing process is susceptible to signature forgery and unfairness, and although the existing solutions focus on security, they may lead to unfairness due to collusion by third parties. Although the blockchain solution provides traceability and tamper-proof features, it has the risk of privacy leakage.

[0003] Previous blockchain-based fair contract signing schemes have mainly focused on scenarios with a small number of signatories, and these agreements usually become time-consuming and expensive when the number of signatories increases. To overcome this problem, we propose a new model that aims to achieve low latency and low cost while scaling the number of signatories.

[0004] To address these issues, this paper proposes a multi-party fair contract signing model that combines off-chain protocols and on-chain smart contracts. By sharing keys to encrypt off-chain contracts and signature aggregators to reduce the communication burden and avoid the risk of sensitive information being exposed on the chain, smart contracts are used on the chain to verify signatures and execute penalty mechanisms to ensure the fairness of the system. The combination of on-chain and off-chain processing allows the system to be expanded without increasing the complexity of the chain to accommodate a larger group of signatories. Security and performance analysis and simulation experiments show that this scheme achieves fairness, security, and efficiency in multi-party contract signing. Summary of the invention

[0005] The present invention aims to solve the technical problem that the blockchain solution in the above-mentioned prior art may increase delays and costs when multiple parties participate.

[0006] To achieve the above object, the present invention provides the following technical solutions:

[0007] A multi-party fair contract signing system based on off-chain protocols and on-chain contracts, including contract signatories, key generation centers, signature aggregators, smart contracts and blockchains;

[0008] The contract signatory generates its own public-private key pair, calculates the shared key with other signatories, encrypts the contract information, digitally signs the encrypted contract, submits part of the signature to the signature aggregator for aggregation, and submits part of the signature to the smart contract for verification;

[0009] The key generation center is used to generate the public parameters of the system and securely distribute the public parameters to all participants;

[0010] The signature aggregator is used to receive partial signatures from each signatory, aggregate the partial signatures of each signatory into a complete multi-signature according to the MuSig protocol, and submit the final multi-signature to the smart contract as a certificate of contract signing;

[0011] Smart contracts are used to receive partial signatures submitted by contract signatories and multi-signatures submitted by signature aggregators, verify their validity, make judgments based on the status of contract signing, and hold dishonest behavior accountable. After the contract is successfully signed, the multi-signatures are recorded on the blockchain;

[0012] Blockchain is used to provide an open, transparent, and tamper-proof record of contract signing.

[0013] Preferably, the common parameters include a generator g, a hash function H, and a bilinear map e.

[0014] A multi-party fair contract signing method based on an off-chain protocol and an on-chain contract is used to execute a multi-party fair contract signing system based on an off-chain protocol and an on-chain contract, comprising the following steps:

[0015] S1. Key generation: The key generation center generates a set of public and private key pairs (pk i ,sk i ), where pk i is the public key, sk i Private keys, and distribute these keys to individual signers;

[0016] S2. Contract encryption: Use the multilinear mapping Diffie-Hellman protocol to generate a shared key k. Each participant generates their own key pair off-chain and uses the generated shared key k to symmetrically encrypt the contract content to form an encrypted contract m.

[0017] S3. Signer signature: Each signer i digitally signs the encrypted contract m, generating their own partial signature σ i , submitted to the signature aggregator for signature aggregation, so that the signature aggregator collects the partial signatures and public keys of all signers and generates an aggregate signature;

[0018] S4. Signature aggregation: The signature aggregator aggregates each signature to form a multi-signature σ agg , and upload it to the smart contract together with the signature verification information, and pay no less than the preset amount of ether to the contract account;

[0019] S5. Multi-signature verification: The smart contract is responsible for verifying the submitted multi-signatures. The smart contract executes the verification procedure to check the validity of the aggregated signature.

[0020] As a preference, in step S3, the signer needs to send the partial signature σ within a preset time. i Upload to the smart contract and pay no less than the preset amount of ether to the contract account;

[0021] Preferably, in step S5, after verification, the smart contract stores the contract content and related signatures and multiple signatures on the blockchain. According to the terms of the contract, the smart contract automatically performs corresponding operations to ensure the fairness and non-tamperability of the signing process, and automatically refunds the pre-paid Ether.

[0022] Preferably, in step S6, when multi-signature verification fails, the penalty mechanism designed in the smart contract will verify the partial signature of each signatory one by one to trace and determine the root cause of the problem, identify and punish dishonest signatories through the smart contract, and ensure the fairness of the signing process.

[0023] As a preferred method, in step S2, the Advanced Encryption Standard AES algorithm is used to encrypt and decrypt the contract. The contract encryption and decryption algorithm is as follows: Public parameter generation: input the security parameter q and the number of participants n to KGC. KGC determines the relationship between the number of participants n and the linear mapping of K parties n=K+1, ensures that there are at least K+1 participants when calculating the multi-party negotiation session key, selects a large prime number q to define the size of the finite field, and selects an elliptic curve group G 1 and target group G 2 , Group G 1 The order is q, and g is the group G 1 A generator of , e is a generator that satisfies In addition, we need to select three hash functions H com , H agg , H sig , for use in the subsequent multi-signature phase, output public parameters params = (e, g, q, H com , H agg , H sig ), broadcast the public parameters params in the system;

[0024] Key generation: The input is the public parameter params and the identity of the participant i∈{1,...,n}, and the participant i selects a random number sk i For its private key, calculate For its public key, broadcast the public key within the system;

[0025] Key negotiation: Each participant i inputs public parameters params and the private key sk of participant i i , other participants' public keys (pk 1 , ..., pk j )i≠j ; Each participant sk i The session key k negotiated by multiple parties can be calculated locally. According to the properties of multi-party linear mapping, the session key k calculated by each participant is the same. The calculation formula of k is as follows:

[0026]

[0027] Encryption process: The negotiated contract is regarded as message M. The parties use the shared key k as the symmetric encryption key and use the AES algorithm to encrypt message M to generate encrypted ciphertext m. Finally, the encrypted contract m is submitted to SA, which determines whether all ciphertexts are the same, where m = AES encrypt (M, k);

[0028] Decryption process: The participants use the shared key k and AES algorithm to decrypt the ciphertext m and restore the original message M, where M = AES decrypt (M, k).

[0029] As a preference, n signatories jointly sign an encryption contract m∈{0,1} * , the designed multi-signature authentication scheme describes the multi-party contract signing authentication algorithm. The specific contents of the multi-party contract signing authentication algorithm are as follows:

[0030] Aggregate public key: Each signer sorts the public keys to form a public key list L = {pk 1 , pk 2 , ..., pk n}, and calculate the weight a of each signer based on this list i , a i =H agg (pk i , L); then use the weight to calculate the aggregate public key PK agg , the aggregate public key calculated by each signer is the same. Similarly, the signature aggregator calculates the same aggregate public key PK agg ,

[0031] Non-interactive commitment: Each signer i generates a random number r i ←Z q , calculate its partial commitment value and the commitment hash t i =H com (R i ), and then the partial commitment value R i and hash value t i Sent to the signature aggregator, the signature aggregator verifies equation t i =H com (R i) is true, if the equality is not true, the protocol is terminated, otherwise the aggregate commitment value R is calculated. agg , and the aggregate commitment value R agg Broadcast to each signer, Each signer then calculates the challenge value c, c = H sig (PK agg , R agg , m);

[0032] Generate partial signature: Signer i uses his private key to calculate statement value s i , partial signature σ i By the partial commitment value R i and statement values ​​s i Each signer i will sign part of σ i Send it to the signature aggregator and submit the signature to the smart contract for later verification and dispute resolution. i =r i +ca i sk i mod q;σ i =(R i ,s i );

[0033] Aggregate multi-signature: The signature aggregator is based on the signature set σ={σ 1 , σ 2 , ..., σ n} Compute aggregate statements agg , output multi-signature σ agg ; σ agg =(PK agg , R agg ,s agg ); The signature aggregator will multi-signature σ agg 、Hash function H sig And the encrypted contract m is submitted to the smart contract for verification;

[0034] Verify multi-signatures: The smart contract verifies the multi-signatures and calculates c = H based on the submitted multi-signatures and the encrypted contract m. sig (PK agg , R agg , m);

[0035] Verify partial signatures: The smart contract verifies in turn whether each signer has signed the contract correctly, and for signer i, calculates:

[0036] Preferably, in verifying the partial signature, the equation If it holds, then through the partial signature σi , equation Not established, refuse to sign.

[0037] Preferably, the smart contract includes verification of submitted multi-signatures, verification of partial signatures of individual signatories, handling of erroneous behavior, and storage of successfully verified signatures on the blockchain for long-term auditing.

[0038] Compared with the prior art, the technical effects and advantages of the present invention are:

[0039] This multi-party fair contract signing system and method based on off-chain protocols and on-chain contracts can effectively protect the privacy of participants and the confidentiality of contract contents and prevent sensitive information leakage by combining off-chain protocols and on-chain smart contracts. At the same time, the use of digital signature and multi-signature technology ensures the unforgeability and non-repudiation of contract signing. The automatic verification and accountability mechanism in the smart contract ensures fairness in the contract signing process. If a signatory behaves dishonestly, the smart contract can automatically identify and implement punishment measures.

[0040] Off-chain signature aggregation reduces the number of transactions on the chain, thereby reducing transaction fees and confirmation time. This allows the system to maintain low latency and low costs even when multiple parties are involved. The model allows the number of participants to be expanded without increasing the complexity of the chain, adapting to larger-scale contract signings, and maintaining the flexibility and scalability of the system. The storage of contract content and signatures on the blockchain ensures the openness, transparency and immutability of information, which is conducive to long-term auditing and tracing.

[0041] Smart contracts can automatically perform corresponding operations according to the terms of the contract, reducing manual intervention and improving the efficiency and accuracy of contract execution. Through digital and automated processes, contract management is simplified and paper documents and manual processing are reduced. The system is particularly suitable for cross-border trade contracts because it provides a safe and efficient contract signing environment, helping to reduce legal and administrative barriers in cross-border transactions.

[0042] In summary, the system and method improve the efficiency of contract signing and management, reduce costs, and provide a reliable technical solution for multi-party contract signing while ensuring security and fairness. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 The Schnorr digital signature algorithm diagram of the present invention;

[0044] Figure 2 It is a system model architecture diagram of the present invention;

[0045] Figure 3 It is the contract sequence diagram of the present invention;

[0046] Figure 4 This is the off-chain time consumption diagram of the present invention;

[0047] Figure 5 This is a comparison chart of the time overhead of the aggregate signature of the present invention;

[0048] Figure 6 This is a comparison chart of the time cost of verifying multiple signatures of the present invention.

[0049] Figure 7 This is a result diagram of the signature evidence storage of the present invention;

[0050] Figure 8 This is the gas cost graph of the present invention;

[0051] Fig. 9 This is a gas consumption comparison analysis diagram of the present invention. DETAILED DESCRIPTION

[0052] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] The MuSig scheme has been improved by introducing a signature aggregator role. The signer provides his public key and discrete logarithm to the signature aggregator, which is responsible for aggregating multiple signatures, thereby reducing the number of interactions and reducing the complexity of communication. We combined blockchain technology. In order to prevent the privacy leakage of the contract, we use the MDH protocol to generate a shared key k to encrypt the contract. The signature of each signer will be submitted to the smart contract for verification to prevent the signature aggregator from tampering with the signature and aggregating false multiple signatures. In the design of the smart contract, we proposed a penalty mechanism to ensure the fairness of the signing process.

[0054] First, do the preparation work, multilinear mapping: Assume the mapping is a k-linear map, then it satisfies the following properties: (1) G 1 and G 2 are groups of the same prime order; (2) if x 1 , ..., x k ∈G 1 So (3) The mapping e is non-degenerate: if g∈G 1 It's G 1 The generator of G, then e(g, ..., g) is 2 The generator of .

[0055] Schnorr digital signature algorithm: The main idea of ​​Schnorr signature is based on the discrete logarithm problem. Let be the cyclic group of prime order, be the generator on the finite field, and have a hash function. The message to be signed, the signature σ, the specific steps are as follows Figure 1 As shown;

[0056] (1) Key generation: The signer first generates a pair of keys, including the private key sk←Z q and public key pk=g sk , output the signer's public and private key pair (pk, sk). (2) Signature generation: For the message m to be signed, the signer randomly selects a private random number r←Z q , calculate R = g r , and calculate e = H (R, m), where H is a hash function. Then calculate s = r-sk·e. Finally, output the signature pair σ = (e, s), and send the signature pair σ and the message m to the verifier. (3) Signature verification: The verifier uses the public key pk, the message m and the signature σ = (e, s) for verification. First, calculate R′ = g s pk e , compare whether R′=R. Then calculate e′=H(R′,m) and verify whether e′ is equal to e. If the final verification passes, the signature is valid, otherwise the signature is invalid.

[0057] Multi-party contract signing authentication model: In the past, blockchain-based fair contract signing schemes have mainly focused on the scenario of a small number of signatories, and when the number of signatories increases, these agreements usually become time-consuming and expensive. To overcome this problem, we propose a new model that aims to achieve the characteristics of low latency and low cost while expanding the number of signatories.

[0058] When designing our multi-signature authentication scheme, we fully considered the respective characteristics of on-chain and off-chain. If all aggregation processes are carried out on the blockchain, the immutability of each step is guaranteed, so there is no need to worry about cheating or violating the protocol by the aggregation nodes. However, on-chain operations require paying Ethereum's Gas fees, resulting in high costs. Secondly, the throughput and processing speed of blockchains are generally low, limiting their ability to handle large amounts of data or high-frequency transactions. In addition, although the risk of sensitive data leakage brought about by the transparency of on-chain aggregation can be mitigated by privacy protection technologies, these technologies are often complex and computationally expensive.

[0059] In contrast, off-chain operations do not require blockchain transaction fees, can handle large amounts of data and high-frequency transactions, and can better protect privacy and sensitive information. However, off-chain solutions require trust in off-chain aggregators, and there is a risk that nodes may do evil. In addition, off-chain data lacks the persistence and tamper-resistance of on-chain data, and additional measures may be required to ensure the secure storage of data.

[0060] To this end, we proposed the "off-chain protocol on-chain contract model", where most of the calculations and signature collection are completed off-chain, reducing the frequency and cost of on-chain interactions. Only the final verification is performed on the chain to avoid high gas fees. Automatic execution and verification are achieved through smart contracts, reducing the need for trust in any single party. Even if the signature aggregation is performed off-chain by SA, we can resolve disputes through the local verifiable method of the smart contract designed in the end, and prevent malicious behavior of SA in the semi-centralized model. The designed local verifiable method can prevent malicious behavior of any party. Only necessary information is uploaded to the chain to minimize the amount of public information.

[0061] System model: According to the solution we designed, the system model includes the following five entities: Signers, Key Generation Center (KGC), Signature Aggregator (SA), Smart Contract, and Blockchain. Figure 2 As shown, the functions of each entity are as follows:

[0062] Contract signatories (Signers): Generate their own public-private key pairs, and calculate shared keys with other signatories to encrypt contract information. Digitally sign the encrypted contract, submit part of the signature to the signature aggregator (SA) for aggregation, and submit part of the signature to the smart contract for verification.

[0063] Key Generation Center (KGC): Generates the public parameters of the system, including generator g, hash function, bilinear map e, etc. Securely distributes public parameters to all participants.

[0064] Signature Aggregator (SA): Receives partial signatures from each signatory, and aggregates them into a complete multi-signature according to the MuSig protocol. Submits the final multi-signature to the smart contract as proof of contract signing.

[0065] Smart Contract: Receive partial signatures submitted by the contract signatories and multiple signatures submitted by the signature aggregator (SA) to verify their validity. Make judgments based on the status of contract signing and hold dishonest behavior accountable. After the contract is successfully signed, the multiple signatures are recorded on the blockchain.

[0066] Blockchain: Provides open, transparent and tamper-proof records of contract signing.

[0067] Our approach involves the five key entities listed above, working together through the following six steps:

[0068] (1) Key generation: We assume that there are n signers. KGC first generates a set of public-private key pairs (pk i ,sk i ) and distribute these keys to the individual signers.

[0069] (2) Contract encryption: Since the information stored on the public chain is public, in order to protect the privacy of the contract, we choose to encrypt the contract. Each signatory must understand the content of the contract, so they need to know the key used to encrypt the contract. With this in mind, we use the MDH protocol to generate a shared key k. Then, they use the generated shared key k to symmetrically encrypt the contract to form an encrypted contract m. This effectively maintains the confidentiality of the contract information and ensures that only participants with the corresponding key can decrypt and learn the details of the contract.

[0070] (3) Signer signature: Each signer i digitally signs the encrypted contract m, generating their own partial signature σ i , submitted to SA for signature aggregation. In addition, the signer needs to submit part of the signature σ within a preset time i Upload to the smart contract and pay no less than the preset amount of ether to the contract account.

[0071] (4) Signature aggregation: SA aggregates each signature to form a multi-signature σ agg , and upload it to the smart contract together with the signature verification information, and pay no less than the preset amount of ether to the contract account. The signature aggregation in this process has multiple functions, which not only improves the efficiency of the subsequent signature verification, but also ensures the atomicity of the multi-signature effectiveness. Here, atomicity refers to the multi-signature σ agg When generated, it means that the signatures of all signatories are valid. agg Before generation, even if they each generate a partial signature σ i , we still do not consider a certain signatory to have signed the contract. If one of the signatories fails to complete his part, the entire contract will be considered as not being signed by a single signatory, thus maintaining the fairness of the contract to each signatory.

[0072] (5) Multi-signature verification: The smart contract is responsible for verifying the submitted multi-signatures. Once verified, the multi-signatures will be stored on the blockchain to ensure the fairness and immutability of the signing process. The pre-paid Ether will also be automatically refunded.

[0073] (6) Partial signature verification: If multi-signature verification fails, the smart contract will verify the partial signatures of each signatory one by one to determine the root cause of the problem. This process can identify which signatory or signature aggregator (SA) may have malicious behavior. If dishonest behavior is confirmed, the relevant parties will be punished.

[0074] Contract encryption:

[0075] Since the contract signing involves the blockchain, we need to consider protecting the privacy of the contract. Our design uses the MDH protocol to generate the shared key k and uses the Advanced Encryption Standard (AES) algorithm to encrypt and decrypt the contract. This method allows the generation of shared keys to be independent of any single entity, reducing trust risks. The contract encryption and decryption algorithm is described in Algorithm 1.

[0076] (1) Public parameter generation: Input security parameter q and the number of participants n into KGC. KGC determines the relationship between the number of participants n and the linear mapping of K parties n = K+1, ensuring that there are at least K+1 participants when calculating the multi-party negotiation session key. Select a large prime number q to define the size of the finite field and select an elliptic curve group G. 1 and target group G 2 , Group G 1 The order is q, and g is the group G 1 A generator of , e is a generator that satisfies In addition, three hash functions H need to be selected. com , H agg , H sig , for use in the subsequent multi-signature phase. Output public parameters params = (e, g, q, H com , H agg , H sig ) to broadcast the public parameters params in the system.

[0077] (2) Key generation: The input is the public parameter params and the identity of the participant i∈{1,...,n}. Participant i selects a random number sk i For its private key, calculate The public key is broadcasted in the system.

[0078] (3) Key negotiation: Each participant i inputs the public parameters params and the private key sk of participant i. i , other participants' public keys (pk 1 , ..., pk j ) i≠j Each participant i can calculate the multi-party negotiated session key k locally. According to the properties of multi-party linear mapping, the session key k calculated by each participant is the same. The calculation formula of k is as follows:

[0079] (4) Encryption process: The negotiated contract is regarded as message M. The parties use the shared key k as the symmetric encryption key and use the AES algorithm to encrypt message M to generate encrypted ciphertext m. Finally, the encrypted contract m is submitted to SA, which determines whether all ciphertexts are the same.

[0080] m=AES encrypt (M, k);

[0081] (5) Decryption process

[0082] The participants use the shared key k and the AES algorithm to decrypt the ciphertext m and restore the original message M.

[0083] M=AES decrypt (M, k);

[0084] Algorithm 1: Contract encryption algorithm

[0085]

[0086]

[0087]

[0088] Multi-party contract signing authentication algorithm

[0089] A cryptographic contract m∈{0,1} is signed by n signatories * , we describe the designed multi-party signature authentication scheme as an algorithm. The specific algorithm is shown in Algorithm 2.

[0090] (1) Aggregate public key: In the previous contract encryption step, each signer i has generated a public-private key pair (sk i , pk i ), and has the public keys of other signers. Each signer sorts the public keys to form a public key list L = {pk 1 , pk 2 , ..., pk n}, and calculate the weight a of each signer based on this listi .

[0091] a i =H agg (pk i , L)

[0092] This ensures that the weight of each participant is unique, effectively preventing forged key attacks. Then use the weight to calculate the aggregate public key PK agg , the aggregate public key calculated by each signer should be the same. Similarly, SA can also calculate the same aggregate public key PK agg .

[0093]

[0094] (2) Non-interactive commitment: Each signer i generates a random number r i ←Z q , calculate its partial commitment value and the commitment hash t i =H com (R i ), and then the partial commitment value R i and hash value t i Sent to SA. SA verifies equation t i =H com (R i ) is true, if not, the protocol is terminated. Otherwise, the aggregate commitment value R is calculated. agg , and the aggregate commitment value R agg Broadcast to each signer.

[0095]

[0096] Each signer then calculates a challenge value c.

[0097] c=H sig (PK agg , R agg , m);

[0098] (3) Generate partial signature: The signer i uses his private key to calculate the statement value s i , partial signature σ i By the partial commitment value R i and statement values ​​s i Each signer i will sign part of σ i Sent to SA, and submit the signature to the smart contract for later verification and dispute resolution.

[0099] s i =r i +ca i ski mod q

[0100] σ i =(R i ,s i );

[0101] (4) Aggregate multi-signature: SA is based on the signature set σ = {σ1, σ 2 , ..., σ n} Compute aggregate statements agg , output multi-signature σ agg Although SA aggregates public keys and partial signatures, it does not hold any private keys. Even if SA behaves maliciously or makes mistakes, it cannot forge valid multi-signatures.

[0102]

[0103] σ agg =(PK agg , R agg ,s agg )

[0104] Finally, SA will multi-sign σ agg 、Hash function H sig And the encrypted contract m is submitted to the smart contract for verification.

[0105] (5) Verify multi-signatures: The smart contract verifies the multi-signatures. Based on the submitted multi-signatures and the encrypted contract m, the following can be calculated:

[0106] c=H sig (PK agg , R agg , m)

[0107]

[0108] If the equation holds, then through multi-signature σ agg , otherwise the multi-signature is rejected. When the multi-signature is verified, the multi-signature σ agg The encrypted contract m is stored on the blockchain for long-term audit. If the multi-signature verification fails, the partial verification stage is entered to identify the dishonest signatory.

[0109] (6) Verify partial signature

[0110] The smart contract verifies in turn whether each signer has signed the contract correctly, and for signer i, calculates:

[0111]

[0112] If the equality holds, then by partial signature σ i, otherwise the signature is rejected. If the partial signatures of all signatories are verified, it can be determined that the problem lies with the SA. When it is determined that any party has made a wrong behavior, the penalty measures are initiated and their deposit is confiscated.

[0113] Algorithm 2: Collaborative public key aggregate signature algorithm

[0114]

[0115]

[0116] 4.2.3 Smart Contract Algorithm

[0117] We designed and implemented a smart contract specifically for verifying multi-signature schemes. The main functions of this contract include verifying submitted multi-signatures, verifying partial signatures of each signer, handling erroneous behaviors, and storing successfully verified signatures on the blockchain for long-term auditing. The detailed functional description is as follows:

[0118] (1) Smart Contract Constructor

[0119] The contract will call the constructor for initialization when it is deployed. The constructor accepts the following parameters:

[0120] Table 1 State variable table

[0121]

[0122] The constructor stores this information in the contract and marks each signer as honest, while also setting their initial deposit.

[0123] (2) Pre-deposit of funds

[0124] Participants can deposit funds into the contract through the depositFunds function to pay the margin in advance. The amount of the margin must not be less than the preset amount. The pre-deposit algorithm is shown in Algorithm 3.

[0125] Algorithm 3. Deposit funds

[0126]

[0127] (3) Multi-signature verification

[0128] SA can call submitAggregateSignature function to submit multi-signature and encrypted contract. Verification of multi-signature is performed by verifyAggregateSignature function, which determines the correctness of signature by comparing the hash value of multi-signature and encrypted contract. If multi-signature verification is passed, the contract will store the signature and encrypted contract on the blockchain and trigger the SignatureStored event to ensure the long-term auditability of information. If verification fails, it will enter the partial signature verification stage. The multi-signature verification algorithm is shown in Algorithm 4.

[0129] Algorithm 4. verifyAggregateSignature

[0130]

[0131]

[0132] (4) Partial signature verification

[0133] Each signer submits its partial signature through the submitPartSignature function. If the multi-signature verification fails, the contract will verify the partial signature of each signer one by one. The verifyPartSignatures function iterates over each signer and verifies its partial signature. Signers who fail the verification will be punished. If all partial signatures are verified, but the multi-signature is still invalid, the SA will be considered a problematic party and the penalty mechanism will be triggered. The partial signature verification algorithm is shown in Algorithm 5.

[0134]

[0135] Algorithm 5. verifyPartSignatures

[0136] (5) Penalty mechanism

[0137] If the signer submits an invalid signature, the contract will mark the signer as dishonest through the penalizeSigner function. Finally, the withdrawFunds function returns the deposit to all honest signers after the signing process deadline. Dishonest signers will not be able to get a refund and their deposit will be confiscated. The penalty algorithm is shown in Algorithm 6.

[0138] Algorithm 6. Penalty

[0139]

[0140] When the smart contract is executed normally, the execution process is as follows Figure 3 As shown in the timing diagram in . When the contract is deployed, the constructor accepts parameters such as the list of signers, signature aggregator, fee map, preset guarantee amount and deadline, and stores this information in the contract. All signers are marked as honest after the contract is deployed and their initial margin is set. Participants call the depositFunds function to deposit a margin into the contract. The contract checks whether the deposit amount is not less than the feeThreshold. If the conditions are met, the funds are stored and the corresponding entries in the fee map are updated. SA calls submitAggregateSignature to submit the multi-signature and encrypted contract. The contract verifies the multi-signature through the verifyAggregateSignature function. If the signature matches the hash value of the contract, the contract stores the signature and encrypted contract on the blockchain and triggers the SignatureStored event.

[0141] The following situations may occur when a smart contract is incorrectly executed. 1) Funds pre-deposit error. If the deposit amount received by the depositFunds function is less than the feeThreshold, the contract will reject the deposit and issue an error prompt. When a non-signer or signature aggregator attempts to call the function, it will trigger a permission check failure, resulting in the operation being rejected. 2) Signature verification error. If the multi-signature submitted by submitAggregateSignature does not match the hash value of the encrypted contract, the signature verification will fail and enter the partial signature verification stage. If partial signature verification fails, the contract will mark the corresponding signer as dishonest and may lead to the termination of the entire signing process. If the SA or signer maliciously submits an invalid signature, the contract will trigger a penalty mechanism to restrict it from obtaining a refund.

[0142] Security Analysis

[0143] Correctness: If the signature published by the signer on the public chain can be verified by the smart contract, it means that this solution is correct.

[0144] Proof: Partial signature verification checks each signer’s partial signature one by one through the smart contract Whether the verification conditions are met If the verification condition is met, it indicates that the partial signature of the signer is correct.

[0145]

[0146] Then we have:

[0147]

[0148] in Therefore, the verification condition is:

[0149]

[0150] Multi-signature verification is performed by checking the multi-signature σ generated by SA agg Whether the verification conditions are met If this condition holds, the multi-signature is valid and all signatories’ partial signatures have been correctly generated and successfully aggregated.

[0151]

[0152] Right now

[0153]

[0154] Forgeability:

[0155] (1) Proof of the unforgeability of partial signatures

[0156] Attack Model: Attacker The goal is to obtain the private key sk of a signer i without knowing the private key sk of a signer i. i In the case of forging the signer's partial signature on the encrypted contract m And make the forged signature pass verification.

[0157] Proof: Assume that the attacker Trying to forge s′ i , that is, calculate: s′ i = r′ i +c·a i ·sk i

[0158] where r′ i yes A self-selected random number. Part of the signature verification process checks whether the following conditions are true:

[0159] in Attacker If we can successfully forge s′ i , which means it can find a suitable r′ i So the above formula is established. But due to sk i is unknown, Need to solve the discrete logarithm problem sk i , since solving the discrete logarithm problem is not feasible under the random oracle model and discrete logarithm assumption

[29]

[30] . Therefore, some signatures are unforgeable.

[0160] (2) Proof of the unforgeability of multiple signatures

[0161] Attack Model: Attacker The goal is to forge multiple signatures for a cryptographic contract m without having the private keys of all signers. Make it pass verification.

[0162] Proof: Assume that the attacker Trying to forge s′ agg , that is, without knowing the private keys sk of all signers 1 ,sk 2 , ..., sk n In the case of, construct:

[0163] The multi-signature verification process checks that the following conditions are true: Among them PK agg is the weighted product of all signers’ public keys. If Can successfully forge s′ agg , it must be possible to calculate for each s′ i So that the following equation holds:

[0164]

[0165] This means Each sk must be solved i Since solving the discrete logarithm problem is not feasible under the random oracle model and discrete logarithm assumption, the attacker It is impossible to forge all s′ i , it is impossible to forge multiple signatures.

[0166] Non-repudiation:

[0167] Non-repudiation means that in the process of multiple parties signing a contract, the operations completed and the signed actions of the signatories cannot be denied or revoked.

[0168] Proof: Suppose signer i attempts to deny having generated s i , they must prove s i It is not calculated by them. To make the deniability work, the attacker A valid signature s′ must be constructed i , but this signature cannot depend on sk i , and still needs to pass the signature verification. This means that the attacker Need to construct an s′ i So that:

[0169] So s′ i Must be equal to r i +c·ai ·sk i mod q. attacker Try to construct another c′=H sig (PK′ agg , R′ agg , m′) so that c′ can be used without using sk i The above equation is true when . This means Need to find collision: H sig (PK' agg , PK' agg , m′)=H si g(PK agg , R agg , m);

[0170] But this is not feasible in the random oracle model because hash functions are collision-free. i Generate a valid s i Therefore, once a signer generates a signature, they cannot deny having generated it.

[0171] Furthermore, once the signature is verified by the smart contract and stored on the blockchain, the signatory cannot deny having signed the contract due to the immutability of the blockchain. Therefore, the entire process ensures non-repudiation, and the signatory cannot claim that he did not sign the contract or attempt to forge a new signature afterwards.

[0172] Fairness:

[0173] In the process of multi-party contract signing, fairness is the key principle to ensure that all parties enjoy similar rights and interests under the same conditions. Since smart contracts are only responsible for signature verification and do not participate in the key generation and signature generation process, they remain neutral throughout the process and do not favor any party. All signature verification processes are automatically executed by smart contracts, and the verification results are public and cannot be tampered with. These results will be stored on the blockchain, ensuring the transparency and fairness of signature verification.

[0174] The atomicity of the contract signing process is the core guarantee of the fairness of the scheme. Only when all signatories submit valid partial signatures and pass the verification of the smart contract, the entire signing process will be considered successful and the signature record will be stored on the blockchain. If any signer fails to submit a signature or submits an invalid partial signature, the smart contract will reject the signature, causing the entire signing process to fail and the signature record cannot be stored on the blockchain. If signature aggregation fails or partial signature verification fails, the smart contract can identify and punish malicious participants to prevent any signer or SA from attempting to cheat or disrupt the execution of the agreement. If the signer completes the signature within the specified time, the smart contract can automatically trigger the refund mechanism and refund all paid fees to all signatories. This mechanism is implemented through timestamp control and automatic execution of smart contracts, further ensuring the fairness of the entire process.

[0175] Experiment and analysis

[0176] Experimental environment:

[0177] First, the development environment of the multi-signature algorithm is introduced. The experiment is conducted on the PyCharm platform, using Python 3.8 as the development language, and citing the PyCryptodome 3.15 cryptographic library for writing off-chain protocols. The smart contract part uses the web browser-based Remix IDE as a development tool, and uses the Solidity language to write and deploy smart contracts.

[0178] Experimental results analysis

[0179] Off-chain time analysis:

[0180] In a local environment, we tested this scheme to evaluate the time changes of aggregating multi-signatures and verifying multi-signatures as the number of signers increases. Under the same message m, we set the number of signers to 2, 4, 6, 8, 10, 12, 14, 16, and 18. Each group of experiments was tested 5 times, and the average of the 3 groups of experiments was taken.

[0181] pass Figure 4 From the observation, we can clearly find that whether it is aggregating multi-signatures or verifying multi-signatures, the time consumption does not change much as the number of signatories increases. In addition, the time for aggregating multi-signatures is slightly longer than that for verifying multi-signatures.

[0182] In the process of aggregate multi-signature, n-1 scalar additions are mainly involved. The time complexity of these operations is low. Scalar addition is a relatively simple operation with low time overhead. The complexity of scalar addition is linear with the number of signatories, but because each operation is relatively fast, the total computation time does not increase significantly with the increase of the number of signatories.

[0183] The length of a multi-signature is roughly the same as that of a normal single signature, so the time to verify a multi-signature is almost unaffected by the number of signatories. The process of verifying a multi-signature involves one hash operation, two elliptic curve scalar multiplications, and one elliptic curve point addition. The complexity of the hash operation is fixed and depends on the size of the input data, but it can usually be completed in a shorter time. Elliptic curve scalar multiplication is a computationally intensive operation that involves multiplying a scalar by a point on the elliptic curve. This operation has a high time complexity and is the most time-consuming part of the verification process. Elliptic curve point addition has a lower time overhead than scalar multiplication, but it is still more complex than ordinary scalar addition.

[0184] Since verifying multi-signatures requires complex elliptic curve operations, including two scalar multiplications and one point addition, plus hash operations, it takes more time than aggregate multi-signatures. In contrast, aggregate multi-signatures only need to perform n-1 scalar additions, which is relatively simple and less time-consuming.

[0185] It can be seen that our multi-signature scheme reduces the amount of data transmitted on the network and the amount of computation required for signature verification, which helps to reduce the communication overhead in distributed systems, especially in scenarios where frequent multi-party signatures are required.

[0186] Off-chain time comparison analysis: For comparison purposes, we first tested the time overhead of the signature and verification phases of this scheme, and then tested the Boneh scheme

[31] and the Drijvers scheme

[32] . The number of signers in the test was 2, 4, 6, 8, and 10, and the average running time of the five tests was taken. Figure 5 and Figure 6 As shown in the figure, both the verification speed and the signing speed of this scheme are much faster than the other two signature schemes.

[0187] The Drijvers signature scheme shows a large change when the number of signatories increases. This is mainly because the signature length of the Drijvers scheme increases significantly with the increase in the number of signatories, which leads to a significant increase in system operation and storage overhead. In contrast, the Boneh scheme has a slight change when the number of signatories increases, and its computational complexity is linearly related to the number of signatories. Compared with these two schemes, the scheme we proposed has extremely small changes when the number of signatories changes. This shows that our scheme is not only efficient, but also more stable under different numbers of signatories.

[0188] On-chain cost analysis: MetaMask's test network was selected to verify and evaluate the functionality of smart contracts. Through the test network, we were able to simulate and test the performance of smart contracts in the actual Ethereum network environment, providing a credible basis for research.

[0189] In the process of verifying the deployment of smart contracts, we adopted the "Injected provider-MetaMask" mode, which is an efficient interaction method provided by the Ethereum DApp browser integrated with MetaMask. Users can easily access Ethereum accounts on the web through MetaMask, and conduct transactions and store evidence information. During the initialization of the smart contract, we set the signature deadline and the minimum prepaid fee threshold for the evidence information. The initial value settings for smart contract deployment are shown in Table 4.

[0190]

[0191] After successful deployment, we can obtain the address of the smart contract for further interaction and testing. The signature aggregator can flexibly add or remove signers. Both the signature aggregator and the signer have the right to deposit fees above the threshold into the contract. If the signature is submitted before the deadline and verified by the smart contract, the fee can be refunded; otherwise, the fee will not be refunded to ensure that the contract signing process is completed within a certain period of time. This design ensures the smooth progress of the transaction while safeguarding the rights and interests of both parties.

[0192] pass Figure 7 It can be observed that when Signer1 uploads the signature correctly, the smart contract will refund the full amount of the fee previously deposited by Signer1. The refund operation is achieved through an internal transaction with the smart contract that uploaded the information.

[0193] Figure 8The gas cost of this scheme is shown in Figure 1. The gas cost of contract deployment is significantly higher than that of multi-signature verification. This is because the operations involved in contract deployment are more complex, usually including code storage, initialization operations, and setting of state variables. These operations need to be permanently stored on the blockchain and take up a large storage space, so the gas consumption is high. In contrast, the cost of multi-signature verification is lower, and the gas cost does not change much with the increase in the number of participants. This is because the computational operations mainly involved in multi-signature verification are independent of the number of participants, and the length of the multi-signature is basically the same as the length of a single signature. Therefore, even if the number of participants increases, the gas cost of the verification process remains at a relatively stable level. Overall, the efficiency and scalability of the verification process reflect the performance advantages of the multi-signature mechanism, allowing the system to maintain a low cost when facing a large number of signatories.

[0194] Comparative analysis of on-chain costs

[0195] Fig. 9 The gas values ​​consumed by five schemes to verify signatures are shown to evaluate the on-chain transaction confirmation costs. In the comparison of gas consumption in the signing process, our scheme performs well in significantly reducing gas consumption. The experimental results show that Hinarejos's scheme

[26] consumes 172006 gas units, Ferrer-Gomila's scheme

[28] utilizes 274576 gas units, Syta's scheme

[33] requires 58610 gas units, and Maxwell's scheme

[18] consumes 56490 gas units. In comparison, our scheme performs well, consuming only 30288 gas units.

[0196] Our solution achieves low gas consumption, mainly due to the following key optimization points. First, we move the signature calculation process off-chain, and only need to verify it on the smart contract, which effectively reduces the computational overhead on the public chain. Our solution has shown good gas efficiency in practical applications, providing key support for cost-effective and resource-efficient transactions. Gas consumption directly affects the economic cost of users on the blockchain. Our solution provides a cost-effective solution for users participating in blockchain signature operations.

[0197] The present invention proposes a multi-party fair contract signing scheme that combines off-chain protocols and on-chain smart contracts, aiming to solve the security and fairness problems existing in the signing process of cross-border trade electronic contracts. By adopting the MDH protocol to generate a shared key and encrypt the contract content, the privacy of the contract content is guaranteed. In addition, the introduction of the signature aggregator reduces the communication burden, and at the same time, the smart contract is used to verify multiple signatures and execute the penalty mechanism on the chain to ensure the fairness and security of the signing process. Compared with traditional blockchain-based solutions, this solution shows significant advantages in time and economic expenses, especially in scenarios with a large number of signatories, it can effectively reduce gas fees and computational complexity. Through security and performance analysis, as well as verification of simulation experiments, this solution achieves efficiency, scalability and fairness in multi-party contract signing, providing a reliable solution for cross-border trade contract signing.

[0198] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A multi-party fair contract signing system based on off-chain protocols and on-chain contracts, characterized in that: Includes contract signatories, key generation centers, signature aggregators, smart contracts, and blockchains; The contract signatory generates its own public-private key pair, calculates the shared key with other signatories, encrypts the contract information, digitally signs the encrypted contract, submits part of the signature to the signature aggregator for aggregation, and submits part of the signature to the smart contract for verification; The key generation center is used to generate the public parameters of the system and securely distribute the public parameters to all participants; The signature aggregator is used to receive partial signatures from each signatory, aggregate the partial signatures of each signatory into a complete multi-signature according to the MuSig protocol, and submit the final multi-signature to the smart contract as a certificate of contract signing; Smart contracts are used to receive partial signatures submitted by contract signatories and multi-signatures submitted by signature aggregators, verify their validity, make judgments based on the status of contract signing, and hold dishonest behavior accountable. After the contract is successfully signed, the multi-signatures are recorded on the blockchain; Blockchain is used to provide an open, transparent, and tamper-proof record of contract signing.

2. According to claim 1, a multi-party fair contract signing system based on off-chain protocol and on-chain contract is characterized by: The public parameters include generator g, hash function H, and bilinear map e.

3. A multi-party fair contract signing method based on an off-chain protocol and an on-chain contract for executing a multi-party fair contract signing system based on an off-chain protocol and an on-chain contract as described in claim 1 or 2, characterized in that: The specific steps include: S1. Key generation: The key generation center generates a set of public and private key pairs (pk i ,sk i ), where pk i is the public key, sk i Private keys, and distribute these keys to individual signers; S2. Contract encryption: Use the multilinear mapping Diffie-Hellman protocol to generate a shared key k. Each participant generates their own key pair off-chain and uses the generated shared key k to symmetrically encrypt the contract content to form an encrypted contract m. S3. Signer signature: Each signer i digitally signs the encrypted contract m, generating their own partial signature σ i , submitted to the signature aggregator for signature aggregation, so that the signature aggregator collects the partial signatures and public keys of all signers and generates an aggregate signature; S4. Signature aggregation: The signature aggregator aggregates each signature to form a multi-signature σ agg , and upload it to the smart contract together with the signature verification information, and pay no less than the preset amount of ether to the contract account; S5. Multi-signature verification: The smart contract is responsible for verifying the submitted multi-signatures. The smart contract executes the verification procedure to check the validity of the aggregated signature.

4. According to claim 3, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized by: In step S3, the signer needs to send the partial signature σ i Upload to the smart contract and pay no less than the preset amount of ether to the contract account.

5. According to claim 3, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized in that: In step S5, after verification, the smart contract stores the contract content and related signatures and multi-signatures on the blockchain. According to the terms of the contract, the smart contract automatically performs corresponding operations to ensure the fairness and immutability of the signing process, and automatically refunds the pre-paid Ether.

6. According to claim 4, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized in that: In step S6, when multi-signature verification fails, the penalty mechanism designed in the smart contract will verify the partial signatures of each signatory one by one to trace and determine the root cause of the problem. Through the smart contract, dishonest signatories can be identified and punished to ensure the fairness of the signing process.

7. According to claim 3, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized in that: In step S2, the Advanced Encryption Standard AES algorithm is used to encrypt and decrypt the contract. The contract encryption and decryption algorithm is as follows: Public parameter generation: input the security parameter q and the number of participants n to KGC. KGC determines the relationship between the number of participants n and the linear mapping of K parties n=K+1, ensuring that there are at least K+1 participants when calculating the multi-party negotiation session key. Select a large prime number q to define the size of the finite field, select an elliptic curve group G1 and a target group G2, the order of group G1 is q, g is a generator of group G1, and e is a generator that satisfies In addition, we need to select three hash functions H com , H agg , H sig , for use in the subsequent multi-signature phase, output public parameters params = (e, g, q, H com , H agg , H sig ), broadcast the public parameters params in the system; Key generation: The input is the public parameter params and the identity of the participant i∈{1,...,n}, and the participant i selects a random number sk i For its private key, calculate For its public key, broadcast the public key within the system; Key negotiation: Each participant i inputs public parameters params and the private key sk of participant i i , other participants' public keys (pk1, ..., pk j ) i≠j ; Each participant sk i The session key k negotiated by multiple parties can be calculated locally. According to the properties of multi-party linear mapping, the session key k calculated by each participant is the same. The calculation formula of k is as follows: Encryption process: The negotiated contract is regarded as message M. The parties use the shared key k as the symmetric encryption key and use the AES algorithm to encrypt message M to generate encrypted ciphertext m. Finally, the encrypted contract m is submitted to SA, which determines whether all ciphertexts are the same, where m = AES encrypt (M, k); Decryption process: The participants use the shared key k and AES algorithm to decrypt the ciphertext m and restore the original message M, where M = AES decrypt (M, k).

8. According to claim 3, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized in that: An encrypted contract m∈{0,1}* is jointly signed by n signatories. The designed multi-signature authentication scheme describes the multi-party contract signing authentication algorithm. The specific contents of the multi-party contract signing authentication algorithm are as follows: Aggregate public key: Each signer sorts the public keys to form a public key list L = {pk1, pk2, ..., pk n }, and calculate the weight a of each signer based on this list i , a i =H agg (pk i , L); then use the weight to calculate the aggregate public key PK agg , the aggregate public key calculated by each signer is the same. Similarly, the signature aggregator calculates the same aggregate public key PK agg , Non-interactive commitment: Each signer i generates a random number r i ←Z q , calculate its partial commitment value and the commitment hash t i =H com (R i ), and then the partial commitment value R i and hash value t i Sent to the signature aggregator, the signature aggregator verifies the equation t1 = H com (R i ) is true, if the equality is not true, the protocol is terminated, otherwise the aggregate commitment value R is calculated. agg , and the aggregate commitment value R agg Broadcast to each signer, Each signer then calculates the challenge value c, c = H sig (PK agg , R agg , m); Generate partial signature: Signer i uses his private key to calculate statement value s i , partial signature σ i By the partial commitment value R i and statement values ​​s i Each signer i will partially sign σ i Send it to the signature aggregator and submit the signature to the smart contract for later verification and dispute resolution. i =r i +ca i sk i mod q;σi=(R i ,s i ); Aggregate multi-signature: The signature aggregator generates a signature according to the signature set σ = {σ1, σ2, ..., σ n } Compute aggregate statements agg , output multi-signature σ agg ; σ agg =(PK agg , R agg ,s agg ); The signature aggregator will multi-signature σ agg , hash function H sig And the encrypted contract m is submitted to the smart contract for verification; Verify multi-signatures: The smart contract verifies the multi-signatures and calculates c = H based on the submitted multi-signatures and the encrypted contract m. sig (PK agg , R agg , m); Verify partial signatures: The smart contract verifies in turn whether each signer has signed the contract correctly, and for signer i, calculates:

9. A multi-party fair contract signing method based on off-chain protocol and on-chain contract according to claim 8, characterized in that: In the verification of partial signature, equation If it holds, then through the partial signature σ i , equation Not established, refuse to sign.

10. According to claim 3, a multi-party fair contract signing method based on off-chain protocol and on-chain contract is characterized in that: Smart contracts include verifying submitted multi-signatures, verifying partial signatures of individual signers, handling erroneous behavior, and storing successfully verified signatures on the blockchain for long-term auditing.

Images