Micro payments: Viable technical platforms and models for a bankto provide payments on micro amounts

U.U.D.M. Project Report 2018:21

Examensarbete i matematik, 30 hp Handledare: Johan Hörmark, SEB

Ämnesgranskare och examinator: Kaj Nyström Juni 2018

Department of Mathematics

Micro payments

– Viable technical platforms and models for a bank to provide payments on micro amounts

Kevin Cribäck

Micro payments

- Viable technical platforms and models for a bank to provide payments on micro amounts

Kevin Cribäck

June 19, 2018

Abstract

Micro payments are researched in a scenario where the parties transacting do not trust each other but they have trust in their respective bank. An attempt to quantify the willingness-to-pay for such a payment scheme in comparison to traditional payment methods is carried out. A brief qualitative

study in different platforms to host this type of payment solution is conducted. These are limited to distributed ledger technology platforms and a technical review of the same is made. Finally, collateral optimisation from the perspective of a bank is examined in a setting where the bank is hosting a

payment channel scheme.

Acknowledgements

I would like to express my gratitude towards Johan Hörmark for his insights in the field of payments and financial technology. I also wish to thank

Kaj Nyström for interesting and rewarding discussions regarding this thesis.

In general, I would like to thank the lecturers and my fellow students for the

years at Uppsala University.

Contents

1 Introduction 1

2 Background 1

2.1 The business case . . . . 1

2.2 Technology and product design specification . . . . 3

3 Blockchain technology 4 3.1 Secure hash functions . . . . 4

3.2 Asymmetrical Cryptography . . . . 4

3.3 Merkle trees . . . . 6

3.4 Transactions . . . . 6

3.5 Smart contracts . . . . 7

3.6 Oracles . . . . 8

4 Consensus Algorithms 8 4.1 Proof of Work . . . . 9

4.2 Proof of Stake . . . . 9

4.3 Practical Byzantine Fault Tolerance . . . 10

4.4 Raft . . . 10

5 Blockchain implementations and State channel technology 11 5.1 Ethereum . . . 11

5.2 Quorum . . . 11

5.3 Corda . . . 12

5.4 Hyperledger Fabric . . . 12

5.5 Scalability . . . 13

5.6 State channel technology . . . 13

6 Financial implications 16 6.1 A model for the banks involved . . . 18

6.2 Optimisation . . . 20

6.3 Numerical results . . . 26

7 Conclusion 29

References 30

1 Introduction

When two parties transact with each other, there is always a possibility that one cheats the other. This is usually compensated with a premium. The buyer is usu- ally protected by being able to pay after delivery while the seller is taking a higher margin then what would otherwise be necessary. Another way of removing the risk of cheating is by using a trusted entity, this is usually seen in centralised payment providers. In recent times, a decentralised solution is emerging, namely, distributed ledger technologies in which trust is not necessarily tied to one central party.

We define micro payments as amounts which are less then what payments gener- ally are today. This delimitation is defined by what transactions are profitable to carry through and as such, what payment model is suitable for the product in ques- tion. We try to quantify the willingness to pay for a buyer and a seller to be able to transact products for micro amounts. This is done to see whether there is a business case or not. We see a potential problem in transaction throughput, and consequently, in transaction fees if two transacting parties were to use a centralised payment scheme for micro payments. Therefore, we examine distributed payment solutions, or more precisely, how micro transactions could be carried out using dis- tributed ledger technologies.

One potential solution, which is the main focus of this thesis, is state channel tech- nology, or payment channels. These payments are carried out peer-to-peer and thus, reduces the requirement of transaction throughput considerably if the involved par- ties are recurrent. For one-off transactions between parties, it is an inferior solution which is why we imagine that the solution should be used between businesses.

Finally, the problem of managing collateral between two banks is studied. The study is carried out in the setting where the banks has launched a micro payment solution based on distributed ledger technology with a payment channel layer.

2 Background

2.1 The business case

Pay-per-use is a maturing payment model where the buyer pays the seller per use

of the product. This payment model have enabled businesses to acquire equipment

and technology which otherwise would be too expensive or unaffordable to pay for

upfront. One of the reasons which have enabled pay-per-use is digitisation. Another payment model, Pay-for-outcome, is emerging and allows business to trade solutions instead of products. The Pay-for-outcome improves cash flow, competitiveness and also decrease the time-to-market of innovation according to Siemens AG (2017).

In this paper we examine payment methods which should be part of a Pay-for- outcome, Purchase-to-pay system for use between businesses. A Purchase-to-pay process is the business process of requesting, purchasing, receiving and paying for a product. The requirement for such a system should be that the transaction fees should be held relatively low, it should be integrated in the production facilities so that a real-time flow of payments per produced item is enabled. Since the involved parties do not necessarily trust each other, however, they have trust in the bank and the transaction volumes will be high, we propose a decentralised system with a token issued by the bank. Because the seller of an item doesn’t necessarily trust the buyer, a control function should be implemented so that the seller knows when the outcome has been realised and therefore has the right to the money from the purchase.

