Resource Analysis of Ethereum 2.

0 Clients
Mikel Cortes-Goicoechea Luca Franceschini Leonardo Bautista-Gomez
Barcelona Supercomputing Center Barcelona Supercomputing Center Barcelona Supercomputing Center
Barcelona, Spain Barcelona, Spain Barcelona, Spain
[email protected] [email protected] [email protected]

Abstract—Scalability is a common issue among the most Proof-of-Work (PoW) to Proof-of-Stake (PoS). This change
used permissionless blockchains, and several approaches have allows blocks to be produced in a more sustainable way, saving
been proposed accordingly. As Ethereum is set to be a solid electricity while implementing a more exhaustive network
arXiv:2012.14718v1 [cs.CR] 29 Dec 2020

foundation for a decentralized Internet web, the need for tackling

scalability issues while preserving the security of the network is infrastructure. Due to the complexity of introducing this con-
an important challenge. In order to successfully deliver effective sensus mechanism, the achievement of sharding in Eth2 has
scaling solutions, Ethereum is on the path of a major protocol im- been split into different phases. In the first phase, called “Phase
provement called Ethereum 2.0 (Eth2), that implements sharding. 0” [2], PoS is implemented on the Beacon Chain and validators
As the change of consensus mechanism is an extremely delicate participate as part of proposers and attestation committees. The
matter, this improvement will be achieved through different
phases, first of which is the implementation of the Beacon Beacon Chain provides the random assignment of validators
Chain. For this, a specification has been developed and multiple to committees, and this sets the foundation of the next phases.
groups have implemented clients to run the new protocol. In The remainder of this paper is organized as follows. Sec-
this work, we analyse the resource usage behaviour of different tion II explains the methodology used during for evaluation.
clients running as Eth2 nodes, comparing their performance In Section III we show and analyse the results obtained
and analysing differences. Our results show multiple network
perturbations and how different clients react to it. by our study. Section IV discusses related work. Finally,
Index Terms—Blokchain, Ethereum2, Eth2, Beacon Chain, Section V concludes this work and presents some possible
Sharding, Clients, Proof of Stake, Smart Contracts, Scaling future directions.

I. I NTRODUCTION II. M ETHODOLOGY

Ethereum [1] has been a great achievement in the road to In order to study differences in behaviour of Eth2 clients, we
ubiquitous blockchain technology. It led to a huge growth have been running the Eth2 clients Teku, Nimbus, Lighthouse,
in the number of decentralized applications, due to its gen- Prysm and Lodestar for several hours, letting the clients sync
eral purpose virtual machine and its dedicated programming to the Eth2 chain from scratch. The objective of this study is to
language. These characteristics have set the conditions for a monitor specific metrics in order to understand the behaviour
solid community of developers and continuous advancements and performance of the clients when initialized to sync to the
as well as introducing new technological possibilities. As the Eth2 network. Clients have not always been run at the same
Ethereum adoption increases, its usability has been threatened time, as Prysm and Nimbus were launched and ran together,
by the rising transactions volume and network clogging. while Teku, Lighthouse and Lodestar have been run during
In order to successfully implement effective scaling solu- different periods of time. In addition to some differences in
tions, Ethereum is on the path to a major protocol improve- clients’ behaviour that may have been caused by conditions
ment, that will enhance its scalability by several orders of of the Medalla Test Network [3] at a given time, we have
magnitude and provide an architecture to flexibly address the found out some patterns and gathered some insights about the
needs of a constantly changing industry. Ethereum 2.0 (Eth2) clients. The metrics that have been monitored are:
is based around the concept of sharding, where the blockchain • Syncing time
is split into shards and subsets of validators are randomly • Peer connections
assigned to each shard in order to validate transactions. As • Network outgoing traffic
validators just need to validate transactions relative to the • Network incoming traffic
shards they have been assigned to, parallelism and therefore • Memory Usage
scalability is achieved. To have a coherent state of the network • CPU
between different shards, the roots of the shard blocks are • Disk Usage
appended to a dedicated chain called the Beacon Chain. This The metrics mentioned above have been collected by
Beacon Chain is considered to be the heart beat and the foun- launching the clients with an empty database and no external
dation of the sharding protocol. Validators shuffle randomly processes running. After having located the client process ID,
every epoch, verifying transactions on different shards. we launched a resource monitoring script written in python [4]
In order to embrace these changes to the final stage of that records the resource utilization every second into a data
Eth2, the consensus mechanism of Ethereum will change from file. While launching the clients, a flag has been added in order

