# Causal Analysis of GossipSub Mesh Parameters Over the XRP Ledger

Flaviene Scheidt de Cristo, Jorge Augusto Meira, Jean-Philippe Eisenbarth, Radu State

► To cite this version:

Flaviene Scheidt de Cristo, Jorge Augusto Meira, Jean-Philippe Eisenbarth, Radu State. Causal Analysis of GossipSub Mesh Parameters Over the XRP Ledger. NOMS 2025 - IEEE Network Operations and Management Symposium, May 2025, Honolulu, United States. pp.01-09, 10.1109/NOMS57970.2025.11073650. hal-05462849v2

HAL Id: hal-05462849

https://inria.hal.science/hal-05462849v2

Submitted on 6 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Causal Analysis of GossipSub Mesh Parameters over the XRP Ledger

Flaviene Scheidt de Cristo*, Jorge Augusto Meira*, Jean-Philippe Eisenbarth*, Radu State*

* University of Luxembourg, SnT, 29, Avenue J.F Kennedy, L-1855 Luxembourg

Email: { flaviene.scheidt, jorge.meira, philippe.eisenbarth, radu.state } @uni.lu

***Abstract***—Several distributed systems based on unstructured p2p networks, such as blockchains, rely on underlying protocols to disseminate messages in a fast and reliable way. As the state-of-the-art for message dissemination in blockchains, GossipSub guarantees delivery and resilience against attacks and Byzantine faults by scaling pubsub dissemination without exceeding bandwidth or overloading peers. Although GossipSub relies heavily on the way its mesh is constructed, there is little insight into how different configuration parameters impact the overall performance of the system. This study analyzes the relationships between the configuration and the performance of GossipSub from a causal point of view using the concrete case of the XRPL. By employing graphical causal methods to investigate the strength of those connections, this study goes towards the direction of finding the best configuration for GossipSub for different domains, without the need for excessive empirical tests.

***Index Terms***—XRPL, unstructured p2p, pubsub, blockchain, GossipSub

## I. INTRODUCTION

Distributed systems based on peer-to-peer (p2p) networks are heavily dependent on the efficiency with which messages can be exchanged between their participants. An example of such systems are blockchains, in which the speed and safety of the consensus process leans on how efficiently nodes can receive and transmit transactions, validations, and blocks [1]. The state-of-the-art for message dissemination in blockchains is GossipSub [2], currently used in Ethereum and FileCoin.

GossipSub conciliates publisher/subscriber (pubsub) dissemination with a gossiping stage to guarantee message delivery through the network. Distributed as an extensible component within libp2p [3], it also employs a peer score function and some mitigation strategies, guaranteeing not only speed and reliability but also safety against attacks and Byzantine faults. GossipSub is characterized by a global amplification factor and peer degree limitations that define how its dissemination mesh is constructed.

Although used in Ethereum, there is not much effort focused on how it can be used in different types of blockchain. One such blockchain is the XRP Ledger [4](XRPL), which uses an alternative consensus algorithm, less resource-intensive than Proof of Work (PoW) and Proof of Stake (PoS). The XRPL uses quorum-voting to achieve consensus, employing Federated Byzantine Agreement (FBA) between its peers. In this scenario, each peer maintains a list of nodes that they collectively trust to not defraud the ledger. Because these lists can be mapped as topics in a pubsub

system, we have previously proposed the use of GossipSub to disseminate proposals and validations in the XRPL [5].

GossipSub has tunable parameters related to its mesh construction and its score function, meaning that it is possible to configure it for better performance depending on the kind of system on which it is being used. Unfortunately, not much effort has been put into understanding how this configuration can affect the performance of the network. The configuration of Ethereum has been performed through extensive empirical tests on simulated networks [6]. However, in several scenarios, it may not be feasible.

Considering a scenario where we have scarce means to extensively test and analyze the network according to its configuration, we propose the use of graphical causal tools to analyze the system from a causal point of view. Causal analysis can give us insight into how each parameter can affect a target performance measurement, also giving us tools to quantify those influences.

In this study, we expand the previous analysis done on the impact of the GossipSub mesh parameters on the performance and scalability of an underlying XRPL network [7] [8]. In particular, we extend a study on Causal AI discovery [8] to include a more thorough discussion of the methodology and, most importantly, we deepen our understanding of GossipSub causal mechanisms by employing root-cause analysis and simulated interventions. We base our methodology on the ideas presented by Judea Pearl [9] on the steps for causal inference, seeking to answer the following questions:

* Which parameters are more likely to affect the performance of the network?

* How do these parameters affect the performance of the network?

## II. BACKGROUND

### A. GossipSub

Blockchain consensus is heavily dependent on how efficiently messages containing transactions, blocks, and validations can be disseminated on the network. Built on top of unstructured p2p networks, implementing fast and reliable communications without compromising safety is a challenge. The straightforward way to guarantee that all participants will be synchronized to the last version of the ledger is to employ flood publishing, in which every node sends and relays messages to all its peers. This solution guarantees that messages will be delivered to all participants. However, with
a high amplification factor, as the number of nodes increases, more and more replicas of the same message will transit the network, causing congestion and delays. Delays may not only affect the performance of the blockchain in terms of transactions per second (TPS), but can also cause forks [1] and, in some types of consensus, a complete stall in the validation of transactions.

