## I Introduction

Blockchains have drawn much research interest, way beyond its first realization, Bitcoin [3], a cryptocurrency application built upon blockchains. From system perspectives, various facets, especially performance and scalability, have been intensively studied by multiple computer systems communities including but not limited to: computer security [7], distributed systems [11], and database systems [9]. Works on the theoretical foundation of blockchains are, however, comparatively limited, and mostly in the cryptocurrency context [6, 8, 10], usually in a permissionless setup where nodes are free to join or leave the blockchain network. In permissioned blockchains such as Hyperledger Fabric [2], where Practical Byzantine Fault-Tolerance [4] (PBFT) is the de facto consensus protocol, much work focused on PBFT and its variants without in-depth reasoning on the node’s (or, user’s) rationality—analyses simply assume that a node is either faulty or non-faulty. Admittedly, the emphasis of reasoning about a node’s rationality is historically an area in multi-agent systems and game theory.

This position paper envisions and advocates that a global-scale, likely utility-incentive, blockchain system might be better understood from a holistic view of multiple perspectives as its theoretical foundation. As a starting point, we take a hybrid approach of both distributed computing and game theory to study blockchains. The inner-connection between distributed computing and game theory dates back to 2011 [1], which reviewed important commonality between, and more importantly complimentary research methodologies shared by two communities, both of which parallelly concentrated on distributed irrational-machine systems and utility-maximizing multi-agent systems, respectively. We will articulate the models of our approach in §II, formulate the Blockchain Game in §III problem, sketch one possible Nash equilibrium for the problem and discuss open questions in §IV.

## Ii Models

We illustrate the Blockchain Game in Figure 1.
There are three type of nodes^{1}^{1}1Also called players (game theory), users (databases), or participants (distributed systems), depending on various contexts. involved in a blockchain game:
a good citizen (C) who always votes for the proposal,
a terrorist (T) who always votes against the proposal,
and an adventurer (A) who makes her decision to maximize the utility (either voting for () or against () the proposed value, i.e., ).
A proposal could be a proposed value in a permissioned blockchain or a newly-mined block to be verified by a permissionless blockchain.

We use to denote the entire set of nodes, and use the cardinality of the node set. We will use to denote the cardinality of the terrorist set , to denote the cardinality of the citizen set , and and for the two subsets’ cardinalities, respectively.

## Iii The Blockchain Game

### Iii-a Normal Game Strategies

In the real world, a distributed system, including blockchains, usually adopts a timeout mechanism that sets some unresponsive nodes to a default value, such as null or nil. From a pure system point of view, an abstain vote is not different than a no vote—the system takes a very conservative position in interpreting the responses. In the case of blockchains, therefore, the consensus protocol interprets an abstain vote as a no vote. Formally, we have two pure strategies for all the nodes in the blockchain: , .

In blockchains, it takes a simple quorum mechanism to move forward. In permissionless blockchains (Bitcoin [3], Ethereum [5]), the longest list of transactions will overwrite the shorter ones and the system is considered stable as long as no more than 51% nodes are controlled or compromised (i.e., ). In permissioned blockchains (Hyperledger Fabric [2] and other variants based on PBFT [4]), non-faculty nodes need to outnumber the faulty nodes by at least 200%. The following discussion assumes the blockchain is permissionless for the sake of space.

If the system is not compromised, the non-faulty nodes will continue to work on “agreeing” on the next proposed value and get rewarded by a transaction fee, and the faulty nodes might be forced to leave the network; Otherwise, the faulty nodes overturn the existing network and collect a high reward, leaving the “honest” nodes’ work worthless. Note that we neglect the cost (e.g., electricity, hardware procurement, space rental) for mining blocks or attacking the network. Formally, the payoff function for a non-faulty node is defined as follows:

(1) |

where denotes the overall payoff of a winning “honest” nodes and denotes that winning non-faulty node, i.e., . Statistically, each “honest” node receives payoff. Similarly, we have the payoff for a faulty node (but not a terrorist) as follows:

(2) |

where denotes the overall payoff of all “deviating” nodes and denotes a faulty node, i.e., .

### Iii-B Zero-Sum among Non-Terrorist Nodes

An important observation is that all the non-terrorist nodes constitute a zero-sum game. That is, the Byzantine nodes, or terrorists, are disinterested in the expense or utility incurred in the game—the only objective is to sabotage the network. As a consequence, we have the following invariant:

(3) |

where the first term indicates the payoff for good citizen, the second term indicates the payoff for adventurers who vote for the proposal, the third term indicates the payoff for adventurers who vote against the proposal.

### Iii-C Consensus Protocols

There are rich literature in handling arbitrary nodes in the distributed system community. In the context of blockchains, there are two main categories of consensus protocols by which the participating reach an agreement: (i) Proof-of-Work (PoW) and its variants for permissionless blockchains; (ii) PBFT for permissioned blockchains. Again, we will focus on permissionless blockchains in this paper.

Permissionless blockchains require that the number of non-faulty nodes is strictly larger than that of faulty nodes. Therefore, we set the difference as one between the two cliques as the borderline case in the following discussion:

(4) |

### Iii-D Blockchain Game

With all the aforementioned preliminaries, we are ready to define a general blockchain system and the associated game.

###### Definition III.1 (Blockchain System).

A blockchain system is represented as a tuple , where denotes the set of all nodes (or, players), denotes the set of strategies and associated payoffs available for the nodes, and denotes the consensus protocol among the nodes.

###### Definition III.2 (Blockchain Game).

In a blockchain system , each adventurer node in of a blockchain maximizes its utility according to without violating .

## Iv Discussions

Since the Blockchain Game exhibits a finite number of players and strategies, there must exist at least one Nash equilibrium. Obviously, the solution to the above equations represents one such equilibrium. Due to limited space, we simply give the closed-form solution without numerical analysis:

(5) |

where . Note that in the real world, is, usually, significantly larger than , implying that . We call this variable reciprocal risk factor (RRF), indicating the payoff ratio of a compliant action over a deviating action.

It should be clear that the results are for permissionless blockchains only, although a similar one can be obtained for permissioned blockchains as well. It should also be noted that the discussion so far is limited to a normal game, which is played by the nodes only once. We leave extensive-form game that counts times as an open question and our future work.

## References

- [1] (2011) Distributed computing meets game theory: combining insights from two fields. SIGACT News. Cited by: §I.
- [2] (2018) Hyperledger fabric: a distributed operating system for permissioned blockchains. In EuroSys, Cited by: §I, §III-A.
- [3] Cited by: §I, §III-A.
- [4] (1999) Practical byzantine fault tolerance. In Operating Systems Design and Implementation (OSDI), Cited by: §I, §III-A.
- [5] Cited by: §III-A.
- [6] (2015) The miner’s dilemma. In IEEE Symposium on Security and Privacy, Cited by: §I.
- [7] (2019) Teechain: a secure payment network with asynchronous blockchain access. In ACM Symposium on Operating Systems Principles (SOSP), Cited by: §I.
- [8] (2017) Hybrid Consensus: Efficient Consensus in the Permissionless Model. In 31st International Symposium on Distributed Computing (DISC), Cited by: §I.
- [9] (2019) Fine-grained, secure and efficient data provenance on blockchain systems. Proc. VLDB Endow.. Cited by: §I.
- [10] (2018) The gap game. In ACM SIGSAC Conference on Computer and Communications Security (CCS), Cited by: §I.
- [11] (2019) Monoxide: scale out blockchains with asynchronous consensus zones. In USENIX Symposium on Networked Systems Design and Implementation (NSDI), Cited by: §I.

Comments

There are no comments yet.