1. Introduction
The signing of contracts is an essential process in conventional commerce. When a contract is sufficiently important, a signature is obtained face to face to prevent one of the parties from cheating, for example, by obtaining a signed copy from the other party and not providing a signed copy; that is, the exchange must be fair. In the case of very important or special contracts, a trusted third party (TTP) intervenes in the signing of the contract (for example, a notary).
The digital signature of contracts and agreements is also a main process in both electronic commerce and marketplaces, and for this reason, protocols must be established (the steps that the parties must follow). In the electronic world, it is not possible (reasonable) for a signature to be obtained face to face. However, it is possible for a TTP to intervene in the protocols. In fact, most of the schemes that we find in the literature (e.g., [
1,
2,
3,
4]) are solutions with a TTP (since previous solutions without a TTP are not secure or feasible from a practical point of view [
5]). Among the solutions with a TTP, we can differentiate two types: an online TTP, who intervenes in all executions, and an offline TTP, who intervenes only in the event of conflict. In both cases, these solutions are problematic because it can be difficult for the parties to identify a TTP whom all signatories agree is trustworthy.
In the marketplace scenario, where consumers and providers share the same business space, the relationships and agreements among the different parties are more dynamic [
6]. Sometimes a contract must be signed by more than two parties, which is the case we discuss here of multi-party contract signing. We also find solutions with a TTP for this case in the literature [
7,
8], but some problems can still arise. The more signing parties there are, the more difficult it will be to agree on a TTP. In fact, after more than 40 years of proposals with TTPs, we have not found any that have been put into practice and are available to potential signatories. One aspect that should not be forgotten is that TTPs, regardless of how “trusted” they may be, can act maliciously (harming one or more of the signatories). For this reason, it is very important that if entities other than the signatories are involved in the contract signing process, the behavior of these entities is verifiable. This weakness in classic solutions is one of the strengths of the blockchain: operations carried out through public blockchains are verifiable by the entire community of participants in the system.
In the literature, we find schemes for signing contracts that use blockchain [
9]. In some of these solutions, it is possible to achieve the fairness property without using the services of a TTP. Most solutions are for the signing of contracts between two parties and therefore do not solve the problem of multi-party contracting. In fact, we found only one solution for signing contracts for three signatories [
10], with the shortcoming that it is not easily extendable to
N signatories. For this reason, in this article, we present a scheme for multi-party contract signing based on blockchain (without TTP) that improves on the solutions presented to date: it is truly multi-party and, in addition, requires the use of the blockchain at a low cost when problems appear during contract signing.
Contributions. The main contribution of this paper is that we present the first proposal for multi-party contract signing based on the blockchain (with Ethereum smart contracts). The previous proposals to sign contracts based on the blockchain, which we find in the analyzed bibliography, only allow the signing of contracts between two parties, except for one proposal that is designed for the signing of contracts between three parties. Therefore, it is the first proposal for N signatories (where N can be the desired value) that does not require the existence or the intervention of a TTP, as is the case in most of the classic proposals (with the inconveniences already indicated) for multi-party contract signing.
The second contribution is that the proposal is off-chain, that is, transactions are only carried out with the blockchain (the execution of smart contract functions) in the event that one or more of the parties attempts to cheat. If the signatories follow the steps indicated in the protocol, the intervention of the blockchain is not necessary, with the consequent cost savings. None of the solutions analyzed for two or three parties meets this requirement, and we are thus opening a new line to design protocols for blockchain-based contract signing in an off-chain manner.
Finally, we demonstrate that in the event that blockchain intervention is necessary, only one interaction with the blockchain is necessary, regardless of the number of signatories. Thus, the costs that the signatories should incur are very reasonable. Specifically, we conduct a temporal and cost assessment showing that a balance between the delay required to execute the blockchain functions and the price paid for their execution can be achieved.
Organization. We have organized this paper into the following sections. The security requirements for multi-party contract signing are defined in
Section 2.
Section 3 is devoted to analyzing the related work found in the literature.
Section 4 provides a complete description of our multi-party contract signing protocol. This section is followed by a description of the code of the smart contract in
Section 5 and the analysis of the security of our proposal in
Section 6. In
Section 7, we analyze the cost of our proposed solution. Finally, in
Section 8, we summarize the main results.
3. Related Work
In this section, we review the articles found regarding contract signing based on the blockchain. For this, a search was carried out in Web of Science, Scopus, and Scholar (of the terms “contract signing”, “fairness”, and “blockchain”). Eight of thirteen references found have been analyzed, since five of them correspond to articles only available in Chinese (of which only the abstract is available in English).
None of the previous solutions analyzed solves the problem of multi-party contract signing, and none of them uses the off-chain mode. Therefore, it will not be possible to compare our proposal with the previous solutions presented in this section. However, the analysis of the previous solutions for blockchain-based contract signing between two parties, and in one case for three parties, is interesting because some lessons can be extracted to consider in the design of blockchain-based solutions (multi-party, two-party, or three-party).
The oldest reference is from [
13], with a proposal that bases fairness on the involvement of a trustworthy time-stamping service in the protocol. The authors indicate that this role can be centralized or decentralized. In the second case, they note, tangentially, that a blockchain such as Bitcoin could be used. However, the authors do not specify what the protocol would be like in the event that the time-stamping service was provided by a blockchain. Consequently, they also do not provide any evaluation of the costs involved. In any case, each execution of the contract signing protocol would require the intervention of the blockchain, with its corresponding cost.
In Reference [
10] presented a scheme for contract signing between three parties (
A,
B, and
C) based on blockchain. This conference article is expanded by the same authors in a journal article ([
14]). This latter article contains a security analysis, which the first one lacks. However, the proposal is essentially the same. The authors emphasized that their proposal allows for the privacy of the signed contract and that the number of rounds is constant.
In a first phase, the three signatories exchange directly (without the intervention of the blockchain) verifiable signatures on the contract they wish to sign. These are partial signatures that do not constitute proof that the contract is signed. In a third phase, they must provide, through the blockchain, additional information that will make it possible to convert partial signatures into “final” signatures that will serve to prove that the contract is signed.
In a second phase, the signatories make deposits in the blockchain, to provide “guarantees” that they will comply with the provisions of the protocol (the third phase). These deposits, by design of the protocol, are asymmetric: B and C deposit twice as much cryptocurrency as A. It is true that in the end, the possible penalties are the same for all three signatories, but this asymmetry is not fair: A has an advantage over B and C since he deposits a lower amount.
In a third phase, the signatories must publish on the blockchain the information necessary to convert partial signatures into final signatures before a deadline expires (each signatory has a specific deadline). The signatories who comply with this third phase will be able to recover the deposit they had made. Signatories who do not comply with this third phase will be penalized since they will not be able to recover their deposits, which will be distributed between the other two signatories.
The protocol has a weakness, which the authors themselves highlight. A situation may arise where C obtains the evidence from A and B, and he does not provide his evidence to A and B. C will be penalized: his deposit will be provided to A and B. However, C will have proof that the contract is signed, while A and B will not have such proof.
References [
10,
14] did not clarify the nature of the deposit (or the amount). Whatever it is, we want to emphasize that this makes this protocol (and others we will discuss later) not viable in all contract signing scenarios. In a purchase-sale contract, it is possible (and reasonable) to think that the buyer has funds (at least those necessary to make the purchase), but forcing the seller to have equivalent funds means that not all sellers can use this type of protocol.
References [
10,
14] did not provide a cost analysis, which is especially important because the number of interactions with the blockchain (up to 10) suggests that the proposal is not scalable: it is costly for three parties and most likely much more expensive for a possible extension to
N parties. In any case, the authors do not indicate how the protocol could be extended to
N parties, and from the analysis we have carried out, we conclude that it is not a trivial task.
Reference [
15] presented a protocol for signing contracts in PDF format. Although the authors highlighted this fact of the format, it turns out to be quite irrelevant in the design of their protocol (contracts could also be signed in any other format, such as XML). What is highly relevant is that these authors, to overcome the problems posed by the restrictions of the Bitcoin and Ethereum blockchains, proposed to create a new cryptocurrency. This cryptocurrency is created from Bitcoin but expands the script opcodes to be able to perform necessary operations, according to the design of its protocol, on the blockchain. This means that the real viability of the proposal cannot be analyzed, nor can we conduct a cost analysis of the use of the blockchain. The authors especially emphasized that their proposal guarantees privacy regarding the content of the contract and regarding the identity of the signatories.
Tian et al.’s proposal shares with that of Huang et al. the defect that they base fairness on the deposit of cryptocurrencies that the signatories must make. In Tian et al.’s proposal, this amount is also recovered if the signatories follow the steps specified in the protocol. However, regarding the amount of the deposit, they went further than Huang et al., “... the deposit should be a similar value as the contract to be signed”. In addition to the disadvantage already indicated above, this value would not always have to be easy to calculate. Imagine the case in which the buyer and the seller must convert different currencies to cryptocurrencies. Unfortunately, these cryptocurrencies fluctuate continuously (with respect to different foreign exchanges).
It also shares with the Huang et al. proposal the defect that it cannot be considered to meet the fairness requirement. As the authors indicated, a situation may arise where “... party A gets a signed contract of party B at the cost of losing the deposit”. It is true that B receives compensation, but he does not know whether A will execute the contract. Suppose that the contract is for the purchase of X units of a product. If B does not manufacture these units, and A decides to execute the contract, then B must face a possible lawsuit from A. If B manufactures the units and A decides not to execute the contract, then B will have lost an opportunity cost (he could have accepted other orders that would have brought direct benefits—income—and indirect benefits—the possible diffusion of customer satisfaction).
Execution of the Tian et al. protocol involves a minimum of three and a maximum of five transactions with the blockchain. In this case this is relatively important because, as we have indicated, they use a new blockchain, about which we do not know the possible transaction costs, who manages the cryptocurrency, etc.
In Reference [
12], we presented a protocol for contract signing between two parties based on the Bitcoin blockchain (without using scripts or smart contracts). The protocol consists of four steps, and it involves only one transaction with the blockchain. We presented an evaluation of costs, showing that they are reasonable values for a signature between two parties, especially if the volume of signed contracts is low. The proposal is accompanied by a proof of concept that allows us to demonstrate its practical viability. From the perspective of multi-party contract signing, our previous proposal suffers from two defects. On the one hand, each execution implies a transaction with the blockchain and, therefore, associated costs. On the other hand, the proposal targets contracting between two parties, and it is not envisaged that the extension to
N parties will be a simple task.
Reference [
16] presented a protocol that, although the terms “contract signing” appear in the title, is actually a protocol for the purchase of physical goods in exchange for payment. It is a problem in the same family as contract signing (fair exchange of values), but it has some peculiarities that distinguish it from the objective of contract signing protocols and, therefore, the objective of this article. In any case, it also has the drawback that the achievement of fairness is based on the parties making deposits on the Bitcoin blockchain. Furthermore, the proposal is explained at a very high level, without specifying the details of the protocol, which makes it difficult to carry out an analysis of the protocol. Among the data that are provided, we find different deadlines: one of three days and one of seven days. These are very long periods, which may be reasonable for the purchase-by-payment application but which we do not find in any contract signing proposal.
Reference [
17] presented two proposals for contract signing based on blockchain. The first one is simple (three steps), but the content of the contract is published on the blockchain, so its privacy is not possible. Moreover, each of the three steps of the protocol involves a transaction with the blockchain.
The second solution from Mut-Puigserver et al. achieves the privacy of the contract content and is therefore more complex. In this case, an encrypted version of the contract is published on the blockchain. This, which has privacy as a positive aspect, has a drawback: there are very voluminous contracts, and the cost of storing them on the blockchain, encrypted or not, can entail a high cost. The authors also incorporated the deposit mechanism (in both proposals), but note that it is optional (it is only an incentive, not an obligation, for the initiator of the contract to act honestly).
Another drawback of Mut-Puigserver et al.’s “confidential” proposal is that it requires the execution of cryptographic operations on the blockchain, which is costly. The authors indicated that the evaluation of the protocol is pending, particularly the evaluation of the costs of executing the smart contract functions. It is relevant that this proposal requires the execution of five to seven functions on the blockchain. Moreover, on several occasions, the authors affirmed that the design of the protocol has been carried out with the intention that it be extensible for more than two signatories (multi-party). However, it does not seem that it will be a trivial task or have an efficient result, and the authors themselves left as future work to “reformulate the system of confidential contract signing to create a multiparty protocol”.
The last scheme analyzed is that of [
18]. This scheme uses a verifiable encryption signature to achieve the privacy of the contract. Their proposal also uses the deposit mechanism but with a great difference from the previous proposals. If both parties are honest, they will get their deposits back (as in all proposals analyzed). If one of the parties is dishonest and the other honest, then the latter will receive the deposit of the former (and will recover its own), but in addition, the blockchain will mark the contract as invalid. Therefore, deposits, which continue to present the aforementioned drawbacks regarding determining the amount and requiring that both parties have sufficient cryptocurrency, in this case are an incentive to act honestly but do not have a negative impact on fairness. As a negative point, the process of invalidating a contract requires the applicant to provide the text of the contract, with the consequent loss of privacy.
Zhang et al.’s proposal also makes intensive use of the blockchain: up to six transactions are carried out with the blockchain in the event that both parties are honest. Fortunately, the authors provide the costs in terms of gas (they work with the Ethereum blockchain) of the six functions established in their protocol.
Although none of the solutions analyzed solves the problem of multi-party contract signing, some interesting conclusions can be drawn, which we have considered when designing our solution. Basing the fairness of the proposal on deposits can limit the scope of the proposal and even lead to proposals that do not meet the fairness requirement. A high number of transactions with the blockchain simplifies the design of the proposal but at the cost of increasing the costs for the signatories of the contract. In relation to costs, the proposals should include a cost analysis, since a system can be secure and practical but not viable from an economic point of view. Worse is the use of non-standard blockchains or cryptocurrencies: this does not allow conclusions to be drawn about the viability of the same, neither from a practical point nor from a cost point of view. Finally, having a solution for contract signing between two or three parties does not mean that we can straightforwardly extend the solution to N signatories.
5. Smart Contract Specification
We deployed the smart contract (
) defined in
Section 4.2 on Ethereum “because Ethereum was designed as a platform for deploying smart SC that run on the blockchain to facilitate, execute and enforce the terms of an agreement among parties” [
19].
Moreover, it is the second largest cryptocurrency by market share according to CoinMarketCap (CoinMarketCap: Cryptocurrency Market Capitalizations. Source:
https://coinmarketcap.com/. Data publication date: 1 March 2021). Note that a smart contract defined in Ethereum should not be confused with a contract that outlines the terms of a relationship (usually one enforceable by law).
As explained in
Section 4.1, when a signatory has the signatures of all signatories of the contract but does not have the acknowledgment of receipt from one or more of them, he can call the
functions.
Therefore, the signatories must agree on the
to be used. This agreement is conducted in the negotiation phase prior to the signing of the contract itself, in the same way that the signatories agree on any other information necessary to carry out the signing of the contract, such as the finish deadline. The address of the contract (
) must be included in the first round of the
sub-protocol (see
Section 4.2.1), so the
must be deployed before the
sub-protocol can be executed.
Once the contract has been deployed (including the code of the smart contract in a transaction), it is self-executed in the EVM (Ethereum Virtual Machine) of each node of the Ethereum network. To execute its functions, a signatory must send a transaction (to the address of the deployed contract, ) indicating the function to be executed and the required parameters. Each network node executes the function and, if the execution is successful, the transaction is published on the blockchain, recording its execution.
All analyzed protocols for contract signing based on smart contracts (
Section 3), with the exception of [
12], require a cost when deploying the smart contract. However, in addition, the execution of these protocols entails an additional cost each time a contract is signed because they require executing functions of the deployed smart contract. In contrast, our proposal involves only the deployment costs, but it does not involve additional subsequent costs for each contract signing (except in cases of conflict, which should be exceptional, since a dishonest signatory will not obtain any benefit by not following the steps indicated in the protocol). Therefore, the
may be deployed only once (by any of the signatories or other entities) and used as many times as required to sign different multi-party contracts. For this purpose, it is not necessary to provide any information regarding a specific execution of a multi-party contract signing when deploying the
. This exhibits the importance and advantage of meeting the requirement of bc-effectiveness.
We define a data structure (see
Listing 1) to store the data associated with each contract (the hash of the contract, finish deadline, signatures, and status of the contract) and indexed by
. All these data are provided by the signatory who calls the
function and are verified by the
before establishing its status (as explained below). A new data structure is created for each multi-party contract signing that requires the
to be called. Note that no confidential data are stored in the
data structure; that is, the content of the contract,
M, cannot be recovered by anyone from the signatures or the stored hash of the contract.
Listing 1.
Data structure associated with each exchange identifier () requiring the use of the blockchain.
Listing 1.
Data structure associated with each exchange identifier () requiring the use of the blockchain.
The provides two public functions:
: given a contract identifier, any signatory can provide all signatures on the contract, before t expires, establishing the status of the contract as .
: given a contract identifier, any signatory may check the status of the contract, obtaining all signatures if the contract was previously finished by one of the signatories.
A signatory provides, as input parameters to the
function (see
Listing 2), the contract identifier, the associated deadline, the hash of the contract, the list with the public key of each signatory, an index pointing to the signatory’s public key that calls the
function, and all signatures on the contract.
Listing 2.
Code of the finish function.
Listing 2.
Code of the finish function.
The
checks that the contract has not already been finished (there is no entry for that identifier in the
data structure), that the signatory calling this function is one of the legitimate signatories of the contract, and that the deadline has not expired. Next, the
must verify that the data provided by the signatory requesting finalization are linked to a valid contract identifier (
). As shown in
Figure 3, the identifier is generated as the hash of the
,
, the expiration time and
. To do so, the
retrieves its Ethereum address (
) and the public key of the requesting signatory from its own information to generate the
(the contract is assigned the address of the signatory who called the
function). Next, the
checks that the identifier matches the one provided by the signatory as input to the
function. In this way, only one of the legitimate contract signatories can successfully execute the
function. After the identifier is verified, the
checks the validity of each signature provided by the signatory (see
Listing 3).
The use of secure signatures is a key point in any contract signing procedure. Thus, it is crucial to consider secure algorithms using cryptographic keys of suitable length. Moreover, in any electronic contract signing, designers and developers should consider legal regulations, but it is outside the scope of this paper. We use the ECDSA (Elliptic Curve Digital Signature Algorithm) signature scheme [
20], the same used by Ethereum for signing transactions. The security level (“a number associated with the amount of work (the number of operations) that is required to break a cryptographic algorithm or system” [
21]) recommended today [
22,
23] is at least 112 bits, equivalent to a 224-bit key for ECDSA. Ethereum uses keys of 256 bits, equivalent to a security level of 128 bits. For these conditions, the use of an SHA-256 hash function is sufficient to maintain the security level of the signature scheme [
23]).
Listing 3.
Verifying the contract signature for each signatory.
Listing 3.
Verifying the contract signature for each signatory.
The digital signatures on the contract are created off-chain during the
sub-protocol but must be validated by the
(
on-chain) when calling the
function is required. An ECDSA signature together with the hash and the signature on the contract allow the public key used to sign that contract to be recovered (see
Listing 3). We use the extended ECDSA signature to allow the public key to be recovered from its signature with no ambiguity. In this way, one can verify whether the signature on the contract was originally produced by each signatory (each public key provided to the
function).
Once all signatures have been validated, the
function modifies the status of the exchange for the given exchange identifier, so a new transaction is included in the blockchain, as will be explained in
Section 7. Each transaction signature is used to authorize transactions on behalf of the signatory. Therefore, these signed transactions can be used as non-repudiation evidence.
Any signatory can call the
function (see
Listing 4) providing the contract identifier. The smart contract checks whether a data structure for this identifier exists (
Listing 1) and whether the status of the contract was finished. If the contract was
, the
returns the signatures of all signatories. The
function does not modify the status of the exchange and therefore does not require any transaction to be included in the blockchain (see
Section 7).
Listing 4.
Code of the query function.
Listing 4.
Code of the query function.
6. Security Analysis
In this section, we demonstrate that our proposal meets the requirements explained in
Section 2. The bc-effectiveness is the first requirement that we will verify.
If all signatories follow the two rounds of the sub-protocol, at the end of the execution, the signatories will have evidence that the contract is signed, and the or functions of the smart contract will not have been executed. Therefore, our protocol satisfies the bc-effectiveness requirement.
Next, we will prove that for any honest signatory, whatever the behavior of the other signatories (whether they are honest or attempt to cheat), the protocol meets the fairness requirement: at the end of the exchange, he is not in a disadvantageous situation. If the protocol is fair to any honest signatory, regardless of what others signatories do, this means that the protocol is fair to all honest signatories. Before proceeding with the proof, we present some preliminary questions:
We will say that a signatory is honest if he follows the steps established in the protocol.
We do not analyze whether the protocol is fair or unfair for a dishonest signatory since failing to follow the steps established in the protocol is his responsibility.
In relation to the blockchain, for the signing of a specific contract, two situations may arise:
- -
the finish function has not been executed successfully; in this case, no information regarding the contract has been published on the blockchain;
- -
the finish function has been successfully executed; this means that:
- *
a signatory executed the finish function before the deadline expired (after the deadline, the finish function will not be executed);
- *
the signatory provided the correct signatures of all the N signatories of the contract (if one or more of the signatures are not correct, the finish function will not be executed successfully);
- *
it will be recorded in the blockchain that this contract has been signed for the N signatories (if a signatory executes the query function, he will obtain evidence that the contract is signed).
Now, we will proceed to analyze the possible situations that the honest signatory (Bob) may face:
situation-1: Bob has not received the signatures to be sent by the previous signatory (note that the first signatory cannot be in this situation since he does not have a previous signatory). Since Bob is honest (he follows the steps of the protocol), he does not take any action (he does not send anything to anyone). Therefore, we have the following:
Since Bob has not sent anything, no other signatory can have all the signatures and all the acknowledgments.
No signatory can successfully execute the finish function because this requires all N signatures, and Bob has not provided his signature to anyone.
Therefore, in this situation-1 the contract is not signed, and correspondingly, Bob has no evidence of the signing of the contract, as none of the other signatories does: it is fair.
situation-2: Bob has sent his signature and has not received the signatures from the following signatory in the chain (note that the last signatory cannot be in this situation since he does not have a following signatory). Since Bob is honest (he follows the protocol steps), he will not send his acknowledgment to anyone. Therefore, no other signatory can have all the signatures and all the acknowledgments. However, Bob knows that some signatory could have all the signatures, and therefore he must request the execution of the query function when the deadline expires. Bob can face two situations:
situation-2.1: No one has successfully executed the finish function. Therefore, in this situation-2.1 the contract is not signed, and correspondingly Bob executes the query function and obtains no evidence of the signing of the contract, as none of the other signatories does: it is fair.
situation-2.2: A signatory has successfully executed the finish function. Therefore, in this situation-2.2 the contract is signed. Bob executes the query function when the deadline expires and obtains the evidence that the contract is signed. The signatory who successfully ran the finish function had evidence of the contract signing, and now Bob has it too: it is fair.
Therefore, whether situation-2.1 or situation-2.2 occurs, the exchange is fair for Bob.
situation-3: Bob has received the signatures of all the other signatories, and he is not receiving the acknowledgments from the previous signatory in the chain (note that, again, the first signatory cannot be in this situation since he does not have a previous signatory). Bob will not send his acknowledgment, and therefore no one can have evidence of the signing of the contract without the intervention of the blockchain: as Bob has not sent his acknowledgment, no other signatory can have all the signatures and all the acknowledgments. Since Bob is honest (he follows the protocol steps), he will request the execution of the finish function. Now, Bob can face two situations:
situation-3.1: No one has successfully executed the finish function before Bob. Bob has all the signatures, and with this information, he can request the successful execution of the finish function, with which he will obtain the evidence that the contract is signed. There is no evidence in our protocol that could contradict Bob: it is fair.
situation-3.2: Another signatory has successfully executed the finish function. Therefore, in this situation-3.2 the contract is signed. When Bob requests the execution of the finish function, he will see that it has already been executed (and cannot be executed again), but Bob will still obtain the evidence that the contract is signed. The signatory who successfully ran the finish function had evidence of the contract signing, and now Bob has it too: it is fair.
Therefore, whether situation-3.1 or situation-3.2 occurs, the exchange is fair for Bob.
situation-4: Bob has received the signatures of all the other signatories, he has received the acknowledgments of the previous signatories, he has sent his acknowledgment of receipt (he follows the steps in the protocol), but he has not received all the acknowledgments of receipt from the following signatory in the chain (note that, again, the last signatory cannot be in this situation since he does not have a following signatory). Once Bob has sent his acknowledgment, one or more of the other signatories can obtain all the signatures and all the acknowledgments. Therefore, Bob, following the protocol, must attempt to execute the finish function before the deadline expires. Analogous to what we explained in situation-3, Bob can face two situations:
situation-4.1: No one has successfully executed the finish function before Bob. Bob has all the signatures, and with this information, he can request the successful execution of the finish function, with which he will obtain the evidence that the contract is signed. There is no evidence in our protocol that could contradict Bob: it is fair.
situation-4.2: Another signatory has successfully executed the finish function. Therefore, in this situation-4.2, the contract is signed. When Bob requests the execution of the finish function, he will see that it has already been executed (and cannot be executed again), but Bob will still obtain the evidence that the contract is signed. The signatory who successfully ran the finish function had evidence of the contract signing, and now Bob has it too: it is fair.
Therefore, whether situation-4.1 or situation-4.2 occurs, the exchange is fair for Bob.
In conclusion, any honest signatory is guaranteed that if he follows the steps of the protocol, the fairness requirement is met for him: he will never be at a disadvantage. This statement is valid for each and every one of the signatories who are honest, with which we conclude that the protocol meets the fairness requirement: if any signatory has evidence that the contract is signed, all honest signatories will have evidence that the contract is signed; if the honest signatories have no evidence that the contract is signed, no signatory will have evidence that the contract is signed.
If all parties are honest, the execution of the protocol ends after the second round of the sub-protocol. However, in any of the cases, all parties have the guarantee that at t (the deadline), the exchange will have reached a final state. Before this moment, any signatory not receiving an acknowledgment must have executed the function. Signatories not receiving signatures can execute the function at any time after t to know the final state of the exchange (and obtain evidence). In short, the protocol satisfies the timeliness requirement because it allows the parties to know that the execution of the protocol ends fairly in a finite time.
In the first round of the sub-protocol, the text of the contract is transmitted without encryption. This is performed to avoid introducing further complexity into the explanation of the protocol, but it is very easy to obtain a confidential exchange. The text of the contract can be encrypted with a symmetric cryptographic key k, and this key can be encrypted with the public keys of all signatories, so that only they can access the content of the contract. In the event that a smart contract function must be executed, this function needs only the hash of the contract to conduct the signature verification (if applicable). Therefore, we can affirm that the proposed protocol can easily satisfy the confidentiality requirement.
Once the exchange is positively completed (with or without the execution of the smart contract functions), all parties have evidence of non-repudiation. Each signatory (e.g., Bob) has evidence of the non-repudiation of receipt and non-repudiation of origin of all other signatories: all of them have signed the contract. Bob has obtained the signatures of all other signatories on the contract, and he has obtained either the acknowledgments of all other signatories or the evidence from the smart contract functions. Therefore, the non-repudiation of receipt and non-repudiation of origin requirements are met.