A solution for this problem has been proposed by Vy-
zovitis et al [2] using pubsub dissemination allied with
gossiping to guarantee fast and reliable message transmission,
ensuring safety by employing peer score functions and a set
of mitigation strategies. GossipSub [2] is distributed as an
extensible component inside libp2p and is currently employed
in Ethereum, FileCoin, and The Interplanetary File System
(IPFS). By controlling the amplification factor globally and
limiting the degree of each peer, the solution scales pubsub
dissemination without overloading peers or consuming ex-
ccessive bandwidth. Pubsub dissemination employs publishers
and subscribers as source and target nodes, using topics to
deliver messages from source to target. Subscribers subscribe
to topics to receive the desired messages, while publishers
publish the said messages on the appropriate topics. A node
can be both a publisher and a subscriber.

One of the main characteristics of GossipSub is how
its mesh is constructed, aiming to control the amplification
factor while guaranteeing fast and reliable delivery. We can
abstract the GossipSub mesh as two overlays. The first layer
employs *eager push* to disseminate full messages, using an
amplification parameter called *D*, which dictates the desired
number of peers a node should keep for each subscribed
topic. This parameter can be relaxed according to a ceiling,
*Dhi*, and a floor, *Dlo*.

Each node has only a local view of the mesh, meaning
that they only know their immediate peers and the topics to
which they are related. In this scenario, the act of acquiring
a new connection is called a *graft* and occurs mainly in three
instances, the first being when a new node joins the network
or subscribes to a new topic, the second when the number of
peers falls below *Dlo* for a topic. The third instance occurs
when the number of peers increases above *Dhi*, the node then
*prunes* connections, keeping only a certain number of peers,
which is given by a parameter called *Dout*. Considering that
*Dout* may be lower than *Dlo*, the node now needs to *graft*
new connections.

The second mesh layer uses gossiping to propagate meta-
data only and also serves as a reconciliation phase to reach
distant nodes by employing *lazy pull*. The propagated meta-
data refers to events that happened on the network, such as
nodes joining and leaving topics, grafts, prunes, and "I have"
and "I want" announcements.

B. The XRP Ledger

The XRP Ledger [4] was one of the first blockchains
to be deployed, proposing an alternative type of consensus,
more resource efficient than PoW. The XRP Ledger Con-
sensus Protocol (XRP LCP) uses FBA to reach consensus

on successive ledger versions. Each node in the network has
a list of peers they trust not to collude to defraud or stall
the ledger. The nodes use the position of the peers in their
lists to cast their own votes. Those lists are called Unique
Nodes Lists (UNLs) and serve as a basis to establish trust
relationships between the validators in the network, forming
a *trust overlay*.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Unique Nodes Lists</figcaption></figure>

Consider a network with five validators: *A*, *B*, *C*, *D*, and *E*, represented in Figure 1. Let $U_A$ be the UNL of node *A*, so $U_A = \{C, D\}$, which means that the validator *A* trusts the votes of the nodes *C* and *D*. Following the example, $U_B = \{A, C, E\}$, $U_C = \{A, E\}$, $U_D = \{C, E\}$ and $U_E = \{A, C, D\}$.

During a *consensus round*<fnref n="1" />, each validator starts by forming a *proposal*, which is a set of transactions that the node believes to be valid. The validator then broadcasts its proposal to the network while waiting for the proposals from the nodes that figure in its UNL. Node *A*, for example, will form its proposal, broadcast it to the network, and then wait for the proposals sent by *C* and *D*. The validator then compares its own proposal with the ones received from *C* and *D*, if there exists a transaction in *A* that is not present in either *C* or *D* – or vice versa – we then have a dispute. A node solves a dispute by counting the number of trusted peers that have that transaction in their proposal; if this number is greater than half of the number of peers, *A* will include the transaction in its next proposal; if the number is lower, the transaction is discarded. Validators will exchange proposals throughout several *proposition rounds*, in each round, the threshold for the inclusion of the transaction increases. The cycle ends when the threshold reaches 80%, at this moment the last proposal formed by *A* will become a *validation*. The validations are then again transmitted to the network. *A* will compare its validation with the ones received from *C* and *D*, if 80% of the trusted peers agree to the same validation, *A* applies the validation to its local version of the ledger; in case of disagreement, *A* will consider itself out of sync and will start a syncing process to acquire the last version of the ledger agreed upon by the network.

<footnote n="1">¹A consensus round comprehends an entire cycle on the distributed states
machine that represents the consensus process, starting with the formation
of new local ledgers in each validator, until full agreement is reached in the
network.</footnote>
In the current implementation, nodes broadcast their pro-
posals and validations using flood publishing, which means
that every one of the 5 nodes in our example transmits
their messages to the entire network, even to nodes that will
discard their messages because they do not appear in their
UNL. In special, the validator *B* will broadcast messages that
are not used in the consensus process, since *B* is not trusted
by any of the other peers.

