# CBDC-AquaSphere: Interoperable Central Bank Digital Currency Built on
Trusted Computing and Blockchain

Ivan Homoliak,† Martin Perešíni,† Patrik Holop,† Jakub Handzuš,† Fran
Casino$\ast$ †Brno University of Technology, Faculty of Information
Technology, Czech Republic∗Universitat Rovira i Virgili, Tarragona, Spain

###### Abstract.

The adoption of decentralized, tamper-proof ledger systems is paving the way
for new applications and opportunities in different contexts. While most
research aims to improve their scalability, privacy, and governance issues,
interoperability has received less attention. Executing transactions across
various blockchains is notably instrumental in unlocking the potential of
novel applications, particularly in the financial sector, where their
potential would otherwise be significantly diminished. Therefore,
interoperable ledgers are crucial to ensure the expansion and further adoption
of such a technology in various contexts.

In this paper, we present a protocol that uses a combination of trusted
execution environment (TEE) and blockchains to enable interoperability over
independent semi-centralized CBDC ledgers, guaranteeing the atomicity of
inter-bank transfers. Our interoperability protocol uses a custom adaptation
of atomic swap protocol and is executed by any pair of CBDC instances to
realize a one-way transfer. It ensures features such as atomicity,
verifiability, correctness, censorship resistance, and privacy while offering
high scalability in terms of the number of CBDC instances. Our approach
enables to possible deployment scenarios that can be combined: (1) CBDC
instances represent central banks of multiple countries, and (2) CBDC
instances represent the set of retail banks and a paramount central bank of a
single country. We provide a detailed description of our protocol as well as
an extensive analysis of its benefits, features, and security.

In this WIP paper, we made a proof-of-concept implementation and made a
partial evaluation, while the more extensive evaluation will be made in our
future work.

Blockchain, Interoperability, Central Bank Digital Currency (CBDC), Trusted
Execution Environment, Cross-chain Protocol, Privacy, Censorship.

##  1\. Introduction

Blockchain technology is becoming the backbone of a myriad of applications
since it provides features such as decentralization, immutability,
availability, and transparency. More recently, along with the increasing
adoption and maturity of such a technology (AlShamsi et al., 2022), central
banks all over the world are accelerating the process of Central Bank Digital
Currency (CBDC) development (Zhang and Huang, 2021). CBDC has received
increasing attention in the past few years. More than 85% of central banks are
actively researching the potential for CBDCs, and according to BIS survey
(Boar and Wehrli, 2021) conducted in 2021 central banks covering 20% of the
world’s population are likely to launch retail CBDCs before 2025. Some of the
reasons behind this new paradigm are the digitization of the economy, the
level of development of the financial sector, and a strong decline in the use
of cash (Náñez Alonso et al., 2020).

Despite the generalized will to improve the worldwide financial system by
utilizing blockchain technology (Ehrenfeld, 2022) in centralized environments,
there is still a road ahead for the realization of fast secure blockchain
payment systems. Nevertheless, some features are essential to enable financial
solutions to reach an operational level, making interoperability a crucial
requirement in this context. Note that a few cross-chain solutions and
protocols (Zhang and Huang, 2021; Lan et al., 2021; Bellavista et al., 2021)
that leverage the necessary level of interoperability for execution of inter-
bank financial transactions have been proposed in the literature. In this
regard, technologies such as Trusted Execution Environments (TEE) in a
potential combination with blockchains can efficiently enforce the required
security and privacy levels of centralized environments of banks, and thus
provide a high level of trustworthiness for the end users.

##### Motivation

CBDC legislation and adoption goes in hand with privacy and security concerns.
The centralized nature of banks implies that transactions are recorded in
private ledgers managed by banks, contrary to the very nature of public
decentralized cryptocurrencies. While this may prevent some potential
malicious scenarios, users are forced into trusting a single authority and its
corresponding regulations. Aiming at increasing decentralization and trust,
several authors have proposed the use of TEE to leverage verifiable protocols
enabling interoperability of multiple centralized isolated environments (Wang
et al., 2023; Lacoste and Lefebvre, 2023).

While achieving blockchain interoperability is challenging regardless of its
flavor (i.e., between centralized, decentralized or hybrid blockchain
structures) additional features such as scalability, confidentiality, and
censorship resistance are necessary to guarantee for practical scenarios.
Digital Euro Association released on October 2022 the CBDC manifesto (Digital
Euro Association, 2022), in which they highlight important features of CBDC,
such as strong value proposition for the end users, the highest degree of
privacy, and interoperability. Our work is inline with this manifesto and
adheres to its features while it provides even additional features that are
interesting for the users and the whole ecosystem assuming that the CBDC-
equipped bank might potentially be an untrusted entity.

##### Contributions

In this paper, we present a practical blockchain interoperability protocol
that integrates such features. On top of the above mentioned features, to the
best of our knowledge, our work represents the first TEE-based interoperable
CBDC approach that provides the proof-of-censorship. Our main contributions
are summarized as follows:

  1. (1)

We specify requirements for an instance of CBDC that is controlled by a single
bank111As we will see it can be a central bank or even a retail bank,
depending on the deployment scenario described in Section 4.2.1. Therefore,
depending on the scenario, we well use the term CBDC instance even for a
retail bank. and forms an isolated environment. These requirements include
high processing performance, transparent token issuance, correctness of intra-
bank transfers, immutability of historical data, non-equivocation, privacy,
and the indisputable proofs of censorship.

  2. (2)

We investigate state-of-the-art approaches applicable for a CBDC instance
assuming our requirements and identify the most convenient one, Aquareum
(Homoliak and Szalachowski, 2020), that we further base on. The Aquareum-based
CBDC ledger ensures immutability, non-equivocation, privacy, and the
indisputable proofs of transaction censorship by utilizing a permissionless
blockchain (e.g., Ethereum). Next, by using TEE (e.g., Intel SGX), it ensures
the correctness of any transaction execution.

  3. (3)

Our main contribution resides in a design and implementation of a protocol
resolving interoperability over multiple instances of semi-centralized CBDC,
which guarantees the atomicity of inter-bank transfers.

  4. (4)

We provide a security analysis, to prove the the properties of our approach.

##### Organization

The remainder of the article is organized as follows. In Section 2, we provide
a background on blockchain, atomic swap, and trusted computing. We define the
problem in Section 3, where we describe the attacker model and required
features of a single CBDC instance as well as the environment of multiple
interoperable CBDC instances. Section 4 provides a description of the proposed
interoperability protocol and its deployment scenarios. Next, the
implementation details of the designed protocol and its partial evaluation are
described in Section 5. We make a security analysis of our approach in Section
6. Section 7 reviews the state of the art of CBDC approaches and TEE-based
blockchain solutions. Section 8 discusses the benefits and limitations of our
approach. We conclude the paper in Section 9 with some final remarks.

##  2\. Background

This section provides the reader with the essential context needed to
understand the topics that will be discussed in this article.

###  2.1. Blockchain

Blockchain is a tamper-resistant data structure, in which data records (i.e.,
blocks) are linked using a cryptographic hash function, and each new block has
to be agreed upon by participants (a.k.a., miners) running a consensus
protocol (i.e., consensus nodes). Each block may contain data records
representing orders that transfer tokens, application codes written in a
platform-supported language, and the execution orders of such application
codes. These application codes are referred to as smart contracts, and they
encode arbitrary processing logic written in a supported language of a smart
contract platform. Interactions between clients and the smart contract
platform are based on messages called transactions.

###  2.2. Trusted Execution Environment

Trusted Execution Environment (TEE) is a hardware-based component that enables
secure (remote) execution (Subramanyan et al., 2017) of a pre-defined code
(i.e., enclave) in an isolated environment. TEE uses cryptographic primitives
and hardware-embedded secrets that protect data confidentiality and the
integrity of computations. In particular, the adversary model of TEE involves
the operating system (OS) that may compromise user-space applications but not
TEE-protected applications. An enclave process cannot execute system calls but
can read and write memory outside the enclave. Thus isolated execution in TEE
may be viewed as an ideal model in which a process is guaranteed to be
executed correctly with ideal confidentiality, while it might run on a
potentially malicious OS.

##### Intel SGX

While there exist multiple instances of TEE, in the context of this work we
will focus on Intel SGX (Software Guard Extensions) (Anati et al., 2013;
McKeen et al., 2013; Hoekstra et al., 2013). Intel SGX allows a local process
or a remote system to securely communicate with the enclave as well as execute
verification of the integrity of the enclave’s code. When an enclave is
created, the CPU outputs a report of its initial state, also referred to as a
measurement, which is signed by the private key of TEE and encrypted by a
public key of Intel Attestation Service (IAS). The hardware-protected
signature serves as the proof that the measured code is running in an SGX-
protected enclave, while the encryption by IAS public key ensures that the
SGX-equipped CPU is genuine and was manufactured by Intel. This proof is also
known as a quote or attestation, and it can be verified by a local process or
by a remote system. The enclave-provided public key can be used by a verifier
to establish a secure remote channel with the enclave or to verify the
signature during the attestation.

###  2.3. CBDC

CBDC is often defined as a digital liability backed and issued by a central
bank that is widely available to the general public. CBDC encompasses many
potential benefits such as efficiency and resiliency, flexible monetary
policies, and enables enhanced control of tax evasion and money laundering
(Kiff et al., 2020). However, regulations, privacy and identity management
issues, as well as design vulnerabilities are potential risks that are shared
with cryptocurrencies. Many blockchain-based CBDC projects rely on using some
sort of stable coins adapting permissioned blockchains due to their
scalability and the capability to establish specific privacy policies, as
compared to public blockchains (Sethaput and Innet, 2021; Zhang and Huang,
2021). Therefore, the level of decentralization and coin volatility are two
main differences between blockchain-based CBDCs and common cryptocurrencies.
These CBDCs are often based on permissioned blockchain projects such as Corda
(Brown et al., 2016), variants of Hyperledger (Hyperledger Foundation, 2022),
and Quorum (Espel et al., 2017).

CDBC solutions are often designed as multi-layer projects (Jin and Xia, 2022).
Wholesale CBDC targets communication of financial institutions and inter-bank
settlements. Retail CBDC includes accessibility to the general public or their
customers.

###  2.4. Atomic Swap

A basic atomic swap assumes two parties $\mathbb{A}$ and $\mathbb{B}$ owning
crypto-tokens in two different blockchains. $\mathbb{A}$ and $\mathbb{B}$ wish
to execute cross-chain exchange atomically and thus achieve a fairness
property, i.e., either both of the parties receive the agreed amount of
crypto-tokens or neither of them. First, this process involves an agreement on
the amount and exchange rate, and second, the execution of the exchange
itself.

In a centralized scenario (Micali, 2003), the approach is to utilize a trusted
third party for the execution of the exchange. In contrast to the centralized
scenario, blockchains allow us to execute such an exchange without a
requirement of the trusted party. The atomic swap protocol (Bitcoin Wiki,
2018) enables conditional redemption of the funds in the first blockchain to
$\mathbb{B}$ upon revealing of the hash pre-image (i.e., secret) that redeems
the funds on the second blockchain to $\mathbb{A}$. The atomic swap protocol
is based on two Hashed Time-Lock Contracts (HTLC) that are deployed by both
parties in both blockchains.

Although HTLCs can be implemented by Turing-incomplete smart contracts with
support for hash-locks and time-locks, for clarity, we provide a description
assuming Turing-complete smart contracts, requiring four transactions:

  1. (1)

$\mathbb{A}$ chooses a random string $x$ (i.e., a secret) and computes its
hash $h(x)$. Using $h(x)$, $\mathbb{A}$ deploys $HTLC_{\mathbb{A}}$ on the
first blockchain and sends the agreed amount to it, which later enables
anybody to do a conditional transfer of that amount to $\mathbb{B}$ upon
calling a particular method of $HTLC_{\mathbb{A}}$ with $x=h(x)$ as an
argument (i.e., hash-lock). Moreover, $\mathbb{A}$ defines a time-lock, which,
when expired, allows $\mathbb{A}$ to recover funds into her address by calling
a dedicated method: this is to prevent aborting of the protocol by another
party.

  2. (2)

When $\mathbb{B}$ notices that $HTLC_{\mathbb{A}}$ has been already deployed,
she deploys $HTLC_{\mathbb{B}}$ on the second blockchain and sends the agreed
amount there, enabling a conditional transfer of that amount to $\mathbb{A}$
upon revealing the correct pre-image of $h(x)$ ($h(x)$ is visible from already
deployed $HTLC_{\mathbb{A}}$). $\mathbb{B}$ also defines a time-lock in
$HTLC_{\mathbb{B}}$ to handle abortion by $\mathbb{A}$.

  3. (3)

Once $\mathbb{A}$ notices deployed $HTLC_{\mathbb{B}}$, she calls a method of
$HTLC_{\mathbb{B}}$ with revealed $x$, and in turn, she obtains the funds on
the second blockchain.

  4. (4)

Once $\mathbb{B}$ notices that $x$ was revealed by $\mathbb{A}$ on the second
blockchain, she calls a method of $HTLC_{\mathbb{A}}$ with $x$ as an argument,
and in turn, she obtains the funds on the first blockchain.

If any of the parties aborts, the counter-party waits until the time-lock
expires and redeems the funds.

###  2.5. Merkle Tree

A Merkle tree (Merkle, 1989) is a data structure based on the binary tree in
which each leaf node contains a hash of a single data block, while each non-
leaf node contains a hash of its concatenated children. Hence, the root node
provides a tamper-evident integrity snapshot of the tree contents. A Merkle
tree enables efficient membership verification (with logarithmic time/space
complexity) using the Merkle proof. To enable a membership verification of
element $x_{i}$ in the list $X$, the Merkle tree supports the following
operations:

:

$\mathbf{MkRoot(X)\rightarrow Root}$: an aggregation of all elements of the
list $X$ by a Merkle tree, providing a single value $Root$.

:

$\mathbf{MkProof(x_{i},X)\rightarrow\pi^{mk}}$: a Merkle proof generation for
the $i$th element $x_{i}$ present in the list of all elements $X$.

:

$\mathbf{\pi^{mk}.Verify(x_{i},Root)\rightarrow\\{T,F\\}}$: verification of
the Merkle proof $\pi^{mk}$, witnessing that $x_{i}$ is included in the list
$X$ that is aggregated by the Merkle tree with the root hash $Root$.

###  2.6. History Tree

A Merkle tree has been primarily used for proving membership. However, Crosby
and Wallach (Crosby and Wallach, 2009) extended its application for an append-
only tamper-evident log, named a history tree. In history tree, leaf nodes are
added in an append-only fashion while it enables to produce incremental proofs
witnessing that arbitrary two versions of the tree are consistent. The history
tree brings a versioned computation of hashes over the Merkle tree, enabling
to prove that different versions (i.e., commitments) of a log, with distinct
root hashes, make consistent claims about the past. The history tree $L$
supports the following operations:

$\mathbf{L.add(x)\rightarrow C_{j}}$::

appending of the record $x$ to $L$, returning a new commitment $C_{j}$ that
represents the most recent value of the root hash of the history tree.

$\mathbf{L.IncProof(C_{i},C_{j})\rightarrow\pi^{inc}}$::

an incremental proof generation between two commitments $C_{i}$ and $C_{j}$,
where $i\leq j$.

$\mathbf{L.MemProof(i,C_{j})\rightarrow\pi^{mem}}$::

