Transferable channels for fair micropurchases

Abstract

The development of e-commerce applications for small-value transactions introduces significant security and privacy challenges. Micropurchases, that is, commercial operations involving micropayments, offer a practical solution that balances efficiency and security for these transactions. The increasing demand for this payment approach, especially with technologies such as the Internet of Things (IoT), highlights the need for innovative solutions. This paper presents a novel micropurchase protocol utilizing a new type of channels, termed transferable payment channels. The proposed protocol, managed through smart contracts, facilitates fair and equitable exchanges between minimal monetary units ($\mu$-coins) and desired goods or services, enabling efficient low-value payments. Transferable payment channels enable off-chain transactions, reducing the reliance on on-chain transactions to achieve essential security features and ensure fair exchanges without a centralized intermediary or Trusted Third Party (TTP), commonly employed in traditional payment systems. The protocol outlines the processes for making purchases, handling payments, and incorporating functionalities for the transfer and reuse of payment channels by both customers and merchants. Additionally, it specifies procedures for merchants to redeem earned $\mu$-coins and for customers to refund unused $\mu$-coins. This comprehensive set of functions makes the protocol fully functional and highly efficient for micropurchases. By introducing transferable payment channels and minimizing reliance on centralized intermediaries, this work significantly advances the security and efficiency of micropayment systems. The proposed protocol has been implemented and analyzed for both security and performance.

1 Introduction

Electronic commerce (e-commerce) is continuously evolving, introducing new applications and services to meet the demands of the digital era. One such application is the facilitation of micropayments or microtransactions, allowing the seamless exchange of small amounts of money for low-cost goods or services. Micropayments can range from fractions of a cent to $10 or $20, depending on the functionalities of the system in place.

Micropayments present distinctive functional and security requirements within the realm of electronic payments. The paramount requirements pertain to the efficiency and security of the system. Striking a balance between these two attributes is challenging, given that efficiency and low transaction costs are imperative due to the nominal values of each micropayment. Additionally, users often demand real-time execution to ensure the system’s profitability for merchants and customers. Simultaneously, robust security and privacy measures are essential to mitigate financial risks and safeguard customer identities.

Examples of micropayments abound in applications dealing with digital goods and services, encompassing digital newspapers, music, books, location-based services, virtual presents, and more. Recent expansions into areas such as the Internet of Things, web advertising, and gaming underscore the versatility of micropayments. Primarily, these services require token exchanges between actors, [1, 2].

The emergence of payment systems based on cryptocurrencies, utilizing cryptographic principles and decentralized databases like the blockchain, has gained prominence. While cryptocurrencies offer advantages over traditional fiat currencies, such as enhanced security, they are not without limitations. Blockchain transactions, despite their traceability, are not completely anonymous. Users, however, maintain a degree of anonymity through the use of pseudonymous addresses.

To address efficiency concerns, users can conduct instant transactions outside the blockchain via payment channels. These channels facilitate instant transactions with cryptocurrencies, with lower costs, overcoming scalability and high cost issues associated with blockchain operations. Payment channels act as an excellent layer 2 solution, mitigating the direct dependency on the blockchain for each payment.

The use of blockchain and cryptocurrencies for micropayments provides the benefit of smaller transaction values compared to fiat currencies. For instance, BTC can be divided into eight decimals, and ERC20 tokens into eighteen decimals, surpassing the limited two decimals of fiat currencies.

This paper introduces a novel protocol for fair micropurchases that uses micropayment channels to ensure secure and private management of payments for products or services. The protocol guarantees the equitable exchange of goods or services against microcoins, without relying on a centralized intermediary or Trusted Third Party (TTP), which is commonly employed in traditional payment systems through brokers or banks.

Following this introduction section, the paper is organized as follows: Sect. 2 provides an overview of the current state of the art. Section 3 outlines the contributions of our research. Section 4 presents the system overview, while Sect. 5 details the compulsory phases of the protocol and Sect. 6 explain the additional phases that enhance protocol efficiency. Section 8 describes the database implementation and the corresponding smart contracts. Then, the analysis of the main properties is presented in Sect. 9 and Sect. 10 evaluates the implementation execution costs. Finally, Sect. 11 concludes the paper and presents future work lines.

2 State of the art

This section analyzes the related work of the proposal presented in this paper. In [3] we presented an efficient and secure micropayment scheme, with a fair exchange between a coin and a desired good or service, claiming the anonymity and the impossibility of customer tracking. The present article improves that proposal, taking advantage of the features provided by the blockchain technology.

Protocol for the fair exchange of microcurrencies must be evaluated differently from protocols for fair payment with cryptocurrencies due to the small amounts involved in each operation. Consequently, the set of ideal properties for micropayments, even those that do not rely on cryptocurrencies, differs significantly. A comprehensive list of security requirements and functional features for an ideal micropayment system can be found in [4] and [5]. In [4], various properties related to the balance between security and efficiency in micropayment systems are discussed, including security features and also functional features as the following::

• Financial Risks Control: The assumed risks must be controlled even if security measures are limited to minimize costs.

• Partial Financial Risks Control: Micropayment systems can allow for the loss or theft of small amounts of money.

• Low Transactional Costs: Each microtransaction’s cost must be a small fraction of the amount transferred. Achieving low transactional costs.

• Use of Coins: Security algorithms can be implemented more efficiently if coins are designed for specific services or providers rather than for general purposes.

Most functional features focus on efficiency, cost, and theft minimization, often in opposition to stringent security and privacy requirements like strong fairness or anonymity. An ideal micropayment system should be secure, offline, anonymous, untraceable, and have low storage, computational, and transactional costs. Moreover, it must ensure a fair exchange between the coin and the purchased service, controlling financial risks. As a result of this trade-off, the possibility of loss of small quantities is acceptable in a micropurchase scenario, especially when this loss is subjected to financial risk control and the protocol is able to discourage microfraud.

The idea of using coupons to perform micropayments in purchases was included in [3]. They are used in a protocol that involves customers, merchants and a central entity acting as a Bank. The costumer uses a coin to obtain services or buy products offered by merchants and the Bank manages merchants and customers bank accounts and also the functions to issue, deposit, refund and exchange coins. The system makes use of anonymous and untraceable coins. These coins are used in a fair exchange between different actors of the system, customers and merchants, to pay for the desired small-value good or service. The system detects and avoids several kinds of fraud: double-spending, overspending, forgeability and moreover allows customers to request a secure refund for partially used or unused coins. However, the customers cannot use the refund subprotocol to fraudulently refund a single spent coupon. The system is completed with a resolution subprotocol that allows the merchant to deposit the received coupons even when the customers are trying to cheat, avoiding the loss of money, including very small amounts. The coins used in the system are specific to pay a single merchant, they are anonymous and untraceable and payments made with different coins are unlinkable and customers can refund the partially spent coins.

The proposal in [3] defines five mandatory protocols: setup, service request, withdrawal, spend and deposit, and two more protocols which are optional depending on the implementation and the use of the coins (anonymous exchange and refund). The procedure followed by the protocol is as follows:

• 1. A coin is build around a partially blind signature scheme [6], so it has three key parts: verifiably public data (called common data), data hidden to the signer (blind data) and the signature over both parts. On one hand, common data is public and it should be agreed by the signer and the requester during the service request protocol. On the other hand, blind data contains some information hidden to the signer, the coin identifier. Finally, the signer signs both parts and outputs a coin made by a partially blind signature in the withdrawal protocol.

• 2. Then, the customer keeps secret a list of elements obtained by the use of the hash chain procedure. These elements are called coupons and they will be used to pay services to the merchant using the spend protocol. The number of coupons is 2c+1: 2c coupons available to use along the spend protocol and one more coupon called root coupon which is used to link the chained list of coupons to the partially blind signature. Regarding these 2c coupons, we can distinguish two types of them: payment coupons and proof coupons. A payment coupon (odd index) has monetary value and a proof coupon (even index) is used together with a payment coupon in order to validate it.

• 3. When the merchant has some coupons received from the customer through the spend protocol, he can use the deposit protocol to request credit in exchange of these coupons. To do so, he must prove that he knows how the other half of the coin identifier was made, revealing a secret proof.