Implementing such a system using flood publishing occurs
in a high message overhead, augmenting the required band-
width, and harming node-wise scalability [10]. Considering
that the UNLs works the same way as topics in a pubsub
system, we have previously proposed the use of GossipSub
to disseminate proposals and validations [5]. In this work, we
use the XRPL as a concrete case for GossipSub, in which
different topic arrangements can be better explored.

III. RELATED WORK

The performance and scalability of GossipSub have seldom
been studied in academic research. We previously performed
a dimensional analysis of the GossipSub mesh parameters,
using data science tools to find a correlation between the
parameter values and the performance metrics [7]. We also
performed an analysis of different causal AI discovery al-
gorithms to find causal relationships between GossipSub
mesh parameters and message overhead in the XRPL [8].
Non-academically, an investigation has been conducted by
Whiteblock [6], concluding that GossipSub is suitable for
Ethereum 2.0 deployment despite some problems found in
the Golang implementation.

To our best knowledge, no studies have so far explored
causal analysis for network parameterization; nevertheless,
its application in analyzing network performance is not
entirely new. Hours et al. [11] introduced a study supporting
the use of graphical causal methods for network perfor-
mance analysis. This study collected data from an emulated
Transmission Control Protocol (TCP) network tracking File
Transfer Protocol (FTP) traffic, followed by additional data
from a single FTP server connected to the Internet. Initially,
a causal graph was created using the emulated network data,
followed by the application of causal inference techniques to
make predictions, which were then corroborated using data
from the FTP server connected to the Internet. The study
employed the Tetrad [12] suite, finding that constraint-based
algorithms produced more detailed causal models.

In the domain of log analysis on distributed systems, Neves et al. [13] present Horus, a tool that uses graph databases for storing causal graphs obtained from causally consistent aggregation of distributed systems. More specifically on the analysis of network events logs, we can cite Kobayashi et al. [14], which presents a methodology for the comparative analysis of two networks using causal graphs obtained from log data. The study focused on comparing logs from different sources by reconciling the generated causal graphs. In parallel, Jarry et al. [15] applies MixedLinGaM to the problem, generating weighted graphs with more causal relationships

than the baseline given in the previous study. Regarding
the use of causal analysis in network management, we can
highlight Kim et al. [16], which proposes an algorithm for
Alarm Correlation based on root cause analysis without the
need for domain knowledge.

IV. STEPS FOR THE CAUSAL ANALYSIS

In this section, we present the foundational theory on
causality used to analyze the impact of the GossipSub mesh
parameters on message overhead in the XRPL. This approach
was pioneered by Judea Pearl [9] and uses a ladder to abstract
the levels of relationships between variables. This ladder
of causation has three steps: association, intervention, and
counterfactual. The higher we climb the ladder, the better
the understanding of the causal relationships between the
variables and the metrics studied.

In the first step, we have *association*, in which we *observe* the system and try to understand how a change in an input can affect a possible output. Observations allow us to generate predictions that can be made from the perspective of *conditional probability* [17]. However, this mathematical formulation may not be able to fully express the causal relationship.

The association step may not give us information about
causal relationships but gives us a good foundation to find
correlations between variables. So we now climb to the
second step, where we perform interventions. *Interventions*
are made to observe how a modification in an element can
impact an outcome. Mathematically, interventions can be
expressed by *do*-calculus.

Interventions help us find causal relationships between
components of a system and how they impact certain out-
comes; the next step of the ladder, counterfactuals, extrapo-
lates the insights acquired to answer hypothetical questions.
*Counterfactuals* can be seen as simulated or hypothetical
interventions, where we try to emulate a state of the system
that has never been observed in the real world.

In a broad view, we can consider *observation* the step
where we start formulating a view of the system and
identify correlations between variables and ask how those
variables causally interact with each other. *Intervention* is
where we can start answering the questions by means of
experimentation. And finally, *counterfactuals* helps us answer
hypothetical questions about the behavior of the modeled
system.

V. METHODOLOGY

In this work, we opt for graphical tools to help us model
and analyze causal relationships. The first tool used is Struc-
tural Causal Models (SCMs), which uses Directed Acyclic
Graphs (DAGs) to represent the causal relationships between
variables. However, SCMs can only represent the causal
relationships and their directions, without any information
about the distribution of the data used to generate such
graphs. To encode distributions, we need Graphical Causal
Models (GCMs), which are sets consisting of a graph and a
group of functions that can represent the distribution of the
data for each variable in the model [18].

<figure><img src="image_3.png" /><figcaption>Fig. 2. Steps for the Causal Analysis</figcaption></figure>

