[go: up one dir, main page]
Open
Milestone started on Jul 3, 2024

Protocol agnostic baker

Context and Scope

Currently a baker binary is produced for each protocol. At migration between two protocols (P1 and P2), it forces users to run two bakers:

  • P1-baker to be able to bake/(pre)attest until migration, potentially bake the migration block
  • P2-baker to bake/(pre)attest after migration

This leads to very bad user experience. We continuously have to remind bakers of this and they have to adapt their infra for migration only. This is true for all networks, including weeklynet that starts with a migration and thus migrates once per week. This might lead to poor participation to this network.
Besides, this is error prone, it often occurs that bakers fail to run both bakers, or make mistakes and end up running twice the same baker, putting them at risk of double signing and being slashed.

Besides,  our monitoring tools only show the hash of the head commit used to compile the octez baker binary that baked the latest block of the baker. This gives too few information. In particular, it does not tell us the version of the node the baker is connected to, nor if the baker is running both binaries in case of a protocol migration. 

Goals and Non goals

Goals:

  • handle baker migration during protocol upgrade automatically
    • automatically start second baker before migration
    • automatically stops first baker after migration 
  • increase our confidence in baker infra, our knowledge on its running version of bakers/nodes
    • ensure both bakers are built using the right octez version
    • ensure they are able to handle migration correctly (using automatic migration tests)
    • increase confidence in the baking node version used by bakers
  • fully compatible with current baker command arguments

Non goals:

  • TBD

Stretch-goals:

  • Make the baker hypervisor a library for other octez-binaries to use

Future improvements (not to be done in this project):

  • Handle the baking node with the same hypervisor

Design

General design:

  • Checks node version, only starts if node version is high enough (can be bypassed with an option for tests and advanced users)
  • Wait to be bootstrapped
  • Start curr_baker based on protocol in head
  • Monitor new_heads and voting periods
  • Start next_baker in adoption period
  • Kill curr_baker after several blocks in new protocol

First implementation:

  • Build a binary that controls both existing baker binaries. 

Improvement:

  • Use a single binary that automatically forks processes for both bakers

Work breakdown - Phase 1 -- OUTDATED

  • Deliverable 1
  • Deliverable 2
    • Create a new binary that only starts a baker binary with the right parameters !14489 (closed)
    • (In a temporary branch for validation only) replace baker binaries in tezt with the new baker (keep the commit(s) for future tests)
    • Monitor heads and stop baker when enough blocks have been baked with a more recent protocol
    • Monitor voting periods and start a new baker when adoption period starts
  • Deliverable 3
    • Test (tezt) that migrations are handled correctly with the new agnostic baker handler
    • Add more tests for special cases (multiple bakers, with a remote signer, with a ledger etc.) The goal here is to be on par (or better) than with the current bakers
  • Deliverable 4 (to be refined)
    • Replace binary calls with process forks

Work breakdown - Phase 2

Share delegate cmd. line args amongst baker daemon -- Cancelled

  • Introduce a lib to factorise and shard baker command line arguments
    • Create a lib_delegate_config
    • Extract some Shared_args as done in lib_node_config
  • Assume that the delegates of every proto are sharing the same argos
  • Introduce some genericity to allow specific arguments for specific protocols
    • Implement a signature specific to one or several protocol environment
  • (Optional: generalise to the accuser)

Dummy agnostic baker (@vect0r)

  • Introduce a dummy agnostic baker (TZenbaker ?) that only spawn the alpha baker internally
  • Along to the running baker, add a daemon that monitors a node and displays period informations

Simple Agnostic baker (@vect0r)

  • Based on the daemon, spawn and stop baker right on time
  • Secure baker lifecycle by introducing a daemon that will restart crashed bakers
  • Plug the agnostic baker into Tezt

Consolidate agnostic baker (@gabriel.moise, @vch9, @vect0r)

Packaging + consolidation (@vch9)

Agnostic accuser (@gabriel.moise)

Risks:

  • Risks are very high here
  • It is likely to bring a lot of flakiness to Tezt
  • The handling of the remote signers/ledger is likely to bring unexpected behaviours