A Multi-Party Functional Signatures Scheme for Private Blockchain

: Digital signature technology is essential for ensuring the authenticity and unforgeability of transactions in a private blockchain framework. In some scenarios, transactions require veriﬁcation from multiple parties, each of whom needs to authenticate different parts of the transaction. To address this issue, researchers have developed multi-party ECDSA (Elliptic Curve Digital Signature Algorithm) signature schemes. However, these schemes either need to consider the authentication of different parts of the transaction or generate an aggregated signature. This paper proposes a novel solution that combines functional signatures and multi-party ECDSA signatures to create a multi-party functional signature for private blockchains. Compared to previous constructions, the proposed scheme ensures that each part of the transaction is veriﬁed. Furthermore, when the aggregate signature of the entire transaction cannot be veriﬁed, this scheme identiﬁes the speciﬁc part of the transaction for which the signature authentication fails instead of rejecting the entire transaction. This paper uses a smart contract to securely deploy the proposed scheme and authenticate the f in functional signatures. The constructed scheme also provides security under the existential unforgeability of the ECDSA signature, even if n − 1 parties are corrupted, assuming a total of n parties. The scheme of this paper successfully conducted experiments on a personal computer, with three users taking approximately 343 ms, six users taking 552 ms, and nine users taking 791 ms.


Introduction
Recently, blockchain has played a significant role in various fields, including finance [1][2][3], IoT [4,5], and decentralized storage [6] due to its decentralization, immutability, and traceability properties. The development of blockchain in cryptocurrency has made it a modern network technology [7]. Bitcoin [8], as blockchain 1.0, has successfully deployed and applied the ECDSA (Elliptic Curve Digital Signature Algorithm scheme), gaining wider attention and gradually becoming the default signature mechanism of current mainstream blockchain platforms and projects. Some blockchains, such as Ethereum [9] as Blockchain 2.0 and Hyperledger Fabric, have been proposed to make blockchain more flexible and perform better. Smart contracts, as the core technology of Ethereum [9], can be seen as computer programs that perform all contract-related operations autonomously, with corresponding results. The validity and authenticity of the contract operations can be checked on the Ethereum account. Deploying smart contracts can realize some special operations in the blockchain system. A private blockchain is a permission-based network that limits usage to specific organizations or individuals. Unlike public blockchains, private blockchains allow only authorized users or organizations to join, and their transaction data are restricted to authorized viewing. The efficient development of any network technology must consider its network security factors [10][11][12][13][14][15], and the signature technology of cryptography can effectively solve some security problems in the blockchain.
Functional signatures, a new type of signature introduced by Boyle, Goldwasser, and Ivan [16], have some properties that standard signatures do not have. In a functional signatures scheme, there are two private keys, a private key that can sign any message belonging to the message space called the master private key, and another one that can sign information defined in the scope of the function f . The owner of the master private key can use the master private key to generate a functional signing private key sk f for function f . The owner can allow others to use the functional signing private key sk f to sign messages in the range of f . The above gives the functional signatures the property of fine-grained access control, and the property is beneficial for multiple users. For example, there is a document that can be noted as message m. The primary user with the master private key can sign the m. The primary user only allows other users to modify some of the information in the document. It issues some functions f for other users, and others can sign the f (m) to modify part of the document. Based on [16], Backes [17] proposed delegatable functional signatures and achieved the application of delegation using functional signatures. In the functional signatures scheme, the master key and the signing key sk f of function f are generated by one user. Once this user is corrupted, it will cause much damage. The new scheme called decentralized multi-authority functional signatures, which supports nonmonotone access structures using inner-product relations, was introduced by Okamoto and Takashima [18] to address this type of problem.
In private blockchain systems, private keys are essential for users to control their cryptocurrency and are the basis for implementing privacy protection schemes. If a malicious attacker illegally steals a private blockchain user's signature private key, they can transfer the user's cryptocurrency arbitrarily or impersonate the user to publish illegal transaction information. This can lead to severe economic loss problems [19]. Some multiple signature schemes have been proposed to solve this problem. MacKenzie [20] initially proposed a two-party signature scheme for DSA that enables two signing parties to generate a valid DSA signature for a given public key. Neither party can complete the signature alone, and no reconstruction of the private key is required during the signing process. Lindell [21] proposed a two-party ECDSA signature scheme based on the Paillier homomorphic encryption algorithm. This scheme utilizes the Paillier homomorphic property to complete the signature process and improve efficiency directly. Castagnos [22] introduced hash proof systems technology to replace the Paillier homomorphic of Lindell [21] and completed the security proof. In addition to the two-party ECDSA signature scheme, multi-party threshold ECDSA signature schemes have also been proposed. Lindell [23] designed a secure privacy multiplication protocol for extending the original two-party signature scheme into a multi-party threshold signature scheme. Doerner [24] also designed a multi-party threshold signature scheme by extending the two-party signature. Gennaro [25] designed the MtA protocol based on Paillier homomorphic encryption and proposed a new multi-party threshold ECDSA signature scheme based on this protocol. However, these schemes use a homomorphic encryption algorithm or oblivious transfer (OT) protocol used in two-party signature schemes, so they have high computational and communication overheads. The above-distributed signatures are all multiple parties signing the same message, and none can solve the problem of fine-grained authentication of partial information. For example, in a technology company, various departments may need to authenticate specific project parts before uploading them to the company's private blockchain. However, the methods noted above do not allow for this level of fine-grained authentication, as they only produce an aggregated signature. This paper uses the ECDSA scheme as a standard signature in functional signatures and constructs a system model based on functional signatures with multiple parties for private blockchain. The proposed scheme enables multiple parties to sign different parts of the message and collaborate to produce a signature for the message. It can effectively solve the example described above. It can solve some real problems about fine-grained security authentication of multiple parties. The contributions of this paper are as follows: • This paper proposes a novel scheme that combines functional signatures and multiparty ECDSA signatures to create a multi-party functional signature for private blockchains. Compared to the previous scheme, the proposed scheme ensures that each part of the transaction is verified. Moreover, in cases where the aggregate signature of the entire transaction cannot be verified, this scheme identifies the precise portion of the transaction where signature authentication fails rather than rejecting the transaction in its entirety. • This paper ensures the security and authenticity of function f in the function signature by embedding it in a smart contract using blockchain's smart contract technology. • This paper provides proof of the security of the constructed scheme. Under the existence of the unforgeability of ECDSA signatures, the proposed scheme is secure even if it is corrupted in n − 1 parties (assuming a total of n parties).