Figure 2 presents a diagram of how we use the causation
ladder to discover and analyze causal relationships between
the GossipSub mesh parameters and the target metric. We
start by generating a SCM based on observational data and
domain knowledge. The observational data were collected
from the results of two studies [5] [7] that analyzed the use
of GossipSub as a message dissemination strategy in the XRP
Ledger (XRPL) to reduce the message overhead and increase
the scalability and performance of the network.

In the next step, we perform interventions on the Gossip-
Sub mesh parameters and use the data generated to create
a second SCM using an algorithm for causal discovery. We
then create a GCM using DoWhy to fit the distributions of
the variables into the model. The first two steps have been
explained in more detail in a previous work [8].

Having climbed the ladder, we get to the third step. We start by quantifying the strength of the causal relationships and determining which variables had the biggest causal influence on the chosen metric: message overhead. We then proceed to make interventions using some variables to analyze which set of parameters would create the desired behavior in the system. The next sections better detail the process and the results obtained for each step.

VI. OBSERVATIONAL ANALYSIS

We use the results of two studies on the integration of
GossipSub into the XRPL to make observations about how
the GossipSub mesh parameters affect message overhead.
The first study [5] presents GossipSub as an alternative for
message dissemination on the XRPL, considering that the
network uses flood publishing for certain types of messages
related to the consensus process, which causes excessive
message overhead and negatively influences the scalability
of the network. In this work we also previously made the
case for treating the XRP LCP as a pubsub system, using

three different UNL structures, abstracting each structure as
a different arrangement of GossipSub topics.

The second work [7] dives deeper into the correlation
between nine dimensions identified as the main factors
that can affect the performance of GossipSub. The dimen-
sions studied were some configuration parameters for the
mesh construction, events on the network and metrics of
performance, namely *messageReceived*, *duplicatedMessage*,
*prune*, *graft*, *ihave*, *iwant*, *bandwidth*, *propagationTime* and
*messageOverhead* and the 8 parameters used to tune the
mesh construction: *D*, *Dhi*, *Dlo*, *Dscore*, *Dout*, *Dlazy*, *Gos-
sipFactor*, *Heartbeat Interval*. The study used data science
techniques to provide some useful tools to better understand
the relationships between the parameters and the events and
metrics.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Causal Graph generated with observational data and domain knowledge</figcaption></figure>

In particular, the study mentioned above provided a cor-
relation heatmap that helped us identify the variables to be
used in our causal model. Considering the importance that
*messageOverhead* has for the scalability and performance
of the XRPL, we use this metric as a target in our model.
We then identified which parameters and events showed the
highest correlation with our target measurement and used
domain knowledge to model the SCM shown in Figure 3.

D dictates the ideal number of connections per topic on
the full message overlay and is more likely to affect the
number of grafts and prunes. It may also cause the number of
*messagesReceived* to increase and decrease; as for the *mes-
sageOverhead*, *D* influences the number of replicas a given
node receives, forward by their direct peers. *Dhi* influences
the *prune* of the connections since it dictates the limit of the
number of connections per topic. When a *prune* occurs, only
*Dout* outbound connections of high-scoring peers are kept,
so new connections must *graft*, therefore, *prune* events gen-
erally cause *graft* events, which are also bound to *Dlo*. The
number of *topics* also affects *messageReceived* and affects
*messageOverhead*, since each *d-value*<fnref n="2" /> is defined per topic.

<footnote n="2">²The *d-values* are all the parameters related to the fanout; namely *D*, *Dlo*, *Dhi*, *Dscore*, *Dout* and *Dlazy*</footnote>
The *topicSize* affects the total number of *messageReceived*, directly affecting the *messageOverhead*.

## VII. INTERVENTIONAL ANALYSIS

To gather interventional data, we set up an XRPL testnet with 24 nodes using GossipSub to disseminate proposals. We chose 43 sets of parameters and ran tests over three different structures of topics, each emulating different configurations for the XRPL trust overlay.

The XRPL mainnet is currently structured with a core of connected validators, forming a complete graph. The naive way to map the XRPL trust relationships into topics is to use a structure similar to the one employed in Ethereum, with different topics for different types of messages. We emulated this behavior by creating a structure called *general* where we have only one topic (validations) with all 24 validators publishing and also subscribing to this single topic.

The second way to map the XRPL trust relationships into a pubsub structure is to create a topic for each trusted validator in the network. Each validator only publishes messages on its own topic and the nodes can subscribe to several topics. We then have the structure called *validator*, with 24 topics of size 1. To stabilize the network, we subscribed each node to at least 16 topics, so that every node could listen to at least 60% of the network. We know from previous studies [4] [19] [20] [21] that a minimum overlap is required between UNLs to avoid forks in the ledger and stalls in the consensus process. However, in the absence of malicious players, we were able to stabilize the ledger using this setup.

Finally, we get to the third structure, *unl*, where we can better explore the pubsub characteristics of the XRPL. Here we have eight predefined UNLs of varying size. The average size of each list is 16, while the largest list is formed by 18 nodes and the shortest one by 15, respecting the minimum number of peers required for each node to stabilize the consensus process in the absence of malicious parts.