a membership proof generation for $x_{i}$ from the commitment $C_{j}$, where
$i\leq j$.

$\mathbf{\pi^{inc}.Verify(C_{i},C_{j})\rightarrow\\{T,F\\}}$::

verification of the incremental proof $\pi^{inc}$, witnessing that the
commitment $C_{j}$ contains the same history of records
$x_{k},k\in\\{0,\ldots,i\\}$ as the commitment $C_{i}$, where $i\leq j$.

$\mathbf{\pi^{mem}.Verify(i,x_{i},C_{j})\rightarrow\\{T,F\\}}$::

verification of the membership proof $\pi^{mem}$, witnessing that $x_{i}$ is
the $i$th record in the $j$th version of $L$, fixed by the commitment $C_{j}$,
$i\leq j$.

$\mathbf{\pi^{inc}.ReduceRoot()\rightarrow C_{j}}$::

a reduction of the commitment $C_{j}$ from the incremental proof $\pi^{inc}$
that was generated by $L.Inc\\-Proof(C_{i},C_{j})$.

###  2.7. Aquareum

Aquareum (Homoliak and Szalachowski, 2020) is a centralized ledger that is
based on a combination of a trusted execution environment (TEE) with a public
blockchain platform (see our other submission with ID $\\#83$). It provides a
publicly verifiable non-equivocating censorship-evident private ledger.
Aquareum is integrated with a Turing-complete virtual machine (instantiated by
eEVM (Microsoft, 2020)), allowing arbitrary transaction processing logic, such
as transfers or client-specified smart contracts. In other words, Aquareum
provides most of the blockchain features while being lightweight and cheap in
contrast to them. Nevertheless, Aquareum does not provide extremely high
availability (such as blockchains) due to its centralized nature, which is,
however, common and acceptable for the environment of CBDC.

Figure 1. Architecture of Aquareum with our modifications in red.

The overview of Aquareum is depicted in Figure 1 (where parts in red are our
modifications and are irrelevant for the current description). In Aquareum,
clients $\mathbb{C}$s submit transactions to operator $\mathbb{O}$ (1), who
executes them in protected TEE enclave $\mathbb{E}$ (4) upon fetching a few
data of the ledger $L$ with the partial state containing only concerned
accounts (2). $\mathbb{E}$ outputs updated state of affected client accounts
with execution receipts and a version transition pair of $L$ (5) that is
periodically submitted to the smart contract $\mathbb{S}$ deployed on a public
blockchain (7). $\mathbb{S}$ verifies $\mathbb{E}$’s signature and the
consistency of the previous version of $L$ with $\mathbb{S}$’s local snapshot
(8) before updating the snapshot to a new version. Note that snapshot is
represented by the root hash (i.e., $LRoot$ ) of the history tree of $L$.

##  3\. Problem Definition

Our goal is to propose a CBDC approach that respects the features proposed in
DEA manifesto (Digital Euro Association, 2022) released in 2022, while on top
of it, we assume other features that might bring more benefits and guarantees.
First, we start with a specification of the desired features related to a
single instance of CBDC that we assume is operated by a single entity (further
a bank or its operator) that maintains its ledger. Later, we describe desired
features related to multiple instances of CBDC that co-exist in the ecosystem
of wholesale and/or retail CBDC.222Note that we will propose two deployment
scenarios (see Section 4.2.1), one for the wholesale environment and the
second one for the retail environment of multiple retail banks interacting
with a single central bank. In both cases, we assume that a central bank might
not be a trusted entity. All features that respect this assumption are marked
with asterisk ∗ and are considered as requirements for such an attacker model.

###  3.1. Single Instance of CBDC

When assuming a basic building block of CBDC – a single bank’s CBDC working in
an isolated environment from the other banks – we specify the desired features
of CBDC as follows:

  1. Correctness of Operation Execution∗:

The clients who are involved in a monetary operation (such as a transfer)
should be guaranteed with a correct execution of their operation.

  2. Integrity∗:

The effect of all executed operations made over the client accounts should be
irreversible, and no “quiet” tampering of the data by a bank should be
possible. Also, no conflicting transactions can be (executed and) stored by
the CBDC instance in its ledger.

  3. Verifiability∗:

This feature extends integrity and enables the clients of CBDC to obtain
easily verifiable evidence that the ledger they interact with is internally
correct and consistent. In particular, it means that none of the previously
inserted transactions was neither modified nor deleted.

  4. Non-Equivocation∗:

From the perspective of the client’s security, the bank should not be able to
present at least two inconsistent views on its ledger to (at least) two
distinct clients who would accept such views as valid.

  5. Censorship Evidence∗:

The bank should not be able to censor a client’s request without leaving any
public audit trails proving the censorship occurrence.

  6. Transparent Token Issuance∗:

Every CBDC-issued token should be publicly visible (and thus audit-able) to
ensure that a bank is not secretly creating token value “out-of-nothing,” and
thus causing uncontrolled inflation. The transparency also holds for burning
of existing tokens.

  7. High Performance:

A CBDC instance should be capable of processing a huge number of transactions
per second since it is intended for daily usage by thousands to millions of
people.

  8. Privacy:

All transfers between clients as well as information about the clients of CBDC
should remain private for the public and all other clients that are not
involved in particular transfers. However, a bank can access this kind of
information and potentially provide it to legal bodies, if requested.

###  3.2. Multiple Instances of CBDC

In the case of multiple CBDC instances that can co-exist in a common
environment, we extend the features described in the previous listing by
features that are all requirements:

  1. Interoperability∗:

As a necessary prerequisite for co-existence of multiple CBDC instances, we
require them to be mutually interoperable, which means that tokens issued by
one bank can be transferred to any other bank. For simplicity, we assume that
all the CBDC instances are using the unit token of the same value within its
ecosystem.333On the other hand, conversions of disparate CBDC-backed tokens
would be possible by following trusted oracles or oracle networks. At the
hearth of interoperability lies atomicity of supported operations. Atomic
interoperability, however, requires means for accountable coping with
censorship and recovery from stalling. We specify these features in the
following.

    1. Atomicity∗:

Any operation (e.g., transfer) between two interoperable CBDC instances must
be either executed completely or not executed at all. As a consequence, no new
tokens can be created out-of-nothing and no tokens can be lost in an inter-
bank operation. Note that even if this would be possible, the state of both
involved instances of CBDC would remain internally consistent; therefore,
consistency of particular instances (Section 3.1) is not a sufficient feature
to ensure atomicity within multiple interoperable CBDC instances. This
requirement is especially important due to trustless assumption about
particular banks, who might act in their benefits even for the cost of
imposing the extreme inflation to the whole system.444For example, if
atomicity is not enforced, one bank might send the tokens to another bank,
while not decreasing its supply due to pretended operation abortion.

    2. Inter-CBDC Censorship Evidence∗:

Having multiple instances of CBDC enables a different way of censorship, where
one CBDC (and its clients) might be censored within some inter-CBDC operation
with another CBDC instance, precluding them to finish the operation.
Therefore, there should exist a means how to accountably detect this kind of
censorship as well.

    3. Inter-CBDC Censorship Recovery∗:

If the permanent censorship happens and is indisputably proven, it must not
impact other instances of CBDC, including the ones that the inter-CBDC
operations are undergoing. Therefore, the interoperable CBDC environment
should provide a means to recover from inter-CBDC censorship of unfinished
operations.

  2. Identity Management of CBDC Instances∗:

Since we assume that CBDC instances are trustless, in theory, there might
emerge a fake CBDC instance, pretentding to act as a valid one. To avoid this
kind of situation, it is important for the ecosystem of wholesale CBDC to
manage identities of particular valid CBDC instances in a secure manner.

###  3.3. Adversary Model

The attacker can be represented by the operator of a bank or the client of a
bank, and their intention is to break functionalities that are provided by the
features described above. Next, we assume that the adversary cannot undermine
the cryptographic primitives used, the blockchain platform, and the TEE
platform deployed.

##  4\. Proposed CBDC Approach

Figure 2. Overview of our CBDC architecture supporting interoperability among
multiple CBDC instances (i.e., banks). The schema depicts two instances, where
each of them has its own centralized ledger $L$ modified in a secure way
through TEE of $\mathbb{E}$, while its integrity is ensured by periodic
integrity snapshots to the integrity preserving smart contract
($\mathbb{IPSC}$) in a public blockchain $PB$. Each CBDC instance is
registered in the identity management smart contract $\mathbb{IMSC}$ of a
public blockchain, serving as a global registry of bank instances. A client
who makes an inter-bank transfer communicates with her bank and the counter-
party bank utilizing interoperability micro contracts ($\mathbb{IOMC}$),
running in the TEE. Any censored request of a client is resolved by
$\mathbb{IPSC}$ of a particular bank and can be initiated by its client or a
counter-party client.

We propose a holistic approach for the ecosystem of wholesale and/or retail
CBDC, which aims at meeting the features described in Section 3. To accomplish
these features, we leverage interesting properties stemming from a combination
of a public blockchain (with smart contract platform) and TEE. Such a
combination was proposed for various purposes in related work (see Section 7),
out of which the use case of generic centralized ledger Aquareum (Homoliak and
Szalachowski, 2020) is most convenient to build on. Therefore, we utilize
Aquareum as a building block for a single instance of CBDC, and we make a few
CBDC-specific modifications to it, enhancing its transparency and
functionality. Our modifications are outlined in Figure 1 by red color, while
the details of them (especially changes in programs of smart contract and
enclave) will be described in this section. First, we start by a description
of a single CBDC instance and then we extend it to a fully interoperable
environment consisting of multiple CBDC instances.

Note that in this paper, we focus solely on the transfer of tokens operation
within the context of CBDC interoperability. However, our approach could be
extended to different operations, involving inter-CBDC smart contract
invocations. Also, note that to distinguish between smart contracts on a
public blockchains and smart contracts running in TEE, we will denote latter
as micro contracts (or $\mu$-contracts). Similarly, we denote transactions
sent to TEE as micro transactions (or $\mu$-transactions) and blocks created
in the ledger of CBDC instance as micro blocks (or $\mu$-blocks).

###  4.1. A CBDC Instance

Alike in Aquareum, the primary entity of each CBDC instance is its operator
$\mathbb{O}$ (i.e., a bank), who is responsible for (1) maintaining the ledger
$L$, (2) running the TEE enclave $\mathbb{E}$, (3) synchronization of the
$L$’s snapshot to a public blockchain with smart contract $\mathbb{IPSC}$
($\mathbb{I}$ntegrity $\mathbb{P}$reserving $\mathbb{S}$mart
$\mathbb{C}$ontract), (4) resolving censorship requests, and (5) a
communication with clients $\mathbb{C}$s.

####  4.1.1. Token Issuance

On top of Aquareum’s $\mathbb{S}$, our $\mathbb{IPSC}$ contains snapshotting
of the total issued tokens $t_{i}$ by the current CBDC instance and the total
supply $t_{s}$ available at the instance for the purpose of transparency in
token issuance (and potentially even burning). Therefore, we extend the
$\mathbb{E}$-signed version transition pair periodically submitted to
$\mathbb{IPSC}$ by these two fields that are relayed to $\mathbb{IPSC}$ upon
snapshotting $L$ (see red text in Figure 1). Notice that $t_{i}=t_{s}$ in the
case of a single instance since the environment of the instance is isolated.

#### An Inflation Bound

Although snapshotting the total tokens in circulation is useful for the
transparency of token issuance, $\mathbb{O}$ might still hyper-inflate the
CBDC instance. Therefore, we require $\mathbb{O}$ to guarantee a maximal
inflation rate $i_{r}$ per year, which can be enforced by $\mathbb{IPSC}$ as
well as $\mathbb{E}$ since the code of both is publicly visible and
attestable. The $i_{r}$ should be adjusted to a constant value by $\mathbb{O}$
at the initialization of $\mathbb{IPSC}$ and verified every time the new
version of $L$ is posted to $\mathbb{IPSC}$; in the case of not meeting the
constrain, the new version would not be accepted at $\mathbb{IPSC}$. However,
another possible option is that the majority vote of $\mathbb{C}$s can change
$i_{r}$ even after initialization. Besides, $\mathbb{E}$ also enforces $i_{r}$
on $t_{i}$ and does not allow $\mathbb{O}$ to issue yearly more tokens than
defined by $i_{r}$. Nevertheless, we put the inflation rate logic also into
$\mathbb{IPSC}$ for the purpose of transparency.

####  4.1.2. Initialization

First, $\mathbb{E}$ with program $prog^{\mathbb{E}}$ (see Algorithm 5 of
Appendix) generates and stores two key pairs, one under $\Sigma_{pb}$ (i.e.,
$SK_{\mathbb{E}}^{pb}$, $PK_{\mathbb{E}}^{pb}$) and one under $\Sigma_{tee}$
(i.e., $SK_{\mathbb{E}}^{tee}$, $PK_{\mathbb{E}}^{tee}$). Then, $\mathbb{O}$
generates one key pair under $\Sigma_{pb}$ (i.e., $SK_{\mathbb{O}}^{pb}$,
$PK_{\mathbb{O}}^{pb}$), which is then used as the sender of a transaction
deploying $\mathbb{IPSC}$ with program $prog^{\mathbb{IPSC}}$ (see Algorithm 6
of Appendix) at public blockchain with parameters $PK_{\mathbb{E}}^{pb}$,
$PK_{\mathbb{E}}^{tee}$, $PK_{\mathbb{O}}^{pb}$, $t_{i}$, and $i_{r}$. Then,
$\mathbb{IPSC}$ stores the keys in parameters, sets the initial version of $L$
by putting $LRoot_{pb}\leftarrow~{}\perp$, and sets the initial total issued
tokens and the total supply, both to $t_{i}$.555Among these parameters, a
constructor of $\mathbb{IPSC}$ also accepts the indication whether an instance
is allowed to issue tokens. This is, however, implicit for the single
instance, while restrictions are reasonable in the case of multiple instances.

#### Client Registration

A client $\mathbb{C}$ registers with $\mathbb{O}$, who performs know your
customer (KYC) checks and submits her public key $PK_{pb}^{\mathbb{C}}$ to
$\mathbb{E}$. Then, $\mathbb{E}$ outputs an execution receipt about the
successful registration of $\mathbb{C}$ as well as her access ticket
$t^{\mathbb{C}}$ that will serve for potential communication with
$\mathbb{IPSC}$ and its purpose is to avoid spamming $\mathbb{IPSC}$ by
invalid requests. In detail, $t^{\mathbb{C}}$ is the $\mathbb{E}$-signed tuple
that contains $PK_{pb}^{\mathbb{C}}$ and optionally other fields such as the
account expiration timestamp. Next, $\mathbb{C}$ verifies whether her
registration (proved by the receipt) was already snapshotted by $\mathbb{O}$
at $\mathbb{IPSC}$.

####  4.1.3. Normal Operation

$\mathbb{C}$s send $\mu$-transactions (writing to $L$) and queries (reading
from $L$) to $\mathbb{O}$, who validates them and relays them to $\mathbb{E}$,
which processes them within its virtual machine (Aquareum uses eEVM
(Microsoft, 2020)). Therefore, $L$ and its state are modified in a trusted
code of $\mathbb{E}$, creating a new version of $L$, which is represented by
the root hash $LRoot$ of the history tree. Note that program
$prog^{\mathbb{E}}$ is public and can be remotely attested by $\mathbb{C}$s
(or anybody). $\mathbb{O}$ is responsible for a periodic synchronization of
the most recent root hash $LRoot_{cur}$ (i.e., snapshotting the current
version of $L$ ) to $\mathbb{IPSC}$, running on a public blockchain $PB$.
Besides, $\mathbb{C}$s use this smart contract to resolve censored
transactions and queries, while preserving the privacy of data.

####  4.1.4. Censorship Resolution

$\mathbb{O}$ might potentially censor some write transactions or read queries
of $\mathbb{C}s$. However, these can be resolved by Aquareum’s mechanism as
follows. If $\mathbb{C}$’s $\mu$-transaction $\mu$-tx is censored by
$\mathbb{O}$, $\mathbb{C}$ first creates $PK_{\mathbb{E}}^{tee}$-encrypted
$\mu$-$etx$ (to ensure privacy in $PB$), and then she creates and signs a
transaction containing $\mathbb{C}^{\prime}s$ access ticket $t^{\mathbb{C}}$
and $\mu$-$etx$. $\mathbb{C}$ sends this transaction to $\mathbb{IPSC}$, which
verifies $t^{\mathbb{C}}$ and stores $\mu$-$etx$, which is now visible to
$\mathbb{O}$ and the public. Therefore, $\mathbb{O}$ might relay $\mu$-$etx$
to $\mathbb{E}$ for processing and then provide $\mathbb{E}$-signed execution
receipt to $\mathbb{IPSC}$ that publicly resolves this censorship request. On
the other hand, if $\mathbb{O}$ were not to do it, $\mathbb{IPSC}$ would
contain an indisputable proof of censorship by $\mathbb{O}$ on a client
$\mathbb{C}$.

###  4.2. Multiple CBDC Instances

The conceptual model of our interoperable CBDC architecture is depicted in
Figure 2. It consists of multiple CBDC instances (i.e., at least two), whose
$\mathbb{C}s$ communicate in three different ways: (1) directly with each
other, (2) in the instance-to-instance fashion through the infrastructure of
their $\mathbb{O}$ as well as counterpart’s $\mathbb{O}$, (3) through $PB$
with $\mathbb{IPSC}$ of both $\mathbb{O}$s and a global registry
$\mathbb{IMSC}$ managing identities of instances.

For simplified description, in the following we assume the transfer operation
where a local CBDC instance in Figure 2 is A (i.e., the sender of tokens) and
the external one is B (i.e., the receiver of tokens). To ensure
interoperability, we require a communication channel of local clients
$\mathbb{C}s_{A}$ to external clients $\mathbb{C}s_{B}$ (the green arrow), the
local operator $\mathbb{O}_{A}$ (the black arrow), and the external operator
$\mathbb{O}_{B}$ (the black dashed arrow). In our interoperability protocol
$\Pi^{T}$ (described later in Section 4.3), external $\mathbb{C}s_{B}$ use the
channel with the local operator $\mathbb{O}_{A}$ only for obtaining
incremental proofs of $L_{A}$’s history tree to verify inclusion of some
$\mu$-transactions in $L_{A}$. However, there might arise a situation in which
$\mathbb{O}_{A}$ might censor such queries, therefore, we need to address it
by another communication channel – i.e., the public blockchain $PB$.

#### Censorship of External Clients

We allow external clients $\mathbb{C}s_{B}$ to use the same means of
censorship resolution as internal clients of a single CBDC instance (see
Section 4.1.4). To request a resolution of a censored query, the external
$\mathbb{C}_{B}$ uses the access ticket $t^{\mathbb{C}_{B}}$ at
$\mathbb{IPSC}_{A}$, which is issued by $\mathbb{E}_{A}$ in the first phase of
$\Pi^{T}$.

#### Identification of Client Accounts

To uniquely identify $\mathbb{C}$’s account at a particular CBDC instance,
first it is necessary to specify the globally unique identifier of the CBDC
instance. The best candidate is the blockchain address of the $\mathbb{IPSC}$
in $PB$ since it is publicly visible and unique in $PB$ (and we denote it by
$\mathbb{IPSC}$). Then, the identification of $\mathbb{C}$’s relevant account
is a pair $\mathbb{C}^{ID}=\\{PK_{pb}^{\mathbb{C}}||~{}\mathbb{IPSC}\\}$. Note
that $\mathbb{C}$ might use the same $PK_{pb}^{\mathbb{C}}$ for the
registration at multiple CBDC instances (i.e., equivalent of having accounts
in multiple banks); however, to preserve better privacy, making linkage of
$\mathbb{C}$’s instances more difficult, we recommend $\mathbb{C}s$ to have
dedicated key pair for each instance.

####  4.2.1. Identity Management of CBDC Instances

To manage identities of all CBDC instances in the system, we need a global
registry of their identifiers – $\mathbb{IPSC}$ addresses. For this purpose,
we use the $\mathbb{I}$dentity $\mathbb{M}$anagement $\mathbb{S}$mart
$\mathbb{C}$ontract ($\mathbb{IMSC}$) deployed in $PB$ (see program
$prog^{\mathbb{IMSC}}$ in Algorithm 1). We propose $\mathbb{IMSC}$ to be
managed in either decentralized or centralized fashion, depending on the
deployment scenario described below.

### Deployment scenarios

#### Decentralized Scheme

In the decentralized scheme, the enrollment of a new CBDC instance must be
approved by a majority vote of the already existing instances. This might be
convenient for interconnecting central banks from various countries/regions.

The enrollment requires creating a request entry at $\mathbb{IMSC}$ (i.e.,
$newJoinRequest()$) by a new instance specifying the address of its
$\mathbb{IPSC}_{new}$ and $PK_{PB}^{\mathbb{O}_{new}}$. Then, the request has
to be approved by voting of existing instances. Prior to voting (i.e.,
$approveJoinRequest()$), the existing instances should first verify a new
instance by certain legal processes as well as by technical means: do the
remote attestation of $prog^{\mathbb{E}}_{new}$, verify the inflation rate
$i_{r}$ and the initial value of total issued tokens $t_{i}$ in
$\mathbb{IPSC}$, etc. Removing of the existing instance also requires the
majority of all instances, who should verify legal conditions prior to voting.

#### Centralized Scheme

So far, we were assuming that CBDC instances are equal, which might be
convenient for interconnection of central banks from different countries.
However, from the single-country point-of-view, there usually exist only one
central bank, which might not be interested in decentralization of its
competences (e.g., issuing tokens, setting inflation rate) among multiple
commercial banks. We respect this and enable our approach to be utilized for
such a use case, while the necessary changes are made to $\mathbb{IMSC}_{c}$
(see Algorithm 2), allowing to have only one CBDC authority that can add or
delete instances of (commercial) banks, upon their verification (as outlined
above). The new instances can be adjusted even with token issuance capability
and constraints on inflation, which is enforced within the code of
$\mathbb{E}$ as well as $\mathbb{IPSC}$.

$\triangleright$ Declaration of types and variables:

$msg$: a current transaction that called $\mathbb{IMSC}$,

struct InstanceInfo {

$operator$ : $PK_{\mathbb{O}}^{PB}$ of the instance’s $\mathbb{O}$,

$isApproved$: admission status of the instance,

$approvals\leftarrow[]$ : $\mathbb{O}$s who have approved the instance
creation (or deletion),

}

$instances[]$: a mapping of $\mathbb{IPSC}$ to InstanceInfo,

$\triangleright$ Declaration of functions:

function  _$Init$($\mathbb{IPSC}s[],\mathbb{O}s[]$) public $\triangleright$
Initial instances are implicitly approved. _

assert $|\mathbb{IPSC}s|=|\mathbb{O}s|$ ;

for  _$i\leftarrow 0;\ i\leq|\mathbb{O}s|;\ i\leftarrow i+1$_ do

$instances[\mathbb{IPSC}s[i]]\leftarrow\textbf{InstanceInfo}(\mathbb{O}s[i],True,[])$;

function  _$newJoinRequest$($\mathbb{IPSC}$) public _

assert $instances[\mathbb{IPSC}]=~{}\perp$; $\triangleright$ The instance must
not exist yet.

$instances[\mathbb{IPSC}]\leftarrow\textbf{InstanceInfo}(msg.sender,False,[])$;

function  _$approveJoinRequest$($\mathbb{IPSC}_{my},\mathbb{IPSC}_{new}$)
public _

assert $instances[\mathbb{IPSC}_{my}].operator=msg.sender$; $\triangleright$
Sender’s check.

assert $instances[\mathbb{IPSC}_{my}].isApproved$; $\triangleright$ The
sending $\mathbb{O}$ has valid instance.

assert $!instances[\mathbb{IPSC}_{new}].isApproved$; $\triangleright$ The new
instance is not approved.

$r\leftarrow instances[\mathbb{IPSC}_{new}]$;

$r.approvals[msg.sender]\leftarrow True$; $\triangleright$ The sender
acknowledges the request.

if  _$|r.approvals| >\lfloor|instances|/2\rfloor$_ then

$r.isApproved\leftarrow True$; $\triangleright$ Majority vote applies.

$r.approvals\leftarrow[]$; $\triangleright$ Switch this field for a potential
deletion.

function  _$approveDelete$($\mathbb{IPSC}_{my},\mathbb{IPSC}_{del}$) public _

assert $instances[\mathbb{IPSC}_{my}].operator=msg.sender$; $\triangleright$
Sender’s check.

assert $instances[\mathbb{IPSC}_{my}].isApproved$; $\triangleright$ The
sending $\mathbb{O}$ has valid instance.

assert $instances[\mathbb{IPSC}_{del}].isApproved$; $\triangleright$ An
instance to delete must be approved.

$r\leftarrow instances[\mathbb{IPSC}_{del}]$;

$r.approvals[msg.sender]\leftarrow True$; $\triangleright$ The sender
acknowledges the request.

if  _$|r.approvals| >\lfloor|instances|/2\rfloor$_ then

delete $r$;

Algorithm 1 $prog^{\mathbb{IMSC}}_{d}$ of decentralized $\mathbb{IMSC}$

$\triangleright$ Declaration of types and variables:

$msg$: a current transaction that called $\mathbb{IMSC}$,

$authority$: $\mathbb{IPSC}$ of the authority bank,

$authority^{\mathbb{O}}$: $PK^{\mathbb{O}}_{pb}$ of $\mathbb{O}$ at authority
bank,

$instances[]$: a mapping of $\mathbb{IPSC}$ to $PK_{\mathbb{O}}^{PB}$,

$\triangleright$ Declaration of functions:

function  _$Init$($\mathbb{IPSC}$) public $\triangleright$ Initial instances
are implicitly approved. _

$authority^{\mathbb{O}}\leftarrow msg.sender$;

$authority\leftarrow\mathbb{IPSC}$;

function  _$addInstance$($\mathbb{IPSC}_{new},~{}\mathbb{O}_{new}$) public _

assert $msg.sender=authority^{\mathbb{O}}$ ; $\triangleright$ Only the
authority can add instances.

assert $instances[\mathbb{IPSC}_{new}]=~{}\perp$; $\triangleright$ The
instance must not exist yet.

$instances[\mathbb{IPSC}_{new}]\leftarrow\mathbb{O}_{new}$;

function  _$delInstance$($\mathbb{IPSC}_{del}$) public _

assert $msg.sender=authority^{\mathbb{O}}$ ; $\triangleright$ Only the
authority can delete instances.

delete $instances[\mathbb{IPSC}_{del}]$;

Algorithm 2 $prog^{\mathbb{IMSC}}_{c}$ of centralized $\mathbb{IMSC}$

####  4.2.2. Token Issuance

With multiple CBDC instances, $\mathbb{C}$s and the public can obtain the
total value of issued tokens in the ecosystem of CBDC and compare it to the
total value of token supply of all instances. Nevertheless, assuming only two
instances A and B, the value of $t_{s}$ snapshotted by $\mathbb{IPSC}_{A}$
might not reflect the recently executed transfers to instance B that might
have already made the snapshot of its actual $L_{B}$ version to
$\mathbb{IPSC}_{B}$, accounting for the transfers. As a consequence, given a
set of instances, the value of the aggregated $t_{s}$ should always be greater
or equal than the corresponding sum of $t_{i}$:

(1) $\displaystyle t_{i}^{A}+t_{i}^{B}$ $\displaystyle\leq$ $\displaystyle
t_{s}^{A}+t_{s}^{B}.$

We can generalize it for $N$ instances known by $\mathbb{IMSC}$ as follows:

(2) $\displaystyle\sum_{\forall X~{}\in~{}\mathbb{IMSC}}t_{i}^{X}$
$\displaystyle\leq$ $\displaystyle\sum_{\forall
X~{}\in~{}\mathbb{IMSC}}t_{s}^{X}.$

####  4.2.3. Inflation Rate

In contrast to a single CBDC instance, multiple independent instances must
provide certain guarantees about inflation not only to their clients, but also
to each other. For this purpose, the parameter inflation rate $i_{r}$ is
adjusted to a constant value in the initialization of $\mathbb{IPSC}$ and
checked before the instance is approved at $\mathbb{IMSC}$.

If one would like to enable the update of $i_{r}$ at CBDC instances, a
majority vote at $\mathbb{IMSC}$ on a new value could be utilized (or just the
vote of authority in the case of centralized scenario). Nevertheless, to
support even fairer properties, $\mathbb{C}$s of a particular instance might
vote on the value of $i_{r}$ upon its acceptance by $\mathbb{IOMC}$ and before
it is propagated to $\mathbb{IPSC}$ of an instance. Then, based on the new
value of $\mathbb{IPSC}.i_{r}$, $\mathbb{E}.i_{r}$ can be adjusted as well
(i.e., upon the validation by the light client of $\mathbb{E}$). However, the
application of such a mechanism might depend on the use case, and we state it
only as a possible option that can be enabled in our approach.

$\triangleright$ Declaration of types and variables:

$\mathbb{E}$, $\triangleright$ The reference to $\mathbb{E}_{A}$ of sending
party.

$msg$, $\triangleright$ The current $\mu$-transaction that called
$\mathbb{IOMC}^{S}$.

struct LockedTransfer {

$sender$, $\triangleright$ Sending client $\mathbb{C}_{A}$.

$receiver$, $\triangleright$ Receiving client $\mathbb{C}_{B}$.

$receiver\mathbb{IPSC}$, $\triangleright$ The $\mathbb{IPSC}$ contract address
of the receiver’s instance.

$amount$, $\triangleright$ Amount of tokens sent.

$hashlock$, $\triangleright$ Hash of the secret of the sending
$\mathbb{C}_{A}$.

$timelock$, $\triangleright$ A timestamp defining the end of validity of the
transfer.

$isCompleted$, $\triangleright$ Indicates whether the transfer has been
completed.

$isReverted$, $\triangleright$ Indicates whether the transfer has been
canceled.

},

$transfers\leftarrow[]$, $\triangleright$ Initiated outgoing transfers (i.e.,
LockedTransfer).

const $timeout^{HTLC}\leftarrow 24h$, $\triangleright$ Set the time lock for
e.g., 24 hours.

$\triangleright$ Declaration of functions:

function  _$sendInit$($receiver,receiver\mathbb{IPSC},hashlock$) public
payable _

assert $msg.value>0$; $\triangleright$ Checks the amount of tokens.

$timelock\leftarrow timestamp.now()+timeout^{HTLC}$;

$t\leftarrow\textbf{LockedTransfer}(msg.sender,receiver,receiver\mathbb{IPSC},$

$msg.value$, $hashlock,timelock,False,False)$; $\triangleright$ A new
receiving transfer.

$transfers.append(t)$;

Output $("sendInitialized",transferID\leftarrow|transfers|-1))$;

