Agent-Based Simulations of Blockchain protocols illustrated via Kadena's Chainweb

TL;DR

This paper presents a simulation system to analyze how economic incentives and adversarial behaviors impact the security and liveness of blockchain protocols, demonstrated through Kadena's Chainweb.

Contribution

It introduces a novel simulation framework for blockchain security analysis that incorporates economic incentives and adversarial strategies, applied to Chainweb's complex Proof-of-Work system.

Findings

Phase transition in block height growth rate with shard connectivity

Censorship is too costly for rational miners in Chainweb

Formal description of Chainweb's architecture

Abstract

While many distributed consensus protocols provide robust liveness and consistency guarantees under the presence of malicious actors, quantitative estimates of how economic incentives affect security are few and far between. In this paper, we describe a system for simulating how adversarial agents, both economically rational and Byzantine, interact with a blockchain protocol. This system provides statistical estimates for the economic difficulty of an attack and how the presence of certain actors influences protocol-level statistics, such as the expected time to regain liveness. This simulation system is influenced by the design of algorithmic trading and reinforcement learning systems that use explicit modeling of an agent's reward mechanism to evaluate and optimize a fully autonomous agent. We implement and apply this simulation framework to Kadena's Chainweb, a parallelized Proof-of-Work system, that contains complexity in how miner incentive compliance affects security and censorship resistance. We provide the first formal description of Chainweb that is in the literature and use this formal description to motivate our simulation design. Our simulation results include a phase transition in block height growth rate as a function of shard connectivity and empirical evidence that censorship in Chainweb is too costly for rational miners to engage in. We conclude with an outlook on how simulation can guide and optimize protocol development in a variety of contexts, including Proof-of-Stake parameter optimization and peer-to-peer networking design.

Figures

Equations

$${\mathsf{E}}_{\alpha }[R_t]=\sum _{\tau =0}^{k-1}{\alpha }^{\tau }U(S_{t-\tau })$$

$$S_{t+1}=S_t-\eta \sum _{\tau =0}^{k-1}{2}^{-\tau }{\nabla }_{S_{t-\tau }}U(S_{t-\tau }).$$

$$U_{i,\alpha }(S_t)=U_{i,\alpha }(A_t,h_t)=\frac{\gamma (\text{height}({\mathcal{C}}_{\alpha ,t}))}{h_t}$$

$$U_i(S_t)=\sum _{\alpha \in [N_{\text{shards}}]}{U}_{i,\alpha }(S_t)$$

$${\Lambda }_{\text{Chainweb}}((v,w),T(v)\cup T(w))=$$

$$(0pt(T(w))==0pt(T(v))-1)$$

$$\vee (0pt(T(w))-1==0pt(T(v)))$$

$$\vee (0pt(T(w))==0pt(T(v)))$$

