Cross-Blockchain Smart Contract
Interoperability
vorgelegt von
M. Sc.
Martin Westerkamp
ORCID: 0000-0001-5333-8695
an der Fakultät IV – Elektrotechnik und Informatik
der Technischen Universität Berlin
zur Erlangung des akademischen Grades
Doktor der Ingenieurwissenschaften
- Dr.-Ing. -
genehmigte Dissertation
Promotionsausschuss:
Vorsitzender: Prof. Dr.-Ing. Stefan Tai
Gutachter: Prof. Dr. Axel Küpper
Gutachter: Prof. Dr.-Ing. Stefan Schulte
Gutachter: Prof. Andreas Veneris, Ph.D.
Tag der wissenschaftlichen Aussprache: 28. Juni 2023
Berlin 2023
i
Abstract
Blockchain technologies’ rapid evolution has resulted in the fragmentation of decen-
tralized applications across multiple networks. Since blockchain protocols do not per-
mit the autonomous retrieval of external data, deployed smart contracts are restricted
to their host blockchain. The resulting lock-in effect contradicts the initial proposi-
tion of smart contracts to enable independent decentralized applications. Therefore,
cross-blockchain interoperabilitymethods areneeded to enable smartcontracts to in-
teract across blockchain network boundaries. Current approaches to blockchain in-
teroperability suffer from centralization, high transaction costs, or require economic
rationality assumptions. The execution of present cross-blockchain smart contract
messaging protocols incurs high delays and costs, as multiple transactions must be
executed sequentially. In addition, these protocols do not remedy the tight binding
between smart contracts and their host blockchain.
This thesis presents novel cross-blockchain smart contract interoperability concepts
that are trustless, efficient, and do not require financial preconditions. The first con-
tribution depicts a chain relay utilizing verifiable off-chain computations to off-load
the validation of Proof-of-Work (PoW) block headers. As a result, on-chain validation
costs are reduced by orders of magnitude without compromising security. The con-
cept is evaluated based on a prototype relaying Bitcoin and Ethereum block headers to
blockchains that support the Ethereum Virtual Machine (EVM).
In recent years, Proof-of-Stake (PoS) blockchains have become increasingly popu-
lar. The second contribution of this thesis introduces an efficient chain relay scheme
addressing PoS blockchains that guarantee finality. The consensus protocol’s finality
guarantee enables the chain relay to operate on a subset of finalized block headers. As
a result, transaction costs are minimized without compromising the relay’s security.
The introduced cross-chain state access methods depictthe foundation for smart con-
tract interoperability across blockchain networks. As a third contribution, we present
theconceptofsmartcontractforkstomitigatetheclosedependencyofsmartcontracts
on their host blockchain. The business logic and state of smart contracts are migrated
to other blockchains that supportthe same execution environment. As a migration re-
sult, smart contract users benefit from the properties the target blockchain provides,
and lock-in effects are alleviated.
The fourth contribution of this thesis is a concept for smart contract synchronization,
which enables instant read-onlycross-blockchain function calls. Replica contracts are
created on targetblockchains and updated according to the initiallydeployed instance.
We evaluate smart contractforks and synchronizations based on a prototype thatsup-
ports EVM-compliant blockchains.
iii
Zusammenfassung
Die rapide Entwicklung von Blockchain-Technologien hat zu einer Fragmentierung
dezentraler Anwendungen über mehrere Netzwerke hinweg geführt. Da Blockchain-
Protokolle keinen autonomen Abruf externer Daten zulassen, sind darauf ausgeführ-
te Smart Contracts auf ihre Host-Blockchain beschränkt. Der daraus resultieren-
de Lock-in-Effekt widerspricht der ursprünglichen Prämisse, unabhängige und de-
zentrale Anwendungen mittels Smart Contracts zu ermöglichen. Daher werden Me-
thoden für die Interoperabilität von Blockchains benötigt, die es Smart Contracts
ermöglichen, über Blockchain-Netzwerkgrenzen hinweg zu interagieren. Aktuel-
le Ansätze zur Blockchain-Interoperabilität weisen einen hohen Zentralisierungs-
grad auf, resultieren in hohen Transaktionskosten oder setzen die wirtschaftliche
Rationalität teilnehmender Entitäten voraus. Die Ausführung darauf aufbauender
Blockchain-übergreifender Smart-Contract-Messaging-Protokolle verursacht hohe
Ausführungsverzögerungen und Kosten, da mehrere aufeinanderfolgende Transak-
tionen benötigt werden. Zudem beheben diese Protokolle nicht die enge Bindung zwi-
schen Smart Contracts und Host-Blockchains.
In dieser Arbeit werden effiziente Konzepte für Blockchain-übergreifende Smart-
Contract-Interoperabilität vorgestellt, die weder Vertrauen in Dritte noch finanzi-
elle Voraussetzungen erfordern. Das erste Konzept stellt ein Chain-Relay dar, wel-
ches überprüfbar korrekte Off-Chain-Berechnungen für die Validierung von Proof-
of-Work-(PoW-)Block-Headern nutzt. Hierdurch werden die Validierungskosten auf
der Ziel-Blockchain um ein Vielfaches reduziert, ohne die Sicherheit des Protokolls
zu beeinträchtigen. Das Konzept wird anhand eines Prototyps evaluiert, welcher die
Abbildung von Bitcoin- und Ethereum-Block-Headern auf Blockchains ermöglicht,
welche die Ethereum-Virtual-Machine (EVM) unterstützen.
In jüngster Vergangenheit hat der Konsensmechanismus Proof-of-Stake (PoS) an Be-
liebtheit gewonnen. Das zweite in dieser Arbeit vorgestellte Konzept stellt ein Chain-
Relay-Schema dar, das PoS-Blockchains adressiert, welche die zeitnahe Finalisierung
von Blöcken garantierten. Die Finalisierungsgarantie des Konsensmechanismus er-
möglicht die Konzeptionierung eines Chain Relays, welches nur eine Teilmenge von
finalisierten Block-Headern für die Validierung voraussetzt. Infolgedessen werden die
Transaktionskosten minimiert, ohne die Sicherheit des Relays zu beeinträchtigen.
Die vorgestellten Methoden für den Blockchain-übergreifenden Zustandsabruf stel-
len die Grundlage für die Interoperabilität von Smart Contracts über Blockchain-
Netzwerke hinweg dar. Das dritte Konzept dieser Arbeit umfasst Smart-Contract-
Forks, welche die Abhängigkeit von Smart Contracts zu ihren Host-Blockchains min-
dern. Die Geschäftslogik und der Zustand von Smart Contracts werden zwischen
Blockchains migriert, welche dieselbe Ausführungsumgebung unterstützten. Durch
iv
die Migration profitieren Smart-Contract-Nutzer von den Eigenschaften der Ziel-
Blockchain und Lock-in-Effekte werden abgemildert.
Das vierte in dieser Arbeit vorgestellte Konzept stellt Smart-Contract-Synchronisa-
tionen dar, welche sofortige Blockchain-übergreifende Funktionsaufrufe mit Lesezu-
griff ermöglichen. Replica-Contracts werden auf Ziel-Blockchains erstellt und ent-
sprechendder ursprünglichenInstanzaktualisiert. Smart-Contract-Forksund -Syn-
chronisationen werden anhand eines Prototyps evaluiert, welcher EVM-kompatible
Blockchains unterstützt.
v
Acknowledgements
This work would have been impossible without the support of many people, some of
whom I would like to acknowledge here.
First and foremost, I am thankful for the excellent research environment at the
Service-centric Networking research group at TU Berlin. I am particularly indebted to
Prof. Dr. Axel Küpper, who let me pursue my research interests and provided excellent
supervision and support in the process. He has always encouraged me to explore the
requirements for real-world applications and propose practical solutions. I also thank
Prof. Dr. Stefan Schulte and Prof. Andreas Veneris, Ph.D., for their valuable feedback
and participation in the doctoral committee.
I want to thank all mycolleagues atthe Service-centric Networking research group for
themanyfruitfuldiscussionsandexcellentworkingatmosphere. NotonlyhaveIfound
great working conditions here, but I have also made friendships that will certainly last
beyond my time at the university. Special thanks go to Friedhelm Victor, whose chal-
lenging questions and stimulating discussions gave me newfood for thoughtand sup-
ported me in my research work. In addition, I would like to thank him for his valu-
able feedback on my publications and parts of my dissertation. Furthermore, I thank
Tobias Eichinger, Dr. Sandro Rodriguez Garzon, and Philip Raschke for the thought-
provoking discussions over the past years. Also, this thesis would never have come to
fruition without the extraordinary administrative support ofAndrea Hahn and Sandra
Wild.
My research at TU Berlin was funded by Deutsche Telekom Innovation Laboratories,
where I was able to engage in constructive and inspiring discussions throughout the
years. I extend special thanks to Andreas Sommerwerk for the great collaboration and
for allowing me to apply my research to multiple practical projects.
I would also like to thank those students whose theses I had the opportunity to su-
pervise. Their excellent contributions were a great support. This is especially true for
Lukas George, Maximilian Diez, and Leonard Stutzer. Furthermore, I thank Leonard
Stutzer for his valuable contributions to implementing several prototypes in the con-
text of the Software Campus project DISCO.
Finally, I want to thank my family for their loving support, my parents, Marianne and
Aloys, my siblings Kristin and Dominik, and of course, my girlfriend, Maria. Without
your support and encouragement, this work would not have been possible.
vii
Contents
Abstract i
Zusammenfassung iii
Acknowledgements v
Contents vii
List of Figures xi
List of Tables xv
List of Abbreviations xvii
Bibliographic Notes xix
I Foundations 1
1 Introduction 3
1.1 Challenges...................................... 3
1.2 ResearchQuestions ................................ 5
1.3 Contributions and Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Cross-Chain State Access Using Off-Chain Computations . . . . . 6
1.3.2 Cross-Chain State Access Based on Finality Checkpoints . . . . . 6
1.3.3 Smart Contract Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Smart Contract Synchronization . . . . . . . . . . . . . . . . . . . . 7
1.3.5 Decentralized Applications Using Cross-Chain Contracts . . . . . 8
1.4 Research Methodology and Thesis Organization . . . . . . . . . . . . . . . 8
2 Background 11
2.1 Blockchain Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Properties.................................. 13
2.1.2 Merkle Trees and Proofs . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 ConsensusAlgorithms .............................. 17
2.2.1 Nakamoto Consensus (Proof-of-Work) . . . . . . . . . . . . . . . . 18
2.2.2 Memory-hard PoW Algorithms (Ethash) . . . . . . . . . . . . . . . 20
2.2.3 Proof-of-Stake............................... 20
2.3 LightClients .................................... 22
2.4 Smart Contracts and the EVM . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Verifiable Off-Chain Computations . . . . . . . . . . . . . . . . . . . . . . . 26
viii
2.5.1 Zero-Knowledge Proof Schemes . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Hash Functions for Zero-Knowledge Proof Systems . . . . . . . . 29
2.5.3 Zero-Knowledge Proof Frameworks . . . . . . . . . . . . . . . . . . 30
3 Related Work 33
3.1 Trusted State Access Across Blockchains . . . . . . . . . . . . . . . . . . . 33
3.1.1 Relay Chains and Sharding . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 ChainRelays ................................ 37
3.1.3 NotarySchemes.............................. 40
3.2 Transfer and Exchange of Tokens . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 AtomicSwaps ............................... 41
3.2.2 WrappedTokens.............................. 42
3.2.3 Multi-Chain Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Cross-Chain Smart Contract Interaction . . . . . . . . . . . . . . . . . . . 44
3.3.1 Function Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.2 Smart Contract Moves . . . . . . . . . . . . . . . . . . . . . . . . . . 47
II Scalable Chain Relays 49
4 Zero-Knowledge Proof-based Chain Relay 53
4.1 Motivation...................................... 53
4.2 DesignGoals .................................... 54
4.3 Concept ....................................... 55
4.3.1 Single Block Header Validation . . . . . . . . . . . . . . . . . . . . . 55
4.3.2 Epoch-based Block Header Validation . . . . . . . . . . . . . . . . . 57
4.3.3 Inclusion Proof for Intermediary Headers . . . . . . . . . . . . . . . 59
4.3.4 Flexible Batch Sizes for Block Header Validation . . . . . . . . . . . 60
4.3.5 Memory-hard PoW algorithms . . . . . . . . . . . . . . . . . . . . . 62
4.4 Implementation .................................. 64
4.4.1 ZoKrates................................... 64
4.4.2 Cairo..................................... 66
4.5 Evaluation...................................... 67
4.5.1 BitcoinRelay................................ 67
4.5.2 Ethereum1.0Relay ............................ 71
4.5.3 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6 Discussion...................................... 74
4.7 Conclusion ..................................... 76
5 Proof-of-Stake Chain Relay 79
5.1 Motivation...................................... 79
5.2 Concept ....................................... 80
5.2.1 Overview .................................. 80
5.2.2 ValidatorSet ................................ 81
5.2.3 BlockValidation .............................. 81
5.2.4 AccountableSafety ............................ 82
5.3 Ethereum2.0Relay ................................ 84
5.4 Implementation .................................. 85
ix
5.5 Evaluation...................................... 87
5.5.1 Quantitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5.2 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.3 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.6 Discussion...................................... 90
5.7 Conclusion ..................................... 90
III Smart Contract Portability 93
6 Smart Contract Forks 97
6.1 Motivation...................................... 97
6.2 Concept ....................................... 98
6.2.1 StateRetrieval ............................... 99
6.2.2 Deployment Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2.3 Dynamic Contract References . . . . . . . . . . . . . . . . . . . . . . 105
6.2.4 Static Contract References . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3 Evaluation...................................... 106
6.3.1 Scalability.................................. 106
6.3.2 TokenContracts.............................. 108
6.3.3 Contract Dependencies and Private Networks . . . . . . . . . . . . 109
6.4 Discussion...................................... 109
6.5 Conclusion ..................................... 110
7 Smart Contract Synchronization 111
7.1 Motivation...................................... 111
7.2 Definitions ..................................... 112
7.3 Concept ....................................... 113
7.3.1 Synchronization Conditions . . . . . . . . . . . . . . . . . . . . . . . 113
7.3.2 Initialization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.3.3 Synchronization Process . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.4 Evaluation...................................... 120
7.4.1 ExecutionCosts .............................. 121
7.4.2 Synchronization Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.5 Discussion...................................... 124
7.6 Conclusion ..................................... 126
IV Applications 127
8 Token-based Supply Chain Traceability 131
8.1 Motivation...................................... 131
8.2 Concept ....................................... 132
8.2.1 Tokenization of Products . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.2.2 Recipes for Product Transformation . . . . . . . . . . . . . . . . . . 133
8.2.3 Traceability................................. 134
8.3 Cross-Blockchain Interoperability . . . . . . . . . . . . . . . . . . . . . . . 134
8.3.1 Cross-Blockchain Deployment . . . . . . . . . . . . . . . . . . . . . 135
x
8.3.2 Smart Contract Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.4 Evaluation...................................... 138
8.5 Discussion...................................... 141
8.6 Conclusion ..................................... 142
9 Decentralized Online Social Network 143
9.1 Motivation...................................... 143
9.2 Concept ....................................... 144
9.2.1 Personal Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.2.2 User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.3 Cross-Blockchain Interoperability . . . . . . . . . . . . . . . . . . . . . . . 146
9.3.1 Smart Contract Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.3.2 Smart Contract Synchronization . . . . . . . . . . . . . . . . . . . . 147
9.4 Evaluation...................................... 147
9.5 Discussion...................................... 149
9.6 Conclusion ..................................... 150
10 Cross-chain Oracle 151
10.1Motivation...................................... 151
10.2 Cross-Blockchain Interoperability . . . . . . . . . . . . . . . . . . . . . . . 152
10.3Evaluation...................................... 153
10.4Discussion...................................... 155
10.5Conclusion ..................................... 156
V Summary and Outlook 157
11 Conclusion 159
12 Future Work 161
Bibliography 163
xi
List of Figures
1.1 Overview of the thesis structure in stack representation. . . . . . . . . . . 8
2.1 Simplified overview of blockchain structure, including a Merkle tree
of transactions. Every block holds a reference to the preceding block.
Merkle trees allow the implementation of light clients. . . . . . . . . . . . 12
2.2 Representation of two forks that occurred in the history of the longest
chain depicted by block E. The fork choice depends on the consensus al-
gorithm’srules.................................... 13
2.3 Simplified representation of a Merkle Patricia tree of degree 16. Five key-
value pairs are stored in four leaf nodes and one branch node. . . . . . . 18
2.4 High level Solidity code is compiled to deployment code which is embed-
dedintoatransaction................................ 25
2.5 Each block in Ethereum holds three distinct Merkle trees for transac-
tions, states and receipts. Accounts maintain discrete storage tries. The
gray highlighted area of the Merkle tree represents the smart contract’s
currentstate. .................................... 27
2.6 Two types of processes are differentiated in ZoKrates, the one-time
setup and repetitive program executions. The steps of the ZoKrates ini-
tializationprocess arenumbered incircles, andthe sequenceofoff-chain
computation steps is illustrated in diamond shapes. . . . . . . . . . . . . 30
2.7 After performing the off-chain computation using the Cairo framework,
SHARP collects execution traces and generates a joint proof verified on-
chain.......................................... 31
3.1 Classification of cross-chain applications and their enablers in a stack
format. In this thesis, we focus on the grey-shaded research topics. . . . 34
3.2 Shards may be connected to multiple neighboring shards [128]. Infor-
mation is only exchanged between neighboring shards. Every shard can
be reached by applying multiple hops. Here, a message is sent from A to
DviaE......................................... 36
3.3 Atomic swaps require locking tokens in an HTLC using a secret. Claim-
ing token B on blockchain Y involves revealing the secret allowing the
transaction partner to claim token A on blockchain X. . . . . . . . . . . . 42
3.4 Transferringtokensbetween blockchainnetworksincludes lockingiton
one blockchain and proving the locking operation on another blockchain. 43
4.1 Workflow of a chain relay update. Retrieved blocks are processed off-
chain and correct execution is verified on-chain by the relay contract. . 56
xii
4.2 The first block of an epoch is the last block of a batch in the relay (N=
E= 2016). Block headers shaded in dark grey are public and visible and
passed to the relay contract. The last block of an epoch is persisted in
the relay contract. Block headers shaded in light grey are intermediary
blocks and initially not stored on the target ledger. . . . . . . . . . . . . . 58
4.3 A Merkle tree is built using all block header hashes as leaves. The sub-
mitted Merkle root enables the submission of intermediary blocks at a
laterstage....................................... 60
4.4 Different batch sizes require distinct verification methods. Relay con-
tracts verifying specific sizes mayreference relay contracts ofhigher or-
der. Block headers shaded in dark gray indicate public parameters. . . . 61
4.5 The verification of memory-hard PoW algorithms requires the pro-
computation of commitments to a dataset that is utilized by off-chain
programs to efficiently proof the correct selection of dataset items. . . . 63
4.6 Performance evaluation of many-time steps in logarithmic scale using
Cairo, Giza, and ZoKrates based on the Bitcoin verifier. . . . . . . . . . . . 68
4.7 Performance evaluation of one-time steps in logarithmic scale using
Cairo and ZoKrates based on the Bitcoin verifier. . . . . . . . . . . . . . . . 70
4.8 The time and memory required during different process steps depend on
the utilized backed, proving scheme, and hashing algorithm [76]. . . . 72
4.9 Performanceevaluationofone-time steps in logarithmic scale usingPo-
seidon and Pedersen hashes within ZoKrates based on the Ethereum 1.0
verifier......................................... 73
4.10 Performance evaluation of many-time steps in logarithmic scale us-
ing Poseidon and Pedersen hashes within ZoKrates based on the Eth-
ereum1.0verifier. ................................. 73
4.11 Validation time of Ethereum 1.0 block headers including witness and
proofgenerationusingBellmanbackendandtheG16provingscheme[76].
Applying a coordination oracle enables horizontal scalabilityto maintain
the chain relay in a live state. . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1 The chain relay always maintains one block header that is currently ac-
tive. Two block headers must be submitted to update the relay contract,
the target block and the latest block that finalizes it. The three involved
block headers may be part of different sync committee periods, deter-
miningwhichsynccommitteesignsthelatestblockandifthesynccom-
mittee period transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Simplified representation of required parameters in SSZ structure. Bold
borders and arrows represent the Merkle paths of involved attributes. . 86
5.3 Gas costs for deploying and updating the chain relay. Three different
configurations are presented: storing sync committees ofsize 32 and 512
andnotstoringthesync committee of512 validators. The red dashed line
indicates the current block gas limit on the Ethereum main network. B:
Block. SC: Sync Committee. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
xiii
6.1 A smart contractis deployed and used on blockchain A. Its state is recon-
structed to create respective migration code for blockchain B. The ported
contract is verified by a third party not involved in the migration process. 99
6.2 Example of deployment and interaction process with a separate logic,
proxy, and initialization contracts. The proxy contract allows distribut-
ing the state initialization over multiple transactions for large state sizes. 104
6.3 Delay and gas costs required creating a smart contract fork, including
state retrieval and deployment. Delay and gas scale linear to the smart
contract’sstatesize................................. 107
7.1 Simplified contract state capturing the initial migration and synchro-
nization of a diverted state. Green highlighting indicates transaction
triggered value changes, purple illustrates the initial fork state and blue
marks synchronized values. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2 Left: Merkle tree of an account state derived from source chain. Right:
Multi-proof of an updated state: 0x03 is deleted (red), 0x42 is modified
(yellow) and 0x02 is added (green). Bottom: Transition confirmation
calculated on the target chain. . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.3 The client retrieves state changes and respective proofs to compute a
multi-proof. The multi-proof is submitted to the targetchain that com-
putesthetransitionconfirmationandvalidatesboth. Afterthat,thestate
is updated, rendering equivalent states for the source and target con-
tract. ......................................... 119
7.4 Gas costs required for updating a single value at different storage heights
intheMerkletree.................................. 121
7.5 Gas costs required for updating multiple values using a single multi-proof.122
7.6 Time required for updating a single value at different storage heights in
theMerkletree.................................... 123
7.7 Time required for synchronization including different update set sizes. 124
8.1 The production process is projected onto digital tokens using smart con-
tracts in an example supply chain. Every minting, transfer, and con-
sumption operation is recorded when executed by the token contract. . 133
8.2 Gas costs required for minting tokens depending on the number of inputs.139
8.3 Delay incurred for minting tokens depending on the number of inputs. 140
9.1 Friend requests allow sharing of private messages. Users retrieve the
backend URI and public key using the blockchain-based registry to send
andsignrequests. ................................. 146
9.2 Delay and gas costs for synchronizing an ENS resolver, including state
retrievalandupdate................................. 149
10.1 Synchronized contracts are modified according to the source blockchain
and accessible as client contracts to smart contracts on other blockchain
networks. ...................................... 153
xv
List of Tables
2.1 Comparison of zero-knowledge proof scheme attributes. . . . . . . . . . 28
4.1 Comparison of different sidechain mechanisms. . . . . . . . . . . . . . . . 75
5.1 Required data for a chain relay update in the generic case and specific to
Ethereum2.0..................................... 82
8.1 Timeandgasrequiredforforkinganon-fungibletokencontractforsup-
ply chain traceability. The contract stores 50 tokens and maintains 300
key-value pairs. One hundred iterations have been performed to retrieve
the average delay and standard deviation (sd). . . . . . . . . . . . . . . . . 141
9.1 Time and gas required for forking an ENS resolver holding 5,000 entries.
One hundred iterations have been performed to retrieve the average de-
lay and standard deviation (sd). . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.1 Time and gas required for forking a major AMM to enable sychronization.154
10.2 Time and gas required for synchronizing a major AMM . . . . . . . . . . 155
xvii
List of Abbreviations
AMM Automated Market Maker. 112, 151–153, 155, 156
ASIC Application-Specific Integrated Circuit. 20, 38
BFT Byzantine Fault Tolerant. 18
BLS Boneh-Lynn-Shacham. 86, 87
CRS Common Reference String. 28
DAG Directed Acyclic Graph. 13
DAPP Decentralized Application. 3
DeFi Decentralized Finance. 8, 112, 124, 129, 130, 151, 152, 155, 156
DEX Decentralized Exchange. 129, 130, 151
DLP Discrete Logarithm Problem. 27, 29
dPoS delegated Proof-of-Stake. 21
DSL Domain-Specific Language. 28, 30, 45, 64
DSR Design Science Research. 8
ECC Elliptic-curve cryptography. 27
EIP Ethereum Improvement Proposal. 86, 88, 90, 120, 121, 123
ENS Ethereum Name Service. xiii, xv, 111, 124, 147–150
EOA Externally Owned Account. 13, 26
ERC Ethereum Request for Comment. 7, 42, 108, 110
EVM Ethereum Virtual Machine. i, 6, 7, 24, 25, 29, 38, 45, 54, 57, 64, 80, 85–87, 90,
91, 98, 101, 103, 108, 116, 120, 124–126, 141, 148, 149, 160, 162
GDPR General Data Protection Regulation. 144
GMP General Message Passing. 45
GPACT General Purpose Atomic Crosschain Transactions. 46, 122, 124, 142, 155
HTLC Hash-Time Lock Contract. 41
IBC Interblockchain Communication. 47, 135
xviii
IoT Internet-of-Things. 22
MMR Merkle Mountain Range. 24
MPC Multi-Party Computation. 28, 74
NAS Network Attached Storage. 144
NIPoPoW Non-Interactive Proofs of Proof-of-Work. 24, 39
OSN Online Social Network. 8, 129, 143, 144, 146, 147, 150
PBFT Practical Byzantine Fault Tolerance. 18, 21, 22, 51, 79, 80, 84, 90, 91, 109, 138
PKI Public Key Infrastructure. 145
PoS Proof-of-Stake. i, 6, 9, 20–23, 37–40, 51, 64, 79, 80, 90, 91, 109, 126, 138, 159
PoW Proof-of-Work. i, 6, 7, 9, 14, 18–21, 23, 24, 37–39, 51, 53–59, 62–65, 71, 73,
75–77, 79, 97, 109, 138, 159, 161
RLP Recursive Length Prefix. 162
SHARP Shared Prover. 31, 32, 67
SPV Simplified Payment Verification. 23, 37, 46, 53–55, 57, 59, 60
SSI Self-Sovereign Identity. 14
SSZ SimpleSerialize. 85, 86, 155, 162
TEE Trusted Execution Environment. 4, 40
URI Uniform Resource Identifier. xiii, 145–147, 150
UTXO Unspent Transaction Output. 12, 13, 25, 112
VDF Verifiable Delay Function. 23
VRF Verifiable Random Function. 35
XCMP Cross-Chain Messaging Protocol. 36, 46, 135
zkSNARK zero-knowledge Succinct Non-Interactive Argument of Knowledge. 6,
27–30, 39, 54, 55, 57, 61, 64, 66–71, 73, 74, 76, 77, 79, 138, 159, 161
zkSTARK zero-knowledge Scalable Transparent Argument-of-Knowledge. 6, 27–
32, 39, 54, 55, 57, 60, 64, 66–68, 71, 74, 76, 77, 159, 161
xix
Bibliographic Notes
Most of the concepts and protocols presented in this thesis have been published pre-
viously. In the following, we provide an overview of published articles and to which
chapter they have contributed.
Chapter 4 is based on an article published in 2020:
•M.WesterkampandJ.Eberhardt. “zkRelay: FacilitatingSidechainsusingzkSNARK-
based Chain-Relays”. In: 2020 IEEE European Symposium on Security and Privacy
Workshops (EuroS&PW). IEEE, 2020, pp. 378–386. DOI: 10.1109/EuroSPW51379.-
2020.00058. [1]
Chapter 5 is an extended version of an article originally published in 2022:
•M. Westerkamp and M. Diez. “Verilay: A Verifiable Proof of Stake Chain Relay”. In:
2022IEEEInternationalConferenceonBlockchainandCryptocurrency (ICBC). IEEE,
2022, pp. 1–9. DOI: 10.1109/ICBC54727.2022.9805554. [2]
Chapter 6 resembles the results published in 2019:
•M. Westerkamp. “Verifiable Smart Contract Portability”. In: 2019 IEEE Interna-
tional Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2019, pp. 1–9.
DOI: 10.1109/BLOC.2019.8751335. [3]
Chapter 7 elaborates on the results published in a conference paper in 2022. Further,
parts of an extended version have been incorporated that laid the basis for a use case
study presented in Chapter 10.
•M. Westerkamp and A. Küpper. “SmartSync: Cross-Blockchain Smart Contract In-
teraction and Synchronization”. In: 2022 IEEE International Conference on Block-
chain and Cryptocurrency (ICBC). (Distinguished Paper Award). IEEE, 2022, pp.
1–9. DOI: 10.1109/ICBC54727.2022.9805524. [4]
The use case presented in Chapter 8 for evaluating cross-blockchain smart contract
interoperability concepts was firstpublished in 2018. An extended journal paper based
on the results was published in 2020.
•M. Westerkamp, F. Victor, and A. Küpper. “Blockchain-Based Supply Chain Trace-
ability: Token Recipes Model Manufacturing Processes”. In: 2018 IEEE Interna-
tional Conference on Blockchain (Blockchain). IEEE, 2018, pp. 1595–1602. DOI:
10.1109/Cybermatics_2018.2018.00267. [5]
•M. Westerkamp, F. Victor, and A. Küpper. “Tracing manufacturing processes using
blockchain-based token compositions”. In: Digital Communications and Networks,
vol. 06, no. 02, Sep. 2020, pp. 167–176. DOI: 10.1016/j.dcan.2019.01.007. [6]
xx
The concept of a blockchain-based decentralized online social network outlined in
Chapter 9 was published in 2019.
•M. Westerkamp, S. Göndör, and A. Küpper. “Tawki: Towards Self-Sovereign Social
Communication”. In: 2019 IEEE International Conference on Decentralized Applica-
tions and Infrastructures (DAPPCON). IEEE, 2019, pp. 29–38. DOI: 10.1109/DAPP-
CON.2019.00014. [7]
Chapter 10 presents a use case studybased on a real-world smart contractdeployment.
The chapter depicts an extended version of the application published in an extended
version of “SmartSync: Cross-Blockchain Smart Contract Interaction and Synchroniza-
tion,” and was published in 2023.
•M. Westerkamp and A. Küpper. “Instant Function Calls using Synchronized Cross-
Blockchain Smart Contracts”. In: IEEE Transactions on Network and Service Man-
agement, Accepted for Publication, 2023. DOI: 10.1109/TNSM.2023.3236437. [8]
The Background and Related Work chapters presented in this thesis are summarized
and expanded editions of the corresponding chapters of the published articles.
In addition, the following works have been co-authored but are not part of this thesis.
•C. Rieger, M. Westerkamp, and H. Kuchen. “Challenges and Opportunities of Mod-
ularizing Textual Domain-Specific Languages”. In: 2018 International Conference
on Model-Driven Engineering and Software Development (MODELSWARD). SciTe-
Press, 2018, pp. 387–395. DOI: 10.5220/0006601903870395. [9]
•M. Müller, S. R. Garzon, M. Westerkamp, and Z. A. Lux. “HIDALS: A Hybrid
IoT-based Decentralized Application for Logistics and Supply Chain Management”.
In: 2019 IEEE 10th Annual Information Technology, Electronics and Mobile Com-
munication Conference (IEMCON). IEEE, 2019, pp. 802–808. DOI: 10.1109/IEM-
CON.2019.8936305. [10]
•S. Göndör, H. Yildiz, M. Westerkamp, and A. Küpper. “Blade: A Blockchain-
supported Architecture for Decentralized Services”. In: 2022 IEEE International
Conference on Decentralized Applications and Infrastructures (DAPPS). IEEE, 2022,
pp. 19–26. DOI: 10.1109/DAPPS55202.2022.00011. [11]
1
Part I
Foundations
3
1 Introduction
In recent years, blockchain technologies have gained traction as theypermit users and
organizations to collaborate in a decentralized fashion. Participants execute a consen-
susprotocoltoagreeonthetransitionofasharedstatewithoutrequiringtrustedinter-
mediaries [12]. The technology has fostered a plethora of Decentralized Applications
(DAPPs) in various industries. Most prominently, Bitcoin enables digital peer-to-peer
payments based on a distributed ledger [13].
The first generation of blockchain implementations executes application-specific op-
erations as part of its primary protocol, resulting in limited extensibility. Ethereum
introduced the second generation of blockchains, which allow the execution of almost
arbitrary business logic based on a shared ledger [14]. These smart contracts are de-
ployed and executed via a virtual machine performing state transitions according to
user transactions [15]. As a result, many applications sharing state and security be-
come available on a single blockchain instance. Interoperability exists between smart
contracts deployed to the same blockchain instance. Functions are executed by exter-
nal user transactions and may invoke other smart contracts to modify their state or
retrieve information.
Over time, various blockchain networks have been established with different char-
acteristics. These properties include reduced latency [16], high throughput [17], in-
creased security [18], and fast finality [19]. As a result, increasing fragmentation of
smart contracts across different blockchain instances can be observed [20]. Block-
chain networks are self-contained since state transitions must be verifiable byall par-
ticipants. Due to this isolation, external data, including the state information of other
blockchain instances, is unavailable [21].
1.1 Challenges
Smart contracts permit the implementation of arbitrary application logic, benefit-
ing from blockchain networks’ decentralization and immutability properties. How-
ever, smart contracts and their host blockchain exhibit a strong binding once de-
ployed. Since the transaction history leading to the current state is only available on
the original blockchain instance, users cannot migrate deployed smart contracts. Fur-
thermore, cross-blockchain function calls are prevented, and only smart contracts
deployed to the same host blockchain are available. As a result, a novel lock-in ef-
fect toward the host blockchain is created that contradicts the initial proposition of
smart contracts to provide decentralization without requiring third-party dependen-
cies. This lock-in effect restricts the utilization of newly available blockchain net-
works fostering, for instance, increased throughput or security, or decreased latency
4Chapter 1. Introduction
or costs [22]. Conversely, reduced participation in the host blockchain’s consensus
protocol, for example, because of reduced incentives or protocol failure, may lead to
networkcentralization andinsecureoperation thatalso appliesto deployed smartcon-
tracts [23, 24]. Further, during a smart contract’s life cycle, requirements may change.
For instance, the application scenario could shift from a public to a private environ-
ment or vice versa. Similarly, the setting could require switching from a permis-
sionless blockchain to a permissioned implementation. Decreasing the dependency
of smart contracts on their host blockchain requires techniques for migrating smart
contracts during their life cycle and enabling cross-blockchain function calls.
While interoperability exists between smart contracts hosted on the same blockchain
instance, remotely hosted smart contracts cannot be incorporated. Therefore, due to
network effects, it is expected that many smart contracts will be deployed to the same
blockchain to benefit from other available applications [25]. Two problems arise from
this. First, developers cannot choose the best-suited host blockchain according to the
application’s requirements but must align with the previous deployment of dependent
smart contracts. Second, the dependencies lead to a growing concentration of appli-
cations on a single ledger and, thus, scalability issues [26]. Ultimately, the increasing
utilization of a single ledger results in high latency and costs, driving the requirement
for migrating the deployed application to another blockchain instance.
Cross-blockchain smart contract migrations alleviate the strong binding between the
initialhostblockchainandsmartcontractbutdo notpermitaccessing remotelyhosted
smart contracts. While cross-blockchain state access enables applications like cross-
chain token transfers [27], limited research exists regarding the interoperability of
smart contracts across different networks. Previous approaches focused on cross-
chainfunctioninvocation to permitmodifyingthe stateofremotelyhosted smartcon-
tracts [28, 29, 30]. These conceptstypically require intermediaries toexecute transac-
tionsand include multiple smartcontract calls. As aresult, transactionexecutionmust
be orchestrated. Further, additional overhead is generated, resulting in increased de-
lays. To the best of our knowledge, no cross-chain smart contract interoperability so-
lution allowing the instant read access of remotely hosted smart contracts is available
as of early 2023.
The interoperability of smart contracts requires secure access to the state of another
blockchain network. In the following, we refer to a source blockchain as the instance
holding the state of interest and a target blockchain as the instance on which access to
that state is to be enabled. Blockchain protocols do not provide for retrieving external
data because itmaylead to inconsistencies and affect verifiability [31]. Solving this so-
called blockchainoracleproblem is challenging, as the solution should not compromise
the inherent properties of blockchain technology such as decentralization and veri-
fiability [21]. Several blockchain oracle concepts have been presented, proposing the
use of economic incentive models [32], Trusted Execution Environments (TEEs) [33],
and multi-signatures [21]. These approaches require a minimum number of honest
participants or sufficient escrowed assets to operate. Failure to meet these require-
mentscanhavesignificantconsequences. Forexample, thehijackingofRoninBridge’s
signing nodes resulted in the loss of more than 600 million USD worth of assets [34].
1.2. Research Questions 5
Therefore, a more resilient mechanism is needed to prevent such attacks. Oracles en-
abling blockchain interoperability provide structured data that conforms to a specific
blockchain protocol. Chain relays exploit this fact by running a blockchain light client
to provide cross-chain state access without the need for trusted intermediaries [35].
However, current approaches incur validation overhead, resulting in high execution
costs and rendering many use cases infeasible.
Insummary, smartcontractsandblockchainsaretightlycoupled. Allowingthemigra-
tion of smart contracts will foster their flexible deployment according to the applica-
tion’s requirements. Current cross-blockchain function calls suffer from high delays
and increased complexity due to the involvement of external actors. As a precondi-
tion for trustless smart contract interoperability, state access must be available with-
out compromising blockchain-inherent attributes such as decentralization. In the re-
mainder of this thesis, we propose concepts for tackling the described shortcomings
and evaluate them based on use case scenarios of different domains.
1.2 Research Questions
Having presented the problems of isolated blockchain networks and smart contracts,
we specifythree research questions guiding the contributions presented in this thesis.
RQ1 How can smart contract states be accessed across different blockchain networks se-
curely, trustless, and efficiently?
Cross-blockchain state access depicts an enabler for many interoperable appli-
cations. Existing solutions either require trusted intermediaries or complex eco-
nomic models or are inefficient. Thus, an alternative method for cross-chain
state access is required to maintain blockchain properties like decentralization,
transparency, and verifiability.
RQ2 How can the tight bond between smart contracts and blockchains be resolved?
Once a smart contract is deployed, it strongly depends on the host blockchain.
While the state transitions over time, to date, it cannot be migrated to another
network to benefit from novel innovations, for instance. This limitation moti-
vates the conceptualization of verifiable smart contract migrations.
RQ3 How can smart contract functions query remotely hosted smart contracts without
compromising decentralization?
Currentsolutions for remotelyinvoking smart contractfunctions involve the ex-
ecutionofmultiple transactionsand sufferfromdelaysor the needfortrusted in-
termediaries. Since many applications only need read access and rely on up-to-
date data, current methods are inappropriate. Therefore, a concept for trustless
(near)-instant cross-blockchain smart contract queries is required.
6Chapter 1. Introduction
1.3 Contributions and Takeaways
We address the posed research questions through five contributions. The contribu-
tions introduced in Sections 1.3.1 and 1.3.2 focus on Research Question 1. While Sec-
tion 1.3.3 takes Research Question 2 into account, Section 1.3.4 takes up Research Ques-
tion 3. Section 1.3.5 depicts the application-based evaluation of all presented concepts
and thus contributes to all research questions.
1.3.1 Cross-Chain State Access Using Off-Chain Computations
We address Research Question 1 by presenting a concept overcoming the limitations of
state-of-the-art cross-blockchain state access solutions. Chain relayschemes provide
trustless and secure cross-blockchain state access, but current implementations are
inefficient since the entire hash chain of a remote blockchain must be verified.
We propose a novel chain relay scheme based on verifiable off-chain computations
through zero-knowledge proofs to provide cryptographically secure and highly scal-
able cross-blockchain state proofs. The presented concept enables the off-chain vali-
dation of Proof-of-Work (PoW) block headers. Multiple block headers are batched and
validated using an off-chain program. The correct program execution is proven byap-
plying zero-knowledge proofs. Since different zero-knowledge proof schemes com-
prise distinct properties, we examine their applicability and select zero-knowledge
Succinct Non-Interactive Arguments of Knowledge (zkSNARKs) and zero-knowledge
Scalable Transparent Arguments-of-Knowledge (zkSTARKs) to evaluate their scala-
bility when verifying blockchain headers. As a result, only the correct off-chain pro-
gram execution is validated on-chain, decreasing the transaction cost by orders of
magnitude.
In addition to conceptualizing standard PoW validation, we introduce a mechanism
permitting the validation of memory-hard algorithms such as Ethereum’s Ethash
within off-chain programs. We provide prototypical implementations for validating
Bitcoin and Ethereum 1.0 block headers off-chain and executing a chain relay on Eth-
ereum Virtual Machine (EVM)-compatible blockchains. Our evaluation shows that
batching 504 Bitcoin blocks and proving their validity using zkSNARKs reduces val-
idation costs by a factor of 187 compared to the prevailing BTC relay approach. The
off-chain validation of five Ethereum 1.0 block headers results in a 29x cost reduction
compared to the state-of-the-art.
1.3.2 Cross-Chain State Access Based on Finality Checkpoints
While verifiable off-chain computations permit the efficient execution of PoW-based
chain relays, they do not cater to Proof-of-Stake (PoS) protocols. We propose a con-
cept for efficiently validating block headers generated using PoS protocols that pro-
vide guaranteed finality, as implemented by, for instance, Ethereum 2.0, Cosmos, and
Polkadot. Therefore,ResearchQuestion1isaddressedbyintroducinganefficientchain
relay targeting PoS-based consensus algorithms. The presented concept does not re-
quire changes to the source blockchain protocol or validator operations. A dedicated
1.3. Contributions and Takeaways 7
relay smart contract on the target blockchain validates the signatures of block pro-
posers. Only a subset of block headers must be validated for the chain relay to main-
tain live. This yields enhanced scalability. We provide a prototype to validate Ether-
eum 2.0 beacon chain headers within the EVM. Our evaluation proves the applicability
to Ethereum’s main network and confirms that only a fraction of transaction costs are
required compared to present PoW chain relays.
1.3.3 Smart Contract Forks
We propose the concept of smart contract forks to address Research Question 2. These
forks are comparable to blockchain forks in that they share a transaction history but
diverge after a second instance is created. A smart contract’s business logic and state
are migrated flexibly and verifiable to alleviate the tight bond between the smart con-
tract and host blockchain. The newly created smart contract instance becomes avail-
able to all users and hosted smart contracts on the target blockchain. Any entity with
access to the source and target blockchain can create smart contract forks, and the
migration result is verifiable externally or by utilizing cross-chain state access tech-
niques. As various blockchain implementations support the EVM, it depicts a shared
execution environment. We provide a toolbox facilitating smart contract migrations
between EVM-compatible blockchains without requiring trust in the entity execut-
ing the migration process. To prove the concept’s soundness, we transfer token con-
tracts based on the Ethereum Request for Comment (ERC)-20 standard and applica-
tions containing dependencies to other smart contracts. Our evaluation shows the va-
lidity of ported applications, including their current states. As a result, the tight bind-
ing between smart contracts and host blockchain is effectively reduced.
1.3.4 Smart Contract Synchronization
Research Question 3 is addressed through a conceptenabling instant cross-blockchain
function calls. Smart contracts are synchronized across multiple blockchain networks
to provide directly accessible instances. Client contracts reflect the logic and state of
the original instance. Other smart contracts can query these client contracts on the
target blockchain for retrieving information without requiring cross-chain messages.
With this, we reducethe dependencyofsmartcontracts on their hostblockchainas re-
mote contracts become available as read-only instances. The synchronization process
does not require trust in the executing intermediary since Merkle proofs guarantee
correct execution. We propose a novel concept called transition confirmations for effi-
ciently proving the correctness of state updates. As a result, correct state transitions
of the client contract are ensured without re-executing the original transactions. The
prototypical implementation enables smartcontract synchronizations between EVM-
compatible blockchains. Our evaluation shows the approach’s applicability regarding
execution costs and delay.
8Chapter 1. Introduction
I Foundations
1 Introduction 2 Background 3 Related Work
II Scalable Chain Relays
4 Zero-Knowledge Proof-
based Chain Relays
5 Proof-of-Stake
Chain Relay
III Smart Contract Portability
6 Smart Contract Forks
7 Smart Contract Synchronization
IV Applications
8 Token-based
Supply Chain
Traceability
9 Decentralized
Online Social
Network
10 Cross-Chain
Oracle
V Conclusion
11 Summary 12 Discussion and Future Work
Figure 1.1: Overview of the thesis structure in stack representation.
1.3.5 Decentralized Applications Using Cross-Chain Contracts
In addition to the generic evaluation conducted for each presented concept, we evalu-
ate their applicabilitybased on the use cases of three domains. The supplychain man-
agement, Online Social Network (OSN), and Decentralized Finance (DeFi) domains
are selected because they potentially benefit significantly from blockchain technolo-
gies [36]. We demonstrate how the presented techniques can be applied to overcome
the shortcomings of application deployments limited to a single blockchain network.
Each use case has different requirements, which must be considered for selecting the
appropriate methods. We showhowthe combination of cross-chain technologies pre-
sentedinthisworkhelpstosolvelock-ineffectsandfosteraninteroperable blockchain
landscape.
1.4 Research Methodology and Thesis Organization
We apply the Design Science Research (DSR) method proposed by Hevner et al. [37] to
structure the research conducted in this thesis. The intention of DSR is to develop ab-
stract knowledge bycreating and evaluating artifacts based on a specific problem [38].
Here, artifacts can depict constructs, models, or methods [37]. The DSR research
framework includes three interdependent cycles [39].
Within the relevance cycle, requirements are collected from the application domain
and may include organizational or technical systems [39]. The concepts presented in
this work aremotivated byuse cases of three domains: supplychaintraceability, OSNs,
and DeFi. We derive the requirements for cross-blockchain smart contract interoper-
ability from these applications and evaluate the developed methods in Part IV of this
thesis, as illustrated in Figure 1.1.
1.4. Research Methodology and Thesis Organization 9
Related and foundational work is collected in the rigor cycle [39]. We present the re-
spective results in Chapters 2 and 3. Here, we introduce the foundations of blockchain
networks and current approaches for addressing blockchain interoperability, includ-
ing their limitations, such as centralization, high execution costs, and delay or fi-
nancial requirements. Further, we introduce enabling methods like zero-knowledge
proofs that are the foundations of our concepts.
The design cycle depicts the core of the research project and iterates between the con-
struction of artifacts, evaluation, and refinementfor further design steps [39]. This it-
eration is also reflected in the contributions presented in this thesis. The first require-
ment derived from the different use cases constitutes efficient and trustless cross-
chain state access. Part II of this thesis addresses Research Question 1 and introduces
two chain relaymechanisms targeting different consensus protocols. While Chapter 4
focuses on the cross-chain validation of PoW-based blockchains, Chapter 5 introduces
an approach catering to PoS-based implementations. Part II provides the foundation
for the trustless cross-chain interoperability of smart contracts presented in Part III.
Therequirementforsmartcontractmigrations isderivedfromthe presented usecases
and indicated in Research Question 2. The concept of verifiable smart contract forks
addresses this issue in Chapter 6. Since the solution does not allow for the retrieval of
cross-chain states, another artifact is required to address Research Question 3. There-
fore, we present smart contract synchronizations in Chapter 7, which are based on
smart contract forks, as illustrated by the stack architecture depicted in Figure 1.1. Fi-
nally, we discuss and conclude the results before closing with an outlook in Part V.
11
2 Background
In this chapter, we first introduce the basic functionalities and properties of block-
chains before presenting the two most prominent consensus algorithms used within
public blockchain networks, for which we will develop concepts of interoperability in
Part II of this work. We then show how light clients can be used for efficient valida-
tion since they form the basis for verifiable blockchain interoperability demonstrated
in this thesis. To understand the requirements for smart contract portability as intro-
duced inPartIII ofthis thesis, weelaborateon smartcontracts andtheir state manage-
ment. Finally, we introduce verifiable off-chain computation frameworks that permit
offloading program execution from blockchains.
2.1 Blockchain Foundations
Blockchains provide a decentralized, shared database of immutable transaction en-
tries to enable collaboration between entities without requiring centralized authori-
ties [40]. First introduced in 2008 as the foundation for the Bitcoin network, block-
chain technologyfacilitated the implementation ofa digital currencythat does not de-
pend on central banks [13]. Today, blockchains foster a plethora of decentralized ap-
plications in various application domains such as supply chain management [41], fi-
nancial markets [42] and the Internet-of-Things (IoT) [43]. In the following, we first
elaborate on the characteristic properties of blockchain technologies. After that, we
present respective concepts that provide the outlined properties.
Blockchains are distributed append-only databases that enforce a common state in
a decentralized setting [44]. Nodes in the network are connected in a peer-to-peer
manner to share transactions and state updates. Network nodes retrieve user trans-
actions and disseminate them within the network [45]. Block proposers collect these
transactions, verify and bundle them in so-called blocks. As illustrated in Figure 2.1,
blocks contain a reference to the previous block, which ensures a uniform chrono-
logical sequence of transactions. In the context of digital currencies, this mechanism
prevents double-spending, as the shared history would reveal previous transactions
spending equivalent tokens [13]. This mechanism generally represents a uniform se-
quence of state transitions across the network, which can be mapped to the state ma-
chine of arbitrary decentralized applications [14]. Since block hashes conduct ref-
erences, this creates a recursive concatenation that—given an accepted succeeding
block—renders history modifications very costly.
In the following, we introduce the terminology used for describing blockchain pro-
cesses and properties.
12 Chapter 2. Background
Merkle Root
Timestamp
Nonce
Previous Hash
Merkle Root
Timestamp
Nonce
Previous Hash
Merkle Root
Timestamp
Nonce
Previous Hash
Block Hash Block Hash Block Hash
Transaction A Transaction B Transaction C Transaction D
Hash (A) Hash (B) Hash (C) Hash (D)
Hash (H(A) || H(B)) Hash (H(C) || H(D))
Figure 2.1: Simplified overview of blockchain structure, including a
Merkle tree of transactions. Every block holds a reference to the pre-
ceding block. Merkle trees allow the implementation of light clients.
Leader election. Since decentralized networks consist of participants having equal
rights, an algorithm is required that allocates the right to append a subsequent block
to the blockchain. This process is referred to as leaderelection and is usuallyconducted
as part of the consensus algorithm. As distributed networks suffer from network de-
lays and partitions, there may be distinct views on the current state between partici-
pants [46, 47]. Therefore, the leader election process may lead to multiple valid block
proposers for a succeeding block.
Forks. Forks describe the creation of more than one block succeeding a single block of
the blockchain. For instance, Figure 2.2 illustrates the appearance of two forks. First,
two blocks B1and B2are proposed based on a common block Aand multiple blocks
succeed both blocks. Second, a single block D3is appended to C2. Note that all blocks
succeed the genesis block that is pre-defined by the protocol and irreversible. The lat-
est accepted block is also referred to as blockchain head. Depending on the network
state, distinct forks may be accepted by different network members. However, there
must be eventual consistency over time as delayed blocks are disseminated within the
network. Multiple selection rules exist to choose from competing blocks, as outlined
in Section 2.2.
Finality. Once a block cannot be reverted by a competing fork, the block is considered
final. Finality either occurs (near) instantly after a sufficient amount of votes has been
collected from participants [19, 48, 49], or probabilisticallywith anincreasing number
of succeeding blocks [13]. Since blocks that are not finalized entail a certain degree of
uncertainty, they pose a challenge to implementing blockchain interoperability.
State. The state of a blockchain network results from sequentially executed trans-
actions that have been included in all accepted blocks. Two distinct concepts exist for
representing the global network state: Unspent Transaction Outputs (UTXOs) and ac-
counts.
2.1. Blockchain Foundations 13
A
B1
B2
C1
C2 D2
D3
E
D1
…
Genesis
Block
Figure 2.2: Representation of two forks that occurred in the history of
the longest chain depicted by block E. The fork choice depends on the
consensus algorithm’s rules.
The UTXO model was first proposed to define ownership of tokens in Bitcoin [13]. To-
kens aretransferredbycreatingtransactionsthatcomprisescripts definingconditions
for spending respective tokens. In the simplest case, the script requires proving own-
ership of the public key corresponding to the recipient’s address by signing the hash
of the spending transaction [12, 50]. As long as the script has not been executed, the
transaction is unspent, and the address owner owns the comprised tokens. Each out-
put is represented by a single script connected to a unique input [50]. A transaction
can hold multiple input and output addresses so that the tokens included in transac-
tions can be merged and split. The resulting network structure can be represented as
a Directed Acyclic Graph (DAG) [50, 51]. Since ownership is only defined as the un-
used output of a transaction, there is no fungible account balance that is managed in
addition.
The account-based model was first implemented to cater to smart contracts in the
Ethereum network (see Section 2.4) [14]. An account can be assigned to a user, also
referred to as an Externally Owned Account (EOA), or a smart contract. Every account
has adedicated state thattracks its balance and, in the caseofsmartcontracts, its stor-
age values [15]. Instead of executing a script that is included within the transaction,
state transitions are executed by a state machine that verifies sufficient balance and
executes formerly deployed execution logic.
2.1.1 Properties
Different manifestations of blockchains exist. In the following, we present the char-
acteristics by which blockchain concepts can be distinguished.
Permission. Decentralized networks are usually divided into permissioned and per-
missionless networks [52]. Before joining a permissioned network, participants must
receive authorization. The enrollment process is either executed by a dedicated gate-
keeper or granted by an issued agreement of participants. The rules for accepting new
participants may be enforced in an automated fashion, for instance, by executing re-
spective smart contracts (see Section 2.4) or in a process that is outside the consensus
protocol’s scope [53]. As the enrollment process typically includes authentication, the
identities ofparticipants are known. Therefore, consensusprotocolsthatutilize voting
to commit to a common state in a permissioned setting usually allocate a single vote
to each authorized entity [54]. In addition to voting, known identities allow for the
14 Chapter 2. Background
efficient implementation of leader election in the block proposal process, for instance
by selecting the next block proposer in round-robin order [55, 56].
A common application for permissioned networks is the collaborative execution of
shared business processes by a consortium of organizations [57]. Such applications
usually restrict access to the ledger to participating entities, as it may comprise con-
fidential information that should only be shared within the consortium. Correspond-
ing blockchain networks are referred to as private since external entities cannot read
or write to the ledger [58]. Another use case comprises institutions that collaborate
to offer services, such as in Self-Sovereign Identity (SSI) applications [59]. While the
consensus algorithm is operated by a pre-defined set of participants, external enti-
ties can access the ledger state. Therefore, blockchain networks that do not restrict
retrieving the ledger are called public.
Permissionless networks neither restrict reading and writing to the ledger nor par-
ticipation in the consensus algorithm [60]. Participants are usually identified by an
address that is derived from their public key [12, 15]. Thus, identities are pseudony-
mous and not directly linkable to respective users [44]. Since key pairs are generated
locally, userscancreatearbitrarypseudonyms. Therefore,permissionlessledgershave
to cope with Sybil attacks that infer the creation of multiple identities to cast votes in a
distributed system [61]. As a result, corresponding consensus algorithms cannot rely
on identities for leader election and validation buthave to utilize scarce resources such
as computational power (see Section 2.2.1) or staked tokens of limited supply(see Sec-
tion 2.2.3).
Roles. Wedifferentiatebetween threedifferenttypes ofnodesparticipating inthe net-
work: block proposers, validators, and wallets. While wallet holders do not actively
participate in the consensus protocol, they hold identities that enable the creation of
transactions [62]. Validator nodes verify the correctness of the blockchain, including
transactions and the correct application of the consensus protocol. Furthermore, they
retrieve transactions from wallet holders and disseminate them in the network after
validation. Block proposers compete to create the next block to append to the block-
chain. Sinceblockchainsynchronizationisrequiredbeforeproposingnewblocks, they
usually also take the role of validators.
Decentralization. Blockchain networks facilitate the collaboration of mutually dis-
trusting entities by seeking consensus on a shared truth and not requiring centralized
authorities to operate. No single entity or minority should be able to modify the his-
tory of transactions or prevent valid transactions from being appended to the ledger.
The degree of decentralization depends on the distribution of voting rights between
participants, where each member acts independently [24]. Different consensus algo-
rithms provide distinct guarantees to withstand attacks from groups of participants.
For instance, under certain assumptions, the PoWalgorithmensures correctoperation
in case a majority of respective computational resources is applied by honest partic-
ipants, as elaborated in Section 2.2.1. For this reason, networks that share required
resources among participants are considered decentralized [63]. The higher the dis-
tribution of the required resources, the greater the decentralization.
2.1. Blockchain Foundations 15
Consensus. There is a general agreement about a shared state between all partici-
pants. The state is derived from a set of transactions. Global consensus is reached
with the finality of a block or epoch and includes all previous transactions and states.
Depending on the protocol, finality may occur instantly, after a predefined period, or
probabilistically.
Total order. Applying blockchains to a state machine that transitions between states
in a reproducible fashion requires the total ordering of transactions. For instance,
the transfer of value should only be executable by the respective owner, and double-
spending must be prevented [12]. Blockchains guarantee total order by linking blocks
of transactions successively [44]. Transactions that have been recorded previously
or violate the state machine rules are rejected. Additionally, block proposers arrange
transactions within the created blocks [15]. The total order is guaranteed as long as no
competing fork converts the previously accepted blockchain history [44].
Verifiability. Any participant in the network can verify the correctness of the ledger
state, including block proposers and observing validation nodes [58]. As all aspects
are verifiable by applying a protocol based on public data, the property is referred to
as public verifiability. It comprises the entire blockchain history so that newly join-
ing participants should be able to verify the correctness of the retrieved state accord-
ing to the protocol. The validation considers various conditions, which are defined by
the consensus protocol and state machine. State machine transitions are initiated by
transactions signed by external users using respective blockchain wallets. Such wal-
lets comprise one or more key pairs that are used to create signatures authorizing the
execution of specific transactions. For instance, the state machine maypermit a token
transfer if the transaction presents a signature that is verifiable using a specific public
key. Therefore, blockchain verification implies executing and validating all transac-
tions in each block.
The consensus verification is specific to the applied algorithm but always entails the
validation of the hash chain. Thus, each block must refer to the previous block using
its hash, as illustrated in Figure 2.1. Furthermore, everyconsensus algorithm requires
the verification of the correct leader election.
In the context of blockchain interoperability, verifiability constitutes a challenge, as
data cannotbe activelyretrieved from the source blockchain. In addition, there maybe
limited computational capacityon the target blockchain, memory and storage restric-
tions, and limited instruction sets supplied by the target blockchain’s state machine.
Redundancy. All data that is required for verification must be available to existing and
newly joining participants [58]. The replication of respective data ensures verifiability
from the genesis block. While some clients may prune the state history to minimize
storage requirements, nodes supplying historical transactions are required to serve
new nodes in the network for full synchronization.
Immutability. Blockchains provide immutability of the transaction history, given an
accepted succeeding block [52]. The implementation of a hash chain reveals any mod-
ification in the state history, as either the link between two blocks would break or all
following blocks would have to be modified. Since such a modification results in a dis-
tinct blockchain head from the currently accepted, nodes following the protocol would
16 Chapter 2. Background
reject such hash chains. Yet, immutability can only be guaranteed as long as a prede-
fined minimum of participants acts honestly and after finality is reached. Thus, im-
mutability presumes a notion of finality that is either guaranteed or probabilistic.
2.1.2 Merkle Trees and Proofs
Blockchain implementations widely utilize Merkle trees to provide a means for effi-
ciently storing transactions and state information while maintaining full verifiability.
We differentiate between full blockchain blocks that include all transaction data and
block headers that contain the information required for the core consensus and a ref-
erence to transaction data stored in a Merkle tree. Merkle trees facilitate the efficient
storage of states in account-based blockchain implementations. In addition, they en-
able the use of light clients as outlined in Section 2.3.
2.1.2.1 Binary Merkle Trees
The concept of hash trees, also referred to as Merkle tree, was first proposed by Ralph
Merkle to efficiently create one-time signatures that commit to a single public key
and are logarithmic in size [64]. The concept can be generalized to a commitment
scheme that enables arbitrary messages to commit to a single value [65]. Messages
in a Merkle tree are hashed recursively, with each message depicting a tree leaf and a
single root that constitutes a common commitment for all comprised messages, as il-
lustratedin Figure 2.1. Interiornodesofthe treearedetermined bythe hashofmultiple
child nodes, depending on the tree’s degree [65, 66]. In its original proposal, Merkle
suggested a degree of two, i.e., a binary tree [64].
Due to the properties of cryptographic hash functions, changes to a message would
result in a distinct digest. Since the hash function is applied recursively, a modified
message consequently results in a different tree root. This ensures the integrity of
included messages, given a trusted tree root.
To prove the commitment of a message to a Merkle root, the prover must present the
message itself and a so-called witness. The witness includes the hashes of all nodes
contributing to the path computation from the leaf to the root. These nodes are also
referred to as sibling nodes, as they constitute the path’s child nodes that are not de-
rived from the leaf of interest. Furthermore, the witness requires an indicator for each
sibling node representing its concatenation location. For example, in the case of bi-
nary trees, it is indicated whether the child node is located on the left or right side to
correctly concatenate hashes for computing the interior node. The witness size wde-
pends on the tree’s degree dand the number of messages in the tree m. Since all sibling
nodes are required to compute the parent nodes that constitute the witness path, the
size is defined as w=d· ⌈logdm⌉. For instance, the witness for a message in a binary
tree with m= 4, as depicted in Figure 2.1, comprises 2·log24=2node hashes. More
elaborate Merkle tree concepts, such as Merkle Patricia trees, store values on different
heights of the tree, resulting in distinct scalability properties.
2.2. Consensus Algorithms 17
2.1.2.2 Merkle Patricia Trees
Patricia trees were first proposed by Morrison in 1968 to efficiently store, index, and
retrieve information in large files [67]. Merkle Patricia trees extend this data structure
to enable Merkle proofs for indexed data [14]. Indexed storage is required by account-
based blockchains that assign a state to accounts. The state is determined by key-
value pairs, where the key can be the hash of a transaction or account address [15]. For
example, Ethereum utilizes Merkle Patricia trees to store transactions, the resulting
global state, and emitted events in every block [14]. Merkle Patricia trees are selected
since theypermit proving the inclusion ofa value given a specific keyin the key-value
store.
Paths constructed in Merkle Patricia trees are built from the root to the leaf based
on the key, as depicted in Figure 2.3. Thus, it differs from the previously introduced
Merkle trees that construct the tree starting from the leaves and change depending
on the order of leaves. Nodes are identified by their hash digest and referenced from
a parent node. The tree structure of Merkle Patricia trees is deterministic and deter-
mined by the keys of included key-value pairs. The keys of corresponding values are
partitioned into common partial keys that are subsumed in nodes. Traversing the tree
requires iterating the key nibble by nibble. Each node comprises a partial key. The full
key of a value stored in a leaf can be observed by concatenating all partial keys of a
path from the Merkle root to the leaf. For instance, Ethereum uses a hexadecimal key
representation that results in a tree degree of 16. While a high tree degree produces
short paths, respective witnesses require large sets of sibling node hashes. Therefore,
generated proofs are typically larger compared to binary Merkle trees.
The modified Merkle Patricia trees introduced in Ethereum comprise three node
types [15]. First, branch nodes represent diverging paths based on a single nibble.
Therefore, in the case of Ethereum’s hexadecimal key representation, a branch node
holds references to up to 16 nodes. Furthermore, a branch node may comprise a value
if the tree was fully traversed to represent the respective key. For instance, the key
0xB22 is represented by a branch node that holds the value 7in Figure 2.3. Second, ex-
tension nodes comprise a partial key without branches. A “shortcut” is implemented
that permits compressing multiple nibbles into a single node. As extension nodes only
represent a shared part but no branches, only a single node is referenced for the re-
maining partial key. Note that extension nodes always reference branch nodes, as the
partial keyof a second extension node could be merged into a single extension node or
a single leaf node in case only one key-value pair follows. Third, leaf nodes hold the
remaining partial keythat is not shared with any other key-value pair and a value. For
instance, Figure 2.3 depicts a leaf node representing key 0x41357, where the first nib-
ble is represented by a branch node, and the remaining partial key is stored within the
leaf.
2.2 Consensus Algorithms
Consensusalgorithmsenableestablishingasharedstatebetweenpeersofadistributed
system, even in the event of individual participant failure, malicious behavior, and
asynchrony[68]. Indecentralizednetworks, controlisdistributedacrossparticipating
18 Chapter 2. Background
Branch Node
0 1 2 3 4 5 6 7 8 9 A B C D E F Value: 0
Merkle Root
Leaf Node
Path: 02 Value: 17
Hash
Extension Node
Path: 22 Key
Hash
Branch Node
0123456789ABCDEF
Hash
Value: 7
Full Path: 0xB22602
Leaf Node
Path: 02 Value: 72
Hash
Full Path: 0xB22B02
Full Path: 0xB22
Full Path: 0x41357
Leaf Node
Path: 1357 Value: 23
Hash
Full Path: 0xD42
Leaf Node
Path: 42 Value: 13
Hash
Figure 2.3: Simplified representation of a Merkle Patricia tree ofdegree
16. Five key-value pairs are stored in four leaf nodes and one branch
node.
clients and does not rest with a central authority. Presuming participants in a decen-
tralized networkmaybehave maliciously, applied consensus algorithms mustcater for
agreement even in the event of attacks ofa certain fraction of actors. Algorithms with-
standing such misbehavior, referred to as Byzantine actors, are called Byzantine Fault
Tolerant (BFT). Algorithms providing consensus in fixed and limited-sized networks
have been available for decades. Examples include Paxos [69], Raft [70], and Practical
Byzantine Fault Tolerance (PBFT) [54]. With Nakamoto consensus, the first protocol
enabling consensus in public settings was introduced with Bitcoin in 2008 [13]. Here,
the consensus protocol permits the implementation of a distributed ledger of transac-
tions maintained by participants without requiring permission to participate.
Consensus algorithms catering to blockchain networks must provide means for leader
election and fork choice [12, 70]. Those protocols operating in permissionless settings
must prevent Sybil-attacks in addition [61]. Since this work focuses on interoperabil-
ity and the incorporation ofpermissionless networks, the two most popular categories
of corresponding consensus algorithms are presented in the following.
2.2.1 Nakamoto Consensus (Proof-of-Work)
Nakamoto consensus is a protocol that conducts leader election based on PoWand was
first developed to enable the Bitcoin blockchain to operate in a permissionless net-
work setting [13]. Dwork and Naor initially proposed PoW in 1992 to mitigate spam
2.2. Consensus Algorithms 19
E-Mails [71]. Message senders must present proof that computation of certain com-
plexityhas been conducted before the receiver accepts a message. The Nakamoto con-
sensus protocol applies a similar mechanism: Participants competing to append the
next block to the blockchain, also referred to as miners or block proposers, compute a
solution to a predefined cryptographic problem [13]. Network nodes only accept pro-
posed blocks if the provided PoW is sufficient.
Mining. In blockchain implementations such as Bitcoin, PoW implies finding a nonce
that, concatenated with the proposed block header, results in a hash smaller than a
given target value. Since block headers include the previous block’s hash, a distinct
nonce is required after a new block is appended to the blockchain, mitigating pre-
computations. This property is also referred to as uniformround [46]. While the calcu-
lation ofa valid PoWis computationallycomplex, thepresented solution canbe verified
efficiently by other network participants. The PoW difficulty is adjusted regularly as
the total computational power of all network nodes is variable in a public setting [13].
The protocol targets an average mining time for each newblock. For instance, the Bit-
coin protocol aims for a new block to be appended every ten minutes on average [72].
The PoW difficulty is constant for a given number of blocks, referred to as epoch, and
recalculated after the period elapsed. Note that the epoch length may also equal one,
as in the case of Ethereum 1.0, resulting in difficulty adjustment with every mined
block [15]. If the average mining time within the elapsed epoch is below the target,
the difficulty is increased, and vice versa if the target is exceeded [12].
Nakamotoconsensus usescomputational powervia PoWasa scarceresourceforleader
election and does not require unique identification of participants. This prevents, for
example, Sybil attacks in which attackers create new identities at virtually no cost to
increase the probability of being elected [61]. While permissioned blockchain net-
works address this problem through an authentication process, pseudonyms preserve
user privacy in public settings.
Forks and Finality. Similarly, fork choice requires a rule applicable in an asyn-
chronous setting [73]. Nakamoto consensus utilizes the so-called longest chain rule
that prefers the fork involving the most accumulated PoW [12]. Thus, when nodes re-
ceive a competing fork, it is checked whether the included total computational effort
exceeds the PoWincluded in the currently accepted hash chain. The term longestchain
roots in the fact that usually hash chains containing more PoW, also comprise more
blocks, while this is not true in all cases. In the following, longer hash chains refer to
forks containing more PoW.
Since forks comprising more PoW can appear at any time, the Nakamoto consensus
does not guarantee finality. Attackers could create an unpublished fork longer than
the currently accepted main chain, for instance, to execute a double-spending attack.
Yet, the creation of such forks requires at least 51% of the network’s total computa-
tional power,1as the remaining network participants would create a longer chain in
the same time otherwise [12]. The public takeover of the computational majority is
referred to as 51%-attack, while disclosure after private mining is called long-range-
attack [45]. Since theuse of computing power involves economic effort, theprobability
1Eyal and Sirer showed that under certain conditions, less than 51% of the network’s total computational
power are sufficient for constructing long range attacks by applying selfish mining [74].
20 Chapter 2. Background
that the attack is worthwhile decreases with the number of blocks added to the main
chain. Therefore, Nakamoto consensus achieves probabilistic finality since the prob-
ability of a block to be included in the main chain permanently increases with every
block appended subsequently [47].
2.2.2 Memory-hard PoW Algorithms (Ethash)
To optimize the mining process, so-called Application-Specific Integrated Circuits
(ASICs), dedicated hardware specialized for a single task, have been constructed for ef-
ficiently computing PoW. Since the utilization of professional hardware may exclude
end-users from participating in the mining process and thus potentially lead to the
centralization of mining power, memory-hard PoW algorithms have been proposed
to mitigate the utilization of ASICs [75]. For instance, Ethereum’s Ethash requires re-
trieving data slices from a dataset that is held in memory. The retrieved slices are de-
terministic to the block number and nonce and contribute to the pre-image used for
computing the target hash. As a result, the data bus becomes the bottleneck in mining
instead of the hashing function as in the original proposal [15].
In Ethereum 1.0, an epoch does not refer to the number of blocks maintaining a
constant PoW difficulty but to the number of blocks mined using an equivalent
dataset [15]. Every epoch holds a seed that is defined as the Keccak-256 hash of the
previous seed, where the initial seed is the hash of 32 bytes of zeros. Since the seed is
independent of the blockchain’s history, it can be pre-computed for all future epochs.
Based on the seed, a pseudo-random cache is generated that is approximately 16MB
large and used for generating the mining dataset. In addition, the cache is used for val-
idating the PoW solution, for instance, bylight clients. The dataset consists of pseudo-
randomly generated data items based on the cache. The initial size is about 1GB and
growing over time.
Mining using the Ethash algorithm requires the retrieval of 64 data slices from the
calculated dataset for each tested nonce [15]. The slices are selected based on the hash
of the block header and nonce. The PoW value constitutes the hash of the compressed
data slices and seed value [76]. To validate a block header, nodes check whether the
correctdataitemswereusedbycalculatingthemfromthecache. Proposedblockhead-
ers are only accepted if the PoW falls below the target value, and the correct dataset
items were selected [15].
2.2.3 Proof-of-Stake
The objective of PoS is to overcome the inherently high energy consumption of PoW
as well as higher participation of users in the protocol and the provision of guaranteed
finality[48, 68, 77]. Insteadofcomputationalresources, storedassetsareusedtoselect
the next block proposer [19]. Sybil attacks are mitigated, as staked deposits act as a
limiting factor [78]. Furthermore, honest behavior is incentivized, for instance, by
distributing rewards for correct participation in the protocol or by burning stakes in
case of disclosed misbehavior, also referred to as slashing [79]. Protocols that apply
slashing when misbehavior isdetected are called accountablysafe in thefollowing[49].
2.2. Consensus Algorithms 21
Staking. Staking, also referred to as bonding [80], describes the process of locking as-
sets to participatein the consensus protocol [79]. Stakeholders can withdraw stakes in
a process called unbonding [81]. The unbonding period defines a duration participants
have to wait before the stake can be withdrawn. Typically, the probability of becom-
ing a block proposer is either proportional to bound stake [77, 78] or a fixed amount of
stake required to participate [49]. Delegated Proof-of-Stake (dPoS) describes an ex-
tension that permits voting for a delegate who participates in the consensus protocol
on behalf of the staking nominator [78].
PoS consensus protocols suffer from the so-called nothing-at-stake problem that al-
lows for long-range attacks [78]. PoW-based protocols do not suffer from such at-
tacks, as creating forks requires significant computational and, thus, economic in-
vestments. Creating an illegitimate fork becomes more infeasible with each appended
block in the competing fork. In comparison, creating blocks in PoS calls for the com-
putation of signatures, a relativelycheap operation compared to PoWmining thatmay
permit colluding validators to create forks of arbitrary length to force blockchain reor-
ganizations. Various approaches exist to tackle such attacks. For instance, validators
maydetectthe double-signing of competing forks and submit proof to the blockchain,
slashing the perpetrator’s funds [49]. Protocols that accept only recent blocks to pre-
vent long-range attacks are denoted weakly subjective [45].
Time. Many PoS protocols divide time into slots and epochs [48, 49, 77]. A slot is
a time period containing at most one valid block. An epoch is defined by the num-
ber of consecutive slots with a constant set of validators responsible for voting on
blocks [49]. Each transition between two epochs can be considered a scheduled val-
idator set change. The validator change rate defines how much the validator set may
change at each scheduled validator set change.
2.2.3.1 Nakamoto-inspired PoS
In Nakamoto-inspired consensus protocols, the longest chain of blocks is the pre-
ferred fork [13]. The likelihood of a block being permanently included in the agreed
blockchain increases the more successive blocks are appended. While first proposed
in 2008 as part of the Bitcoin protocol, the concept has also been applied to PoS proto-
cols [77]. With Ouroboros Genesis, Badertscher et al. have proposed a protocol that
utilizes the density of created blocks to choose the accepted chain rather than the
longest chain [18]. Hereby, long-range attacks are mitigated, and nodes that turn of-
fline or join the network ata later stage can synchronize from the genesis block and do
not require trusted checkpoints. Thus, the trustless synchronization of Nakamoto-
based PoS provides an advantage compared to PBFT-inspired algorithms (see Sec-
tion 2.2.3.2).
Forks and Finality. The validation of a Nakamoto-inspired PoS protocol requires sig-
nature validation, fork handling, and the validation of validator sets. Ifthe target block
succeeds a stored block within the same epoch, the validator set must be equal. Oth-
erwise, the epoch transition must be verified based on the selection rule. As finality
is only probabilistic for Nakamoto-inspired protocols, interoperability concepts like
chain relays (see Section 3.1.2) have to be able to handle forks of arbitrary length. In
22 Chapter 2. Background
order to synchronize, the fork’s length or density is taken into account. The valida-
tion of validator set changes typically requires awareness of the entire blockchain, as
leader election depends on preceding stake distribution, and subsequentvalidator sets
are not explicitly signed.
2.2.3.2 PBFT-inspired PoS
PBFT is a consensus algorithm that enables state machine replication surviving
Byzantine faults in a permissioned setting [54]. Participants cast votes in multiple
rounds to commit to a common state. The protocol tolerates up to 1/3 of Byzantine
participants. PBFT-inspired PoS algorithms such as Tendermint [80] or Gasper [49]
apply a comparable voting mechanism to facilitate consensus in a permissionless set-
ting. Validators vote on their view of the current state by signing blocks. As a result,
finality is guaranteed since a block holding sufficient signatures from the responsible
validator set cannot be reverted and is therefore deemed final [48]. This feature repre-
sents an advantage over Nakamoto-based protocols, as no probabilistic assumptions
are required.
However, this comes at the cost of limited verifiability when participants temporarily
leave the network or join at a later stage, as fork choice depends on validators’ votes.
Accountablysafe andweaklysubjectiveprotocolspreventlong-rangeattacksbyslash-
ing their stake in case the double-signing of multiple forks is disclosed. Yet, the stake
can be withdrawn after the unbonding period has elapsed, permitting adversaries to
collude on double-signingatpracticallyno cost. Validator signaturesareonlytrusted if
the validators are accountable in weakly subjective PoS protocols [45]. The trustingpe-
riod describes the duration validators are accountable, and it must be shorter than the
unbonding period [82]. Weakly subjective consensus protocols require participants
who have not received and validated any block for longer than the trusting period to
obtain a trusted state from a trusted source [81]. Based on this state, they can continue
validating succeeding blocks. Consequently, clients cannot synchronize starting from
the genesis block after the firsttrusting periodhas elapsed if the respective blockchain
applies a weakly subjective consensus protocol.
Accountable safety depicts a challenge for blockchain interoperability and, in partic-
ular, chain relays, as the property can only be maintained if valid block headers are
submitted regularly (see Section 3.1.2). For instance, a validator could double-sign a
forkfromthemainchainandsubmitittothechainrelay. Ifthetrustingperiodelapsed,
the adversary could not be held accountable. If the trusting period has not elapsed, ac-
countabilitycan only be ensured if observers capture potential misbehavior and report
it to the source chain.
2.3 Light Clients
Light clients are network nodes that do not validate the transactions included in a
block, but the hash chain’s consensus rules [13, 83]. Thus, light clients only retrieve
block headers for validation, decreasing networking, storage, and processing load.
Hereby, devices with restricted resources such as mobile or IoT devices are enabled to
2.3. Light Clients 23
operate blockchain clients [84]. Light clients retrieve a Merkle proof of inclusion from
a full node to validate a specific transaction of interest. The proof is verified based on
the Merkle root stored in the respective block header that is part of the formerly val-
idated local header chain. This process is also referred to as Simplified Payment Ver-
ification (SPV). SPVs can be executed to guarantee the inclusion of a transaction in a
specific block or, in the case of state-based blockchains, the existence of events and
states [85].
The trust assumption that light clients adopt depends on the blockchain’s consensus
protocol. For instance, in thecase ofPoW, a minercould create ablock that includes in-
valid transactions to execute attacks such as double-spending. While full nodes would
reject the proposed block after transaction validation, light clients may accept such a
block header if it meets the consensus rules. After acceptance, attackers could pro-
vide Merkle proofs to convince the light client that a particular transaction has been
included. PoW light clients utilize a mechanism based on economic assumptions to
mitigate such attacks. Block headers are only trusted after a predefined number of
blocks have been appended to them. With this, the risk of forks is reduced, and the
economic burden on the attacker increases since honest miners running full nodes
would detect the invalid block and refuse it. For this reason, PoW light clients apply
countermeasures similar to those used to prevent 51% attacks (cf. Section 2.2.1).
In contrast, PoS light clients need to check the correct selection of validators and their
signature to validate the header chain [82]. Typically, the validator set is selected
pseudo-randomly based on the blockchain history and entropy provided through
commit reveal schemes such as RANDAO and Verifiable Delay Functions (VDFs) [18,
78, 86]. Since the required history may not be available to light clients and the val-
idation of all validator signatures may exceed the device’s computational resources,
multiple concepts have been proposed to facilitate efficient verification. First, a subset
of validators is sampled that remains responsible for a longer period, compared to the
validator set of the main consensus [87]. Hereby, fewer transitions between smaller
validator sets must be verified. Second, validators sign the sampled succeeding val-
idator set [88]. Since the current validator set is trusted, light clients do not need to
conduct the sampling to reproduce the validator set transition. Instead, it can rely on
the provided trusted signature. Third, PoS lightclients donotneed tomaintain the en-
tirehashchainbutonlyrequiretrackingitsevolutionbasedon epochs[82]. Asa result,
correct validator set transitions between epochs are ensured while reducing compu-
tational and storage overhead.
Sublinear Light Clients. The validation time of classic lightclients scales linearlywith
the hash chain’s size. Sublinear light clients aim to reduce validation costs by requir-
ing only a subset of block headers to be validated. Multiple approaches have been pre-
sented to overcome the challenges posed by sublinear scalability, as the clients that
only retrieve a subset of blocks cannot fully validate the blockchain’s PoW or PoS sig-
natures [84].
Kiayias et al. propose the utilization of so-called super-blocks to facilitate efficient PoW
light clients [89]. A super-block is a blockchain block that comprises significantly
more PoW than required to be accepted. Multiple levels of super-blocks exist. Lev-
els are assigned to blocks depending on the amount of PoW exceeding the required
24 Chapter 2. Background
difficulty. The concept requires the underlying blockchain protocol to be modified so
that blocks contain a reference to a super-block of each level. Verifiers query respec-
tive blocks from the prover interactively, skipping intermediary non-super-blocks.
Hereby, validation is enabled in logarithmic time. With Non-Interactive Proofs of
Proof-of-Work (NIPoPoW), an extension to the protocol is presented that does not re-
quire interactive communication [90].
With FlyClient, Bünz et al. present a light client solution that is supposed to overcome
the inherent shortcomings of NIPoPoWs [84]. Namely, NIPoPoWs presume constant
difficulty, a property PoWblockchains such as Bitcoin or Ethereum 1.0 do not have [13,
15, 84]. Furthermore, NIPoPoWs tolerate attacks from adversaries that account for up
to 1/3 of the total hash rate, while FlyClient tolerates up to 1/2 adversarial hash power.
FlyClient facilitates logarithmic transaction proofs through Merkle Mountain Ranges
(MMRs). An MMR is an append-only data structure of balanced Merkle trees that are
merged if the resulting tree is also balanced [84]. As a result, insertion is efficient, as
rebalancing only requires merging trees, while proofs remain short and logarithmic
in size. Like NIPoPoWs, FlyClient requires modifications to the blockchain protocol.
Each blockchain block must comprise an MMR root hash that subsumes all previous
block headers of the header chain. In addition, the constructed MMR holds informa-
tion concerning the total difficulty and difficulty transitions to enable the application
of FlyClient to blockchain protocols that implement variable difficulty. While transac-
tion proofs also scale logarithmically with the blockchain’s size, they are about 40%
smaller compared to NIPoPoWs.
2.4 Smart Contracts and the EVM
Blockchains provide immutable peer-to-peer storage of digitally signed transactions
that permit, for instance, exchanging assets without requiring any intermediaries. In
addition to simple transactions sending assets from one partyto another, Bitcoin sup-
plies a scripting language for implementing additional functionality such as multi-
signature transactions [12]. However, the scope of Bitcoin scripts is limited to very
basic procedures [91].
To overcome this limitation, Ethereum was proposed as an alternative blockchain im-
plementation that provides a quasi-Turing-complete virtual machine, the EVM [14].
Programs written for the EVM, called smart contracts, are typically developed using a
high-level programming language such as Solidity2or Vyper3. These high-level con-
tracts are then compiled to bytecode that is interpreted by the EVM. The resulting
program code consists of multiple components, as exemplified in Figure 2.4. First,
deployment-specific code is generated that instructs the EVM to allocate memory,
store contract code, and execute the constructor [15]. Second, the constructor sets the
initial state. Because it is only executed during the contract’s deployment, its byte-
code is not included in the application logic, namely the contract code. Nevertheless,
it changes the contract instance’s state according to the declared instructions. Third,
2https://github.com/ethereum/solidity
3https://github.com/ethereum/vyper
2.4. Smart Contracts and the EVM 25
Smart Contract
constructor
functions
variables
events
set
set
emit
Deploy Code
preamble
constructor
Contract Code
Compilation
code copy instruction
1
2
3
Figure 2.4: High level Solidity code is compiled to deployment code
which is embedded into a transaction.
functions implemented in Solidity permit executing calculations, accessing the ap-
plication’s storage, and triggering other internal or external procedures on the same
chain. Accordingly, functions are compiled to runtime code by the Solidity compiler,
which is a subset of the deploy code that is executed when deploying smart contracts
to the blockchain. While the EVM does not nativelysupport functions, referenced code
can be called using the original function’s signature, which is defined as the first four
bytes of themethod’s nameand parameterhash [92]. Within thedeploycode, the EVM
is instructed to copy the compiled runtime code; therefore, it is part of the blockchain
account. The compiler also calculates storage locations for each variable set. As the
EVM uses key-value mappings for allocating variables in the storage tree, single vari-
ables are numbered sequentially by the Solidity compiler. Values stored in mappings
and arrays are allocated according to their keys’ hash. In addition to constructor and
contract code, a preamble is generated during the compilation process that allocates
memory and calls required deployment instructions.
Since all participants must execute the transactions recorded in a block for validation
purposes, the number of possible execution steps is limited to cater to restricted com-
putational resources and network delays. Ethereum implements a concept called gas
to regulate resource allocation. Every operation in the EVM requires a specific amount
of gas for its execution [15]. Blockchains implementing the EVM specify a gas limit
for each block to determine an upper bound of execution steps. In Ethereum, trans-
action senders must include cryptocurrency in each transaction to bid for gas that is
needed for its execution. Hereby, a market is created for the limited gas supply, leading
to increasing gas prices with a growing number oftransactions. In addition, Ethereum
offers an alternative pricing model that was implemented with the so-called London
fork4. Here, the gas needed for executing the transaction is multiplied bya base fee and
priority fee. The previous block’s utilization determines the base fee, and users set the
priority fee depending on the price they are willing to pay for timely transaction in-
clusion.
Unlike Bitcoin, which relies on UTXO to facilitate asset transfers [12, 13], Ethereum
follows a state-based account structure. Two forms of accounts exist: user accounts,
4https://eips.ethereum.org/EIPS/eip-1559
26 Chapter 2. Background
also referred to as EOAs, and smart contracts. An account is defined as a mapping be-
tween an account address and a tuple of four [15]:
•Nonce. The value ensures correct ordering of transactions initiated by from
an account and is incremented after every transaction execution. Transaction
senderscan submitmultipletransactionsusingthesamenonce. Minerswilltyp-
icallyrecord the transaction that allows for a higher gas price. If the accountcon-
tains a smart contract, the nonce is incremented after it has been invoked.
•Balance. EthereumstoresthebalancesofitsnativetokenETHseparatelyforeach
account.
•Storage Root. Smart Contracts maintain a dedicated state that is represented
using a Merkle Patricia tree for fast and secure verifiability (cf. Section 2.1.2).
Thus, the account’s associated Merkle root changes with every state transition,
as illustrated in Figure 2.5. EOAs do not maintain a state.
•Code Hash. During deployment of a smart contract, its logic is stored and re-
ferred by its hash. Since the value is immutable, the smart contract logic cannot
be changed after its deployment. EOAs accounts have no associated code.
Figure 2.5 depicts the state transition of a smart contract between two blocks of a
blockchain. In the given example, a transaction calls a contract function that instructs
the virtual machine to modify the value stored at key 0x05 from five to six. As a result,
the respective path within the contract-specific Merkle tree changes, and the storage
root is adjusted. During contract execution, the internal state may change, and exter-
nal smart contracts deployed on the same chain can be triggered. In addition, events
can be emitted to trigger off-chain processes such as user interface updates or to pro-
vide information that cannot be accessed from smart contracts but save gas costs in
contrast to state storage operations [5]. Events are not stored by contract but are part
of a Merkle tree holding all receipts of executed transactions within each Ethereum
block. Therefore, to retrieve past events, nodes need to iterate over all blocks from the
most current block to the block that holds the contract’s deployment transaction. To
increase efficiency, Ethereum utilizes Bloom filters to check if a block holds relevant
events [15].
2.5 Verifiable Off-Chain Computations
Blockchains suffer from scalability and privacy limitations since all network partic-
ipants must replicate and execute all transactions to verify their correctness. These
limitations are tackled by verifiable off-chain computations, which involve executing
functions on blockchain-external resources and verifying the execution’s correctness
on the blockchain [93]. Zero-knowledge proofs are an efficient and secure option to
implement this idea but are inherently complex in their programming abstraction and
application[94]. Theypermitprovingtheknowledgeofasolutiontoastatementwith-
out revealing the statement [95]. The process includes two entities: prover and veri-
fier. While the statement can be arbitrarily chosen, we focus on executing programs
to release blockchain participants from re-executing the program of interest. In this
2.5. Verifiable Off-Chain Computations 27
tx
trie
[nonce, balance, storageRoot, codeHash]
state
trie
rcpt
trie
0x23
0x42
0x0:
50x13
0x1:
8
0x22:
3
tx
trie
[nonce, balance, storageRoot, codeHash]
state
trie
rcpt
trie
0x23
0x84
0x0:
6
…
Figure 2.5: Each block in Ethereum holds three distinct Merkle trees
fortransactions,statesandreceipts. Accountsmaintaindiscretestorage
tries. The gray highlighted area of the Merkle tree represents the smart
contract’s current state.
case, the prover is a participant willing to execute a function, and the blockchain net-
work acts as a verifier checking the proof’s correctness. Note that the target program
does not have to be executed on-chain, but only the proof of correct program execu-
tion is submitted by the prover and validated by a smart contract. There are interac-
tive zero-knowledge proofs requiring a round-based challenge mechanism [96] and
non-interactive proofs based on the Fiat-Shamir heuristic [97]. We focus on the non-
interactive manifestation since they are particularly suited for on-chain proof valida-
tion [98].
In the following, we introduce an overview of different zero-knowledge schemes
which constitute candidates for implementing efficient verifiable off-chain compu-
tations. After that, we introduce frameworks based on respective schemes enabling
efficient development of off-chain programs and on-chain validation.
2.5.1 Zero-Knowledge Proof Schemes
Multiple types of non-interactive zero-knowledge schemes exist, most prominently,
zkSNARKs [99], Bulletproofs [100], and zkSTARKs [101]. While the first two concepts
are based on Elliptic-curve cryptography (ECC), the latter utilizes collision-resistant
hash functions. As a result of this, zkSTARKs are post-quantum resistant since they
do not rely on the Discrete Logarithm Problem (DLP) [101]. Since the approaches pro-
vide distinct properties concerning security and scalability, we present a comparative
overview in Table 2.1 and elaborate on them in the following.
28 Chapter 2. Background
Table 2.1: Comparison of zero-knowledge proof scheme attributes.
Scheme Proof
computation
Proof
size
Proof
validation
Quantum
secure
Trusted
setup
zkSNARKs[106] O(n) 1 O(1) No Yes
zkSTARKs[101] O(n)log(n)O(log(time(n))) Yes No
Bulletproofs[100] O(n)log(n)O(n)No No
Setup. Unlike zkSTARKs and Bulletproofs, zkSNARKs presuppose a trusted one-time
setup for generating a Common Reference String (CRS) which is required for the proof
generation and validation [102]. The process can either be executed by one trusted
party or as part of a Multi-Party Computation (MPC) within a group of mutually dis-
trustingpeers. TheMPC-basedapproachrelaxesthetrustassumptionto theexistence
of at least one honest participant [103].
Furthermore, universal setups have been proposed that enable reusing generated
keys for multiple programs [104]. Therefore, program-specific setups become su-
perfluous. On the downside, the generated CRS is more extensive than those pro-
duced by program-specific setups, rendering the approach infeasible for many ap-
plications [105]. Yet, novel schemes such as Marlin decrease the CRS size by orders of
magnitude [104].
Program definition. zkSNARKs and Bulletproofs operate on arithmetic circuits
or Rank-1-Constraint-Systems, while zkSTARKs utilize higher degree polynomi-
als [106, 107, 108]. Since their direct definition is difficult, Domain-Specific Lan-
guages (DSLs) have been proposed to enable programming similar to general purpose
languages (see Section 2.5.3). Defined programs are compiled to the target represen-
tation, which enables program execution.
Computation. The off-chain computation phase includes program execution and
proof creation. The execution result constitutes a witness for a given input, includ-
ing the program’s return value [106]. The input values can either be public or remain
secret. For instance, the input could be a pre-image, and the program could produce
a hash digest as program output, allowing a user to prove the knowledge of the pre-
image without revealing it. Since proofs do not reveal private data in zkSNARKs, such
input does not contribute to communication complexity [102]. In the case ofoff-chain
computations, privateinputsdothusnotincreasethecalldataofatransactionsubmit-
ting a proof. The three presented schemes exhibit a runtime complexity linear to the
number of gates for the proof generation. However, they exhibit different proof sizes.
zkSNARKs produce constant size proofs, for instance, 127 bytes for the ALT_BN128
curve implemented by the EVM [15, 108]. zkSTARKs generate proofs of logarithmic
size to the number gates in the program [101] and are relatively large in reference to
the blockchain domain, at about 200 KB for a typical program at only 60-bit secu-
rity [100]. In comparison, Bulletproofs exhibit a proof size that scales logarithmically
but at a lower scale. For instance, an equivalent program requires only one kilobyte for
twice the security compared to zkSTARKs [100].
Verification. The verifier, which in the case of off-chain computation is represented
by a smart contract, takes a cryptographic proof and checks it for correctness. Since
2.5. Verifiable Off-Chain Computations 29
the goal is relief in terms of transaction costs, which are defined by the amount of data
carried, computation complexity, and storage costs, these attributes, in particular, are
essential for evaluating the different schemes. Since the respective proof sizes con-
tributing to transaction costs have already been outlined as a result ofthe computation
phase, we compare the verification complexity in the following.
The verification complexity of zkSNARKs is constant and independentof the off-chain
program’s complexity [107]. Therefore, it is especially well suited for complex off-
chain computations, releasing the target ledger from computational effort. In addition
to the constant-size proof, only public inputs have to be submitted, contributing to
communication costs [108].
In contrast, the verification complexity of zkSTARKs-based proofs scales poly-log-
arithmically with the off-chain program’s computation time [101]. Therefore, it is
less suited for extensive computations but enables medium-sized programs. Since
the proof size is relatively large, the involved communication complexity results in
overhead excelling its benefits for small programs.
As the validation complexity of Bulletproofs scales linear to the program’s complex-
ity, the scheme is only suitable for small programs [100]. Compared to zkSTARKs, the
smaller proof size also results in limited communication overhead, lowering the con-
stant costs involved.
2.5.2 Hash Functions for Zero-Knowledge Proof Systems
While hash functions play an outstanding role in blockchain protocols, the execution
of classic cryptographic hash functions such as SHA-256 requires manyconstraints in
provable abstractions, as it is based on bit manipulations [105]. Therefore, novel hash
functions have been proposed utilizing the specifics of zero-knowledge proof systems
to decrease proof computation times. Since these hash functions are not nativelysup-
ported by the EVM, their execution is only efficient in off-chain programs but ineffi-
cient within smart contracts in Ethereum.
Pedersen hashes are based on Pedersen commitments [109] and have been proposed
as an enhancement to the Zcash protocol [110]. Bits are mapped onto an elliptic curve
and aggregated to create a fixed-length output. Since the algorithm is based on the
DLP, it is not quantum-resistant [111]. It requires an embedded curve to operate in
a zero-knowledge proof system. In the case of Ethereum, Pedersen hashes are exe-
cutable based on the Babyjubjub curve, which is embedded into the natively supported
ALT_BN128 curve [105]. The scheme is only collision-resistant for fixed input lengths.
Further, pseudorandomness cannot be assumed, and the hash should not be used as
a random oracle [112]. Since we intend to use hash functions in the context of block
header validation, these limitations do not pose an issue as the consensus protocol de-
fines the input, and randomness is not required.
Poseidon hashes execute permutations on the prime field using a sponge func-
tion[113]. Asaresult,theschemesupportsvariableinputlengths,pseudorandomness,
and quantum resistance. Multiple rounds of cryptographic permutations are executed
by applying substitution boxes to the previous layer’s output. Since the substitution
is computationally expensive, the algorithm alternates between applying substitution
30 Chapter 2. Background
ZoKrates
Program
Setup
Execution
Trace
Run
Program
Proving &
Verification Keys Verification
Contract
Proof
12 3
1
2 3
Figure 2.6: Two types of processes are differentiated in ZoKrates, the
one-time setup and repetitive program executions. The steps of the Zo-
Krates initialization process are numbered in circles, and the sequence
of off-chain computation steps is illustrated in diamond shapes.
boxes to the entire input and partial application, also known as Hades design [114]. As
a result, the number of constraints is minimized without compromising the crypto-
graphic properties of the function. Compared to Pedersen hashes, the authors claim a
reduction of constraints per message bit by order of eight. While more efficient than
Pedersen hashes, the algorithm has been proposed only recently and is currently un-
dergoing in-depth cryptographic analysis.
2.5.3 Zero-Knowledge Proof Frameworks
Since the direct implementation of arithmetic circuits or higher degree polynomials
for zero-knowledge proofs is difficult, DSLs have been developed to define programs
in a high-level language and compile them to the target format. Since our objective is
to utilize verifiable computations for enabling scalable off-chain calculations foster-
ingcross-chain information exchange, we presentzero-knowledge proof frameworks
targeting blockchain environments in this section. These frameworks not only sup-
port programming off-chain functions but also generate execution proofs and provide
on-chainverifiersthatprocess proofs. Due to the limited scalabilityofBulletproofver-
ification, we present the most prominent frameworks for zkSNARKs and zkSTARKs
development.
2.5.3.1 ZoKrates
ZoKrates provides a high-level programming language for off-chain computations
based on zkSNARKs and a set of tools for off-chain execution and on-chain verifi-
cation [102]. When specifying a ZoKrates program, the developer explicitly decides
which inputs should later become public or remain secret. Hiding inputs becomes
possible due to the employed proving scheme’s zero-knowledge property. Figure 2.6
shows ZoKrates’ two core processes, initialization, and off-chain computation.
2.5. Verifiable Off-Chain Computations 31
Cairo
Program
Execution
Trace
Run
Program Verifier
Proof
1 32 Run
Program
Off-chain Program Execution SHARP On-Chain
Figure 2.7: After performing the off-chain computation using the
Cairo framework, SHARP collects execution traces and generates a joint
proof verified on-chain.
Initialization. Before off-chain computations can be executed, the initialization pro-
cess must be completed. For a compiled ZoKrates program 1, an initial setup is per-
formed to generate a program-specific key pair, which consists of proving and verifi-
cation keys 2. In Step 3, a verification smart contractis derived from the verification
key, which is deployed to a blockchain.
Off-chain Computation. After the successful completion of the initialization, off-
chain computations can be run and verified: In the first Step 1, a compiled program
is executed for a given set of inputs, which generates an execution trace, also referred
to as witness. A proof attesting to the correct execution of the program for the given
set of inputs is generated in Step 2by combining the witness with the proving key
generated in the initialization process. This proof is then submitted to the blockchain
to verify the off-chain computation’s correctness by checking the proof in Step 3.
Due to the use of state-of-the-art zkSNARK schemes, this proof is of small constant
size. Its verification complexity is independent of the complexity of the off-chain pro-
gram and linear in the number of public inputs and outputs.
2.5.3.2 Cairo and SHARP
Cairo provides a Turing-complete programming framework for creating zkSTARKs-
provable programs [115]. Incontrastto ZoKrates, Cairo doesnot requirea trusted setup
due to the properties ofzkSTARKs. The framework provides a compiler and runner for
program execution butexcludes proof creation. Cairo programs are compiled and exe-
cuted locally (Step 1), while the proof generation is conducted remotely(Step 2). By
default, proofs are generated using an external service called Shared Prover (SHARP),
as illustrated in Figure 2.7. SHARP is a centralized service provided by StarkWare5,
which also develops the Cairo framework. Since the proof size of zkSTARKs is rela-
tively large, efficiency gains require a minimum of execution steps. Therefore, SHARP
collects execution traces ofmultiple sources and creates a proof attesting to the correct
execution of all respective programs. In Step 3, the proof validation result is stored in
a smart contract and becomes utilizable by other contracts operating on the identical
blockchain. Since SHARP is offered as a service, users must pay fees depending on the
size of the submitted execution trace.
5https://starkware.co/
32 Chapter 2. Background
Alternative to SHARP, the Winterfell6project provides zkSTARKs-based locally exe-
cutableverifiersand provers. Based on Winterfell, theGiza project permitsthe utiliza-
tion of Cairo execution traces for proving and verifying programs. As a result, all ex-
ecution steps become executable locally, and third-party dependencies are mitigated.
Yet, the provided verifier is not tailored to be executed in blockchain environments,
limiting its applicability to the intended use.
6https://github.com/novifinancial/winterfell
33
3 Related Work
This thesis proposes chain relay mechanisms enabling efficient state proofs across
blockchain networks. Based on these state proofs, methods for forking and synchro-
nizing smart contracts are presented. In order to contextualize the presented con-
cepts, we demonstrate similar works and how they differ in this section.
Multipleconceptsforenabling trustedstateaccessbetweenblockchainnetworksexist.
As indicated in Figure 3.1, these concepts depict the foundation of many cross-chain
applications. Therefore, we first provide an overview of these concepts in Section 3.1
and outline the limitations of current approaches.
Since our objective is to maintain the decentralization properties introduced byblock-
chain technologies and to provide flexibility in orchestrating distinct blockchain net-
works, we focus on efficient chain relays in Part II of this thesis. The exchange and
transfer of tokens are among the most prominent use cases of cross-chain technolo-
gies. In Section 3.2, we describe different forms of cross-chain token transfers, their
requirements, and how the concepts benefit from efficient state access across block-
chains, as provided by the chain relays introduced in this thesis. While the current
proposal of multi-chain tokens requires an application-specific notary scheme [116],
we argue that efficient relays can also act as enablers in future implementations.
Section 3.3 describes protocols enabling the interactions of smart contracts across
blockchains. Currently, two types of cross-chain smart contract interaction exist: di-
rectfunctioninvocationand smartcontractmoves. InPartIII of thisthesis, we propose
concepts for alleviating the dependency of smart contracts on the host blockchain.
First, smart contractforks enable the migration of smart contracts to other blockchain
networks, includinglogic andstate. Asa result, participantscan utilizethe best-suited
blockchain for a given use case. Second, smart contracts can be synchronized based
on smart contract forks to permit synchronous cross-chain read-only function exe-
cutions.
3.1 Trusted State Access Across Blockchains
Different kinds of cross-chain applications necessitate distinct forms of communica-
tionbetweenblockchains. Elaborateusecases,suchastokentransfersandcross-chain
function calls of smart contracts, require the replication of states between blockchain
networks. Since every blockchain state transition must be verifiable by all partici-
pants, retrieving external data constitutes a challenge. Solutions for enabling trusted
state access across blockchains are categorized into relay-based systems and ora-
cles [22]. Relays utilize the inherent verifiability of blockchains to create proofs about
34 Chapter 3. Related Work
Trusted State Access Across Blockchains
Cross-Chain Applications
Cross-
Chain
Function
Invocation
Smart
Contract
Moves Forks
Synchro-
nization
Wrapped
Tokens
Cross-Chain Smart Contract
Interaction
Atomic
Swaps
Multi-
Chain
Tokens
Relay Chains
and Sharding
Chain
Relays
Notary
Schemes
Direct State
Access
Figure 3.1: Classification ofcross-chain applications and their enablers
in a stack format. In this thesis, we focus on the grey-shaded research
topics.
the states and events of a third blockchain. We differentiate between two kinds of re-
lays: relay networks, which are presented in Section 3.1.1, and chain relays, described
in Section 3.1.2. Oracle systems have been proposed to provide a link to external data
sources [117]. Thus, they are not limited to external blockchain networks but can be
utilized to retrieve arbitrary data. In contrast to chain relays, oracles typically require
trusted third parties and exhibit limited verifiability [31]. Since notary schemes are
the most prominent oracle systems concerning cross-chain state access [118], related
concepts and implementations are introduced in Section 3.1.3.
3.1.1 Relay Chains and Sharding
As a result of the increasing use of blockchain networks, the question of scalability
has become increasingly important. Since finding consensus in a decentralized set-
ting requires replicated transaction execution, validation, and storage, classic block-
chain systems suffer from limited throughput, restrained storage capacity, and high
latency compared to centralized solutions [119]. The application of sharding has been
proposed to remedy these shortcomings by permitting parallel processing and dis-
crete persistence [120]. Sharding is a common technique for scaling databases in dis-
tributed deployments. The system state is partitioned into multiple subsets, and sep-
arate transactions are processed by discrete nodes [16]. Thus, the system scales hori-
zontally with the number of participants [121]. Many blockchain systems implement-
ing sharding require a coordination layer [49, 122, 123]. The coordination is conducted
by a dedicated blockchain relaying state roots or transactions between shards. In the
following, we introduce requirements for implementing shard-based blockchain ar-
chitectures.
Shard allocation. In decentralized settings, sharding solutions must ensure a fair and
random distribution of validators among shards to mitigate the assignment of adver-
sary majorities to a single shard [124]. Therefore, most blockchain systems imple-
menting sharding comprise a central blockchain that is responsible for the orches-
tration of shards. Typically, these so-called hubs or relay chains do not perform clas-
sic transaction validation but are only in charge of allocating validators to a specific
3.1. Trusted State Access Across Blockchains 35
shard and providing a trust anchor between connected shards [118]. Since it should be
impossible for a minority of participants to manipulate the allocation of validators, a
source of randomness is required in a permissionless setting. Algorithms like Verifi-
able Random Functions (VRFs) enable participating nodes to prove correct computa-
tion based on a secret without revealing the secret [125, 126]. For instance, Polkadot’s
validator allocation algorithm requires participants to create an output based on ran-
domness generated (and finalized) in the past, the target slot, and a user-specific se-
cret. Ifthe outputfalls belowa given threshold, the entityis qualified toproposea block
in the respective slot. As a result, shard validators are regularly shuffled. In the case of
Polkadot, validators are allocated after every slot [122], while Ethereum’s novel con-
sensuslayermaintainsshard-specificvalidatorsetsforepochsof32slots[127]. Incon-
trast, Cosmos maintainsseparate validator setsand decoupled consensus mechanisms
for each shard [118]. After being assigned to one shard, nodes only process transac-
tions modifying the respective shard’s state and find consensus within the group of
shard validators.
Sharding presumes the connection of multiple blockchains by design, creating a
strong binding. While allowing efficient communication within the network, the
number of connected blockchains is limited. Therefore, mechanisms are needed to
decide which application-specific shards are included in the network. For instance,
Polkadot promotes the temporary attachment of application-specific shards through
auctions [122]. In contrast, the chain relay mechanisms presented in Part II of this
thesis enable the ad-hoc implementation of secure communication between indepen-
dent blockchains. No waiting times for slot allocations or economic preconditions are
required to enable cross-chain communication. The execution costs only need to be
justified by the target application.
Consistency. Due to the separation of states, transactions, and smart contracts, state
transitions across multiple shards constitute a challenge. Relay networks create a
strong binding between shards because they produce a commitment to the history
of all linked shards. In permissionless settings, a central relay chain typically stores
the state roots of connected shards and makes them available for processing cross-
chain transactions [124]. The strong binding of shards enables the timely handling of
cross-chain messages, as a message anchored in the relay chain can be treated as fi-
nalized. For instance, Polkadot implements a shared security model where all shards
inherit the security from the relay chain and all shards revert if reorganizations oc-
cur [122]. As a result, there can be no inconsistencies between connected shards. Cos-
mos provides a more loosely coupled link with every connected shard implementing
its own security model [123]. Therefore, a failing shard may result in inconsistencies
if other shards incorporate a reverted state. Communication across shards is typically
asynchronous, and deployed applications must consider delays derived from message
queuing. Multiple protocols have been proposed to implement cross-shard and cross-
chain communication, as depicted in Section 3.3.
Since shard systems have a shared state root, the smart contract synchronization
methods presented in Chapter 7 of this work are also applicable for enabling syn-
chronous function invocations of smart contracts that have initially been deployed to
a foreign shard.
36 Chapter 3. Related Work
A
F
C
D
B
EG
J
I
H
Figure 3.2: Shards may be connected to multiple neighboring
shards [128]. Information is only exchanged between neighboring
shards. Every shard can be reached by applying multiple hops. Here,
a message is sent from A to D via E.
Data availability. Since shard data is isolated and validators maybe shuffled regularly,
amechanismfor ensuringdataavailabilityis required. Becauseonlya subsetofvalida-
tors maintains a shard’s state, the risk of failing data replication is eminent compared
to anon-sharded solution. To reducethis risk, the utilizationoferasure codes hasbeen
proposed and is used by sharding implementations such as Polkadot and Near [122,
128]. Data availability is also required for retrieving incoming cross-chain messages.
One common approach to guarantee availability is the validation of multiple neigh-
boring shards by a set of validators [129]. For instance, Figure 3.2 depicts a network of
ten shards, where every shard is connected to four others. Thus, validators must only
be aware of directlyconnected shards while enabling network-wide cross-chain mes-
saging. In the given example, at most one hop is needed to send messages to any other
shard. Sending a message from shard A to D would require shard E to act as a proxy
since the corresponding validators know all three involved shards. Another method
is implemented by Polkadot’s Cross-Chain Messaging Protocol (XCMP) that requires
everyshard’s outbox to be signed bythe respective validators [122]. State root and out-
box are stored on the relay chain and are thus retrievable by every other shard. Both
approaches facilitate cross-shard state access, enabling smart contract portability, as
outlined in Part III of this thesis.
Permissioned networks. Shards are also referred to as channels in the contextof per-
missioned blockchain networks and follow different assumptions [121]. Since chan-
nels typically support consortia in processing data collectively, the primary purpose
is not scalability but data privacy. Participants would like to share sensitive data only
with authorized partners and protect it from outside observation. Yet, interoperabil-
ity between channels is possible if the respective validator sets intersect. For example,
Hyperledger Fabric seals blocks with a predefined endorsement policy, e.g., N-out-
of-M validators must sign a block. Data can be exchanged and endorsed if enough
validators participate in cooperating channels. Since a sub-set of validators act as no-
taries between channels, the concept overlaps with notary schemes, as presented in
Section 3.1.3.
3.1. Trusted State Access Across Blockchains 37
3.1.2 Chain Relays
Chain relays reflect the consensus mechanism of a primary blockchain on a secondary
blockchain [130]. Thus, they mimic light client validation of a remote blockchain to
enable cross-chain information exchange. Block headers of a primary blockchain are
submitted, validated, and stored on a secondary blockchain if the validation is suc-
cessful according to the primary blockchain’s consensus rules. In the case of PoW, a
block header is deemed to be part of the primary main chain (i.e., to be final) after n
headers have been validated subsequently, as it would become economically infeasi-
ble to mine ninvalid blocks. The parameter ndepends on the primary blockchain’s
economic incentive mechanism and the desired level of security. While PoW-based
blockchains typically do not guarantee finality, choosing a high value for parameter n
also reduces the riskofincorporating forks, as thelikelihood ofminers producing valid
blocks based on a fork decreases with every block added to the leading chain [13]. Once
a block header is deemed final by the relay, it can be utilized to prove the inclusion of
transactions, states, or events within the primary blockchain on the secondary block-
chain. As block headers comprise corresponding Merkle roots, SPVs can be utilized
for submitting inclusion proofs without requiring trusted intermediaries [13]. While
many chain relays exist [88, 131, 132, 133], we present a brief overview of five promi-
nent chain relay techniques. BTC Relay was the first chain relay in production. ETH
Relay proposes an optimistic approach for Ethereum’s consensus algorithm Ethash.
Dogeethereum introduces zero-knowledge Bulletproofs to decrease on-chain valida-
tion complexity. NIPoPoWs exhibit sublinear validation costs by using non-interactive
proofs. Finally, PoS sidechains enable relays for PoW-inspired PoS blockchains.
3.1.2.1 BTC Relay
BTC Relay was the first chain relay to be deployed in a live setting in April 2016 and
enables the submission ofBitcoin headers to Ethereum to prove the inclusion of trans-
actions [35]. In order to enable a one-way peg from Bitcoin to Ethereum, participants
upload Bitcoin block headers to a smart contract that validates compliance with Bit-
coin’s consensus rules [35]. Therefore, the submitted block header is only accepted
and stored within the contractif it references a block header that has been successfully
submitted before. BTC Relay utilizes an incentive mechanism to compensate partici-
pants’ gas costs for submitting block headers. Every block header of the source block-
chain must be submitted for relay to remain live. Therefore, even if no cross-chain
transactionis included inblock headers, theyarerequired tomaintain the hashchain’s
verifiability. However, submittingthese intermediary headers impliesa highoverhead
that needs to be compensated adequately. As a result, BTC Relay has stalled for more
than 60 months since the last block was submitted at the time of writing.1Catching
up to the head of the Bitcoin blockchain would require more than 238,000 transactions
accounting for about 194,000 gas each,2a burden economically rational participants
are not willing to take.
1Date: March 8, 2023. BTC Relay contract address: 0x41f274c0023f83391DE4e0733C609DF5a124c3d4
2Exemplary transaction of a Bitcoin header submission in BTC relay:
0xaef2a2467279f2feed086f74d1fb8502c3b135776aae3e1c139181e85f6054e3
38 Chapter 3. Related Work
In contrast, the chain relay concepts presented in this thesis permit migrating only a
subsetofblock headers to maintain live without compromising on the level ofsecurity.
As a result, the execution costs are reduced by orders of magnitude, and the risk of
stalling is minimized.
3.1.2.2 ETH Relay
ETH Relay constitutes a chain relay that links Ethereum 1.0 with any blockchain sup-
porting the EVM [85]. Ethereum 1.0 applies a memory-hard PoWalgorithm to prevent
centralization tendencies that originate from the use of customized hardware, so-
called ASICs [15]. The objective is to motivate a more extensive set of miners to partic-
ipate, as consumer hardware can be used efficiently. On-chain validation of Ethash is
complexas itmustinclude proofthatcorrectmemoryoperationshavebeenconducted.
As on-chain validation of memory-hard algorithms is difficult, ETH Relay follows an
optimistic approach and accepts block headers without verification. Submitted head-
ers are blocked for a contesting period during which observers can challenge them.
When a challenge is presented, the submitted block header is validated on-chain, and
the submitter is slashed if fraudulent behavior is detected. The optimistic approach
taken by ETH Relay potentially decreases operational costs significantly, as costly val-
idation is only conducted in the case of misbehavior. Therefore, while targeting PoW
consensus algorithms in its current proposal, its general concept applies to PoS chain
relays as well. Yet, as the concept depends on intermediaries observing and validating
submitted blocks, it requires sufficient incentivization to ensure correct behavior. As
a result, trust in transferred block headers is limited compared to full validation.
Thechainrelayspresentedin thisthesisperformlightclientvalidationandbatching of
block headers to provide trustless and efficient cross-chain state access. Therefore, no
economicpreconditionsarerequiredtoguaranteesecurecross-chainstateaccess. The
complexvalidationofblockheadersisperformedbyoff-chaincomputationsandprov-
ing the correct program execution. Using ETH Relay, validating a single block header
accounts for 284,041 gas if all actors act honestly and 3,369,653gas in the worst case.
The off-chain validation proposed in this thesis calls for 556,724gas independent for
anybatchsize. Thus, thevalidationcostsperblockdecreaseasthebatchsizeincreases,
and efficient execution does not depend on predominantly honest behavior.
3.1.2.3 Dogethereum
In contrast to Bitcoin, the Dogecoin blockchain does not rely on SHA-256 for creat-
ing PoW [13], but on the memory-hard Scrypt algorithm to prevent the utilization
of ASICs [75]. As executing Scrypt within a smart contract is infeasible, Teutsch et
al. [134] have proposed Dogethereum, which enables off-chain validation of Doge-
coin’s PoW using Bulletproofs.
While the implemented mechanism facilitates batching multiple blocks for valida-
tion, the proofsize ofbulletproofsscales logarithmically, and thevalidation complexity
scales linearly with the computation’s complexity [100] (cf. Section 2.5), resulting in
high validation costs for large batch sizes. Therefore, instead of verifying the proof
3.1. Trusted State Access Across Blockchains 39
on-chain, Truebit [135] is used to minimize verification costs. Truebit permits adver-
tising off-chain computations that participants conduct to retrieve bounties. Chal-
lengers are incentivized to find incorrect submissions and claim them on-chain. The
disputed section of the computation is then validated on-chain, and the honest entity
earns an escrowed reward. Therefore, Truebit requires depositing a sufficient amount
of collateral to incentivize participants. The correct execution requires constant mon-
itoring of multiple distinct entities. While Dogethereum also proposes a mechanism
of locking and unlocking assets to exchange them between ledgers, we refer to [134]
for further reading, as it exceeds the focus of this work.
In comparison, the use of zkSNARKs and zkSTARKs, as proposed in this thesis, en-
ables the efficient on-chain validation of off-chain execution proofs without requiring
collateralization. This results from their improved scalability and smaller proof size.
3.1.2.4 NIPoPoWs
Kiayias and Zindros [136] have proposed a sidechaining mechanism that is based on
NIPoPoWs [90]. NIPoPoWs permit constructing succinct proofs about predicates—or
events—from regular blockchains. The proof size scales polylogarithmically to the
number of blocks that have been mined at the time the event occurred [90]. How-
ever, the source blockchain must support NIPoPoWs. If NIPoPoWs are not supported
natively, they can be added to a ledger through a velvet fork [137]. Thus, miners do not
have to be aware of the fork, and NIPoPoWs are implementable retrospectively. How-
ever, the source blockchain must support the proof mechanism. Kiayias et al. have
shown that velvet forks introduce new attack vectors, reducing the concept’s security
if no additional countermeasures are implemented [138]. Furthermore, NIPoPoWs ex-
pectconstantPoWdifficultyandarethereforenotapplicabletoblockchainslikeBitcoin
that adjust the difficulty to achieve relatively constant block mining rates [84].
The chain relays presented in this thesis do not require any modifications to the source
blockchain protocol. Therefore, they do not need additional precautions to secure vel-
vet forks. In addition, the introduced concepts can handle difficulty adjustments and
apply to a wide range of consensus protocols.
3.1.2.5 PoS Sidechains
Gaži et al. have proposed a sidechain mechanism for PoS-based blockchains that op-
erates on explicitly signed cross-chain transactions [88]. A subset ofthe source block-
chain’s validator set is sampled to create certificates that notarize cross-chain trans-
actions. The solution is tailored to cater to Nakamoto-inspired PoS blockchains such
as Cardano.
Thus, compared to the PoS relay we propose in Chapter 5, different assumptions are
applied concerning finality and verifiability. Furthermore, while generalizable, the
concept presented by Gaži et al. enables the specific use case of transferring tokens.
In contrast, our proposed PoS chain relay applies the source blockchain’s consensus
to maintain the source blockchain’s security properties and enables the inclusion of
proofs of arbitrary data.
40 Chapter 3. Related Work
3.1.3 Notary Schemes
The notary scheme is one of the most used techniques for achieving interoperabil-
ity between distinct blockchain networks. It relies on intermediary entities retrieving
data from a source blockchain, signing the given data, and writing it to a target block-
chain [139]. Because the protocol only requires signature validation, it is independent
of the source blockchain’s consensus algorithm, involves fewer validation costs, and
can provide more timely data than chain relays. Many variants exist, the simplest be-
ing a single trusted entity acting as a notary. The process may also be distributed to
multiple entities to mitigate a single point of failure and spread the risk of misbehav-
ing actors. Before relayed information is trusted, a minimum of signatures must be
collected, for instance, byusing a multi-signature wallet or threshold signatures [140,
141]. Similar to other cross-chain technologies, applications must decide under what
conditions the data can be trusted and utilized after data has been transmitted. For in-
stance, Blockstream’s Liquid protocol enables a Bitcoin sidechain using an N-out-of-
M signature scheme operated by a preset federation [142]. Bridges such as Harmony’s
Horizon Bridge3or Ronin Bridge4enable cross-chain asset transfers. External valida-
tors retrieve locking events emitted on a source chain by a dedicated smart contract
and sign the transfer operations to unlock representations of the locked tokens on a
target blockchain.
The deposit of collateral has been proposed to incentivize honest behavior in permis-
sionless notary networks [117]. Oracle implementations such as Astrea [32] or Chain-
Link [143] permit arbitrary participants to join the network by depositing some col-
lateral. As soon as a user detects misconduct, it can be reported to and reviewed by
all participants. If the misconduct is confirmed, a portion of the deposited collateral is
taken from the perpetrator and credited to the reporting entity. Blockchain protocols
that consider interoperability may utilize validators’ deposits for multiple purposes.
For instance, the Polygon network executes a bridge5to the Ethereum network and
applies stake for PoS validation and cross-chain notarization. As an alternative to de-
positing collateral, TEEs are also used to map external data in a tamper-proof man-
ner [33]. Even though oracle networks can create a gateway to arbitrary external data
sources,enablinginteroperabilitybetweenblockchainnetworksisacommonusecase.
While notary schemes provide timely data exchange and low execution costs, their
security is limited by the participants’ correct behavior. In the recent past, attackers
exploited multiple instances like the Harmony Bridge and Ronin Bridge. In the case of
the Ronin Bridge, five out ofnine signatures were required for executing a cross-chain
asset transfer. Since a single organization held four keys and another delegating their
voting rightsto thefirst, onlya single organization’s ITsystemhad to becompromised
to retrieve the required private keys that were used to sign fraudulent transactions and
captureabout600 millionUSD worthoftokens[34]. Theexampleshowsthatthesmall
number of nodes in charge and the vulnerability of host systems pose a significant
securityrisk to notaryschemes. In contrast, chain relays execute full validation on the
target blockchain and do thus not suffer from this risk at the cost of higher execution
overhead in current implementations.
3https://bridge.harmony.one
4https://bridge.roninchain.com/
5https://docs.polygon.technology/docs/category/pos-bridge
3.2. Transfer and Exchange of Tokens 41
Since notary schemes can transfer arbitrary data between blockchain networks, they
can also be used for providing storage roots that are required for cross-chain smart
contract portability. Therefore, they are enablers for the interoperabilityschemes pre-
sented in Part III of this work. Yet, due to their shortcomings concerning security, we
focus on efficient chain relays to provide a trustless alternative while pushing valida-
tion costs toward those of notary schemes.
3.2 Transfer and Exchange of Tokens
The independence of blockchain networks from each other leads to the isolation of
hosted applications. This also applies to a primary use case: token management. Mul-
tiple dedicated cross-chain solutions have been proposed to alleviate the restrictions
stemming from vendor lock-ins [144]. We differentiate between three kinds of cross-
chain token concepts; those enabling the exchange of tokens between users without
the token leaving the blockchain network, those creating a token representation on
another blockchain, and those promoting a synchronized token model on multiple
blockchains.
3.2.1 Atomic Swaps
One ofthe most prominentuse cases for blockchain interoperability is the exchange of
tokens between two (or more) participants [145]. Here, both participants have access
to both blockchains, and their tokens are stored on one of these, respectively. After
they agree to exchange the tokens at a set exchange rate, they perform a commit-
reveal scheme that enables the exchange to be executed atomically [146]. Thus, either
the exchange is executed entirely or it is reverted. As the information required to ex-
ecute the scheme is retrieved by observing the blockchain holding the counterpart’s
assets, data exchange between the blockchain networks is not required. In practice,
users do not have to execute the steps for performing atomic swaps manually but can
utilize elaborate wallet implementations such as the Liquality Wallet6.
Figure 3.3 exemplifies the execution of an atomic swap between two participants, Alice
and Bob, where Alice holds tokens on blockchain Xand Bob has tokens on blockchain
Y. In the given example, Alice and Bob agree to exchange token Aon Xin return for
token Bon Y. To initiate the trade, Alice first generates a secret Sand uses its hash
H(S)to lock Ain a Hash-Time Lock Contract (HTLC). HTLCs describe scripts that
enable unlocking tokens either by supplying the preimage of a hash digest or after a
given time. A variant of atomic swaps does not require scripts but relies on signatures
and time-lock puzzles [147]. The locked funds can either be retrieved by Bob after
learning Sor by Alice after a predefined amount of time has elapsed. As a result, Alice
assures that Bob cannot exit the exchange and leave Alice’s assets locked. Second, Bob
observes the transaction, learns H(S), and locks B, which Alice can unlock using S.
Otherwise, Bob unlocks Bafter a predefined amount of time to avoid Alice locking
his funds by exiting from the trade. Third, Alice uses Sto retrieve Band effectively
reveals it to Bob, who can use it for retrieving Ain Step 4, as agreed. Thus, the trade is
6https://liquality.io/
42 Chapter 3. Related Work
Generate
secret S
Lock A Bob observes
transaction
Lock B
Alice observes
transaction
Claim B using S
Bob learns S
Bob learns S
Claim A using S
2
3
4
1
Alice Bob
Blockchain X Blockchain Y
Figure 3.3: Atomic swaps require locking tokens in an HTLC using a
secret. Claiming token B on blockchain Y involves revealing the secret
allowing the transaction partner to claim token A on blockchain X.
executed entirely, both parties receive their exchanged tokens, and no intermediaries
are required.
A caveat of atomic swaps is that both parties must be online to perform the trade, and
suitable time frames must be configured to ensure secure exchanges. In addition, par-
ticipants may utilize involved time delays to gain benefits from changing exchange
rates. As a result, the trade could only be executed if beneficial and aborted otherwise.
More elaborate schemes seek to remedy such shortcomings by implementing sanc-
tions for prematurely exiting trades [148, 149].
3.2.2 Wrapped Tokens
Wrapped tokens are a representation of tokens that are exchangeable 1-to-1 with the
original instance. They permit using the token in a context that does not apply to the
original instance. For example, the first wrapped token minted was wETH, which rep-
resents Ethereum’s native currency, ETH, but complies with the ERC-20 standard for
fungible tokens [27]. As a result, it can be used and exchanged using smart contracts
supporting ERC-20 tokens but loses its function as a native currency in its wrapped
form. Therefore, it cannot be used for paying gas fees.
While wETH is minted and used on the identical blockchain as its original instance,
wrapped tokens are often used to enable the utilization of tokens on distinct block-
chains. To mint a wrapped token, the original instance is transferred to a custodian
that locks the token until it is proven that its wrapped version has been destroyed.
There are centralized custodians as well as decentralized protocols.
3.2. Transfer and Exchange of Tokens 43
Lock A
Burn AY
Get state of Blockchain X
Write state of
Blockchain X
Mint AY (transaction proof)
Get state of
Blockchain Y
Write state of Blockchain Y
Claim A
(TX proof)
Alice Relayer
Blockchain X Blockchain Y
2
3
4
5
1
6
Figure 3.4: Transferringtokensbetweenblockchainnetworksincludes
locking it on one blockchain and proving the locking operation on an-
other blockchain.
Centralized approaches such as wBTC7or renBTC8presume a single entity or a pre-
set group to treasure retrieved tokens. As illustrated in Figure 3.4 (Step 1), any user
intending to mint a wrapped token can send the native version to a custodian wal-
let, which can be a smart contract, a user wallet, or a multi-signature wallet. To mint
a wrapped token on a secondary blockchain, the custodian notarizes having retrieved
the original token (Steps 2–3). Therefore, the concept shares similarities with the no-
taryschemedescribed inSection 3.1.3. After the wrapped token has been minted, itcan
be used and traded like anyother token on the destination blockchain. Redeeming the
original token requires the destruction—also referred to as burning—of the wrapped
version (Step 4). After the burn event is proven on the primary blockchain, it can be
claimed using a wallet address that was declared during the burn operation (Steps 5–
6). Therefore, the entity that redeems the token does not necessarily have to be the
same entity that initially locked it.
Decentralized wrapped token protocols rely on cryptographic proofs of locking and
unlocking events, for instance, by using chain relays. If both blockchains provide
smart contract functionality, the required proofs are executable on-chain and do not
require external involvement. Other blockchains, like Bitcoin, require third-party
custodians. For example, Zamyatin et al. proposed the implementation of vaults that
any participant can join to create a decentralized custodian service [150]. To join a
7https://wbtc.network/
8https://bridge.renproject.io
44 Chapter 3. Related Work
vault, participants must deposit collateral that is confiscated if misbehavior is dis-
closed. A chain relay enables proving misconduct like failing to reimburse the original
token after its wrapped version has been destroyed. Therefore, the concept heavilyre-
lies on efficient chain relays and will benefit from this thesis’ contributions presented
in Part II. In practice, the method is used by the Interlay9project to create a bridge
between Bitcoin and Polkadot’s Kusama network.
3.2.3 Multi-Chain Tokens
Borkowski et al. have proposed a concept for tokens that are held on multiple block-
chains simultaneously [116]. The state is synchronized between all affected block-
chains by external observers—so-called contestants—who compete for rewards over-
compensating involved execution costs. The concept is permissionless and requires
the participation of the sender and receiver of tokens and any observer propagating
transactions. The authors argue that no full-state synchronization between block-
chain networks was possible due to the storage overhead of validating external block-
chains. Therefore, the concept applies economic incentives for correct behavior rather
than state proofs. Yet, since the election of contestants solely depends on their signa-
tures, it needs to be evident how inconsistencies are prevented. As it is economically
rational to submit a bid just before bidding finishes to prevent revealing information
to competitors, it is to be expected that all transactions are submitted as late as pos-
sible. Because transactions may be delayed or due to an attacker’s attempt, the set of
participating contestants may differ between blockchains, resulting in inconsistent
states.
In the remainder of this thesis, we argue that efficient cross-chain state synchroniza-
tion is possible by applying novel techniques such as provable off-chain computations
(see Section 2.5) or blockchain finality (see Section 2.2.3). Using an efficient chain re-
lay, proofs of no-spent could be used following a two-phase commitprotocol for prov-
ably secure multi-chains in the future.
3.3 Cross-Chain Smart Contract Interaction
Mostcross-chainprotocolstargettheexchangeortransferoftokensacrossblockchain
networks [88, 116, 145, 146, 150]. Yet, multiple forms of cross-chain interoperability
exist that generalize smart contract interactions and loosen the strong binding be-
tween the contract and host blockchain. In the following, we first introduce concepts
forcross-blockchain smartcontractfunctioncalls. Theconceptofsmart contractsyn-
chronization presented in Chapter 7 of this thesis complements these techniques with
a synchronous read-only approach for timely state access. Then, we depictsmart con-
tract moves which is an alternative concept to the smart contract forks presented in
Chapter 6.
9https://interlay.io/
3.3. Cross-Chain Smart Contract Interaction 45
3.3.1 Function Invocation
The objective of cross-chain smart contract invocations is to call functions ofremotely
hosted smart contracts and retrieving the return value. As a result, the isolation of
smart contracts toward their host blockchain is alleviated. Since cross-chain calls
must guarantee function execution in correct order and typically presume atomicity,
coordination is required. In the following, we present three different types of cross-
chain smart contract invocation schemes.
3.3.1.1 Orchestration Blockchain
Orchestration blockchains constitute central hubs connecting multiple blockchain
networks to coordinate the execution of cross-chain function calls. The concept was
first introduced by Liu et al. and coined HyperService [28]. The approach includes
a DSL that generates decentralized applications utilizing multiple interacting smart
contracts deployed to separate blockchain networks. A state model is created to track
the global application state on a dedicated blockchain for cross-chain communication.
Thus, a hub blockchain orchestrates cross-chain smart contract interaction.
With General Message Passing (GMP), the Axelar network provides a protocol for
cross-chain function calls between blockchains connected to a hub [151]. The imple-
mentationsupports callingfunctions ofEVM-basedcontracts. Everyconnectedblock-
chain maintains a gateway contract receiving cross-chain function calls. When the
gateway contract is called, the sender pays fees using the source blockchain’s native
token. Validators collect requested function calls and convert the paid asset to the tar-
get blockchain’s native token for compensating transaction fees.
While enabling a wide range of smart contract interactions, orchestration blockchains
do not permit querying smart contracts instantly, which is enabled by the smart con-
tract synchronization concept presented in Chapter 7 of this thesis. Every function
call requires multiple transactions on multiple blockchains. In addition, the block-
chain hub creates overhead and may create a bottleneck if many blockchain networks
and respective applicationsareattached. Further, the hub blockchain must supportthe
source and target blockchains of interest, while the chain relaymechanisms presented
in Part II of this thesis allow establishing connections on demand.
3.3.1.2 Delegated Function Invocation
Insteadofrelying on acentral hub, multiple relayersmayactas intermediaries toproxy
function calls between distinct blockchain networks. Nissl et al. have proposed a con-
cept that enables cross-chain function calls but does not implement an abstraction
layer and does not require a mediating blockchain to orchestrate interaction [29]. In-
stead, smart contract invocations are executed by intermediaries and checked by val-
idators who finalize transactions. Intermediaries bid on the right to execute cross-
chain function calls to receive a reward, overcompensating execution costs on the
target blockchain. A similar process is implemented for validators. If misbehavior is
observed, deposited funds are reduced. While the concept permits cross-chain func-
tion calls, multiple contract invocations and waiting times are required. Furthermore,
46 Chapter 3. Related Work
the approach is only secure under economic assumptions. Chainbridge10 constitutes a
similar protocol but relies on a trusted federation rather than economic safeguarding.
With General Purpose Atomic Crosschain Transactions (GPACT), Robinson and Ra-
mesh have proposed a protocol for cross-chain function calls that is agnostic to the
applied communication technique [30]. Thus, the verification of emitted events may
depend on external signers of events or block headers, an intermediary blockchain, or
chain relays. Before actual function invocation, the execution is simulated of-chain,
and a call graph including expected return values is returned. Initiating the cross-
chain function call involves the registration on the first affected blockchain, includ-
ing the call graph. After that, the functions are called sequentially, and it is verified
whether the preceding transactions terminated successfully. Function calls are only
deemed successful if the returned value is equivalent to the expected value retrieved
during the simulation. All functions altering the state lock the contract until the en-
tire call graph has been executed and state updates are applied atomically. Since the
approach is based on emitted events, even queries that do not modify the contract
state require function invocations, resulting in increased latency and execution costs
compared to concepts using SPVs. Furthermore, return values must match a pre-
computed simulation which may be impossible for use cases relying on volatile data
such as price oracles.
In comparison, the concept of smart contract synchronization presented in Chapter 7
enables reproducing smart contract states to multiple blockchain networks. As a re-
sult, no auxiliary transactions are required, and instant queries are enabled to retrieve
timelystate information. In addition, no off-chainpre-computation ofexecution trees
is needed, and frequently changing states become available.
3.3.1.3 Message-based
Instead of intermediaries invoking smart contract functions directly, message-based
protocols mediate using outgoing and incoming message queues. Smart contracts
sending cross-chain messages must prepare outgoing and process incoming mes-
sages. A message could, for example, include a notification that a token has been
locked and cause a receiving token contract to issue a wrapped representation.
The XCMP enables sending messages between shards in the Polkadot ecosystem [78,
152]. To send cross-shard messages, a smart contract emits a message that is stored in
its host shard’s outgoing queue. The validators of Polkadot’s relay chain, which acts as
a centralhub, are responsible fordistributingmessagesto theincomingqueues of des-
tination shards. Thus, the incoming message can be processed with the delayof a sin-
gle relaychain block. After the process is finished, it is registered in the relaychain. As
a result, the protocol enables very timely processing of cross-chain messaging, even
though asynchronous. Therefore, smart contracts hosted on another shard cannotin-
teract synchronously, but require multiple invocations to process the message reply. In
addition, XCMP is only applicable to sharded blockchain networks relying on a shared
trust model and is not transferable to a heterogeneous setting.
10https://chainbridge.chainsafe.io/
3.3. Cross-Chain Smart Contract Interaction 47
In contrast, the Interblockchain Communication (IBC) protocol enables sending mes-
sages between heterogeneous blockchain networks [153]. Therefore, message broad-
casting is not limited to sharded blockchain networks organized in a hub-and-spoke
fashion but applicable to any pair of networks allowing the implementation of relays.
Messages are mediated by relayers who prove the correct settlement based on chain
relays. Therefore, bidirectional chain relays are required to enable communication
between two blockchain networks, and security guarantees are bound to the respec-
tive host blockchain network. The protocol defines interfaces for implementing chain
relays—also called clients—and is agnostic to applied consensus algorithms as long as
eventual finality is provided. Thus, efficient chain relays, as presented in Part II ofthis
thesis, constitute enablers for the IBC protocol. Connections are established between
blockchains to guarantee messages’ correct ordering and prevent the re-execution of
respectivemessagequeues. Smartcontractscommunicateviachannelsthatdefinethe
semanticsofapplication-specificcommunication, e.g. ifmessage orderingis required.
A connection can serve an arbitrary number of channels. If no direct connection ex-
ists, a route via intermediary blockchains can be established to deliver messages. Due
to the abstraction of interfaces, the IBC protocol can cater to various blockchain im-
plementations. While it has been initiallyproposed for communication via the Cosmos
relay chain, the Hyperledger YUI11 project implements the protocol for a diverse set of
blockchains, namely Hyperledger Fabric, Hyperledger Besu, and Corda.
Similar to IBC, the Layer Zero protocol permits transferring messages between het-
erogeneous networks [154]. Cross-chain messages are collected, and their existence
is proven on the receiving blockchain using Merkle proofs based on previously relayed
block headers. Yet, the protocol suggests using oracle networks like Chainlink instead
of chain relays to provide block headers in a cost-efficient fashion.
Since message-based protocols implement outgoing and incoming message queues,
theyincur overhead for sending initial messages, processingincoming messages, cre-
ating replymessages, and retrieving the result. The requirement for creating multiple
transactions drives execution costs and delays. In comparison, synchronizing smart
contracts as proposed in Chapter 7 permits instant on-chain access. Therefore, smart
contract functions can directly access the state of remotely hosted smart contracts
without requiring supplementary transactions.
3.3.2 Smart Contract Moves
There is a strong dependency between smart contracts and the host blockchain. After
the concept of smart contract forks presented in this thesis has been published [3],
Fynn et al. proposed a mechanism for moving smart contracts between blockchains
to alleviate such dependencies [26]. If the host blockchain suffers from decreasing
security, high transaction load resulting in increasing execution costs, or if better-
suited blockchain implementations are established, smart contracts are suspended
and moved to another blockchain instance. Movable contracts must declare an autho-
rized owner to initialize move operations. Moving a contract locks the contract state
on the source blockchain and indicates to which blockchain the contract is migrated.
The concept presumes the availability of a trusted state root, as provided by a chain
11https://labs.hyperledger.org/labs/yui.html
48 Chapter 3. Related Work
relay. The state root is used to prove the correct migration of the contract state. Af-
ter the migration is finished, the relayer submits a Merkle proof that, after validation,
unlocks the smart contract on the target blockchain. The authors propose dedicated
instructions to the virtual machine to facilitate preconditional locking and unlocking
of migrated contracts. Beneficial to users is the decreased risk of dispersion across
multiple instances. Since onlyauthorized entities can move contracts, users must ad-
here to the move decision. Thus, a strong dependency on the contract owner exists.
Smart contract moves suspend the primary contract before enabling the secondary
instance. In contrast, smart contract forks, presented in Chapter 6, result in two or
more contractinstances existing in parallel. Furthermore, smart contract forks do not
require modifications to the source blockchain protocol, while smart contract moves
presume the virtual machine to support dedicated locking operations.
49
Part II
Scalable Chain Relays
51
The increasing utilization of blockchain networks has entailed novel implementations
fostering high throughput and advanced scalability. Emerging consensus algorithms
such as PoS mitigate the inherent immense power consumption of PoW-based net-
works. However, with a growing number of blockchain networks, the resulting frag-
mentation constitutes a pressing challenge. This is especially the case since the infor-
mationstoredonblockchainsexistsin isolation. Theresulting networkeffects leadto a
clustering of users in a few blockchain networks, potentially hindering the adaptation
of new, innovative blockchain technologies.
While multiple approaches have been presented in the literature to enable cross-
blockchain communication, their application requires trusted intermediaries or pro-
vides limited scalability. As of today, notary schemes are widely used, especially for
enabling the creation of wrapped tokens that become usable on foreign blockchain
networks [117]. However, recent exploits have proven the concept to suffer from vul-
nerabilities originating in the limited number of trusted entities (see Section 3.1.3).
Further, chain relay deployments like BTC Relay involve complex on-chain validation
driving the execution costs [155] (see Section 3.1.2).
In this part, we propose trusted cross-chain state access based on chain relays that
does thus not incorporate novel trust assumptions. The concept mitigates trusted in-
termediaries as theycontradict the original idea ofdecentralization in blockchain net-
works. As a result, we facilitate cross-chain applications requiring a trusted state root
for processing cross-chain function calls, smart contract forks, smart contract syn-
chronization, minting wrapped tokens, etc. In contrast to current chain relays that
suffer from computational overhead on the verifying blockchain, the presented con-
cepts relieve the verifier from computational and storage overhead.
In the first chapter of this contribution, we introduce a chain relay mechanism based
on verifiable off-chain computations and tailored to validate PoW-based blockchains.
Block header validation is conducted in off-chain programs, and the correct execution
is validated on the target blockchain to prove the existence of transactions, states, or
events on the source blockchain.
The second chapter presents a chain relay enabling the efficient validation of PoS
blockchain headers. We utilize the finality guarantees provided by PBFT-based PoS
blockchains to allow the validation ofonly a subset of block headers while maintaining
equivalent security guarantees to the source blockchain’s light client protocol.
53
4 Zero-Knowledge
Proof-based Chain Relay
In this chapter, we facilitate trusted cross-blockchain state proofs by implementing
a chain relay that validates block headers from PoW blockchains. While current ap-
proaches enabling cross-blockchain state access require proofsizes linear to the num-
ber of blocks the state was built on, trusted intermediaries, or economic assumptions,
we propose the utilization of off-chain computations through zkSNARKs to provide
a cryptographically secure and highly scalable sidechain mechanism. Multiple block
headers are included in batches and verified off-chain while preserving light client
support. Only the validity of the off-chain computation is verified on-chain, creating
asidechainmechanismthatrequires constantverificationcosts andreleasesthe target
ledger from processing and storing everysingle block header of the source blockchain.
4.1 Motivation
Chain relays depict a promising solution for providing blockchain interoperability and
enabling applications like cross-chain token transfers and smart contract portability.
Current implementations of chain relays such as BTC Relay [35] permit submitting
single blocks of PoW blockchains to a smart contract, which in turn validates its com-
pliance to the defined consensus rules of the source chain.
BTC Relay incentivizes participants to submit Bitcoin headers to an Ethereum smart
contract by permitting them to set a fee that has to be paid every time proofs are con-
structed from the submitted header. However, the overhead for submitting an up-to-
date block header grows continuously with the gap to the latest submitted block, as
all intermediate blocks have to be submitted first to enable header-chain verification.
Due to this fact, the BTC Relay contract has stalled for millions of blocks at the time
of writing,1corresponding to more than 60 months since the last block has been sub-
mitted.
We address this issue by proposing and implementing a batch-aggregating zero-
knowledge proof-based relay system for PoW blockchains. Instead of verifying each
header of a source ledger, our system allows a target ledger to validate a chain of block
headers in batch. Crucially, our design upholds the ability for SPVs for blocks in such
1Date: February 17, 2023
54 Chapter 4. Zero-Knowledge Proof-based Chain Relay
batches. Only a single block header of a batch is persisted on the target ledger, min-
imizing the storage costs. As the consensus validation is performed completely off-
chain, only the verification of a zero-knowledge proof has to be performed on the tar-
get ledger, which leads to a further cost reduction.
To demonstrate the viability of our proposed system design, we provide and evaluate
prototypical implementations that establish bridges from Bitcoin and Ethereum 1.0 to
any EVM-based blockchain. First, we use the ZoKrates framework [102] to prove the
validity of batches of Bitcoin block headers in an off-chain computation through zk-
SNARKs. Second, we implement a similar chain relay using the Cairo framework [115]
to compare the scalability and security impact of zkSTARKs to zkSNARKs Third, the
concept is extended to cater to memory-hard PoW algorithms like Ethereum’s Ethash.
Since the comparison between ZoKrates and Cairo shows a scalability advantage for
ZoKrates, it is used for implementing and evaluating the extended concept. An Eth-
ereum smart contract confirms the correctness of the resulting proof and stores the
target block header. Finally, light clients can utilize SPVs on verified block-header
batches.
4.2 Design Goals
In order to guide the chain relay design, we introduce six qualitative design goals de-
rived from related cross-chain literature and adapted to suit a chain relay[1, 35, 85, 88,
130, 137]. The defined designgoalsensure that theblockchain properties decentraliza-
tion, transparency, and immutabilityaremaintained byoverarching cross-blockchain
applications. We focus on public and permissionless network settings. The presented
design goals will be utilized to evaluate the proposed concept in Section 4.5. Further-
more, the goals depict the condition for functioning smart contractportability, as out-
lined in Part III of this work.
•Forkless. The chain relay does not require any soft, hard, or velvet fork on the
source blockchain or explicit collaboration of a subset of its validators [1, 88, 137].
Forks can reduce the network’s security since miners and validators may par-
ticipate in distinct networks in the following, effectively reducing the degree of
decentralization of every single network. Even velvet forks that do not result in
network partitions constitute a security issue to dependent applications due to
the limited validator set [84].
•Trustless. There are no trusted intermediaries. Here, trust includes the correct
executionofprotocolsorstorageofprivatesigningkeys, whichmayleadtothird-
party exploits if handled incautiously. Trust in stored block headers should be
derived solely from the source blockchain’s consensus validation. Any trusted
state required for bootstrapping the chain relay can be verified independently by
its users [1, 85, 130].
•Autonomous. The chain relay should remain operational independent of any
single entity [35]. The only condition should be the source and target block-
chains’ liveness. Single entities cannot effectively stall the relay.
4.3. Concept 55
•Robust. The chain relaysurvives extended periods of inactivity. For instance, the
targetblockchain mayhave been congested, resulting in delaysor highexecution
costs [45]. The chain relay should retain its state and maintain updatable at all
times without decreasing security.
•Corresponding. Only those block headers that are valid according to the source
blockchain’s consensus rules are processed by the chain relay [1, 85]. The repli-
cated data should allow applying inclusion proofs of transactions, states, and
events that occurred on the source blockchain.
•Lightweight. Executing the chain relay client should be efficient in terms of
computation and memory usage. Corresponding update transactions should re-
main at least within the execution limits of the target ledger [1, 85]. This could
be achieved by efficient execution on a single machine or parallelization in a dis-
tributed setting, i.e., horizontal scalability.
4.3 Concept
The objective of chain relays is to enable the target ledger (LT) to interpret events that
have occurred on the source ledger (LS) in a verifiable manner without requiring any
intermediaries or strong trust assumptions. Currentsolutions such as BTC Relayincur
costs linear in the number of blocks contained in LS. Implemented incentive mecha-
nisms have shown to be inadequate, as the required investment for keeping the relay
up-to-date exceeded the expected profits.
We propose the utilization of off-chain computations using zero-knowledge proofs to
facilitate the submission of validated batches of block headers. As a result, the relay’s
costs are decimated. We expect on-chain execution costs to be constant for any batch
size instead of growing linearly with the number of blocks when zkSNARKs are ap-
plied. We expect logarithmic cost development with growing batch sizes in the case of
zkSTARKs.
In the following, we firstpresent howoff-chain computations can be used to construct
a chain relay based on zero-knowledge proofs to permit submitting proofs for single
block headers. Thereafter, the concept is extended to permit batching multiple block
headers and submitting only a subset of headers to LT. Then, we introduce a mech-
anism to ensure that SPVs can be performed for all block headers. Finally, we present
a mechanism for applying off-chain computations to memory-hard PoW algorithms
such as Ethereum’s Ethash.
4.3.1 Single Block Header Validation
To decrease the on-chain complexity of validating a block header’s correctness ac-
cording to the consensus rules of LS, we construct a provable off-chain program that
takes a block header as input and returns a boolean value indicating its validity. Con-
ceptually, the relay acts as a light client; it does not validate transactions included in
blocks but relies on the assumption that forging valid header chains is economically
infeasible [13]. Due to the probabilistic PoW consensus, the concept has to cope with
56 Chapter 4. Zero-Knowledge Proof-based Chain Relay
Source
Ledger
Relay
Client
Zero-Knowledge
Proof Framework
Target
Ledger
getBlock
Headers()
Block Headers
validate()
Result
createProof()
Proof
submitProof()
Result
Off-Chain
Validation
Calculate
Proof Relay
Contract
1
2
3
Figure 4.1: Workflow of a chain relay update. Retrieved blocks are pro-
cessed off-chain and correct execution is verified on-chain by the relay
contract.
missing finality and fork handling. Furthermore, each block header must satisfy a
PoW requirement, defined through its computed target difficulty. In the following, we
tackle a light client’s tasks through off-chain computations based on zero-knowledge
proofs.
The proposed chain relay enables users to perform off-chain block header validation
without requiring trust or permissions. At the beginning of the process, a LSclient is
queried to retrieve the header chain up to the target header HX
S, where Xcorresponds
to the header’s block height, as illustrated in Figure 4.1. The relay client pre-processes
blocks by serializing input values, converting between endianness as required, and
casting to the expected types before submitting the values to the off-chain program.
The off-chain validation program checks the PoW of the header and returns a boolean
value that indicates the validity of the block header (validation step 1). Based on the
outcome, a proof is generated attesting to the correctness of the off-chain computa-
tion (step 2). The proof size is linear in the number of public input parameters and
outputs and constant otherwise. In step 3, the computed proof is submitted to the
relay contract, which verifies the proof’s correctness.
Fork handling. The generated proof is submitted to a relay contract on LTthat first
validates the proof’s correctness using the formerly computed verification key. In ad-
dition, it verifies the correctness of the hash chain. The relay contract stores the gen-
esis block Gof LS. Only blocks that build on top of Gsequentially are considered valid.
As valid blocks are not necessarilypart of LSbutcould depict a fork, block headers that
build on top of the most recent valid block header are accepted but may be challenged.
We underline that every accepted block header is valid by the consensus rules of LS, as
it has been validated during the off-chain computation, which in turn has been ver-
ified within the relay contract. However, the currently accepted main chain can be
challenged and replaced if a header chain contains more cumulative PoW in LS. Mul-
tiple challenging forks may exist simultaneously, and a fork replaces the main chain if
it contains more cumulative work than the current main chain.
Difficulty adjustment. PoW-based blockchains regularly adjust the target difficulty
to achieve relatively constant mining rates, depending on the total hash power in the
4.3. Concept 57
network. For instance, Bitcoin adjusts the difficulty after a fixed number of blocks
called epoch (E) [13, 156], while Ethereum 1.0 conducts adjustments with everymined
block [15]. The PoW algorithm requires the hash value of a block header to be smaller
than a target value inferred from the calculated difficulty. While the off-chain pro-
gram validates the PoW of submitted headers, the computation is isolated and has no
information about the difficulty that is applied in its epoch. However, the target is en-
coded within the block header in PoW blockchains. The off-chain program extracts
the target value and utilizes it during validation. To prevent attackers from submit-
ting block headers that encode invalid target values which cannot be detected within
the off-chain computation, the relay contract verifies its correctness before accept-
ing a proof in step 3 , depicted in Figure 4.1. For epoch-based PoW blockchains, the
target must be equal to the encoded target in HX−1
Sif HX
Slies within the epoch (i.e.
Xmod E= 0). Otherwise, the off-chain program calculates the new target difficulty
from the former target and the time delta between the preceding epoch’s first and last
block.
Finality. After a block header has been appended to the stored main chain in the re-
lay contract, it becomes the basis for validation of successively submitted headers and
can also be used for SPVs. In order to prevent constructing SPV-proofs from a fork of
LS, we define a security parameter nthat indicates the number of blocks that have to
be appended to a given block before it is considered final. Only block headers consid-
ered final might be used for SPVs. The parameter is defined by external smart con-
tracts that reference the relay contract and depends on the balance between up-to-
date cross-chain references and security for the given use case. SPV proofs are either
validated on-chain within a smart contract that references HX
Sin the relaycontract or
by a zero-knowledge proof verifying a Merkle proof. The utilization of zkSNARKs re-
sults in constant proof sizes but would require fixed Merkle tree heights, as the input
size of respective off-chain programs must be known at compile time. As the amount
oftransactions storedin ablock fluctuateshighly, the corresponding Merkletree is ad-
justed accordingly. To cope with this limitation, multiple distinct off-chain programs
are required, each validating a single Merkle tree depth. In contrast, zkSTARKs-based
programs are not constrained to a fixed input length and are capable of processing
Merkle proofs of variable size.
4.3.2 Epoch-based Block Header Validation
Performing off-chain validations of single blockchain headers is particularly helpful
if it requires instructions that are not natively supported by the target chain. In the
case of Bitcoin, the SHA-256 hash function is applied to the header twice to verify it
contains sufficient PoW. As the SHA-256 hash function is a native opcode in the EVM,
it requires relatively small amounts of gas to execute [15]. Nonetheless, other PoW-
based blockchains like Litecoin or Ethereum 1.0 require more complex operations to
verify block headers, as outlined in Section 2.2.2.
As chain relays mimic the same mechanisms as the source blockchain, block headers
have to reference a formerly submitted block. As a result, potentially large amounts
of intermediary headers need to be verified and stored on the target ledger before the
58 Chapter 4. Zero-Knowledge Proof-based Chain Relay
2016 2017 4030 4031 4032 4033
…
Epoch
Relay
Contract
Verify
Headers
…
Calculate
Target
Difficulty Submit
Proof
Figure 4.2: The first block of an epoch is the last block of a batch in the
relay (N=E= 2016). Block headers shaded in dark grey are public
and visible and passed to the relay contract. The last block of an epoch
is persisted in the relay contract. Block headers shaded in light grey are
intermediary blocks and initially not stored on the target ledger.
intended header can be submitted. In Ethereum, storing data is the second most ex-
pensive operation (after creating accounts) within smartcontracts to prevent bloating
the state [15]. Chain relays—and smart contracts in general—should therefore avoid
storing intermediary data that is not required on-chain.
Off-chain programs that are verifiable through zero-knowledge proofs offer functions
that provide public and private parameters. Private parameters are only needed dur-
ing off-chain computations and remain invisible during the proof validation process.
While this characteristic poses promising privacy-related opportunities, we utilize it
to hide complexity to the target ledger in the proof validation process by submitting
batches of headers. We differentiate between block headers that are passed as public
parameters and private intermediary block headers. While all block headers of a batch
are validated off-chain to ensure onlyvalid hash chains that include sufficientPoWare
submitted, only the last block header of a batch is stored in the relay contract, as illus-
trated in Figure 4.2. The relay contract remains unaware of private intermediaryblock
headers and neither stores them, nor requires any information about them to validate
the correctness of a batch.
We define a batch BNas an ordered list of Nblock headers HX..(X+N−1)
S. For demon-
stration purposes, we first choose a batch size greater or equal to the epoch length
(N≥E) and, after that, abstract to arbitrarysizes of N. This ensures thatall necessary
information is available to compute the targetdifficulty within the off-chain program.
Note that a batch can also include multiple epochs while maintaining full verifiability.
Blockchainimplementationssuch asEthereum1.0thatadjusttheirtargetdifficultyaf-
ter everymined block provide an epoch length ofone block. Thus, a batch may include
multiple blocks corresponding to multiple epochs in this case. When validating single
block headers, the difficulty computation is performed within the relay contract, as
the required time stamps and target values are encoded in the headers that are stored
in the contract. However, this is not the case when batching block headers off-chain,
as only the last header of a batch is stored in the relay contract. Due to this, the target
calculation is shifted to the off-chain program, providing information about the given
epoch and further reducing overhead in the relay contract.
4.3. Concept 59
Intuitively, one may assume that a batch contains exactlythose block headers that be-
long to one epoch in case their size is equal. Yet, as the off-chain program performs an
isolated computation, such a composition does not comprise sufficient information to
calculate the target difficulty of an epoch. The target difficulty is computed from the
time delta ∆tbetween the first and last block of an epoch, the prior difficulty, and the
target mining time θ:
targetn=∆t
θ·E·targetn−1
A naïve construction of headers within a batch would, therefore, miss the timestamps
required to calculate ∆t. Shifting the batch with an offset of one block to the epoch
permitsconstructing aproofthatholdsallrequiredinformationtocalculate thecorrect
target difficulty, as depicted in Figure 4.2. In addition to the headers that need to be
validated, the last block of the previous batch is submitted publicly. As it is public, it
is utilized by the relay contract to ensure the batch builds on top of the current main
chain. Furthermore, the timestamp is extracted and used for calculating ∆tduring the
off-chain validation process. In contrast to the single block header validation, not only
the PoW is verified off-chain, but also the correctness of the previous block-header
hash as well as a constant difficulty up until the last block of the batch.
4.3.3 Inclusion Proof for Intermediary Headers
The aggregation of block headers into batches facilitates efficientoff-chain validations
to release LTfrom storing every single header of LSin the relay contract. While inter-
mediary headers are initially not stored on LS, users may intend to create SPVs from
them to prove the occurrence of transactions, states, or events. The proposed relay
mechanism enables users to retrospectively submit intermediary blocks to the relay
contract by utilizing a Merkle tree built over all headers included in a batch. For this
purpose, the off-chain program does not only verify the correctness of the headers
within a batch but also includes them in a unique Merkle tree, as illustrated in Fig-
ure 4.3. Each leaf node in the tree corresponds to a block header’s hash. The root of the
Merkle tree is returned bythe off-chain program, and the results from the header and
difficulty validation and stored in the corresponding relay contract. While the inter-
mediary block headers of a batch are not stored in the relay contract, the Merkle root
enables participants to submit a Merkle proof for any intermediary header of a batch.
As the header has already been validated off-chain and the Merkle proof ensures its
inclusion in a stored batch, no further proofs or batch submissions are required to in-
clude intermediary headers. We underline that the computed Merkle tree is indepen-
dent of any Merkle tree natively used by LSor LTand only responsible for facilitating
the trusted submission of intermediary blocks from validated batches.
Constructing a binary tree for N= 2016, as implemented by Bitcoin, results in a tree
height of ⌈log22016⌉= 11. Thus, a respective Merkle proof requires eleven nodes in
addition to the target block header. In order to minimize the computational overhead
on-chain, the proof is computed off-chain within a dedicated program. The Merkle
tree is calculated based on a hash function that employs embedded elliptic curves and
can be executed efficiently by zero-knowledge proof frameworks such as ZoKrates or
Cairo. In contrast, the application of SHA-256 is computationally expensive in such
60 Chapter 4. Zero-Knowledge Proof-based Chain Relay
Submit
Proof
incl. Merkle
root
…
4 Block Batch
Relay Contract
Figure 4.3: A Merkle tree is built using all block header hashes as
leaves. The submitted Merkle root enables the submission of interme-
diary blocks at a later stage.
frameworks, as modulus operations require numerous constraints in the underlying
constraint system.
4.3.4 Flexible Batch Sizes for Block Header Validation
The header validation concept introduced in Section 4.3.2 facilitates the submission of
batches that are of equal size or larger than the epoch length of LS. After a batch has
been submitted, users can submit Merkle proofs to the relay contract to include in-
termediary blocks from which SPVs can be performed. However, two important chal-
lenges remain:
•Large batch sizes prevent the submission of SPVs from recent block headers. For
instance, Bitcoin’s currentmining time of10 minutes per block andan epoch size
of 2016 results in an epoch duration of 14 days. Therefore, users would have to
wait for two weeks before being able to utilize verifiable off-chain computations.
•Compiling an off-chain program, constructing a witness, and particularly com-
puting a respective proof requires large amounts of RAM, as demonstrated in
Section 4.5. Thus, the complexity of the off-chain computation needs to be re-
duced to ensure the practicality of computing zero-knowledge proofs on end-
user hardware.
To mitigate the obstacles introduced by large batch sizes, we introduce a concept for
flexible batch sizes in addition to Merkle proof submissions. The mechanisms are in-
teroperable and may thus be applied in conjunction.
Since the zkSTARKs framework Cairo can handle variable input sizes during witness
computation, users can flexibly choose the intended batch size. Therefore, a single
relay contract can handle proofs that include arbitrary batch sizes. For instance, the
batch size could be selected so that the final block header comprises a transaction or
4.3. Concept 61
Submit
Proof
…
Submit
Proof
Val. preceeding
Block Hash
4 Block Batch
Relay Contract
2 Block Batch
Relay Contract
Epoch
Head
Figure 4.4: Different batch sizes require distinct verification methods.
Relay contracts verifying specific sizes may reference relay contracts of
higher order. Block headers shaded in dark gray indicate public param-
eters.
state of interest. In that case, no further proof concerning intermediary blocks is re-
quired. Yet, other users canutilize the submitted batchfor incorporating intermediary
headers using an off-chain computed Merkle proof, as presented in Section 4.3.3.
As off-chain programs based on zkSNARKs, as enabled by ZoKrates, are not capable of
handling variable batch sizes, we introduce multiple off-chain programs for this case,
each handling a distinct batch size. The setup phase is executed for each batch size,
resulting in distinct proving and verification keys for each size. There are two options
to verify the correctness of batches of different size.
•A distinct verification method is embedded into a single contract for each batch
size. Asaresult, thecomplexityiskeptlow, asallbatchesaresubmittedtoasingle
contract that handles references between distinct batch sizes. This approach,
however, implies a fixed set of batch sizes that cannot be modified once the relay
contract has been deployed to the target ledger.
•Deploying a single relay contract for each batch size provides more flexibility to
participants, as novel contracts can be added retrospectively.
We utilize the second approach in the following, enabling users to use batch sizes ac-
cording to their requirements, as illustrated in Figure 4.4. Every relay contract main-
tains a set of other relay contracts that may be referenced during a batch submission.
Assuming, for example, that a batch of two block headers is submitted, it could build
on top of a batch of four headers stored in a separate contract. Hereby, the compu-
tational complexity is decreased for smaller batch sizes, which facilitates the cheap
submission of recent block headers.
However, applying smaller batch sizes prevents the off-chain computation from cal-
culating a correct target difficulty in case a new epoch is entered. Therefore, the first
block header of the corresponding epoch (HX−(Xmod N)
S) is passed as a public parame-
ter to the off-chain program. Furthermore, an additional outputvariable is introduced
that indicates the validity of the encoded target difficulty. Short-circuit evaluation is
not supported in off-chain programs, so the target value is computed for every sub-
mitted batch. Thus, the target value is computed even if the batch does not include a
transition between epochs. In this case, the value is invalid as the elapsed time within
62 Chapter 4. Zero-Knowledge Proof-based Chain Relay
an epoch is smaller than expected in most cases. To tackle this issue, the relay con-
tract first calculates whether the submitted batch exceeds the current epoch and only
utilizes the program’s corresponding output in that case. Each batch size should be
constructed in a form that satisfies the requirement of storing the first block of an
epoch as the lastblock of a batch. The relay contractverifies that the correct first block
of an epoch has been submitted to the off-chain program.
Every relay contract references relay contracts of higher order to prevent offsets re-
sulting in batch submissions surpassing an epoch boundary. For example, a partici-
pantmaysubmitabatchofsize fourstartingfromgenesisblock G. Based onthis batch,
any participant could submit a batch of size N=E= 2016. As a result, the latter batch
would store H2020
Sinstead of the required H2016
Sthat corresponds to the first block of
the subsequent epoch. Enforcing a top-down approach prevents such threats while
maintaining sufficient flexibility to participants.
4.3.5 Memory-hard PoW algorithms
Memory-hard PoW algorithms constitute a challenge to verifiable off-chain compu-
tations since the required dataset for generating PoW would result in many circuits,
rendering the execution infeasible. Therefore, we present a mechanism that bypasses
the computation of extensive data volumes within the verifiable off-chain program
by committing to pre-computed values. While the presented solution applies to any
memory-hard PoW algorithm permitting the computation of data slices in advance,
we exemplify our concept using Ethereum’s Ethash algorithm (see Section 2.2.1).
Our concept is inspired byan approach firstpresented byLuu etal. for enabling decen-
tralized Ethereum 1.0 mining pools called SmartPool [157]. Since decentralized mining
pools require an efficient validation procedure within a smart contract, the authors
propose pre-computing the datasets of future epochs, creating Merkle trees with the
dataset items as leaves, and storing the roots in a smart contract. At the time of de-
ployment, Merkle roots may be computed and stored by a single entity. Other users
must verify the correctness before using the smart contract. The Merkle roots permit
omitting the calculation of a cache during validation that would be necessary other-
wise [15]. When proposing a block, the respective data items and Merkle proofs are
submitted in addition to the block header and nonce. The verifier checks if the items
were indeed part of the dataset and if they were retrieved from the correct slot, ac-
cording to the protocol. With ETH Relay, Frauenthaler et al. propose a probabilistic
chain relay that utilizes SmartPool’s concept for disputing invalid block headers (see
Section3.1.2) [85]. Theauthorsshowthaton-chain validationofmemory-hardPoWis
infeasibleforentirehashchainsandcomputationallycostlyforchallengedblockhead-
ers. Therefore, our concept may be used to support probabilistic chain relays like ETH
Relay or act as an independent chain relay. In addition, it may be applied to SmartPool
to reduce on-chain validation costs.
We adopt the pre-computation approach of SmartPool for enabling a chain relay vali-
dating memory-hard PoWblockchains using verifiable off-chain computations. First,
the datasets of all epochs that should be covered in the future are computed in a regu-
lar, non-verifiable fashion, as illustrated in Step 1of Figure 4.5. Based on the dataset
4.3. Concept 63
Relay client
compute
Merkle trees
compute
Merkle proofs
compute
datasets
4
5
Zero-Knowledge
Proof Framework
Source Blockchain
Node
1
2deploy relay contract
(Merkle roots)
get block headers
return
calculate witness
(block headers,
dataset Merkle proofs)
return
create relay
update relay
calculate proof
(witness)
return
update relay contract
(proof, final header
Merkle root)
Target Blockchain
Node
return
return
3
6
Figure 4.5: The verification of memory-hard PoW algorithms requires
thepro-computationofcommitments toa datasetthatis utilized byoff-
chainprogramsto efficientlyproofthecorrectselectionofdatasetitems.
items, the relay client generates a Merkle tree using a hash function, such as a Ped-
ersen hash [109], that is efficiently executable within a verifiable off-chain program
(Step 2). The resulting Merkle roots are submitted at deployment time (Step 3)
and must be validated by users before the contract’s utilization. Updating the relay
contract requires retrieving the respective block headers from the source and com-
puting a Merkle proof for each dataset item used for PoW calculation (Step 4 ). In
Step 5, a verifiable off-chain program checks the correctness ofthe header chain and
PoW of each block header. While PoW validation would usually require the generation
of a 16MB cache for computing the dataset items, we mitigate the involved overhead
by replacing the cache with the submitted Merkle proofs. Since the dataset items are
recorded sequentiallyas leaves in the Merkle tree, they can be addressed bycomputing
all locations based on the header and nonce. We utilize a binary Merkle tree so that the
tree is traversed by applying the location’s binary representation. If all dataset items
match, the Merkle root is generated and compared with the pre-computed Merkle
roots that are hard-coded into the off-chain program. In addition, a Merkle tree over
all submitted block headers is computed, permitting proving their inclusion at a later
stage. As a result of the off-chain computation, all block headers have been validated,
and a witness is returned, including the block header, difficulty, and time of the pre-
vious block, as well as the last block of the batch. Based on the witness, a proof is
generated attesting to the correct program execution. Finally, the proof is submitted
to the relay contract on the target blockchain in Step 6, which validates the proof
and ensures the correct application of the previous block header, time, and difficulty,
before storing the final block and Merkle root.
As a result, the on-chain validation complexity is equivalent to non-memory-hard
64 Chapter 4. Zero-Knowledge Proof-based Chain Relay
PoW validation when applying zkSNARKs since the proof validation complexity is in-
dependent of the off-chain program. In the case of zkSTARKs, logarithmic complexity
is expected for proof validation resulting in increasing gas costs stemming from the
off-chain processing of Merkle proofs.
4.4 Implementation
To allow the evaluation of the presented concept, we implement three different in-
stances utilizing distinct frameworks and source blockchains. First, we present the
implementation based on the ZoKrates framework thatenables creating verifiable off-
chain computions using zkSNARKs (see Section 2.5.3). While other frameworks, like
Circom [158] or Snarky2, exist for generating zkSNARKs circuits, they do not pro-
vide verfier smart contracts. In addition, ZoKrates is actively developed and shows
wide community support. Therefore, ZoKrates is used for implementing a chain relay
verifying Bitcoin block headers and another chain relay verifying Ethereum 1.0 block
headers. We choose these blockchains since they are the most used networks, accord-
ing to their market capitalization. Further, Ethereum 1.0 applies Ethash, permitting
us to evaluate out concept’s applicability to memory-hard PoW algorithms.
Second, we implementa chain relayvalidating the Bitcoin blockchain usingzkSTARKs
tocomparetheoff-chainandon-chainperformancetothe zkSNARKs-based counter-
part. We utilize the Cairo framework for implementing the off-chain program, since it
is the only DSL supporting the development of zkSTARKs to the best of our knowledge
(see Section 2.5.3).
4.4.1 ZoKrates
In this section, we demonstrate how to utilize the ZoKrates framework to create an
efficient chain relay using verifiable off-chain computations. First, we introduce an
implementation for verifying Bitcoin block headers within an off-chain program and
the program’s validation on an EVM-compatible blockchain. Second, we present an
implementation targeting the Ethereum blockchain before it transitioned to PoS, us-
ing the Ethash consensus algorithm.
4.4.1.1 Bitcoin
The implementation of the relay scheme is separated into three components. While
the off-chain program is implemented using the ZoKrates framework, the relay con-
tractisaSoliditysmartcontractthattargetstheEthereumblockchain. Lastly,aPython
pipeline enables retrieving block headers from a Bitcoin client, computing corre-
spondingwitnessesandproofsusingZoKrates, andsubmittingproofstotherelaycon-
tract. The implementation is available on GitHub3under an open-source license.
Beforesubmittingblockheaders tothe off-chainprogram, the rawinputhas tobe pre-
processed, as variables in ZoKrates are restricted to a field size of 16 bytes [102]. Be-
cause the size of Bitcoin headers is 80 bytes [156], each header is split into five 16 byte
2https://github.com/o1-labs/snarky
3https://github.com/informartin/zkRelay
4.4. Implementation 65
long integer values before being passed as a parameter. The off-chain program ap-
plies two SHA-256 hashes to the header and compares the result to the encoded target
value. The target value must remain constant within an epoch. Otherwise, the cor-
rect calculation of the target value is validated by computing it from the timestamps
of an epoch’s first and last block. Due to Bitcoin’s encoding of the target to four bytes,
some precision is lost in comparison to its former 32-byte value. In ZoKrates pro-
grams, floor functions that permit compensating for imprecision are computationally
inefficient. Therefore, a target is considered valid if it is equal up to the last digit of
its encoded value. Furthermore, the standard encoding for Bitcoin headers is little-
endian. Therefore, headers are passed in little-endian to calculate valid hashes dur-
ing PoW calculations, while static functions convert header contents to big-endian for
further processing.
Based on the verification keys that are generated during the setup phase, ZoKrates
generatesaSoliditysmartcontractthatverifiesthecorrectprogramexecutionforsub-
mitted proofs. To maintain a clear separation between zkSNARK verification and relay
logic, a second smart contract is implemented that stores all successfully submitted
Bitcoin headers. The zkSNARK verification contractis called every time a block header
is submitted. If the program execution is deemed valid, further processing occurs in
the relay contract. Regular batch submissions must build on the current main chain
stored in the contract. Any participant can challenge any former submission. After a
challenging fork has been successfully submitted, either further batches are submit-
ted that build on top of the fork, or a settlement function is called that compares the
cumulative difficulty of the current main chain and the target fork. If the fork com-
prises more cumulative difficulty than the main chain, all parallel headers are deleted
and substituted by the fork.
The relay contract is equivalent for each batch size in all but two aspects: First, the
batch size is stored in a constant value and used to guarantee the correct calculation of
an epoch’s target difficulty. Second, each relay contract maintains a distinct zkSNARK
verification contract to ensure that submitted proofs have been computed correctly for
the given batch size.
4.4.1.2 Ethereum 1.0
Similar to the previously introduced Bitcoin relay, the implementation of the Ether-
eum 1.0 relay is separated into an off-chain program based on ZoKrates, Soliditysmart
contracts for the on-chain validation, and a client handling the pre-processing. Yet,
the client implemented using GoLang instead of Python since it needs to compute the
Merkle tree over all dataset items for each epoch [76]. As this task is computationally
intensive, a well-performing programming language like GoLang provides runtime
advantages over Python. Furthermore, the Go-Ethereum client4provides an efficient
implementationforthedatasetgenerationthatweextractandintegrateintoourclient.
In general, the relay update process is similar to the Bitcoin relay but differs in two as-
pects: dataset validation and difficulty adjustment.
4https://github.com/ethereum/go-ethereum
66 Chapter 4. Zero-Knowledge Proof-based Chain Relay
Before compiling the off-chain programs, we must compute the datasets for allepochs
that the chain relay should cover. Since the datasets are independent of the blockchain
state, the client does not require a connection to an Ethereum 1.0 node to generate the
dataset items and create a Merkle tree to which the off-chain program commits. For
creating the Merkle tree, we apply zkSNARKs-friendly hashing algorithms to permit
efficient validation within the off-chain program. Namely, we evaluate the compile
and execution times of Pedersen [109] and Poseidon [113] hashes which are available
through the ZoKrates standard library. The commitment is conducted byhard-coding
the Merkle roots into the off-chain program. As a result, the off-chain program can
ensurethe correctsubmission ofMerkle proofs during headervalidation, andno inter-
vention by the relay contract is required. The respective Merkle proofs are computed
for every block header of a batch by the relay client and are only submitted to the off-
chain program but remain hidden from the relay contract, resulting in reduced call
data during transaction submission and, thus, lower execution costs.
The Ethereum 1.0 protocol provides for the difficulty to be adjusted with each new
block header [15]. Therefore, there is no epoch-based adjustment validation such as
for Bitcoin, but the off-chain program must calculate and update the target difficulty
for every validated block. Since the off-chain program cannot access the relay state,
the timestamp of the last submitted block must be provided as a parameter. The re-
lay contract validates the parameter’s correctness for each submitted batch to miti-
gate passing incorrect timestamps, which must be public. To reduce storage costs in
the relay contract, we do not store the entire block header but only the block header
hash, difficulty, and time of the last block within a batch. Parameter processing, fork
handling, and batch validation are conducted equivalently to the Bitcoin relay imple-
mentation.
4.4.2 Cairo
We use Cairo to implement a Bitcoin relay that uses zkSTARKs-based verifiable off-
chain computations. Bitcoin is evaluated since the off-chain validation complexity
is lower compared to Ethereum’s Ethash. As the validation complexity of zkSTARKs
scales logarithmically with the off-chain computation, Bitcoin provides a candidate
thatmore likely benefits from the proofsystem’s flexibilitywhile keeping costs in bal-
ance. The workflow is similar to the ZoKrates implementation and we also provide a
Python pipeline for block retrieval, pre-processing and batch submission [159].
The most outstanding advantages of zkSTARKs over zkSNARKs are twofold. First,
there is no requirement for a trusted setup, alleviating derived trust assumptions and
decreasingcomplexity. Second, respective off-chainprogramsallowflexibleiterations
at runtime. Therefore, the number of iterations does not need to be known at compile
time. As a result, the batch size can be chosen arbitrarily when updating the relay,
mitigating the complexity of maintaining multiple off-chain programs and validation
contracts. There is only a single off-chain program catering to any batch size that can
be chosen to meet the maximum hardware capacity or to capture the block of inter-
est. For instance, if a user intends to prove the existence of a transaction that is part
of a block five blocks after the current header, choosing a batch size of five permits
the immediate utilization of the block header without requiring an intermediate block
4.5. Evaluation 67
proof. While the ZoKrates implementation conducts the target difficulty validation
for each batch, and the relay contract decides whether it has to be applied depending
on the batch location within an epoch, the flexibility of Cairo enables calculating the
difficulty only if required. Since the off-chain program is stateless, no information
about the batch location within the epoch is known. Therefore, an additional param-
eter I=Xmod Eis introduced, indicating the index of the batch’s first block within
the epoch. For example, updating block header H2021
Sgiven an epoch size of E= 2016
results in an index I= 5. The off-chain program utilizes Ifor deciding whether dif-
ficulty calculation is necessary and, if so, at which location. The relay contract must
validate the correctness of Ito mitigate incorrect difficulty calculations.
For evaluating the on-chain execution costs, we utilize SHARP which is provided by
Starkware (see Section 2.5.3). After successful validation, the result is stored in a fact
registrycontract. Afactisahash ofanoff-chainprogram’shashandthehashedoutput
of its execution for a given input [159]. The relay contract receives the required fields,
creates the fact, and checks whether the fact has been recorded in the registry.
Since SHARP generates proofs remotely, we cannot measure the proofgeneration per-
formance. Thus, we generate proofs locally using Giza (see Section 2.5.3) to evaluate
proof generation times and hardware requirements.
4.5 Evaluation
We evaluate the implementation of chain relays using verifiable off-chain computa-
tions based on performance, memory requirements, and on-chain execution costs.
We first evaluate the Bitcoin relay implementations using the ZoKrates and Cairo
frameworks. After that, we depict the application of an Ethereum 1.0 relay using Zo-
Krates, since it provides superior validation scalability compared to Cairo, as demon-
strated in the following.
4.5.1 Bitcoin Relay
Our evaluation results showthat the computation time and memoryrequirements de-
pend on the program’s batch size for the zkSNARKs-based and zkSTARKs-based im-
plementations. Theon-chainexecutioncosts remainconstantforanybatchsizewhen
applyingzkSNARKs, while execution costsdepend onthe fee model used bytheshared
prover for zkSTARKs. Seven off-chain programs performing the light client validation
have been created to evaluate the scalability of the presented approach, each serving
a distinct batch size. The number of block headers in a batch is selected to satisfy the
requirements specified in Section 4.3.2, i.e., Emod N= 0. Note that this requirement
is only relevant for the zkSNARKs-based implementation due to the fixed batch size
provided by off-chain programs.
The off-chain benchmarks were performed on a Dell PowerEdge R540 server equipped
with an Intel Xeon Silver 4112 CPU clocked at 2.60GHZ on four cores, 256 GB RAM
clocked at 2666MHz and an SSD. In the workflow, we distinguish between those steps
performed to submit batches and the one-time setup for a given batch size.
68 Chapter 4. Zero-Knowledge Proof-based Chain Relay
(a) Runtime in seconds. (b) RAM required in MB.
Figure 4.6: Performance evaluation of many-time steps in logarithmic
scale using Cairo, Giza, and ZoKrates based on the Bitcoin verifier.
4.5.1.1 Batch Verification and Submission
Every time a batch is submitted to the relay, the corresponding off-chain program is
executed, and a proof is generated. The measured data reflects a single program exe-
cution for each batch size, as displayed in Figure 4.6. We run seven iterations repre-
senting different batch sizes to evaluate the approach’s scalability. Executing multiple
iterations for each batch size produces insignificant deviation rendering a single run
sufficient to provide intuition about the implementation’s scalability given a constant
experimental hardware setup. We first present the results for the implementation us-
ing zkSTARKs and then using zkSNARKs.
zkSTARKs. The execution time and memory consumption for the off-chain valida-
tion of block headers using Cairo scales linearly, as illustrated in Figures 4.6a and 4.6b.
The off-chain generation of a batch of 504 blocks takes about 19.71 minutes. Since the
shared prover is closed source and hosted remotely, it does not permit insights into the
proof generation. Therefore, we generate proofs based on the compiled Cairo traces
using Giza. The proof computation for a batch of 504 blocks requires about 44.32 min-
utes. While the total computation time adds up to about 64 minutes, the chain relay
maintains liveness due to Bitcoin’s configured mining rate of 10 minutes per block,
or 84 hours for 504 blocks. Thus, the verifiable off-chain validation requires less time
than the source blockchain’s mining rate.
Memory is a limiting factor during computation. While the off-chain validation of
a 504 block batch calls for about 23.37 GB of RAM, generating a respective proof re-
quires about 190.82GB of RAM. The relatively large memory requirements constitute
a potential obstacle for end-users during proof generation. However, if user hardware
provides insufficient memory for computing large batch proofs, the batch size can be
reduced to adjust memory requirements. Furthermore, the shared prover may be uti-
lized if the call trace size does not exceed the maximum configured threshold.
Since Giza does not provide an on-chain verifier, we can only derive expected exe-
cution costs from the fee model Starkware’s shared prover proposes. Since the size
of Giza-generated proofs is more than 200KB, submitting a single, non-shared proof
4.5. Evaluation 69
would create significant transaction data costs. The shared prover comprises a max-
imum number of execution steps for all included execution traces. While the current
test network deployment does not require payments, the future main network version
based on StarkNet5will charge fees proportionally to the execution steps allocated in
the shared proof [160]. Built-in operations such as range checks and specific hash
implementations are charged separately from general execution steps. Yet, users only
have to pay for the operations that constitute the limiting factor within the shared
proof. For instance, let us assume the shared proof allows 100 execution steps and 10
Pedersen hash executions. A program requiring 20 execution steps and one Peder-
sen hash would fit five times into one proof. Since the limit stems from the execu-
tion steps, the sender only has to pay for these, and the Pedersen hashes are omitted.
Investigating the program profile indicates the utilization of three different kinds of
built-ins in the off-chain program, Pedersen hashes, range checks, and bitwise and
operations [159]. Yet, since only a few built-ins are executed, the general execution
steps are likely to depict the limit factor in most configurations. The number of ex-
ecution steps scales linearly with the batch size. The trace of validating 504 blocks
comprises 14,446,102 steps, summing up to 722,306gas at price of 0.05gas per step.
These gas costs refer to StarkNet’s fee metering of layer-2 transactions and are, there-
fore, independent of the host blockchain’s native transaction costs. In addition to the
prover-related layer-2 costs, updating the relayrequires calling the relay contractthat
checks the parameter validity and the off-chain program’s correct execution accord-
ingtothe shared prover’s factregistry. Therespective transactionrequires 368,976 gas
when applied to Ethereum’s Goerli network and is constant for any batch size [159].
The combined costs depend on the on-chain gas costs and StarkNet’s fees. Therefore,
a direct comparison to mechanisms excluding layer-2 costs is impossible.
zkSNARKs. We observe that the time and memory required for computing the Zo-
Krates program’s result and proof also scale linearly to the number of block headers
in the respective batch, as illustrated in Figures 4.6a and 4.6b. While the off-chain
computation takes about 4.38 minutes for a batch of 504 blocks, the respective proof
generation requires about 26.61 minutes. The most memory-intensive operation in
the entire ZoKrates workflow is proof generation. For instance, computing the proof
for a batch size of 504 block headers requires about 104.33GB of RAM. Similar to the
Cairo implementation, users can choose a smaller batch size to generate proofs call-
ing for less memory. Yet, a preset batch size must be selected and can not be adjusted
exactly as flexible. For example, a single 504 header batch is substitutable by eight
batches of size 63. In this case, the proof generation reserves only 13.10GB of RAM. As
every proof submission implies gas costs on the target ledger, users should choose the
largest possible batch size that is supported by their hardware and smaller than the
target block header.
After a batch has been validated off-chain and a respective proof has been generated,
the proof is submitted to the relay contract. We measure the gas costs for proof valida-
tion and header storage based on the Ethereum blockchain with the Istanbul fork en-
abled. This fork reduced the gas costs for elliptic curve operations and, therefore, also
reduces the validation costs for zkSNARKs-based proofs. The submission of a batch
requires 522,865 gas including proof validation and storage of the target block’s header
5https://starkware.co/starknet/
70 Chapter 4. Zero-Knowledge Proof-based Chain Relay
(a) Runtime in minutes. (b) RAM required in MB.
Figure 4.7: Performance evaluation of one-time steps in logarithmic
scale using Cairo and ZoKrates based on the Bitcoin verifier.
and hash. The proof validation accounts for 351,226gas of the total transaction costs.
We underline that the transaction costs remain constant for any batch size, as they
onlydepend on the numberofpublic parameters intheoff-chainprogram. Asoutlined
in Section 4.1, the submission of a single block header requires about 194,000gas us-
ing BTC Relay. Therefore, zkRelayis more efficient than BTC Relayfor any batch of size
N≥3. Given a batch size of 504, using a zkSNARKs-based off-chain program is about
187 times more efficient than BTC Relay, which accounts for about 97,776,000gas to
verify the same number of block headers.
4.5.1.2 One-time Setup
While Cairo flexiblycaters to arbitrary batch sizes with a single program, ZoKrates re-
quires compilation and contract generation to be performed once for each batch size.
In addition, the applied zkSNARKs scheme Groth requires a one-time setup for each
off-chain program [104]. The universal Cairo program compilation takes about 5.21
seconds using the introduced hardware. In the case of ZoKrates, we observe that the
compilation and setup times scale linearly with the number of headers in the corre-
sponding batch, as illustrated in Figure 4.7. For instance, the compilation of the off-
chain program verifying 504 Bitcoin headers takes about 30.39 minutes, while the
setup-phased needs about 99.21 minutes. In addition, we observe that the number
of constraints generated from the ZoKrates program scales equivalently and adds up
to 43,331,225 constraints in the case of the 504 Bitcoin header program (not illustrated
forclarityreasons). Similarly, the generatedcomputation steps using Cairoscale linear
to the batch size, as outlined in the previous section’s gas cost analysis.
Our measurements showthat the required memory constitutes a potential obstacle for
average devices when using zkSNARKs-based ZoKrates. While the reserved RAM also
scales linearly with the number of block headers in a batch, compiling the program
verifying 504 headers calls for about 80.50GB of RAM. However, as the compilation is
requiredonlyonce,participantsdo notneedtoperformthecompilation. Furthermore,
compiling the respective program verifying 63 blocks reserves only 10.13GB of RAM,
constituting a feasible task for consumer hardware.
4.5. Evaluation 71
After compilation and setup are completed, ZoKrates generates a smart contract that
verifies proofs of off-chain program executions, while Starkware provides the exist-
ing shared prover for Cairo programs. The relay contracts reference the respective
verifier contracts, store submitted headers, and handle challenging forks. Deploy-
ing the ZoKrates-based relay contract including proof verification contact requires
2,961,750 gas, corresponding to about 0.042353ETH, or about 60.26USD at the time of
writing,6at a gas price of 12gwei.7As the number of public parameters remains con-
stant for all batch sizes, the deployment costs are also equivalent for each respective
contract set. Since the Cairo-based relay contract contains more complex logic for the
flexible handling of arbitrarybatch size, its deployment costs sum up to 3,594,057 gas,
corresponding to about 0.051395ETH, or approximately 73.12USD.
4.5.2 Ethereum 1.0 Relay
As we have demonstrated, zkSNARKs provide enhanced off-chain and on-chain scal-
ability compared to zkSTARKs. Therefore, we implement the concept for validating
memory-hard PoW algorithms using off-chain computations based on ZoKrates. As
expected, the off-chain computation and on-chain validation scale similar to the Bit-
coin relay but with a higher factor for all off-chain steps due to the more complex
Keccak-512 hash algorithm and dataset item validation.
Sincethevalidation of64 Merkleproofsimpliesthe manifoldexecutionofa hash func-
tion, we put an emphasis on selecting a suitable zkSNARKs-friendly hash algorithm.
ZoKrates provides three hash algorithms that are tailored to the efficient execution
within zkSNARKs: Pedersen [109], Poseidon [113], and MiMC [161]. Since Poseidon is
partiallybased on MiMC[113] and our assessmentshowedfewergeneratedconstraints
andlowercomputationtimesin direct comparison, we focuson the detailedevaluation
of Pedersen and Poseidon hashes in the following.
Due to the increased validation complexity of memory-hard PoW, we investigate the
impact of using different zkSNARKs backends and proving schemes. As we are mea-
suring the performance of concrete implementations for our evaluation, different re-
sults are expected for other backends, even when using equivalent proving schemes
and off-chain programs. ZoKrates offers two backends: Bellman8and Ark9. While
Bellman only supports Groth’s proving scheme G16 [162], Ark additionally supports
Groth and Maller’s GM17 scheme [163], and the Marlin scheme introduced by Chiesa
et al. [164]. Proving schemes comprise different security properties. The G16 scheme
generates malleable proofs, i.e., attackers observing a valid proof can create a distinct
but still valid proof. Since the witness cannot be modified, malleability does not pose
a threat to the application of chain relays. While the GM17 scheme is non-malleable,
its execution complexity is higher compared to G16 [163]. Marlin is a novel proving
scheme that enables the computation of a general setup catering to multiple off-chain
programs and could thus alleviate the drawbacks of zkSNARKs [164].
6Date: February 20, 2023. Exchange rate: 1695.42 ETH/USD
71gwei = 0.000000001ETH
8https://github.com/zkcrypto/bellman
9https://github.com/arkworks-rs
72 Chapter 4. Zero-Knowledge Proof-based Chain Relay
0 0.5 1 1.5 2 2.5
·104
Bellman/G16/Poseidon
Bellman/G16/Pedersen
Ark/G16/Poseidon
Ark/G16/Pedersen
Ark/GM17/Poseidon
Ark/GM17/Pedersen
Ark/Marlin/Poseidon
Ark/Marlin/Pedersen
Time in seconds
(a) Computation time for proof generation.
0 20 40 60 80 100
Memory in GB
(b) Memory required during proof genera-
tion.
Figure 4.8: The time and memory required during different process
steps depend on the utilized backed, proving scheme, and hashing al-
gorithm [76].
We first evaluate the performance of our off-chain program validating a single block
header using different backends, proving schemes, and hash algorithms, as depicted
in Figure 4.8. Based on the results, we select a combination for the subsequent anal-
ysis of the one-time execution’s performance and batch validation. We observe that
utilizing the Bellman backend using G16 and Poseidon requires the least computa-
tion time and memory. In any combination, the execution of Poseidon hashes is faster
and requires less memory than Pedersen hashes. Furthermore, the Bellman back-
end is more efficient than Ark regarding execution time and memory requirements.
As expected, the GM17 scheme is less efficient than the G16 scheme. While the Mar-
lin scheme takes the highest execution time and memory, the provided general setup
constitutes a unique advantage.
Given the observed metrics, we analyze the performance of off-chain programs val-
idating different batch sizes based on the Bellman backend and the G16 scheme, as
utilized in the Bitcoin relay. Yet, we take both Poseidon and Pedersen hashes into ac-
count since the Poseidon hash has been proposed recently and thus has not under-
gone broad analysis. As illustrated in Figure 4.9, compiling the off-chain program that
utilizes Poseidon hashes for the Merkle proof validation requires less time but more
memory throughout all batch sizes. Compiling a program validating five blocks de-
mands about 146.43 minutes and 224GB of RAM when using Pedersen hashes, while
thesameprogramusingPoseidon hashes cannotbecompiledsincetheserver’s 256GB
of RAM are not sufficient. Notably, using the Poseidon hash results in short computa-
tion times and lower memory consumption during the setup phase. Yet, as the compi-
lation phase’s memory requirement depicts the limiting factor during the initial one-
time computation, Pedersen hashes are advantageous in this respect compared to Po-
seidon hashes.
Executing the off-chain validation program for a batch size of four requires about 82
seconds when using Poseidon hashes and 200 seconds for Pedersen hashes. While Po-
seidonhashesneedlessthanhalfthetimeduringwitnessgeneration, Pedersenhashes
could also be used for validating a batch of five block headers at about 253 seconds,
4.5. Evaluation 73
(a) Runtime in seconds. (b) RAM required in MB.
Figure 4.9: Performance evaluation of one-time steps in logarithmic
scale using Poseidon and Pedersen hashes within ZoKrates based on the
Ethereum 1.0 verifier.
(a) Runtime in seconds. (b) RAM required in MB.
Figure 4.10: Performance evaluation of many-time steps in logarith-
mic scale using Poseidon and Pedersen hashes within ZoKrates based
on the Ethereum 1.0 verifier.
while the respective Poseidon program could not be compiled. We observe similar re-
sults for the generation of proofs. Here, applying Poseidon hashes takes about 961
seconds for a batch size of four, while Pedersen hashes require about 2,580 seconds.
In addition, the program using Poseidon hashes requests less memory during witness
and proof generation. The generation of a proof covering four blocks using Poseidon
involves about 12.01GB of memory, while Pedersen requires about 38.37 GB.
Themostsignificantbenefitofusingoff-chaincomputationsisreducedon-chainexe-
cutioncosts. Toevaluateourconceptfortheoff-chainvalidationofmemory-hardPoW
algorithms, we compare the execution costs to the on-chain validation implemented
byLuu et al. for their work on SmartPool [157] that is utilized by Frauenthaler et al. for
enabling a probabilistic Ethereum 1.0 chain relay [85]. Since the on-chain validation
costs of zkSNARKs proofs are constant and independent of the off-chain computa-
tion’s complexity, they are equivalent for all batch sizes and hash implementations.
Updating the chain relayusing our implementation requires 556,724gas, correspond-
ing to about 0.00796ETH or 11.33USD at the time of writing,10 at a gas price of 12gwei.
10Date: February 20, 2023. Exchange rate: 1695.42 ETH/USD
74 Chapter 4. Zero-Knowledge Proof-based Chain Relay
In comparison, the on-chain validation using SmartPool requires about 3.3 million gas
for a single block header and scales linearly with the batch size. As a result, the val-
idation of five block headers involves about 16.5 million gas costs. At the same time,
our proposal remains constant at 556,724gas and is, thus, about 29.46 times more ef-
ficient concerning on-chain execution costs. Compiling programs catering to larger
batch sizes would increase efficiency gains. Our evaluation also shows that the proof
generation on the user end requires fewer resources compared to the one-time setup,
resulting in the feasibility of validating large batches off-chain to decrease on-chain
validation costs further.
4.5.3 Qualitative Analysis
In the following, we analyse the compliance ofverifiable off-chain computations using
the design goals introduced in Section 4.2.
•Forkless. Neither the Bitcoin nor the Ethereum 1.0 protocols need to be adjusted,
as the off-chain programs mimic implementation-specific light clients.
•Trustless. There are no economic assumptions exceeding those of the source
blockchains. zkSNARKs require a trusted setup. Yet, using MPC or a general-
purpose setup as supplied by the Marlin proving scheme alleviates the incurred
trust requirement. In addition, zkSTARKs do not require a setup phase.
•Autonomous. Anyone with access to the source and target ledger is enabled to
compute proofs off-chain and submit updates. Different batch sizes cater to var-
ious hardware enabling the participation of end-users.
•Robust. While the Bitcoin validation is well within the protocol’s mining rate,
validating Ethereum 1.0 block headers requires parallelizing computations to re-
main live.
•Corresponding. Merkle branches enable proving the inclusion of transactions,
states, and events. Thus, the relay fosters applications requiring trusted cross-
chain access.
•Lightweight. The concept is lightweight, as only a single header is stored for one
batch. The on-chain scalability depends on the batch sizes.
4.6 Discussion
Verifiable off-chain computations enable the validation of blockchain header batches
without requiring central authorities, economic assumptions, or modifications to the
source ledger. The proposed approach is unique in scalability and provably correct of-
chain light client validation compared to current methods, as outlined in Table 4.1.
While Dogethereum also provides constant validation costs for any batch size, it relies
on an economic rationality model applied with Truebit [135]. ETH Relay only achieves
sublinear on-chain complexity if participants act honestly [85]. This is due to the
smart contract validation of block headers as a fallback when submitted block head-
ers are disputed. Applying an optimistic approach in combination with the verifiable
off-chain computations presented in this work constitutes a promising solution for a
4.6. Discussion 75
Table 4.1: Comparison of different sidechain mechanisms. *ETH Relay
scales linearlyto the numberofblocks ifthe optimisticassumptionfails.
BTC Relay Dogeth. NIPoPoW ETH Relay This work
Source
Ledger Bitcoin Dogecoin — Ethereum Bitcoin /
Ethereum
On-chain
Complexity O(n)O(1) O(log n)O(n)*O(1)
Block
Validation On-Chain Bulletpoof NIPoPoW Optimistic zkSNARK
Computation
Validation
Smart
Contract Truebit Contract
(Proof)
Smart
Contract
Contract
(Proof)
Economic
Rationality No Yes Yes Yes No
Fork
required No No Velvet
Fork No No
scalable chain relay in the future. As a result, the requirement of proof validation for
every block header is alleviated, and low costs are guaranteed via the optimistic block
submission.
While the prototypical implementations of our approach facilitate chain relays from
Bitcoin and Ethereum 1.0 to EVM-compatible blockchains, the proposed concept is
not limited to these blockchains. The consensus mechanism of the source blockchain
must be reproduced by the off-chain program to apply the approach to other ledgers.
Our implementation of an Ethereum 1.0 chain relay demonstrates the applicability to
memory-hard algorithms. Yet, it is specific to the Ethash algorithm and does not sup-
port other memory-hard algorithms such as Scrypt utilized, for instance, by Litecoin
and Dogecoin [75]. Therefore, we can only conclude the feasibility for Bitcoin’s PoW
implementation and Ethash while alternative concepts may incur different require-
ments.
Because the validation and proof generation of Bitcoin headers requires only about 31
minutes for a batch of 504 blocks, i.e., approximately 16.24 seconds per block header,
the computation is well within Bitcoin’s mining rate of about 10 minutes. In the case
ofEthereum 1.0, block header validation is more complex, and Ethereum’s mining rate
is configured to 12.5 seconds. A chain relay has to be able to validate more blocks than
appendedto the sourcechainatthesame timeto remainlive. Sincethe hardwaresetup
utilized for evaluating our implementation cannot produce validation proofs in time,
an additional scalability mechanism is required. So far, we have focused on analyzing
the implementation performance using a single server. The presented chain relay al-
lows for horizontal scaling for producing proofs. Thus, many participants collaborate
to validate distinct batches of blocks to conduct timely chain relay updates. Such col-
laboration requires a coordination oracle that allocates batches to validators. Depend-
ing on the incentive mechanism applied by the chain relay, the relay contract could
depict such a coordination oracle to allocate batches and only disburse rewards if the
allocated batch is submitted. As demonstrated in Section 4.5, the off-chain computa-
tion time depends on the utilized backend, proving scheme, and hash algorithm. Ap-
plying the Poseidon hash requires less time for witness and proof generation. Thus,
76 Chapter 4. Zero-Knowledge Proof-based Chain Relay
Figure 4.11: Validation time of Ethereum 1.0 block headers including
witness and proofgeneration using Bellman backend and the G16 prov-
ing scheme [76]. Applying a coordination oracle enables horizontal
scalability to maintain the chain relay in a live state.
it requires fewer participants to collaborate to maintain the chain relay in a live state,
as illustrated in Figure 4.11. The overall validation rate of 12.5 seconds per block is un-
dershot from 21 validators for Poseidon hashes and 56 for Pedersen hashes. Therefore,
although Poseidon hashes are newer and have been analyzed less, they represent a
promising candidate for implementing a scalable chain relay. In addition, in this con-
text, validators refer to servers and not necessarily to independententities. Therefore,
a single entity executing multiple validations on distributed resources may maintain
the relay live without negatively impacting trust.
While zkSNARKs provideshorter off-chain computation times and less on-chain vali-
dation costs than zkSTARKs, they require a trusted setup. For a use case that leverages
a public blockchain, the setup should be performed by multiple distinct entities and
is safe as long as at least one honest entity participated [103]. If a fixed set of users
intends to utilize the chain relay for a given use case, a specific instance can be de-
ployed by performing a trusted setup between all these participants. The utilization
of zkSTARKs enables verifiable off-chain computations without requiring a trusted
setup [101]. Therefore, they can be bootstrapped easier and comprise fewer trust as-
sumptions. We have shown that zkSTARKs are feasible for implementing an efficient
chain relay. Yet, the off-chain computation complexity renders complex validations,
such as for memory-hard PoW algorithms, impractical.
4.7 Conclusion
In this chapter, we proposed a zkSNARK-based chain relay that facilitates sidechains
in a verifiable and scalable manner. The target blockchain is released from validating
and storing every block header of the source chain by shifting the validation process
to an off-chain program that is verifiable on-chain. A batching mechanism enables
4.7. Conclusion 77
users to submita subsetofblock headers to the target ledger while intermediary head-
ers are processed and validated off-chain. This validation process is cryptographically
secure and does not require economic assumptions or game-theoretic considerations.
Flexible batch sizes and single block submissions through Merkle proofs enable the
inclusion of recently added or intermediary block headers.
We provided two prototypical implementations facilitating chain relays between Bit-
coin and EVM-based blockchains based on the ZoKrates and Cairo frameworks. Our
evaluation shows that zkSNARKs-based on-chain validation costs for submitting
batches are constant for any batch size. The on-chain validation of zkSTARKs entails
the utilization of a shared verifier that batches multiple proofs for decreasing vali-
dation costs. Here, we observe validation costs linear to the number of blocks in the
batch. In both cases, users are enabled to choose the batch size flexibly to best fit their
requirements. While Cairo permits the utilization of a single off-chain program for
arbitrary batch sizes, we have presented a mechanism merging verifiers catering to
different batch sizes based on the ZoKrates framework. Compared to BTC Relay, the
presented approach requires only a fraction of gas when submitting a batch of block
headers. While submitting a single header using ETH Relay entails less on-chain val-
idation costs, our solution is beneficial when disputes are required or for any batch
size greater than one. In the future, our solution may facilitate batching for optimistic
chainrelays like ETHRelay. Sinceoff-chainvalidationscan beparallelized, our concept
constitutes a promising solution to the liveness issues of current PoW-based block-
chain relays.
79
5 Proof-of-Stake Chain Relay
In this chapter, we propose the first chain relay scheme enabling the validation of PoS
protocols producing finalized blocks, for example, Ethereum 2.0, Cosmos, and Polka-
dot. The concept does not require changes to the source blockchain protocols or val-
idator operations. A dedicated relay smart contract on the target blockchain validates
the signatures of block proposers. The relay scheme demands only a subset of block
headers to be submitted to maintain full verifiability, yielding enhanced scalability.
5.1 Motivation
Since PoW entails high energy consumption, limited throughput, and no guaran-
teed finality, PoS blockchain protocols have become increasingly popular for address-
ing these shortcomings. Instead of using computational resources as a limiting fac-
tor when competing for proposing upcoming blocks, participants stake assets and are
selected accordingly. As a result, the energy consumption of network participants is
reduced byorders of magnitude [165]. However, the protocol also leads to a significant
change in the validation of block headers. While validating PoW entails—upon other
checks—creating a hash to verify the accordance to a target value, PoS protocols re-
quire signature validation. The consequential requirements represent a challenge for
chain relays.
While we have shown the feasibility of verifiable off-chain computations for enabling
efficient PoW chain relays in Chapter 4, the same techniques cannot be applied to PoS
blockchains. The signatureschemes used forimplementingPoSprotocols aretypically
tailored for efficient hardware validation. Thus, they are not specifically customized
to the validation within elliptic curves utilized by zkSNARKs schemes and cannot be
efficiently verified [161].
Most chain relays target the validation of Nakamoto consensus protocols and their
derivatives. The majority of these implementations enable the validation of PoW-
based algorithms [1, 35, 85]. In addition, Gaži et al. proposed a sidechain protocol for
PoS algorithms that are derived from Nakamoto consensus [88]. Yet, this proposal
does not cater to emerging blockchain implementations such as Ethereum 2.0 [49],
Polkadot [78] or Cosmos [166], which provide guaranteed finality.
We propose a chain relay enabling interoperability between PoS-based blockchains
supportingguaranteedfinalityandanyblockchainprovidingsmartcontractfunction-
ality. We differentiate between Nakamoto-based consensus algorithms, which fol-
low the longest-chain rule, and those based on PBFT, as depicted in Section 2.2.3. To
our knowledge, we propose the first non-trustee-based chain relay compatible with
80 Chapter 5. Proof-of-Stake Chain Relay
PBFT-based PoS blockchains. Compared to previous chain relay proposals, our con-
cept provides enhanced scalability by skipping blocks of the source blockchain and
replacing formerly relayed blocks while retaining the verifiability of the entire block-
chain history.
To demonstrate the viability of our proposed design, we provide a prototypical im-
plementation that establishes a bridge between Ethereum 2.0’s consensus layer and
any blockchain supporting the EVM. Then, we evaluate the implementation based on
quantitative benchmarks and qualitative measures presented in Section 4.2. As the
EVM is supported by a multitude of blockchain implementations such as Hyperledger
Burrow1or shards of Avalanche2, Polkadot3, and Cosmos4, the presented chain relay
has the potential to provide trustless interoperability between PoS-based blockchain
networks.
5.2 Concept
This section presents the concept of a chain relay enabling the validation of PBFT-
based PoS blockchains. We first introduce the general chain relay concept and ex-
emplify its realization given the specifics of Ethereum 2.0’s Gasper protocol [49] in
the next section. The validation process applies to any blockchain supporting (quasi)
Turing-complete user-defined computations such as the EVM [15]. Therefore, it is in-
dependentofthetargetblockchain’s consensusalgorithmandsuitableforawiderange
of blockchain networks. In the following, we depict the required steps for relaying PoS
block headers and outline the relay states and preconditions.
5.2.1 Overview
In the presented relay scheme, participation is permissionless and does not require
trust in third-party entities after validating the correct initialization, as depicted sub-
sequently.
Initialization. Anyclientattempting tosynchronize withaPoS-based blockchain that
is weaklysubjective has to be bootstrapped with a trusted initial state. The initial state
consists of a trusted block and the epoch’s validator set. Here, an epoch refers to the
number ofblocks maintaining a constant validator set. As this condition also applies to
PoS chain relays, users must verify the initial state before utilizing the contract. This
process is similar to the initial verification of an unknown contract’s logic to prevent
unexpected behavior during its execution. While the verification process is left to the
skilled user, increasing utilization and security audits conducted by trusted entities
may render the contract trustworthy to any user.
Relay update. After the relay contract’s deployment, any entity connected to the
source and the target blockchain is enabled to update the relay state. As the validation
of submitted block headers is conducted in the relay contract, no trust in the relayer is
required. In PBFT-based PoS protocols, blocks are signed by the members of rotating
1https://github.com/hyperledger/burrow
2https://docs.avax.network/
3https://www.parity.io/blog/substrate-evm/
4https://github.com/tharsis/evmos
5.2. Concept 81
validator sets [48, 49]. To apply an update, the relay client retrieves the destination
block header, current validator set, and next validator set from the source blockchain.
Finally, the client prepares a transaction calling the relay contract’s update function
and submits it to the target blockchain.
Finalized blocks. The proposed chain relay only accepts finalized blocks according to
the source blockchain’s consensus rules. Since finalized blocks are guaranteed to be
part of the main chain, forks cannot occur and hence do not have to be handled by the
relay contract. Depending on the source blockchain’s consensus algorithm, the final-
ization may be accompanied by a delay if validators’ votes are collected in successive
blocks [49].
5.2.2 Validator Set
The size of the validator set varies greatly depending on the implementation. While
Cosmos envisions validator set sizes in the order of hundreds and Polkadot plans to
scale up to one thousand, Ethereum 2.0 does not define an upper bound. The chain
relay design must support these configurations. As the validation of signatures re-
quires both computing resources and available public keys, the costs for updating the
relay increase with the number of validators. Hence, it is infeasible for a relay con-
tract executed in a constrained execution environment to process all signatures of the
Ethereum 2.0 validator set.
To facilitate light client validation, Ethereum’s first beacon chain upgrade called Al-
tair implemented so-called sync committees [127]. A sync committee is a periodically
sampled subsetofthefullvalidator set. Itconsists of512 validators whogenerate a sup-
plementary signature of each block used for synchronization byresource-constrained
devices. Furthermore, sync committees are stable during a sync committee period,
which is two orders of magnitude longer than a validator set epoch, and thus requires
less frequent updates. Successive sync committees are sampled one period in advance.
Since every block references both the currently valid and the following sync commit-
tee, the transition between sync committees can be validated by light clients as long
as at least one block is submitted within each sync committee period. As a result, only
one block out of each sync committee period is required to guarantee liveness. Sync
committees remain trusted until a block signed by the following sync committee is
submitted.
Polkadot and Cosmos do not need to implement the sync committees concept because
a validator set’s election natively selects a subset of stakers for validation [78, 123].
Thus, the set sizes are limited, and signature validation is manageable by light clients.
In the following, we presume the utilization of the full validator set where its size is
limited and a sub-sample such as a sync committee otherwise.
5.2.3 Block Validation
The minimum number of signatures defined in the consensus protocol must be
checked to validate a block. In the case of Ethereum 2.0, it is verified whether a thresh-
old of its members generated the sync committee’s aggregated signature. Other im-
plementations that do not apply signature aggregation require a sufficient amount of
82 Chapter 5. Proof-of-Stake Chain Relay
Table 5.1: Required data for a chain relay update in the generic case and
specific to Ethereum 2.0.
Type Generic Ethereum 2.0
Regular
Finalized block
header Finalized block header root btarget
Finality proof or
signature
Latest block header root blatest
Merkle proof that btarget is final
Multi-signature by vtrusted/vtrustedNext
Validator
set update
Next validator set Next sync committee vnext
Next validator set
proof or signature
Merkle proof that vnext is the next validator
set according to btarget
signatures to be available. Therefore, transactions updating the relay contract must
submit the finalized block header that is intended to be stored and a signature or fi-
nality proof issued by the respective validator set, as depicted in Table 5.1.
If the signature validation succeeds, the chain relay substitutes the currently stored
block with the newly validated block. Hereby, storage costs are reduced, as allocating
new storage is usually the most expensive operation in blockchains’ execution envi-
ronments [15]. Unlike Bitcoin or Ethereum 1.0, blocks in Ethereum 2.0 contain Merkle
roots that reference the complete history. Thereby, historical states are retrievable
based on a single subsequent block.
In addition, if the newblock is part ofa newepoch, the transition between both valida-
tor sets is verified, and the new one replaces the old set. New validator sets are either
signedinthepreviousepoch(Ethereum2.0) or sharesignificantintersectionsthatcan
be used to verifytransitions. For instance, in the case ofCosmos, its securitymodel as-
sumes aminimumof2/3 ofhonestvalidators. Submitted block headers mustbe within
acertainbound. Accordingto thelightclientsynchronizationprotocolofCosmos [82],
a successive block can be validated by the chain relay as long as the previously stored
block was signed by at least 1/3 of equivalent validators. In the case of Ethereum 2.0, at
least one block out of each epoch is required to verify the transition between validator
sets. Everychain relayupdate transaction thatincludes a block header signed bya new
validator set must also contain the subsequent validator set and a proof or signature
attesting to the transition. Table 5.1 presents the required parameters for chain relay
updates within a single epoch and across epochs.
5.2.4 Accountable Safety
Assuming that the source blockchain supports accountable safety, the chain relay
should retain this property. As accountable safety can only be ensured within the
trusting period of the signing validator set, updates must be submitted to the chain
relay before the trusting period elapses. Otherwise, the chain relay expires and must
5.2. Concept 83
vtrustedNext
vtrusted
…
vtrustedNext
vtrusted
…
…
vtrustedNext
vtrusted
…
1st signs
Latest
final
block
…
references
bcurrent btarget blatest
current block
in chain relay
submitted to
chain relay
2nd / 3rd signs
vtrusted active
vtrusted active
vtrusted active
vtrustedNext active
vtrustedNext active
1st option
2nd option
3rd option
Figure 5.1: The chain relay always maintains one block header that is currently active. Two block headers must be submitted to update the
relay contract, the target block and the latest block that finalizes it. The three involved block headers may be part of different sync committee
periods, determining which sync committee signs the latest block and if the sync committee period transitions.
84 Chapter 5. Proof-of-Stake Chain Relay
be redeployed, including an initial trusted validator set. This is due to a potentiallyun-
bonded stake that permits colluding validators to sign blocks of multiple forks without
beingheldaccountable. Toretainaccountablesafety, observersmustdetectmisbehav-
ior and submit respective proofs to the source blockchain that applies slashing.
If the source blockchain protocol does not include slashing, the chain relay does not
need to adhere to such boundaries. Some protocols, such as Ethereum 2.0, apply ac-
countable safetyto full validation butnot for sync committees, as misbehavior in such
a subset would provide only limited accountability guarantees. Thus, the use of sync
committees for chain relay updates does not supply accountable safety.
5.3 Ethereum 2.0 Relay
Ethereum 2.0 utilizes the consensus algorithm Gasper, which implements two dis-
tinct concepts for block production and finalization, namely LMD GHOST and PBFT
inspired Casper FFG [49]. Casper FFG finalizes checkpoints by collecting votes in two
rounds that first justify a checkpoint before finalizing it. This process is derived from
the commit phases of PBFT and adapted to a permissionless setting. In Ethereum 2.0,
a checkpoint is defined as the first block of an epoch and implicitly finalizes all pre-
ceding blocks. Votes are collected in succeeding blocks, and checkpoints are finalized
as soon as a sufficient amount of votes has been collected. The proposed chain relay
provides finalized blocks that cannot be reverted. Therefore, two blocks must be sub-
mitted for updating the relay state: the finalized block btarget, which is to be stored by
the relay contract, and the latest block blatest, which declares btarget to be finalized. Ev-
ery block contains a reference to the currently active sync committee vtrusted and the
subsequent sync committee vtrustedNext. The relay contract verifies blatest byvalidating
the signatures according to either vtrusted or vtrustedNext, which are contained in the
currently stored block bcurrent. Depending on the sync committee period the blocks
fall into, three different scenarios need to be considered, as in Figure 5.1.
In the first case, all three blocks bcurrent,btarget, and blatest are part of the same sync
committee period. Therefore, the public keys of sync committee vtrusted included in
bcurrent are used to validate the block signature for blatest. As bcurrent has been success-
fully verified before, the referenced sync committee is trusted as well. Since no sync
committee update is needed, only the block headers btarget and blatest, a Merkle proof
that btarget is final according to blatest, and a multi-signature by vtrusted are required to
update the chain relay, as depicted in Table 5.1.
Inthesecondcase,bcurrent andbtarget arecontainedinsynccommitteeperiodofvtrusted,
while blatest is part of the successive sync committee period of vtrustedNext. Thus,
vtrustedNext referenced in bcurrent must be used to verify the multi-signature attesting
the validity of blatest. Because bcurrent and btarget reference equivalent sync committees,
there is no transition to a newly active sync committee. Even though blatest includes a
new sync committee reference, it is not applied, as the block has not necessarily been
finalized at the time of submission. As a result, compared to case one, the same data
must be passed to apply an update, but a different validator set is used for signature
validation.
5.4. Implementation 85
Lastly, bcurrent is part of the sync committee period of vtrusted, while btarget and blatest
are included within the sync committee period of vtrustedNext. Here, signature valida-
tion is performed analogously to the one in case two. However, a transition to a new
validator set occurs, transitioning former vtrustedNext to vtrusted and accepting a newset
for vtrustedNext. Thus, the submitted data mustinclude the succeeding sync committee
vnext and a Merkle proof that it is part of btarget, as detailed in Table 5.1. Since the suc-
ceeding sync committee is finalized, the updated committees vtrusted and vtrustedNext
are accepted and stored in the contract.
5.4 Implementation
We provide a prototypical chain relay implementation that enables the validation of
Ethereum 2.0 beacon chain headers on any EVM-compatible blockchain. The proto-
type is separated into the relay contract, hosted on the target blockchain, and an off-
chain client. While the relay contract is responsible for validation, the client retrieves
block headers from the beacon chain and prepares update transactions, including re-
spective proofs. No authorization is required to update the relay state, as the relay con-
tract validates submitted block headers. Users intending to update the relay contract
require access to a synchronized node of the source and target blockchain. The imple-
mentation is available on GitHub5under an open-source license.
Each operation of the EVM has a cost assigned to it that is measured in gas and paid
by the transaction sender using the host blockchain’s native currency [15]. To reduce
costs and enable lightweight updates, the relay contract requires only fractions of a
block to be submitted while maintaining full verifiability. Referenced parts are vali-
dated using Merkle proofs, which must be passed with every update. In contrast to
Ethereum 1.0, which uses a modified Merkle Patricia tree to represent block data, Eth-
ereum 2.0 implements a concept called SimpleSerialize (SSZ) for serializing data con-
tainers, which are represented in a binary Merkle tree [127]. As SSZ utilizes SHA256,
available asa cost-effective pre-compiled contracton Ethereum1.0, for computing the
Merkle tree, respective proofs can be verified efficiently on-chain.
TherelayclientpreparestheparametersaccordingtotherequirementsdepictedinTa-
ble 5.1. The latest and finalized blocks are represented by their Merkle root subsuming
their referenced content. The finalized block is referenced bythe latest block as part of
the current state, as illustrated in Figure 5.2. Since the sync committee used for vali-
dation is selected based on the block’s slot, the slot is passed along with a Merkle proof
of inclusion for both the latest and finalized blocks.
Our implementation provides two options for accessing the sync committee’s public
keys during validation. Option 1 requires passing the sync committee’s public keys
with every update transaction that results in the transition to a new sync commit-
tee. After that, the relay contract validates the respective Merkle proof and replaces
the stored keys of the current sync committee with the new ones. In Ethereum 2.0,
the sync committee consists of 512 members. Each member holds a public key that
is 48byte long, resulting in a total size of 512 ·48 byte = 24,576 byte. As the update of
5https://github.com/verilay/verilay
86 Chapter 5. Proof-of-Stake Chain Relay
slot
latest
block
state …
latest block
header
slot
final.
block
state …
current sync
committee
finalized
block header
next sync
committee
Merkle root
Merkle tree
node
data
container
…
…
signature
Figure 5.2: Simplified representation of required parameters in SSZ
structure. Bold borders and arrows represent the Merkle paths of in-
volved attributes.
a 32byte storage slot calls for 5,000 gas, the lower bound for updating the sync com-
mittee is 24,576 byte
32 byte ·5,000 gas = 3,840,000 gas, excluding validation, data processing,
and memory operations. The stored keys are retrieved from storage and used for each
update’s validation within the same sync committee period.
As storage operations require comparatively large amounts of gas, we provide a second
option that does not store the sync committee in the contract but demands all public
keys to be resubmitted with each update. The sync committee period only determines
which public keys to pass and validate but does not affect the transaction’s number of
attributes. Resubmissionofdatatoreducestoragecostshasbeenproposedinliterature
before [85, 167], but involved the calculation of a hash or Merkle root on-chain. As the
sync committee is part of the SSZ Merkle tree, this step can be omitted by the relay
contract. In Section 5.5, we show that Option 2 is beneficial even when updates are
submitted regularly.
Multiple steps are required to verify the signature of the submitted latest block. First,
the relay contract checks whether a sufficient amount of sync committee members
have participated. Ethereum 2.0 enables signature aggregation by applying Boneh-
Lynn-Shacham (BLS) multi-signatures based on the BLS12-381 elliptic curve [127,
141]. Operations on the BLS12-381 curve are conducted on 384-bit words. Since the
EVM operates on 256-bit words, the virtual machine cannot execute the operations
required to validate BLS signatures efficiently. The Ethereum Improvement Proposal
(EIP) 25376recommends the introduction of a pre-compiled contract to Ethereum 1.0
6https://eips.ethereum.org/EIPS/eip-2537
5.5. Evaluation 87
thatexecutesBLS12-381 curveoperationsoutsidethe EVM.Thepre-compiledcontract
willallowtheefficientimplementationofBLSsignaturevalidationwithinasmartcon-
tract. Other EVM-based blockchains like Celo7already support BLS12-381 operations
using pre-compiled contracts.
As no on-chain signature validation library is available at the time of writing, we ex-
tend the Go Ethereum (Geth) client with a customized pre-compiled contract that
conducts validations using the Herumi BLS library8. To validate a submitted block
header, the relay contract first serializes the sync committee’s public keys and the ag-
gregated signature before calling the pre-compiled contract. If the signature is valid,
all Merkle proofs are checked to ensure the correct finalized block is referenced, and
correct slots have been declared. Finally, the currently stored block header is replaced
with the submitted finalized block header.
5.5 Evaluation
In this section, we evaluate the presented concept according to its quantitative prop-
erties, such as on-chain execution costs and design goals, as defined in Section 4.2.
5.5.1 Quantitative Analysis
The chain relay’s applicability depends, in particular, on the complexity of the asso-
ciated on-chain computations. Complex computations and high storage volumes in-
crease transaction costs and may render transaction execution impossible if they ex-
ceed the limits of a block on the target blockchain. Therefore, we analyze transaction
costs for deploying the relay contract and applying regular updates. Since our chain
relay prototype operates on the EVM, we measure transaction costs in gas, as defined
by the Ethereum protocol [15].
While the Ethereum 2.0 specifications define a sync committee size of 512, we also
measure the costs of smaller sizes that result in reduced costs. Even though our eval-
uation proves the concept’s applicability for standard configurations of Ethereum 1.0
and 2.0, we outline that the impact of a smaller set is minor in Section 5.5.3. Figure 5.3
depicts the gas costs of three different configurations, using a reduced sync commit-
tee size of 32, applying the full set with 512 members while storing the set within the
contract, and resubmitting the set with every update, as described in Section 5.4.
We observe that the contract’s one-time deployment remains within the gas limits of
the Ethereum main network. Most gas is accounted for allocating storage for the sync
committee. Since the option to resubmit the set with every update does not require
this step, the respective contract deployment is significantly cheaper, as illustrated in
Figure 5.3. Furthermore, all operations on the smaller set are cheaper, as fewer storage
operations and signature aggregations are required. The most expensive transaction
is an update that includes a sync committee transition, as the respective public keys
must be passed and stored. Although requiring about 28.7 million gas, the transaction
remains within the block gas limitof the Ethereum main network, which is 30 million
7https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0031.md
8https://github.com/herumi/bls
88 Chapter 5. Proof-of-Stake Chain Relay
Figure 5.3: Gas costs for deploying and updating the chain relay. Three
different configurations are presented: storing sync committees of size
32 and 512 and not storing the sync committee of512 validators. The red
dashed line indicates the current block gas limit on the Ethereum main
network. B: Block. SC: Sync Committee.
as of February 2023. As expected, transitions of the sync committee are significantly
cheaper when resubmitting the sync committee’s public keys with every update, as
no storage write operations are required. Interestingly, update transactions that do
not include such transitions also call for less gas compared to stored public keys. Here,
our results deviate from the evaluation of a similar approach taken by ETH Relay [85].
We attribute this deviation to the Istanbul hard fork that included relevant changes to
gas metering. First, EIP 18849increased the costs for reading a storage value from 200
gas to 600 gas. Second, EIP 201810 reduced the price for passing call data from 68 gas
to 16 gas. We conclude that the described pattern is favorable when utilizing externally
submitted data, even when regular resubmission is required.
5.5.2 Qualitative Analysis
Inthefollowing,weanalyzetheconcept’scompliancewiththedesigngoalsintroduced
in Section 4.2 based on the presented prototype.
•Forkless. The suggested relay utilizes sync committees that are part of the Eth-
ereum 2.0 protocol and does not require the collaboration of validators specific to
the chain relay.
•Trustless. After bootstrapping the relaycontract, trust is solelyderived from the
source blockchain’s sync committee signatures. As the validation is conducted
on-chain, no trust in entities executing updates is needed.
•Autonomous. Anyone with access to the source and target ledger can submit
updates by executing the relay client.
9https://eips.ethereum.org/EIPS/eip-1884
10https://eips.ethereum.org/EIPS/eip-2028
5.5. Evaluation 89
•Robust. While Ethereum 2.0 applies a weakly subjective consensus algorithm,
sync committees do not hold this property. As a result, the relay can be updated
after arbitrarilylong periods of inactivity. The relaymayonlystall if no valid sync
committee signature is present for an entire sync committee period.
•Corresponding. Since block headers are validated by sync committee members
and a majority of at least 2/3 is assumed to be honest, relayed block headers are
also assumed to be valid. Merkle branches can be used to prove the inclusion of
transactions, states, and events.
•Lightweight. The concept is lightweight, as only a single block must be submit-
ted for each sync committee period. Since such a period subsumes 256 epochs of
32 slots, only a single update is required every 8,192 blocks, involving 17.7 million
gas. In comparison, a single block update using BTC Relaycalls for 194,000 gas,11
resulting in 1,589,248,000 gas for an equivalent number of blocks.
5.5.3 Security Considerations
The light client protocol of Ethereum 2.0 operates on a subsample of validators to de-
crease the verification complexity. Therefore, the provided security is also reduced
compared to the main consensus protocol. This section discusses the derived impact
on security, includingparameterization. Yet, a detailedsecurityanalysisofEthereum’s
consensus layer and light client protocol is out of the scope of this work.
In the following, we assume the distribution of malicious participants in the full val-
idator set and the sampled set to be equivalent. While validators are only account-
able for voting on submitted blocks in the main protocol, only non-participation is
slashed in the sync committee [87]. Therefore, a malicious sync committee collabo-
ration could resultin incorrectly signed block headers without being held accountable.
Yet, due to the large number of participants, such collaboration is unlikely, as depicted
subsequently.
Ethereum 2.0’s light client protocol defines a sample size of s= 512 [87]. While the
main protocol proportionally allocates voting weights to validators according to their
stake, we assume equivalent voting power for every validator. In practice, the voting
power deviates at most by a factor of two, as the amount of stake is bound between
16Eth and 32Eth [127]. Ethereum 2.0’s consensus is designed to withhold up to 1/3
of validators from acting maliciously [49]. Therefore, we consider equivalent require-
ments for the light client protocol, i.e., the security threshold defining the fraction of
honest participants is t∈(1
3,1]. The parameter tis selected as the minimum fraction
of parameters required to create an aggregated signature [81]. Thus, at least t·spar-
ticipants must sign a block to be accepted. We calculate the probability of malicious
actors signing a rogue block using the cumulative binomial distribution:
s
X
i=t·ss
i(b)i(1 −b)s−i
11Exemplary transaction ID of a Bitcoin header submission in BTC Relay:
0xe21099d8fd1252281389fc888f23f98e60db22ecb5c149ad6fda6dccdf110b50
90 Chapter 5. Proof-of-Stake Chain Relay
Assuming a participation rate of t= 0.8and a worst-case likelihood of a fraction of
b=1
3of participants behaving maliciously, the probability of successfully signing a
fraudulent block is:
512
X
i=0.8·512 512
i(1
3)i(2
3)512−i≈3.23472 ·10−104
Given that non-participation in the sync committee is slashed [87], the participation
rate t= 0.8is chosen conservatively. Therefore, the demonstrated probability of ma-
licious actors signing a fraudulent block is negligible.
5.6 Discussion
The evaluation of our implementation demonstrates the concept’s applicability under
the assumption that signatures applied by the source blockchain’s consensus protocol
can be efficiently validated. In the case of Ethereum 1.0’s EVM, this will be the case as
soon as the respective EIPs are applied. Other Ethereum derivatives like Celo have im-
plemented the required pre-compiled contract12 and can execute the presented chain
relay. The number of signatures that must be validated needs to be limited. Therefore,
Ethereum 2.0’s unbounded validator set cannot be efficiently validated, and we rely
on its light client protocol, which provides a sub-sample of predefined size. Since the
misbehavior of the sub-sample cannot be slashed, it is assumed that a majority of the
sync committee acts altruistically honest. Thus, the security guarantees are inferior
compared to the validation of the full validator set. Yet, some PoS protocols that do not
offer accountable safety operate fully under similar assumptions [18].
Validator set changes constitute a challenge to the relay if they are not efficiently ver-
ifiable. As succeeding sync committees are signed by a trusted set in Ethereum 2.0,
the chain relay does not need to re-execute the sampling. PoS protocols that require
all blocks of an epoch to calculate the next validator set may require the submission of
all respective blocks to the chain relay. Yet, this requirement may be alleviated if the
source blockchain’s protocol specifies limits for validator set changes. For instance,
Cosmos’ Tendermint consensus implements a respective light client protocol allow-
ing to skip the validation of intermediary blocks [82].
5.7 Conclusion
In this chapter, we proposed a chain relay that provides interoperability between
PBFT-inspired PoS blockchains and any blockchain capable of executing smart con-
tracts. We enable the submission of PoS block headers to a relay contract without re-
quiring trust in the executing entity, as submitted block headers are verified based on
the source blockchain’s consensus protocol. The source blockchain’s validator set is
utilized to perform signature validation on submitted block headers. The chain relay
only accepts finalized block headers and thus does not require fork handling. Since
12https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0031.md
5.7. Conclusion 91
PBFT-based PoS protocols provide finality, no fork handling is required, and submit-
ted blocks committo the entire blockchain history. Thus, the chain relayrequires only
a single update during each validator set period, providing a lightweight solution com-
pared to previous chain relay proposals.
The concept’s prototypical implementation constitutes a chain relay for the Ethereum
2.0 beacon chain and provides a relay contract operating on the EVM. Our evaluation
shows that the proposed solution is viable without requiring changes to the consen-
sus protocol of Ethereum 2.0. Recent blocks can be submitted upon finalization by the
source blockchain’s consensus. Since only two blocks must be submitted during each
sync committee period, which lasts 17.3 hours, execution costs decrease significantly.
Thus, our implementation demonstrates that PoS chain relays constitute a promising
solution for blockchain interoperability.
93
Part III
Smart Contract Portability
95
Smartcontracts aredesigned to providedecentralizedapplications executingarbitrary
logic based on a shared state. They inherit their host blockchain’s decentralization,
storage, and throughput properties and share them with other smart contracts de-
ployed to the same network. Yet, while designed to prevent single points of failures
and lock-in effects, there is a vendor lock-in toward the deployment blockchain. As
a result, smart contracts cannot be migrated between network instances, and com-
munication is limited to the host blockchain. This circumstance proves to be particu-
larlydisadvantageous if the properties of the hostblockchain or external requirements
change over time. For instance, the utilization may increase, resulting in increased
costs and delays, or the security may decrease due to decreasing participation in the
consensus protocol.
In this part, we present a novel cross-chain smart contract interoperability scheme
that alleviates the isolation of smart contracts toward the host blockchain. The pre-
sented interoperability schemes are not limited to single application domains such as
asset management but are generally applicable to smart contracts. The concepts re-
quire a trusted state root but are agnostic to the source. While mechanisms like notary
schemes may be used for this purpose, we suggest trustless protocols like chain relays.
Therefore, PartII of this thesis depicts the foundation for the presented smartcontract
interoperability schemes. The methods presented in Part II allow generic state proofs
across network boundaries. Thus, they are the enablers for resolving the tight binding
of smart contracts to their host blockchain in a trustless fashion, as elaborated in this
part.
In the first chapter of this part, we present smart contract forks, a mechanism allow-
ing any participant to migrate the business logic and state of a smart contract to an-
other blockchain instance. The migrating entity does not need control over the source
contract and can create secondary accounts reflecting an equivalent state. Similar to
blockchain hard forks, the initial smart contract instance continues to exist, and their
statesdivergeovertimewithdistinctusage. Asaresult,participantscanmigratesmart
contracts to benefit from the properties the target blockchain provides.
InChapter 7, we introduce the conceptofsmartcontract synchronization. While based
on smart contract forks, the secondary instance is synchronized to mitigate diverging
states. Synchronizations are performed in one direction only, from the primary con-
tract to client instances. The state of client contracts can only be modified via the syn-
chronization operation and not through general function calls. Since client contracts
are deployed and synchronized on secondary blockchain networks, other smart con-
tracts deployed to the same blockchain can use them to execute functions instantly.
Therefore, client contracts depict read-only mirrored versions of the original smart
contract allowing access across blockchain networks.
97
6 Smart Contract Forks
Smart contracts are designed to enable decentralized software execution on a shared
state without requiring a central authority. Yet, smart contracts deployed to a block-
chain generate dependencies on the underlying network instance. Over time, require-
ments regarding contract execution may detach from the utilized blockchain due to
contradicting incentives and security or performance issues. In this chapter, we in-
troduce the concept of smart contract forks, permitting users to flexibly migrate con-
tract logic and state between blockchains to avoid a novel lock-in effect towards a host
blockchain.
6.1 Motivation
Applications utilizing smart contracts have evolved in various domains such as sup-
ply chain management [5, 168, 169], social networks [170, 171], identity manage-
ment [172, 173] and energy marketing [174]. With a growing number of smart con-
tracts deployed to a single ledger, scalability is increasingly concerning. Furthermore,
during a smart contract’s life cycle, requirements may change. For instance, the ap-
plication scenario could shift from a public to a private environment or vice versa.
Similarly, the setting could require switching from a permissionless blockchain to
a permissioned implementation. Furthermore, other blockchains may better suit a
given use case due to novel functionality or scalability. In addition, blockchains host-
ing smart contracts may cease due to decreasing incentives, security issues, or cen-
tralization tendencies [23], mitigating deployed applications’ survivability, as defined
by Hardjono et al. [175]. Several attack vectors have been proven to threaten block-
chains [176, 177]. For example, despite inherent blockchain vulnerabilities such as
51% attacks, where attackers control more than 50% of the overall mining capabil-
ities, i.e., hashing power in PoW, nodes in the network can be isolated using Eclipse
attacks[176]. Incentives formaintainingablockchaindonotnecessarilyconformwith
those of smart contract users on the same blockchain [178]. This mismatch may lead
to the requirement of migrating a smart contract to another blockchain to mitigate
involved issues such as limited security, availability, innovation, scalability, or gover-
nance.
Similarly, attack vectors affecting secure contract execution do not exclusively arise
from underlying blockchains but also faulty contract implementations. The exposure
multiplies when referenced libraries comprise vulnerabilities, as in Parity’s multi-
signature wallet implementation in 2017 [179]. While referencing affected contracts in
98 Chapter 6. Smart Contract Forks
contractclones1couldnotrecoverlockedcryptocurrencydueto theirnativecharacter-
istic in Ethereum, it can restore asset contracts if users agree on a specific application
replication.
Transferring smart contracts between blockchains requires a shared execution en-
vironment. While ledger implementations such as Cardano2provide their own plat-
form for smart contracts, the Ethereum Virtual Machine (EVM) has been adopted by
a multitude of blockchains outside the Ethereum universe, such as Hyperledger Bur-
row3, Polygon4, Gnosis5, Quorum6, Qtum7, and Avalanche8. A smart contract written
in a high-level programming language like Solidity and compiled to EVM-compatible
bytecode is deployable to any blockchain supporting the EVM.
This chapter proposes a concept for cross-chain smart contract forks targeting
EVM-compatible blockchains. We present a tool implementing all required steps of
the migration process, namely execution code retrieval, state reconstruction, and
deployment-readybytecode generation. Furthermore, any blockchain participant can
verify the migration’s validity by comparing the roots of the original and novel state
Merkle trees. Therefore, no trust in the executing party is required as both smart
contract logic and state are publicly verifiable. Alternatively, trusted state roots—as
provided by chain relays—can be utilized to guarantee the correct migration between
blockchains. All transformations are performed in bytecode. As a result, the contract’s
high-level source code is not required for fork operations, enabling the migration of
smart contracts independent of contract owners or primary deploying instances.
6.2 Concept
Migrating smart contracts between blockchains poses multiple requirements. First,
both the source and target blockchain need to be able to interpret the given contract
code. We have identified a multitude of distributed ledgers implementing the EVM,
which provides a shared execution environment for such applications. Second, the
contract state in a given block of the source blockchain should be maintained and
transferred to the target blockchain. Third, the correctness of the ported application
should be verifiable.
To facilitate smart contract forks and portability to blockchains independent of the
source blockchain, we propose a migration process requiring multiple steps, as illus-
trated in Figure 6.1. Therein, several entities interact with the smart contract. In the
presented example, Alice develops the smartcontract in a high-level language such as
Solidity, compiles it to bytecode, and deploys it to blockchain A. After that, Bob exe-
cutes a setter function, effectively modifying a state variable. Then, Carol retrieves the
runtime code and state to port the contract to another blockchain, These components
are used for constructing a deploycode that stores identical contract code on the target
1https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1167.md
2https://developers.cardano.org/docs/smart-contracts/plutus
3https://www.hyperledger.org/projects/hyperledger-burrow
4https://wiki.polygon.technology/docs/category/smart-contracts
5https://docs.gnosischain.com/developers
6https://www.jpmorgan.com/global/Quorum
7https://qtum.org/en
8https://github.com/ava-labs/subnet-evm
6.2. Concept 99
Chain B
(target)
Chain A
(source)
Alice
deploy
contract address:
0x42...
Deploy code
a = 2
Bob
a := 5
Contract code:
0x6080...
State:
1. Replay all TXs
2. Create key/value
map
Carol
extract
contract
replay transactions
1. Preamble
2. Constructor: set key/value states
3. Code Copy instructions
4. Contract Code
create
bytecode
deploy
contract
address:
0x73...
State root: 0x1337
Dave
get
state root
State root:
0x1337
get (a)
a = 5
12 3
4
5
6 7
Figure 6.1: A smart contract is deployed and used on blockchain A. Its
state is reconstructed to create respective migration code for blockchain
B. The ported contract is verified by a third party not involved in the
migration process.
blockchain and sets all state variables equivalent to the source contract’s current state.
Finally, while not involved in the migration process, Dave can verify the equality of
both execution code and state between the source and target blockchain bycomparing
their state trie hashes.
Migrating smart contracts from one blockchain to another should not be limited to
contract owners or developers, as they represent centralized entities, weakening the
original idea of decentralization and independence from central authorities. All op-
erations are conducted in bytecode to achieve this target, providing flexibility and
security. The contract code is available to every participant in the network, and the
transferred code will be verifiably identical to the source contract. The deployed
contract code can be retrieved directly from Ethereum client nodes such as Geth or
OpenEthereum. A migrated contract constitutes an application fork since the origi-
nal contract remains unaffected. However, if the migrating entity controls the source
contract, it may be destructed by its owner if intended.
6.2.1 State Retrieval
All contained variables must be observed from the source blockchain to reconstruct
the contract’s state. Each smart contractmaintains a unique state tree holding all state
variables. Figure 2.5 presents an example of the impact on the state tree when modi-
fying a single variable in a smart contract. Changing the value associated with key 0x0
only affects its respective node and referencing nodes, while the remaining tree is un-
affected. The current state that is required for the contract’s migration is highlighted
in grey in Figure 2.5.
In order to provide an example of different kinds of variables available in Solidity and
to showcase how they are persisted in the state trie, we implement a simple smart
contract that is depicted in Listing 6.1. While retrieving the variables directly from the
Merkle tree byaccessing the node’s underlying key-value database would be sufficient
for single variables (cf. Listing 6.1, Line 4), as keys are numbered sequentially by the
100 Chapter 6. Smart Contract Forks
Listing 6.1: Example contract containing three different kinds of vari-
ables: integer mapping and smart contract reference.
1import "./ ReferencedContract . sol ";
2
3contract SimpleContract {
4uint256 a;
5mapping (uint256 => uint256) b;
6ReferencedContract referncedContr ;
7
8constructor(address _referncedContr) public {
9a = 42;
10 b[13] = 21;
11 referencedContr = ReferencedContract(_referencedContr);
12 }
13
14 function setA(uint256 _a) public {
15 a = _a;
16 }
17
18 function setB(uint256 key , uint256 val ) public {
19 b[ key ] = val;
20 }
21
22 function setRefVar ( uint256 _var) public {
23 referencedContr . setVar ( _var );
24 }
25 }
Solidity compiler [180], this is not the case for mappings and arrays (cf. Listing 6.1,
Line 5) or bytecode that was created using different compilers. To prevent Denial-of-
service (DoS) attacks that create Merkle trees with maximum branch length, keys are
hashed by the EVM so that the resulting key for allocating the variable in the Merkle
tree cannot be easily manipulated [181]. Therefore, when retrieving the keys from the
Merkle tree directly to create storage instructions, they would be hashed again dur-
ing the deployment, destroying the original mapping. By this means, the information
stored in the database is not sufficient for restoring its state on a another blockchain.
In the following, we present two techniques for retrieving the state of a deployed smart
contract. First, transaction are replayed for reconstructing the state. Second, client-
specific functionality is utilized for retrieving the storage keys of all values stored by a
smart contract. Selecting a suitable technique depends on the state size, synchroniza-
tion mode, and functionality the utilized blockchain client offers.
6.2.1.1 Transaction Replay
Since the state of a smart contract is the result of transactions storing or modifying
data, re-executing all past transactions allows for reconstructing the state. Ethereum
node implementations such as Geth and OpenEthereum provide a debug mode that
permits replaying past transactions [182, 183]. By this means, transactions are exe-
cuted locally to record state changes. State differentials do not only include affected
values but also their respective storage location in the state trie. A prerequisite for de-
bugging is a full node that does not perform trie pruning, as the entire transaction
history has to be available. To trace the outcome of transactions, the blockchain state
that existed before the transaction was mined is reconstructed, and the transaction is
6.2. Concept 101
executed, providing the corresponding output. As a result, all state changes can be ob-
served, providing information about the keys used in mappings and single variables’
keys used to allocate them in the contract’s key-value store. We utilize this mecha-
nism to reconstruct the smart contract’s current state.
All transactions sent to the smart contract must be discovered, including its initial de-
ployment transaction. To deploy smart contracts, the contract code is included in a
transaction that instructs the EVM to copy the respective code to a new account. In-
formation about deployed contracts is provided in the transaction’s receipt. Transac-
tion receipts are stored in a unique Merkle tree referenced in each block that has been
mined. As receipts are stored independently from the referenced account, all block-
chain transaction receipts must be explored from the current block back to the block
that holds the deploying transaction to examine if they are related to the target con-
tract. Due to the rapidly growing ledger size of the Ethereum main chain, iterating
over all transactions can be computationally intensive, depending on the contract’s
deployment time.
We extract transaction data into an external, structured data storage to efficiently
access all relevant transactions. Instead of querying a blockchain node directly, the
structured data is utilized for fast information retrieval. While maintaining an exter-
nal transaction database leads to significant performance improvements, it is optional
for successfully migrating smart contracts. All relevant transactions are fetched from
thisdatabase andreplayedsequentiallyusingan Ethereumarchive nodeto reconstruct
the final state, as illustrated in Figure 6.1. State changes resulting from transactions
are stored in a key-value store with the original key in place instead of the hashed key
that is persisted in the Merkle tree. As the transactions are replayed sequentially, we
eventually obtain the final contract variable state and store it in a key-value map.
6.2.1.2 Storage Key Collection
Replaying all past transactions is a method provided by most blockchain clients. Still,
it potentiallyinvolves significant overhead if the smartcontract was deployed long ago
or many transactions have executed its functions. Client node implementations such
as OpenEthereum provide more elaborate traceabilityfunctions thatpermit retrieving
all occupied keys of a smart contract [184]. As a result, the smart contract’s histori-
cal evolution can be neglected, as the client permits accessing all storage keys of the
current state. Therefore, the required key-value map can be retrieved by retrieving
all reserved keys of the smart contract and capturing the respective values based on
the keys. While this method incurs significant performance advantages compared to
replaying past transactions, it must be supported and activated by the client imple-
mentation.
6.2.2 Deployment Strategies
After receiving the smart contract’s bytecode and state, the deployment instructions
for applying the smart contract logic and state to another blockchain are generated in
bytecode. Weproposetwodistinctdeploymentstrategiesdependingonthe smartcon-
tract code and state size. As a smart contract’s state tends to grow over time due to an
102 Chapter 6. Smart Contract Forks
increasing number of variables stored in maps and arrays, storing the entire state dur-
ing deployment would exceed Ethereum’s gas limit. Therefore, the deploying trans-
action has to be aligned with the gas limit within the target chain.
6.2.2.1 Single Contract
Suppose the gas used for deploying the contract code and executing all instructions re-
quired to recover its state from the source blockchain is smaller than the target block-
chain’s gas limit. In that case, the migration is conducted within a single transaction.
For that purpose, we utilize the fact that the constructor is, while being part of the de-
ploy code, excluded from the actual contract code that is persisted on the blockchain,
as illustratedin Figure 2.4. Therefore, we generate anewconstructorthatrecreates the
source contract’s state from our produced key-value map. To create respective deploy
code, first, a static preamble is applied to set the correct memory pointer and handle
cryptocurrency that was sent with the deploying transaction, as demonstrated in Al-
gorithm 1, Line 2. After that, the storage instructions for each key-value pair observed
from the state are generated and appended to the bytecode (cf. Algorithm 1, Lines 3-
10). Here, the key and value are pushed to the EVM’s stack before calling the SSTORE
opcode. Furthermore, the byte size has to be calculated to select correct PUSH opcodes
ranging from 1 to 32 bytes in the EVM [15]. To observe the respective opcode, we utilize
the fact that all PUSH instructions are represented sequentially in bytecode so that the
length can be added to its lowest operation, as presented in Algorithm 1, Lines 5 and 6.
After setting all variables, the contract code copy instructions must be generated (cf.
Algorithm 1, Lines 11-16). As the location of the contract code within the deployment
code is required, it must be calculated using the constructor and the contract size be-
fore adding the corresponding bytecode. In the end, the contract code is included as it
was retrieved from the source chain.
Sending a transaction, including the generated deploy code, to the target chain results
in a new smart contract holding the identical contract code and state. The equality of
smart contracts can be verified byanyuser and is not limited to the transferring entity.
For verification, the source and target contracts are first retrieved from the respective
blockchain nodes and compared. Second, both contracts’ Merkle trees are retrieved
from the nodes’ databases. Only the trees’ root hashes need to be compared to guar-
antee the equalityof both states. Alternatively, a trusted state rootcan be used to prove
the correct migration. As a result, smart contracts can be forked either on the same
blockchain or between EVM-compatible chains. Due to the facilitated verifiability, no
trust in the entity performing the transferring process is required.
6.2.2.2 Proxy Contract
Ifthesourcecontractoritsstateistoolargefordeploymentwithina singletransaction,
the reconstruction process has to be split into multiple transactions. While adding a
function to the original contract code would permit iteratively setting the correct state
using transactions distributed over numerous blocks to avoid exceeding the gas limit,
such alteration mitigates the ported contract’s verifiability. Therefore, three contracts
are generated performing distinct tasks:
6.2. Concept 103
Algorithm 1: Create Deploy Code
input : S−Set of state variable key-value pair
C−Contract Code
output: D−Deploy Code
1begin
/* Add static preamble */
2D←0x608060405234801561001057600080fd5b50
3foreach s∈Sdo
4lkey ←byteLength(skey)
5lvalue ←byteLength(svalue)
6D←D . (opcode(P USH1) + lvalue −1)
7D←D . svalue
8D←D . (opcode(P USH1) + lkey −1)
9D←D . skey
10 D←D . opcode(SST ORE)
11 lcode ←byteLength(C)
12 D←D . (opcode(P USH1) + lcode)
13 D←D . lcode
14 D←D . opcode(DUP 1)
15 D←D . byteLength(D)
16 D←D . opcode(CODECOP Y )
1. The logic contract contains the source contract code without any alterations.
2. The proxy contract holds all variables and redirects all method calls to the logic
contract.
3. The initializationcontract is authorized bythe proxy contract to set its state vari-
ables and destroyed after the transfer operation is completed.
We utilize the EVM’s capability of calling a remote contract’s function while operating
on the calling contract’s state by using the delegatecall opcode [15]. As a result, the
deployed contract code is only responsible for maintaining the source contract’s logic
but is independent of its state. Instead, all state variables are managed within a proxy
contract implementing two functions: setting its state for porting the source state and
a fallback function that is executed every time an unknown method is called. The first
function is used to facilitate dividing the state recreation into multiple transactions.
As it is crucial from a security perspective that manipulating the contract state is only
permitted during an initialization phase, we define an authorized contract responsible
forthistask. Onlytransactionssentfromthisinitializationcontractareaccepted. After
all variables have been set in the proxycontract, the initialization contract is destroyed
so that it cannot be used for future variable modifications. Through this mechanism,
only the original contract state is part of the proxy contract, ensuring verifiability by
maintaining an equal Merkle tree compared to the source state. Therefore, the ini-
tialization contract’s address must be hard-coded into the contract code to avoid al-
terations to the state. The proxy contract’s fallback function is called every time the
EVM does not recognize the calling method’s signature. It forwards the method call
to the logic contract, including its signature and parameters. While the logic contract
executes the initiated function, it operates on the proxy contract’s state.
104 Chapter 6. Smart Contract Forks
Alice
Logic Contract
Proxy Contract
Initialization
Contract
deploy
deploy
selfDestruct()
return
Bob
deploy
setA(42)
return
setA(42)
return
return
setState
(keys[],values[])
return
Loop(1,x)
setState(keys[], values[])
Figure 6.2: Example ofdeployment and interaction process with a sep-
arate logic, proxy, and initialization contracts. The proxy contract al-
lows distributing the state initialization over multiple transactions for
large state sizes.
To embed correct reference addresses, the three distinct contracts should be deployed
in the same order as depicted in Figure 6.2. Bidirectional dependencies of proxy and
initializationcontracteitherrequiretheinitializationcontractto maintainarespective
state variable or the target address to be precalculated. In the first case, a function in
the initialization contract permits setting the reference contract. Instead, to decrease
gas costs resulting from additional deploy code and transactions, the referenced con-
tract’s address can be calculated bythe sender’s address and transaction nonce (trans-
action count) [15]. The calculated address is set in the contract’s bytecode, preventing
the requirement for any further setup.
After the contract migration is completed, users should address the proxy contract,
which forwards the method call to the logic contract but provides the state that was
ported previously. The source contract remains unaffected by the smart contract fork.
6.2. Concept 105
6.2.3 Dynamic Contract References
Smart contracts are not limited to isolated state variables but may refer to other con-
tracts deployed to the same chain, as exemplified in Listing 6.1, Line 6. These refer-
enced smart contracts may also maintain a mutable state. Thus, the correct execution
of smart contracts also relies on associated contracts and their state. To maintain such
connections during the migration process, references are extracted by iterating over
all state variables and checking them for valid addresses. After that, it is examined if
the addresses hold any contract code. If nothing is retrieved, we assume the address
refers to an externally owned account. Otherwise, it depicts a smart contract that is
migrated recursively. As a result, not only the target contract is migrated, but also
all dependencies. Such referenced smart contracts can be represented in a tree-like
structure that depicts all required migrations. As redeployed contracts retrieve new
addresses, respective references must be updated accordingly in the target contract.
Following historical migrations of referenced contracts, some dependencies may have
already been migrated to the target chain. Depending on the use-case, it may be ben-
eficial to either redeploy the contract, for instance if the state has diverted due to its
utilization during a given time disparity, or maintain the already deployed instance
in case it is intended to rely on its current state. To validate a migration process, it is
not sufficient to approve the root contract; all related contracts need to be considered.
For this purpose, transparency is required to indicate if all related contracts have been
redeployed during the migration or if it relies on other contract instances. Emitting
an event to publish all migrated dependencies during the migration process enables
participants to validate the entire dependency tree of smart contracts.
Replacing contract references in the state also modifies the resulting state trie. There-
fore, in this case, the correct state transfer cannot be validated by comparing the state
trie root hashes of source and target contracts. As a result, all values need to be verified
according to the claimed referenced contracts and unaffected state variables.
6.2.4 Static Contract References
Despite dynamic references to smart contracts, addresses may be encoded in the con-
tract code. Respective addresses can be declared directly in high-level code such as
Solidity or woven into the bytecode at compile time. For instance, when utilizing a li-
brary, such contracts are primarily constant, already deployed to the blockchain, and
do not change over time. To create a link between the newly deployed contract and
the library instance, smart contract tools like Truffle9permit specifying the library’s
address during the deployment process. It is then inserted into the bytecode accord-
ingly by the Solidity compiler. Similarly to dynamic references, static links must be
migrated recursively to the target blockchain to maintain existing contract connec-
tions. The bytecode is analyzed for dependencies using the contract analysis toolbox
Mythril10 to observe present static references. After migrating all corresponding con-
tracts, their source addresses are replaced with the newly retrieved target addresses.
9https://github.com/trufflesuite/truffle
10https://github.com/ConsenSys/mythril-classic
106 Chapter 6. Smart Contract Forks
As substituting addresses in the contract code leads to a failure in validation when
comparing source and target code, a map of replaced addresses is supplied by an event
emitted during the migration process. The correct deployment of contract code can
be validated using this map. Second, all migrated contracts are checked recursively
based on the address map. At this moment, the target contract is migrated, including
all relations in a transparent and verifiable manner.
6.3 Evaluation
We provide a toolbox that offers all proposed functionality to evaluate the feasibility
of the presented smart contract portability concept. It contains multiple components
targeting each step during the migration process and is published under an open-
source license on GitHub11.
All components retrieving smart contract code or related transactions and execut-
ing transactions utilize Ethereum nodes using the web312 library or direct JSON RPC
queries. Methods targeting debug operations, such as replaying transactions, are ex-
plicitly implemented to a given client. Thus, theyare notincluded in web3 butmust be
called explicitly. OpenEthereum and Geth and their forks, such as Quorum, are cur-
rentlysupported. Whilethestateis analyzedforobservingpossiblecontractreferences
within our implementation, we rely on the security analysis tool Mythril for extract-
ing static dependencies. As the storage root of smart contracts cannot be retrieved
from the available node implementations, we supply a validation tool for underlying
database implementations. The key-value database LevelDB is accessed directly, as
the Geth client utilizes it for storing blockchain data.
6.3.1 Scalability
We first analyze our implementation’s scalability regarding delay and gas required.
For this purpose, we implement a simple smart contract storing a mapping of un-
signed integers. The contract logic consists of a setter and getter function targeting
the stored mapping. After deploying the smart contract to the source blockchain, we
increase the number of stored values in the mapping in steps of ten variables, starting
with an empty mapping and increasing the size to 1,000. Thus, each of the 100 iter-
ations is subject to a different state size. The smart contract is forked and stored on
a second blockchain instance to measure the incurred delay and gas required for ev-
ery applied mapping size. We configure an instant mining Ethereum test network as
the target blockchain to exclude delays involved by fixed mining rates. Instant mining
describesthe creationofthe nextblockupon transaction retrieval[185]. The addedde-
lays induced byproduction deployments are nottaken into account, as theydepend on
their implementation and parameterization. The benchmark is executed on a server
equipped with an AMD EPYC 7262 8-Core Processor and 128GB RAM. Both test net-
worknodesruninseparateDockercontainers. Themeasureddelayincludesretrieving
transactionssent tothe target contract, their re-execution for reconstructing thecon-
tractstate, and thedeploymentto the target network. Since toolargetransactions may
11https://github.com/informartin/VeriSmart
12https://github.com/ethereum/web3.js/
6.3. Evaluation 107
0
2
4
0
10
20
0 250 500 750 1000
#values
Delay (sec)
Gas (Million)
Delay Gas
Figure 6.3: Delayand gas costs required creating a smart contractfork,
including state retrieval and deployment. Delay and gas scale linear to
the smart contract’s state size.
be ignored in production deployments, the transaction gas limit is set to 320,000gas.
The implemented fork client adjusts the number of key-value pairs set in one trans-
action accordingly.
Every contract holding different storage sizes is migrated once to provide insights into
the approach’s scalability. We observe minor noise in the measured time but can de-
rive linear scalability to the state size, as illustrated in Figure 6.3. While multiple runs
of all 100 iterations may reduce the noise and executions on different hardware may
result in different absolute delays, the approach is expected to scale linearly. Migrat-
ing the smart contract holding no values requires about 958.47 ms, and creating a fork
containing 1,000 key-value pairs takes approximately 5,222.61ms. Therefore, we de-
duce an added delay of about 4.26ms for every added key-value pair. Yet, since the
source blockchain is a local test instance only holding the smart contract to be mi-
grated, it also only contains transactions sent to this contract. Therefore, there is no
delay introduced by filtering non-relevant transactions. In production deployments,
such delays can be reduced by maintaining a database that can be efficiently queried
for relevant transactions. Furthermore, it is expected that the scaling is not only re-
lated to the state size, but also to the number of transactions. Every transaction adds
key-value pairs to the contract state in the presented setting. As every transaction
must be re-executed, a lower number of transactions adding more values to the map-
ping each would reduce the delay. Similarly, transactions modifying the state without
adding new values would increase the delay.
Like the incurred delay, the required gas for migrating a smart contract depends on
the storage size and scales linearly. Since the amount of gas is assigned to state ma-
chine operations, the measured gas only depends on the executed operations and is
independent of the executing machine. Creating a smart contract fork without stor-
age variables accounts for 743,989gas, while the migration of 1,000 key-value pairs
108 Chapter 6. Smart Contract Forks
requires 24,193,125gas. Thus, every additional key-value pair results in costs of about
23,449 gas. While the EVM’s SSTORE operation accounts for 20,000gas, the remaining
3,449 gas are caused by the costs for additional parameters and supplementary logic
for storing values [15]. In contrast to the delay, the incurred costs are independent of
the number of transactions sent to the source contract and only depend on the logic
and state size.
6.3.2 Token Contracts
As a major use-case for applications on Ethereum are token contracts [186], we ran-
domly choose a smart contract13 that implements the ERC-20 token standard14 to
prove the presented concept’s validity. A prerequisite for transaction tracing is an
archive node that does not perform state trie pruning. Therefore, we synchronize
the Ethereum main chain using the OpenEthereum client. Retrieved contracts should
then be ported to a public test network and a private, permissioned chain using several
node implementations.
For the selected contract, we observe 3,179 transactions sent to the given smart con-
tract at block height 6,837,908, including the deploying transaction. The recon-
structed state holds 759 key-value pairs. As storing a single variable requires 20,000
gas, storing all values in a single transaction would exceed Ethereum’s block size limit
that is configured to 8,000,000gas on the utilized test network. The implemented
toolbox automatically detects the needed gas and utilizes a proxy contract to split the
migration process into multiple transactions. Finally, the state root of the proxy con-
tract is verifiably identical to the source contract. Thus, we could demonstrate the
implementation’s applicability for token contracts between multiple blockchains.
Whenever the proxy contract is addressed after the migration, the call is forwarded
to the logic contract. As a result, the overhead of a delegate contract call is required,
resulting in additional gas costs of about 956gas. Therefore, the costs of deploying
three smart contracts instead of a single one and requiring additional gas for every
method call result in an inferior solution compared to the prior migration approach.
However, it applies toanycontract state size, and theadditionalgasdemand isminimal
compared to the costs of storing a single state variable taking 20,000gas alone [15].
While not intended, any user could call the logic contract immediately, potentially
changing its state. As the trusted state maintained on the proxy contract remains
unaffected, such actions do not constitute a security threat per se. Yet, malicious at-
tackers could execute unchecked self-destructions if the logic contract exposes such
instructions. As a missing initialization could lead to failures in authorization valida-
tion, the deployed contract code needs to be analyzed for such vulnerabilities in ad-
vance using tools such as Manticore15 or Mythril. Such added security implications do
not apply for single contract migrations, as they remain initialized.
13Contract address: 0x2A05d22DB079BC40C2f77a1d1fF703a56E631cc1
14https://eips.ethereum.org/EIPS/eip-20
15https://github.com/trailofbits/manticore/
6.4. Discussion 109
6.3.3 Contract Dependencies and Private Networks
We migrate the smart contract presented in Listing 6.1 to showcase the migration
of contracts containing dependencies on other contracts. The application is first de-
ployed to a permissioned Ethereum blockchain using the Geth client before it is trans-
ferred to a local Quorum node. Executing the migration process shows that all de-
pendencies are recursively resolved as expected. Yet, using Quorum as a target chain
reveals a limitation regarding verifiability. The Quorum client supports private smart
contracts which share their state only between authorized nodes in the network. Pri-
vate transactions are brokered in a dedicated constellation network and stored sep-
arately from the public state trie. While migrating contracts to Quorum in a private
environment is possible, the current migration implementation cannot validate re-
lated state variables. Though, we could prove smart contract verifiability for public
applications using Quorum.
6.4 Discussion
While the implemented set of tools for migrating smart contracts and verifying their
validity proves the concept’s soundness, potential issues evolving from underlying
blockchainimplementationsremain. Forinstance,blockchainsutilizingPoWforfind-
ing consensus and leader election suffer from absent finality guarantees [79]. As a
result, the state of a contract could be retrieved from a fork of the blockchain that is
not proceeded with due to inferior cumulative PoW. While validations may succeed as
longas theyare based onthe source fork, the contracts’ actual state coulddiffer insuch
cases. Hereby,usersassumeacorrectcontractmigrationwhile,infact,thesourcestate
has not been recorded in the origin ledger. In contrast, PBFT-inspired PoS blockchains
provide finality and, thus, do not suffer from this limitation.
The presented concept follows the assumption that the source and target ledger share
the same address pattern as defined in [15, Appendix F]. Onlyin this case can keypairs
be reused on the target chain to claim assets, permissions, etc. While substituting
addresses with those of the target chain could mitigate such issues, it requires prior
authentication of all affected users. Generally, this process would be comparable to
claiming token ownership on a newly deployed blockchain after participating in an
Initial Coin Offering (ICO). This process should be conducted on the source chain to
achieve verifiability. As a result, account ownership can be ensured, and information
required for validation is available to all participants.
Like any account in Ethereum, smart contracts can hold Ether, its native cryptocur-
rency. As an account’s balance is directly stored as a value in the account (cf. Sec-
tion 2.4), it does not affect the contract’s storage tree. Therefore, cryptocurrency held
bya contract does not mitigate the validation of transferred state variables. Yet, linked
native currency cannot be migrated to this point. Wrapped tokens may be used to
transfer respective tokens if the executing entity is authorized to administer stored
funds (cf. Section 3.2.2).
InEthereum,smartcontractscanemiteventsformultiplepurposes. Forinstance,user
interfaces may subscribe to events to observe updates to display current information.
110 Chapter 6. Smart Contract Forks
In other use cases, events are used as a cheap kind of storage, as they require less gas
compared to persisting information by utilizing state variables [5]. While such data is
only accessible externally, it may be crucial information depending on the application.
Currently, the presented concept does not consider the migration of events. As events
are bound to the block where the emitting transaction was mined, their migration to
another blockchain is impossible. Both source and target blockchain are required to
maintain associated information. Users should query the source blockchain until the
migration block and the target chain. A middleware forwarding requests to respective
nodes could ease accessing smart contracts which have been migrated during their life
cycle.
6.5 Conclusion
In this chapter, we have introduced a concept for facilitating smart contract forks be-
tween EVM-compatible blockchains. Trust requirements in the migrating entity are
mitigated by providing verifiabilityofcontract code and state to anyparticipant on the
ledger. Depending on the source contract’s size, two distinct concepts have been pro-
posed, enabling migrations of small contracts within a single transaction as well as a
set of three contracts to facilitate transferring large contracts in a verifiable fashion.
To showcase the concept’s soundness, we presented a toolbox implementing all com-
ponents of the proposed migration process. Respective contract runtime code is re-
trieved directly from the source chain, while all transactions that have been sent to
the contract are re-executed locally to reconstruct the current state. Alternatively, if
available, client-specific functionality can be utilized to retrieve required storage keys
and values efficiently. For applications that permitdeploying the fetched state in a sin-
gle transaction, a deploy code is generated that stores the contract’s logic and initiates
its state. Large contract states are migrated using a dedicated storage contract decou-
pled from its logic to maintain verifiability after a migration phase.
We could prove the validity of migrated contracts by utilizing an ERC-20-compliant
smart contract and a sample contract containing references to other contracts de-
ployed on the same chain. The evaluation of smart contracts using multiple distinct
blockchain clients provides evidence of the proposed concept’s applicability.
111
7 Smart Contract
Synchronization
The increasing fragmentation of blockchain networks and scalability solutions, such
as side-chaining and sharding, result in the isolation of hosted smart contracts. While
smart contract forks provide an efficient tool for effectively moving smartcontracts to
other blockchain instances, they do not permit cross-chain communication between
smart contracts. This section proposes a novel concept for cross-blockchain smart
contract interactions that creates client contracts on arbitrary blockchain networks
supporting the same execution environment. Client contracts mirror the logic and
state of the original instance and enable seamless on-chain function executions pro-
viding recent states. Synchronized contracts supply instant read-only function calls
to other applications hosted on the target blockchain. As a result, current limitations
in cross-chain communication are alleviated, and new forms of contract interactions
are enabled.
7.1 Motivation
Today, the communication between smart contracts is limited to a shared host block-
chain. As a result, smart contracts cannot utilize smart contracts hosted on distinct
networks, as developers have to choose an instance the smart contract is bound to at
deployment time. While many concepts have been presented to overcome this limi-
tation, current proposals to enable cross-chain function calls entail multiple trans-
actions on the initiating blockchain and cannot cater use cases that require instant
responses [30, 152, 153]. Furthermore, contracts must be adjusted to support cross-
chain calls, as specific message formats and fallback functions are required to process
return values.
Due to the limitations of current cross-chain solutions, use cases that require up-to-
date read-only access cannot be implemented efficiently. For example, registries such
as the Ethereum Name Service (ENS) provide mappings between human-readable
names and a plethora of attributes. These attributes may include account addresses of
a set of blockchains. A link is created between multiple user wallets on various block-
chainnetworks that maybe utilized for further processing or transfers. Forinstance, if
a user decides to register a name on Ethereum [14] and stores their account addresses
of Ethereum and Polkadot [78], this information is currently only available on Ether-
eum. It cannot be used by applications hosted on the Polkadot network. By providing
cross-chainaccesstosuchregistries, usersareenabledtoperformasinglenameregis-
tration on a blockchain of their choice and use it across multiple blockchain networks.
112 Chapter 7. Smart Contract Synchronization
One of the most prominent application domains enabled by blockchain technology is
DeFi, which provides financial products without involving intermediaries. Most DeFi
applications require trusted data, such as price feeds, that is typically delivered by or-
acles [42]. As an alternative to external oracles, Automated Market Makers (AMMs)
like Uniswap have proven to provide reliable on-chain price estimations [187]. Up to
now, only smart contracts hosted on the same blockchain as the AMM could benefit
from the provided data. Allowing smart contract queries across blockchain networks
will permit hosting applications on the best-suited blockchain while retrieving data
feeds cross-chain.
We enable such use cases and remedy shortcomings of isolated smart contract states
by developing a novel concept for smart contract synchronization across blockchains.
Here,asecondarycontractiscreatedonthetargetblockchainthatreflectsthelogicand
current state of a smart contract on the source blockchain. State updates are synchro-
nized byregularlyapplying storage proofs verified based on a trusted storage root. Our
approach is agnostic to the storage root source and is thus applicable to chain relays,
notary schemes, sharding as proposed for Ethereum 2.0 [49], or related concepts such
as Polkadot [78] or Cosmos [123]. While smart contract calls are currently limited to
their host blockchain or shard, smart contract forks provide synchronized replicas of
remotely hosted smart contract instances. These replicas provide all view functions of
the original contract. As a result, external contracts can execute the logic of a contract
that was initially deployed on another blockchain network to retrieve verified infor-
mation. To prove the concept’s soundness, we provide a prototypical implementation
and publish it under an open-source license.
The contributions presented in this chapter are as follows: We propose a novel con-
cept for synchronizing smart contracts across multiple blockchain networks and in-
troduce a new form of state transition confirmation to facilitate trustless, lightweight
state updates. A prototypical implementation is provided and published, including an
off-chain client and respective smart contracts. The prototype is used to prove the
concept’s feasibility and evaluate implied operational costs.
7.2 Definitions
In this section, we introduce common terms used in the following. We base our con-
cept on the assumption that two blockchain instances Aand Bexist in parallel and
support the same execution environment for smart contracts. Information is only
transmitted in one direction from Ato B. Therefore, we also refer to Aas source and B
as target blockchain in the following. To exemplify the applicability of our concept, we
presume an Ethereum-like implementation of state storage for our model [15]. Thus,
themodelincorporates an account-basedmodel to representthe staterather than uti-
lizing UTXOs [13].
Each blockchain comprises a sequence of block headers H. We denote HA
tas the head
of blockchain Aat time tand HA
t+1 as the subsequent block header. Block headers hold
information proving their validity according to the applied consensus algorithm and
a reference to the current state. The global state is defined as the union of all account
7.3. Concept 113
states. Each account is identified by an address and owned by external users or smart
contracts. Every account holds a state composed of a set of key/value pairs f:K→V.
We define the state of contract Cat time tand instantiated on blockchain Aas
S(CA
t) = {(k1, v1),(k2, v2), ...(kn, vn)}.
The Merkle hash tree function mmaps the entire state to a storage root R, so that
m:S(CA
t)→R(CA
t). The Merkle proof Q(R(CA
t),(k, v)) proves that (k, v)∈S(CA
t).
Equivalently, S(HA
t)represents the global state and the respective Merkle hash tree
function maps an account CA
tto the global state root R(HA
t), so that Q(R(HA
t), CA
t)
proves CA
t∈S(HA
t). Note that S(CA
t)⊆S(HA
t).
7.3 Concept
The objective of smart contract synchronization is to provide instant read-only access
to a smart contract that was initially deployed to another blockchain. Instant access
is characterized as an on-chain function invocation that terminates in a single trans-
action. A secondary smart contract is created on the target blockchain that mirrors
the original source contract. Hereby, the smart contract’s functionality and the state
become available to other smart contracts on the secondary blockchain for retrieving
information, e.g., through getter methods, while changing its state is prevented. Con-
sequently, smart contracts hosted on a remote blockchain can be used within a single
transaction, asthe state migrationfinalized previously. Furthermore, complexqueries
can be achieved on-chain following the original contract logic.
As a prerequisite, a smart contractfork is created to migrate the logic and currentstate
of the target contract onto a secondary blockchain. In contrast to smart contract forks,
onlythosefunctionsnotmodifyingthestatearecallable. Wepresentasynchronization
mechanism that ensures only valid state updates are applied.
7.3.1 Synchronization Conditions
As the smart contract state may divert from the forked instance over time, a mecha-
nism for synchronizing the state is required. Given the decentralized nature of block-
chain applications, we derive the following conditions that must be met to guarantee
valid state updates:
•Equality. The secondary contract’s state must reflect a state of the primary that
was valid at a given point in time according to the source blockchain’s consensus
rules.
•Completeness. The entire state must be captured, including new, updated, and
deleted variables.
•Succession. Each synchronization update must reflect a state that succeeded the
previous state.
•Trustlessness. Correct execution must not depend on any trusted intermediary.
114 Chapter 7. Smart Contract Synchronization
Frequent synchronizations are required to provide valid states over time. Thus, the
depicted conditions are expected to be met during synchronization. The frequency
must be defined by the referencing contract, as different applications may have dis-
tinct needs in terms of timeliness.
7.3.2 Initialization Process
Before a smart contract can be synchronized, its state and logic must be duplicated
via a smart contract fork. While smart contract forks permit the external validation
of the migration across blockchains, synchronization requires a trusted state root to
perform recurring on-chain validation. Before the source contract’s state can be ap-
plied on the target blockchain, its bytecode and state must be retrieved by replaying
past transactions or using a blockchain client’s extended database access.
Contractseparation. Similartoasmartcontractforkmigratinglargestates, theorigi-
nal contract is split into dedicated logic and proxy contracts. The proxycontract main-
tains the contract state and delegates all function calls to the logic contract, which in
turn executes function logic based on the proxy contract state. This pattern enables
the implementation of migration and synchronization logic within the proxy contract
while keeping the source contract’s logicseparated. As a result, thecontractlogic’s va-
lidity is maintained, as it is not modified. The proxy contract supplies setter methods
that enable distributing the initialization over multiple transactions. After the entire
stateis replicated, thesetter methodsare disabled, onlypermittingstatemodifications
via the synchronization method.
Verification. Since smart contract synchronization requires the on-chain validation
of the equality states, the fork validity is also permitted using a trusted state root. As
a result, no external validation is necessary before utilizing synchronized smart con-
tracts. For this purpose, a global synchronization contract is introduced on the target
blockchain tracing and verifying all migrated smart contracts from a specific source
blockchain. After successfully migrating a contract, a transaction is submitted to the
synchronization contract indicating the migration is finished. To prove its correct-
ness, two Merkle proofs are submitted: Q(R(HA
t), CA
t)and Q(R(HB
t+x), CB
t+x), where
x≥1. They both depict account proofs indicating the existence of a specific account
tuple on the respective blockchain. The first proof guarantees the submission of a cor-
rect contract state and is verified using the source blockchain’s state root. The second
proof confirms the correct application of the contract’s source state on blockchain B.
We assume header HB
t+xis available to the contract as a historical state. For instance,
Ethereum permits accessing header hashes of the 256 most recent blocks [15]. If the
target ledger does not provide the respective block hash to smart contracts, the con-
tract state’s Merkle root can be computed within the synchronization contract during
submission.
7.3.3 Synchronization Process
The objective of smart contract synchronization is to provide a secondary instance of
a smart contract on a remote blockchain. The contract state is synchronized regularly,
providingaccesstoits currentstatetoarbitrarycontracts onthe secondaryblockchain.
7.3. Concept 115
a = 5
b = 3
TX 1 TX 2 TX 3
a = 5
b = 3
a = 5
b = 3
a = 6
b = 3
a = 7
b = 4
a = 6
b = 4
a = 6
b = 4
Contract C:
Blockchain A
Contract C:
Blockchain B
Fork Synchronize
a = 5
b = 3
Figure 7.1: Simplified contract state capturing the initial migration and
synchronization of a diverted state. Green highlighting indicates trans-
action triggered value changes, purple illustrates the initial fork state
and blue marks synchronized values.
The synchronization process is unidirectional. Thus, the primary contract remains
unaffected by derived synchronized contracts. Furthermore, the secondary contract’s
state is only modifiable by proving that the state was obtained from the primary con-
tract. As a prerequisite, we assume a smart contract fork is created and verified as
depicted in Section 7.3.2. To capture all conditions and challenges for smart contract
synchronization, we first introduce a naïve approach and elaborate our concept based
on it in the following.
7.3.3.1 Naïve Approach
The state of smart contracts is the result of executed contract logic that is triggered by
transactions. As the objective of smartcontract synchronization is to replicate the pri-
mary contract’s state and the state is derived from transactions, it is intuitive to record
all past transactions sent to the contract on the primary blockchain and apply them
on the secondary blockchain. For instance, Figure 7.1 illustrates a contract CAthat is
forked and deployed to blockchain B. Three transactions are sent to CAmodifying its
state in the following. To reflect the resulting state on CB, all three transactions would
have to be executed sequentially on blockchain B. The synchronization contract first
verifies the inclusion of each transaction on Ausing a Merkle proof attesting its inclu-
sion in a block thatis provided by the relay contract. After that, the correct sequence is
confirmed, i.e., no transaction maybe skipped, and the submission must adhere to the
correct order. The same state will be reached as on the source contract byre-executing
all transactions. However, multiple challenges exist following such an approach.
Transactions cannotbe re-executed natively, as the account matching the signing key
pair either does not exist on the target blockchain or is likely to be in a distinct state
compared to the source blockchain. Furthermore, corresponding accounts must hold
sufficientfunds to compensate for transaction fees, and a linked nonce is incremented
everytimeatransactionissent. Thus,allaccountshavingsenttransactionstocontract
Con blockchain Amustholdsufficientfundsandbe in an equivalentstate. In addition,
transactions are targeted to a specific address necessitating equivalent addresses on
both blockchains. As these requirements can not be guaranteed, native execution of
source transactions is not applicable.
116 Chapter 7. Smart Contract Synchronization
A
B C
D E F
G H I J K L M
Key
Value
0x00
0x12
0x03
0x32
0x42
0x20
0x17
0x08
0x84
0x13
0x48
0x30
0x72
0x29
N
O P
Q R F
G S J KT
0x00
0x12
0x42
0x84
0x02
0x44
0x84
0x13
0x17
0x08
0x03
0x00
A
B C
D E F
G H I J K
0x00
0x12
0x03
0x32
0x42
0x20
0x17
0x08
0x84
0x13
State Tree Multi-Proof
Transition Confirmation
Client
Computation
On-Chain
Computation
Key
Value
Figure 7.2: Left: Merkle tree of an account state derived from source
chain. Right: Multi-proof of an updated state: 0x03 is deleted (red),
0x42 is modified (yellow) and 0x02 is added (green). Bottom: Transi-
tion confirmation calculated on the target chain.
Alternatively, transactions could be executed in an emulated environment. For in-
stance, in the case of Ethereum, the EVM could be implemented within a smart con-
tract executing every transaction decoupled from the sender’s account state and con-
tract address on the target blockchain. However, such emulation will come at the cost
of increased complexity and, thus, execution costs. Despite the inherent additional
fees for synchronization, it cannot be guaranteed that all transactions can be repli-
cated, as the limit of execution steps within a block may be exceeded. As a result, an
attacker could create a transaction executing complex logic to prevent its replication
on the target ledger, effectively stalling contract synchronization.
Replaying every single transaction also incurs overhead concerning storage opera-
tions. Figure 7.1 presents anexample where variable aisfirst changed fromsix to seven
before being changed back to six. While the result is equivalent, these operations can-
not be subsumed and must be executed sequentially. Moreover, to prove the inclusion
of every transaction, respective storage roots must be provided by the relay contract.
As a result, optimized concepts that reproduce only a subset of historic storage roots,
such as the efficient chain relays presented in Part II of this thesis, cannot be utilized,
inducing overhead during synchronization.
7.3.3.2 Verifiable State Updates
We present a method that utilizes state proofs for synchronizing contract states across
blockchains to solve the shortcomings of simple transaction replication. Instead of
proving the inclusion of transactions sent to the source contract, the resulting state is
used for updates. To prove the presence of a particular key-value pair in the contract
7.3. Concept 117
state, two Merkle proofs are required. First, the account proof Q(R(HA
t), CA
t)docu-
ments the inclusion of an account tuple within a block header H, where R(HA
t)is the
global state root at time t. Second, storage proofs notarize the inclusion of a specific
key-value pair Q(R(CA
t),(k, v)) in the account state, where R(CA
t)is the account state
root at time t. Applying these proofs on the target ledger permits proving the addition,
change, or deletion of single key-value pairs. Proving the result of executed transac-
tions rather than replaying state transitions results in more efficient state updates in
case of multiple write operations at a single key location. For instance, Figure 7.1 de-
picts multiple updates of multiple values. Utilizing storage proofs permits skipping all
intermediary changes and applying the verified final result.
The application of single key-value proofs meets all conditions defined in Section 7.3.1
but Completeness.Equality is met as the combination of account and storage proof en-
sures thepresented key-value pair existed on blockchain Aatsome time. Onlyupdates
newer than the previous update are accepted. Succession and Trustlessness are estab-
lished via the utilized state root. Furthermore, anyone can submit account and stor-
age proofs, rendering the entire process open and verifiable. Completeness, however,
is not assured, as storage proofs are independent from each other. An attacker could
submit only a subset of state updates to induce an inconsistent state. While it would
be impossible to add variables that are not part of the source contract, delete variables
that have not been deleted or modify values that have not been modified, concealing
a subset of state updates poses a severe vulnerability. Figure 7.2 depicts a state transi-
tion S(CA
t)→S(CA
t+x), where x > 0and includes three updates. To fully capture the
state transition, all three updates must be applied via dedicated storage proofs. How-
ever, this would require trust in the executing entity and therefore violate the Trust-
lessness condition. Moreover, submitting a single storage proof for each modification
creates considerable overhead, as each proof must be verified independently. To over-
come both issues, we introduce transition confirmations based on multi-proofs.
7.3.3.3 Multi-proofs
Multi-proof describes a mechanism for proving the inclusion of multiple values us-
ing a single proof and has been proposed to overcome inefficiencies when querying
multiple values [66]. We utilize multi-proofs for efficient validation and a basis for
transition confirmations.
While common Merkle proofs reflect a path within the respective Merkle tree, multi-
proofs share nodes of paths and thus depict sub-trees with substituting hash val-
ues where the tree was pruned. As a result, a set of key-value pairs can be included
in a proof Q(R(CA
t),{(k1, v1),(k2, v2), ..., (kn, vn)}), indicating that {(k1, v1),(k2, v2), ...,
(kn, vn)} ∈ S(CA
t). For instance, to prove the inclusion of keys 0x00 and 0x03 in Fig-
ure 7.2, only the leaf values and two branch hashes of the successive two layers of the
tree are required. The efficiency of multi-proofs depends on the index of the target
leaf values. The more branches are shared, the more efficient a multi-proof becomes
compared to single proofs.
Whereas multi-proofs increase efficiency, they do not solve the threat of withholding
parts of the resulting state. Thus, completeness cannot be guaranteed. Attackers could
submit valid multi-proofs, including only a subset of key-value pairs involved in the
118 Chapter 7. Smart Contract Synchronization
original state transition. Updating the secondary contract state by applying a multi-
proof could thus result in an inconsistent state.
7.3.3.4 Transition confirmations
The objective of transition confirmations is to guarantee Completeness. Thus, the en-
tire state transition result must be captured, including all create, update, and delete
operations. Transition confirmations are not submitted externally but computed on-
chain based on a multi-proof. As the source contract’s state is not accessible from the
target ledger,1we utilize the fact that the latest target contract state S(CB
t+x)equals the
primary state S(CA
t)of original state transition S(CA
t)→S(CA
t+y), where y > x > 0.
The submitted multi-proof Q(R(CA
t+y),{(k1, v1),(k2, v2), ...(kn, vn)})indicates the in-
clusion of respective key-value pairs given the Merkle root, but fails to create a link
to the previous state S(CA
t). Transition confirmations create such a link by replacing
all values of the multi-proof’s key-value set with the original values of the state tran-
sition. The original values are available during the computation, as they constitute
the target contract’s current state S(CA
t) = S(CB
t+x). Therefore, they are retrievable
by reading from the respective key location on the ledger. While the multi-proof’s
leaf values are substituted, the actual paths remain equivalent. As a result, it is en-
sured that the entire state is captured, as withheld state updates would be reflected in
changed paths. The computed transition confirmation depicts a valid multi-proof of
the initial state S(CB
t+x)if all changed values of the state transitions are reflected in the
submitted multi-proof:
Y(R(CA
t+y),{(k1, vt+y
1),(k2, vt+y
2), ...(kn, vt+y
n)})→
Y(R(CB
t+x),{(k1, vt+x
1),(k2, vt+x
2), ...(kn, vt+x
n)})
Thus, thetransitionconfirmation is validated equivalentlyto a multi-proof. We expect
the computed Merkle root to equal the previous state’s Merkle root if all changes were
captured and different otherwise, as illustrated in Figure 7.2. The rationale is that a
multi-proof is a pruned version of the original Merkle tree and includes those key-
value pairs modified during a state transition. Withholding a subset of updates will be
disclosed by this kind of transition check, as the withheld set is captured in a hashed
branch:
Y(R(CA
t+y),{(k1, vt+y
1),✘✘✘✘
✘✿ ∅
(k2, vt+y
2), ...(kn, vt+y
n)})↛
Y(R(CB
t+x),{(k1, vt+x
1), ...(kn, vt+x
n)})
When computing the transition confirmation’s Merkle root, it becomes evident that
theresultis differentfromthe originalrootif the submittedmulti-proofisincomplete.
While the sole validation of a multi-proof could not capture the state transition de-
picted in Figure 7.2, the computed transition confirmation ensures correct state up-
dates. For instance, let us assume an attacker submits a multi-proof including state
1Submitting Merkle proofs for each primary key-value pair would be possible but requires considerable
overhead that is avoidable by accessing the currently synchronized state on the target ledger.
7.3. Concept 119
Blockchain A
Client
Primary
Contract: C
transactions: TXs
proof
synchronize
(accountProof, multiProof)
verify
accountProof
getStorageRoot
storageRoot
Blockchain B
Client
verify
multiProof
1
2
3
6
7
8
create
optimized
Merkle proof
return
verify
transition conf.
create
transition conf.
9
updateState 10
4storageProofs
Synchonization
Client
getAccountProof(C)
getTransactions(C)
5
Relay
Contract
Secondary
Contract
(State Proxy)
getStorageProofs(keys)
stateDiff
replay(TXs)
Figure 7.3: The client retrieves state changes and respective proofs
to compute a multi-proof. The multi-proof is submitted to the target
chain that computes the transition confirmation and validates both. Af-
ter that, the state is updated, rendering equivalent states for the source
and target contract.
updates at keys 0x03 and 0x24 but withholds the value addition at key 0x02. The val-
ues at key locations 0x03 and 0x42 are read from the target ledger and inserted in the
multi-proof to build the transition confirmation. As Node P remains unaffected, the
tree root would be calculated from nodes Band Pinstead of Band C, resulting in a
hash different from A. Thus, it becomes evident that an incomplete multi-proof was
passed, and the state update is aborted.
7.3.3.5 Workflow
Combining accountproof, multi-proof, and on-chain computed transition confirma-
tion enables verifiable state replication of smart contracts across multiple blockchain
instances. The following depicts the required steps to synchronize state updates from
a primary contract to a secondary client contract hosted on a remote blockchain. The
entire workflow is illustrated in Figure 7.3.
The process is initiated byany entity motivated to update an expired state on the target
blockchain. Motivation may be intrinsic, as a depending smart contract of interest
requires a recent state, or it maybe triggered externally through a monetary incentive
system. As external incentive layers exceed the focus of this work, we refer to [35, 85,
120 Chapter 7. Smart Contract Synchronization
135] for further reading and leave its application on the presented concept for future
work. The external entity runs a synchronization client with access to client nodes of
blockchains A and B.
After retrieving the account proof from the source client, all transactions sent to the
smart contract since the last update are retrieved and replayed locally (Steps 1-3).
Replaying respective transactions results in a set of key-value pairs representing the
consequential state update. If the source client node supports a so-called fat database
modethatstoresallstoragekeysofasmartcontract, thestatemayberetrievedwithout
replaying the transaction. Thus, Steps 2and 3would be substituted with two calls
retrieving the initial and resulting states. Yet, in case the state is large, this procedure
requiresmorecomputationaleffortcomparedtothere-executionoftransactions. This
is especially the case if synchronization is applied regularly since only a few transac-
tions are to be expected. After that, a storage proof is retrieved from the source node
for each key-value pair (Step 4 ) and combined to a multi-proof (Step 5). Both ac-
count and multi-proof are submitted to the proxy contract on the target blockchain in
Step 6. The account proof verification takes place within the proxy contract and pre-
sumes a respective block header to be available within the relay contract. If the block
header is unavailable, the relay contract must be updated accordingly before starting
the synchronization process. After verifying the multi-proof, itis used forcreating the
transition confirmation that ensures all state updates are included in the multi-proof
(Steps 7-8). While the multi-proof utilizes the Merkle root stored in the passed
account proof, i.e., the new storage root, the transition confirmation is based on the
current storage root stored within the smart contract and updated for each synchro-
nization. If the transition confirmation is deemed valid, the state updates included in
the multi-proof are applied to the proxy state (Steps 9-10 ).
Utilizingtheresultingstoragestateofthe sourcecontractpermits subsumingmultiple
transactions to reduce storage and execution costs. If the state update is too large to be
executed within a single transaction, a previous state subsuming fewer transactions
must be utilized first.
7.4 Evaluation
We provide a prototypical implementation of the synchronization concept to evaluate
its applicability, scalability, and execution costs. The implementation permits fork-
ing and synchronizing smart contracts between blockchains supporting the EVM and
is published2under an open-source license. The prototype provides a client with a
command-line interface to retrieve states and proofs from the source blockchain, cre-
ate corresponding multi-proofs, and submit them to the target blockchain. Further-
more, a proxy contract is supplied that retrieves, validates, and applies state updates,
delegates read-only function calls to the logic contract, and prevents write operations
otherthansynchronizations. Theexecutioncontextmustbestatictopreventthedele-
gationoffunctioncallsthatwouldmodifythestate. Currently,thereisnonativeopera-
tion for retrieving the execution context within the EVM. Acorresponding EIP is under
2https://github.com/disco-project/smart-sync
7.4. Evaluation 121
600
800
1000
2 3 4 5 6
Storage height in Merkle tree
Gas used (Thousand)
Storage size 10 100 1000
Figure 7.4: Gas costs required for updating a single value at different
storage heights in the Merkle tree.
reviewat the time of writing. Until EIP 29703is implemented, we utilize a workaround
proposed in the EIP description that involves emitting an event to check whether the
transaction can change the state. If the operation fails, the context is deemed static
and non-static otherwise. When retrieving a function call, the proxy contract’s fall-
back function is executed, as it is the default operation in case the function signature
is unknown. The fallback function checks whether the execution context is static and
delegates the call to the logic contract. As a result, the executed logic operates on the
state of the proxy contract, which is a replica of the source contract.
7.4.1 Execution Costs
Theapplication ofsmartcontractsynchronizationentailsexecutioncostsonthe target
blockchain. As the concept is agnostic to the state root’s source, we neglect the evalu-
ation of related application costs. Multiple contracts are deployed and synchronized to
determine the gas costs of synchronization operations. Each contract holds a mapping
of different sizes, resulting in storage tries of variable depth.
First, we analyze the costs of updating a single value depending on its index in the
Merkle tree. As indicated in Figure 7.4, the costs increase with the value’s storage
height within the tree, as the corresponding Merkle proof requires more nodes to be
submitted. Each additional node results in increasing costs for parameter size and
proof validation. Large contract storage sizes lead to deeper Merkle trees and thus
drive synchronization costs. Furthermore, execution costs depend on the node types
included in the Merkle proof. Ethereum utilizes modified Merkle Patricia trees to store
values [15]. We observe that proofs containing more extension nodes are cheaper than
3https://eips.ethereum.org/EIPS/eip-2970
122 Chapter 7. Smart Contract Synchronization
0
5
10
15
20
0 25 50 75 100
#values
Gas used (Million)
Storage size 10 100 1000
Figure 7.5: Gas costs required for updating multiple values using a sin-
gle multi-proof.
those containing branch nodes, as depicted in Figure 7.4 for heights three to six. Since
branches contain up to 17 elements, more bytes mustbe passed compared to extension
nodes holding two items.
Second, we evaluate the gas costs when updating multiple values in a single synchro-
nization transaction. As for single values, updates incur fewer gas costs for smaller
storage sizes, as depicted in Figure 7.5. Synchronization costs per value decrease with
an increasing number of values subsumed in a single transaction. Thus, gas costs in-
crease sub-linearly. As multi-proofs share nodes of the original Merkle tree, fewer
nodes have to be submitted and validated the more nodes are shared. The effect can
particularly be observed when a large share of the total storage is modified since many
nodes in the Merkle tree are shared, as illustrated by the storage size of 100 in Fig-
ure 7.5.
While no other concept exists permitting instant read-only calls, GPACT allow asyn-
chronous cross-chain calls (see Section 3.3.1.2) [30]. Since GPACT function calls are
conceptually most similar to cross-chain synchronization, we use it as a baseline to
evaluate our approach. Reading a value using GPACT is independent of the smart con-
tract storage and requires 495,049gas. In contrast, the transaction costs for synchro-
nizing smart contracts depend on the storage size and number of values updated. For
instance, updating a single value ata storage size of ten requires 471,334 gas and is thus
comparable to GPACT. Updating multiple values drives costs. For example, updating
all ten values stored in a smart contract calls for 883,397 gas. Therefore, the costs for
smart contract synchronization are only higher compared to GPACT if multiple values
are updated but enable instant on-chain calls on the target blockchain.
7.4. Evaluation 123
0.1
0.2
0.3
0.4
23456
Storage height in Merkle tree
Time (sec)
Storage size 10 100 1000
Figure 7.6: Time required for updating a single value at different stor-
age heights in the Merkle tree.
7.4.2 Synchronization Delay
Time-critical applications rely on a low delay. Therefore, we measure the latency of
synchronizationupdates,includingtheretrievalofstateproofs,computationofmulti-
proofs, and execution on the target blockchain. The benchmark was executed on a
machine equipped with an Intel Xeon CPU E3-1230 v6 @ 3.50GHz and 64 GB mem-
ory. Source and target blockchains are private Ethereum networks performing instant
mining. We measure the delay based on different contract storage sizes and investi-
gate the impact of the target value’s storage height within the Merkle tree. For this
purpose, we retrieve the stored keys and calculate the height within the storage key.
After that, we select one key-value pair for each height and storage size and modify
its value before synchronizing the smart contract to observe the approach’s scalabil-
ity. The single execution on a specific machine provides an intuition concerning the
order of magnitudes of the expected delay and impact factors. Our results show that
updating a single value takes between 64ms and 69ms for storage size 10, 83ms and
99ms for storage size 100, and 342ms and 421ms for storage size 1,000, as illustrated
in Figure 7.6. The storage size significantly impacts the delay, while the target value’s
location within the Merkle tree is negligible. While some noise is monitored, partic-
ularly for storage size 1,000, there is a clear indication of the storage size dominating
the delay. The delay in retrieving an entry from the database depends on the Merkle
tree size and motivates EIP 18844, which suggests repricing the SLOAD opcode. There-
fore, the observed delays are aligned with the delays induced bythe blockchain clients’
database operations.
Since we expect more than one key-value pair to be affected by updates in most cases,
the approach’s delay is measured based on the number of migrated values. Figure 7.7
4https://eips.ethereum.org/EIPS/eip-1884
124 Chapter 7. Smart Contract Synchronization
0.0
0.5
1.0
1.5
0 25 50 75 100
#values
Time (sec)
Storage size 10 100 1000
Figure 7.7: Time required for synchronization including different up-
date set sizes.
depicts the delay in synchronizing key-value pair batches within three storage sizes.
The migration of 10 values requires 71ms for storage size 10, 120ms for storage size
100, and 511 ms for storage size 1,000. Thus, we observe the same pattern for updat-
ing a single value; the synchronization delay depends on the underlying storage size.
The delay develops approximately linearly. Some noise is observed as expected when
observing a single execution, but we derive linear scalability with the slope depend-
ing on the storage size. This observation is aligned with the expected scalability since
retrieving Merkle proofs requires more database operations, and their verification in-
volves more EVM procedures. The synchronization of 100 values leads to a delay of
406ms for a storage size of 100 and 1,449 ms for a storage size of1,000. As the involved
latency remains well within the block mining times of most blockchain networks, the
concept is suitable for applications requiring timely updates.
Compared to GPACT, the latency of smart contract synchronizations is expected to be
lower since theydo notrequiresignalingmessages[30]. While no exacttime measures
are available for GPACT, at least three blocks are mined before a value can be read, as
messages are sent sequentially. In contrast, smart contract synchronizations could
be conducted with a delay of only a single block if supported by the applied state root
transfer protocol, such as sharding or notary schemes.
7.5 Discussion
Different use cases have specific requirements for the refresh period of depending
smart contracts. For instance, DeFi applications typically rely on up-to-date data,
while registries such as the ENS do not change as regularly. Smart contract synchro-
nizations can cater to both use cases, given the storage root is updated in time. Chain
7.5. Discussion 125
relay and target contract can be updated in the same block as the calling contract exe-
cution to provide the mostrecent state. For instance, when a contract is called thatde-
pends on a recent state of a remotely hosted contract, three transactions could be sent
within a single block. First, the storage rootmustbe updated, for example, by utilizing
a chain relay. Second, the contract state has to be updated by calling the proxy con-
tract. Last, the application can query the synchronized contract as any other contract
on the target blockchain. Thus, recent states can be provided as long as an up-to-date
storage root is available. If the concept is applied to provide accessibility across shards,
the utilization of synchronized contracts may behave equivalently to locally hosted
contracts.
Synchronized smart contracts may also depend on other smart contracts. Synchro-
nizing only a single contract without considering dependencies could lead to unex-
pected behavior. Therefore, all referenced contracts and libraries must be migrated
and synchronized. Previous work on smart contract forks proposed the analysis of
logic and state during migration and recursively deploying dependencies [3]. As con-
tract addresses change during deployment, they are substituted for each reference.
Replacing addresses in the state results in a distinct state and thus Merkle root, lead-
ing to complex verification during deployment. In the case of synchronizations, the
exact mechanism could be applied. As the contract’s Merkle root is deemed valid af-
ter migration, the computed transition confirmation also utilizes a valid root and does
not need to be modified to create valid results. Therefore, the presented concept is
applicable even if reference addresses were replaced during the initial migration.
The presented concept promotes read-only access for synchronized smart contracts
and does not provide cross-chain write operations. While other approaches target
such write access [29, 30], multiple steps, including locking, are required to main-
tain atomicity. As a result, the process is time-intensive and may lead to additional
overhead if the timeout period is exceeded. Therefore, our solution leaves the respon-
sibility of invoking transactions across multiple blockchains to the external applica-
tion. Depending smart contracts hosted on another blockchain network are put in the
desired state that is subsequently proven on the target blockchain. Thus, the result-
ing state becomes accessible through simple function calls. Time-consuming locking
mechanisms are mitigated, and instant function execution is enabled on the target
blockchain.
The synchronization scheme assumes that the source and target blockchain share the
same execution environment, for instance, the EVM. Furthermore, the smart contract
storage must use the same Merkle tree variant to guarantee correct state updates. Dif-
ferent execution environments or storage methods prohibit trustless transition proofs
and are, therefore, out of the scope of this work.
While our evaluation focused on the EVM and the Ethereum blockchain, the solution is
not limited to these protocols. In addition to classic blockchain networks, smart con-
tract synchronization could also be performed on scalability solutions allowing smart
contract execution like sidechains and layer-2 solutions.
Sidechains are pegged to another blockchain but may provide enhanced throughput
126 Chapter 7. Smart Contract Synchronization
and lower transaction fees [155]. For instance, Polygon’s PoS chain5provides a bridge
to the Ethereum main network and offers the execution of EVM contracts. While the
scalability of updating states is aligned with our evaluation when using such side-
chains, transaction costs can be significantly lower compared to the main chain. In
addition, other contracts deployed to sidechains may require instant read-only access
to referenced contracts. Therefore, the synchronization of smart contracts can act as
an enabler to those contracts using sidechains for scalability reasons while utilizing
main chain contracts.
The execution costs of smart contract synchronizations constitute a challenge to their
adoption. Layer-2 concepts propose off-loading transaction execution from the block-
chain to increase throughput and decrease costs [188]. Multiple approaches exist. For
instance, optimistic rollups allow the off-chain execution of transactions, while ob-
servers can challenge the results ifmisconductis detected [189]. Another conceptthat
recentlygainedtractionisusingzero-knowledgeproofstoguaranteecorrectoff-chain
transaction execution [189]. Since transactions do not have to be executed by all net-
work participants but only a small set, layer-2 concepts generally scale well and incur
less execution costs. However, data availability is a challenge and typically depicts one
ofthe main cost drivers if storage is performed bythe host blockchain, for example, by
using transaction call data. Therefore, smart contract synchronizations would partic-
ularlybenefitfromtheefficientvalidationofMerkleproofs. Althoughzero-knowledge
proof-based layer-2 solutions such as zkSync 2.0 are still in their test phase, they de-
pict a promising scalability solution in future implementations of smart contract syn-
chronizations, as they facilitate the efficient execution of EVM contracts.
7.6 Conclusion
In this chapter, we presented a novel concept for synchronizing smart contracts across
multiple blockchain networks. The state of a remotely hosted smart contract is syn-
chronizedperiodicallyina verifiable manner. Notrustin executingentitiesisrequired,
enabling all participants to perform state updates. Furthermore, we introduced tran-
sition confirmations thatprove correct smart contractstate transitions on a secondary
blockchain based on a multi-proof. As the entire smart contract is migrated from
the source blockchain, the contract’s state and logic become accessible on the target
network. As a result, instant read-only function calls by depending smart contracts
are rendered possible, facilitating use cases such as cross-chain registries or oracles.
Our open-source implementation proves the concept’s soundness and demonstrates
timely updates of contract states.
In the future, the presented solution will foster overarching architectures that in-
clude off-chain components and on-chain workflows executed on multiple block-
chains. Providing atomicity within such workflows depicts a potential task for future
research. Required state updates are initiated sequentially and become available after
synchronization. Thus, smart contract synchronization constitutes a foundation for
applications that utilize smart contracts across multiple blockchain networks.
5https://polygon.technology/solutions/polygon-pos/
127
Part IV
Applications
129
The objective of the concepts presented in Parts II and III of this thesis is alleviating
the tight binding between smart contracts and their host blockchains. Efficient chain
relay concepts enable the trustless migration and synchronization of smart contracts
betweendistinctblockchainnetworks. Whiletheperformedevaluationoftheconcepts
allows the analysis of their practicability and scalability, no conclusions can be drawn
about their applicability to actual use cases. We present three use cases in this part
representing decentralized applications in different fields to evaluate the feasibility of
the smart contract interoperability concepts presented in this thesis.
Supply chain traceability is one of the most promising use cases to benefit from block-
chain characteristics such as decentralization, immutability, and transparency with-
out requiring intermediaries or bilateral trust between entities. Many blockchain-
based supply chain traceability solutions have been proposed recently [41, 168, 190].
Due to the highly interconnected nature of global production chains, no single block-
chain network can be expected to cover the needs of all use cases in the field [169].
It is to be expected that a multitude of blockchain networks will evolve, which ful-
fill industry-specific requirements, for example. Since supply chains exhibit global
cross-industry dependencies, interoperability between these blockchain networks is
paramount. In Chapter 8, we present a supply chain use case based on digital tokens
requiring cross-blockchain smart contract interoperability to provide traceability of
processed goods. We elaborate on the application adjustments required to handle pro-
duction processes ondistinct blockchains. Inaddition, smartcontract forksare used to
permit the migration of token contracts to the best-suited host blockchain at a given
time.
In 2022, the changed ownership of the centralized OSN Twitter and the accompany-
ing transition in moderation policies have led to a growing interest in decentralized
alternatives [191]. While decentralized OSNs enable federations of service providers to
interoperate, users depend on provider-specific identifiers [192]. Blockchain-based
identifier registries facilitate self-sovereign identity management to overcome this
vendor lock-in. Users create publicly available links from a registered identifier to a
backend that provides OSN services. However, the blockchain instance hosting the
registrymaylockusers inifnomigrationorinformationretrievalfromotherinstances
is possible. In Chapter 9, we present a blockchain-based OSN and investigate if cross-
blockchain smart contract interoperability techniques can mitigate novel lock-in ef-
fects toward the registry’s host blockchain. We show that smart contract forks and
synchronization increase users’ flexibility by allowing them to migrate registries and
reusing identifiers across multiple blockchain networks.
DeFi enables financial services without requiring intermediaries and has become one
of the most used blockchain applications [193]. Many DeFi applications require or-
acle data such as price feeds to operate [42]. Despite external providers, such data
can be provided by other smart contracts like Decentralized Exchanges (DEXs). How-
ever, sufficientutilization is required to provideprecise estimates. Since therespective
smart contracts are bound to their host blockchain, the same restriction holds for gen-
erated oracle data. Therefore, there is a risk of many applications accumulating on a
single blockchain to benefit from data provided byother applications. Providing cross-
blockchain smart contract interoperability alleviates this limitation by providing read
130
access to remotelyhosted smart contracts. Therefore, developers can choose the best-
fitting blockchain instance when deploying an application while benefiting from data
generated on another instance. Further, the mechanism prevents the concentration of
smart contracts on one blockchain, as the isolation of networks is mitigated. In Chap-
ter 10, we apply smart contract synchronization to a DeFi application and emphasize
its delay in the evaluation since timely data is typically required. For this purpose, we
synchronizeoneofthemostusedDEXsbasedonUniswapbetweentheEthereummain
network and the Görli test network.
131
8 Token-based Supply Chain
Traceability
Supply chain traceability is one of the most promising use cases to benefit from block-
chain characteristics such as decentralization, immutability, and transparency. To-
day, many variations of blockchain-based supply chain traceability exist, incorporat-
ing different degrees of smart contract interaction. Due to the potentially high num-
ber of transactions and varying privacy requirements, scalability and access control
are paramount. Therefore, many blockchain networks catering to different needs are
expected to operate in parallel. As a result, blockchain interoperability is required to
achieve end-to-end traceability. In this chapter, we present an exemplary use case for
supply chain traceability utilizing smart contract interactions to trace the composi-
tion of goods across multiple production steps. We show how such a use case could be
applied on a single blockchain network and which adjustments are required to enable
tracing across blockchain networks. For this purpose, we utilize the concepts pre-
sented in Parts II and III of this work and demonstrate how they enable cross-chain
applications.
8.1 Motivation
Providing traceability of goods from resource to retailer has become increasingly im-
portant in the past decade. Consumers are more interested in consuming goods that
comply with certain ecological and ethical standards [194]. Global supply chains have
become complex to a greater extent, hampering quality management in manufac-
turers’ procurement [195]. Furthermore, regulations, international standardizations,
and increased consumer awareness imply novel requirements for supply chain man-
agement systems. For instance, the European Parliament postulates food traceability,
requiring food suppliers and market actors to provide information about the prove-
nance of goods [196]. In addition, the ISO 9001:2015 standard instructs organizations
to monitor the identifiability and traceability of products and services.
To copewith these requirements, supplychainmanagementsystems should ideallybe
operated by multiple business partners to trace a product’s origin and transformation
process. However, traditional supply chain management systems are operated iso-
lated from other participants and cannot provide comprehensible provenance infor-
mation [197]. Shortcomings include insufficient trust between parties, isolated data
storage, and unsatisfactory standardization in communication and data formats [169,
198].
132 Chapter 8. Token-based Supply Chain Traceability
Blockchain technology has been proposed for providing enhanced traceability in sup-
ply chains [58, 168, 169, 199, 200]. Major drivers originate from typical blockchain
characteristics such as decentralization, verifiability, and immutability that could
tackle the observed shortcomings.
In contrast to existing solutions, we foster a representation mechanism for the con-
vertibility of products. Instead of only projecting physical goods onto the blockchain
in the form of tokens, our target is to document their transformation in the produc-
tion process on the ledger. We, therefore, propose a set of smart contracts that handles
modifiable goods by capturing their creation, transformation, and exchange on a dis-
tributed ledger. As a result, not only the good’s origin is traceable but also its inputs.
We tackle two requirements for supply chain management that conventional systems
cannot deliver comprehensively [201]. First, customers are empowered to review a
product’s and its ingredients’ quality in various dimensions, such as environmental
and labor standards. Second, in the context ofqualitymanagement, the proposed sys-
tem enables manufacturers to monitor the supply chain for multiple tiers rather than
relying on information provided by suppliers.
Since the proposed concept requires smart contract interactions to enable traceabil-
ity production processes, external information retrieval does not suffice. Distribut-
ing the application to multiple blockchain networks requires cross-chain state access.
The following presents the concept of tracing manufacturing processes using multiple
smart contracts deployed to a single blockchain. Then, we discuss scenarios requir-
ing blockchain interoperability during the application’s life cycle. After that, cross-
blockchain solutions are presented based on the concepts presented in Parts II and III
ofthis work. The concept presented here for tracking goods is one of the drivers moti-
vating the cross-chain techniques developed in this thesis. Due to the focus on block-
chaininteroperability, wesubsequentlypresent abriefintroduction tothe blockchain-
based supply chain traceability solution and refer to [5] and the extended version [6]
for a more detailed description.
8.2 Concept
We propose a blockchain-based, decentralized supplychain management system uti-
lizing smart contracts. The concept is based on two key ideas: representing phys-
ical goods in the form of digital tokens and recipes that enable their transforma-
tion. To provide comprehensive provenance information to consumers and produc-
ers, we maintain the relationship between resources and products in manufacturing
processes. Additional functionality like certifying goods, transferring, splitting, and
combining tokens facilitates cross-business traceability.
8.2.1 Tokenization of Products
For each type of good managed in the supply chain, a smart contract is set up. Within
such a smart contract, non-fungible tokens that represent physical goods can be cre-
ated. One token corresponds to one batch of goods that could be measured in items,
weight, volume or size.
8.2. Concept 133
Resource Suppliers Producers Logistics / Retailers Consumers
Forester
Glue plant
Sawmill & Factory
Hardware store
Figure 8.1: The production process is projected onto digital tokens us-
ing smart contracts in an example supply chain. Every minting, trans-
fer, and consumption operation is recorded when executed bythe token
contract.
The batch size is flexible, so that large quantities of goods, but also single entities are
manageable. The tokens are non-fungible, meaning that each token is unique. This
allows distinguishing between batches of the same type of good. To apply this concept
to the physical world, the contract owner would create digital tokens that correspond
to manufactured products. For instance, Figure 8.1 illustrates the production and trade
of edge-glued wood [197]. Two base products are required during production: wood
and glue. Every producer in the production chain creates a smart contract unique to
their product. The producer mints a token for every physically produced good. When
the product changes ownership, the token is transferred accordingly.
8.2.2 Recipes for Product Transformation
In order to digitally represent a manufacturing process, several tokens can be trans-
formed into a new token. When creating a new smart contract, the product compo-
sition is defined. Comparable to a recipe, the creator specifies the number of input
goods and corresponding amounts required for creating a new product. Following the
recipe, when a batch of goods is to be created, the contract owner must possess the
required input goods in sufficient amounts. The specific batches of input tokens need
to be specified so that they can be consumed by the smart contract automatically. If a
batchofunitsisnotentirelydepleted, theremainingunitsarekepttobeusedforfuture
manufacturing. Onlycontractownerscan generate token batches, as acontract always
corresponds to a specific producer’s or supplier’s product. However, token owners can
split, merge, transfer and consume batches.
As the product recipe should be immutable to guarantee the comparability of minted
batches, it cannot be changed after the token contract’s deployment and applies to all
minting procedures. When minting a token, the number of units within the batch and
the used components’ information need to be passed, as exemplified in Algorithm 2.
Within the minting function, it is first ensured that the declared array sizes are equal
and comply with the recipe size (Line 2). Afterward, it is checked whether enough
units were used according to the recipe for each component(Lines 4-5). Furthermore,
used contract addresses and those defined in the recipe are compared (Line 7). The
component’s contract is called, and the batch is reduced according to the amount that
was declared (Line 9). Finally, a batch identifier and a token holding owner informa-
tion as well as its size are created (Lines 10-13).
134 Chapter 8. Token-based Supply Chain Traceability
Algorithm 2: mint(u, Ic, Ib, Iu)
recipe : Rc−array of contract addresses of required inputs
Ru−array of required units
input : u−units to mint in batch
Ic−array of input contract addresses
Ib−array of input batches identifiers
Iu−array of input units
output: identifier of the newly added token
1begin
2if |Iu|=|Ib|=|Ic|=|Rc|then continue
3else revert
4for i←0to |Rc| − 1do
5if u∗Iui≥Ruithen continue
6else revert
7if Ici=Rcithen continue
8else revert
/* Calling external contract to reduce batch content */
9(Ibi∈Instance(Ici)) ←consume(Iui)
10 tokenId ←keccak256(u, Ic, Ib, Iu, msg. sender, time)
11 token.owner ←msg. sender
12 token.amount ←u
13 tokens[tokenId]←token
8.2.3 Traceability
The physical production process is fully reflected on the blockchain. It works across
multiple entities, as they can only proceed with the correct inputs. Every step of the
production process is accountable; therefore, traceability is provided for a single good
and its ingredients. Depending on the interval in which new blocks are added to the
blockchain, the block creation timestamp informs about the time and date a given
product has been manufactured. As products are handled in batches, input informa-
tion is available by batch. For example, a batch of edge-glued wood could be traceable
to a batch of 100 logs, as illustrated in Figure 8.1. In order to accomplish traceability
for single goods, they should be declared as their own batch. However, fine-grained
traceability comes with the cost of higher transaction counts.
8.3 Cross-Blockchain Interoperability
The deployment of smart contracts to a single blockchain network for enabling supply
chain traceability results in multiple issues we are addressing in this section by dis-
tributing the application to multiple networks and applying cross-chain techniques.
We apply two kinds of smart contract cross-blockchain interoperability and explain
their implementation to the use case in the following. First, the application is dis-
tributed to multiple blockchain networks operating cross-chain. Second, smart con-
tract portability is applied to allow producers to migrate smart contracts to another
blockchain if requirements or external conditions change.
8.3. Cross-Blockchain Interoperability 135
8.3.1 Cross-Blockchain Deployment
In production deployments, supply chain traceability applications are expected to be
distributed to multiple blockchains [202]. Global supply chains are complex, and a
single blockchain network cannot handle the high transaction volume. In addition,
there may be different requirements toward throughput, latency, privacy, and costs,
resulting in a set of blockchain instances serving different needs. For instance, indus-
trial consortia could operate blockchain networks to enhance supply chain traceability.
However, since the types of resources required during the production process can vary
widely, there are interdependencies across the boundaries of individual industries. As
a result, cross-blockchain deployments require a means for interoperability.
In the presented supply chain traceability concept, traceability is maintained across
multiple production steps, allowing users to observe the source of components and
resources. For this purpose, the tokens of input components used in the production
process are burned when minting a token representing the produced good reflecting
the production process. As depicted in Line 9 of Algorithm 2, this process is atomic
since the input tokens are consumed within the minting transaction by calling the
respective smartcontract function. However, the minting function can only call smart
contracts if they are hosted on the same blockchain instance.
Enabling cross-blockchain smart contract interoperability requires access to a trusted
staterootacrossblockchainnetworks. Staterootscan be providedvia anotaryscheme,
a chain relay, or a relay chain when interoperability between shards of a blockchain
network is targeted. Especially suited to public blockchain settings, chain relays pro-
vide a trustless mechanism for sharing state roots. Therefore, we propose the applica-
tion of efficient chain relays as presented in Part II of this thesis for permitting cross-
chain state retrieval.
Since direct function invocations are infeasible if the referenced smart contract is de-
ployed to a different blockchain network, the presented supply chain traceability con-
cept must be adjusted to support cross-blockchain deployments. Delegated cross-
chain function calls as proposed by Nissl et al. depict a potential solution but involve
economic assumptions increasing complexity and costs of the application [29]. Dedi-
cated to cross-blockchain tokens, Borkowski etal. synchronize the balances of a token
across blockchain networks, but the concept relies on external intermediaries [116].
Further, message-based protocols like XCMP or IBC permit triggering smart contract
functions hosted on a remote network but require multiple transactions on the inti-
tating blockchain and, therefore, involve increased latency [152, 153]. The synchro-
nization of token contracts could provide all needed information for minting tokens
but would require storing indications of burned tokens in the state. Storing additional
values would result in increased execution costs. In addition, the entire state would
have to be synchronized while only the burn token event is relevant.
We propose an alternative solution enabling the smart contract deployment to mul-
tiple blockchain networks while maintaining the application’s functionality based on
a trusted state root, preferably provided by a chain relay. In a single network setting,
the token contract’s minting function is directly invoked by the burn function of the
inputs’ token contracts. The cross-chain-aware concept requires input tokens to be
136 Chapter 8. Token-based Supply Chain Traceability
burned before calling the minting function. Instead of the minting function perform-
ing direct function invocation to deplete input tokens, the contract owner must prove
the completed burn operation to mint newtokens. For this purpose, the user burns the
input tokens hosted on any blockchain network connected via a relay scheme. During
the burn transaction, the smart contract emits a burn event attesting the amount de-
pleted, the address of the target product to be minted, and a production counter an-
nounced by the target product contract. The target product’s address and counter are
required to prevent double-spending. Every supply chain token contract keeps an in-
cremental counter indicating which batch is created next. When minting a token, the
user submits the transaction receipt including the burn event. The smart contract ver-
ifies if sufficient amounts of input goods have been burned according to the product’s
recipe. In addition, it checks whether the input goods have been burned as inputs to
the target product and batch. As a result, users cannot reuse events as inputs to dif-
ferent products or batches.
In the case of Ethereum, every block stores the receipts of executed transactions, in-
cluding emitted events. The transaction receipts are included in a dedicated Merkle
tree. Block headers comprise the respective Merkle root and permitproving the inclu-
sion of transaction receipts. Therefore, we can use the block headers provided bychain
relays to enable cross-chain proofs of emitted events. Algorithm 3 depicts the adjusted
minting function, including proof validation. Before minting a new token, the block
headers, which include the burning transactions of input tokens, must be verified by
the respective relay contract. In addition to the source token contract address, the
token recipe must include the address of the chain relay providing block headers of
the host blockchain. The minting function verifies the Merkle proof’s correctness and
whether the relay contract has stored the block header (Lines 6–8). In addition, it
is checked if the emitted event confirms the correct target contract, amount burned,
and counter value of the target contract (Lines 10–17). If all checks pass, the token
is minted and redeemed to the message sender, i.e., the contract owner (Lines 20–
23). As a result, multiple transactions are required to enable tracing production pro-
cesseswhen distributingthe application to multiple blockchainnetworks. Whileaddi-
tional delays and transaction costs are expected, the system allows interoperable sup-
ply chain traceability across industries and consortia.
8.3.2 Smart Contract Forks
Supply chain traceability applications’ requirements and external conditions may
change during their life cycle. For example, the current host blockchain may become
insecure and involve low throughput, high latency, or high transaction costs. In addi-
tion, novel blockchain implementations may be better suited, or usage patterns may
change, rendering the current host blockchain inappropriate. As a result, producers—
as the owners of token contracts—may intend to migrate respective token contracts
to another blockchain while maintaining traceability.
Smart contract forks enable the migration of business logic and state, providing the
demanded flexibility to move to another host blockchain if requirements or circum-
stances change. The presented use case has a special feature in that each smart con-
tract is assigned to an owner. Only owners can mint tokens, as they are the producers
8.3. Cross-Blockchain Interoperability 137
Algorithm 3: mint(u, Ip)
recipe : Rc−array of contract addresses of required inputs
Rr−array of chain relay addresses of inputs’ host blockchain
Ru−array of required units
counter: c−incremental counter ensuring correct input assignment
input : Iu−units to mint in batch
Ip−array of transaction receipt proofs
output : identifier of the newly added token
1begin
2if |Iu|=|Ip|=|Rc|then continue
3else revert
4for i←0to |Rc| − 1do
5(blockHash, blockHeader, receipt, path, witness)←unpack(Ipi)
6if chainRelayri.hasBlockHash(blockHash)then continue
7else revert
8if verifyP roof (blockHash, blockHeader, receipt, path, witness)then
continue
9else revert
10 (sourceContract, targetContract, counter, amount)←unpack(receipt)
11 if targetContract =address(this)then continue
12 else revert
13 if Iu∗amount ≥Ruithen continue
14 else revert
15 if sourceContract =Rcithen continue
16 else revert
17 if counter =Cthen continue
18 else revert
19 c←c+ 1
20 tokenId ←keccak256(C, u, Ip, msg. sender, time)
21 token.owner ←msg. sender
22 token.amount ←u
23 tokens[tokenId]←token
ofrepresented goods. Therefore, the owner is empowered to decide if and when to mi-
grate the token contract. While other participants could also create forks, only those
tokens thathavealreadybeenmintedcouldbetradedinthefollowingiftheownerdoes
not support the migration and maintains the original contract instance. As a result, it
is to be expected that only producers fork smart contracts, effectively mitigating the
fragmentation of a smart contract into multiple parallel instances.
As for any smart contract migration, other smart contracts depending on the forked
contract can only utilize the original instance’s state. In the presented use case, smart
contract traceability contracts depend on input tokens during the minting process.
When aninputtokenis migrated to another blockchain, producersshould update their
contracts which utilize these tokens as inputs. Producers replace the existing contract
and chain relay addresses in the stored recipe to update input tokens. If input tokens
are not updated accordingly, producers cannot utilize tokens newly minted by suppli-
ers. Further, the smart contract only accepts input token updates if the update was
executed after the last minting operation to prevent double-spending of input tokens.
138 Chapter 8. Token-based Supply Chain Traceability
Otherwise, producers could deplete all owned input tokens stored in the original con-
tract and refer to the same tokens after an update since the depleted tokens have been
migratedbeforeandthe burnoperation hasnotbeensynchronized. To furtherprevent
producers’ misconduct, contract owners announce forks on-chain, including the tar-
get blockchain (i.e., its chain relay address) and address. Referring contracts can only
be updated according to the announcement.
8.4 Evaluation
As discussed, blockchain-based supply chain traceability benefits from multiple con-
tributions presented in this thesis. Chain relays provide cross-chain state access and
depict enablers for smart contract portability and interoperable cross-chain deploy-
ments. In this section, we evaluate the delay and costs involved when applying cross-
chain techniques in contrast to a single ledger deployment. A prototypical implemen-
tation proving the application’s feasibility and measuring execution costs and delay is
published under an open-source license.1
First, we take the chain relay execution into account. Since chain relays are tailored
to specific consensus algorithms, their choice depends on the source blockchain’s im-
plementation. IfthesourceblockchainusesPoW,a zero-knowledgeproof-basedchain
relaymaybeusedtobenefitfromlowexecutioncosts(seeChapter4). Theutilizationof
PBFT-inspired PoS allows for the application of an efficient epoch-based chain relayto
skip irrelevant blocks (see Chapter 5). Since the chain relay operates independently of
the use case, the involved delay and costs can be derived from the relay-specific eval-
uation. For instance, using the zkSNARKs-based approach to validate a batch of four
blocks requires about 82 seconds and 556,724 gas. However, the delay only includes
the off-chain validation and excludes the transaction execution as it is specific to the
target blockchain. In the case of PoS, the block of interest must be finalized before the
chain relay can process it. Since minting operations are not timely in the presented
use case, these delays do not constitute restrictions to producers in the supply chain.
Second, we analyze the impact of using event proofs for ensuring input tokens have
been burned in contrast to direct function invocation. The original single blockchain
approach permits minting new tokens in a single transaction as the minting func-
tion invokes the burn function of every input token. Since using event proofs requires
burning input tokens before a product token can be minted, multiple transactions are
required. Furthermore, the collected event proofs mustbe passed to themintingfunc-
tion and are verified therein. These additional steps drive gas costs and delays. We
execute both variants using an Ethereum-based development blockchain that cre-
ates blocks upon transaction retrieval. The benchmarks are executed on a machine
equipped with an Intel Xeon CPU E3-1230 v6 @ 3.50 GHz and 64GB memory. We per-
form 50 iterations and increment the number of inputs with every iteration. Since gas
costs are deterministic, no variation is expected between minting operations of equiv-
alent input size. As illustrated in Figure 8.2, using event proofs is only beneficial com-
pared to instant function calls if no input tokens are required for minting a new token.
1https://github.com/informartin/SupplyChainToken
8.4. Evaluation 139
0
1
2
3
4
0 10 20 30 40 50
#inputs
Gas used (Million)
Instant call
Event proof
Event proof incl. burn transactions
Figure 8.2: Gas costs required for minting tokens depending on the
number of inputs.
Otherwise, the proof validation costs excel the costs saved for calling the burn func-
tion. The disparity becomes evident when taking onlythe minting operation into per-
spective and excluding the costs incurred byprevious burn transactions. For instance,
usingthe instantfunctioncall method to mintatoken requiring25inputsaccountsfor
735,268 gas, corresponding to about14.96 USD at agaspriceof12 gwei.2Utilizingevent
proofs for minting an equivalent token requires 1,324,776 gas or about 26.95 USD. The
minting operation and previous burn transactions call for 2,153,040 gas cumulatively
which is equivalentto 43.80USD usingthe Ethereummain network. As utilizingevent
proofs incurs significantly higher gas costs, a hybrid approach may be used to benefit
from efficient instant function calls if an input’s smart contract is hosted on the same
blockchain. Event proofs are only required if input tokens are maintained on remote
blockchains.
The measured delay increases approximately linearly with the number of input to-
kens, as illustrated in Figure 8.3. While the linear increase contains some variation
stemming from the single execution of every input size, we observe similar slopes
whenmintingtokensdirectlyorusingeventproofswhenneglectingtherequiredburn
transactions. Further, the monitored noise is consistent with the expected behavior
and shows low deviation from the linear dependence on the number of inputs. The
execution of the minting function using event proofs accompanies a slightly shorter
delay than the direct function call since no additional contractcalls are required. How-
ever, the application delay of the complete execution sequence—also taking the pre-
vious burn transactions into account—increases with a higher factor. For instance,
direct function calls take about 968 ms to mint a token comprising 25 input tokens,
while event proofs, including previous burn transactions, require about 2,110 ms for
the equivalent operation. While more than doubling the delay, the burn operations are
executed sequentially on a single blockchain. In a production setting, the distribution
ofsmartcontractstomultiplehostblockchains istobeexpected. Therefore, thesecon-
tract functions can be called in parallel to decrease the total delay. Further, blockchain
2Date: February 20, 2023. Exchange rate: 1695.42 ETH/USD
140 Chapter 8. Token-based Supply Chain Traceability
0
1
2
3
0 10 20 30 40 50
#inputs
Delay (s)
Instant call
Event proof
Event proof incl. burn transactions
Figure 8.3: Delay incurred for minting tokens depending on the num-
ber of inputs.
blocks are not created upon transaction retrieval in most production networks [15, 80,
122, 203]. As a result, transactions are collected before creating a new block, and all
burn transactions could be included in a single block as the execution time is belowthe
block creation rate of many implementations. When deployed in a sharding network,
the mining sequence can be executed with the delay of a single block. After burning
the input token within one block, the block header is relayed to the shard minting new
tokens, and event proofs are used to execute the minting operation. If chain relays are
utilized, the total delay is dominated by the finalization time of the source blockchain.
While the Tendermint protocol enables instant finality [80], Ethereum 2.0 finalizes
blocks with a delay of at least twelve minutes [127]. Since all input tokens must be
burned before minting the token representing a produced good, the delay is defined
by the input token’s host blockchain providing the slowest finality in addition to the
minting operation on the target blockchain.
Suppose the host blockchain no longer satisfies the producer’s requirements, for in-
stance, because of increasing throughput or security demands. In that case, migrating
the smart contract to another blockchain may facilitate the utilization of a more suit-
ableblockchainnetwork. We createa smart contractforktoevaluatethe involvedcosts
for a supply chain token contract. The contract is initialized with 50 tokens and holds
300key-value pairsthatmustbemigrated. Both sourceandtargetblockchainsconsti-
tute Ethereum test networks performing instant mining. Due to the large state size,
migrating the smart contract in a single transaction would exceed the target block-
chain’s gas limit. Therefore, the smart contract fork client deploys an initialization,
proxy, and logic contract to distribute the state initialization to multiple transactions,
as explained in Section 6.2.2.2. Overall, almost nine million gas are required to create
the contractforkon thetargetblockchain. Asdepictedin Table 8.1, the migrationtakes
just over 300 ms in total, with the key retrieval accounting for the most delay. Since
the token contract comprises more complex logic compared to the proxy and initial-
ization contracts, its bytecode is also larger. Therefore, deploying the logic contract
8.5. Discussion 141
Table 8.1: Timeand gas required forforkinga non-fungible tokencon-
tract for supply chain traceability. The contract stores 50 tokens and
maintains 300 key-value pairs. One hundred iterations have been per-
formed to retrieve the average delay and standard deviation (sd).
Action Time (ms) Gas
Average sd Average sd
State retrieval 207.14 3.43 — —
Deploy logic contract 18.16 0.59 2,224,126 0.00
Deploy initialization contract 13.67 0.21 204,876 3.45
Deploy proxy contract 14.33 0.55 166,618 3.62
Migrate state 41.81 1.14 6,381,077 0.00
295.11 8,976,697
also calls for more gas. As the amount of gas depends on the executed EVM opera-
tions and the logic contract remains equivalent for all iterations, there is no deviation
in deployment costs. In contrast, the fork client modifies the bytecodes of the initial-
ization and proxy contracts to add a static reference to the logic contract address. Since
the contract addresses differ between iterations, the EVM performs optimizations like
storing multiple values in one memoryslot resulting in marginal deviations. The state
migration accounts for about two-thirds of the total gas costs and is performed in two
transactions to maintain within the transaction gas limit. The operation requires the
most gas because storing values is the most expensive operation in the EVM [15]. No
deviation is observed, as the forked state is equivalent between all iterations.
8.5 Discussion
As demonstrated, theconcepts presented inthis thesis facilitate blockchain interoper-
ability to one of the most promising use cases for the technology. However, the smart
contracts have to be adjusted to enable cross-chain deployments. As a result, exe-
cution costs, delays, and complexity are added. Complementary tooling may support
users by orchestrating required transactions.
The presented solution is application-specific and not a generalization to every smart
contract. The minting process is executed by a single entity, ensuring correct order.
Therefore, no dedicated orchestration blockchain such as HyperService is required
(see Section 3.3.1.1) [28]. While the application could also be implemented using cross-
chainmessages(seeSection3.3.1.3),theprocesswouldhavetobeinitiatedonthetarget
contract’s host blockchain. For that reason, multiple transactions would be required
on the target blockchain, adding messages to the outgoing message queue and re-
trieving messages from the incoming queue after the remote functions have been ex-
ecuted. In addition, messagingwouldhave to beperformedon everyinputtoken’s host
blockchain, resulting in overhead and the requirement for a bi-directional blockchain
bridge. In contrast, our presented approach only requires a unidirectional bridge from
the input tokens’ hosts to the target blockchain. Similar holds for delegated function
142 Chapter 8. Token-based Supply Chain Traceability
invocations (see Section3.3.1.2), eventhoughtheyarenot operatingon messages. Del-
egated function invocations like GPACT depict a similar solution, as they utilize event
proofs to ensure correct behavior [30]. Yet, due to the registration of cross-chain calls,
this general approach incurs overhead that is not required by the application-tailored
approach.
8.6 Conclusion
In this chapter, we presented a concept for supply chain traceability that tracks pro-
duction processes to provide transparency across complex supply chains. Due to the
wide range of involved participants, scalability limitations, and varying privacy re-
quirements, traceability applications are expected to be deployed to multiple block-
chain networks. Cross-blockchain smart contract interoperability ensures traceabil-
ity across blockchain networks. We have demonstrated howthe concepts presented in
this thesis enable application deployment distributed over multiple networks. While
someadditionalexecutioncostsareimpliedtotransferstaterootsandeventproofs,the
observed delays remain below the block creation rate of most blockchain implemen-
tations. In addition, smart contract forks provide flexibility to producers maintaining
token contracts. As a result, they can select the best-suited blockchain implementa-
tion according to their requirements.
143
9 Decentralized Online Social
Network
Blockchain technology depicts a promising enabler for decentralized OSNs since they
provide decentralized registries. These registries permit users to manage human-
readable identifierswithoutrelying on athirdpartyandmitigatelock-in effects. How-
ever, the host blockchain itself may create a novel lock-in effect if registries cannot be
accessed from or moved to other networks. This chapter presents the concept of a
blockchain-based OSN and applies smart contract forks and synchronization to foster
flexible identity management and access.
9.1 Motivation
Web-based social communication platforms today are almost exclusively designed in
a centralized, proprietary fashion. As a result, users can only communicate and share
content with users of the same service, as proprietary communication protocols and
APIs restrict interoperability with other services. This way, users are locked into the
service they signed up for, unable to freely communicate with users of other OSN ser-
vices [204].
To alleviate the issue of OSN services being proprietary, isolated platforms, peer-to-
peer, and federated social communication architectures have been proposed that dis-
tribute control and information between multiple servers or devices [205, 206]. Still,
existing decentralized OSN services such as Mastodon1or Diaspora2again lock users
into their ecosystems, even though being distributed services. As communication
with outside services is again mostly not possible [192], the adaption of decentralized
OSN services is relatively low.
Blockchain technology provides decentralized data storage enabling the registration
of identifiers without depending on an external service provider. For instance, the
micro-blogging service Peepeth3permits users to post messages using the Ethereum
blockchain. However, once messages have been posted, they can never be changed or
deleted safely, reducing users’ control over their data. Therefore, we propose identifier
registries stored on a blockchain while storing messages and complementary data on
user devices.
1http://mastodon.social
2https://diasporafoundation.org
3https://peepeth.com
144 Chapter 9. Decentralized Online Social Network
Since our objective is to overcome lock-in effects to a single provider in a federated
network, novel lock-in effects towards a single blockchain must be mitigated. There-
fore, cross-chain interoperability is required to access identifiers stored on another
blockchain network or migrating registries, for instance, if a host blockchain becomes
insecure.
This chapter presents the concept of using a blockchain-based decentralized registry
to enable self-sovereign OSNs. Since the focus of this thesis is on cross-blockchain
smartcontractinteroperability,wepresentabriefintroductiontotheconceptofblock-
chain-based OSNs and refer to [7] for a more detailed description. In the following, we
demonstrate how the smartcontract interoperability methods presented in this thesis
facilitate independence from blockchain instances. The applied techniques are evalu-
ated given the use case’s requirements. Finally, we discuss the results before conclud-
ing.
9.2 Concept
We propose addressing users using blockchain-based registries to facilitate Web-
based communication and collaboration without any central or semi-central entity
controlling or monitoring the process. Distributed human-readable identifiers are
linked to self-hosted data storage. The concept poses an alternative to centralized or
federated social networks that suffer from isolated data storage and lock-in effects in
so-called walled gardens [207].
9.2.1 Personal Data Storage
User-generated content is only stored in personal data storage to ensure full control
over created content and achieve data sovereignty. A user-specific backend server of-
fers data storage and supplies a REST API for interacting with the client and exchang-
ing messages with other users’ data storage. Users can deploy an instance on their
device, such as a Network Attached Storage (NAS), or use a trusted party’s service. As
personalcontentisonlystored on a devicethatis controlledbythe user anddistributed
to other contacts when intended, it can be deleted or altered by its owner at any time
while allowing the owner to define fine-grained access control policies for other users.
As a result, sensitive data is not only protected from unintended processing by a third
party, but it is also fully compliant with the European General Data Protection Regu-
lation (GDPR) [208].
In contrastto client devices, the personal data storage server has to provide high avail-
abilityto be accessible byother contacts who retrieve public or shared information and
messages. Notifications about new private or public messages are stored by the back-
end and delivered to clients when going online. With this, a user experience similar to
centralized OSNs is guaranteed, as information can be exchanged without all clients
having to be available simultaneously. Even though decentralization introduces a cer-
tain communication overhead compared to centralized service architectures, the gen-
eral applicability of such a federated approach has been found to be feasible [209].
9.2. Concept 145
In order to verify the validity of interactions with the server in server-to-server com-
munication, a key pair is generated. The respective public key is stored and linked to
the user on a distributed ledger. Server responses are signed using the private key and
are, therefore, verifiable after retrieving the public key from the ledger.
Since backend servers can directly query nodes catering to different blockchain net-
works, blockchain interoperability is not required for providing access to identifiers
hosted on various networks. Blockchain integration patterns are sufficient for this
task to guarantee compatibility of transactions and data formats [210]. However, on-
chain cross-references and migrations require cross-blockchain interoperability, as
outlined in Section 9.3.
9.2.2 User Identification
User-specific identifiers are stored on the blockchain to achieve secure, distributed,
and human-readable names. Unique identifiers are attributed with a Uniform Re-
source Identifier (URI) that refers to a user’s API server handling message exchange
and personal data storage. As the link between a user’s identifier and storage is de-
coupled, the server instance can be shifted to any location at any time. Only the URI
attribute set on the blockchain needs to be adjusted to achieve this. This characteris-
ticdistinguishesthe conceptfromfederated approaches such asDiaspora, where users
canchooseaninstancein the firstplacebut cannotmovetheirprofile to anotherserver
without losing personal information and connections. Applying the presented concept
ensures that connections to other users remain intact and no data is lost.
The user login in the client is deduced from the cryptographic key pair used for block-
chain communication. These keys are handled by blockchain-specific wallets and are
accessible through browser plug-ins, mobile applications, or standalone browsers. As
a result, users do not have to handle usernames and passwords but are identified by
their blockchain account’s key pair and do not have to register at a central service.
On-chain identifiers allow retrieving public messages by retrieving the user’s public
keyand URI. Afterward, messages can bequeried fromthe user’s personaldata storage
and verified using the public key. Therefore, no Public Key Infrastructure (PKI) is re-
quired to guarantee authentic communication. Similarly, messages can be encrypted
using the counterpart’s public key to achieve confidentiality. For instance, Figure 9.1
illustrates an example friend request that allows exchanging private messages if ac-
cepted. Messages and requests are stored on the user-specific data storage, and the
communication is initiated based on the data received from the on-chain registry.
In addition to mapping an identifier to the user backend, the registry can be used to
enable blockchain functionalitysuch as payments. For this purpose, further attributes
like blockchain addresses can be stored to facilitate other users sending tokens using
the human-readable identifier. The stored blockchain wallet address is not limited to
the host blockchain but can include wallet addresses referencing remote networks.
146 Chapter 9. Decentralized Online Social Network
Alice Bob
get URI
(bob.eth)
URI
get public profile
add Friend
(bob.eth, sig(alice))
friend request (alice.eth, sig(alice))
get public keys (alice.eth)
store
request verify
signatues
get friend
requests
confirm(sig(bob))
accepted (bob.eth, sig(bob))
public keys
requests
get public profile
public profile
get URI
(alice.eth)
URI
public profile
1
2
5
68
9
10
11
12
Blockchain
Blockchain
Blockchain
3
7
Alice's API Server Bob's API Server
4
Figure 9.1: Friend requests allow sharing of private messages. Users
retrieve the backend URI and public key using the blockchain-based
registry to send and sign requests.
9.3 Cross-Blockchain Interoperability
In the presented use case, users benefit from smart contract cross-blockchain inter-
operability in multiple ways. First, smart contract forks permit migrating registries
between blockchain networks if the former instance does not cater to the current re-
quirements. Second, smart contract synchronization enables users to maintain a sin-
gle human-readable identifier that can be utilized on multiple blockchains.
9.3.1 Smart Contract Forks
Users may intend to create a fork of the registry contract for multiple reasons. For
instance, the participation in the host blockchain’s consensus protocol may decrease,
resulting in centralization and, thus, insecure operation, as consensus becomes dom-
inated bya fewentities. Further, the hostblockchain may be used bya minority of OSN
participants. As a result, the access to nodes allowing to retrieve identifiers’ attributes
maybe limited since every backend handles only a set of blockchain networks defined
by the user.
In the case of registries, a consensus is required between the smart contract’s users
for a fork to succeed. Because a fork results in two smart contract instances operating
in parallel, an agreement on the utilized instance is required. Otherwise, diverging
states mayresult in inconsistencies when querying different smart contractinstances.
Therefore, some coordination is needed, which is not required if the smart contract is
assigned to an owner, such as the case for supply chain traceability token contracts
(see Chapter 8). Such coordination could be performed on-chain or off-chain.
Thehostblockchainofanidentifierdomainmustbeembeddedintothebackendserver
to address the correct network when querying for identities. One blockchain can host
multiple registry contracts but a domain must be provided by a single smart contract
instance.
9.4. Evaluation 147
9.3.2 Smart Contract Synchronization
Synchronizing registrycontracts allows for the utilization of a single human-readable
identifier across multiple blockchain networks. This has two advantages for users.
First, they benefit from on-chain functionality beyond OSNs, such as payment. Sec-
ond, registries hosted on a blockchain supported by few participants can be made
available on another, more popular network to provide access to a wide range of users.
Users intending to use a single identifier on multiple networks first register at the do-
main of their interest. For instance, “.eth” depicts the default domain for the ENS.
After registering a name, attributes are stored. Using OSN requires the specification of
the corresponding user-specific URI. In addition, public keys of different networks can
be stored, for example, to receive payments based on the registered user name. These
public keys are not limited to the host blockchain but may include wallet addresses of
remote networks. The attributes of registered names can be resolved externally and
by smart contracts to address entities. If a user wishes to specify their account on a
remote blockchain using the registered identifier, cross-chain access is required. For
this purpose, the registry contract may be synchronized between blockchains to pro-
vide access to remotely hosted identifiers. As a result, smart contracts hosted on a
remote blockchain can query the synchronized registry contract to retrieve the user’s
wallet address instantly. The synchronization scheme also ensures the utilization of
up-to-date attributes after being changed by the user.
While smart contract forks assist users with migrating registries if the current host
blockchain becomes unsuitable, consensus supporting the migration is required. Al-
ternatively, registries hosted on a minor blockchain can be synchronized to more pop-
ular instances to guarantee accessibility. As a result, backends do not need to maintain
nodes of blockchain networks exhibiting few users for querying identifier data. Fur-
ther, the registry management persists on the original blockchain that may be best
suited for other applications.
9.4 Evaluation
In this section, we assess the migration and synchronization of registries which are
managed by smart contracts based on the ENS. While the ENS consists of multiple
smartcontracts catering todifferenttasks, wefocuson the resolver contractthatholds
the attributes assigned to domain names. In the following, we first evaluate the cre-
ation of a fork for permanently migrating registry contracts. After that, we synchro-
nize a registry contract holding different states and analyze the costs and delays de-
pending on the number of updated values. We use the same hardware and blockchain
setup as in Chapter 8. Thus, the source and target blockchains are deployed locally,
creating new blocks upon transaction retrieval. Further, we assume cross-chain state
roots are provided via a chain relay, sharding, or notary scheme. Since registry entries
are expected to change rarely, there is no formal timeliness requirement. Neverthe-
less, the costs and delay of transferring state roots must also be taken into account
and—while independent of the use case—depends on the specific implementation.
148 Chapter 9. Decentralized Online Social Network
Table 9.1: Time and gas required for forking an ENS resolver holding
5,000 entries. One hundred iterations have been performed to retrieve
the average delay and standard deviation (sd).
Action Time (ms) Gas
Average sd Average sd
State retrieval 11,104.72 136.43 — —
Deploy logic contract 20.82 2.64 2,815,274 0.00
Deploy initialization contract 13.34 1.03 204,875 4.27
Deploy proxy contract 13.27 0.34 166,618 4.84
Migrate state 522.82 13.58 105,609,433 0.00
11,674.97 108,796,200
We deploy a resolver contract maintaining a mapping between a node and a name. In
the ENS, nodes are hashed versions of fully qualified names and depict unique identi-
fiers. The contract is initialized with 5,000 entries that should be migrated along with
the contract logic. The state is retrieved by replaying past transactions, a technique
supported by most Ethereum node implementations. Since no other application is de-
ployedtothetestinstance,onlyrelevanttransactionsexist,resultinginfastertransac-
tion retrieval compared to production deployments. Since 5,000 key-value pairs can-
not be migrated in a single transaction in typical blockchain configurations, the con-
tract is split into a logic and proxy contract, enabling the utilization of an initialization
contract for distributing the migration to multiple transactions, as proposed in Sec-
tion 6.2.2.2. Table 9.1 shows the delay and gas required for each step ofthe fork process.
We observe that state retrieval consumes the most time, followed by migration to the
target blockchain. Similar to the observations presented in Section 8.4, deploying the
initialization and proxy contracts entails minor deviations concerning gas costs due
to the insertion of different logic contract addresses between iterations. Since state
retrieval does not require interaction with the target blockchain, no gas is consumed.
The state migration is performed in 26 transactions and uses more than 105 million
gas. Since a single storage operation accounts for 20,000 gas in the EVM [15], these
operations accumulate 100 million gas, dominating the overall fees. Given the current
configuration of Ethereum’s main network allowing a maximum of 30 million gas per
block [15], the forking process would require at least four blocks to migrate the entire
state.
A resolver contract holding no values is deployed to measure the time and gas re-
quired to synchronize states after increasing its size. For this purpose, a new map-
ping is added to the contract, and all previously added values are modified with every
iteration. The measured delay for retrieving state updates, calculating the required
multi-proof, and executing the synchronization transaction ranges between 88 ms
and 272 ms, as illustrated in Figure 9.2. The required gas ranges between 481,025 gas
and 4,589,186 gas and is monotonously increasing. The execution costs particularly
depend on the submitted multi-proof size and structure. Therefore, the cost develop-
ment is not precisely linearly increasing since adding a value to a present branch node
9.5. Discussion 149
100
200
1
2
3
4
5
0 10 20 30 40 50
#values
Delay (ms)
Gas (Million)
Delay Gas
Figure 9.2: Delay and gas costs for synchronizing an ENS resolver, in-
cluding state retrieval and update.
requires fewer call data and verification steps than adding a new branch node. Fur-
ther, the slope is less than for creating smart contract forks since only a single storage
location is newly allocated while all other key-value pairs replace existing values. The
latter operation only accounts for 5,000 gas instead of 20,000 gas in the EVM [15]. The
production deployment of the ENS provides a default resolver contract4allowing to
store the most used attributes. At the time of writing,5we observe an average of 25
transactions per hour modifying the resolver contract’s state. If an update is intended
to be applied every hour, and we assume every transaction modifies one storage lo-
cation, the synchronization of 25 key-value pairs accounts for 2,888,379 gas, corre-
sponding to 58.76 USD,6and requires about 190 ms. The costs include 24 state mod-
ifications and one addition, a larger share of additions results in additional costs of at
least 15,000 gas per value. Merkle tree rearrangements may result in additional costs.
In production deployments, the measured delay of 190 ms is well within the mining
rate of most networks and can therefore be recorded in the next created block if dis-
seminated in time.
9.5 Discussion
We have shown how smart contract forks and synchronization foster flexibility in us-
ingdecentralizedregistriesacrossblockchainnetworks. However, manyinter-depen-
dencies exist that need to be taken into consideration.
First, domain names may reference smart contracts hosted on the same blockchain
instance. Such dependencies may brake if no recursive dependency migration is ap-
plied. As presented in Section 6.2.3, the fork client allows deploying all dependencies
4Public resolver contract: 0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41
5Date: January 11, 2023
6Date: February 20, 2023. Gas price: 12gwei. Exchange rate: 1695.42 ETH/USD
150 Chapter 9. Decentralized Online Social Network
and substituting contract addresses accordingly. Nevertheless, applying this tech-
nique may result in the migration of a large dependency tree and thus drive costs. In
addition, the validation becomes more complex, as it is not sufficient to compare the
state roots of the source and target contracts. Instead, the Merkle tree must be recal-
culated, similar to transition proofs. Since the main objective in OSNs is the retrieval
of backend URIs and private wallet addresses, this limitation does not pose an issue to
the described use case.
Second, the ENS is composed of multiple smart contracts catering to different pur-
poses. The central ENS contract registers top-level domains and forwards requests
to the matching registrar contract. Registrar contracts handle domain registrations
and permit setting a resolver storing associated attributes. We have only transferred
the resolver contract, as it maintains the mappings between domain identifiers and
attributes. Therefore, retrieving information given a known identifier is sufficient if
it is stored in that resolver. In the case of smart contract synchronization, the client
contract’s state can only be modified if it matches the state available on the source
blockchain. Therefore, the registrar is not necessarily required to guarantee correct
state transitions, as no query to the registrar is required. However, users may store
attributes in different resolver contracts that must be synchronized to provide cross-
chainaccessibility. SincethemainENScontractacts asanentrypointtothedecentral-
ized domain name system, an independent instance may already be deployed on the
targetblockchain. In this case, synchronized registrars andresolversmaybe manually
registered to enable their integration into the present system.
9.6 Conclusion
In this chapter, we have presented the concept of blockchain-based decentralized
OSNs and how they benefit from the cross-chain smart contract interoperability
schemes presented in this thesis. The potential lock-in effect toward a host block-
chain is mitigated byperforming smart contract forks. As a result, registered human-
readable identifiers can be managed on an alternative blockchain instance, providing
the required properties. In addition, domain names can be used for supplying refer-
ences to wallet addresses that can be utilized on-chain. Smart contract synchroniza-
tionsallowusersto managean identifierontheprimaryhostblockchainwhilemaking
use of it on multiple other networks. Therefore, users can store their wallet addresses
on remote blockchains and refer to them on remote networks. Further, user-specific
OSN backends may only support a limited number of blockchains. Synchronized re-
solvers contracts allow maintaining the contract on a minor blockchain and access-
ing it via a synchronized version if no direct access is available. Our evaluation shows
the applicability of the applied cross-chain techniques concerning delay and execution
costs.
151
10 Cross-chain Oracle
In recent years, DeFi has become one of the most promising application areas for
blockchain technology. In particular, AMMs allowing to trade assets in a decentral-
ized fashion have become popular [193]. However, many DeFi applications require or-
acle data to operate [42]. In this chapter, we show how AMMs provide reliable price
feeds to dependent contracts and how this information can be made available across
multiple blockchains. As a result, DeFi applications deployed to various blockchain in-
stances can utilize the oracle data generated on other networks. For this purpose, we
apply cross-blockchain smart contract synchronization to enable instant read access.
Incontrast tothe applicationspresented inChapters 8and 9, oracles such aspricefeeds
require timely data. Therefore, we particularly investigate the time delay incurred by
the synchronization process. Further, we apply smartcontract synchronization to one
of the most used AMMs deployed to the Ethereum main network to analyze the tech-
nique’s feasibility in a production setting.
10.1 Motivation
While the roots of blockchain technology lie in decentralized digital currencies [13],
DeFi generalizes this concept to create an alternative to the present financial system
by circumventing centralized actors. The objective is to create an open, censorship-
resistant market that enables the flexible composition of financial instruments [42].
The increasing investment illustrates the growing interest in DeFi protocols. While
the investment size was around 700 million USD at the beginning of 2020, the amount
grew to over 100 billion USD by September 2021 [193]. DeFi applications such as de-
centralized stable coins, like MakerDAO’s DAI,1or lending platforms, like Compound,2
require reliable price feeds through data oracles [42]. While external data sources
may be used as price oracles, respective feeds suffer from centralization tendencies,
data manipulation, complex incentive mechanisms, and additional transaction costs.
However, one of the most prominent DeFi applications, DEXs, depict an alternative
to external data sources by providing an on-chain price estimate derived from past
trades [211]. Therefore, DEXs generate a decentralized price feed that provides data
on-chain instead of requiring external data. As of today, AMMs depict the most pop-
ular type of DEXs. Instead of relying on order books, liquidity providers supply tokens
of trading pairs that can be exchanged for a fee [212]. High deposits reduce the risk
of manipulation to exploit dependent protocols. Therefore, sufficient liquidity must
be ensured that may not be provided by AMMs deployed to the identical blockchain as
the target application.
1https://makerdao.com
2https://compound.finance
152 Chapter 10. Cross-chain Oracle
Smart contract portability offers mechanisms for securely retrieving smart contract
states across blockchain networks. As a result, DeFiapplications can bedeployed to the
best-suited blockchain while relying on a decentralized price feed supplied on another
blockchain.
10.2 Cross-Blockchain Interoperability
While AMM contracts may be migrated through a fork to utilize another blockchain
instance that may provide the best-fitting properties at a given time, there are ob-
stacles. Since the trading pairs reflect tokens hosted on the same blockchain—either
native or wrapped—the respective token contracts would have to be forked as well.
Not only a significant number of AMM users would have to follow the new fork, but
also token holders who have never interacted with the trading contract. Due to their
limited applicability, we neglect the creation of smart contract forks for AMMs.
As many DeFi applications rely on price feeds, synchronizing an AMM may allevi-
ate limitations stemming from isolated blockchain networks. The synchronization
of a contract does not have to be backed by a certain number of users but can supply
data feeds without third-party interaction. Hereby, smart contract synchronizations
provide oracle data across distinct blockchain networks. Since prices may be volatile,
timely data is required.
AMM-based price oracles do not relyon the last executed trade but on an accumulated
price that is updated after every transaction and incorporates the trade historyto mit-
igate exchange rate manipulations [187]. Therefore, relaying the receipt of a recent
trading transaction is not sufficient to obtain an accurate price estimate. The syn-
chronization of an AMM contract that permits trading the trading pair of interest will
enable dependent contracts to query for the calculated time-weighted average price,
according to the contract logic. Figure 10.1 depicts an example where an AMM contract
is synchronized to provide a cross-chain price feed. We assume that both blockchains
exhibit equal mining rates and that blocks are mined synchronously. In the first step,
the synchronization client creates an initial fork of the source contract. At this point
in time, the contract reports an exchange rate of 2:1. After a user sends a transaction
to exchange tokens using the AMM on Blockchain A, the exchange rate is recalculated
andresultsin a1.9:1ratio. Whiledependentcontracts on BlockchainAcaninstantlyre-
trieve theupdatedexchange rate after thetrade transactionis executed, this isonlythe
case on Blockchain B once the synchronization is executed. Thus, respective queries
on Blockchains A and B would return distinct results at block 0x3 in the example il-
lustrated in Figure 10.1. Our experiment is divided into two steps: creating the initial
smart contract fork and subsequent synchronization. A trusted state root of Block-
chain Ais required on Blockchain B as a prerequisite. Ifboth blockchains depictshards
of an interconnected network, state roots are typically supplied by a relay chain [122,
123]. Therefore, accessing a remote state root does not incur additional operational
costs and a delay of one slot.
10.3. Evaluation 153
0x1 0x2 0x3 0x4
0x2 0x3 0x4 0x5
Cumulative
exchange
rate: 2:1 Fork
Cumulative
exchange
rate: 1.9:1 Synchronize
Transaction:
Exchange tokens
0x1
0x5
Blockchain A
Blockchain B
Synchronized
AMM Contract
Retrieve
exchange
rate
Query
···
···
Dependent
DeFi Contract
Figure 10.1: Synchronized contracts are modified according to the
source blockchain and accessible as client contracts to smart contracts
on other blockchain networks.
10.3 Evaluation
Wesynchronizeone ofthemostusedAMMsinproduction toevaluatethe performance
of smart contract synchronizations in a production setting. Uniswap is the largest
AMM by total locked volume [213]. For this reason, many supplied trading pairs are
well suited to act as a price oracle. We select the WBTC / ETH trading pair since it is
one of the most popular Uniswap contracts according to Uniswap’s pair tracker.3The
source contract4is hosted on Ethereum’s main network, and we intend to create a
synchronized version on Ethereum’s Görli test network. The fork and synchroniza-
tion processes are performed once to avoid overloading the public test network.
Table 10.1 depicts the delay and required gas for each step of the initial fork, as outlined
in Section 6.2. The initial state comprises 20,831 key-value pairs. Instead of retrieving
the value of every key used by the smart contract individually, the storage proofs for
all keys are retrieved from the blockchain client, which includes the respective values.
Our experiments with the OpenEthereum client have shown that proof retrieval in-
volves a shorter delay than iterative value retrieval in a production environment, even
though the process entails a delay that is more than twice as long as key retrieval. The
test networks used in Chapters 8 and 9 only included transactions relevantto the con-
tract migration and thus provided fast key retrieval by querying past transactions. In
a production setting, the filtering process required to find and replay relevant trans-
actions exceeds the time required when using OpenEthereum’s full storage database
to get all contract storage keys.
The delay incurred for deploying contracts mainly reflects the target network’s min-
ing rate. After retrieving the state, it is applied to the proxy contract5on the target
blockchain using 70 transactions, where the gas limit is set to eight million. Since the
3https://v2.info.uniswap.org/pairs
4Source contract: 0xBb2b8038a1640196FbE3e38816F3e67Cba72D940
5Proxy contract: 0x1E2681f92da88212524cD05D3102BEacbE1Da240
154 Chapter 10. Cross-chain Oracle
Table 10.1: Time and gas required for forking a major AMM to enable
sychronization.
Action Time (sec) Gas
Key retrieval 32.71 —
Proof retrieval 73.09 —
Deploy logic contract 12.10 2,475,924
Deploy proxy contract 24.11 2,596,862
Migrate state 264.28 483,383,735
Verify migration 36.12 656,445
442.411 489,112,966
target blockchain is configured to a maximum gas limit of 30 million, larger trans-
actions would be possible. However, since the submitted transactions compete with
those of other users, larger transactions may not be considered by miners, so a gas
limit of eight million constitutes a compromise between delay and gas costs. Every
transaction includes up to 300 key-value pairs, and the average gas usage is around
seven million. Since forking a smart contract is a one-time procedure, the required
time of about 442 seconds is considered viable. Nevertheless, the involved costs of al-
most 500 million gas constitute a challenge for some applications when applied to a
blockchain such as the Ethereum main network, as 483,383,735 gas corresponds to
9,834.46 USD at the time of writing.6Since many alternative blockchains supporting
the EVM and incorporating lower gas fees exist, their utilization will also reduce the
entrance barrier.
After the smart contract fork has been successfully executed using block 14,926,123
of Ethereum’s main network, user transactions modified the source state. Therefore,
we execute the synchronization process to update the target contract to the state of
source block 14,926,556. Thus, the synchronization step includes 433 blocks of the
source blockchain. The overall state transition affects eight key-value pairs, which
are updated. Two options exist to retrieve the delta between the current and updated
state: retrieving all transactions that have modified the contract state or querying the
entire contract state to compute differentials. Our experiments have shown that the
latter approach results in lower delays when upgrading between more than tens of
blocks. We, therefore, retrieve the source and target state, as indicated in Table 10.2.
Both states are retrieved sequentially on a single machine. Parallelizing the tasks on
multiple machines would accelerate the process. If the last synchronization was exe-
cuted by the same entity and the previous state was stored, it can be utilized instead
of retrieving the target state again. Retrieving only a single contract state reduces the
delay significantly. The effective reduction depends on the target blockchain’s state
size and node implementation. The most significant delay is produced by computing
the differentials, which includes retrieving every value for retrieved keys and creating
the multi-proof. The delay induced by the synchronization transaction reflects the
target blockchain’s network dissemination time and mining rate. The overall delay of
288.42 seconds is relatively high but may be reduced by reducing the included blocks
6Date: February 20, 2023. Gas Price: 12 gwei. Exchange rate: 1695.42 ETH/USD
10.4. Discussion 155
Table 10.2: Time and gas required for synchronizing a major AMM
Action Time (sec) Gas
Key retrieval 65.31 —
Compute diff & multi-proof 203.02 —
Synchronize state transaction 20.09 4,626,942
288.42 4,626,942
or replaying transactions as soon as they occur on the source ledger. The required gas
costs sum up to 4,626,942 gas corresponding to about 94.14 USD.
10.4 Discussion
OurresultsshowtheapplicabilityofsmartcontractsynchronizationstoAMMsforcre-
ating cross-chain price oracles. Whether the costs are feasible depends on the given
use case and target blockchain. While the total delay seems significant, it is still be-
low the finality constraints of many blockchains. Thus, the synchronization process
could be triggered while waiting for the finalityof the source blockchain. For instance,
Ethereum’sconsensus layerrequires atleast twelve minutes until a block is deemedfi-
nal [127]. Once the block of interest is finalized, its state root is transferred, and the
computed multi-proof is submitted to synchronize the smart contract. While the la-
tency can be reduced by caching states or parallelizing tasks, the total delay may ex-
ceed what is acceptable to DeFi applications. The state retrieval has the most con-
siderable delay and stems from the database operations performed by the blockchain
node client. Since accessing Ethereum’s Merkle Patricia tree is computationally com-
plex, the task induces delays, especially if the global state is large, as is the case for
Ethereum’s main network. Thus, the required time will be decreased when utilizing
a different network or Merkle tree implementation. Due to the limited scalability of
Merkle Patricia trees, Ethereum is transitioning to more performantbinarybased SSZ
scheme with Ethereum 2.0 [127].
If regular, timely updates are required, a listener retrieving relevant transactions as
soon as they have been mined will reduce computation times significantly. Since only
those transactions recorded in one block need to be replayed for retrieving the state
differential, the induced delaywill be comparable to the results presented for test net-
works (see Chapters 8 and 9). As a result, a lowdelaycan be achieved, providing timely
oracle data.
Alternatively, cross-blockchain smart contract invocation protocols could be used for
retrieving price feeds. However, they require additional transactions driving execu-
tion costs and delays. In the case of the GPACT protocol, call graphs must be regis-
tered and finalized [30]. Other approaches, like the cross-chain function call protocol
proposed by Nissl et al. [29], require external actors who are economically motivated.
Therefore, complexityis added, and the cross-chain application mustbe monitored to
operate reliably. In contrast, smart contract synchronizations do notrequire economic
assumptions and comprise low delays if the state is updated regularly.
156 Chapter 10. Cross-chain Oracle
10.5 Conclusion
This chapter shows that smart contract synchronizations can add significant value
to DeFi applications. Recent oracle data is supplied via synchronized AMM contracts,
for instance, to query price feeds from remote blockchain networks. The evaluation
proves the concept’s applicability to real-world use cases by synchronizing one of the
most popular AMMs deployed to the Ethereum main network. While production net-
works add execution delays due to the increased state size and relatively low mining
rates, regular state updates enable efficient synchronization. As a result, smart con-
tract synchronizations can provide recent data without requiring trusted intermedi-
aries.
157
Part V
Summary and Outlook
159
11 Conclusion
Due to the increasing fragmentation of blockchain networks, cross-blockchain inter-
operability constitutes a prerequisite for interconnected decentralized applications.
The concepts proposed in this thesis address blockchain interoperability at different
levels. We enable cross-chain state access without requiring trusted intermediaries,
economic assumptions, or modifications to present blockchain protocols. The intro-
duced smart contract fork and synchronization concepts reduce the tight binding be-
tween smart contracts and their host blockchain to mitigate lock-in effects. The qual-
itative and quantitative evaluation of the presented methods proves their applicability
to use cases of various domains. In the following, we describe howthese concepts con-
tribute to answering the posed research questions.
RQ1 How can smart contract states be accessed across different blockchain networks se-
curely, trustless, and efficiently?
Chain relays provide secure and trustless state access across different blockchain
networks but require the validation of every consecutive block header resulting
in high transaction costs. We presented two chain relay concepts providing en-
hanced scalability by allowing the validation of batches of blocks, effectively re-
ducing the on-chain validation costs by orders of magnitude without compro-
mising security or trustlessness.
The first conceptenables the verifiable off-chain validation of PoW-based block-
chains. We apply two different kinds of zero-knowledge proofs to enable per-
missionless participation and on-chain proof validation. zkSNARKs prove to be
efficient concerning off-chain block validation and on-chain proof verification
but presuppose a setup ceremony. While less efficient, zkSTARKs do not require
such ceremony and allow the validation of arbitrary batch sizes. The proof sys-
tem choice depends on the application’s requirements. Our evaluation shows
that both solutions reduce execution costs significantly and therefore provide a
promising alternative to current cross-chain state access protocols.
The second presented method applies to PoS-based blockchains providing guar-
anteedfinality. The conceptpermits skippingintermediaryblockheadersbyuti-
lizingfinalitycheckpointsandinclusionproofsofpreviousblockheaders. There-
fore, only a subset of block headers must be verified to maintain the chain relay’s
liveness. As a result, the validation costs are reduced while preserving verifiabil-
ity.
RQ2 How can the tight bond between smart contracts and blockchains be resolved?
The smart contract fork concept enables the flexible migration of smart con-
tracts between blockchains supportingthe same executionenvironment, such as
160 Chapter 11. Conclusion
the EVM. Any source and target blockchain participant can execute smart con-
tract forks based on current or historic contract states. We introduce a set of
techniques for retrieving smart contract states that cater to different blockchain
clients, state sizes, and transaction distributions. The deployment of dedicated
initialization, logic, and proxy contracts permits the migration of large contract
states without compromising the verifiability of logic or state. After the execu-
tion of the smart contract fork is completed, the state can only be modified ac-
cording to the contract’s business logic. Further, its validity is verifiable exter-
nally or by utilizing a trusted state root of the source blockchain. As a result, the
tightbond between smart contracts and blockchains can be resolved byconduct-
ing smartcontract forks that create new instances on other blockchain networks
based on a shared state. With this, users benefit from the properties of the target
blockchain and are not limited to the initially selected host blockchain.
RQ3 How can smart contract functions query remotely hosted smart contracts without
compromising decentralization?
We present smart contract synchronization to enable (near)-instant cross-
blockchain read-only smart contract calls. Secondary replica contracts are cre-
ated using the introduced smart contract fork mechanism. After the migration
is completed, only functions that do not modifythe contract state are executable.
While the states offorked smart contracts diverge over time, smart contract syn-
chronizations enable updating the secondary contract according to the primary
instance’s state. Essential to the verifiability and efficiency of smart contract
synchronizations are the introduced transition confirmations. With this, the
synchronization contract ensures the entire state is updated and prevents incon-
sistencies between the primary and secondary instance. As a result, synchro-
nized smart contracts can be utilized for querying information using the pro-
vided business logic. Direct function calls reduce delays and mitigate overhead
for cross-chain messaging requiring multiple transactions. The synchroniza-
tion process is permissionless and is free from financial requirements or trusted
intermediaries.
In conclusion, we advanced the state-of-the-art in two fields of blockchain interoper-
ability. Efficient chain relays enable various applications, including cross-blockchain
assettransfers[150]andsmartcontractportability. Smartcontractforksandsynchro-
nizations reduce the dependency on the host blockchain and mitigate lock-in effects.
161
12 Future Work
The concepts presented in this thesis depict the foundation for various potential ex-
tensions, further enhancing blockchain interoperability. In the following, we describe
the most promising approaches for future research.
Recursive zkSNARKs. We propose a concept for efficient chain relays based on ver-
ifiable off-chain computations using zkSNARKs and zkSTARKs in Chapter 4. While
zkSTARKs permit the validation of flexible batch sizes and do not require trusted se-
tups, the on-chain validation of generated proofs is computationally complex com-
pared to zkSNARKs. Recursive zkSNARKs depict a promising approach for future im-
plementations as theyenable the validation of a zkSNARKs proof using a verifiable off-
chain program based on zkSNARKs [214]. As a result, flexibility and efficiency can be
improved. First, recursive proofs may allow verifying arbitrary batch sizes for block
header validation, similar to zkSTARKs. Second, different proof schemes can be ap-
plied following a multi-layered approach [215]. In the case of chain relays, the scheme
applied for proving the correctness of block headers may be computationallyefficient,
resulting in fast computation and limited memory requirements but producing large
proofs. Since the on-chain validation of such proof would result in high transaction
costs, another proof is created, verifying the first and producing a shortand efficiently
verifiable second proof. Hence, efficient off-chain and on-chain executions are en-
abled, fostering low latency and costs.
Orchestrating proof computation. Our concept of using off-chain computations to
implement efficient chain relays is permissionless, and any user can submit proofs
of validated block headers according to their requirements. While providing a high
degree of flexibility, this approach comes with limitations. First, multiple users may
execute off-chain validation, including intersecting block ranges resulting in unnec-
essary overhead. Second, even though off-chain computations result in low on-chain
validation costs, appropriate hardware is required that may exceed typical consumer
devicesetups. Third, the validationusingmemory-hard PoWis computationallycom-
plex and results in delays that may surpass the source blockchain’s configured block
mining rate. Delegating off-chain computations to users and service providers depicts
a promising mechanism for implementing efficient chain relays in the future. Users
requiring a specific state root can offer rewards for validating block headers off-chain
and submitting respective proofs. Validators deposit certain assets to prevent possible
fraud by accepting an offer without processing the requested block headers. Imple-
menting such an incentive mechanism using smart contracts ensures decentraliza-
tion while contributing to solving the described challenges as parallel and distributed
off-chain validation becomes available.
162 Chapter 12. Future Work
Utilizing efficient Merkle proof schemes. The EVM is supported bymanyblockchain
implementations [25] and thus constitutes the natural choice for implementing smart
contract forks and synchronizations. Ethereum applies Merkle Patricia trees of degree
16 for storing states resulting in large proofs [15, 216]. In addition, state modifications
may require reorganizations of the Merkle tree leading to computational overhead.
As a result, the high volume of call data and computational overhead drives smart
contract synchronization transaction costs. Alternative Merkle tree schemes will fa-
cilitate more efficient implementations in the future. For instance, the SSZ method
introduced with Ethereum 2.0 combines efficient serialization with a binary Merkle
tree [127]. Thus, the proof size is reduced, and complex deserialization of the current
Recursive Length Prefix (RLP) encoding is mitigated. So-called Verkletrees depict an-
other promising alternative to current Merkle tree implementations [216]. Here, vec-
torcommitmentsreplacethe cryptographichashfunctionsofMerkle trees to decrease
the node size ofhigh-degree trees. Due to these approaches’ increased efficiency, they
are expected to be utilized for future implementations of blockchain virtual machines.
Therefore, smart contract synchronizations will benefit from the reduced complexity
and proof size, resulting in low transaction fees.
Integrationofcross-chain schemes. Smartcontractsynchronizationsenable instant
function queries reflecting the state of a remotely hosted smart contract. However,
the function calls are read-only and do not provide cross-chain write access. Inte-
grating multiple smart contract invocation approaches will foster more flexible cross-
blockchainapplications. Forinstance,message-basedapproachesallowtheinvocation
of write functions. After the transaction is executed, the resulting state can be syn-
chronized to allow queries based on the updated state. Therefore, flexible write access
is provided while maintaining direct function calls that provide instant read access to
synchronized smart contracts.
163
Bibliography
[1] M. Westerkamp and J. Eberhardt. “zkRelay: Facilitating Sidechains using zk-
SNARK-based Chain-Relays”. In: 2020 IEEE European Symposium on Security
and Privacy Workshops (EuroS&PW). IEEE, 2020, pp. 378–386. doi: 10.1109/Eu
roSPW51379.2020.00058.
[2] M. Westerkamp and M. Diez. “Verilay: AVerifiable Proof ofStake Chain Relay”.
In: 2022 IEEEInternational Conference on Blockchain and Cryptocurrency (ICBC).
IEEE, 2022, pp. 1–9. doi: 10.1109/ICBC54727.2022.9805554.
[3] M. Westerkamp. “Verifiable Smart ContractPortability”. In: 2019IEEEInterna-
tional Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2019, pp. 1–9.
doi: 10.1109/BLOC.2019.8751335.
[4] M. Westerkamp and A. Küpper. “SmartSync: Cross-Blockchain Smart Con-
tract Interaction and Synchronization”. In: 2022 IEEE International Conference
on Blockchain and Cryptocurrency (ICBC). IEEE, 2022, pp. 1–9. doi: 10.1109/ICB
C54727.2022.9805524.
[5] M. Westerkamp, F. Victor, and A. Küpper. “Blockchain-based Supply Chain
Traceability: Token Recipes Model Manufacturing Processes”. In: 2018 IEEE
InternationalConferenceonBlockchain(Blockchain). IEEE, 2018, pp. 1595–1602.
doi: 10.1109/Cybermatics_2018.2018.00267.
[6] M. Westerkamp, F. Victor, and A. Küpper. “Tracing manufacturing processes
using blockchain-based token compositions”. In: Digital Communications and
Networks 6.2 (2020), pp. 167–176. doi: 10.1016/j.dcan.2019.01.007.
[7] M. Westerkamp, S. Göndör, and A. Küpper. “Tawki: Towards Self-Sovereign
SocialCommunication”.In:2019IEEEInternationalConferenceonDecentralized
Applications and Infrastructures (DAPPCON). IEEE, 2019, pp. 29–38. doi: 10.110
9/DAPPCON.2019.00014.
[8] M. Westerkamp and A. Küpper. “Instant Function Calls using Synchronized
Cross-Blockchain Smart Contracts”. In: IEEETransactionsonNetworkandSer-
vice Management (2023). Accepted for Publication. doi: 10.1109/TNSM.2023.3
236437.
[9] C. Rieger, M. Westerkamp, and H. Kuchen. “Challenges and Opportunities
of Modularizing Textual Domain-Specific Languages”. In: 2018 International
Conference on Model-Driven Engineering and Software Development (MODEL-
SWARD). SciTePress, 2018, pp. 387–395. doi: 10.5220/0006601903870395.
[10] M. Müller, S. R. Garzon, M. Westerkamp, and Z. A. Lux. “HIDALS: A Hybrid
IoT-based Decentralized Application for Logistics and Supply Chain Manage-
ment”. In: 2019IEEE10thAnnualInformationTechnology,ElectronicsandMobile
Communication Conference (IEMCON). IEEE, 2019, pp. 802–808. doi: 10.1109
/IEMCON.2019.8936305.
164 Bibliography
[11] S. Göndör, H. Yildiz, M. Westerkamp, and A. Küpper. “Blade: A Blockchain-
supported Architecture for Decentralized Services”. In: 2022IEEEInternational
Conference on Decentralized Applications and Infrastructures (DAPPS). IEEE,
2022, pp. 19–26. doi: 10.1109/DAPPS55202.2022.00011.
[12] F.TschorschandB.Scheuermann.“BitcoinandBeyond:ATechnicalSurveyon
Decentralized Digital Currencies”. In: IEEE Communications Surveys Tutorials
18.3 (2016), pp. 2084–2123. doi: 10.1109/COMST.2016.2535718.
[13] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. http://www.bitcoi
n.org/bitcoin.pdf. Accessed: 2023-02-24. 2008.
[14] V.Buterin.ANext-GenerationSmartContractandDecentralizedApplicationPlat-
form. https://ethereum.org/669c9e2e2027310b6b3cdce6e1c52962/Ethereum
_Whitepaper_-_Buterin_2014.pdf. Accessed: 2023-02-06. 2014.
[15] G. Wood et al. Ethereum: A secure decentralised generalised transaction ledger.
https://ethereum.github.io/yellowpaper/paper.pdf. Accessed: 2021-07-05.
2021.
[16] M. Zamani, M. Movahedi, and M. Raykova. “RapidChain: Scaling Blockchain
via Full Sharding”. In: 2018 ACM SIGSAC Conference on Computer and Commu-
nications Security (CCS). ACM, 2018, pp. 931–948. doi: 10.1145/3243734.324385
3.
[17] J. Wang and H. Wang. “Monoxide: Scale out Blockchain with Asynchronous
Consensus Zones”. In: 16th USENIX Conference on Networked Systems Design
and Implementation (NSDI). USENIX Association, 2019, pp. 95–112.
[18] C.Badertscher,P.Gaži,A.Kiayias,A.Russell,andV.Zikas.“OuroborosGenesis:
Composable Proof-of-Stake Blockchains with Dynamic Availability”. In: 2018
ACM SIGSAC ConferenceonComputerand Communications Security(CCS). ACM,
2018, pp. 913–930. doi: 10.1145/3243734.3243848.
[19] J. Chen and S. Micali. “Algorand: A secure and efficient distributed ledger”. In:
Theoretical Computer Science 777 (2019), pp. 155–183. doi: 10.1016/j.tcs.2019.0
2.001.
[20] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang. “Blockchain challenges and
opportunities: a survey”. In: International Journal of Web and Grid Services 14.4
(2018), pp. 352–375. doi: 10.1504/IJWGS.2018.095647.
[21] M. Sober, G. Scaffino, C. Spanring, and S. Schulte. “A Voting-Based Blockchain
Interoperability Oracle”. In: 2021 IEEE International Conference on Blockchain
(Blockchain). IEEE, 2021, pp. 160–169. doi: 10.1109/Blockchain53845.2021.00
030.
[22] S. Schulte, M. Sigwart, P. Frauenthaler, and M. Borkowski. “Towards Block-
chain Interoperability”. In: Business Process Management: Blockchain and Cen-
tral and Eastern Europe Forum. Springer International Publishing, 2019, pp. 3–
10. doi: 10.1007/978-3-030-30429-4_1.
[23] A. Beikverdi and J. Song. “Trend of centralization in Bitcoin’s distributed net-
work”.In:2015IEEE/ACIS16thInternationalConferenceonSoftwareEngineering,
Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD).
IEEE, 2015, pp. 1–6. doi: 10.1109/SNPD.2015.7176229.
[24] P. Frauenthaler, M. Borkowski, and S. Schulte. “A Framework for Assessing
and Selecting Blockchains at Runtime”. In: 2020 IEEE International Conference
Bibliography 165
onDecentralized ApplicationsandInfrastructures (DAPPS). IEEE, 2020, pp. 106–
113. doi: 10.1109/DAPPS49028.2020.00013.
[25] R. Jia and S. Yin. “To EVM or Not to EVM: Blockchain Compatibility and Net-
workEffects”.In:2022ACMCCSWorkshoponDecentralizedFinanceandSecurity
(DeFi). ACM, 2022, pp. 23–29. doi: 10.1145/3560832.3563442.
[26] E. Fynn, A. Bessani, and F. Pedone. “Smart Contracts on the Move”. In: 50th
Annual IEEE/IFIP International Conference on Dependable Systems and Networks
(DSN). IEEE, 2020, pp. 233–244. doi: 10.1109/DSN48063.2020.00040.
[27] G. Caldarelli. “Wrapping Trust for Interoperability: A Preliminary Study of
Wrapped Tokens”. In: Information 13.1 (2022). doi: 10.3390/info13010006.
[28] Z. Liu, Y. Xiang, J. Shi, P. Gao, H. Wang, X. Xiao, B. Wen, and Y.-C. Hu. “Hyper-
Service: Interoperability and Programmability Across Heterogeneous Block-
chains”. In: 2019 ACM SIGSAC Conferenceon Computerand Communications Se-
curity (CCS). ACM, 2019, pp. 549–566. doi: 10.1145/3319535.3355503.
[29] M. Nissl, E. Sallinger, S. Schulte, and M. Borkowski. “Towards Cross-Block-
chain SmartContracts”. In: 2021IEEEInternationalConferenceonDecentralized
Applications and Infrastructures (DAPPS). IEEE, 2021, pp. 85–94. doi: 10.1109
/DAPPS52256.2021.00015.
[30] P. Robinson and R. Ramesh. “General Purpose Atomic Crosschain Transac-
tions”.In:20213rdConferenceonBlockchainResearchApplicationsforInnovative
Networks and Services (BRAINS). IEEE, 2021, pp. 61–68. doi: 10.1109/BRAINS5
2497.2021.9569837.
[31] H. Al-Breiki, M. H. U. Rehman, K. Salah, and D. Svetinovic. “Trustworthy
Blockchain Oracles: Review, Comparison, and Open Research Challenges”. In:
IEEE Access 8 (2020), pp. 85675–85685. doi: 10.1109/ACCESS.2020.2992698.
[32] J. Adler, R. Berryhill, A. Veneris, Z. Poulos, N. Veira, and A. Kastania. “Astraea:
A Decentralized Blockchain Oracle”. In: 2018 IEEE International Conference on
Blockchain (Blockchain). IEEE, 2018, pp. 1145–1152. doi: 10.1109/Cybermatics
_2018.2018.00207.
[33] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi. “Town Crier: An Au-
thenticated Data Feed for Smart Contracts”. In: 2016 ACM SIGSAC Conference
onComputerandCommunicationsSecurity(CCS). ACM, 2016, pp. 270–282. doi:
10.1145/2976749.2978326.
[34] R. Weeks. How a fake job offer took down the world’s most popular crypto game.
https://www.theblock.co/post/156038/how-a-fake-job-offer-took-down-t
he-worlds-most-popular-crypto-game. Accessed: 2022-07-12.
[35] BTC Relay. https://github.com/ethereum/btcrelay. Accessed: 2021-07-14.
[36] J. Abou Jaoude and R. George Saade. “Blockchain Applications – Usage in Dif-
ferent Domains”. In: IEEE Access 7 (2019), pp. 45360–45381. doi: 10.1109/ACC
ESS.2019.2902501.
[37] A. R. Hevner, S. T. March, J. Park, and S. Ram. “Design science in information
systems research”. In: MIS quarterly 28 (2004), pp. 75–105. doi: 10.2307/2514
8625.
[38] J. E. v. Aken. “Management Research Based on the Paradigm of the Design
Sciences: The Quest for Field-Tested and Grounded Technological Rules”. In:
166 Bibliography
Journal of Management Studies 41.2 (2004), pp. 219–246. doi: 10.1111/j.1467-6
486.2004.00430.x.
[39] A. R. Hevner. “Athree cycle view of design science research”. In: Scandinavian
journal of information systems 19.2 (2007), pp. 87–92.
[40] National Institute of Standards and Technology. Blockchain Technology Over-
view.Tech.rep. NationalInstituteofStandardsandTechnologyInternalReport
8202. U.S. Department of Commerce, 2018. doi: 10.6028/NIST.IR.8202.
[41] D. Miehle, D. Henze, A. Seitz, A. Luckow, and B. Bruegge. “PartChain: A De-
centralized Traceability Application for Multi-Tier Supply Chain Networks in
the Automotive Industry”. In: 2019IEEE InternationalConference on Decentral-
ized Applications and Infrastructures (DAPPCON). IEEE, 2019, pp. 140–145. doi:
10.1109/DAPPCON.2019.00027.
[42] B. Liu, P. Szalachowski, and J. Zhou. “A First Look into DeFi Oracles”. In: 2021
IEEE International Conference on Decentralized Applications and Infrastructures
(DAPPS). IEEE, 2021, pp. 39–48. doi: 10.1109/DAPPS52256.2021.00010.
[43] T. M. Fernández-Caramés and P. Fraga-Lamas. “AReviewon the Use of Block-
chain for the Internet of Things”. In: IEEE Access 6 (2018), pp. 32979–33001.
doi: 10.1109/ACCESS.2018.2842685.
[44] X. Xu, C. Pautasso, L. Zhu, V. Gramoli, A. Ponomarev, A. B. Tran, and S. Chen.
“The Blockchain as a Software Connector”. In: 2016 13th Working IEEE/IFIP
Conference on Software Architecture (WICSA). IEEE, 2016, pp. 182–191. doi: 10.1
109/WICSA.2016.21.
[45] E. Deirmentzoglou, G. Papakyriakopoulos, and C. Patsakis. “A Survey on
Long-Range Attacks for Proof of Stake Protocols”. In: IEEE Access 7 (2019),
pp. 28712–28725. doi: 10.1109/ACCESS.2019.2901858.
[46] J. Garay, A. Kiayias, and N. Leonardos. “The Bitcoin Backbone Protocol: Analy-
sis and Applications”. In: AdvancesinCryptology(EUROCRYPT). Springer Berlin
Heidelberg, 2015, pp. 281–310. doi: 10.1007/978-3-662-46803-6_10.
[47] Y. Xiao, N. Zhang, W. Lou, and Y. T. Hou. “A Survey of Distributed Consensus
Protocols for Blockchain Networks”. In: IEEE Communications Surveys Tutori-
als 22.2 (2020), pp. 1432–1465. doi: 10.1109/COMST.2020.2969706.
[48] A. Stewart and E. Kokoris-Kogia. “GRANDPA: a Byzantine Finality Gadget”.
In: CoRR abs/2007.01560 (2020). arXiv: 2007.01560.
[49] V. Buterin, D. Hernandez, T. Kamphefner, K. Pham, Z. Qiao, D. Ryan, J. Sin, Y.
Wang, and Y. X. Zhang. “Combining GHOST and Casper”. In: CoRR abs/2003.-
03052 (2020). arXiv: 2003.03052.
[50] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton
Jones, and P. Wadler. “The Extended UTXO Model”. In: Financial Cryptogra-
phy and Data Security (FC). Springer International Publishing, 2020, pp. 525–
539. doi: 10.1007/978-3-030-54455-3_37.
[51] F. Reid and M. Harrigan. “An Analysis of Anonymity in the Bitcoin System”.
In: Security and Privacy in Social Networks. Springer New York, 2013, pp. 197–
223. doi: 10.1007/978-1-4614-4139-7_10.
[52] X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, and P. Rimba.
“A Taxonomy of Blockchain-Based Systems for Architecture Design”. In:
Bibliography 167
2017 IEEE International Conference on Software Architecture (ICSA). IEEE, 2017,
pp. 243–252. doi: 10.1109/ICSA.2017.33.
[53] A. Miller. “Permissioned and Permissionless Blockchains”. In: Blockchain for
Distributed Systems Security. John Wiley & Sons, Ltd, 2019. Chap. 9, pp. 193–
204. doi: 10.1002/9781119519621.ch9.
[54] M. Castro and B. Liskov. “Practical Byzantine Fault Tolerance”. In: 3rdSympo-
sium on Operating Systems Design and Implementation (OSDI). USENIX Associ-
ation, 1999, pp. 173–186.
[55] E. Androulaki et al. “Hyperledger Fabric: A Distributed Operating System for
Permissioned Blockchains”. In: 13th EuroSys Conference (EuroSys). ACM, 2018.
doi: 10.1145/3190508.3190538.
[56] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song. “The Honey Badger of BFT
Protocols”. In: 2016 ACM SIGSAC Conference on Computer and Communications
Security (CCS). ACM, 2016, pp. 31–42. doi: 10.1145/2976749.2978399.
[57] C. V. Helliar, L. Crawford, L. Rocca, C. Teodori, and M. Veneziani. “Permission-
less and permissioned blockchain diffusion”. In: International Journal of Infor-
mation Management 54 (2020). paper 102136. doi: 10.1016/j.ijinfomgt.2020.10
2136.
[58] K. Wüst and A. Gervais. “Do you Need a Blockchain?” In: 2018 Crypto Valley
Conference on Blockchain Technology (CVCBT). IEEE, 2018, pp. 45–54. doi: 10.1
109/CVCBT.2018.00011.
[59] N. Naik and P. Jenkins. “Sovrin Network for Decentralized Digital Iden-
tity: Analysing a Self-Sovereign Identity System Based on Distributed Ledger
Technology”. In: 2021 IEEE International Symposium on Systems Engineering
(ISSE). IEEE, 2021, pp. 1–7. doi: 10.1109/ISSE51541.2021.9582551.
[60] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang. “An Overview of Blockchain
Technology: Architecture, Consensus, and Future Trends”. In: 2017 IEEE In-
ternational Congress on Big Data (BigData Congress). IEEE, 2017, pp. 557–564.
doi: 10.1109/BigDataCongress.2017.85.
[61] J. R. Douceur. “The Sybil Attack”. In: Peer-to-Peer Systems (IPTPS). Springer
Berlin Heidelberg, 2002, pp. 251–260. doi: 10.1007/3-540-45748-8_24.
[62] P.Chatzigiannis,F.Baldimtsi,andK.Chalkias.“SoK:BlockchainLightClients”.
In: Financial Cryptography and Data Security (FC). Springer International Pub-
lishing, 2022, pp. 615–641. doi: 10.1007/978-3-031-18283-9_31.
[63] S. P. Gochhayat, S. Shetty, R. Mukkamala, P. Foytik, G. A. Kamhoua, and L.
Njilla. “Measuring Decentrality in Blockchain Based Systems”. In: IEEE Access
8 (2020), pp. 178372–178390. doi: 10.1109/ACCESS.2020.3026577.
[64] R. C. Merkle. “A Digital Signature Based on a Conventional Encryption Func-
tion”. In: Advances in Cryptology (CRYPTO). Springer Berlin Heidelberg, 1988,
pp. 369–378. doi: 10.1007/3-540-48184-2_32.
[65] M. Szydlo. “Merkle Tree Traversal in Log Space and Time”. In: Advances in
Cryptology (EUROCRYPT). Springer Berlin Heidelberg, 2004, pp. 541–554. doi:
10.1007/b97182.
[66] A. Mizrahi, N. Koren, and O. Rottenstreich. “Optimizing Merkle Proof Size for
Blockchain Transactions”. In: 2021InternationalConferenceonCOMmunication
168 Bibliography
Systems NETworkS (COMSNETS). IEEE, 2021, pp. 299–307. doi: 10.1109/COMS
NETS51098.2021.9352820.
[67] D. R. Morrison. “PATRICIA—Practical Algorithm To Retrieve Information
Coded in Alphanumeric”. In: Journal of the ACM 15.4 (Oct. 1968), pp. 514–534.
doi: 10.1145/321479.321481.
[68] P. Daian, R.Pass,andE. Shi.“SnowWhite: RobustlyReconfigurableConsensus
and Applications to Provably Secure Proof ofStake”. In: FinancialCryptography
andDataSecurity(FC). Springer International Publishing, 2019,pp. 23–41. doi:
10.1007/978-3-030-32101-7_2.
[69] L. Lamport. “The Part-Time Parliament”. In: ACM Transactions on Computer
Systems 16.2 (May 1998), pp. 133–169. doi: 10.1145/279227.279229.
[70] D. Ongaro and J. Ousterhout. “In Search of an Understandable Consensus Al-
gorithm”. In: 2014USENIX AnnualTechnicalConference(ATC). USENIX Associ-
ation, 2014, pp. 305–319.
[71] C. Dwork and M. Naor. “Pricing via Processing or Combatting Junk Mail”.
In: 12th Annual International Cryptology Conference on Advances in Cryptology
(CRYPTO). Springer Berlin Heidelberg, 1992, pp. 139–147. doi: 10.1007/3-540
-48071-4_10.
[72] A. Gervais, H.Ritzdorf,G. O.Karame,and S. Capkun.“Tamperingwith the De-
livery of Blocks and Transactions in Bitcoin”. In: 22nd ACM SIGSAC Conference
onComputerandCommunicationsSecurity(CCS). ACM, 2015, pp. 692–705. doi:
10.1145/2810103.2813655.
[73] R. Pass, L. Seeman, and A. Shelat. “Analysis of the Blockchain Protocol in
Asynchronous Networks”. In: Advances in Cryptology (EUROCRYPT). Springer
International Publishing, 2017, pp. 643–673. doi: 10.1007/978-3-319-56614-
6_22.
[74] I. Eyal and E. G. Sirer. “Majority Is Not Enough: Bitcoin Mining Is Vulnerable”.
In: Financial Cryptography and Data Security (FC). Springer Berlin Heidelberg,
2014, pp. 436–454. doi: 10.1145/3212998.
[75] J. Alwen, B. Chen, K. Pietrzak, L. Reyzin, and S. Tessaro. “Scrypt Is Maximally
Memory-Hard”. In: Advances in Cryptology (EUROCRYPT). Springer Interna-
tional Publishing, 2017, pp. 33–62. doi: 10.1007/978-3-319-56617-7_2.
[76] L. Stutzer. “State Validation of Ethash-based Blockchains using a zk-SNARK-
based Chain Relay”. MAthesis. KTH Royal Institute of Technology, Sept. 2022.
[77] A. Kiayias, A. Russell, B. David, and R. Oliynykov. “Ouroboros: A Prov-
ably Secure Proof-of-Stake Blockchain Protocol”. In: Advances in Cryptology
(CRYPTO). Springer International Publishing, 2017, pp. 357–388. doi: 10.100
7/978-3-319-63688-7_12.
[78] G. Wood. Polkadot: Vision for a Heterogeneous Multi-chain Framework. https://p
olkadot.network/PolkaDotPaper.pdf. Accessed: 2021-03-18. 2016.
[79] V. Buterin and V. Griffith. “Casper the Friendly Finality Gadget”. In: CoRR
abs/1710.09437 (2017). arXiv: 1710.09437.
[80] J. Kwon. Tendermint: Consensus without Mining. https://tendermint.com/static
/docs/tendermint.pdf. Accessed: 2023-02-06. 2014.
[81] M. Diez. “A Trustless Chain Relay for Proof of Stake Blockchains”. MA thesis.
Hasso Plattner Institute at University of Potsdam, Sept. 2021.
Bibliography 169
[82] S. Braithwaite, E. Buchman, I. Khoffi, I. Konnov, Z. Milosevic, R. Ruetschi, and
J. Widder. “ATendermint Light Client”. In: CoRR abs/2010.07031 (2020). arXiv:
2010.07031.
[83] A. Gervais, S. Capkun, G. O. Karame, and D. Gruber. “On the PrivacyProvisions
of Bloom Filters in Lightweight Bitcoin Clients”. In: 30th Annual Computer Se-
curity Applications Conference (ACSAC). ACM, 2014, pp. 326–335. doi: 10.1145/2
664243.2664267.
[84] B. Bünz, L. Kiffer, L. Luu, and M. Zamani. “FlyClient: Super-Light Clients for
Cryptocurrencies”. In: 2020IEEESymposiumonSecurityandPrivacy(SP).IEEE,
2020, pp. 928–946. doi: 10.1109/SP40000.2020.00049.
[85] P. Frauenthaler, M. Sigwart, C. Spanring, M. Sober, and S. Schulte. “ETH Re-
lay: A Cost-efficient Relay for Ethereum-based Blockchains”. In: 2020 Inter-
national Conference on Blockchain (Blockchain). IEEE, 2020, pp. 204–213. doi:
10.1109/Blockchain50366.2020.00032.
[86] D. Boneh, J. Bonneau, B. Bünz, and B. Fisch. “Verifiable Delay Functions”.
In: Advances in Cryptology (CRYPTO). Springer International Publishing, 2018,
pp. 757–788. doi: 10.1007/978-3-319-96884-1_25.
[87] V. Buterin, H.-W. Wang, E. Kissling, D. Ryan, A. Stokes, T. Tsao, and D. Loer-
akker. Altair – Minimal Light Client. https://github.com/ethereum/consensus
-specs/blob/dev/specs/altair. Accessed: 2022-03-01. 2022.
[88] P. Gaži, A. Kiayias, and D. Zindros. “Proof-of-Stake Sidechains”. In: 2019 IEEE
Symposium on Security and Privacy (SP). IEEE, 2019, pp. 677–694. doi: 10.1109
/SP.2019.00040.
[89] A. Kiayias, N. Lamprou, and A.-P. Stouka. “Proofs of Proofs of Work with Sub-
linear Complexity”. In: FinancialCryptographyandDataSecurity(FC). Springer
Berlin Heidelberg, 2016, pp. 61–78. doi: 10.1007/978-3-662-53357-4_5.
[90] A. Kiayias, A. Miller, and D. Zindros. “Non-interactive Proofs of Proof-of-
Work”. In: Financial Cryptography and Data Security (FC). Springer Interna-
tional Publishing, 2020, pp. 505–522. doi: 10.1007/978-3-030-51280-4_2
7.
[91] M. Bartoletti and L. Pompianu. “An Empirical Analysis of Smart Contracts:
Platforms, Applications, and Design Patterns”. In: Financial Cryptography and
Data Security (FC). Springer International Publishing, 2017, pp. 494–509. doi:
10.1007/978-3-319-70278-0_31.
[92] N. Atzei, M. Bartoletti, and T. Cimoli. “ASurveyof Attacks on Ethereum Smart
Contracts (SoK)”. In: Principles of Security and Trust (POST). Springer Berlin
Heidelberg, 2017, pp. 164–186. doi: 10.1007/978-3-662-54455-6_8.
[93] J. Eberhardt and S. Tai. “On or Off the Blockchain? Insights on Off-Chaining
Computation and Data”. In: Service-Oriented and Cloud Computing (ESOCC).
Springer International Publishing, 2017, pp. 3–15. doi: 10.1007/978- 3- 319
-67262-5_1.
[94] M. Walfish and A. J. Blumberg. “Verifying Computations without Reexecuting
Them”. In: Communications of the ACM 58.2 (Jan. 2015), pp. 74–84. doi: 10.114
5/2641562.
170 Bibliography
[95] T.Xie,J.Zhang,Y.Zhang,C.Papamanthou,andD.Song.“Libra:SuccinctZero-
Knowledge Proofs with Optimal Prover Computation”. In: AdvancesinCryptol-
ogy (CRYPTO). Springer International Publishing, 2019, pp. 733–764. doi: 10.1
007/978-3-030-26954-8_24.
[96] S. Goldwasser, S. Micali, and C. Rackoff. “The Knowledge Complexity of In-
teractive Proof-Systems”. In:ProvidingSoundFoundationsforCryptography:On
the Work of Shafi Goldwasser and Silvio Micali. ACM, 2019, pp. 203–225. doi: 10
.1145/3335741.3335750.
[97] A. Fiat and A. Shamir. “How To Prove Yourself: Practical Solutions to Identifi-
cationand SignatureProblems”. In:AdvancesinCryptology(CRYPTO). Springer
Berlin Heidelberg, 1987, pp. 186–194. doi: 10.1007/3-540-47721-7_12.
[98] S. Steffen, B. Bichsel, M. Gersbach, N. Melchior, P. Tsankov, and M. Vechev.
“Zkay: Specifying and Enforcing Data Privacy in Smart Contracts”. In: 2019
ACM SIGSAC ConferenceonComputerand Communications Security(CCS). ACM,
2019, pp. 1759–1776. doi: 10.1145/3319535.3363222.
[99] R. Gennaro, C. Gentry, B. Parno, and M. Raykova. “Quadratic Span Programs
and Succinct NIZKs without PCPs”. In: Advances in Cryptology (EUROCRYPT).
Springer Berlin Heidelberg, 2013, pp. 626–645. doi: 10.1007/978-3-642-3834
8-9_37.
[100] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell. “Bullet-
proofs: Short Proofs for Confidential Transactions and More”. In: 2018 IEEE
Symposium on Security and Privacy (SP). IEEE, 2018, pp. 315–334. doi: 10.1109
/SP.2018.00020.
[101] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev. “Scalable Zero Knowledge
with No Trusted Setup”. In: Advances in Cryptology (CRYPTO). Springer Inter-
national Publishing, 2019, pp. 701–732. doi: 10.1007/978-3-030-26954-8_23.
[102] J. Eberhardt and S. Tai. “ZoKrates - Scalable Privacy-Preserving Off-Chain
Computations”. In: 2018 IEEE International Conference on Blockchain (Block-
chain). IEEE, 2018, pp. 1084–1091. doi: 10.1109/Cybermatics_2018.2018.00
199.
[103] E. Ben-Sasson, A. Chiesa, M. Green, E. Tromer, and M. Virza. “Secure Sam-
pling of Public Parameters for Succinct Zero Knowledge Proofs”. In: 2015 IEEE
Symposium on Security and Privacy (SP). IEEE, 2015, pp. 287–304. doi: 10.1109
/SP.2015.25.
[104] J. Groth, M. Kohlweiss, M. Maller, S. Meiklejohn, and I. Miers. “Updatable
and Universal Common Reference Strings with Applications to zk-SNARKs”.
In: Advances in Cryptology (CRYPTO). Springer International Publishing, 2018,
pp. 698–728. doi: 10.1007/978-3-319-96878-0_24.
[105] J. Eberhardt. “Scalable and privacy-preserving off-chain computations”. PhD
thesis. Technische Universität Berlin, 2021.
[106] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza. “Succinct Non-Interactive
Zero Knowledge for a von Neumann Architecture”. In: 23rd USENIX Security
Symposium (USENIX Security). USENIX Association, 2014, pp. 781–796.
[107] B. Parno, J. Howell, C. Gentry, and M. Raykova. “Pinocchio: Nearly Practical
Verifiable Computation”. In: 2013 IEEE Symposium on Security and Privacy (SP).
IEEE, 2013, pp. 238–252. doi: 10.1109/SP.2013.47.
Bibliography 171
[108] J. Eberhardt and J. Heiss. “Off-Chaining Models and Approaches to Off-Chain
Computations”. In: 2nd Workshop on Scalable and Resilient Infrastructures for
Distributed Ledgers (SERIAL). ACM, 2018, pp. 7–12. doi: 10.1145/3284764.32
84766.
[109] T. P. Pedersen. “Non-Interactive and Information-Theoretic Secure Verifiable
Secret Sharing”. In: Advances in Cryptology (CRYPTO). Springer Berlin Heidel-
berg, 1992, pp. 129–140. doi: 10.1007/3-540-46766-1_9.
[110] D. Hopwood, S. Bowe, T. Hornby, and N. Wilcox. Zcash Protocol Specification -
Version 2022.3.8. https://github.com/zcash/zips/blob/main/protocol/protocol
.pdf. Accessed: 2023-01-31. 2022.
[111] P.W.Shor.“Polynomial-TimeAlgorithmsforPrimeFactorizationandDiscrete
Logarithms on a Quantum Computer”. In: SIAM Review 41.2 (1999), pp. 303–
332. doi: 10.1137/S0036144598347011.
[112] M. Liskov.“Updatable Zero-Knowledge Databases”. In: AdvancesinCryptology
(ASIACRYPT). Springer Berlin Heidelberg, 2005, pp. 174–198. doi: 10.1007/115
93447_10.
[113] L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger. “Po-
seidon: A New Hash Function for Zero-Knowledge Proof Systems”. In: 30th
USENIX Security Symposium (USENIX Security). USENIX Association, 2021,
pp. 519–535.
[114] L. Grassi, R. Lüftenegger, C. Rechberger, D. Rotaru, and M. Schofnegger. “On
a Generalization of Substitution-Permutation Networks: The HADES Design
Strategy”. In: Advances in Cryptology (EUROCRYPT). Springer International
Publishing, 2020, pp. 674–704. doi: 10.1007/978-3-030-45724-2_23.
[115] L. Goldberg, S. Papini, and M. Riabzev. Cairo - a Turing-complete STARK-
friendly CPU architecture. Cryptology ePrint Archive, Paper 2021/1063. https:
//eprint.iacr.org/2021/1063. 2021.
[116] M. Borkowski, M. Sigwart, P. Frauenthaler, T. Hukkinen, and S. Schulte.
“Dextt: Deterministic Cross-Blockchain Token Transfers”. In: IEEE Access 7
(2019), pp. 111030–111042. doi: 10.1109/ACCESS.2019.2934707.
[117] J. Heiss, J. Eberhardt, and S. Tai. “From Oracles to Trustworthy Data On-
ChainingSystems”.In:2019IEEEInternationalConferenceonBlockchain(Block-
chain). IEEE, 2019, pp. 496–503. doi: 10.1109/Blockchain.2019.00075.
[118] R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia. “A Survey on Block-
chain Interoperability: Past, Present, and Future Trends”. In: ACM Computing
Surveys 54.8 (Oct. 2021). doi: 10.1145/3471140.
[119] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Sax-
ena, E. Shi, E. Gün Sirer, D. Song, and R. Wattenhofer. “On Scaling Decentral-
ized Blockchains”. In: Financial Cryptography and Data Security (FC). Springer
Berlin Heidelberg, 2016, pp. 106–125. doi: 10.1007/978-3-662-53357-4_8.
[120] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena. “A Secure
Sharding Protocol For Open Blockchains”. In: 2016 ACM SIGSAC Conference on
Computer and Communications Security (CCS). ACM, 2016, pp. 17–30. doi: 10.1
145/2976749.2978389.
172 Bibliography
[121] E. Androulaki, C. Cachin, A. De Caro, and E. Kokoris-Kogias. “Channels: Hor-
izontal Scaling and Confidentiality on Permissioned Blockchains”. In: Com-
puter Security (ESORICS). Springer International Publishing, 2018, pp. 111–131.
doi: 10.1007/978-3-319-99073-6_6.
[122] J. Burdges, A. Cevallos, P. Czaban, R. Habermeier, S. Hosseini, F. Lama, H. K.
Alper, X. Luo, F. Shirazi, A. Stewart, and G. Wood. “Overview of Polkadot and
its Design Considerations”. In: CoRR abs/2005.13456 (2020). arXiv: 2005.1345
6.
[123] J. Kwon and E. Buchman. Cosmos: A Network of Distributed Ledgers. https://gi
thub.com/cosmos/cosmos/blob/master/WHITEPAPER.md. Accessed: 2021-
07-20. 2018.
[124] G. Wang, Z. J. Shi, M. Nixon, and S. Han. “SoK: Sharding on Blockchain”. In:
1st ACM Conference on Advances in Financial Technologies (AFT). ACM, 2019,
pp. 41–61. doi: 10.1145/3318041.3355457.
[125] S. Micali, M. Rabin, and S. Vadhan. “Verifiable random functions”. In: 40th
Annual Symposium on Foundations of Computer Science (FOCS). IEEE, 1999,
pp. 120–130. doi: 10.1109/SFFCS.1999.814584.
[126] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. “Algorand: Scaling
Byzantine Agreements for Cryptocurrencies”. In: 26th Symposium on Operat-
ing Systems Principles (SOSP). ACM, 2017, pp. 51–68. doi: 10.1145/3132747.3132
757.
[127] Ethereum Proof-of-Stake Consensus Specifications. https://github.com/ethereu
m/consensus-specs. Accessed: 2021-11-17. 2021.
[128] A. Skidanov and I. Polosukhin. Nightshade:Nearprotocolshardingdesign. https:
//nearprotocol.com/downloads/Nightshade.pdf. Accessed: 2022-07-04. 2019.
[129] W.Martino,M.Quaintance,andS.Popejoy.Chainweb:Aproof-of-workparallel-
chain architecture for massive throughput. https://neironix.io/documents/whit
epaper/6793/chainweb-v15.pdf. Accessed: 2022-07-04. 2018.
[130] V. Buterin. Chain Interoperability. https://allquantor.at/blockchainbib/pdf/but
erin2016chain.pdf. Accessed: 2023-02-06. 2016.
[131] R. Lan, G. Upadhyaya, S. Tse, and M. Zamani. “Horizon: A Gas-Efficient,
Trustless Bridge for Cross-Chain Transactions”. In: CoRR abs/2101.06000
(2021). arXiv: 2101.06000.
[132] M. Zavershynskyi. ETH-NEAR Rainbow Bridge. https://near.org/blog/eth-nea
r-rainbow-bridge/. Accessed: 2021-08-04. 2020.
[133] T. Baneth. Waterloo - a Decentralized Practical Bridge between EOS and Ether-
eum. https://blog.kyber.network/waterloo-a-decentralized-practical-bridg
e-between-eos-and-ethereum-1c230ac65524. Accessed: 2021-08-04. 2019.
[134] J. Teutsch, M. Straka, and D. Boneh. “Retrofitting a two-way peg between
blockchains”. In: CoRR abs/1908.03999 (2019). arXiv: 1908.03999.
[135] J. Teutsch and C. Reitwießner. “A scalable verification solution for block-
chains”. In: CoRR abs/1908.04756 (2019). arXiv: 1908.04756.
[136] A. Kiayias and D. Zindros. “Proof-of-Work Sidechains”. In: Financial Cryptog-
raphy and Data Security (FC). Springer International Publishing, 2020, pp. 21–
34. doi: 10.1007/978-3-030-43725-1_3.
Bibliography 173
[137] A. Zamyatin, N. Stifter, A. Judmayer, P. Schindler, E. Weippl, and W. J. Knot-
tenbelt. “A Wild Velvet Fork Appears! Inclusive Blockchain Protocol Changes
in Practice”. In: Financial Cryptography and Data Security (FC). Springer Berlin
Heidelberg, 2019, pp. 31–42. doi: 10.1007/978-3-662-58820-8_3.
[138] A. Kiayias, A. Polydouri, and D. Zindros. “The Velvet Path to Superlight Block-
chain Clients”. In: 3rd ACM Conference on Advances in Financial Technologies
(AFT). ACM, 2021, pp. 205–218. doi: 10.1145/3479722.3480999.
[139] H. Jin, X. Dai, and J. Xiao. “Towards a Novel Architecture for Enabling Interop-
erability amongst Multiple Blockchains”. In: 2018 IEEE 38th International Con-
ference on Distributed Computing Systems (ICDCS). IEEE, 2018, pp. 1203–1211.
doi: 10.1109/ICDCS.2018.00120.
[140] N. Kannengießer, M. Pfister, M. Greulich, S. Lins, and A. Sunyaev. “Bridges be-
tween islands: Cross-chain technology for distributed ledger technology”. In:
53rd Hawaii International Conference on System Sciences (HICSS). ScholarSpace,
2020. doi: 10.24251/HICSS.2020.652.
[141] D. Boneh, B. Lynn, and H. Shacham. “Short Signatures from the Weil Pairing”.
In: Advances in Cryptology (ASIACRYPT). Springer Berlin Heidelberg, 2001,
pp. 514–532. doi: 10.1007/3-540-45682-1_30.
[142] J. Dilley, A. Poelstra, J. Wilkins, M. Piekarska, B. Gorlick, and M. Frieden-
bach. “Strong Federations: An Interoperable Blockchain Solution to Central-
ized Third Party Risks”. In: CoRR abs/1612.05491 (2016). arXiv: 1612.05491.
[143] L.Breidenbach, C.Cachin,B.Chan,A. Coventry, S.Ellis, A.Juels,F. Koushanfar,
A. Miller, B. Magauran, D. Moroz, et al. Chainlink 2.0: Next steps in the evolution
of decentralized oracle networks. https://research.chain.link/whitepaper-v2.p
df. Accessed: 2022-07-11. 2021.
[144] M. Sigwart, P. Frauenthaler, C.Spanring,M.Sober, and S. Schulte. “Decentral-
ized Cross-Blockchain Asset Transfers”. In: 2021 3rd International Conference
on Blockchain Computing and Applications (BCCA). IEEE, 2021, pp. 34–41. doi:
10.1109/BCCA53669.2021.9657007.
[145] M. Herlihy. “Atomic Cross-Chain Swaps”. In: 2018 ACM Symposium on Princi-
ples of Distributed Computing (PODC). ACM, 2018, pp. 245–254. doi: 10.1145/32
12734.3212736.
[146] M. Herlihy, B. Liskov, and L. Shrira. “Cross-chain deals and adversarial com-
merce”. In: The VLDB Journal 31.6 (2022), pp. 1291–1309. doi: 10.1007/s00778
-021-00686-1.
[147] S. Thyagarajan, G. Malavolta, and P. Moreno-Sanchez. “Universal Atomic
Swaps: Secure Exchange of Coins Across All Blockchains”. In: 2022 IEEE Sym-
posium on Security and Privacy (SP). IEEE, 2022, pp. 1083–1100. doi: 10.1109
/SP46214.2022.00063.
[148] T. Nadahalli, M. Khabbazian, and R. Wattenhofer. “Grief-free Atomic Swaps”.
In: 2022 IEEEInternational Conference on Blockchain and Cryptocurrency (ICBC).
IEEE, 2022, pp. 1–9. doi: 10.1109/ICBC54727.2022.9805490.
[149] J. Xu, D. Ackerer, and A. Dubovitskaya. “A Game-Theoretic Analysis of Cross-
Chain Atomic Swaps with HTLCs”. In: 2021 IEEE 41st International Conference
on Distributed Computing Systems (ICDCS). IEEE, 2021, pp. 584–594. doi: 10.11
09/ICDCS51616.2021.00062.
174 Bibliography
[150] A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais, and W. Knottenbelt.
“XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets”. In: 2019
IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp. 193–210. doi: 10
.1109/SP.2019.00085.
[151] Axelar Team. General Message Passing. https://docs.axelar.dev/dev/gmp-over
view. Accessed: 2022-12-23. 2022.
[152] Alistair Stewartand Fatemeh Shirazi and Ximin Luo. Web3foundationresearch:
XCMP. https://research.web3.foundation/en/latest/polkadot/XCMP/index.ht
ml. Accessed: 2022-12-01. 2022.
[153] C. Goes. “The Interblockchain Communication Protocol: An Overview”. In:
CoRR abs/2006.15918 (2020). arXiv: 2006.15918.
[154] R. Zarick, B. Pellegrino, and C. Banister. “LayerZero: Trustless Omnichain In-
teroperability Protocol”. In: CoRR abs/2110.13871 (2021). arXiv: 2110.13871.
[155] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poel-
stra, J. Timón, and P. Wuille. Enabling Blockchain Innovations with Pegged Side-
chains. https://blockstream.com/sidechains.pdf. Accessed: 2022-01-17. 2014.
[156] Bitcoin protocol documentation. https://en.bitcoin.it/wiki/Protocol_document
ation. Accessed: 2019-11-13.
[157] L. Luu, Y. Velner, J. Teutsch, and P. Saxena. “SmartPool: Practical Decentral-
ized Pooled Mining”. In: 26th USENIX Security Symposium (USENIX Security).
USENIX Association, 2017, pp. 1409–1426.
[158] M. Bellés-Muñoz, J. Baylina, V. Daza, and J. L. Muñoz-Tapia. “New Privacy
Practices for Blockchain Software”. In: IEEE Software 39.3 (2022), pp. 43–49.
doi: 10.1109/MS.2021.3086718.
[159] L. L. George. “STARK-based Chain Relays”. BAThesis. Technische Universität
Berlin, June 2022.
[160] StarkWare. StarkNeetDocumentation-FeeMechanism. https://docs.starknet.io
/documentation/develop/Fees/fee-mechanism/. Accessed: 2022-10-14. 2022.
[161] M. Albrecht, L. Grassi, C. Rechberger, A. Roy, and T. Tiessen. “MiMC: Efficient
Encryption and Cryptographic Hashing with Minimal Multiplicative Com-
plexity”. In: Advances in Cryptology (ASIACRYPT). Springer Berlin Heidelberg,
2016, pp. 191–219. doi: 10.1007/978-3-662-53887-6_7.
[162] J. Groth. “On the Size of Pairing-Based Non-interactive Arguments”. In: Ad-
vances in Cryptology (EUROCRYPT). Springer Berlin Heidelberg, 2016, pp. 305–
326. doi: 10.1007/978-3-662-49896-5_11.
[163] J. Groth and M. Maller. “Snarky Signatures: Minimal Signatures of Knowledge
from Simulation-Extractable SNARKs”. In: Advances in Cryptology (CRYPTO).
Springer International Publishing, 2017, pp. 581–612. doi: 10.1007/978-3-319
-63715-0_20.
[164] A. Chiesa, Y. Hu, M. Maller, P. Mishra, N. Vesely, and N. Ward. “Marlin: Prepro-
cessing zkSNARKs with Universal and Updatable SRS”. In: Advances in Cryp-
tology (EUROCRYPT). Springer International Publishing, 2020, pp. 738–768.
doi: 10.1007/978-3-030-45721-1_26.
Bibliography 175
[165] M. Platt, J. Sedlmeir, D. Platt, J. Xu, P. Tasca, N. Vadgama, and J. I. Ibañez.
“The Energy Footprint of Blockchain Consensus Mechanisms Beyond Proof-
of-Work”. In: 2021 IEEE 21st International Conference on Software Quality, Reli-
ability and Security Companion (QRS-C). IEEE, 2021, pp. 1135–1144. doi: 10.110
9/QRS-C55045.2021.00168.
[166] E. Buchman, J. Kwon, and Z. Milosevic. “The latest gossip on BFT consensus”.
In: CoRR abs/1807.04938 (2018). arXiv: 1807.04938.
[167] S. Daveas, K. Karantias, A. Kiayias, and D. Zindros. “AGas-EfficientSuperlight
Bitcoin Client in Solidity”. In: 2nd ACM Conference on Advances in Financial
Technologies (AFT). ACM, 2020, pp. 132–144. doi: 10.1145/3419614.3423255.
[168] K. Toyoda, P. T. Mathiopoulos, I. Sasase, and T. Ohtsuki. “A Novel Blockchain-
Based ProductOwnership ManagementSystem (POMS) for Anti-Counterfeits
in the Post Supply Chain”. In: IEEE Access 5 (2017), pp. 17465–17477. doi: 10.11
09/ACCESS.2017.2720760.
[169] K. Korpela, J. Hallikas, and T. Dahlberg. “Digital Supply Chain Transforma-
tion toward Blockchain Integration”. In: 50th Hawaii International Conference
on System Sciences (HICSS). ScholarSpace, 2017. doi: 10.24251/HICSS.2017.506.
[170] A. Chakravorty and C. Rong. “Ushare: User Controlled Social Media Based on
Blockchain”. In: 11th International Conference on Ubiquitous Information Man-
agement and Communication (IMCOM). paper 99. ACM, 2017. doi: 10.1145/302
2227.3022325.
[171] S. Biedermann, N. P. Karvelas, S. Katzenbeisser, T. Strufe, and A. Peter. “Proof-
Book: An Online Social Network Based on Proof-of-Work and Friend-Propa-
gation”. In: Theory and Practice of Computer Science (SOFSEM). Springer Inter-
national Publishing, 2014, pp. 114–125. doi: 10.1007/978-3-319-04298-5_11.
[172] A. Mühle, A. Grüner, T. Gayvoronskaya, and C. Meinel. “A survey on essen-
tial components of a self-sovereign identity”. In: Computer Science Review 30
(2018), pp. 80–86. doi: 10.1016/j.cosrev.2018.10.002.
[173] M. Ali, J. Nelson, R. Shea, and M. J. Freedman. “Blockstack: A Global Naming
and Storage System Secured by Blockchains”. In: 2016 USENIX Conference on
Usenix Annual Technical Conference (ATC). USENIX Association, 2016, pp. 181–
194.
[174] J. Eberhardt, M. Peise, D.-H. Kim, and S. Tai. “Privacy-Preserving Netting in
Local Energy Grids”. In: 2020 IEEE International Conference on Blockchain and
Cryptocurrency (ICBC). IEEE, 2020, pp. 1–9. doi: 10.1109/ICBC48266.2020.916
9440.
[175] T. Hardjono, A. Lipton, and A. Pentland. “Towards a Design Philosophy for In-
teroperable Blockchain Systems”. In: CoRR abs/1805.05934 (2018). arXiv: 1805
.05934.
[176] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. “Eclipse Attacks on Bit-
coin’s Peer-to-Peer Network”. In: 24th USENIX Conference on Security Sympo-
sium (SEC). USENIX Association, 2015, pp. 129–144.
[177] D. K. Tosh, S. Shetty, X. Liang, C. A. Kamhoua, K. A. Kwiat, and L. Njilla. “Se-
curity Implications of Blockchain Cloud with Analysis of Block Withholding
Attack”. In: 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid
Computing (CCGrid). IEEE, 2017, pp. 458–467. doi: 10.1109/CCGRID.2017.111.
176 Bibliography
[178] K. Shudo, R. Kanda, and K. Saito. “Towards Application Portability on Block-
chains”. In: 2018 1st IEEE International Conference on Hot Information-Centric
Networking (HotICN). IEEE, 2018, pp. 51–55. doi: 10.1109/HOTICN.2018.86059
77.
[179] G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, and R. Hierons.
“Smart contracts vulnerabilities: a call for blockchain software engineering?”
In: 2018 International Workshop on Blockchain Oriented Software Engineering
(IWBOSE). IEEE, 2018, pp. 19–25. doi: 10.1109/IWBOSE.2018.8327567.
[180] Ethereum Foundation. Solidity - Layout of State Variables in Storage. https://do
cs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html?highlight=la
yout-of-state-variables-in-storage. Accessed: 25.11.2022. 2022.
[181] Ethereum Foundation. Data Structures and Encoding: Merkle Patricia Trees. http
s://ethereum.org/en/developers/docs/data-structures-and-encoding/patrici
a-merkle-trie. Accessed: 2023-02-06. 2023.
[182] The go-ethereum Authors. Go Ethereum: debug Namespace - traceTransaction.
https://geth.ethereum.org/docs/rpc/ns-debug#debug_tracetransaction.
Accessed: 2022-11-25. 2022.
[183] Parity Technologies. The trace Module - trace_transaction. https://openethere
um.github.io/JSONRPC-trace-module. Accessed: 2022-11-25. 2022.
[184] Parity Technologies. The Parity Module - parity_listStorageKeys. https://open
ethereum.github.io/JSONRPC-parity-module#parity_liststoragekeys. Ac-
cessed: 2022-11-25. 2022.
[185] ConsenSys Software Inc. Trufflesuite - Ganache. https://github.com/trufflesui
te/ganache. Accessed: 2023-01-01. 2023.
[186] F. Victor and B. K. Lüders. “Measuring Ethereum-Based ERC20 Token Net-
works”. In: Financial Cryptography and Data Security (FC). Springer Interna-
tional Publishing, 2019, pp. 113–129. doi: 10.1007/978-3-030-32101-7_8.
[187] Uniswapv2Core. https://uniswap.org/whitepaper.pdf. Accessed: 2022-09-08.
[188] L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais. “SoK:
Layer-TwoBlockchain Protocols”. In: FinancialCryptographyandDataSecurity
(FC). Springer International Publishing, 2020, pp. 201–226. doi: 10.1007/978
-3-030-51280-4_12.
[189] L. T. Thibault, T. Sarry, and A. S. Hafid. “Blockchain Scaling Using Rollups:
A Comprehensive Survey”. In: IEEE Access 10 (2022), pp. 93039–93054. doi:
10.1109/ACCESS.2022.3200051.
[190] F. Tian. “A supply chain traceability system for food safety based on HACCP,
blockchain & Internet of things”. In: 2017 International Conference on Service
Systems and Service Management. IEEE, 2017, pp. 1–6. doi: 10.1109/ICSSSM.20
17.7996119.
[191] K. Kupferschmidt. “As Musk reshapes Twitter, academics ponder taking
flight”. In: Science 378.6620 (Nov. 2022), pp. 583–584. doi: 10.1126/science
.adf6617.
[192] S. Göndör and A. Küpper. “The Current State of Interoperability in Decen-
tralized Online Social Networking Services”. In: 2017 International Conference
on Computational Science and Computational Intelligence (CSCI). 2017, pp. 852–
857. doi: 10.1109/CSCI.2017.148.
Bibliography 177
[193] S. M. Werner, D. Perez, L. Gudgeon, A. Klages-Mundt, D. Harz, and W. J. Knot-
tenbelt. “SoK: Decentralized Finance (DeFi)”. In: CoRR abs/2101.08778 (2021).
arXiv: 2101.08778.
[194] F. Dabbene, P. Gay, and C. Tortia. “Traceability issues in food supply chain
management: A review”. In: Biosystems Engineering 120 (2014), pp. 65 –80.
doi: 10.1016/j.biosystemseng.2013.09.006.
[195] J. Gualandris, R. D. Klassen, S. Vachon, and M. Kalchschmidt. “Sustainable
evaluation and verification in supplychains: Aligning and leveraging account-
ability to stakeholders”. In: Journal of Operations Management 38 (2015), pp. 1
–13. doi: 10.1016/j.jom.2015.06.002.
[196] European Parliament. Regulation (EC) No 178/2002 of the European Parliament
and of the Council of 28 January 2002 laying down the general principles and re-
quirements of food law, establishing the European Food Safety Authority and lay-
ing down procedures in matters of food safety. https://eur-lex.europa.eu/leg
al-content/EN/TXT/PDF/?uri=CELEX:32002R0178&from=DE. Accessed:
2023-01-05. 2002.
[197] S. Appelhanz, V.-S. Osburg, W. Toporowski, and M. Schumann. “Traceability
system for capturing, processing and providing consumer-relevant informa-
tion about wood products: system solution and its economic feasibility”. In:
JournalofCleanerProduction 110 (2016). Special Volume: Improved resource ef-
ficiency and cascading utilisation of renewable materials, pp. 132 –148. doi: 1
0.1016/j.jclepro.2015.02.034.
[198] S. A. Abeyratne and R. P. Monfared. “Blockchain ready manufacturing supply
chain using distributed ledger”. In: International Journal of Research in Engi-
neering and Technology 05 (Sept. 2016). doi: 10.15623/ijret.2016.0509001.
[199] F. Glaser. “Pervasive Decentralisation of Digital Infrastructures: A Framework
for Blockchain enabled System and Use Case Analysis”. In: 50th Hawaii Inter-
national Conference on System Sciences (HICSS). ScholarSpace, 2017. doi: 10.24
251/HICSS.2017.186.
[200] H. M. Kim and M. Laskowski. “Toward an ontology-driven blockchain de-
sign for supply-chain provenance”. In: Intelligent Systems in Accounting, Fi-
nance and Management 25.1 (2018), pp. 18–27. doi: 10.1002/isaf.1424.
[201] A. Bechini, M. G. Cimino, F. Marcelloni, and A. Tomasi. “Patterns and tech-
nologies for enabling supply chain traceability through collaborative e-busi-
ness”. In: Information and Software Technology 50.4 (2008), pp. 342 –359. doi:
10.1016/j.infsof.2007.02.017.
[202] G. S. Ramachandran, S. Malik, S. Pal, A. Dorri, V. Dedeoglu, S. Kanhere, and
R. Jurdak. “Blockchain in Supply Chain: Opportunities and Design Consider-
ations”. In: Handbook on Blockchain. Springer International Publishing, 2022,
pp. 541–576. doi: 10.1007/978-3-031-07535-3_17.
[203] B. David, P. Gaži, A. Kiayias, and A. Russell. “Ouroboros Praos: An Adaptively-
Secure, Semi-synchronous Proof-of-Stake Blockchain”. In: Advances in Cryp-
tology(EUROCRYPT). Springer International Publishing, 2018, pp. 66–98. doi:
10.1007/978-3-319-78375-8_3.
[204] S. Gilbertson. Slap in the Facebook: It’s Time for Social Networks to Open Up. http
s://www.wired.com/2007/08/open-social-net/. Accessed: 2023-01-05. 2007.
178 Bibliography
[205] T. Paul, A. Famulari, and T. Strufe. “A Survey on Decentralized Online Social
Networks”. In: Computer Networks 75, Part A (2014), pp. 437–452. doi: 10.101
6/j.comnet.2014.10.005.
[206] D. Koll, J. Li, and X. Fu. “The Good Left Undone: Advances and Challenges
in Decentralizing Online Social Networks”. In: Computer Communications 108
(2017), pp. 36–51. doi: 10.1016/j.comcom.2017.04.008.
[207] C.-m. A. Yeung, I. Liccardi, K. Lu, O. Seneviratne, and T. Berners-Lee. “Decen-
tralization: The future of online social networking”. In: W3C workshop on the
future of social networking position papers. Vol. 2. 2009, pp. 2–7.
[208] European Parliament. Regulation (EU) 2016/679 of the European Parliament and
of the Council of 27 April 2016 on the Protection of Natural Persons With Regard
to the Processing of Personal Data and on the Free Movement of Such Data, and
Repealing Directive 95/46/EC (General Data Protection Regulation). http://eur-l
ex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from
=EN. Accessed: 2023-01-05. 2016.
[209] M. Marcon,B.Viswanath,M.Cha, andK. P.Gummadi. “SharingSocial Content
from Home: A Measurement-Driven Feasibility Study”. In: 21st International
Workshop on Network and Operating Systems Support for Digital Audio and Video
(NOSSDAV). ACM, 2011, pp. 45–50. doi: 10.1145/1989240.1989253.
[210] G. Falazi, U. Breitenbücher, F. Daniel, A. Lamparelli, F. Leymann, and V. Yus-
supov. “Smart Contract Invocation Protocol (SCIP): A Protocol for the Uni-
formIntegration of Heterogeneous Blockchain SmartContracts”. In: Advanced
Information Systems Engineering (CAiSE). Springer International Publishing,
2020, pp. 134–149. doi: 10.1007/978-3-030-49435-3_9.
[211] G. Angeris and T. Chitra. “Improved Price Oracles: Constant Function Market
Makers”. In: 2nd ACM Conference on Advances in Financial Technologies (AFT).
ACM, 2020, pp. 80–91. doi: 10.1145/3419614.3423251.
[212] R. Fritsch. “Concentrated Liquidity in Automated Market Makers”. In: 2021
ACM CCS Workshop on Decentralized Finance and Security (DeFi). ACM, 2021,
pp. 15–20. doi: 10.1145/3464967.3488590.
[213] K. Qin, L. Zhou, and A. Gervais. “Quantifying Blockchain Extractable Value:
How dark is the forest?” In: 2022 IEEE Symposium on Security and Privacy (SP).
IEEE, 2022, pp. 198–214. doi: 10.1109/SP46214.2022.9833734.
[214] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer. “Recursive Composition and
Bootstrapping for SNARKS and Proof-Carrying Data”. In: 45th Annual ACM
Symposium on Theory of Computing (STOC). ACM, 2013, pp. 111–120. doi: 10.11
45/2488608.2488623.
[215] T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y. Zhang, Y. Jia, D. Boneh, and D.
Song. “ZkBridge: Trustless Cross-Chain Bridges Made Practical”. In: 2022
ACM SIGSAC ConferenceonComputer and Communications Security(CCS). ACM,
2022, pp. 3003–3017. doi: 10.1145/3548606.3560652.
[216] J. Kuszmaul. Verkle trees. https://math.mit.edu/research/highschool/primes
/materials/2018/Kuszmaul.pdf. Accessed: 2023-01-26. 2018.