Related Work
The security of network technology has always been a frontier worthy of research. Shaukat [26,27] summarized the cyber security issues regarding the rapidly evolving technologies. For the development of blockchain security, Halpin [28] proposed an introduction to security and privacy on the blockchain. As blockchain technology evolves, many researchers have recognized cryptography as essential for analyzing and addressing blockchain security concerns. Li [29] utilized puncturable signatures in cryptography to resolve the issue of long-range attacks in the blockchain's Proof of Stake protocol. Signature technology is the core of cryptography. It can effectively solve many blockchain security problems.
The use of signature technology to protect the security and privacy of the blockchain has been studied by many scholars. Zhu et al. [30] proposed an interactive incontestable signature for transactions of blockchain, which ensures that the transactions were certified by the dealer and are non-repudiable. Mercer [31] applied ring signatures to the blockchain, enabling privacy protection for the blockchain users themselves. Gong et al. [32] proposed an anonymous traceability protocol based on group signature; the protocol guaranteed the anonymity of blockchain transactions. The design of multiple signatures in blockchain can effectively solve the problem of multi-party verification and decentralization of blockchain transactions. Kogias et al. [33] proposed a collective signing scheme to improve the security and performance of Bitcoin, but it was not very efficient. Zhou et al. [34] proposed a distributed account management scheme for Bitcoin, which aims to protect the private key of a user's account. Alangot et al. [35] introduced a spanning-tree topology to scale Schnorr multi-signature, which could enhance the consistency of the blockchain. Yu [36] proposed a method to combine Schnorr multi-signature and blockchain to ensure privacy and security of data in the Internet of Things. Maxwell [37] constructed a new Schnorr multi-signature scheme, which could improve both performance and user privacy in Bitcoin. Yu [38] also proposed an elliptic curve threshold signature scheme for blockchain, which has relatively high efficiency compared to other multi-party signatures of elliptic curves. Xiao [39] proposed a secure and efficient multi-signature scheme for Fabric, and Uganya [40] proposed a modified elliptic curve cryptography multi-signature scheme to enhance security in cryptocurrency. The detailed comparison is shown in Table 1.
All of the above blockchain multi-signature schemes only generate one signature collaboratively by multiple parties, without considering the fine-grained authentication of partial transaction data by a single party before collaboratively generating a single signature. So far, no scheme has considered fine-grained authentication of transactions in the private blockchain along with multiple signatures. This paper proposes a multi-party functional signatures scheme based on ECDSA signature that can solve the aforementioned problems.