Each set of parameters was used 3 times for 30 minutes in each of the structures, totaling 387 executions. We gathered data on the executions from the GossipSub tracer and loaded them into a timeseries database. The tracer provides time-stamped information about events on the network, both on full message and gossip overlays. After that, the data were aggregated per number of events in 5-second time chunks, excluding faulty executions from the dataset. The faulty executions are the ones in which the z-score falls below 0, 15 * standard deviation, considering the total number of data points recorded on the database for each execution.

Using the dataset generated over the interventional data, we generate another SCM, shown in Figure 4. For this step, we use a causal discovery algorithm from the gCastle suit, NOTEARS [22]. The NOTEARS algorithm uses a differentiable function to ensure that the optimized graph is acyclic [17].

Domain knowledge is a crucial aspect of causal analysis, but it cannot find all the causal relationships between variables. As a result, we analyzed the distance between the

<figure><img src="image_5.png" /><figcaption>Fig. 4. Causal Graph generated with interventional data using the NOTEARS algorithm</figcaption></figure>

NOTEARS graph and the SCM generated in the observational phase, concluding that some causal relations found between the parameters were spurious. That is, NOTEARS found relationships between the *d-values* and between *topics* and *topicSize*. Since gCastle does not allow us to input prior knowledge into the NOTEARS algorithm, we pruned these edges because while most *d-values* are related to the value of *D*, being then correlated, they create a false causal relationship that NOTEARS cannot properly identify without the use of prior knowledge, the same occurring with *topics* and *topicSize*. More details on algorithm selection and edge pruning can be found in the previous work on causal discovery [8].

<table><caption>TABLE I
DISTRIBUTION FUNCTIONS OF THE GCM VARIABLES</caption><thead><tr><td></td><td>Distribution</td><td>Function</td></tr></thead><tbody><tr><td>graft</td><td>Discrete</td><td>LinearRegression</td></tr><tr><td>mReceived</td><td>Discrete</td><td>HistGradientBoostingRegressor</td></tr><tr><td>mOverhead</td><td>Discrete</td><td>HistGradientBoostingRegressor</td></tr></tbody></table>

Having the SCM and the interventional dataset in hands, we can now generate a GCM by fitting distribution functions for each variable. For that, we use the DoWhy automatic assignment. The distribution functions attributed to each non-root node can be seen in Table I.

## VIII. COUNTERFACTUAL ANALYSIS

<figure><img src="image_6.png" /><figcaption>Fig. 5. Causal strength of parameters over metrics, with *messageOverhead* as target</figcaption></figure>
Counterfactuals can help us answer questions in the form of *what would have happened with variable x had I assigned the value y' to the variable y*. It helps us to evaluate possible outcomes from states that were never observed or cannot be observed in the real world. But first, we must identify which variables are more likely to impact the outcome.

<figure><img src="image_7.png" /><figcaption>Fig. 6. Causal Influence of parameters over metrics</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 7. Causal strength of parameters over metrics, with `messageReceived` as target</figcaption></figure>

Figure 5 shows the causal strength of each variable in our target measurement, the values in the edges being the percentage of causal strength of each variable over the target. The graph was obtained again using the *direct strength arrow algorithm* [23], provided by DoWhy. This algorithm tries to quantify causal relationships by abstracting the edges of the causal DAG as communication channels that can be corrupted by interventions. Those interventions cause new distributions on the data, the causal strength is then measured by the relative entropy distance between the two distributions.

We can see that the greatest influence on the *messageOverhead* variance comes from *messageReceived* and, on a minor scale, from *D*, *Dhi* and *Dout*. The causal relationship between *messageReceived* and *messageOverhead* is trivial, since more messages will always generate more duplicates.

We also ask what factors influence *messageOverhead* the most. This question can be answered by applying the *intrinsic causal contribution* method [24], which recursively rewrites each node as a function of its ancestors to make interventions that do not change the observed joint distribution. Figure 6 shows a bar graph that summarizes the results obtained. We

can now see that, in addition to *messageReceived*, *D* and *Dhi*, *TopicSize* and *Topics* also influence *messageOverhead*, in fact, they have the highest influence.

Since we are unable to capture much causal strength from *topicSize* directly in *messageOverhead*, we analyze the strength of causal relationships using *messageReceived* as the target measurement. Since the *intrinsic causal contribution* represents a node as a function of its ancestors, the previous results may imply that there are indirect causal effects that could not be captured by the *direct strength arrow algorithm*. Figure 7 shows the resulting SCM. *topicSize* and *topics* are indeed the variables with higher causal strength over *messageReceived*, confirming that the variables have an indirect causal effect over *messageOverhead*.

### A. Simulated Interventions

After identifying the parameters that mostly affect our target measurement, we can now make interventions in the model-scenarios created in the previous steps of the ladder. Simulating interventions helps us better understand the impact that a certain value change in one variable can have on the target measurement. Here, we try to answer the questions in the form of *What happens to variable x if we change the value of variable y*.

