A Blockchain-Based Protocol for Fair Delivery for Receipts

Abstract

Message exchange for acknowledgment of receipt (e.g., for services that provide recipients with certain documents, such as sanctions, summonses, or requirements, which are often sent by public administrations) has traditionally been provided through protocols based on the use of trusted third parties (TTPs). More recently, solutions have been proposed that totally or partially replace the TTP with a blockchain. However, an analysis of these proposals reveals that they have one or more of the following drawbacks: failure to meet confidentiality requirements, the use of TTPs, and susceptibility to attacks that make them unfair. In this paper, we present a method of providing fair delivery for receipts based on a blockchain that does not suffer from the above disadvantages: it is fair and confidential and does not use a TTP. In addition, we demonstrate the feasibility of the protocol through a cost analysis and a proof-of-concept implementation, showing that our solution is more economical than existing solutions, and can be considered cost-effective even under low time requirements.

1. Introduction

Acknowledgment of receipt in exchanging documents is a method used in multiple environments, especially in public administration. Referrals of sanctions, summonses, and requirements are examples of processes that use this service. The replacement of paper documents with their electronic equivalent transfers the need for this service to the electronic world. This problem falls under the broader category of problems concerning the fair exchange of values, encompassing examples such as contract signing, payment for receipt, certified email, and electronic notifications. These use cases share various similarities, particularly the fairness requirement: a protocol must guarantee fair conditions for all participants during the exchange. However, even though the use cases all share the most challenging objective of ensuring fairness, the methods used to achieve fairness can be quite different depending on the scenario. Therefore, each use case introduces specific challenges, necessitating tailored approaches to address its unique requirements.

As stated above, for the particular case of the acknowledgment of receipt, which we address in this research, the main requirement that must be met in this process is fairness. The sender wants the recipient to be unable to access the contents of the document if the recipient does not sign an acknowledgment of receipt. The recipient does not want to sign an acknowledgment of receipt if they do not have a guarantee that they are able to access the contents of the document. This problem has traditionally been resolved with the intervention of trusted third parties (in the case of both paper documents and electronic documents [1,2]).

The use of TTPs is not without problems. A TTP can be dishonest and can help one of the parties (for example, by allowing the document to be read without requesting an acknowledgment of receipt); the TTP also constitutes a single point of failure. Therefore, blockchains have arisen as a possible substitute for TTPs. However, the use of public blockchains entails an economic cost that must be analyzed to guarantee the viability of this proposed approach. The use of private blockchains in “open” environments does not seem to be a viable solution from a system security perspective.

The fairness requirement is not the only requirement that must be met. Proposed approaches must ensure that the document is seen only by the sender and recipient. The use of TTPs in addition to blockchains should be avoided (in the Related Work section, we show that some proposed approaches use both blockchains and TTPs). Users must be guaranteed that the exchange ends fairly within a finite time, and these users must not be able to deny their actions after the exchange.

Contributions. The main contribution of this paper is the proposal of the first blockchain-based approach for exchanging a message for a receipt that satisfies all of the following requirements: fairness, confidentiality, and no use of TTPs. We analyze the previous solutions found in the literature, and in the “Related Work” section, we show that each of them fails to fulfill one or more of these three requirements.

Another contribution is the evaluation of the cost of the proposed solution for different public blockchains based on the EVM (Ethereum Virtual Machine) considering the trade-off between cost and delay. The results show that the proposed approach is feasible in terms of cost and that it outperforms the previously analyzed solutions. In addition, we provide the code corresponding to the smart contracts, enabling other authors to verify the accuracy of our results.

Finally, we provide a proof-of-concept implementation to show that our approach is feasible from a practical point of view.

Organization. The remainder of this paper is organized as follows: Section 2 introduces the features of blockchain technology and smart contracts. Related work is analyzed in Section 3. Section 4 summarizes our proposal for a fair method of providing delivery for receipts, followed by a full specification of the protocol in Section 5. The smart contract execution logic is provided in Section 6. We provide a proof-of-concept implementation that shows how our solution works in Section 7. A security analysis of our proposal is presented in Section 8, and a cost assessment is presented in Section 9. Finally, the conclusions are summarized in Section 10.

2. Blockchain and Smart Contracts

In this section, we describe the main characteristics of blockchain technology, focusing on the operation of smart contracts.

Blockchain technology has emerged as a transformative method, reducing reliance on TTPs in various sectors, such as the energy [3,4], e-commerce [5], supply chain [6], data sharing [7], healthcare [8,9] and 6G technology [10,11] sectors. In the blockchain ecosystem [12], we can categorize blockchains into two main types: permissionless and permissioned [13]. Permissionless, or public, blockchains are accessible to all and offer a decentralized and trustless environment. In contrast, permissioned blockchains are managed by a central authority. While permissioned blockchains can provide greater privacy and control, permissionless blockchains are more transparent, eliminating the need for trusted entities or a private infrastructure.

At its core, a blockchain acts as a transparent distributed ledger system for network nodes (also known as miners) [12]. The blockchain, as a distributed ledger, consists of linked and cryptographically secured records (blocks) recorded in a decentralized peer-to-peer network. The design of the blockchain ensures resistance to data modification, as altering one block requires changing all subsequent blocks. Owing to its decentralized and immutable structure, the blockchain can provide a verifiable and secure record of transactions.

Each block published on the blockchain contains all valid transactions included in the block (see Figure 1). A transaction is essentially an operation that is to be recorded on the blockchain; cryptocurrency operations (e.g., transfers between accounts) are the most commonly recorded operations, as exemplified by bitcoin. However, the need for automated, trustworthy execution of agreements, combined with a demand for decentralized applications (DApps), has driven an evolution in the use of cryptocurrency from a simple transaction tool to a platform for smart contracts, with Ethereum being the prime example.