• 4. The system includes two optional protocols, anonymous exchange and refund protocols which can be implemented or not depending on whether they are considered necessary or not. The aim of both protocols is to provide the customer the ability to request a reimbursement of unused coupons.

• 5. Each protocol can only be used exclusively during a specific period between defined time marks. These time marks are also useful from the point of view of efficiency because when a coin is expired, all parties can erase its related data. These time marks and intervals are included inside the common information of each coin.

The protocol presented in this paper inherits some concepts presented in [3]. The idea of a coin formed by coupons, the duality of the coupons and the fair exchange of coupons for goods or services. However, the protocol proposed in this paper represents a total new approach since this concepts are used now in a blockchain environment. No central entity is required and the system makes use of cryptocurrencies, smart contracts and payment channels.

There are several other papers related with the proposal presented in this paper. In [7] two micropayment protocols were presented: PayWord and MicroMind, which make use of off-line hash chains, feature that provides the reduction of the number of transactions, combined with some public-key operations to provide some low level security. In addition, [7] provides a second protocol, MicroMint, which was designed with the objective to provide reasonable security at very low cost. This early approaches were very useful, however they do not take advantage of the blockchain technology.

With the emergence of the Bitcoin blockchain network and its high fee transaction costs, there is a need to generate micropayment channels over blockchain networks. As expected, there are a lot of proposals using the Bitcoin network. Starting with the Lightning network [8], where the transactions are made using Payment Channel Networks (PCN) that reside outside the blockchain, where the transactions performed on the channels are verified afterwards on-chain .

These kinds of solutions are named Layer 2 protocols, and they aim to improve the scalability and efficiency of the main blockchain (Layer 1). Layer 2 payment protocols create PCNs in a decentralized network using smart contract functionality in the blockchain to enable instant payments across a network of participants. It allows for transactions to be conducted off-chain, meaning they do not need to be recorded on the blockchain until the participants are ready to close the channel. More examples of this approach are Plasma chains,¹ these are a framework for creating scalable applications by utilizing child chains (smaller blockchains) that operate alongside the main Ethereum blockchain. These child chains handle most of the processing work and only periodically report to the main chain. Also Optimistic Rollups² are another example of Layer 2 protocols that involve bundling multiple transactions into a single batch which is then committed to the Ethereum main chain. This reduces the amount of data that needs to be stored and processed by the blockchain. Arbitrum³ is an Optimistic Rollup solution that allows Ethereum smart contracts to scale by enabling them to run on a second layer while using the Ethereum blockchain to record the results. However, the security of these solutions relies on the assumption that users will actively monitor the network and submit fraud proofs if they detect incorrect transactions, which may not always happen in practice.

Moreover, Layer 2 protocols introduce latency that significantly impacts multihop payment channels. This added latency makes micropayment solutions less feasible. For instance, in the Lightning Network, if a user wants to send money to another user (receiver) via a multihop connection, the payment requires a blocking protocol. This protocol necessitates that each channel waits for all preceding channels, closer to receiver, to update before proceeding. Consequently, the payment latency increases linearly with the number of hops. In the schema proposed in this paper, we present different features to help and ensure that funds are efficiently transferred within the micropayment network (e.g. the Channel handoff feature).

Sidechains are also created to address scalability issues of the main blockchains. Sidechains are separate blockchains that run parallel to the main blockchain (e.g., Ethereum or Bitcoin). They can have their own consensus mechanisms and are interoperable with the main chain through two-way pegs, allowing assets to be transferred between chains. Polygon is a multi-chain system similar to Polkadot, Cosmos, or Avalanche but designed to be compatible with Ethereum. However, there are some security concerns about sidechains because they typically have their own consensus mechanisms, which might be less secure than the main chain. They can be more vulnerable to attacks if they are not properly secured. In addition to that, sidechains have interoperability challenges since ensuring seamless and secure interoperability between the main chain and sidechains can be complex and fraught with potential issues. Another drawback related with some sidechains is that they may be operated by a limited set of validators, leading to potential centralization concerns.

Following this need of payment channels over blockchain networks, [9] presents a distributed robust protocol (named RobustPay) which achieves robustness (generating two or more node-disjoint payment paths, to fulfill individual payment requests), efficiency and distributedness. These features are achieved by the use of an adapted version of the Hashed Time-Lock Contract (HTLC) protocol in PCNs.

Also, there are some probabilistic payment system proposals as RandPay [10]. Systems that do not ensure the success of the payment, as they strongly depend on the probability that the ticket is the winner. RandPay is a blockchain protocol developed in Emercoin, based on the use of “lottery tickets” as micropayments.

Another probabilistic payment system is proposed in [11], which proposes the introduction of a Transferable Scheme and a Proportional Fee Scheme. In this approach, when a user has received a ticket from a payee, he can transfer it to another user, but he has to previously sign it with his wallet address.

Besides, there are some different approaches using the Ethereum network. Starting with Raiden network [12], the Lightning equivalent network, which provides instant transactions and aims to allow for multihop transfers via a network of bidirectional payment channels. And its younger brother, the $\mu$-Raiden network based in micropayments between two parties. ElSheikh et al. in [13] presents the PayWord protocol [7] deployed in Ethereum where, as it has been introduced previously, makes use of hash chains that represents the different coins to spend in the channel and also requires the use of digital signatures, cryptography operation that highly increases the gas costs of the blockchain.

Shortly afterwards, in [14] Galal et. al present an improvement of [13], where the use of hash chains are substituted by a variant of Merkle trees that contains n payment proofs generated by the customer user. In each payment, the next proof is provided to the merchant user. These proofs are necessary to finally release the funds. This proposal also provides a dynamic refund extension, which allows the customer to add more funds to the channel.

Some papers as [15,16,17] propose improvements to state channels systems used as payment channels. [15] achieves better efficiency using a method for connecting channels in contrast to the use of the routing transactions technique. [16] proposes a reduction of the probability of the financial damage caused by fork attacks, using a third party that allows the user to go off-line. Finally, [17] proposes the use of off-chain payment channels on the consortium blockchain.

In order to achieve a recovery of the channels approaching the end of liquidity, [18] proposes OPRE (OPtimal off-chain REcovering of payment channels), which recovers the maximum number of nearly exhausted channels in a PCN, transforming the remaining channel tokens into cheaper off-chain payments in respect to those initially defined. In addition, the OPRE protocol provides a privacy preserving version design, which does not require a Trusted Third Party (TTP).

Therefore, current proposals are generally centered on the need of payment channels that allows a desired transfer of money between two users. In addition, the use of digital signatures on relevant information represents large costs on the blockchain. Moreover, there are some proposals using hash chains, but to achieve the needed security they also have to use digital signatures on the data.

Furthermore, some above approaches, as the lottery tickets, do not ensure the reception of any payment, because they are probabilistic systems.

Finally, the proposals that only use payment or micropayment channels do not ensure the reception of the good or service which leads the exchange, the fair exchange feature will only be obtained by a channel for fair micropurchases, as the protocol presented in this paper.

3 Contribution

In this paper we present a new protocol that represents an improvement of the protocol presented in [3], where an efficient and secure system for micropurchases ensuring customers privacy were presented.

The main improvement is the introduction of blockchain-based channels that allows the use of cryptocurrencies in a fair exchange between customers and merchants in purchases of goods or services. The proposal is particularly useful in those services where payment is made based on the amount of data obtained or the duration of access to the service.

The system most important features are:

• Avoiding double spending and overspending. The system is protected in front of forgery and it also ensures a fair exchange between the money and the purchased product or service.

• All the off-chain messages related with the management of the channel are exchanged using encryption to ensure their confidentiality.

• The protocol ensures that the merchant functions can only be executed by the receiver of the payment channel without the need for on-chain digital signatures.

• The system ensures the privacy of the users, since the protocol does not store any personal data. In order to identify them, the protocol only uses their wallet addresses.

• In addition to basic operations, the protocol also allows the reuse of own channels and the transfer of funds between channels or from a channel to a wallet address, during the Refund or Redeem periods, depending on whether the user represents the customer or the merchant respectively.