1
to save clients’ logs to a text file. The logs were parsed through
python scripts [5], allowing to extrapolate the syncing speed
of the clients. Metrics and slot times were plotted through
python-matplotlib scripts [6], and saved into CSV files.
A. Evaluation platform
Tests have been run on two nodes, each node with an
Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz with 1 core
and two threads. Each client has been run on a single node
with 4.8 GB of total memory available and 34GB of storage
(40GB total, of which 6GB used for the operating system).
Clients have been run on the Medalla Test Network using
their default configuration. No additional flags or configuration
have been used with the exception of the flag on Teku that
limits the JVM memory and rising the heap size of Lodestar Fig. 1: Slot synchronization of Eth2 clients
on the package.json. Teku ran allocating 2 GB to the JVM,
as allocating more than 2GB would make the server crash. Figure 1 shows the synchronization slot as the client runs
Similar issues occurred with Lodestar. from genesis. We tried to run all clients for over 24 hours,
with the exception of Lodestar, which suffered from multiple
B. Client versions and running period
crashes and had to be restarted several times. We can see that
Clients have been run with the following versions: Lighthouse appears to be the fastest syncing client, though
• Teku: v0.12.14-dev-6883451c [7] its syncing process stops around hour 24 due to reaching the
• Prysm: v1.0.0-beta.1-4bc7cb6959a1ea5b [8] maximum storage capacity of the server (See Section III-G).
• Lighthouse: v0.3.0-95c96ac5 [9] After Lighthouse stopped its syncing process, Prysm was able
• Nimbus: 0.5.0-9255945f [10] to catch up and sync faster than the other clients with a steady
• Lodestar: commit 40a561483119c14751 [11] progress throughout the whole test. Nimbus and Lodestar seem
Clients have been running during the periods depicted in to be the ones that take more time to sync. More importantly,
Table I. Teku and Lighthouse were run several times in order it can be seen that all clients experience a sharp increase in
to compare the resource usage of two different executions. syncing speed around slot 100,000. The fact that all clients
observe the same change of steepness in the syncing curve
TABLE I: Client Running Periods around this slot might suggest that this phenomena is inherited
from the network conditions (See Section III-H).
Client Start Time End Time
Teku 2020-11-09 17:25:12 2020-11-10 17:34:45
Prysm 2020-11-04 18:34:12 2020-11-06 09:34:34 B. Peer connections
Lighthouse 2020-11-02 17:17:51 2020-11-04 02:57:38
Nimbus 2020-11-04 18:40:35 2020-11-06 10:23:04
We kept track of the number of peer connections for each
Lodestar 2020-11-08 20:19:02 2020-11-09 08:54:04 client during the experiment. While this is a parameter that
can be tuned, we used the default values for each client, as
this is what most user would do on a regular basis. We can
III. A NALYSIS see in Figure 2 that Teku connects to the highest number of
In this section we go over the results obtained during the peers (i.e., over 70 peers) than any other client and keeps a
runs of the five clients and we analyse their differences in stable number of connections during the entire experiment.
resource consumption and behaviour. Lighthouse is the client that connects with more peers after
Teku with about 50 peers. After 20 hours of execution, the
A. Client syncing number of connected peers drastically decreased (oscillating
First, we start by studying the synchronization time of all around 25 peers), and later rises its peer connection back to 50
clients. It is important to note that the synchronization time peers (hour 24). After hour 24 Lighthouse experienced sharp
of a client is not really a determining factor of its efficiency. drops and recoveries in peer connections. It is important to
First, this is a cost that it should be paid only once in the notice that Lighthouse was the first client to be run, from
lifetime of a client (assuming no hard failures that force a November 2dn to November 4th, while the Medalla Testnet
restart from scratch), but also because most clients can now was experiencing some issues related to non-finality [13]
start from a weak subjectivity state and be up and running which might explain the peer connection drops as well as
in under a minute. Nonetheless, synchronization time is very other strange phenomena observed in the Lighthouse run. This
relevant when comparing it with other resources metrics to try allowed us to do a more detailed analysis of the data. Nimbus
to uncover hidden effects or understand unexpected behaviour peers connections oscillate significantly, usually connecting
and this is the way we use it in this research. Other studies with over 15 peers and arriving up to 42 peers. Prysm
have also used syncing metrics in a similar way [12]. distinguishes itself for its stability of peer connections, as