A smart contract in Ethereum is self-executing code that runs on the Ethereum virtual machine (the Ethereum virtual machine (EVM) is a decentralized computing environment that executes smart contracts and runs decentralized applications (dApps) on the Ethereum blockchain) which is composed of executable functions that can handle digital assets or digital data [14]. A transaction that interacts with a smart contract includes key information such as the sender’s address, the smart contract’s address, specific data indicating which function of the contract is being called and with what input parameters, as well as the gas limit and associated fees (see Figure 1). This information is signed digitally by the sender, submitted to the network for validation, and, if accepted, executed within the contract’s context, with the results recorded on the blockchain. The input parameters and values necessary for a smart contract to execute its functions are included in the transaction data invoking the smart contract and are read-only. Therefore, the input data for a smart contract are part of the blockchain transaction, meaning that they cannot be altered. When these functions are called, they execute predefined actions that could require the validation of conditions or the storage of information [15]. Smart contracts use the storage component of the EVM, which is a long-term and tamper-proof storage area, to store the information needed to execute the different functions of a smart contract [14], but this information is not recorded in the blockchain blocks. In contrast, logs are used to store information that is not essential for the smart contract but must be accessible to off-chain applications. Logs are stored in a transaction receipt (see Figure 1), which is a data structure that is generated upon completion of a transaction and contains detailed information about the transaction’s outcome. This includes whether the transaction succeeded, specific events logged during execution, and other relevant details. Both the transaction and the transaction receipt are stored in the block, ensuring their inalterability.

3. Related Work

The service of exchanging a document for an acknowledgment of receipt has been referred to by various names, such as certified electronic mail, certified notifications, electronic registered delivery, and registered e-delivery. To determine the methods of performing this service on the basis of a blockchain, a search was carried out in Scopus, Web of Science, and Google Scholar for the terms above. Once the results of the search were screened, nine works were obtained, which are reviewed below.

In [16], the authors present two solutions for a certified notification service for the one-recipient scenario. One of them does not meet the confidentiality requirement, and the other requires the intervention of a TTP. The same authors in [17] propose two schemes for multiple-recipient scenarios. As in the previous case, one proposal does not meet the confidentiality requirement, and the other solution uses the services of a TTP. The same authors in [18] present a solution for multiple recipients in which the intervention of a TTP may be needed. The solution proposed in [19] also requires the intervention of a TTP (which the authors call “middleware”), which poses security concerns for the system. Although the behavior of this TTP is verifiable, one of the great advantages of using the blockchain is that it enables us to avoid the use of TTPs. As the authors indicate, the TTP can become a single point of failure: if the middleware is out of service, the certified notification service cannot be provided. Furthermore, the authors carry out a cost analysis of the use of blockchain, but they neglect to mention that the use of the TTP incurs additional costs for certified notifications. In short, these six solutions do not meet some of the requirements established in Section 4.1.

Regarding the solution presented in [19], the authors boast that their solution “reduces the number of steps to be executed by the involved actors by reducing them to two, one step per actor”. However, the protocol involves sending a message from the sender to the recipient; the sender must then execute one blockchain function, and the recipient must execute two blockchain functions. To all of the above, we add that the TTP must execute two blockchain functions.

The authors of [20] present a solution specifically designed for the multirecipient scenario since it performs operations that do not make sense in the single-recipient scenario. In any case, the protocol specification is incomplete because, for example, the authors do not explain how the recipient knows that they have a message from the sender, nor do they explain that functions must be executed to obtain data published on the blockchain. Moreover, even if no recipient states that they wish to receive the message, the sender must execute a finish function on the blockchain (with a consequent cost) to recover a deposit that they previously made. Finally, a cancellation function is provided for recipients, which is unnecessary (as it only increases costs). In [21], the authors present an improvement, in terms of cost, over the approach proposed in [20]. However, they indicate that “the steps of the fair exchange and the generated proof are the same” in both solutions (in fact, they do not provide a security analysis).

The authors of [22] present a solution based on the bitcoin blockchain, which makes it difficult to extend this solution to more advanced services (multirecipient services, combinations with other services, etc.) since it is not possible to program complex tasks on the bitcoin blockchain. One of the solutions presented in [23] is also based on the bitcoin blockchain; additionally, the explanation is incomplete, and the protocol is incorrectly specified. The description of the protocol indicates that the recipient must publish the decryption key and his signature on the blockchain so that the sender has evidence of receipt of the message, whereas the security analysis states that it is sufficient for the sender to publish the key and her signature so that they have evidence of receipt.

Some solutions (the second proposal in [23] and the approach proposed in [24]) impose a deadline for one of the parties to execute a blockchain function. If they fail to execute the function, they are left in an unfair situation. This situation can occur even if the party is honest, such as if the party is experiencing a denial of service (DoS) attack, a network failure occurs, or the party has suffered a ransomware attack that disabled their equipment. Therefore, it is preferable to design solutions in which these situations cannot cause a loss of fairness. Our proposed scheme also uses a deadline, but the protocol design avoids the problem of the previous solutions.

All previous proposals analyzed allow selective rejection by the recipient on the basis of the identity of the sender (this may occur, for example, if the recipient suspects that the message is a notice of a fine). Our proposed approach also does not address this problem. We only found two approaches [25,26] that attempt to solve this problem, and both require the use of TTPs. These are partial solutions, as both rely on maintaining the anonymity of the sender until the recipient accepts receipt of the message. This does not prevent the sender from rejecting receipt of messages from anonymous senders.

In conclusion, none of the solutions analyzed are fully satisfactory.

4. Proposal Overview

The scenario on which our solution is based is shown in Figure 2, which summarizes the involved participants and the relationships among them. The parties that use the protocol are described as follows:

• Sender (A). The sender is the party who wishes to deliver a document (or any other digital asset) to another party in exchange for a receipt as evidence of delivery.
• Recipient (B). The recipient is the party intended to receive the document and has the option to accept or decline delivery.
• Smart contract ($SC$). A smart contract is self-executing digital code deployed on a blockchain that is designed to manage the delivery process and settle any disputes that may arise.