function  _$sendCommit$($transferID,secret,extTransferID$) public _

assert $transfers[transferID]\neq\perp$; $\triangleright$ Check the existence
of locked transfer.

$t\leftarrow transfers[transferID]$;

assert $t.hashlock=h(secret)$; $\triangleright$ Check the secret.

assert $!t.isCompleted~{}\wedge~{}!t.isReverted$; $\triangleright$ Test if the
transfer is still pending.

$t.isCompleted\leftarrow True$;

burn t.amount; $\triangleright$ Burn tokens.

$\mathbb{E}.t_{s}\leftarrow\mathbb{E}.t_{s}-t.amount$; $\triangleright$
Decrease the total supply of the instance.

Output $("sendCommitted",transferID,$ $extTransferID,$ $t.receiver,$
$t.receiver\mathbb{IPSC},$ $t.amount)$;

function  _$sendRevert$($transferID$) public _

assert $transfers[transferID]\neq\perp$; $\triangleright$ Check the existence
of locked transfer.

$t\leftarrow transfers[transferID]$;

assert $!t.isCompleted~{}\wedge~{}!t.isReverted$; $\triangleright$ Test the
transfer is still pending.

assert $t.timelock\leq timestamp.now()$; $\triangleright$ Check the HTLC
expiration.

$transfer(t.amount,t.sender)$; $\triangleright$ Returning tokens back to the
sender.

