1 Introduction

The company eMarketer estimates that the worldwide turnover of electronic commerce will reach approximately 6 trillion euros in 2023 and will exceed 7 trillion euros by 2025 [1]. One of the key elements required for this volume of business to further increase is to have secure and usable protocols for contract signing.

From a security perspective, any contract signing protocol must meet certain requirements [2]: fairness, timeliness and nonrepudiation. In brief, the following must be fulfilled: no signatory must be at a disadvantage, the protocol must end at a finite instant, and the signatories must not be able to deny their actions.

Conversely, there are optional security requirements that are not always demanded by users. A clear example is confidentiality. There are contracts, which, by their nature (for example, contracts with the public administration), do not require confidentiality. Another example of an optional requirement is abuse-freeness, that is, that no signatory is in a dominant position during the execution of the protocol. However, both requirements can be of interest in multiple contract signing scenarios; therefore, proposals that meet these requirements are necessary.

The traditional way in which to adhere to the fairness requirement is to rely on services provided by a trusted third party (TTP) (e.g., [3,4,5]). However, the use of TTPs is not without problems. It can be difficult for the parties to agree on a TTP that is trusted by both parties, and in such instances, the TTP becomes a point of failure for the system. In fact, the attempt to avoid the use of TTPs is not specific to contract signing since this trend is also observed in other environments, such as energy trading [6] and spectrum sharing [7].

Since 2017, there have been solutions for contract signing that replace the use of TTPs with the use of blockchain (see Sect. 3). Blockchain, an immutable and distributed register, can provide the necessary security features to guarantee that the fairness requirement is met. However, none of the analyzed blockchain-based contract signing solutions meet the abuse-freeness requirement (and some fail to meet other essential requirements, such as the timeliness requirement).

Contributions. The most important contribution is that we provide the first protocol for contract signing based on blockchain, which, in addition to meeting the mandatory security requirements (fairness, timeliness and nonrepudiation), meets the optional requirements of confidentiality and abuse-freeness. A review of all the definitions used to date is provided for this latter property. Moreover, an analysis of all proposals for contract signing based on blockchain has been performed. Finally, we conduct an economic cost analysis of our solution to verify its economic feasibility.

Organization. The remainder of this paper is organized as follows. Section 2 provides a review of all the definitions of abuse-freeness used to date. Related work in the literature is analyzed in Sect. 3. Section 4 introduces the features of blockchain technology. Section 5 summarizes our proposal for abuse-freeness in contract signing, followed by a full specification of the protocol in Sect. 6. The smart contract execution logic is provided in Sect. 7. A security analysis of our proposal is presented in Sect. 8, and a cost analysis is presented in Sect. 9. Finally, the conclusions are presented in Sect. 10.

2 Abuse-freeness

In 1999, Garay et al. [8] introduced the abuse-freeness requirement for contract signing and defined this requirement as follows: it is impossible for a single player at any point in the protocol to be able to prove to an outside party that he or she has the power to terminate (abort) or successfully complete the contract. A group of later authors [9,10,11, 13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32, 43] cited or adhered to this definition.

Baum et al. [33] added (to the definition provided by Garay et al.) the nuance of "whatever the honest party does", and Gaber et al. [34] changed "at any time" to "before the completion of protocol execution". For some authors [2, 35], the "single player" (of Garay et al.’s definition) can be a legitimate participant or an outsider, and for other authors [36,37,38,39,40,41], he or she can be a set/collection of signers (these latter authors proposed or analyzed multiparty contract signing protocols). In the article by Garay et al. [8], a supplementary explanation is provided: a protocol is not abuse-free if a signing party (X), at some point, can convince a third party (Z) that the other signing party (Y) is committed to the contract, whereas he or she (X) is not yet committed to the contract (the authors of [10] and [42] present similar explanations in their respective articles).

Other authors have made significant changes with respect to the original definition. Thus, in two articles [11, 13], Shmatikov et al. used a definition indicating that neither party should have an advantage during the execution of the protocol. Chatterjee et al. [12] explained that abuse-freeness prevent either participant from proving to a third party that he or she has an advantage or, in other words, that he or she has the other participant’s intent to sign the contract. Kremer et al. [43] provided a new definition of abuse-freeness: a signing party cannot reach a state in the protocol where he or she can prove to an external party that the protocol has been initiated with the other signing party, without the latter signing party having a strategy to successfully complete the protocol. Gao et al. [23] defined abuse-freeness as no party being able to prove the validity of intermediate results to others if the protocol ends unsuccessfully. Chatterjee et al. [44] adhered to this definition, while other authors [45, 46] added that the definition must be fulfilled during or after the execution of the protocol, and Xu et al. [47] explained that it must be fulfilled specifically during the execution of the protocol.