$$\vee (0pt(T(v)==0)$$

$$\vee (0pt(T(v)==0)\vee \mathsf{compatible}(T(v),T(w))$$

$$H_{\text{total}}=\sum _{i=1}^{N_{\text{net}}}{H}_i$$

$${\Gamma }_{\alpha }=\frac{1}{H_{\text{total}}}\sum _{i=1}^{N_{\text{net}}}{H}_i{\zeta }_{i,\alpha }$$

$$\alpha$$

$$j$$

$$t$$

$$H(\tau )=\frac{1}{N_{\text{net}}}\frac{1}{N_{\text{shards}}}\sum _{i=1}^{N_{\text{net}}}\sum _{\alpha =1}^{N_{\text{shards}}}{\mathsf{E}}_t[h_{i,\alpha }(t))-h_{i,\alpha }(t-\tau )]$$

$${\mathsf{E}}_t[h_{i,\alpha }(t)-h_{i,\alpha }(t-\tau )]\approx \frac{1}{kT}\sum _{t\le T}(h_{i,\alpha }(t)-h_{i,\alpha }(t-\tau ))$$

$$\overline{\tau }=\frac{1}{N_{\text{shards}}}\sum _{i=1}^{N_{\text{shards}}}{\mathsf{E}}_k\left[\underset{k\in [N_{\text{net}}]}{\max }{\hat{\tau }}_{i,j,k}-\underset{k\in [N_{\text{net}}]}{\min }{\hat{\tau }}_{i,\alpha ,k}\right]$$

$${\gamma }_{\text{honest}}(h)$$

$${\gamma }_{\text{adversary}}(h)$$

Full text

I Introduction

Blockchain systems provide security via the economic disincentivization of malicious behaviors, such as double-spending or long-range attacks. Formally, this security is established by proving that the system achieves liveness, consistency, and persistence under suitable networking conditions (e.g. partial synchrony or asynchrony) and under the assumption that honest and rational agents are in the majority [1, 2, 3]. Many of these results give precise quantitative conditions that prescribe when a protocol will fail as a function of parameters, such as the difficulty adjustment period [1] or epoch length [2]. However, it becomes exceedingly difficult to provide similarly strong results when dealing with sharded or parallelized blockchains. There is a marked loss in quantitative strength in the existing literature of results, as accommodating for communication complexity and resource (e.g. energy, space, or stake) redistribution leads to significantly worse liveness performance [4, 5] and weaker tolerances for Byzantine actors. Mathematically, the main reason for this loss in statistical power comes from an inability to apply non-trivial concentration inequalities to all chains simultaneously, due to residual correlations that stem from cross-shard transactions and the overhead of repeated committee selection. Moreover, the increased communication cost for cross-shard or cross-chain transactions is only described asymptotically, which makes it hard to tune practical peer-to-peer networking algorithms for cross-shard transactions. Finally, as one increases the number of shards, there is often a dramatic increase in the number of parameters, such as timeouts and resource limits per shard, that a protocol designer must choose. The choice of these parameters can dramatically impact real-world performance and security of a sharded or parallelized blockchain. This paper will introduce agent-based simulation, which is used in a variety of other fields, as a way for protocol designers and practitioners to overcome some of these problems.

Agent-based simulation is used by practitioners and researchers in algorithmic trading [6], artificial intelligence [7], autonomous vehicles [8], cybersecurity [9], economics [10], energy allocation [11], and by the US Commodities and Futures Trading Commission to detect fraudulent market activity [12]. These systems define a set of agents $A_{1},\ldots,A_{n}$ that each have a state space $\mathcal{S}_{i}$ and interact with each other via a prescribed set of actions $\mathcal{A}$. Each agent receives updates to their state, caused either by the choice of actions of other agents or due to exogenous signals (e.g. external market prices), and then computes a policy function $\pi_{i}$ that selects an action for an agent to take. After running a number of simulations of agents interacting under different ensembles of initial conditions, exogenous data, and policies, a practitioner usually computes statistical averages and/or estimators of game theoretic quantities [13] to provide estimates of ‘macroscopic’ quantities that are emergent properties of the agent interaction. The statistical sampling of these ensembles is usually implemented via Monte Carlo (MC) and Markov chain Monte Carlo (MCMC) methods, while the designing of policies, state spaces, and action spaces is performed via analytic modeling and more recently, deep reinforcement learning [7].

While these techniques have been successfully deployed in practice within other financial disciplines, the use of agent-based simulations for blockchain development has been scant. As far as the authors can tell, agent-based blockchain simulation has focused on refining selfish mining rewards [14], reducing the energy usage of Proof-of-Work systems [15], and on disproving the claims of various block-free ledgers (e.g. IOTA [16]). However, agent-based simulation can be used as a production tool to help protocol designers optimize parameters, estimate latency and bandwidth usage, and to estimate the true cost of security for Proof-of-Stake systems. Moreover, the pervasive usage of agent-based simulations in production environments within algorithmic trading intimates that the technique is useful for monitoring and estimating risk within live blockchain systems.

We aim to illustrate the versatility of agent-based simulation via an analysis of Chainweb, a parallelized Proof-of-Work protocol that has eluded a closed-form security proof due to explicit correlation between chains that makes it difficult to use standard probabilistic tools. Our simulations, which are designed to handle arbitrary distributed consensus protocols, will show that we can get high-fidelity estimates for the latency-security trade-off in Chainweb and an estimate for how much miners lose when they try to censor particular chains.

Finally, we note that estimating the precise cost of security is a difficult challenge that involves a number of variables, some of which are exogenous to the underlying chain like rental markets [17], arbitrage opportunities on centralized and decentralized exchanges, and the difficulty of estimating the market impact of attacks. The simulations in this paper illustrate how endogenous design choices, such as difficulty adjustment periods or shard correlations, affect practical protocol performance. Our final section will conclude with a description of how simulations can interact with exogenous data (akin to trading strategies) and how we can use simulation to model the effects of volatile exchange prices and derivatives markets on chain security. These uses are increasingly important as the security of Proof-of-Stake protocols is inseparably tied to exogenous data and judicious parameter selection (e.g. slashing rates in live protocols such as Tezos [18]). Even alternative Sybil resistance mechanisms such as Proof-of-Replication (used in FileCoin [19]) and privacy data marketplaces [20] end up relying on market making and order matching functionality that is best optimized via agent-based simulation.

II Simulation Methodology

We will discuss our simulation methodology in two parts: one that evinces the features of our generic simulation platform and another that describes how we modeled agents within our system.

II-A Simulation Platform

Our C++ simulation platform consists of a custom discrete event simulation that emulates the peer-to-peer network of a blockchain system and uses a probabilistic generative model to generate events that corresponds to actions that agents can take within a blockchain system. We use MCMC methods to sample from this model to generate the next event and to propagate this event via the network graph. Each protocol, whether it be Proof-of-Work, Proof-of-Stake, of Proof-of-Replication, has a standardized interface to define its generative model. This interface forces the protocol designer to specify a model for event arrival times, a method for selecting an agent or committee to produce an event, and actions that agents are supposed to take. The protocol designer also has to select a routing algorithm that represents how protocol users are gossiping blocks and off-chain packets with each other. We deliberately separate the routing algorithm from the underlying graph of miners and users, allowing us to test how the system behaves with different gossip protocols. This allows for a protocol designer to test their protocol under deterministic algorithms, such as Kademlia [21], or a randomized gossip method [22]. Moreover, the design of this platform is based on a combination of high-frequency financial back-testing simulations, which use highly optimized, low latency versions of probabilistic networking models, and computational physics simulations, which provide optimized methods for evolving systems of interacting objects.

The simulation also includes a domain-specific language for describing the statistical calculations and policies of individual agents. In order to mimic cryptographic simulation-based proofs [23] and ideal functionalities, we allow for agents to directly interact with the MCMC model. This allows for honest agents to mutate stochastic components of the simulation related to their local state (e.g. hash power, bonded stake or space) and lets Byzantine agents mutate the state of other agents. Agent computations are not restricted and allowed to be generic; for instance, an agent can use a trained TensorFlow or PyTorch model as a policy. Given that there is a modicum, at best, of data stored in blockchains, all agent policies used in the sequel will be rules-based and closer to high precision, low recall trading strategies versus low precision, high recall reinforcement learning policies.

II-B Agent Design Methodology

We use agent-based models to model rational, Byzantine, and adversarial miner strategies. We assume, without the loss of generality, that our agents satisfy the Byzantine-Altruistic-Rational assumption [24]. Agents are represented via a state and action space model, in which agents provide a utility function $U:\mathcal{S}\rightarrow\mathbb{R}$ that is used to adapt a policy, $\pi:\mathcal{S}\rightarrow\mathcal{A}$, where the state space is $S$ and the action space is $\mathcal{A}$. In this paper, we define our state space to be $\mathrm{A}_{t}\times\Delta^{N_{\text{shards}}}$, where $\mathrm{A}_{t}$ is the miner’s local arboretum at time $t$ and $\Delta^{N_{\text{shards}}}$ represents the miner’s hash power distribution. Note that we explicitly exclude block withholding from the action space, as the only choices that a miner can make involve changing their hash power distribution. In particular, this also means that our action space is simply $\Delta^{N_{\text{shards}}}$, as any action corresponds to a choice of hash power distribution. As this is preliminary work, we excluded selfish mining and withholding attacks to simplify the statistical analysis111Our future work will discuss using adaptive sampling methods to deal with the non-stationarity that occurs when adding block withholding in §4. We will expand upon these results and include selfish mining and withholding attacks in future work. Agents adjust their policies by attempting to optimize their expected reward under a prescribed utility function. For simplicity, we assume that the utility function is $C^{1}$, so that we can optimize it via gradient descent. Drawing inspiration from the reinforcement learning literature, we define the expected reward as the $k$-step exponential moving average ($\alpha<1$) of the utility function:

[TABLE]

where $S_{t}\in\mathcal{S}$ is the state observed by the agent at time $t$. In this paper, $S_{t}$ is simply the agent’s local copy of the Chainweb arboretum at time $t$ and their current hash power distribution. From here on, we fix $\alpha=\frac{1}{2}$ and let $\mathsf{E}[R_{t}]=\mathsf{E}\left[R_{t},\frac{1}{2}\right]$. Thus, given a utility function, an agent will update their state via the ordinary gradient descent iteration,

[TABLE]

Using gradient descent also helps us enforce a locality constraint that ensures that miner strategies are purely local and not reliant on long-term historical results.

In order to program the agents within our simulation environment, we have developed a custom domain-specific language that aims to optimize the computation of utilities and policies for each simulated agent. This will be discussed in more detail in a subsequent paper by a subset of the authors. Using this language, we can specify what statistical signals trigger agents to take actions, allowing for us to describe complex agent strategies and policies via a simple script. Our language also allows for us to treat agents as a template, which lets us take a set of nodes and assign the same strategy to that set of nodes. This allows for easy specification of agent distributions, allowing for a user to specify policies $\pi_{1},\ldots,\pi_{n}$ and their relative proportions $p\in\Delta^{n}$.

II-B1 Utility Function

The authors of [25] show that in the continuous time and zero latency (e.g. no peer-to-peer network) setting, Markovian agents maximize their expected reward in Bitcoin by optimizing a utility function propotional to $\frac{R(t)}{H(t)}$, where $R(t)$ is the number of rewards that the agent has accrued at time $t$ and $H(t)$ the agent’s hash power expenditure at time $t$. Since this paper assumes that $H(t)$ is constant and uniform for all agents, we can simply define the single chain utility function to be:

[TABLE]

where $h_{t}\in(0,1)$ is the fraction of hash power placed on chain $\mathcal{C}_{\alpha,t}$ is the $\alpha$th chain of the arboretum $A_{t}$ and $\gamma$ is the fraction of blocks in chain $\mathcal{C}$ that agent $i$ produced (see equation 4). Since both values fall in $(0,1)$, we’ve removed the issue of ensuring that the dynamic ranges of these quantities are compatible and will not under/overflow. In future work, we plan on allowing $h_{t}$ to be an arbitrary positive real number, representing energy costs, which will force us to add in a scaling constant to this utility function.

In the multiple chain setting, we simply define the $i$th miner’s utility function as:

[TABLE]

III Chainweb Details

For demonstration of the proposed modeling techniques we will analyze Chainweb [26], a parallelized Proof-of-Work network architecture designed to provide high security and high transaction throughput. Chainweb serves as an ideal use case for simulation because designers have to choose $\Omega(N_{\text{shards}}^{2})$ parameters and because it is difficult to formally prove that Chainweb is resistant to miner censorship. As there has not been a formal description of Chainweb in the literature, we will provide both an informal description (with visualization) and a formal description that proves that the parallelized system achieves liveness.

III-A Informal Description

Chainweb is a parallel chain Proof of Work architecture that combines hundreds or thousands of individually mined peer chains into a single network. Figure 1 depicts ten chains that are connected via the Petersen graph. The three-dimensional figures show the dependencies of blocks at different heights on blocks of lower heights. Each chain in the Chainweb braid maintains its own ledger, and blocks on each chain are mined with Nakamoto-style Proof of Work hashing. Peer chains incorporate each other’s Merkle roots to enforce a single super chain that offers an effective hash power that is the sum of the hash rate of each individual chain. Each chain in the network mines the same cryptocurrency which can be transferred cross-chain via a Proof-of-Burn verified with trustless Simple Payment Verification (SPV) at the smart contract level. The configuration of the Chainweb braid and the relationship between chains is fixed at launch and can be hard forked to larger configurations as throughput demands.

The majority of miners are expected to mine the entire Chainweb braid, and as such each miner will maintain its own local version of Chainweb, the braid of which will be recombined with those of other miners as blocks are created.

III-B Formal Description

Notation

• •

For any $n\in\mathbb{N},[n]=\{1,2,\ldots,n\}\subset\mathbb{N}$

• •

$\mathcal{T}_{h,d}$ is the set of a directed trees with maximum height $h$ and maximum degree $d$

• •

$\mathcal{T}=\displaystyle{\lim_{h,d\uparrow\infty}}\mathcal{T}_{h,d}$. We can take this limit as there is a natural lattice: $\mathcal{T}_{h,d}\subset\mathcal{T}_{h^{\prime},d^{\prime}}$ if $h<h^{\prime}$ and $d<d^{\prime}$

• •

$\mathcal{B}\subset\{0,1\}^{*}$: The space of admissible blocks

• •

$\mathcal{T}_{\emptyset}$: The tree with one node that represents the genesis block (e.g. the empty blockchain). We define $0pt(\mathcal{T}_{\emptyset})=0$

• •

If we have a graph $G=(V,E)$ define the boundary operator $\partial:V\rightarrow 2^{V}$ by $\partial(v)=\{w:(v,w)\in E\}$

From single chain to multiple chains with constraints

In order to fully-specify a single chain PoW system, one needs to define the following [1]:

Network graph that describes how miners and users communicate 2. 2.

Merkle trees for each miner that represent each miner’s copy of the blockchain. 3. 3.

A process for dynamically growing and updating the Merkle tree

When we refer to trees, we will refer to a block tree, where each vertex of the tree represents a block. In the multiple chain world, in order to balance security and throughput, we need to replace the single Merkle tree rooted at each miner with a set of Merkle trees and a set of constraints that do not let the different chains get too far out of sync with out other. To formalize this, we will first need to define the terms network graph, base graph, and arboretum:

Definition 1**.**

A network graph is a weighted, undirected graph $G_{\text{network}}=(V_{\text{network}},E_{\text{network}},W_{\text{network}})$, where each vertex $v\in V_{\text{network}}$ represents a miner, each edge $e\in E_{\text{network}},e=(v,w)$ represents a peer-to-peer network connection between miners $v$ and $w$, and $W_{\text{network}}:E_{\text{network}}\rightarrow\mathbb{R}$ maps an edge to a latency. An $N_{\text{shards}}$-base graph is an unweighted, undirected graph $G_{\text{base}}=([N_{\text{shards}}],E_{\text{base}})$, where each vertex represents a separate chain and each edge represents a constraint.

In practice, the network graph is changing as users join and leave the network and the edges change in accordance with the peer-to-peer networking protocol.222Formally, if we think of all possible node sets $N$ as being a subset of $[N_{\max}]$, then we can view the networking protocol as a map $\rho:2^{N_{\max}}\rightarrow 2^{\binom{N_{\max}}{2}}$, which maps a node set into an edge set. In this work, we will consider the network graph static and unchanging during the remainder of our analysis. We next need to define how our constraint set, represented by $G_{\text{base}}$, affects the allowable Merkle trees.

Definition 2**.**

An arboretum $A$ is a triple $(V,E,T)$ where $V\subset\mathbb{N}$ is a vertex set, $E\subset 2^{\binom{V}{2}}$ is an edge set and $T:V\rightarrow\mathcal{T}$ is an operator that maps a vertex to a tree. If $\Lambda:E\times\sqcup_{v\in V}T(v)\rightarrow\{0,1\}$ is a predicate, a $\Lambda$-arboretum is an arboretum that $\Lambda((v,w),T(v)\sqcup T(v))=1$ for all $(v,w)\in E$. Finally, if $G^{\prime}=(W,F)$ is a subgraph of $G=(V,E)$, we define a subarboretum centered on $(W,F)$ to be $(W,F,T|_{W})$

An arboretum is distinct from a forest, as a forest does not prescribe connectivity between trees, whereas the edge set in an arboretum provides a natural graph distance between any two trees. Figure 2 depicts an arboretum where $G_{\text{network}}$ is the triangle graph and $G_{\text{base}}$ is a length-1 path with two vertices and one edge. The use of an arboretum is a key feature that is important to Chainweb’s performance claims, as the choice of graph can dramatically affect performance in a sharded PoW setting. More precisely, if an edge $e=(v,w)\in E_{\text{base}}$, this means that $i$th block of chain $v$ can only be added if the $i-1$st block of $w$ has been added. Thus, a valid Chainweb arboretum will need to satisfy the following predicate for all $(v,w)\in E$:

[TABLE]

The last predicate, $\mathsf{compat}(T(v),T(w))$ ensures that the block at the tip of $T(v)$ at height $h$ includes a header from a block at height $h-1$ of $T(w)$. This condition is illustrated in figure 2, where we see the two blocks in red depending on both their predecessor on the same chain and the adjacent chain. By assumption, we have $\mathsf{compat}(T_{\emptyset},T_{\emptyset})=1$ Finally, given a predicate $\Lambda$, we define a dynamic process on an arboretum that represents a single miner’s mining activity:

In order to prove that the system achieves liveness, assuming that there is a non-zero amount of hash power on every shard, we need to show that this process can continue in an infinite loop without halting for Chainweb. This can happen, for instance, if there are no $\Lambda_{\text{Chainweb}}$-subarboreta of $A_{t}$. We will show that this cannot happen:

Claim 1**.**

If $G=(V,E)$ is connected, then for all $t\in\mathbb{N}$, there exists a non-empty $\Lambda_{\text{Chainweb}}$-subarboretum of $A_{t}$

This claim is proved in the appendix. Let $B_{t}=(C_{t},D_{t},\tilde{T}_{t})$ be the non-empty $\Lambda_{\text{Chainweb}}$-subarboretum of $A_{t}$. We call $C_{t}$ the cut set of the chain at time $t$. The above claim says that the cut set is never empty and we can always make progress and the liveness of the set of chains reduces to the liveness of the individual chains. Chainweb thus consists of a miner graph $G$ and a series of arboreta, one for each vertex, denoted $A_{t,v}$. We note for completeness that one can also frame Chainweb as an arboretum on the strong graph product of a network graph and base graph.

III-C Implementation of Chainweb

We represent Chainweb via a graph of miners each of whom holds a copy of their local arboretum. We sample new blocks from a probabilistic model representing Chainweb that has the following parameters:

• •

$\lambda_{\alpha}$: Block frequency for chain $\alpha$

• •

$\mathbf{\zeta}_{i}\in\Delta^{N_{\text{shards}}}$: Hash power distribution of miner $i$

• •

$H_{i}\in\mathbb{R}_{\geq 0}$: Hash power of miner $i$

• •

$H_{\text{total}}$: The total hash power of the system, defined as

[TABLE]

• •

$\Gamma_{\alpha}$: The fraction of hash power on chain $\alpha$, defined as:

[TABLE]

We sample a new block on chain $\alpha$ at time $t$ created by miner $j$, $B_{\alpha,j,t}\in\mathcal{B}$, via the following generative model:

[TABLE]

Given this model and initial conditions (such as a choice of genesis block and random number seeds), our simulation platform can sample a trajectory of how Chainweb might evolve. Each miner’s policy is represented via a function that adapts and optimizes their own hash power distribution, $\mathbf{\zeta}_{i}$, which allows for the miner to affect the sampled trajectory. We also note that this model shares a number of similarities with multivariate Hawkes processes [27]. In all simulations performed in this paper, we make the following assumptions about the above parameters (as these likely reflect the choices in Chainweb upon launch [26]):

• •

All chains have the same block production rate: $\exists\lambda\in\mathbb{R}_{\geq 0}\;\forall\alpha\in[N_{\text{shards}}]\;\lambda_{\alpha}=\lambda$

• •

We use uniform hash power, e.g. $\exists H\in\mathbb{R}_{\geq 0}\;\forall i\in[N_{\text{net}}]\;H_{i}=H$

• •

Our network graph will only contain miners (e.g. we are assuming that all transaction generating participants are also miners)

• •

All simulations in this paper route blocks using either $k$-nearest neighbor routing (like Bitcoin) or use randomized gossip [22]

• •

All latencies were sampled from the Bitcoin latency distribution in [28]

Finally, we note that we do not include an explicit difficult adjustment in our simulations, even though it is supported within the platform. While changing the difficulty adjustment time window can have dramatic effects on the profitability of selfish mining [29], we wanted to reduce the noise in our statistics and plan on describing selfish mining optimization in a subsequent work.

IV Results

We performed two experiments to validate our simulation methodology and to estimate endogenous costs of security in Chainweb. Our goal is to illustrate how modeling adversarial and networking behavior can help choose design parameters such as $\lambda_{i}$ and the choice of base graph that is used in the production client.

IV-A Network Analysis

Our first experiment aims to test how different network and base graph configurations lead to changes in system dynamics under different routing profiles. As Claim 1 only guarantees that we will eventually achieve liveness in Chainweb provided that all chains have non-trivial chain growth, our goal is to perform a numerical study of how realistic chain growth looks and to find an estimate for how long it takes for a block to reach the whole network. Statistically estimating chain growth and the time to achieve liveness is crucial for deciding how to set parameters the block production rates, $\lambda_{i}$, as there is a natural trade-off between liveness time and block production rate [30]. Since Chainweb’s throughput is bounded by the diameter of the base graph [26], we aimed to use graphs that are the best known solutions to the degree-diameter problem. For these experiments, we used $N_{\text{net}}=8192$ and $N_{\text{shards}}=57$, with the choice of shards due to the existence of a Moore Graph, the Hoffman-Singleton graph, that solves the degree-diameter problem [31].

We will describe the statistics of interest. For a miner $i$ and chain $\alpha$, let $h_{i,\alpha}(t)\in\mathbb{N}$ be the height of the longest branch of chain $\alpha$ that miner $i$ has seen. For notational convenience, we assume that $h_{i,\alpha}(t)=0$ for $t<0$. Define the height function, $H:\mathbb{R}_{\geq 0}\rightarrow\mathbb{R}$ as:

[TABLE]

where $\mathsf{E}_{t}$ is the expectation over all environments up to time333Our Chainweb model is a composed of Markov models and inherits a natural filtration that $\mathsf{E}_{t}$ is defined on (regardless of initial environment). $t$. In practice, if we simulate $k$ trajectories until time $T$, we can approximate this expectation as:

[TABLE]

Intuitively, this tells us what the expected height change of the blockchain is within a window of size $\tau$. By averaging over windows that start at different times $t$, we can de-noise the variations of this measurement and observe behaviors that are persistent across different initial conditions. Finally, let $\tau_{i,\alpha,k}$ be the time that the $k$th miner receives block $i$ on chain $\alpha$. Let $\hat{\tau}_{i,\alpha,k}$ be the random variable that is $\tau_{i,\alpha,k}$ conditional on block $k$ being on the main branch of chain $\alpha$. Define the liveness time $\overline{\tau}$ to be:

[TABLE]

This measures the average time that it takes for a block that reaches the main chain to reach all miners. If we use randomized gossip, one expects this time to simply be the covering time of random walk on the miner graph, which is controlled by the spectral gap of the miner graph [32]. However, since we are conditioning on blocks that make up the main chain, this number can be significantly greater than the covering time.

IV-A1 Verification Runs

We performed a few verification runs to show that our simulation is replicating the behavior of Chainweb. For these runs, we let set the base graph be equal to the complete graph, $G_{\text{base}}=K_{N_{\text{shards}}}$. In this situation, since every shard depends on every other shard, we expect the time between successive blocks on the same chain to have super-linear scaling in the size of the base graph. We ran 100 simulations with 16,384 miners and a base graph with $|V_{\text{base}}|\in\{2^{k}:1\leq k\leq 13\}$ and calculated this time. In figure 3, we see super-linear scaling (note that both scales are logarithmic) and decreasing variance as we increase the base graph size. We also note that one expected some finite-size effects as $|V_{\text{base}}|\approx|V_{\text{network}}|$, which is the likely cause of the decay in the rate of growth of this curve.

IV-A2 Liveness Time

To assess liveness time (3) under realistic conditions, we constructed a realistic internet graph, the Barabási small world graph [33], used a randomized gossip protocol [22], and sampled latencies the Bitcoin latency distribution [28]. In order to stress the system, we assumed a block production rate of $\lambda=1\text{Hz}$. In figure 4, we see a plot of the expected degree of a Barabási graph versus liveness time. We used a miner graph of size 32,768 and used the Hoffman-Singleton graph as a base graph to generate these figures. The different curves correspond to a different number of simultaneous connections, which is how we quantify bandwidth. This corresponds to the upper bound on the number of neighbors forwarded to by a miner. We can see that by the time we get to 10 simultaneous connections, we are close to saturating the high-bandwidth limit, even for low-connectivity Barabási graphs. Data of this form helps protocol developers assess design decisions and choose peer-to-peer networking capabilities whose bandwidth-latency tradeoff matches the expectations of the consensus mechanism.

IV-A3 Random Miner Graph

In order to assess how Chainweb performs under more extreme network graphs, we looked at a modified version of Erdös-Renyi random graphs $G_{p}$ such that if $i\in[N_{\text{net}}-1],j\in[N_{\text{net}}]-\{i+1\}$, then the edge $(i,j)$ is included with probability $p$ and such that the edge $(i,i+1)$ is always included. We chose this ensemble because it ensures that our graph is connected (via the inclusion of the line edges $(i,i+1)$), but still inherits the Erdös-Renyi phase transition. In these experiments, we set the block production rate to be that of Bitcoin ($\lambda=\frac{1}{600}\text{Hz}$) so that these results could be interpreted in terms of real world data. Moreover, we averaged over 10 instances of each random graph $G_{p}$ and used the Hoffman-Singleton graph as a base graph.

In Figure 5, we see computations of $H(\tau)$ within one block interval. We see that for high values of $p$ (e.g. the miner graph is more connected), there is a sharp uptick in expected height increase around a half block time (300s). As we decrease connectivity, we expect there to be a more gradual height increase as some of the graph will have received the latest block, whereas other are still waiting to receive it and/or are on other forks. This is the expected behavior: when height increases propagate uniformly and rapidly throughout the network graph, we expect a sharp uptick in expected height change, as most participants receive the block (on average) at the same time (since miners have the same hash power). However, it is curious to note that the Erdös-Renyi phase transition [34] takes place around $p=0.001$ for our graphs and yet we only observe the signs of the transition (e.g. the sharp derivative for $p\in\{0.1,0.25,0.5\}$) far away from it. This suggests that the presence of forks can dramatically slow down block propagation and adds in a non-linear latency effect. This effect can likely be measured by miners, who measure their deviation from these expected curves, who can potentially use this information to boost the rewards from selfish mining, akin to latency arbitrage in high-frequency trading.

IV-B Adversarial Censorship

In order to test how resilient Chainweb is to miners attempting to censor a chain $\alpha$ by not allocating any hash power to $\alpha$, we used our domain specific language to construct two agents that do the following:

Honest Agent: Computes utility and gradient on all chains and updates its hash power distribution via gradient descent 2. 2.

Adversarial Agent: Computes utility and gradient on all chains, updates its hash power via gradient descent, sets the hash power allocated to the censored chain to zero, and then redistributes the excess hash power equally.

We chose a sequence of twenty five evenly-spaced adversary fractions $f_{i}\in(0,1)$ and for each of these, ran 256 simulations (with the Hoffman-Singleton base graph) of 30,000 blocks produced with a $(1-f_{i})$ fraction of honest agents and $f_{i}$ censoring agents. For each miner $i$ and chain $\alpha$, we computed the fraction $\gamma_{i,\alpha}(h)$ of blocks on the main branch of chain $\alpha$ that were created by miner $i$ at block height $h$, where $\forall\alpha\in[N_{\text{shards}}]\,\forall h\in\mathbb{N}\,\sum_{i\in[N_{\text{net}}]}\gamma_{i,\alpha}(h)=1$. For simplicity, we assume that the block reward is constant and is equal to one coin per block throughout our simulations (as all of our plots are about relative rewards, this choice of units does not affect our results). We define the following two quantities:

[TABLE]

where $S_{\text{honest}}\subset[N_{\text{net}}]$ is the set of honest miners and $S_{\text{adversary}}=[N_{\text{net}}]-S_{\text{honest}}$. In Figure 6, we see the plot for a single trajectory with $f_{i}=0.1$, where we see that $\gamma_{\text{honest}}>\gamma_{\text{adversary}}$ and that the honest curve is much smoother than the noisy adversary curve.

In Figure 7, we see how the expected difference in rewards and risk-adjusted rewards vary as a function of $f\in(0,1)$. We measure risk-adjusted rewards using the Sharpe Ratio, a common measure of trading strategy performance, which is measured via the mean reward (over all trajectories sampled) divided by the standard deviation of the reward. As the plots illustrate, honest, profit-maximizing agents beat out the censoring agents until 50-60%, at which point the censoring adversary is increasingly favored.

From this data, we can conclude that it appears to be hard for miners that are aiming to censor a chain to successfully do it as long as there are enough rational, profit-maximizing miners in the system.

V Conclusions and Further Work

We explored how adversarial, agent-based simulation can be used to assess claims and measure networking behavior for a blockchain protocol. Our techniques helped us assess different design choices, such as how the choice of base graph affects liveness time, and we were able to statistically estimate the rewards sacrificed by an adversarial, censoring agent. These techniques helped us evaluate the safety of Chainweb and help us statistically justify that degree-diameter minimizing base graphs prevent censorship attacks. As our experiments with liveness time show, one can use these techniques to optimize peer-to-peer networking performance based on various metrics, such as the number of simultaneous connection in 4. Finally, we note that more complicated consensus protocols, such as Proof-of-Stake and Proof-of-Space tend to have a variety of other parameters (slashing, market making or auction parameters, etc.) and these can be optimized in a similar fashion, given a certain mixture of honest and adversarial agents. Our future work will include an analysis of block withholding and selfish mining and analyzing Chainweb (once it is live) by incorporating exogenous data to estimate the true cost of security and selfish mining, conditional on the existence of active fiat and derivatives markets.

VI Acknowledgments

The authors would like to thank Joseph Bonneau, Yi Sun, Emily Pillmore, and the anonymous reviewers for insightful and constructive comments.

VII Appendix: Proof of Claim 1

Proof.

We will prove this by induction. By construction, $A_{0}$ is a $\Lambda_{\text{Chainweb}}$-arboretum since $0pt(\mathcal{T}_{\emptyset})=0$ and $\mathsf{compat}(\mathcal{T}_{\emptyset},\mathcal{T}_{\emptyset})=1$. Now assume the induction hypothesis that $A_{t-1}$ has a $\Lambda_{\text{Chainweb}}$-subarboretum and suppose for a contradiction that $A_{t}$ does not have a $\Lambda_{\text{Chainweb}}$-arboretum. We first note that if $\mathsf{compat}(T_{t}(v),T_{t}(w))$ is not satisfied, but all of the height conditions are satisfied, then one can start a fork at $T_{t-1}(v)$ or $T_{t-1}(w)$ that forces compatibility. By assumption $T_{t-1}(v)$ and $T_{t-1}(w)$ are admissible, so this is possible. Thus, we can assume that the compatibility condition is satisfied. Since $A_{t-1}$ has a $\Lambda_{\text{Chainweb}}$-subarboretum, $\tilde{A}_{t}$ was non-empty. Let $i\in[N_{\text{shards}}]$ be the index of the block mined in the second step of the loop. From the definition of $\Lambda_{\text{Chainweb}}$, this means that $0pt(T_{t-1}(i))\in\{0pt(T_{t-1}(j))+\eta:j\in\partial(i_{t}),\eta\in\{0,1\}\}$ and this set is non-empty since $G$ is connected. We have two cases:

$0pt(T_{t-1}(i))=0pt(T_{t-1}(j))$: This implies that $0pt(T_{t}(i))=0pt(T_{t}(j))+1$, so $j$ is admissible in the next round 2. 2.

$0pt(T_{t-1}(i))=0pt(T_{t-1}(j))+1$: This implies that $0pt(T_{t}(i))=0pt(T_{t}(j)$ in the next round, so both $i,j$ are admissible

Thus $j$ is admissible and there must be a non-empty $\Lambda_{\text{Chainweb}}$-arboretum ∎