Payments today are transferred separately from the product it is intended to fund,

see figure 1. The overall setting in this thesis is to integrate the payments as closely

as possible with the product which it is used to fund. Imagine a subcontracted com-

pany S (seller) who rents a machine to producing company B (buyer) and company

B pays per outcome in a IoT-world. That is, the produced goods from the machine

rented by S has a digital twin, then B would want to surveil the manufacturing pro-

cess to have knowledge of the outcomes of the process as well. Company S would

have a credit-exposure to company B as well as held up cash flow. Meanwhile, com-

pany B would earn interest on the money it owes company S. Focusing on medium

sized companies with limited trust capital, we imagine that the credit-exposure due

to default risk of the buyer is the largest. We therefore try to make a business case

by finding a payment method where the transaction cost is lower then the price of

the default risk of the buyer. This would reduce the premium which the seller has

included in its pricing of the product and a win-win is apparent.

B(uyer) Bank B

2. Payment

Clearing Eventual surplus

Eventual shortage

Bank S Eventual surplus

Eventual shortage

3. Netting 2. Payment

S(eller)

2. Payment 1. Product

Figure 1: A traditional Business-to-business payment.

2.2 Technology and product design specification

There exists payment schemes for Customer-to-merchant where the bank does not

have to process each payment, for example Riverest (1997). These schemes usually

involve probabilistic payments and are efficient for micro amounts. However, the

scope of this thesis is to look at viable Business-to-business payment platforms where

the bank does not necessarily have to process all transactions, whilst being able

to conduct controls on the involved parties. We examine different permissioned

(private) blockchains which is a subset of distributed ledger technology. It can be

observed that the focus of corporations are on permissioned solutions rather then

public. Take for example Quorum which is developed by JP Morgan, Corda by R3,

which is a consortium of banks, and the Hyperledger project, founded by the Linux

foundation that motivates having the focus on these types of platforms. Blockchain

technology is known to possess immutability when it comes to recorded transactions

and tools to prevent double-spending. It is important that the payment system has

good transaction throughput since it could be compared to a centralised solution

which potentially can be solved using payment channels.

3 Blockchain technology

A blockchain is a data structure containing linked blocks. A block at height t in the chain is denoted B

and is identified by a hash (see next subsection) of its header generated by some cryptographic algorithm. The header of a block B

consists of metadata which includes a reference to the previous block, B

, this property motivates the name blockchain. The header can also include a root to a Merkle tree, which is an efficient data verification structure, and a timestamp containing the time of creation. Each block contains a list of transactions which once the block is accepted by the network, by some consensus algorithm, will be broadcasted to the network and included in the blockchain. For more details, see Antonopoulus

(2017).

3.1 Secure hash functions

A hash function hp¨q, is a function that, given a message m, outputs a hash hpmq of the message. This hash could be seen as a fingerprint of the message. An important feature of hash functions is that hpmq will be of a fix length independent of the length of m. For a hash to be secure, we require that it should have good pre- image resistance meaning that given hpmq, it should be impracticable to retrieve m. We also want the function to have collision resistance, that is, it should be infeasible to find m

‰ m

such that hpm

q “ hpm

q. We would also like hp¨q to be computationally cheap and some usual hashing functions for blockchains are SHA2 and SHA3 (Secure Hashing Algorithm). For further reading about hash functions, see Paar & Pelzl (2010).

3.2 Asymmetrical Cryptography

Asymmetrical Cryptography is commonly used for encryption and authentication.

The scheme is based on the fact that the involved participants has generated a per-

sonal key-pair, k “ pk

, k

q. If Alice would like to send a secret message, m, to Bob,

Alice would do this by requesting Bobs public key k

pBq and encrypt m with it,

B

pmq. When Bob receives the message, he would decrypt it with his private key,

k

, obtaining m. Meanwhile, any eavesdropper would only see Bobs public key as

well as the encrypted message. Observe that the public key is not able to decrypt

B

pmq. Asymmetrical Cryptography is widely used in blockchain technologies for

authentication purposes. The cryptography used in Bitcoin and Ethereum is Elliptic-

curve cryptography (ECC).

Given a randomly generated private key, k

P r1, q ´ 1s where q P Z

, a public key k

“ k

G is generated, G being a so called generator point lying on an elliptic curve,

E : y

` a

xy ` a

y “ x

` ax

` a

x ` a

,

where ~a “ pa

, a, a

, a

, a

q P F

, F

being a field. Elliptic arithmetic differs depend- ing on the characteristic of the curve and the field of which it is being evaluated over. In the case of Ethereum and Bitcoin, they both follow the standard secp256k1 which defines recommended parameters for use with ECC. The recommendation is

to use #

q “ 2

´ 2

´ 2

´ 2

´ 2

´ 2

´ 2

´ 1,

~a “ p0, 0, 0, 0, 7q

along with a specific generator point which together with other details can be found at Certicom Research, (2010). The resulting curve is therefore E : y

“ x

` 7.

Elliptic point multiplication given a known point, P “ px

, y