Scheme
Efficiency Blockchain Provable Security Against Collusion Attack [24] low no yes no [33] low yes uncertain no [34] low yes uncertain yes [37] high yes yes yes [38] high yes yes no [39] high yes yes yes [40] high yes yes yes

Preliminaries
Some basic definitions and notational concepts are as follows.

ECDSA Signature
ECDSA signature is divided into four steps, which include Setup, KeyGen, SigGen, and Verify. Setup is responsible for generating the system parameters, KeyGen generates the public-private key pairs of the scheme, SigGen represents the signing process, and Verify represents the verification process of the signature. The detailed steps are shown below. Setup: On inputting the security parameter, the system outputs public parameters param = {E, F p , G, P, p, q, H}, where E is an elliptic curve defined over a finite field F p , p is a prime and G is an additive cyclic group consisting of all points in E; P is the generator of the group G, and q is the prime order of the group G. Finally, H is a cryptographic hash function denoted as H : {0, 1} * → Z * q and Z * q is the field consisting of the set of integers {1, 2, . . . , q − 1}. KeyGen: On inputting the public parameter param, the following two steps generate the signed public-private key pair.
• Choose a random integer d ∈ Z * q as secret key. • Compute the Q = d · P as public key. SigGen: On inputting the public parameter param, the signing secret key d, and the message m, output the signature of message m δ = (r, s). The steps for generating a signature are as follows.

•
Randomly select integer k ∈ Z * q . • Compute R = k · P = (r x , r y ), where R is a point on the elliptic curve E. • Compute r = r x mod q, and if/when r is 0, return to the first step to reselect k.
Output the generated signature δ = (r, s), where s = min{q − s 1 , s 1 }. Verify: On inputting the message m to be verified and it's signature δ, output 0 or 1 (0 means failure, 1 means success). The steps for verifying a signature are as follows.
• Check whether the integers r and s belong to Z * q . If they do not belong, terminate the verification; otherwise, execute next step.
When r = r x mod q, output 1, otherwise output 0.

Security Definition
Definition 2. Unforgeability: The functional signatures is unforgeable if the advantage of any PPT algorithm A in the following game is negligible: • The challenger runs (Msk, Mvk) ← FS.Setup(1 λ ) and sends Mvk to adversary A.
• Adversary A is allowed to query the key generation oracle and a signing oracle; they are noted as O k and O sig . The challenger initializes a dictionary indexed by tuples ( f , i) ∈ F × N , which contained the signing keys: sk i f ←FS.KeyGen(Msk,f). This dictionary records the keys that were previously generated in the Unforgivability game. O k and O sig are defined as follows: , the challenger runs as follows: 1.
If there is an entry for ( f , i) in the dictionary, then the corresponding key sk i f is output.

2.
Otherwise, by sk i f ← FS.KeyGen(Msk,f) sample a fresh key, add the ( f , i) → sk i f to the dictionary in order to update it, and output sk i f .
, the challenger runs as follows: 1.
If there is an entry for ( f , i, m) in the dictionary, then the corresponding Otherwise, by sk i f ← FS.KeyGen(Msk,f) sample a fresh key, add the ( f , i) → sk i f to the dictionary, and the corresponding signature σ → FS.Sign(f,sk i f ,m) is output. - The adversary wins the game if it can output a signature (m * , σ) such that: 1. FS.Verify(Mvk,m * , σ) = 1.