<figure><img src="image_9.png" /><figcaption>Fig. 8. Simulated results for *messageOverhead* when intervening on *topicSize* and number of topics</figcaption></figure>

We previously identified *topicSize* and *topics* as variables with a higher causal influence over *messageReceived*, also causing a high indirect causal influence in *messageOverhead*. So, we selected these two variables for the first counterfactual analysis. It is hard to separate the two variables from each other, considering that the growth in the number of participants in the network may affect both dimensions.

In Ethereum and FileCoin, the number of topics remains constant no matter the size of the network, with only the size of the topics growing. The XRPL allows us to try different arrangements for topics so that we can analyze how the network may behave in the case of a dynamic arrangement. Consider the case in which UNLs can vary in number and sizes; would this arrangement have any advantages over the approach where we mimic the structure used on Ethereum, with fixed topics always varying in size?

We try to answer this question by first simulating interventions on the number of topics to which each node
is subscribed, with values ranging from 1 to 24. We use DoWhy to generate a dataset with simulated interventional samples, we then fit this dataset into a new GCM, again using the automatic distribution assignment capabilities, and the same SCM generated using NOTEARS. Since DoWhy uses the distribution functions previously assigned to the model to generate the simulated interventional samples, the same distribution functions were assigned to the GCM. We then used the GCM generated with the simulated interventional data for topics to simulate interventions in topicSize, with a range of 1 to 35.

<table><caption>TABLE II
DEFAULT AND ETHEREUM CONFIGURATION</caption><thead><tr><th></th><th>D</th><th>Dlo</th><th>Dhi</th><th>Dout</th></tr></thead><tbody><tr><th>Ethereum</th><td>8</td><td>6</td><td>12</td><td>2</td></tr><tr><th>Default</th><td>6</td><td>5</td><td>12</td><td>2</td></tr></tbody></table>

Figure 8 shows a graphical representation of the dataset generated by the two subsequent simulated interventions in *topics* and *topicSize*. To isolate these two variables, we fixed the values of *D*, *Dhi*, *Dlo*, and *Dout* using the Ethereum configuration, shown in Table II. The graph shows that a smaller number of topics leads to a higher message overhead. When associated with the number of topics, *topicSize* does not appear to impact the target measurement as much as expected by the intrinsic causal contribution of *topicsSize* in *messageOverhead*.

<figure><img src="image_10.png" /><figcaption>Fig. 9. Simulated results for messageOverhead when intervening on D with 8 topics of size 16</figcaption></figure>

What we can take from these results is that more varied topics can optimize message overhead. The size of the topics has less influence, so a dynamic arrangement of topics according to the size of the network could be marginally beneficial to the performance of the system. It is important to note that in this study we do not consider the qualitative nature of topics, but we solely look at them from a quantitative point of view, not making any considerations about the difference between the nature of the messages published in each topic.

Going a step further, we simulate interventions in the next variable that shows to have the largest direct impact on *messageOverhead*: *D*. To isolate the variable being studied, we fixed the number of topics and the size of the topics to 8 and 16 respectively. We did not fix the values for *Dhi* and *Dlo*

as they are dependent on *D*. We then simulated interventions in *D*, varying its values from 1 to 24.

Figure 9 represents the dataset generated by the simulated interventions in *D*. We can see that the smallest *messageOverhead* occurs in the region where *D* is between 3 and 4. Since the value of *D* can be relaxed from *Dlo* to *Dhi*, we consider it more suitable to refer to the ranges rather than to absolute values directly. After the optimal region, there is a natural increase in message overhead as the number of connections per topic increases, except for a slight decrease in the region where *D* is equal to 16, which may be related to the size of the topics being also 16.

<figure><img src="image_11.png" /><figcaption>Fig. 10. Simulated results for messageOverhead when intervening on *D* with 2 topics of size 24</figcaption></figure>

It is important to note that the values of *D* are bound to the number of topics to which a node is subscribed. With that in mind, we repeat the analysis fixing the number of topics to 2 and the topic size to 24, similar to how we simulated the current structure of the XRPL. Figure 10 represents the resulting dataset, showing that, however smaller than in the previous simulation, there is still a valley where the values of *D* are optimal, in this case in the region between 2 and 3. There is again a slight decrease around 21 and 24, similar to the previous analysis, and it may be due to the value of *D* being closer to the size of the topics.

This counterfactual analysis shows the importance of the structure of topics for optimal message overhead on Gossip-Sub. First, *direct strength arrow algorithm* and the *intrinsic causal contribution* calculated using DoWhy showed a strong indirect influence of *topics* and *topicSize* on *messageOverhead*, and also the direct influence of *D* on the target measure. Then, the simulated interventions showed how *topics* and *topicSize* work together to influence the outcome and how important they are for the proper configuration of the *d-values*, which are bound to the value of *D*.

## IX. EVALUATION & LIMITATIONS

