again

just accrued rewards

under contro

block

similarly to

Ethereum 1

miners

is

on the above figure

the application of a block to the state on which it is built

from

of

information

block that immediately proceeds this one, and by

is then

ans

,

as mentioned above

of

,

graph

rewards

completed

carried out

TODO explicit color for this line.

in

spanning

when

contra

above

that for

The

highest amount of useful data

results

was carried out

effectiveness

are

Enough is different from 2020 to consider it worthwhile to re-evaluate

undre

,

easily see

Because this certificate can be considered confidential, Vouch supports the use of Majordomo to store the certificates

environment variables, command-line flags

tegies allow Vouch to be extensible

is available again

its

to best

to intelligently decide

No movement of keys,

requires

takes advantage of the optimizations carried out in beacon nodes to provide a fast and efficient validating experience that benefits from the existing diversity of beacon nodes

it reduces the potential for failure

as be more of

however validator clients only need to talk to their respective beacon nodes

other,

have to talk to

validator client over one provided by the client teams

or verifying the aggregation of

, a task that they want to carry out for service resiliency or client diversity purposes,

Another recent article evaluated the performance of beacon nodes in proposing blocks. It’s conclusion was that any of the beacon nodes examined would be a good choice, however there is still a choice to be made. A better answer would be “don’t choose”: use all of the beacon nodes to ensure diversity and increase reliability. How can Vouch achieve this?

independently decide which of the blocks presented it wants to sign

This avoids Vouch itself becoming a layer that requires diversity3, and in turn benefit from the existing diversity of beacon nodes.

considering beacon nodes untrusted entities regarding the data they provide

So what is to be gained by using a dedicated validator client over one provided by the client teams?

A dedicated validator client also addresses additional areas.

as users start to build their own staking infrastructures they understand that some of their operational requirements are hard to achieve using single-vendor codebases.

As has been mentioned above some of the scores could be artificially high due to lack of intelligent selection of the information included in the block.

What does this tell you

This provided a very brief look at a single aspect of beacon node performance.

An outstanding question is if

It can be seen that

Block proposal time distribution

as the validators were unaware of its existence

in

seemed to be

As a different approach, the scores for each node were summed across all slots to provide a different comparison:

each node’s

The obvious question to ask from the data is which node provides the best block proposals

in to

could contain

Some reasons why are

direct comparison of the results

proposer

attester

inclusion distance

he block given a score

At the beginning of each slot

Within the bounds of the available parameters

Attestant took a brief look

The beacon node is the piece of an Ethereum 2 infrastructure that forms the Ethereum 2 network

secrets management

overhead

ll configuration options are available through environment variables, command-line flags or a dedicated configuration file.

when configuring, running and monitoring.

Distributed key generation

Threshold signing is a powerful tool to provide high levels of availability.

,

to build a valid signature

, however the most important feature it provides is that a strict subset of Dirk instances can create a valid signature.

a single point

It can be seen that simply signing a proposal or attestation without slashing protection takes a couple of milliseconds. Adding in slashing protection increases these numbers, however the vast majority of the additional time is spent in ensuring that the protection is written safely to disk.

than running without slashing protection

allowing a “warm standby” configuration without having to worry about two validators running at the same time and generating slashable attestations.

describe

Here

[^Here, administrator means whomever is running the Dirk instance.]

it

stop

combination of information

running a service

.

keymanager

Clients that want to talk to Dirk over the network require a certificate that provides their identity before sending requests. The process is: the administrator2 generates a master certificate; the administrator generates client certificates and provides them to users; and users send their client certificates with requests.

Network access is good, but unrestricted network access is bad.

as new wallet support is added to Dirk

A wallet implementation could be software or hardware, standalone or distributed, and they are all supported with the same network call to Dirk.

Dirk provides access to different wallets without the user needing to know the particular type of wallet.

Why is a gateway necessary? Dirk provides a number of features that are not available if the wallet is on a local filesystem, and can provide higher security and availability than would be possible with such a configuration.