2
it succeeds in achieving 30 peer connections with almost no
variation. When it comes to Lodestar, the client does not report
the number of peers until the moment in which it retrieves the
genesis block (hour 4), and from this point Lodestar’s peer
connections oscillate in the range of 20-30 peers.

Fig. 4: Clients outgoing network traffic and connected peers

Nimbus presents an interesting behaviour. As shown in

Figure 6, there is a point in which incoming traffic increases
substantially, while at the same time the curve that represents
Fig. 2: Peer connections of Eth2 Clients its slot synchronization does not appear to have accelerated
accordingly but on the contrary, it slows down. Teku is the
C. Outgoing network traffic client that has more network traffic for almost all of its
execution, but Lighthouse sharply increases network incoming
We also monitored the outgoing network traffic for all
data from hour 20 to hour 24, overtaking Teku. To analyse this
clients. In general, we can see in Figure 3 a steady constant
phenomena in more detail we plot the net incoming data vs
behaviour across all the clients for network outgoing data.
the number of peer connections in Figure 7. It can be seen
Prysm and Nimbus are the most conservative in outgoing
a considerable difference in Lighthouse’s incoming network
network traffic and their behaviour is quite similar (as their
traffic, as we can witness the acceleration in receiving data
network outgoing traffic almost overlaps). Teku seems to share
from 250MB/h (hours 15-17) to 1700MB/h (hours 21-23).
more data than the other clients. In general, the amount of
We notice that during those hours (i.e., 20-24) the number of
data shared by clients seems to correlate well to the number
peer connections decreases by about 50%, while the network
of peer connections: clients with more peer connections have
incoming data increases by a factor of 6.8. A similar (but
more outgoing traffic as shown in Figure 4.
smaller) effect is observed in hours 30-32, followed by a
period of stability.

Fig. 3: Clients outgoing network traffic

Fig. 5: Clients incoming network traffic

D. Incoming Network Traffic
For incoming network traffic, we see a much less stable Such a behaviour could be reasonably explained by the non-
behaviour than for outgoing. We can see in Figure 5 that finality period experienced at the end of October and beginning
Nimbus and Prysm are again the lightest clients in terms of of November, which fits well with the important number of
incoming network traffic. Prysm and Teku show a normal clients that drop out of the network during those hours. This
steady behaviour but Nimbus and Lighthouse do not. demonstrate, how non-finality periods can impact the clients.

3
 usage begins to diminish and then becomes flat. This is due
to the storage limitations in the node.

Fig. 6: Nimbus incoming traffic (green) and syncing (black)

E. Memory
Fig. 8: Memory consumption of Eth2 clients
When it comes to memory consumption, we can see in
Figure 8 how Teku and Prysm tend to have a similar behaviour,
by starting with a steep usage of memory consumption and F. CPU
settling with a similar high memory consumption in the long
run. Interestingly, we can notice sharp drops of memory usage From monitoring the CPU usage across the different clients,
for Prysm at somehow regular intervals, indicating some kind we noticed in Figure 10 that Nimbus has the lowest CPU
of periodic cleaning process, while the behaviour of Teku consumption overall, staying always under 50%. The CPU
is more constant. Nimbus distinguishes itself with a very usage of Prysm and Lodestar concentrates around 50%, while
low memory consumption with minimal changes. Lodestar the CPU usage of Lighthouse is most of the time above
memory usage is characterized by periodic spikes, and appears 50% and Teku constantly oscillates near 100%. Teku’s CPU
to be less demanding than the memory usage of Teku and usage is always high and stable in our experiments. There
Prysm. It can also be noticed that the first relevant spike might be several reasons for this. First, we performed our
corresponds to the moment in which the client actually starts experiments on a virtual machine with just one core of an
the syncing process. Lighthouse memory consumption is low Intel(R) Xeon(R) E5-2620 CPU (See Section II), which might
overall, but it showed some unstable behaviour. be significantly more limited than a contemporary node with
a more recent CPU generation and multiple cores. Second, we
limited the JVM heap size to only 2GB because larger JVM
heap sizes kept leading to crashes. With 2GB for the JVM
heap, Teku managed to run smoothly without issues. However,
2GB is quite tight for Medalla testnet and it is possible that a
significant portion of the time was spent in garbage collection,
leading to the observed high CPU utilization.