Finally, to summarize our contribution, we can state that the protocol ensures that the merchant has provided the purchased good or service before being able to earn the corresponding money, so the proposal to describe a complete fair micropurchase system based on the use of blockchain micropayment channels. In addition, the transfer and reuse of channels makes the proposal very efficient.

4 System overview

In this section we will present the notation used in the protocol, a high level system overview as well as the actors involved in it.

Fig. 1

Payment channel life cycle

4.1 Actors

The two principal actors involved in the purchase protocol are the customer C and the merchant M. In addition, the protocol is controlled by a smart contract (SC) deployed on the blockchain, which regulates the operations over the payment channel between C and M. Since the protocol describes a transferable channel system, it can also involve multiple merchants. For this purpose, the second merchant involved in the channel transfer will be called N.

4.2 Notation

Table 1 shows the notation used in the protocol description.

Table 1 Notation

4.3 Operation

The proposed protocol has several phases, that will be described in Sect. 5. Briefly, the protocol operates as follows:

• First of all, the customer selects the merchant where she wants to buy the service or product.

• Next, if the merchant accepts the customer request, the opening of the channel is carried out.

• Then, there is a period where the involved parties can execute the purchase operations, that is, payments and deliveries of the products or services. We will call $\mu$-coins to the monetary units used in this phase.

Figure 1 shows the channels life cycle, with the different execution periods. After the users have completed all the desired purchases (expiration time: $T_{Exp}$), the channel enters the Redeem period, where the merchant can deposit the received $\mu$-coins to his address balance, or alternatively, he can transfer the channel. In a channel transfer, the merchant can transfer the received $\mu$-coins to another channel without any fund transfer to the blockchain. We call Channel Handoff to this feature, where the merchant becomes the customer in this new channel. The Channel Handoff property enables a user, who acts as a merchant in one payment channel, to seamlessly become a customer in a new payment channel by transferring funds directly from one channel to another. This eliminates the need to redeem the funds to the user’s wallet before initiating transactions in the new channel, resulting in increased efficiency and reduced transaction costs. The Channel Handoff ensures that funds are efficiently transferred within the micropayment network, enabling continuous and streamlined transactions.

Finally, after the timeline where the merchant can redeem or transfer the channel, there is a refund timeline where the customer can deposit the non used $\mu$-coins or, alternatively, he can recover the channel and reuse it with another merchant.

We have divided the description of the protocol in two parts. In the first one we explain those subprotocols that represent the minimum phases that must be executed by the involved parties to use the system. This way we can state that this subprotocols define the basic or compulsory phases of the protocol. The second part of the description of the protocol includes the additional or optional phases. These additional subprotocols are useful to add functionality to the protocol and also to obtain a reduction of the transactions needed to finish the exchange, making the protocol much more efficient. Section 5 presents the compulsory subprotocols while section 6 presents the optional subprotocols.

The compulsory part of the protocol is formed by five phases: Service request executed by the customer, Opening phase that configure the channel parameters; Purchase (fair exchange of $\mu$-coins and the corresponding product or service) and finally the redemption (Redeem) of the received $\mu$-coins by the merchant and Refund of the $\mu$-coins to the customer wallet.

The optional part of the protocol includes three subprotocols, introducing the Channel Handoff property in the protocol: channel Transfer by the merchant, channel Transfer to an already opened channel by the merchant and, finally, Reuse, this is an alternative option for the customer to manage the not used $\mu$-coins, depositing them or reusing the channel with another merchant, respectively.

5 Basic phases of the protocol

This section presents the basic and compulsory phases of the protocol. Figure 2 represents the workflow of these functions using red lines.

Fig. 2

Protocol workflow

5.1 Service request

Previous to the opening of the channel, the customer C has to select the service or product that she wishes to use or obtain. A service request operation allows a customer to select a service of those offered by the merchants. Each merchant M has published his available services list. Then, C selects a merchant M and a service from his service list. The selected service is identified by $S_{id}$. The customer decides the exact number of $\mu$-coins c that wants to enter to the channel. Each $\mu$-coin will have a value v, which can be determined depending on the selected service, i.e. the price of $S_{id}$ should be a multiple of v, or directly v can be exactly $S_{id}$ price. The customer sends this data to M, that can decide to accept or reject the request. In case M accepts the request, he creates the hash chain generator $W_{LM}$ (where $L = 2c + 1$) and applies the hash function L times over this item getting $W_{0M} = H^{L}(W_{LM})$. We will call $W_{(L-1)M}$ to the result of applying the hash function over $W_{LM}$. The last element of the chain corresponds to $W_{0M}$.

The merchant M sends $W_{0M}$ to C to open the payment channel for this service, and stores $W_{LM}$ privately. It’s important to take into account that this chain is generated with the objective to allow partial redeems of the channel. In the case of a single redeem, that is, if M redeems all the received $\mu$-coins at the same time, it would be enough that M applies the hash function once over the generator to obtain the identifier. The Subprotocol 1 summarizes these operations.

In the description of the subprotocols, the black triangles represent transfers of information between users or execution of functions of the smart contracts (SC:function-name).

5.2 Opening phase

The channels are opened in two steps, the Channel Opening and the Channel parameters configuration. The utility of this division will be shown later in the paper.

5.2.1 Channel opening

Once the service request has been accepted by M, the protocol changes to the opening phase, where C starts executing the deployment of the new channel smart contract and transferring the amount $Q = c * v$ to it, using the defined functions of the developed smart contracts presented in section 8. This function is represented by the circle Open in Fig. 2. Remember that c is the number of $\mu$-coins that the customer wants to deposit to the channel and v corresponds to the value of them. Then, the smart contract, previous to the channel configuration, checks that the transaction value is equal to Q.

The subprotocols can include references to operations to be performed in the case of channel transfer. This functionality will be explained in section 6.

5.2.2 Channel parameters configuration

Previous to the channel parameters configuration, C generates $W_{LC}$, where $L = 2c + 1$ and applies over it L times the hash function to obtain $W_{0C}$. We will call $W_{(L-1)C}$ to the result of applying the hash function over $W_{LC}$. Thus, C builds an analogous hash chain to the one that M has built in the Service Request section. The last element of this chain will be called $W_{0C}$. Inside the hash chain, the elements with odd sub-index will represent $\mu$-coins, and the elements with even sub-index will represent the previous $\mu$-coin proof, as it can be seen in Fig. 3.

Its decided that $M's$ chain has the same length that $C's$ chain, to simplify the notation, even though a chain with half number of elements would be enough, since $M's$ chain does not contain payment items inserted between proof items.

To set up the channel timeline, C has to define three deadlines, which are represented in Fig. 1. First, $T_{Exp}$ represents the expiration date of the channel, then $\Delta _{TD}$ defines the period after the expiration date where the merchant can deposit the earned $\mu$-coins or, alternatively, transfer them to another channel. Finally, $\Delta _{TR}$ represents the period to refund the remaining coins that were not used in the payments by C or, alternatively, C can transfer the remaining $\mu$-coins to another opened channel or reuse the channel. When the Refund period has finished, the protocol only allows C to execute a refund, it’s not possible to transfer or reuse the channel.

With this values, the customer C sets up the channel configuration, defining the element $\Gamma$ = (C, M, $W_{0\,M}, S_{Id}, 2c, v, T_{Exp}, \Delta _{TD},$ $\Delta _{TR}, W_{0C}$). Note that the first two items are the blockchain addresses of the customer and the merchant (C and M), these addresses are used by the smart contract to control the redeem and refund actions of the payment channel. This set of parameters has to be sent to the channel smart contract for the effective creation of the payment channel. Additionally, the smart contract sets the counter $j = 0$, which symbolizes the number of revealed items of the $\mu$-coins chain, and checks that the balance of the smart contract corresponds to the initially defined Q parameter. Each channel will be identified with the parameter $Channel_{Id}$ which corresponds to the channel deployed smart contract address. These operations are depicted in Subprotocol 3.

5.3 Purchase phase