We assume that a sender (A) wants to deliver digital content (M) to a recipient (B), who then acknowledges the receipt. The digital content to be delivered may include any material that can be delivered in a digital format. The protocol has three steps and essentially orchestrates communication between the sender and recipient, with the collaboration of a smart contract ($SC$). The protocol begins with an off-chain message in which A provides B with content encrypted via a symmetric key algorithm, along with a nonrefutable signature. Upon receiving the message, B has the option to accept or decline the message. If they opt to accept, they send an acceptance acknowledgment to the blockchain, which serves as nonrepudiation evidence that B is willing to receive the content. If B chooses to decline (e.g., if they suspect that it is a fraudulent request), they simply disregard the message without detriment to either party’s fairness. Once A is aware of the acceptance (by means of an event emitted by the blockchain), they publish the encryption key with an on-chain transaction, protecting it to ensure exclusive access by B. Finally, once B sees that A has published the key (again, through a blockchain event), they can retrieve, decrypt, and use the key to access the content delivered in the initial step. Notably, although there are three steps in the protocol, only Steps 2 (acceptance) and 3 (key publication) involve write operations to the blockchain, whereas the initial step involves only an off-chain message from A to B (transmitted through a secure connection such as a TLS connection) that has no blockchain cost.

Table 1. Notation for the fair delivery for receipts protocol.

A	Sender
B	Recipient
$SC$	Smart contract
$@X$	Blockchain address of entity X
M	Document to deliver
$h\left(\right)$	One-way collision-resistant hash function
$id$	Identifier of a protocol execution
$Si{g}_X\left(a\right)$	Signature on element a made by entity X
K	Secure key to be used by a symmetric cipher
$E_K\left(a\right)$ and $D_K\left(a\right)$	Symmetric encryption and decryption functions, respectively,
	on element a using symmetric key K

provides a summary of the notation used in the protocol description.

4.1. Security Requirements

Our solution must meet the security requirements outlined below to provide secure and reliable document delivery for a receipt [16,22]:

• Effectiveness. No TTP is involved in the protocol.
• Fairness. After protocol execution, either the recipient receives the document and the sender obtains the receipt or neither party receives either.
• Timeliness. Both participants can execute the protocol within a finite amount of time while ensuring that fairness is upheld.
• Nonrepudiation. None of the parties can deny their involvement in protocol execution. The recipient cannot deny having accepted the delivery, and the sender cannot refuse to provide a specific key for accessing the delivered content.
• Confidentiality. Only the sender and recipient have access to the digital document. Furthermore, the information published on the blockchain does not grant access to the content to any other party.

5. Certified Delivery Protocol

In this section, we provide a comprehensive explanation of the protocol, elaborating on each defined step. Figure 3 summarizes all the steps considered by the protocol. In the figure, the solid lines represent messages sent by the sender or recipient, whereas the dotted lines indicate events generated by the smart contract after successful function execution.

• Step 1 (Off-chain message). The first step of the protocol is to compose an off-chain message that A sends to B containing the following information:

$$\mathit{id},{\mathit{t}}_{\mathit{m}},{\mathit{t}}_{\mathit{d}},\mathit{C},\mathit{h},\mathrm{and}\mathit{f}\left(\mathit{C}\right),$$

where

• $id$ is an identifier used to link all messages that are involved in the same execution of the protocol and is calculated as $id$ = $H(@A,@B,@SC,t_m,t_d,h)$;
• $t_m$ is the timestamp of the creation of the first message, i.e., the time at which protocol execution begins;
• $t_d$ is the deadline before which delivery execution has to be completed;
• C is the encrypted version of the message M with a symmetric key K, namely $C=E_K\left(M\right)$, along with any security parameter required for verifying the encryption;
• h is the hash of C, namely h = $H\left(C\right)$;
• $f\left(C\right)$ is A’s signature on the previous information, namely $f\left(C\right)$ = $Si{g}_A(id,t_m,t_d,h)$.

Once this information is received by B, they can decide which of the following actions to take:

• If they do not wish to receive the document, they simply do nothing. In this case, once the deadline $t_d$ expires, A observes that B has not agreed to receive the document.
• Otherwise, after verifying whether the information provided by the sender is correct and adequate, they proceed to Step 2.

• Step 2 (Accepting delivery). If B agrees to receive the delivery, they execute this step. It triggers the generation of an on-chain transaction by calling the $accept$ function defined by the smart contract. Consequently, it generates an on-chain transaction ($t{x}_{acceptB}$) that is signed with the private key of B, which corresponds to the public blockchain address $@B$:

$$t{x}_{acceptB}=accept(id,t_d,h,f\left(C\right))$$

Once this message is received by the smart contract, it verifies the provided information. If the deadline $t_d$ has not yet expired, the provided $id$ is correct and matches the received parameters, and the smart contract has not stored any other record related to $id$, the smart contract stores the data received from B, indexes them, links them to $id$, modifies the delivery state to accepted and finally triggers an event that contains the evidence. Otherwise, the smart contract does not perform any action and effectively ignores the request.

At this time, B has expressed their desire to receive the document, so A must provide the key K via Step 3 before the expiration of the deadline $t_d$.

• Step 3 (Publishing the key). After listening to the blockchain and detecting the event triggered by the smart contract after it has completed Step 2, A proceeds with the encryption key release. Once A is certain that the evidence carried by the blockchain event is correct and sound, A must provide B with the data required to obtain K by executing the $publish$ function from the smart contract. By the same method as that of Step 2, this step generates an on-chain transaction ($t{x}_{publishA}$) that is signed with the private key of A, which is related to the public blockchain address $@A$:

$$t{x}_{publishA}=publish(id,k)$$

where k contains the cryptographic parameters required by the recipient to retrieve K and decrypt the content in accordance with the selected cryptographic scheme (see Section 7.2 for more details).

Once the smart contract receives this message, it verifies its contents. If the deadline $t_d$ has not yet expired, the received transaction is signed by B, the provided $id$ matches, and there is already an entry stored for the identifier $id$ with the state accepted, then the smart contract modifies the execution status to delivered, stores the received information as evidence of publication and triggers a blockchain event that contains this evidence. Otherwise, the smart contract does not execute any action, so it ignores the incoming request.

When B is notified of the blockchain event, they can check the correctness of its contents, and if the contents are correct, they can recover K from the data provided in k (according to the cryptographic scheme used by A in Step 3 to protect K). Once K is available, it can be used to decrypt the delivered document ($M=D_K\left(C\right)$).