As discussed in Section II-B, the XRP LCP works based on quorum voting, with the nodes casting votes according to the position of trusted peers. Each node maintains a UNL, trusting that the peers on that list will not collude to defraud or stop the ledger. To converge into agreement, there needs to be a minimum overlap between all UNLs in the network, otherwise, the excessive disagreement may lead to a stall in the progress of the ledger [20] [19] [4] [21], considering that the XRPL has fork prevention mechanisms.
The overlap required between the lists limits our evaluation when considering different combinations of number of topics and topic size. In most of the model scenarios presented, there is an impossibility for the XRPL network to bootstrap, given that the UNLs will not have enough overlap between themselves for the consensus process to converge into a single ledger version. This characteristic of the XRPL limits our ability to directly evaluate the results obtained in the simulated interventions. Nevertheless, this work has the goal to better understand how the GossipSub mesh parameters impact the performance of the network, and not to directly find the ideal values for each parameter. This analysis seeks to understand the causal relationships between parameters and metrics, so we can better parameterize GossipSub for different scenarios than the ones it is already employed.

<figure><img src="image_12.png" /><figcaption>Fig. 11. Causal strength of parameters over metrics, with messageOverhead as a target. Generated using the simulated dataset</figcaption></figure>

Instead of an empirical evaluation of the results obtained with the simulated interventions, we opted to evaluate our methodology by comparing the graph generated by the *direct strength arrow algorithm* in the interventional data (Figure 5) with the one generated by the simulated interventions (Figure 11). The two graphs are similar with regard to the strength of the causal influences calculated, from which we can say that the dataset generated by the simulated interventions is representative of the data distribution observed on the interventional dataset, and thus our methodology is consistent for the data distribution and to the causal relationships and strengths observed.

# X. DISCUSSION & FUTURE PERSPECTIVES

In this work, we presented a causal analysis of the GossipSub mesh parameters in relation to message overhead to understand how parameterization affects the performance of the dissemination system. We used graphical causal tools, establishing our methodology on the ideas presented by Judea Pearl [9] about how to understand causality.

We started our analysis by observing the behavior of GossipSub based on the findings of previous studies [7] [5] [8] and applying domain knowledge. This phase resulted in the selection of the parameters used for our analysis, as well as the selection of the target measurement. The final product was SCM, laying the foundation for the subsequent steps.

We then moved to the second phase, which involves making interventions in the system and analyzing the results to answer questions about what happens to a certain variable when we change the values of another variable. We made interventions and measured results on an XRPL testnet, using the XRPL as a concrete case for the usage of GossipSub to disseminate messages on blockchains. From the data gathered on these interventional experiments, we generated a new SCM, this time using a causal discovery algorithm, NOTEARS, which was chosen based on a previous study [8] on causal AI discovery on the impact of GossipSub's mesh parameters over the XRPL scalability. We then used DoWhy to fit the distribution of each variable into distribution functions. The outcome of this phase was a more refined understanding of the causal relationships present in the system, as well as insights on the data distribution of the dataset obtained by making interventions in the real-world system, culminating in a model represented by a GCM.

The final step is the one that gave us the most insight into how the parameters causally relate to the target measurement. To start the analysis, we asked which parameters had the greatest influence on message overhead, by applying two causal influence algorithms. We discovered that the number of topics, the size of the topics, and *D* were the parameters with a higher causal influence on the message overhead. We then proceeded to perform simulated interventions in the model to be able to visually study the impact of the simulations on message overhead.

In all, this study helped us to better understand the causal relationships between the parameterization of the network and its behavior. The visual causal tools and techniques helped us to reach conclusions that would not be possible simply by observing the system. However, domain knowledge played a huge role in making sense of the results given by graphical tools. In a more empirical sense, we could observe how strong the influence of the topic structure is, even impacting the optimal values for the third most influential variable: *D*. However, we still have a limited understanding of how the parameters related to the gossiping layer impact the overall performance of the system. Future work can move in the direction of a more complete analysis of the entire mesh of GossipSub, encompassing both the full message and gossip layers in the same model. This study was also limited by the necessity of the XRP LCP to have overlapping sets of UNLs on a tightly connected trust overlay. A validation of our methodology in a broader scenario can also be achieved in the future, although the validation of counterfactuals on scenarios that are hard or not possible to achieve experimentally is still a challenge in the domain of causal inference.

# ACKNOWLEDGMENT

We thankfully acknowledge the support from the RIPPLE University Blockchain Research Initiative (UBRI) for our research.
REFERENCES

[1] W. Hao, J. Zeng, X. Dai, J. Xiao, Q. S. Hua, H. Chen, K. C. Li, and H. Jin, "Towards a trust-enhanced blockchain p2p topology for enabling fast and reliable broadcast," *IEEE Transactions on Network and Service Management*, vol. 17, pp. 904-917, 6 2020.

[2] D. Vyzovitis and Y. Psaras, "Gossipsub: A secure pubsub protocol for unstructured, decentralised p2p overlays," 2019. [Online]. Available: https://research.protocol.ai/blog/2019/a-new-lab-for-resilient-networks-research/PL-TechRep-gossipsub-v0.1-Dec30.pdf