The purchase operation is performed off-chain. The purchase process is made by three steps, forming a fair exchange between the money and the product or service. In the first step, C sends money to M, in the form of $\mu$-coins, then M sends the purchased product or service to C. Finally, C sends a purchase proof. It is possible to perform as many payment transactions as the number of $\mu$-coins that conforms the channel before it reaches $T_{exp}$. The smart contract will verify, previous to each payment, that the current date has not reached the expiration date and that the smart contract contains the correct balance, indicated on the channel opening.

Fig. 3

Chain structure of the purchase items

In the purchase phase the $\mu$-coins will be revealed in reverse order of the hash chain, i.e. the first $\mu$-coin used will be $W_{1C}$. In this process a session secret key $K_s$ will be used, this key is shared between C and M, renewed periodically. The generation of the session secret key is left to the choice of each implementation using the proposed protocol, but it is considered that it should change periodically, at least once for each new channel. An example of cipher algorithm that can be used is ECIES, generating an encryption key for a message and encrypting the key of the message using the pubic key of the receiver of the message.

Now we will describe the three steps to perform a micro-payment. In addition to that, the Subprotocol 4 sketches these operations.

• Step 1: C sends to M the message $m_1 = [E_{K_s}[{W_{iC}}], i]$ using the off-chain channel identified by $Channel_{Id}$. When M receives the message, deciphers $W_{iC}$, verifies the date and the channel identifier, i.e. checks that the channel is opened. Then, the merchant M checks that the $\mu$-coin has not been reused, checking that $i > k$, where i is the order number of the $\mu$-coin used in the payment and k is the order number of the last item of the hash chain received by M. At the same time checks that C is not using $\mu$-coins that don’t exist in the channel, verifying that $L > i$. In addition, M verifies that $W_{iC}$ belongs to the chain checking $H^{i-k}(W_{iC}) == W_{kC}$, assuring that the last item received ($W_{jC}$) is derived from the new one. Just in the case of the first payment of the channel, the verification will be: $H^{i}(W_{iC}) == W_{0C}$. Once the validations are completed, M stores $W_{iC}$ and $(k = i)$ in the corresponding $Channel_{Id}$. When M receives $m_{1}$, he first deciphers it and carries out the corresponding validations. Then, he stores the deciphered $W_{iC}$ value in his private database, to be used in future validations.

• Step 2: M sends the product or service using the message $m_2 = E_{Ks}[service/product]$. When C receives the message, she deciphers $m_{2}$ and prepares the $\mu$-coin attached proof.

• Step 3: C sends the attached proof of the $\mu$-coin, as a ciphered message, together with the corresponding index of its chain position, $m_{3} = E_{Ks}[W_{(i+1)C},(i+1)]$. Then, M deciphers and verifies $W_{(i+1)C}$. This verification is made applying a hash function over the proof and checking that the result corresponds to the $\mu$-coin used for the payment with $W_{iC}$. Finally, M saves the value of $W_{(i+1)C}$ and updates $k = i + 1$.

5.4 Redeem phase

Once M has received the payments through the channel, he has to execute the Redeem operation to transfer the received funds to his wallet. The redemption of the channel can be done when all the channel $\mu$-coins have been received, but it can also be executed when M has received only one or several $\mu$-coins of the payment channel, although this practice is not recommended due to the gas costs.

The Redeem operation is executed on-chain. M calls the channel smart contract, and it will execute the Transfer representing the sum of the values of the revealed $\mu$-coins. The smart contract always transfer the value to the Merchant’s wallet according to the Merchant blockchain’s address parameter established in the Opening phase of the channel. Based on that, the smart contract will verify that the request is performed in the Redeem period, that is, between $T_{Exp}$ and $T_{Exp} + \Delta _{TD}$.

Nevertheless, M can execute the Redeem function before $T_{Exp}$. In this case, M will execute a partial redeem of the received $\mu$-coins. Then, he can execute a new redemption in the future. Executing this operation, as it is depicted in Subprotocol 5, M has to send to the smart contract the values of the following parameters stored privately by M: $W_{kM}$, $W_{kC}$ and k, where k is the last received index of the chain, with independence of its index (it can represent a $\mu$-coin or a proof).

The smart contract checks that:

• msg.sender == merchant. Verifying that the caller address of the function corresponds to the defined merchant address.

• $k > j$. Verifying that there is no $\mu$-coin reuse.

• $W_{jM} == H^{k-j}(W_{kM})$. Verifying that the user which executes the function is the receiver of the payment channel.

• $W_{jC} == H^{k-j}(W_{kC})$. Verifying that the $\mu$-coin forms part of the payment channel.

If all the checks are correct, the smart contract executes the deposit of the balance associated to the request to M’s wallet. For this purpose, the smart contract determines the value in function of the quantity of $\mu$-coins and the value defined in the channel. The number of $\mu$-coins deposited is determined by the index provided by M. If it is even, the smart contract will transfer the value of $(k - j)/2$, while, if the index is odd, the smart contract will transfer the value of $(k - j - 1)/2$, because the indexes that represent proofs are considered. This is due to the fact that the protocol takes into account two cases. In the first one, M presents all the proofs associated with the received $\mu$-coins. While, in the second one, M does not provide the proof related with the last $\mu$-coin.

Then, the smart contract has to update the parameters $j = k$, $W_{jM} = W_{kM}$ and $W_{jC} = W_{kC}$, when k is even. In contrast, if k is odd, the smart contract will update the parameters as $j = k - 1$ and, next, it has to regenerate the values of $W_{jM}$ and $W_{jC}$ related to the new value of j, i.e. the smart contract has to calculate the value of $W_{jM}$ and $W_{jC}$ of the last $\mu$-coin proof redeemed by M.

If M does not execute the channel redeem in the corresponding period, that is, the channel Refund period, customer C will receive all the $\mu$-coins remaining in the channel. Even though some of them may have been transmitted off-chain to M.

5.5 Refund phase

Finally, once the channel has been redeemed, the $\mu$-coins not used in the payment operations will be returned to C. This phase is the one that finishes the protocol and the customer has two possibilities: transfer directly the $\mu$-coins to the customer wallet address or, alternatively, submit a new Ethereum address where the channel remaining $\mu$-coins will be transferred. Therefore, the customer can refund the channel to a wallet address or to an already opened channel.

This two alternatives are represented in Fig. 2 by the close item, which connects to the wallet item representing the Refund directly to the customer wallet or the channel item, to perform the Refund to an opened channel or any other Ethereum address different from the customer address.

In case $t > T_{Exp}+\Delta _{TD}+\Delta _{TR}$, if C has not executed the Refund, it will be executed automatically when the user enters to the dApp, without allowance of reuse the channel, and refunding it directly to the customer address (according to the corresponding parameter defined in the Opening phase of the channel). Also, as it has been introduced previously, in case M does not have executed the Redeem operation, all the $\mu$-coins will be refunded to C, eliminating M’s opportunity to redeem them (since the period to redeem has expired).

6 Optional phases of the protocol

This section describes the optional or additional subprotocols. This phases are represented in Fig. 2 by the workflow lines in blue.

These three subprotocols are introduced to improve the efficiency of the basic protocol. The phase Channel transfer to an already opened channel by M is useful when the merchant has already acted as a customer in the past and wants to act again as a customer, taking advantage of a previous deployed channel. In contrast to the phase Channel Transfer by M, that is useful when a merchant wants to act as a customer to spend the earned $\mu$-coins. Additionally, the Reuse subprotocol is useful when a customer wants to continue acting as a customer, using the same already deployed channel, with the same merchant or with another one.

The main goal of these new operations is to reduce the number of transactions on the blockchain, together with their associated costs.

6.1 Channel transfer by M.

The protocol has been designed taking into account the Channel Handoff feature, that is channels where the $\mu$-coins owner can change multiple times without the need to transfer the funds to a particular user wallet.

Channel transfer subprotocol allows M to transfer the received funds on the channel shared with C to a new channel shared with another merchant N, where M will be the customer.

For the purpose of simplicity, we will consider that M will use $\mu$-coins of the same value in both channels, but the protocol could easily be extended to the use of different $\mu$-coin values.