2.
There does not exist m such that m * = f (m) for any f that was sent as a query to the key generation oracle O k .

3.
There does not exist a ( f , m) that was queried to the signing oracle O sig and m * = f (m).

Smart Contract
In a private blockchain system, the smart contract is compiled by the Solidity language and each different node represents a different private blockchain account. The smart contract is a type of computer protocol that can be executed through the account. Briefly, the smart contract is a computer program that has been compiled and deployed on the private blockchain. The process of deploying smart contracts is shown in Figure 1.

Proposed System Model and Multi-Party Functional Signatures Method
This section gives the concrete system architecture framework proposed in this paper. Moreover, it gives the specific setup of the scheme and the construction of smart contracts to run.

System Model Framework
The concrete system model is shown in Figure 2. When a transaction in the private blockchain requires fine-grained collaborative authentication by multiple nodes, the full nodes prefer to send the parameter of the signature scheme to each mining node. A complete transaction is recorded as Data, and a partial transaction is recorded as Data i . The detailed steps are described below: • Validator nodes check the correctness of the queried signature. Once an error occurs in the signature stored in the block header, the partial transaction signature signature i stored in the block body can be queried and checked.
As is shown in Figure 3, the final aggregated signature is stored in the block header, and the signatures generated for different transactions are stored in the respective transactions. The validator nodes can query the signatures of the different transactions from full nodes and verify that the signatures are valid.

Smart Contract Settings and Proposed Concrete Scheme
This subsection gives the specific smart contract setup and scheme construction.

Smart Contract Design
This section introduces the concrete process of deployment and invocation of smart contracts and related algorithms. Some special variables are used in the algorithm of smart contracts: authorizeAccount is a set of trusted private blockchain accounts (nodes of private blockchain), functionSet stores all functions f of functional signatures, ct.sender is the account, and f.Set stores the account of who can use f . The specific definitions of these variables are as follows: • authorizeAccount: When deploying the smart contract, the gateway nodes collect all legal account identity information. All these accounts consist of authorizeAccount. This paper now describes the details of the multi-party functional signatures (MFS) scheme. This paper denotes the setup phase, the key generation phase, the signature phase, and the verification phase of the scheme as MFS.Setup, MFS.KeyGen, MFS.Sign, and MFS.Verify. • MFS.Setup: The full node first selects the security parameter λ and runs the Setup algorithm of the ECDSA signature to generate public parameters param = {E, F p , G, P, p, q, H}, then randomly selects d ← Z * q as the master private key Msk and computes the master public key d · P as Mvk. The full node chooses n random numbers d i and MFS.KeyGen: Each mining node A i initiates a request to the full node, and then the full node sends the d i to mining node A i by a secure channel. Each mining node A i selects k i ← Z * q randomly to send to the full node by Diffie-Hellman key exchange. The full node computes k = ∏ n i=1 k i and k · P = (r x , r y ), where k is stored in the full node and k · P is sent to each mining node A i . Let {v 1 , v 2 , · · · , v n−1 } be chosen randomly by the full node, and v n is computed by Each mining node sends H(Aid i ) to the full node, where Aid i is the identification information of node A i . The full node stores {d i , v i , H(Aid i )} i∈ [1,n] securely. The full node randomly selects X ji ← Z * q and computes X ij = d i v j + d j v i − X ji . Two nodes A i and A j receive X ij and X ji , respectively, by Diffie-Hellman key exchange, where they satisfy Each mining node computes The public key of mining node A i is X i P. Each mining node A i gets v i by Diffie-Hellman key exchange as a part of the private key sk and invokes a smart contract to verify the authenticity of f i . The full node signs for f i |vk i by the Msk and SigGen algorithms of the ECDSA signature, the signature of f i |vk i is noted as σ vk i . Creating the certificate c i = ( f i , vk i , σ vk i ), the private key sk i f of node A i is sk i f = (X i , c i ).
The signature generated by each mining node A i is The full node receives sig i from all nodes and calculates sig n+1 = k −1 r x d n+1 using the internally saved d n+1 . Finally, the output is the MFS.Verify: For overall transactions, the data of the transactions verifier can verify signature Sig by using the Verify algorithm of the ECDSA signature. If the data of transactions verifier needs to check the authenticity of the signature of node A i , he can check that: Whether σ vk i is valid by the Verify algorithm of the ECDSA signature and Mvk.
• Correctness: The correctness of the signature for node A i is guaranteed by the ECDSA signature algorithm. The following equation determines the correctness of Sig:

