Resource Analysis of Ethereum 2.0 Clients
Mikel Cortes-Goicoechea, Luca Franceschini, Leonardo Bautista-Gomez
RResource Analysis of Ethereum 2.0 Clients
Mikel Cortes-Goicoechea
Barcelona Supercomputing Center
Barcelona, [email protected]
Luca Franceschini
Barcelona Supercomputing Center
Barcelona, [email protected]
Leonardo Bautista-Gomez
Barcelona Supercomputing Center
Barcelona, [email protected]
Abstract —Scalability is a common issue among the mostused permissionless blockchains, and several approaches havebeen proposed accordingly. As Ethereum is set to be a solidfoundation for a decentralized Internet web, the need for tacklingscalability issues while preserving the security of the network isan important challenge. In order to successfully deliver effectivescaling solutions, Ethereum is on the path of a major protocol im-provement called Ethereum 2.0 (Eth2), that implements sharding.As the change of consensus mechanism is an extremely delicatematter, this improvement will be achieved through differentphases, first of which is the implementation of the BeaconChain. For this, a specification has been developed and multiplegroups have implemented clients to run the new protocol. Inthis work, we analyse the resource usage behaviour of differentclients running as Eth2 nodes, comparing their performanceand analysing differences. Our results show multiple networkperturbations and how different clients react to it.
Index Terms —Blokchain, Ethereum2, Eth2, Beacon Chain,Sharding, Clients, Proof of Stake, Smart Contracts, Scaling
I. I
NTRODUCTION
Ethereum [1] has been a great achievement in the road toubiquitous blockchain technology. It led to a huge growthin the number of decentralized applications, due to its gen-eral purpose virtual machine and its dedicated programminglanguage. These characteristics have set the conditions for asolid community of developers and continuous advancementsas well as introducing new technological possibilities. As theEthereum adoption increases, its usability has been threatenedby the rising transactions volume and network clogging.In order to successfully implement effective scaling solu-tions, Ethereum is on the path to a major protocol improve-ment, that will enhance its scalability by several orders ofmagnitude and provide an architecture to flexibly address theneeds of a constantly changing industry. Ethereum 2.0 (Eth2)is based around the concept of sharding, where the blockchainis split into shards and subsets of validators are randomlyassigned to each shard in order to validate transactions. Asvalidators just need to validate transactions relative to theshards they have been assigned to, parallelism and thereforescalability is achieved. To have a coherent state of the networkbetween different shards, the roots of the shard blocks areappended to a dedicated chain called the Beacon Chain. ThisBeacon Chain is considered to be the heart beat and the foun-dation of the sharding protocol. Validators shuffle randomlyevery epoch, verifying transactions on different shards.In order to embrace these changes to the final stage ofEth2, the consensus mechanism of Ethereum will change from Proof-of-Work (PoW) to Proof-of-Stake (PoS). This changeallows blocks to be produced in a more sustainable way, savingelectricity while implementing a more exhaustive networkinfrastructure. Due to the complexity of introducing this con-sensus mechanism, the achievement of sharding in Eth2 hasbeen split into different phases. In the first phase, called “Phase0” [2], PoS is implemented on the Beacon Chain and validatorsparticipate as part of proposers and attestation committees. TheBeacon Chain provides the random assignment of validatorsto committees, and this sets the foundation of the next phases.The remainder of this paper is organized as follows. Sec-tion II explains the methodology used during for evaluation.In Section III we show and analyse the results obtainedby our study. Section IV discusses related work. Finally,Section V concludes this work and presents some possiblefuture directions. II. M
ETHODOLOGY
In order to study differences in behaviour of Eth2 clients, wehave been running the Eth2 clients Teku, Nimbus, Lighthouse,Prysm and Lodestar for several hours, letting the clients syncto the Eth2 chain from scratch. The objective of this study is tomonitor specific metrics in order to understand the behaviourand performance of the clients when initialized to sync to theEth2 network. Clients have not always been run at the sametime, as Prysm and Nimbus were launched and ran together,while Teku, Lighthouse and Lodestar have been run duringdifferent periods of time. In addition to some differences inclients’ behaviour that may have been caused by conditionsof the Medalla Test Network [3] at a given time, we havefound out some patterns and gathered some insights about theclients. The metrics that have been monitored are: • Syncing time • Peer connections • Network outgoing traffic • Network incoming traffic • Memory Usage • CPU • Disk UsageThe metrics mentioned above have been collected bylaunching the clients with an empty database and no externalprocesses running. After having located the client process ID,we launched a resource monitoring script written in python [4]that records the resource utilization every second into a datafile. While launching the clients, a flag has been added in order1 a r X i v : . [ c s . CR ] D ec o save clients’ logs to a text file. The logs were parsed throughpython scripts [5], allowing to extrapolate the syncing speedof the clients. Metrics and slot times were plotted throughpython-matplotlib scripts [6], and saved into CSV files. A. Evaluation platform
Tests have been run on two nodes, each node with anIntel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz with 1 coreand two threads. Each client has been run on a single nodewith 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 usingtheir default configuration. No additional flags or configurationhave been used with the exception of the flag on Teku thatlimits the JVM memory and rising the heap size of Lodestaron the package.json. Teku ran allocating 2 GB to the JVM,as allocating more than 2GB would make the server crash.Similar issues occurred with Lodestar.
B. Client versions and running period
Clients have been run with the following versions: • Teku: v0.12.14-dev-6883451c [7] • Prysm: v1.0.0-beta.1-4bc7cb6959a1ea5b [8] • Lighthouse: v0.3.0-95c96ac5 [9] • Nimbus: 0.5.0-9255945f [10] • Lodestar: commit 40a561483119c14751 [11]Clients have been running during the periods depicted inTable I. Teku and Lighthouse were run several times in orderto compare the resource usage of two different executions.TABLE I: Client Running Periods
Client Start Time End TimeTeku 2020-11-09 17:25:12 2020-11-10 17:34:45Prysm 2020-11-04 18:34:12 2020-11-06 09:34:34Lighthouse 2020-11-02 17:17:51 2020-11-04 02:57:38Nimbus 2020-11-04 18:40:35 2020-11-06 10:23:04Lodestar 2020-11-08 20:19:02 2020-11-09 08:54:04
III. A
NALYSIS
In this section we go over the results obtained during theruns of the five clients and we analyse their differences inresource consumption and behaviour.
A. Client syncing
First, we start by studying the synchronization time of allclients. It is important to note that the synchronization timeof a client is not really a determining factor of its efficiency.First, this is a cost that it should be paid only once in thelifetime of a client (assuming no hard failures that force arestart from scratch), but also because most clients can nowstart from a weak subjectivity state and be up and runningin under a minute. Nonetheless, synchronization time is veryrelevant when comparing it with other resources metrics to tryto uncover hidden effects or understand unexpected behaviourand this is the way we use it in this research. Other studieshave also used syncing metrics in a similar way [12]. Fig. 1: Slot synchronization of Eth2 clientsFigure 1 shows the synchronization slot as the client runsfrom genesis. We tried to run all clients for over 24 hours,with the exception of Lodestar, which suffered from multiplecrashes and had to be restarted several times. We can see thatLighthouse appears to be the fastest syncing client, thoughits syncing process stops around hour 24 due to reaching themaximum storage capacity of the server (See Section III-G).After Lighthouse stopped its syncing process, Prysm was ableto catch up and sync faster than the other clients with a steadyprogress throughout the whole test. Nimbus and Lodestar seemto be the ones that take more time to sync. More importantly,it can be seen that all clients experience a sharp increase insyncing speed around slot 100,000. The fact that all clientsobserve the same change of steepness in the syncing curvearound this slot might suggest that this phenomena is inheritedfrom the network conditions (See Section III-H).
B. Peer connections
We kept track of the number of peer connections for eachclient during the experiment. While this is a parameter thatcan be tuned, we used the default values for each client, asthis is what most user would do on a regular basis. We cansee in Figure 2 that Teku connects to the highest number ofpeers (i.e., over 70 peers) than any other client and keeps astable number of connections during the entire experiment.Lighthouse is the client that connects with more peers afterTeku with about 50 peers. After 20 hours of execution, thenumber of connected peers drastically decreased (oscillatingaround 25 peers), and later rises its peer connection back to 50peers (hour 24). After hour 24 Lighthouse experienced sharpdrops and recoveries in peer connections. It is important tonotice that Lighthouse was the first client to be run, fromNovember 2dn to November 4th, while the Medalla Testnetwas experiencing some issues related to non-finality [13]which might explain the peer connection drops as well asother strange phenomena observed in the Lighthouse run. Thisallowed us to do a more detailed analysis of the data. Nimbuspeers connections oscillate significantly, usually connectingwith over 15 peers and arriving up to 42 peers. Prysmdistinguishes itself for its stability of peer connections, as2t succeeds in achieving 30 peer connections with almost novariation. When it comes to Lodestar, the client does not reportthe number of peers until the moment in which it retrieves thegenesis block (hour 4), and from this point Lodestar’s peerconnections oscillate in the range of 20-30 peers.Fig. 2: Peer connections of Eth2 Clients
C. Outgoing network traffic
We also monitored the outgoing network traffic for allclients. In general, we can see in Figure 3 a steady constantbehaviour across all the clients for network outgoing data.Prysm and Nimbus are the most conservative in outgoingnetwork traffic and their behaviour is quite similar (as theirnetwork outgoing traffic almost overlaps). Teku seems to sharemore data than the other clients. In general, the amount ofdata shared by clients seems to correlate well to the numberof peer connections: clients with more peer connections havemore outgoing traffic as shown in Figure 4.Fig. 3: Clients outgoing network traffic
D. Incoming Network Traffic
For incoming network traffic, we see a much less stablebehaviour than for outgoing. We can see in Figure 5 thatNimbus and Prysm are again the lightest clients in terms ofincoming network traffic. Prysm and Teku show a normalsteady behaviour but Nimbus and Lighthouse do not. Fig. 4: Clients outgoing network traffic and connected peersNimbus presents an interesting behaviour. As shown inFigure 6, there is a point in which incoming traffic increasessubstantially, while at the same time the curve that representsits slot synchronization does not appear to have acceleratedaccordingly but on the contrary, it slows down. Teku is theclient that has more network traffic for almost all of itsexecution, but Lighthouse sharply increases network incomingdata from hour 20 to hour 24, overtaking Teku. To analyse thisphenomena in more detail we plot the net incoming data vsthe number of peer connections in Figure 7. It can be seena considerable difference in Lighthouse’s incoming networktraffic, as we can witness the acceleration in receiving datafrom 250MB/h (hours 15-17) to 1700MB/h (hours 21-23).We notice that during those hours (i.e., 20-24) the number ofpeer connections decreases by about 50%, while the networkincoming data increases by a factor of . . A similar (butsmaller) effect is observed in hours 30-32, followed by aperiod of stability.Fig. 5: Clients incoming network trafficSuch a behaviour could be reasonably explained by the non-finality period experienced at the end of October and beginningof November, which fits well with the important number ofclients that drop out of the network during those hours. Thisdemonstrate, how non-finality periods can impact the clients.3ig. 6: Nimbus incoming traffic (green) and syncing (black) E. Memory
When it comes to memory consumption, we can see inFigure 8 how Teku and Prysm tend to have a similar behaviour,by starting with a steep usage of memory consumption andsettling with a similar high memory consumption in the longrun. Interestingly, we can notice sharp drops of memory usagefor Prysm at somehow regular intervals, indicating some kindof periodic cleaning process, while the behaviour of Tekuis more constant. Nimbus distinguishes itself with a verylow memory consumption with minimal changes. Lodestarmemory usage is characterized by periodic spikes, and appearsto be less demanding than the memory usage of Teku andPrysm. It can also be noticed that the first relevant spikecorresponds to the moment in which the client actually startsthe syncing process. Lighthouse memory consumption is lowoverall, but it showed some unstable behaviour.Fig. 7: Lighthouse incoming traffic (blue) and peer connections(black)In Figure 9 we can witness a considerable rise in memoryusage for Lighthouse (hour 20) that corresponds to the timein which Lighthouse began to sharply increase its incomingnetwork traffic and the decrease in peer connections. Thememory usage oscillates around 3GB for several hours, untilthe 24th hour where it can be seen that Lighthouse’s memory usage begins to diminish and then becomes flat. This is dueto the storage limitations in the node.Fig. 8: Memory consumption of Eth2 clients
F. CPU
From monitoring the CPU usage across the different clients,we noticed in Figure 10 that Nimbus has the lowest CPUconsumption overall, staying always under 50%. The CPUusage of Prysm and Lodestar concentrates around 50%, whilethe CPU usage of Lighthouse is most of the time above50% and Teku constantly oscillates near 100%. Teku’s CPUusage is always high and stable in our experiments. Theremight be several reasons for this. First, we performed ourexperiments on a virtual machine with just one core of anIntel(R) Xeon(R) E5-2620 CPU (See Section II), which mightbe significantly more limited than a contemporary node witha more recent CPU generation and multiple cores. Second, welimited the JVM heap size to only 2GB because larger JVMheap sizes kept leading to crashes. With 2GB for the JVMheap, Teku managed to run smoothly without issues. However,2GB is quite tight for Medalla testnet and it is possible that asignificant portion of the time was spent in garbage collection,leading to the observed high CPU utilization.Fig. 9: Lighthouse memory (blue) and synchronization (black)4rysm also shows a relatively constant CPU utilizationexcept for hour 35, where it drops to 0, as shown in Figure11. During that time, we also observe a strong reduction onnetwork incoming traffic, which explains the drop on CPUutilization. It is interesting to notice that this happens evenwhile Prysm keeps stable peer connections (See Figure 2).Fig. 10: CPU usage of Eth2 clientsNimbus also showed a constant CPU utilization most of thetime, except for a short period of time around hour 7 where itwitnessed a quite sharp drop in CPU usage, as it can be seenin Figure 12. We also can observe that this drop comes justafter a steep increase in blocks synced. In the other clients,such an increase in synced blocks in a period of time is notfollowed by a CPU drop. This drop in CPU usage will befurther investigated later (See Section III-G).Fig. 11: Prysm CPU (red) and incoming traffic (black)Lighthouse showed some irregular CPU utilization patternwith a sudden drop to 0% CPU utilization accompanied with aflat memory usage during hours 10-12 as shown in Figure 13.The same happens after hour 24, where the client stops syncingand the CPU utilization spend most of the time near 0%. Aftera sharp increase in memory usage during the previous periodof dropping peer connection (See Section III-E), the memorystarts to decrease gradually, ending on a flat line. Fig. 12: Nimbus CPU (green) and slot synchronization (black)
G. Disk Usage
We plot the disk usage of all clients in Figure 14. This plotshows some unexpected behaviour for some of the clients.The most stable behaviour, in terms of disk usage amongall clients, seems to be Prysm according to this experiment.Nimbus maintains a low storage usage for most of the time,although it does experience a sharp increase in storage atsome point. We investigate this increase in storage by isolatingNimbus’ disk utilization and comparing it with its CPU usage.We can see in Figure 15 that the increase in storage is quitedramatic, it goes from 1GB to over 4GB in a short period oftime. Curiously, just after this storage increase, the CPU usageof Nimbus drops substantially. While it is true that periods ofhigh storage intensity are often followed by idle CPU time,note that the x-axis is denominated in hours. Such idle CPUtimes just last for milliseconds or seconds after storage bursts,so this solely it is unlikely to explain the whole drop of CPUutilization. In addition, this is not observed in other clientsthat also experience large increases in disk utilization.Fig. 13: Lighthouse CPU (blue) and memory usage (black)Lighthouse also shows a steep increase in disk usage,although much more important than Nimbus, going from 3GBto over 10GB in minutes. After this, the disk usage continues5o increment at the same speed than initially doing, keepingthe same growth rate for several hours, to then drop sharply ataround hour 8. Interestingly, extrapolating the initial storagegrowth rate would place Lighthouse at the same spot after9 hours of syncing, as if the whole storage used during theperturbation was just temporary data that once everythingsolved, could be discarded without losing any real information.After 20 hours, however, Lighthouse observes another sharpincrease in disk usage, but this time it keeps going up untilit consumes the whole 34GB of space in the node, at whichpoint it becomes a flat line for the next 10 hours.Fig. 14: Disk Usage of Eth2 clientsIn figure 16, we compare the disk and CPU utilization ofLighthouse. As we can see, in the same spots where thereis no CPU utilization (i.e., hours 10-12 and 24-34) the diskutilization also becomes flat, showing that the client stallduring those last hours.Fig. 15: Nimbus CPU (green) and slot synchronization (black)This phenomena, could be linked to a Medalla non-finalityperiod during October-November caused by a low number ofvalidators [13]. With the exception of Lighthouse’s behaviour,possibly caused by a consensus problem in the MedallaTestnet, Lodestar seems to use more storage than all the otherclients. In addition, it can be noticed that Lodestar startsgathering data after a long period of time (4 hours), whichseems to be linked to the time spent getting the genesis block. Fig. 16: Lighthouse CPU (blue) and disk usage (black)Teku, on the other hand, demonstrated a strange disk usagepattern that resembles to a zig-zag as shown in Figure 14.This zig-zag pattern could be explained by the fact thatTeku uses RocksDB, which sometimes implements a periodiccompression scheme in which the database grows for a whileand then compacts itself. Nonetheless, its periodicity getsdisrupted at some point, and from hours 4 to 6 we can seean important perturbation in the disk utilization.Fig. 17: Teku Disk Usage for two different executionsTo have a better view of the perturbation, we plotted the diskutilization of Teku by last synced slot (instead of wall-clocktime) and we can clearly see that the perturbation happensbetween slots 70,000 and 120,000, as shown in Figure 17.Given that this perturbation could be related to some randominternal process in the node or events linked to RocksDB or theJVM, we decided to run Teku again from scratch on the samenode. To our surprise the disk usage pattern of the second runis almost identical to the first one, with the same perturbationbetween the same slots (i.e., 70,000-120,000). Please note thatthese two runs were done one three days after the other. Thisdeterministic behaviour seems to imply that the client is simplyrequesting and processing blocks in order, one after the other,which could imply that the client is syncing through a finalised6art of the chain where there are no forks to explore andeverything is deterministic. We also ran Lighthouse twice tocheck if the disk behaviour was deterministic and it is for mostof the period between slots 75,000 and 120,000, as shown inFigure 18. However, Lighthouse behaviour does change a bitafter slot 210,000: the second run managed to reduce storageusage way before the first run. Although, this shows that thisbehaviour is not just an artifact of our experiments, this doesnot explain why the disk grows so fast and what is the root-cause of the perturbation.Fig. 18: Lighthouse Disk Usage for two different executions
H. Fossil Records of Non-Finality
In an attempt to compare the disk behaviour of all clientsin a synchronous way, we have plotted the storage usage ofall clients with respect to the slot number in Figure 19. In thisplot, we see that almost all clients change behaviour some-where around slot 70,000 and go back to a normal behaviouraround slot 120,000. This period corresponds with the non-finality period of Medalla. Indeed, the Medalla network passedthrough a period of non-finality caused by erroneous roughtime responses witnessed by Prysm clients [14].Fig. 19: Disk Usage of Eth2 clients for slots During this period, we observe a sharp increase in thedisk usage of Teku, Lighthouse and Nimbus, while Lodestarshows the exact opposite and the behaviour of Prysm seemsto be unaffected. For Lighthouse and Teku, we can see thatthe sharp increase in Disk usage is followed by a similarlysharp drop towards the end of this period. Considering therelatively similar behaviour of both clients, it is interesting tonotice how Teku reduced the time of higher disk usage, whileLighthouse keeps running several hours with additional databefore dumping it. This is due to the dual-database system thatLighthouse and some other clients use: a
Hot database thatstores unfinalized BeaconState objects, and a cold databasethat stores finalized BeaconStates. As they sync through a largepatch of non-finality, their hot databases grow large until theyreach finality and then migrate this state into the cold database.Fig. 20: Detail of slot synchronization of Eth2 clientsOn the other hand, Nimbus rise in disk storage is not assharp as Teku and Lighthouse, however it did not reduceits storage afterwards (in contrast to Teku and Lighthouse).Oddly, we can notice that Lodestar’s disk usage increasesmore rapidly than any other client at the beginning, until thestart of this non-finality period, when it stops growing at all.Prysm’s disk usage continues its trend without any variationsas if it was not perturbed by the non-finality period. This isbecause Prysm clients only save finalized states in intervals ofevery 2048 slots. This keeps disk utilization to a minimum.During non-finality, they do not save unfinalized states todisk which allows them to prevent the database from growingunnecessarily large. However doing this comes at a cost, asthey now keep everything in memory so if they do need toretrieve a particular state (unfinalized) and it’s been a whilesince finality, they have to regenerate it. Doing this puts a nontrivial amount of pressure on the CPU and can make keepingtrack of all the different forks harder.During this non-finality period, clients also showed a steepersyncing curve around slot 100,000, as we can see in Figure20. This could imply that during this period there is littleinformation to process and therefore clients can move faster inthe syncing process. However, this does not seem to fit withthe accelerating disk usage observed during the same period.7o look deeper into this question, we used Teku logs to analysethe number of times a block was queued and/or processed foreach slot during the non-finality period. The results, depictedin Figure 21, show that during this period there were almostno blocks queued, which seems to be consistent with theaccelerated syncing speed. However we also notice that just atthe beginning of the non-finality period, at exactly slot 73,248,there were 219 blocks queued (note the logarithmic Y axis).This clearly shows a huge perturbation in the network.Fig. 21: Number of times a block is queuedWe assume that the accelerating disk usage is related to anincrease in the state stored in the database of the client, andthis might be linked to a difficulty of pruning states duringa non-finality period. Thus, to corroborate our hypothesis, weanalysed Lighthouse detailed logs and plot the frequency atwhich different events get executed. Figure 22 lists a total of11 different types of events. We can see that during the non-finality period there are four type of events that almost neverget executed:
Freezer migration started, Database pruningcomplete, Extra pruning information, and Starting databasepruning . This demonstrates that during this period the clientis unable to prune the database, which is consistent with therapid disk usage increase.Fig. 22: Events timeline for LighthouseAlthough there are multiple of things that remain to beunderstood about the behaviour of some clients during a non- finality period, we have demonstrated in this paper that itis possible to identify such a network disturbance by simplylooking at the resource utilization of the clients.IV. R
ELATED W ORK
In recent years, there have been significant efforts to studythe scalability and security of the Ethereum network from mul-tiple perspectives. The importance of a new consensus mech-anism for Ethereum can be understood through the scalabilitychallenges that the protocol faces [15]. Peers participation ofEthereum network has been studied previously [16].Eth2 clients rely on the Proof-of-Stake (PoS) consensusmechanism called Casper [17] and some works have showninsights on the Casper’s robustness depending on the networklatency [18]. However, Casper and the Beacon Chain is just thefirst step (i.e., Phase 0) of a fully sharded Eth2 protocol, and itsfollowing phase concerns the problem of data availability [19].In addition, the current security threats of Ethereum havealso been analysed recently [20]. While all these analysesare very valuable for the community, they all focus on theprotocol security aspects and none of them evaluates the actualimplementation of the protocol.Eth2 consensus mechanism requires validators to lock ETHinto a deposit smart-contract, whose security is essential. Inorder to verify and increase the security of the deposit contract,formal verification of the Eth2 deposit contract has beendone [21]. This study does verify the implementation of thedeposit contract but not the Eth2 clients. While Eth1 clientshave also been analysed in the past [22], to the best of ourknowledge there is no a study showing the resource utilizationof Eth2 clients and what can be understood from it.V. C
ONCLUSION
In this work, we have performed a detailed analysis of theresource usage of Eth2 clients. Through this analysis, we havebeen able to notice the effort of different teams to developfunctional software in order to tackle the transitioning to Eth2.The necessity of relying on several types of clients is reflectedby the different objectives and resources of a broad varietyof users. Our analysis showed significant differences betweenclients in terms of CPU, memory and disk utilization. We alsoobserved some network perturbations where the number ofpeers dropped quickly and its impact on the other resources.To the best of our knowledge, this is the first study of the Eth2clients resource usage at this scale and to demonstrate that itis possible to detect traces of non-finality periods by simplylooking at the clients’ resource usage. The diverse behaviourof the analysed clients is a positive sign for the Ethereumcommunity, as it shows a solid variety of software availablefor Eth2 validators, and this provides the network with furtherdecentralization, resilience and security.As future work, we would like to further study how non-finality periods affect the resources usage of Eth2 clients, inorder to implement online detectors that use this informationto signal possible network perturbations in real time.8
CKNOWLEDGMENT
This work has been supported by the Ethereum Founda-tion under Grant FY20-0198. We would like to thank theresearchers of the Ethereum Foundation for their feedback andsuggestions. We would also like to thank the developers andresearchers of the five client teams for all their help to set upour 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/metricsmonitoring scripts.[5] “Logs parsing scripts:,” https://github.com/leobago/BSC-ETH2/tree/master/ETH2-clients-comparison/scripts/parsing scripts/client logsanalysis 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 august2020:,” https://docs.google.com/document/d/11RmitNRui10LcLCyoXY6B1INCZZKq30gEU6BEg3EWfk.[15] M. Bez, G. Fornari, and T. Vardanega, “The scalability challenge ofethereum: An initial quantitative analysis,” in , April2019, 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 InternetMeasurement 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 thedata availability problem for sharded ethereum,” in
Proceedingsof the 2nd Workshop on Scalable and Resilient Infrastructuresfor 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 onethereum 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 verificationof ethereum 2.0 deposit smart contract,” in
Computer Aided Verifica-tion , S. K. Lahiri and C. Wang, Eds. Cham: Springer InternationalPublishing, 2020, pp. 151–164.[22] S. Rouhani and R. Deters, “Performance analysis of ethereum transac-tions in private blockchain,” in , 2017, pp. 70–74., 2017, pp. 70–74.