2.1 Overview

The first major update was to create a robust and scalable data backend. For the Medalla testnet, we collected the data ad-hoc in a data scraping procedure that extracted information from Beaconscan. For this update, we’ve built upon chaind to pull data directly from the Ethereum blockchain into a structured PostgreSQL database.

2.2 Technical Steps

For the technically curious, these are the exact steps we took to configure the above setup on our Ubuntu 20.04 analytics server.

1. Install a Beacon Node
   1. Supported Beacon Nodes are Teku, Prysm, and Lighthouse. For performance reasons, Teku is recommended.
   2. Full Teku installation instructions available at: https://docs.teku.consensys.net/en/latest/HowTo/Get-Started/Installation-Options/Install-Binaries/
   3. Latest binary release available at: https://github.com/ConsenSys/teku/releases
   4. Download the binary zip file
   5. Unzip the archive
2. Run a Beacon Node
   1. cd into the Teku folder (at the time of writing, the latest release is 21.3.2. So the command would be cd teku-21.3.2.
   2. cd into the bin folder
   3. Execute Teku in Data Storage Archive mode, with the REST API enabled: teku –rest-api-enabled –data-storage-mode=archive
   4. Teku will begin to sync the blocks and associated information from the Ethereum 2 Mainnet to the local machine. This process could take several hours. The current slot will indicate the most recent slot for Ethereum 2, while the head slot will indicated what the most recent slot synced is. For example, A sync that is about 5000 slots behind display logging along the lines of: 06:47:11.394 INFO - Sync Event *** Current slot: 922134, Head slot: 917151, Connected peers: 22
   5. Once, fully synced, the logs should show something along the lines of 06:53:51.163 INFO - Slot Event *** Slot: 922167, Block: fd9e45..5701, Epoch: 28817, Finalized checkpoint: 28815, Finalized root: 522dc6..a6b7, Peers: 42 . This is the indication that all blocks have been synced, and we can proceed by installing and running chaind to populate our PostgreSQL database.
3. Install PostgresSQL and configure an empty database
   1. The following instructions assume the use of Ubuntu 20.04. Full documentation on this and other platforms is available at: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-20-04
   2. Install the Postgres binary: sudo apt install postgresql postgresql-contrib
   3. Create a role for chaind: sudo -u postgres createuser –interactive Follow the prompts, naming the new user chaind
   4. Create a database for chaind: sudo -u postgres createdb chaind
   5. Login to the new database: sudo -u chaind psql
   6. Set the database password: ALTER USER user_name WITH PASSWORD ‘chaind’;
4. Install chaind
   1. The following instructions use the Go Source installation method. Full installation instructions are available at: https://github.com/wealdtech/chaind#source
   2. Install Go: sudo apt install golang-go
   3. Download chaind with Go: GO111MODULE=on go get github.com/wealdtech/chaind
5. Run chaind
   1. Change directory to the location of the chaind binary: cd ~/go/bin
   2. Execute the binary, providing both the Teku REST API url and the Postgres connection URL: chaind –chaindb.url=postgres://chaind:chaind@localhost:5432 –eth2client.address=localhost:5051
   3. The database synchronization will now take place. This could take several more hours.
6. Check the database sync progress
   1. Access the database: sudo -u chaind psql
   2. Check the metadata table: select * from t_metadata;
   3. The latest slot and block will be displayed, which can be compared with the Ethereum Mainnet to see the progress of the database sync

In Figure 2.1 our Teku Beacon node is catching up to the head slot. When it is complete, the data is available on the server for chaind to begin synchronization to the database.

Figure 2.1: Left: A Teku Beacon node synchronizing from the Ethereum blockchain to our server. Right: A Teku Beacon node synchronizing from the Ethereum blockchain to our server.

The tables in this database now contain the data needed to recreate our validator analysis. With some minor manipulation and joins of the raw data, we obtain a dataset that matches the original structure of the data collected from the Medalla testnet, which can be seen below:

3.1 Activated Validators over Time

The Ethereum network is configured to activate four validators per epoch. Interestingly, some epochs within the Medalla test phase activated more than 4 validators, but this has not happened on the current Beacon chain. The graphs do point out epochs within the current mainnet have on-boarded fewer than 4 validators.

During the last 3000 or so epochs, there have been a number of attestation periods that have had fewer than the standard 4 validators activated within them. This can be seen through the deviation of the line from its linear pattern.

3.2 Distribution of the Number of Block Assignments per Validator

Constant validator inflows and outflows on the Medalla testnet saw a significant number of nodes without any assignments. One of the first hints that we have that validators on the mainnet have been performing well has been the larger average number of assignments. The peak of the distribution for the mainnet on the right shows that many validators have been assigned to at least five attestations. As we continue to track this specific distribution, it is likely to begin to skew leftward as the early cohorts successfully validate blocks.

3.3 Assigned, Executed and Skipped

When we begin to look more deeply at the breakdown of the assignments, executions and skips across the blocks we see a similar pattern where the steady performance, and time on the network of the validators, have increased with the average number successful proposals per validator. We can also see that the number of skipped slots has decreased dramatically when comparing the shape of the distribution and the average number between the two networks.

3.4 Execution Rate

Given what we’ve seen above it is no surprise that the execution rate, as measured by the number of executed blocks over assigned blocks, is much closer to 100% for all active validators on the Ethereum 2.0 mainnet.

3.5 Skipped Rate

Likewise the skip rate, a measure of the number of blocks skipped divided by the number assigned, has plummeted which suggests that the validators are completing their attestation duties completely and correctly.

3.6 Distribution of Time to Exit

The time to exit distribution is still right-skewed, with most exiting quite early. However, since the launching of mainnet, most misconfigured nodes actually leave within the first 200 hours. A secondary cluster peak was found at 1500 hours, which motivated the following analysis that looks into the time series of validator exits.

3.7 Exiting Validators by Epoch

When looking at the exiting validators by epoch compared to the Medalla testnet, we can immediately see that validators have taken their job more seriously. Only 144 validators have exited in the over 31,000 epochs tracked since the Beacon chain’s inception. Curiously, there was a noticeable spike between 14,000 and 15,000.

3.8 Exiting Validators by Epoch - Cumulative

Like the Medalla chain, the Beacon chain experiences spikes in exits over relatively short periods of time. Here between the Epoch 14000 and 15000 bands, we went from slightly over 40 exited validators to a little more than 140. On a positive note, there are much longer periods of time where there are either no exits or very few per epoch.

3.9 Slashing Over Time

Much like the exits over time, the number of slashings appear to occur in bulk where, again, the majority of slashings occurred during February 1st through 6th (epochs 14,000 and 15,000). As it turns out, this was due to a double-signing mishap by a single staking provider.

All in all, the theme of validators generally performing better than was see on the Medalla testnet is prevalent through most of this analysis. We now turn our attention to deriving a new set of tiers based on the new data.