Security Analysis
This section uses the security model of [10] and give proof of the security of the multi-party functional signatures scheme and system model.

Theorem 1.
If the signature scheme ECDSA is existentially unforgeable under chosen message attacks, then the proposed multi-party functional signatures scheme as specified above satisfies the unforgeability requirement for functional signatures.
Proof of Theorem 1. In the unforgeability game, one can define a PPT adversary noted as A MS , who can be allowed to make a query to the two random oracles denoted O k and O sig . Then create a set [N] to represent all nodes. Let S be the subset of [N] and satisfy that the nodes in S are honest. The set of corrupted nodes is denoted as S :=[N]\S. Assume that Q(λ) is the polynomial number and A MS only can query Q(λ) times in the oracles O k and O sig . This game can use A MS as a subroutine to construct another adversary B MS such that, if adversary A MS wins in the unforgeability game for multi-party functional signatures with non-negligible probability, then it can show that B MS can break the unforgeability game of the ECDSA signature scheme, which is assumed to be unforgeable against the chosen message attack.
For A MS to win the unforgeability game of multi-party functional signatures, either it can generate a final signature Sig by corrupting a dishonest node or simply produce the signature Let us discuss the first situation, where the sig i can be produced by A MS , where i ∈ {i|A i ∈ S}. It can assume that there are n-1 corrupted nodes of which the only uncorrupted node is noted as A i * . There are two types of forgery: • As a challenger, B MS needs to interact with A MS in the unforgeability game for multi-party functional signatures; B MS must simulate the oracles O k and O sig in order to interacting with B MS , and B MS tosses a coin b to guess the type of forgery A MS will generate. Case 1: b = 1: B MS guesses that A MS will produce a Type I forgery: During interacting with A MS , B MS sets the vk sig as the master verification key in this simulation; B MS generates and maintains a dictionary indexed by tuples ( f i , i) to simulate the oracles O k and O sig . Adversary A MS will respond to the B MS 's queries as follows: -If there exists an entry for the tuple ( f i , i) in the dictionary, then output the corresponding value sk i * f . -Otherwise, B MS randomly selects d i * ← Z * q as sk i * , and computes d i * P as vk i * ; B MS obtains σ vk i * ← O Reg sig from his oracle, and return sk i f = (sk i * , σ vk i ) to A MS . He also updates the dictionary by adding the entry ( f i , i).
-If there exists an entry for the tuple ( f i , i) in the dictionary, it has the sk i f = (sk i , σ vk i ). He can generate a signature Sig ← O Reg sig . Because he knows all about the corrupted nodes, he can output Otherwise, B MS randomly selects d i * ← Z * q as sk i * , and computes d i * P as vk i * ; B MS obtains σ vk i * ← O Reg sig from his oracle, and updates the dictionary by adding the entry ( f i , i).
He then generates Sig by O Reg sig , and outputs Finally, A MS outputs the signatures σ j and Sig, where σ j = (m * j , m, ( f j , vk j , σ vk j ), sig j ); B MS then outputs the ( f j |vk j , σ vk j ) as a forged signature in the unforgeability game for ECDSA scheme.
Case 2: b = 0: B MS guesses that A MS will produce a Type II forgery: Here, B MS randomly selects d ← Z * q as master private key Msk and computes dP as the master public key Mvk. Then B MS generates d i , k ← Z * q , k · p = (r x , r y ),v i and X i , where d i and v i satisfy that ∑ n i=1 d i = d and ∑ n i=1 v i = k −1 , respectively; B MS can compute X i P as vk i and sends the vk i of all nodes to A MS along with the X i of the specified set S of corrupt nodes. In addition, B MS guesses a value i * between 1 and Q(λ) as a special index of signing queries of multi-party functional signatures where the challenge verification key will be embedded. This game uses a variate denoted as Numkeys to indicate the numbers of signing keys already generated and initializes Numkeys = 0. Adversary B MS maintains a dictionary indexed by tuples ( f i , i) for responding to the queries of A MS ; B MS responses to the queries issued by B MS as follows: -If there exists an entry for the tuple ( f i , i) in the dictionary with the value CHA, abort. -If there exists an entry for the tuple ( f i , i) in the dictionary with a value that is not CHA, output the key sk i f .
-Otherwise, B MS randomly selects d i ← Z * q as sk i , and computes d i P as vk i ; B MS generates the σ vk i by himself and returns sk i f = (sk i , σ vk i ) to A MS . He also updates the dictionary by adding the entry ( f i , i).
-If there exists an entry for the tuple ( f i , i) in the dictionary, sk i f = (sk i , σ vk i ). He generates a signature Sig by himself, and outputs If there is no the tuple ( f i , i) in the dictionary, and Numkeys = i * , B MS generates a new key pair by randomly choosing the d i ← Z * q as sk i and computing d i P as vk i ; B MS signs f i |vk i to generate σ vk i by using Msk, and sets tuple ( f i , i) in his dictionary to sk i f . He then generates the signature Sig on message m by using Msk, outputs It can indicate that, if A MS breaks the multi-party functional signatures scheme with non-negligible probability, then B MS can break ECDSA scheme with non-negligible probability. In this unforgeability game, A MS has two different types of forgery.
For Type I forgery, this game can know that this forgery has a signature on the new message f i |vk i that was never signed under the master public key Mvk by the oracle. In Type I forgery, this game assumes that the probability of breaking the multi-party functional signatures scheme is Pr[I], and it is obvious that the probability of B MS breaking the ECDSA scheme is greater than or equal to 1  Proof of Theorem 2. In the multi-party functional signatures scheme, it needs to be assumed that the full node is secure. The master private key of the scheme is d = ∑ n+1 i=1 d i ; therefore, even if n − 1 nodes are corrupted, the adversary cannot recover d by corrupted nodes. Furthermore, the nodes have X i = d i v i + ∑ n j=1,j =i X ij , even if n-1 corrupted nodes provide X i , the adversary cannot compute X i * that the honest node has, so it cannot get sig i * . The above illustrates this scheme resists n-1 corrupted nodes collusion attacks.