q can be carried out by the following algorithm as presented by Hankerson et al. (2004):

Given k represented in binary, pk

, ..., k

, k

q

, k

P t0, 1u for i “ 0, 1, ..., t « log

pqq.

1. Set Q – inf.

2. For i from 0 to t ´ 1 do:

2.1. If k

“ 1, set Q – Q ` P . 2.2. P – 2P.

3. Return(Q)

The above return is kP . The elliptic point addition in (2.1) given the parameters in secp256k1 is carried out in the following way:

Q ` P “ px

, y

q “

˜ ´ y

´ y

x

´ x

¯

´ x

´ x

, y

´ y

x

´ x

px

´ x

q ´ y

¸ . The point doubling occurring in step 2.2, again with the parameters of secp256k1, is defined as the point

px

, y

q “

˜ ´3x

2y

¯

´ 2x

, ´3x

2y

¯ px

´ x

q ´ y

¸ .

Once a user has generated a public key, k

, he or she may sign a hashed message,

h pmq, by using the ECDSASIGN method. Together with a signature verification signa-

ture ECDSARECOVER, the receiver can be sure that the sender (and signer) has indeed

signed the message. For more details concerning elliptic curves and its arithmetic as

well as details about the ECDSA-algorithms, see Hankerson et al. (2004).

3.3 Merkle trees

A Merkle tree is a data structure that is used when it is necessary to efficiently verify the integrity of stored data. They contribute to the blockchain by structuring the transactions in a tree. The structure can be described as a tree with branches, b.

The "main" branch b

, also known as the root, is connected to b

, b

by their concatenated hashes. That is,

b

“ hpb

` b

q, where the branches

´

b

, b

¯

“ ´

h pb

` b

q, hpb

` b

q ¯ . This binary branching continues down to

b

“ hpT

q, ..., b

“ hpT

q,

where T

is transaction i P t1, ..., nu recorded in the block in the case of a blockchain.

For more information about Merkle trees, see Merkle (1982).

This data structure allows for efficient comparison of data. Say that we would want to audit T

and have a Merkle root b

. We would then only need to be given the hashes b

, b

and b

whereby we would produce b

“ hphpT

q ` b

q, followed by b

“ hpb

` b

q and finally compare hpb

` b

q with the Merkle root b

. By this methodology we have showed whether the transaction of interest is indeed in the Merkle tree with root b

or not without comparing the transac- tions explicitly. The marginal benefit of comparing data implicitly in this way is of course increasing in size/complexity of the transactions. In general, it takes log

pnq branches to verify that a (hashed) transaction hpT q P b

.

3.4 Transactions

A transaction in a blockchain is typically represented by an input and one or several outputs. The input in a transaction consists of unspent transaction output (UTXO) and is considered used by the payer once the transaction has been accepted by the network. The spent transaction output for a sender will become UTXO for the receiver of the payment which the receiver can prove with an attached hash.

However, in technologies such as Ethereum, the function of UTXO does not exist,

instead, the blockchain is a state that stores a list of account balances. If a sender

wish to send tokens, the blockchain will only credit the receiver and debit the sender if the account balance of the sender is at, or above, the needed amount. For a limited comparison between UTXO and state, see Ethereum

(2017).

3.5 Smart contracts

Smart contracts were first theorised by Nick Szabo in 1996. He described a smart contract as "... a set of promises, specified in digital form, including protocols within which the parties perform on these promises", see Szabo (1996). From basic con- tract design point of view, Szabo highlights that a contract should be observable, verifiable, privity and enforceable. In the context of blockchains, a smart contract is computer code executable by the participants in the blockchain. It is recognis- able that the keywords by Szabo still is of importance, as the smart contract on a blockchain might control valuable tokens.

One of the most widely used platform for smart contracts is the Ethereum platform (see section 5.1). A smart contract takes the form of EVM-bytecode in Ethereum.

Instead of programming in EVM-code directly, one could for example use the pro- gramming language Solidity which compiles to EVM-code, ready to be uploaded onto the blockchain.

A smart contract which can verify a signature is depicted in figure 2. The contract can be uploaded by whomever and can be run without reading or modifying the current state, as declared by the pure flag in the function check. The same function is public which means that it is callable by both the contract itself or via messages. The func- tion check takes an Ethereum signature splitted up in four parts, ph, v, r, sq, where h is a hash of the message, and an address which it will compare the signature to as input. The web3.js implementation of ECDSASIGN from section 3.2 takes the message one wish to sign and prepends the string "\x19Ethereum Signed Message:\n32"

which is why we must modify the hash so that the ECDSARECOVER implemented in

Solidity is able to verify the signature. The return of the function check, in the

contract checker, is a boolean variable indicating whether or not sender has signed

the hashed message h. For details about Solidity and the web3.js library, see Solidity

(2018) and web3.js (2018) respectively.

Figure 2: A signature verification contract written in Solidity.

3.6 Oracles