Heidarvand et al. [42] (and similarly Draper-Gil et al. [48]) stated that it should be impossible for an external party to publicly verify a partial signature made by a signing party, and they add that a signing party should not obtain publicly verifiable information from the other signing party until the first signing party is also bound to the contract. Paunković et al. [49] indicated that a signing party should not have any proof that it has communicated with another signing party trying to sign a particular contract. Al-Saggaf et al. [50] explained that a signing party should not be able to convince an external party of a commitment from the other signing party after the execution of the protocol. Some authors [5, 47] offer a very open definition—that neither party should benefit from intermediate results. Similarly, Rajasree et al. [51] exposed that one party should not benefit over the other party whenever the protocol is terminated. Yadav et al. [52] indicated that a signing party should neither be able to prove that he or she is involved in signing a contract nor be able to show evidence (from other parties) to negotiate better conditions in another contract.

Wang et al. [16] provided a new definition: before the protocol ends, no party can prove to an outside party that his or her opponent is participating in the protocol exchange. These authors are among the few who use a new name for the new definition: strong abuse-freeness (because it is a stronger version of the definition provided by Garay et al. [8]).

In addition to repeating the definition of Garay et al., Chadha et al. [10] presented the following new requirement (related to abuse-freeness): balance. A protocol is balanced if, for X, Y does not have the power to abort or complete the protocol. Let us observe that the phrase "to prove to an outside party" has disappeared because it is unnecessary: if Y cannot abort and complete, then he or she cannot prove it to an outside party. This requirement is stronger than is that for abuse-freeness: if a protocol is balanced, then it is considered abuse-free (the opposite is not true). Other authors [43, 53, 54] have cited or used this requirement.

Starting from the balanced protocol definition in [10], Küsters et al. [55] provided two new definitions. Weak abuse-freeness requires that there be no way for a dishonest signer (X) to convince the verifier (Z) that the protocol is currently in an unbalanced state. Strong fairness requires that a signer (X) cannot even prove to the verifier (Z) that the protocol was in an unbalanced state at some point during the run. A protocol is in an unbalanced state if a signer (X) can unilaterally determine the outcome of the protocol: obtain the other signer’s (Y) signature and prevent the other signer (Y) from obtaining X’s signature.

The definition of abuse-freeness is not inconsequential and is not equivalent to saying that a party cannot prove that he or she has the power to validate or invalidate the signing of a contract or to say that this party cannot have any intermediate evidence from the other party. A protocol proposal can meet the requirement established by the first definition and not meet the requirement established by the second definition. We use the initial definition of Garay et al. [8], and we believe that all the authors who have introduced significant changes with respect to the initial definition should have used other terms to avoid confusion.

3 Related work

A search in Scopus and Web of Science for articles in English published in journals and conference proceedings that contained the terms "contract signing" and "blockchain" produced an initial result of 22 articles. In the first filtering step, 8 articles were discarded for not addressing the topic of interest (in some cases, they were treated only tangentially, and in other cases, not at all). Among the 14 articles analyzed, only one [56] cited the abuse-freeness requirement, and none imposed this requirement as needing to be met. This finding is not surprising since it is an optional requirement that is not necessarily of interest for all contract signing scenarios.

Some of the 14 articles were not specifically analyzed for the abuse-freeness requirement. For example, in [57], a platform for e-contracting was presented, but no protocol for contract signing was discussed. In one of the two proposals in [58], the text of the contract must be published on the blockchain, with the corresponding loss of confidentiality. In [59], the contract must also be published on the blockchain in the case of a dispute between parties. Some authors [60, 61] presented proposals for scenarios (signature delegation and payment by product) different from our scenario, and the protocols were insufficiently explained. We are not interested in proposals such as those in [62], in which, in addition to using blockchain, TTPs were used.