$t.isReverted\leftarrow True$;

Output$("sendReverted",transferID)$;

Algorithm 3 $prog^{\mathbb{IOMC}^{S}}$ of sending $\mathbb{IOMC}^{S}$

####  4.2.4. Interoperability

The interoperability logic itself is provided by our protocol $\Pi^{T}$ that
utilizes $\mathbb{I}$nter$\mathbb{O}$perability $\mathbb{M}$icro
$\mathbb{C}$ontracts $\mathbb{IOMC}^{S}$ and $\mathbb{IOMC}^{R}$, which serve
for sending and receiving tokens, respectively. Therefore, in the context of
$\mathbb{E}$-isolated environment these $\mu$-contracts allow to mint and burn
tokens, reflecting the changes in $t_{s}$ after sending or receiving tokens
between CBDC instances. Both $\mu$-contracts are deployed in $\mathbb{E}$ by
each $\mathbb{O}$ as soon as the instance is created, while $\mathbb{E}$
records their addresses that can be obtained and attested by $\mathbb{C}$s. We
briefly review these contracts in the following, and we will demonstrate their
usage in Section 4.3.

#### The Sending $\mathbb{IOMC}^{S}$

The sending $\mathbb{IOMC}^{S}$ (see Algorithm 3) is based on Hash Time LoCks
(HTLC), thus upon initialization of transfer by $hashlock$ provided by
$\mathbb{C}_{A}$ (i.e., $hashlock\leftarrow h(secret)$) and calling
$sendInit(hash\\-lock,\ldots)$, $\mathbb{IOMC}^{S}$ locks transferred tokens
for the timeout required to complete the transfer by
$send\\-Commit\\-(secret,\ldots)$. If tokens are not successfully transferred
to the recipient of the external instance during the timeout, they can be
recovered by the sender (i.e., $sendRevert()$).666Note that setting a short
timeout might prevent the completion of the protocol. If tokens were sent
successfully from $\mathbb{C}_{A}$ to $\mathbb{C}_{B}$, then instance A burns
them within $sendCommit()$ of $\mathbb{IOMC}^{S}$ and deducts them from
$t_{s}$. Note that deducting $t_{s}$ is a special operation that cannot be
executed within standard $\mu$-contracts, but $\mathbb{IOMC}$ contracts are
exceptions and can access some variables of $\mathbb{E}$.

#### The Receiving $\mathbb{IOMC}^{R}$

The receiving $\mathbb{IOMC}^{R}$ (see Algorithm 4) is based on Hashlocks
(referred to as HLC) and works pairwise with sending $\mathbb{IOMC}^{S}$ to
facilitate four phases of our interoperable transfer protocol $\Pi_{T}$
(described below). After calling $\mathbb{IOMC^{S}}.sendInit()$, incoming
initiated transfer is recorded at $\mathbb{IOMC}^{R}$ by
$receiveInit(hash\\-lock,\ldots)$. Similarly, after executing token deduction
at instance A (i.e., $\mathbb{IOMC^{S}}.send\\-Commit\\-(secret,\ldots)$),
incoming transfer is executed at $\mathbb{IOMC}^{R}$ by
$receiveCommit(secret,\ldots)$ that mints tokens to $\mathbb{C}_{B}$ and
increases $t_{s}$. Similar to $\mathbb{IOMC}^{S}$, minting tokens and
increasing $t_{s}$ are special operations requiring access to $\mathbb{E}$,
which is exceptional for $\mathbb{IOMC}$. The overview of $\Pi_{T}$ is
depicted in Figure 3.

$\triangleright$ Declaration of types and variables:

$\mathbb{E}$, $\triangleright$ The reference to $\mathbb{E}_{B}$ of receiving
party.

struct LockedTransfer {

$sender$, $\triangleright$ Sending client $\mathbb{C}_{A}$.

$sender\mathbb{IPSC}$, $\triangleright$ The IPSC contract address of the
sender’s instance.

$receiver$, $\triangleright$ Receiving client $\mathbb{C}_{B}$.

$amount$, $\triangleright$ Amount of transferred tokens.

$hashlock$, $\triangleright$ Hash of the secret of the sending
$\mathbb{C}_{A}$.

$isCompleted$, $\triangleright$ Indicates whether the transfer has been
completed.

},

$transfers\leftarrow[]$, $\triangleright$ Initiated incoming transfers (i.e.,
LockedTransfer).

$\triangleright$ Declaration of functions:

function  _$receiveInit$($sender,sender\mathbb{IPSC},hashlock,amount$) public
_

assert $amount>0$;

$t\leftarrow\textbf{LockedTransfer}(sender,sender\mathbb{IPSC},msg.sender,amount,$

$hashlock,False)$; $\triangleright$ Make a new receiving transfer entry.

$transfers.append(t)$;

Output$("receiveInitialized",transferID\leftarrow|transfers|-1)$;

function  _$receiveCommit$($transferID,secret$) public _

assert $transfers[transferID]~{}\neq~{}\perp$; $\triangleright$ Check the
existence of transfer entry.

$t\leftarrow transfers[transferID]$;

assert $t.hashlock=h(secret)$; $\triangleright$ Check the secret.

assert $!t.isCompleted$; $\triangleright$ Check whether the transfer is
pending.

$\mathbb{E}.mint(this,t.amount)$; $\triangleright$ Call $\mathbb{E}$ to mint
tokens on $\mathbb{IOMC}_{R}$.

$\mathbb{E}.t_{s}\leftarrow\mathbb{E}.t_{s}+t.amount$ ; $\triangleright$
Increase the total supply of the instance.

$transfer(t.amount,t.receiver)$; $\triangleright$ Credit tokens to the
recipient.

$t.isCompleted\leftarrow True$;

Output$("receiveCommited",transferID)$;

Algorithm 4 $prog^{\mathbb{IOMC}^{R}}$ of receiving $\mathbb{IOMC}^{R}$ Figure
3. Overview of the protocol $\Pi^{T}$, consisting of 4 phases.

###  4.3. Interoperable Transfer Protocol $\mathbf{\Pi^{T}}$

In this section we outline our instance-to-instance interoperable transfer
protocol $\Pi^{T}$ for inter-CBDC transfer operation, which is inspired by the
atomic swap protocol (see Section 2.4), but in contrast to the exchange-
oriented approach of atomic swap, $\Pi^{T}$ focuses only on one-way atomic
transfer between instances of the custodial environment of CBDC, where four
parties are involved in each transfer – a sending $\mathbb{C}_{A}$ and
$\mathbb{O}_{A}$ versus a receiving $\mathbb{C}_{B}$ and $\mathbb{O}_{B}$. The
goal of $\Pi^{T}$ is to eliminate any dishonest behavior by $\mathbb{C}s$ or
$\mathbb{O}$s that would incur token duplication or the loss of tokens.

Figure 4. The details of the proposed interoperability protocol $\Pi^{T}$.

To execute $\Pi^{T}$ it is necessary to inter-connect $\mathbb{E}$s of two
instances involved in a transfer. However, $\mathbb{E}$ does not allow direct
communication with the outside world, and therefore it is necessary to use an
intermediary. One solution is to involve $\mathbb{O}$s but they might be
overwhelmed with other activities, updating the ledger by executing
$\mu$-transactions, and moreover, they might not have direct incentives to
execute inter-CBDC transfers. Therefore, we argue that in contrast to the
above option, involving $\mathbb{C}s$ as intermediaries has two advantages:
(1) elimination of the synchronous communication overhead on $\mathbb{O}$s and
(2) enabling $\mathbb{C}$s to have a transparent view about the status of the
transfer and take action if required. In the following, we describe phases of
$\Pi^{T}$ in detail (see also Figure 4).

### Phase 1 – Client $\mathbb{C}_{A}$ Initiates the Protocol

The client $\mathbb{C}_{A}$ creates a $\mu$-tx1 with the amount being sent,
which invokes the sendInit() of $\mathbb{IOMC}_{A}$ with arguments containing
the address of the external client $\mathbb{C}_{B}$, the address of
$\mathbb{IPSC}_{B}$ (denoted as $\mathbb{S}_{B}$ in Figure 4 for brevity), and
the hash of the secret that is created by $\mathbb{C}_{A}$. $\mathbb{C}_{A}$
sends signed $\mu$-tx1 to $\mathbb{O}_{A}$ who forwards it to the
$\mathbb{E}_{A}$. Before executing the $\mu$-tx1, $\mathbb{E}_{A}$ ensures
that the external recipient (i.e., $\mathbb{C}_{B}$) has the access ticket
already issued and valid, enabling her to post censorship resolution requests
to $\mathbb{IPSC}_{A}$ (if needed). The access ticket should be valid for at
least the entire period defined by the HTLC of $\mathbb{IOMC}_{A}$. In the
next step, a $\mu$-tx1 is executed by $\mathbb{E}_{A}$, creating a new
transfer record with $transferId$ in $\mathbb{IOMC}_{A}$. During the
execution, $\mathbb{C}_{A}$’s tokens are transferred (and thus locked) to the
$\mathbb{IOMC}_{A}$’s address. $\mathbb{C}_{A}$ waits until the new version of
$L_{A}$ is snapshotted to $\mathbb{IPSC}_{A}$, and then obtains $LRoot^{A}$
from it. Then $\mathbb{C}_{A}$ asks $\mathbb{O}_{A}$ for the execution receipt
$rcp_{1}$ of $\mu$-tx1 that also contains a set of proofs ($\pi_{hdr}^{mem}$,
$\pi_{rcp_{1}}^{mk}$) and the header of the $\mu$-block that includes
$\mu$-tx1. In detail, $\pi_{hdr}^{mem}$ is the inclusion proof of the
$\mu$-block b in the current version of $L_{A}$; $\pi_{rcp_{1}}^{mk}$ is the
Merkle proof proving that $rcp_{1}$ is included in b (while $rcp_{1}$ proves
that $\mu$-tx1 was executed correctly). The mentioned proofs and the receipt
are provided to $\mathbb{C}_{B}$, who verifies that $\mu$-tx1 was executed and
included in the $L_{A}$’s version that is already snapshotted to
$\mathbb{IPSC}_{A}$, thus irreversible (see below).

### Phase 2 – $\mathbb{C}_{B}$ Initiates Receive

First, $\mathbb{C}_{B}$ validates an access ticket to $\mathbb{IPSC}_{A}$
using the enclave $\mathbb{E}_{A}$’s public key accessible in that smart
contract. Next, $\mathbb{C}_{B}$ obtains the root hash $LRoot_{pb}^{A}$ of
$L_{A}$ to ensure that $\mathbb{C}_{B}$’s received state has been already
published in $\mathbb{IPSC}_{A}$, and thus contains $\mu$-tx1. After obtaining
$LRoot_{pb}^{A}$, $\mathbb{C}_{B}$ forwards it along with the root $LRoot^{A}$
obtained from $\mathbb{C}_{A}$ to $\mathbb{O}_{A}$, who creates an incremental
proof $\pi^{inc}$ of $\langle LRoot^{A},LRoot_{pb}^{A}\rangle$. Once the proof
$\pi^{inc}$ has been obtained and validated, the protocol can proceed to
validate the remaining proofs sent by the client $\mathbb{C}_{A}$ along with
verifying that the receiving address belongs to $\mathbb{C}_{B}$. Next,
$\mathbb{C}_{B}$ creates $\mu$-$tx_{2}$, invoking the method receiveInit()
with the arguments: the address of $\mathbb{C}_{A}$ obtained from
$\mu$-$tx_{1}$,777Note that we assume that the address is extractable from the
signature. the address $\mathbb{IPSC}_{A}.addr$ of $\mathbb{C}_{A}$’s
instance, the hash value of the secret, and the amount of crypto-tokens being
sent. $\mathbb{C}_{B}$ sends $\mu$-$tx_{2}$ to $\mathbb{O}_{B}$, who forwards
it to $\mathbb{E}_{B}$ for processing. During processing of $\mu$-$tx_{2}$,
$\mathbb{E}_{B}$ determines whether the external client (from its point of
view – i.e., $\mathbb{C}_{A}$) has an access ticket issued with a sufficiently
long validity period; if not, one is created. Subsequently, $\mathbb{E}_{B}$
creates a new record in $\mathbb{IOMC}_{B}$ with $extTransferId$. Afterward,
$\mathbb{C}_{B}$ retrieves the $LRoot^{B}$ from $L_{B}$ and requests the
execution receipt $rcp_{2}$ from $\mathbb{O}_{B}$, acknowledging that the
$\mu$-$tx_{2}$ has been executed. Finally, $\mathbb{C}_{B}$ sends a message
$\mathbb{C}_{A}$ with $\mu$-$tx_{2}$ and cryptographic proofs
$\pi_{hdr}^{mem}$, $\pi_{rcp_{2}}^{mk}$, the execution receipt of
$\mu$-$tx_{2}$, the block header $b$ in which the $\mu$-$tx_{2}$ was included,
$LRoot^{B}$ (i.e., the root value of $L_{B}$ after $\mu$-$tx_{2}$ was
executed), and the valid client access ticket for $\mathbb{C}_{A}$.

### Phase 3 – Confirmation of Transfer by $\mathbb{C}_{A}$