Fig. 7: Lighthouse incoming traffic (blue) and peer connections

(black)

In Figure 9 we can witness a considerable rise in memory

usage for Lighthouse (hour 20) that corresponds to the time
in which Lighthouse began to sharply increase its incoming
network traffic and the decrease in peer connections. The
memory usage oscillates around 3GB for several hours, until
the 24th hour where it can be seen that Lighthouse’s memory Fig. 9: Lighthouse memory (blue) and synchronization (black)

4
 Prysm also shows a relatively constant CPU utilization
except for hour 35, where it drops to 0, as shown in Figure
11. During that time, we also observe a strong reduction on
network incoming traffic, which explains the drop on CPU
utilization. It is interesting to notice that this happens even
while Prysm keeps stable peer connections (See Figure 2).

Fig. 12: Nimbus CPU (green) and slot synchronization (black)

G. Disk Usage
We plot the disk usage of all clients in Figure 14. This plot
shows some unexpected behaviour for some of the clients.
The most stable behaviour, in terms of disk usage among
Fig. 10: CPU usage of Eth2 clients all clients, seems to be Prysm according to this experiment.
Nimbus maintains a low storage usage for most of the time,
Nimbus also showed a constant CPU utilization most of the although it does experience a sharp increase in storage at
time, except for a short period of time around hour 7 where it some point. We investigate this increase in storage by isolating
witnessed a quite sharp drop in CPU usage, as it can be seen Nimbus’ disk utilization and comparing it with its CPU usage.
in Figure 12. We also can observe that this drop comes just We can see in Figure 15 that the increase in storage is quite
after a steep increase in blocks synced. In the other clients, dramatic, it goes from 1GB to over 4GB in a short period of
such an increase in synced blocks in a period of time is not time. Curiously, just after this storage increase, the CPU usage
followed by a CPU drop. This drop in CPU usage will be of Nimbus drops substantially. While it is true that periods of
further investigated later (See Section III-G). high storage intensity are often followed by idle CPU time,
note that the x-axis is denominated in hours. Such idle CPU
times just last for milliseconds or seconds after storage bursts,
so this solely it is unlikely to explain the whole drop of CPU
utilization. In addition, this is not observed in other clients
that also experience large increases in disk utilization.

Fig. 11: Prysm CPU (red) and incoming traffic (black)

Lighthouse showed some irregular CPU utilization pattern

with a sudden drop to 0% CPU utilization accompanied with a
flat memory usage during hours 10-12 as shown in Figure 13.
The same happens after hour 24, where the client stops syncing Fig. 13: Lighthouse CPU (blue) and memory usage (black)
and the CPU utilization spend most of the time near 0%. After
a sharp increase in memory usage during the previous period Lighthouse also shows a steep increase in disk usage,
of dropping peer connection (See Section III-E), the memory although much more important than Nimbus, going from 3GB
starts to decrease gradually, ending on a flat line. to over 10GB in minutes. After this, the disk usage continues

5
to increment at the same speed than initially doing, keeping
the same growth rate for several hours, to then drop sharply at
around hour 8. Interestingly, extrapolating the initial storage
growth rate would place Lighthouse at the same spot after
9 hours of syncing, as if the whole storage used during the
perturbation was just temporary data that once everything
solved, could be discarded without losing any real information.
After 20 hours, however, Lighthouse observes another sharp
increase in disk usage, but this time it keeps going up until
it consumes the whole 34GB of space in the node, at which
point it becomes a flat line for the next 10 hours.

Fig. 16: Lighthouse CPU (blue) and disk usage (black)

Teku, on the other hand, demonstrated a strange disk usage