Some of the proposals [58, 59, 63,64,65] based the fairness of the protocol on the making of deposits by one or more of the signatories. If a signer’s behavior is not honest, then the signer loses his or her deposit (which serves to compensate for honest signers). We think that as far as possible, the use of this mechanism should be avoided for two reasons. First, if one signatory obtains evidence of the contract and the other signatory does not, then the protocol cannot be considered as satisfying the fairness requirement (despite possible financial compensation). In contrast, there are many contracts in which the establishment of economic compensation can be very complicated (in addition to the fact that most cryptocurrencies present a very high degree of fluctuation in value).

Most proposals [56, 58, 59, 63,64,65,66,67] made great use of blockchain (a high number of transactions or execution of smart contract functions). It should be noted that each transaction or execution of code increases the cost and delay, at least in public blockchains. The ideal case, then, involves blockchain-optimistic solutions (which interact, only in case of exception, with the blockchain), as long as the remaining desired requirements are met. However, no blockchain-optimistic solution has been found that meets the abuse-freeness requirement.

The solutions in [66, 67] are not satisfactory because they do not meet the timeliness requirement. At some point during protocol execution, one of the parties may be forced to wait an indefinite amount of time until the other party makes a decision on whether to continue with protocol execution. These proposals lack cancel/finish functions or a pre-established deadline that guarantees that the protocol execution will be completed fairly in a finite amount of time. These types of solutions do not meet the abuse-freeness requirement.

Finally, we have a set of proposals [56, 58, 59, 63,64,65, 68, 69] that meet the other desired requirements (fairness, timeliness, nonrepudiation and confidentiality) but that do not meet the abuse-freeness requirement. These solutions present a temporary window (until a deadline expires) in which one of the parties can decide whether to terminate or abort the signing of the contract. Notably, an attack can be conducted only within a temporary window; otherwise, the parties are faced with the problem of the timeliness requirement.

In conclusion, we have not found any solution based on blockchain (without using TTPs) that satisfies all the desired requirements (including the abuse-freeness requirement).

4 Background

Blockchain is an emerging technology that can be used to overcome the need to rely on TTPs in several scenarios. In essence, blockchain can be defined as a distributed ledger managed transparently among a computer network’s nodes, called miners, where the data recorded in the ledger are unalterable.

Blockchains can generally be categorized as public or private or permissionless or permissioned. In public block-chains, anyone can participate in the network, and there does not exist a single entity controlling the network, allowing for a permissionless and trustless scenario. Therefore, the blockchain technology offer an interesting solution from the perspective of security: the greater the number of nodes is, the greater the level of security. Within private blockchains, there is an authority that controls access to the network (permissioned and trusted); unlike public blockchains, only a limited number of authorized nodes participate actively in the network in private blockchains. Therefore, security risks can arise.

Although blockchain was used initially for cryptocurrencies, over time, a wide variety of new applications have appeared, owing mainly to the development of smart contracts. A smart contract can be defined as code that is self-executed if a specific event occurs. Code execution incurs costs that depend on the computational complexity of the code. The public blockchain that first introduced the possibility of running smart contracts through the implementation of the Ethereum Virtual Machine (EVM) [70] was Ethereum. Although the EVM was designed for use with Ethereum, it is now being used with other blockchains, such as Polygon and Binance Smart Chain, which brings about numerous benefits for developers, such as the easy migration of smart contracts developed for one EVM-compatible blockchain to other blockchains based on EVM.

Fig. 1
figure 1

Abuse-free contract signing scenario

Full size image
Table 1 Abuse-free contract signing protocol notation
Full size table

5 Proposal overview

In this section, we provide a first view of our proposal and the requirements it must meet. Figure 1 shows the actors and their relationships. Table 1 provides a summary of the notation used throughout the protocol description.

The following three actors are involved in our protocol:

  • the two signing parties (A and B), and

  • a smart contract (SC) that enables us to meet the fairness and abuse-freeness requirements.

The proposals must adhere to the following security requirements:

  • Effectiveness: No TTP should intervene during protocol execution.

  • Fairness: Both signatories must be bound by the contract, or neither must be bound.

  • Timeliness: Signatories must be able to complete the execution of the protocol in a finite amount of time.

  • Nonrepudiation: None of the signatories must be able to deny their participation once the contract has been signed.

  • Confidentiality: Only the signatories can read the content of the contract.

  • Abuse-freeness: None of the signatories should be able to prove to an external party that they have the ability to validate or abort the execution of the contract signing.