First, $\mathbb{C}_{A}$ validates the received access ticket to
$\mathbb{IPSC}_{B}$. Next, $\mathbb{C}_{A}$ obtains the snapshotted root hash
$LRoot_{pb}^{B}$ of $L_{B}$ from $\mathbb{IPSC}_{B}$. As in the previous
phases, it is necessary to verify that the version of $L_{B}$ that includes
$\mu$-$tx_{2}$ is represented by $LRoot_{pb}^{B}$ (thus is irreversible).
Next, both root hashes ($LRoot^{B}$ and $LRoot_{pb}^{B}$) are sent to the
external operator $\mathbb{O}_{B}$, which produces the incremental proof
$\pi^{inc}$ from them. Next, $\mathbb{C}_{A}$ creates $\mu$-$tx_{3}$ that
consists of invoking the sendCommit() method at $\mathbb{E}_{A}$ with the
arguments containing the published secret (i.e., $preimage$) and the record
identifier of the transfer at local instance (i.e., $transferId$) as well as
the external one (i.e., $extTransferId$). Along with the invocation of
sendCommit(), $\mu$-$tx_{3}$ also wraps $\pi^{inc}$ with its versions
($LRoot_{pb}^{B}$ and $LRoot^{B}$), $\mu$-$tx_{2}$, its execution receipt
$rcp_{2}$ with its Merkle proof $\pi_{rcp_{2}}^{mk}$, $b.hdr$ – the header of
the block that included $\mu$-$tx_{2}$, and its membership proof
$\pi^{mem}_{hdr}$ of $L_{B}$. Next, $\mathbb{C}_{A}$ sends $\mu$-$tx_{3}$ to
$\mathbb{E}_{A}$ through $\mathbb{O}_{A}$. During the execution of
$\mu$-$tx_{3}$, $\mathbb{E}_{A}$ validates the provided proofs and the
equality of transfer IDs from both sides of the protocol. Note that to verify
$\pi^{mem}_{hdr}$, $\mathbb{E}_{A}$ uses its light client to $L_{B}$.
$\mathbb{E}_{A}$ then validates whether $\mathbb{C}_{A}$’s provided secret
corresponds to the hashlock recorded in the 1st phase of the protocol, and if
so, it burns the sent balance of the transfer.

Next, $\mathbb{C}_{A}$ waits until the new version of $L_{A}$ is snapshotted
to $\mathbb{IPSC}_{A}$, and then obtains $LRoot^{A}$ from it. Then
$\mathbb{C}_{A}$ asks $\mathbb{O}_{A}$ for the execution receipt $rcp_{3}$ of
$\mu$-tx3 that also contains a set of proofs ($\pi_{hdr}^{mem}$,
$\pi_{rcp_{3}}^{mk}$) and the header of the $\mu$-block that includes
$\mu$-tx3. The proofs have the same interpretation as in the end of the 1st
phase. The mentioned proofs and the receipt are provided to $\mathbb{C}_{B}$,
who verifies that $\mu$-tx1 was executed and included in the $L_{A}$’s version
that is already snapshotted to $\mathbb{IPSC}_{A}$, thus irreversible.

### Phase 4 – Acceptance of Tokens by $\mathbb{C}_{B}$

After receiving a message from client $\mathbb{C}_{A}$, the client
$\mathbb{C}_{B}$ obtains $LRoot_{pb}^{A}$ from $\mathbb{IPSC}_{A}$ and then
requests the incremental proof between versions $\langle
LRoot^{A},LRoot_{pb}^{A}\rangle$ from $\mathbb{O}_{A}$. Then, $\mathbb{C}_{B}$
creates $\mu$-$tx_{4}$ invoking the receiveClaim() function at
$\mathbb{E}_{B}$ with $transferId$ and the disclosed secret by
$\mathbb{C}_{A}$ as the arguments. Moreover, $\mu$-$tx_{4}$ contains remaining
items received from $\mathbb{C}_{A}$. Then, $\mu$-$tx_{4}$ is sent to
$\mathbb{O}_{B}$, who forwards it to $\mathbb{E}_{B}$. During the execution of
$\mu$-$tx_{4}$, $\mathbb{E}_{B}$ verifies the provided proofs, the equality of
transfer IDs from both sides of the protocol, the amount being sent, and the
receiver of the transfer (i.e., $\mathbb{C}_{B}$ —— $\mathbb{IPSC}_{B}$). Note
that to verify $\pi^{mem}_{hdr}$, $\mathbb{E}_{B}$ uses its light client to
$L_{A}$. $\mathbb{E}_{A}$ then validates whether $\mathbb{C}_{A}$’s provided
secret corresponds to the hashlock recorded in the 2nd phase of the protocol,
and if so, it mints the sent balance of the transfer on the receiver’s account
$\mathbb{C}_{B}$. Finally, $\mathbb{C}_{B}$ verifies that $\mu$-$tx_{4}$ was
snapshotted at $\mathbb{IPSC}_{B}$, thus is irreversible. In detail, first
$\mathbb{C}_{B}$ obtains $LRoot_{pb}^{B}$ from $\mathbb{IPSC}_{B}$ and then
asks $\mathbb{O}_{B}$ to provide her with the execution receipt $rcp_{4}$ of
$\mu$-$tx_{4}$ in the version of $L_{B}$ that is equal or newer than
$LRoot_{pb}^{B}$. Then, $\mathbb{C}_{B}$ verifies $rcp_{4}$, which completes
the protocol.

##  5\. Implementation & Evaluation

The work is built on a proof-of-concept implementation of the decentralized
smart contract platform Aquareum in C++ and Intel SGX technology for enclave
instantiation. The IPSC contract on the public blockchain is constructed using
the Solidity programming language and is prepared for deployment on the
Ethereum network. The enclave employs the OpenEnclave SDK development
tool,888https://openenclave.io/sdk/, which is compatible with several TEE
technologies and OS systems. Aquareum incorporates the Ethereum virtual
machine – EVM, in its stripped-down, minimalist version eEVM.999Microsoft’s
Enclave EVM is available at https://github.com/microsoft/eEVM.

####  5.0.1. Implementation Details

The C++ written client application enables the clients to execute internal and
external (i.e., between two instance) transfer operations as well as invoking
internal and external functions of micro contracts. The operator component is
represented by the C++ written server implemented as a concurrent non-blocking
application that processes messages from clients. So far, the PoC of the
server enables to process three types of messages: transaction execution,
client registration, query for IOMC contract addresses.

###  5.1. Evaluation

We used Ganache101010https://github.com/trufflesuite/ganache-cli and
Truffle,111111https://github.com/trufflesuite/truffle to develop
$\mathbb{IOMC}$, $\mathbb{IPSC}$, and $\mathbb{IMSC}$ contracts. In addition,
using the Pexpect121212https://github.com/pexpect/pexpect tool, we tested the
intercommunication of the implemented components and validated the correctness
of the implemented interoperability protocol. The tool enabled the parallel
execution and control of numerous programs (in this case, multiple Aquareum
instances and client programs) to check the correctness of the expected
output.

The computational cost of executing the operations defined in $\mathbb{IOMC}$
and $\mathbb{IMSC}^{X}$ contracts is presented in Table 1, Table 2, and Table
3.131313Note that we do not provide the gas measurements for $\mathbb{IPSC}$
since these are almost the same as in Aquareum (Homoliak and Szalachowski,
2020). We optimized our implementation to minimize the storage requirements of
smart contract platform. On the other hand, it is important to highlight that
$\mathbb{IOMC}^{X}$ $\mu$-contracts are executed on a private ledger
corresponding to the instance of CBDC, where the cost of gas is minimal or
negligible as compared to a public blockchain. Other experiments are the
subject of our future work.

Function |  constructor |  sendInitialize |  sendCommit |  sendRevert
---|---|---|---|---
Deployment | 901 509 | 160 698 | 64 629 | 60 923
Execution | 653 689 | 134 498 | 42 717 | 39 523
Table 1. The cost of deployment and invocation of functions in the sending $\mathbb{IOMC}^{S}$ $\mu$-contract in gas units (CBDC private ledger). Function |  constructor |  receiveInit |  receiveClaim |  fund
---|---|---|---|---
Deployment | 716 330 | 139 218 | 61 245 | 23 168
Execution | 509 366 | 112 762 | 39 653 | 1 896
Table 2. The cost of deployment and invocation of functions in the receiving $\mathbb{IOMC}^{R}$ $\mu$-contract in units of gas (CBDC private ledger). Function |  constructor |  newJoinRequest |  approveRequest |  isApproved
---|---|---|---|---
Deployment | 830 074 | 48 629 | 69 642 | 0
Execution | 567 838 | 25 949 | 45 554 | 0
Table 3. The invocation cost of functions in $\mathbb{IMSC}$ smart contract in
units of gas (Ethereum public blockchain).

##  6\. Security Analysis

In this section, we analyze our approach in terms of security-oriented
features and requirements specified in Section 3. In particular, we focus on
resilience analysis of our approach against adversarial actions that the
malicious CBDC instance (i.e., its operator $\mathcal{O}$) or malicious client
(i.e., $\mathcal{C}$) can perform to violate the security requirements.

###  6.1. Single Instance of CBDC

###### Theorem 1.

(Correctness of Operation Execution) $\mathcal{O}$ is unable to modify the
full state of $L$ in a way that does not respect the semantics of VM deployed
in $\mathbb{E}$ of CBDC instance.

###### Justification.

The update of the $L$’s state is performed exclusively in $\mathbb{E}$. Since
$\mathbb{E}$ contains trusted code that is publicly known and remotely
attested by $\mathbb{C}$s, $\mathcal{O}$ cannot tamper with this code. ∎

###### Theorem 2.

(Integrity) $\mathcal{O}$ is unable to modify the past records of $L$, and no
conflicting transactions can be stored in $L$.

###### Justification.

All extensions of $L$ are performed within trusted code of $\mathbb{E}$ (see
Theorem 1), while utilizing the history tree (Crosby and Wallach, 2009) as a
tamper evident data structure, which enables us to make only such incremental
extensions of $L$ that are consistent with $L$’s past. ∎

###### Theorem 3.

(Verifiability) $\mathcal{O}$ is unable to unnoticeably modify or delete a
transaction $tx$ that was previously inserted to $L$, if sync with
$\mathbb{IPSC}$ was executed anytime afterward.

###### Justification.

Since $tx$ was correctly executed (Theorem 1) as a part of the block $b_{i}$
in a trusted code of $\mathbb{E}$, $\mathbb{E}$ produced a signed version
transition pair $\\{h(L_{i-1}),h(L_{i}),t_{i},t_{s}\\}_{\mathbb{E}}$ of $L$
from the version $i-1$ to the new version $i$ that corresponds to $L$ with
$b_{i}$ included. $\mathcal{O}$ could either sync $L$ with $\mathbb{IPSC}$
immediately after $b_{i}$ was appended or she could do it $n$ versions later.
In the first case, $\mathcal{O}$ published
$\\{h(L_{i-1}),h(L_{i}),t_{i},t_{s}\\}_{\mathbb{E}}$ to $\mathbb{IPSC}$, which
updated its current version of $L$ to $i$ by storing $h(L_{i})$ into
$\mathbb{IPSC}.LRoot_{pb}$. In the second case, $n$ blocks were appended to
$L$, obtaining its $(i+n)$th version. $\mathbb{E}$ executed all transactions
from versions $(i+1),\ldots,(i+n)$ of $L$, while preserving correctness
(Theorem 1) and integrity (Theorem 2). Then $\mathbb{E}$ generated a version
transition pair $\\{h(L_{i-1}),h(L_{i+n}),t_{i},t_{s}\\}_{\mathbb{E}}$ and
$\mathcal{O}$ posted it to $\mathbb{IPSC}$, where the current version of $L$
was updated to $i+n$ by storing $h(L_{i+n})$ into $\mathbb{IPSC}.LRoot_{pb}$.
When any $\mathbb{C}$ requests $tx$ and its proofs from $\mathcal{O}$ with
regard to publicly visible $\mathbb{IPSC}.LRoot_{pb}$, she might obtain a
modified $tx^{\prime}$ with a valid membership proof $\pi^{mem}_{hdr_{i}}$ of
the block $b_{i}$ but an invalid Merkle proof $\pi^{mk}_{tx^{\prime}}$, which
cannot be forged. $\Box$ In the case of $tx$ deletion, $\mathcal{O}$ provides
$\mathbb{C}$ with the tampered full block $b_{i}^{\prime}$ (maliciously
excluding $tx$) whose membership proof $\pi^{mem}_{hdr_{i}^{\prime}}$ is
invalid – it cannot be forged. ∎

###### Theorem 4.

(Non-Equivocation) Assuming $L$ synced with $\mathbb{IPSC}$: $\mathcal{O}$ is
unable to provide two distinct $\mathbb{C}$s with two distinct valid views on
$L$.

###### Justification.

Since $L$ is periodically synced with publicly accessible $\mathbb{IPSC}$, and
$\mathbb{IPSC}$ stores only a single current version of $L$ (i.e.,
$\mathbb{IPSC}.LRoot_{pb}$), all $\mathbb{C}s$ share the same view on $L$. ∎

###### Theorem 5.

(Censorship Evidence) $\mathcal{O}$ is unable to censor any request
(transaction or query) from $\mathbb{C}$ while staying unnoticeable.

###### Justification.

If $\mathbb{C}$’s request is censored by CBDC’s operator $\mathcal{O}$,
$\mathbb{C}$ can ask for a resolution of the request through public
$\mathbb{IPSC}$. $\mathcal{O}$ observing the request might either ignore it
and leave the indisputable proof of censorship at $\mathbb{IPSC}$ or she might
submit the request to $\mathbb{E}$ and obtain an enclave-signed proof
witnessing that a request was processed (hence have not remained censored) –
this proof is submitted to $\mathbb{IPSC}$, whereby publicly resolving the
request. ∎

###### Theorem 6.

(Privacy) $\mathcal{C}$ is unable to obtain plain text of $\mu$-transactions
of other $\mathbb{C}$s even during the censorship resolution.

###### Justification.

$\mu$-transactions are sent to $\mathbb{O}$ in TLS-encrypted messages. In the
case of censorship resolution, submitted $\mu$-transactions by $\mathbb{C}$ to
public $\mathbb{IPSC}$ are encrypted by $\mathbb{E}$’s public key
$PK_{\mathbb{E}}^{tee}$. ∎

###### Theorem 7.

(Transparent Token Issuance) $\mathcal{O}$ is unable to issue or burn any
tokens without leaving a publicly visible evidence.

###### Justification.

All issued tokens of CBDC are publicly visible at $\mathbb{IPSC}$ since each
transaction posting a new version transition pair also contains
$\mathbb{E}$-signed information about the current total issued tokens $t_{i}$
and total supply of the instance $t_{s}$,141414Note that in the case of single
CBDC instance $t_{i}=t_{s}$ while $t_{i}$ was updated within the trusted code
of $\mathbb{E}$. The information about $t_{i}$ is updated at $\mathbb{IPSC}$
along with the new version of $L$. Note that the history of changes in total
issued tokens $t_{i}$ can be parsed from all transactions updating version of
$L$ published by $\mathcal{O}$ to $PB$. ∎

###  6.2. Multiple Instances of CBDC

In the following, we assume two CBDC instances A and B.

###### Theorem 8.

(Atomic Interoperability I) Neither $\mathcal{O}_{A}$ (operating $A$) nor
$\mathcal{O}_{B}$ (operating $B$) is unable to steal any tokens during the
inter-bank CBDC transfer.

###### Justification.

