Secure and Efficient Implementation of Electronic Money

Abstract

During the last years, central banks have discussed possible use of central bank digital currencies (CBDC) – electronic cash. Besides the financial and economic factors also the security and scalability of technical implementation of CBDC have been studied. Blockchain technology provides high level of security independent of the technical infrastructure and enables central banks to outsource most of the CBDC operations to the private sector while still having full control over the total amount of CBDC in circulation. Scalability of blockchain solutions depends on the possibility of decomposing (sharding) the blockchain. Electronic money and payments can be represented and organized in several ways, including accounts, bills/coins, and also unspent transaction outputs (UTXOs). We show how the representation of money and payments influences the existence of secure and decomposable blockchain implementations of electronic money. We show that the bill money scheme can be securely and efficiently implemented as sharded blockchains.

1 Introduction

During the last years, central banks have discussed possible use of central bank digital currencies (CBDC) – electronic cash. Besides the financial and economic factors also the scalability and security of technical implementation of CBDC have been studied. Blockchain technology provides a high level of security independent of the technical infrastructure and enables central banks to outsource most of the CBDC operations to the private sector while still having full control over the total amount of CBDC in circulation. The security measures may depend on whether the blockchain solution is public (permissionless) or private (permissioned). Private blockchains are less costly but their security needs somewhat more care as some type of insider attacks have to be considered.

Scalability has been the biggest technical concern of using blockchain-based CBDC. Nation-wide deployment of electronic cash requires service rates of ten to hundred thousands transactions per second while blockchain money solutions like Bitcoin only offer the rate of few dozen transactions per second. The key of filling the scalability gap is the possibility of decomposing (sharding) the blockchain. The efficiency of decomposition highly depends on the need for inter-component communication. For example, whenever two accounts are in different components, paying from one account to another requires two simultaneous operations in both components: debiting one account and crediting the other. This is technically challenging as it requires solving the atomic commit problem (often called “two generals problem”), which has no deterministic time solutions if possible message loss is considered. On the other hand, if we imagine a single coin or bill given by one person to another, the only parameter that changes is the ownership of the coin/bill. Such operation is atomic by definition. Hence, if an electronic money solution uses coins and bills to represent money and is sharded so that some coins and bills belong to one shard and others to another shard, then every single coin payment is uni shard and does not require inter shard communication. We explain the implications of a general composition theory of money schemes [1] about how the possibility of efficient sharding depends on the choice of the money scheme (accounts, coins, etc.). One implication of the theory is that blockchain-based implementations of account money schemes are to hard efficiently and securely, while bill based money schemes have efficient and secure sharding mechanisms.

This work focuses on the security of sharded blockchain implementations of the bill money scheme considering that the blockchain is used in a permissioned and controlled scenario by the central bank. However, we consider the possibility that the central bank can outsource most of the service machinery to the private sector. The security of the solution is based on special types of lightweight user-initiated audit protocols that are executed during every payment. The goal of the audit procedure is to verify that each particular bill is properly used, i.e., all the ledger rules are fulfilled. We study two types of audit protocols:

• 1. Full audit – if successful, guarantees that the ledger rules are followed

• 2. Probabilistic audit – guarantees that any deviation from ledger rules will be detected very soon. The motivation behind probabilistic audit is that the communication complexity of the audit protocol is reduced.

The existence of communication-efficient probabilistic protocols seems to depend on the chosen money scheme and the blockchain certification scheme. We show that such protocols exist in the KSI-Cash CBDC solution [2] that is based on the bill money scheme, i.e. simulates the use of physical cash. It remains an open question if efficient probabilistic audit protocols exist for other money schemes.

In Sects. 2 and 3, we explain money schemes and the decomposability of payments. We formalize the implementation of money schemes and investigate their blockchain implementations in Sects. 4 and 5. In Sect. 6, we show that the bill scheme has atomic decompositions – and the account and UTXO schemes do not. In Sects. 7, 8 and 9, we discuss diverse security aspects of blockchain implementations. In Sects. 10 and 11, we describe KSI-Cash and its user side probabilistic audit. We finish the paper with the mentioned open research question in Sect. 12.

2 Money Schemes

A money scheme [1] describes the representational aspects of money and payments. Money can be represented as a set U of units and a value function $\nu : U \rightarrow \mathbb {N}$ that defines for each unit $u\in U$ its value $\nu (u)\in \mathbb {N}$, where N is the set of natural numbers. The units may be accounts, bills, UTXOs, etc. Payments represent the change of ownership of money and hence, it is also necessary to model the ownership. For that, a second function $\beta : U \rightarrow \mathbb {B}$ is introduced that assigns for each unit $u\in U$ its owner (bearer) $\beta (u)\in \mathbb {B}$, where $\mathbb {B}$ is the set of all potential bearers.

A triple $M=(U, \nu , \beta )$ is called a money distribution because it describes the units with their values and ownership. In such a model, we define the total amount of money as $\sigma (M)=\sum _{u\in U}\nu (u)$, and a money owned by a bearer $b\in \mathbb {B}$ by $\sigma (M, b)= \sum _{u\in \beta ^{-1}(b)} \nu (u)$. Money distribution is only a static picture of money and does not distinguish different money schemes. What makes the most important technical difference between money schemes are the payments – transactions P that change the money distribution, but preserving the total amount of money.

Formally, a money scheme is a pair $(\mathscr {M}, \mathscr {P})$, where $\mathscr {M}$ is the set of all allowed money distributions and $\mathscr {P}$ is the set of all allowed payments – functions fof type $\mathscr {M}\rightarrow \mathscr {M}$. We make a natural and intuitive assumption that for every $M\in \mathscr {M}$, there exists a composition $P=P_1\circ \ldots \circ P_k$ of payments $P_i\in \mathscr {P}$ such that $\sigma (P(M),b)=0$, i.e. every bearer can always spend all the money he/she owns. This property is called quasi completeness in [1]. We also assume that in every money scheme $(\mathscr {M}, \mathscr {P})$, the identity function $1_\mathscr {M}$ defined by $1_\mathscr {M}(M) = M$ is a payment, i.e. $1_\mathscr {M}\in \mathscr {P}$.