[3] "libp2p", accessed: 2024-09-13. [Online]. Available: https://libp2p.io

[4] B. Chase and E. MacBrough, "Analysis of the xrp ledger consensus protocol," 2018. [Online]. Available: https://arxiv.org/abs/1802.07242

[5] F. Scheidt de Cristo, W. M. Shbair, L. Trestioreanu, and R. State, "Pub/sub dissemination on the xrp ledger," in *2023 IEEE Latin-American Conference on Communications (LATINCOM)*. IEEE, 2023, best Paper Award.

[6] T. V. Epps, "Testing gossipsub with genesis," accessed: 2022-02-01. [Online]. Available: https://medium.com/whiteblock/testing-gossipsub-with-genesis-6f89e845b7c1

[7] F. Scheidt de Cristo, J.-P. Eisenbarth, J. A. Meira, and R. State, "A 9-dimensional analysis of gossipsub over the xrp ledger consensus protocol," in *NOMS 2024 IEEE/IFIP Network Operations and Management Symposium*. IEEE, 2024.

[8] F. Scheidt de Cristo, J.-P. Eisenbarth, J. Meira, and R. State, "Causal ai for xrpl/gossipsub network configuration," in *CNSM 2024 International Conference on Network and Service Management*. IEEE, 2024.

[9] J. Pearl and D. Mackenzie, *The book of why: the new science of cause and effect*. Basic books, 2018.

[10] L. A. Trestioreanu, F. Scheidt de Cristo, W. Shbair, J. Francois, D. Magoni et al., "To squelch or not to squelch: Enabling improved message dissemination on the xrp ledger," in *NOMS 2024 IEEE/IFIP Network Operations and Management Symposium*. IEEE, 2024.

[11] H. Hours, E. Biersack, and P. Loiseau, "A causal approach to the study of tcp performance," *ACM Transactions on Intelligent Systems and Technology (TIST)*, vol. 7, no. 2, pp. 1-25, 2015.

[12] P. Spirtes, C. N. Glymour, and R. Scheines, *Causation, prediction, and search*. MIT press, 2000.

[13] F. Neves, N. Machado, R. Vilaça, and J. Pereira, "Horus: Non-intrusive causal analysis of distributed systems logs," in *2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)*. IEEE, 2021, pp. 212-223.

[14] S. Kobayashi, K. Shima, K. Cho, O. Akashi, and K. Fukuda, "Comparative causal analysis of network log data in two large isps," in *NOMS 2022 IEEE/IFIP Network Operations and Management Symposium*. IEEE, 2022.

[15] R. Jarry, S. Kobayashi, and K. Fukuda, "A quantitative causal analysis for network log data," in *2021 IEEE 45th Annual Computers, Software, and Applications Conference (COMPSAC)*. IEEE, 2021, pp. 1437-1442.

[16] D. S. Kim, H. Shinbo, and H. Yokota, "An alarm correlation algorithm for network management based on root cause analysis," in *13th International Conference on Advanced Communication Technology (ICACT2011)*. IEEE, 2011, pp. 1233-1238.

[17] A. Molak, *Causal Inference and Discovery in Python: Unlock the secrets of modern causal machine learning with DoWhy, EconML, PyTorch and more*. Packt Publishing Ltd, 2023.

[18] J. Peters, D. Janzing, and B. Schölkopf, *Elements of causal inference: foundations and learning algorithms*. The MIT Press, 2017.

[19] F. Armknecht, G. O. Karame, A. Mandal, F. Youssef, and E. Zenner, "Ripple: Overview and outlook," vol. 9229. Springer Verlag, 2015, pp. 163-180.

[20] L. Mauri, S. Cimato, and E. Damiani, "A formal approach for the analysis of the xrp ledger consensus protocol." *SciTePress*, 2020, pp. 52-63.

[21] I. Amores-Sesar, C. Cachin, and J. Mićić, "Security analysis of ripple consensus," in *24th International Conference on Principles of Distributed Systems, OPODIS 2020, December 14-16, 2020, Strasbourg, France (Virtual Conference)*, ser. LIPIcs, vol. 184. Schloss Dagstuhl - Leibniz-Zentrum für Informatik, 2021. [Online]. Available: https://www.dagstuhl.de/dagpub/978-3-95977-176-4

[22] P. Spirtes and C. Glymour, "An algorithm for fast recovery of sparse causal graphs," *Social science computer review*, vol. 9, no. 1, pp. 62-72, 1991.

[23] D. Janzing, D. Balduzzi, M. Grosse-Wentrup, and B. Schölkopf, "Quantifying causal influences," *The Annals of Statistics*, vol. 41, no. 5, 10 2013. [Online]. Available: http://dx.doi.org/10.1214/13-AOS1145

[24] D. Janzing, P. Blöbaum, A. A. Mastakouri, P. M. Faller, L. Minorics, and K. Budhathoki, "Quantifying intrinsic causal contributions via structure preserving interventions," in *International Conference on Artificial Intelligence and Statistics*. PMLR, 2024, pp. 2188-2196.