We assume that the two signing parties conduct a negotiation process prior to signing the contract. In this negotiation, they establish products (or services), prices, etc. One result of this negotiation is the text of the contract that both parties must sign. From this point, our protocol comes into play.

Fig. 2
figure 2

Abuse-freeness protocol: signing procedure

Full size image

One of the signers, A, sends her signed copy to the other party, B. If B does not want to sign the contract, then he simply ignores the received message. Otherwise, B must finish the signature, sending his signed copy to the blockchain for this signature to be available to A and for the blockchain to signal the contract as being signed. If A sees that it is taking too long for B to post his signed copy to the blockchain, then she must cancel the signature by calling a function of the smart contract to signal the contract as being canceled. If A cancels her signature before B sends his signature to the blockchain, then the signature can no longer be finalized.

One advantage of our protocol is that it is asynchronous, which means that the parties can request the intervention of the blockchain at any time (without having to wait for deadlines to expire).

6 Abuse-free contract signing protocol

As indicated, we assume that the signatories have performed a negotiation process that has led them to the text of the contract M. Next, we describe the protocol specification (see Fig. 2).

First, A sends B the following information:

  • the unique identifier of the current transaction \(id_{AB}\);

  • the hash of the contract to sign h(M); and

  • the signature made by A on the basis of the previous information, \(Sig_A\) \([id_{AB}, h(M)]\).

The identifier for each contract signing procedure (\(id_{AB}\)) must be unique. For this purpose, \(id_{AB}\) is generated as follows:

\(id_{AB}=h(@A, @B, @SC, h(M))\)

If, despite having carried out a negotiation with A, at this moment, B decides that he does not want to sign the contract, then he simply does not have to do anything (as will be seen, this will force A to cancel the transaction). If B wishes to sign the contract, then he must verify the data provided by A. If all the data are valid, then he must call the sign function of the smart contract, with the following input parameters:

  • A’s address @A;

  • the transaction identifier \(id_{AB}\);

  • the hash of the contract h(M);

  • A’s signature \(Sig_A[id_{AB}, h(M)]\); and

  • the signature of B on \(id_{AB}\) and h(M) \(Sig_B\) \([id_{AB}, h(M)]\).

The smart contract performs the following operations using the received parameters:

  • checks if \(id_{AB}\) is valid and the signature status for this identifier is canceled, and if this is the case, then it informs B and ends the execution of the function;

  • checks whether the signatures of A and B are correct, and if any of them are invalid, then the execution of the function ends;

  • stores the signatures of both A and B; and

  • sets the transaction status identified by \(id_{AB}\) to signed.

If a long time has elapsed (according to the A criteria) since A sent her signature to B, then she must call the cancel function of the smart contract (see Fig. 3) with the following parameters:

  • B’s address @B;

  • the transaction identifier \(id_{AB}\);

  • the hash of the contract h(M); and

  • her signature sent to B in the first step \(Sig_A\) \([id_{AB}, h(M)]\).

The smart contract performs the following operations using the received parameters:

  • checks if \(id_{AB}\) is valid and the signature status for this identifier is signed, and if this is the case, then the smart contract provides the signature of B to A, \(Sig_B\), and ends the execution of the function;

  • checks if A’s signature is correct, and if the signature is not valid, then the execution of the function ends; and

  • sets the status of the transaction \(id_{AB}\) to canceled.

Fig. 3
figure 3

Abuse-freeness protocol: cancel procedure

Full size image

As indicated, once the smart contract determines the status of a transaction (regarding the signing of a contract, with the identifier \(id_{AB}\)), this status is unalterable regardless of the actions taken by all signers.

As the protocol explains, signatory B does not directly send his signature to A. Even though B may send this information directly to A, she can listen to SC’s events to be aware of the change in transaction status and obtain B’s signature. Additionally, SC can provide a function allowing the signatories, at any time, to know the status of the contract signing and recover the signatures.

If A and B follow the steps of the protocol properly, then in the end, both have evidence of signing the contract. A has the signature of B, and the state signed of the contract is identified by \(id_{AB}\) in the blockchain. B has the signature of A, and the state signed of the contract \(id_{AB}\) in the blockchain.

7 Smart contract specification