pattern that resembles to a zig-zag as shown in Figure 14.
This zig-zag pattern could be explained by the fact that
Teku uses RocksDB, which sometimes implements a periodic
compression scheme in which the database grows for a while
and then compacts itself. Nonetheless, its periodicity gets
disrupted at some point, and from hours 4 to 6 we can see
an important perturbation in the disk utilization.
Fig. 14: Disk Usage of Eth2 clients

In figure 16, we compare the disk and CPU utilization of

Lighthouse. As we can see, in the same spots where there
is no CPU utilization (i.e., hours 10-12 and 24-34) the disk
utilization also becomes flat, showing that the client stall
during those last hours.

Fig. 17: Teku Disk Usage for two different executions

To have a better view of the perturbation, we plotted the disk

utilization of Teku by last synced slot (instead of wall-clock
time) and we can clearly see that the perturbation happens
between slots 70,000 and 120,000, as shown in Figure 17.
Fig. 15: Nimbus CPU (green) and slot synchronization (black) Given that this perturbation could be related to some random
internal process in the node or events linked to RocksDB or the
This phenomena, could be linked to a Medalla non-finality JVM, we decided to run Teku again from scratch on the same
period during October-November caused by a low number of node. To our surprise the disk usage pattern of the second run
validators [13]. With the exception of Lighthouse’s behaviour, is almost identical to the first one, with the same perturbation
possibly caused by a consensus problem in the Medalla between the same slots (i.e., 70,000-120,000). Please note that
Testnet, Lodestar seems to use more storage than all the other these two runs were done one three days after the other. This
clients. In addition, it can be noticed that Lodestar starts deterministic behaviour seems to imply that the client is simply
gathering data after a long period of time (4 hours), which requesting and processing blocks in order, one after the other,
seems to be linked to the time spent getting the genesis block. which could imply that the client is syncing through a finalised

6
part of the chain where there are no forks to explore and During this period, we observe a sharp increase in the
everything is deterministic. We also ran Lighthouse twice to disk usage of Teku, Lighthouse and Nimbus, while Lodestar
check if the disk behaviour was deterministic and it is for most shows the exact opposite and the behaviour of Prysm seems
of the period between slots 75,000 and 120,000, as shown in to be unaffected. For Lighthouse and Teku, we can see that
Figure 18. However, Lighthouse behaviour does change a bit the sharp increase in Disk usage is followed by a similarly
after slot 210,000: the second run managed to reduce storage sharp drop towards the end of this period. Considering the
usage way before the first run. Although, this shows that this relatively similar behaviour of both clients, it is interesting to
behaviour is not just an artifact of our experiments, this does notice how Teku reduced the time of higher disk usage, while
not explain why the disk grows so fast and what is the root- Lighthouse keeps running several hours with additional data
cause of the perturbation. before dumping it. This is due to the dual-database system that
Lighthouse and some other clients use: a Hot database that
stores unfinalized BeaconState objects, and a cold database
that stores finalized BeaconStates. As they sync through a large
patch of non-finality, their hot databases grow large until they
reach finality and then migrate this state into the cold database.

Fig. 18: Lighthouse Disk Usage for two different executions

H. Fossil Records of Non-Finality

Fig. 20: Detail of slot synchronization of Eth2 clients
In an attempt to compare the disk behaviour of all clients
in a synchronous way, we have plotted the storage usage of
all clients with respect to the slot number in Figure 19. In this On the other hand, Nimbus rise in disk storage is not as
plot, we see that almost all clients change behaviour some- sharp as Teku and Lighthouse, however it did not reduce
where around slot 70,000 and go back to a normal behaviour its storage afterwards (in contrast to Teku and Lighthouse).
around slot 120,000. This period corresponds with the non- Oddly, we can notice that Lodestar’s disk usage increases
finality period of Medalla. Indeed, the Medalla network passed more rapidly than any other client at the beginning, until the
through a period of non-finality caused by erroneous rough start of this non-finality period, when it stops growing at all.
time responses witnessed by Prysm clients [14]. Prysm’s disk usage continues its trend without any variations
as if it was not perturbed by the non-finality period. This is
because Prysm clients only save finalized states in intervals of
every 2048 slots. This keeps disk utilization to a minimum.
During non-finality, they do not save unfinalized states to
disk which allows them to prevent the database from growing
unnecessarily large. However doing this comes at a cost, as
they now keep everything in memory so if they do need to
retrieve a particular state (unfinalized) and it’s been a while
since finality, they have to regenerate it. Doing this puts a non
trivial amount of pressure on the CPU and can make keeping
track of all the different forks harder.
During this non-finality period, clients also showed a steeper
syncing curve around slot 100,000, as we can see in Figure
20. This could imply that during this period there is little
information to process and therefore clients can move faster in
the syncing process. However, this does not seem to fit with
Fig. 19: Disk Usage of Eth2 clients for slots the accelerating disk usage observed during the same period.