Note that the set $\mathscr {P}$ of payments is not necessarily composition-closed, i.e. a composition $P=P_1\circ P_2$ of payments $P_1,P_2\in \mathscr {P}$ is not always a payment. From practical implementation view-point, payments represent transactions that are initiated by payment orders sent to the money and payment system by its users. If two users send their payment orders $P_1, P_2$ to the system, then the money and payment system does not necessarily accept “composite” payment orders the execution of which is equivalent to applying $P_1\circ P_2$ to the current money distribution.

In account money schemes, payments change the values $\nu (u)$ and $\nu (v)$ of two units (accounts) $u,v\in U$ so that in the resulting money distribution $P(M)=(U', \nu ', \beta ')$ we have $U'=U$ (no accounts are created or deleted), $\beta '=\beta$ (ownership of accounts stays the same), and $\nu '(u)+\nu '(v)= \nu (u)+\nu (v)$ (total amount of money does not change).

In bill money schemes, payments change only the ownership $\beta (u)$ of a unit u, i.e. in the resulting money distribution $P(M)=(U', \nu ', \beta ')$ we have $U'=U$ (no bills are created or deleted), $\nu '=\nu$ (the nominal values of the bills stays the same), but it may be that $\beta '(u)\ne \beta (u)$.

In UTXO money schemes, payments delete a set $u_1, \ldots , u_m$ of units and create a set $v_1, \ldots , v_k$ units so that $\nu (u_1)+ \ldots + \nu (u_m) = \nu '(v_1) + \ldots + \nu '(v_k)$.

3 Payments and Their Descriptional Complexity

In this section, we describe and categorise all possible types of payments and show how payments can be algebraically decomposed to irreducible payments.

If the current money distribution is $M=(U, \nu , \beta )$, then every payment P can be characterised by three subsets $U^-, U^+, U^0$ of U.

• $U^-$: the set of units that P deletes.

• $U^+$: the set of units that P creates.

• $U^0$: the set of units u the parameters $\nu (u), \beta (u)$ of which are changed by P.

To completely characterise P, it is also necessary to define the parameters of the newly created units in $U^+$ and the way how exactly P changes the parameters of the units in $U^0$, but for the purpose of this section such details are unnecessary.

The descriptional complexity $\Vert P\Vert$ of P is the sum of the sizes of $U^-, U^+, U^0$, i.e. $\Vert P\Vert = |U^-|+|U^+|+|U^0|$. The input complexity $\Vert P\Vert _\textsf{in}$ of P is the sum of the sizes of $U^-, U^0$, i.e. $\Vert P\Vert _\textsf{in} = |U^-|+|U^0|$. For $P=1_\mathcal {M}$, we have $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 0$. In the following, we present three more examples of the complexities of payments:

• Single bill transfer: A payment P that changes the bearer of a single unit u and does nothing else. In this case, $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 1$.

• Account payment: A payment P that changes the values $n_1, n_2$ of two units $u_1$ and $u_2$ to $n'_1, n'_2$ so that $n'_1 + n'_2 = n_1 + n_2$. In this case, $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 2$.

• UTXO payment: A payment P that deletes units $u_1, \!\ldots ,\! u_k$ with values $n_1, \ldots , n_k$ and creates units $u'_1, \!\ldots ,\! u'_\ell$ with values $n'_1, \ldots , n'_\ell$ so that $n'_1 + \ldots + n'_\ell = n_1 + \ldots + n_k$. In this case, $\Vert P\Vert = k+\ell$ and $\Vert P\Vert _\textsf{in} = k$.

A payment P is composition-irreducible if there exist no payments $P_1, P_2$ with $\Vert P_1\Vert<\Vert P\Vert , \;\Vert P_2\Vert <\Vert P\Vert$ such that $P = P_1 \circ P_2$. Clearly, every payment is a composition of composition-irreducible payments. It can be shown [1] that there are the following composition-irreducible payments P with $\Vert P\Vert \le 2$:

• Zero creation – creates a unit with value 0, i.e. $\Vert P\Vert = 1$ and $\Vert P\Vert _\textsf{in} = 0$.

• Zero deletion – deletes a unit with value 0, i.e. $\Vert P\Vert = 1$ and $\Vert P\Vert _\textsf{in} = 1$.

• Single unit transfer – changes the bearer of one unit, i.e. $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 1$.

• Transfer with recreation – deletes a unit and creates a new unit with the same value, i.e. $\Vert P\Vert = 2$ and $\Vert P\Vert _\textsf{in} = 1$.

• Two unit split – creates a new unit and changes the parameters of a unit, i.e. $\Vert P\Vert = 2$ and $\Vert P\Vert _\textsf{in} = 1$.

• Two-unit swap – changes the values and possibly bearers of two units, i.e. $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 2$.

• Two unit join – deletes a unit and changes the parameters of a unit, i.e. $\Vert P\Vert = \Vert P\Vert _\textsf{in} = 2$.

It can also be shown that every payment P is a composition of payments with $\Vert P\Vert \le 2$, and hence, these seven payment types together with the identity payment are the only existing composition-irreducible payments.

4 Money Scheme Implementations by Transition Systems

Money schemes are special cases of transition systems. Every transition system is a pair (S, T), where S is the set of states and T is a set of state transitions (functions of type $S\rightarrow S$) that contains the identity transition $1_S$ defined by $1_S(s)=s$ for every $s\in S$. Transition systems are equivalent to state machines and in this paper we refer to them simply as machines. This is motivated by modelling machine-implementations of money schemes.

Definition 1

(Implementation). A transition system (S, T) implements a money scheme $(\mathscr {M}, \mathscr {P})$ if (Fig. 1):

• 1. There is an interpretation map $\pi : S\rightarrow \mathscr {M}$, i.e. every state s of the machine is interpreted as a money distribution $M=\pi (s)$.

• 2. For every payment $P\in \mathcal {P}$ and every state $s\in S$ interpreted as a money distribution $M\in \mathcal {M}$ (i.e. $\pi (s)=M$) there exists a transition $t\in T$ such that the state $s'=t(s)$ is interpreted as the money distribution P(M), i.e. $\pi (s')=\pi (t(s)) = P(\pi (s)) = P(M)$.

Fig. 1.

Implementation of a money scheme by a transition system (machine).

A decomposition of a money scheme is an implementation of the money scheme with two machines, formally defined as follows:

Definition 2

(Decomposition). Transition systems $(S_1,T_1),(S_2,T_2)$ decompose a money scheme $(\mathscr {M}, \mathscr {P})$ if:

• 1. There is an interpretation map $\pi : S_1\times S_2\rightarrow \mathscr {M}$, i.e. every pair of states $s_1\in S_1, s_2\in S_2$ of the machines is interpreted as a money distribution $M=\pi (s_1,s_2)$ (Fig. 2, left).

• 2. For every payment $P\in \mathcal {P}$ and every pair of states state $s_1\in S_1, s_2\in S_2$ interpreted as a money distribution $M\in \mathcal {M}$ (i.e. $\pi (s_1,s_2)=M$) there exist transitions $t_1\in T_1, t_2\in T_2$ such that the pair of states $s'_1=t_1(s_1), s'_2 = t_2(s_2)$ is interpreted as the money distribution P(M), i.e. (Fig. 2, right)

  $$ \pi (s'_1,s'_2)=\pi (t_1(s_1),t_2(s_2)) = P(\pi (s_1,s_2)) = P(M). $$

Fig. 2.

Decomposition of a money scheme.

Decomposition of a money scheme can also be defined as implementation of the money scheme by the direct product of the machines $(S_1,T_1),(S_2,T_2)$, which is defined as a machine (S, T), where $S=S_1\times S_2$ and $T=T_1\times T_2$ and for every $t=(t_1,t_2)\in T_1\times T_2$ and $s=(s_1,s_2)$ the new state $s'=t(s)$ is defined by $t(s) = (t_1(s_1), t_2(s_2))$.

5 Blockchain Implementations of Money Schemes

By an evolution of a transition system (S, T) is a sequence

$$ (s_0, \tau _0; (t_1,\tau _1), (t_2,\tau _2), \ldots , (t_m, \tau _m)), $$

where $s_0\in S$ is the initial state, $t_1,t_2, \ldots , t_m\in T$ are transitions, and $\tau _0<\tau _1<\tau _2< \ldots < \tau _m$ are real numbers interpreted as timestamps. The final state $s'$ of the evolution is defined by $s'=t_m(t_{m-1}(\ldots t_1(s_0) \ldots ))$. Intuitively, evolution is a description of the execution of the transition system in time.

For security-critical transition systems such as money schemes it is vital to store the evolution and protect its integrity with cryptography. Therefore, certificates $C_0,C_1, C_2, \ldots , C_m$ to the evolution, so that the certified evolution

$$ (s_0, \tau _0, C_0; (t_1,\tau _1, C_1), (t_2,\tau _2,C_2), \ldots , (t_m, \tau _m, C_m)) $$

cannot be maliciously modified without making it cryptographically inconsistent. The certificates also prove the uniqueness of the certified evolution, i.e. it must convince the verifiers that there exist no alternative versions of the evolution.

What is also important for the verifiers is whether they see the whole evolution that includes all transition that have been executed so far, i.e. if verification happens at time $\tau$, then also the fact that no transitions happened in between $\tau _m$ and $\tau$. This suggests a certification scheme, where transitions of the evolution are certified in batches (blocks) in a pre-determined time schedule and the certified evolution being in the form:

$$\begin{aligned} (s_0,\tau _0,C_0; (B_1,\tau _1, C_1), (B_2,\tau _2,C_2), \ldots , (B_m, \tau _m, C_m)) \end{aligned}$$

(1)

where every block $B_i$ represents a composition $t^1_i\circ \ldots \circ t^{m_i}_i$ of transitions. Note that some blocks $B_i$ may be empty and in this case, they represent the identity transition $1_S$. Certified data structures in the form of (1) are called blockchains.

Fig. 3.

Blockchain node.

Blockchain implementation of a transition system (S, T) is a network of machines called a blockchain node that consists of three machines (Fig. 3):

• File repository – stores certified blocks and, on request, provides applications with blockchain data.

• Certifier – regularly (based on clock) creates block certificates based on a cryptographic hash of the block.

• Transaction validator – receives transition orders from applications, verifies them using the current state $s\in S$, combines transactions to blocks, obtains certificates from the certifier, and sends certified blocks to the file repository.

Fig. 4.

Sharded blockchain node.

A blockchain implementation of a composed money scheme with two transition systems $(S_1,T_1)$ and $(S_2, T_2)$ is a network of machines called a sharded blockchain node (Fig. 4). It has two independent transaction validators that implement $(S_1,T_1)$ and $(S_2, T_2)$ and produce sub-blocks $B^1$ and $B^2$, respectively. It also has two file repositories, and a common certifier for both blocks. The blockchain produced by the first transaction validator is in the form:

$$ (s^1_0,\tau _0,\varPi ^1_0,C_0; (B^1_1,\tau _1, \varPi ^1_1,C_1), (B^1_2,\tau _2, \varPi ^1_2,C_2), \ldots , (B^1_m, \tau _m, \varPi ^1_m,C_m)) , $$

where $\varPi ^1_i$ denotes additional information (usually in the form of a hash chain) that helps to verify the blockchain against the certificate $C_i$. Analogously, the blockchain produced by the second transaction validator is in the form:

$$ (s^2_0,\tau _0,\varPi ^2_0,C_0; (B^2_1,\tau _1, \varPi ^2_1,C_1), (B^2_2,\tau _2, \varPi ^2_2,C_2), \ldots , (B^2_m, \tau _m, \varPi ^2_m,C_m)) . $$

For executing a payment P, two transaction orders $t_1, t_2$ has to be sent to the two transaction validators (Fig. 4) and the validators include these transactions to the blocks $B^1$ and $B^2$, respectively.

6 Atomic Decomposition of a Money Scheme

As the blocks have to be produced based on a fixed time schedule, there is a limited time for the validators to decide whether to include $t_1$ and $t_2$ to the blocks $B^1$ and $B^2$. Considering possible message loss and network delays between the transaction validators and applications, it is always possible that only one of the transactions $t_1,t_2$ is received in time (considering the block creation schedule).

It is known that there exist no deterministic time protocols (executed between transaction validators) which ensure that either $t_1\in B^1$ and $t_2\in B^2$, or $t_1\not \in B^1$ and $t_2\not \in B^2$. Such a communication problem is often called the two generals problem. Therefore, it is possible that $t_1\in B^1$ but $t_2\not \in B^2$ and vice versa. In transition system terms, instead of executing $(t_1,t_2)$, either $(t_1,1)$ or $(1,t_2)$ is executed in the implementing machines.

If $(S_1,T_1), (S_2, T_2)$ represent a decomposition of a money scheme $(\mathscr {M}, \mathscr {P})$ and such errors cannot in principle be avoided, we can only ask how the partial transactions $(t_1,1),(1,t_2)$ are interpreted in the money scheme as changes of the money distribution. Do they preserve total money? Are they payments, i.e. elements of $\mathscr {P}$? If the current states are $s_1\in S_1$ and $s_2\in S_2$ and money distribution is $M=\pi (s_1,s_2)$, then $P(M)=\pi (t_1(s_1), t_2(s_2))$. The money distribution after applying the erroneous pair $(t_1,1)$ is $M_1=\pi (t_1(s_1), s_2)$ and after applying $(1,t_2)$, the resulting money distribution is $M_2=\pi (s_1, t_2(s_2))$. It is intuitive and natural to require that:

• 1. There are payments $P_1,P_2\in \mathscr {P}$ such that $P_1(M) = M_1$ and $P_1(M) = M_1$.

• 2. If the money $\sigma (M,b)$ of a bearer b is reduced by P, i.e. if $\sigma (M,b)>\sigma (P(M), b)$, then $P_1$ and $P_2$ do not reduce $\sigma (M,b)$ more than P, i.e.:

  $$\begin{aligned} \sigma (M,b)-\sigma (P(M), b)\ge & {} \sigma (M,b)-\sigma (M_1, b),\\ \sigma (M,b)-\sigma (P(M), b)\ge & {} \sigma (M,b)-\sigma (M_2, b). \end{aligned}$$

• 3. If the money $\sigma (M,b)$ of a bearer b is raised by P, i.e. if $\sigma (M,b)<\sigma (P(M), b)$, then $P_1$ and $P_2$ do not raise $\sigma (M,b)$ more than P, i.e.:

  $$\begin{aligned} \sigma (P(M),b)-\sigma (M, b)\ge & {} \sigma (M_1,b)-\sigma (M, b),\\ \sigma (P(M),b)-\sigma (M, b)\ge & {} \sigma (M_2,b)-\sigma (M, b). \end{aligned}$$

• 4. If the money $\sigma (M,b)$ of a bearer b is not changed by P, i.e. if $\sigma (M,b)=\sigma (P(M), b)$, then also $P_1$ and $P_2$ do not change $\sigma (M,b)$, i.e. $\sigma (M_1,b)=\sigma (M, b)$ and $\sigma (M_2,b)-\sigma (M, b)$.

If a decomposition of a money scheme $(\mathscr {M}, \mathscr {P})$ has such properties, then such a decomposition is said to be atomic. It can be shown [1] that atomic decomposition of a money scheme has the following properties:

• $(S_1,T_1), (S_2, T_2)$ can be interpreted as money schemes $(\mathcal {M}, \mathcal {P}_1)$ and $(\mathcal {M}, \mathcal {P}_2)$ where the elements of $\mathcal {P}_1$ contains payments that correspond to transaction pairs $(t_1,1)$ and $\mathcal {P}_2$ contains payments that correspond to pairs $(1,t_2)$.

• Money $\sigma _1(M, b)$ of a bearer b in $(S_1,T_1)$ is defined as the largest amount of money b can pay with a a sequence of transactions of type $(t_1,1)$.

• Money $\sigma _2(M, b)$ of a bearer b in $(S_2,T_2)$ is defined as the largest amount of money b can pay with a a sequence of transactions of type $(1,t_2)$.

• $\sigma _1(M, b) + \sigma _2(M,b) = \sigma (M,b)$

• The total amount $\sigma _1$ of money in $(\mathcal {M}, \mathcal {P}_1)$ and the total amount $\sigma _2$ of money in $(\mathcal {M}, \mathcal {P}_2)$ are invariant and $\sigma _1 + \sigma _2 =\sigma (M)$. There is no transfer of value from $(\mathcal {M}, \mathcal {P}_1)$ to $\sigma _2$ of money in $(\mathcal {M}, \mathcal {P}_2)$ and vice versa.

For example, there is no atomic decomposition of an account scheme such that $(S_1,T_1)$ handles one subset of accounts and $(S_2,T_2)$ handles other accounts, because there is no possibility to pay from an account handled by $(S_1,T_1)$ to an account handled by $(S_2,T_2)$. Otherwise, the values $\sigma _1$ and $\sigma _2$ would change.

From a bit more general viewpoint, we define unitwise decompositions as those decompositions where there is a rule that divides the set U of the existing units into two non-intersecting subsets $U_1$ and $U_2$ so that:

• Every $P\in \mathcal {P}_1$ acts only on $U_1$ and does not delete, create, or change the parameters of the units of $U_2$.

• Every $P\in \mathcal {P}_2$ acts only on $U_2$ and does not delete, create, or change the parameters of the units of $U_1$.

It can be shown that if $\mathscr {P}$ contains composition-irreducible payments P with $\Vert P\Vert _\textsf{in} = 2$ with input units in two different components, then $(\mathcal {M}, \mathcal {P})$ is not unitwise atomically decomposable. Note that the newly created units can always be chosen in the same component, and hence, the input complexity $\Vert P\Vert _\textsf{in}$ (and not $\Vert P\Vert$) is critical for unitwise atomic decomposability. Some implications:

• The account money scheme has no unitwise atomic decompositions, because it implements two-unit swap.

• The UTXO money scheme has no unitwise atomic decompositions, because it implements two-unit join.

• The bill money scheme has unitwise atomic decompositions, as single bill payments have complexity $\Vert P\Vert _\textsf{in} = 1$ and can be executed in parallel.

Moreover, the bill money scheme enables total unitwise atomic decomposability where every bill u is maintained in a separate machine and in the blockchain setting in a separate transaction validator that produces the blockchain (ledger) of the bill u in the form:

$$ (s^u_0,\tau _0,\varPi ^u_0,C_0; (B^u_1,\tau _1, \varPi ^u_1,C_1), (B^u_2,\tau _2, \varPi ^u_2,C_2), \ldots , (B^u_m, \tau _m, \varPi ^u_m,C_m)) , $$

where $B^u_i$ is either empty or contains a single payment $P^u_i$, and $\varPi ^u_i$ denotes additional information (usually in the form of a hash chain) that helps to verify the blockchain against the certificate $C_i$.

7 Security of Blockchain Implementations

In the so called permissionless blockchain systems new blocks are verified by thousands of nodes and erroneous blocks in the certified blockchain can be considered as almost impossible. However, permissionless systems tend to be more costly to manage and to have larger CO2 traces compared to permissioned blockchain systems where the number of redundant nodes is much smaller.

Hence, it is probably more efficient to implement Central Bank Digital Currency (CBDC) as a permissioned blockchain system, where new blocks are verified by just a few nodes. However, in this case, due to potential internal threats, erroneous blocks in the blockchain should be considered a possibility.

In the blockchain node (Fig. 3), the transaction validator together with the file repository are modelled as an adversarial entity that may deviate from ledger rules. Misbehavior of a node may be caused by internal attacks by malicious employees of system operators who may also be owners of money.

The practical goal of an attacker is to buy some goods by using falsified electronic cash, so that such a deception remains undetected for certain time sufficient for the attacker to escape. We assume covert adversaries [3, 4] that are considered successful only if their malicious behaviour remains undetected at least for some time. The Certifier (Fig. 3) is guaranteed to create a unique block certificate $C_n$ for every block number n. Adversary has no control over the Certifier that is assumed to be controlled by the central bank.

We assume that a bill payment scheme is used in the CBDC blockchain solution, where every bill u has a bill ledger. At every payment with u, an audit protocol is executed to verify that the bill is properly used, i.e. all the ledger rules are fulfilled. In the sequel, we study two types of audit protocols:

• 1. Full audit – guarantees that the ledger rules are followed.

• 2. Probabilistic audit – guarantees that any deviation from ledger rules will be detected very soon with high probability.

8 Rules of a Bill Ledger

Let U be the set of all bills and $\beta _0: U \rightarrow B$ be a function that defines the initial owner $\beta _0(u)$ of every bill $u\in U$. We assume that both U and $\beta _0$ are verifiably certified by Central Bank and cannot be altered by other parties. Every payment order is in the form $P^u=\langle \iota , b, \lambda , s \rangle$, where $\iota$ is a unique identifier of u, $b\in B$ is the payee identifier, $\lambda$ is a unique identifier of the payment order, and s is a signature of the payer. Every block $B^u_n$ of the bill ledger

$$ (s^u_0,\tau _0,\varPi ^u_0,C_0; (B^u_1,\tau _1, \varPi ^u_1,C_1), (B^u_2,\tau _2, \varPi ^u_2,C_2), \ldots , (B^u_m, \tau _m, \varPi ^u_m,C_m)), $$

is either empty, or contains a payment order $P^u_n=\langle \iota , b, \lambda , s \rangle$, where:

• 1. $\lambda = H(\iota , \beta _0(u))$ and s is the signature of $\beta _0(u)$ if $P^u_n$ is the first payment with u, where $H: \{0,1\}^*\rightarrow \{0,1\}^k$ is a cryptographic hash function.

• 2. $\lambda = H(P^u_{n'})$ and s is the signature of $b'$ if $P^u_{n'}=\langle \iota , b', \lambda ', s' \rangle$ is the payment order contained in the last non-empty block $B^u_{n'}$ in the sequence $B^u_1, \ldots , B^u_{n-1}$.

Hence, the blocks $B^u_{n'+1}, B^u_{n'+2}, \ldots , B^u_{n-2}, B^u_{n-1}$ must be empty. The collision-resistance of H guarantees that $\lambda$ is unique for every payment order.

The certificate $C_n$ contains the block hash $r_n$ and there is a function $F^H$ that uses H as an oracle such that $F^H(u; B^u_n, \varPi ^u_n)=r_n$, and If $R^u\ne \underline{R}^u$ and $F^H(u; B^u, \varPi ^u)=F^H(u; \underline{B}^u, \underline{\varPi }^u)$, then the computations of $F^H$ contain either an H-collision, or an H-pre-image of $0^k$ – a bitstring X such that $H(X)=0^k$. Both are assumed to be infeasible to find for practical hash functions.

9 User Side Full Audit

The main idea behind the full audit is that every user who has received u with a payment $P^u_{n'}$ and later, at block $n>n'$, uses u in a payment $P^u_n$, verifies that the blocks $B^u_{n'+1}, B^u_{n'+2}, \ldots , B^u_{n-1}$ are empty (Fig. 5).

Fig. 5.

User side full audit.

9.1 Full Audit Protocol

Assume that a user has a bill u paid to her with a payment order $P^u_{n'}$ at block $n'$, and that the user’s wallet already contains the certificates $C_0, \ldots , C_{n'}$ that were already verified, the block $B^u_{n'}$, and the proof $\varPi ^u_{n'}$ which also has been verified.

In a block $n>n'$, the user creates a block $B^u_n$ with a new payment order $P^u_n=\langle \iota , b, \lambda , s \rangle$, where $\lambda =H(P^u_{n'})$ and sends it to the transaction validator. User then executes the following full audit protocol:

• 1. User requests $C_{n'+1}, \ldots , C_n$ and $\varPi ^u_{n'+1}, \ldots , \varPi ^u_n$ from the file repository.

• 2. User verifies $C_{n'+1}, \ldots , C_n$.

• 3. User verifies $\varPi ^u_{n'+1}, \ldots , \varPi ^u_n$, assuming that $B^u_{n'+1}, \ldots , B^u_{n-1}$ are empty, i.e. for every $i\in \{n'+1, \ldots , n-1\}$ the user extracts the block hashes $x_i$ from $C_i$ and checks that $F^H(u; \emptyset , \varPi ^u_i)=r_n$.

9.2 Security of the Full Audit

Ledger rules violation means inserting a block $\overline{B}^u_i=\{P^u_i\}$ to the ledger, where $P^u_i$ does not properly follow $P^u_{n'}$, e.g. is not signed by $P^u_{n'}.b$. If the full audit at n also verifies, then $F^H(u; B^u_i, \varPi ^u_i) = r_n = F^H(u; \underline{B}^u_i, \underline{\varPi }^u_i)$ and there is a collision for H or an X such that $H(X)=0^k$ (Fig. 6).

Fig. 6.

Ledger rules violation leads to a hash collision.

9.3 Communication Complexity of the Full Audit

Let N be the total number of bills. The size of a proof is $k\cdot \log _2 N$ bits. As we need $n-n'$ proofs during the audit, the total number of bits communicated is $(n-n')\cdot k\cdot \log _2 N$ which may be impractical if $n\gg n'$. Using the probabilistic audit enables to reduce the communication complexity. The idea is that we check a random d-element subset of $B^u_{n'+1}, B^u_{n'+2}, \ldots , B^u_{n-1}$. In the general case, with the bill ledger certification scheme that we described, such an audit is inefficient because the detection probability $\delta$ of one single illegal block is about $\frac{d}{n-n'}$ which means that for a high $\delta$ the number d of detected blocks must be close to $n-n'$. We show that proper ledger certification schemes enable to keep d small.

10 KSI-Cash Bill Ledger

In this section, we describe the bill ledger certification scheme of the KSI-Cash CBDC solution [2] enables efficient probabilistic audit protocols with d being a fixed constant that only depends on the required detection probability and not on the length $n-n'$ of the auditing interval.

10.1 Hash Chains

By a hash chain c we mean a (possibly empty) list $\langle (b_1, y_1), (b_2, y_2), \ldots , (b_\ell , y_\ell ) \rangle$, where $b_i\in \{0,1\}$ and $y_i\in \{0,1\}^k$ for every $i\in \{1, \ldots , \ell \}$. The bitstring $b_1b_2\ldots b_\ell$ is called the shape of c. Every hash chain can be viewed as a function $c: \{0,1\}^k\rightarrow \{0,1\}^k$ defined as follows:

• 1. $\langle \rangle (x) = x$ for every $x\in \{0,1\}^k$, where $\langle \rangle$ is the empty list

• 2. $\langle c\Vert (b,y)\rangle (x) = \left\{ \begin{array}{ll} H(c(x), y) &{} \text{ if } b=0\\ H(y, c(x)) &{} \text{ if } b=1 \end{array} , \right.$ where $\langle c\Vert (b,y)\rangle$ denotes the list obtained from c by adding (b, y) as the last element.

10.2 The Idea of Probabilistic Audit

For every block $B^u_n$, we define the ledger hash $x_n$ that is a function of the previous ledger hash $x_{n-1}$ and the block $B^u_n$. If $B^u_n=\emptyset$, then $x_{n+1}=x_{n}$. Hence, if $B^u_{n'}=\{P^u_{n'}\}$ is the last non-empty block of u, and the current block number is $n-1$, then $x_{n-1} = x_{n-2}=\ldots = x_{n'}$ if ledger is correctly formed. We say that the empty blocks $n'+1, \ldots , n-1$ are consistent with $B^u_{n'}$.

Assume now that an illegal block $B^u_{i}=\{P^u_i\}$ with $n'<i<n-1$ is added to the ledger (Fig. 7) with $P^u_i.\lambda \ne H(P^u_{n'})$, i.e. $P^u_i$ “double-spends” the bill u. Then $x_{i}\ne x_{n'}$ and hence, each of the empty blocks $B^u_{i+1}, B^u_{i+2},\ldots , B^u_{n-1}$ is either consistent with $B^u_{n'}$ or with $B^u_{i}$, but not with both. The empty blocks that are consistent with $B^u_{n'}$ are called black blocks, and the empty blocks that are consistent with $B^u_{i}$ are called white blocks. Hence, each of the blocks $B^u_{i+1}, B^u_{i+2},\ldots , B^u_{n-1}$ is either black or white (Fig. 7).

The next payment $P^u_n$ with u in the block $B^u_n=\{P^u_n\}$ may either refer back to $B^u_{n'}$ (i.e. $P^u_{n}.\lambda = H(P^u_{n'})$) or to $B^u_{i}$ (i.e. $P^u_{n}.\lambda = H(P^u_{i})$). In the former case, during the audit protocol the blocks $B^u_{i+1}, B^u_{i+2},\ldots , B^u_{n-1}$ must be shown to be black, and in the latter case these blocks must be shown to be white. For randomly chosen $j\leftarrow \{i+1, \ldots , n-1\}$, either

• The probability that $B^u_j$ is consistent with $B^u_{i}$ is $\le \frac{1}{2}$

• The probability that $B^u_j$ is consistent with $B^u_{n'}$ is $\le \frac{1}{2}$

and hence, an audit with one randomly selected block $B^u_j$ in at least one of the two cases succeeds with probability not larger than $\frac{1}{2}$.

Fig. 7.

Blocks of an inconsistent bill ledger.

10.3 Proofs and Ledger Hashes in KSI-Cash

For every $n>0$, a proof $\varPi ^u_{n}$ is a pair $(x_{n-1}^u, c^u_n)$, where $x^u_{i}$ is a ledger hash computed by the rules:

• 1. $x^u_0 = 0$

• 2. $x^u_i = h_0(x^u_{i-1}, h_D(R^u_{i}))$ , where:

  • $h_D(X) = H(X)$ if $X\ne \emptyset$, and $h_D(X) = 0$ if $X=\emptyset$

  • $h_0(x,y) = H(x,y)$ if $y\ne 0$, and $h_0(x, y) = 0$ if $y=0$

and $c^u_n$ is a hash chain with the shape special to u from $x_n$ to the block hash $r_n$ in $C_n$, i.e. $c^u_n(x_n)=r_n$. The function $F_H$ is defined as follows:

$$ F^H(u; B, (x, c)) = c(h_0(x, h_D(B))). $$

Lemma 1 guarantees that two different non-empty blocks $B^u_{n'}$ and $B^u_{n''}$ must have different ledger hashes. If $n'<n''<j$, then the ledger hash $x_{j}$ cannot equal to both $x_{n'}$ and $x_{n''}$ and then by Lemma 2 (proved in [5]) , if the block $B^u_j$ is consistent with both $B^u_{n'}$ and $B^u_{n''}$, we have a collision for H.

Lemma 1

If $\emptyset \ne B^u_{n'} \ne B^u_{n''}\ne \emptyset$, then either $x^u_{n'} \ne x^u_{n''}$, or we have an explicit H-collision or a bitstring X such that $H(X)=0$.

Proof

If $x^u_{n'} = x^u_{n''}$, then by definition $h_0(x', h_D(B^u_{n'})) = h_0(x'', h_D(B^u_{n''}))$ for some $x', x''\in \{0,1\}^k$, which by $B^u_{n'}\ne \emptyset$ and $B^u_{n''}\ne \emptyset$ implies $h_0(x', H(B^u_{n'})) = h_0(x'', H(B^u_{n''}))$. If $H(B^u_{n'})=0$ or $H(B^u_{n''})=0$, then we can take $X=B^u_{n'}$ or $X=H(B^u_{n''})$ and have $H(X)=0$. If $H(B^u_{n'})\ne 0\ne H(B^u_{n''})$, then by definition of $h_0$, we have $H(x', H(B^u_{n'})) = H(x'', H(B^u_{n''}))$ and because of $B^u_{n'} \ne B^u_{n''}$, we have a collision for H. $\square$

Lemma 2

If $c^u, {\underline{c}}^u$ are two hash chains with the same u-specific shape, and $c^u(x^u_{n'}) = \underline{c}^u (x^u_{n''})$ and $x^u_{n'}\ne x^u_{n''}$, then we have an explicit H-collision.

Proof

Let $c^u=\langle (b_1, y_1), \ldots , (b_\ell , y_\ell ) \rangle$ and ${\underline{c}}^u=\langle (b_1, y'_1), \ldots , (b_\ell , y'_\ell ) \rangle$ be two hash chains of the same shape. We use induction on $\ell$. If $\ell = 0$, then $c^u=\langle \rangle ={\underline{c}}^u$ and for every $x^u_{n'}\ne x^u_{n''}$, we have $c^u(x^u_{n'}) = x^u_{n'} \ne x^u_{n''}=\underline{c}^u (x^u_{n''})$ and hence, the induction basis trivially holds. Assume now that the statement holds for the chains of length $\ell -1$, for example, for the chains $c\!=\!\langle (b_1, y_1), \ldots ,\! (b_{\ell -1}, y_{\ell -1})$ and $c'\!=\!\langle (b_1, y'_1), \ldots ,\! (b_{\ell -1}, y_{\ell -1})$. Hence, $c^u=\langle c\Vert (b_\ell ,y_\ell )\rangle$ and ${\underline{c}}^u=\langle c'\Vert (b_\ell ,y'_\ell )\rangle$. If $b_\ell = 1$, then it follows from $c^u(x^u_{n'}) = \underline{c}^u (x^u_{n''})$ that

$$\begin{aligned} H(y_\ell , c(x^u_{n'})) = H(y'_\ell , c'(x^u_{n''})). \end{aligned}$$

(2)

If $c(x^u_{n'})\ne c'(x^u_{n''})$, then (2) represents a collision for H. If $c(x^u_{n'})= c'(x^u_{n''})$, we apply the induction hypothesis to imply that the computations $c(x^u_{n'})$, $c'(x^u_{n''})$ contain an H-collision. The proof for the case $b_\ell = 0$ is similar. $\square$

11 User Side Probabilistic Audit in KSI-Cash

User has a bill u paid to her with a payment order $P^u_{n'}$ at block $n'$. We assume that user wallet contains the certificates $C_0, \ldots , C_{n'}$ that were already verified, the block $B^u_{n'}$, and the proof $\varPi ^u_{n'}$, that have also been verified. In a block $n>n'$, the user creates a block $B^u_n$ with a new payment order $P^u_n=\langle \iota , b, \lambda , s \rangle$, where $\lambda =H(P^u_{n'})$, sends it to the transaction validator, and initiates the next protocol:

Probabilistic Audit Protocol:

• 1. The user requests and verifies the certificates $C_{n'+1}, \ldots , C_{n}$.

• 2. The user generates d random numbers $n_1, \ldots , n_d \in \{n'+1, \ldots , n-1\}$.

• 3. The user requests $\varPi ^u_{n_1}=(x'_{n_1}, c^u_{n_1}), \ldots , \varPi ^u_{n_d}=(x'_{n_d}, c^u_{n_d})$ and checks that $x'_{n_1} = \ldots = x'_{n_d}=x^u_{n'}$, and $c^u_{n_1}(x^u_{n'})=r_{n_1}, \ldots , c^u_{n_d}(x^u_{n'})=r_{n_d}$.

11.1 Simplistic Security Analysis

Let the ledger be inconsistent already at block $B^u_{n'}$ and there are black blocks and white blocks that are inconsistent with each other (Fig. 8). Therefore:

• If the fraction of white blocks between $n'$ and n is $\le \frac{1}{2}$, and the payment $P^u_n$ is “white” ($P^u_n.\lambda = H(P^u_{i})$), then the audit succeeds with probability $\le 2^{-d}$.

• If the fraction of black blocks between $n'$ and n is $\le \frac{1}{2}$, and $P^u_n$ is “black” ($P^u_n.\lambda = H(P^u_{n'})$), then the audit succeeds with probability $\le 2^{-d}$.

Fig. 8.

Security argument for probabilistic audit.

This analysis is precise only if the two blocks $B^u_{n'}, B^u_{n''}$ are very close, i.e. $n'\approx n''$. In a more realistic scenario, adversary may choose suitable block numbers, for example, by delaying the execution of transactions, in order to make the success probability of probabilistic audit as high as possible. In the next section, we analyze such a possibility and show that such manipulation is not possible considering the properties of practical money systems.

11.2 Security: Alternating Payments Case

First, consider a scenario, where the adversary has to execute black payments and white payments alternatively as shown in Fig. 9. Assume that the bill u have paid to two different honest users b and $b'$ at block $n_0$ and $n_1$, respectively. We assume that the payment to b is already an illegal transaction, i.e. from the block $n_0$ and further, the later blocks (and their certificates) may be consistent with only one branch of the bill ledger. The blocks consistent with the payment to b are said to be black, and the blocks consistent with the payment to $b'$ are said to be white.

Fig. 9.

Alternating attack and general attack.

Later at block $n_2$, the user b pays u to another user, at block $n_3$ the user $b'$ pays u to another user, and at block $n_4$ the bill u is being paid again. We assume that the adversary can choose the blocks $n_1, n_2, n_3, n_4$ in an appropriate way in order to hide the inconsistency of the ledger from probabilistic audit.

We assume that there are $N_0=n_1-n_0-1$ between the payments to b and $b'$. Analogously, let $N_1=n_2-n_1-1$, $N_2=n_3-n_2-1$, and $N_3=n_4-n_3-1$ (Fig. 9, upper). Note that all these blocks depicted as grey are either black or white. The color of these blocks can be chosen by the adversary. When the payment is made at the block $n_2$, the adversary is interested that most of the $N_0+N_1$ grey blocks are black, because the payment at $n_2$ is checked to be consistent with the black branch. When the payment is made at $n_3$, the adversary is interested that most of the $N_1+N_2$ blocks are white, and for the payment at $n_4$, most of the $N_2+N_3$ should be black again.

In the general case, the adversary has to execute black and white payments in arbitrary order (Fig. 9, lower), that before the payment that continues the black block at $n_0$ is made at the block $n_2$, some payments continue the white block at $n_1$ and the last such payment happens at the block $n'_1$. We assume that the number of blocks between $n_1$ and $n'_1$ is $N'_0$. It may be that none of such payments happen and then $n'_1=n_1$ and $N'_0=0$, and hence, we have the alternating attack. Analogously, we assume that some payments may continue the black block at $n_2$ and the last such payment happens at the block $n'_2$, etc.

Say the adversary wants that any of the probabilistic test with d samples should succeed with probability $1-\delta$. This means that every single-sample test must succeed with probability $1-\epsilon$, where $(1-\epsilon )^d = (1-\delta )$. For small values of $\epsilon$ and $\delta$ they are related linearly: $\epsilon \approx \frac{\delta }{d}$. We can show that in the general case:

$$\begin{aligned} n_{k+1} - n_0> & {} N_0 + N'_0 + N_1 + N'_1 + \ldots + N_{k-1}+N'_{k-1} +N_k \\\ge & {} \left( \frac{1-\epsilon }{\epsilon }\right) ^{k-1} (N_1+N'_1) - \left[ \frac{1-\epsilon }{\epsilon } \!+\! \ldots \!+\! \left( \frac{1-\epsilon }{\epsilon }\right) ^{k-2} \right] (N_0\!+\!N'_0), \end{aligned}$$

and hence, the required delays between payments must grow exponentially, that is clearly not realistic to enforce by adversaries in practice.

12 Probabilistic Audit for Account Money Schemes?

We cannot just copy the idea of probabilistic audit from bill ledgers, because of very different ledger rules. Even if the total amount of money is controlled by the Central Bank (via count-certified trees [6], etc.), there is always “money on the fly” – payer account debited but payee account not yet credited. The amount of “money on the fly” gives attackers room for illegal transactions that are hard to detect “on-line”. It would be an interesting research question whether there exist efficient probabilistic audit protocols for account money schemes.