The solution designed in Sect. 6 relies on a public blockchain to provide an abuse-free contract signature solution with no TTP involvement and the participation of a smart contract. In this section, we specify the smart contract code required to test our proposed solution using Solidity [71], a programming language developed for use on an EVM [70].

We define a data structure (see Listing 1) to store the data associated with each contract (the hash of the contract, signatures, and status of the contract) and indexed by \(id_{AB}\). These data are provided by the signatory who calls the sign function or the cancel function and are verified by the SC before its status is established. Note that the content of the contract is not stored and cannot be recovered by any party from the signatures or the hash of the contract stored in the data structure.

figure a

Following the description of the proposal (see Sect. 6), SC provides three public functions:

  • sign: given a transaction identifier, B must finish the contract signature by providing both signatures on the contract: his own signature and that of A.

  • cancel: given a transaction identifier, A can cancel the contract signature by providing her own signature on the contract.

  • query: given a transaction identifier, A or B may check the status of the transaction and obtain the required data. If the contract is finished by B, then A obtains B’s signature. If the contract is canceled by A, then B obtains evidence of this fact.

In addition, SC provides the following internal utilities:

  • validStatus: given a transaction identifier, this modifierFootnote 1 checks if the status contract allows for the execution of the sign and cancel functions.

  • validID: this is a private function called by the sign and cancel functions to check if the given transaction identifier is valid.

  • validSign: this is a private function called by the sign and cancel functions to check if the provided data are signed by a specific party.

Upon receipt of A’s signature on the contract, B calls the sign function to complete the contract signing (see Listing 2). We have established that B is the signatory authorized to call this function (see Sect. 6); therefore, he must provide the transaction identifier (\(id_{AB}\)), A’s address (@A), and the hash of the contract (h(M)), along with the signatures on this contract (\(Sig_A[id_{AB}, h(M)]\) and \(Sig_B[id_{AB}, h(M)]\)). SC implements the validStatus modifier to check that there are no data associated with this transaction identifier in the structure dataAFC and that it has not already been signed or canceled. Next, SC verifies that the data provided by B are valid. First, SC generates \(id_{AB}\) (see Sect. 5) by retrieving B’s address from the blockchain transaction signed by B and using SC’s address stored in the smart contract at the time of its deployment. The other data are provided by B as input parameters. If \(id_{AB}\) is valid, then SC checks the signatures on the contract provided by B. If both signatures are valid, then SC stores the signatures and changes the status to signed.

figure b

A can cancel the contract signing any time before the sign function is called by B. She can call the cancel function (see Listing 3), providing, as input parameters, the transaction identifier (\(id_{AB}\)), B’s address (@B), and the hash of the contract (h(M)) along with her signature on this contract (\(Sig_A[id_{AB}, h(M)]\)). SC checks that the contract is not already signed or canceled (using the validStatus modifier) and that the transaction identifier is valid. The value of the identifier is computed using data provided by A, retrieving A’s address from the blockchain transaction signed by A, and using SC’s address stored in the smart contract. If \(id_{AB}\) is valid, then SC checks the signature on the contract provided by A. If all validations are met, then SC changes the status to cancel and updates the data structure associated with \(id_{AB}\).

figure c

Every time a function is executed, the contract emits an event reporting the outcome of the execution. Then, A and B can determine the status of the contract signing in real time. Nevertheless, we implement the query function (see Listing 4) to enable both A and B to check the status of the contract at any given time. SC returns B’s signature on the account if the status is finalized and A’s signature on the contract if the contract is canceled. The query function does not modify the status of the contract signing and, therefore, does not require any transaction to be included in the blockchain (see Sect. 9).

figure d

8 Security analysis

Next, we show how our proposal satisfies the desired requirements.

Effectiveness. No TTP is involved in our protocol. Therefore, the protocol meets the effectiveness requirement.

Fairness. We consider only cases where the parties take actions that do not negatively affect themselves (for example, we ignore the case where A sends her signed copy and does nothing else). Thus, we have only the following two possible situations:

  1. 1.

    A sends her signed copy and cancels the contract, and

  2. 2.

    A sends her signed copy, and B finalizes the contract.

In the first case, the final status of the contract is canceled for both signers, and neither signer is able to do anything to change this status. In the second case, the final status of the contract is signed for both signers, and again, neither signer is able to do anything to change this state. Therefore, the protocol satisfies the fairness requirement.

