Finality provider
EOTS Manager component
Description
EOTS Manager is a secure key-management daemon in the Babylon finality protocol that manages extractable one-time signature (EOTS) keys. This component is responsible for generating, storing, and signing finality votes for the finality provider (FP). Through EOTS signatures, if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing.
Invariants
The EOTS Manager must commit only one public randomness per block height for each FP.
If an FP submits EOTSs for two different blocks at the same height, it must be possible to extract the private key.
Finality provider daemon component
Description
The finality provider daemon is a core component required for the operation of an FP in the Babylon Network. This daemon monitors the Babylon chain, submits finality votes, commits public randomness, and manages state transitions.
If an FP is in a Slashed or Jailed state, the daemon will automatically stop operation and support the unjailing process.
Invariants
The daemon must not run if the FP is in a
SlashedorJailedstate.It must ensure that no duplicate votes are submitted for any block.
Before submitting a finality vote, it must verify whether the block has already been finalized.
Public-randomness commits must not overlap with existing commits and must start immediately after the last committed block height.
During fast synchronization, previous blocks must be validated and signed sequentially.
Test coverage
Cases covered
E2E test, finality-provider life cycle — tests the full life cycle of a finality provider, including creation, registration, randomness commitment, BTC delegation, covenant signature submission, vote submission, and block finalization
E2E test, double-signing attack — simulates an equivocation attack where the finality provider submits a conflicting finality vote, triggering the extraction of its BTC private key and ensuring that slashed providers cannot restart
E2E test, fast sync process — tests the scenario where a finality provider is stopped and restarted after several blocks to validate the fast synchronization mechanism, ensuring the finalized block height remains consistent
Cases not covered
E2E test, multiple reorgs/multiple reboot cycles (fuzzing)
Fuzzing and E2E tests combined for more coverage
Attack surface
The following are available attack surfaces.
EOTS key theft. If the private key stored in the EOTS Manager is leaked, the FP's signatures may be compromised.
Public-randomness manipulation. An attacker could submit incorrect public randomness to disrupt the FP's block validation process.
Finality signature manipulation attack. An external attacker may attempt to trigger the FP to maliciously submit two signatures for the same block height.
RPC interface attack. The FP daemon's RPC interface may be vulnerable to DOS attacks, key-management abuse, or manipulation of the signing process.