Skip to content

Beacon chain simulator

Jump to bottom
Anton Nashatyrev edited this page Mar 11, 2019 · 24 revisions

A simulator is a tool that runs a standalone beacon chain instance with a number of assumptions and limitations. The main goal of simulator is to try beacon chain consensus algorithms executing in different circumstances like with a 100% honest validator set and some bad actors in it, network drops and delays. The other goal is to measure performance, check out bottlenecks and look for ways of design improvement and optimizations.

Parameters

There is a number of parameters affecting beacon chain runtime. Some of them are hard coded in the simulator but valuable consensus parameters are configurable by the user.

Built-in parameters

There is a set of immutable simulation parameters:

  • time - beacon chain time is driven by a routine called ControlledSchedulers which method addTime adds a slot to overall system time and processes all the events that correspond to this time slot; during simulation addTime is triggered by infinite loop adding 1 millisecond in each iteration.
  • thread model - all the system (including all peers asynchronous tasks) runs on a single main thread. This makes the simulator runs deterministic (with fixed random seed) and helps reproducing the same behaviour across different runs.
  • network - there is a special storage in memory that aids network simulation; attestations and blocks are simply propagated to all peers in the "network".
  • database - simulator doesn't store anything on disk, each time it starts with clean in-memory database.
  • eth1 chain - simulator starts with a set of initial validators defined by user, validator registration is not handled by simulation.

Configurable parameters

  • genesis-time - sets Genesis time in seconds using Unix timestamp notation.
  • seed - an integer number that will be used as a seed to generate credentials of initial validator set, if not specified random value will be used; setting this parameter preserves validator credentials between simulations. Taking into account the single-threaded model different runs with same seed should be absolutely identical.
  • bls-verify - whether BLS verification is enabled during simulation or not, disabled by default; this flag doesn't affect BLS signature creation, it only skips its verification part allowing simulation to run faster.
  • beacon chain parameters - values of beacon chain constants defined by the spec could be overridden.
  • peers - describes groups of peers with different behavior that are participating in simulation.

Peer groups

  • validator - a flag indicating whether this is a validator group or chain observers that passively imports the chain.
  • count - number of peers in the group.
  • blsPrivateKey - sets the specific validator key. count should be equal to 1 if this option is not null. null means the personal keypair will generated for each peer in this group
  • systemTimeShift - emulates system clock shift for this peer(s)
  • wireInboundDelay - emulates network lag of inbound messages for this peer(s)
  • wireOutboundDelay - emulates network lag of outbound messages for this peer(s)

This parameter list is going to be extended in the future versions to simulate network issues and dishonest validator actions.

Clone this wiki locally