Notably, if the sender fails to execute Step 3 before $t_d$ expires, the delivery is not completed successfully. Nevertheless, this does not compromise fairness for either participant.

If the protocol ends successfully, both participants have the following evidence:

• A receives B’s acknowledgment of receipt, which was published on the blockchain as a result of executing the $accept$ function. This evidence indicates that B wanted to receive the document linked to C. Additionally, A possesses a blockchain transaction confirming the publication of the decryption key (signed with the private key associated with their blockchain address $@A$). Consequently, they can demonstrate that the key K corresponds to the key accessible to B, confirming that B was able to access the document contents promptly.
• B possesses C and k; hence, they also possess K, which enables them to access the document. In addition, B has the signature from Step 1 and the blockchain transaction generated by the $publish$ function (duly signed by the private key bound to the blockchain address $@A$). If B cannot decrypt the document with the key K (A provided an incorrect key), they can demonstrate to any relevant party that they were unable to access the document content, implying that A was dishonest.

• Get status. The two parties can always determine the status of the document delivery process by executing a read-only action. This action incurs no blockchain transaction costs, as it simply queries the smart contract for the delivery status identified by $id$, so the smart contract answers with undefined, accepted or delivered according to the state of the specified delivery.

6. Smart Contract Specification

The fair document exchange solution defined in Section 4 and Section 5 relies on the use of a public EVM-based blockchain, where a smart contract is used to manage document delivery between parties without the need for TTP intervention. In this section, we specify the smart contract code necessary for securely executing the process and storing the required evidence (the source code and test scripts for the blockchain-based protocol ensuring fair delivery with receipt are available at GitFront: https://gitfront.io/r/blobsec/ZzsjksXtwYgX/DocDelivery/ (accessed on 1 November 2024)). We use Solidity [27] as the programming language, as it was developed specifically for use on an EVM [14].

6.1. Data Storage and Indexing

A critical aspect of using a smart contract is identifying which data need to be stored and the most appropriate type of storage. All the data required for use in different functions of the smart contract are stored in the data structure defined in Listing 1 and are indexed by $id$. For this purpose, we use the EVM’s storage component (see Section 2). These data are provided by the document recipient, who calls the $accept$ function to confirm receipt of the message, and are verified by the smart contract before the message delivery status is set to “accepted”.

Three possible states of delivery are defined (see $State$ in Listing 1):

• $undefined$, which is the default value when the structure is created;
• $accepted$, which indicates that the recipient has successfully executed the $accept$ function; and
• $delivered$, which indicates that the sender has published the key for retrieving the delivered document.

Listing 1: Fair delivery of documents: data structure.

   As shown in Listing 1, the $data$ structure is defined to store the following information:

• $td$, which is the timestamp indicating the deadline by which the recipient can accept document delivery;
• $addrA$ and $addrB$, which store the blockchain addresses of the sender and recipient, respectively;
• $status$, which indicates the current state of document delivery.

The smart contract allows information to be stored for different instances of document delivery, and the delivery identifier $id$ is used to index the data structure associated with each delivery, which is defined as $docDelivery$. For this purpose, we use a mapping, which is a type of variable that enables us to represent a table that stores data as type–value pairs.

6.2. Main Smart Contract Functions

The smart contract defines three public functions (see Section 5), which can be executed by the different parties involved in the delivery process:

• $accept$: Given a delivery identifier, B provides the evidence necessary for proving that they are the recipient authorized to accept the delivery and confirms acceptance of the document delivery.
• $publish$: Given a delivery identifier, A provides the key for accessing the document once B has accepted the delivery.
• $getStatus$: Given a delivery identifier, the sender and the recipient can check the status of the delivery.

The smart contract performs various verifications when an entity calls any of its public functions. These include checking whether the calling entity is authorized, whether the entity is the sender or the recipient, and whether the deadline for executing the function has expired. To achieve this, the smart contract uses a special type of function, called a modifier, which is defined in Solidity. A modifier [27] is code that can be run before and/or after a function call and can be used to restrict access, validate inputs, etc. We define three modifiers for controlling by whom and when each of the smart contract functions can be executed:

• onlySender: verifies that the caller of the function is the sender of the document;
• validStatus: verifies whether the delivery status allows the calling function to be executed;
• deadline: checks whether, at the time of calling the function, the deadline has expired.

In addition, the smart contact provides the following private functions that are used internally by the public functions and modifiers:

• $validID$: This function is used by the $accept$ function to check whether the given delivery identifier is valid.
• $getCurrentTime$: This function is used by the $deadline$ modifier to provide the current time on the basis of the current timestamp of the block being mined on the blockchain.

6.2.1. Recording Evidence

Solidity provides a mechanism called events, which can exploit blockchain logs (see Section 2). Evidence sent by both the sender and the recipient can be stored on the blockchain, which offers a more cost-effective solution than storing evidence directly in the smart contract [14]. Events can also be used as a communication channel through which both the sender and the recipient can learn about delivery status updates. This use of events ensures that all participants in the delivery process remain aware of relevant information throughout the process.

Each time a function is executed, the contract emits an event reporting the result of the execution by calling the $Result$ event (see Listing 2); this result is stored in the transaction’s log (see Section 2). As shown in Listing 2, the event provides information about who called the function that generated the event ($account$), the identifier and current status ($info$) of the delivery, and the evidence provided by the caller of the function. The delivery status is encoded as an integer value, where the status undefined corresponds to the value of 0, accepted corresponds to the value of 1, and delivered corresponds to the value of 2.

Listing 2: Fair delivery of documents: Result event.

The use of events enables the sender and the recipient to know the status of the document delivery and the provided evidence in real time. However, we also implement the $getStatus$ function (see Listing 3) to enable both the sender and the recipient to check the status of the document delivery at any time. The $getStatus$ function does not change the status of the document delivery and therefore does not require a transaction to be added to the blockchain (see Section 9).

Listing 3: Fair delivery of documents: getStatus function.

6.2.2. Accept Function

Once the sender delivers the encrypted document to the recipient, the latter can choose to accept or reject the final delivery of the document. If the recipient does not wish to accept the delivery, they simply do not execute any function of the smart contract. However, if they choose to accept the delivery, they must call the $accept$ function (see Listing 4), providing all the information associated with the delivery identified by $id$: A’s blockchain address, the hash on the encrypted document, the timestamp of the delivery, the deadline for accepting the delivery, and the evidence provided by A (A’s signature on the off-chain message that informed B of the data associated with the delivery, as described in Step 1 (Off-chain message)).

Listing 4: Fair delivery of documents: accept function.

As shown in Listing 4, the smart contract verifies that there are no data associated with the identifier provided by the recipient (State.undefined) and that the deadline for accepting the delivery has not expired by using the functions $validStatus$ and $deadline\left(td\right)$, respectively. If these validations are successful, the smart contract generates the identifier value by following the steps defined in Step 1 (Off-chain message) of Section 5. To achieve this, it uses the information provided by the recipient as the parameters of the function call, the blockchain address of the smart contract, and the blockchain address of the entity that signed the function call. If the generated value matches the $id$ provided by the recipient, the smart contract stores the addresses of the sender and recipient and the deadline value $td$ in the $docDelivery$ structure and updates the delivery status to accepted.

In the end, the function emits an event indicating that B has accepted the delivery and containing the evidence provided by A to B during Step 1 (Off-chain message).

6.2.3. Publish Function

Once the sender receives the acceptance event from the recipient, they must provide the decryption key to the recipient. To accomplish this, the sender calls the $publish$ function (see Listing 5), passing as parameters the delivery identifier ($id$) and the cryptographic data required for recovering the decryption key (k). The smart contract employs the $onlySender$ modifier, which verifies that the blockchain address used to sign the function call matches the address provided by the recipient. Additionally, the contract checks that the status of the delivery associated with the provided identifier is accepted (modifier $validStatus$) and that the deadline has not yet expired (modifier $deadline$).

Finally, the function emits an event indicating that A has published the decryption key data and provides these data.

Listing 5: Fair delivery of documents: publish function.

7. Proof of Concept

In this section, we provide a proof of concept (PoC) implementation that shows how our solution works and manages evidence, demonstrating the deployment and use of the proposed protocol in a real-world scenario supported by a working blockchain network.

7.1. Selected Tools

As we explain in Section 9, there are costs associated with deploying and using a smart contract on a public EVM-based blockchain. To avoid these costs for the PoC, we used a testnet. A testnet is a simulated version of the main blockchain network that uses test currency instead of real money, where developers can safely test their distributed applications (dApps) without risking real money or impacting the main network.

We used the testnet Sepolia (web for Sepolia resources: https://sepolia.dev/, accessed on 1 November 2024), which is designed primarily for developers and provides space for precision testing of smart contracts and decentralized applications (dApps). In addition, Sepolia eliminates the bottlenecks of other testnets by providing unlimited cryptocurrency, Sepolia ETH (sepETH), for testing purposes. Additionally, we used MetaMask (MetaMask is a digital wallet designed for Web3, which is also known as a crypto wallet: https://metamask.io/, accessed on 1 November 2024) as a Sepolia-compatible crypto wallet to obtain sepETH from the Sepolia faucet (Sepolia faucet: https://github.com/eth-clients/sepolia, accessed on 1 November 2024). A crypto wallet provides a means of storing and managing the public and private keys needed to interact with the blockchain, such as by connecting to a dApp or sending and receiving cryptocurrency.

To perform cryptographic operations such as hashing data and performing signatures, we used eth-crypto (cryptographic JavaScript functions for Ethereum: https://www.npmjs.com/package/eth-crypto, accessed on 1 November 2024). Eth-crypto is a JavaScript library that provides cryptographic functions, such as signing and validating data and recovering the signer’s address and public key from a signature, for Ethereum. Additionally, to retrieve data from the blockchain, we used ethers.js (library for interacting with the Ethereum blockchain and its ecosystem: https://docs.ethers.org/, accessed on 1 November 2024), which is a JavaScript library that provides methods for interacting with the Ethereum blockchain and supports tasks such as querying transaction data and transaction logs.

We also used Remix IDE [28], which is a tool from the Remix Project that includes a set of plugins and libraries to assist with smart contract development, compilation, testing, and deployment. It provides numerous features that are beneficial in the development process: an intuitive user interface, real-time code analysis, extensive documentation and integration with MetaMask.

7.2. Protocol Execution Example

To show how the protocol for fair delivery works, we delivered the Ethereum Yellow Paper in PDF format (the Ethereum Yellow Paper in PDF format was downloaded from https://ethereum.github.io/yellowpaper/paper.pdf on 1 November 2024) from sender A to recipient B, showing the interactions of both parties with the blockchain. For this purpose, we created two MetaMask accounts to establish the scenario, along with their associated elliptic curve cryptography (ECC) public and private keys for signing messages and transactions (see

Table 2. Blockchain addresses for A and B, along with the corresponding pair of public ($Pu$) and private ($Pr$) keys.

$@\mathit{S}\mathit{C}$	0x24a835494a443e59eA034547e8447DF937924Df9
$@A$	0xBe3D99b191e7918dB2AbcA0C6155136BEDeC1a8B
$P{u}_A$	493880199bb22a3a8756df08a584ef958755ce963770aeb057e067dede72b5c2
	3ff72b2b919f5751d0c6bb3e633ae7180ddc34398e4ed752fe91607cef94daa7
$P{r}_A$	8b342123b0bb40bef5c53af35bd9eb41edb2beedcce4c58146ce2fd5e731c2c5
$@B$	0x277dCb7375b1DaC8Fc93E1C6698A9F9C8Cfdb3Dc
$P{u}_B$	d29237510009167eeb23f2dd3b5e757fe557488c4d0cdd537512601229ea50a
	fdcb9642f1634aa3d104f3310c0a70668083f8ebcfdc1822797ed9932f91628a1
$P{r}_B$	492771e52e46cd16a418bee40055fb04f6ca09d0c21ef9feaeb69104eb2ff4d1

): $@A$ is the sender’s account, and $@B$ is the recipient’s account. We also deployed the smart contract code on the Sepolia testnet, the blockchain address of which ($@SC$) is specified in Table 2.

Next, the values of the various parameters involved in the off-chain message sent from A to B were calculated (Step 1 of the protocol). For this purpose, we chose ECC as the public key cryptographic scheme, along with the elliptic curve integrated encryption scheme (ECIES) [29] to encrypt the message. This scheme enabled us to derive a symmetric key (K) from B’s public key and the message to be encrypted (M), encrypt the message ($C=E_K\left(M\right)$), and generate an ephemeral public key. This ephemeral key was sent by A to B in the third step ($publish$ function), enabling B to use his own private key to recover the symmetric key (K) and thus decrypt the message. The encryption algorithm considered was AES-256 in CBC mode, which requires an initialization vector $IV$. To obtain h, the SHA-256 hash function was applied to C (resulting in a 256-bit hash value). A calculated C, h, $id$, and $f\left(C\right)$ and chose values for $t_m$ and $t_d$.

Table 3. Values of the parameters that are required for the execution of blockchain-related transactions.

Parameter	Value
M	Ethereum Yellow Paper in PDF format
$id$	0xa4d656f44b2b91812bf2ffd0f61e3c581a487c37ce284c6b3f5f98c9964ed238
h	0x62d296b37a4ff302e79ebe54065db5089f0b70891cec2f8013f7cb08a0d7e56d
$t_m$	1721282400 (Thu Jul 18 2024 06:00:00 GMT+0000)
$t_d$	1721887200 (Thu Jul 25 2024 06:00:00 GMT+0000)
$f\left(C\right)$	0x394b7a6ef945456db455b63c6107c30cf6b2ac2c75183038a194f0711377b3bd
	1bbf321e2e056a919d4fa4d933aa23da998d7d68cc6473646124281b357c4b861c
$IV$	0x1d8b0f92c9f19097cefb5367de1a740d
k	0x035821728754dc3b2f7c6b5632fb3543270b9b61585b92610e662173a9f5b801ce

shows the calculated values of all the required parameters (all the scripts used to generate these values are available at https://gitfront.io/r/blobsec/9RBsqW2vpY9D/PoC-Doc-Delivery/ (accessed on 1 November 2024)).

After A sent the message in Step 1 to B ($id$, $t_m$, $t_d$, C, h, and $f\left(C\right)$), B accepted the delivery from A by calling the $accept$ function of the contract (Step 2 of the protocol). The execution of the $accept$ function returned the identifier of the transaction ($Tx$) in which $accept$ was published on the blockchain (see

Table 4. Identifiers for the transactions ($Tx$) in which the deploy, accept, and publish operations are incorporated into the blockchain.

Transaction Hash ($\mathit{Tx}$)	Value
deployment	0x65d56381b58cbc26df5c83be993ba2e78fa9ed486fdea61bac4a7464e7255ec0
$accept$	0x8892950c27da7ec77e4c01efb879a27116d2539aefd4aedc67271f7a5ac145a7
$publish$	0x95ef60231f905bdd470a573d32a667142b04ba6b1379ece1f38c8e08575ca5de

).

Using the Sepolia Testnet Explorer and the transaction hash, we accessed the transaction generated as a result of acceptance. Figure 4 and Figure 5 show the data recorded on the blockchain, such as the input data (see Figure 4) and the data stored in the log associated with the transaction (see Figure 5). The transaction log contains the values recorded as the transaction event (see Section 6.2.1), such as $id$ ($identifier$), the delivery status ($info=1$ corresponds to accepted), and the proof ($evidence$), which in this case was the value of $f\left(C\right)$ (see Table 3).

Once the delivery was accepted by B, A called the $publish$ function to provide the necessary data for B to obtain the delivered document. Similar to the execution of the $accept$ function, the execution of the $publish$ function returned the identifier of the transaction ($Tx$), where $publish$ was included in the blockchain (see Table 4). Figure 6 and Figure 7 show the input data included in the function call (see Figure 6) and the log associated with the transaction (see Figure 7). The transaction log contains the data in the event notification (see Section 6.2.1), that is, the delivery $id$ ($identifier$), the delivery status ($info=2$ corresponds to delivered), and the proof ($evidence$), which in this case is the value of k, the ephemeral public key that was obtained from the ECIES process and was needed to decrypt the document (see Table 3).

Although we used the transaction hash to show the content published on the blockchain, for analysis purposes, A and B can directly receive the information on the events by configuring the receipt of the events associated with a specific $id$ issued by the contract. Thus, A and B receive the information published in the transaction logs and learn the status of the delivery in real time. In addition, all the data associated with the transaction, including the input data and logs, are published on the blockchain, making the process auditable.

8. Security Analysis

Next, we evaluate compliance with the security requirements of our proposal.

• Effectiveness. There is no TTP involved in the execution of the protocol. Therefore, the protocol meets the effectiveness requirement.
• Timeliness. The protocol ends when or before the deadline $t_d$ expires. Therefore, the protocol meets the timeliness requirement.
• Nonrepudiation. The sender provides a signature on the encrypted document ($f\left(C\right)$) and a signature on the data required to recover the decryption key (k recorded on the transaction log), which prohibits her from denying having sent this information. The recipient provides a signature indicating a willingness to accept the document (recorded on the blockchain using the $accept$ function), which prohibits him from denying having agreed to receive the document. Therefore, the protocol meets the nonrepudiation requirement.
• Confidentiality. The sender sends the document encrypted with a secret key K ($C=E_K\left(M\right)$) and publishes the data for recovering the secret key on the blockchain so that only the recipient can recover it via his private key. Therefore, the protocol meets the confidentiality requirement.
• Fairness. Next, we analyze the different situations that can occur.

• Situation 1. Only Step 1 is executed. The sender does not have an acknowledgment of receipt, and the recipient does not have the document.
• Situation 2. Steps 1 and 2 are executed. The recipient does not have the content of the document, and the sender does not have an acknowledgment of receipt (they have evidence of the sender’s willingness to accept but do not have evidence of key publication).
• Situation 3. All steps of the protocol are executed. In this situation, we distinguish two possible cases: the sender has published correct data for recovering the decryption key (Situation 3.1) and the sender has published incorrect data for recovering the decryption key (Situation 3.2).

  (a)

  Situation 3.1. The recipient has the document since they have the encrypted document (Step 1) and the decryption key (Step 3). The sender has the acknowledgement of receipt since they have the recipient’s acceptance (Step 2) and proof that they published the data for recovering the key (Step 3).

  (b)

  Situation 3.2. The recipient has a key that does not allow them to access the content of the document, but they have the evidence to prove that this is the case and that therefore they have not received the document. The sender has the recipient’s acceptance (Step 2), but the evidence posted in Step 3 shows that they were dishonest and therefore do not have evidence that they delivered the document.

• The conclusion of the analysis is that the protocol meets the fairness requirement (the recipient receives the document and the sender obtains the receipt, or neither party receives either).

9. Cost Assessment

In this section, we examine the suitability of employing an EVM-based public blockchain for our delivery-based proposal. The use of a public blockchain incurs costs: whenever a sender or a recipient interacts with the smart contract deployed on the blockchain, fees must be paid for executing the function and recording it on the blockchain. These fees contribute to maintaining the security of the blockchain network and vary depending on factors such as the complexity of the operations to be carried out, the transaction speed needed, and the demand from other users of the blockchain. Therefore, more complex operations and shorter transaction times result in increased costs for blockchain-related processing. Consequently, it is essential to analyze the price that users must pay to use the proposed solution.

9.1. Gas Cost

In Section 6, we specified the smart contract that can be deployed and used on any EVM-based blockchain. This smart contract was programmed in the Solidity language [27] and deployed via the Hardhat network, which is a local Ethereum network node designed for development [30]. This methodology allows for the deployment, testing, and debugging of the smart contract code in a local environment without incurring real-world expenses.

On an EVM-based blockchain, the transaction execution cost is measured in gas units; for example, the basic cost for creating a smart contract is approximately 32,000 gas units, as stated in Ethereum’s yellow paper [14]. However, the total cost of deploying the smart contract varies depending on the size of the deployed code, which is measured in bytes [14]. The cost for deploying or calling a function of the smart contract, measured in gas units, remains fixed regardless of the environment in which the smart contract is executed, meaning that the technical specifications of the hardware or software used to test our proposal do not impact the cost.

Various utilities are available to assist in determining the gas costs associated with executing each function. For this analysis, we used the hardhat-gas-reporter plugin (Gas metrics for method calls and deployments on EVM-based blockchain networks. Available at https://www.npmjs.com/package/hardhat-gas-reporter and accessed on 1 November 2024), which enables the straightforward generation of gas consumption reports for both contract deployment and the execution of each of the contract functions.

Table 5. Cost in gas units of our proposed solution.

	Total Cost	(Deploy)	$\mathit{accept}$	$\mathit{publish}$
Our proposal	522,676	391,165	94,896	36,615

shows the costs (measured in gas units) of the two main functions of our solution ($accept$ and $publish$) and the cost of deploying the smart contract. The cost of deploying the contract in the blockchain network is higher than those of the other functions. However, once the smart contract is deployed, it can be used multiple times for different instances of delivery for receipts. The $accept$ and $publish$ functions must be called by B and A, respectively, in each protocol execution, and this cost is fixed for each delivery regardless of the type or size of the document to be delivered. The $getStatus$ function does not change the state of the blockchain; thus, it does not incur an economic cost.

The cost, measured in gas units, can be used to evaluate the complexity of the operations involved in each function of the smart contract. This metric is platform-agnostic, making it an ideal measure for comparing different solutions, regardless of the EVM-based blockchain on which they are executed. By using gas as a standard unit, we can objectively assess and contrast the efficiency and performance of various smart contract implementations.

Next, we compared our proposed solution with the solutions analyzed in Section 3. Among the reviewed solutions, we considered those that do not require a TTP and can be deployed and used on EVM-based blockchains [16,17,20,21,23,24]. The solutions requiring a TTP were excluded because their costs were not considered in the analyzed publications. In the comparison, the total cost of successfully executing each considered protocol was calculated. Protocol execution was considered successful if the recipient received the document (email, notification, etc.) and if the sender had proof of delivery. Two different scenarios were evaluated:

• First delivery: In this scenario, the total cost was evaluated, including both the deployment of the smart contract and the execution of the functions necessary for delivery.
• Next delivery: In this scenario, the cost was evaluated under the assumption that the smart contract had already been deployed (if the solution allows it) and that only the functions directly related to fair delivery were executed.

Figure 8 summarizes the costs associated with each solution for the two defined scenarios. The total cost of our proposal for the first delivery scenario was significantly lower than those of other solutions, especially those with high deployment and execution costs such as [20,21]. Solutions [16,17,20,23] incurred the same costs in both scenarios because the smart contract managing the delivery had to be deployed for each protocol execution. This contrasts with solutions [21,24] and our own. Although the authors in [21] reduced the cost of successive deliveries, their proposal remains the second most expensive solution.

In summary, compared with the other solutions, our proposed solution achieved the lowest costs in the first delivery scenario, with cost reductions ranging from 38% to 90% and averaging 62%. In the successive-delivery scenario, the cost reductions compared with those of other proposals varied between 6% and 95%, averaging 75%, except against [24] when executed optimistically, where no blockchain-associated costs were incurred. Therefore, we can conclude that our proposal offers an efficient solution for both initial deployment and subsequent deliveries, outperforming the analyzed proposals.

9.2. Cost in Fiat

The cost, measured in gas units, offers valuable insights into the complexity of operations and allows for the comparison of different solutions deployed on an EVM-based blockchain (as explained in Section 9.1) since this metric remains unaffected by the price volatility of the related cryptocurrency. However, the economic costs of calling the $accept$ and $publish$ functions can fluctuate daily because of changes in the cryptocurrency’s price. Consequently, the final cost of executing a function is determined by multiplying the number of gas units required by the gas price. The gas price is the amount of Wei (Wei refers to the smallest denomination of the cryptocurrency used in the EVM-based blockchain. A unit of the currency used in the blockchain corresponds to ${10}^{18}$ Wei) that a user is willing to pay for each gas unit.

Ethereum offers a robust and established platform for the execution of smart contracts, making it a preferred choice. However, the price of its cryptocurrency is higher than that of other solutions. It would be beneficial to evaluate the cost of our solution by comparing Ethereum with other blockchains. Among other EVM-based blockchains, Polygon is specifically designed to improve the scalability of Ethereum, thereby reducing the costs associated with executing smart contracts. In addition, Polygon is a popular layer-2 blockchain (“A layer-2 solution builds on layer 1 and relies on it to finalize its transactions.” Source: https://academy.binance.com, accessed on 1 November 2024) that has the highest number of deployed smart contracts, namely approximately 160 million (number of deployed smart contracts from 1 January 2023; source: https://dune.com/queries/, accessed on 1 November 2024). Therefore, to determine the cost over time of using a public EVM-based blockchain for our proposed fair delivery receipt method, we analyze the potential cost reduction associated with the use of Polygon in front of Ethereum.

To determine the total cost in fiat currency, we collected the daily average price per unit of gas (measured in Wei) and the daily exchange rate between the cryptocurrency used by the blockchain (MATIC for Polygon and ETH for Ethereum) and the US dollar (utilizing the dataset provided in [31,32]). The final cost of executing our solution was computed by multiplying the gas units (calculated in Section 9.1) by the daily average gas price.

Figure 9 shows the average cost of our solution in 2024 (1 January to 16 July). Similar to the gas evaluation case, we considered two scenarios: first and next delivery. As shown in the figure, our proposal has a cost of less than USD 0.23 for the first delivery and less than USD 0.045 for subsequent deliveries in Polygon, whereas for Ethereum, these values increase to approximately USD 183 and USD 46.

Table 6. Comparing the costs (in USD) of our solution using both Polygon and Ethereum: Maximum, minimum, and average (with the standard deviation) costs (in USD) required for each blockchain network.

	Polygon		Ethereum
	First Delivery	Next Delivery	First Delivery	Next Delivery
Avg.	0.053	0.011	41.21	10.37
Max.	0.226	0.045	183.51	46.17
Min.	0.013	0.002	5.875	1.478
Std.	0.037	0.007	34.08	8.577

summarizes the statistics of the cost metrics. For example, when the contract is deployed (first delivery), our solution has an average cost of USD 0.053 in Polygon (USD 41 in Ethereum). For subsequent deliveries, the average cost drops to USD 0.011 in Polygon (USD 10 in Ethereum). Considering the minimum values, the cost in Ethereum is reduced to approximately USD 1.4, but it also reaches a maximum of USD 46, which is a price that can be considered very high, especially since there are alternatives that allow its cost to be reduced; therefore, if our solution is deployed on Polygon, its cost can be reduced by 99% compared to its cost on Ethereum.

9.3. Trade-Off Between Cost and Delay

The economic viability of the proposed solution was assessed on the basis of the average cost of executing each function on the blockchain. However, the latency introduced by the use of the blockchain is another key factor that can affect the overall cost.

When a transaction is published to the blockchain, there is both a cost and a delay before it is confirmed and added to the chain. This delay is influenced by numerous factors. Network congestion is a primary factor; a high volume of pending transactions increases competition for inclusion into the next block. The fee offered by users is a critical determinant because miners prioritize transactions with higher fees, as these provide better financial incentives. Therefore, to minimize delays, users can offer higher fees to encourage miners to include their transactions earlier.

We used the data provided in [31] to obtain the required gas price for the same period as in Section 9.2. Figure 10 shows the daily costs of executing the $accept$ and $publish$ functions of our proposed solution. The maximum price to be paid by the recipient is approximately USD 0.034, while the cost for the sender is approximately USD 0.013. In this case, the transaction publication time for both the sender and the recipient is between 5 and 10 s, which can be considered both fast and cost-effective. Furthermore, the deadline can be adjusted depending on the scenario in which the solution is used and the estimated publication cost at any given time.

Understanding the delay in publishing transactions to the blockchain is critical for applications with strict time-sensitive requirements. While in some scenarios, the delay may not significantly impact functionality, in other use cases, such as real-time financial trading, supply chain tracking, and automated smart contract execution, timeliness can be critical. In these situations, it is essential to analyze the expected delay to ensure that the blockchain meets the requirements of the application.

10. Conclusions

In this paper, we propose a secure and fair protocol based on blockchain for delivering a digital document in exchange for a receipt between a sender and a recipient. This generic scenario arises in many contemporary use cases, such as certified electronic mail, certified notifications, and registered e-delivery. This scenario requires delivering a document to the recipient with confidentiality (only the sender and the final recipient can know its contents) while ensuring fairness, preventing either participant from misbehaving during the delivery process.

By reviewing the literature on this topic and focusing on solutions that utilize blockchain technology, we find that no solution meets all the necessary requirements. Specifically, existing solutions fail to provide either confidentiality or fairness; this is sometimes caused by issues with deadline expiration. Moreover, some methods rely on centralized entities that can be effectively considered trusted third parties (TTPs), which may lead to potential bottlenecks or security breaches.

To address these issues, we present a secure and fair blockchain-based solution that meets all security and privacy requirements and protects both participants from misbehavior, as discussed in the security analysis. To demonstrate the technical and economic viability of our solution, we first define and detail the smart contract specifications for EVM-based blockchains. On the basis of this comprehensive smart contract specification, we provide a proof-of-concept (PoC) implementation and a protocol execution example to show how our solution works in a real blockchain network, thereby demonstrating its technical feasibility.

Finally, according to the exhaustive cost assessment, we assert that our protocol is economically viable when public blockchains are used and offers better performance at significantly lower costs than previous solutions do. In fact, our solution not only significantly reduces the costs associated with the deployment and execution of smart contracts for document delivery but also offers a scalable and efficient solution for EVM-based blockchain environments. By not relying on a TTP or any centralized entity, it provides greater transparency and security, better aligning with the decentralization principles of blockchain technology.

Future work will focus on extending this solution to multiparty scenarios in which multiple recipients must receive the same document.