Atomic interoperability is ensured in our approach by adaptation of atomic
swap protocol for all inter-bank transfers, which enables us to preserve the
wholesale environment of CBDC in a consistent state (respecting Equation 2).
In detail, the transferred tokens from CBDC instance $A$ to instance $B$ are
not credited to $B$ until $A$ does not provide the indisputable proof that
tokens were deducted from a relevant $A$’s account. This proof confirms
irreversible inclusion of $tx_{3}$ (i.e., $\mathbb{E}_{A}.sendCommit()$ that
deducts account of $A$’s client) in $A$’s ledger and it is verified in 4th
stage of our protocol by the trusted code of $\mathbb{E}_{B}$.

In the case that $\mathcal{O}_{A}$ would like to present $B$ with integrity
snapshot of $L_{A}$ that was not synced to $\mathbb{IPSC}_{A}$ yet, B will not
accept it since the 4th phase of our protocol requires $\mathcal{O}_{B}$ to
fetch the recent $\mathbb{IPSC}_{A}.LRoot_{pb}$ and verify its consistency
with A-provided $LRoot$ as well as inclusion proof in $PB$; all
executed/verified within trusted code of $\mathbb{E}_{B}$. ∎

###### Theorem 9.

(Atomic Interoperability II) Colluding clients $\mathcal{C}_{A}$ and
$\mathcal{C}_{B}$ of two CBDC instances cannot steal any tokens form the
system during the transfer operation of our protocol.

###### Justification.

If the first two phases of our protocol have been executed, $\mathcal{C}_{A}$
might potentially reveal the $preimage$ to $\mathcal{C}_{B}$ without running
the 3rd phase with the intention to credit the tokens at $B$ while deduction
at $A$ had not been executed yet. However, this is prevented since the trusted
code of $\mathbb{E}_{B}$ verifies that the deduction was performed at $A$
before crediting the tokens to $\mathcal{C}_{B}$ – as described in Theorem 8.
∎

###### Theorem 10.

(Inter-CBDC Censorship Evidence) $\mathcal{O}_{A}$ is unable to unnoticeably
censor any request (transaction or query) from $\mathbb{C}_{B}$.

###### Justification.

If $\mathbb{C}_{B}$’s request is censored by $\mathcal{O}_{A}$,
$\mathbb{C}_{B}$ can ask for a resolution of the request through public
$\mathbb{IPSC}_{A}$ since $\mathbb{C}_{B}$ already has the access ticket to
instance $A$. The access ticket is signed by $\mathbb{E}_{A}$ and thus can be
verified at $\mathbb{IPSC}_{A}$. Hence, the censorship resolution/evidence is
the same as in Theorem 5 of a single CBDC instance. ∎

###### Theorem 11.

(Inter-CBDC Censorship Recovery) A permanent inter-CBDC censorship by
$\mathcal{O}_{A}$ does not cause an inconsistent state or permanently frozen
funds of undergoing transfer operations at any other CBDC instance – all
initiated and not finished transfer operations can be recovered from.

###### Justification.

If $\mathcal{O}_{A}$ were to censor $\mathbb{C}_{B}$ in the 2nd phase of our
protocol, no changes at ledger $L_{B}$ would be made. If $\mathcal{O}_{A}$
were to censor $\mathbb{C}_{B}$ in the 4th phase of our protocol, $L_{B}$
would contain an initiated transfer entry, which has not any impact on the
consistency of the ledger since it does not contain any locked tokens. $\Box$

If $\mathcal{O}_{B}$ were to censor $\mathbb{C}_{A}$ in the 3rd phase of our
protocol, $A$ would contain some frozen funds of the initiated transfer.
However, these funds can be recovered back to $\mathbb{C}_{A}$ upon a recovery
call of $\mathbb{E}_{A}$ after a recovery timeout has passed. Note that after
tokens of $\mathbb{C}_{A}$ have been recovered and synced to
$\mathbb{IPSC}_{A}$ in $PB$, it is not possible to finish the 4th stage of our
protocol since it requires providing the proof that tokens were deducted at
$A$ and such a proof cannot be constructed anymore. The same holds in the
situation where the sync to $\mathbb{IPSC}_{A}$ at $PB$ has not been made yet
– after recovery of tokens, $\mathbb{E}_{A}$ does not allow to deduct the same
tokens due to its correct execution (see Theorem 1). ∎

###### Theorem 12.

(Identity Management of CBDC Instances I) A new (potentially fake) CBDC
instance cannot enter the ecosystem of wholesale CBDC upon its decision.

###### Justification.

To extend the list of valid CBDC instances (stored in IMSC contract), the
majority vote of all existing CBDC instances must be achieved through public
voting on IMSC. ∎

###### Theorem 13.

(Identity Management of CBDC Instances II) Any CBDC instance (that e.g., does
not respect certain rules for issuance of tokens) might be removed from the
ecosystem of CBDC by majority vote.

###### Justification.

A publicly visible voting about removal of a CBDC instance from the ecosystem
is realized by IMSC contract that resides in $PB$, while each existing
instance has a single vote. ∎

###  6.3. Security of TEE

We assume that its TEE platform employed is secure. However, previous research
indicated that this might not be the case in practical implementations of TEE,
such as SGX that was vulnerable to memory corruption attacks (Biondo et al.,
2018) as well as side channel attacks (Brasser et al., 2017; Van Bulck et al.,
2018; Lipp et al., 2021; Murdock et al., 2020). A number of software-based
defense and mitigation techniques have been proposed (Shih et al., 2017; Gruss
et al., 2017; Chen et al., 2017; Brasser et al., 2017; Seo et al., 2017) and
some vulnerabilities were patched by Intel at the hardware level (Intel,
2018). Nevertheless, we note that our approach is TEE-agnostic thus can be
integrated with other TEEs such as ARM TrustZone or RISC-V architectures
(using Keystone-enclave (Enclave, 2019) or Sanctum (Costan et al., 2016)).

Another class of SGX vulnerabilities was presented by Cloosters et al.
(Cloosters et al., 2020) and involved incorrect application designs enabling
arbitrary reads and writes of protected memory. Since the authors did not
provide public with their tool (and moreover it does not support Open-enclave
SDK), we did manual inspection of our code and did not find any of the
concerned vulnerabilities. Another work was done by Borrello et al. (Borrello
et al., 2022) and involves more serious micro-architectural flaws in chip
design. Intel has already released microcode and SGX SDK updates to fix the
issue.

###  6.4. Public Blockchain & Finality

Many blockchain platforms suffer from accidental forks (i.e., availability-
favored blockchains in terms of CAP theorem), which temporarily create
parallel inconsistent blockchain views. To mitigate this phenomenon, it is
recommended to wait a certain number of block confirmations after a given
block is created before considering it irreversible with overwhelming
probability. This waiting time (a.k.a., time to finality) influences the non-
equivocation property of our approach, inheriting it from the underlying
blockchain platform. Most availability-favored blockchains have a long time to
finality, e.g., $\sim$3mins in Bitcoin (Nakamoto, 2008), $\sim$3mins in
Ethereum (wood2014ethereum), $\sim$2mins in Cardano (Kiayias et al., 2017).
However, consistency-favored blockchains in terms of the CAP theorem have a
short time to finality, e.g., HoneyBadgerBFT (Miller et al., 2016), Algorand
(Gilad et al., 2017), Hyperledger Besu (Hyperledger Foundation, 2022). The
selection of the underlying blockchain platform should respect low time to
finality in the critical environment of CBDC, and thus employ a consistency-
favored public blockchain.

##  7\. Related Work

In this section, we first review various approaches to interoperability and
CBDC. Moreover, since our protocol is designed using a combination of TEE and
the blockchain, we revise the most relevant solutions and stress the novelty
of our approach, which combines several unique features.

###  7.1. Blockchain Interoperability

Cross-chain interoperability is one of the most desirable yet challenging
features to be designed and developed in blockchains, affecting the impact and
usability of the solution (Wang et al., 2023; Belchior et al., 2021; Mohanty
et al., 2022; Qasse et al., 2019).

Cross-chain communication protocols define the process of synchronization
between different chains of the same blockchain, e.g., by the use of
sidechains. Additionally, cross-blockchain communication protocols, such as
Interledger Protocol (Siris et al., 2019), allow interaction of different
blockchains. While the cross-chain solutions can be employed by the native
constructs such as atomic swap, the cross-blockchain protocols require
adoption of the solution. Blockchain interoperability solutions can be
categorized into three groups according to the principle they are based on and
the type of chains that are supported (Belchior et al., 2021).

#####  Public connectors.

Public connectors are a set of approaches that focuses on cryptocurrency
systems and their transactions. This includes the sidechains, relays, notary
schemes, and hash time locks (Musungate et al., 2019; Mohanty et al., 2022;
Dcunha et al., 2021).

#####  Blockchain of blockchains.

Blockchain of blockchains focuses on application specific-solutions. The
example is Polkadot (Belchior et al., 2021; Burdges et al., 2020) – a network
for cross-blockchain interoperability. In Polkadot network, multiple
parallelized globally-coherent chains (parachains) are connected via bridges
that represent a specific type of parachain. Bridges also serve as a gateway
for communication with external networks, such as Bitcoin.

##### Hybrid Connectors

Hybrid solutions create an abstraction layer over the blockchain ecosystem and
provide a unified API for interaction between blockchain and applications
(Madine et al., 2021). Examples are trusted relays or blockchain migrators.
The interoperability requires validators present in both the source and target
blockchains. The validators collect cross-chain transactions and ensure that
they are delivered (Wang and Nixon, 2021).

The proposed solution in this paper contain a custom one-way atomic swap
protocol that utilizes hash time lock contracts. Such swaps are settled on
public blockchain $PB$. It is also expected that $PB$ used for the
synchronization of clients and CBDC instances deploys a single blockchain
technology. The usability of the proposed solution targets the financial
institutions such as banks, leveraging its potential use in CBDC projects. The
protocol does not specify a middleware layer providing API or the use of
gateway chains. Therefore, it can be categorized as a public connector that
augments and combines the features provided by individual solutions in the
same category.

###  7.2. CBDC Projects

While most CBDC projects are still in their early stages, some well-known
proposals are reaching maturity level (Zhang and Huang, 2021). For instance,
Project Jasper (Chapman et al., 2017) was one of the initial prototypes for
inter-bank payments using blockchain technology. Project Ubin (Monetary
Authority of Singapore, 2016) appeared with the aim of clearing and settling
of payments and securities efficiently by using several blockchain
technologies and smart contracts. Project E-krona (Armelius et al., 2020) was
designed, among others, to enable fast transactions between domestic and
cross-border entities. Stella (Kishi, 2019) is another well-known project that
uses permissioned blockchain technology to enable cross border operations as
well as confidentiality protection. The mBridge project (BIS innovation hub,
2021) (initially named Inthanon-LionRock) prototype is built by ConsenSys on
Hyperledger Besu. The prototype encompasses several jurisdictions and aims at
creating a cross-border payment infrastructure that improves on key pain
points, including high cost, low speed, and operational complexities. Finally,
Project Khokha (South African Reserve Bank, 2018) was designed for efficient,
confidential inter-bank transactions.

Despite the maturity of some projects, research on CBDC technology is still in
its infancy. In addition, the road to creating a native interoperable protocol
that can be used regardless of the underlying blockchain technology still
requires further exploration and is one of the main objectives of this
article. Compared to other CBDC projects, our approach is the first protocol
combining TEE and blockchain to bring interesting security and privacy
features, accompanied by external interoperability. In detail, our protocol
guarantees a set of features such as integrity, non-equivocation (i.e., we
provide snapshots to public blockchain to avoid reverts and forks of the local
CBDC ledgers), correctness (i.e., the EVM is executed in an enclave which can
be remotely attested), and censorship evidence. Since the designed protocol
addresses inter-bank communication and payment settlements, it can be
potentially integrated as a part of the above-mentioned wholesale CBDC
projects. The advantages of the retail CBDC approach towards individual
clients are also preserved by the privacy support, censorship evidence and
mitigation of malicious approach described in Section 6. The general approach
is also invariant towards token differences introduced by different projects
with regard to the public blockchain.

###  7.3. Combining Blockchain and TEE

The combination of Trusted Execution Environment (TEE) technologies and
blockchain has gained increased attention in the past few years. Hybridchain
(Wang et al., 2020) is an architecture for confidentiality-preserving in
permissioned blockchain. Such architecture extends the enclave memory of TEE
that allows blockchain applications running in TEE to securely store
transaction records outside of TEE. Ekiden (Cheng et al., 2018) is a
blockchain-agnostic solution that offloads smart contract execution to TEE
enclaves. Teechain (Lind et al., 2017) focuses on the Bitcoin network and
enables the secure execution of transactions in TEE, enhancing the scalability
of the network. Fastkitten enables extended functionality in the Bitcoin
network by using Turing-complete smart contracts executed via TEE-enabled
operators (Das et al., 2019).

However, solutions combining interoperability with TEE-based blockchains are
still in their infancy. Only a few authors have explored this such as
Bellavista et al. (Bellavista et al., 2021), and Lan et al. (Lan et al.,
2021), which are the works most similar to ours. More concretely, Bellavista
et al. (Bellavista et al., 2021) explore the use of a relay scheme based on
TEE to provide blockchain interoperability in the context of collaborative
manufacturing and supply chains. Lan et al. (Lan et al., 2021) aim to preserve
confidentiality in interoperable cross-chain platforms and propose a protocol
to ensure privacy-preserving communications among them. Nevertheless, our
approach is the first one designing a functional protocol for interoperable
CBDC, considering features such as the ones mentioned in Section 3.

##  8\. Discussion

As seen in Section 7, this is the first blockchain TEE-based interoperable
protocol that operates in the context of CBDC. However, our protocol allows
modifications if additional requirements were to be fulfilled (i.e.,
considering the ones defined in Section 3). The latter enables a certain
degree of dynamism when adapting the protocol to specific application
contexts.