Results
This section analyzes the computation complexity and implements the proposed system model on a personal computer.

Complexity Analysis
As shown in Table 2, this paper gives a theoretical analysis of the proposed scheme. Some notations of time complexity analysis are given as follows. Table 2. Theoretical cost analysis.

Mining Node Full Node
Time costs In the proposed scheme, each mining node must perform one hash function, three multiplications in the field Z * q , n + 1 additions in the field Z * q , one multiplication in G, one f (m), and n Diffie-Hellman key exchanges. Each mining node needs to invoke one smart contract to use function f . Excluding communication time, each mining node will cost For the full node, it needs to run some random number generation algorithm and ordinary addition and multiplication operations several times (the time cost of these steps is negligible). In addition, it runs the n hash function, two multiplications in G, n(n − 1) + 2n + (n − 1) multiplications in the field Z * q , n(n − 1)/2 + n + (n − 1) + 1 additions in field Z * q , n + 1 extended Euclidean algorithms, and n Diffie-Hellman key exchanges. Therefore, the full node requires For communication between the full node and mining node, it requires (n 2 + 2n)T com . The scheme presented in this paper implements fine-grained authentication for certain transactions, which is highly significant. Additionally, for multi-party signature schemes, it is essential that they satisfy resistance to collusion attacks and can be proven secure. As is shown in Table 3, the proposed scheme has certain advantages compared to the previous scheme. The proposed scheme ensures that every part of the transaction is validated, reflecting the fine-grained nature of the scheme. Furthermore, the scheme is adapted to run on multiple nodes of the blockchain, and it is provably secure. For the collusion attack, the proposed scheme can effectively resist such attacks. Even if n − 1 nodes are corrupted, the adversary cannot forge the signature generated by this scheme. The significant advantage of this paper's scheme over previous schemes is that it can achieve fine-grained authentication of different parts of the transaction and resist collusion attacks. Table 3. Properties and disadvantages of the schemes.