Timeliness. Once the contracting process has started (A has sent her signature to B), both signatories can decide when to end the signing process (the signatory who executes the smart contract function first is the one who decides the outcome of the process), without this implying the possibility of loss of fairness (as seen in the previous paragraph). Therefore, the protocol meets the timeliness requirement.

Nonrepudiation. A and B sign the text of the contract that together with the status variable of the smart contract, does not allow them to deny their commitment (if the final status is finished). Therefore, the protocol meets the nonrepudiation requirement.

Confidentiality. The content of the contract is known only to A and B, and the smart contract functions require only the hash of the contract; therefore, the protocol meets the confidentiality requirement.

Abuse-freeness. We now analyze, in detail, the points at which the execution of the protocol can be found:

  • Before sending the signature of A, neither party can clearly abort or terminate the execution of the protocol;

  • A has sent her signature and can cancel anytime she wants, and B can finish the contract signing anytime he wants, and therefore, neither party can control the result of the execution of the protocol;

  • A cancels (before B signs): the contract status is canceled, and as of this moment, neither A nor B can take any further action; and

  • B signs (before A cancels): the contract status is signed, and as of this moment, neither A nor B can take any further action.

Therefore, at no time can A or B unilaterally determine the final status of the signing of the contract. Thus, the protocol satisfies the abuse-freeness requirement.

9 Cost assessment

To evaluate the cost of our solution, we deploy our smart contract using the Hardhat network, a local Ethereum network node designed for development [72]. This approach enables us to deploy, test and debug the code of our smart contract, all in a local environment, while avoiding the cost of a real public blockchain.

9.1 Gas cost

The complexity of the operations involved in executing a function of a smart contract on an EVM fixes some of the economic costs derived from the execution of this function. This complexity is measured in gas units and is fixed by [70]. For example, the amount of gas required for contract creation is fixed at 32,000 gas units (without the execution of any function of the contract). There are several available utilities that enable us to determine the amount of gas consumed by each function of a smart contract. We selected the Ethereum gas reporter plugin [73] because it can be integrated into different development frameworks, such as Hardhat.

Table 2 shows the cost (measured in gas units) of the two main functions of our solution (sign and cancel) and the cost of deploying the smart contract. As we can see, and as expected, the cost of deploying the contract in the blockchain network is high compared to that of the other functions. However, the contract is deployed only once and used multiple times for different instances of abuse-free contract signing. The sign function must be called by B in each protocol execution, and as shown in 2, and its cost is approximately 62% higher than the cost of cancel execution. The query function does not change the state of the blockchain; thus, it does not entail an economic cost.

Table 2 Cost in gas units of the deployment of SC and the execution of each SC function
Full size table

9.2 Cost in fiat

The cost measured in gas units provides useful information about the complexity of the operations as well as a way in which to compare different solutions because this metric is not affected by price fluctuations in the associated cryptocurrency. However, the economic cost of running the different tasks involved in the abuse-free contract signing can change daily as a result of fluctuations in the price of the associated cryptocurrency. Therefore, the final price of executing a function is calculated as the number of gas units needed to run a function multiplied by the gas price at the time of its execution.