Following the interest of countries in CBDC (Atlantic Council, [n. d.]),
research on CBDCs and their potential challenges has also been receiving
increasing attention in the last years (i.e., the number of contributions has
been doubling yearly since 2020 according to Scopus, using the query TITLE-
ABS-KEY ( ( ( central AND bank AND digital AND currency ) OR CBDC ) AND
challenges ). While a profound analysis of state of the art is out of the
scope of this paper, we found that authors typically follow two strategies to
discuss CBDC and its challenges, namely considering a local perspective (i.e.,
at a jurisdiction or national level) and adopting a global challenge
abstraction. Overall, we considered the most recent reviews and surveys
analyzing CBDC and its challenges (Catalini et al., 2022; Alwago, 2022;
Koziuk, 2021; Sebastião et al., 2021) and other grey literature, such as the
Digital Euro Association (Digital Euro Association, [n. d.]), or the US
federal reserve (US Federal Reserve, [n. d.]), to extract the challenges and
represent them according to a high-level hierarchical abstraction. Since one
of the aims of our proposal is to provide solutions to as many challenges as
possible, we describe, for each challenge, the benefits and features that our
proposal provides in Table 4.

Topic |  Main concerns |  Our proposal’s contribution
---|---|---
Technology |  The design, implementation and maintenance of CBDC’s as well as their scalability, resiliency and compatibility with the current financial structure. |  Our system is scalable and compatible with current financial system
Monetary Policy |  Monetary policy transmission, including interest rates, the value of money, or other tools, should not be hindered by CBDC. |  Our system relies on smart contracts to enforce specific policies if required, such as token expiration or token usability.
Financial Stability |  The potentially disrupting impact of CBDC on the existing financial system could create new financial vulnerabilities, uncontrolled disintermediation or illicit activities. |  The use of blockchain and the policies translated into the system should be audited and verified. Our system is compatible with the latter and other policies in the above layers.
Legal Framework |  The legal framework for CBDC needs to comply with existing laws and regulations, including consumer protection, anti-money laundering, and countering the financing of terrorism. |  The system is compatible with auditability layers compliant with current legal and regulations
Interoperability |  Ensuring interoperability by guaranteeing that CBDCs are compatible with other countries monetary policies and promoting cross-border cooperation and standardisation. |  Our protocol is interoperable by design and ensures the system remains in monetary equilibrium since no new tokens are created. The potential use of oracles enables further operations with different currencies beyond current ones, promoting cross-border cooperation and additional capabilities.
Security and Privacy |  CBDC needs to ensure robustness to prevent cyberattacks and unauthorised access to data by guaranteeing privacy-preserving mechanisms of transactions and personal information. |  Our proposal is robust and preserves the privacy of transactions since all the transactions are encrypted. We provide various security properties, such as atomicity, verifiability, integrity, non-equivocation, correctness of execution, censorship evidence, and others.
User Adoption and Inclusion |  CBDCs will need to provide access to banking services to different populations. Users will require a behaviour change, acceptance and trust. |  The use of our system is transparent to other layers, so it does not introduce any burden. TEE technologies enable trustable platforms, and our protocol allows verifiable censorship resolution.
Table 4. High-level abstraction of CBDC’s challenges and how our proposal
contributes to them. In some cases, our proposal slightly interferes with
these challenges since many only apply to other CBDC ecosystem layers.

##  9\. Conclusion

Although the controversy surrounding the coexistence of privacy and CBDC
(Lagarde, 2022), the latter promises a series of benefits, such as transaction
efficiency (e.g., by reducing costs and decreasing its finality at the
national or international level) and countering financial crime. Moreover,
CBDC complements current financial services by offering broader opportunities.
Nevertheless, the corresponding regulations should carefully manage these new
opportunities, ensuring they do not restrict citizens’ rights. Note that novel
functionalities enforced in financial transactions, such as token expiration
dates, negative interest rates for token holders (i.e., in an attempt to
stimulate the economy in recession periods) or tokens whose validity is tied
to a specific subset of goods (e.g., enforcing that part of the salary is
spent on energy or healthcare), could either be applied for the sustainability
of the society or state control in the context of authoritarian regimes.

Given the above circumstances, we provide the design and implementation of the
protocol that uses a custom adaptation of atomic swap and is executed by any
pair of CBDC instances to realize a one-way transfer, resolving
interoperability over multiple instances of semi-centralized CBDC. Our
protocol guarantees a series of properties such as verifiability, atomicity of
inter-bank transfers, censorship resistance, and privacy. Our contributions
result in a step forward toward enriching the capabilities of CBDC and their
practical deployment.

Future work will closer study token issuance management through protocol
directives, perform more extensive evaluation, and propose interoperable
execution of smart contracts between CBDC instances.

## Acknowledgments

This work was supported by the FIT BUT internal project FIT-S-23-8151. This
work was also supported by the European Commission under the Horizon Europe
Programme, as part of the LAZARUS project (http://lazarus-he.eu/ Grant
Agreement no. 101070303). Fran Casino was supported by the Government of
Catalonia with the Beatriu de Pinós programme (Grant No. 2020 BP 00035), and
by AGAUR with the 2021-SGR-00111 project. The content of this article does not
reflect the official opinion of the European Union. Responsibility for the
information and views expressed therein lies entirely with the authors.

## References

  * (1)
  * AlShamsi et al. (2022) Mohammed AlShamsi, Mostafa Al-Emran, and Khaled Shaalan. 2022\.  A Systematic Review on Blockchain Adoption.  _Applied Sciences_ 12, 9 (2022), 4245.
  * Alwago (2022) W.O. Alwago. 2022\.  Is the Renminbi a Global Currency in the Making? Globalization of Digital yuan.  67, 4 (2022), 553–566.
  * Anati et al. (2013) Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata. 2013\.  Innovative technology for CPU based attestation and sealing. In _Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy_ , Vol. 13. ACM New York, NY, USA.
  * Armelius et al. (2020) Hanna Armelius, Gabriela Guibourg, Stig Johansson, and Johan Schmalholz. 2020.  E-krona design models: pros, cons and trade-offs.  _Sveriges Riksbank Economic Review_ 2 (2020), 80–96.
  * Atlantic Council ([n. d.]) Atlantic Council. [n. d.].  Central Bank Digital Currency Tracker.  https://www.atlanticcouncil.org/cbdctracker/.
  * Belchior et al. (2021) Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. 2021.  A survey on blockchain interoperability: Past, present, and future trends.  _ACM Computing Surveys (CSUR)_ 54, 8 (2021), 1–41.
  * Bellavista et al. (2021) Paolo Bellavista, Christian Esposito, Luca Foschini, Carlo Giannelli, Nicola Mazzocca, and Rebecca Montanari. 2021.  Interoperable Blockchains for Highly-Integrated Supply Chains in Collaborative Manufacturing.  _Sensors_ 21, 15 (2021), 4955.
  * Biondo et al. (2018) Andrea Biondo, Mauro Conti, Lucas Davi, Tommaso Frassetto, and Ahmad-Reza Sadeghi. 2018.  The Guard’s Dilemma: Efficient Code-Reuse Attacks Against Intel $\\{$SGX$\\}$. In _27th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 18)_. 1213–1227.
  * BIS innovation hub (2021) BIS innovation hub. 2021\.  Inthanon-LionRock to mBridge: Building a multi CBDC platform for international payments.  https://www.bis.org/publ/othp40.htm
  * Bitcoin Wiki (2018) Bitcoin Wiki. 2018\.  Atomic Swap.  {https://en.bitcoinwiki.org/wiki/Atomic_Swap}
  * Boar and Wehrli (2021) Codruta Boar and Andreas Wehrli. 2021.  Ready, steady, go?-Results of the third BIS survey on central bank digital currency.  (2021).
  * Borrello et al. (2022) Pietro Borrello, Andreas Kogler, Martin Schwarzl, Moritz Lipp, Daniel Gruss, and Michael Schwarz. 2022\.  ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture. In _31st USENIX Security Symposium (USENIX Security 22)_.
  * Brasser et al. (2017) Ferdinand Brasser, Srdjan Capkun, Alexandra Dmitrienko, Tommaso Frassetto, Kari Kostiainen, Urs Müller, and Ahmad-Reza Sadeghi. 2017\.  DR. SGX: hardening SGX enclaves against cache attacks with data location randomization.  _arXiv preprint arXiv:1709.09917_ (2017).
  * Brown et al. (2016) Richard Gendal Brown, James Carlyle, Ian Grigg, and Mike Hearn. 2016.  Corda: an introduction.  _R3 CEV, August_ 1, 15 (2016), 14.
  * Burdges et al. (2020) Jeff Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini, Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh Shirazi, Alistair Stewart, and Gavin Wood. 2020.  Overview of Polkadot and its Design Considerations.  https://doi.org/10.48550/ARXIV.2005.13456
  * Catalini et al. (2022) C. Catalini, A. De Gortari, and N. Shah. 2022\.  Some Simple Economics of Stablecoins.  14 (2022), 117–135.
  * Chapman et al. (2017) James Chapman, Rodney Garratt, Scott Hendry, Andrew McCormack, and Wade McMahon. 2017.  Project Jasper: Are distributed wholesale payment systems feasible yet.  _Financial System_ 59 (2017).
  * Chen et al. (2017) Sanchuan Chen, Xiaokuan Zhang, Michael K Reiter, and Yinqian Zhang. 2017.  Detecting privileged side-channel attacks in shielded execution with Déjá Vu. In _Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security_. 7–18.
  * Cheng et al. (2018) Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song. 2018.  Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contract execution.  _arXiv preprint arXiv:1804.05141_ (2018).
  * Cloosters et al. (2020) Tobias Cloosters, Michael Rodler, and Lucas Davi. 2020\.  TeeRex: Discovery and Exploitation of Memory Corruption Vulnerabilities in $\\{$SGX$\\}$ Enclaves. In _29th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 20)_. 841–858.
  * Costan et al. (2016) Victor Costan, Ilia Lebedev, and Srinivas Devadas. 2016\.  Sanctum: Minimal hardware extensions for strong software isolation. In _25th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 16)_. 857–874.
  * Crosby and Wallach (2009) Scott A Crosby and Dan S Wallach. 2009.  Efficient Data Structures For Tamper-Evident Logging.. In _USENIX Security Symposium_. 317–334.
  * Das et al. (2019) Poulami Das, Lisa Eckey, Tommaso Frassetto, David Gens, Kristina Hostáková, Patrick Jauernig, Sebastian Faust, and Ahmad-Reza Sadeghi. 2019.  $\\{$FastKitten$\\}$: Practical Smart Contracts on Bitcoin. In _28th USENIX Security Symposium (USENIX Security 19)_. 801–818.
  * Dcunha et al. (2021) Snoviya Dcunha, Srushti Patel, Shravani Sawant, Varsha Kulkarni, and Mahesh Shirole. 2021.  Blockchain Interoperability Using Hash Time Locks. In _Proceeding of Fifth International Conference on Microelectronics, Computing and Communication Systems_ , Vijay Nath and J. K. Mandal (Eds.). Springer Singapore, Singapore, 475–487.
  * Digital Euro Association ([n. d.]) Digital Euro Association. [n. d.].  Central Bank Digital Currency.  https://home.digital-euro-association.de/cbdc/en.
  * Digital Euro Association (2022) Digital Euro Association. 2022\.  The CBDC Manifesto.  https://cbdcmanifesto.com/
  * Ehrenfeld (2022) Jonathan Ehrenfeld. 2022\.  SWIFT partners with Chainlink for cross-chain crypto transfer project.  https://blog.chain.link/smartcon-2022-recap/
  * Enclave (2019) Keystone Enclave. 2019\.  Keystone: An Open Framework for Architecting Trusted Execution Environments.  https://keystone-enclave.github.io/.
  * Espel et al. (2017) Thomas Espel, Laurent Katz, and Guillaume Robin. 2017\.  Proposal for Protocol on a Quorum Blockchain with Zero Knowledge.  2017 (2017).
  * Gilad et al. (2017) Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. 2017.  Algorand: Scaling byzantine agreements for cryptocurrencies. In _SOSP_.
  * Gruss et al. (2017) Daniel Gruss, Julian Lettner, Felix Schuster, Olya Ohrimenko, Istvan Haller, and Manuel Costa. 2017\.  Strong and efficient cache side-channel protection using hardware transactional memory. In _26th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 17)_. 217–233.
  * Hoekstra et al. (2013) Matthew Hoekstra, Reshma Lal, Pradeep Pappachan, Vinay Phegade, and Juan Del Cuvillo. 2013.  Using innovative instructions to create trustworthy software solutions.  _HASP@ ISCA_ 11 (2013).
  * Homoliak and Szalachowski (2020) Ivan Homoliak and Pawel Szalachowski. 2020.  Aquareum: A Centralized Ledger Enhanced with Blockchain and Trusted Computing.  arXiv:2005.13339 [cs.CR]
  * Hyperledger Foundation (2022) Hyperledger Foundation. 2022\.  Hyperledger.  https://github.com/hyperledger.
  * Intel (2018) Intel. 2018.  Resources and Response to Side Channel L1 Terminal Fault.  https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html
  * Jin and Xia (2022) Si Yuan Jin and Yong Xia. 2022.  CEV Framework: A Central Bank Digital Currency Evaluation and Verification Framework With a Focus on Consensus Algorithms and Operating Architectures.  _IEEE Access_ 10 (2022), 63698–63714.  https://doi.org/10.1109/ACCESS.2022.3183092
  * Kiayias et al. (2017) Aggelos Kiayias, Al‘exander Russell, Bernardo David, and Roman Oliynykov. 2017.  Ouroboros: A provably secure proof-of-stake blockchain protocol. In _CRYPTO’17_.
  * Kiff et al. (2020) Mr John Kiff, Jihad Alwazir, Sonja Davidovic, Aquiles Farias, Mr Ashraf Khan, Mr Tanai Khiaonarong, Majid Malaika, Mr Hunter K Monroe, Nobu Sugimoto, Hervé Tourpe, et al. 2020\.  A survey of research on retail central bank digital currency.  (2020).
  * Kishi (2019) Michinobu Kishi. 2019\.  Project Stella and the impacts of fintech on financial infrastructures in Japan.
  * Koziuk (2021) V. Koziuk. 2021\.  Confidence in digital money: Are central banks more trusted than age is matter?  18, 1 (2021), 12–32.
  * Lacoste and Lefebvre (2023) Marc Lacoste and Vincent Lefebvre. 2023.  Trusted Execution Environments for Telecoms: Strengths, Weaknesses, Opportunities, and Threats.  _IEEE Security & Privacy_ (2023).
  * Lagarde (2022) Christine Lagarde. 2022\.  High level conference: Towards a legislative framework enabling a digital euro for citizens and businesses.  https://www.ecb.europa.eu/press/key/date/2022/html/ecb.sp221107~dcc0cd8ed9.en.html
  * Lan et al. (2021) Ying Lan et al. 2021\.  TrustCross: Enabling Confidential Interoperability across Blockchains Using Trusted Hardware. In _2021 4th International Conference on Blockchain Technology and Applications_ (Xi’an, China) _(ICBTA 2021)_. Association for Computing Machinery, New York, NY, USA, 17–23.  https://doi.org/10.1145/3510487.3510491
  * Lind et al. (2017) Joshua Lind, Ittay Eyal, Florian Kelbert, Oded Naor, Peter Pietzuch, and Emin Gün Sirer. 2017.  Teechain: Scalable blockchain payments using trusted execution environments.  _arXiv preprint arXiv:1707.05454_ (2017).
  * Lipp et al. (2021) Moritz Lipp, Andreas Kogler, David Oswald, Michael Schwarz, Catherine Easdon, Claudio Canella, and Daniel Gruss. 2021.  PLATYPUS: Software-based Power Side-Channel Attacks on x86. In _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE.
  * Madine et al. (2021) Mohammad Madine, Khaled Salah, Raja Jayaraman, Yousof Al-Hammadi, Junaid Arshad, and Ibrar Yaqoob. 2021.  appXchain: Application-Level Interoperability for Blockchain Networks.  _IEEE Access_ 9 (2021), 87777–87791.  https://doi.org/10.1109/ACCESS.2021.3089603
  * McKeen et al. (2013) Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R Savagaonkar. 2013.  Innovative instructions and software model for isolated execution.  _Hasp@isca_ 10, 1 (2013).
  * Merkle (1989) Ralph C Merkle. 1989\.  A certified digital signature. In _Conference on the Theory and Application of Cryptology_. Springer, 218–238.
  * Micali (2003) Silvio Micali. 2003\.  Simple and fast optimistic protocols for fair electronic exchange. In _Proceedings of the twenty-second annual symposium on Principles of distributed computing_. ACM, 12–19.
  * Microsoft (2020) Microsoft. 2020\.  Enclave EVM.  https://github.com/microsoft/eEVM
  * Miller et al. (2016) Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. 2016.  The honeybadger of BFT protocols. In _ACM CCS_.
  * Mohanty et al. (2022) Debasis Mohanty, Divya Anand, Hani Moaiteq Aljahdali, and Santos Gracia Villar. 2022.  Blockchain Interoperability: Towards a Sustainable Payment System.  _Sustainability_ 14, 2 (2022), 913.
  * Monetary Authority of Singapore (2016) Monetary Authority of Singapore. 2016\.  Project Ubin.  https://www.mas.gov.sg/schemes-and-initiatives/Project-Ubin
  * Murdock et al. (2020) Kit Murdock, David Oswald, Flavio D. Garcia, Jo Van Bulck, Daniel Gruss, and Frank Piessens. 2020\.  Plundervolt: Software-based Fault Injection Attacks against Intel SGX. In _Proceedings of the 41st IEEE Symposium on Security and Privacy (S &P’20)_.
  * Musungate et al. (2019) Blessing Musungate, Busra Candan, Umut Cabuk, and Gokhan Dalkilic. 2019.  Sidechains: Highlights and Challenges.  https://doi.org/10.1109/ASYU48272.2019.8946384
  * Nakamoto (2008) Satoshi Nakamoto. 2008\.  Bitcoin: A peer-to-peer electronic cash system.
  * Náñez Alonso et al. (2020) Sergio Luis Náñez Alonso, Miguel Ángel Echarte Fernández, David Sanz Bas, and Jarosław Kaczmarek. 2020.  Reasons fostering or discouraging the implementation of central bank-backed digital currency: A review.  _Economies_ 8, 2 (2020), 41.
  * Qasse et al. (2019) Ilham A Qasse, Manar Abu Talib, and Qassim Nasir. 2019\.  Inter blockchain communication: A survey. In _Proceedings of the ArabWIC 6th Annual International Conference Research Track_. 1–6.
  * Sebastião et al. (2021) H.M.C.V. Sebastião, P.J.O.R. da Cunha, and P.M.C. Godinho. 2021\.  Cryptocurrencies and blockchain. Overview and future perspectives.  21, 3 (2021), 305–342.
  * Seo et al. (2017) Jaebaek Seo, Byoungyoung Lee, Seong Min Kim, Ming-Wei Shih, Insik Shin, Dongsu Han, and Taesoo Kim. 2017.  SGX-Shield: Enabling Address Space Layout Randomization for SGX Programs.. In _NDSS_.
  * Sethaput and Innet (2021) Vijak Sethaput and Supachate Innet. 2021.  Blockchain Application for Central Bank Digital Currencies (CBDC). In _2021 Third International Conference on Blockchain Computing and Applications (BCCA)_. IEEE, 3–10.
  * Shih et al. (2017) Ming-Wei Shih, Sangho Lee, Taesoo Kim, and Marcus Peinado. 2017\.  T-SGX: Eradicating Controlled-Channel Attacks Against Enclave Programs.. In _NDSS_.
  * Siris et al. (2019) Vasilios Siris, Pekka Nikander, Spyros Voulgaris, Nikos Fotiou, Dmitrij Lagutin, and George Polyzos. 2019.  Interledger Approaches.  _IEEE Access_ PP (07 2019), 1–1.  https://doi.org/10.1109/ACCESS.2019.2926880
  * South African Reserve Bank (2018) South African Reserve Bank. 2018\.  Project Khokha: Blockchain Case Study for Central Banking in South Africa .  https://consensys.net/blockchain-use-cases/finance/project-khokha/
  * Subramanyan et al. (2017) Pramod Subramanyan, Rohit Sinha, Ilia Lebedev, Srinivas Devadas, and Sanjit A Seshia. 2017.  A formal foundation for secure remote execution of enclaves. In _Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security_. 2435–2450.
  * US Federal Reserve ([n. d.]) US Federal Reserve. [n. d.].  Central Bank Digital Currency.  https://www.federalreserve.gov/central-bank-digital-currency.htm.
  * Van Bulck et al. (2018) Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F Wenisch, Yuval Yarom, and Raoul Strackx. 2018\.  Foreshadow: Extracting the keys to the intel $\\{$SGX$\\}$ kingdom with transient out-of-order execution. In _27th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 18)_. 991–1008.
  * Wang and Nixon (2021) Gang Wang and Mark Nixon. 2021.  InterTrust: Towards an Efficient Blockchain Interoperability Architecture with Trusted Services. In _2021 IEEE International Conference on Blockchain (Blockchain)_. 150–159.  https://doi.org/10.1109/Blockchain53845.2021.00029
  * Wang et al. (2023) Gang Wang, Qin Wang, and Shiping Chen. 2023.  Exploring Blockchains Interoperability: A Systematic Survey.  _Comput. Surveys_ (2023).
  * Wang et al. (2020) Yong Wang, June Li, Siyu Zhao, and Fajiang Yu. 2020\.  Hybridchain: A novel architecture for confidentiality-preserving and performant permissioned blockchain using trusted execution environment.  _IEEE Access_ 8 (2020), 190652–190662.
  * Zhang and Huang (2021) Tao Zhang and Zhigang Huang. 2021.  Blockchain and central bank digital currency.  _ICT Express_ (2021).

