Je Soussignée

Marianna Belotti

LIST OF FIGURES 4.2 Two party 'atomic' cross-chain swap protocol proposed in [5; 6] characterized by sequential publishing and commitment: σ P = {(x, B), (y, A)} and σ T = {(y, A), (x, B)}. 4.3 Extensive form game associated to the blockchains swap protocol, presented in [5]. Publishing and commitment phases are sequentially executed one after the other. Outcomes represent the payoffs (assets) owned by Alice and Bob respectively. The figure represents the backward induction process for each decision step. . . . . . . . . . . . . 4.4 Two party AC3TW cross-chain swap protocol proposed in [7] characterized by concurrent publishing and snap commitment. It is represented by the following formalization: σ P = {({x, y}, {A, B})} and σ T = {({x, y}, {A, B}, {X 1 (x) = B, X 1 (y) = A})}. . . . . 4.5 Normal form game associated to the blockchains swap protocol, presented in [7]. Alice and Bob decide whether to publish or not the contract on the corresponding blockchain. Outcomes represent the payoffs of Alice and Bob respectively. By eliminating dominated strategies the emphasized outcomes are the equilibria of the game. The dominant B and Γ rout C . . . .

Vorrei dedicare questa tesi ai miei desideri, sogni e progetti che possono cominciare ora a realizzarsi. I would like to dedicate this thesis to my wishes, dreams and projects that can now start to come true.

Je souhaiterais dédier cette thèse à mes souhaits, mes rêves et mes projets qui peuvent maintenant commencer à se réaliser.

Résumé

La technologie disruptive née en 2008 avec Bitcoin et connue sous le nom de blockchain représente un saut qualitatif important par rapport à la technologie des bases de données distribuées. La théorie des systèmes distribués fournit alors des modèles et des techniques pour analyser certains protocoles caractérisant la technologie, cependant afin d'analyser un système blockchain des considérations supplémentaires sur ses utilisateurs doivent être faites. Cette thèse vise à analyser les différents comportements des utilisateurs opérant dans les blockchains ou plus largement dans les DLTs (i.e., Distributed Ledger Technologies). Ces derniers sont considérés comme des agents rationnels, pleinement conscients de toutes les actions à leur disposition et capables de choisir celle qui leur semble la meilleure pour eux-mêmes. La théorie des jeux est alors utilisée pour modéliser des situations où les utilisateurs sont appelés à choisir et à effectuer certaines actions dans l'environnement DLT. Cette thèse analyse différents utilisateurs ainsi que différentes blockchains dans le but de fournir une vue d'ensemble sur le sujet et des résultats formels sur leurs comportements ; les utilisateurs peuvent en effet être honnêtes vis-à-vis des autres utilisateurs ou se comporter de manière malveillante (comme des noeuds byzantins) en attaquant le système blockchain.

Mots-clés : Blockchain, Consensus, Théorie des Jeux, Crypto-actifs List of Tables [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF], Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF], Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a side-chain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and a cross-chain swap protocol [5; 6] with respect to the number of rational deviating agents (k ) and the number of Byzantine deviating agents (t) where n is the total number of players in the game. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Immunity and resilience properties for Tendermint

Propriétés d'immunité et de résilience par rapport au nombre d'agents déviants rationnels (k )

et au nombre d'agents déviants byzantins (t) où n est le nombre total de joueurs dans le jeu. . 1.5 Phases of the digital signature protocol: (i) a public/private key pair is created -the public key can be recovered from the private one while the viceversa is not possible, (ii) data are signed -the signature is the result of encoding with the sender's private key the hashed data -and transferred. Once received (iii) the receiver decode data by the usage of the sender's public key and additionally verifies its authenticity. . . . . . . . .

List of Figures

Introduction

Looking back to the last half century of computer technologies, architectures and related design practices, we can observe a fluctuation trend between the centralization and subsequent decentralization of computing resources such as computing power, storage, infrastructure, protocols, and code.

Mainframe computers are largely centralized, housing most of computing resources. Today, computational capabilities are distributed on the clients, the clients facilities, and on distant servers. This approach gave rise to the 'client-server' architecture which supported the development of the Internet and relational database systems. Massive data sets, originally housed on mainframes, can move onto a distributed architecture, with data replicated from node to node, or server to server, and subsets of the data can be accessed and processed on clients, and then, synced back to one of the servers.

Over time, Internet and cloud computing architectures enabled global access from a variety of computing devices ; whereas mainframes were largely designed to address the needs of large corporations and governments. Even though such an Internet/Cloud architecture is decentralized in terms of hardware, it has given rise to application-level centralization. Currently, we are witnessing the transition from centralized computing, storage, and processing to decentralized architectures and systems. The DLT is the key innovation making this shift possible. Some distributed systems (e.g., permissionless blockchains) aim to give the control of digital assets to end users without the need for intermediate nodes. Others (e.g., permissioned blockchains), attempt at maintaining a logical centralization of some information while adopting a decentralized architecture. Not all DLTs make use of a block architecture and can therefore be defined as 'blockchains' (e.g., The Tangle and BigchainDB [9; 10]). Blockchain can hence be used in diverse sectors with several applications. Indeed, it is crucial for adopters to understand whether the technology fits the problems they are aiming to solve or not.

The disruptive technology born in 2008 with Bitcoin and known as blockchain represents a significant quality leap from the distributed database technology studied since June of 1970 (when the first INTRODUCTION paper on the subject [START_REF] Codd | A relational model of data for large shared data banks[END_REF] was published). Blockchain allows sharing a ledger of transactions that are read, validated and stored in a chain of blocks. Systems based on blockchain technology work in a distributed manner, involving multiple agents or participants that ought to be independent of each other, and which can use peer-to-peer communications (P2P) to structure themselves into a network collectivity (where nodes represent users connected via transactions). The adoption of P2P as communication paradigm adequately supports the goal that resources are shared and dispersed over a network which by construction forbids the existence of providers or servers centralizing tasks. The result is a decentralized ecosystem with no central authority.

In contrast to legacy client-server architectures [START_REF] Schollmeier | A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications[END_REF], P2P network nodes do not always a fixed hierarchy ; roles may not be predetermined, or may change over time depending on the actual operation behind a communication, i.e., a blockchain transaction.

Blockchain Transactions and Users' Roles

Whenever a user aims at interacting with another one in a blockchain network, one or multiple transactions are created, propagated, validated and confirmed by the network. This journey starts at the moment in which the transaction is created and ends when the transaction is recorded in the blockchain. Four crucial steps of the journey of a blockchain transaction can be identified :

-Creation : the sender of a transaction must define, according to the data model, the origin and the destination of "the object of the transfer" (i.e., the digital asset). Transactions must specify as well the conditions under which the transaction object can be redeemed (i.e., the conditions to update the system state). Depending on the model, redemption criteria can be simple scripts or more generally actual contracts (smart contracts).

-Propagation : the transaction (eventually in a block) is propagated to the validating peers. An efficient transaction broadcasting has an impact on the transactions processing speed.

-Validation : it is the most crucial step since it characterizes all the existing blockchain-based systems. At this step transactions, collected in blocks, must address the different stages of the consensus mechanism envisaged to be considered valid and therefore executable. Afterwards, the block of transactions can be attached to the blockchain, updating its state. The valid transactions block is propagated throughout the network in order to let all nodes to update their own replica.

INTRODUCTION

-Confirmation : blocks of transactions give rise to a real transfer of assets only if, once validated and eventually published on the blockchain, they are confirmed in the final version of the ledger from which they may no longer be discarded. To become part of it, the consensus procedure has to come to the end, i.e, nodes have to agree on a single chain of blocks.

Transitions from one step to another characterize the technology. Cryptography is involved with hashing and key-generation techniques. Verification checks and block formation may connect the two first steps or the central ones. These four steps mark a strong distinction between two levels of technology use : (i) using the technology to perform simple transactions to then propagate to the network (i.e., creation and propagation) and (ii) helping to maintain the system by participating in the validation and confirmation phase of the transactions (collected in blocks).

Validators are all the peers involved from the moment in which the transaction is included in a block (or its outputs are collected in a block) upon its publication on the ledger. Peers collecting transactions (or transactions outputs) in blocks may not enter the validation phase however, since for many blockchain systems transaction collection is a part of the validation process, this separation is not emphasized throughout the manuscript. Section 1.3.5 presents a more detailed division of the roles blockchain users assume, we highlight in the following the key ones.

-Transacting parties : a blockchain transaction involves two different types of actors related to single or multiple blockchain users : the data-sender and the data-receiver. Interactions take place at address level : the sending-address(es) and the receiving-address(es) digitally track the data-flow (i.e., the transfer of digital assets) between the parties.

-Validating nodes : validating actors run the consensus algorithm and are responsible for establishing the agreement on the proposals made by other validators or by leading nodes (see Section 1.3.5). The validation of a block represents the consensus among validating nodes on which block to publish and in which order.

Blockchain Users' Behaviors

As multi-agent systems, blockchain systems characterized by different layers and protocols, can be modeled as games to be solved using game theory. Agents characterizing blockchains are human being or systems with behaviors programmed by human being even if referred to as nodes, peers, agents or INTRODUCTION players. They are indeed agents who can be considered as rational. Being rational does not consist trivially in behaving in a selfish manner without considering the satisfaction of the others. On the other hand, rational agents aim to get the best for themselves and this can sometimes coincide with the best for the community. Rationality has two strong connotations, (i) it assumes agents are able to order outcomes according to some preferences and that (ii) they are able to analyze the problem they are dealing with and take the right decisions. These two strong assumptions are not always met by blockchain users, leading them to be classified as altruistic and Byzantine nodes according to [START_REF] Aiyer | Bar fault tolerance for cooperative services[END_REF].

Blockchain users play specific games depending on their specific roles within the blockchain system ; they may participate in the consensus phase, they may simply interact among each other via transactions or again they may be interested in attacking the system to damage it or with the mere intention of ending up with a gain. The behaviors they may have can be honest, dishonest or armful.

Analyzing all these different behaviors of blockchain users helps in building robust blockchain protocols characterizing robust blockchain systems. This manuscript analyzes the two main types of blockchain users (i.e., transacting parties and validating nodes) as well as different blockchains (i.e., permissionless and permissioned) with the scope of providing a general overview of the topic and formal results on blockchain users' behaviors ; users may indeed be honest vis-à-vis of other users or they may behave maliciously (as Byzantine nodes) attacking the blockchain system. Both blockchain users are at first modeled as rational agents. This game-theoretical modeling enables to capture several behaviors. To be more generic (i.e., including also irrational or unexpected malicious behaviors) blockchain users are modeled also as Byzantine agents ; this is to assess the robustness of general protocols deviations in the blockchain context. The manuscript is structured as follows :

• Chapter 1 presents a comprehensive overview of blockchain technology analyzing its key features as well as all the layers characterizing the blockchain architecture. It particularly focuses on the features that lead possible blockchain users' decision on (i) whether to adopt the technology or not and, (ii) which type of blockchain to choose. The content of the chapter originates from [START_REF] Belotti | A vademecum on blockchain technologies : When, which, and how[END_REF].

• Chapter 2 provides an introduction to Game Theory, focusing on the rationality of the players taking part in in a game. This enables to predict players' actions and thus the outcomes of the game that can be more or less stable (i.e., equilibria or solution in the core). Game participants may play as an individual or as a group leading to two different types of modeling.

INTRODUCTION

• Chapter 3 models and analyzes the behaviors of a particular type of validating nodes ; Bitcoin miners. Miners who operate validating tasks in the Bitcoin blockchain are modeled as rational agents who may or may not behave maliciously (i.e., perform an attack) in certain situations.

The situation we present in this chapter is the process of remunerating miners for their validating work. Two types of malicious behaviors are analyzed ; pool-hopping and block-withholding. The content of the chapter originates from [START_REF] Belotti | Bitcoin pool-hopping detection[END_REF] and [START_REF] Belotti | Rewarding miners : bankruptcy situations and pooling strategies[END_REF].

• Chapter 4 is devoted to the analysis of the behaviors of transacting parties aiming at exchanging assets through cross-chain swaps. Cross-chain swaps enable interactions between multiple blockchains i.e., blockchain interoperability. Game theory is used to model transacting parties (who swap crypto-assets) as rational agents and characterize the equilibria of existing cross-chain protocols. The content of the chapter originates from [START_REF] Belotti | Game theoretical analysis of atomic cross-chain swaps[END_REF].

• Chapter 5 brings together the two types of users that are analyzed in Section 5.3 (i.e., validating nodes for layer-1 blockchain protocols) and Section 5.4 (i.e., transacting parties for layer-2 blockchain protocols), respectively, in a more general way, going beyond the strong assumptions (and repetitive limitations) of the rationality of the agents present in the previous chapters. This chapter proposes a game theoretical framework that characterizes the robustness of general blockchains systems in terms of resilience to rational deviations and immunity to Byzantine behaviors. Rational blockchain users faced with a blockchain protocol to follow may act altruistically (following the protocol) or maliciously (deviating from the protocol) according to their personal utility. On the other hand, Byzantine users deviate from the protocol in any situation (even acting irrationally). We prove the practical interest of our formal framework by characterizing the robustness of two layer-1 blockchain protocols (i.e., Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF] and Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF]) and three layer-2 blockchain protocols (i.e., Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a side-chain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and a cross-chain swap protocol [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF])). The content of the chapter originates from [START_REF] Zappalà | Game theoretical framework for analyzing blockchains robustness[END_REF].

The following table represents the analysis structure of the manuscript for Chapters 3-5. The first two chapters introduce the topics of "Blockchain" and "Game Theory".

Chapter 1

State of the Art on Blockchain Technology and its Users This chapter provides a comprehensive overview of blockchain technology analyzing its key features as well as all the layers characterizing the blockchain architecture particularly focusing on those that help a potential blockchain users to decide (i) whether to adopt the technology or not and, (ii) which type of blockchain to choose. The content of the chapter originates from [START_REF] Belotti | A vademecum on blockchain technologies : When, which, and how[END_REF].

INTRODUCTION ON BLOCKCHAIN AND DLTS

Introduction on Blockchain and DLTs

Blockchain can be regarded as a quality leap from the distributed database technology [START_REF] Davenport | Distributed database technology-a survey[END_REF] studied since the seventies, which consists in a transaction database shared by different users. Generally, Distributed Ledger Technologies (DLTs) are designed to deal with database in the form of data shared in a distributed manner, and blockchain represents one possible DLT to do it (see Fig. 1.1).

Fundamental bricks in the design of a blockchain technology are as follows : (i) communications and transaction data storage are regulated by cryptographic security, network nodes have to agree on both the validity and the order in which transactions are listed in the blockchain and (ii) distributed consensus protocols solve these issues in a scenario where each node comes to vote.

The first example of such a blockchain is Bitcoin, proposed in 2008 by its anonymous identity [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF].

The Bitcoin behavior traces what can be defined as the 'classical' blockchain, consisting in a permissionless blockchain alternative enabling a digital, distributed and decentralized payment system.

The Bitcoin blockchain is structured in order to protect the ecosystem against attacks launched by malicious or simply rational nodes of the network. As attackers may exploit blockchain vulnerabilities in several ways to achieve a privileged position on the network, the Bitcoin blockchain was designed primarily for preventing the so called double spending and Sybil attacks, without addressing other important aspects [21; 22] such as :

(i) complete anonymity -Bitcoin provides its users with only pseudonymity ;

(ii) blocks have a limited size, limiting both the number of transactions that can be validated with one block and the number of validated transactions per second (tps) -Bitcoin has a 1 MB limit with a transaction rate ranging from 3.3 to 7, incomparable to current credit card systems managing tens of thousands tps [START_REF]Bitcoin-NG : A Scalable Blockchain Protocol[END_REF] ;

INTRODUCTION ON BLOCKCHAIN AND DLTS

(iii) eco-sustainability of the validation process -Bitcoin is designed to make it difficult to validate blocks with validating agents or miners required to solve computationally heavy crypto-puzzles, and therefore consuming energy.

As a consequence, even if Bitcoin remains the most successful cryptocurrency in circulation, a large number blockchain-based cryptocurrencies have been defined -as of [START_REF]What to Mine[END_REF], more than 50 alternative cryptocurrencies exist. Some of these 'Altcoins' [START_REF] Wisniewska | institute of Economic Research[END_REF] can guarantee anonymity, solve the energy consumption issue, reduce the price volatility (Stablecoins [START_REF] Chohan | Are stable coins stable ?[END_REF]) or rely on a permissioned blockchain -accessible only to authorized nodes, in order to offer a more scalable and fast system.

Going beyond the Bitcoin case, the general blockchain technology aims at assuring the third party benefits such as integrity, authenticity, security and non-repudiation in a distributed and decentralized environment. In addition to auditability and transparency, it offers immutability 1 . Besides being evident for currency systems, these features are useful for any transactional system that is to be used by multiple independent trustless parties.

With the introduction of permissioned blockchains, users may opt for its adoption by placing constraints and customizing the behavior of network nodes. While with classical blockchains it is possible to build a completely open and decentralized system, permissioned ones allow only a limited number of users to have the right of validating transactions. Validators constitute a set of nodes that can be publicly elected or selected by a central authority. Limiting the number of participants in the validation procedure can grant significant scalability improvements by using appropriate consensus mechanisms. Moreover, protocols changes (in both the blockchain data and consensus structure) made to support the execution of Turing-complete codes, facilitate the deployment of distributed applications ('dapps') based on smart contracts. However, since full-permissioned blockchains have many similarities with classic shared databases, there can be situations where such a complex architecture is not indispensable.

The literature published after 2014 widely covers blockchain technology in a comprehensive manner but the majority of the articles and surveys analyze it without dwelling on the permissionless part rather than on the permissioned one. Concerning DLT, a term coined in [START_REF] Walport | Distributed ledger technology : beyond blockchain[END_REF] in 2016, many works also

INTRODUCTION ON BLOCKCHAIN AND DLTS address the comparison between blockchain and previous technologies.

Most of the articles focus on cryptocurrency blockchain-based systems, with different focus on all their aspects. Tschorsch and Scheuermann [START_REF] Tschorsch | Bitcoin and Be-yond : A Technical Survey on Decentralized Digital Currencies[END_REF] present a complete work covering all aspects of the Bitcoin protocols, addressing security, network and privacy aspects. Conti et al. [START_REF] Conti | A Survey on Security and Privacy Issues of Bitcoin[END_REF] survey security and privacy issues of the Bitcoin blockchain, while Khalilov et al. [START_REF] Khalilov | A Survey on Anonymity and Privacy in Bitcoin-like Digital Cash Systems[END_REF] focus on surveying techniques enhancing anonymity and privacy in blockchains based on PoW consensus with an emphasize on Bitcoin. Network aspects and related attacks are surveyed by Neudecker and Hartenstein [START_REF] Neudecker | Network layer aspects of permissionless blockchains[END_REF]. Mining procedures for cryptocurrency are presented by Mukhopadhyay et al. [START_REF] Mukhopadhyay | A brief survey of Cryptocurrency systems[END_REF]. Consensus mechanisms constructed using the Bitcoin architecture are surveyed by Sankar et al. [START_REF] Sankar | Survey of consensus protocols on blockchain applications[END_REF] and Garay et al. [START_REF] Garay | The bitcoin backbone protocol : Analysis and applications[END_REF].

Besides crypotocurrency-oriented works, general technology aspects are also covered by other articles presenting differences among permissioned and permissionless blockchains. Zheng et al. [34; 35] presented a key features overview for blockchains, covering both public and private modes. Consensus protocols in blockchains are surveyed in [START_REF] Cachin | Blockchains Consensus Protocols in the Wild[END_REF] and [START_REF] Bano | Consensus in the Age of Blockchains[END_REF], the latter focusing on consensus evolution from the Bitcoin blockchains to the private ones. Wang et al. [START_REF] Wang | A survey on consensus mechanisms and mining management in blockchain networks[END_REF] presented the design methodologies for consensus incentive mechanisms in blockchain. Li et al. [START_REF] Li | A survey on the security of blockchain systems[END_REF] surveyed attacks against blockchain networks, while security issues and challenges are briefly presented in [START_REF] Lin | A Survey of Blockchain Security Issues and Challenges[END_REF].

Furthermore, a comprehensive overview of blockchain applications and use-cases is provided by [START_REF]Survey on Blockchain Technologies and Related Services[END_REF].

Generic IoT (Internet of Things) blockchain applications are presented by Ferrag in [START_REF] Ferrag | Blockchain Technologies for the Internet of Things : Research Issues and Challenges[END_REF]. Recently published, two tutorials [43; 44] present comparisons between permissionless and permissioned blockchains relating them to technology use-cases.

In this chapter, as in our article [START_REF] Belotti | A vademecum on blockchain technologies : When, which, and how[END_REF], we explore all the layers characterizing the blockchain architecture (i.e., network layer, data model layer, execution layer, consensus layer and, application layer), particularly focusing on those that are crucial for deciding (i) whether to adopt the technology or not and, (ii) which of the available blockchain solution come closest to a certain use-case. The chapter is organized as follows. Section 1.1 provides an overview of blockchain and Distributed Ledger Technology (DLT) while Section 1.2 presents the basic features of the technologies and its architecture. In Section 1.3 we present the journey of a generic blockchain transaction ; we go through creation, propagation and validation steps. Section 1.4 describes the agreement problem, its history in the blockchain context and presents the different types of algorithms adopted by existing DLTs. The decision steps leading a potential blockchain user to adopt the technology are presented in Section 1.5.

BLOCKCHAIN STRUCTURE AND FEATURES

Blockchain Structure and Features

A fundamental element beyond the innovation brought by blockchain to the DLT ecosystem is its intelligent mix of encryption techniques [START_REF] Antonopoulos | Mastering Bitcoin, unlocking digital cryptocurrencies[END_REF] in data storage -preserving block structure through timestamping [START_REF] Haber | How to time-stamp a digital document[END_REF] -and in transacting -authenticating transfers with digital signatures. A blockchain ledger consists of a history of validated digital transactions collected in blocks ; each block of transactions is linked to the immediately previous one (known as parent block ) through a hash value ; hence by traversing the transactions ledger one can trace back the genesis block, which has no parent block and contains the first processed transactions in the blockchain history. Cryptography characterizes the technology and attributes important properties to it. Let us start familiarizing the reader with the terminology and the different blockchain participation modes. Afterwards, we present the features of the technology and its architecture.

Terminology

-A distributed ledger is a type of digital data structure residing across multiple computer devices, generally at geographically distinguished locations [START_REF] Saur | Technology for secure partitioning and updating of a distributed digital ledger[END_REF].

-Distributed Ledger Technology (DLT) designs a type of technology enabling storing and updating a distributed ledger in a decentralized manner. As shown in Fig. 1.1, the blockchain and all its variations belong to the spectrum of DLTs. While distributed ledgers existed prior to Bitcoin, the Bitcoin blockchain was novel in that since marking the convergence of a set of existing technologies (including timestamping of transactions, P2P networks, cryptography, and shared computational power) and enabling data sharing and storage without entrusting any central party for the ledger maintenance. DLTs consist of three basic components :

1. a data model that captures the current ledger state ; 2. a communication language defined by transactions that change the ledger state ;

3. a protocol used to build consensus among participants around which transactions are accepted by the ledger and in which order.

-A blockchain is a P2P DLT structured as a chain of blocks, forged by consensus, which can be combined with a data model and a communication language enabling smart contracts and other assisting technologies. Cryptography lets blockchains overcome former DLTs by offering 1.2. BLOCKCHAIN STRUCTURE AND FEATURES secure data-transmission and by enabling records immutability, in a decentralized environment (see Section 1.2.5). Hence, a blockchain is an immutable read-only data structure, where new entries (blocks) get appended onto the end of the ledger by linkage with the previous block's 'hash' identifier.

The collection of these features can be used to build a new generation of transactional applications that establish trust, accountability, and transparency at their core, while streamlining business processes and legal constraints. In all DLTs, there is an initial record -in a blockchain it is called a genesis block. Each block includes one or more transactions. Connecting to a blockchain involves users connecting to this distributed ledger via, typically, an application. The blockchain ledger consists of digital transactions representing interactions between nodes of a P2P network.

-Transactions are individual and indivisible operations that involve exchange or transfer of digital assets. The latter can be information, goods, services, funds or set of rules which can trigger another transaction.

-Blockchain nodes are computing device connected to the blockchain that support the network by maintaining a copy of the ledger. Records replicas are stored by full nodes which verify blockchain data integrity. There can be nodes that, when connecting to the blockchain, do not download the whole ledger but just a subset of it ; these lightweight nodes -served by full nodes allowing them to transmit their transactions to the network -download the headers of all blocks on the blockchain in order to verify only if a transaction has been included in a block.

Whenever blockchain nodes exchange assets via transactions in the network they are considered as blockchain users. In order to transact with the network peers2 , they generate a cryptographic key-pair (see Section 1.2.4). If the private key is used to sign transactions, the public key is the one identifying the user(s) address storing exchangeable assets (e.g., addresses with tokens defined as accounts or wallets).

Blockchain transactions are grouped into blocks, and there can be any number of transactions per block while respecting a given block size limit. Nodes on a blockchain network group up these transactions and send them throughout the network. Eventually peers synchronize to an exact copy 1.2. BLOCKCHAIN STRUCTURE AND FEATURES of the blockchain throughout the network. The blockchain updating procedure needs an agreement, e.g., a consensus among the network peers.

-Consensus or more generally agreement in the network refers to the process of achieving agreement among the network participants as to the correct state of data on the system. It leads to all nodes sharing the exact same data. Therefore an agreement algorithm (i) ensures that the data on the ledger is the same for all network nodes, and (ii) prevents malicious actors from manipulating the data.

The agreement procedure varies with different blockchain implementations. While the Bitcoin blockchain uses a PoW -based consensus mechanism, other blockchains and distributed ledgers are deploying a variety of consensus algorithms belonging to two main classes : (i) Proof-of-X -based algorithms and (ii) Byzantine Fault Tolerant algorithms. We elaborate about agreement and consensus algorithms used in DLTs in Section 1.4.

Early blockchain-based systems were meant for managing digital currencies. However, a generic DLT can fit any digital asset exchange requirement. Contractual aspects of an exchange, involving nodes' rights and obligations, can be digitalized and controlled by proper digital (smart) contracts.

-A smart contract is a computer program that executes predefined actions when certain conditions within the system are met. Smart contracts provide the transactions language allowing the ledger state to be modified. They can facilitate the exchange and transfer of any asset (e.g. shares, currency, content, property). They reside into the blockchain structure and are triggered along with transactions. Smart contracts can be imagined as digital protocols used to facilitate and enforce the negotiation of a legal contract. Actions carried out by trusted third-parties during a trade are replaced by pieces of code.

Having acknowledged that blockchain ledgers fit within a wider spectrum of technologies, our contribution focuses on the analysis of blockchain systems characterized by a permissionless or permissioned participation mode.

Permissionless and Permissioned Participation Modes

In conventional central data storage systems, only a single entity, the owner or the administrator, keeps a copy of the database. Consequently, this entity controls what data is contributed and what other entities are permitted to contribute. With the advent of DLT this radically changes in favor 1.2. BLOCKCHAIN STRUCTURE AND FEATURES of distributed data storage where multiple entities hold a copy of the underlying database and are naturally permitted to contribute. Data is replicated for all entities participating in a distributed ledger in a network of so-called peers. Due to distributed data storage, the difficulty arises to ensure that all nodes agree upon a common truth, i.e., the correctness of a ledger, as changes made by one node have to be propagated to all other peer nodes in the network. The result of arriving at a common truth is referred to as consensus among nodes.

With respect to accessing the blockchain network, there are two main modes of operation : permissionless and permissioned -it is worth noting that in the literature, these are often referred to as public and private blockchains, respectively, but we use in this thesis a more precise taxonomy as explained hereafter. The same division is adopted regarding the participation to the ledger maintenance procedures, i.e., the possibility to modify (update) the network state. In the first mode, participation is public and open-access : anybody is allowed to participate in the network and in the consensus process [START_REF] Buterin | On public and private blockchains[END_REF] ; this mode is the one adopted by first generation blockchains (e.g., Bitcoin).

On the other hand, if participation is permissioned, participants have either restrictions on writing (validation) rights only, or on both reading (access) and writing rights. In the first case, permissions concern the participation to the phases of the transaction journey (see Section 1.3) amending the log ; any modification of the transaction ledger is entrusted to a selected set of nodes. Instead, the so-called full-permissioned blockchains select participants in advance and restrict any sort of activity in the network to these only.

The participation mode differentiates between decentralized blockchain-based ledgers and those that additionally offer disintermediation namely, that cut out any middleman (i.e., permissionless blockchains). It is worth stressing that in permissionless blockchains anyone with an Internet connection can join the network, as well as write and read transactions ; this is why permissionless, public and open-access are terms used interchangeably to refer to such technologies. Participants here are pseudonymous, which is not preventing malicious nodes to act within the network. Contrariwise, full-permissioned blockchains, reduces these security risks by whitelisting authorizations to join the network. In this way, rather than displaying the transactions record to the entire Internet community, transactions remain visible only to a private network of nodes.

The differentiating points in the previous two paragraphs allow us to support what authors in [START_REF] Wüst | Do you need a blockchain ?[END_REF] propose, i.e., differentiating full-permissioned blockchains from those allowing anyone to read the With respect to the nature of participants, permissioned blockchains can be further classified in private blockchains -where the participants are within the same organization -and consortium blockchains -where the permissioned blockchain is deployed among several organizations (consortium).

BLOCKCHAIN STRUCTURE AND FEATURES

A consortium blockchain represents a joint effort of several entities sharing a common goal or business need. Furthermore, 'private' and 'consortium' attributes can be linked to the blockchain governance system. There are some developed by a single enterprise, and others by a joint effort of several contributors (e.g., Corda and Hyperledger [50; 51]). The latter, for instance, is a cross-industry project led by the Linux Foundation to advance blockchain technology by coming up with common standards.

Data Structure

A block is the junction of (i) an outer header identifying the blockchain and specifying the size of the block, (ii) a block header -containing all the information on the block validation and on its parent block -and (iii) a block body -consisting in a list of transactions and a transaction counter. While the precise structure of a block varies from one blockchain to another, each blockchain is identified by the magic number3 which is included in any block of transactions at the beginning together with the blocksize field reporting the maximum number of bytes in a block. The block header should include for every blockchain system, as in Fig. 1.3, the following elements (whose order can vary from one

BLOCKCHAIN STRUCTURE AND FEATURES blockchain to another one) :

-Block version number : it refers to the blockchain protocol and hence the used consensus algorithm followed by the (majority of the) nodes at the moment of the block validations.

-Parent-block hash : it is the output of the hashing function with the previous block header as input.

-Nonce : it is a string of fixed length crucial in the validation process (Section 1.3.3).

-Timestamp : it indicates the time elapsed since a predefined instant.

-Merkle tree root : it is the hash value descending from a hash tree procedure (patented in 1989 [START_REF] Merkle | Digital signature system and method based on a conventional encryption function[END_REF]) applied to the transactions present in the block body ; transaction informations are iteratively hashed in pairs as showed in Fig. 1.4 (if the number of transactions is odd, the last transaction, hashed or not, in the list is duplicated). The hash of the block header serves as a link to future new blocks on top of it. The block body consists of all the transactions involved in the Merkle root calculation and of a transaction counter providing the total number of transactions contained in the block. Note that the block size limit has a direct effect on the number of transactions that can be included in the block body.

Cryptography

Cryptography allows sending data trough trustless channels in a secure and verifiable way. Data hashing consists in a basic cryptographic operation that not only compresses data in a fixed-length

BLOCKCHAIN STRUCTURE AND FEATURES

format, but it does so irreversibly, which is crucial for ensuring the integrity of digital assets when transferred in the network. Asymmetric cryptography authenticates the data source and ensures its reception by the desired user. Blockchain combines asymmetric cryptography with hashing and digital signature schemes in order to provide fundamental security guarantees presented later on.

More precisely, a digital signature scheme consists of three phases as depicted in Fig. 1.5 :

-Key-pair generation phase : each blockchain user generates a private key to sign a transaction with and a public key by which the receiver can verify the authenticity, integrity and provenance of the received data.

-Signing phase : the sender hashes the data and generates the digital signature with its private key ; next, the signed hash is sent together with the encoded original data to the receiver. Data hashing not only makes the signature scheme more streamlined and efficient (data are compressed and have the same format), it also ensures the integrity of the transferred data (transactions contents are protected against being modified).

-Verification phase : the signed data is decoded with the sender's public key and compared with the re-computed hash value of the unsigned and uncompressed data.

Note that, in both the signing and verification phases the hashing function used must be the same (e.g., SHA256 for Bitcoin blockchain). Blockchain requires asymmetric algorithms -generating both public and private key -that allow for fast verification (the time taken for signing shall be the same as for the last phase). Digital signature algorithms in blockchains widely use elliptic curves (ECDSA [53; 54]). Figure 1.5 -Phases of the digital signature protocol : (i) a public/private key pair is created -the public key can be recovered from the private one while the viceversa is not possible, (ii) data are signed -the signature is the result of encoding with the sender's private key the hashed data -and transferred. Once received (iii) the receiver decode data by the usage of the sender's public key and additionally verifies its authenticity.

Blockchain Features

Thanks to the explanations of the previous paragraphs, we can now highlight six fundamental blockchain features, which are obviously dependent upon each others :

-Decentralization : DLTs enables P2P data sharing and storage without entrusting the ledger maintenance to any central authority. It does not mean completely cutting out intermediaries that validate transactions (disintermediation) like permissionless blockchains do, but rather decentralizing them along with their roles.

-Immutability : while shared ledgers allow data manipulation by a central authority, distributed ledgers working with replicated information protect data from any sort of tampering and falsification ; except in situations where the majority of the network's efforts are devoted to change the registry [START_REF] Conte De Leon | Blockchain : properties and misconceptions[END_REF] (e.g, the Ethereum DAO fork [START_REF] Dupont | Experiments in algorithmic governance : A history and ethnography of "the dao", a failed decentralized autonomous organization[END_REF]) or where the adversary thresholds are exceeded (see Section 1.4.1.3). Data immutability makes data accessible and manageable by different entities that do not trust each other.

-Integrity, Authenticity and Non-Repudiation : the data hashing grants that data is not modified during its transmission (i.e., integrity). Moreover, the origin of a transaction can be ascertained by the senders' public key dissemination, while the evidence of the sending action is represented by the data signing procedure involving the private key (i.e., authenticity and non-repudiation).

BLOCKCHAIN STRUCTURE AND FEATURES

Blockchain signing scheme combining asymmetries cryptography and data hashing is presented in Section 1.2.4.

-Auditability : Transactions in blockchain systems must be validated and verified thus, each data transfer should be visible to all blockchains participants in its entirety. In this way, all blockchain operations are traceable via audits. Users accessing the first generation blockchains can see the data ledger in its entirety. Indeed, recent implementations enable multiple ledger to be isolated and maintained within the same blockchain system via private channels. Nevertheless, ledgers data is visible to all channel participants, thus the auditability is satisfied at channel level.

The mix of the above features qualifies the technology at a quite high level of dependability, differentiating it from the classic distributed database. Blockchain features result strictly correlated with the consensus mechanism in use.

JOURNEY OF A TRANSACTION

Journey of a Transaction

Generally, transactions in blockchains or DLTs are not strictly financial and do not just carry and store transaction data. Hence, the usage of blockchain transactions is not limited to the simple assets exchange, but it also covers the execution of computing instructions such as storing, querying and sharing. Every transaction, once validated, is placed in a new block which is added in the transaction ledger and linked to the previous one. This results in an update of the system state and of users' local copy of the blockchain. Whenever a user aims at interacting with another one in the network, one or multiple transactions are created, propagated, validated and confirmed by the network. Each blockchain-based system differs from the others by the way in which the steps of the 'transaction journey' are performed. This journey starts at the moment in which the transaction is created and ends when the transaction is recorded in the blockchain. Four crucial steps of the journey of a blockchain transaction can be identified :

-Creation : each blockchain adopts a predefined data-structure that determines certain benefits and drawbacks. Some data models are designed for specific blockchain applications, others are designed to be as flexible as possible. The sender of a transaction must define, according to the data model, the origin and the destination of "the object of the transfer" (i.e., the digital asset).

Transactions must specify as well the conditions under which the transaction object can be redeemed (i.e., the conditions to update the system state). Depending on the model, redemption criteria can be simple scripts or more generally actual contracts (smart contracts).

-Propagation : the transaction (eventually in a block) is propagated to the validating peers.

An efficient transaction broadcasting has an impact on the transactions processing speed. The communication protocols adopted by blockchains aim at optimizing the network performance while being resistant to manipulations and attacks.

-Validation : it is the most crucial step since it characterizes all the existing blockchain-based systems. At this step transactions, collected in blocks, must address the different stages of the agreement mechanism envisaged to be considered valid and therefore executable. Afterwards, the block of transactions can be attached to the blockchain, updating its state.

-Block Propagation : the valid transactions block is propagated throughout the network in order to let all nodes to update their own replica.

JOURNEY OF A TRANSACTION

-Confirmation : blocks of transactions give rise to a real transfer of assets only if, once validated and published on the blockchain, they are confirmed in the final version of the ledger from which they may no longer be discarded. To become part of it, the agreement procedure has to come to the end, i.e., nodes have to agree on a single chain of blocks. Once a block of transactions is confirmed, users can be sure or mostly sure (depending on the agreement mechanism of the blockchain) that the validated block cannot be changed or removed from the blockchain ledger.

Transaction Creation

Whenever a user aims at interacting with another one in the blockchain network, a transaction takes place. In general, a transaction indicates to the network that a user has authorized a data flow.

Hence, it has to be properly constructed for its purpose before its propagation.

Firstly, the sender user has to build a transaction proposal specifying all the criteria according to which the information can flow to the transaction receiver(s). All blockchain transactions must specify the destination of the operation, in most cases provided with a unique transaction identifier. Moreover, a transaction field reporting the entity of the transfer must exist ; i.e., in the case of cryptocurrencies a certain amount of tokens is specified in the amount field of the transaction. Blockchain technology supports the presence of both multiple origins and multiple destinations ; a transaction sender may have more receivers and vice-versa.

The transaction proposal must be signed by the sender(s) to prove the ownership of the address(es) instantiating the transaction. Blockchain-based systems use digital signatures as authentication methods (as presented in Section 1.2.4). Once signed, the transaction can move on to be propagated in the P2P network. Privacy-preserving blockchains -trying to hide the source, the destination and the entity of a transaction -can make use of temporary addresses and special cartographic tool to sign and encrypt transactions before the propagation [START_REF] Khalilov | A Survey on Anonymity and Privacy in Bitcoin-like Digital Cash Systems[END_REF].

The data model of a blockchain transaction differs depending on the system implementation and its business application. For instance, the Bitcoin protocol imposes the transfer of Unspent Transaction Outputs (UTXOs [START_REF]Bitcoin Wiki. Transaction[END_REF]), presented hereafter. Post-Bitcoin data models have evolved in two different ways. First, blockchains moved to the adoption of an account-based model, making use of a completely new transaction syntax (Turing complete) [START_REF] Buterin | Ethereum White-paper[END_REF] and resulting more 'smart contract friendly' ; Ethereum is one of the so-called 'second generation' cryptocurrencies [START_REF] Willet | The Second Bitcoin Whitepaper, V. 0.5[END_REF] adopting this record-keeping model.

JOURNEY OF A TRANSACTION

Subsequently, blockchains' intention was to maintain the original Bitcoin data-structure along with its improvement proposals [START_REF] Bonneau | Research perspectives on bitcoin and second-generation cryptocurrencies[END_REF] to which integrate the benefits of an account-based model. General blockchains, going beyond cryptocurrencies and digital assets, may adopt basic models supporting smart contract execution. Offering more and more general operations corresponds to a data model supporting more and more complex logic, hence overcoming both the account and the UTXO models.

Blockchain-based systems of this type adopt a key-value data model (also called table-data model) where the blockchain registers its state as data-tuples that can be updated. We present in the following these different models in more details ; benefits and drawbacks are summarized in Table 1.1.

UTXO Model.

This record-keeping model associates value to users' addresses as 'unspent' transaction outputs, i.e., cryptocurrency amounts that may be spent in the future through the construction of other transactions ; UTXOs become inputs of a 'spending transaction' transferring the value previously received to another blockchain user. Transactions outputs (TXOs) can only be spent (i.e., transferred) once.

Blockchain addresses keeps track of the received UTXOs ; their sum corresponds to the address balance.

A peculiarity of the UTXO model is that transactions inputs and outputs must match ; namely the entire value of the TXOs received in a prior transaction has to be transferred in order to be spent. More precisely, a user aiming at transferring data to another one does nothing more than 'endorsing' a previous received UTXO. Users unlock an output, appropriately transform it and generate a new one ; the procedure, resembling the "compare-and-swap" instruction in computer science, forces a synchronization in data accessing [START_REF] Macgregor | Method and apparatus for a compare and swap instruction[END_REF]. The problem arises whenever a user has no intention of spending the entire value of a TXO. The issue is solved with the proper use of multiple outputs ; the system creates a transaction with two different outputs : (i) one destined to the receiving user, transferring the aimed value (lower in relation to the TXO) and, (ii) one transferring the difference back to the sender in the form of a new UTXO. In this way, the inputs value corresponds to outputs value. The UTXO model is designed in such a way that each UTXO has to be transferred/spent in its entirety as input of another transaction. That is why operations on UTXO-based blockchains are so reminiscent of exchanging cash. has to be included as input of a second transaction. This implies high verification, duplication and transmission costs. Because of these drawbacks, UTXO model forces blockchains to limit the amount of operations impacting the system state.

Bitcoin adopts a transaction structure with three basic fields : (i) the value to be transferred, (ii) a short script specifying the conditions under which the value can be redeemed (i.e., the Locking Script or Redeem Script [START_REF] Atzei | SoK : unraveling Bitcoin smart con-tracts[END_REF]) and (iii) a witness field to unlock the previous transaction output. The script locks the transaction until spending conditions are met, i.e., when a witness is provided. The approach works for simple transactions ("Pay-to-PubKeyHash" [START_REF] Antonopoulos | Mastering Bitcoin, unlocking digital cryptocurrencies[END_REF]) or simple contracts involving a small number of transactions locked with proper locking scripts ("Pay-to-ScriptHash" [START_REF] Andresen | BIP 16 : Pay to script hash[END_REF]), however it results not suitable for slightly more complex operations contemplated with smart contracts. UTXO-based applications in Bitcoin should limit the number of transactions involved, because of both the cost in terms of computations required to find a PoW (a golden nonce [START_REF]Bitcoin Wiki. Nonce[END_REF]) validating a transaction, and the scripting language supported by the model which is Turing incomplete [START_REF]Bitcoin Wiki. Script[END_REF].

Account-Balance Model.

This model results more intuitive in keeping track of the balance of each account as a global state of the blockchain. State replication completely overcomes the concept of transaction input and output ; more precisely, the blockchain state is an outcome of a transaction. Once a transaction is executed the states of the accounts involved in the transferring are updated.

There are different options for creating a transaction depending on the output and the finality ; regular transactions between users have to simply specify the receiving account(s) and the entity of the transfer, while transactions dealing with contracts present rather complex structures.

JOURNEY OF A TRANSACTION

-Smart contracts. The smart contracts idea of Nick Szabo [START_REF] Szabo | The Idea of Smart Contracts[END_REF], was a key driver in the blockchain evolution since its conception. At the time, he used an analogy with vending machines, that in hardware implements predefined set of rules, an agreement between a machine and a user. Thus, smart contracts are computer codes which digitally represent contracts on a DLT and enable its automatic execution. Smart contracts are distributed to the network of peers characterizing the blockchain and are executed on the blockchain i.e., the outcomes (e.g., exchange of assets, access to property, certification of documents, etc...) are recorded on the ledger. The power of smart contracts is that they remove the counter-party risk making third party services redundant.

Let see it with an example : Alice enters at time T 0 into a contract to buy a land from Bob by providing a deposit upfront and committing to pay the full amount by the time T : T > T 0 . A smart contract can verify whether the payment took place on time and in that case (i.e., under that condition) it can release the funds and change the title on the property. On the other hand, the smart contract can cancel the contract and liquidate the deposit if Alice did not pay on time.

We can see that the code characterizing a smart contract can replace the third party services provided by an escrow service (that keep the deposit), a title company (that verify payments) and a titling (that update the records).

In terms of data model, a smart contract consists of a collection of standard transactions presenting locking conditions : contracts on the blockchain are created as transactions between addresses and they can be executed thanks to triggering transactions. For instance, Ethereum works with different types of accounts : Externally Owned Accounts (EOAs) holding only its balance, and Contract Accounts (CAs) holding the code of a smart contract and keeping an internal state. Once a transaction in a contract or a regular one is executed, the ledger is updated together with its state.

Smart contracts play an important role in this thesis contributions as they enable settlement operation between different blockchains (see Chapter 5).

Contrary to UTXO-based blockchain, account-based systems have to deal with several security issues.

First of all, the account model is not not immune to double-spending practice. Hence, it is necessary to secure the blockchain adopting this record-keeping model, preventing the same transaction being submitted more than once. Moreover, an anonymity issue arises when accounts are reused ; the account model gives preference to balance updates rather than new account creation.

JOURNEY OF A TRANSACTION

UTXO + .
The idea beyond the UTXO + model is to maintain the UTXO structure, to which appropriate changes are made in order to obtain the same benefits granted by the account-based models. There is no notion of 'account' and state is forced to be included in the transactions outputs. Such operations still result quite unnatural and require a deep-level of abstraction together with serious complexities. Corda, Chain Core and Qtum [50; 67; 68] appropriately mix the Bitcoin and the Ethereum data-structures in order to have an UTXO-based model supporting complex contract operations ; both systems adopt powerful virtual machines supporting operations written in Turing-complete code but differently to Ethereum the EVM are stateless.

Key-Value Model.

An evolution of the previous data models consists in including in the state of a blockchain more variables, presenting them as tuples or tables. Such a general approach allows to adopt an UTXO-like or an account-like structure depending on the business constructed on top of the blockchain.

For instance, Hyperledger Fabric offers the possibility to deploy Bitcoin-like currency systems (Fabric-Coin [START_REF] Androulaki | Hyperledger fabric : A distributed operating system for permissioned blockchains[END_REF]), digital assets exchange (i.e., a contract, liabilities, properties) and tangible assets exchange (i.e., real estate and hardware). Fabric represents general assets as collections of key-value pairs (KVP) and it records state changes as transactions outcomes [START_REF]Hyperledger Architecture Vol.1, Introduction to Hyp-erledger Business Blockchain Design Philosophy and Consensus[END_REF]. Kadena [START_REF] Popejoy | The Pact Smart-Contract Language[END_REF] adopts a tablebased data model operating modification at a per-row level. That is, the blockchain registers a columnar history and transactions, both regular and smart contract ones, can update multiple column values at once thanks to a proper object syntax.

Model Comparison.

Major differences between the four models are summarized in Table 1.1. The table reports benefits and drawbacks of the data models and cite some blockchain frameworks adopting them 4 . Transacting using a UTXO model is conceptually equivalent to banknotes exchanging ; the amount of paper bills (UTXOs) in the purse is the balance of our wallet and, whenever users spend money, they pay with a bill covering the cost (existing UTXOs) and they receive a change back consisting in other bills (new UTXOs). Thanks to the analogy, it is easy to note that this record-keeping model provides higher 4. The DLT platforms we refer to were the mainly adopted ones during the time period of the thesis i.e., 2017-2020 1.3. JOURNEY OF A TRANSACTION levels of scalability and anonymity ; multiple UTXOs can be processed in parallel and whenever a new address is receiving new UTXOs the identity of the user owning the address is hidden. The account data model is constructed to record each account's balance so as to allow the issue of valid transactions. With accounts resembling traditional banks' debit cards, the blockchain structure results more intuitive and efficient. Adopting a stateful approach, the balance of each debit card is registered in the system and it is not included in the transactions data as for the Bitcoin stateless model. Ethereum, Tezos [START_REF] Goodman | Tezos -A self-amending crypto-ledger[END_REF], IOTA [START_REF] Popov | The Tangle," iOTA White paper[END_REF], Ripple [START_REF] Schwartz | The Ripple protocol consensus algorithm -White Paper[END_REF],

Stellar [START_REF] Mazieres | The stellar consensus protocol : A fede-rated model for internet-level consensus -White paper[END_REF].

UTXO + scalability, efficiency , security, anonymity.
applicability, intuitiveness, model complexity.

Corda [50],

Chain Core [START_REF]Chain Protocol -White Paper[END_REF],

Qtum [START_REF] Dai | Smart-Contract Value-Transfer Protocols on a Distributed Mobile Application Platform -White paper[END_REF].

Key-value

as UTXO and Account. model complexity.

Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF], Hyperledger Fabric [START_REF]Hyperledger Architecture Vol.1, Introduction to Hyp-erledger Business Blockchain Design Philosophy and Consensus[END_REF], Kadena [START_REF] Popejoy | The Pact Smart-Contract Language[END_REF], SawtoothLake [START_REF] Olson | Sawtooth : An Introduction -White paper[END_REF].

Transaction Propagation

This step results crucial for the correct functioning of the consensus mechanism in the network.

In order to establish which transactions are valid or not, all the validating peers must have complete knowledge of the information to be agreed upon. Therefore, transactions must be propagated to validators as fast as possible.

In order to optimize blockchain network performance and scalability, flooding or gossip protocols [START_REF] Demers | Epidemic algorithms for replicated database maintenance[END_REF] are used for the propagation. Transaction propagation is carried out by means of a message exchange amongst peers. Blockchains clients connect only to a limited number of peers (neighbors) ;

the message is first propagated to the connecting peers that then propagate it to their neighbors, and so on until it reaches all network nodes. Data present in the messages can be encrypted or not.

Blockchain-based systems can require sending peers' authentication via exchange of a public key that can be included in the message or communicated out of band. Hence, receiving peers' can verify the data integrity. 50

JOURNEY OF A TRANSACTION

From a networking performance perspective, it is important to establish to which of its neighbors peers have to relay a message. Flooding protocols include message transmission to all neighbors, while according to gossip protocols messages are relayed to a subset of randomly selected neighbor nodes.

Both approaches assure a fast information dissemination but they differ in term of bandwidth and delay performance. The design of the transmitted message can impact the transmission delay. Delay-aware or bandwidth-aware neighbor selection can obviously lead to clear forwarding delay and bandwidth gains. A Bitcoin-like announce-and-request signaling, adding two more steps in peers communications (i.e., two more round-trip time, RTT, latencies), can consume less network bandwidth at the expense of delayed transmission. Such signaling can also imply a more complex data model : the protocol has to rule peers' request mechanism, peers' access to the data-ledger and peers' verification of the message originality (i.e., whether the information is new or not).

Apart from bandwidth and delay aspects, message propagation has to deal with network privacy and security aspects : multiple connections per node implies a large attack surface, while a limited number of communications facilitates interrupting and avoiding attacks (i.e., eclipse and DoS attacks [80; 81]). Regarding the identity-privacy aspects in permissionless blockchains, P2P protocols can reveal information on nodes identity. Deanonymization practices are related to the blockchain network topology built on top of the P2P overlay network, which can be generally disclosed if global-view P2P network traces are available or can be collected from different peers.

Bitcoin and the first generation of Altcoins work with flooding protocols using an announceand-request signaling, where information is first announced to the neighbors to be sent afterwards, if not already possessed. Even if propagation costs with flooding do increase sub-linearly with the number of neighbors, the dissemination protocol is prone to deanonimization attempts [START_REF] Fanti | Deanonymization in the Bitcoin P2P Network[END_REF] along with destabilizing communication strategies [START_REF] Babaioff | On bitcoin and red balloons[END_REF] ; starting from withholding (relay-delay [START_REF] Göbel | Bitcoin blockchain dynamics : The selfish-mine strategy in the presence of propagation delay[END_REF]), ending with net-split and gold-finger attacks [START_REF] Conti | A Survey on Security and Privacy Issues of Bitcoin[END_REF]. Moreover, even if the announce-and-request signaling can be improved (e.g., compressing information by announcing headers only) or appropriately mixed with the classical push (e.g., Ethereum), the added latencies elapse can be more or less significant.

Permissioned blockchains are superior to permissionless ones also in the communication performance. In permissioned environments where anonymity, message encryption, Sybil attacks do not represent a major issue, the communication security is concentrated on the faulty nodes management, to which gossip dissemination is more resistant with respect to flooding. The dissemination protocol 51

JOURNEY OF A TRANSACTION

does not require fixed connectivity to work since it operates with an unsolicited push propagation [START_REF] Gervais | On the security and performance of proof of work blockchains[END_REF] mechanism, providing a consistent data synchronization tolerant to node crashes. Permissioned blockchains can count on a fast propagation with low latency (due to the direct push) and low bandwidth costs. In order to further speed up the propagation, the push mechanism can be improved reducing the size of the broadcasted messages by disseminating the transactions ID instead of the whole transactions.

Model Comparison.

Table 1.2 summarizes the differences. First generation cryptocurrencies opt for flooding protocols using announce-and-request signaling, leading to higher bandwidth consumption and lower delay performance. Concerning security, the level of attack resistance depends on other factors (e.g., relay-delay).

In this respect, Ethereum represents a transition from flooding to gossip adopting a "hybrid" design where some information is pushed and the rest is sent selectively. The gossip protocol promises good performances pushing messages ; however, it results more sensible to net-split attacks due to the fewer connections involved in the propagation. , Medium : , Low : .

Transaction (Block) Validation

Before being collected in blocks, transactions must pass the verification checks, i.e., they must have been created in accordance with the network rules. Once verified and inserted in the blocks, validators check whether the blocks meet all the protocol requirements necessary to assign the 'valid' entry and to proceed with the publication. These validation criteria must be deterministic and uniform across the network. While the transactions verification consists in a trivial cryptographic check, the 1.3. JOURNEY OF A TRANSACTION block-validation phase is considered a key passage since it attributes to every blockchain-based system a distinctive character. After verifying that the block proposal has been correctly carried out, nodes have to find an agreement on the validity of the block. More precisely, nodes in the network must agree on a unique record of transactions following a collaborative consensus protocol.

Transactions-ordering and consensus establishment can be considered as separated phases, or can be combined as in most of the existing consensus protocols. Bitcoin combined the two processes in the consensus procedure proposed in [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF]. Validators in the Bitcoin network, known as miners, have to agree on both the order and the validity of the blocks. Some permissioned blockchains separate these steps (e.g., Hyperledger [START_REF]Hyperledger Architecture Vol.1, Introduction to Hyp-erledger Business Blockchain Design Philosophy and Consensus[END_REF]) : peers can agree on the ordering of the transactions that are validated in a second moment, right before their publication.

The agreement -on both publication and ordering of the transactions in the ledger -is reached through a distributed protocol executed by the nodes involved in the validation procedure. The consensus protocol must solve the Byzantine Generals (BG) problem [START_REF] Lamport | The byzantine generals problem[END_REF], which consists in reaching consensus among trustless nodes (i.e., generals can be traitors). Since systems must accomplish this agreement state in a distributed manner, protocols should provide a consistent (or at least eventually consistent) view of the blockchain in the whole network. Thus, protocols adopt data replication, meaning that nodes hold replicas of the transaction ledger. Replicating data over nodes in the network makes blockchains resilient.

Building a proper consensus protocol is a challenge, as we develop in detail in Section 1.4. Since blockchain technology has many different use-cases, consensus protocols have been designed to meet specific system requirements. In permissionless blockchain applications, everyone is allowed to participate in the network, executing the consensus protocol and maintaining the shared ledger. The availability of these systems results in a substantial amount of computational power (hence energy)

for maintaining a distributed ledger at a large scale (e.g., as in Bitcoin). Permissioned blockchains, with the presence of restrictions on who is allowed to participate in the network, adopt differently designed agreement procedures. More specifically, since the participants using blockchain are whitelisted, consensus protocols in permissioned blockchains guarantee higher performances.

JOURNEY OF A TRANSACTION

Transaction (Block) Confirmation

Block confirmation coincides with its inclusion in the valid transactions history. Confirmation is the direct consequence of consensus finality (i.e., an agreed transactions never change or disappear) characterizing the so-called "consensus-based" blockchains. In this case, confirmation consists of a transaction predicate obtained when the majority of nodes get to decide to validate, and then publish the block containing the given transaction. However, in general, decentralized distributed ledgers may ensure a probabilistic and economic consensus finality -since they rely on eventually consistent consensus algorithms [START_REF] Swanson | Consensus-as-a-service : a brief report on the emergence of permissioned, distributed ledger systems[END_REF] -referring to cases in which the block-confirmation probability/cost (depending on the type of consensus) is increasing with the number of validated children blocks . In fact, despite the robustness of permissionless blockchains against double spending attempts (they need the involvement of the majority of the network to be successful), reversals are very common by means of forking attitudes that do not correspond necessarily to malicious intents. Confirmed blocks that cannot be discarded give way to the proposed exchange in the collected transactions. Therefore, in this case block confirmation is not a formal step explicitly notified to blockchain nodes, but it is implicitly inferred by the actual presence of the validated block in the blockchain branch where the majority of nodes concentrate their efforts.

Transitions from one step to another characterize the technology. Cryptography is involved with hashing and key-generation techniques. Verification checks and block formation may connect the two first steps or the central ones. More precisely, (i) transactions are signed once created (i.e., the signing phase in Section 1.2) and (ii) their signature authenticity is checked (i.e., the verification phase in Section 1.2) when collected in blocks ; this can be done before or after the propagation to the validating nodes. Signing and verification grant to blockchain the fundamental features of integrity, authenticity and non-repudiation mentioned in Section 1.2.5.

The block formation procedure can be an integral part of the validation step or a separate one depending on the blockchain nature. The validation process in blockchains is the expression of the distributed consensus on the transactions to be executed, and on their ordering. Hence, validators are all the peers involved from the moment in which the transaction is included in a block (or its outputs are collected in a block) upon its publication on the ledger. Peers collecting transactions (or transactions outputs) in blocks may not enter the validation phase. Any node of the network can build blocks to its liking. The possibility of subjecting the built blocks to the validation process (i.e., provide 54 1.3. JOURNEY OF A TRANSACTION a block-proposal ) can be entrusted to a restricted circle of peers (or even to a single one) denoted as leading node(s). Leading nodes election procedure can be interwoven with the validation procedure or it can be completely separated. Permissioned blockchains adopt direct voting-based consensus protocols enabling a drastic separation between the leader election and the validation phase. Incentive-based consensus mechanisms admit the degeneration of the leaders' role into the validators' one -in order to be elected as leaders peers have to do the effort to validate the block they have constructed.

Due to the decentralized nature of blockchain technology, leading nodes, as validating ones, are likely changed once the proposed block of transactions is validated (as in the Bitcoin blockchain where leaders and validators are elected in a random fashion).

Comparisons of blockchains data-models can be found in [88; 89]. Authors survey in [START_REF] Seijas | Scripting smart contracts for distributed ledger technology[END_REF] the scripting language in both the UTXO and the account model (for Bitcoin and Ethereum). Regarding the transactions propagation, authors present in [91; 82] weaknesses of the propagation model adopted in Bitcoin-like networks and countermeasures to adopt for preventing any type of attack. In [START_REF] Neudecker | Network layer aspects of permissionless blockchains[END_REF] authors present how the propagation model can be appropriately modified on the basis of specific strategic decisions. A list of the different block propagation mechanisms used in existing blockchains can be found in [START_REF] Li | A survey on the security of blockchain systems[END_REF]. Concerning the different validation and consensus procedures adopted in blockchains few comprehensive works exists [37; 92; 93] ; one may find much more literature focusing respectively on permissionless [START_REF] Tschorsch | Bitcoin and Be-yond : A Technical Survey on Decentralized Digital Currencies[END_REF] and permissioned [87; 36] environments. The following section presents the blockchain actors encountered by every blockchain transaction along the journey. Fig. 1.7 illustrates the transaction journey in its entirety : the four crucial steps, the intermediate steps and the key actors in the path. The proposed classification of the blockchain roles nodes can assume follows the logic proposed in [START_REF] Ellervee | A Comprehensive Reference Model for Blockchainbased Distributed Ledger Technology[END_REF] and surveys the different classifications presented in the white-papers of the major platforms (see Table 1.3).

Blockchain Actors and Corresponding Roles

We highlight in the following the key roles that blockchain nodes (with at least reading permissions) can assume.

Transacting parties : A blockchain transaction involves two different types of actors related to single or multiple blockchain users : the data-sender and the data-receiver. Interactions take place at address level : the sending-address(es) and the receiving-address(es) digitally track the data-flow (i.e.,

JOURNEY OF A TRANSACTION

the transfer of digital assets) between the parties.

-Data-Sender : The data-sender is the node transferring data through an atomic operation (i.e, transaction) to a receiving node. The data-sender is not necessarily coinciding with (i) the transaction creator, (ii) the node with the right of initiating a data-transfer or, (iii) the dataholder [START_REF] Kiyomoto | On blockchain-based anonymized dataset distribution platform[END_REF]. Smart contracts involve the creation of a 'locked' transactions sequence that can be triggered by an authorized node (or even by a node outside the network) that may not be the owner of the transferred data. However, the data-sender is the one responsible for signing transactions (with its private key) in order to authenticate the origin of the object of the transfer (i.e., digital asset).

-Data-Receiver : Any user receiving a signed transaction that can : (i) recover the sender's publickey from the message and (ii) verify the transaction authenticity (i.e., transaction author and signature correspondence), is a data-receiver. Any blockchain node (user or contract account) can recover and verify the signature allowing tamper-proof transfers in the network.

Leading nodes : Agreement can be established by the election of a temporary leader node acting as a 'dictator'. The leader is responsible for both deciding which block to propose as a candidate to be included in the blockchain ledger and verifying the block proposal correctness. The leader goes out of power immediately after the validation of its block proposal. During its round (i.e., time interval

where the leader has decisional power), the peer has no certainty that its block will be confirmed.

Whenever a round expires, a new leader election starts.

The leaders election procedure is inherent in the agreement mechanism adopted by blockchain systems. Permissioned and permissionless blockchains adopt different methods to establish the peer in charge of proposing blocks to validators. Based on the journey of the transaction presented so far, it can be seen that it is nothing but the actors assuming the roles just described to characterize it. At the first stage the transaction meets (i)

the transacting parties, namely data-sender and data-receiver ; the transaction is then transmitted to the (ii) leading peers responsible for verifying the correctness of the transactions, collecting them in blocks and proposing the block as a good candidate for the validation ; at the final stage, (iii) validating peers proceed with the validity attribution.

In permissioned environments, each actor has a different role with no overlap in the procedures of block proposal and validation. This is due to the scalable voting-based agreement procedure adopted in permissioned blockchains (see Section 1.4). Instead, open-access blockchains foresee overlapping roles for the mining nodes. Indeed, mining can be interpreted as a simulation of the leader election in traditional consensus protocols. Table 1.3 shows the different actors of widely adopted blockchain platforms 5 assuming the relevant roles previously presented.

A blockchain transaction is intended to meet these three main actors, but not only them. Some permissioned blockchains improve their scalability by designating to other peers different tasks such as execution-verification checks, leader election and ordering (e.g. Hyperledger endorsers and ordering service nodes [START_REF] Androulaki | Hyperledger fabric : A distributed operating system for permissioned blockchains[END_REF]). The words "agreement" and "consensus" refer to the convergence to a common interest. Consensus is the task of getting multi-agent systems with interacting agents to achieve a common goal. Agents must reach an agreement regarding a certain interest (a value or an action, etc.) depending on their state.

Consensus ensures agents' agreement on a single request, or a sequence of requests also referred to as atomic broadcast [START_REF] Luan | A fault-tolerant protocol for atomic broadcast[END_REF]. Evidently, in any consensus protocol there are two events : the proposal and the decision. What nodes propose and decide is the interest they aim to agree upon, that in applications is most of the time a numerical value.

Fault-tolerant protocols are designed to deal with a limited number of faulty agents. According to [100; 101; 102], consensus reliability to halting failures is ensured by the following properties :

-Agreement : every correct/honest node must agree on the same proposed value V.

-Validity : if all nodes propose the same value V, then all correct nodes decide V.

-Termination : every correct node has to take a decision on a value V.

Moreover, atomic broadcasts are reliable broadcasts satisfying the following property :

-Total order : if any correct node decides that value V 1 comes before value V 2 , then every other correct node must order V 1 and V 2 at the same way.

Therefore atomic broadcasts are also known as total order broadcasts [START_REF] Défago | Total Order Broadcast and Multicast Algorithms : Taxonomy and Survey[END_REF].

In [104; 36] authors grouped these properties in two classes : liveness, grouping validity and termination, and safety that incorporates the remaining properties. These properties are analyzed in [START_REF] Cachin | Blockchains Consensus Protocols in the Wild[END_REF] for atomic broadcasts characterized by a broadcast and a deliver event.

It is worth noticing that blockchain applications may rise additional properties that can appear more important than those above to the designer. For instance, authors in [START_REF] Vukolić | The quest for scalable blockchain fabric : Proof-of-work vs. bft replication[END_REF] compare protocols in terms of network identity management, energy consumption and adversary tolerated power. Authors in [START_REF] Bano | Consensus in the Age of Blockchains[END_REF] make comparisons in terms of security and performance ; in particular, security is qualified in terms of agreement (i.e., the achievement of a consensus state) and the resistance to transaction censorship (i.e., the malicious behavior of suppressing transaction) and Denial of Service attacks [START_REF] Wiki | Weaknesses-Denial of Service (DoS)[END_REF] ; and

AGREEMENT IN BLOCKCHAINS

performance is qualified in terms of throughput (i.e., the transaction agreement rate), scalability (i.e., the system capability to respond adequately to a growth in the number of nodes) and latency (i.e., the time elapsing between proposal and decision phases during the agreement process). In [START_REF] Cachin | Blockchains Consensus Protocols in the Wild[END_REF] we find a comparison based on liveness and safety, while in [START_REF] Vukolić | Rethinking Permissioned Blockchains[END_REF] the comparison is limited to permissioned blockchains. A complete contribution on BFT protocols for replicated systems is provided in [START_REF] Singh | BFT Protocols Under Fire[END_REF] where algorithm performances are evaluated in terms of cryptography costs, workloads, network conditions and faults.

Eventually, in order to satisfy the desirable set of properties, an agreement or consensus protocol consists in a set of rules that each database transaction must respect. These rules, embedded in each blockchain node behavior implementation, are therefore application-dependent rules that can vary from system to system [START_REF] Christidis | Blockchains and Smart Contracts for the Internet of Things[END_REF]. Therefore, agreement in blockchains is crucial since it characterizes the systems ensuring properties such as resilience and security that can be summarized by a desirable level of dependability [108; 109].

Dealing with Asynchronous Communications

Networks can be synchronous, asynchronous or partially synchronous [110; 111]. Dealing with synchronous network does not mean dealing with networks where nodes' communications are not delayed in time ; instead, it means considering message delays bounded by some value. In asynchronous networks, this upper bound does not exist or is flexible, as messages are supposed to be delayed arbitrarily. In partially synchronous networks, or eventually synchronous networks, asynchronous nodes present time windows where they behave synchronously. Partial synchrony offers a good adaptability to the real network behavior and, at the same time, simplifies network modeling. Both liveness and safety properties are guaranteed during synchronous periods. On the other hand, during periods of asynchrony liveness cannot be ensured as proven by the "impossibility theorem" [START_REF] Fischer | Impossibility of Distributed Consensus with One Faulty Process[END_REF] stating that deterministic protocols do not reach agreement in a fully asynchronous environment.

In order to overcome this limitation, fully synchronous networks opt for relaxing the deterministic constraint ; they introduce randomness by requiring probabilistic termination (i.e., it is improbable for non-terminating executions to collectively occur) [START_REF] Aspnes | Randomized protocols for asynchronous consensus[END_REF]. Authors in [START_REF] Cachin | Random Oracles in Constantipole : Practical Asynchronous Byzantine Agreement Using Cryptography[END_REF] Liveness and safety in synchronous or partially synchronous environments are guaranteed for those protocols working with n ≥ 3f + 1 replicas, where f denotes the number of faulty nodes in general.

AGREEMENT IN BLOCKCHAINS

In blockchains, properties and features result from a clever choice and implementation of a consensus protocol.

Consensus protocols, aiming at reaching an agreement state in the networks, satisfy their desired features and properties (such as liveness and safety) under some conditions. These are the so called trust assumptions characterizing the failure model of a protocol. These models are typically presenting bounds/threshold on the gap between two parameters referring to honest and malicious nodes respectively. Therefore, they are known in literature as "threshold adversary models" [104; 120]. The typical failure model foresees a threshold on the total number of nodes an adversary can control (f ) with respect to the total number of nodes in the network (n). The threshold choice depends on the failure type and is between the half and a third (as previously met). However, this failure model presupposes knowledge of the number of parties involved in the network. Therefore, this classical adversary model works for permissioned networks where parties joining the system follows a specific membership protocol.

Bitcoin and other PoW-based cryptocurrencies consider an alternative failure model bounding no more the number of nodes but the work they may do. More precisely, the computational threshold adversary model limits the total amount of computational power that the adversary control (f c ) with respect to the total computational power (n c ). In order to guarantee double-spending resilience Bitcoin selects a threshold of a minority n c > 2f c , namely the adversary can control a minority of computational power. Bounding computational power does not require knowledge on participating parties, therefore the model well adapts to PoW-based permissionless networks, where anyone can join the system.

Further adversary models can be found in literature ; a new approach is the one of bounding the adversary stake (i.e., participation in a finite limited resource) [START_REF] Buterin | Ethereum News : On Stake[END_REF], another option may be to adopt a game theoretical approach and therefore bounding adversary utility [122; 123].

Consensus in Distributed Systems and Blockchains

Agreement problems see abundant applications in complex systems dynamics [START_REF] Ren | A survey of consensus problems in multi-agent coordination[END_REF] as well as in computer science and communications [START_REF] Lynch | Distributed Algorithms[END_REF]. In such systems, consensus protocols must deal with dynamic agents that may fail during the agreement process.

AGREEMENT IN BLOCKCHAINS

The two phase commit (2PC) protocol [START_REF] Gray | Notes on data base operating systems[END_REF], proposed in 1978, enables transaction processing in a distributed environment where nodes can atomically commit transactions trough pre-commit and validation phases. However, with 2PC any node failure compromises the consensus procedure. In this context, fault-tolerance (see Section 1.4.1.3) is defined as a property such that the system continues operating properly in the event of both process and communication failures caused by both honest nodes (i.e, crash failures) and nodes that act maliciously (i.e, Byzantine failures).

The state machine replication (SMR) technique [START_REF] Schneider | Implementing Fault-tolerant Services Using the State Machine Approach : A Tutorial[END_REF] enables the construction of fault-resilient consensus protocols ; robust against crash failures in trusted environments (e.g., Paxos and RAFT [128; 129]) and additionally capable of tolerating Byzantine failures in networks of untrusted parties (e.g., BFT). Any computation is considered as a state machine mutating its state through request receiving. In a distributed environment, state machines are replicated and executed across multiple nodes.

Though they do not evolve simultaneously, they have to agree on a common sequence of requests (state transformations) they are going to accept in order to have consistent replicas. A popular class of state-machine replication protocol is the one of Byzantine Fault Tolerant (BFT) protocols [86; 130].

We developed in Section 1.4.1.1 desirable behaviors with respect to asynchronous communications and data consistency guarantees, while recalling the strong relationship of these aspects with fault tolerance and the fact that in blockchain the consensus needed is about both on the elements of the ledger and their order.

The first approaches to consensus in distributed databases (2PC, atomic broadcast, SMR, BFT) can be considered as the predecessors of consensus solutions for DLTs. First generation blockchains (e.g., Bitcoin, Litecoin, Ethereum) establish consensus among millions of users in a probabilistic manner [START_REF] Garay | The bitcoin backbone protocol : Analysis and applications[END_REF] thus, eventual consistency [START_REF] Baldoni | Unconscious Eventual Consistency with Gossips[END_REF] took over from the initial need to maintain a coherent view of the system among participants. Failure-resilience characterize the systems as long as malicious nodes remain a minority in the P2P network (see Section 1.4.1.3). The idea is to introduce computational costs -to find a proof-of-work that validates a block of transactions -for charging peers who deviate from the default behavior (e.g., Bitcoin adopts previous approaches for fighting email spam [START_REF] Wiki | Hashcash[END_REF] and preventing Sybil attack [START_REF] Aspnes | Exposing computationally-challenged Byzantine impostors[END_REF]). With the increase in popularity for cryptocurrencies, scalability and performance requirements changed significantly. Weaknesses of first generation blockchains led to a deeper analysis of the underlying technology through the lens of distributed computing. At a closer look PoW consensus procedure with its limited scalability and hight latency wastes too much 1.4. AGREEMENT IN BLOCKCHAINS computational resources. Appropriate amendments to the PoW procedure can guarantee challenging scalability levels without energy waste.

Several alternatives to PoW were proposed in order to compensate for its complexity and scalability issues. The idea was to replace the wasteful computations characterizing the PoW consensus with alternative proofs of a performed effort in validating transactions. PoW consensus together with protocols characterized by an effort-based leader election form the class of proof-of-X (PoX) consensus algorithms as defined by Tschorsch and Scheuermann in [START_REF] Tschorsch | Bitcoin and Be-yond : A Technical Survey on Decentralized Digital Currencies[END_REF].

1.4.2.1 Proof-of-X Consensus
PoX protocols are designed for permissionless blockchains and relay on a probabilistic leader election process. In permissionless environments every node has the chance to become a leader simply proving that it made some "effort". The latter may have a computational, a monetary, or a storage nature or it may be an effort to assert itself on the blockchain network. The elected leader maintains his voting role till the new election's results are available. In the following we detail the PoW consensus, the PoS algorithm and, the PoS variations involving virtual mining.

Proof-of-Work.

The idea behind a PoW protocol is to make validation tasks difficult to perform, but trivial to verify. This idea was first presented as a solution to the email-spamming issue [START_REF] Dwork | Pricing via processing or combatting junk mail[END_REF] and applied in a system called Hashcash [START_REF] Back | Hashcash -a denial of service counter-measure[END_REF]. The email sender should solve a cryptopuzzle finding the hash of a string, containing all the necessary information of the receiver, which has to meet a certain target.

The usage of the Secure Hash Algorithm (SHA) [START_REF] Eastlake | US secure hash algorithm 1 (SHA1)[END_REF], mapping data of arbitrary length to data of a fixed length in a non-invertible way, ensures a costly procedure to find a valid hash. B-money [START_REF] Dai | B-money (Blockchain)[END_REF] suggested, in 1998, a PoW procedure where the computational effort can be easily quantified in terms of commodities baskets. At the same time, a PoW-based decentralized digital currency called Bit Gold was proposed [START_REF] Szabo | Bit Gold[END_REF] such that nodes should generate strings of bits using one-way functions with a cost expressed in number of compute cycles. The last Bitcoin's precursor, RPOW [START_REF] Finney | RPOW -Reusable PoW[END_REF], incorporates the hashcash scheme creating Reusable PoW (RPoW) tokens. Bitcoin, as its precursors, uses a computational hard validation procedure to create rare and valuable goods. The real contribution brought by the system is the combination of decentralization, double-spending resistance, Sybil resistance and 1.4. AGREEMENT IN BLOCKCHAINS trustless node management with the "block-chain" architecture.

The PoW protocol consists in a race among nodes to be the winner and therefore gaining a reward of new minted tokens. The competition takes place among particular nodes, called miners, aiming at producing a valid PoW consisting in the hash value computation of a previous block header.

In order to validate a block, the computed hash should meet a precise difficulty requirement. The nature of the problem relates the mining procedure to a lottery race where the validation process is completely aleatory and the probability of finding a valid hash is proportional to miners' computing power. Once the winner is found it acts as a leader node attaching to the blockchain its selected block of transactions. Its epoch expires with a new valid block, thus a new winner of the mining race.

Bitcoin consensus provides for the coincidence of both validator and leader roles in a single node. In general, PoW blockchains may separate the leader election (mining/transaction validation) form the transaction ordering procedure (i.e., Bitcoin-NG [START_REF]Bitcoin-NG : A Scalable Blockchain Protocol[END_REF]).

Strong consistency would ensure a single chain of valid blocks published on the ledger. A PoW mechanism, however, guarantees consistency on a probabilistic form (forms of eventual consistency [20; 104; 139; 140]) since forks may occur. Whenever two blocks are validated approximately at the same time, or the network latency is delaying the transmission of a valid solution to the network, the result is the presence of two valid chains with the same block number. This inconsistent situation is solved with the validation of a new block through the longest chain rule : the chain with the most blocks is considered as the valid one, noting that the chain related to the greatest PoW effort may not be the longest chain [START_REF] Wiki | Testnet[END_REF]. The rule is proposed as a probabilistic solution to the Byzantine Generals problem [START_REF] Lamport | The byzantine generals problem[END_REF]. Other variants of the longest chain rule were proposed in order to scale PoW blockchains : GHOST [START_REF] Sompolinsky | Accelerating Bitcoin's Transaction Processing Fast Money Grows on Trees, Not Chains[END_REF] proposed the heaviest chain rule that is confirming the block in the chain with the highest aggregate difficulty level, i.e., with the greatest computational load involved.

The economic incentives [START_REF] Okada | Proposed classification of blockchains based on authority and incentive dimensions[END_REF] resulting from the mining procedure induce miners to reduce the validation costs in order to maximize their earnings. Over the years the democratic idea pushed by Bitcoin of one-CPU-one-vote has left room for a centralizing trend in the validation process with a decreasing number of active solo miners and the formation of powerful coalitions of miners, mining pool, showing practical advantages but also motivating opportunistic pool-hopping behaviors [START_REF] Belotti | Bitcoin pool-hopping detection[END_REF].

Centralization in a permissionless environment results in increased vulnerability to double-spending attack. Decentralization is a characterizing feature for blockchain based cryptocurrency, one may argue

AGREEMENT IN BLOCKCHAINS

that pool formation is nothing more than a converging trend to the original banking system [START_REF] Gervais | Is Bitcoin a Decentralized Currency ?[END_REF].

An approach to face this monopoly trend is the inclusion of memory-access operations in the PoW computations accompanied by memory-bound functions. However, these schemes cannot make this centralization trend disappear since it requires specialized mining equipment and thus benefits from miners cooperation, as the original PoW (i.e., Litecoin [145; 146]).

Mining devices are constructed to compute hash values as fast as possible. The Bitcoin system was conceived for a CPU mining that was quickly replaced by a GPU (Graphic Processing Unit) mining. GPUs can perform hash computations in a more efficient way with respect to classical CPUs, therefore general Altcoins started adopting GPU mining at the end of 2010. This results in faster operations, due to operations parallelizing [START_REF] Zhou | Parallel frequent patterns mining algorithm on GPU[END_REF] and in energy savings [START_REF] Pinto | Mining questions ab-out software energy consumption[END_REF]. When hardware based mining solutions took over the computing power dedicated in mining activities experienced, despite strong fluctuations, an exponential growth [START_REF] Taylor | The Evolution of Bitcoin Hardware[END_REF]. It worth nothing that alternative PoW-schemes try to compensate the incredible waste of energy with useful work at an academic level ; Primecoin [START_REF] King | Primecoin : Cryptocurrency with prime number proof-of-work[END_REF] searches for prime numbers chains (Cunningham chain [START_REF] Andersen | Cunningham chain. from mathworld-a wolfram web resource[END_REF]), NooShare [START_REF] Coventry | NooShare : A decentralized ledger of shared computational resources[END_REF] executes Monte-Carlo simulations, Shoker [START_REF] Shoker | Sustainable blockchain through proof of exercise[END_REF] proposes matrix-product problems to solve while in [START_REF] Marshall | Proofs of Work from Worst-Case Assumptions[END_REF] authors propose to replace PoW hashing function with alternative one-way functions satisfying additional properties.

Pseudo-random leader elections based on PoW schemes [START_REF] Bentov | Proof of Activity : Extending Bitcoin's Proof of Work via Proof of Stake[END_REF] are generally prone to grinding attacks. The practice consists in testing several candidate blocks improving in this way the possibility of being a leader in the following round. Hence the need of unbiased unpredictable random elections as those adopted in [156; 157]. The need of alternative PoX schemes (i) motivating the proof of "useful" efforts and (ii) improving performance [START_REF] Singh | Performance Comparison of Executing Fast Transactions in Bitcoin Network Using Verifiable Code Execution[END_REF] in terms of security, scalability and eco-friendliness is evident.

Proof-of-Stake and Virtual Mining Alternatives.

The PoS mechanism resumes the PoW one while passing from a real mining to a virtual mining (i.e., consumption-free mining). It replaces the PoW leader election based on mining, with an alternative approach depending on users' investments in the blockchain, i.e., their stake : the amount of virtual tokens held by a user ; in other words, the mining race costs are replaced by shares in the consensus.

The probability of becoming a leader is proportional to one's stake ; once a leader is selected among stake-holders, it has the right of validating the preferred block. As for PoW, consensus finality is not 1.4. AGREEMENT IN BLOCKCHAINS met and the "richest chain" rule breaks deadlock points -the valid chain is the one with the highest total amount of stake involved. Hence PoS could avoid the centralization trends observed with Bitcoin. PoS-type algorithms differ in the (i) estimate of users' holding and, in the (ii) adopted incentive mechanisms.

Users' stake can be estimated as an amount of coins stored in an account. However, security and fairness issues [START_REF] Amoussou-Guenou | Correctness and Fairness of Tendermint-core Blockchains[END_REF] arise when considering this consensus configuration : leader election components are quite predictable, and a selection based solely on the amount of tokens held by users is unfair ("rich-get-richer"). Hence, alternative solutions were proposed to elect the leader taking into account its stake.

One of the first PoS variations consists in weighting a coin stake by its "age" (i.e., the time elapsing between the last movement of the coin). In PeerCoin [START_REF] King | Peercoin-secure & sustainable cryptocoin[END_REF] the coin age has the same role of the computational power for the classical PoW scheme. However, the real difference is to give all participants the chance to be elected, thus solving monopoly-like situations. Despite stake-based coins (e.g., Peer-Coin and Nextcoin [START_REF] Penzl | SNAPSHOT-Nxt unsurpassable blockchain solutions[END_REF]) prevent centralization trends, their underlying protocols encourage amassing coins and stay inactive in the network -that exposes the network to Sybil and DoS attacks [START_REF] Babaioff | On bitcoin and red balloons[END_REF]. Thus, the ideas to punish coins accumulation trends (proof-of-stake-velocity [START_REF] Ren | Proof of stake velocity : Building the social currency of the digital age[END_REF]) and to assign the reward for the validated blocks only to the active users (proof-of-activity [START_REF] Bentov | Proof of Activity : Extending Bitcoin's Proof of Work via Proof of Stake[END_REF]). Active peers are the ones that solve a crypto-puzzle with a difficulty target depending on the users' stake, thus hash computing improves network security. Leading stake-holders, responsible for block validation, are therefore picked in a pseudo-random fashion.

In both Ouroboros [START_REF] Kiayias | Ouroboros : A provably secure proof-of-stake blockchain protocol[END_REF] and Snow White [START_REF] Bentov | Snow white : Provably secure proofs of stake[END_REF] participants use pseudo-random function to predict the block-generator however, while the former takes into account only the stake distribution in the network, the latter additionally relies on a pre-image (nonce) calculation. More precisely, Snow White is an "hybrid" protocol cleverly mixing PoW (computing only one hash per round) and PoS (the hash should meet a target depending on user's stake). Blackcoin [START_REF] Vasin | Blackcoin's proof-of-stake protocol v2[END_REF] and Nova Coin [164] are the first applications using this type of hybrid schemes (i.e. mixing different consensus mechanisms).

One of the latest variants of the PoS scheme was recently proposed by Ethereum. This is Casper [START_REF] Buterin | Casper the friendly finality gadget[END_REF] that is to be incorporated into the "Serenity" [START_REF] Buterin | Understanding Serenity, part I : Abstraction[END_REF] version of the platform. Casper brings the PoS scheme closer to the traditional BFT model -more precisely, it combines the concepts of security deposits with voting in order to reach agreement. Peers have to make a security deposit in order to be Concerning rewards distribution, PoS protocols originally distributed rewards among all peers regardless the elections results [157; 156] with the result of incentivizing the famous nothing-at-stake [START_REF] Li | Securing proof-of-stake blockchain protocols[END_REF] attack. Today these naive implementations are overcame by valid alternatives : some [1; 165] asking validators to lock an amount of coins (proof-of-deposit), some [START_REF] King | Peercoin-secure & sustainable cryptocoin[END_REF] asking to destroy it (proof-of-burn), and some [168; 169; 170] asking to allocate a significant amount of memory/disk-space (proof-ofcapacity) or to provide wireless network coverage (proof-of-coverage).

Efficient PoS alternatives based on virtual mining working for open-access blockchains with random leader election within untrusted nodes are the PoET (proof-of-elapsed-time) and the PoI (proof-ofimportance) consensus schemes. The former adopts a trusted execution environment (TEE) in Intel SGX for the results verification [START_REF] Olson | Sawtooth : An Introduction -White paper[END_REF] for guaranteeing both safety and randomness of the leader election.

Peers make a request of wait time for processing the election procedure ; the winner of the lottery is the validator with the shortest waiting. Correctness of the election can be publicly verified within the TEE : leaders generate a proof testifying they had the shortest wait time and additionally, they prove that the block broadcast happened right after the waiting expiration. The platform NEM (New Economic Movement [171]) proposes a blockchain based on a peculiar block validation process (i.e., harvesting) and a PoI [START_REF]Survey on Blockchain Technologies and Related Services[END_REF] consensus algorithm determining the user that create and append transactions block (i.e., harvester ). NEM works with an underlying cryptocurrency (i.e., XEM) that characterizing the balance of each account on the network that is split in a vested and an unvested part. Eligible validating peers are evaluated according to the amount of vested XEM and the support their accounts give to the network (i.e., number of transaction partners and number and size of transactions in the last 30 days). Contrary to previous mechanisms, PoI does not incentivize peers to save their coins/resources increasing their voting power. Harvester candidates are incentivezed to be 'active' in the network.

PoS enables both public and private leader election thus, the consensus protocol is applicable by both blockchain with and without permissions. Restricted elections result in DoS resilience since leader in the epoch become known to the stake-holder community at first and then to th public. Moreover, permissions on block validation may be assigned in order to improve the efficiency of the system.

AGREEMENT IN BLOCKCHAINS

That is, stakeholders privately delegate a representative set of validating peers (delegated proof-ofstake DPoS [START_REF] Larimer | Delegated proof-of-stake white paper[END_REF]). The list of witnesses is shuffled at the end of each round in such a way that each validator can produce block according to a certain rate. Witnesses are paid out for each produced block.

BFT Algorithms

Traditional BFT protocols -resilient to both byzantine and crash failures -generally work under partial synchrony assumptions, bounded communication latency and a classical client-server architecture. Due to their nature (state machine replication protocols) properties of liveness and safety are guaranteed. Moreover, in BFT, both consensus proposal and consensus decision events are separated.

The downside in these agreement protocol class is the communication complexity [START_REF] Cachin | Yet another visit to Paxos[END_REF]. Hence, the necessity for closed-system adoption (i.e., permissioned blockchains).

The Practical Byzantine Fault Tolerant (PBFT) protocol [START_REF] Castro | Practical byzantine fault tolerance[END_REF] is a BFT variant that addresses the consensus problems for small systems, since agreement among n nodes is reached through the transmission of O(n 2 ) messages ; it does so relying on a three phase round division where in each round a block is validated passing through a pre-prepared, prepared and commit steps. Each peer proposal access to the next phase only with the 2/3 network approval. Therefore, the algorithm requires at least 3f + 1 honest replicas to tolerate f failing nodes. Recent PBFT variant SIEVE [START_REF] Cachin | Non-determinism in byzantine fault-tolerant replication[END_REF] introduce non-determinism in the chaincode execution handling transactions with occasionally different outputs.

Moreover, an alternative PBFT-based consensus protocol recently proposed simplifies the traditional failure model for better efficiency levels. The idea behind XFT protocol [START_REF] Liu | XFT : Practical Fault Tolerance beyond Crashes[END_REF] is to exploit the following assumption : adversaries cannot control the majority of the nodes n > 2f . In this way the crash fault tolerant protocol avoids considering byzantine failures.

With the arrival of consortium blockchains, the BFT protocol (popular in the financial sector)

The most popular BFT-open protocol adopting trusted subnetwork in the block validation process is

Ripple [START_REF] Schwartz | The Ripple protocol consensus algorithm -White Paper[END_REF]. It make use of unique node lists (UNLs) playing the same role as the Stellar quorums.

AGREEMENT IN BLOCKCHAINS

The main characteristic of the protocol is that agreement is reached when the 80% of the nodes vote for the same candidate block, this result in low adversary power tolerance. The recent BFT variant, proof-of-authority (PoA) [178], relies on a set of trusted nodes (authorities) with a rotating leader.

PoA algorithms [179; 180] ensure better performance with respect to PBFT consensus since working with less message exchanges (i.e., 1-2 message rounds to commit a block).

Classical BFT scalability drawbacks, regarding the number of nodes participating in the consensus, have been solved with hybrid consensus protocols appropriately mixing PoX with BFT algorithms used in permissioned environments. This mix results in committee formation driving the consensus process replacing the original leader role. Hybrid models contemplate the usage of two different consensus procedures ; one to form the committee and another one to establish consensus among the nodes inside the community. Note that, however, by "hybrid" we do not mean any committee-based consensus procedures (e.g., Hyperledger utilizes PBFT) ; hybrid algorithms are the ones mixing two different consensus schemes. In order to differentiate those hybrid schemes running classical BFT protocol -to the ones that make use only of PoX procedures -we denote them as hybrid BFT-based algorithms.

Nowadays, it is possible to find blockchains not requiring global consensus where each node has its own hash chain containing only the transactions where a user is involved. Cong proposed in [START_REF] Cong | A Blockchain Consensus Protocol With Horizontal Scalability[END_REF] a system where agreement is established on special blocks representing a set of transactions. These systems can reach full horizontal scalability (i.e., scalability in the number of nodes) at the expense of robustness.

Hybrid BFT-based Algorithms

Hybrid consensus mechanisms are born with the intent of preserving permissionless consensus but overcoming the trade-off between scalability and performance. Standard PoX consensus has to be improved by combining it with parts of BFT-based permissioned consensus mechanism. The idea of dividing the agreement process into different parts (see Section 1.3), initially proposed by private blockchains such as Hyperledger, is the key to built scalable permissionless protocols providing consensus finality. The assignment of tasks to the nodes is carried out by means of a committee-formation ;

consensus is driven by a community of nodes that build blocks at a first stage and then come to vote for their validity.

At first, the committee is formed, which then will agree on the validation of a block. Membership

AGREEMENT IN BLOCKCHAINS

of the committee is open to all nodes in the blockchain ; they acquire voting rights for the second phase through a PoX scheme. Existing hybrid algorithms involve PoW and PoS procedures to establish the leading nodes in the committee responsible for validating blocks. The idea of joining a committee through a PoW procedure is to assign voting power to each participant in proportion to their computational strength ; this is the case of ByzCoin [START_REF] Kogias | Enhancing bitcoin security and performance with strong consistency via collective signing[END_REF] and PeerCensus [START_REF] Decker | Bitcoin meets strong consistency[END_REF] where Bitcoin meet strong-consistency. Committee formation through PoX schemes is a dynamic process ; participants receive a share of the committee through real or virtual mining. Tendermint [START_REF] Buchman | Tendermint : Byzantine fault tolerance in the age of blockchains[END_REF] is the most popular protocol where Bitcoin PoW protocol is replaced with a PoS scheme that is, virtual mining.

For Tendermint and other less known protocols [185; 186; 187] random committee selection is (can be)

replaced by an assessment of the amount of tokens held by the blockchain nodes.

The right combination of PoX and BFT algorithms significantly improves the blockchain performance ; however, scalability and throughput are not positively affected with a huge single-committee.

Therefore, blockchains may adopt a consensus procedure based on multiple committee, also known as sharding [START_REF] Bano | Consensus in the Age of Blockchains[END_REF]. In this way transactions can be processed in parallel by different shards (i.e., committees)

of few nodes since their size is inversely proportional to the achieved performance level.

Summary of Consensus Mechanisms and Their Evolution

The diagram in Fig. 1.4 summarizes the evolution of the procedures to reach consensus in distributed systems, starting from the classic pre-blockchain algorithms -(i) Classic consensus -passing through the early blockchain consensus -(ii) Proof-of-X and (iii) Hybrid consensus -and, ending with the consortium solutions widely used today -(iv) Consortium BFT consensus and (v) Hybrid BFT-based.

We have highlighted five main classes of consensus and characterized (where possible) the different variants. We consistently cite the main algorithms representing the consensus classes, encountered in the previous discussion.

AGREEMENT IN BLOCKCHAINS

Classic consensus (predecessors)

Crash fault tolerant : 2PC, Atomic broadcast, SMR (Paxos [START_REF] Lamport | Paxos made simple[END_REF], RAFT [START_REF] Ongaro | In search of an understandable consensus algorithm[END_REF])

BFT : PBFT [174]
Proof-of-X (permissionless)

PoW (Bitcoin [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF]), PoS (Peercoin [START_REF] King | Peercoin-secure & sustainable cryptocoin[END_REF]), PoI (NEM [171]), PoC(Permacoin [START_REF] Miller | Permacoin : Repurposing Bitcoin Work for Data Preservation[END_REF]), PoB (Slimcoin [START_REF]Slimcoin : A Peer-to-Peer Crypto-Currency with Proof-of-Burn[END_REF]), PoD (Ethereum [START_REF] Buterin | Casper the friendly finality gadget[END_REF]),

PoET (Intel SawtoothLake protocol [START_REF] Olson | Sawtooth : An Introduction -White paper[END_REF])

Hybrid consensus

Pseudo-random leader election mixing PoW and PoS (Blackcoin [START_REF] Vasin | Blackcoin's proof-of-stake protocol v2[END_REF], Novacoin [164], Casper [START_REF] Buterin | Casper the friendly finality gadget[END_REF])

Consortium BFT consensus

Trusted validators set : Qourum (SCP [START_REF] Mazieres | The stellar consensus protocol : A fede-rated model for internet-level consensus -White paper[END_REF]) ;

representative nodes (Neo, dBFT [177]) ; uniqe node list (Ripple [START_REF] Schwartz | The Ripple protocol consensus algorithm -White Paper[END_REF]) ; authorities (PoA [178])

Hybrid BFT-based consensus

Comparison between Blockchain Consensus Protocols

Previous sections presented the problem of reaching consensus in a distributed system. Traditional consensus protocols have opened the way to PoX-type mechanisms and then reconsidered in permissioned blockchains fro their performances. Vukolic [START_REF] Vukolić | The quest for scalable blockchain fabric : Proof-of-work vs. bft replication[END_REF] work is one of the first at addressing a comparative analysis on the different consensus procedures however, it focuses only on the PoW-based algorithm and traditional BFT scheme. Recent works [93; 36; 37; 35; 189] compare different agreement protocols in terms of (i) node identity management, (ii) energy saving, (iii) tolerated power of adversary, (iv) transaction finality, (v) communication complexity, (vi) nodes scalability, (vii) throughput and, (viii) latency level.

Table 1.4 and Table 1.5 summarize these comparative studies. The data shows the tendency to implement safer and high-performance (1000 tps) blockchain-based systems with low energy impact 1.4. AGREEMENT IN BLOCKCHAINS and low latency, that reach a final agreement with the guarantee that the validated blocks will not be discarded. It can be deduced that further work needs to be done regarding the message overhead between the consensus participants (n in Table 1.4) and Table 1.5).

Blockchain Implementation

Leveraging on the important background presented in the previous sections, this section is meant to start our blockchain vademecum 6 , to give to the reader a tutorial about when to use blockchain, which solution to use, and how to use it, based on use-case requirements.

During the past few years, research societies along with industrial and governmental institutions intensively worked on DLT and blockchain, trying to understand better this paradigm and its place in today's market. This resulted in many publications and standardization activities as well. In the following, we provide the reader with a decision model to understand When to use the blockchain technology (Section 1.5.1) and Which type of blockchain suits a certain use case best (Section 1.5.2). The decision model is characterized by two decision paths (When and Which paths) that can be traversed either consecutively or independently ; the decision points can be both direct questions or trade-off points 7 . In the following, we use Fig. 5.19 as a support for the When and the Which questions in Sections 1.5.1 and 1.5.2.

General Purpose Reading List.

In developing this tutorial we made use of a broad spectrum of documents going beyond academic literature, and including books, white-papers, technical reports, blockchain forums, discussion papers, and online encyclopaedias. We concentrated on works showing real applications of blockchain in the industry going beyond the well-known digital payment systems proposed by cryptocurrencies. The main investigated areas were : (i) finance, (ii) security-and-privacy, (iii) public, (iv) Internet-of-Things (IoT), (v ) smart business. We report such reference works in Table 1.6. In addition, our reading list includes works investigating when a blockchain can revolutionize a business [190; 191; 192], benefits and drawbacks of both permissioned and permissionless blockchains [92; 105; 193; 74; 43], and links with traditional solutions [194; 195; 196; 197; 198].

6. 'Vademecum' is a term that may not be well-known by the reader. It derives from the latin expression 'Vade Mecum', literally meaning 'go with me'. It refers to a synthetic collection of information concerning a specific field or technique (blockchain in our case), having the goal to provide the reader with quick and concise responses on the different details of the specific field or technique.

7. Trade-off points represent situations that involve a choice between two or more aspects, where the loss of value for one aspect constitutes an increase in value for the other one(s). In the proposed decision tree alternatives are (i) blockchain or traditional database features for Section 1.5.1 and, (ii) permissionless or permissioned blockchain features for Section 1.5.2. [199; 200; 201; 202; 203].

(ii) personal data-management [204; 94].

(iii) energy [205; 206; 207], health-care [208; 209; 210; 211; 212; 213; 214; 215; 216].

(iv) storage, authentication, e-commerce [217; 218; 219; 220] communications & networking [221; 222; 223]. (v) supply chain [224; 225; 226], transportation [227; 228].

When to Use Blockchain ?

This section focuses on the first general question of the vademecum : when to use blockchain as a technology ? Our use-case oriented answer to the When question is given passing through the following direct questions and trade-off points (see Fig. 5. [START_REF] Davenport | Distributed database technology-a survey[END_REF]). The vademecum aims to provide an answer for any use-case questioning whether the blockchain represents a good business solution.

(1) Do you need to store and share a ledger state ?

We start from a situation where a ledger database is required i.e., data in transaction form needs to be stored and shared. Data constitute the ledger state, which is subject to updates that must be shared over the network. Whenever it is not needed to share a stored state, complex cryptographically-based architectures result unnecessary for simply letting stored data to be accessible. Therefore, in the presence of a negative answer blockchain is certainly not needed and traditional solutions are preferable.

(2) Are there multiple potential writers ?

The adoption of blockchains makes sense only when data need to be stored by multiple users and shared among them. Indeed, in a blockchain multiple users (not necessarily all network users) are supposed to have writing access and permission to participate in the procedure to establish consensus among parties. Blockchain lets business move from hierarchical client-server systems with locked writing rights to decentralized P2P interactions with multiple (if not all) nodes able to write to the distributed ledger.

(3) Who do you entrust with the ledger maintenance ?

Blockchain enables interactions among trustless actors circumventing any intervention by a central authority. The need for decentralized systems arises whenever network participants lose their trust on a (alternative or pre-existing) centralized system. However, the transition from a centralized to a 1.5. BLOCKCHAIN IMPLEMENTATION decentralized system is not necessarily radical ; blockchains can decentralize some functions while keeping others centralized. Blockchain has revolutionized the concept of 'trust', which is no more related to the identity of the actors in charge of the validation procedure, but it is related to the protocol architecture. Clients trust the technology that is forcing validators to follow the protocol punishing or making unfeasible any possible deviation. For such a key strategic question on the trust, we can spot three possible types of answers : a) An external third party : the system maintenance is entrusted to an external entity which in case of failure could be switched. In such a case, designers should opt for a centralized architecture that is easy to deploy and maintain by the trusted third party. b) A group of selected actors : nodes in charge of updating the ledger participate to the system. Their identity can be known or unknown, however, the methods for selecting these nodes and the targeted activities are important aspects. Indeed, the class of partially-centralized systems includes a spectrum of possibilities such as adopting private distributed ledger, creating consensus committee [START_REF] Bano | Consensus in the Age of Blockchains[END_REF], and structuring the communication with external trusted systems [START_REF] Clack | Smart contract templates : foundations, design landscape and research directions[END_REF]. Instead of providing open-access to anyone, blockchains can bind certain of their functionalities (read and write) arranging permissions. We may therefore have an escalation of permissions, from the single permission to read the transaction log to the ability of validating transactions. At first, permissioned blockchains select participants with network access controls ; their identity must be known. Then, permissions are given to implement any type of change to the data registry ; different trust levels can be associated with different nodes' roles (see Section 1.3). Moreover, whenever the validation of a transaction is linked to an external variable realization, one may choose whether to trust or not the actor designated to communicate with the outside.

Regardless of any restrictions on the node roles, once decided to trust a restricted entourage for the validation process, one may wander which actor to entrust the verification of the operation correctness. Let us recall that block verification consists in a repeated check of both the chained blocks integrity and authenticity -carried out in most cases by the validators themselves -and the chained blocks validity. Blockchain transparency allows any network participant to verify whether a published block was validated according to the protocol since all network nodes have the same view on the log. On the other hand, verification checks are entrusted to a central 1.5. BLOCKCHAIN IMPLEMENTATION authority whenever participants differ in the view they have of the ledger. Thus, the next question at this point is :

(3.b) Do you need the ledger to be publicly verifiable ?

Whenever a system requires public verifiability, one may keep restrictions on writing rights but at the same time leave the freedom to everyone to observe the system state -as for openpermissioned blockchains. For those cases in which verification checks may not be in the public domain, the choice between a private blockchain (full-permissioned) and a traditional solution is clearly linked to the nature of the verifier(s). Verifying peers coincide with the so-called validating peers in a private environment where transactions validation is performed by trusted parties.

The choice now is between a centralized verifier -leading to the adoption of a traditional central database where the group of trusted nodes organize themselves in a central authority (with both reading a writing rights) representing however, a potential single point of failure -and a distributed verifier -consisting in several trusted validators known to the network operating in a P2P framework where all the participants in the system may connect to each other. The adoption of a blockchain (permissioned in this case) rather than a traditional solution is dominated by trade-offs regarding mainly the impact on the throughput, the costs, the presence of the basic blockchain features, the failure resistance level and the adaptability to different business cases.

Trade-off (3.b) performance, cost efficiency and adaptability VS blockchain features and failure resistance

Traditional centralized databases are widely used both for their simple architecture -easy to adapt to each use case and often affordable as the data is stored and maintained from a single central computing node -and, for the speed and ease in updating the data they manageevery change is managed by the central authority and immediately communicated to users [START_REF] Schollmeier | A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications[END_REF].

In fact, the central authority can easily modify data with CRUD (Create, Read, Update, and Delete) commands. Thus, the technology strengths consist in high levels of performance (in terms of transaction processing rate), low costs in adopting the technology (in terms of design and management cost, as conventional softwares are cheaper than blockchain solutions) and high degree of adaptability in managing any type of data and its use.

Despite the countless advances made by blockchain technologies to reach higher levels of scalability, throughput and latency, blockchain will likely always be less performing than a centralized 1.5. BLOCKCHAIN IMPLEMENTATION database. This is because processing any change in a distributed system -through transactions -requires additional efforts consisting in : (i) applying and verifying the digital signature, (ii) agreeing on a unique vision of the data ledger, (iii) replicating data across the network and, (iv) updating the ledger only with write-operations. In blockchain the idea is that the validating nodes independently process transactions and then at a second stage compare the obtained results with the rest of the network until they come to an agreement. However, blockchain offers, at the same time, the six important features presented in Section 1.2.5 (decentralization, immutability, confidentiality, integrity, authenticity and transparency), that are absent (in their entirety) in traditional databases. In addition, since blockchain is first and foremost a distributed ledger, it is robust against node failures 8 . Adopting or not blockchain is therefore a matter of which set of quality properties to privilege between (i) performance, cost efficiency and adaptability and, (ii) blockchain fundamental features and failure resistance.

c) The public community : Whenever trust cannot be laid on a set of network nodes, it is better to have confidence in a protocol (i.e., a set of rules) that guarantees the correct functioning of a system maintained by the public community. Permissionless blockchains enable untrusted parties to interact without relying on any man-in-the-middle (i.e., disintermediation). Transaction history is fully transparent to everyone. Validation and verification are carried out in a fully open and distributed fashion ; any network node can participate in the process possibly remaining pseudonymous.

Which Blockchain to Use ?

Thanks to the attractive blockchain properties (Section 1.2.5), the development community has worked hard to broaden its range of applicability. At this point, the vademecum suggests to apply blockchain also to multi-access shared ledger situation such that there is a circle of trust, and concessions in terms of performance, cost efficiency and adaptability can be acceptable.

Permissionless blockchains require users to direct their trust towards cryptography and related mathematics, while permissioned ones ask for confidence in few (or all) nodes of the network. Therefore, given that blockchain is the right technology after the When question, at this stage the first question 8. However, it should be noted that for permissioned blockchains any centralized procedure (such as validation, verification or external communication) can be considered as a single point of failure.

BLOCKCHAIN IMPLEMENTATION

the designer may wander is in which of the two categories falls its use-case. In addition, if directed to a permissioned blockchain one may choose whether or not to put restrictions on data ledger access.

The vademecum chart in Fig. 5.19 can now be read from the bottom to the top.

(4) Which is the blockchain primary adoption ?

Blockchain can be primarily adopted as (i) a system of records (SOR) and as a (ii) platform. Polarization toward the former or the latter application class is important to characterize the blockchain nature. a) Blockchain as a system of records SOR's principal goal is storing data and wisely processing it in order to re-present to users the history of data. Blockchain constitutes an innovative solution to track the history of information modifications that is characterized by interesting features, including its transparency. The question now is which blockchain solution between a permissionless and a permissioned one is best for a SOR. Firstly, one should realize if there are disclosure issues. Once understood the desired privacy level (between anonymity and confidentiality), the choice is a matter of trade-offs ; high performance comes at a cost. what permissionless blockchains can hide to the network is the users' identity only, conversely, every operation performed in the network is in the public domain. Hence, permissionless blockchains guarantee users some degree of anonymity (pseudonymity) without offering any confidentiality in transacting on the blockchain. On the other hand, private blockchains (with restrictions on both writing and reading operations -and where participants are known in the network) can ensure that 'what happens in the network remains in the network'. Therefore, if operations are not to be disclosed to the public, the most appropriate solution is a blockchain that is not accessible to everyone, i.e., a full-permissioned blockchain ; otherwise, the following trade-off allows discriminating among a permissionless blockchain and a permissioned one.

Trade-off (4.A) performance VS cost efficiency : In the absence of confidentiality constraints, one should concern about the importance of performance over cost efficiency. In order to achieve a processing rate of the order of thousands tps, the classical permissionless blockchain structure must 9. We mean by the term 'confidentiality' the non-disclosure to the public of the operations performed by blockchain users.

1.5. BLOCKCHAIN IMPLEMENTATION be abandoned. Blocks of transactions should no longer be processed one at a time ; blockchain needs to adopt an architecture favoring the processing of multiple blocks in parallel. These result in a more complex technology structure with high design costs. Permissioned blockchains (both openpermissioned and full-permissioned) offer good performance due to their restricted nature where data validation, verification, replication and modification are faster with respect to a public environment.

Thus, whenever priority is given to the throughput, the best choice is in favor of permissioned solutions (both full-permissioned and open-permissioned). (4.A.i) Which is the performance level required ? If it is required to have performance comparable to that of a centralized system, a possible solution is to store data (i) off-chain or (ii) on-chain via smart contracts. Blockchain initial aim was to enable data-storing on-chain ; however the kind of data stored was the transaction history. In the Bitcoin blockchain external data was initially stored on the ledger through unofficial transaction manipulation (e.g., writing in a coinbase transaction or using a fake account address) discovered and disseminated by avid network users [START_REF] Xu | A taxonomy of blockchain-based systems for architecture design[END_REF]. Due to the limited space provided by the OP-RETURN, second-generation blockchains proposed alternative solutions based on smart contracts and off-chain solutions. Data can be included in a smart contract at variable or event level directly on-chain (on a blockchain -no matter the nature -supporting smart contracts), however performance (up to thousands tps) is not still comparable with the one offered by traditional databases (e.g. Multichain early versions [231]). Off-chains solutions are the best in terms of performance ; raw-data are stored off-chain, while it is possible to handle meta-data or hashed-data on-chain as a complementary storage (e.g., Swarm [232] and Filecoin [START_REF] Labs | Filecoin : A Decentralized Storage Network (White paper)[END_REF]). However, the ease of communication between the two technologies heavily depends on the type of blockchain and the corresponding off-chain solution chosen. The ideal off-chain storage is a private cloud attached to the corresponding blockchain, thus a full-permissioned structure (e.g., Microsoft Cryptlet Fabric [234]).

b) Blockchain as a platform

In general a blockchain-based system enables digital data-sharing, digital data-storing and virtual interactions among peers. The principal goal of a blockchain platform is to form P2P digital relationships favoring digital exchanges and business automatization.

(4.B) Which is the platform primary purpose ? The central question relies on the platform primary purpose between the following fundamental categories : 1.5. BLOCKCHAIN IMPLEMENTATION i) Asset digital exchange : Blockchain enables the sharing of any valuable data (i.e., asset) among parties without any geographical and timing constraint. Both the asset nature and the size of the data-flow impact on the choice of the blockchain nature and its architectural design. (4.B.i) Which is the asset nature ? Assets could be sensible data that have to be managed restricting access to the record -full-permissioned blockchains. If no disclosure issue occurs, the quest of adopting or not permissions in writing rights merely depends on trade-offs : for better performance than that offered by Bitcoin-like blockchains one should pay the price of not guaranteeing full transparency (auditability) and equal rights of participation.

Trade-off (4.B.i) performance VS blockchain features : The choice whether to give priority to the basic blockchain features rather than to the performance is strictly linked to the nature of the exchanged assets in the network. To give the reader an idea, let us take the case of tokens.

Blockchain became popular thanks to assets tokenization ; the aim is to create a trading system of items that cannot be duplicated. Cryptocurrencies propose alternative payment methods through their tokens that represent a currency, i.e., a generic payment instrument. Other types of tokens such as security tokens -representing a participation, in terms of dividends, voting rights, interest rates and/or percentage of the issuing entity's profits -and utility tokens -representing only the right to purchase goods and services of the issuing entity -were created on blockchain in order to digitally participate in a business having easy access to digital services-goods [235]. In the case of currencies, all blockchain properties (auditability in particular) are fundamental in the system, thus blockchain designers are forced to loose something in terms of performance since usually currencies are intended for the widest possible public. On the other hand, security and utility tokens are considered as an alternative investment method, therefore transparency is not essential in this case and one may adopt permissioned blockchains profiting from higher processing rate with respect to permissionless solutions.

ii) Business automatization : Blockchain platforms allow smart contract deployment and execution with the aim of letting any business automate its functionalities. After questioning the sensitivity of the automatically managed data (as in question A.1), it is important to consider the ability to support world changing applications. There is no perfect blockchain for every use-case.

However, what a selection of participants is affecting the most are : (i) the non functional properties of security and robustness in terms of failures resistance and, (ii) all the features related 1.5. BLOCKCHAIN IMPLEMENTATION to blockchain applicability -that is, the flexibility to adapt the designed blockchain protocol to different business cases. Therefore, the choice is a matter of trade-off ; more flexible architectures are usually less robust. Trade-off (4.B.ii) flexibility VS robustness : Permissionless blockchains suffer from limitations in data-storing, computations, scalability and performance which does not make it applicable to many business situations. On the other hand, permissioned blockchains result more flexible for configuration since governed and hosted by a single central committee of trusted nodes ; therefore, any type of change is made faster than in a fully open and trustless environment. A classic example is off-chain storage that results more intuitive in private networks that ease communications between the off-chain storage system and the blockchain [START_REF] Xu | The blockchain as a software connector[END_REF].

Concerning security and robustness : is it better to adopt a permissionless blockchain architecture or to build a new structure on top of it. In fact, fully open-access distributed ledgers are quite robust against any type of failure as long as 50% of the system nodes are honest (see Section 1.4.1.3). In order to have robust but performing public blockchains, a possible solution is to use side-chains [START_REF] Back | Enabling blockchain innovations with pegged sidechains[END_REF]. With side-chains one may move assets and functions from the principal blockchain (main-chain) to a second one. Thus, it is possible to have a private blockchain linked to a permissionless one. [START_REF] Xu | A taxonomy of blockchain-based systems for architecture design[END_REF] gives a detailed report on the levels of performance and flexibility in permissioned, permissionless and open-permissioned blockchains. With regard to security and robustness in DLT we refer to the works of Lin et al. [START_REF] Lin | A Survey of Blockchain Security Issues and Challenges[END_REF] and Li et al. [START_REF] Li | A survey on the security of blockchain systems[END_REF].

Summary

For a new technology to realize its full potential, a lot of circumstances need to co-exist before network effects can be realized. Moreover, the actual advantages in using blockchain instead of any other traditional solution (such as centralized databases) need to be understood or at least showcase. Hence, the need for a vademecum guiding designers toward the right decision about when to adopt blockchain or not, which kind of blockchain better meets use-case requirements, and how to use it. In this chapter we provided the community with such a vademecum, while giving a general presentation of blockchain (that goes beyond its usage in Bitcoin) and surveying a selection of the vast literature that emerged in the last few years. We draw the key requirements and their evolution when passing from permissionless to permissioned blockchains, presenting the differences between proposed and experimented consensus mechanisms, and describing existing blockchain platforms. All to provide any potential blockchain user with the information to join the blockchain network as a transacting party and/or a validating node. This chapter provides an introduction to Game Theory, a branch of Decision Theory that considers decision-makers as rational agents. The rationality of the players taking part in a game enables to predict their actions and thus the outcome of the game. Knowing a game (i.e., a problem that can be modeled as a game) and the strategies available to its players (i.e., the actions agents can perform), it is possible to predict its final outcome that can be more or less stable (i.e., equilibria or solution in the core). examples that are collected in [START_REF] Lucchetti | A primer in game theory[END_REF].

In the following we present non-cooperative and cooperative games with the aim to show the reader the difference between the two classes of games. Although there exist problems that can be addressed with both non-cooperative and cooperative game theory making the distinction between the two quite informal, the problems we present throughout the thesis are modeled so that the non-cooperative and cooperative approaches differ from each other.

The following sections aim at familiarizing the reader with the concept of agents' rationality and game theoretical modeling in both non-cooperative and cooperative scenarios. Modeling techniques presented in this chapter are adopted in the following of this thesis to model blockchain users' behaviors. We focus then on a particular class of games adopted to model bankruptcy situations that may arise in the blockchain context as well. Properties of this class of games have important connotations

RATIONALITY OF THE AGENTS

when contextualized in the blockchain environment.

The chapter is organized as follows. Section 2.2 introduces the concept of agents' rationality. In Section 2.3 and Section 2.4 we present non-cooperative and cooperative games as well as their solution concepts. Bankruptcy games and their properties are presented in Section 2.5.

For further details on game theoretical modeling we invite the reader to consult [START_REF] Peters | Game theory : A Multi-leveled approach[END_REF].

Rationality of the Agents

Game theory helps understanding agents behaviors in different situation. It is based one fundamental assumption : rationality of the agents which does not necessarily mean being egoistic.

Agents behaving egoistically try to get the best for themselves without considering the satisfaction of the others. On the other hand, rational agents aim to maximize their own utility function which not always coincides with an egoistic choice. Hence, rationality overcomes egoism by taking into account players' preferences and utility functions. The second assumption states that each player is able to completely analyze the problem knowing other agents' utility functions. Each player knows what other rational players do for maximizing their utility and behave accordingly. It is important to stress out that agents' payouts depends on others' people behaviors.

In general, any situation with two or more agents involving quantifiable consequences, can be modeled as a game and game theory can help determining the 'most likely' outcomes of the game.

Let us define a few terms characterizing game theoretical modeling. A game consists of an interactive decision-making process among multiple decision-makers called players. Any set of actions available to a player in a game, depending on the game's structure, identifies a strategy. The payoff is the quantifiable (according to a utility function) payout a player receives according to the outcome of the game.

Let us present rationality in a more formal way. Each player of a game has some strategies to choose from and every combination of choices of each player results in a possible outcome of the game.

The very first assumption characterizing game theory is the fact that each player is able to order the outcomes of the game according to consistent preferences. That is, players can observe all possible strategy combinations, they have preferences on the outcomes resulting from these combinations and they are able to order these preferences. These concepts can be translated in mathematical form with 2.2. RATIONALITY OF THE AGENTS a function defined as follows.

Definition 2.1 (Utility function) A utility function is a real valued function u : X i → R defined on the set of alternatives X i of player i fulfilling the property that u

(A) ≥ u(B) (u(A) > u(B)) if the alternative A is preferred (strictly preferred) to alternative B.
It is important to notice that the utility function u depends from the behaviors of all players i.e., their strategy choices.

The second concept characterizing game theory is the fact that players are fully able to analyze the problem (i.e., the game) and take the right decisions. This fundamental assumption states that players are able to to make a full and deep analysis of the game, on other players' preferences and on the consequences of their choices. Players have then a global vision of the problem i.e., they know the involved players, the strategies they have , their preferences and the moment when they are called to make a decision.

NON-COOPERATIVE GAMES

Non-cooperative Games

Following the steps that gave birth to game theory, we start addressing non-cooperative game where players do not cooperate and make individual choices within a game.

Game Representation

Finite n-players games can be represented with a tree that provide information on the initial setting, all possible evaluations and all final outcomes of the game. This representation enables representing a set of players which act in sequence. Formally, the theoretical concept which models this situation is the extensive form game [START_REF] Kuhn | Contributions to the Theory of Games[END_REF].

Definition 2.2 (extensive form game) An extensive form game with perfect information is a tuple

Γ = ⟨N, T, P, (A h ) h∈V , (u i ) i∈N ⟩
, where :

• N is the set of players.

• T = (V, E) is a directed rooted tree.

• Z ⊂ V is the set of terminal nodes.

• P : V \ Z → N is a function assigning to each non-end node a player in N . The function P identifies at which nodes a player acts.

• A h = {(x h , x i ) ∈ E} for each node h ∈ V \ Z is the set of edges going from node h to some other nodes and represents the set of actions at node h of the tree T .

• Ω i = {s i : V \ Z → A 1 × A 2 × . . . A h × • • • × A H , h : P (h) = i}
is the set of pure strategies of player i. Every pure strategy of player i is a function that assigns an action a ∈ A h to every node h ∈ V \ Z in which player i is involved (formally, h : P (h) = i).

• S i = {σ i : Ω i → [0, 1], ∑ s∈Ω i σ i (s) = 1}
is the set of mixed strategies of player i. A mixed strategy is a probability distribution over the set of pure strategies of player i.

• u i : Z → R is the utility function for player i ∈ N . A set of strategies S i is available to every player i in the game. Supposing that every player picks a strategy σ i ∈ S i ; then it is possible to compute the utility for a player i, u i (σ 1 , σ 2 , . . . , σ n ), which is the i-th component of the utility function u. Since players are rational agents, their goal is to maximize their utility by choosing their own strategy. Usually there is no strategy that allows every player to maximize their utility, therefore we have to consider strategy profiles σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S.

Each player i chooses a strategy σ i and the outcome u(σ) may please every player so that they do not want to change their strategy. The following section introduces solution concepts of a game i.e., strategy profiles with different properties.

Solution and Equilibria

A solution concept is a strategy profile that described the dynamic and the result (i.e., the final outcome) of the game. Von Neumann and Morgenstern [START_REF] Neumann | Theory of games and economic behavior[END_REF] further characterized the concept of rationality by providing an additional assumption ; the elimination of dominated strategies. This assumption provides a method to solve a game identifying its final outcome as well as its strategy profile. Elimination of dominated strategies assumes that, independently from the choice the other players make, a player does not choose alternative A, if B is available to her allowing her to get more.

By iterating the process of eliminating dominated strategies, a game in normal form can be solved.

If a strictly dominant strategy exists for one player in a game, that player will play that strategy. If both players have a strictly dominant strategy, the game has only one unique equilibrium known as Nash equilibrium. Definition 2.4 (Nash equilibrium) A strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is a Nash equilibrium if for every player i and for every τ i ∈ S i we have that :

u i (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ≥ u i (σ 1 , σ 2 , . . . , τ i , . . . , σ n )
The definition of Nash equilibrium is based on the concept of best response, i.e., the strategy σ i that maximizes the utility of a player i, given the strategies of the other players σ -i . In a Nash equilibrium no player has an incentive to unilaterally change its strategy since utilities do not increase. Nash [START_REF] Nash | Equilibrium points in n-person games[END_REF] proves that every game in normal form admits at least one Nash equilibrium. Nash equilibria are reasonable solution concepts since they represent a scenario in which nobody is tempted to unilaterally change her own strategy. However, the set of Nash equilibria is not always a singleton, it might happen indeed that there is more than one equilibrium. Here below some properties of Nash equilibria are introduced.

Definition 2.5 (strong Nash equilibrium [START_REF] Bernheim | Coalition-proof nash equilibria i. concepts[END_REF]) A Nash equilibrium σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is said to be strong if and only if for all C ⊆ N and all τ C ∈ S C , there exists i ∈ C such that

u i (σ C , σ -C ) ≥ u i (τ C , σ -C ). 91 2.

NON-COOPERATIVE GAMES

In [START_REF] Bernheim | Coalition-proof nash equilibria i. concepts[END_REF] the authors prove that the outcome of every strong Nash equilibrium is Pareto efficient i.e., no player can improve her outcome without reducing the outcome of another players. Strong Nash equilibria are easy to be identified, but they do not always exist. Definition 2.6 (stable Nash equilibrium [START_REF] Hillas | On the definition of the strategic stability of equilibria[END_REF]) A Nash equilibrium σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is said to be stable if it belongs to the set S which is minimal with respect to the following property : for every ϵ > 0 there exists δ > 0 such that any upper-hemicontinuous compact convex valued correspondence pointwise within Hausdorff distance δ of the best response correspondence of Γ has a fixed point within ϵ of S.

The concept of stable equilibria was introduced in [START_REF] Kohlberg | On the strategic stability of equilibria[END_REF] in order to exclude less meaningful Nash equilibria i.e., those equilibria that are less resilient against small changes. After [START_REF] Kohlberg | On the strategic stability of equilibria[END_REF], several other definitions of stability were introduced. We cite the definition provided in [START_REF] Hillas | On the definition of the strategic stability of equilibria[END_REF], which fulfills some useful properties. One of these states that there always exists a stable Nash equilibrium. Moreover, stable Nash equilibria survive after the iterated deletion of weakly dominated strategies, i.e., those strategies σ i ∈ S i that perform as well as or worse than another strategy σ ′ i ∈ S i no matter which strategy the other players choose (formally, we have that u i (σ i , τ -i ) ≤ u i (σ ′ i , τ -i ) for all τ -i ∈ S -i ). In the process of iterated deletion [START_REF] Osborne | A course in game theory[END_REF] weakly dominated strategies are excluded from the set of strategies available to players and the set of Nash equilibria is recomputed.

A Nash equilibrium of an extensive form game is a Nash equilibrium of the associated normal form game. A subgame of an extensive form game (with perfect information) on node v ∈ V \ Z is another extensive form game (with perfect information) obtained as a part of the directed tree starting at the decision node v. A subgame perfect equilibrium is a strategy profile that induces a Nash equilibrium on any subgame. For more details see, for instance, the book [START_REF] Peters | Game theory : A Multi-leveled approach[END_REF].

Extensive form games can be represented in normal form and solved with the principle of elimination of dominated strategies, however an alternative method exists and is known as backward induction. It consists of reasoning backwards in time, from the end of a problem (represented by the end node) till the beginning (the first/root node).It proceeds by examining the last decision step, identifying what action would be most optimal at that moment and iterating the procedure. Note that both solving principles, elimination of dominated strategies and backward induction, are used to solve games and find Nash equilibria in Chapter 4.

COOPERATIVE GAMES

Cooperative Games

In order to characterize cooperative game theory it is crucial to identify a set of players and to define a characteristic function for games. We denote by N a finite set of players. Any subset S of N is said a coalition. The cardinalities of N and S are denoted by n and s, respectively while 2 N denotes the set of all possible coalitions. The value v(S) represents in general something that can be shared among agents in the coalition.

Whenever amount v(S) can be freely divided among the members of S, in any way we have that the game (N, v) is a Transferable Utility (TU) game.

The question now is : how is this value shared ?. In our work, the following chapters are devoted to find the answer to the question : how is this bitcoin reward shared among pools' participants ?

Solution, Imputation and Core

Given the definition of cooperative game, it is now the time to introduce the idea of solution. Given a game (N, v) a solution is a vector (x 1 , ..., x n ) where x i represents the amount assigned to the player i. Moreover given a game (N, v) a set of solution vectors is a solution concept.

As we can see, there are several solution concepts for cooperative games. This can be explained with the fact that cooperative model is complex and can fit several situations. Therefore, it is not possible to define a solution concept providing a reasonable outcome for all the situations that a game 93 2.4. COOPERATIVE GAMES can model. That is the reason why some requirements have to be asked. There are three minimal conditions that are common to all the solution concepts :

1. x i ≥ v(i) ∀i 2. ∑ n i=1 x i ≤ v(N ) (feasibility) 3. ∑ n i=1 x i ≥ v(N ) (efficiency).
The first condition has a simple meaning : the output of the game must give to each player not less than what he/she can get by its own. The second condition establishes that the amount distributed among players cannot be more than the available one, while the third inequality is an efficiency condition, since the whole amount v(N ) has to be distributed. All the solutions satisfying these important constraints are called imputations. Definition 2.9 (Imputation) Given a cooperative game (N, v), we call imputation any vector x fulfilling condition (1) and condition (2) presented above.

We can denote this set of reasonable solutions by I(v). Let us now consider a subsets of I(v).

Definition 2.10 (The Core) Let v : 2 N → R be a TU game. The core of the game, denoted by C(v), is the set :

C(v) = { x ∈ R n : ∑ i∈N x i = v(N ) ∧ ∑ i∈S x i ≥ v(S), ∀S ⊂ N } .
The idea behind the definition of the core is to enforce condition (1) which guarantees that players do not object since they do not get less than what they can get alone. Imputations are feasible solutions rejected neither by the single players nor by the grand coalition N . Imputations in the core are not rejected by any coalition. Therefore, C(v) is an imputation set without all the imputations that are rejected by at least one coalition. The core is a meaningful concept since it provides a set of efficient, feasible and stable solutions. Each coalition with associated payoffs in the core receives at least what it deserves, therefore no subset of players have any incentive in leaving the grand coalition. In Definition 5.19 it is the following inequality

∑ i∈S x i ≥ v(S), ∀S ⊂ N
which represents a stability concept guaranteeing that agents with offered payoffs in the core stay in the grand coalition and cooperate together.

BANKRUPTCY GAMES

Bankruptcy Games

A bankruptcy situation arises whenever there are some agents claiming a certain amount of a divisible estate, and the sum of the claims is larger than the estate. Let N = {1, . . . , n} be a set of agents. Formally, a bankruptcy situation on the set N consists of a pair (c,

E) ∈ R N × R with c i ≥ 0 for all i ∈ N and 0 < E < ∑ i∈N c i = C.
The vector c represents agents' demands (each agent i ∈ N claims a quantity c i ) and E is the estate that has to be divided among agents (and it is not enough to satisfy the total demand C).

Denoting by B N the class of all bankruptcy problems (c, E) ∈ R N × R with 0 < E < ∑ i∈N c i and N as a set of agents. A solution (also called allocation rule) for bankruptcy situations on N consists of a map f : B N → R N assigning to each bankruptcy situation in B N an allocation vector in R N , which specifies the amount f i (c, E) ∈ R of estates E that each player i ∈ N receives in situation (c, E). A solution must satisfy a minimal set of "natural" requirements : We now introduce three well-studied solutions for bankruptcy situations (see, for instance, [242; 241; 251]). The first one is the Proportional rule.

-f i (c, E) ≥ 0 ∀i ∈ N (Individual
∑ i∈N min{c i , λ} = E.
The CEA rule consists of giving to every agent the same amount until the agent's demand is not completely satisfied and the estate is not finished.

CEA(c, E) = ( 7 2 , 7 2 , 3 )
.

The last division rule we consider, i.e. the Constrained Equal Losses rule, is an alternative to the CEA rule which focuses on the losses in which claimants incur. More precisely, instead of equating awards this rule equates losses.

Definition 2.13 (Constrained equal losses rule (CEL)) For each bankruptcy situation (c, E) ∈ B N , the constrained equal losses rule is defined as CEL i (c, E) = max{c i -λ ′ , 0} where the parameter λ ′ is such that unit is assigned to each player : x = (3, 4, 2). Then, it is easy to check that λ ′ = 1 3 and therefore, we have (4, 5, 3) -1 3 = ( 10 3 , 13 3 , 7 3 ). So,

∑ i∈N max{c i -λ ′ , 0} = E.
CEL(c, E) = ( 10 3 , 13 3 , 7 3
) .

Bankruptcy Games : Game theoretical Division Rules

Bankruptcy problems are not necessarily bankruptcy games, they can be solved without using game

v p (S) = max ( 0, E - ∑ i∈N \S c i )
Bankruptcy problems can be represented as cooperative games with pessimistic characteristic functions. At this point, it is natural to ask : what about division rules associated to this type of games ?

Authors in [START_REF] Curiel | Bankruptcy games[END_REF] proposed a necessary and sufficient condition for a division rule to be a game theoretical division rule : We have two different outcomes for the problems :

CEL(c, E) = (0.5, 9.5), CEL(c T , E) = (1, 9).
Concerning the constrained equal awards rule, it is immediate to see that it is a game theoretical division rule by simply using the rule's definition :

CEA i (c T , E) = min{c i , E, λ} = min{c i , λ} = CEA i (c, E) since λ ∈ [0, c n ] : λ ≤ E.

BANKRUPTCY GAMES

Another interesting consideration on the solutions of bankruptcy problems is the fact that the core of the associated pessimistic games coincides with the the set of admissible solutions.

Proposition 2.1 Given a bankruptcy problem (c, E) ∈ B N and its associated pessimistic cooperative game v p(C,E) , calling x the outcome of the problem/game we have that

x ∈ C(v p )⇐⇒ ∑ i∈N x i = E and 0 ≤ x i ≤ c i , ∀i ∈ N Proof.
Concerning the only if part, the first condition is efficiency. For the second one we get ∀i ∈

N, x i ≥ v p (i) ≥ 0 and E -x i = ∑ j∈N \{i} x j ≥ v p (N \ {i}) ≥ E -c i which implies x i ≤ c i .
In order to prove the if part let us notice that efficiency condition is satisfied.

This theorem states that every game theoretical division rule of bankruptcy problems provides allocations which are in the core of the associated cooperative games. Therefore given a bankruptcy game (c, E), the constrained equal awards rule provides an outcome contained in the set C(v (c,E) ) as

∀S ⊆ N we have two cases : v p (S) = 0 ≤ ∑ i∈S x i and v p (S) = E - ∑ i∈N \S c i ≤ E - ∑ i∈N \S x i ≤ ∑ i∈S x i .

Bankruptcy Rules' Properties

Following the presentation in [START_REF] Herrero | The three musketeers : four classical solutions to bankruptcy problems[END_REF], we now focus on some properties from the literature that are satisfied from the three previously introduced solutions, and that will be relevant for the discussion about Bitcoin systems in the next section. The first property consists of a basic equity requirement stating that players with identical claims are identical for the allocation rule. More precisely, agents with the same demands are treated identically in the sense that they receive the same fraction of the estate.

Property 2.1 (Equal treatment of equals) For all (c, E) ∈ B N and all i, j ∈ N we have that

c i = c j implies f i (c, E) = f j (c, E).
The second property requires that an allocation rules is invariant to scale change, so it does not depend on the units in which problems' demands and estate are expressed.

BANKRUPTCY GAMES

Property 2.2 (Scale invariance) For all (c, E) ∈ B N and all γ > 0 we have :

f (γc, γE) = γf (c, E).
The next property refers to a situation where the population of agents may change. This property considers the case in which after providing an allocation vector according to a solution applied to the original situation (c, E) ∈ B N , a group of agents S ⊂ N forms and re-apply the solution on the reduced situation (c S ,

∑ i∈S f i (c, E)) ∈ B S
, where c S = (c i ) i∈S and the new estate is

∑ i∈S f i (c, E).
This property states that a solution applied to any reduced problem should provide to agents in S the same output as in the original situation.

Property 2.3 (Consistency) For all S ⊂ N , all (c, E, N ) ∈ B and all i ∈ S we have :

f i (c, E, N ) = f i (c S , ∑ i∈S f i (c, E, N ), S).
The following two properties characterise the allocation priorities of an allocation rule. Exemption establishes that when claims are smaller than the equal division the rule has to first satisfy them and therefore cut larger claims.

Property 2.4 (Exemption) For all (c, E) ∈ B N if c i ≤ E/n then f i (c, E) = c i .
Exclusion gives an opposite message, since it excludes from the problem those agents with very low claims.

Property 2.5 (Exclusion) For all (c, E) ∈ B N if c i ≤ L/n where L = ∑ n i=1 c i -E then f i (c, E) = 0.
The next property deals with the possibility that a group of agents may aggregate their demands and appear as a single claimant, or that a single agent may split her demand to represent several claimants. If these behaviors are not beneficial for the agents, we say that a solution satisfies no advantageous merging or splitting.

(c ′ , E ′ ) ∈ B N ′ be such that N ′ ⊂ N , E = E ′ and suppose there is an agent i ∈ N ′ such that c ′ i = c i + ∑ j∈N \N ′ c j and c ′ j = c j for each j ∈ N ′ \ {i}, then f i (c ′ , E ′ ) = f i (c, E) + ∑ j∈N \N ′ f j (c, E).
i ∈ N ′ such that c ′ i = c i + ∑ j∈N \N ′ c j and c ′ j = c j for each j ∈ N ′ \ {i}, then f i (c ′ , E ′ ) ≤ f i (c, E) + ∑ j∈N \N ′ f j (c, E). Property 2.8 (No advantageous splitting) Let (c, E) ∈ B N and (c ′ , E ′ ) ∈ B N ′ be such that N ′ ⊂ N , E = E ′ and suppose there is and agent i ∈ N ′ such that c ′ i = c i + ∑ j∈N \N ′ c j and c ′ j = c j for each j ∈ N ′ \ {i}, then f i (c ′ , E ′ ) ≥ f i (c, E) + ∑ j∈N \N ′ f j (c, E).
According to Property 2.7 no group of agents has an incentive to aggregate their demands and to be treated as a single agent whose claim is the sum of the individual demands of their participants.

Conversely, Property 2.8 says that no agent has an incentive to divide his/her demand to represent several claimants whose demands add up to her/his original claim. Solutions introduced in this section satisfy alternative sets of properties, as reported in Table 2.1 (for more details on these results see, [START_REF] Herrero | The three musketeers : four classical solutions to bankruptcy problems[END_REF]). This chapter models and analyzes the behaviors of a particular type of validating nodes operating on a specific DLT i.e., Bitcoin miners. Miners who operate validating tasks in the Bitcoin blockchain are modeled as rational agents who may or may not behave maliciously (i.e., perform an attack) in certain situations. The situation we present in this chapter is the process of remunerating miners for their validating work. Two types of malicious behaviors are analyzed ; pool-hopping and block-withholding. The first part of the chapter is devoted to describing and assessing the pool-hopping phenomenon while in the second part block-withholding miners are modeled as players of a bankruptcy game. The content of the chapter originates from [START_REF] Belotti | Bitcoin pool-hopping detection[END_REF] and [START_REF] Belotti | Rewarding miners : bankruptcy situations and pooling strategies[END_REF].

Properties

INTRODUCTION TO REWARDING MINERS

Introduction to Rewarding Miners

As presented in Chapter 1 (Section 1.3), blockchain transactions are collected in blocks, validated and published on the distributed ledger. Nakamoto [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF] proposed a Proof-of-Work system based on Back's Hashcash algorithm [START_REF] Back | Hashcash -a denial of service counter-measure[END_REF] that validates blocks and chains them one to another. Let us recollect that the Proof-of-Work system requires finding an input of a predefined one-way function (e.g., hash function) generating an output that meets the difficulty target. More precisely, the goal for the block validators (miners) is to find a numerical value (nonce) that added to an input data string and "hashed" gives an output which is lower than the predefined threshold. A miner who finds a full solution (i.e., a nonce meeting the difficulty target) broadcasts it across the network.

Miners compete to be the first to find a full solution in order to publish the block and gain a reward, denoted with B, consisting in new minted crypto-currencies. The Bitcoin monetary policy establishes the reward amount one receives once it validates a block (6.25 BTC, valid until the next halving scheduled for 2024 when the block mining reward is decreasing to 3.125 BTC) -noting that a block can contain more than 2000 transactions, while respecting the block size limit of 1 MB. Mining is a competitive crypto puzzle (a mining race) that participants try to solve as fast as possible. The difficulty D of the crypto puzzle limits the rate at which new transaction blocks are generated by the blockchain (e.g., it takes approximately 10 minutes to find a full solution in the Bitcoin network). This difficulty value is adjusted periodically in order to meet the established validation rate. At the time of writing, in order to validate a block in the Bitcoin blockchain, miners needs to generate (on average) a number D = 20.1T of hashes1 .

Mining is a procedure through which miners can gain a substantial amount of money. Nowadays, due to the high difficulty values, solo miners (i.e., miners who work alone with a personal device) find a full solution with a time variance range of billions of years. Small miners survive in this new industry by joining mining pools. A mining pool is a cooperative approach in which multiple miners share their efforts (i.e., their computational power) in order to validate blocks and gain rewards. Once a full solution is found, pool's reward is split among the miners. In this way small miners, instead of waiting for years to be rewarded, gain a fraction of the reward on a regular basis.

Miners' reward is based on their contribution in finding a full solution. In order to give proof of their

INTRODUCTION TO REWARDING MINERS

work, miners submit to the pool partial solutions, i.e., nonces that do not meet the original threshold, but a higher one. The solutions of this easier crypto puzzle are considered "near to valid" solutions and called shares. For those blockchains that adopt a SHA-256 function, every hash value (i.e., output of the hash function) is a full solution with probability 1 2 32 D , and each hash has a probability of 1 2 32 to be a share. Hence, a share is a full solution with probability p := 1 D .

Miners are rewarded according to the number of shares that they provide. Whenever a share is also a full-solution a block is validated and the pool gains a reward that is split among pool participants according to the number of shares that they have reported. Mining pools are managed by a pool manager that establishes the way in which miners should be rewarded. Each pool adopts its own rewarding system.

There exist several rewarding approaches that can be more or less attractive to miners (see [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF]).

These rewarding methods have to meet certain requirements in order to guarantee the proper functioning of the ecosystem. Since the aim of forming pools is to share efforts and rewards thus, participants should be rewarded in a fair manner with respect to their contribution to the pool, i.e., proportionally to the hashing power invested in the pool. Original simple rewarding methods met this fairness criterion at the expense of vulnerability to some miners strategic behaviors.

Mining pool attacks.

An attack to a mining pool refers to any miner's behavior which differs from the default practice (the honest one) and that jeopardizes the collective welfare of the pool. Rosenfeld provided in [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] an overview of the possible malicious behaviors regarding pools whose profitability depends on their own rewarding mechanism. Miners attack a mining pool in order to obtain a higher reward i.e, miners behave as rational agents whose decisions are driven by the expected gain.

Miners may attack their pool at the time of reporting their Proof-of-Work. More precisely they can (i) delay in reporting a share (i.e., block-withholding) and/or (ii) report a share elsewhere (i.e., pool-hopping). The former is a practice consisting in delaying in reporting shares and full solutions to a mining pool. This practice implies delaying a block validation and the consequent possession of the reward, that in some cases may be profitable for attackers. Pool-hopping is an attack where miners "hop" from a pool to another one according to pools' attractiveness.

INTRODUCTION TO REWARDING MINERS

Related works and contributions.

The problem for a pool manager is to establish how to redistribute the rewards among pool participants in order to prevent malicious behaviors (as the ones listed above). In other words, the pool manager must choose an "appropriate" rewarding mechanism preventing (possibly, all) different types of attacks.

Concerning the block-withholding practice, Schrivers et al. [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] make use of non-cooperative game theory to propose a rewarding mechanism (denoted as incentive compatible) that prevents this attack. This specific rewarding system is robust against malicious actions operated inside a pool, however it does not behave as well in an inter-pool environment since it cannot prevent pool-hopping. In this case, Rosenfeld [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] shows that malicious miners can gain at the expenses of the honest ones, who receive a lower reward than the expected one. In [START_REF] Lewenberg | Bitcoin mining pools : A cooperative game theoretic analysis[END_REF] the authors use cooperative games to prove that pool-hopping is not preventable, thus mining pools are not stable coalitions.

The first part of this chapter, Section 3.2, presents the methodology designed to analyze the poolhopping phenomenon, focusing on the detection of pool-hoppers. By analyzing those Bitcoin transactions that pools create for rewarding its participants, it is possible to determine time epochs where miners worked. Thus, we can identify those miners who have worked intermittently for pools adopting a rewarding system which pays out for each validated block. This evaluation leads us qualifying the miners who have hopped along with their hopping behavior and financial performance.

In the second part of the chapter, Section 3.3, starting from the model in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], we propose an alternative incentive compatible rewarding mechanism discouraging the pool-hopping practice. We model and analyze with game theory the rewarding problem by reinterpreting the reward function in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] as an outcome of a bankruptcy game. Then, we construct, analyze and test a new rewarding mechanism adoptable by pools to remunerate contributing miners.

POOL-HOPPING AND REWARDING STRATEGIES

Pool-hopping and Rewarding Strategies

Bitcoin public nature provides us with both generation transactions [START_REF] Antonopoulos | Mastering Bitcoin, unlocking digital cryptocurrencies[END_REF] and transactions used by pools to remunerate their participants. The first are those transactions by means of which new bitcoins are generated and issued in the system. The second are the so called "rewarding transactions" which are transferring the funds received through the generation process to pool participants in a chain of ownership, i.e., new minted bitcoins are transferred from pools' addresses (input) to miners' ones (output) in the form of Unspent Transaction Output, UTXO (see Section 1.6). Proper analysis of the public ledger can reveal a lot of information on the network users. Deanonymization techniques applied on a selected set of users do contribute in enhancing the quality of the extracted information. In our analysis, the Bitcoin actors we are interested in are the ones involved in the rewarding transactions, i.e., pools and miners, remunerated according to pools policies ; the first step of our work is determining the related user network [START_REF] Koshy | An analysis of anonymity in bitcoin using p2p network traffic[END_REF].

Rewarding methods with direct correspondences between block validation and miners' payout do help in hoppers detection. Through a targeted analysis of the transactions ledger, it is possible to place a miner -intent on working for a pool -within a time interval denoted as epoch. This time period is nothing more than an estimate of a miner's working time for a given pool. Hoppers detection consists in comparing miners' epochs in different pools. All the actors in a pool have full knowledge of the internal mining activities carried out over time, which is not the case for any user external to pool. Once pool-hoppers have been identified among all the miners interacting with multiple pools, it is possible to describe the hopping evolution over time.

Rewarding Methods

Rewarding methods [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] generally pay out according to a division into rounds, where a round is the time elapsed between two different block validations performed by the same pool. Thus, pool distributes the block reward among miners at round end, in proportion to their contribution within the round. Some methods replace such a round-based remuneration opting for the attribution of a score to each share. Score-based methods register the time of a share submission, assign a value to the share according to a scoring function and remunerate the submitter correspondingly. Thus, rewards calculation is no more linked to the concept of round but it is based on the scoring systems in use. 107

POOL-HOPPING AND REWARDING STRATEGIES

However, payouts are still executed on a round basis.

Besides rewarding fairness, score-based methods also offer pool-hopping resistance. Meni Rosenfeld analyzes in [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] several score-based rewarding systems. We briefly present in the following the two most popular methods of this type in use in 20172 :

-Pay-Per-Last-N-Shares (PPLNS) method [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF]. It represents an allocation rule rewarding miners for their recently submitted shares -eventually computed at different rounds. The block reward B, instead of being distributed only among actual round participants, can also be assigned to those miners who have submitted shares in a previous round. Then, for short actual rounds, the rewarding calculation may consider also shares submitted in previous rounds. Note that, with the PPLNS system it can happen that some submitted shares may not be considered for the reward calculation (i.e., shares in long actual rounds). N varies with the difficulty parameter D ;

it can be up to twice D (rounded down to integer), as an upper-bound threshold. More accurate implementations tend to set N < 2D ; e.g., the author in [START_REF]Analysis of hashrate-based double spending[END_REF] proposes to score shares as the inverse of D, and determines N as a given portion of the score, hence N ≤ D.

-Slush method. Slush pool [258] has been the first mining pool developing a rewarding method aimed at combating pool-hopping. Block rewards are divided in proportion to the score miners obtained with their reported share(s) in the rounds. Slush's scoring system dynamically calculates a score for a specified share according to its submission time. More precisely, the score at time t 0 for a share s submitted at time t s is given by : score(s, t 0 ) = exp

( t s -t 0 Λ ) (3.1)
where Λ is a constant value representing the speed at which the score decreases over time. An exponentially decreasing scoring is well suited due to its invariance to time shift.

Pool-Hopping

Pool-hopping is a strategic behavior influenced by the attractiveness of mining in terms of expected payoffs [259]. In other words, pool-hopping consists in mining for a pool only when its attractiveness is high and leaving it when it is not (i.e., directing computing power towards another pool).

POOL-HOPPING AND REWARDING STRATEGIES

Meni Rosenfeld shows in [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] that pools using proportional systems encourage this practice in the sense that pool-hopping results more profitable than mining continuously. Since for proportional methods each share is paid out according to the total number of submitted shares in the round, the longer is the round the less is the reward per share. Each share payoff corresponds to B S , where S is the total number of shares submitted to the pool during a round. Thus, submitting shares to a pool as long as the rounds are short and then hopping elsewhere results in a higher gain than the fair share [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF]. What makes this practice, known as early mining, feasible is the miners' knowledge of the round start time and the number of shares taken into account for the reward calculation. PPLNS and Slush methods propose scoring functions that do not encourage early mining practice, thus the pools are preventing hopping behaviors on round length basis.

However, as the Slush score is a function of the time elapsed since a share submission, pools' attractiveness is eventually affected by the hash-rate fluctuations over time. Pools' hashing power directly influences the number of shares found and the round length. In addition, both PPLNS and Slush systems' 'hoppability' is affected by difficulty (D) and reward (B) adjustments. Therefore, advanced pool-hopping strategies are possible for both Slush and basic PPLNS implementations.

Nevertheless, the two methods present different levels of hoppability as described in [START_REF]Analysis of hashrate-based double spending[END_REF].

User Sub-network Inference Process

Bitcoin transactions move funds from one or more 'inputs' to one or more 'outputs' containing all the references of previous and next owners. Users receive bitcoins in the form of unspent transaction output (UTXO) in their addresses, i.e., strings identifying sources and destinations for bitcoin payments. In order to be spent, funds contained in the output of a transaction must turn into the input of a new one. Inputs and outputs must match in the sense that the entire value of the previous transaction(s) has to be transferred. Thus, whenever a user aims at sending an amount lower than the UTXO value, a second output containing a changing address is added. That is, a bitcoin address held by the sender appears as an output with the purpose of transferring funds back.

Coinbase, rewarding and transferring transactions

Each transactions block contains a generation transaction remunerating the pool or the miner who validates it. These type of transactions does not specify any previous UTXO to spend, its input field (denoted as coinbase) contains arbitrary data ; generation transactions, also known as coinbase transactions, provide funds that cannot be spent for at least 100 confirmed blocks. Due to this requirement, Bitcoin system rewards only for valid blocks in the longest chain (i.e., the longest blockchain branch).

While mining pools are financed by coinbase transactions, miners are remunerated through ordinary transactions we denote as rewarding transactions. Ideally, they should transfer the coinbase UTXO, however this is not always the case. Some pools use additional transactions -we refer to as transferring transactions -that move funds to specified addresses within the pool, which reward miners later on.

All these transactions are publicly readable from the blockchain ledger and can be easily gathered through Bitcoin-Core [260]. This information leads to construct the transaction sub-network [START_REF] Koshy | An analysis of anonymity in bitcoin using p2p network traffic[END_REF] representing the flow of bitcoins between a specific subset of transactions -of coinbase, rewarding and transferring types -over time. Fig. 3.1 example shows pool-miners interactions where coinbase transactions are inputs of transferring transactions whose outputs consist in rewarding ones. Arrows represent the funds flow.

The topology of Fig. 3.1 example synthesizes a generic view of the Bitcoin network, where one may detect the relationships between various input and output addresses. For coinbase, rewarding and transferring transactions, the addresses involved certainly belong to pools and miners however, it is not known to which user they belong exactly since each of them can have multiple addresses. Moreover, it is considered a good practice for confidentiality to generate and use new addresses for each operation on the network. As hoppers detection requires the analysis of the interactions among Bitcoin specific users, it is necessary to map each bitcoin actor with its associated addresses.

Address-User Mapping Procedure

The address-user mapping problem can be solved using two basic heuristics introduced in [START_REF] Reid | An analysis of anonymity in the bitcoin system[END_REF], which derive from the expert knowledge of Bitcoin protocols and common practices. The mapping procedure we use is based on the concatenated application of the two heuristics. The first heuristic, addressing transaction inputs only, exploits the concept of multi-input transactions : it assumes that all the inputs in a transaction belong to the same bitcoin user. This heuristic results reasonable in its simplicity since (i) different users likely very rarely collaborate in a single transaction, and (ii) very often it happens that users move funds from their multiple addresses to one or multiple deposit accounts. The second heuristic deals with changing addresses : it associates input addresses with output ones when they result to be completely new (i.e., they never appeared in the blockchain before).

Therefore, applying the mapping procedure one can derive the user sub-network from the address sub-network. The relationship between addresses can be easily inferred from the transactions subnetwork ; Fig. 3.2 shows the address sub-network corresponding to the Fig. 3.1 example. Once the address sub-network is derived, addresses are associated with their users following the two heuristics ; Fig. 3.3 shows an instance of user sub-network for the given example.

It is not possible to obtain a perfectly true user sub-network, since heuristics are not perfect and addresses do not contain any information about their owners. In order to maximize the precision, due to the limited number of coinbase, transferring and rewarding transactions with respect to the overall volume of transactions, we have applied the mapping procedure to the entire transaction network (including ordinary transactions as well). Doing so, we can provide an accurate representation of miners and pools interactions, since we are associating with these specific users the highest possible number of employed addresses. The application of such deanonymization techniques for the mapping allows us building an interaction network between pools and miners. Pool-hopping consists in mining for two or more pools during a round, thus hoppers submitting shares to multiple pools are remunerated accordingly by multiple pools. Hoppers detection requires the analysis of those miners who are connected to several pools.

Hoppers Detection

The previous section provides us with those network pre-processing steps for detecting poolhoppers. From the constructed user sub-network it is possible to select those miners who are remunerated from multiple pools. In order to determine whether a miner who submits shares to more than one pool is really implementing a hopping strategy, it is necessary to focus on its rewarding transactions. Our analysis addresses those pools adopting rewarding methods which are paying out miners on a round basis and assumes that :

-Miners' pay-outs are entirely originated by coinbase transactions3 and, -Each reward is originated by a single coinbase transaction4 .

Simplistic Case

For pools using per-round rewarding systems, rewarding transactions should be ideally linked to the corresponding rounds they are paying for. This link could be found in their inputs, namely in the coinbase transactions providing pools with the rewards that have to be redistributed. It would then be possible, by analyzing the rewarding transactions, to place a miner in a certain round. In Fig. 3.4 we show how to identify miners' working period : a miner rewarded at time A is associated with the corresponding round of pool A that is marked in yellow. Then, considering multiple pools and their rounds, it would be enough to check if the same miner is present in two overlapping rounds of different pools. The procedure results quite trivial once pools' rewarding transactions are ordered according to their corresponding rounds, that is, in accordance with the corresponding coinbase transactions.

In a 2-pool case, if the same miner is present in two consecutive (ordered) rewarding transactions belonging one to a pool and one to another one, we can declare it as a hopper. There may be doubtful situations whenever the same miner is found in two rewarding transactions of different pools which are not directly consecutive (i.e., after ordering we could have two transactions created by pool A, one created by pool B and the same miner present in the first and third transaction). In this cases it is mandatory to analyze the rounds length to establish if the miner adopted or not a hooping strategy.

Realistic Case

In reality, pools do not associate exactly a paying transaction to each round. Miners receive their payouts once they cross a predefined sending threshold (Slush pool adopts a threshold of 0.001 BTC [258]). This means that in reality pools pay for miners' work on multiple rounds with a single rewarding transaction. In Fig. 3.5 pool A is rewarding a miner for its work in two rounds.

Rewarding transactions no longer use the reward provided by a single coinbase but they have several generation transactions as inputs. In this way, it is no longer possible to place a miner in its working round.

Miners paid out with the rewarding transactions can be placed within a time interval that we The idea is always to check if a miner is present in two overlapping time periods, however it can be defined as a hopper with a certain probability depending on epochs' length. As for the ideal case, transaction ordering should simplify the detection procedure. Rewarding transactions can be sorted by membership blocks, that is, ordering procedure refers to the coinbase transactions corresponding to epoch ends. For the 2-pool case in which a miner is found in two consecutive rewarding transactions with different creators, we can conclude with any doubt that the miner is a pool-hopper. This is due to epoch definition, since it ends with that round in which miners submitted the number of shares necessary to reach the threshold value. Hence, there is the certainty of miners' presence in the epochs' final rounds.

By considering only consecutive transactions, other cases where hopping is possible are overlooked.

First of all, this approach detect only hoppers in epochs' final rounds without considering the other 3.2. POOL-HOPPING AND REWARDING STRATEGIES rounds within them. Moreover, as in the simplistic case, we can have hoppers paid out in two rewarding transactions that are not adjacent. Epochs length could help us in detecting miners who are likely to hop, thus in this cases we are talking about potential hoppers. Potential hopping is formalized in the following paragraphs but not considered in the measurement results as left for future works.

How can we establish the hopping probability for a potential hopper ? Evidently it depends on the number of overlapping rounds that the epochs in question contains and on their lengths. Pool operator's point of view. The case in which a user can easily define the hopping probability for a potential hopper is the one in which he is a pool manager. Let us suppose that a pool operator aims at detecting among the miners who are working for him those who are hopping to a second pool adopting a score-based rewarding method paying out on a round basis (i.e. ; Slush or PPLNS). This manager can precisely position his miners in his pool's round history. Moreover, through a proper analysis on the transaction network he can derive a miner sub-network and subsequently can place this entities within epochs. Whenever the operator finds one of his workers in an epoch that overlaps with his pool's rounds, he can compute the hopping probability for his miner. Given a miner m who works for the pool manager in the rounds r p 1 I where I ⊂ [1, ∞) and who is present in a time epoch E ⊂ [1, ∞) of a second pool with length l = ∑ i∈E r p 2 i his hopping probability would be the following :

P(m is an hopper) = ∑ i∈E∩I r p 2 i l .
External user's point of view. Hopping probability in this case may be defined for two pools using PPLNS or Slush method. Potential hopper is any miner found in two overlapping epochs. However, those potential hoppers presenting in two consecutive rewarding transactions created by two different pools can be defined as real hoppers. For those potential hoppers who can be found in not directly consecutive transactions the hopping probability can be defined as follows :

P(m is an hopper) = ∑ i∈E 1 ∩E 2 r p 2 i ∑ i∈E 1 r p 1 i
, where E 1 , E 2 denotes pools' overlapping epochs ordered according to the oldest coinbase. Thus, the probability for a miner to hop depends on the number of overlapping rounds with respect to the oldest epoch's length. In the trivial case with one overlap between a round (|E 2 | = 1) and a younger epoch, we can classify it as a pool-hopping behavior.

Measurement Results

We analyze the user sub-network involving miners interacting with the two most popular mining pools adopting score-based rewarding methods : Slush pool [258] and Kano pool [262]. Since these pools opt for a per-round rewarding system, we can apply the hopping detection technique showed in Section 3.2.4. We aim at capturing real-hoppers (i.e., miners who have definitely hopped) and the result of their behavior. Thanks to the user sub-network, we can describe the phenomenon evolution over a predetermined time window.

The analyzed period is April 6-20, 2016, chosen for its massive transactions flow (over 5m transactions) such that Kano pool recorded its maximum hashing power [263] ; with a substantial number of miners attracted in joining the pool it has been a remarkable period for hopping opportunities.

First, we detect all the miners, interacting with the two pools, that can potentially adopt a hopping strategy. Afterward, according to our hypothesis (Section 3.2.4), we capture the real-hoppers among them. Moreover, we perform a daily analysis on the number of hoppers and the number of 'hops' made, both globally and individually. Changing-pool hoppers may have simply changed the pool to work for, since they do not present an intermittent behavior. Frequent and occasional hoppers represent together the 46.4% of the hopping miners, while 11 miners perform only a single hop.

In addition we quantify the hopping frequency for those miners who are changing pool more than 5 times in the observed period. Fig. 3.9 presents the distribution of the inter-hopping times (i.e., the time elapsing between two successive hops performed by the same hopper), with boxplots (reporting a quartile box, minimum and maximum) indicating over the number of hops. Approximately half of the miners shows a median time less than 12 hours, with small variance, while the other half shows a higher median with an inter-quartile range of many hours. There is no evidence of the adoption of a strict hard-coded frequency, hence the hopping decision appears to be event-based as expected.

Moreover, we are interested in quantifying the advantage in hopping. The distribution of hoppers' revenues over the time window is presented in Fig. 5.22 with boxplots ; the hoppers' order is the same than the one in Fig. 3.8 ; for some hoppers, only few transactions exist and in that case instead of the boxplot only few points are plotted. The last two boxplots on the right-side of Fig. 5.22 cover all hoppers together and all static miners (that mine continuously without hopping) in the time period ;

we find a median transaction reward 3 times higher for hopping miners than for static ones. This highlights a very important gain justifying pool-hopping ; note that miners' computational power cannot be inferred from the ledger, and in practice for pool-hoppers it may significantly differ from that of the 'typical' miner.

Finally, we report in Fig. 3.11 the correlation between the number of hops and the Bitcoin (USD) price evolution over the 15 days ; we compute the average Bitcoin price and the number of hops performed within a time window of two hours. No evident correlation between the two distributions emerges, i.e., we find here a confirmation that pool-hopping strategies do not appear to be hard-coded in miners behavior as a function of the Bitcoin actual value. Experimental findings. Our analysis determines that the hopping phenomenon is relatively limited in a time window which could have led to a high hopping propensity (only 0.02% of the miners did perform pool-hopping between the two selected pools).

Nonetheless, it is worth noting that our approach is able to spot hoppers assuming rewards happen in a per-round fashion, which is not always the case in practice ; so, the number of hoppers we detect as to be considered a lower bound, and further studies are needed to get closer to an even more realistic hopper detection.

Independently of this latter aspect, the key finding of our empirical study is that we show hoppers' rewards significantly exceed those of static miners. Besides these facts, we have also determined that pool-hoppers have disparate behaviors, likely not correlated, and not dependent on the actual value of the crypto-currency. This suggests that there may not be a shared methodology to implement a hopping strategy, and that pool-hoppers do proceed on a do-it-in-your-own, manual, fashion. Similar conclusions have been stated by works that have removed the assumptions we made in the hopper identification phase [264; 265].

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

Rewarding Rational Miners : Bankruptcy Situations

Following the logic introduced in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], we propose an alternative rewarding mechanism discouraging both pool-hopping and block-withholding behaviors. This section abandons score-based rewarding methods (presented in the first part of this chapter) and analyzes round-based remuneration systems.

By reinterpreting the reward function proposed in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] as an outcome of a bankruptcy situation, we construct, analyze and test a new rewarding mechanism adoptable by pools to remunerate miners.

The following section presents the basic model for mining pool. Please note that definitions about bankruptcy situations are also introduced in Chapter 2. In Section 3.3.2, we introduce a reward function from the literature, we compare it with a new one (based on a modified version of the CEL rule for bankruptcy situation) and we show that the two are equivalent with respect to incentives in reporting shares or full solutions. Then, in Section 3.3.3, we compare these two methods from a multipool perspective by showing (also with the aid of simulations) that the CEL-based reward function performs better than the one from the literature in discouraging miners to hop from a pool to another.

The Model

Let N = {1, . . . , n} be a finite set of miners. Time is split into rounds, i.e., the period it takes any of the miner in the pool to find a full solution. During a round miners participate in the mining race and report their shares (and the full solution) to the pool manager. Once the full solution is submitted, the pool manager broadcasts the information to the network and receives the block reward B. Then, the pool manager redistributes the block reward B among the miners according to a pre-defined reward function. The round is then concluded and a new one starts. For the sake of simplicity we set B = 1.

The situation is represented by the vector s = (s 1 , s 2 , ..., s n ) ∈ N N , defined as history transcript, that contains the number of shares s i reported by each miner i ∈ N in a round. Letting S = ∑ i∈N s i be the total number of reported shares, the reward function R : N N → [0, 1] n , according to [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], is a function assigning to each history transcript s an allocation of the reward (R 1 (s), . . . , R n (s)), where R i denotes the fraction of reward gained by the single miner i ∈ N and

∑ i∈N R i = B = 1.
Following the approach in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], under the assumption of rationality, miners want to maximize their individual revenues over time. Let K be the numbers of rounds that have been completed at time t and let s j be the transcript history for any round j ∈ K. Given a reward function R, a miner 120 3.3. REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS i ∈ N will adopt a strategy (i.e., the number of reported shares at each round j) aimed at maximizing her total reward given by

lim t→+∞ ∑ j∈K R i (s j ),
where a strategy affects both the number of completed rounds and the number of reported shares. In [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], a reward function R is said to be incentive compatible if each miner's best response strategy is to immediately report to the pool a share and a full solution. Assuming that (i) one single pool represents the total mining power (normalized to 1) of the network and that (ii) each miner i ∈ N has a fraction α i of the hashing power, then the probability for a miner i to find a full solution is α i . Under this assumption, Schrijvers et al. [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] show that a miner i ∈ N has an incentive to immediately report her shares if and only if the reward function R is monotonically increasing (i.e., R i (s + e i ) > R i (s) for all history transcripts s, where e i = (e i 1 , . . . , e i n ) ∈ {0, 1} N is a vector such that e i j = 0 for each j ∈ N \ {i} and e i i = 1.). Moreover, they show that a miner i ∈ N , finding a full solution at time t, has an incentive to immediately report it if and only if the following condition holds :

n ∑ j=1 α j • ( R i (s t + e j ) -R i (s t ) ) ≤ E s [R i (s)] D (3.2)
for all vectors of mining powers (α i ) n i=1 and all history transcripts s t , where E s [R i (s)] is the expected reward for miner i over all possible history transcripts. Condition (3.2) results from the comparison of the withholding strategy -i.e., -with the honest one -i.e., R i (s t )+ Es[R i (s)]

Es[S]

-knowing the fact that the total number of submitted shares in a round, S = ∑ i∈N s i , follows a geometrical distribution of parameter p = 1 D (i.e., the probability for a share to be a full solution), where D is the difficulty of the crypto puzzle. Therefore, the value of the parameter D corresponds to the average number of submitted shares in a round.

Let us now report some game-theoretical basic definitions presented in Chapter 2. A bankruptcy situation arises whenever there are some agents claiming a certain amount of a divisible estate, and the sum of the claims is larger than the estate. Formally, a bankruptcy situation on the set N consists of a pair (c, E) ∈ R N × R with c i ≥ 0 ∀i ∈ N and 0 < E < ∑ i∈N c i = C. The vector c represents agents' demands (each agent i ∈ N claims a quantity c i ) and E is the estate that has to be divided among them (and it is not sufficient to satisfy the total demand C).

We denote by B N the class of all bankruptcy situations (c, E) ∈ R N × R with 0 < E < ∑ i∈N c i A solution (also called allocation rule or allocation method ) for bankruptcy situations on N is a map 121 3.3. REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS f : B N → R N assigning to each bankruptcy situation in B N an allocation vector in R N , which specifies the amount f i (c, E) ∈ R of the estate E that each agent i ∈ N receives in situation (c, E).

A well-known allocation rule in the literature is the Constrained Equal Losses (CEL) rule, which is defined in Def. 2.13 (see, for instance, [242; 241] for more details on bankruptcy situations and the CEL rule).

Incentive Compatible Reward Functions

Schrijvers et al. [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] introduce a reward mechanism that fulfills the property of incentive compatibility using the identity of the full solution discoverer w. Given a vector e w = (e w 1 , . . . , e w n ) ∈ {0, 1} N such that e w i = 0 for each i ∈ N \ {w} and e w w = 1, the incentive compatible reward function R is the following :

R i (s; w) = ⎧ ⎨ ⎩ s i D + e w i ( 1 -S D ) , if S < D s i S , if S ≥ D ∀i ∈ N, (3.3)
where s i is the number of shares reported by miner i, S is the total number of reported shares in a round and D is the crypto puzzle difficulty.

This function rewards miner i proportionally to the submitted shares in the case S ≥ D. On the other hand, in the case S < D, each miner receives a fixed reward-per-share equal to 1 D and the discoverer w of the full solution receives, in addition, all the remaining amount 1 -S D . So, in both cases, ∑ i∈N R i (s; w) = B = 1. We can see that the reward function R is the combination of two distinct allocation methods. In a short round, i.e., when the total amount of reported shares is smaller than the difficulty D of the original problem, the reward function allocates a fixed amount-per-share to all agents equal to 1 D , but the agent w who finds a solution is rewarded with an extra prize. Instead, in a long round, i.e., when the total amount of reported shares exceeds the difficulty of the problem, the reward function allocates the reward proportionally to the individual shares.

Remunerating miners in a per-share fashion, for long rounds, would lead pool going bankrupt since the reward B results insufficient to pay out all the reported shares. For long rounds, the rewarding mechanism proposed in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] is nothing more than a solution to a bankruptcy situation. Therefore, it is possible to create new reward functions by simply substituting in long rounds (i.e., in bankruptcy situations) different bankruptcy solutions.

Hence we can construct two new rewarding functions by substituting to the proportional division 122 3.3. REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS the CEA and the CEL rules defined in Def 2.13 and Def 2.12 respectively.

R cea i (s; w) = ⎧ ⎨ ⎩ s i D + e w i ( 1 -S D ) , if S < D min ( s i D , λ ) s.t. λ : ∑ i min ( s i D , λ ) = 1, if S ≥ D ∀i ∈ N R cel i (s; w) = ⎧ ⎨ ⎩ s i D + e w i ( 1 -S D ) , if S < D max ( s i D -λ ′ , 0 ) s.t. λ ′ : ∑ i max ( s i D -λ ′ , 0 ) = 1, if S ≥ D ∀i ∈ N
In Section 2.5.2 we have listed some common properties for solutions of bankruptcy situations.

Some of these properties are satisfied by proportional, CEA and CEL solutions (see Table 2.1), and therefore they are obviously also satisfied by R, R cea and R cel , respectively, on the long run (i.e.,

S ≥ D).

In the following, we discuss the interpretation of these properties in the Bitcoin context.

Equal treatment of equals (2.1).This property ensures impartiality : agents with the same number of shares have to be rewarded in the same way. In the Bitcoin framework impartiality of the pool manager is mandatory.

Scale invariance (2.2). This property ensures the independence of the reward function from the currency in which problem's variables are defined.

Consistency (2.3).

Consistency expresses the independence of a reward function with respect to population restrictions. In the Bitcoin framework, this property implies that no group of miners has an incentive to re-apply a solution in the reduced problem and there is no advantage for miners to renegotiate the allocation in a sub-group once a reward function is accepted by the pool's participants.

No advantageous merging or splitting (2.6). This property rules out the possibility for a group of miners to aggregate their shares in order to appear as a single miner, or conversely, the possibility for a single miner to split its share and appearing as several miners. In the Bitcoin framework, this last behavior identifies with the Sybil attack presented in Chapter 1. These miners can create multiple accounts with different "username" and e-mail addresses and pretend to be different entities. The proportional rule is the only rule which satisfies no advantageous merging or splitting. Therefore, it guarantees pools' robustness with respect to the Sybil attack. However, in order to prevent this attack it is enough to have an allocation rule satisfying only no advantageous splitting. As reported in

 R i (s; w) = ⎧ ⎨ ⎩ s i D + e w i ( 1 -S D ) , if S < D e w i D + max ( s i D -λ, 0 )
, λ :

∑ i max ( s i D -λ, 0 ) = 1 -1 D , if S ≥ D
, where e w = (e w 1 , . . . , e w n ) ∈ {0, 1} N is a vector such that e w w = 1 and e w i = 0 ∀i ∈ N \ {w}, s i is the number of shares reported by miner i, S = ∑ i∈N s i is the total number of reported shares in a round and D is the crypto-puzzle difficulty.

We assign to agent w, who finds the solution during a long round, an extra prize of .

In other words, it means that 1 is added to the count of the shares s i reported by the full solution discoverer w. If the value s i D -λ is negative, by default, the agent w is receiving 1 D . This incentive is sufficient to make the reward function incentive compatible.  R((2, 7, 8); 1) = (0.1, 0, 0) + CEL((0.2, 0.7, 0.8), 0.9) = (0.1, 0, 0) + (0, 0.4, 0.5) = (0.1, 0.4, 0.5). 124

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

In order to prove that the CEL-based rule is incentive compatible we need to present some preliminary results. More precisely, to express Condition (3.2) for this new reward function we need to focus on the parameter λ of the definition. This parameter depends on miners' demands and it changes value from round to round. It is important to analyze how the parameter varies if an additional share is found. Let us denote by : (i) λ 1 the value of the parameter λ when miner i finds the full solution and immediately reports it to the pool and, (ii) λ 2 the value of the parameter after delaying in reporting the full solution by one additional share. By convention, if miner i finds the additional share the parameter is denoted as λ 1 2 , while if any other miner finds it we have λ 2 2 .

By analyzing the different values of the parameter λ it is possible to derive the following result :

Proposition 3.1 Let us consider CEL i (c, E) = max(c i -λ 1 , 0) and CEL i (c + e j , E) = max(c ′ i -λ 2 , 0). For each (c, E) ∈ B N , i, j ∈ N we have that λ 1 ≤ λ 2 .
Proof. Let us report the efficiency condition for the two allocations :

max(c j -λ 1 , 0) + ∑ i∈N \{j} max(c i -λ 1 , 0) = = max(c j + 1 -λ 2 , 0) + ∑ i∈N \{j} max(c i -λ 2 , 0). If c j ≤ λ 1 , efficiency condition implies that ∑ i∈N \{j} max(c i -λ 1 , 0) ≥ ∑ i∈N \{j} max(c i -λ 2 , 0). Hence, λ 1 ≤ λ 2 . For c j > λ 1 let us assume, by contradiction, that λ 1 > λ 2 . The assumption implies that ∑ i∈N \{j} max(c i -λ 1 , 0) ≤ ∑ i∈N \{j} max(c i -λ 2 , 0). However, max(c j -λ 1 , 0) = c j -λ 1 < c j -λ 2 < c j + 1 -λ 2 = max(c j + 1 -λ 2 ,

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

Proof. Let us write down Condition (3.2) for ˆ R :

α i ( 1 D + max ( s i + 1 D -λ 1 2 , 0 ) - 1 D -max ( s i D -λ 1 , 0 )) + (1 -α i ) ( max ( s i D -λ 2 2 , 0 ) - 1 D -max ( s i D -λ 1 , 0 )) ≤ E s [ ˆ R i (s; w)] D .
Since the average reward E s [ ˆ R i (s; w)] is positive, the right hand side is positive. Therefore, the condition is fulfilled if the left hand side is not positive.

Due to Proposition 3.1 and Corollary 3.0.1 we have that :

s i D -λ 2 2 ≤ s i D -λ 1 ≤ s i +1 D -λ 1 2
. If all the terms in the form max(•, 0) are positive, then the condition is fulfilled :

α i ( 1 D -λ 1 2 + λ 1 ) + (1 -α i ) ( -λ 2 2 - 1 D + λ 1 ) ≤ max(α i , 1 -α i )(-λ 1 2 -λ 2 2 + 2λ 1 ) ≤ 0. If s i D -λ 2 2 ≤ 0 ≤ s i D -λ 1 we get : α i ( 1 D -λ 1 2 + λ 1 ) + (1 -α i ) ( - s i D - 1 D + λ 1 ) ≤ max(α i , 1 -α i )(-λ 1 2 - s i D + 2λ 1 ) ≤ 0. If s i D -λ 1 ≤ 0 ≤ s i +1 D -λ 1 2
we get :

α i ( s i + 1 D -λ 1 2 ) + (1 -α i ) ( - 1 D ) ≤ max(α i , 1 -α i ) ( s i D -λ 1 2 ) ≤ max(α i , 1 -α i ) ( s i D -λ 1 ) ≤ 0.
In the end, if all the terms in the form max(•, 0) are equal to 0, then the condition is fulfilled, since the left hand side is negative. ■

A Multi-Pool Analysis

Pool-hopping consists of a practice in which miners leave a pool to join another one that is considered more attractive in terms of remuneration. More precisely, during a round a miner performing pool-hopping (i.e., a hopper ) stops submitting shares to the pool she was working with at the beginning of the round and starts submitting shares to a different one. A hopper leaves, during a mining race, a pool entering (or already in) a long round for a pool that is currently in a short round. The hopping miner receives an increasing reward from the brand new pool (in short round) and a decreasing reward from the pool left (facing a bankruptcy situation where the resource B is insufficient to remunerate the working miners).

In a multi-pool framework, the total mining power of the network is represented by different mining pools each with its own computational power. Differently from Section 3.3.1, each miner i ∈ N

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

is characterized by α i that now represents a fraction of the pool hashing rate. Indeed, in the single-pool framework, we denote with α i the fraction of the total hashing power.

Hopping affects the actual rewards of a pool. If a miner performs pool-hopping the pool loses computational power and so on average the full solution is found later, i.e., the rounds become longer.

In our multi-pool analysis, we assume that pool-hopping is performed at the very beginning of a long round and that miners hop between two pools adopting the same rewarding mechanism. Every mean denoted as E[•] is considered conditioned to the fact that the miner is in a long round :

E s [•|S > D].
From now on, we mark with an asterisk ( * ) every variable defining the reward of miners once poolhopping is performed.

Hopping Analysis on Schrijver's Rewarding Function

When miner i is remunerated with reward function R her incentive to perform pool-hopping can be measured as the difference between (i) the average reward when hopping E[R * i ] and (ii) the average reward E[R i ] when working for the pool : Proof.As shown in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF], the average reward of an honest miner i ∈ N , i.e., not hopping, is :

δ hop := E[R * i ] -E[R i ].
E[R i ] = α i .
A hopper (hopping at time t) receives an increasing reward from the new pool in a short round and a decreasing one from the pool left. The sum of the two represents the total reward. On average at the end of a short round (S = D) a miner has found α i • D shares. The round finishes after D + t shares are found, with t ∈ [0, +∞), hence the reward for the miner who performs pool-hopping is the following :

E[R * i ] = ∞ ∑ t=0 ( α i t D + α i D D + t ) p ′ (1 -p ′ ) t > α i 1 -α i > α i ,
where p ′ = 1-α i D is the probability that a share found by an honest miner is a full solution, t is the time taken by an honest miner (working for the old pool) to find a new share and R * i is the reward obtained 127

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

by a miner who hops from a pool rewarding with R to another pool using the same reward function.

Hence, the incentive to perform pool-hopping is always positive :

δ hop = E[R * i ] -E[R i ] > α i -α i = 0.

■

A second result deriving from Proposition 5.6 is the fact that, on average, the hopping miners gain more than their hashing ratio α i . This has been empirically verified on the Bitcoin network in the contribution presented in Section 3.2. The average reward for a hopper, between pools adopting R, can be analytically computed according to the following result.

Proposition 3.4 The average reward of miner i ∈ N hopping between two different pools remunerating miners according to the reward function R is the following :

E[R * i ] = α i 1 -α i + α * i ,
where

α * i = α i (1 -α i )e 1-α i (-Ei(α i -1)) with Ei(x) = ∫ x -∞ e t
t denoting the exponential integral.

Proof. On average, a miner with computational power α i who performs pool-hopping receives :

E[R * i ] = ∞ ∑ t=0 α i t D p ′ (1 -p ′ ) t + ∞ ∑ t=0 α i D D + t p ′ (1 -p ′ ) t .
The first term represents the reward received by the new pool in short round that can be easily computed as follows :

α i D ∞ ∑ t=0 t • p ′ (1 -p ′ ) t = α i D • D 1 -α i = α i 1 -α i .
The second term (denoted as α * i ) corresponds to the reward assigned by the pool left by the hopping miner. In order to compute this term we need to consider an approximation for D → ∞ :

α * i = ∞ ∑ t=0 α i D D + t 1 -α i D ( 1 - 1 -α i D ) t ≈ α i (1 -α i )e 1-α i ∞ ∑ t=D 1 t e -1-α i D t .
The computations can be solved by defining :

f (x) := lim D→∞ f D (x) = lim D→∞ ∞ ∑ t=D 1 t e -tx D .
Using Lebesgue's theorem and given the constraint lim x→∞ f (x) = 0 we get :

f (x) = -Ei(-x). 128

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

Hence :

α * i ≈ α i (1 -α i )e 1-α i f (1 -α i ) = α i (1 -α i )e 1-α i (-Ei(α i -1)).

■

Thanks to the result provided by Proposition 3.4 we note that the shares submitted in the pool left by the hopping miner (α * i ) represent an important part of her average reward. More precisely, for values of α i < 0.39, α * i is more than the 50% of the average reward a miner would have got by not leaving the pool (i.e., her computational power α i ). For instance, if a miner has α i = 0.2 as computational power, she will get α * i ≈ 0.11.

Hopping Analysis on CEL-based Rewarding Function

Following similar arguments, we can analyze the incentive to perform pool-hopping when adopting the CEL-based rule R ˆ. We can, then, compare the results obtained for the reward function R with the ones provided by ˆ R. We denote as β i the average reward of function ˆ R (corresponding to α i for function R) that can be computed as follows since the probability for a miner i to find a full solution and to receive the extra prize 1 D is α i :

β i = E[ ˆ R i ] = α i D + E [ max ( s i D -λ, 0 )] λ : ∑ i max ( s i D -λ, 0 ) = 1 - 1 D .
Like in Section 3.3.3.1, let us define the incentive to perform pool-hopping ˆ

δ hop := E[ ˆ R * i ] -E[ ˆ R i ] and
let us compute the average reward received by a hopper :

E[ ˆ R * i ] = ∞ ∑ t=0 ( α i t D + max ( α i D D -λ, 0 )) p ′ (1 -p ′ ) t = α i 1 -α i + E [max(α i -λ, 0)] ,
where p ′ = 1-α i D , t is the time taken by an honest miner to find a new share and ˆ R * i is the reward obtained by a hopping miner.

Analogously to α * i for function R, we denote by β * i the reward given by the pool the hopper left :

β * i = E [max(α i -λ, 0)] .
Hence we have that :

ˆ δ hop = E[ ˆ R * i ] -E[ ˆ R i ] = α i 1 -α i + β * i -β i .
δ ˆhop ≤ δ hop ⇔ β i -β * i ≥ α i -α * i .
In order to show that the hopping incentive for the CEL-based reward function is lower with respect to the incentive given by R it is sufficient to prove that

β i -β * i ≥ α i -α * i .
Proposition 3.5 Let N be the ordered set of miners :

α 1 ≤ α 2 ≤ • • • ≤ α n , let us define α >i :=
∑ j>i α j , as the global computational powers of the miners who are more powerful than α i . Then,

β i -β * i ≥ α i -α * i if (1 -α i )(α >i -α i )e -α i +(α >i -α i ) -1 (-Ei(α i -1)) ≥ 1 where Ei(•) is the exponential integral function.
Proof. Given the definitions of β i and β * i :

β i = α i D + ∞ ∑ t=0 max ( α i + α i t D -λ, 0 ) p(1 -p) t and β * i = ∞ ∑ t=0 max (α i -λ, 0) p ′ (1 -p ′ ) t ,
let us recall that p = 1 D is the probability for a share to be a full solution and that p ′ = 1-α i D represents the probability for a share reported by an honest miner to be a full solution.

For t → ∞ (i.e., for very long rounds) the function max(•, 0) either tends to 0 or to 1 since in long rounds eventually the most powerful miner is receiving all the reward (max(•, 0) → 1) and the other miners are receiving none of it (max(•, 0) → 0). The limit value 0 is reached for t = γ i • D, where

γ i ∈ R ∪ {+∞} is defined as follows ; γ i := argmin γ { α i t D -λ < 0, ∀t ≥ γD}.
Indeed, γ i • D represents the number of shares after which miner i is not rewarded.

Hence, it is possible to rewrite β i and β * i in this form :

β i = α i D + γ i D ∑ t=0 ( α i + α i t D -λ ) p(1 -p) t and β * i = γ i D ∑ t=0 (α i -λ) p ′ (1 -p ′ ) t .
The value of γ i might change if the miner is performing pool-hopping, but for the sake of simplicity we approximate by considering the same γ i in both cases.

Assuming that

∑ t λ • p(1 -p) t ≈ ∑ t λ • p ′ (1 -p ′ ) t we
β i -β * i ≈ α i D + γ i D ∑ t=0 α i t D p(1 -p) t .
Due to the value of the difficulty D, we can consider the limit for D → ∞, then :

β i -β * i ≈ α i D + γ i D ∑ k=0 α i k D 1 D e -k/D = α i D + α i 1 D 2 γ i D ∑ k=0 ke -k/D → α i (1 -e -γ i (1 + γ i )).
Let us now compute explicitly γ i . If i = N (i.e., α i = argmax j {α j }) then γ i = ∞. Otherwise at time t = γ i • D the miners who receive a positive reward are all the j ∈ N : α j > α i , i.e., all the ones having larger computational power than i. According to the CEL rule definition we get the following balance equation :

∑ j>i ( α j ( 1 + t D ) -λ ) = 1 - 1 D ≈ 1.
Since the time t = γ i • D is the moment when the value max(α i (1 + t D ) -λ, 0) turns from positive to null, we can say that α i (1 + t D ) -λ ≈ 0. Therefore we have that :

∑ j>i ( α j ( 1 + t D ) -α i ( 1 + t D )) = 1.
Replacing the value of t with γ i • D we get (α >i -(N -i)α i )(1 + γ i ) = 1, then :

γ i = ((α >i -(N -i)α i ) -1 -1).
Now we can find a lower bound for γ i (since N -i ≥ 1) and so for β i -β * i :

γ i ≥ γ ¯i := ((α >i -α i ) -1 -1) =⇒ β i -β * i ≥ α i (1 -e -γ ¯i (1 + γ ¯i)).

The sufficient condition for

β i -β * i ≥ α i -α * i is : α i (1 -e -γ ¯i (1 + γ ¯i) ≥ α i -α * i .
We get the statement of the proposition by replacing γ ¯i and α * i with their explicit formulas. ■ Thanks to Proposition 3.5, given miner i's hashing ratio (i.e., α i ) and the power of the miners who are stronger than i (i.e., α >i ), we can check whether ˆ R is giving a lower hopping incentive than the one given by R (i.e., check whether δ ˆhop ≤ δ hop ) by simply applying the sufficient condition introduced above that we denote as f (α i , α >i ) :

f (α i , α >i ) := (1 -α i )(α >i -α i )e -α i +(α >i -α i ) -1 (-Ei(α i -1)) ≥ 1. 131

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

Let us analyze the hopping performance of R and ˆ R in the following example.

Example 3.3.2 Given 5 miners ordered according to their hash rates : α 1 = 0.10 α 2 = 0.15, α 3 = 0.20, α 4 = 0.25, α 5 = 0.30, using the condition provided by Proposition 3.5 we get : • f (α 5 , α >5 ) = f (0.30, 0) → ∞ > 1, miner 5 has a really low incentive to perform pool-hopping if rewarded with ˆ R.

• f (α 1 , α >1 ) = f (0.
We can see that miners representing the 75% of the pool's computational power have a lower incentive to perform pool-hopping when the CEL-based rewarding mechanism is adopted.

By analyzing function f (•, α >i ) -i.e., fixing α >i -we can identify the cases in which δ ˆhop ≤ δ hop (where ˆ R performs better than R). For instance, f (•, α >i ) > 1 for every α >i < 0.4, means that with ˆ R not only the miners representing the most powerful 40% of the pool have a lower incentive to perform pool-hopping, but also the miner i who just follows in the ranking.

To compare the two reward functions, it is necessary to estimate the percentage of miners who have a lower incentive to perform pool-hopping. In Example 3.3.2 this percentage is computed as follows :

p(α = {0.1, 0.15, 0.2, 0.25, 0.3}) = 75%. Formally we would like to estimate :

p(α) := ∑ i α i • 1 {β i -β * i ≥α i -α * i } .
We know that p(α) > 40% thanks to the analysis of function f . In order to get a better idea of the range of the value of function p we perform a simulation.

Simulation. Due to the unpredictability of α, we assume that it comes from a random distribution.

REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS

More precisely, given X i ∼ U [0, 1], α i is defined as follows :

α i := X i ∑ j X j .
We run a simulation with 100 different samples of α for n miners, with n ∈ {3, 10, 20, 30, 50}, and estimate the CDF of p n (α) for every n. We compute explicitly β i and β * i , without using the approximation above introduced. This means that in most of the cases the majority of the miners have a lower incentive to perform pool-hopping with ˆ R rather than R.

Conclusions. The contribution analyzes the robustness of two different rewarding mechanisms in both

intra-pool and inter-pool environments. The reward function introduces in [START_REF] Schrijvers | Incentive compatibility of bitcoin mining pool reward functions[END_REF] is incentive compatible but not hopping proof. By reinterpreting R, in long rounds, as an allocation rule for a bankruptcy situation, we created a new rewarding function ˆ R inspired to the well-known Constrained Equal Loss (CEL) rule. We show that this CEL-based rule is incentive compatible as R but it provides to most of the miners a lower incentive to perform pool-hopping in long rounds. In conclusion, if a pool wants to tackle this issue, the proposed rewarding function ˆ R is the one to be recommended.

SUMMARY

Summary

Summary. This chapter analyzes a particular type of blockchain users, i.e., validating nodes of the Bitcoin blockchain, who act in a rational manner driven in their choices by the mere intent of gaining a higher reward. The first contribution presents evidence of Bitcoin miners' hopping propensity emphasizing the rationality of miners behaviors. In the second contribution we model the rewarding problem as a bankruptcy game with the scope of identifying a reward function that can prevent both block-withholding and pool-hopping behaviors. In reality, Bitcoin and more in general blockchain systems are subject to countless attacks on a daily basis related to their design constructs, the peer-to-peer architecture and their application [START_REF] Saad | Exploring the attack surface of blockchain : A comprehensive survey[END_REF]. Rationality cannot always explain these behaviors ; some blockchain users attack the system with the simple intent of compromising and/or destroying it [START_REF] Forbes | Bitcoin Fork Suffers 'Massive' 51% Attack In Attempt To 'Destroy' The Cryptocurrency, Sending Its Price Sharply Lower[END_REF], even if this comes at a cost. Hence, the presence of these Byzantine validators, who behave in a malicious manner no matter what, needs to be considered in assessing the robustness of blockchain systems (see Chapter 5).

INTRODUCTION TO BLOCKCHAIN INTEROPERABILITY AND CROSS-CHAIN PROBLEMS

Introduction to Blockchain Interoperability and Cross-Chain Problems

The modern economy is moving to a new era where economical transactions use crypto-currencies instead of fiat money. Crypto-currencies (i.e., Bitcoin, Ethereum, etc.) are based on the use of blockchains, which are basically transactional systems governed by decentralized protocols. Blockchains pave the way for a new approach to organize and sustainably maintain long-term transactions as well as high-level services. It is interesting to note that the number of blockchains that currently hold the head of newspapers has gone from one in 2008 (the famous Bitcoin blockchain [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF]) to a few tens in 2018 such as Hyperledger [START_REF]Hyperledger Architecture Vol.1, Introduction to Hyp-erledger Business Blockchain Design Philosophy and Consensus[END_REF], Ethereum [START_REF] Buterin | Ethereum White-paper[END_REF], Zcash [START_REF] Green | Bolt : Anonymous payment channels for decentralized currencies[END_REF], Corda [START_REF] Hearn | Corda : A distributed ledger[END_REF], Ripple [START_REF] Schwartz | The Ripple protocol consensus algorithm -White Paper[END_REF], Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] etc. Each of these systems has its own modus operandi, its own governance and even its own way of agreeing on a common history. Each system has its own advantages that make it attractive for various applications and geopolitical contexts. We are witnessing the creation of several ecosystems, each with its own currency and governance.

Similar to modern international economical exchanges which are based on different governmentissued currencies, inter-blockchain exchanges must be based on common rules resilient to attacks, failures or malicious behaviors affecting the network. There are currently several operational systems for achieving interoperability between different blockchains such as Kybernetwork [268], Aion [269],

Cosmos [270] or Polkadot [START_REF]Polkadot : Vision for a Heterogeneous Multi-Chain Framework[END_REF]. These systems can be classified into two categories according to their decentralization level : systems that use a trusted third-party to validate transactions or systems that realize it directly between blockchains without the need of a trusted third-party. In order to execute an exchange or a swap (i.e., a set of transactions between parties), transacting agents (i.e., blockchain users) are provided with a protocol to stick to. A protocol in this case consists of a specific sequence of instructions agents should perform to preserve the ACID properties [START_REF] Lewis | Databases and transaction processing : an application-oriented approach[END_REF] of the individual transactions or exchanges ; that is, Atomicity : the all-or-nothing occurs and each participant must know which state he or she is in ; Consistency : each successful transaction by definition commits only valid results ; Isolation : transactions run independently ; Durability : transactions cannot be abrogated after commitment.

Atomic cross-chain swaps fall into the class of the so called TAST (i.e., Token Atomic Swap Technology) [START_REF] Borkowski | Towards atomic cross-chain token transfers : State of the art and open questions within tast[END_REF] research ideas aiming at making blockchains interoperable. Differently from decentralized exchanges -initiatives recently emerged to remove the need of trust on traditional exchange AC3TW and AC3WN [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] protocols propose atomic cross-chain swaps respectively with centralized and "decentralized" trusted authorities (i.e., an external agent and an external blockchain) acting as witnesses. According to Arwen protocol [START_REF] Heilman | The arwen trading protocols[END_REF] crypto-assets are swapped through centralized exchange services that in no way acquire the assets custody. XClaim [START_REF] Zamyatin | Xclaim : Trustless, interoperable, cryptocurrency-backed assets[END_REF] overcomes blockchain data-structures incompatibility by swapping cryptocurrency-backed assets.

It should be noted that different swap protocols differ essentially in the involved parties. The set of swap participants can be composed only of the asset owners (e.g., as in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF]) or by owners accompanied by a trusted third party (e.g., as in the AC3TW protocol [START_REF] Zakhary | Atomic commitment across blockchains[END_REF]).

To the best of our knowledge, there is (i) no formal analysis on the structure and the properties blockchain swap protocols satisfy and, (ii) no game theoretical modeling of participants strategic interactions (i.e., to follow or not to follow the prescribed protocol). More precisely, Nolan [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] presents the Bitcoin swap protocol in a functional manner. In [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] the author provides a partial game theoretical analysis (specific to the protocol) presenting no structural characterization of the possible equilibria of the system (see Section 4.4.1). Authors in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] analyze the atomicity violations characterizing the protocol in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]. However, no game theoretical result is provided.

According to recent studies [287; 288] proposed swap protocols are not properly analyzed neither from the structural point of view, responsible for their atomicity, nor from the strategical point of view making them satisfying liveness and safety properties (i.e., the protocol terminates in a valid state). More precisely, it is important to analyze the behaviors of the swap participants who can be

INTRODUCTION TO BLOCKCHAIN INTEROPERABILITY AND CROSS-CHAIN PROBLEMS

considered as rational agents actively participating in the exchange by following or not the prescribed protocol according to their own objective function.

We propose, in Section 4.2, a generic game theoretical framework that formalizes the swap problem and characterizes blockchain swap protocols by clearly separating the contracts publishing phase and their commitment phase. Furthermore, we prove in Section 4.3 that (i) following a swap protocol characterized by an effective decision function (when players have the power to accept or decline the desired assets) is a subgame perfect equilibrium in dominant strategies and, that (ii) following a swap protocol characterized by concurrent publishing and snap (immediate) commitment is a Nash equilibrium. Our generic framework allows us to characterize, in Section 4.4, equilibria of two representative recent protocols presented in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and [START_REF] Zakhary | Atomic commitment across blockchains[END_REF], respectively. In the case of the protocol proposed in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and generalized in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF], following the protocol is the unique subgame perfect equilibrium (in dominant strategies), while in the case of the protocol proposed in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF], following the protocol is a Nash equilibrium.

SWAP PROBLEMS AND SWAP PROTOCOLS

In order to formally define a swap protocol we need to introduce first, the structure of a decentralized exchange protocol, consisting of a sequence of asset(s) transfers to be committed.

Definition 4.2 (decentralized exchange protocol) Let σ = {(A k , O k , X k ) : |A k | ≥ |O k |} k , k ∈ {1, . . . , t},
t ∈ N : t ≤ m be a sequence of exchanges where,

• A k ⊆ A specifies the subset of assets involved in the exchange at step k ;

• O k ⊆ O specifies the subset of owners involved in the exchange at step k ;

• X k : A k → O k (surjective) specifies the owner X k (a) ∈ O k of any asset a ∈ A K at step k ;
A sequence σ defines a decentralized exchange protocol that engenders a sequence of maps b

σ 1 , b σ 2 , . . . , b σ t : A → O such that for all k ∈ {1, 2, . . . , t} : -b σ k (z) = b σ k-1 (z), ∀z ∈ A \ A k ; -b σ k (z) = X k (z), ∀z ∈ A k ,
where we set b σ 0 = b 0 .

So, the triple (A k , O k , X k ) specifies that the asset set A k ⊆ A is transferred at step k to owners The sequence σ defines, for each protocol step k, (i) the assets A k whose property is to be transferred, (ii) the new assets' owners O k and, (iii) the function X k assigning the precise owner to each asset.

O k ⊆ O
The protocol is decentralized as ownership transfers take place among the owners themselves. At each step k an asset can change owner, the final configuration at time t provides the final asset owner.

In the simple case where agents agree on exchanging assets through a single ownership transfer at each step k, the corresponding single-swap protocol is represented by the sequence σ = {(a k , o k ) : A → O according to Definition 4.3.

o k ∈ O, a k ∈ A} k∈{1,...,
We associate to each sequence σ P , σ T the corresponding decision function F P , F T defined above.

Let us note that the publishing sequence σ P is constructed in such a way that transfers that can be published are of type (A j , b * (A j )) or (A j , b 0 (A j )). That is, blockchain transactions can transfer the asset ownership to desired owners and original owners only.

Phases Separation

We have defined a blockchain swap protocol as a publishing sequence followed by a commitment emphasizing the precedence of the first phase over the second. However, it is necessary to condition the execution of the commitment protocol to the publication of all the contracts in order to have an atomic blockchain swap protocol. The following definition formalizes such a commitment requirement.

Definition 4.8 (commitment requirement) Given a blockchain swap protocol (σ P , σ T ) whenever there exists an asset transfer (using the swap structure previously given) that is not correctly published, then no asset transfer is committed. Formally, if, in σ P , ∃j ¯∈ {1, . . . , t P } :

O j ¯∩ b 0 (A j ¯) ̸ = ∅ then, in σ T , b σ T k = b 0 ∀k ∈ {1, . . . , t T }.
Every blockchain swap protocol has to meet the commitment requirement defined above in order to be atomic. Hence, Definition 4.8 is a necessary condition (but not sufficient, see Section 4.4.1.3) for atomicity. Indeed, whenever an asset transfer is not correctly published the time-lock acts by not modifying the original asset ownership, i.e., transferring the asset back to the original owner (see [291; 292] for more details).

Focusing separately on the commitment protocol, it is possible to derive initial properties on blockchain swaps.

SWAP PROBLEMS AND SWAP PROTOCOLS

Commitment Protocol

As stated in the following proposition, whenever an asset transfer is not committed, the swap participant supposed to acquire the asset(s) ends up with less assets than expected while the original asset owner finds himself with an extra asset. Next proposition does not depend on the exact specification maps X k , so we omit them in the sequence σ T for the sake of simplicity.

Proposition 4.1 Given a commitment sequence σ T = {(A k , O k , X k )} k∈{1,...,t T } , t T ∈ N : t T ≤ m then, replacing O k by b σ T k-1 (A k ) in σ T i.e., considering a new sequence σ k T = (A 1 , O 1 ), . . . , (A k-1 , O k-1 ), (A k , b σ T k-1 (A k )), (A k+1 , O k+1 ), . . . , (A t T , O t T )
, for some k ∈ {1, . . . , t T }, implies that :

(i) ( b σ k T t T ) -1 (O k ) ⊆ ( b σ T t T ) -1 (O k ) and, ( ii
) ( b σ k T t T ) -1 (b σ T k-1 (A k )) ⊇ ( b σ T t T ) -1 (b σ T k-1 (A k )).
Proof. The claims follow from the fact that A k is not given to O k in σ k T but it is given back to the original owners.

Sequential Phases and Beyond

The formalization provided by Definition 5.23, enables capturing :

1-Single-asset and multi-assets swaps depending on the cardinality of the asset set A k at step k in the commitment protocol.

2-Swap protocols with sequential publishing and commitment, both single-asset and multiple-assets, where ownership transfers are published and committed according to a precise temporal order.

Every crypto-asset transfer has to be executed before or after another one. In Section 4.4.1 we

show that the sequentiality of the publishing phase combined with the leader role of a swap participant guarantees that the commitment ownership is verified.

3-Swap protocols with concurrent publishing where transfers are no longer published according to a given time order, but may be concurrently created and propagated to the blockchain network.

SWAP PROBLEMS AND SWAP PROTOCOLS

In fact, it is not essential that the various transfers are published one at a time but only that there is a clear distinction between the publication and the commitment phase. Therefore, the transfers publication can take place in a concurrential way and this is captured by the sequence σ P where at step j : j ∈ {1, . . . , t P } multiple assets transfers (A j , O j ) are published.

4-Swap protocols with snap commitment, where assets transfers are all committed at the same time.

Proposition 4.2 A blockchain swap protocol with a snap commitment scheme satisfying the commitment requirement as in Definition 4.8 is atomic.

Proof. By contradiction, if b σ T t T ̸ = b 0 ∧ b σ T t T ̸ = b *
then, since no problem in the publishing occurs, there should be a situation where some assets transfers are triggered and some others are not. However, this contradicts the snap commitment. ■

Decision Function

Let us focus on the decision function F previously defined. A blockchain swap can be completely driven by the asset owners only, in that case the function outcomes are all elements of O. On the other hand, we can have the intervention of an external actor τ entrusted for committing assets transfers. More precisely, the external trusted actor cannot publish blockchain contracts in behalf of asset owners since blockchain swap protocols contemplate ownership transfers among owners only (as in Definiton 5.23). Considering the publishing phase we can notice that every asset owner is in charge of publishing the signed contract transferring the asset ownership. In case of multi-assets transfers a multisig scheme [START_REF] Harn | Digital multisignature with distinguished signing authorities[END_REF] can be adopted.

Definition 4.9 (ownership requirement) In a blockchain swap protocol, the decision function F P (corresponding to sequence σ P ) is such that

F P (j) = b 0 (A j ) ⊆ O

Game Theoretical Analysis of Cross-Chain Swaps

Thanks to the formalization presented in the previous section we can use game theory to analyze strategic behaviors of the swap participants (modeled as rational agents) in a blockchain swap protocol.

In this sections we associate a specific blockchain swap protocol (σ P , σ T ) (e.g., sequential, concurrent publishing and snap commitment) with the corresponding game (in strategic or extensive form). We prove that (i) following a swap protocol characterized by an effective decision function is a subgame perfect equilibrium in dominant strategies and, that (ii) following a swap protocol characterized by concurrent publishing and snap (immediate) commitment is a Nash equilibrium.

Considering decentralized swap protocols, the participants, intervening in both commitment and publishing phase, are more or less incentivized to stick or not to the protocol regulating the swap.

The outcomes of a single agent, varying according to personal strategies, result depending from other agents strategic behaviors, too. What is common knowledge among the swap participants is the swap protocol structure that is represented by the pair (σ P , σ T ).

As discussed in Section 4.2.2, blockchain swap protocols in both single and multi-assets case, can be characterized by sequential publishing and commitment, concurrent publishing and snap commitment.

For those protocols characterized by concurrent moves (i.e., concurrent publishing) we can adopt a representation with games in normal form presented in Section 2. • N = O is the set of players ;

• (S i ) i∈N = {action 1, action 0} is the set of pure strategies for player i consisting in the pair ( follow the protocol, not follow the protocol) labelled respectively as action 1 and action 0 ;

• (u i ) i∈N : u i : ∏ j∈N S i → R is the payoff function for asset owners N = O evaluating the outcomes of type b σ T t T that is, for every player i we have u i ( (b σ T t T ) -1 (i) )
.

We model protocols with sequential phases with extensive form games (see Section 2.3.1) in order to represent the sequencing of swap participants' moves and the fact that at each decision point asset owners know the moves history so far. Indeed, that blockchains involved in a swap are of public nature • N = O is the set of players ;

• T is a (binary) directed tree such that each directed path from the root v 0 ∈ V to an end node v ∈ Z is formed by precisely t + 1 nodes and t arcs (V is the set of the nodes of the tree T and Z ⊂ V is the set of leaf nodes) ;

• P (v) = F P,T (l(v)), for each v ∈ V \ Z, is the publisher/activator of the asset transfer(s) at step l(v) in the protocol (σ P , σ T ), where l(v) is the number of arcs between v 0 and v on the unique path from v 0 to v (we assume that l(v 0 ) = 0) ;

• A h for all h ∈ V is formed by two outgoing arcs in h ; one arc in A h is labeled with action 1 (i.e., follow the protocol) and the other one, action 0 (i.e., not follow the protocol) for any h ∈ V \ Z.

So, a unique path from v 0 to an end node z ∈ Z identifies a binary vector p z ∈ {0, 1} t such that p z k is the label of the arc starting from node v with l(v) = k on the path from v 0 to z.

• Any end node z ∈ Z is associated with a unique outcome corresponding to the map b and let F T : {1, . . . , t T } → O ∪ {τ } be a decision function. If F T is effective on σ T , then the strategy profile (s ˆ1, . . . , s ˆn) that specifies action 1 (follow the protocol) at any node is the unique subgame perfect equilibrium (in dominant strategies).

Proof. For each node v, by the fact that F T is effective, we have that v) . So, at each decision node v ∈ V \ Z, if player P (v) specifies action 0 (not follow the protocol) at node v, then by the first claim of Proposition 4.1, player P (v) ends up with a set of assets that is contained in the one that player P (v) would obtain if she/he specifies action 1 at node v. So, the utility of player P (v) is larger if it chooses, at each decision node, action 1 than action 0. It follows that at each node v action 1 strictly dominates action 0 for player P (v). ■

P (v) = F T (l(v)) = O l(

GAME THEORETICAL ANALYSIS OF CROSS-CHAIN SWAPS

Note that if (σ P , σ T ) is efficient, then in Proposition 4.3 the unique subgame perfect equilibrium in dominant strategies corresponds to the desired outcome b * . Proposition 4.3 shows that, whenever players in the game have to decide whether to accept or decline an asset acquisition, they are incentivized to follow the protocol by accepting the desired asset. Nonetheless, a stronger result can be proved. (follow the protocol) at any node is the unique subgame perfect equilibrium (in dominant strategies).

Proof. We have to prove the "if" since the "only if" directly follows from Proposition 4.3. By contradiction, if F T is not effective we have the following cases : (i)

P (v) = F T (l(v)) = b σ T 0 (A l(v)
), the original owner of the assets decides whether or not to follow the protocol or, (ii)

P (v) = F T (l(v)) = O k ̸ = b σ T 0 (A l(v) ) such that k ∈ {1, . . . , t T } : k ̸ = l(v)
, the activators are any player in the game but the original asset owners and the asset receivers.

(i) Whenever the owners of the assets in the initial configuration have to decide between action 0 (not follow the protocol) and action 1 (follow the protocol), by the second claim of Proposition 4.1 they have no incentive to follow the protocol σ T . That is, not following the protocol the asset set obtained at time t T is greater then the one obtained by following the protocol.

(ii) Whenever the activators of transfers

(A k , O k ) are neither O k nor b σ T 0 (A k
), the situation is more complex. Assuming that players activate only exchanges of other players, it always exist an activator o l (v) : l(v) ∈ {1, . . . , t} that has to decide whether to follow the protocol σ T or to deviate by originating the sequence σ K T (defined in Section 4.2.2). However, the activator would be indifferent to the two strategies since

u o l(v) ( (b σ T t ) -1 (o l(v) ) ) = u o l(v) ( (b σ K T t ) -1 (o l(v) ) )
due to the fact that the cardinality of the asset set remains unchanged.

Therefore, the strategy profile specifying action 1 (follow the protocol) at each stage cannot be a perfect equilibrium in dominant strategies if F T is not effective. ■

This result seems to rule out any swap protocol with a non-effective decision function F T : {1, . . . , t T } → O. However, we can imagine protocols with transaction triggering mechanism not involving receiving agents (see Section 4.4.2).

CROSS-CHAIN SWAP PROTOCOLS

Cross-Chain Swap protocols

This section is devoted to the analysis of existing cross-blockchains swap protocols aiming to move forward the custodial trading performed by centralized exchanged services. Our generic framework allows us to characterize equilibria of two representative recent protocols presented in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] respectively. In the case of the protocol proposed in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and generalised in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF], following the protocol is the unique subgame perfect equilibrium (in dominant strategies), while in the case of the protocol proposed in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF], following the protocol is a Nash equilibrium.

Sequential Publishing and Commitment

Here we present the swap solution proposed by Nolan [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] for permissionless UTXO-based blockchains. Nolan's protocol make use of contracts [START_REF] Wiki | Distributed contract[END_REF], hash-locks as commitment/locking scheme and time-locks to restore the initial situation consequently to failures in the publishing phase.

Given two asset owners (e.g., Alice and Bob) aiming at cross-swapping two crypto-assets (e.g., x

Bitcoins and y Litecoins), the protocol (represented in Fig. 4.2) works as follows :

1. The agent Alice creates a secret s such that h = H(s), and publishes a contract transferring the ownership of her x Bitcoins to Bob on the Bitcoin blockchain. The contract is locked with the hashlock h and a timelock ∆ Bob ensuring that : "Bob can claim the asset property providing s before time ∆ Bob ".

2. When Bob confirms that Alice's contract has been correctly published on the Bitcoin blockchain, he publishes a contract on the Litecoin blockchain with the same hashlock h but with timelock ∆ Alice stipulating that : "before time ∆ Alice , Alice can claim the asset property with secret s". According to our formalization the two party cross-chain swap is represented as follows :

σ P = {(x, B), (y, A)}, F P (j) = {A, B}, j = {1, 2}; σ T = {(y, A), (x, B)} F T (k) = {A, B}, k = {1, 2}.
The protocol assumes that swap participants (i) actively monitor the involved blockchain in order to confirm contracts publication and, (ii) adopt a common hashing method. Herlihy [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] extends the protocol for multi-assets and multi-agents swaps (with the secret creators forming a feedback vertex set L i.e., a subset of V whose deletion leaves D = (V, E) acyclic) and analyzes under which conditions it is 'atomic'. Atomicity, in this case, is defined in a game theoretical fashion : in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] a swap protocol is defined as atomic if :

-"following the protocol" is a nash equilibrium strategy and, -no conforming party is affected (in terms of payoff) by a protocol deviation.

Moreover, multi-asset swaps that are atomic according to [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] have a strongly connected corresponding digraph D (i.e., for every pair of distinct owners there is always a path from one to the other and viceversa).

The Separating Agent

In multi-players protocol implementations, the role of the secret creator or leader, denoted as l, becomes crucial. Let us consider only single leader swap protocols. The latter initiates the publishing and most importantly the commitment phase of the protocol by disseminating the secret s. A swap leader reveals the secret whenever all the contracts transferring her the ownership of the desired Proof. We can state that the last contract(s) to be published are the ones involving the leader acting as a receiver ;

O t P = {l}. If a contract is not correctly published (∃j ¯∈ {1, . . . , t P } : O j ¯∩ b 0 (A j ¯) ̸ = ∅),
either the receiver is the leader, hence the commitment cannot start for (i), or the receiver is a different participant which for (ii) cannot publish her contracts. Indeed, since the graph is strongly connected, there is a sequence of participants, from the receiver to the leader, not activating their contracts. ■

Protocol Strategic Behavior

The blockchain swap protocol presented above works with a sequential commitment phase where swap participants trigger contracts transferring them the ownership of the desired assets. Therefore, the decision function characterizing the protocol is effective. Note that, thanks to Proposition 4.4, we can derive a stronger result than the one proposed by the original paper concerning the players strategic behavior.

Corollary 4.0.1 In the blockchain swap protocol (σ P , σ T ) presented in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] (and generalised in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF]), the strategy profile (s ˆ1, . . . , s ˆn) specifying action 1 (follow the protocol) at any node is the unique subgame perfect equilibrium (in dominant strategies).

Let us provide (Fig. 4.3) the graphical representation of the extensive form game associated to the blockchain swap protocol (σ P , σ T ) presented in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]. We do consider two owners O = {A, B} swapping Subgame perfect equilibria are computed by applying the backward induction process presented in Section 2.3.2. By reasoning from the end to the beginning of the game, at each decision step the strategy providing a better payoff (i.e., the one providing greater utility) is selected. Then, considering the game associated to the swap protocol presented in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF], the sequence of optimal actions is the one specifying action 1 at each decision step (see Fig. 4.3).

CROSS-CHAIN SWAP PROTOCOLS

Atomicity Violations

In [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] the authors observe that the protocol presented by Nolan [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] is not immune to violation of the all-or-nothing atomicity as in Definition 4.7. More precisely, a time-lock expiration before commitment can lead an honest swap participant to deviate from the protocol. As in Fig. 4.3 if Bob does not commit the transfer at the last decision step (i.e., if the time-lock expires before) the outcome is b σ T 2 = (A, A) which differs from both b 0 and b * . Crash failures together with network delays are some of the possible causes of time-lock expiration before commitment making the deviating party ending up with an asset loss. Rational swap participants may be induced to deviate from the prescribed swap protocol (i.e., behaving as Byzantine agents) by external factors. Hence, the need to analyze the robustness of crosschain swap protocols (those that are vulnerable to atomicity violations e.g., [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]) to Byzantine behaviors (see Section 5.4 of Chapter 5). A snap commitment represents a solution to atomicity violations in asynchronous environments.

Concurrent Publishing and Snap Commitment Protocols

In [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] authors propose an atomic swap protocol characterized by a concurrent publishing phase and a snap commitment. The protocol AC3TW works with a centralized trusted authority τ called Trent, acting as a separating agent that (i) verifies the correctness of the publishing phase and, (ii) witness the redemption contracts. Thanks to the trusted witness Trent the protocol benefits from all-or-nothing atomicity and faster publishing phase with respect to the sequential one (i.e., increasing overhead proportional to the number of contracts involved in the swap).

CROSS-CHAIN SWAP PROTOCOLS

The protocol constructs for every possible swap configuration a directed graph D = (V, E) similar to the one of [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] (see Section 4.2 for more details). D is multisigned by all swap participants in the set V generating a graph multisignature m s (D). The signatures order is irrelevant, the multisignature represents the participants' agreement on D.

Given two asset owners (e.g., Alice and Bob) aiming at swapping x Bitcoins for y Ethereum here below the steps characterizing the two party AC3TW protocol (represented in Fig. 4.4) :

(1) Alice and Bob create the digraph D and multisign it generating m s (D).

(2) The multisignature is registered and stored by the centralized trusted authority, Trent, only if not registered before and it is set to a null value ⌉.

(3) Alice publishes the contract C 1 on the Bitcoin blockchain stating that :

-if Bob provides Trent's signature to the redemption instance, i.e., if he provides T (m s (D); RD) then, x Bitcoins' ownership is transferred from Alice to Bob.

-if Alice provides T (m s (D); RF ) then, the x Bitcoins are transferred back to Alice. According to our formalization the two party cross-chain AC3TW protocol is represented as follows :

σ P = {({x, y}, {A, B})}, F P (j) = {A, B}, j = {1}; 4.4. CROSS-CHAIN SWAP PROTOCOLS σ T = {({x, y}, {A, B}, {X 1 (x) = B, X 1 (y) = A})} F T (k) = τ, k = {1}.
All-or-nothing atomicity is achieved by the fact that the redemption T (m s (D); RD) and the refund T (m s (D); RF ) events are mutually exclusive. The protocol meets the commitment requirement due to Trent's witnessing activity. The latter reduces as well the interactivity (i.e., the active participation of the swap participants) of the swap protocol [START_REF] Zamyatin | Xclaim : Trustless, interoperable, cryptocurrency-backed assets[END_REF] with respect to Nolan's swap implementation where asset owners have to be constantly on-line monitoring the involved blockchains. The two contracts of the AC3TW protocol are respectively a Bitcoin contract C 1 and an Ethereum smart contract C 2 (see [294; 295; 296] for more details) therefore, the protocol works in both UTXO-based and accountbased blockchains [START_REF] Belotti | A vademecum on blockchain technologies : When, which, and how[END_REF]. Moreover, concerning the protocol strategic behavior we have that "following the protocol" is a Nash equilibrium. Then, the strategy profile (s ˆ1, . . . , s ˆn) that specifies action 1 (follow the protocol) for every player i is a Nash equilibrium.

Proof. Given a strategy profile s = (s i ) i∈N ∈ ∏ j∈N S i whenever ∃i ∈ N such that s i is action 0 then, due to Trent witnessing, the protocol ends up in the original configuration b 0 . The outcome corresponding to the desired configuration b * is reached whenever action 1 is chosen by all the players.

Hence, since u i (b -1 0 (i)) < u i (b -1 * (i)) ∀i ∈ N , action 1 is the dominant best response strategy to all s -i ∀i ∈ N . ■
Let us analyze the normal form game associated to the blockchain swap protocol presented in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] in the case of two owners O = {A, B} swapping two assets A = {x, y} where t P = t T = 2. Normal form games represent situations where players make decision simultaneously. In this cases, a matrix representation (Fig. In order to identify the game's equilibria, dominated strategies (i.e., strategies providing a lower utility than others) have to be eliminated. Two different equilibria are computed : "following the protocol" is a dominant strategy always providing a greater utility for all the other player's strategies, "do nothing" (i.e., choosing action 0) is a weakly dominant strategy that provides the same payoffs for all the other player's strategies. Since dominant strategies are always Nash equilibria [START_REF] Peters | Game theory : A Multi-leveled approach[END_REF], the startegy profile specifying action 1 for every player of the game is a Nash equilibrium.

SUMMARY

Summary

Summary. This contribution formalizes the distributed cross-chain swap problem in the blockchain context where parties exchange assets across multiple blockchains (i.e., inter-operate between different blockchains). To the best of our knowledge this work is the first to propose a complete framework allowing to analyze existing cross-chain swap protocols as normal form games (i.e., non-cooperative games, see Section 2.3.) We prove that (i) following a swap protocol characterized by an effective decision function (e.g. the protocol proposed in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and generalized in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF]) is a subgame perfect equilibrium in dominant strategies while (ii) following a swap protocol characterized by concurrent publishing and snap commitment (e.g. the protocol proposed in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF]) is a Nash equilibrium. Equilibria represent stable solution where no player has incentive in unilaterally deviating from the prescribed swap protocol. Moreover, the protocol in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] ensures that no conforming party is affected by a protocol deviation. However, contrary to what stated in [START_REF] Herlihy | Atomic cross-chain swaps[END_REF], these two conditions cannot ensure protocol atomicity as precised in Section 4.4.1.3. Framework in [START_REF] Zakhary | Atomic commitment across blockchains[END_REF] represents an improvement considering a formal adversary model and a concurrent commitment guaranteeing protocol atomicity. On the other hand, the next chapter analyzes the robustness of cross-chain swap protocols to Byzantine behaviors (i.e., swap participants who may be induced to deviate or irrationally deviate).

INTRODUCTION ON BLOCKCHAIN ROBUSTNESS

Introduction on Blockchain Robustness

Beyond the traditional blockchain architectures (layer-1 protocols), the literature proposes other protocols that respectively define and regulate interactions in an overlaying network (layer-2 protocols) and interactions between different blockchains (cross-chain protocols). Each of these protocols establishes the instructions that a user must follow in order to interact with or through a blockchain.

In a blockchain system players can be classified, as proposed in [START_REF] Aiyer | Bar fault tolerance for cooperative services[END_REF] for classical distributed systems, in three different categories : (i) players who follow the prescribed protocol i.e., altruistic, (ii) those who act in order to maximize their own benefit i.e., rational, and (iii) players who may rationally deviate from the prescribed protocol, i.e., rational Byzantine. The latest category can be redefined, according to [START_REF] Kiayias | Coalition-safe equilibria with virtual payoffs[END_REF], to include any possible arbitrary protocol deviation (including irrational) as Byzantine.

Interactions among users are usually modeled with game theory which analyzes the decision-making process in presence of multiple rational agents, called players or agents.

In the context of blockchain systems, game theoretical frameworks were introduced in [29; 298] to analyze security aspects and incentive compatibility of Nakamoto's consensus protocol (i.e., Proofof-Work [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF]) characterizing the very first blockchain implementation known as Bitcoin. Chapter 3 models the behaviors of users participating to the consensus mechanism (i.e., miners) of the Bitcoin blockchain ; they are considered as individually rational moved by the mere intention to increase their revenues i.e., the rewards earned form the mining activities. Authors in [299; 300; 301] adopt different utility functions for miners and pools that consider costs and relative rewards. Concerning layer-2 and cross-chain protocols, game theoretical analysis are carried out by [302; 17; 6; 303]. These analysis are strictly specific to the particular deployment context than to a generic blockchain. Most of the game theoretical models adopted to design secure and robust blockchain protocols, surveyed in [START_REF] Liu | A survey on blockchain : A game theoretical perspective[END_REF], (i) address protocols characterizing specific blockchain implementations, (ii) analyze miners' behaviors in the consensus phase and (iii) adopt Nash equilibria as solution concept.

Concerning rational agents, the existing analyzes include the study of the equilibria and the evaluation of their properties. The most studied and adopted solution concept in literature is the Nash equilibrium, i.e., a strategy profile in which no player has interest in individually deviating from her own strategy. A first approach to the analysis of robustness is to compare Nash equilibria, through indices such Price of Byzantine Anarchy [START_REF] Moscibroda | When selfish meets evil : Byzantine players in a virus inoculation game[END_REF], Price of Malice [START_REF] Moscibroda | When selfish meets evil : Byzantine players in a virus inoculation game[END_REF] and Price of Anarchy [START_REF] Koutsoupias | Worst-case equilibria[END_REF]. This

INTRODUCTION ON BLOCKCHAIN ROBUSTNESS

approach summarizes the outcomes of the games representing protocols, but it does not show explicitly the implementation risks of such systems. A second approach is to analyze peculiar Nash equilibria.

The authors of [START_REF] Pass | Fruitchains : A fair blockchain[END_REF] take probability into account and extend the concept of Nash equilibrium. In [START_REF] Kiayias | Coalition-safe equilibria with virtual payoffs[END_REF], virtual utility -alternative to the classical game utility -is introduced to capture the blockchain agreement structure.

The analysis of robustness with respect to Byzantine agents was modeled in [START_REF] Amoussou-Guenou | Rationals vs byzantines in consensus-based blockchains[END_REF] with a Bayesian game. The authors provide the analysis of Tendermint protocol [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF]. This method allows making forecasts on the expected outcomes of a game, but it does not provide a comprehensive analysis of the risks. It should be noted that none of the previous works is generic enough to propose a methodology for analyzing the robustness of blockchain protocols to both rational and Byzantine players.

The first generic framework for analyzing the robustness of distributed protocols with respect to the behavior of rational and Byzantine players was proposed by the authors of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] who introduced the concept of mechanism (i.e., a pair game-prescribed strategy). Moreover in [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] authors introduced the notions of (i) k-resilience, (ii) practicality and (iii) t-immunity. A strategy profile is defined as k-resilient if there is no coalition with at most k players having an incentive to deviate from the prescribed protocol. The category of practical strategy profiles is defined when equilibria with weakly dominated strategies are excluded.

In this chapter we follow the line of work opened in [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] and present a game theoretical framework aiming at characterizing the robustness of blockchain protocols to rational and byzantine users' behaviors. More precisely, this work focuses on the analysis of blockchain agents who can act rationally (altruistically or maliciously) or maliciously no matter what. Our contributions can be summarized as follows : a) We prove that t-immunity property defined in [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] is not verified by a large class of blockchain protocols (see Table 5.2). It should be noted that the authors of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] already observed that "t-immunity is often impossible to be satisfied by practical systems" and left open the definition of a weaker property ; b) We introduce the new concept of t-weak-immunity ; a mechanism is t-weak-immune if any altruistic player receives no worse payoff than the initial state, no matter how any set of t players deviate from the prescribed protocol. This new concept is sufficiently strong to capture the 5.1. INTRODUCTION ON BLOCKCHAIN ROBUSTNESS robustness of a large class of blockchain protocols (see Table 5.2) ; c) We identify and prove necessary and sufficient conditions for a mechanism to be k-resilient and t-weak-immune ; d) We define a new operator for game composition and prove that it preserves the robustness properties of the individual games ; e) Using our generic framework and the composition operator we study the robustness to the behaviors of the two main types of blockchain users : transacting parties and validators, both modeled as rational and Byzantine agents. More precisely, robustness to miners (i.e., validators) behaviors is analyzed for Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] and Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF] (i.e., layer-1 protocols). While for layer-2 protocols (the Lightning Network protocol [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], the side-chain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and the cross-chain protocol [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]) robustness is analyzed considering transacting parties' behaviors.

For each one of the analyzed protocols we provide bounds on the number of Byzantine processes in order to verify t-weak immunity. Furthermore, for the same class of protocols we compute bounds on the number of rational processes in order to achieve k-resilience. Our results are reported in Table 5.2.

Interestingly, our analysis allowed us to spot the weakness of the Lightning Network protocol [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF] to Byzantine behavior. Therefore, we propose and further analyze an alternative version of the protocol.

The chapter is structured as follows. Section 5.2 is devoted to the definition of mechanism, (k, t)robustness, necessary and sufficient conditions for optimal resilience and weak immunity and, composition of mechanisms. We apply in Section 5.3 and Section 5.4 the methodology developed in Section 5.2 to prove the robustness of the protocols presented in [1; 2; 3; 4; 5]. Table 5.1 -Immunity and resilience properties for Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF], Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF], Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a sidechain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and a cross-chain swap protocol [5; 6] with respect to the number of rational deviating agents (k ) and the number of Byzantine deviating agents (t) where n is the total number of players in the game.

Protocol k-resilience t-immunity t-weak immunity Results

Tendermint

GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

Game Theoretical Modeling for Blockchain Robustness

In a distributed protocol, agents who run it can either decide to follow the prescribed protocol or not. In case they do not, they deviate from the prescribed protocol by choosing a byzantine behavior.

We would like to model these situations and understand whether the players are incentivized to follow the given advice. In [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] the authors introduce a game theoretical framework based on the concept of mechanism and its properties. In the following we recall and extend the framework of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF].

A game is a tuple Γ = ⟨N, S, u⟩ in which the set of players N corresponds to the agents involved in a protocol. We map all the possible behaviors of the players and define them as their strategies S. Following the protocol corresponds to one and only strategy σ i ∈ S i for every player i. For the sake of simplicity we assign utility u i (s) = 0 for every s ∈ S when the player i is indifferent between the outcome of the strategy profile s and the outcome of the initial state, i.e. the utility given to the players before the game is played. Analogously we assign utility u i (s) > 0 when the outcome of the strategy profile s corresponds to the final state provided by the protocol and u i (s) ≤ 0 when the outcome of s is worse than the initial state. The value of the utility corresponds to the marginal utility with respect to the initial state. The choice of the utility function is arbitrary, once the constraints above introduced are fulfilled.

Given the strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S that corresponds to every player i following the protocol by playing strategy σ i we define the mechanism (Γ, σ).

Definition 5.1 (mechanism [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF]) A mechanism is a pair (Γ, σ) in which Γ = ⟨N, S, u⟩ is a game and

σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is a strategy profile.
Every player is advised to play strategy σ i ∈ S i . The game Γ shows all the possible strategies available to the players.

Players have a very low incentive to play weakly dominated strategies (see Definition 2.6) since they always have available a different strategy that provides no lower outcome in any scenario. A practical mechanism, formally defined below, ensures that these strategies are not included.

Definition 5.2 (practical mechanism [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF]) A mechanism (Γ, σ) is practical if σ is a Nash equilibrium of the game Γ after the iterated deletion of weakly dominated strategies.

GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

Evaluating the resilience of a distributed protocol to Byzantine behaviors corresponds to identifying the properties of the mechanism (Γ, σ). Users can decide to choose a Byzantine behavior for two different reasons. On one hand they can cooperate in order to find a strategy profile that provides a better outcome than the one given by the protocol, i.e. that increases any of their utilities. A mechanism which is optimal resilient, i.e., practical (see Definition 5.2) and strongly resilient (see Definition 5.3), discourages these behaviors. On the other hand some agents can behave maliciously for any reason and bring other players to unpleasant scenarios. In [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] a mechanism is t-immune to this behavior if it provides not inferior utility in the case when at most t players play a strategy different from the one prescribed by the mechanism. This condition has been already identified as being too strong in practice therefore we introduce the property of t-weak-immunity (see Definition 5.25), which means that a player i who chooses the prescribed strategy σ i ∈ S i is never lead to a worse state than the initial one, under the hypothesis that at most t players are byzantine.

In [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] the authors introduce a generalization of Nash equilibrium, k-resilient equilibrium defined formally below. The definition is a generalization of the concept of Nash equilibrium, which can be considered as a 1-resilient equilibrium. Indeed, in a Nash equilibrium no coalition formed by a single player has an incentive to change strategy. In a k-resilient equilibrium there is no coalition of k players that have an incentive to simultaneously change strategy to get a better outcome, i.e. when any of the players identifies a larger utility. Given a coalition of rational players C ⊆ N of size up to k : 1 ≤ k < |N |, the strategy profile σ ∈ S and any other of their strategy profiles τ C ∈ S C we can define k-resilience as follows.

Definition 5.3 (k-resilient equilibrium [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF])

A strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is a k-resilient equilibrium if for all C ⊆ N with 1 ≤ |C| ≤ k, all τ C ∈ S C and all i ∈ C, we have u i (σ C , σ -C ) ≥ u i (τ C , σ -C ).
We say that a mechanism

(Γ, σ) is k-resilient if σ is a k-resilient equilibrium for Γ.
If every strict subset of the players has no incentive to change strategy we say that the strategy profile is strongly resilient (formally, if it is k-resilient for all k ≤ n -1). We say that a mechanism (Γ, σ) is strongly resilient if σ is strongly resilient.

A mechanism (Γ, σ) is optimal resilient if it is practical and strongly resilient.

One of the basic assumption of game theory is that agents are rational. However, in real applications it might happen that agents behave irrationally. There are different reasons for this. Agents might have some limits that do not let them identify and choose rational behaviors. We always work under the assumptions that everything works, but there might be some technical failures that make some actions inaccessible to players. Lastly, the game might be not independent from other games. For instance, some agents might be subject to bribes which entice them to play an irrational strategy. Therefore it is interesting to study strategies that are immune to this type of behaviors. A strategy profile is t-immune if it provides not inferior utility in the case when at most t players play a strategy different from the one prescribed by the mechanism.

Definition 5.4 (t-immunity [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF]) A strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is t-immune if for all T ⊆ N with |T | ≤ t, all τ T ∈ S T and all i ∈ N \ T , we have

u i (σ -T , τ T ) ≥ u i (σ). A mechanism (Γ, σ) is t-immune if σ is t-immune in the game Γ.
The concept of k-resilience denotes the tendency of a set of k players to cooperate to move to a equilibrium different from the one prescribed. On the other hand, the concept of t-immunity evaluates the risk of a set of t players to defect and play a different strategy that can damage the other players.

The two concepts are complementary. In [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] the authors introduced the notion of (k, t)-robust mechanism. A mechanism is (k, t)-robust if it is k-resilient and t-immune.

The property of t-immunity (see Definition 5.4) is too strong and difficult to be verified in practice because it requires that the protocol provided the best outcome no matter which strategy a set of t players choose. In [START_REF] Brenguier | Robust equilibria in mean-payoff games[END_REF] the author generalizes it with the definition of (t, r)-immunity, i.e., that players receive at least u(σ) -r no matter what the other players do. For our purposes we need a more specific definition, that is valid for all players and that is related to a threshold, that we fix equal to zero.

Since zero is the utility provided to players in their initial state, the property of immunity corresponds to guaranteeing at least the value of the initial state to every player. Given a coalition of Byzantine players T ⊆ N of size up to t : 1 ≤ t < |N |, their strategy profile τ T ∈ S T and the set of strategies σ -T of altruistic players i ∈ N \ T we can define t-weak-immunity as follows.

Definition 5.5 (t-weak-immunity) A strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is t-weak-immune if for all T ⊆ N with |T | ≤ t, all τ T ∈ S T and all i ∈ N \ T , we have u i (σ -T , τ T ) ≥ 0. A mechanism (Γ, σ) is t-weak-immune if σ is t-weak-immune in the game Γ. Definition 5.3). Therefore, for all C ⊂ N there always exists i such

GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

u i (σ C , σ -C ) ≥ u i (τ C , σ -C ) (see
that u i (σ C , σ -C ) ≥ u i (τ C , σ -C
), which corresponds to the Definition 2.5 of strong equilibrium. ■

Strong Nash equilibria are easy to be identified, but they are very rare ; indeed, they do not always exist [START_REF] Bernheim | Coalition-proof nash equilibria i. concepts[END_REF]. Therefore, the property of strongly resiliency is even more rare. We thus take into account a different concept of solution, that of stable Nash equilibrium, which tries to identify those Nash equilibria that are more likely to be played. According to definition provided in [START_REF] Hillas | On the definition of the strategic stability of equilibria[END_REF],

stable equilibria fulfill different properties, among which they survive the iterated deletion of weakly dominated strategies. The concept of stable equilibria, which is well studied in literature [248; 249] extends the concept of practical mechanism.

Proposition 5.2 (practicality) If σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) is a stable equilibrium of Γ, then the mechanism (Γ, σ) is practical.

Proof. Stable equilibria survive after the iterated deletion of weakly dominated strategies, therefore the mechanism is practical. ■

In [START_REF] Hillas | On the definition of the strategic stability of equilibria[END_REF] the authors proves that there always exists at least one stable Nash equilibrium, that leads us to the following corollary.

Corollary 5.0.1 For any game Γ there is always at least one σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S such that the mechanism (Γ, σ) is practical.

Indeed, since for every game Γ = ⟨N, S, u⟩ there always exists a stable equilibrium σ ∈ S, from Proposition 5.2 we have that (Γ, σ) is practical.

We now know prove that the properties of strongly resiliency and practicality are independent, and therefore both of them have to be studied. This result comes from the fact that also strength and stability are independent [START_REF] Kohlberg | On the strategic stability of equilibria[END_REF].

Proposition 5.3 The property of strongly resiliency and practicality are independent.

Proof. In order to prove the independence we have to identify 4 examples of mechanism with the following properties : (i) strongly resilient and practical, (ii) strongly resilient and not practical, (iii) not strongly resilient and practical, (iv) not strongly resilient and not practical :

1. We define the mechanism (Γ, σ) such that for all i we have that u i (σ) = 1 and u i (τ ) = 0 for all τ ̸ = σ. The mechanism is strongly resilient. The strategy profile σ is the only Nash equilibrium.

Since there always exists a stable Nash equilibrium, σ is stable and thanks to Proposition 5.2 we have that (Γ, σ) is practical.

2. Let us consider the mechanism (Γ, σ), in which Γ has two players, for all i and for all τ ∈ S we have that u i (τ ) = 1, but for τ = (σ 1 , τ 2 ) with τ 2 ̸ = σ 2 which provides utility u i (τ ) = (0, 1). The mechanism (Γ, σ) is strongly resilient, because u i (σ) ≥ u i (τ ) for all i and all τ ∈ S. However, it is not practical, as player 1 would not consider σ 1 ∈ S 1 , but a different strategy that always provides utility equal to 1.

3. Since strength and stability are independent [START_REF] Kohlberg | On the strategic stability of equilibria[END_REF], there always exists a game Γ in which an equilibrium σ is stable, but not strong. The mechanism (Γ, σ) is not strongly resilient (thanks to Proposition 5.1 and it is practical, since it is stable (Proposition 5.2).

4. It is enough to define a mechanism (Γ, σ) such that σ is not a Nash equilibrium of Γ.

■

The following proposition provides a necessary and sufficient condition to determine if a mechanism is weak immune.

Proposition 5.4 (weak immunity) A strategy profile σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S is weak immune if and only if for all i ∈ N in the game

Γ i = ⟨N ′ , S ′ , u ′ ⟩ with N ′ = {i, j}, S ′ i = S i , S ′ j = S 1 × S 2 × • • • × S i-1 × S i+1 × • • • × S n , u ′ i = u i and u ′ j = -u i the best response τ ′ j ∈ S ′ j to u ′ i gives outcome u ′ i (σ i , τ ′ j ) ≥ 0.
Proof. Let us prove the if part. Since τ ′ j is a best response to σ i , by definition

u ′ j (σ i , τ ′ j ) ≥ u ′ j (σ i , τ ′ ) for all τ ′ ∈ S j . Therefore u ′ i (σ i , τ ′ j ) ≤ u ′ i (σ i , τ ′ )
and so for all τ ′ ∈ S j we have that u ′ i (σ i , τ ′ ) ≥ 0. By construction for every τ -i ∈ S -i there is one and only one τ ′ ∈ S ′ j , which gives u i (σ i , τ -i ) = u ′ i (σ i , τ ′ j ). Hence we have that u i (σ i , τ -i ) ≥ 0 for all τ -i ∈ S -i . The proof for the only if part is analogous, since we can find a one-to-one correspondence among strategies in S and S ′ . ■

The principle is to fix one player i ∈ N at a time and consider all the other players as a unique adversarial player j that sets her strategy in order to reduce the utility of player i. The game Γ i in 5.2. GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS which player i faces an adversarial player j belongs to a specific class of games, called two-player zero-sum games [START_REF] Von Neumann | Theory of games and economic behavior[END_REF], whose Nash equilibria are always in the form (v, -v) with v ∈ R. The term v is called value of the game and corresponds to the minimum value that player i is able to achieve.

Proposition 5.4 states that a strategy profile is weak immune if and only if the best response (i.e., the strategy producing the most favorable outcome) for the adversarial player j assigns to player i a positive outcome v ≥ 0. This condition allows us to check the weak immunity property by looking at only N outcomes from N games, which is more efficient than considering all the possible outcomes of the game Γ. We see in Section 5.4.1.2 how this condition allows us to verify the weak immunity of a mechanism.

Composition of Games and Mechanisms

Blockchains systems are complex protocols designed in a modular way. In order to study the robustness of such complex protocols we analyze the robustness of the individual modules and infer the properties of the system by composition.

We introduce therefore the notion of composition of games. Given two different games A and B, the game A ⊙ B corresponds to players picking a strategy from each game and receiving as utility the sum of the utilities of the two games. The games are intended to be played separately and independently. -N is the set of the players,

-S C := {(s Ai , s Bi ), s Ai ∈ S Ai , s Bi ∈ S Bi , ∀i ∈ N } is the set of strategies, -u C ({(σ Ai , σ Bi )}) := u A ({σ Ai }) + u B ({σ Bi })
is the utility function.

In the context of non-cooperative games linear transformations of utility functions (u ′ i = a • u i + b with a ∈ R + and b ∈ R) are considered invariant transformations since they preserve the main properties of the game [START_REF] Hammond | [END_REF]. Therefore, defining the utility function of the composition of games as the sum of the utility functions is equivalent to defining it for any linear combination. It is possible to

ROBUSTNESS TO VALIDATING USERS' BEHAVIORS IN LAYER-1 PROTOCOLS

Robustness to Validating Users' Behaviors in Layer-1 protocols

In this section we prove the effectiveness of our framework by analyzing the robustness of different blockchain layer-1 protocols. Section 5.3.1 and 5.3.2 analyze Tendermint1 [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] and Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF], respectively. Blockchain users modeled as rational and Byzantine agents are validating nodes (i.e., Tendermint validating nodes and Bitcoin miners analyzed in Chapter 3) who participate to the blockchain consensus phase. as the threshold of n 3 + 1 votes is met, so they both broadcast the values v and v ′ which are however incompatible.

Tendermint

■

We considered the case for a generic n, which cannot give results about weak immunity for values n 3 and 1 3 n + 1. Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] considers only the case of a specific n = 3f + 1 number of players, with threshold ν = 2f + 1. In this specific case, Theorem 5.5 consists in setting t, the number of byzantine players, the following condition for weak immunity : t < n 3 < f + 1. On the other hand, we can state from Theorem 5.6 that we do not have weak immunity for t ≥ 1 3 n + 2 > f + 2. With a similar argument to the one proposed in Theorem 5.6 it is possible to prove that for t = f + 1 or t = f + 2 Tendermint's protocol does not fulfill weak immunity.

Bitcoin

Bitcoin is a permissionless blockchain based on the Proof-of-Work mechanism [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF] where every user has a chance to publish a new block in the distributed ledger. The probability of user to publish/mine a new block (i.e., validator) is proportional to her computational power α. Bitcoin's protocol requires that once a block is mined, it should be broadcast to every other user. In case two or more blocks are mined at the same moment, the players split their effort to mine from any of the blocks (i.e., a fork is generated). Hence, published blocks are not automatically validated ; they are considered as valid when belonging to the longest chain i.e., the longest branch of the ledger called main chain.

As for Tendermint, Bitcoin's protocol can be represented by a mechanism (Γ btc , σ btc ). We take into account the worst-case scenario, in which the byzantine users coordinate, thus they are represented by a single player i. The altruistic users act in the same way and can therefore be represented by a second player j. The strategies of the players correspond to choosing (i) where in the chain add a new block and (ii) when to publish the mined blocks. Player j plays only one strategy defined by σ btc i.e., she follows the protocol by mining on the main chain (the longest one) or splitting her effort if there is more than one chain of the same length available. Since the game is stochastic, we group all the equivalent states of the game in the same class. We consider two states as equivalent if they have the same configuration independently from the precise position in the chain (i.e., the difference between the number of mined blocks by the i and j is the same). In the Bitcoin blockchain a best practice

ROBUSTNESS TO VALIDATING USERS' BEHAVIORS IN LAYER-1 PROTOCOLS

is to consider a block as valid if belonging to a chain where at least B (usually, B = 6) blocks have been published afterwards, because it is presumably considered impossible to create a longer chain that does not include it. This block is invalidated if a fork is made at the previous block and more than B + 1 blocks are published starting from it. In this way, the block does not belong to the longest chain anymore and it is not considered valid.

Definition 5.8 The Bitcoin game is a mechanism (Γ btc , σ btc ) such that the game Γ btc represents the decision-making problem and the strategy σ btc is the prescribed protocol. The game Γ btc is characterized by two players i and j, who have respectively mining power α and 1 -α and every state of the game can be represented by the state class {x k } k∈{0,1,...,B+1} , where x k is the number of blocks mined, yet not published, at level k by player i. The block at level k = 0 is the only one to be published. The initial state of the game is {x k = 0} ∀k ∈ {0, 1, . . . , B + 1}, while the final state of the game is represented by the state class with value x B+1 ≥ 1. While player j has only one possible strategy σ btc , player i can choose which branches to mine from (i.e. at which level k add the block). The utility of the players corresponds to the number of bitcoins they own. The game theoretical framework let us state the following results on Bitcoin's mechanism robustness. Any subset of players T with |T | = t having mining power α > 0 have a small probability, not negligible, to perform a successful attack, by building a longer chain which does not include a block which was already considered valid (Theorem 5.7).

Proposition 5.5 The probability for a player with mining power α to find n blocks before any other player can find at most m blocks is

P (n, m) = n+m-1 ∑ i=n ( n + m -1 i ) α i (1 -α) n+m-1-i .
Proof. It's enough to compute that among n + m -1 blocks at least n are being mined by the player with mining power α.

P (n, m) = n+m-1 ∑ i=n ( n + m -1 i ) α i (1 -α) n+m-1-i .

■

If m = 1 we have that P (n, 1) = α n .

ROBUSTNESS TO VALIDATING USERS' BEHAVIORS IN LAYER-1 PROTOCOLS

Theorem 5.7 The Bitcoin mechanism (Γ btc , σ btc ) is not t-weak-immune for any t.

Proof. Let us suppose that a player with mining power α > 0 plays the strategy of block withholding if she has mined more blocks than the main chain. When she reaches more than B blocks than the main chain, she publishes all of them, thus invalidating the others. Due to Proposition 5.5, at every new block she has approximately probability α B > 0 to perform the attack. When the number of attempts goes to ∞, the probability to perform the attack goes to 1. Thus it is almost sure that any subset of players T of cardinality |T | = t with total mining power α, with α > 0, the attack will be successfully performed. ■ Theorem 5.8 The Bitcoin mechanism (Γ btc , σ btc ) is k-resilient if k players have at most α ≤ 3 20 as total mining power.

Proof. Let us suppose that i is a rational player and j is an altruistic player, i.e. it follows the protocol.

The goal of player i is to maximise the number of bitcoins owned by her. A combination of attacks can make her owning more bitcoins than the ones she would receive by following the protocol. Specifically, she can gain bitcoins by double spending them. She validates a block in which she spends M bitcoins, then she creates a fork before the block which creates a longer chain from. Performing such selfish mining attack [START_REF] Eyal | Majority is not enough : Bitcoin mining is vulnerable[END_REF] makes the player i lose some bitcoins. Indeed, creating forks includes the risk of creating blocks which can eventually not belong to the longest chain ; thus, the reward R given by these blocks would get lost. Let us define N (α), the average number of blocks lost in the attack by player i, who has computation power α. The player i chooses to perform the attack if M > R • N (α), i.e. if the double spended bitcoins are greater than the average reward lost in the attack. The values of M and R are parameters, while N (α) depends on the strategy chosen by i. Since i is a rational player, she chooses the optimal strategy, i.e. the strategy that minimises N (α).

We thus have to identify the optimal strategy. The probability for player i to add a new block depends on how the other players are split in mining the other blocks. If there are m forks, there is

α ′ := α α+ 1-α m+1
chance for player i to mine the next block and 1-α ′ = 1-α m+1 α+ 1-α m+1 chance for player j to mine the next block. Player i has probability α ′ to add a new block at the level k that she chooses, i.e. to add 1 to the value of any x k . Player j has probability 1 -α ′ to mine a block, which is added at level k = 0.

The chain is increased by one level, i.e. the number of forks x 1 created at level k = 1 are published.

The states are moved by one position, i.e. x k → x k-1 . From every state s = {x k } k∈{0,1,...,B+1} player

ROBUSTNESS TO VALIDATING USERS' BEHAVIORS IN LAYER-1 PROTOCOLS

a transaction to be published within ∆ > 0 blocks is :

Φ ∆ (α) = α 1 -α - ∆-1 ∑ k=1 (1 -Φ ∆-k (α)) • α k • (1 -α) k • M (k),
where M (k) is a function defined in [START_REF] Inc | The on-line encyclopedia of integer sequences, year = 2021[END_REF] that maps natural numbers to the sequence In case n > 1 we can make a similar argument, but excluding the cases in which the state +1 is achieved too early. We have that :

Φ n (α) = α 1-α - ∑ n-1
k=1 p • q where p is the probability of not achieving +1 with n -k blocks left and q is the probability of getting to +1 in 2k steps. This leads us to the formula :

Φ n (α) = α 1-α - ∑ n-1 k=1 (1 -Φ n-k (α)) • α k • (1 -α) k • M (k)
, where M (k) is a function defined in [START_REF] Inc | The on-line encyclopedia of integer sequences, year = 2021[END_REF] that maps natural numbers to the sequence 1, 1, 2, 5, 13, 42 . . . . ■

Robustness to Transacting Users' Behaviors in Layer-2 protocols

In this section we prove the effectiveness of our framework by analyzing the robustness of three different layer-2 protocols. Section 5.4.1 analyzes Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a protocol on top of the Bitcoin blockchain. Section 5.4.2 addresses the side-chain protocol Platypus [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] while Section 5.4.3 presents an analysis on the cross-chain swap protocol presented [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] and modeled in Chapter 4. Rational and Byzantine behaviors are modeled for blockchain users that in this section (as well as in Chapter 4) are transacting parties.

Lightning Network

Bitcoin faces a problem of scalability, in terms of speed, volume and value of the transactions. A transaction is confirmed only once the block to which it belongs is part of a chain with at least D blocks in front of it (under the convention set by the Bitcoin protocol D = 6). On average a new block is validated every T minutes (within Bitcoin, T = 10), thus it takes around T • D = 60 minutes for a transaction to be confirmed, a value that cannot be reduced. Moreover, the number of transactions in a block is limited. Bitcoin cannot bear a sudden upsurge in volume of transactions. Since not all the requests for transactions can be included in a block, some of them are prioritised. The criterion used to order the transactions is the value of the fee that a user pays to the mining pool who validates the block. Therefore performing a lot of transactions on the network can be expensive, since a lot of fees have to be paid.

In order to overcome these issues authors in [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF] introduce a layer-2 class of protocols called Lightning Network. The latter allows users to create bidirectional payment channels to handle unlimited

B C1b AB DN ES C1a AB ( 1 2 , 1 2 ) (0, 1) (0, 1) A DN (1, 0) (-1, -1) (-1, -1) ES (1, 0) (-1, -1) (1, 1)
First, we assume that the channel (x A , x B ) is funded by both players i.e., x A , x B > 0. If one of the two players has no asset involved in the channel, we have to model the situation with a degenerate game, in which she can play any possible strategy. We recommend users to never unilaterally fund the channel.

Indeed, if we drop the assumption that both players fund the channel, we have to consider a different modelisation. For instance, if B does not fund the channel we have that x B = 0. No matter what her strategy chooses, she gets nothing. We fix the utility of any outcome to 1 because it corresponds to the outcome of closing the channel. The payoff matrix of the game is the following :

B C1b AB DN ES C1a AB ( 1 2 , 1) (0, 1) (0, 1) A DN (1, 1) (-1, 1) (-1, 1) ES (1, 1) (-1, 1) (1, 1)
This is a case of degenerate game, in which player B can theoretically choose any possible strategy, even doing nothing DN .

The players have three different strategies : publishing their commitment, seeking a deal to create a new transaction ES or just doing nothing DN . We assign null utility to players who receive their asset after ∆ blocks, positive utility (normalized to 1) if they receive it immediately, negative utility if they cannot redeem their cryptoassets. The players receive null payoffs if they get their asset within

ROBUSTNESS TO TRANSACTING USERS' BEHAVIORS IN LAYER-2 PROTOCOLS

∆ blocks, because they return to the initial state. For instance, this is case for player A if the strategy profile chosen by the players is (C1a AB , ES), i.e. if B seeks a deal but A unilaterally closes the channel.

The players receive a positive outcome (normalised to 1) if they receive their asset immediately, as for instance if they reach a deal (ES, ES). The players receive a negative outcome (normalised to -1) if their asset is stuck in the channel, such as in the case in which A seeks a deal but B does nothing (DN, ES). In case both users decide to unilaterally close the channel (C1a AB , C2a AB ), only one between C1a and C1b can be published. They have the same chance ( 12 ) for their transaction to published, leading to any of the state (0, 1) and (1, 0) with equivalent probability. Therefore the utility can be computed as a weighted average : 1 2 (0, 1)

+ 1 2 (1, 0) = ( 1 2 , 1 2 ).
The protocol recommends the strategy profile σ cl = (ES, ES) i.e., that both players seek a deal.

In the following we analyze the properties of the mechanism (Γ cl , σ cl ).

Theorem 5.12 Under the assumption x A > 0a or x B > 0, the mechanism (Γ cl , σ cl ) is optimal resilient, but not weak immune.

Proof. The utility u(σ cl ) = (1, 1) cannot be increased by any other strategy profile, therefore the mechanism (Γ cl , σ cl ) is strongly resilient. To prove that the mechanism is not weak immune it is sufficient to show a counterexample. Indeed, if

A chooses ES as required by the protocol and B chooses the Byzantine strategy DN , player A receives

a negative outcome u A (σ cl A , DN ) = u A (ES, DN ) = -1. ■
Since the mechanism is not weak immune, it is not immune either. We thus provide an alternative protocol that can satisfy the property of weak immunity.

Theorem 5.13 Under the assumption x A > 0 or x B > 0, the only weak immune mechanism is (Γ cl , σ * ) with σ * = (C1a AB , C2a AB ).

ROBUSTNESS TO TRANSACTING USERS' BEHAVIORS IN LAYER-2 PROTOCOLS

which is more valuable than the one stored in the channel. We assign a negative value to the states in which players lose their cryptoassets or part of them.

Definition 5.11 The updating game Γ up is a game in extensive form, with two players N = {A, B} and 5 nodes, labeled by a number (1 is the vertex) :

1. A has two actions available : C2b •• which provides outcome (0, 0) ; C2b A• which leads to node 2.

2. B has three actions available : C2a •• which provides outcome (0, 0) ; C2b AB which provides outcome (1, 1) ; C2a •B which leads to node 3.

(x A , x B ) → (x A -δ -ϵ, x B + δ + ϵ)
and (y B , y C ) → (y B -δ, y C + δ). The protocol for routed payments lets the receiver C trigger both payments at the same moment :

1. C creates a random data R and hashes it : H = hash(R). Then, she sends H to A. , which provides outcome (0, 0, 0), or H AB A , which leads to node 3.

B has two actions available : either H BC

•

, which provides outcome (0, 0, 0), or H BC B , which leads to node 4.

4. C has two actions available : either N , not disclosing R to B, which provides outcome (0, 0, 0), or Y , disclosing R to B, which leads to node 5. The HTLCs introduced in the protocol work independently from the routing protocol. We can model them with two different mechanisms : (Γ AB , σ AB ) for H AB and (Γ BC , σ BC ) for H BC . The mechanism (Γ AB , σ AB ) represents the HTLC deployed on the channel A-B, while the mechanism (Γ BC , σ BC ) refers to the HTLC implemented on the channel B-C. The HTLCs belong to two different channels, so they are independent one from another. The assumption from the routing protocol is that in both HTLCs the transactions can be triggered, but this is true only if every transaction can be published within ∆ blocks (see Section 5.4.1.4). Under this assumption, the protocol for routed payments is independent from the protocol for HTLC, because it is external with respect to the channel, while the HTLCs work within the channel. The routed payment is thus represented by three independent protocols (Γ rout , σ rout ), (Γ AB , σ AB ), and (Γ BC , σ BC ). Therefore we analyze the properties of its mechanism by defining the composition of the three games

B has two actions available

(Γ rout ⊙Γ AB ⊙Γ BC , {σ rout i , σ AB i , σ BC i }). Theorem 5.19 The mechanism (Γ rout ⊙ Γ AB ⊙ Γ BC , {σ rout i , σ AB i , σ BC i }
) is optimal resilient and weak immune with probability 1 -Φ ∆ (α).

Proof. We analyze the mechanism (Γ up , σ up ) under the assumption that it is always possible to publish a transaction within ∆ blocks, otherwise it is not possible to validate the breach remedy transactions in time. The probability that this happens when a byzantine agent with computational power α attacks the Bitcoin blockchain is 1 -Φ ∆ (α) (see Theorem 5.9). The operator composition (see Definition 5.6) is invariant with respect the properties of the mechanisms. Thanks to Theorems 5.16 and 5.18 we have that (Γ rout , σ rout ), (Γ AB , σ AB ) and (Γ BC , σ BC ) are practical. Therefore, with Theorem 5.2 we have that their composition (Γ rout ⊙ Γ AB ⊙ Γ BC , {σ rout i , σ AB i , σ BC i }) is practical. Analogously, thanks to Theorems 5.16 and 5.18 we have that every single mechanism is k-resilient for all k and t-weak-immune for all t. Theorems 5.3 and 5.4 allow us to say that the composition -Phase 1 ; only the player p 0 is involved. The player p 0 has two actions : either complete it Y or not N . If she does not, the outcome is 0 for all players.

(Γ rout ⊙ Γ AB ⊙ Γ BC , {σ rout i , σ AB i , σ BC i }) is k-resilient
-Phase 2 ; every player within normal users play at the same time. Everyone dispose of the same two actions : broadcasting their message Y or not N . If the message is not broadcast for player i, her utility is always 0.

-Phase 3 ; the validators can choose within a set of actions a u with u ⊆ U i.e., they can validate all the messages for the users within the set u. The cardinality of the set of their actions is equal to 2 |U | . The utility for the validators corresponds to the number of valid transactions which are broadcast.

-Phase 4 ; the validators can choose within a set of actions in the form (b t , s t ′ ), where t and t ′ are any subset of transactions broadcast in Phase 3. The action b consists in broadcasting the transactions belonging to the set t until ⌊2m v /3⌋ + 1 validators receive it, while s means to send the transactions in t ′ .

We define the mechanism (Γ cr , σ cr ), where σ cr ∈ S is the strategy of following the protocol i.e., for normal users u the strategy is σ cr u = Y , while for validators v the strategy is σ cr v = (a u * , b t * , s t * ), where u * is the set of users who send a message and t * is the set of transactions broadcast in Phase 3. We thus analyze the properties of the mechanism.

Theorem 5. [START_REF] Nakamoto | Bitcoin : A peer-to-peer electronic cash system[END_REF] The mechanism (Γ cr , σ cr ) is not t-immune for any t.

Proof. It is enough to prove that the mechanism is not 1-immune. A mechanism is 1-immune if every player does not reduce her utility if only one other player is choosing a Byzantine behavior (see Definition 5.4). This property is not fulfilled, indeed if in Phase 1 the process p 0 chooses N rather than σ cr p 0 = Y , the utility for every player is 0, which is lower than the utility provided by σ cr . ■

In [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] it is proved that no wrong transaction can be validated if there are at most ⌊ mv 3 ⌋ corrupted players. This property cannot be expressed with the concept of immunity, which is too strong ; to capture this information we exploit the definition of t-weak-immunity (see Definition 5.25). Within message is the only strategy played at the equilibrium. Therefore, the payoffs generated by σ cr cannot be increased and the mechanism Γ cr , σ cr is strongly resilient.

For normal users the strategy Y dominates N (the utility is 1 which is larger then 0), while for validators (a U , b U , s U ) dominates every other strategy ; any other strategy would provide a payoff lower than |U |. Hence, the strategy profile σ cr is the only one with weakly dominating strategies and thanks to Proposition 5.2 we get that the mechanism is practical.

In order to prove weak immunity, we apply Proposition 5.4. We need to prove that every player never gets negative utility when following the protocol, when all the other players become adversarial.

Validators do not have negative utility, thus it is enough to prove that neither the other users do. In the worst case scenario for user u ∈ U a wrong process is validated. To do so, another user u ′ ∈ U should be publish it and the validators should approve it. Under the assumption that there at most ⌊ mv 3 ⌋ corrupted processes, in [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] it is proved that this is not possible. The proof follows from the intuition that the Byzantine validators, owning less than a third of the network, cannot validate two different transactions including one which can damage the user u. Therefore, users never get negative utility if there are at most ⌊ mv 3 ⌋ Byzantine players. This corresponds to the definition of ⌊ mv 3 ⌋-weak-immunity (see Definition 5.25). ■

Cross-Chain Swap

In this section we analyze the protocol introduced in [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF], that allows two users to swap assets belonging to two different blockchains, which do not communicate with each other. In [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] the authors introduce a theoretical framework proving that the protocol is correct for those players who are altruistic, no matter what the others do. In the following we prove that the cross-chain swap protocol [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] satisfies the (k, t)-weak-robustness.

The protocol, presented in Section 4.4.1, is based on transactions that have to be published within two different time intervals, ∆ Bob and ∆ Alice on the corresponding blockchain with ∆ Alice < ∆ Bob .

To recall the protocol we presented before. Alice creates two transactions on the Bitcoin blockchain : 1. A can either Y , pick a random string x, create TX1 and TX2, then send TX2 to B, or doing none of them N . The action Y leads to node 2, while the action N leads to the outcome (0, 0).

B can either Y , sign TX2

, that leads to node 3, or N refusing to do it, with outcome (0, 0).

3.

A can either do nothing N , with thus outcome (0, 0), or Y publish TX1 on the Bitcoin blockchain, that leads to node 4.

4.

Both A and B have available two actions : either Y publish TX2 before that x is revealed or N not. If any of the two does so, the outcome is (0, 0). Otherwise, A reveals x and (N, N ) leads to node 5.

B can either Y publish

x on the Bitcoin blockhain or N not doing it. If she does, the outcome is

(1, 1). If she does not, the outcome is (1, -1).

The strategy profile recommended by the protocol is σ 1 = ({Y, Y, N }, {Y, N, Y }), respectively played at nodes ({1, 3, 4}, {2, 4, 5}). Until x is revealed, the transactions cannot be triggered, therefore they provide null payoff. When x is revealed on the other chain, A has received the litecoins (thus with payoff equal to 1). If at step 5 B reveals x, she triggers the contract and receives the bitcoins (payoff equal to 1). Otherwise she has lost her asset in litecoins (negative payoff -1). 1. B can either Y , create TX3 and TX4 and send the latter to A, or doing nothing N . The action Y leads to node 2, while the action N leads to the outcome (0, 0).

2.

A can either Y , sign TX4, that leads to node 3, or N refusing to do it, with outcome (0, 0).

3. B can either do nothing N , with thus outcome (0, 0), or publish TX3 on the Litecoin blockchain (Y ), that leads to node 4.

4.

Both A and B have available two actions : either publish TX4 (Y ) before that x is revealed or not (N ). If any of the two does so, the outcome is (0, 0). Otherwise, A reveals x and (N, N ) leads to node 5.

5.

A can either publish x on the Litecoin blockhain (Y ) or not doing it (N ). If she does, the outcome is (1, 0). If she does not, the outcome is (0, 0).

Figure 5.17 -The game trees of G 1 and G 2 .

5.5. SUMMARY

Summary

Summary. The contribution proposes the first general game theoretical framework that models the robustness of blockchains towards rational and Byzantine behaviors. Blockchain users faced with a blockchain prescribed protocol may act rationally (following or deviating according to their personal utility) or as a Byzantine agent (i.e., deviating from the protocol for any possible arbitrary reason even irrational). This chapter models the behaviors of blockchain users acting as validating nodes (Section 5.3) and transacting parties (Section 5.4). We identify the necessary and sufficient conditions for a protocol to be robust (defined as the conjunction of two properties : k-resilience and t-weak immunity) and develop a methodology to characterize the robustness of complex protocols via the composition of simpler robust building blocks. The effectiveness of our framework is proved by its capability to capture the robustness of various blockchain protocols such as Bitcoin, Tendermint, Lightning Network, side-chain and cross-chain protocols. Our work continues the work of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] that introduced the notion of robustness defined in terms of t-immunity and k-resilience. The framework of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] was never used till our study in the context of blockchain protocols.

Using the framework of [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] we prove that a large class of blockchain protocols (see results in Table 5.2) does not satisfy the t-immunity property.

It should be noted that our negative result related to the t-immunity property does not depend on the specific choice of a utility function. Therefore, we propose a relaxation of this property i.e., t-weak immunity and analyze the t-weak immunity of a large class of blockchain protocols. For each one of them we prove bounds on the number of Byzantine processes allowed for this property to hold. Furthermore, for the same class of protocols we compute bounds on the number of rational processes in order to achieve k-resilience.

Conclusion General Conclusions of the Thesis

For a new technology to realize its full potential, a lot of circumstances need to co-exist before network effects can be realized. In order for the technology to bring in systemic efficiencies, a critical mass needs to be attained. As an infrastructure technology, all major players in the market need to collaborate to define standards in a democratic manner. The blockchain community is indeed witnessing unprecedented levels of industry collaboration between players who are otherwise competitors in the space. Because of the cost of moving from one infrastructure technology to the next, an collaborative approach is the most promising way forward. This is the direction we insisted on in the first part of this thesis and during my three-years working experience within the "Blockchain and Crypto-asset Programme" of Caisse des Dépôts Groupe [START_REF]Caisse des Dépôts Groupe[END_REF].

From a societal perspective, while there has been an exponential increase in the interest around blockchain technologies, there is a huge lack of technical experts. Currently, blockchain engineers become one of the most payed and required jobs, yet there are really few recognized courses to train engineers to fulfill the existing lack of blockchain experts.

On the other hand, there are more and more actors joining existing blockchain network for variety of reasons ; speculation, asset tokenization, blockchain intermediary service, gaming, smart contract applications and so on so forth. Any new node of the network represents a user intended to interact with the network of peers. Interactions, of different nature, might contribute to the durability as well as the destruction of a blockchain system.

Contributions presented in the thesis analyze the different behaviors of blockchain users by considering them as rational agents, fully aware of all actions available to them and capable of choosing the one they feel is the best for themselves. -Immutabilité : alors que les registres partagés permettent la manipulation des données par une autorité centrale, les registres distribués travaillant avec des informations répliquées protègent les données contre toute sorte de falsification et d'altération ; sauf dans les situations où la majorité des efforts du réseau sont consacrés à modifier le registre [START_REF] Conte De Leon | Blockchain : properties and misconceptions[END_REF] ou lorsque les seuils de l'adversaire sont dépassés (voir la section 1.4.1.3). L'immutabilité des données rend les données accessibles et gérables par différentes entités qui ne se font pas confiance.

-Intégrité, Authenticité and Non-Répudiation : le hachage des données garantit que les données ne sont pas modifiées pendant leur transmission (i.e., l'intégrité). De plus, l'origine d'une transaction peut être vérifiée par la diffusion de la clé publique de l'expéditeur, tandis que la preuve de l'action d'envoi est représentée par la procédure de signature des données impliquant la clé privée (i.e., l'authenticité et la non-répudiation). Le schéma de signature de la blockchain combinant la cryptographie asymétrique et le hachage de données est présenté dans la section 1.2.4.

-Auditabilité : Les transactions dans les systèmes blockchain doivent être validées et vérifiées ; ainsi, chaque transfert de données doit être visible par tous les utilisateurs dans son intégralité.

De cette façon, toutes les opérations blockchain sont traçables via des d'audits. Les utilisateurs qui accèdent aux blockchains peuvent voir le registre des données dans son intégralité.

La conjonction des caractéristiques ci-dessus qualifie la technologie à un niveau de sécurité assez élevé, la différenciant de la base de données distribuée classique.

Jeux coopératifs

Afin de caractériser la théorie des jeux coopératifs, il est crucial d'identifier un ensemble de joueurs et de définir une fonction caractéristique pour les jeux identifiant comment les agents coopératifs partagent quelque chose au sein de leur coalition.

SYNTH ÈSE

Une attaque contre un pool désigne le comportement d'un mineur qui diffère de la pratique par défaut (la pratique honnête) et qui met en péril le bien-être collectif du pool. Les mineurs attaquent un pool afin d'obtenir une récompense plus élevée i.e., les mineurs se comportent comme des agents rationnels dont les décisions sont motivées par le gain attendu. Les mineurs peuvent attaquer leur pool au moment de la déclaration de leur preuve de travail (share). Plus précisément, ils peuvent (i) retarder la déclaration du share (i.e., block-withholding) et/ou (ii) déclarer le share ailleurs (i.e., pool-hopping). Le premier attaque implique un retard de la validation d'un bloc et de la possession de la récompense associée. Le "pool-hopping" est une attaque où les mineurs "sautent" d'un pool à un autre en fonction de leur attractivité en terme de rémunération.

Pool-hopping et Stratégies de Rémunération

Les méthodes de récompense [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] paient généralement selon une division en rounds, où un round est le temps écoulé entre deux validations de blocs différentes effectuées par le même pool. Ainsi, le pool distribue la récompense du bloc entre les mineurs à la fin du round, en proportion de leur contribution au cours du round. Meni Rosenfeld montre dans [START_REF] Rosenfeld | Analysis of bitcoin pooled mining reward systems[END_REF] que les pools utilisant des systèmes proportionnels encouragent des pratique de pool-hopping dans le sens où le saut de pool est plus rentable que le minage en continu. Notre contribution [START_REF] Belotti | Bitcoin pool-hopping detection[END_REF]

δ ˆhop ≤ δ hop ⇔ β i -β * i ≥ α i -α * i .
Nous avons prouvé que l'intérêt hopping pour la fonction de récompense basée sur CEL est plus faible par rapport à l'intérêt donné par R (i.e., β i -β * i ≥ α i -α * i ) avec la Proposition 3.5.

SYNTH ÈSE

Chapitre 4

Ce chapitre est consacré à l'analyse (i) du problème du cross-chain swap distribué dans le contexte Notre cadre théorique nous permet de caractériser les équilibres de deux protocoles représentatifs présentés respectivement dans [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] et [START_REF] Zakhary | Atomic commitment across blockchains[END_REF]. Dans le cas du protocole proposé dans [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] et généralisé dans [START_REF] Herlihy | Atomic cross-chain swaps[END_REF],

suivre le protocole est l'unique équilibre de sous-jeu parfait (en stratégies dominantes i.e., toutes les autres stratégies offrent une utilité inférieure), alors que dans le cas du protocole proposé dans [START_REF] Zakhary | Atomic commitment across blockchains[END_REF],

suivre le protocole est un équilibre de Nash. Le jeu de forme extensive associé au premier protocole est représenté en Fig.

SYNTH ÈSE

Chapitre 5

Dans ce chapitre, nous proposons un cadre théorique, avec la théorie des jeux, qui caractérise formellement la robustesse des systèmes blockchain généraux en termes de résilience aux déviations rationnelles et d'immunité aux comportements byzantins. Les utilisateurs blockchain rationnels confrontés à un protocole blockchain à suivre peuvent agir de manière altruiste (en suivant le protocole) ou malveillante (en s'écartant du protocole) en fonction de leur utilité personnelle. En revanche, les utilisateurs byzantins s'écartent du protocole en toute situation (même en agissant de manière irrationnelle).

Modélisation de la Robustesse des Blockchains par la Théorie des Jeux

Le premier cadre générique d'analyse de la robustesse des protocoles distribués par rapport au comportement des joueurs rationnels et byzantins a été proposé par les auteurs de [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] qui ont introduit le concept de mécanisme (i.e., une paire jeu et stratégie prescrite). Robustesse aux Comportements des Utilisateurs dans les protocoles layer-1 et layer-2

À l'aide de notre cadre théorique et de l'opérateur de composition, nous avons étudié la robustesse aux comportements des deux principaux types d'utilisateurs blockchain : parties contractantes et noeuds de validation, les deux modélisés comme des agents rationnels et byzantins. Plus précisément, la robustesse aux comportements des validateurs est analysée pour Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] et Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF] (i.e., les protocoles layer-1). Pour les protocoles layer-2, (Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], le protocole side-chain [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] et le protocole cross-chain [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]), la robustesse est analysée en tenant compte des comportements des parties contractantes. Nos résultats sont présentés dans le tableau 5.2. Notre analyse nous a permis de repérer la faiblesse du protocole Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF] face au comportement byzantin. Par conséquent, nous avons proposé et analysé plus en détail une version alternative du protocole. Les contributions présentées dans la thèse analysent les différents comportements des utilisateurs blockchain en les considérant comme des agents rationnels, pleinement conscients de toutes les actions à leur disposition et capables de choisir celle qu'ils estiment être la meilleure pour eux-mêmes. Le manuscrit prend en considération différents utilisateurs ainsi que différentes blockchains.

Adoptant une approche agnostique, ce travail analyse les caractéristiques et attributs de la blockchain qui rendent les cas d'usage basés sur la blockchain plus performants ou plus innovants. Une revue de l'utilisation de la blockchain et du type de blockchain à utiliser est fournie dans le chapitre 1.

Après cet aperçu, une analyse formelle est effectuée en combinant la théorie des systèmes distribués et la théorie des jeux (chapitre 2) afin d'analyser les comportements des utilisateurs opérant sur des systèmes de blockchain et de DLT. Ce mode de fonctionnement diffère sensiblement selon le type d'utilisateurs. Les contributions présentées dans les chapitres 3-5 analysent à la fois les utilisateurs qui adoptent simplement la technologie comme moyen de paiement/transfert (i.e., les parties qui effectuent des transactions) et les utilisateurs qui maintiennent le réseau en participant au processus de consensus (i.e., les noeuds de validation également appelés mineurs). Les limites de la rationalité sont prises en compte en analysant la robustesse de la blockchain aux comportements rationnels et byzantins (Chapitre 5).

Les questions de recherche ouvertes par les contributions présentées dans ce manuscrit concernent à la fois la modélisation avec la théorie de jeux (comportements rationnels et concepts de solution) et les types de blockchain analysés (comportements de blockchain et protocoles de consensus).

1. 1

 1 Blockchains data model comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Blockchains propagation mechanism comparison. . . . . . . . . . . . . . . . . . . . . . 1.3 Blockchain peers acting as 'transacting parties', 'leaders' and 'validators' in the different platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Summary about consensus mechanisms: comparative analysis of PoX consensus algorithms 1.5 Summary about consensus mechanisms: comparative analysis of BFT and BFT-based consensus algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Reading list on blockchain application domains . . . . . . . . . . . . . . . . . . . . . . 2.1 Three bankruptcy solutions and some of their properties. . . . . . . . . . . . . . . . .

1. 1

 1 DLT evolution: from the traditional ledger to blockchain. . . . . . . . . . . . . . . . . 1.2 The different participation modes characterizing blockchains and DLTs. After a first distinction based on the reading rights (i.e., permissionless and permissioned), the second distinction is based on writing rights of the data on the ledger. . . . . . . . . . . . . . 1.3 Representation of a blockchain structure. . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Merkle hash tree procedure example: duplicated (hashed) transactions are marked in orange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. 6

 6 An example of UTXO-based transfers in Bitcoin. . . . . . . . . . . . . . . . . . . . . . 1.7 The Transaction Journey. Once created the transaction is signed by the data-sender. Verification checks are performed upon block creation by the leading nodes. Transaction can be collected in a block either before being transmitted to the validating nodes or afterwards. The block of transactions is then validated, propagated and confirmed. . . 1.8 Evolutionary route of consensus protocols in five classes from pre-blockchain to postblockchain protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIST OF FIGURES 1.9 When to use blockchain, and which type, instead of adopting a traditional database system. Red circles represents trade-off points between crucial aspects for the different blockchain use-case. The red arrows indicate the consequence of giving priority to one aspect rather than the other, while black arrows report answers to all the questionscoming with an order -of anyone interested in the blockchain technology. 'tps': transactions per second. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Game Γ in extensive form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Game Γ in normal form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Transaction sub-network. Each arrow is labeled with sender's address. CBtx, Trtx, Rewtx are respectively coinbase, transferring and rewarding transactions. . . . . . . . 3.2 Address sub-network related to Fig. 3.1 example. . . . . . . . . . . . . . . . . . . . . . 3.3 User sub-network related to Fig. 3.1 example. . . . . . . . . . . . . . . . . . . . . . . . 3.4 Simplistic miners' positioning. Blocks are represented with gray boundaries. Vertical lines associate each round end with the corresponding rewarding transaction. . . . . . 3.5 Realistic miners' positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Pool-miners graph representation. The left blue node is Kano pool and the right blue node is Slush pool. Detected pool-hoppers are highlighted in red. Edge thickness and color depend on the frequency of users interactions. . . . . . . . . . . . . . . . . . . . 3.7 Daily number of hoppers and hops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Heat map: daily hopping intensity per hopper. . . . . . . . . . . . . . . . . . . . . . . 3.9 Inter-hopping time boxplot distributions (logscale). . . . . . . . . . . . . . . . . . . . . 3.10 Boxplot distributions of rewarding transactions BTC values (logscale). . . . . . . . . . 3.11 Correlation plot: BTC price vs number of hops. . . . . . . . . . . . . . . . . . . . . . . 3.12 CDF of every p n (α), with n ∈ {3, 10, 20, 30, 50}. . . . . . . . . . . . . . . . . . . . . . . 4.1 Digraph swap protocol representation of the sequence σ = ({a, c}, {1, 2}, {X 1 (a) = 2, X 1 (c) = 1}), ({b, e}, {1, 3}, {X 2 (b) = 3, X 2 (e) = 1}), ({d}, {2}, {X 3 (d) = 2}). . . . . .

Content

1. 1

 1 Introduction on Blockchain and DLTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.2 Blockchain Structure and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 1.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 1.2.2 Permissionless and Permissioned Participation Modes . . . . . . . . . . . . . . 37 1.2.3 Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.2.4 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.2.5 Blockchain Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 1.3 Journey of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 1.3.1 Transaction Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 1.3.2 Transaction Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 1.3.3 Transaction Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 1.3.4 Transaction Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 1.3.5 Blockchain Actors and Corresponding Roles . . . . . . . . . . . . . . . . . . . . 55 1.4 Agreement in Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 1.4.1 Agreement in Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . 58 1.4.2 Consensus in Distributed Systems and Blockchains . . . . . . . . . . . . . . . . 61 1.4.3 Summary of Consensus Mechanisms and Their Evolution . . . . . . . . . . . . 70 1.4.4 Comparison between Blockchain Consensus Protocols . . . . . . . . . . . . . . 71 1.5 Blockchain Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 1.5.1 When to Use Blockchain? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 1.5.2 Which Blockchain to Use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 1.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Figure 1 . 1 -

 11 Figure 1.1 -DLT evolution : from the traditional ledger to blockchain.

Figure 1 . 2 -

 12 Figure 1.2 -The different participation modes characterizing blockchains and DLTs. After a first distinction based on the reading rights (i.e., permissionless and permissioned), the second distinction is based on writing rights of the data on the ledger.

Fig. 1 .

 1 Fig. 1.2 illustrates the different DLT participation modes presented. The participation mode has a braking impact on the decentralization trend in distributed consensus, as we develop in Section 1.4.

Figure 1 . 3 -

 13 Figure 1.3 -Representation of a blockchain structure.

Figure 1 . 4 -

 14 Figure 1.4 -Merkle hash tree procedure example : duplicated (hashed) transactions are marked in orange.

Fig. 1 .Figure 1 . 6 -

 116 Figure 1.6 -An example of UTXO-based transfers in Bitcoin.

Figure 1 . 7 -

 17 Figure 1.7 -The Transaction Journey. Once created the transaction is signed by the data-sender. Verification checks are performed upon block creation by the leading nodes. Transaction can be collected in a block either before being transmitted to the validating nodes or afterwards. The block of transactions is then validated, propagated and confirmed. 56

1. 4 .

 4 AGREEMENT IN BLOCKCHAINS elected as validating peers. The pseudo-random election takes into account the deposit entity made by the candidates and elect a set of validators. That is, Casper cannot be considered as an hybrid algorithm mixing PoS and BFT (see Section 1.4.2.3) since election and validation are not independent processes.

  was amended to support open reading rights (public). Stellar Consensus Protocol (SCP[START_REF] Mazieres | The stellar consensus protocol : A fede-rated model for internet-level consensus -White paper[END_REF]) is a BFT-variant based on permissions to choose a pool of known participants to trust. Participation to this pool (quorum) is open and global consensus is reached intersecting all the chosen quorums. In the same way, in delegated BFT protocols [177] only a class of representative peers comes to vote.

Figure 1 . 8 -

 18 Figure 1.8 -Evolutionary route of consensus protocols in five classes from pre-blockchain to postblockchain protocols

( 4 .

 4 A) Is confidentiality 9 required ? Privacy and confidentiality within blockchains are controversial ;

Figure 1 . 9 -

 19 Figure 1.9 -When to use blockchain, and which type, instead of adopting a traditional database system. Red circles represents trade-off points between crucial aspects for the different blockchain usecase. The red arrows indicate the consequence of giving priority to one aspect rather than the other, while black arrows report answers to all the questions -coming with an order -of anyone interested in the blockchain technology. 'tps' : transactions per second.

Fig. 2 .

 2 Fig. 2.1 represents a game in extensive form Γ with players N = {A, B} and non-terminal nodes V \ Z = {a, b, c}. The structure and the notation of a game in extensive form is not practical for representing finite 2-players games. Every game in extensive form can be rewritten in a more compact way, called normal form representation [245], as shown in Fig. 2.2.

Figure 2 . 1 -

 21 Figure 2.1 -Game Γ in extensive form.

Fig. 2 .

 2 Fig. 2.1 represents a game in extensive form Γ with players N = {A, B} and non-terminal nodes V \ Z = {a, b, c}. The structure and the notation of a game in extensive form is not practical for the purpose of the analysis. Every game in extensive form can be rewritten in a more compact way, called normal form representation [245], as shown in Fig. 2.2.

Figure 2 . 2 -

 22 Figure 2.2 -Game Γ in normal form.

Definition 2 . 7 (

 27 Characteristic function) The characteristic function (or side payment) of a cooperative game is a function v : 2 N → R such that v(∅) = 0, where ∅ denotes the empty set. This function v associates a real value to all the possible coalitions. More precisely, v(S) represents the value that each coalition S can get for itself, once it is formed. The condition on the empty set represents a sort of normalization condition. Definition 2.8 (Cooperative game) A cooperative game is defined by the pair (N, v) where N is the set of players and v is the characteristic function that assigns a value v(S) to each coalition S ⊂ N .

  rationality), saying that every agent must receive a nonnegative amount of the estate E ; -f i (c, E) ≤ c i ∀i ∈ N (Demands boundedness), stating that no agents receives strictly more than what she/he claims ; -∑ i∈N f i (c, E) = E (Efficiency), requiring that the entire estate must be allocated among the claiming agents.

Definition 2 . 11 (

 211 Proportional rule (P)) For each bankruptcy situation (c, E) ∈ B N , the proportional rule yields the allocation vector P (c, E) = πc, where π is such that∑ i∈N πc i = E.Example 2.5.1 Consider a bankruptcy problem with three claimants N = {1, 2, 3} and such that (c, E) = ((4, 5, 3), 10). First, compute the parameter π = E C = 10 12 = 5 6 , then get the proportional allocation multiplying π by the vector of demands c : P (c, E) from the literature that we consider is the Constrained Equal Awards rule. This allocating rule ignores differences among claimants and rule out cases where agents receiving more than what they claim thanks to the boundedness constraint.Definition 2.12 (Constrained equal awards rule (CEA)) For each bankruptcy situation (c, E) ∈ B N , the constrained equal awards rule is defined as CEA i (c, E) = min{c i , λ} where the parameter λ is such that

Example 2 . 5 . 2

 252 Consider the bankruptcy situation given in Example 2.5.1. The first step assigns to all players x = (3, 3, 3). The game to solve is now : (c ′ , E ′ ) = ((1, 2, 0), 1). Since the third agent is satisfied E ′ have to be allocated within the first two players. Here λ =7 2 hence,

Example 2 . 5 . 3

 253 Consider again the bankruptcy situation given in Example 2.5.1. At first, a loss of 1

Theorem 2 . 1 (

 21 [START_REF] Curiel | Bankruptcy games[END_REF]) An allocating rule f (c, E) for bankruptcy problems is a game theoreticaldivision rule if and only if f (c, E) = f (c T , E), c T i = min{c i , E} for all i ∈ N .This condition derives from the fact that cooperative games corresponding to the bankruptcy problems (c, E) and (c T , E) are the same. According to theorem both the constrained equal losses and the proportional rules are not a game theoretical rules. For the CEL rule it is not so immediate as for the proportional one. Let us show this fact with a simple example : Example 2.5.4 Let (c, E) = ((2, 11), 10) and so (c T , E) = ((2, 10), 10).

Property 2 . 6 (

 26 No advantageous merging or splitting) Let (c, E) ∈ B N and

99 2. 5

 995 . BANKRUPTCY GAMES It is possible to split this property in two distinct properties by considering the two different behaviors of merging and splitting.Property 2.7 (No advantageous merging) Let (c, E) ∈ B N and (c ′ , E ′ ) ∈ B N ′ be such that N ′ ⊂ N , E = E ′ and suppose there is and agent

Figure 3 . 1 -

 31 Figure 3.1 -Transaction sub-network. Each arrow is labeled with sender's address. CBtx, Trtx, Rewtx are respectively coinbase, transferring and rewarding transactions.

Figure 3 . 2 -

 32 Figure 3.2 -Address sub-network related to Fig. 3.1 example.

Figure 3 . 3 -

 33 Figure 3.3 -User sub-network related to Fig. 3.1 example.

Figure 3 . 4 -

 34 Figure 3.4 -Simplistic miners' positioning. Blocks are represented with gray boundaries. Vertical lines associate each round end with the corresponding rewarding transaction.

Figure 3 . 5 -

 35 Figure 3.5 -Realistic miners' positioning.

Figure 3 . 6 -

 36 Figure 3.6 -Pool-miners graph representation. The left blue node is Kano pool and the right blue node is Slush pool. Detected pool-hoppers are highlighted in red. Edge thickness and color depend on the frequency of users interactions.

Fig. 5 .

 5 [START_REF] Conti | A Survey on Security and Privacy Issues of Bitcoin[END_REF] captures the interactions of the miners with Kano and Slush pools (represented by blue nodes). Overall, 43 pool-hoppers were detected within a population of 69 miners active with the two pools (26 miners are not hopping within the time period, thus they are mining continuously for one of the two pools), and an approximate global population of 150.000

Figure 3 . 7 -

 37 Figure 3.7 -Daily number of hoppers and hops.

Figure 3 . 8 -

 38 Figure 3.8 -Heat map : daily hopping intensity per hopper.

Fig. 3 .

 3 Fig.3.8 further characterizes the phenomenon on a daily basis, showing for each of the identified hoppers the number of hops per day. We can roughly spot 3 different types of hopper : (i) frequent hoppers, miners who opt for a hopping strategy more than 10 times (e.g., #0, #3, #4), (ii) occasional hoppers, performing a limited number of hops, less than 10 times (e.g., #6, #7, #14), and (iii) changing-pool hoppers, miners who hop just once in the time window (e.g., #19, #20, #21).

Figure 3 . 9 -

 39 Figure 3.9 -Inter-hopping time boxplot distributions (logscale).

Figure 3 . 10 -

 310 Figure 3.10 -Boxplot distributions of rewarding transactions BTC values (logscale).

Figure 3 . 11 -

 311 Figure 3.11 -Correlation plot : BTC price vs number of hops.

1 D 1 D

 11 to add to the allocation established by the classical CEL rule for the bankruptcy situation (c, E) = ( reduced by 1 D . More precisely, in long rounds ˆ R i (s; w) =

Example 3 . 3 . 1

 331 Before proving this statement, let us compare the allocations provided by the classical CEL rule and ˆ R through an example with n = 3, D = 10 and E = 1. Given the following bankruptcy situation : s = (2, 7, 8), miner 1 finds the full solution (w = 1) and (c, E) = ((0.2, 0.7, 0.8), 1). By Definition 2.13, it is easy to check that λ = 0.25, hence : CEL(c, E) = (0, 0.45, 0.55). Now, consider the new CEL-based rule ˆ R, a prize of 1 D = 0.1 is allocated to miner 1, and a new bankruptcy situation (c, E ′ ) arises where the estate is reduced by 0.1 ; (c, E ′ ) = ((0.2, 0.7, 0.8), 0.9). By Definition 5.21, now λ = 0.3 and we have that :

1 D ≤ λ 1 ≤ λ 2 .

 112 0) and this leads to contradiction. ■ Corollary 3.0.1 Given the situation of Proposition 3.1 we have that : λ 2 -Now, we are ready to prove the incentive compatibility of the new reward function based on the CEL rule. Proposition 3.2 The CEL-based reward function ˆ R of Definition 5.21 satisfies the property of incentive compatibility.

Proposition 3 . 3

 33 The reward function R proposed by Schrijvers et. al. always gives miners a positive incentive δ hop > 0 to perform pool-hopping.

129 3. 3 .

 1293 REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS 3.3.3.3 Comparison of the Rewarding Functions in a Multi-Pool Framework We have, now, the metrics to compare the performance of the reward functions R and ˆ R in hopping situations. Both rewarding systems present an incentive to hop in long rounds, however the miner rewarded with the CEL-based reward function are less incentivized. It is possible to compare the incentives δ hop , δ ˆhop given by the two functions R, ˆ R through the variables introduced in Section 3.3.3.2 since :

Figure 3 .

 3 Figure 3.12 -CDF of every p n (α), with n ∈ {3, 10, 20, 30, 50}.

  according to X k . Note that, b σ k and b σ k-1 differ only for the ownership of assets A k belonging to b σ k-1 (A k ) at step k -1 and to O k at step k. Example 4.2.1 Let us consider the swap problem ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ such that the set of assets is A = {a, b, c, d, e}, the set of owners is O = {1, 2, 3}, the original ownership map is b 0 = (1, 1, 2, 3, 3) (meaning that the asset ownership is : 1 for assets a and b, 2 for c and 3 for d and e) and the desired ownership map is b * = (2, 3, 1, 2, 1). One may consider a sequence of exchanges involving first owners 1 and 2, then 1 and 3 and finally 2 and 3. Precisely, σ = ({a, c}, {1, 2}, {X 1 (a) = 2, X 1 (c) = 1}), ({b, e}, {1, 3}, {X 2 (b) = 3, X 2 (e) = 1}), ({d}, {2}, {X 3 (d) = 2}). Sequence σ engenders a sequence of ownership maps such that b 0 = (1, 1, 2, 3, 3), b 1 = (2, 1, 1, 3, 3), b 2 = (2, 3, 1, 3, 1), b 3 = (2, 3, 1, 2, 1) = b * .

Example 4 . 2 .

 42 1 provides a decentralized swap protocol σ since {{a, c}, {b, e}, {d}} is a partition of A. From the formalization introduced in Definition 4.2, it is possible to derive a graphic representation, by means of a digraph D = (V, E), as the one proposed by Herlihy in [6]. More precisely, vertexes are asset owners V = O and edges E ∋ e = (e i , e o ) : (e i , e o ) ∈ V 2 ∧ e i ̸ = e o can be derived by the original ownership map b 0 (providing e i ) and the desired one b * (providing e o ). Fig. 4.1 presents the digraph of Example 4.2.1.

Figure 4 . 1 -

 41 Figure 4.1 -Digraph swap protocol representation of the sequence σ = ({a, c}, {1, 2}, {X 1 (a) = 2, X 1 (c) = 1}), ({b, e}, {1, 3}, {X 2 (b) = 3, X 2 (e) = 1}), ({d}, {2}, {X 3 (d) = 2}).

Definition 4 . 7 (

 47 atomic blockchain swap protocol) An atomic blockchain swap protocol consists of a pair (σ P , σ T ) where the engendered ownership map at time t of the commitment protocol coincides with the desired one ; b σ T t T = b * or with initial one ; b σ T t T = b 0 .

■- 1 (

 1 At time t, assetsA k do not necessarily belong to O k thus, O k could find themselves with no asset i.e., O k ) = ∅. Moreover, the original asset owners find themselves with both the original assets and the swapped ones. Let us denote by σ K T , with K ⊆ {1, . . . , t T } the sequence of pairs obtained by replacing (A k , O k ) in σ T by (A k , b σ T k-1 (A k )) for any k ∈ K (i.e. by the owner(s) of A k at step k -1).

3

 3 K ⊆ {1, . . . , t T } is such that p z k = 0 for any k ∈ K, and p z k = 1 for any {1, . . . , t T } \ K. So, for any i ∈ O, the outcome b σ K T t is evaluated by i with the payoff function u i Let Γ σ = ⟨N, T, P, (A h ) h∈V , (u i ) i∈N ⟩ be the extensive form game associated with the swap problem ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ and the blockchain swap protocol with sequential phases (σ P , σ T )

Proposition 4 . 4

 44 Let Γ σ = ⟨N, T, P, (A h ) h∈V , (u i ) i∈N ⟩ be the extensive form game associated with the swap problem ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ and the blockchain swap protocol with sequential phases (σ P , σ T ) and let F T : {1, . . . , t T } → O ∪ {τ } be a decision function. The decision function F T is effective on the blockchain swap protocol (σ P , σ T ), if and only if the strategy profile (s ˆ1, . . . , s ˆn) that specifies action 1

Figure 4 . 2 - 4 .

 424 Figure 4.2 -Two party 'atomic' cross-chain swap protocol proposed in [5; 6] characterized by sequential publishing and commitment : σ P = {(x, B), (y, A)} and σ T = {(y, A), (x, B)}.

4. 4 .

 4 CROSS-CHAIN SWAP PROTOCOLS crypto-assets are correctly published. The sequentiality of the publishing together with the leader role ensures the required separation between the two phases of the blockchain swap. Let us formalize this concept in the following proposition : Proposition 4.5 A blockchain swap protocol verifying the atomicity definition proposed in[START_REF] Herlihy | Atomic cross-chain swaps[END_REF] and characterized by : (i) a leader participant initiating the publication phase F P (1) = {l} together with the commitment one F T (1) = {l} when all the contracts where she is directly involved are published, (ii) a sequential publishing phase where asset owners are called to publish as soon as all the contracts transferring them the desired assets' property are published, satisfies the commitment requirement of Definition 4.8.

Figure 4 . 3 -

 43 Figure 4.3 -Extensive form game associated to the blockchains swap protocol, presented in [5]. Publishing and commitment phases are sequentially executed one after the other. Outcomes represent the payoffs (assets) owned by Alice and Bob respectively. The figure represents the backward induction process for each decision step.

Figure 4 . 4 -

 44 Figure 4.4 -Two party AC3TW cross-chain swap protocol proposed in [7] characterized by concurrent publishing and snap commitment. It is represented by the following formalization : σ P = {({x, y}, {A, B})} and σ T = {({x, y}, {A, B}, {X 1 (x) = B, X 1 (y) = A})}.

( 4 )

 4 Concurrently, Bob publishes a contract C 2 on the Ethereum network stating the following : -if Alice provides T (m s (D); RD) then, y Ethereums' ownership is transferred from Bob to Alice. -if Bob provides T (m s (D); RF ) then, the y Ethereums are transferred back to Bob. (5) After the publication of C i : i = 1, 2 either Alice or Bob requests Trent to trigger a redemption commitment scheme to redeem the assets. Trent issues T (m s (D); RD) only if both C 1 and C 2 are correctly published in their corresponding blockchains and the value of m s (D) stored by Trent is ⌉.

( 6 )

 6 Whenever a contract is not correctly published any participant can request Trent to trigger a refund commitment scheme. T (m s (D); RF ) is issued only if m s (D) has value ⌉.

( 7 )

 7 Depending on the case, Trent sets the value of m s (D) to T (m s (D); RD) or T (m s (D); RF ) accordingly.

Proposition 4 . 6

 46 Let ⟨N, (S i ) i∈N , (u i ) i∈N ⟩ be the normal form game associated with the swap problem ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ and the blockchain swap protocol (σ P , σ T ) characterized by a concurrent publishing and a snap commitment where the decision function F T is such that F T (k) = τ ∀k ∈ {1, . . . , t T }.

4

 4

  .5) allows to quickly analyze each possible outcome. In this case, Alice and Bob have to decide between action 0 and action 1 during the publishing phase. Once the transfers are

Figure 4 . 5 -

 45 Figure4.5 -Normal form game associated to the blockchains swap protocol, presented in[START_REF] Zakhary | Atomic commitment across blockchains[END_REF]. Alice and Bob decide whether to publish or not the contract on the corresponding blockchain. Outcomes represent the payoffs of Alice and Bob respectively. By eliminating dominated strategies the emphasized outcomes are the equilibria of the game. The dominant strategy, the one providing strictly greater payoffs, is a Nash equilibrium.

Definition 5 . 6

 56 Given A = ⟨N, S A , u A ⟩ and B = ⟨N, S B , u B ⟩ two games in normal form with the same set of players N , two different sets of strategies S A = {S Ai : i ∈ N } and S B = {S Bi : i ∈ N } and two different utility functions : u A : S A → R N and u B : S B → R N then, it is possible to define a new game C = A ⊙ B, called composition of A and B, which is characterized as follows. C = ⟨N, S C , u C ⟩, where :

  Tendermint's consensus protocol (i.e., Tendermint-core[1; 8]) is split into three rounds : the Pre-Propose round, the Propose round and the Vote round. During the Pre-Propose round, the proposer presents a block, to the other participants. During the Propose round, each participant chooses whether to accept or not the block and broadcasts her decision. If the votes for the proposal exceed a predetermined threshold ν then participants start the Vote phase. If the block receives more than ν votes, it is validated. Tendermint's consensus algorithm sets ν = n -f =2 3 n ; the threshold representing the number of non-faulty actors (as n denotes the total number of nodes and f the total number of faulty nodes) is set to2 3 of the network participants.The set of actions available to consensus participants is described in Figure5.1.

Figure 5 . 1 -

 51 Figure 5.1 -Strategies available to participants [8].

Figure 5 . 3 -

 53 Figure 5.3 -A and B open a channel.

Figure 5 . 8 -

 58 Figure 5.8 -Scheme of the commitments for the opening of a channel [3].

  3. A has three actions available : BR1a •• which provides outcome (0, 0) ; C2a AB which provides outcome (1, 1) ; BR1a A• which leads to node 4.4. B has two actions available : BR1b•B which provides outcome (1, 1) ; BR1b •• leading to node 5.5. A has two actions available :C1a AB which provides outcome (-1, 1) ; C2a AB which provides outcome (1, 1).

Figure 5 . 11 -

 511 Figure 5.11 -The game tree of Γ up

  Figure 5.14 -The game tree of Γ rout

Figure 5 . 15 -

 515 Figure 5.15 -The game trees of Γ rout A , Γ rout B and Γ rout C

Figure 5 . 16 - 202 5. 4 .

 5162024 Figure 5.16 -Algorithm to create a chain in Platypus [4].

204 5. 4 .

 2044 ROBUSTNESS TO TRANSACTING USERS' BEHAVIORS IN LAYER-2 PROTOCOLS Definition 5.15 The Litecoin game is an extensive form game G 2 with 2 players N = {A, B} and 5 nodes (1 is the vertex) :

Figure 5 . 19 - 2

 5192 Figure 5.19 -Quand utiliser une blockchain, et quel type, au lieu d'adopter un système de base de données traditionnel. Les cercles rouges représentent les points de trade-off entre les aspects cruciaux pour les différents cas d'usage de la blockchain. Les flèches rouges indiquent la conséquence de la priorité donnée à un aspect plutôt qu'à un autre, tandis que les flèches noires signalent les réponses à toutes les questions -accompagnées d'un ordre -de toute personne intéressée par la technologie blockchain.

Figure 5 . 20 -

 520 Figure 5.20 -Jeux représenté en forme extensive (à gauche) et normale (à droite)

Definition 5 . 18 (

 518 Jeux coopératifs) Un jeu coopératif est défini par la paire (N, v) où N est l'ensemble des joueurs et v : 2 N → R est la fonction caractéristique qui attribue une valeur v(S) à chaque coalition S ⊂ N .SYNTH ÈSEChaque fois que le montant v(S) peut être librement divisé entre les membres de S nous avons que (N, v) est un jeu à Utilité Transférable (TU). La question qui se pose maintenant est la suivante : comment cette valeur est-elle partagée ?, il est maintenant temps d'introduire l'idée de solution. Dans un jeu (N, v), une solution est un vecteur (x 1 , ..., x n ) où x i représente le montant attribué au joueur i. Un concept de solution stable pour les jeux coopératifs est le suivant.Definition 5.19 (Le noyau) Soit v : 2 N → R un jeu TU. Le noyau du jeu, désigné par C(v), est l'ensemble C(v) = {x ∈ R n : ∑ i∈N x i = v(N ) ∧ ∑ i∈S x i ≥ v(S), ∀S ⊂ N }.Les solutions du noyau garantissent que les joueurs ne s'opposent pas puisqu'ils n'obtiennent pas moins que ce qu'ils peuvent obtenir seuls.Jeux de banquerouteUne classe particulière de jeu coopératif que nous adoptons dans le chapitre suivant est celle des jeux de banqueroute. Une situation de banqueroute se présente chaque fois que des agents revendiquent un certain montant d'une masse divisible et que la somme des revendications est supérieure à la masse . Formellement, une situation de banqueroute sur l'ensemble N des agents consiste en une paire(c, E) ∈ R N × R avec c i ≥ 0 pour tout i ∈ N et 0 < E <∑ i∈N c i = C ou c représente les demandes des agents et E est la masse qui doit être divisé entre les agents. Trois solutions bien connues pour les jeux de banqueroute seront analysées lors de la modélisation des problèmes blockchain. Definition 5.20 (Règles) Pour chaque situation de banqueroute (c, E) ∈ B N , la règle -Proportional (P) donne le vecteur d'allocation P (c, E) = πc, où π est tel que ∑ i∈N πc i = E.-Constrained equal awards (CEA) est définie comme CEA i (c, E) = min{c i , λ} où le paramètre λ est tel que∑ i∈N min{c i , λ} = E. -Constrained equal losses (CEL) est définie comme CEL i (c, E) = max{c i -λ ′ , 0} où le paramètre λ est tel que ∑ i∈N max{c i -λ ′ , 0} = E.La règle CEA consiste à donner à chaque agent le même montant jusqu'à ce que sa demande ne soit pas entièrement satisfaite et que la masse ne soit pas terminée. En revanche, au lieu d'égaliser les revendications, la règle CEL égalise les pertes en privilégiant les grosses demandes par rapport aux petites. Les trois règles sont dans le noyau des jeux banqueroute.

  décrit et analyse le phénomène de poolhopping en analysant les flux de transactions des pools et mineurs opérant dans la blockchain Bitcoin. En partant des transactions de coinbase et de récompense, nous avons construit le sous-réseau de transactions [255] représentant le flux de bitcoins entre le pool et les mineurs au niveau de leur adresses. Dans un deuxième temps, nous avons mis en correspondance chaque acteur bitcoin avec les adresses qui lui sont associées afin de dériver un sous-réseau d'utilisateurs plausible où les utilisateurs d'intérêt sont les mineurs et le pool. À partir du sous-réseau d'utilisateurs construit, il est possible de sélectionner les mineurs qui sont rémunérés par plusieurs pools. Dans le cas de deux pools, si le même mineur est présent dans deux transactions de récompense consécutives (ordonnées) appartenant l'une à un pool et l'autre à un autre, nous pouvons le déclarer comme un hopper. Il peut y avoir des situations douteuses lorsque le même mineur est trouvé dans deux transactions de récompense de différents pools qui ne sont pas directement consécutives ou encore certains pools n'associent pas exactement une transaction de rémunération à chaque round. Cette modélisation ne capture donc pas l'intégralité du phénomène. SYNTH ÈSE Nous avons analysé le sous-réseau d'utilisateurs impliquant des mineurs interagissant avec les deux pools miniers les plus populaires en 2016 : Slush pool [258] et Kano pool [262]. Dans l'ensemble, 43 "pool-hoppers" ont été détectés au sein d'une population de 69 mineurs actifs dans les deux pools et d'une population globale approximative de 150 000 mineurs (Fig. 5.21). De plus, nous étions intéressés par la quantification de l'avantage du "hopping". La distribution des revenus des sauteurs sur la fenêtre temporelle est présentée dans la Fig. 5.22 avec des boxplots ; les deux derniers boxplots sur le côté droit couvrent tous les sauteurs ensemble et tous les mineurs statiques ; nous trouvons une récompense médiane de transaction 3 fois plus élevée pour les mineurs sauteurs que pour les statiques.

Figure 5 . 21 -

 521 Figure 5.21 -Représentation graphique des pool-miners. Le noeud bleu de gauche est le pool Kano et le noeud bleu de droite est le pool Slush. Les hoppers détectés sont mis en évidence en rouge. L'épaisseur et la couleur des arcs dépendent de la fréquence des interactions des utilisateurs.

Figure 5 . 22 - 1 . 1 D 1 DProposition 5 . 6

 52211156 Figure 5.22 -Distributions par boxplot des valeurs bitcoin des transactions de récompense (échelle logarithmique).

  de la blockchain et (ii) des comportements des parties contractantes visant à échanger des actifs via de cross-chain swaps. Les échanges atomiques inter-chaînes entrent dans la catégorie de recherche dites TAST (i.e., Token Atomic Swap Technology)[START_REF] Borkowski | Towards atomic cross-chain token transfers : State of the art and open questions within tast[END_REF] visant à rendre les blockchains interopérables. La toute première solution d'échange atomique a été proposée pour Bitcoin par Nolan[START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] en utilisant des hash-time locked contracts permettant des transferts d'actifs conditionnels. La recherche se concentre maintenant sur des protocoles de swap hybrides, avec des hash-locks centralisés, résultant plus efficaces.Il faut noter que les différents protocoles d'échange se distinguent essentiellement par les parties concernées. L'ensemble des participants au swap peut être composé uniquement des propriétaires des actifs (comme dans le protocole[START_REF] Herlihy | Atomic cross-chain swaps[END_REF]) ou des propriétaires accompagnés d'un tiers de confiance (comme dans le protocole AC3TW[START_REF] Zakhary | Atomic commitment across blockchains[END_REF]).Nous proposons, dans cette contribution, un cadre théorique (avec la théorie des jeux) qui formalise un problème de swap et caractérise les protocoles de swap blockchain en séparant clairement la phase de publication des contrats et la phase de réalisation des contrats. Un protocole général de swap définit l'ensemble des transferts d'actifs et l'ordre dans lequel ils doivent être exécutés. Étant donné un ensemble d'actifs A et les propriétaires correspondants O, un swap consiste en un échange de propriété d'actifs au sein de l'ensemble des propriétaires. Un problème de swap est défini comme un tuple ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ où : b 0 , b * : A → O sont les plans de propriété originaux et désirés -les deux surjectives -telles que ∀a ∈ A, b 0 (a) ̸ = b * (a) et u i est la fonction d'utilité du propriétaire i ∈ O sur les actifs dans 2 A telle que u i (b -1 0(i)) < u i (b -1 * (i)). pour chaque i ∈ O. Afin de définir formellement un protocole de swap blockchain, nous devons d'abord introduire la structure d'un protocole d'échange décentralisé, consistant en une suite de transferts d'actifs à réaliser.Definition 5.22 (protocole d'échange décentralisé) Soit σ = {(A k , O k , X k ) : |A k | ≥ |O k |} k , k ∈ {1, . . . , t}, t ∈ N : t ≤ m une suite d'échanges où (i) A k ⊆ A et O k ⊆ O spécifient respectivement les actifs et les propriétaires impliqués dans l'échange à l'étape k et (ii) X k : A k → O k (surjectif ) spécifie le propriétaire X k (a) ∈ O k de tout actif a ∈ A K à l'étape k.La suite σ définit un protocole d'échange décentralisé qui engendre une suite de plans b σ 1 , b σ 2 , . . . , b σ t : A → O telle que pour tout k ∈ {1, 2, . . . , t} : bσ k (z) = b σ k-1 (z), ∀z ∈ A \ A k et b σ k (z) = X k (z), ∀z ∈ A k (avec b σ 0 = b 0 ).232 SYNTH ÈSE La suite σ définit, pour chaque étape du protocole k, les actifs A k dont la propriété doit être transférée et les nouveaux propriétaires O k pour chaque actif. Cependant, une étape supplémentaire est nécessaire lorsque l'on envisage des parties contractantes qui ne se font pas confiance. Le protocole doit être construit de telle sorte que l'échange soit réalisé dans son intégralité ou qu'aucun transfert d'actifs ne soit engagé (i.e., tout ou rien). Afin d'empêcher les participants d'échanger en externe les actifs impliqués dans un swap, le protocole exige que les actifs soient verrouillés dans des transactions spécifiques avec des hash-time locked contracts (HTLC). Ces derniers doivent être correctement mis en oeuvre, publiés et validés sur le réseau avant d'être réalisés. Une fois publié, la réalisation des transferts permet à chaque participant de racheter le ou les nouveaux actifs échangés. Un protocole d'échange de blockchain doit spécifier les phases de publication et d'engagement ainsi que les horaires dans lesquels les agents effectuent les opérations. Par conséquent, étant donné une suite d'opérations σ, un ensemble de propriétaires d'actifs O et une autorité de confiance centralisée τ , nous définissons une fonction de décision F : {1, . . . , t} -→ O ∪ {τ } comme un plan qui spécifie le ou les agents F (k) responsables de la publication (ou de la réalisation) du transfert (A k , O k ). Notez que le ou les agents appelés à décider du transfert peuvent être soit des propriétaires d'actifs (i.e., F (k) ∈ O) soit des acteurs de confiance externes (i.e., F (k) = τ ). Une fonction de décision F T est effective sur σ T si et seulement si F T (k) = O k pour tout k ∈ {1, . . . , t T }, t T ∈ N : t T ≤ m i.e., les joueurs ont le pouvoir d'accepter ou de refuser les actifs désirés.Definition 5.23 (protocole de swap blockchain) Un protocole de swap blockchain est défini par la paire (σ P , σ T ) représentant un protocole de publication suivi par un protocole de réalisation où :• σ P = {(A j , O j )} j∈{1,...,t P } , t P ∈ N : t P ≤ m, A j ⊆ A et O j ⊆ O est une suite telle que ∀j ∈ {1, . . . , t P }, O j = {o ∈ O : o ∈ b * (A j ) ∨ o ∈ b 0 (A j )} et, • σ T = {(A k , O k , X k )} k∈{1,...,t T } est un protocole d'échange engendrant la suite de plans b σ T 1 , . . . , b σ T t T : A → O selon la définition précèdente. Nous associons à σ P , σ T la fonction de décision correspondante F P , F T définie ci-dessus. La formalisation fournie permet de capturer les protocoles de swap blockchain avec publication et réalisation séquentiels où les transferts de propriété sont publiés et réalisés selon un ordre temporel précis et les protocoles de swap avec publication simultanée où les transferts sont créés et propagés simultanément au réseau blockchain. Nous avons prouvé que (i) suivre un protocole de swap séquentiel SYNTH ÈSE caractérisé par une fonction de décision effective est un équilibre parfait de sous-jeu en stratégies dominantes et, que (ii) suivre un protocole de swap caractérisé par une publication concurrente et une réalisation snap (immédiate) est un équilibre de Nash.

4 . 3 .

 43 Les équilibres sont identifiés en adoptant le processus de raisonnement rétrograde (i.e., babackward induction) pour chaque étape de décision. En revanche, le jeu de forme normale associé au protocole AC3TW est représenté en Fig. 4.5 où les équilibres de Nash sont calculés en éliminant les stratégies dominées.

Figure 5 . 23 -

 523 Figure 5.23 -Le protocole de swap proposé dans [5; 6] caractérisé par une publication et une réalisation séquentielles et formalisé comme suit peut être modélisé comme un jeu de forme extensive (i.e., un arbre). σ P = {(x, B), (y, A)} et σ T = {(y, A), (x, B)}.

Figure 5 . 24 -

 524 Figure 5.24 -Le protocole de swap AC3TW proposé dans [7] caractérisé par une publication simultanée et une réalisation instantanée et formalisé comme suit peut être modélisé comme un jeu de forme normale. σ P = {({x, y}, {A, B})} and σ T = {({x, y}, {A, B}, {X 1 (x) = B, X 1 (y) = A})}.

Definition 5 .

 5 [START_REF]What to Mine[END_REF] (mécanisme[START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF]) Un mécanisme est une paire (Γ, σ) dans laquelle Γ = ⟨N, S, u⟩ est un jeu et σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S est un profil de stratégie.Il est conseillé à chaque joueur de jouer la stratégie σ i ∈ S i . Le jeu Γ présente toutes les stratégies possibles à la disposition des joueurs. De plus, dans[START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF], les auteurs ont introduit les notions de (i) k-résilience, (ii) praticité et (iii) t-immunité. Un profil de stratégie est défini comme k-résilient s'il n'existe aucune coalition avec au plus k joueurs ayant une incitation à dévier du protocole prescrit. La catégorie des profils stratégiques pratique est définie lorsque les équilibres avec des stratégies faiblement dominées sont exclus. Dans ce chapitre, nous avons suivi la ligne de travail ouverte dans[START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] et présenté un cadre théorique caractérisent la robustesse des protocoles blockchain aux comportements rationnels et byzantins des utilisateurs. Nos contributions en terme de modélisation de la robustesse peuvent être résumées comme suit : a) Nous avons prouvé que la propriété d'immunité de t définie dans [309] n'est pas vérifiée par une grande classe de protocoles blockchain ; b) Nous avons introduit le nouveau concept de t-weak-immunity ; un mécanisme est t-weak-immune si tout joueur altruiste ne reçoit pas de gain pire que l'état initial, quelle que soit la façon dont un ensemble de t joueurs s'écarte du protocole prescrit. Ce nouveau concept est suffisamment SYNTH ÈSE fort pour capturer la robustesse d'une grande classe de protocoles blockchain ; Definition 5.25 (t-weak-immunity) Un profil de stratégie σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ∈ S est tweak-immune si pour tout T ⊆ N : |T | ≤ t, tous les τ T dansS T et tous les i ∈ N \ T , on a u i (σ -T , τ T ) ≥ 0. Un mécanisme (Γ, σ) est t-weak-immune si σ est t-weak-immune dans le jeu Γ. c) Nous avons identifié et prouvé les conditions nécessaires et suffisantes pour qu'un mécanisme soit k-résilient et t-immunisé ; d) Nous avons défini un nouvel opérateur pour la composition de jeux et prouvé qu'il préserve les propriétés de robustesse des jeux individuels.

Table 1 .

 1 1 -Blockchains data model comparison.

	Data model	Benefits in	Drawbacks in	Frameworks
		scalability,	applicability,	Bitcoin, Litecoin [71],
	UTXO	security,	efficiency,	Dodgecoin [72], ZCash
		anonymity.	intuitiveness.	[73], MultiChain [74].
	Account	intuitiveness, applicability, efficiency.	security, anonymity.

Table 1 .

 1

	2 -Blockchains propagation mechanism comparison.
	Communication protocol -→	Flooding	Hybrid Flooding	Gossip
	bandwidth consumption
	delay performance
	net-split attack resistance
	scalability
	Basic protocol design -→	Announce-Request	Hybrid	Unsolicited push
	RTTs	3	2-3	1
	delay performance
	examples	Bitcoin	Ethereum	Hyperledger
	High :

Table 1 .

 1

	3 -Blockchain peers acting as 'transacting parties', 'leaders' and 'validators' in the different
	platforms.
	Platform	Senders-Receivers	Leaders	Validators
	Bitcoin [20]	Users/Clients	Miners	Miners
	Ethereum [95]	Accounts	Miners	Miners
	Hyperledger Fabric [96]	Clients	Ordering Services Validating Peers
	Corda [97]	Transacting parties	Transaction(s) issuer(s) only
	Tendermint [1]	Accounts	Virtual miners	Committee
	Chain Core [67]	Users/Clients	Block Generators	Block Signers
	Quorum [98]	Accounts	'Makers'	'Voters'
	5. The DLT platforms we refer to were the mainly adopted ones during the time period of the thesis i.e., 2017-2020
		57

Table 1 .

 1 4 -Summary about consensus mechanisms : comparative analysis of PoX consensus algorithms

	Property	PoW	PoS	DPoS	PoET	PoI
	Participation mode	permissionless	both cases	both cases	both cases	both cases
	Energy saving	no	partial	partial	partial	yes
	Tolerated adversary	< 25% power	< 51% stake	< 51% peers	TEE	< 50% importance
	Consensus finality	no	no	no	no	no
	Message overhead	O(1)	O(1)	O(1) -O(n)	O(1)	O(1)
	Node scalability	> 1000	> 1000	> 1000	> 1000	> 1000
	Throughput (tps)	7-30	100-200	millions	1000	4000
	Latency (s)	up to 600	up to 600	unknown	unknown	unknown

Table 1 .

 1

	Property	PBFT & variants	Consortium BFT	Hybrid BFT-based
	Participation mode	permissioned	permissioned	both cases
	Energy saving	yes	yes	yes
	Tolerated adversary	< 33.3% replicas	variable (20%-33.3%)	< 33.3% replicas
	Consensus finality	yes	yes	yes
	Message overhead	O(n 2 )	O(n 2 )	O(n) -O(n 2 )
	Node scalability	< 100	100 -1000	100 -1000
	Throughput (tps)	up to 110k	up to 10k	1000
	Latency (s)	less than 1	less than 1	up to 20

5 -Summary about consensus mechanisms : comparative analysis of BFT and BFT-based consensus algorithms

Table 1 .

 1 6 -Reading list on blockchain application domains

	(i)	clearing, collateralization, real estate

  Introduction on Game Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.2 Rationality of the Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.3 Non-cooperative Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

	1.6. SUMMARY
	Chapter 2
	Game Theory and Rational Agents
	Content
	2.1

2.3.1 Game Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2.3.2 Solution and Equilibria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.4 Cooperative Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.4.1 Solution, Imputation and Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.5 Bankruptcy Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 2.5.1 Bankruptcy Games: Game theoretical Division Rules . . . . . . . . . . . . . . . 96 2.5.2 Bankruptcy Rules' Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

  Game participants may play as individual or as a group leading to two different types of modeling. The theoretical content of this chapter derives from the following literature :[238; 239; 240; 241; 242]. Following chapters present real problems in the blockchain context that we model and analyze as games.2.1. INTRODUCTION ON GAME THEORY2.1 Introduction on Game TheoryGame theory is a branch of mathematics devoted to the study of optimal decision-making process in presence of multiple decision-makers. The latter are called players or equivalently agents. Game theory derives from Decision Theory and it can be also called Interactive Decision Theory. The difference between the two is that decision theory deals with a single agent's choices while game theory is characterized by having different agents (i.e., more than one) taking decisions. Moreover, game theory

studies interactions among agents' choices ; decisions of a player depend on other agents' ones. The birth of game theory is largely attributed to the mathematician John von Neumann and the economist Oskar Morgenstern for their theory on economic and social behaviors based on the concepts of game and strategy published in the 1940s

[START_REF] Neumann | Theory of games and economic behavior[END_REF]

. In 1950 Mathematician John Nash earned his PhD with a thesis on non-cooperative games

[START_REF] Nash | Non-cooperative games[END_REF]

considered as the first significant extension of the work proposed by von Neumann and Morgenstern. Game theory has a wide range of applications in social sciences. Despite its numerous applications in recent years, game theory is still considered a young and developing science.

Several situations may be modeled as games leading to a game classification. Two main classes of games are : non-cooperative games and cooperative games. In this thesis, we deal with both classes of games i.e., games in which individual players compete among each other and games in which there exists the possibility of external enforcement to cooperate. These definitions materialize in several

  BANKRUPTCY GAMESare not necessarily game theoretical division rules. However, these types of problems where an estate is divided among claimants suggest a cooperative behavior. Therefore, it is natural to try to model bankruptcy problems as a cooperative game and analyze the relative solutions. The first step is defining a characteristic function.It is clear that the grand coalition must form and that v(N ) = E, but it is not clear which value should be associated to single players and to intermediate coalitions. From the literature there exist a "pessimistic" approach to evaluate a coalition ; the pessimistic characteristic function assigns to a coalition a value which is what S gets once the other N \ S players have already taken what they claim. The coalition gets the part of the estate that is left after all other players are fully rewarded.

theory, i.e. by applying a natural allocating rule such as the proportional one. Moreover, division rules 96 2.5.

Table 2 .

 2 1 -Three bankruptcy solutions and some of their properties. This chapter presents the two different ways to model situations where agents act rationally (i.e., as rational players) that play as an individual (i.e., normal and extensive form games) or as a group (i.e., cooperative games). Then, a particular class of cooperative game, bankruptcy games, is presented. These games model bankruptcy situations i.e., situations where a resource need to be allocated among a set of claiming agents. In the blockchain context, bankruptcy situations arise when validating nodes (modeled as rational users) need to be remunerated for their validating tasks via new minted crypto-currencies. Rewarding Rational Miners: Bankruptcy Situations . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	CEA CEL P

Content

3.1 Introduction to Rewarding Miners . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Pool-hopping and Rewarding Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Rewarding Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Pool-Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 User Sub-network Inference Process . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Hoppers Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Measurement Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 3.3.1 The Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Incentive Compatible Reward Functions . . . . . . . . . . . . . . . . . . . . . . 3.3.3 A Multi-Pool Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4

Table 2 .

 2

	123

1, we have that the CEA-based reward function R cea satisfies no advantageous merging (2.7) on long

  can approximate the difference between β i

	3.3. REWARDING RATIONAL MINERS : BANKRUPTCY SITUATIONS
	and β * i as follows :
	130

  Focusing on the commitment phase we can derive the following definition stating that whenever the decision function is effective, agents in O k have the power to accept or decline (i.e., redeem or not) the acquisition of the asset(s) in A k .

for any j ∈ {1, . . . , t P }, t P ∈ N : t P ≤ m. Definition 4.10 A decision function F T is effective on σ T if and only if F T (k) = O k for any k ∈ {1, . . . , t T }, t T ∈ N : t T ≤ m.

  4.3. GAME THEORETICAL ANALYSIS OF CROSS-CHAIN SWAPSwith open read access i.e., swap participants have a complete vision of other agents choices. Definition 4.12 Let ⟨A, O, b 0 , b * , (u i ) i∈O ⟩ be a swap problem, let (σ P , σ T ) be a blockchain swap protocol and a let F P : {1, . . . , t P } → O, F T : {1, . . . , t T } → O ∪ {τ } be decision functions. We associate the extensive game form Γ σ = ⟨N, T, P, (A h ) h∈V , (u i ) i∈N ⟩ such that :

  1, 1, 2, 5, 13, 42 . . . . Proof. Let us suppose that a transaction is published on the main chain on the next block, unless the byzantine player succeeds in publishing a block which does not include this transaction. First, let us consider the case n = 1 ; the byzantine player succeeds if she publishes the block before any other player. If she fails, her best strategy is to mine blocks on an alternative chain until it gets to be the longest one. If α ≥ 1 2 the byzantine player will almost surely succeed. Otherwise if α < 1 2 , we have that Φ 1 (α) = α 1-α . Indeed, we can model the problem with a Markov chain with states m ∈ Z∩(-∞, +1], in which +1 is the only absorbing state, it is possible to move from state n to state n + 1 with probability α and from state n to state n -1 with probability 1 -α. It is a reformulation of the gambler's ruin Markov chain. The state m represents how many blocks the private chain is ahead of the main one. It is enough for the private chain to be one block ahead to succeed.

  For both player the strategy DN is weakly dominated by the strategy ES. Indeed, no matter what the other player does, the ES always provides the same or even a better utility than DN . If we exclude both strategies DN the players have available only two strategies : {C1a AB , ES} and {C1b AB , ES}. Once again, ES dominates the other strategy by providing a better outcome. The only strategy that survives the iterated deletion of weakly dominated strategies for both players is ES. Therefore the only stable Nash equilibrium is σ cl = (ES, ES). Thanks to Proposition 5.2 we can say that a stable equilibrium provides a practical mechanism.

  2. A creates a HTLC, namely H AB of value δ + ϵ locked with H and sends it to B. 3. B creates a HTLC, namely H BC of value δ locked with H and sends it to C.4. C discloses R to B, hence validating H BC . 5. B discloses R to A, thus validating H AB .We formalize the protocol with a game in extensive form Γ rout , whose tree is displayed in Fig.5.14.The initial state consists in the initial balance and it is assigned null utility. The final state corresponds for A and C to fulfill the payment, for B to receive the fee ϵ. The final state has positive payoff, normalised to 1. Any state that consists in a loss of assets is assigned negative payoff. The strategy profile recommended by the protocol is denoted by σ rout = ({H AB A }, {H BC B , Y }, {Y, Y }).

	5.4. ROBUSTNESS TO TRANSACTING USERS' BEHAVIORS IN LAYER-2
	PROTOCOLS
	2. A has two actions available : either H AB •
	Definition 5.12 The routing game Γ rout is a game in extensive form, with three players N = {A, B, C}
	and 5 nodes, labeled by a number (1 is the vertex) :
	1. C has two actions available : either N , not sending H to A, which provides outcome (0, 0, 0), or
	Y , sending H to A, which leads to node 2.
	196

  for all k and t-weak-immune for all t i.e., it is strongly resilient and weak immune. ■Recap. All the results of Lightning Network protocol are available in Table5.2. The protocol is built on top of the Bitcoin blockchain therefore, its properties depend on the Bitcoin's ones. If we exclude the closing protocol, the Lightning Network satisfies optimal resilience and weak immunity. Hence, we

can compose (see Definition 5.6) its protocols' games with Bitcoin mechanism's, which provide weaker results, and prove that the Lightning Network satisfies the same properties of the Bitcoin mechanism. PROTOCOLS

  TX1, that lets Bob receive an amount of bitcoins if he provides x, and TX2, that gives back the amount to Alice if Bob does not provide x within ∆ Bob . Bob creates two transactions on the Litecoin Bob and ∆ Alice are provided in[START_REF] Herlihy | Atomic cross-chain swaps[END_REF]. In a context with two players, the condition is that ∆ Bob ≥ 2∆ Alice . From now on we consider the assumption that ∆ Bob and ∆ Alice fulfill the properties set in[START_REF] Herlihy | Atomic cross-chain swaps[END_REF], and specifically we have that min(∆ Bob , ∆ Alice ) = ∆ Alice .Since the two blokchains are independent we model the protocol with two different mechanisms (G 1 , σ 1 ) and (G 2 , σ 2 ) (see Definitions 5.14 and 5.15), that represent the actions that the players perform in each blockchain. We set to 0 the utility of the initial state, 1 the utility of every state in which the player receive what is asked, -1 the utility of every state in which the player gives some coins without receiving any. The Bitcoin blockchain is represented by game G 1 , while the Litecoin blockchain by G 2 (see Fig.5.17). We work under the assumption that a transaction can be published within min(∆ Bob , ∆ Alice ) = ∆ Alice hours.

blockchain : TX3, that lets Alice receive an amount of litecoins if she provides x, and TX4, that gives back the amount to B if A does not provide x within ∆ Alice hours (in

[START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]

∆ Alice = 24). The theoretical PROTOCOLS bounds for ∆ Definition 5.14 The Bitcoin game is an extensive form game G 1 with 2 players N = {A, B} and 5 nodes (1 is the vertex) :

  The manuscript takes into consideration different users 209 CONCLUSION as well as different blockchains with the scope of providing a general overview of the topic and formal results holding for DLTs in general.Adopting an agnostic approach, this work analyzes those blockchain features and attributes making blockchain-based use cases more efficient or more innovative. An overview of when to use blockchain and which type of blockchain to use is provided in Chapter 1. After this overview, formal analysis are performed by combining distributed systems theory as well as game theory (Chapter 2) to analyze the behaviors of users operating on blockchain and DLT systems. This way of operating significantly differs considering the type of users. The contributions presented in Chapters 3-5 analyze both users simply adopting the technology as a payment/transfer mean (i.e., transacting parties) and users maintaining the network by participating in the consensus process (i.e., validating nodes also known as miners). Caisse des Dépôts engaged in a mission of accompanying the different types of blockchain users in the adoption of the technology for which the analysis performed in the first part of the thesis was fundamental. Moreover, the public entity cooperates at a national 2 and international 3 level to facilitate the use of the technology in compliance with regulations of the different jurisdictions. Technical reports on new blockchain systems and protocols have been presented in various acculturation initiatives organized by the Think Tank LaBChain consortium chaired by Caisse des Dépôts. Cross-chain tout en adoptant une architecture décentralisée. Les DLT ne font pas toutes appel à une architecture de blocs et peuvent donc être définies comme des "blockchains" (e.g., The Tangle and BigchainDB[9; 10]). Les blockchains peuvent donc être utilisées dans divers secteurs avec plusieurs applications. En effet, il est crucial pour les adoptants de comprendre si la technologie correspond ou pas aux problèmes qu'ils visent à résoudre.La technologie disruptive née en 2008 avec Bitcoin et connue sous le nom de blockchain représente un saut qualitatif important par rapport à la technologie des bases de données distribuées étudiée depuis juin 1970 (date de publication du premier article[START_REF] Codd | A relational model of data for large shared data banks[END_REF] sur le sujet). La blockchain permet de partager un grand registre de transactions qui sont lues, validées et stockées dans une chaîne de blocs. Les systèmes basés sur la technologie blockchain fonctionnent de manière distribuée, impliquant plusieurs agents ou participants qui devraient être indépendants les uns des autres, et qui peuvent Propagation : la transaction (dans un éventuel bloc) est propagée aux pairs qui la valident. Une diffusion efficace des transactions a un impact sur la vitesse de traitement des transactions.-Validation : c'est l'étape la plus cruciale puisqu'elle caractérise tous les systèmes existants basés sur une blockchain. Lors de cette étape, les transactions, rassemblées en blocs, doivent adresser les différentes étapes du mécanisme de consensus envisagé pour être considérées comme valides et donc exécutables. Ensuite, le bloc de transactions peut être rattaché à la blockchain, mettant à jour son état. Le bloc de transactions valide est ensuite propagé à l'ensemble du réseau afin de permettre à tous les noeuds de mettre à jour leur propre version du registre. ÈSE Ce manuscrit analyse les deux principaux types d'utilisateurs blockchains (i.e., les parties contractantes et les noeuds de validation) ainsi que différentes blockchains (i.e., sans permissions et avec permissions) dans le but de fournir un aperçu général du sujet et des résultats formels sur les comportements des utilisateurs blockchains ; les utilisateurs peuvent en effet être honnêtes vis-à-vis des autres utilisateurs ou ils peuvent se comporter de manière malveillante (comme des noeuds byzantins) en attaquant un système blockchain. Les deux types d'utilisateurs blockchain sont d'abord modélisés comme des agents rationnels. Cette modélisation basée sur la théorie des jeux permet de capturer plusieurs comportements. Pour être plus générique (i.e., en incluant également les comportements malveillants irrationnels ou inattendus), les utilisateurs blockchain sont également modélisés comme des agents byzantins ; ceci afin d'évaluer la robustesse de tout type de déviation du protocole dans le contexte de la blockchain. Le manuscrit est structuré comme suit : Chapitre 3 modélise et analyse les comportements d'un type particulier de noeuds de validation ; les mineurs du Bitcoin. Les mineurs qui effectuent des tâches de validation dans la blockchain attaques lancées par des noeuds malveillants ou simplement rationnels du réseau. Même si le bitcoin reste la crypto-monnaie la plus populaire en circulation, un grand nombre de crypto-monnaies basées sur la blockchain ont été définies -à ce jour, plus de 50 crypto-monnaies alternatives existent.Certaines de ces 'Altcoins'[START_REF] Wisniewska | institute of Economic Research[END_REF] s'appuient sur une blockchain permissioned -accessible uniquement aux noeuds autorisés, afin d'offrir un système plus scalable et rapide.Au-delà du cas du Bitcoin, la technologie blockchain vise à garantir les avantages des tiers de confiance tels que l'intégrité, l'authenticité, la sécurité et la non-répudiation dans un environnement distribué et décentralisé. En plus de l'auditabilité et de la transparence, elle offre l'immuabilité. En plus d'être évidentes pour les systèmes de crypto-monnaies, ces caractéristiques sont utiles pour tout système transactionnel qui doit être utilisé par plusieurs parties indépendantes qui ne se font pas confiance (i.e., trustless). Toutefois, comme les blockchains permissionés présentent de nombreuses similitudes avec les bases de données partagées classiques, il peut y avoir des situations où une architecture aussi complexe n'est pas indispensable. rassemblées en blocs ; chaque bloc de transactions est lié au bloc immédiatement précédent (i.e., bloc parent) par une valeur de hachage ; ainsi, en parcourant le registre des transactions, on peut remonter jusqu'au bloc de départ (i.e., genesis block ), qui n'a pas de bloc parent et contient les premières transactions traitées dans l'historique de la blockchain. La cryptographie caractérise la technologie et lui attribue des propriétés importantes. Nous pouvons mettre en évidence six caractéristiques fondamentales de la blockchain, qui sont dépendantes les unes des autres :-Décentralisation : Les DLT permettent le partage et le stockage de données P2P sans confier la tenue du registre à une autorité centrale. Il ne s'agit pas de supprimer complètement les intermédiaires qui valident les transactions (disintermédiation) comme le font les blockchains sans permission, mais plutôt de les décentraliser ainsi que leurs rôles.

	SYNTH ÈSE
	lement préciser les conditions dans lesquelles l'objet de la transaction peut être racheté (i.e., les
	conditions de mise à jour de l'état du système). Selon le modèle, les critères de rachat peuvent
	être de simples scripts ou plus généralement des contrats réels (i.e., smart contracts ou contrats
	intelligents).
	Rationality limitations are taken into account by analyzing blockchain robustness to both rational and Byzantine behaviors (Chapter 5). Industrial Contributions swap protocols between different blockchains have been implemented for Delivery-versus-Payment ex-periments swapping security tokens (i.e., digital securities issued on a blockchain) with stable coins (i.e., tokens pegged to stable assets such as fiat currencies). Les ensembles de données massives, initialement hébergés sur des ordinateurs centraux, peuvent passer à une architecture distribuée, avec des données répliquées d'un noeud à l'autre, ou d'un serveur à l'autre, et des sous-ensembles de données peuvent être consultés et traités via 'clients', puis synchronisés avec l'un des serveurs. Au fil du temps, les architectures Internet et de cloud computing ont permis un accès mondial à partir d'une variété de dispositifs informatiques, alors que les mainframes ont été largement conçus pour répondre aux besoins des grandes entreprises et des gouvernements. Même si une telle architecture Internet/Cloud est décentralisée en termes de matériel, elle a donné lieu à une centralisation au niveau des applications. Actuellement, nous assistons à la transition d'une informatique, d'un stockage et d'un traitement centralisés vers des architectures et des systèmes décentralisés. La DLT est l'innovation majeure qui rend ce changement possible. Certains systèmes distribués (par exemple, les blockchains sans permission i.e., permissionless) visent à donner le contrôle des actifs numériques aux utilisateurs finaux sans avoir besoin de noeuds intermédiaires. D'autres (par exemple, Transactions Blockchain et Rôles des Utilisateurs Chaque fois qu'un utilisateur souhaite interagir avec un autre dans un réseau blockchain, une ou plusieurs transactions sont créées, propagées, validées et confirmées par le réseau. Ce parcours commence au moment où la transaction est créée et se termine lorsque la transaction est enregistrée -transactions simples qui seront ensuite propagées sur le réseau (i.e., la création et la propagation) et (ii) l'aide à la maintenance du système en participant à la phase de validation et de confirmation des transactions (rassemblées en blocs). Les 'valideurs' sont tous les pairs impliqués à partir du moment où la transaction est incluse dans un Bitcoin sont modélisés comme des agents rationnels qui peuvent ou non avoir un comportement malveillant, c'est-à-dire effectuer une attaque, dans certaines situations. La situation que nous Avec Structure et Caractéristiques de la Blockchain présentons dans ce chapitre est le processus de rémunération des mineurs pour leur travail de bloc jusqu'à sa publication sur le registre. Les pairs qui collectent les transactions dans les blocs peuvent dans la blockchain. Quatre étapes cruciales du parcours d'une transaction blockchain peuvent être ne pas entrer dans la phase de validation ; cependant, étant donné que pour de nombreux systèmes de validation. Deux types de comportements malveillants sont analysés : le pool-hopping et le block-Au-delà de l'innovation apportée par la blockchain à l'écosystème DLT, un élément fondamental identifiées : blockchain, la collecte des transactions fait partie du processus de validation, cette séparation n'est withholding. Le contenu du chapitre est issu de [15] et [16]. est son mélange intelligent de techniques de cryptage [45] dans le stockage des données -préservant

This thesis was carried out within a French industrial PhD program called CIFRE in which my industrial partner was Caisse des Dépôts Groupe

[START_REF]Caisse des Dépôts Groupe[END_REF]

; a French financial institution. During these three years of thesis, the theoretical research has been accompanied by industrial applications of various nature.

Synthèse

En examinant les technologies informatiques, les architectures et les pratiques de conception du dernier demi-siècle, nous pouvons observer une tendance à la fluctuation entre la centralisation et la décentralisation des ressources informatiques telles que la puissance de calcul, le stockage, l'infrastructure, les protocoles et le code. Les ordinateurs centraux sont largement centralisés et concentrent la plupart des ressources informatiques. Aujourd'hui, les capacités de calcul sont distribuées sur les clients et leurs équipements ou encore sur des serveurs distants. Cette approche a donné naissance à l'architecture "client-serveur" qui a permis le développement de l'Internet et des systèmes de bases de données relationnelles.

les blockchains avec permission i.e., permissioned ) tentent de maintenir une centralisation logique de SYNTH ÈSE certaines informations utiliser des communications pair-à-pair (P2P) pour se structurer dans une collectivité de réseau (où les noeuds représentent les utilisateurs qui sont connectés par des transactions). L'adoption du P2P comme paradigme de communication soutient adéquatement l'objectif selon lequel les ressources sont partagées et dispersées sur un réseau qui, par construction, interdit l'existence de fournisseurs ou de serveurs centralisant les tâches. Le résultat est un écosystème décentralisé sans autorité centrale. Contrairement aux architectures client-serveur traditionnelles [12], les noeuds des réseaux P2P n'ont pas toujours une hiérarchie fixe ; les rôles peuvent ne pas être prédéterminés ou peuvent changer au fil du temps en fonction de l'opération réelle sous-jacente à une communication, c'est-à-dire une transaction blockchain. -Création : la partie émettrice d'une transaction doit définir, selon le modèle de données, l'origine et la destination de "l'objet du transfert" (i.e., l'actif numérique). Les transactions doivent éga--Confirmation : les blocs de transactions ne donnent lieu à un véritable transfert d'actifs que si, une fois validés et éventuellement publiés sur la blockchain, ils sont confirmés dans la version finale du registre, dont ils ne peuvent plus être éliminés. Pour en faire partie, la procédure de consensus doit arriver à son terme, c'est-à-dire que les noeuds doivent se mettre d'accord sur une seule chaîne de blocs. Les transitions d'une étape à l'autre caractérisent la technologie. La cryptographie est impliquée dans les techniques de hachage et de génération de clés. Les vérifications et la formation de blocs peuvent relier les deux premières étapes ou les étapes centrales. Ces quatre étapes marquent une forte distinction entre deux niveaux d'utilisation de la technologie : (i) l'utilisation de la technologie pour effectuer des pas évoquée dans ce manuscrit. La section 1.3.5 présente une division plus détaillée des rôles que les utilisateurs blockchain assument, nous soulignons dans ce qui suit les principaux.

SYNTH

• Chapitre 1 présente un aperçu complet de la technologie blockchain en analysant ses principales caractéristiques ainsi que toutes les couches qui caractérisent l'architecture blockchain. Il se concentre en particulier sur les caractéristiques qui conduisent les utilisateurs blockchain à choisir (i) si adopter la technologie ou non et (ii) quel type de blockchain choisir. Le contenu de ce chapitre provient de

[START_REF] Belotti | A vademecum on blockchain technologies : When, which, and how[END_REF]

.

• Chapitre 2 fournit une introduction à la Théorie des Jeux, en mettant l'accent sur la rationalité des joueurs prenant part à un jeu. Cela permet de prévoir les actions des joueurs et donc les résultats du jeu qui peuvent être plus ou moins stables (i.e., des équilibres ou des solutions dans le noyau). Les participants au jeu peuvent jouer en tant que individu ou en tant que groupe, ce qui conduit à deux types de modélisation différents. • • Chapitre 4 est consacré à l'analyse des comportements des parties contractantes visant à échanger des actifs via des swaps cross-chain. Les échanges inter-chaînes rendent possible les interactions SYNTH ÈSE contre les l'introduction des blockchains permissionés, les utilisateurs peuvent choisir de les adopter en imposant des contraintes et en personnalisant le comportement des noeuds du réseau. Alors qu'avec les blockchains classiques, il est possible de construire un système totalement ouvert et décentralisé, les blockchains avec permissions ne permettent qu'à un nombre limité d'utilisateurs d'avoir le droit de valider les transactions. Les valideurs constituent un ensemble de noeuds qui peuvent être élus publiquement ou sélectionnés par une autorité centrale. En limitant le nombre de participants à la procédure de validation, on peut obtenir des améliorations significatives de la scalabilité en utilisant des mécanismes de consensus appropriés. En outre, les modifications apportées aux protocoles (à la fois dans les données de la blockchain et dans la structure de consensus) pour prendre en charge l'exécution de codes Turing-complete, facilitent le déploiement d'applications distribuées ('dapps') basées sur des smart contracts. la structure des blocs grâce à l'horodatage [46] -et dans les transactions -authentifiant les transferts avec des signatures numériques. Le registre d'une blockchain consiste en un historique des transactions SYNTH ÈSE numériques validées

  × • • • × S n où S i est l'ensemble des stratégies du joueur i et u : S → R n est la fonction d'utilité des joueurs.En supposant que chaque joueur choisisse une stratégie σ i dansS i ; il est alors possible de calculer l'utilité d'un joueur i, u i (σ 1 , σ 2 , . . . , σ n ), qui est la i-ième composante de la fonction d'utilité u. Étant donné que les joueurs sont des agents rationnels, leur objectif est de maximiser leur utilité en choisissant leur propre stratégie.Une solution est un profil de stratégie qui décrit la dynamique et le résultat du jeu. Von Neumann et Morgenstern[START_REF] Neumann | Theory of games and economic behavior[END_REF] ont approfondi le concept de rationalité en fournissant une hypothèse supplémentaire : l'élimination des stratégies dominées. Cette méthode suppose que, indépendamment du choix que font les autres joueurs, un joueur ne choisit pas l'alternative A, si B est à sa disposition lui permettant d'obtenir plus. En itérant le processus d'élimination des stratégies dominées, un jeu de forme normale peut être résolu. Si une stratégie strictement dominante existe pour un joueur dans un jeu, ce joueur jouera cette stratégie. Si les deux joueurs ont une stratégie strictement dominante, le jeu n'a qu'une seule solution équilibre, appelée équilibre de Nash. Les équilibres de Nash sont des concepts de solution raisonnables puisqu'ils représentent un scénario dans lequel personne n'est tenté de changer unilatéralement sa propre stratégie. Definition 5.17 ( Équilibre de Nash) Un profil de stratégie σ = (σ 1 , σ 2 , . . . , σ i , . . . , σ n )S est un équilibre de Nash si pour chaque joueur i et pour chaque τ i ∈ S i nous avons que : u i (σ 1 , σ 2 , . . . , σ i , . . . , σ n ) ≥ u i (σ 1 , σ 2 , . . . , τ i , . . . , σ n )

Table 5 .

 5 2 -Propriétés d'immunité et de résilience par rapport au nombre d'agents déviants rationnels (k ) et au nombre d'agents déviants byzantins (t) où n est le nombre total de joueurs dans le jeu.Pour qu'une nouvelle technologie réalise tout son potentiel, il faut que de nombreuses circonstances coexistent avant que les effets de réseau puissent se concrétiser. En tant que technologie d'infrastructure, tous les principaux acteurs du marché doivent collaborer pour définir des normes de manière démocratique. Étant donné le coût du passage d'une technologie d'infrastructure à une autre, une approche collaborative est la voie la plus prometteuse. C'est la direction sur laquelle nous avons insisté dans la première partie de cette thèse et au cours de mon expérience de travail de trois ans au sein du "Programme Blockchain et Cryptoactifs" de Groupe Caisse des Dépôts[START_REF]Caisse des Dépôts Groupe[END_REF].

	Protocol	k-résilience t-immunité t-weak immunity	Résultats
	Tendermint	Oui, k < n/3	Non	Oui, t < n/3	Thm. 5.5
	Bitcoin	Oui, k < 3n/20	Non	Non	Thm. 5.7
	Lightning Network	Oui, k < 3n/20	Non	Non	Thm. 5.9
	Closing module	Oui	Non	Non	Thm. 5.12
	(Alternative closing module)	(Oui)	(Non)	(Oui)	Thm. 5.13
	Other modules	Oui	Non	Oui	Thm. 5.10, 5.11, 5.15, 5.18, 5.19
	Side-chain (Platypus)	Oui, k < n/3	Non	Oui, t < n/3	Thm. 5.20
	Cross-chain Swap	Oui	Non	Oui	Thm. 5.23

With the term immutability we refer to the concept of "immutability unless the adversary thresholds exceedance" : a permissionless blockchain become mutable whenever the majority of the network efforts are devoted for the purpose of replacing validated blocks, a permissioned one can become mutable following an attack by[START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF] 3 of the network (see Section 1.4.1.3). (stored transactions are not editable once published) and pseudonymity[START_REF] Khalilov | A Survey on Anonymity and Privacy in Bitcoin-like Digital Cash Systems[END_REF] to its users.

The term "peer" denotes those blockchain nodes that are directly connected. Nodes that are initially alone seek to establish new connections with a certain number of peers (e.g., 8 for Bitcoin) in order to be part of the network. The terms node and peer are therefore interchangeably used.

The magic number consists in a data-structure identifier characterizing the different blockchain protocols (i.e., 0xD9B4BEF9 is the magic number identifying the Bitcoin blockchain)

The value has been recorded on October 31 st , 2021.

The first year of the thesis and the year this contribution has been submitted to be published.

This work does not take into account rewards mining pool can gain from non-mining activities.

Funds deriving from different coinbase transactions may be adopted to pay out a single miner contribution.

This contribution analyzes the one shot consensus protocol at the core of the Tendermint blockchain.

Caisse des Dépôts is a member of ADAN[START_REF]Association pour le Développement des Actifs NumDériques[END_REF] association representing professionals in the digital assets and blockchain technologies sector in France.

Caisse des Dépôts is a member of the International Association for Trusted Blockchain Application, INATBA [318].

Récompenser les mineurs rationnels : Situations de banqueroute

En suivant la logique introduite dans [253], nous proposons un mécanisme de récompense alternatif qui décourage les comportements de "pool-hopping" et de "block-withholding". En réinterprétant la fonction de récompense proposée dans [253] comme le résultat d'une situation de banqueroute, nous

work presented in this manuscript is my own work, carried out under the scientific direction of Mr Stefano Secci (thesis director), Mrs Maria

Abstract

The disruptive technology born in 2008 with Bitcoin and known as blockchain represents a significant quality leap from the distributed database technology. Distributed systems theory provides then models and techniques to analyze some protocols characterizing the technology, however in order to analyze a blockchain system additional considerations on its users need to be done. This thesis aims at analyzing the different behaviors of the users operating in blockchains or more in general in DLTs (i.e., Distributed Ledger Technologies). The latter are considered as rational agents, fully aware of all actions available to them and capable of choosing the one they feel is the best for themselves. Game theory is then used to model situations where users are called to choose and perform certain actions within the DLT environment. This thesis analyzes different users as well as different blockchains with the scope of providing a general overview on the topic and formal results on their behaviors ; users may indeed be honest vis-à-vis of other users or they may behave maliciously (as Byzantine nodes) attacking the blockchain system. Keywords : Blockchain, Consensus, Game Theory, Crypto-assets.

ABSTRACT Chapter 4 Blockchain Interoperability between Rational Blockchain Users This chapter is devoted to the analysis of (i) distributed cross-chain swap problem in the blockchain context and (ii) the behaviors of transacting parties aiming at exchanging assets through cross-chain swaps. Cross-chain swaps enable interactions between multiple blockchain i.e., blockchain interoperability. We start by presenting a mathematical framework allowing to characterize blockchain swap protocols. Game theory is then used to model transacting parties (who swap crypto-assets) as rational agents and characterize the equilibria of existing cross-chain protocols.

Swap Problems and Swap Protocols

In this section we propose a formal definition of the swap problem and a formalization of the corresponding blockchain swap protocol that can be atomic or not. The latter consists of two different phases (i.e., publishing and commitment of transfers). In a general swap problem, swapping parties aim at exchanging assets among themselves. A swap protocol defines the set of asset transfers and the order in which they should be executed. Given a set of assets and the corresponding owners, a swap consists of an asset ownership exchange within the set of owners. • A = {1, . . . , m} is the set of assets to be swapped ;

• O = {1, . . . , n} is the set of owners or agents participating in the exchange. We consider in the following that n ≤ m since each owner owns at least one asset ; • u i is the payoff function for owner i ∈ O over bundles of assets in 2 A such that u i (b -1 0 (i)) < u i (b -1 * (i)) (i.e., each owner i strictly prefers the desired bundle of assets to her original bundle) and ∀S, T ∈ 2 A : S ⊆ T , u i (T ) ≥ u i (S) (i.e., a larger bundle is strictly preferred to a smaller one), for each i ∈ O.

The representation with two different surjective functions b 0 , b * describes swaps as ownership exchanges problems. Agents participate in a swap with the asset(s) they aim to exchange for others, preferring the desired new asset(s) to finding themselves as in the initial configuration. Moreover, we assume owners' payoff function increases monotonically with the size of the asset bundle.

The transition from an initial configuration to a post-swap configuration is defined by the corresponding swap protocol consisting in a sequence of operations to be executed in a certain order. In centralized swap protocols a central role in the swap is played by a trusted third party. That is, asset ownership is transferred first to the trusted third party that in turn transfers assets back to the new owners. On the other hand, decentralized swap protocols contemplate ownership transfers within asset owners only ; the latter agrees on a particular swap configuration (i.e., the assets to exchange) without trusting each other.

Atomic Swap Protocol

Whenever swapping parties do not trust each other it is in their interest to ensure that no participant can take advantage from the swap agreed on. The protocol must be constructed in such a way that the swap is performed in its entirety or no asset transfer is committed (i.e., all-or-nothing).

In the case of failures during the protocol execution, every swap participant must be able to regain possession of the original owned assets. In order to prevent participants to externally exchange the assets involved in the swap, the protocol requires assets to be locked in specific transactions (i.e., they cannot be the object of other transfers).

Once locked, the transfer commitment allows every participant to redeem the new swapped asset(s).

Moreover, due to the atomicity requirement :

(i) any commitment should be conditioned on the correct asset locking i.e., transfers are committed only when all assets of the swap are correctly locked ;

(ii) consequently to failures in the assets locking, the initial situation must be restored ;

(iii) once an asset transfer is committed all the other transfers have to be committed, too.

When considering blockchains -decentralized trustless environments -swap protocols need to be atomic according to Definition 4.5. Conditional transfers in blockchain systems are implemented with distributed contracts i.e., scripts executed on blockchain nodes that can enforce and regulate relationships among network actors. A widely adopted commitment scheme is the crypto-primitive hash-lock [START_REF] Wiki | Hashlock[END_REF] i.e., asset ownership is locked with a hash value h that is the outcome of a one-way function H with a secret s as input (i.e., h = H(s)) and can be unlocked only when s is revealed. Transfers are conditioned on the hash constraint guaranteeing that assets to be swapped have been properly locked. Whenever transfers are not committed, due to atomicity, the initial ownership configuration needs to be restored ; this can be implemented with time-locks [290] i.e., a contract primitive restricting the asset transfer until a specified future time. Hash-locks and time-locks properly combined enable 4.2. SWAP PROBLEMS AND SWAP PROTOCOLS conditional asset transfers necessary to satisfy requirements (i) and (ii) of a swap protocol. Hence, when considering a blockchain swap, an asset transfer consists of an atomic distributed contract that, according to certain protocols [5; 6], coincides with a distributed hash-time locked contract (HTLC).

The latter needs to be correctly implemented, published and validated on the network (i.e., part of the valid transaction history) before being committed. Concerning requirement (iii), a mechanism that forces committing all transfers is needed in order to avoid possible atomicity violations (see Section 4.4.1.3). However, having a forcing scheme comes at a price, i.e., loss of decentralization (see Section 4.4.2).

Atomic Blockchain Swap Protocol

In this work we consider blockchain swap protocols characterized by two distinct phases : a first phase in which transfers (i.e., hash-locked contracts) are published and a second one where they are committed. To achieve atomicity, the order in which operations in the two phases are executed matters (see Section 4.4). The commitment phase has to be conditioned by the execution of the publishing phase ; all the asset transfers have to be published before being committed. Therefore, a blockchain swap protocol is characterized by a publishing protocol σ P followed by a commitment protocol σ T .

While the first protocol (σ P ) is a simple sequence of transfers, the second one (σ T ) is a decentralized swap protocol according to Definition 4.3.

In order to analyze the participants' strategic behaviors the protocol needs to specify the schedules in which agents perform operations. Therefore, given a sequence of operation σ, a set of asset owners O and a centralized trusted authority τ , we define a decision function F : {1, . . . , t} → O ∪ {τ } as a map that specifies the agent(s) F (k) responsible for the publication (or commitment) of the transfer

Note that the agent(s) called to decide on the transfer can be either asset owners (i.e., F (k) ∈ O) or an external trusted actor (i.e., F (k) = τ ).

Definition 4.6 (decentralized blockchain swap protocol) A decentralized blockchain swap protocol or simply a blockchain swap protocol is defined by the pair (σ P , σ T ) where In this chapter we propose a game theoretical framework that formally characterizes the robustness of general blockchain systems in terms of resilience to rational deviations and immunity to Byzantine behaviors. Rational blockchain users faced with a blockchain protocol to follow may act altruistically (following the protocol) or maliciously (deviating from the protocol) according to their personal utility. On the other hand, Byzantine users deviate from the protocol in any situation (even acting irrationally). We prove the practical interest of our formal framework by characterizing the robustness of various blockchain protocols (Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF], Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF], Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a side-chain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and a cross-chain swap protocol [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]) to the behaviors of the two main types of blockchain user : transacting parties and validating nodes. The content of the chapter originates from [START_REF] Zappalà | Game theoretical framework for analyzing blockchains robustness[END_REF] A player that joins a mechanism that is t-weak-immune knows that she does not suffer any loss (i.e., outcome with negative utility) if there are at most t Byzantine players in the game. Under the assumption that a protocol provides positive outcomes, a t-immune strategy is always t-weakimmune. As the denomination might suggest, this new property is weaker. Formally, it is possible to consider it as one of its generalizations. Indeed, if we consider the equivalent game Γ ′ = ⟨N, S, u ′ ⟩ with u ′ = u -u(σ), the definition of t-immunity and t-weak-immunity are identical.

We say that a mechanism is weak immune if it is t-weak-immune for all t ∈ N and that a mechanism is (k, t)-robust if it is k-resilient and t-weak-immune.

In Section 5.2.1 we provide necessary and sufficient conditions to prove that a mechanism satisfies the property of optimal resilience and t-weak-immunity. Then, we have to take into account that players run complex protocols composed of a set of modules. We introduce in Section 5.2.2 the operator composition of games (see Definition 5.6), i.e., the game that corresponds to different games run at the same time by the same players. We prove that the properties above introduced are invariant with respect to this operator, i.e., if two protocols are independent one from another they preserve their properties when played at the same time.

Necessary and Sufficient Conditions for Optimal Resilience and Weak Immunity

In the following we study the necessary and sufficient conditions for mechanisms to be optimal resilient and weak immune.

According to [START_REF] Abraham | Distributed computing meets game theory : Robust mechanisms for rational secret sharing and multiparty computation[END_REF] if every strict subset of players has no incentive to change their strategy we say that the strategy profile is strongly resilient. (Γ, σ) is a strongly resilient mechanism if σ is strongly resilient. A mechanism (Γ, σ) is optimal resilient if it is practical and strongly resilient. The concepts of k-resilience and practicality are strictly connected with the properties of Nash equilibria, which have been fully studied (see for example [247; 311; 248; 249]). Therefore, connecting these two notions, through necessary and sufficient conditions, allow us to directly exploit the properties of Nash equilibria, such as strength [START_REF] Bernheim | Coalition-proof nash equilibria i. concepts[END_REF] and stability [248; 249].

Proof. If (Γ, σ) is a strongly resilient mechanism, then for all C ⊂ N and for all i such that

GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

extend the definition of composition of games to pairs of games in which different sets of players are involved. Indeed, for instance if a player i is involved in game A but not in game B, it is possible to

and she is assigned a "null" strategy (S ′ B = S B × {σ ∅ }) not influencing the utilities of the outcomes. Formally, for all s ∈ S B and for all j ∈ N ′ \ {i}, u ′ j (s, σ ∅ ) = u j (s), while for i ∈ N ′ we have that u i (s, σ ∅ ) = 0. Intuitively it is possible to extend the definition of composition of games to more than two games. In Section 5.4.1.5 we use the notation

We do not prove the associative property of this operator, but it is intuitive that the two games are the same, except for a different strategy labelling.

The following theorems allow us to model the building blocks of complex protocols, study the properties of the subsequent mechanisms and finally, through the composition of mechanisms, deduce the properties of the composed protocol. Proof. Let us prove the if part. If {σ Ai } and {σ Bi } are Nash equilibria for A and B, then ∀j and for any other pair of strategies for player j, σ ′ Aj and σ ′ Bj we have that :

where -j := {i ∈ N : i ̸ = j}. Hence, for any other {(σ ′ Aj , σ ′ Bj ), (σ A-j , σ B-j )} it is possible to deduce that :

Let us prove the only if part by contradiction, i.e., ∃{(σ Ai , σ Bi )} that is a Nash equilibrium for A ⊙ B but at least one among {σ Ai } and {σ Bi } is not a Nash equilibrium for A or B. Let us suppose that {σ Ai } is not a Nash equilibrium for A : ∃j, ∃σ

which contradicts the hypothesis that {(σ Ai , σ Bi )} is a Nash equilibrium for A ⊙ B. ■

The Nash equilibria can be identified by selecting equilibria within the single games. It is not possible to create other Nash equilibria nor to lose them in the process of composition of the games.

Concerning robustness properties for composition of games, we can state the following results on resiliency and weak immunity for two composed games. The results can be generalized for the composition of multiple games.

Proof. Thanks to Theorem 5.1 we have that {σ Ai , σ Bi } is a Nash equilibrium for A ⊙B. It is sufficient to prove that it survives the iterated deletion of weakly dominated strategy. Indeed, every strategy in the

, where τ * A is weakly dominated in A and τ * B is weakly dominated in B for some player i, is weakly dominated by another Nash equilibrium in A ⊙ B for the very same player i.

The strategy profile {σ Ai , σ Bi } survives the iterated deletion of these weakly dominated strategies. It is now sufficient to prove that there is no other weakly dominated strategy. By contradiction we assume that there is a player i such that there exists (σ ¯Ai , σ ¯Bi ) ∈ S A⊙B that weakly dominates (σ Ai , σ Bi ).

Therefore, considering the utility u for the player i, for every (τ A,-i , τ B,-i ) ∈ S A⊙B,-i we have that :

Therefore we have that :

which contradicts the assumption. ■ Theorem 5.2 formalizes the intuition that if two mechanisms are practical then, playing both selected strategy profiles is still a practical mechanism. Following propositions prove the resilience and immunity of the games composition.

GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

Proof. We know that for all C ⊆ N with 1 ≤ |C| ≤ k, all τ A,C ∈ S A,C and all i ∈ C, we have

. Hence, we have that for all S ⊆ N with

We recall that S A⊙B,S = S A,S × S B,S , thus for all S ⊆ N with

S A⊙B,S and all i ∈ S :

■

If a mechanism is k-resilient, then the protocol is followed by every player whenever at most k rational players are allowed. If there is more than one mechanism, the threshold on the maximum number of rational players allowed is the minimum among the rational player numbers k, k ′ in the individual mechanisms.

. GAME THEORETICAL MODELING FOR BLOCKCHAIN ROBUSTNESS

If a player combines two mechanisms which are weak immune for respectively at most t and t ′

Byzantine players, then it means that she is considering a mechanism which can provide non-negative outcomes if there are at most a number of Byzantine users equal to min(t, t) ′ .

The following corollaries generalize the results reported in Theorem 5.3 and Theorem 5.4.

block is approved or a non-valid block is not approved, u i (τ ) = 0 if a valid block is not approved and

The strategy prescribed by Tendermint consensus protocol is σ tc = (C, V, N V, N V ) i.e., to check for the validity of the proposal and then if the block is valid to vote for it, otherwise not vote for it.

If the number of rational or byzantine players allowed is f < 1 3 n, the other players have the necessary threshold to validate a block. Indeed, they can veto any validation of blocks proposed by malicious nodes. The mechanism (Γ tc , σ tc ) is thus not f -weak-immune for any f ≥ 1 3 n and we can state the following results.

Theorem 5. [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] The mechanism (Γ tc , σ tc ) is (f, f )-robust for any f < 1 3 n.

Proof. First, let's consider the case in which the proposer puts forward a non-valid block. If f < 1 3 n is the number of players who deviate, then at most 1 3 n will vote for the non-valid block, which is less then the threshold ν = 2 3 n asked by the consensus algorithm to validate the block. Let's thus consider the case of the proposer putting forward a valid block. The n -f altruistic player will vote in favour of validating the block. Since n -f ≥ 2/3 n + 1, the threshold ν is overcome. ■

If there are at least f ≥ 1 3 n byzantine players, it is possible to this set of players to veto any validation of blocks. The mechanism (Γ tc , σ tc ) is thus not f -weak-immune for any f ≥ 1 3 n. From now on, we exclude the case that no blocks are validated.

Theorem 5. [START_REF] Herlihy | Atomic cross-chain swaps[END_REF] The mechanism (Γ tc , σ tc ) is not f -weak-immune for any f ≥ 1 3 n + 2.

Proof. It is enough to prove that if there are f = 1 3 n + 2 byzantine players, a non-valid block is approved. Let us suppose that the players are split in 3 sets : altruistic players are divided in two set A and A ′ of dimension 1 3 n -1, while byzantine players are part of the third set B. Let us suppose that the proposer is a byzantine player. She sends two different incompatible values v and v ′ to the players PROTOCOLS i has to mine on average N s blocks before getting to the final state, following the optimal strategy, i.e. the strategy that minimizes the number of blocks to be mined. The problem has infinite states, because at any level k player i can create x k ∈ N forks. We thus fix a maximum number of blocks L ∈ N that can be mined at the same level (i.e. we set x k ≤ L) and consider the equivalent problem with a finite number of states. In order to find the optimal solution we compute the optimal Bellman operator [START_REF] Bellman | Dynamic programming and lagrange multipliers[END_REF], which provides the solution in close form. We find out that even increasing L, for significant (> 0.05) values of α the optimal strategy is to perform a selfish mining attack and create only one fork at every level. Figure 5.2 shows the average number of blocks that player i has to mine in order to perform an attack.

On average every block contains transactions for M = 10000 BTC. Mining a block is worth R = 6.25 BTC. Therefore an attack is rationally chosen by player i if N (α) < M R = 10000 6.25 = 1600. Since N (0.15) = 2347 > 1600, we have the proof. ■

The Bitcoin's mechanism can be made more resilient by reducing the number of bitcoins exchanged in a block M , the reward of a block R and the number of blocks B needed for validation.

On the long run the majority of users (α ≥ 1 2 ) produce the longer chain. However, on the short run a minority of users (α < 1 2 ) can make a fork the longer chain with positive probability. The following theorem provides the value of this probability.

Theorem 5.9 The probability for a byzantine player with computation power α, with α < 1 2 , to prevent PROTOCOLS transactions in a private manner i.e., off-chain without involving the Bitcoin blockchain. In practice, the channel consists of a user, let us say F. Every transaction from and to F must be signed by both users A and B. PROTOCOLS If a user decides to close the channel unilaterally, she receives her part of funds after a certain interval of time, while the other user receives it immediately. We formalize the protocol with a game in extensive form Γ op (see Definition 5.9), represented by its game tree (see Fig. 5.9). At every node of the tree (i.e., decision step) the player involved in the protocol has two actions available : either following it by signing the commitment required or not following it. The initial state corresponds to having no channel opened, while the final state corresponds to having the channel opened. We assign null utility to the initial state and positive utility (unitary by convention) to the final state. If at any step the players do not follow the protocol, they get back to the initial state, with outcome (0, 0). If they do follow at every step, they are able to open the channel, with outcome (1, 1). We denote by

) the strategy profile recommended by the protocol.

Definition 5.9 The opening game Γ op is a game in extensive form, with two players N = {A, B} and 4 nodes, labeled by a number (1 is the vertex) :

1. A has two actions available : C1b •• which provides outcome (0, 0) ; C1b A• which leads to node 2.

B has two actions available : C1a

•• which provides outcome (0, 0) ; C1a •B which leads to node 3.

3.

A has two actions available : T x •• which provides outcome (0, 0) ; T x A• which leads to node 4.

B has two actions available : T x A

• which provides outcome (0, 0) ; T x AB which provides outcome

(1, 1).

At every node the player involved in the protocol have two actions available : either follow it or not follow it. If at any step they do not follow it, they get back to the initial state, with outcome (0, 0). If they do at every step, they are able to open the channel, with outcome (0, 0). The strategy profile recommended by the protocol is Proof. In order to identify weak immune mechanisms we apply Proposition 5.4. We consider player A and the game Γ cl A in which B is the adversarial player whose utility is the opposite of player A's. The payoff matrix of the game

The only Nash equilibria of the game in pure strategies is (C1a AB , DN ), which provides outcome (0, 0). Since this is a zero-sum game, all the Nash equilibria provide the same outcome (v, v) where v = 0 is the value of the game. Since the value of the game is non-negative, player A has always a strategy to get at least 0. This strategy is C1a AB , which thus is the only one that player A can choose in a weak immune mechanism.

Analogously we can define the game Γ cl B in which A is the adversarial player, which lets us prove that C1b AB is the only weak immune strategy for player B. Therefore, (C1a AB , C1b AB ) is the only strategy profile that provides a weak immune mechanism. ■

We believe that Lightning Network should include the alternative protocol (Γ cl , σ * ) as default. In the case in which the channel is unilaterally funded, one of the player is already forced to follow the mechanism (Γ cl , σ * ). Listing all the possible strategies we have determined the only protocol which can be modeled as a weak immune mechanism. It is not possible to create any other protocol that can satisfy this property.

Updating Module

Performing a transaction within a channel consists in updating its balance. Technically, the previous commitments (C1a and C1b) with balance (x A , x B ) are replaced by two new commitments (C2a and C2b) with different balance (x ′ A , x ′ B ). In order to prevent players from publishing old commitments, they sign two Breach Remedy Transactions (BR1a and BR1b), that can invalidate C1a and C2b. Indeed, if any party publishes an outdated commitment the other one can retrieve all the cryptoassets in the fund. If, for instance, user A publishes the outdated commitment C1a, she can retrieve her fund x A unless user B publishes BR1a before ∆ blocks are validated. Briefly speaking, if any part publishes an outdated commitment the other part can retrieve all the assets in the fund. In practice the players PROTOCOLS have an incentive to delete outdated commitments to limit the risk of an unintentional leak, that could provoke their publication and thus the loss of all the assets stored in the channel. The protocol to update the balance (see Fig. 5.10) requires the players to sign the commitments in a specific order.

The protocol involves the following steps : We analyze the properties of the mechanism (Γ up , σ up ) under the assumption that it is always possible to publish a transaction within ∆ blocks, otherwise it is not possible to validate the breach remedy transactions in time. The mechanism is not immune, indeed if any user refuses to sign a commitment the players return to the original balance that provides lower payoff than the final balance.

However, the mechanism satisfies the properties of optimal resilience and weak immunity.

Theorem 5.14 The mechanism (Γ up , σ up ) is not immune.

Proof. Since we are considering a game with only two players, a mechanism is immune if it is 1immune. A mechanism is 1-immune (see Definition 5.4) if any player receives the same outcome by playing the recommended strategy, no matter which strategy the other player chooses. This is not the case of the mechanism (Γ up , σ up ), indeed if player A chooses σ up A and player B chooses

■

The property of immunity is too strong in this case, therefore we consider other weaker properties.

Theorem 5. [START_REF] Belotti | Bitcoin pool-hopping detection[END_REF] The mechanism (Γ up , σ up ) is optimal resilient and weak immune with probability 1 -Φ ∆ (α), but it is not immune.

Proof. We analyze the mechanism (Γ up , σ up ) under the assumption that it is always possible to publish a transaction within ∆ blocks, otherwise it is not possible to validate the breach remedy transactions in time. The probability that this happens when a byzantine agent with computational power α attacks the Bitcoin blockchain is 1 -Φ ∆ (α) (see Theorem 5.9).

The outcome for the strategy profile σ up is (1, 1), which cannot be increased by any other strategy profile. Therefore, the mechanism (Γ up , σ up ) is strongly resilient.

In order to prove that the mechanism is resilient, we have to exclude weakly dominated strategies.

We proceed by excluding all the actions that are included in a weakly dominated strategy. At node PROTOCOLS In order to prove that the mechanism is weak immune we apply Proposition 5.4. We consider one player i at a time and we make the other player j adversarial, by fixing her outcome as the opposite of player i (see Fig. 5.12). Then we prove that the best response of player j to player i never leads her to a negative outcome. We take i = A and we consider the game Γ up A in which player j = B has utility opposite to player i. The best response of player j to the strategy σ up A picked by player i is the strategy {C2a •• , BR1b •• }, i.e. at node 2 to avoid to reach a deal by not signing C2a. The payoff for player A is

1, A receives always a better outcome by picking action C2b

Hash-Time Locked Contract Module

A bidirectional payment channel only allows transactions inside a channel. In order to perform transactions through a network of channels Lightning Network introduces an additional construction, called Hash-Time Locked Contract (HTLC). The HTLC allows to create transactions that can be triggered at will. The HTLC makes use of the hash function, a deterministic caotic function that maps any input x to a fixed-length string y = hash(x). It is not possible to retrieve x given y in a faster way than trying with a bruce-force method to randomly guess x. Hence if x is chosen among strings of considerable length, it is almost impossible to identify x given by y = hash(x) in a reasonable time. Let us suppose that users A and B open a channel with balance (x A , x B ) and A wants to send a payment through HTLC to B so that the new balance would be

A creates a random data R and then computes H = hash(R). Then she sends an update of the contract to B, with a specific characteristic : if B publishes it, she can retrieve the difference x ′ B -x B only if she proves to know x such that H = hash(x) within ∆ blocks (in [3] ∆ = 1000). A can trigger the contract by providing R to B. If she does not do it, B cannot find x = R and thus has no incentive to publish the contract. The HTLC protocol works as follows (see Fig. 5.13) :

1. A creates a commitment C2b that allows F to send x ′ A to A, x B to B after ∆ blocks and x ′ B -x B to B if she publishes x such that H = hash(x) to the Bitcoin blockchain within ∆ blocks. A signs it and sends it to B.

2. Analogously, B creates a set of commitment C2a that allows F to send x ′ B to B, x A to A after ∆ blocks and x ′ B -x B to B if she publishes x such that H = hash(x) to the Bitcoin blockchain within ∆ blocks. B signs it and sends it to A.

A creates a transaction BR1a that lets B retrieve x A in case A publishes C1a and B publishes

BR1a within the following ∆ blocks. Then A sends BR1a to B.

B creates a transaction BR1b that lets A retrieve x B in case B publishes C1b and A publishes

BR1b within the following ∆ blocks. Then B sends BR1b to A.

The protocol for the HTLC corresponds to the protocol for updating a channel, with the only difference that the new commitments C2a and C2b provide a different output. Under the assumption that a transaction (or just the key R) can be published within ∆ blocks, we can define a game Γ htlc with the very same structure as Γ up (see Definition 5.11 and Fig. 5.11). Following the protocol corresponds to Theorem 5. [START_REF] Belotti | Rewarding miners : bankruptcy situations and pooling strategies[END_REF] The mechanism (Γ htlc , σ htlc ) is optimal resilient and weak immune, but not immune, with probability 1 -Φ ∆ (α).

Proof. Since the mechanisms (Γ htlc , σ htlc ) and (Γ up , σ up ) follow the very same structure, we can apply Theorem 5.15. ■

Routing Module

The Hashtime Locked Contract (HTLC) allows to create transactions that can be triggered at will.

Summing up what presented in Section 5. given H. In this way, user A can trigger the transaction whenever she wants by disclosing R to user PROTOCOLS transactions can be triggered. We analyze the protocol under this assumption.

The following theorems state that the mechanism corresponding to the routed payment protocol is not immune but is weak immune and optimal resilient.

Theorem 5.17 (Γ rout , σ rout ) is not immune.

Proof. Since the game Γ rout has three players, the mechanism is immune if it is 1-immune and 2immune. To prove that the mechanism is not immune, it is enough to prove that it is not 1-immune.

A

The property of immunity is too strong for this protocol, therefore we consider the other properties.

Theorem 5.18 Under the assumption that in both HTLCs the transactions can be triggered, (Γ rout , σ rout ) is optimal resilient and weak immune.

Proof. There is no other strategy than σ rout that can improve any of its payoffs u(σ rout ) = (1, 1, 1).

Thus (Γ rout , σ rout ) is a strongly resilient mechanism.

In order to prove that the mechanism is practical, we proceed by excluding the actions that belongs to weakly dominated strategies. At node 5 B never plays N because she would receive -1 rather than 1.

Therefore at node 4 C never chooses N because she would receive 0 rather than 1. Analogously at nodes 3, 2 and 1 players do not choose alternative actions, because they would receive 0 rather than 1. The strategy profile σ rout is the only one that survives the iterated deletion of weakly dominated strategies, hence the mechanism is practical.

In order to prove that the mechanism is weak immune we apply Proposition 5.4. We consider one player i at a time and we introduce an adversarial player j that plays at any node which is not played by i (see Fig. ■ PROTOCOLS

The strategy profile recommended by the protocol is σ 2 = ({Y, N, Y }, {Y, Y, N }), respectively played at nodes ({2, 4, 5}, {1, 3, 4}). Until x is revealed, the transactions cannot be triggered, therefore they provide null payoff. When x is revealed, A receives the litecoins (thus with payoff equal to 1). B does not know if he receives the asset, hence her payoff is 0.

Since the two blockchains are independent, we consider the composition of the two games (G 1 ⊙ G 2 , {σ 1i , σ 2i }) that represents the full protocol and analyze its properties.

Theorem 5.22 Under the assumption that any transaction can be published within a time interval

Proof. The strategy profile {σ 1i , σ 2i } provides outcome

If B considers a strategy σ * B that lets her play action N at node 2 of the Bitcoin game and action N at node 1 of the Litecoin game, the outcome is

thus reducing the payoff for player A. In a two-player game a mechanism is immune if it is 1-immune (see Definition 5.4), but in this case A receives a loss if B performs a specific Byzantin behavior. ■ Theorem 5.23 Under the assumption that any transaction can be published within an interval of time

) is optimal resilient and weak immune.

Proof. It is enough to prove that the two mechanisms (G 1 , σ 1 ) e (G 2 , σ 2 ) satisfy the properties and then exploit the properties of the operator composition of games.

In game G 1 the strategy profile σ 1 is the only one with outcome (1, 1), which is maximal. Thus we have that (G 1 , σ 1 ) is strongly resilient.

Every strategy different from σ 1 is weakly dominated, indeed they bring to either outcome -1 or 0, which is lower than u 1 (σ 1 ) = (1, 1). Thus σ 1 is a stable Nash equilibrium and for Proposition 5.2 we have that the mechanism (G 1 , σ 1 ) is practical.

In order to prove weak immunity we apply Proposition 5.4. When following respectively strategies σ 1A and σ 1B both A and B never get negative utility. Therefore the mechanism (G 1 , σ 1 ) is also weak In game G 2 the strategy profile σ 2 produces an outcome (1, 0) which is maximal for both players, thus we have that the mechanism (G 2 , σ 2 ) is strongly resilient.

The strategies within σ 2 are never weakly dominated, because none of the others can provide a better outcome. Hence the mechanism is practical.

Every outcome is non-negative, therefore the mechanism is weak immune.

Since both mechanisms are optimal resilient and weak immune, we can apply Theorems 5.2, 5.3 and 5.4, that ensure the invariance of the properties once the operator composition is applied. The mechanism

) is thus optimal resilient and weak immune. ■

The mechanism is not immune, indeed it is sufficient that one player does not create or publish a transaction to stop the protocol. Under the assumption that any transaction can be published within a time interval [0, ∆ Alice ] the mechanism is optimal resilient and weak immune.

Future Work Directions

In this section, we present research questions opened up from the contributions presented in this manuscript. We order these research directions from the more general to the more specific.

Rational Behaviors.

Our work raises immediate research questions on the rationality of blockchain users behaviors. After presenting the rationality concept in game theory we encounter throughout the different contributions the limitations of such assumption in real life situations. Indeed, players may act irrationally or may be led to deviate by external phenomena. This opens up an interesting research direction aiming at modeling blockchain systems with fewer assumptions, meaning model real-word blockchain protocols.

These analyses are much more complex to handle and quite delicate, but they will probably have huge impacts on the field, and on the understanding of the systems. An additional interesting question concerns the position of results and theoretical analysis with respect to to real world behaviors of participants. Chapter 3 provides such positioning for the pool-hopping behaviors. To do such comparison for a larger set of behaviors, behavioral sciences need to be integrated, requesting collaboration among different research fields.

Blockchain Users' Behaviors.

In this thesis, we propose a game theoretical analysis of blockchain users' behaviors. The work models the robustness of blockchains towards a particular set of rational and byzantine behaviors i.e., protocol deviations (attacks) presented in the literature or observed in real life scenarios. The work presented in Chapter 5 analyzes Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF], Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF], Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], a side-chain protocol [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] and a cross-chain swap protocol [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF] however, other types of blockchain protocols should be modeled as well with the developed framework e.g., Algorand [START_REF] Chen | Algorand : A secure and efficient distributed ledger[END_REF] or DAG-based blockchains (e.g., Spectre [START_REF] Sompolinsky | Spectre : A fast and scalable cryptocurrency protocol[END_REF], Phantom [START_REF] Sompolinsky | Phantom[END_REF] or IOTA [START_REF] Popov | Equilibria in the tangle[END_REF]). Moreover, as blockchain represents a disruptive technology, new protocols as well as new attacks to such protocols are discovered on a monthly basis. The analysis performed in Chapter 5 should then be extended not only to new blockchain protocols but also to include new protocol deviations.

Solution Concepts.

In this manuscript, when dealing with rational agents, we adopt the notion of Nash En revanche, les utilisateurs byzantins s'écartent du protocole dans n'importe quelle situation (même en agissant de manière irrationnelle). Nous prouvons l'intérêt pratique de notre cadre formel en caractérisant la robustesse de deux protocoles blockchain layer-1 (i.e., Bitcoin [START_REF] Nakamoto | A peer-to-peer electronic cash system[END_REF] et Tendermint [START_REF]Tendermint Byzantine-fault tolerant state machine replication[END_REF]) et de trois protocoles blockchain layer-2 (i.e., Lightning Network [START_REF] Poon | The bitcoin lightning network : Scalable off-chain instant payments[END_REF], un protocole side-chain [START_REF] Pedrosa | Platypus : Offchain protocol without synchrony[END_REF] et un protocole de swap inter-chaîne [START_REF] Nolan | Re : Alt chains and atomic transfers[END_REF]). Le contenu de ce chapitre provient de [START_REF] Zappalà | Game theoretical framework for analyzing blockchains robustness[END_REF].

Le tableau suivant représente la structure d'analyse du manuscrit. Les deux premiers chapitres introduisent les sujets "Blockchain" et "Théorie des jeux". The latter are considered as rational agents, fully aware of all actions available to them and capable of choosing the one they feel is the best for themselves. Game theory is then used to model situations where users are called to choose and perform certain actions within the DLT environment. This thesis analyzes different users as well as different blockchains with the scope of providing a general overview on the topic and formal results on their behaviors ; users may indeed be honest vis-à-vis of other users or they may behave maliciously (as Byzantine nodes) attacking the blockchain system.

Modèle de comportement

Keywords : Blockchain, Consensus, Game Theory, Crypto-assets Résumé : La technologie disruptive née en 2008 avec Bitcoin et connue sous le nom de blockchain représente un saut qualitatif important par rapport à la technologie des bases de données distribuées. La théorie des systèmes distribués fournit alors des modèles et des techniques pour analyser certains protocoles caractérisant la technologie, cependant afin d'analyser un système blockchain des considérations supplémentaires sur ses utilisateurs doivent être faites. Cette thèse vise à analyser les différents comportements des utilisateurs opérant dans les blockchains ou plus largement dans les DLTs (i.e., Distributed Ledger Technologies). Ces derniers sont considérés comme des agents rationnels, pleinement conscients de toutes les actions à leur disposition et capables de choisir celle qui leur semble la meilleure pour eux-mêmes. La théorie des jeux est alors utilisée pour modéliser des situations où les utilisateurs sont appelés à choisir et à effectuer certaines actions dans l'environnement DLT. Cette thèse analyse différents utilisateurs ainsi que différentes blockchains dans le but de fournir une vue d'ensemble sur le sujet et des résultats formels sur leurs comportements ; les utilisateurs peuvent en effet être honnêtes vis-à-vis des autres utilisateurs ou se comporter de manière malveillante (comme des noeuds byzantins) en attaquant le système blockchain.

Mots-clés : Blockchain, Consensus, Théorie des Jeux, Crypto-actifs