To achieve the Transfer to a new channel, first M requests the deployment of a new channel, where he will send the $\mu$-coins received in the previous channel (old channel). So, executing the deploy function, M doesn’t have to introduce any $\mu$-coin. In this case, previous to the channel parameters configuration, the $\mu$-coins of the old channel will be directly transferred on-chain between the smart contracts that represent the two channels. Provided that the owner of the smart contract has the same blockchain’s address of the merchant (i.e. parameter M set up in the Opening phase)

Next, M and N performs the message exchange of the channel parameters configuration. N generates $W_{0N}$ and M generates $W_{0M}'$ analogously to the previous channel opening: $W_{0N}=H^{L'}(W_{L'N})$ and $W_{0M}'=H^{L'}(W_{L'M}')$. The amount $L'= 2c'+1$ must be computed with a value of $c'$ that has to be equal or less than the number of $\mu$-coins in the original channel ($c' <= j$).

Once the new channel has been opened, M can perform the transfer of the $\mu$-coins to be used in the new channel. As in the Redeem subprotocol, the number of transferred $\mu$-coins is determined by the index provided by M. If the index is even, the smart contract will transfer the value of $(k - j)/2$, while if the index is odd, it will transfer $(k - j - 1)/2$. Also, as in the Redeem operation, the smart contract has to update the parameters j, $W_{jM}$ and $W_{jC}$, corresponding to the last transferred $\mu$-coin.

M defines the parameters $T_{Exp}'$, $\Delta _{TD}'$, $\Delta _{TR}', W_{0M}'$ and generates the parameter $\Gamma '$ = (M, N, $W_{0N}$, $S_{Id}$, $2c'$, v, $T_{Exp}'$, $\Delta _{TD}'$, $\Delta _{TR}', W_{0M}'$) and introduces it to the channel smart contract.

M can use the $\mu$-coins of the channel to purchase products or services to N, following the purchase subprotocol described previously. Finally, N can deposit the money using the Redeem channel subprotocol. Alternatively, N can perform another channel transfer to spend the funds with another merchant.

All these previous operations are sketched in Subprotocol 7. In Fig. 2 this subprotocol is represented by the transfer and new channel items, which are connected with the open subprotocol of the new channel where the user wants to transfer the earned $\mu$-coins.

6.2 Channel transfer to an already opened channel by M.

According to the already described phases, the protocol provides a fair $\mu$-payment system with the Channel Handoff feature. As it has been introduced, the protocol allows to the merchant M to redeem the obtained $\mu$-coins or to transfer them to a new channel.

However, we have also designed a function to allow the merchant M to manage the earned $\mu$-coins using an already deployed channel where M is the channel owner, i.e. the customer of the channel. This subprotocol is mainly provided to the merchants that have previously used a channel where they acted as customers. This old channel is already opened and can still keep unused $\mu$-coins from the previous purchase.

This operation is based in the combination of the previous explained phase Channel Transfer by M, and the following one Reuse by C.

To begin with, the merchant M of an opened channel needs to have another old channel, where he represents the customer C and was intended to interact with another merchant ($M^*$). This channel was used in the past, and now it must be in the Refund phase. Given this situation M can transfer the earned $\mu$-coins to the old channel, and spend them with the same $M^*$ of the last time that has used the channel or introducing a new merchant N. With the objective to reuse the old channel, M previously has to execute a new service request to the desired merchant.

Once the new merchant has accepted M’s request, M has to execute the redeem from the smart contract where he acts as the merchant to the old smart contract where he represents the customer, in order to transfer the earned $\mu$-coins to the old smart contract. Then, M sends to the new merchant the address of the old smart contract.

M defines the channel configuration parameters, $T_{Exp}$, $\Delta _{TD}$, $\Delta _{TR}$, generates his hash chain and computes $W_{0M}'$. Finally, he sets the channel smart contract configuration sending the new parameters: M, N, $W_{0N}'$, c, v, $S_{id}$, $T_{Exp}$, $\Delta _{TD}$, $\Delta _{TR}$ and $W_{0M}'$.

The smart contract, once the parameters configuration function has been executed, checks that his own balance is equal to $c*v$ and sets j = 0. Then, the channel users can continue the protocol workflow with the purchase phase.

This subprotocol is represented in Fig. 2 by the lines that start in the transfer item, links to the old channel item and connects with the reuse item. Then, the configuration parameters of the reused channel are updated.

6.3 Channel reuse by C

Once a channel has been redeemed or transferred by M, the $\mu$-coins not used in the payment operations will be returned to C. As long as the Refund period has not expired, the automatic refund will not be made ($t < T_{Exp}+\Delta _{TD}+\Delta _{TR}$). This way, C can decide between closing the channel and obtaining the refund of the $\mu$-coins or, instead, reusing the channel (Subprotocol 9).

In case C wants to take advantage of the already used channel and reuse it with another merchant (or with the same one) using the remaining $\mu$-coins of the channel, the customer C changes the merchant M to another one, $M^*$. (It is also possible to reuse the channel with the same merchant M, allowing the modification of any parameter, as the value of the $\mu$-coins, deadlines,...). This channel change can be performed between the deadlines ($T_{Exp}+\Delta _{TD}$) and ($T_{Exp}+\Delta _{TD}+\Delta _{TR}$). The main goal of the reutilization of channels is to reduce the associated costs of the transaction operations over the blockchain.

To reuse the channel, C has to start the creation of a new channel, requesting to $M^*$ the opening of a new channel, and when $M^*$ has accepted it, on the channel opening transaction, C introduces the smart contract address of the previous channel. So, the opening phase will be made off-chain, because C only has to send the smart contract address to the new $M^*$. Next, C has to enter to the smart contract the new channel configuration, modifying the previous channel parameters with the new ones. Then, she can start the normal usage of the channel. This subprotocol is represented in Fig. 2 by the item reuse which is connected with set-parameters item. It’s important to take into account that previous to the parameter configuration, C has to execute with M* (or M) a new service request, and then, once the request is accepted, it will be linked to the reused channel.

From a merchant point of view, the most efficient way to use channels is to transfer the earned $\mu$-coins to an old channel, as it has been explained in this section. With this objective, it is interesting to note that once a user C opens a new channel or reuses it, she configures $\Delta _{TR}$ to be as long as possible, for example a year. With this approach, the channel will not be destructed after a short time, consequently, C will not have to deploy new channels, she can transfer the earned $\mu$-coins and reuse the channel. With this method, customers can avoid new deploying costs.

7 Protocol workflow states

Fig. 4 summarizes the phases of the protocol as a workflow. It is divided in the three deadlines $T_{Exp}$, $T_{D}$ and $T_{R}$. The Open deadline represents the moment where the channel is deployed by C. Then, inside each period the different states of the channel are presented. This workflow and the corresponding states will be useful to understand the implementation of the protocol and the functions of the smart contract.

First, starting with the service request section, once C has sent the open channel request to M, the channel has the Requested state, then when M accepts the channel it is in the Accepted state. And finally, after the deployment of the channel by C, the channel is opened but it’s not configured. For this reason it is in the Waiting configuration state.

At this point, C can configure the channel by introducing the negotiated parameters that define it. Before this configuration, C can transfer the channel. In the case of a transfer from another channel, C will execute the Transfer from the old channel to this new one. After the channel configuration the state is Opened.

An opened channel is established for the purchase operation. Since the purchase has three steps, the workflow includes three states Payment, Send Service and Send Proof. These states represent the situations after the reception of $m_{1}$, $m_{2}$ and $m_{3}$, respectively. For this reason this three states are recursive, and they will be repeated for each micropurchase.

After $T_{Exp}$ we can find the Redeem or Transfer section, where M can choose between the execution of the channel redeem or the channel transfer. This two actions can also be done before $T_{Exp}$, but to achieve more efficiency it’s important to wait until all the channel $\mu$-coins have been used. In the Transfer case, M should have another channel in the Opened - Waiting configuration state. M can also have an old channel at the Refund phase, that could be reused with the earned $\mu$-coins.

Finally, after $T_{D}$ we can find the Refund or Reuse section. In this section, C decides which action wants to be executed with the remaining $\mu$-coins of the channel. She can simply deposit the money to her wallet or she can reconfigure the channel to use it with a different M or also the same one with new parameters.

Fig. 4

Payment channel states workflow

8 Implementation

The protocol presented above has been implemented using the Ethereum testnet Rinkeby. The complete functionality of the protocol is achieved thanks to the development of different smart contracts using the Solidity language, together with the database that represents the Layer 2 of the blockchain. In this section, we describe this implementation, introducing the database configuration and the main functions of the developed smart contracts. All the presented code in this section is available in our institutional github repository⁴.

The protocol as it has been briefly introduced, is based in the use of smart contracts that manage the $\mu$-payment channel, providing fairness to the protocol, ensuring that the involved parties finally receive the agreed items to be exchanged. In addition to the main smart contract each channel also will use a Layer 2 implementation, that allows a reduction of the on-chain transactions, reducing the monetary transactions over the blockchain.

Concretely, the system uses two smart contracts, a Factory smart contract and a Channel smart contract. The first one is responsible for the management of all the deployed channels, while each channel is represented by a Channel smart contract, that can be deployed by the user customer (or it can be reused) and provides the needed functions to execute the protocol workflow. As it will be explained in the following sections, the channel smart contract will be used by both parties, customer and merchant.

All the phases of the protocol, except for the Service request and Purchase, are performed on-chain, meaning that there is an actor’s action that requires a transaction with the functions of the deployed smart contract, in order to regulate the payment channel. This smart contract will control that each actor only execute the corresponding actions according to his role and will record them on the blockchain.

In addition to the Service request and Purchase that doesn’t perform on-chain communications, the Reuse phase does not represent monetary transactions over the blockchain. The $\mu$-coins remains in the same Channel smart contract. The users only have to do a reconfiguration of the channel.

Finally, it’s important to take into account that thanks to the design of the optional phases, reuse and transfer phases, the user doesn’t have to transfer the $\mu$-coins to her wallet, the $\mu$-coins can remain in the smart contracts, reducing the need to constantly transfer money to the wallet and then create new channels and transfer them back to new smart contracts. So, to achieve the best efficiency of the protocol it is interesting to make use of this optional phases that reduce the number of on-chain transactions. All the functions of the smart contract are presented in section 8.

8.1 Database

In order to introduce the Layer 2 in the protocol implementation, we have developed a small JSON database file where we store the main parameters that the users have to introduce in the blockchain and also share between them. In the implementation, the connection between the dApp and the JSON database is achieved with the execution of a local json-server.

There are three main databases. First of all the services database that contains the merchant provided services. Then the channels database, the most important one, that contains all the open channels and their respective shared parameters. Finally, each user has his own database, where all his channels are stored, including the channel identifier and the private parameters.

8.1.1 Services database

The service database contains all the services provided by the active merchants of the system. It’s a very simple database that, for each entry, only requires four parameters, as it is shown in Listing 1: the $S_{id}$ parameter, the merchant Ethereum address which allows the identification of the merchant, information about the service or product that the merchant wants to publish, for example the service name and some related details, and the service or product price.

8.1.2 Channels database

The channels database is the most important one as it contains all the channel information, that will be gradually filled following the protocol workflow.

Listing 2 shows all the possible parameters that can be entered in any channel database. Specifically, it contains the identifier of the channel in the present database, the customer and merchant Ethereum addresses, the service provided by the merchant using the channel, the number of $\mu$-coins, the state of the channel, the public keys of the users, the timelines ($T_{Exp}$, $\Delta _{TD}$ and $\Delta _{TR}$) and the Ethereum address of the deployed Channel smart contract. The users $\mu$-coin chain parameters ($W_{0M}$, $W_{0C}$) will be published in the blockchain, too. The database also contains the encrypted messages that the users exchange for each payment ($m_{1}$, $m_{2}$, $m_{3}$) and, finally, if the channel has been reused with another merchant, the database entry contains the identifier of the new database that contains all the reused channel information.

8.1.3 User database

The JSON file contains each user database, the identifier of this database corresponds to the Ethereum wallet address of the user and contains all the channels of the user. Listing 3 shows two entries of a user database, one for a customer and the other for a merchant.

For each channel the database contains the user address (customer or merchant address, depending on the user role), the service provided using the channel, the channel encryption keys, the generators $W_{LM}$ or $W_{LC}$ that are generated from the application of the sha256 hash function over a random number of 16 bits and, if the user represents the merchant of the channel, this database also contains j and $W_{ic}$.

8.2 Smart contracts

The implementation of the proposed protocol has been achieved defining two smart contracts, the factoryChannel and the Channel smart contracts, that use the Factory Clone programming pattern, a saving gas solution that derives from the Solidity Factory method programming pattern obtaining an easy management system of the new registered smart contracts. In our case the factoryChannel works as the management system, being the source of the deployed (or cloned) new opened Channels.

The Factory Clone programming pattern is explained in the standard EIP1167 [19]. Instead of deploying a new smart contract each time, it first deploys the smart contract of the system (in our case the Channel smart contract), and then all the other deployments are a minimal deployment that points to the previously on-chain deployment. The minimal deployments delegate all calls to the main Channel deployed smart contract address.

8.2.1 FactoryChannel smart contract

The factoryChannel smart contract is the one responsible for the management of all the different channels that conform the micropurchase system.

The main functions of the factoryChannel smart contract are presented in Listing 4.

The factoryChannel constructor, as it can be seen, only deploys the channel main smart contract, where all the cloned smart contracts will delegate their calls.

Then we define two createChannel functions that are very similar. The first function creates the channel but does not configure it, the configuration has to be done executing the setChannelParams function in a following transaction. Then, the second function allows the creation of a channel together with the parameters configuration in the same transaction. With this same objective, in the channel smart contract two initialize functions are defined, one that only defines the parameters c and v while the second defines all the channel parameters. The reason to use two functions to open a channel is to allow the opening of a smart contract channel and then transfer the $\mu$-coins from another channel.

Both functions use the createClone function of the EIP1167 standard [19] to generate the channel smart contract clone. The clone smart contract is initialized configuring the different parameters, depending on whether it corresponds to a transaction for the creation of a channel in a single step or in two steps (i.e. including or not the parameter configuration). In both functions the user C of the channel is defined, representing the channel owner. Next, the createChannel function stores in the factoryChannel smart contract the new clone channel address and the corresponding owner.

Finally, the factoryChannel smart contract includes getter functions to easy obtain the different channels that are deployed in the system, and their corresponding owners.

8.2.2 Channel smart contract

The Channel smart contract, as it can be expected, includes the main functions to execute the different protocol phases.

First of all, the parameters introduced in section 1 are defined. As it can be seen in Listing 5, they have the same functionality of the presented in Table 1.

Variable j represents the last $\mu$-coin proof index redeemed or transferred by the merchant. Index j are also used in $W_{jm}$ and $W_{jc}$.

Next, as it has been introduced in the factoryChannel smart contract section, the initialization functions are defined. The first one only contains the storage of the variables c, v and the customer address. It doesn’t require the $\mu$-coin value, it can be send in the execution of the setChannelParams function (Listing 7), in order to allow the opening of a smart contract channel and then transfer the $\mu$-coins from another channel. Function setChannelParams ensures that the channel has the initial negotiated $\mu$-coins. In addition, it requires the correct timelines for the correct execution of the different phases of the protocol. T exp it’s a concrete Unix Time Stamp hour, and then the TD and TR parameters are the time difference from the T exp timeline and TD or TR timelines respectively. For this reason, the timelines verification is made with the sum of the parameters.

The transferDeposit function is in charge of the redeem to M or the transfer of the received payments to another channel. For this reason it has to execute all the required verifications of the $\mu$-coin or the proof that M sends as parameter. Then it obtains the balance of the payment channel.

The verifications include validating the date to ensure the channel is in its redeem phase and checking the chain item to confirm that the new hash chain index k sent by M is greater than the previous index j. This process prevents the possibility of $\mu$-coin reuse.

Listing 8 shows the for loop that executes i times the hash sha256 over the chain item entered by M. If the introduced chain item is correct, then $hash_{m}$ and $hash_{c}$ results will be exactly the stored values of $W_{jm}$ and $W_{jc}$. In the first execution of this function in a new channel, these values correspond to the hash chain identifiers ($W_{0C}$ and $W_{0M}$) of the customer and the merchant chains respectively.

Once the smart contract function transferDeposit has verified the correctness of the provided chain items, the value that has to be transferred is calculated. If the index of the presented chain item is even, the amount is obtained with an easy calculation: $(k - j)/2$. Then, it only has to update the parameters j, $W_{jm}$ and $W_{jc}$.

In case the hash index is odd, the value is: $(k - j -1)/2$. The smart contract has to calculate all the parameters corresponding to the proof of the last $\mu$-coin used, as the odd index represents a $\mu$-coin and to avoid forgery the corresponding proof is required.

Finally, the transferDeposit function determines if the transfer corresponds to a redeem to M wallet or to a transfer to another channel owned by M. In case the parameter newChannelAddress is different than the zero address, it represents a channel transfer, in other case it is a normal redeem to M wallet.

The last important function defined in the channel smart contract is the channelClose presented in Listing 9. This function corresponds to the refund of the remaining $\mu$-coins when the channel is located in its refund phase. To achieve the refund, C executes the selfdestruct function which in addition to transfer the remaining channel $\mu$-coins to C, it destructs the channel smart contract.

In the execution of this function, C can define to which address she wants to refund the channel remaining $\mu$-coins, depending on the refundAddress parameter entered by C. This feature allows the customer C to choose if she wants to refund the remaining $\mu$-coins to a different wallet address from the one where the channel was created, or even to another channel, already opened.

Thanks to the presented smart contract functions and the database previously presented the system can execute all the protocol phases.

• First of all, at the service request phase, the involved users generate the parameters and store them in the database.

• The function createChannel of the FactoryChannel smart contract is executed, that clones a new channel, and using the setChannelParams function all the different parameters negotiated previously between C and M are uploaded to the blockchain.

• Before the Redeem timeline, M can redeem the received $\mu$-coins or transfer them to another channel. To redeem them, M only has to execute the transferDeposit smart contract function. In the other hand, if M wants to transfer them to another channel, previously M has to execute the service request phase with the new $M^*$ and once the negotiation is completed, he has to create the new channel with the function createChannel. Previous to the execution of the setChannelParams function he has to transfer the $\mu$-coins from the old channel, and insert them in the new channel. Once the setChannelParams function is executed, the new channel can continue working as in a normal opening.

• Between the Redeem timeline and the Refund timeline, C can execute a refund or a reuse of the channel. In the Refund case, C only has to execute the channelClose function, and as it has been explained the smart contract will return to C the remaining $\mu$-coins.

• In order to reuse the channel, first C has to negotiate with a new M, i.e. it has to execute the request service phase, and then she doesn’t have to open a new channel, in contrast it has to introduce in the channel database the Ethereum address of the channel that wants to reuse, and directly she can continue with the setChannelParams, introducing the negotiated parameters in the service request phase.

9 Evaluation of properties

This section will prove that the proposed protocol fulfills the ideal properties of a micropurchase system.

A list of requirements for a micropayment system were presented in [20], with the following classification:

• Intrinsic characteristics. These features form the base of the criteria for the micropayment system. The list includes Lower bound of value, Divisibility, Portability, and Off-line capability.

• Extended Features, including Transferability, Multicurrency, Cancellation and Fault tolerance.

• Security and privacy aspects, including Authenticity, Integrity, Interruption tolerance, Non-repudiation, Anonymity and Unlinkability.

• System aspects, with two general criteria: Scalability and Universality.

Since this paper proposes a micropurchase protocol then the property of Fairness must be added to the set of required properties. In some papers this property is also called Atomic Exchange.

Taking this list of requirements as starting point we have evaluated the proposed protocol proving each one of the properties related with the relevant aforementioned requirements.

9.1 Fairness

A purchase is a traditional application of a fair exchange of values. In one hand, the buyer makes a payment and in the other hand the seller provides a product or service. This exchange is called Payment per Product or Payment per Service.

In the proposed protocol the exchange is performed without the intervention of any Trusted Third Party (TTP). To perform the fair exchange the proposal uses an off-chain subprotocol, where the messages are exchanged directly between the users C and M.

The procedure is formed by three steps represented by the exchange of $m_{1}$, $m_{2}$ and $m_{3}$. This procedure could be interrupted before the operation would be completed. The possible interruption points are the following:

• After the first step of the exchange, where C provides the $\mu$-coin $W_{iC}$, M does not follow with the protocol and does not provide the product or service.

  • In this case C will not send the proof item $W_{(i+1)C}.$

  • The purchase operation is considered as not executed. C does not obtain the product or service and M cannot include the $\mu$-coin in the redemption of the channel nor in a channel transfer because he does not know the proof element associated with the last $\mu$-coin received in the first step of this purchase.

  • In this first scenario, if several $\mu$-coins have been used in a single payment, M will not be able to redeem the last $\mu$-coin but he would be able to redeem all the previous received $\mu$-coins. For this reason, in order to remove the risk of a partial loss C can adjust the value of the $\mu$-coin to each service. However, it seems logical that M does not act in this way because if he tries this $\mu$-fraud he will lose all the following sells to the customer, so this $\mu$-attack is not profitable for the merchant.

• After the execution of the second step of the exchange, C does not continue providing the proof associated with the $\mu$-coin, $W_{(i+1)C}$.

• A merchant is discouraged from attempting this scenario and committing microfraud because it risks losing future sales to the customer, making such fraud unprofitable.

  • In this case it is assumed that the purchase has been performed.

  • C has the purchased element while M cannot include the $\mu$-coin in the redemption or transfer of the channel.

  • When C wants to make another purchase in this channel, C will use $\mu$-coin $W_{(i+2)C}.$ Using this $\mu$-coin, M can obtain the proof element of the previous purchase $W_{(i+1)C}.$

  • If C does not perform any new payment using the channel then M will not be able to redeem the last $\mu$-coin. In this scenario, a merchant has to assume that he can loose a $\mu$-coin for each channel. This situation presents an acceptable risk in a $\mu$-payment operation. In the other hand, the fraud associated to the creation of channels with the aim to cheat with a single $\mu$-coin is discarded taking into account that the creation of the channel (or its reuse) involves some execution costs that make not viable to obtain benefits from the creation of a channel to steal a single $\mu$-coin.

  • A customer is discouraged from attempting this scenario and committing microfraud because creating channels with the goal of cheating for a single $\mu$-coin is not viable. The execution costs involved in creating or reusing a channel outweigh the potential benefits.

9.2 Counterfeiting, double-spending and overspending avoidance

The protocol has been designed to avoid the counterfeiting of the $\mu$-coins. The protocol does not allow the use of a $\mu$-coin in two payments (double-spending) neither the use of more $\mu$-coins than the number of them included in the channel.

• All the $\mu$-coins involved in a purchase operation must be associated to a channel. The association is verified through the operation $H^{i}(W_{iC})==W_{0C}$, where $W_{0C}$ must be the value stored in the element $\Gamma$ of the channel. This verification avoids the use of false $\mu$-coins.

• A $\mu$-coin cannot be used twice because the merchant checks that $H^{i-j}(W_{iC})==W_{jC}$, where i is the index of the current $\mu$-coin and j is the index of the $\mu$-coin used in the last payment with $\mu$-coins of the channel. For this reason i must be greater than j for the payment to be valid.

• Overspending is avoided by means of two procedures. In one hand, the money associated to the $\mu$-coins of the channel is deposited in the smart contract before the payments. In the other hand, the number of $\mu$-coins associated to the channel is limited and the last $\mu$-coin of the channel is determined by the element $W_{(L-1)C}.$ The merchant will not accept any $\mu$-coin that require a validation using the hash chain with more than L operations.

9.3 Transferability and reusability

The purchase protocol is based in the use of blockchain-based payment channels. The channels allow the payment from a customer C to a merchant M. In the simplest scenario, M will redeem the channel after the reception of the $\mu$-coins related to the channel. This redemption represents a transaction on the blockchain.

However, with the aim to enhance the efficiency of the system, the protocol has been designed to allow Channel handoff operations. Therefore, in out proposal, the $\mu$-coins can be used in several payments without the need of any blockchain transaction. After the reception of the $\mu$-coins, the merchant can choose between the redemption of the channel or its transfer (i.e. channel handoff operation ). With the transfer of the channel the user can rearrange the channel to use it with another user, acting as a customer with a new merchant.

The protocol also allows the customer to use the $\mu$-coins not used in payments to the merchants. This coins could be refunded to the account of the customer automatically at the expiration date of the channel. However, we have decided not to automatize this reimbursement and allow the user to choose between the refund or the redirection of the channel towards another merchant (i.e. channel handoff operation ), as long as the channel is in the Refund phase. This action is called channel reuse. The Transfer and the Reuse of the channel allow to reduce the costs associated with the on-chain operations, making the system more efficient. Figure 2 summarizes the workflow of operations including all the options related with the transferability and reusability of the channels.

9.4 Privacy

Users C and M, (and N if it is the case) access the smart contract using their blockchain addresses. However, the channel is related to the knowledge of certain values. The user who knows the elements for the redemption associated to the channel will be the user with the capability to redeem or transfer the channel. This way the user executes the function without an identification stage.

Since the channels are multihop, the channels can be transferred without a fund transfer on the blockchain. For this reason a user can execute a purchase operation while his blockchain wallet is not involved in any transfer. This way the system fulfills the anonymity property in addition to the unlinkability of the channels.

9.5 Lower bound of value

One of the fundamental features of a $\mu$-payment system is the requirement of reduced cost per transaction because the cost must not be bigger than the benefits associated with the payment and a lot less than the transferred amount. For this reason the payment system presents a lower bound of value representing the minimum value that can be transferred in a payment operation.

The protocol presented in this paper reduces considerably the cost of a single payment using cryptocurrencies thanks to the use of a payment channel. The number of payment operations on the channel is indicated by the variable c. The users can fix this variable in function of the intended number of payments. For long term relationships between customers and sellers the system can use long $\mu$-coin chains associated with the channel, improving the efficiency of the system.

In the other hand, the design of the channels of the system, with the Channel handoff feature, reduces the number of transfers on the blockchain. A transferable channel does not require the redemption of the channel after its use by the first pair of users since the channels can be transferred and reused, see Fig. 2. In Sect. 10 the execution costs of the system are evaluated. The execution cost of a channel represented by the values c and v will determine the lower bound of the $\mu$-payment system.

10 Performance analysis

As has been introduced in the previous sections an important feature of a micropurchase system based on the use of micropayment channels is the transaction cost, because it determines if the system is effective or not. This feature is essential because the protocol manages low value transactions.

The current performance analysis primarily focuses on the gas costs associated with the presented protocol implementation. Other metrics, such as the execution time, are not analyzed because the protocol relies on deploying smart contracts on a blockchain. As a result, the execution time is highly dependent on the specific properties of the chosen blockchain and the network congestion at any given time.

Table 2 Table representing the cost of executing transactions of the main functions of the implementation

Accordingly, we have developed different tests on the smart contracts presented in section 8 to obtain an estimation of the costs of all the protocol phases. This costs have helped us determine that the micropurchase protocol, in addition to functional and secure, is efficient thanks to the relevant reduction of cost compared to the costs of blockchain transactions.

Specifically, the tests have been performed using the gas reporter plugin of the Hardhat framework over the Rinkeby blockchain network, that provides an accurate report of all the executed functions.

In Table 2, the execution results are presented. The first column represents the functions analyzed, then there are the running costs in terms of gas represented in units of gwei and finally the equivalent price in terms of USD, when an ether has a cost of $1807,62.

The Factory channel deployment function represents all the system deployment, i.e. the FactoryChannel smart contract deployment, presented in the implementation section. As it has been explained previously, this smart contract is responsible for the system management and allow the creation of the different cloned channels, executing one of the Channel creation functions. The cost of this function is not relevant because it is only executed once, in the setup of the system.

The creation of the channel can be performed in one step or in two-steps, as it has been previously explained. (Channel creation (1 step)) represents the costs of the creation of a channel together with the channel parameters configuration. For this reason this function is more expensive than the second one, (used in the creation in two steps), that only clones the channel smart contract and defines the $\mu$-coins used.

Then, there is the Channel parameters configuration function, which has to be executed when C opens a new channel in two steps, i.e. when the user wants to do a transfer to a new channel. In this case the user will also execute the Channel transfer function, to move the earned $\mu$-coins from one channel to another, or to deposit it to the wallet.

Finally, the Refund channel function can be executed by the channel customer when the channel is at the Refund phase. It returns the channel remaining $\mu$-coins to the user wallet, and also executes the selfdestruct function of the smart contract.

An important conclusion of the presented performance analysis is that the user have a fixed cost per channel, independently of the number of $\mu$-coins involved and also of the origin and the destination of the payment. In other payment systems used for small payments, as Point of Sale (POS) Terminals or the payment with cards (Visa, Mastercard, PayPal,...), the fee depends on the different characteristics of the payment, for example, if the transfer is made inside the same country or it is a cross border transfer, the provider taxes...

We can compare the cost obtained in this performance analysis of the protocol with the fee taxes paid by merchants using a PoS terminal that depending on the provider generally ranges between a 0,4% and a 4% per transaction costs. Therefore, taking into account that the main subprotocol to be executed by the merchant is the Redeem, which is implemented using the smart contract function Channel transfer and that it costs $0,11, if the set of $\mu$-coins held by the channel represent a value of a few USD (greater than $27,67 in the case of the lowest transaction costs or greater than $2,76 in the case of the higher transaction costs) and it is redeemed in a single transaction, the merchant channel fees will be less than the presented by the use of POS terminals.

It should be noted that we have deployed the implementation using an Ethereum test network, by the fact that it is a public blockchain and it provides us the desired features, but is highly dependent on the network gas price. In case of deployment on a cheaper network or consortium, the resulting costs would be negligible.

11 Conclusions and future work

We have presented a micropurchase scheme, which serves as a fair exchange system between a micropayment and the purchased product or service. A micropayment represents a payment involving a very small amount of money, with minimal profit margins. Consequently, the system must operate without associated costs that substantially reduce or entirely eliminate the profit margin. The design of security and privacy mechanisms is paramount to fulfill this requirements.

Cryptocurrencies offer an optimal solution for micropayments through the implementation of Layer 2 protocols, eliminating the necessity for blockchain transactions for each payment operation. Following this approach the use of channels is presented, enabling off-chain operations until the channel redeem phase.

Furthermore, an effective micropurchase system must include functionalities ensuring a fair exchange between the nominal amount of money and the purchased item.

Specifically, we have presented a micropurchase system using micropayment channels, managed through smart contracts. The protocol leverages hash chains to represent the $\mu$-coins and a set of corresponding proofs to ensure atomicity in purchase operations [3].

The protocol consists of four main phases: the opening where the service is requested and the channel created. The purchase phase, where the customer executes purchase operations off-chain, corresponding to the number of $\mu$-coins within the channel. The redeem phase, enabling merchants to deposit the earned $\mu$-coins and finally the refund phase, used by the customer to obtain refunds for the unused $\mu$-coins. The system’s flexibility allows users to engage in several payments, facilitating channel transfer or reuse for enhanced efficiency and the elimination of unnecessary transactions (i.e. keeping the $\mu$-coins inside the blockchain and using them in different payments thank to the Channel handoff feature).

Channels thanks to the use of hash chains, are not associated with a specific merchant. The merchant possesses an item authenticating him as the legitimate redeemer.

The evaluation of properties indicates that the presented protocol fulfills all crucial requirements for an effective micropurchase system, as detailed in Sect. 9. Moreover, the performance analysis prove that these requirements are met with transaction costs that make the protocol viable for micropayments.

In future research, we intend to study the reversibility of the channel and the necessary modifications of the protocol to facilitate bidirectional payments. In addition, we aim to investigate methods to prevent merchants from losing the last $\mu$-coin in case the customer doesn’t provide the last received good or service proof.