7
To look deeper into this question, we used Teku logs to analyse finality period, we have demonstrated in this paper that it
the number of times a block was queued and/or processed for is possible to identify such a network disturbance by simply
each slot during the non-finality period. The results, depicted looking at the resource utilization of the clients.
in Figure 21, show that during this period there were almost
no blocks queued, which seems to be consistent with the IV. R ELATED W ORK
accelerated syncing speed. However we also notice that just at
In recent years, there have been significant efforts to study
the beginning of the non-finality period, at exactly slot 73,248,
the scalability and security of the Ethereum network from mul-
there were 219 blocks queued (note the logarithmic Y axis).
tiple perspectives. The importance of a new consensus mech-
This clearly shows a huge perturbation in the network.
anism for Ethereum can be understood through the scalability
challenges that the protocol faces [15]. Peers participation of
Ethereum network has been studied previously [16].
Eth2 clients rely on the Proof-of-Stake (PoS) consensus
mechanism called Casper [17] and some works have shown
insights on the Casper’s robustness depending on the network
latency [18]. However, Casper and the Beacon Chain is just the
first step (i.e., Phase 0) of a fully sharded Eth2 protocol, and its
following phase concerns the problem of data availability [19].
In addition, the current security threats of Ethereum have
also been analysed recently [20]. While all these analyses
are very valuable for the community, they all focus on the
protocol security aspects and none of them evaluates the actual
implementation of the protocol.
Eth2 consensus mechanism requires validators to lock ETH
Fig. 21: Number of times a block is queued into a deposit smart-contract, whose security is essential. In
order to verify and increase the security of the deposit contract,
We assume that the accelerating disk usage is related to an formal verification of the Eth2 deposit contract has been
increase in the state stored in the database of the client, and done [21]. This study does verify the implementation of the
this might be linked to a difficulty of pruning states during deposit contract but not the Eth2 clients. While Eth1 clients
a non-finality period. Thus, to corroborate our hypothesis, we have also been analysed in the past [22], to the best of our
analysed Lighthouse detailed logs and plot the frequency at knowledge there is no a study showing the resource utilization
which different events get executed. Figure 22 lists a total of of Eth2 clients and what can be understood from it.
11 different types of events. We can see that during the non-
finality period there are four type of events that almost never V. C ONCLUSION
get executed: Freezer migration started, Database pruning In this work, we have performed a detailed analysis of the
complete, Extra pruning information, and Starting database resource usage of Eth2 clients. Through this analysis, we have
pruning. This demonstrates that during this period the client been able to notice the effort of different teams to develop
is unable to prune the database, which is consistent with the functional software in order to tackle the transitioning to Eth2.
rapid disk usage increase. The necessity of relying on several types of clients is reflected
by the different objectives and resources of a broad variety
of users. Our analysis showed significant differences between
clients in terms of CPU, memory and disk utilization. We also
observed some network perturbations where the number of
peers dropped quickly and its impact on the other resources.
To the best of our knowledge, this is the first study of the Eth2
clients resource usage at this scale and to demonstrate that it
is possible to detect traces of non-finality periods by simply
looking at the clients’ resource usage. The diverse behaviour
of the analysed clients is a positive sign for the Ethereum
community, as it shows a solid variety of software available
for Eth2 validators, and this provides the network with further
decentralization, resilience and security.
Fig. 22: Events timeline for Lighthouse As future work, we would like to further study how non-
finality periods affect the resources usage of Eth2 clients, in
Although there are multiple of things that remain to be order to implement online detectors that use this information
understood about the behaviour of some clients during a non- to signal possible network perturbations in real time.

8
 ACKNOWLEDGMENT