The gas price refers to the amount of WeiFootnote 2 that a user is willing to pay for each unit of gas. As the gas price fluctuates daily, we consider the gas price over time. For this purpose, we use the dataset provided by [74], which contains the average gas price, measured in Wei, paid each day for the Ethereum blockchain. Using the exchange rate between Ether and US dollars (per day [75], we evaluate the final cost of the deployment of SC and the execution of the sign and cancel functions.

Fig. 4
figure 4

sign and cancel Functions: estimated average cost (measured in USD) for 2023 (from January 1 to July 15), considering the average gas price paid in the Ethereum network

Full size image

Figure 4 depicts the average cost that A and B would have paid per day to execute the SC functions in 2023 (from January 1 to July 15) if the Ethereum network were used. By analyzing the figure, we detect a few main peaks due to congestion events and, in turn, to an increase in the gas price required.Footnote 3 Excluding these peaks, the gas price can be considered quite stable (see Fig. 4 and Table 3). Nevertheless, the prices may be considered high based both on the quantity and frequency of the contracts to be signed. As explained in Sect. 6, the sign function must be executed for each contract signing.

New EVM-based blockchains have emerged in recent years to address some of the problems of Ethereum, such as its scalability and, consequently, the associated costs of its use. Polygon is a blockchain, defined as a layer-2 solution, that has emerged to provide faster transactions and lower prices [76]. Figure 5 depicts the average cost of SC’s functions for 2023 (from January 1 to July 15) using the Polygon network. Clearly, the prices are significantly lower than those of the Ethereum network. In the worst case, the cost of running the sign function is $ 0.169, with an associated low standard deviation (see Table 3). Therefore, our solution is cost effective.

Fig. 5
figure 5

sign and cancel Functions: estimated average cost (measured in USD) for 2023 (from January 1 to July 15), considering the average gas price paid in the Polygon network

Full size image
Table 3 Maximum, minimum, and average (and standard deviation) of the price (in USD) required by each function executed in 2023
Full size table

9.3 Practical implementation issues

As analyzed in the previous sections, the economic cost of using blockchain is reduced significantly depending on the blockchain where the smart contract is deployed. Therefore, the solution can be considered economically viable. As it is a relatively new technology, in addition to the economic cost and proven technical feasibility, potential barriers associated with the use of our proposal must be considered.

The adoption of our solution requires the exchange of messages between both signers in an off-chain way, which can be easily implemented using some existing technologies. To secure the process of signing a contract (without blockchain involvement), signers can establish a protected communication channel using two distinct approaches. In the first scenario, where a signer maintains an ongoing service for handling contract signature requests, TLS [77] can be used. TLS provides an encrypted channel, and both signers are authenticated through their respective digital certificates. In the second scenario, signers exchange messages without the need for a continuously running service. Here, S/MIME [78] can be used to guarantee the encrypted delivery of the protocol messages. Both protocols (TLS and S/MIME) offer a secure means of communication between signers. These protocols are widely known and supported by several commercial solutions. TLS is commonly used for secure connections in web browsers, and S/MIME is integrated into popular email clients such as Microsoft Outlook and Mozilla Thunderbird, as well as widely used webmail platforms like GoogleFootnote 4.

One of the limitations of using blockchain is that users need to buy cryptocurrencies to conduct transactions. This step is not complicated, as various solutions, such as MetaMask,Footnote 5 allow an individual to create a crypto wallet that connects to different blockchains and acts as a browser extension, which not only facilitates connections with blockchains but also allows users to purchase cryptocurrencies, thus also allowing them to pay for the publication costs of transactions. Conversely, signatories must be provided with an application that allows them to interact with smart contracts. This type of application is commonly known as a distributed application (DApp). DApps share many similarities with regular web apps and use common tools like HTML, CSS, and JavaScript, which makes it easier for developers and users to adopt such applications. In addition, when MetaMask is integrated with a DApp, the process becomes even simpler. MetaMask acts as a go-between for the web app and blockchain and handles important tasks like managing keys and signing transactions. MetaMask is user friendly, and developers can easily add it to their DApps.Footnote 6

Therefore, developing a DApp that enables the management of both the off-chain and on-chain processes of our solution can be considered relatively straightforward, although, like all new technologies, its widespread adoption may be slow, and factors such as trust in blockchain technology will play a significant role in such development.

10 Conclusions

Since Garay et al. [8], in 1999, defined the abuse-freeness requirement, various authors have proposed solutions based on the use of TTPs. Some of these authors have introduced modifications with respect to the original definition. A first conclusion is that each proposal should clarify with which definition it is working (and as we have already indicated, we think that it would have been desirable to use alternative names if significant changes were made to the definition).

The analysis of contract signing solutions based on blockchain has enabled us to conclude that no existing approaches satisfy the abuse-freeness requirement. Additionally, basing fairness on the establishment of economic deposits by signatories does not appear to be fully satisfactory (at least not for all types of contracts). More seriously, some solutions do not satisfy some of the fundamental requirements of contract signing: fairness, timeliness and nonrepudiation.

We present a proposal for contract signing based on blockchain, and the security analysis shows that in addition to the basic requirements, our solution satisfies the requirements of confidentiality and abuse-freeness.

The deployment of solutions that use public blockchains entails economic costs that must be assumed by participants. We analyze our solution with two EVM-based blockchains. When using Ethereum, costs can be high, whereas these costs are significantly reduced if other types of blockchains, such as Polygon, are used. Therefore, the solution is cost effective.