each feature is judged against the principles to see if it adds to or detracts from them: if it adds to them the feature is considered for inclusion,

if software is going to be part of a long-term infrastructure

Any fault in the validator client has a chance of exposing validating keys, but if the validator does not hold those keys it removes this risk.

It will be faster to restart in the case of a crash or server reboot, as it does not need to obtain and decrypt keys.

Although there are other keymanagers available,

both in and out of band

Access control to the key management features can easily be controlled

as if both are active at the same time it presents a slashing risk

If a server does not contain critical data it allows for a more flexible architecture.

A dedicated keymanager allows the validator to validate and the keymanager to manage keys. By dedicating Dirk to carrying out key management alone it is easier to manage, has lower code complexity, and is focused on doing its only job. This separation also forces a cleaner architecture, as all communication is carried out over interfaces between Dirk its own clients. This separation extends to the physical realm, where Dirk can run on its own server and serve multiple validator clients.

Most Ethereum 2 validator clients have key management built in to them, providing mechanisms to create keys and use them to attest. So why use a dedicated keymanager? There are a number of benefits that dedicated key management brings, some of which are outlined below.

A previous article discussed the protection of Ethereum 2 validator keys. It described a configuration that provided both security and availability, with threshold signing and distributed key generation. Details of these systems, why they are important and what they provide, are in the previous article, however it did not discuss an implementation that provides this functionality. This article introduces Dirk, a distributed remote keymanager1 that provides these features suitable for a production Ethereum 2 infrastructure.

We are excited to share further metrics

find

there is nothing an attesting validator can do to force inclusion by a block-producing validator.

a large number of validators

validators

included

are

As a balance

had

attesting

attestation

aggregation

chain head

Of specific interest for the purposes of this paper is the chain head vote

in

To measure its performance, attestations included on the Ethereum 2 blockchain are tracked by Attestant.

puts security of customer funds first and foremost. Notwithstanding this, it carries out various advanced validating strategies to provide customers with higher rewards than would be possible with traditional validating infrastructures

(node, cluster and full network)

although block production is expected it is not required

an aggregator receives an attestation in time to integrate it into the aggregated attestation before broadcasting

the aggregator broadcasts an aggregated attestation for block producers to include

Once a validator has generated an attestation it needs to propagate it across the network so it is available for the next block producer to include

the information in the attestation is more useful to the network the sooner it is presented

An arbitrary subset of attesting validators will also be assigned to carry out aggregation duties. Such validators are known as aggregators.

This provides a very efficient way of storing many attestations, however does add to the communications and computation burden (more on this below)

has two major changes from an attestation

chain it is important to reduce it if possible

whose structure of an attestation is shown below

Attestant tracks when attestations are included on the Ethereum 2 blockchain

In order to achieve this

maximizing

A fully protected validator key will take all of these areas, and more, in to account.

requirements

obtaining it

ha

If you have multiple validator keys should they have some sort of relationship, to either each other or to their respective withdrawal keys? Doing so brings no security benefit; if it brings an ease-of-use benefit is up to the individual user to decide. The discussion in the (previous article)[../protecting-withdrawal-keys/] may help the user to decide what they want to do in this situation.

Some sort of backup strategy should be put in place

remote storage

only those allowed to can access the keys

there could be an ease of use benefit

The article discusses remote storage of passphrases

some of which are touched on here.

Security is a very broad area, and the above information is provided to explain the features and benefits rather than define any sort of perfect, or even best, solution.

key generation

process,

the old keys

be

does

he weakness of the long-term attack if one of the servers is compromised remains

down fo

key managers

We use the term key manager as the remote servers now carry out more operations than just signing

starts

generation.

where

Keys

remote signer

private

the user is still able to sign undesirable messages

layer.

protection.

it.

,

representation.

As mentioned above, a simple scale of security against accessibility is of no use when both are required. Instead,

First

What is the validator key?

It can immediately be seen that

are very high

such as blackmail