This work has been supported by the Ethereum Founda-
tion under Grant FY20-0198. We would like to thank the
researchers of the Ethereum Foundation for their feedback and
suggestions. We would also like to thank the developers and
researchers of the five client teams for all their help to set up
our experiments and their constructive feedback on this study.
R EFERENCES
[1] “Ethereum whitepaper,” https://ethereum.org/en/whitepaper/.
[2] “Phase-0,” https://notes.ethereum.org/@djrtwo/Bkn3zpwxB.
[3] “Medalla test network:,” https://github.com/goerli/medalla.
[4] “Monitoring scripts:,” https://github.com/leobago/BSC-ETH2/tree/
master/ETH2-clients-comparison/scripts/parsing scripts/metrics
monitoring scripts.
[5] “Logs parsing scripts:,” https://github.com/leobago/BSC-ETH2/tree/
master/ETH2-clients-comparison/scripts/parsing scripts/client logs
analysis scripts.
[6] “Plotting scripts:,” https://github.com/leobago/BSC-ETH2/tree/master/
ETH2-clients-comparison/scripts/plotting scripts.
[7] “Teku version:,” https://github.com/ConsenSys/teku/commit/
6883451c9f87a28c5923dbc8f291db237930cad0.
[8] “Prysm version:,” https://github.com/prysmaticlabs/prysm/commit/
4bc7cb6959a1ea5b4b4b53b42284900e3b117dea.
[9] “Lighthouse version:,” https://github.com/sigp/lighthouse/commit/
95c96ac567474df2abb4e9da9f5e771cf5a7426d.
[10] “Nimbus version:,” https://github.com/status-im/nimbus-eth2/commit/
9255945fb0ef1bf036d32b7cce5df42a8dd69be7.
[11] “Lodestar version:,” https://github.com/ChainSafe/lodestar/pull/1731.
[12] “Multi-client benchmark on medalla testnet 2020/10/01:,” https://github.
com/q9f/eth2-bench-2020-10.
[13] “Medalla non-finality october 2020:,” https://gist.github.com/
yorickdowne/ea9b18ac2b51a508080c9a810d978522.
[14] “Medalla non-finality period august
2020:,” https://docs.google.com/document/d/
11RmitNRui10LcLCyoXY6B1INCZZKq30gEU6BEg3EWfk.
[15] M. Bez, G. Fornari, and T. Vardanega, “The scalability challenge of
ethereum: An initial quantitative analysis,” in 2019 IEEE International
Conference on Service-Oriented System Engineering (SOSE), April
2019, pp. 167–176.
[16] S. K. Kim, Z. Ma, S. Murali, J. Mason, A. Miller, and M. Bailey,
“Measuring ethereum network peers,” in Proceedings of the Internet
Measurement Conference 2018, ser. IMC ’18. New York, NY, USA:
Association for Computing Machinery, 2018, p. 91–104. [Online].
Available: https://doi.org/10.1145/3278532.3278542
[17] V. Buterin and V. Griffith, “Casper the friendly finality gadget,” 2019.
[18] O. Moindrot, “Proof of stake made simple with casper,” 2017.
[19] D. Sel, K. Zhang, and H.-A. Jacobsen, “Towards solving the
data availability problem for sharded ethereum,” in Proceedings
of the 2nd Workshop on Scalable and Resilient Infrastructures
for Distributed Ledgers, ser. SERIAL’18. New York, NY, USA:
Association for Computing Machinery, 2018, p. 25–30. [Online].
Available: https://doi.org/10.1145/3284764.3284769
[20] H. Chen, M. Pendleton, L. Njilla, and S. Xu, “A survey on
ethereum systems security: Vulnerabilities, attacks, and defenses,”
ACM Comput. Surv., vol. 53, no. 3, Jun. 2020. [Online]. Available:
https://doi.org/10.1145/3391195
[21] D. Park, Y. Zhang, and G. Rosu, “End-to-end formal verification
of ethereum 2.0 deposit smart contract,” in Computer Aided Verifica-
tion, S. K. Lahiri and C. Wang, Eds. Cham: Springer International
Publishing, 2020, pp. 151–164.
[22] S. Rouhani and R. Deters, “Performance analysis of ethereum transac-
tions in private blockchain,” in 2017 8th IEEE International Conference
on Software Engineering and Service Science (ICSESS), 2017, pp. 70–
74.