Oracles are the link between the deterministic blockchain network and the outside world. An oracle could take the shape of smart contract that fetches data from some sensor, potentially from an assembly line. In financial applications, an oracle could for example deliver exchange rates for a currency pair. Since events in the world could take on multiple interpretations, the oracle should be a trusted party or, possibly, there should exist numerous oracles monitoring the same event from which consensus can be reached.

4 Consensus Algorithms

A network participating in a decentralised blockchain, where the participants might be mutually distrustful, uses consensus algorithms to agree on what block to append next to the chain. Since some partaker might be malicious, the consensus algorithms should be tolerant against faults. In this section we will briefly go through four consensus algorithms, some better suited for permissioned blockchains. Desirable traits for a consensus algorithm is finality, tolerance against faults, high transaction throughput and low latency.

A blockchain is said to have consensus finality if a block making participant appends

B

before B

while no other block making participant is able to append the blocks

in reverse order (assuming that the block makers are non-adversary). We say that

a fault that shows different symptoms to different participants is called a Byzantine

fault. The faults are assumed to be arbitrary.

4.1 Proof of Work

Satoshi Nakamoto presented proof-of-work, a distributed consensus algorithm, in his white paper on the first blockchain, Bitcoin. The algorithm lets its nodes build blocks of transactions, B

, and manipulating nonce while repeatedly calculating h pB

q, which would become the blocks identifier, until the hash, hpB

q, begins with a number of zero bits. The number of initial zero bits is exponential in the average work of hashing required, resulting in a "one-CPU-one-vote"-system. The first node to construct a block with an accepted hash will broadcast its block to the other nodes in the network whereby the nodes start mining a new block. As more blocks are appended in the blockchain and their hashes are back linked to each other, it requires more hashing power to change the content of B

. If B

is located at height t and the B

“ B

, manipulating B

