Slasher Simulator

Background

Over the course of this quarter, we have redesigned our slasher to perform efficient slashing detection of blocks, double votes, and surround votes. Instead of having the slasher as a separate process from the beacon node, we now make it a service of the beacon node which can be toggled with a feature flag.

This new slasher has a really simple entrypoint: all it needs is a beaconDB and a feed of indexed attestations and beacon block headers. Anyone can send these items over their corresponding feed and slasher will be able to perform its job accordingly. That is:

package slasher

import (
	"time"

	"github.com/prysmaticlabs/prysm/beacon-chain/db"
	"github.com/prysmaticlabs/prysm/shared/event"
)

type SlasherConfig struct {
	IndexedAttsFeed        *event.Feed
	BeaconBlockHeadersFeed *event.Feed
	Database               db.Database
	GenesisTime            time.Time
}

func New(cfg *SlasherConfig) *Slasher {
    ...
}

Given this simple API, we can design a simulator which generates indexed attestations and beacon block headers of different kinds to profile and ensure that slasher works as expected. This document defines the requirements for such a simulator.

Goal

Our goal is to create a standalone binary which runs a slasher simulator and can allow us to profile the behavior of slasher as it would perform in a real node, helping us analyze disk i/o, CPU, and RAM usage in isolation. Additionally, we can also use a simulator to ensure that slasher can indeed detect slashable events. Eventually, we want the code for this simulator to make it into our end to end tests as a component.

Data Requirements

Double Block Proposals

In order to simulate block proposals, the only pieces of information slasher needs are:

• The block signing root
• The block slot
• The block proposer index

When performing double block checking, we simply check the DB if we have an existing proposal for a slot:proposer_index combination, and check if the signing roots are mismatched.

As such, the simulator need not be concerned about the details of blocks. If we can simply simulate the 3 pieces of information, that's enough for the slasher to detect.

Double Votes and Surround Votes

The only pieces of information slasher needs for attester slashing checks are:

• The att signing root
• The att attesting indices
• The att target epoch
• The att source epoch

Every other part of an attestation is unnecessary. To detect double votes, the slasher algorithm when receiving a package containing the 4 fields above, simply:

1. Loops over the attesting indices, for each:
   2. Check if we have an attestation at the target_epoch:validator_index combination
   3. If we do, we check if the signing roots are different, then return a slashable event. Otherwise, continue

As such, the generator need not be concerned with other fields of attestations, such as roots, slot, etc.

Surround votes are more complicated, but once again, slasher only needs the 4 fields above from an attestation in order to perform its duty.

Functional Requirements

• We want the ability to configure:

  • Genesis time
  • Num validators
  • Probabilities of creating double votes, surround votes, and double proposals
  • Percent aggregated attestations per slot (100% means we pack as many attesting indices as possible into a single slot, 0% means there is a single attestation per validator index throughout an epoch)

• We want the ability to profile this with –pprof. The simulator branch already has this ability