Scheme
Blockchain Provable Security

Against Collusion Attack
Fine-Grained [24] no yes no no [33] yes uncertain no no [38] yes yes no no [39] yes yes yes no [40] yes yes yes no our yes yes yes yes

Implement
This paper used a personal computer (RedmiBook with AMD CPU Ryzen 5 5600H with Radeon Graphics @ 3.30 GHz with 16.0 GB RAM and Windows 10 Home OS) implementing the proposed scheme in Python 3.9.6. This paper implements the scheme with different numbers of nodes.
This paper chose the secp256k1 curve that is used in Bitcoin for the simulation experiment. This paper implemented the experiments with different numbers of nodes. Each execution was run 1000 times, and this paper computed the average as the final result. The results of the experiment are shown in Figure 4. It can see that the running time of the scheme slows down as the number of nodes increases: about 343 ms for three nodes, about 552 ms for six nodes, and about 791 ms for nine nodes. Regarding time consumption, the scheme in this paper can be applied to the private blockchain. This paper deployed smart contracts using Solidity language and Ropsten to test the network. The compiler of Solidity language is Remix IDE, and its version is 0.7.4.We. This paper used MetaMask to manage private blockchain accounts. In the experiment, the gasPrice was set to 1.49 Gwei, where 1 Gwei = 10 9 wei = 10 −9 ether. This paper defines | f unctionSet| as the length of set functionSet. As shown in Tables 4 and 5 and Figure 5, some costs of smart contracts were tested through this experiment.  Costs of smart contract deployment and algorithms increase as the functionSet length increases. In this experiment, the cost of deploying smart contract for | f unctionSet| = 5 is $0.973. When the length of functionSet is 10, 15, and 20, the cost of deploying smart contract is $1.144, $1.315, and $1.486. As shown in Table 5 and Figure 5, when | f unctionSet| = 5, gasPrice of invokeF, addUser, and deleteUser is 64,445 Gwei, 94,981 Gwei and 55,675 Gwei, respectively. Obviously, with the increase of the | f unctionSet|, the gasPrice required to invoke the smart contract also increases. GasPrice of addUser is always more than invokeF and deleteUser. All gasPrice consumption is reasonable, which indicates that binding function f of the function signature to a private smart contract is valid.

The Limitations of the Study
This paper is preconfigured to use the function signature of function f in the smart contract, which may limit the operability of this scheme. Additionally, this paper is directly combined with ECDSA signatures and does not apply to other elliptic curve signatures.

Conclusions
Although some researchers have proposed various multi-party signatures to tackle the issue of verifying private blockchain transactions by multiple parties, the previous construct still needs to address authenticating different parts of a transaction. This paper presents a novel approach that combines multi-party ECDSA signatures with functional signatures to enable fine-grained authentication of different parts of the entire transaction. In addition, the function f of the functional signature is safeguarded and implemented using a smart contract on a private blockchain. The research presented in this paper is motivated by the fact that previous multi-party signature schemes designed for blockchains cannot authenticate the entire transaction at a fine-grained level. Furthermore, when the final signature fails to pass the authentication, the whole transaction will be rejected, which greatly wastes time for the partly correct transaction to pass the authentication. Experimental results show that the proposed scheme is feasible to be applied to the blockchain.
Exploring how to design an efficient and multi-party signature with an automatic fine-grained division of blockchain transactions is an important research direction for the future. The multi-party functional signatures proposed in this paper will also find different applications outside of the private blockchain.