would require redoing n ` 1 hashes and potentially even more as newly created blocks is accepted by the network during the time of the attack. The difficulty (number of initial zeros in the hash) in the case of Bitcoin is controlled by a moving average so that an average number of blocks that should be mined per hour is held constant. To motivate miners to use their CPU-power for mining, an amount of bitcoin is rewarded to the first miner to find h pB

q. For more information, see Nakamoto (2009).

4.2 Proof of Stake

The proof-of-stake algorithm is built around the idea that the more stake in the system, the more influence. The network picks a node based on its stake in the net- work, for example wealth, to build the next block in the chain. With a deterministic wealth-based stake the blockchain would by extension end up being centralised which is why randomness is implemented. A proof-of-stake scheme is used in Peercoin where stakeholders can create the next block in the chain according to the same principles as in proof-of-work, but in a limited search space. The search space is proportionate to the amount of unspent output by the rule "one hash per unspent wallet-output per second", reducing the amount of energy needed for mining blocks considerably com- pared to a proof-of-work scheme. As King and Nadal (2012) presents, if an attacker were to try to fend off a transaction from entering the chain, its coinage would be spent and continuing to prevent the transaction might become increasingly difficult.

To motivate minters in a proof-of-stake blockchain, a reward is granted for each new

block added to the chain in similar to the proof-of-work consensus.

4.3 Practical Byzantine Fault Tolerance

Castro and Liskov presented a replication algorithm in 1999 which tolerates pn ´ 1q{3 simultaneously byzantine faulty nodes out of n. The advantage of PBFT against earlier applications is that the method is usable in asynchronous environments and holds improved response time. A new rendering intended for blockchain use is Is- tanbul BFT. A block in a IBFT consensus blockchain is created by the following protocol; A proposer collects transactions and generates a proposal block. This block is transmitted to validators who either approve the block or not. Once each validator has received at least 2pn ´ 1q{3 ` 1 block confirmations, they transition from a pre-prepare state to prepare state. In the prepare state, the validators resend confirmations and once 2pn ´ 1q{3 ` 1 confirmations has been received, they enter a committed state. Once in a committed state, the validators appends the received confirmations and inserts the block into the blockchain. Finally, the validators pick a new proposer and a new round is commenced as described by Lin (2017). It is also interesting to note that the basic PBFT protocol requires Opnq messages for n nodes to reach consensus according to Bano et al. (2017). A high level compari- son between Byzantine Fault Tolerance and proof-of-work consensus was published by Vukolić (2016). Vukolić notes that BFT consensus algorithms have potential to scale up to thousands of clients while it has limited scalability in terms of nodes (validators/proposers in Istanbul). Moreover, BFT consensus has the potential of high throughput and consensus finality.

4.4 Raft

Raft is a consensus algorithm where a subsection of nodes, servers, participate in

a lottery for leadership. Once a leader is chosen for a term, it services clients by

appending their transactions to the leadership log. A log entry is committed once

the leader has replicated the entry on a majority of the servers. When a new term is

approaching, followers candidate for leadership and the winner is appointed leader

for the next term while the losing candidates as well as the former leader are demoted

to followers. This ensures that there is always a block maker, however, as Raft does

not possess byzantine fault tolerance, this consensus algorithm is used exclusively in

permissioned blockchains where trust is established among the servers. For a general

technical report on Raft, see Howard (2014) and for the white paper, see Ongaro and

Ousterhout (2014).

5 Blockchain implementations and State channel tech- nology

5.1 Ethereum

Ethereum is a turing-complete blockchain in the sense that it has a programming language which allows the creation of smart contracts. There are two types of ac- counts in Ethereum, externally owned and contract accounts. The externally owned accounts are controlled by a private key that ensures the identity of the user whereas the contract accounts are autonomous agents which will act on message inputs, exe- cute its embedded script and deliver outputs. The sender of a transaction will include a fee inciting miners to register the transaction onto the blockchain since Ethereum uses proof-of-work for consensus. The Ethereum community is discussing whether to implement a proof-of-stake scheme or not, see Casper

(2018), to improve scalability as well as reduce the risk of centralisation. In the case of a permissioned Ethereum chain, it would be initialised with a set of trusted users, according to Casper

(2018).

5.2 Quorum

There exists a lot of implementations built on the Ethereum platform, one of which is developed by J.P. Morgan, namely Quorum. Quorum is an open source, permis- sioned blockchain designed to process both private and public transactions with high throughput and speed, see Quorum

(2018). Public transactions in Quorum is in- herently treated in the same way as in Ethereum, in a shared blockchain. Private transactions are managed via a constellation network which is a peer-to-peer system.

The sender of a private transaction will order its node to encrypt the message and

some nonce using a generated symmetric key. The node will generate a SHA3-512

hash of the encrypted message, go through the prospective recipients and encrypt

the symmetric key with the recipients public key using PGP-encryption. The node

will then, using the peer-to-peer system, transfer the hash of the encrypted message,

the encrypted message and the encrypted symmetric key. The node of the receivers

will then decrypt their respective symmetric key using their private key, decrypt the

encrypted message using the newly revealed symmetric key until it matches the hash

and the message has been revealed. Once the sender has received response from all

the recipients, a transaction with payload equal to the hash of the encrypted message

will be propagated to the network via the public blockchain. Therefore, only par-

ticipants to the transaction knows of its content while other nodes, not party to the

transaction, only sees the hash. This could be problematic since the blockchain is

used to determine what the current state of the nodes are, which is why two Patricia- Merkle trees are used, one for the public state per standard Ethereum, and one for its private states.

Quorum has in its upgraded version (2.0) implemented Istanbul byzantine proof tol- erance and Raft for consensus. More information can be found at Quorum

(2018) and Quorum

(2017).

5.3 Corda

Corda is a permissioned peer-to-peer network of nodes, launched by the banking consortium R3, where access to the network is controlled by a doorman. If a node wishes to join the network, it must provide sufficient information to the doorman.

If the doorman approves entry to the network, it will hand over a token proving the identity of the node and through that, enabling peer-to-peer messaging. In Corda, all communication between nodes is direct and no global broadcast is possible.

Smart contracts are captured in the broader definition CorDapps, that broadens the capabilities of the platform, for more information about smart contracts in Corda, see Corda (2016). Because Corda is a distributed ledger technology and therefore has no central store of data. If two nodes where to compare its data, it would compare its own database to the other and only see the intersection of their data since all communication is peer-to-peer, this intersection is guaranteed to be identical from both parties perspectives by consensus explained below. This is a major contrast to public blockchains like Ethereum and Bitcoin where all transactions are public in the blocks created, but inline with how private transactions in Quorum are handled.

A transaction between a buyer and a seller is valid if the chain of transactions leading up to the new transaction is valid. This is checked by the buyer by requesting the so called transaction chain from the seller and checking its validity. If a transaction is to be committed to the ledger, it has to be checked for double spend, which is done by notaries. A notary approves a transaction if it has not given approval for any of the proposed transaction’s input states. If a double spend attempt is detected, the notary will flag the transaction. Thus, the notary provides transaction finality.

Corda has different consensus for the notaries to chose from. For a more detailed explanation, see Corda (2018).

5.4 Hyperledger Fabric

Fabric is a blockchain technology initially developed by IBM and now hosted by The

Linux Foundation. It holds modular consensus similar to Quorum and Corda (see

above). Smart contracts in Fabric is called Chaincode and is uploaded and executed on the blockchain via transactions. States changed by Chaincode can only be accessed by other Chaincode if permission for it exists and both of the contracts are uploaded on the same network. When two parties are to transact with each other, they will open a channel where a ’MSP’ (Membership Services Provider) will authenticate the peers and provide the parties with identities. At this point, a genesis block for the specified channel is created and if another party were to join the channel at a later time, they would be provided with the latest block in the chain.

There are three types of nodes in Fabric; clients who submit transactions, peers who receives blocks from orderers and therefore holds a copy of the ledger. A peer can also take the roll of an endorser who receives transactions from clients, simulates them and if a transaction is valid, sign it. Once the submitting client receives enough endorsement signatures, it will broadcast the transaction along with the signatures to the orderers which is the last node-type. The orderers form blocks of the endorsed transactions it receives and link them to the prior block and thus, a hash chain (blockchain) is formed. The orderers can be implemented in different ways, either centralised or decentralised which in the latter case involves consensus algorithms.

Once a block is broadcasted from the ordering service, peers will change state and update their ledger. For details, see Fabric (2018).

5.5 Scalability

Permissionless proof-of-work blockchains such as Bitcoin and Ethereum suffer from scalability problems in terms of speed and throughput. One way of improving this is by offloading some transactions from the blockchain while keeping the security. This is called payment channels and is, for example, used in Lightning and Raiden. The disadvantage of this method is that it uses repeatability, that is, it is only profitable, in terms of transaction cost and throughput if the transacting parties are recurrent.

Another idea of tackling the problem is to split the blockchain into a number of subsets where each subset is running its own chain. This solution is called sharding and has the apparent challenge of cross-shard transacting. For further reading about sharding, see Ethereum

(2018).

5.6 State channel technology

State channel technology, also known as payment channels, is a partial answer to

the scalability problem of blockchains. In the simplest case where Alice wishes to

transact with Bob repeatedly, Alice could set up an escrow containing x in a smart

contract and commit this transaction to the blockchain. Alice would then commu- nicate this transaction to Bob who now knows that Alice is credible up to x. Now Bob might do some work for Alice and be credited along the way. For each ware w

, i “ 1...N, each with cost 1, Bob is producing, Alice would sign a transaction Alice : x ´ i, Bob : i and send this to Bob. Bob would check that it is in fact Alice’s signature and therefore be sure that he is not being cheated out of his money. Once Bob has stopped getting payed, he will simply broadcast Alice’s signature along with his own to the smart contract published by Alice. This settles the transaction as the smart contract distributes the holding of the escrow according to the message signed by both Alice and Bob and broadcasts the new balances to the blockchain.

Alice has set a timer on the smart contract which once the timer is depleted, would return the funding, the escrow, to Alice. This prevents Bob from holding the escrow hostage by not producing any work for Alice. As Bob knows the value of the timer, he should feel safe that he is able to broadcast the signatures before the deadline.

Most importantly is that with only two transactions to the blockchain, Alice and Bob are able to transact N times off-chain up to the value of the escrow, maintain- ing the security of the blockchain. For more advanced payment channel schemes, see Antonopoulus

(2017). A payment channel scheme, in the setting of the traditional Business-to-business payment in figure 1, is illustrated in figure 3.

A segment of an example code of the smart contract depicted in figure 3 is showed in

figure 4. The code is written in Solidity for EVM. Firstly, the bank would upload the

contract and define seller and buyer along with an unique ID for the channel. This

would provide cover against two recurrent parties sending in signatures from prior

transactions. We do not want the smart contract to hold any balances because of

regulatory reasons, see section 6. The contract should also have a timer as explained

in prior paragraphs. Secondly, the buyer would produce its signature by signing the

hashed string channelID ` value and send it to the seller which would check the

signature with the ECDSARECOVER-algorithm explained in section 3.2. Once the seller

wish to settle the channel it would transmit the signature of the buyer as well as its

own signature applied to the same string to the contract whereby the bank would

settle the channel by transferring fiat money accordingly.

B(uyer) Bank B

8’ 1

Clearing Eventual surplus

Eventual shortage

Smart contract Payment channel

2 7

Bank S Eventual surplus

Eventual shortage 9

7

S(eller)

4*

5*

3

6

8

* is done repeatedly

1. Request & reserve capital 2. Creates payment channel 3. Sees available balance 4. Product*

5. Token*

6. Token(s) 7. Done 8. Payment

8’. Eventual residual post 9. Netting

10. Settlment

Figure 3: Proposed Business-to-business payment.

Figure 4: A segment from a payment channel contract written in Solidity.

6 Financial implications

Given the setting in figure 3, we wish to examine the willingness to pay for such a scheme. Say that a company B (buyer) wish to transact with another company S (seller). B would like to buy q ° 0 pieces of a good, each priced at p ° 0. In normal operations, S would send an invoice for a payment, P

“ qp to B at a time t

, with a deadline, T , for when the payment is due. During this time, S will be exposed to default risks of B, BapBq and BapSq where we assume that the default risk of B, d pB, t

, T q, during t P rt

, T s, is the largest and Bapxq is the bank of customer x.

This is included but not visible in the pricing, p “ p

`p

pdpB, t

, T qq, where p

is the price of the product if S had zero credit risk towards the buyer and p

pdpB, t

, T qq is the premium demanded by S for the risk that B will default before the payment is settled.

Say that the buyer has the required cash at time t

but decides to pay at time T , then B has earned interest on the money, equal to qppe

´ 1q where r

is the company’s return on capital. The effective price for B at time t

is thus e

qp p2 ´ e

q whilst the seller is receiving (discounted back to t

):

# qpe

, with probability 1 ´ dpB, t

, T q,

§ qpe

, with probability dpB, t

, T q,

at time T where r is the return in the market. We will therefore propose the following scheme which tries to reduce p by limiting the credit exposure of the seller by using a payment channel.

Instead of sending an invoice from S to B, we propose that B query its bank BapBq to open an unidirectional payment channel from B to S, C

pt

, T, N q, during the time-interval rt

, T s for amounts up to N. The payment channel is as described in section 5.6 with some modifications:

If the banks would emit tokens equal to banknotes onto the payment channel in section 5.6, the holders of the tokens would possibly be able to transact with any- body and regulatory frameworks might be violated. Therefore, the escrow is only accessible by BapBq and BapSq instead of B and S. The banks will only transfer money from the escrow to the companies respective accounts if signatures from both of the transacting parties are received. If no or just one signature is received at the terminal time, T , the bank would demand the missing signature(s) from S, and if none were to be received, the bank would transfer the value of the escrow back to B.

Ba pBq will only open a payment channel if the following conditions hold true:

# B and S are approved to transact.

N is either moved from B’s bank account or B takes a loan of N.

Ba pSq will only credit the bank account of S once the transaction is completed if it is sure that it can withdraw the same amount from the escrow at that time. Hence requirement two for BapBq above. BapSq also expects to be compensated for the increased risk exposure towards BapBq which should be small. Looking closer, we see that if B would deposit N “ qp into an escrow at time t

, B could miss out on Npe

´ 1q and therefore might expect to be compensated, however, this payment system would allow B to transact using business models like Pay-per-use which otherwise weren’t possible. Bear in mind that B will always trade via channel if B is illiquid and could potentially sell or refine the purchased good as they come into its possession.

As S would not be exposed against the default of B, as well as getting payed q

p at t

§ T where q

P t0, 1, ..., qu for some cost, for early withdrawal from the escrow. S would be willing to pay a premium for such a service. If S would cash out at t

§ T when the channel has transferred N funds, that is the channel has 0 transferrable funds left, C

pt

, T, N q “ N, S would gain P

“ qpe

• qpe

. Since the expected payment in the standard system is

EpP

q “ qpe

p1 ´ dpB, t

, T qq ` xdpB, t

, T q, where x P r0, qpe

s,

we see that

EpP

q “ qpe

• EpP

q.

Because of the decreased credit risk of S, as well as the possibility of obtaining the payment earlier, S could potentially price its product down to p “ p

which of course would benefit the buyer, B. Therefore S could be willing to compensate up to

p

EpP

q ´ EpP

q

p ` p

pdpB, t

, T qq • 0.

Hence, there exists a case where the seller is willing to compensate monetarily for the new features which could be used to fund the premium B and BapSq could potentially demand.

6.1 A model for the banks involved

We wish to model the required balance of an escrow, E

ptq between two banks, Ba pSq, BapBq in one direction at a given time t. The amount E

ptq is the balance Ba pSq are able to withdraw from BapBq and there exists another escrow in the op- posite direction. We will assume that netting is not possible in this model but could be expanded in eventual later research. The following assumptions are proposed:

We assume that at each time interval, t, n

channels are created in each di- rection. The total number of created channels follow a homogeneous Poisson point process tNptq, t • 0u. This process is defined as:

$ ’

&

’ %

N p0q “ 0,

N pt

` t

q ´ Npt

q and Npt

` t

q ´ Npt

q are ind. @t

: 0 § t

† t

† ... † t

, n • 1.

The number of occurences, X, in any interval t, X „ P oip tq

Thus, the number of created channels in a period, defined as p

“ tt P pt

, t

s}, is: (1)

n

pt

, t

q „ P oip pt

´ t

qq. (2) We cannot see the status of a channel, C

pt

, T

, N

q, created at time t

with terminal time T

and nominal (maximum) amount N

, during t P pt

, T

q. However, since the used funds in a payment channel is monotonically increasing, we model the used funds, C

pt

, T

, N

q, with three different functions. These functions should represent different behaviours and the following are chosen:

$ ’

’ &

’ ’

%

C

pt

, T

, N

q “ 1 ´ pp

q ´ 1q

C

pt

, T

, N

q “ p

q

C

pt

, T

, N

q “ p

q

(3)

Furthermore, we assume that the probability of the creation of a channel, C

pt

, T

, N

q, at a time, t

, follows an exponentially distributed random variable. That is, Ppt

P pt

, t

sq „ expp

q. Also, a channel closes at a time t

“ t

` t

T

where t

„ pa, bq. In reality, there are three cases for when a channel should be closed,

$ ’

&

’ %

1. C

pt

, T

, N

q “ N

2. C

pt

, T

, N

q † N

, at a cost w 3. t

“ T

.

(4)

We will assume that this is captured by the parameters a, b. The number of active channels n

ptq, at time t, is therefore

n

ptq “ n

pt

, t q ´

nc

ÿ

pt

§ tq, (5)

and the expected number of active channels are

Ern

ptqs “ pt ´ t

qp1 ´ Ppt

§ tqq. (6) Therefore, we wish to find the distribution of t

“ t

` T

t

and since

F

k

ptq “ Ppt

§ tq “ ª

0

u

p1 ´ uq

B

pa, bq du, B

pa, bq “ paq pbq

pa ` bq , (7) pzq “

# pz ´ 1q! if z P Z ≥

0

x

e

dx otherwise. (8) we can derive the probability density function of t

as follows,

f

puq “ 1 T

f

k

p u ´ t

T

q “ p

q

p1 ´

q

T

B

pa, bq . (9)

This is because

F

puq “ Ppt

§ uq “ Ppt

` t

T

§ uq “ Ppt

§ u ´ t

T

q “ F

p u ´ t

T

q. (10) Applying the chain rule to equation 10

f

puq “ F

puq “ d du F

k

p u ´ t

T

q “ f

p u ´ t

T

q d du

u ´ t

T

“ f

p u ´ t

T

q 1 T

. (11) Thus, the expected number of active channels from equation 6,

Ern

ptqs “ pt ´ t

q ´ 1 ´

ª

p

q

p1 ´

q

T

B

pa, bq du ¯

. (12)

6.2 Optimisation

The involved banks are interested in minimising the cost of the payment channels A pr, p

q⇠pp

, E

q, which is done by holding an adequate amount in the escrow E

pp

q at all times. We let Apr, p

q denote the alternative cost of capital which depends on the interest rate of the market r. The banks may rebalance their escrow balance at discrete times, t

P rt

, ..., t

s where they in each period tries to minimise the needed capital ⇠pp

, E

q, p

, being the time between t

and t

and

⇠ pp

, E

q “ fpn

, N

, ..., N

q ¨ ´

E

pp

q § wpp

q ¯

` E

pp

q. (13) In the above expression we let f be a fee payed for overdrawing which, if triggered, should also rebalance the collateral so that it survives until the end of the period and let wpp

q represent accumulate withdrawals under period i, that is,

w pp

q “

na

ÿ

k“1

N

C

¨ pt

§ t

q. (14) We will minimise equation 13 by minimising the expected value:

Ep⇠pp

, E

qq “ f ´

1 ´ P ´

E

pp

q ° wpp

q ¯¯

` E

pp

q. (15) We will focus on the probability in equation 15, which we will model by standardised payment channels, that is N

“ N@k,

P ´ ÿ

k“1

C

¨ pt

§ t

q § E

pp

q{N ¯

“ ÿ

P ´ ÿ

k“1

C

¨ pt

§ t

q § E

pp

q{N | n

“ j ¯ . If we assume that the system is run on maximum capacity, that is n

“ n is fixed at (16) some constant n, we can find a first order approximation by letting Ppn

“ nq “ 1.

We let n “ Ern

ptqs from equation 12 and we get that the right hand side of equation 16 is,

P ´ ÿ

k“1

C

¨ pt

§ t

q § E

pp

q{N | n

“ n ¯

“ P ´ ÿ

k“1

C

¨ pt

§ t

q § E

pp

q{N ¯

Ppn

“ nq “

“ P ´ ÿ

k“1

C

¨ pt

§ t

q § E

pp

q{N ¯

, (17)

which we will see can be approximated with Lyapunov’s Central Limit Theorem.

Theorem 6.1. Lyapunov’s Central Limit Theorem. Given X

, X

, ..., X

indepen- dent random variables, each with EpX

q “ µ

, V pX

q “

. Given that Lyapunov’s condition holds for some ° 0:

nÑ8

lim 1 s

ÿ

E ”

|X

´ µ

|

ı

“ 0,

where s

“ ∞

i

, then 1 s

ÿ

pX

´ µ

q Ñ Np0, 1q in distribution as n Ñ 8.

Applying this to equation 17, we need to find for l “ 1, 2:

E ”

pC

q

pt

q ¨

pt

† t

§ t

q ı

“ ª

´8

C

puq ¨

pt

† u § t

q ¨ f

puqdu (18) The the integral in equation 18 turns to:

ª

t_i´1

pC

q

puq ¨ f

puqdu “ ª

t_i´1

pC

q

puq p

q

p1 ´

q

T

B

pa, bq du “

“ !X “ u ´ t

dX “ du ) “

ª

pC

q

pX ` t

q p

q

p1 ´

q

T

B

pa, bq dX, (19) which if we simplify further, taking b “ 1 and l “ 1, 2, we have that for j “ p2, 3q corresponding to m “ p1, 2q

$ ’

’ &

’ ’

%

µ

“ ≥

t_i´1´t⁰_k

p

q

dX “

≥

t_i´1´t⁰_k

X

dX p¯

q

“ ≥

t_i´1´t⁰_k

´

¯

Tkq^a´1

TkB1pa,1q

dX “

k

≥

t_i´1´t⁰_k

X

dX

(20)

Where p¯

q

is the non-central second moment. Setting t

“ t and t

“ t ` gives us equation 21, provided that we chose a °

.

$ &

%

µ

“

” pt ´ t

` q

´ pt ´ t

q

ı p

q

“

k p2m`aq

” pt ´ t

` q

´ pt ´ t

q

ı

´ µ

(21)