$\triangleright$ Declaration of types and functions:

Header { $ID$, $txsRoot$, $rcpRoot$, $stRoot$};

$\\#(r)\rightarrow v$: denotes the version $v$ of $L$ having $LRoot$ $=$ $r$,

$\triangleright$ Variables of TEE:

$SK_{\mathbb{E}}^{tee},PK_{\mathbb{E}}^{tee}$: keypair of $\mathbb{E}$ under
$\Sigma_{tee}$,

$SK_{\mathbb{E}}^{pb},PK_{\mathbb{E}}^{pb}$: keypair of $\mathbb{E}$ under
$\Sigma_{pb}$,

$hdr_{last}\leftarrow\perp$: the last header created by $\mathbb{E}$,

$LRoot_{pb}\leftarrow\perp$: the last root of $L$ flushed to PB’s
$\mathbb{IPSC}$,

$LRoot_{cur}\leftarrow\perp$: the root of $L\cup blks_{p}$ (not flushed to
PB),

$ID_{cur}\leftarrow 1$: the current version of $L$ (not flushed to PB),

$FH_{cur}\leftarrow[]$: the frozen hashes cache of the current $L$’s history
tree.

$\triangleright$ Declaration of functions:

function  _$Init$() public_

($SK_{\mathbb{E}}^{pb}$,
$PK_{\mathbb{E}}^{pb}$)$\leftarrow\Sigma_{pb}.Keygen()$;

($SK_{\mathbb{E}}^{tee}$,
$PK_{\mathbb{E}}^{tee}$)$\leftarrow\Sigma_{tee}.Keygen()$;

Output($PK_{\mathbb{E}}^{tee},PK_{\mathbb{E}}^{pb}$);

function  _$Exec$($txs[],\partial st^{old}$) public_

assert $\partial st^{old}.root=hdr_{last}.stRoot$;

$\partial
st^{new},rcps,txs_{er}\leftarrow~{}~{}\\_\\_processTxs(txs,~{}\partial
st^{old})$;

$\sigma\leftarrow\Sigma_{pb}.sign(SK_{\mathbb{E}}^{pb},(LRoot_{pb},LRoot_{cur}))$;

Output($LRoot_{pb},LRoot_{cur},\partial st^{new},hdr_{last},rcps$, $txs_{er}$,
$\sigma$);

function  _$Flush$() public_

$LRoot_{pb}\leftarrow LRoot_{cur}$; $\triangleright$ Shift the version of $L$
synchronized with PB.

function  _$\\_\\_processTxs$($txs[],\partial st^{old}$) private_

$\partial st^{new},rcps[],txs_{er}\leftarrow$ runVM($txs$, $\partial
st^{old}$); $\triangleright$ Run $\mu$-$txs$ in VM.

$txs\leftarrow txs\setminus txs_{er}$; $\triangleright$ Filter out parsing
errors/wrong signatures.

$hdr\leftarrow~{}~{}\mathbf{Header}(ID_{cur},MkRoot(txs),MkRoot(rcps),\partial
st^{new}.root))$;

$hdr_{last}\leftarrow hdr$;

$LRoot_{cur}\leftarrow\\_\\_newLRoot(hdr)$;

$ID_{cur}\leftarrow ID_{cur}+1$;

return $\partial st^{new}$, $rcps$, $txs_{er}$;

function  _$\\_\\_newLRoot(hdr)$ private_

$\\_\\_udpateFH(h(hdr));$

return $FH_{cur}.ReduceRoot()$;

$\triangleright$ Since $FH_{cur}=\pi^{inc}_{next}$, inc. proof. for 1 element
commitment.

function  _$\\_\\_updateFH(hdrH)$ private_

$FH_{cur}.add(hdrH);$

$l\leftarrow\lfloor log_{2}(ID_{cur})\rfloor$;

for  _$i\leftarrow 2;\ i\leq 2^{l};\ i\leftarrow 2i$_ do

if  _$0=ID_{cur}\bmod i$_ then

$FH_{cur}[\text{-}2]\leftarrow h(FH_{cur}[\text{-}2]\ ||\
FH_{cur}[\text{-}1])$

$\mathbf{delete}~{}~{}FH_{cur}[\text{-1}]$; $\triangleright$ Remove the last
element.

Algorithm 5 The program $prog^{\mathbb{E}}$ of enclave $\mathbb{E}$

$\triangleright$ Declaration of types and constants:

CensInfo { $\mu$-$etx,\mu$-$equery,status,edata$ },

$msg$: a current transaction that called $\mathbb{IPSC}$,

$\triangleright$ Declaration of functions:

function
_$Init$($PK_{\mathbb{E}}^{pb},PK_{\mathbb{E}}^{tee},PK_{\mathbb{O}},~{}{\color[rgb]{1,0,0}\\_i_{r}},~{}{\color[rgb]{1,0,0}[ia\leftarrow\textbf{T}]}$)
public _

$PK_{\mathbb{E}}^{tee}[].add(PK_{\mathbb{E}}^{tee})$; $\triangleright$ PK of
enclave $\mathbb{E}$ under $\Sigma_{tee}$.

$PK_{\mathbb{E}}^{pb}[].add(PK_{\mathbb{E}}^{pb})$; $\triangleright$ PK of
enclave $\mathbb{E}$ under $\Sigma_{pb}$.

$PK_{\mathbb{O}}^{pb}\leftarrow PK_{\mathbb{O}}$; $\triangleright$ PK of
operator $\mathbb{O}$ under $\Sigma_{pb}$.

$LRoot_{pb}\leftarrow\perp$; $\triangleright$ The most recent root hash of $L$
synchronized with $\mathbb{IPSC}$.

$censReqs\leftarrow[]$; $\triangleright$ Request that $\mathbb{C}$s wants to
resolve publicly.

$t_{s}\leftarrow 0$; $\triangleright$ The total supply of the instance.

$t_{i}\leftarrow 0$; $\triangleright$ The total issued tokens by the instance.

const $issueAuthority\leftarrow ia$; $\triangleright$ Token issuance
capability of the instance.

const $i_{r}\leftarrow\\_i_{r}$; $\triangleright$ Max. yearly inflation of the
instance.

const $createdAt\leftarrow timestamp()$; $\triangleright$ The timestamp of
creation a CBDC instance.

function
_$snapshotLedger$($root_{A},root_{B},{\color[rgb]{1,0,0}\\_t_{i},\\_t_{s},}~{}\sigma$)
public _

$\triangleright$ Verify whether msg was signed by $\mathbb{E}$.

assert
$\Sigma_{pb}.verify((\sigma,PK_{\mathbb{E}}^{pb}[\text{-}1]),(root_{A},root_{B},{\color[rgb]{1,0,0}\\_t_{i},\\_t_{s}}))$;

$\triangleright$ Snapshot issued tokens and total supply.

if  _$issueAuthority$_ then

assert $\\_\\_meetsInflationRate(\\_t_{i})$; $\triangleright$ The code is
trivial, and we omit it.

$t_{i}\leftarrow\\_t_{i}$;

else

assert $t_{i}=\\_t_{i}$;

$\triangleright$ Verify whether a version transition extends the last one.

if  _$LRoot_{pb}=root_{A}$_ then

$LRoot_{pb}\leftarrow root_{B}$; $\triangleright$ Do a version transition of
$L$.

function  _$SubmitCensTx$($\mu$-$etx,\sigma_{msg}$) public _

$\triangleright$ Called by $\mathbb{C}$ in the case her $\mu$-tx is censored.
$\mathbb{C}$ encrypts it by $PK^{tee}_{\mathbb{E}}$.

accessControl($\sigma_{msg},msg.PK_{\mathbb{C}}^{pb}$);

$censReqs$.add(CensInfo($\mu$-$etx,\perp,\perp,\perp$));

function  _$ResolveCensTx(idx_{req},status,\sigma$) public _

$\triangleright$ Called by $\mathbb{O}$ to prove that $\mathbb{C}$’s $\mu$-tx
was processed.

assert $idx_{req}<|censReqs|$;

$r\leftarrow censReqs[idx_{req}]$;

assert
$\Sigma_{pb}.verify((\sigma,PK_{\mathbb{E}}^{pb}[\text{-}1]),~{}(h(r.\mu$-$etx),status))$;

$r.status\leftarrow status$;

function  _$SubmitCensQry$($\mu$-$equery,\sigma_{msg}$) public _

$\triangleright$ Called by $\mathbb{C}$ in the case its read query is
censored. $\mathbb{C}$ encrypts it by $PK^{tee}_{\mathbb{E}}$.

accessControl($msg$, $\sigma_{msg},msg.PK_{\mathbb{C}}^{pb}$);

$censReqs$.add(CensInfo($\perp,\mu$-$equery,\perp,\perp$));

function  _$ResolveCensQry(idx_{req},status,edata,\sigma$) public _

$\triangleright$ Called by $\mathbb{O}$ as a response to the $\mathbb{C}$’s
censored read query.

assert $idx_{req}<|censReqs|$;

$r\leftarrow censReqs[idx_{req}]$;

assert
$\Sigma_{pb}.verify((\sigma,PK_{\mathbb{E}}^{pb}[\text{-}1]),(h(r.\mu$-$equery),status,h(edata)))$;

$r.\\{edata\leftarrow edata,status\leftarrow status\\}$;

function
_$ReplaceEnc$($PKN_{\mathbb{E}}^{pb},PKN_{\mathbb{E}}^{tee},r_{A},r_{B},~{}{\color[rgb]{1,0,0}\\_t_{i},\\_t_{s},}~{}\sigma,\sigma_{msg}$)
public _

$\triangleright$ Called by $\mathbb{O}$ in the case of enclave failure.

assert $\Sigma_{pb}.verify((\sigma_{msg},PK_{\mathbb{O}}^{pb}),msg)$;
$\triangleright$ Avoiding MiTM attack.

$snapshotLedger(r_{A},r_{B},~{}{\color[rgb]{1,0,0}\\_t_{i},\\_t_{s}},~{}\sigma)$
; $\triangleright$ Do a version transition.

$PK_{\mathbb{E}}^{tee}.add(PKN_{\mathbb{E}}^{tee})$; $\triangleright$ Upon
change, $\mathbb{C}s$ make remote attestation.

$PK_{\mathbb{E}}^{pb}.add(PKN_{\mathbb{E}}^{pb})$;

Algorithm 6 The program $prog^{\mathbb{IPSC}}$ of $\mathbb{IPSC}$.