diff --git a/CHANGELOG.md b/CHANGELOG.md index 547ab568..781789fa 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -89,6 +89,8 @@ finality vote submission * [#117](https://github.com/babylonlabs-io/finality-provider/pull/117) Spec of commit public randomness +* [#130](https://github.com/babylonlabs-io/finality-provider/pull/130) Finality +Provider operation documentation ### Bug Fixes diff --git a/README.md b/README.md index 4d10096d..02c15a35 100644 --- a/README.md +++ b/README.md @@ -1,119 +1,140 @@ # Finality Provider -A toolset crafted for the creation and -management of Finality Providers. +Finality providers are key participants in the Babylon BTC staking protocol. +They provide finality votes on top of +[CometBFT](https://github.com/cometbft/cometbft), Babylon's consensus mechanism, +and earn commissions from BTC staking delegations. + +The finality provider toolset operates on standard UNIX-based +systems and consists of three core components: + +1. **Babylon Node**: +A Babylon network node that provides chain data and transaction +submission capabilities. While not mandatory, running your own node is +strongly recommended for security rather than relying on third-party RPC nodes. +See the [Setup Node Guide](https://github.com/babylonlabs-io/networks/tree/main/bbn-5/babylon-node) +for details. +2. **Extractable One-Time Signature (EOTS) Manager**: +A secure key management daemon that handles EOTS key operations, +generates extractable one-time signatures, and produces public randomness. +For enhanced security, this component should run on a separate machine or +network segment. +3. **Finality Provider Daemon**: +The core daemon that polls Babylon blocks, commits public randomness, and +submits finality signatures. It manages the finality provider's status transitions +and handles rewards distribution. + +**Component Interactions**: +The Finality Provider daemon communicates with the Babylon Node to monitor blocks +and submit transactions. It interacts with the EOTS Manager for signature and +randomness generation. The EOTS Manager maintains secure key storage and handles +all EOTS key operations. + +![Finality Provider Architecture Diagram](./docs/static/finality-provider-arch.png) + +## Become a Finality Provider + +For instructions on creating and operating a finality provider, +see our [Finality Provider Guide](./docs/finality-provider-operation.md). + +## High Level Descriptions of EOTS and Finality Provider + + +### EOTS Manager + +The EOTS daemon is responsible for managing EOTS keys, producing EOTS randomness, and +using them to produce EOTS signatures. + +> ⚡ **Note:** EOTS stands for Extractable One Time Signature. You can read more about it +in +the [Babylon BTC Staking Litepaper](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf). +In short, the EOTS manager generates EOTS public/private randomness pairs. The +finality provider commits the public part of these pairs to Babylon for every future +block height that they intend to provide a finality signature for. If the finality +provider votes for two different blocks on the same height, they will have to reuse +the same private randomness which will lead to their EOTS private key being +exposed, leading to the slashing. + +Once a finality provider is double-signs, their voting power is immediately reduced +to zero, while their private key is exposed. A finality provider that double-signs +can never regain voting power (tombstoning). Additionally, the exposed private key +of the finality provider can be used to fully sign the slashing transactions of all +their stake delegations. + +The EOTS manager is responsible for the following operations: + +1. **EOTS Key Management:** + - Generates [Schnorr](https://en.wikipedia.org/wiki/Schnorr_signature) key pairs + for a given finality provider using the + [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) + standard as its EOTS key pair + - Persists generated key pairs in the internal Cosmos keyring. +2. **Randomness Generation:** + - Generates lists of EOTS randomness pairs based on the EOTS key, chain ID, and + block height. + - The randomness is deterministically generated and tied to specific parameters. +3. **Signature Generation:** + - Signs EOTS using the private key of the finality provider and the corresponding + secret randomness for a given chain at a specified height. + - Signs Schnorr signatures using the private key of the finality provider. + +### Finality Provider + +The Finality Provider Daemon is responsible for monitoring for new Babylon blocks, +committing public randomness for the blocks it intends to provide finality signatures +for, and submitting finality signatures. + +The daemon can manage multiple finality providers but only run a single +finality provider instance at a time performing the following operations: + +1. **Creation and Registration**: Creates and registers a finality provider to. + +2. **EOTS Randomness Commitment**: The daemon monitors the Babylon chain and commits + EOTS public randomness for every Babylon block the finality provider intends to + vote for. The commit intervals can be specified in the configuration. + +3. **Finality Votes Submission**: The daemon monitors the Babylon chain and produces + finality votes for each block the finality provider has committed to vote for. + +4. **Status Management**: The daemon continuously monitors voting power and overall + provider status. It manages state transitions between `ACTIVE`, `INACTIVE`, + `JAILED`, and `SLASHED` states, while handling the jailing process when violations + occur. + +5. **Security and Key Management**: The daemon manages Babylon keys for signing + transactions and rewards distribution. It maintains secure coordination with + the EOTS daemon for all key-related operations. + +The daemon is controlled by the `fpd` tool, which provides commands for +interacting with the running daemon. + +## Technical Documentation + +For detailed technical information about the finality provider's internal operations, see: +* [Core Heuristics](./docs/fp-core.md) +* [Public Randomness Commits](./docs/commit-pub-rand.md) +* [Finality Votes submission](./docs/send-finality-vote.md) + +## Overview of Keys for Finality Provider and EOTS Manager + +There are two distinct keys you'll be working with: + +- **EOTS Key**: + - Used for generating EOTS signatures, Schnorr signatures, and randomness pairs + - This serves as the unique identifier for the finality provider + - It's derived from a Bitcoin private key, using the secp256k1 + elliptic curve. + - Stored in the EOTS manager daemon's keyring + - This key is used in the Bitcoin-based security model of Babylon. + +- **Babylon Key**: + - Used for signing transactions on Babylon. + - Associated with a Babylon account that receives rewards + - Stored in the finality provider daemon's keyring -## 1. Overview - -Finality providers are responsible for voting -at a finality round on top of [CometBFT](https://github.com/cometbft/cometbft). -Similar to any native PoS validator, -a finality provider can receive voting power delegations from BTC stakers, and -can earn commission from the staking rewards denominated in Babylon tokens. -The core logic of a finality provider instance can be found in -[Finality Provider Core](./docs/fp-core.md). - -The finality provider toolset does not have -any special hardware requirements -and can operate on standard mid-sized machines -running a UNIX-flavored operating system. -It consists of the following programs: - -- *Babylon full node*: An instance of a Babylon node connecting to - the Babylon network. Running one is not a strict requirement, - but it is recommended for security compared to trusting a third-party RPC node. -- *Extractable One-Time Signature (EOTS) manager*: - A daemon responsible for securely maintaining the finality provider’s - private key and producing extractable one time signatures from it. -- *Finality Provider*: A daemon managing the finality provider. - It connects to the EOTS manager to generate EOTS public randomness and - finality votes for Babylon blocks, which it submits to Babylon through - the node connection. - -The following graphic demonstrates the interconnections between the above programs: - -![Finality Provider Interconnections](./docs/finality-toolset.png) - -## 2. Installation - -### Prerequisites - -This project requires Go version 1.23 or later. - -Install Go by following the instructions on -the [official Go installation guide](https://golang.org/doc/install). - -### Downloading the code - -To get started, clone the repository to your local machine from Github: - -```bash -git clone https://github.com/babylonlabs-io/finality-provider.git -``` - -You can choose a specific version from -the [official releases page](https://github.com/babylonlabs-io/finality-provider/releases) - -```bash -cd finality-provider # cd into the project directory -git checkout -``` - -### Building and installing the binary - -At the top-level directory of the project - -```bash -make install -``` - -The above command will build and install the following binaries to -`$GOPATH/bin`: - -- `eotsd`: The daemon program for the EOTS manager. -- `fpd`: The daemon program for the finality-provider with overall commands. - -If your shell cannot find the installed binaries, make sure `$GOPATH/bin` is in -the `$PATH` of your shell. Usually these commands will do the job - -```bash -export PATH=$HOME/go/bin:$PATH -echo 'export PATH=$HOME/go/bin:$PATH' >> ~/.profile -``` - -## 3. Setting up a finality provider - -### 3.1. Setting up a Babylon Full Node - -Before setting up the finality provider toolset, -an operator must ensure a working connection with a Babylon full node. -It is highly recommended that operators run their own node to avoid -trusting third parties. Instructions on how to set up a full Babylon node -can be found in -[the Babylon documentation](https://docs.babylonchain.io/docs/user-guides/btc-staking-testnet/setup-node). - -### 3.2. Setting up the EOTS Manager - -After a node and a keyring have been set up, -the operator can set up and run the -Extractable One Time Signature (EOTS) manager daemon. -A complete overview of the EOTS manager, its operation, and -its configuration options can be found in the -[EOTS Manager page](docs/eots.md) - -### 3.3. Setting up a Finality Provider - -The last step is to set up and run -the finality daemon. -A complete overview of the finality daemon, its operation, and -its configuration options can be found in the -[Finality page](docs/finality-provider.md). - -## 4. Delegations & Rewards - -A finality provider receives BTC delegations through delegators -interacting with Babylon and choosing it as the recipient of their delegations. -To perform a self-delegation, -the operator can either visit the staking web app we provide, -or run the Babylon [BTC Staker program](https://github.com/babylonlabs-io/btc-staker) once. -The BTC staker connects to a Bitcoin wallet and Babylon to perform delegations. +This dual association allows the finality provider to interact with both the +Bitcoin network (for security) and the Babylon network (for rewards and +governance). + +Once a finality provider is created, neither key can be rotated or changed - +they are permanently associated with that specific finality provider instance. diff --git a/docs/eots.md b/docs/eots.md deleted file mode 100644 index 8b20cb03..00000000 --- a/docs/eots.md +++ /dev/null @@ -1,188 +0,0 @@ -# EOTS Manager - -## 1. Overview - -The EOTS daemon is responsible for managing EOTS keys, producing EOTS randomness, and -using them to produce EOTS signatures. - -**Note:** EOTS stands for Extractable One Time Signature. You can read more about it -in -the [Babylon BTC Staking Litepaper](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf). -In short, the EOTS manager produces EOTS public/private randomness pairs. The -finality provider commits the public part of these pairs to Babylon for every future -block height that they intend to provide a finality signature for. If the finality -provider votes for two different blocks on the same height, they will have to reuse -the same private randomness which will lead to their underlying private key being -exposed, leading to the slashing of them and all their delegators. - -The EOTS manager is responsible for the following operations: - -1. **EOTS Key Management:** - - Generates [Schnorr](https://en.wikipedia.org/wiki/Schnorr_signature) key pairs - for a given finality provider using the - [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) - standard. - - Persists generated key pairs in the internal Cosmos keyring. -2. **Randomness Generation:** - - Generates lists of EOTS randomness pairs based on the EOTS key, chainID, and - block height. - - The randomness is deterministically generated and tied to specific parameters. -3. **Signature Generation:** - - Signs EOTS using the private key of the finality provider and the corresponding - secret randomness for a given chain at a specified height. - - Signs Schnorr signatures using the private key of the finality provider. - -The EOTS manager functions as a daemon controlled by the `eotsd` tool. - -## 2. Configuration - -The `eotsd init` command initializes a home directory for the EOTS manager. This -directory is created in the default home location or in a location specified by -the `--home` flag. - -```bash -eotsd init --home /path/to/eotsd/home/ -``` - -After initialization, the home directory will have the following structure - -```bash -ls /path/to/eotsd/home/ - ├── eotsd.conf # Eotsd-specific configuration file. - ├── logs # Eotsd logs -``` - -If the `--home` flag is not specified, then the default home location will be used. -For different operating systems, those are: - -- **MacOS** `~/Users//Library/Application Support/Eotsd` -- **Linux** `~/.Eotsd` -- **Windows** `C:\Users\\AppData\Local\Eotsd` - -## 3. Keys Management - -Handles the keys for EOTS. - -### 3.1. Create EOTS Keys - -The binary `eotsd` has the option to add a new key to the keyring for -later usage with signing EOTS and Schnorr signatures. Keep in mind -that new keys can be created on demand by the GRPC call from `fpd`. -But, if you would like to add a new EOTS key manually, run `eotsd keys add`. - -This command has several flag options: - -- `--home` specifies the home directory of the `eotsd` in which -the new key will be stored. -- `--key-name` mandatory flag and identifies the name of the key to be generated. -- `--passphrase` specifies the password used to encrypt the key, if such a -passphrase is required. -- `--hd-path` the hd derivation path of the private key. -- `--keyring-backend` specifies the keyring backend, any of `[file, os, kwallet, test, pass, memory]` -are available, by default `test` is used. -- `--recover` indicates whether the user wants to provide a seed phrase to recover -the existing key instead of randomly creating. - -```shell -eotsd keys add --home /path/to/eotsd/home/ --key-name my-key-name --keyring-backend file - -Enter keyring passphrase (attempt 1/3): -... - -2024-04-25T17:11:09.369163Z info successfully created an EOTS key {"key name": "my-key-name", "pk": "50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383"} -New key for the BTC chain is created (mnemonic should be kept in a safe place for recovery): -{ - "name": "my-key-name", - "pub_key_hex": "50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383", - "mnemonic": "bad mnemonic private tilt wish bulb miss plate achieve manage feel word safe dash vanish little miss hockey connect tail certain spread urban series" -} -``` - -> Store the mnemonic in a safe place. With the mnemonic only it is possible to -recover the generated keys by using the `--recover` flag. - -### 3.2. Recover Keys - -To recover the keys from a mnemonic, run: - -```shell -eotsd keys add --home /path/to/eotsd/home/ --key-name my-key-name --keyring-backend file --recover - -> Enter your mnemonic -bad mnemonic private tilt wish bulb miss plate achieve manage feel word safe dash vanish little miss hockey connect tail certain spread urban series -2024-04-25T17:13:29.681324Z info successfully created an EOTS key {"key name": "my-key-name", "pk": "50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383"} -New key for the BTC chain is created (mnemonic should be kept in a safe place for recovery): -{ - "name": "my-key-name", - "pub_key_hex": "50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383", - "mnemonic": "noise measure tuition inform battle swallow slender bundle horn pigeon wage mule average bicycle claim solve home swamp banner idle chapter surround edit gossip" -} -``` - -You will be prompted to provide the mnemonic on key creation. - -### 3.3. Sign Schnorr Signatures - -You can use your key to create a Schnorr signature over arbitrary data -through the `eotsd sign-schnorr` command. -The command takes as an argument the file path, hashes the file content using -sha256, and signs the hash with the EOTS private key in Schnorr format by the -given `key-name` or `eots-pk`. If both flags `--key-name` and `--eots-pk` are -provided, `eots-pk` takes priority. - -```shell -eotsd sign-schnorr /path/to/data/file --home /path/to/eotsd/home/ --key-name my-key-name --keyring-backend file -{ - "key_name": "my-key-name", - "pub_key_hex": "50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383", - "signed_data_hash_hex": "b123ef5f69545cd07ad505c6d3b4931aa87b6adb361fb492275bb81374d98953", - "schnorr_signature_hex": "b91fc06b30b78c0ca66a7e033184d89b61cd6ab572329b20f6052411ab83502effb5c9a1173ed69f20f6502a741eeb5105519bb3f67d37612bc2bcce411f8d72" -} -``` - -### 3.4. Verify Schnorr Signatures - -You can verify the Schnorr signature signed in the previous step through -the `eptsd veify-schnorr-sig` command. -The command takes as an argument the file path, hashes the file content using -sha256 to generate the signed data, and verifies the signature from the `--signature` -flag using the given public key from the `--eots-pk` flag. -If the signature is valid, you will see `Verification is successful!` in the output. -Otherwise, an error message will be printed out. - -```shell -eotsd verify-schnorr-sig /path/to/data/file --eots-pk 50b106208c921b5e8a1c45494306fe1fc2cf68f33b8996420867dc7667fde383 \ ---signature b91fc06b30b78c0ca66a7e033184d89b61cd6ab572329b20f6052411ab83502effb5c9a1173ed69f20f6502a741eeb5105519bb3f67d37612bc2bcce411f8d72 \ ---keyring-backend file -``` - -## 4. Starting the EOTS Daemon - -You can start the EOTS daemon using the following command: - -```bash -eotsd start --home /path/to/eotsd/home -``` - -If the `--home` flag is not specified, then the default home location will be used. - -This will start the EOTS rpc server at the address specified in `eotsd.conf` under -the `RpcListener` field, which is by default set to `127.0.0.1:12582`. You can change -this value in the configuration file or override this value and specify a custom -address using the `--rpc-listener` flag. - -```bash -eotsd start - -2024-02-08T17:59:11.467212Z info RPC server listening {"address": "127.0.0.1:12582"} -2024-02-08T17:59:11.467660Z info EOTS Manager Daemon is fully active! -``` - -All the available cli options can be viewed using the `--help` flag. These options -can also be set in the configuration file. - -**Note**: It is recommended to run the `eotsd` daemon on a separate machine or -network segment to enhance security. This helps isolate the key management -functionality and reduces the potential attack surface. You can edit the -`EOTSManagerAddress` in the configuration file of the finality provider to reference -the address of the machine where `eotsd` is running. diff --git a/docs/finality-provider-operation.md b/docs/finality-provider-operation.md new file mode 100644 index 00000000..35f72d91 --- /dev/null +++ b/docs/finality-provider-operation.md @@ -0,0 +1,668 @@ +# Finality Provider Operation + +This document guides operators through the complete +lifecycle of running a finality provider, including: + +* Installing and configuring the finality provider toolset + (EOTS Manager and Finality Provider daemon) +* Managing keys (EOTS key for signatures and Babylon key for rewards) +* Registering your finality provider on the Babylon network +* Operating and maintaining your finality provider +* Collecting rewards + +This is an operational guide intended for technical finality provider administrators. +For conceptual understanding, see our [Technical Documentation](./docs/fp-core.md). +Please review the [high-level explainer](./README.md) before proceeding to +gain an overall understanding of the finality provider. + +## Table of Contents + +1. [A note about Phase-1 Finality Providers](#1-a-note-about-phase-1-finality-providers) +2. [Install Finality Provider Toolset](#2-install-finality-provider-toolset) +3. [Setting up the EOTS Daemon](#3-setting-up-the-eots-daemon) + 1. [Initialize the EOTS Daemon](#31-initialize-the-eots-daemon) + 2. [Add an EOTS Key](#32-add-an-eots-key) + 1. [Create an EOTS key](#321-create-an-eots-key) + 2. [Import an existing EOTS key](#322-import-an-existing-eots-key) + 3. [Starting the EOTS Daemon](#33-starting-the-eots-daemon) +4. [Setting up the Finality Provider](#4-setting-up-the-finality-provider) + 1. [Initialize the Finality Provider Daemon](#41-initialize-the-finality-provider-daemon) + 2. [Add key for the Babylon account](#42-add-key-for-the-babylon-account) + 3. [Configure Your Finality Provider](#43-configure-your-finality-provider) + 4. [Starting the Finality Provider Daemon](#44-starting-the-finality-provider-daemon) +5. [Finality Provider Operation](#5-finality-provider-operations) + 1. [Create Finality Provider](#51-create-finality-provider) + 2. [Register Finality Provider](#52-register-finality-provider) + 3. [Withdrawing Rewards](#53-withdrawing-rewards) + 4. [Jailing and Unjailing](#54-jailing-and-unjailing) + 5. [Slashing](#55-slashing) + +## 1. A note about Phase-1 Finality Providers + +Thank you for participating in the first phase of the Babylon launch. This guide +provides instructions for setting up the full finality provider toolset required +for your participation in the second phase of the Babylon launch. + +Finality providers that received delegations on the first phase of the launch +are required to transition their finality providers to the second phase +using the same EOTS key that they used and registered with during Phase-1. +The usage of a different key corresponds to setting up an entirely +different finality provider which will not inherit the Phase-1 delegations. +Not transitioning your Phase-1 finality provider prevents your Phase-1 delegations +from transitioning to the second phase. + +If you already have set up a key during Phase-1, please proceed to +[Adding Keys](#32-add-an-eots-key) to import your Phase-1 key. + +## 2. Install Finality Provider Toolset + + +The finality provider toolset requires Golang 1.23](https://go.dev/dl) +to be installed. +Please follow the installation instructions [here](https://go.dev/dl). +You can verify the installation with the following command: + +```shell +go version +``` + +### 2.1. Clone the Finality Provider Repository + +Subsequently, clone the finality provider +[repository](https://github.com/babylonlabs-io/finality-provider) and navigate +to the `bbn-test-5` tag. + + +```shell +git clone https://github.com/babylonchain/finality-provider.git +cd finality-provider +git checkout +``` + +### 2.2. Install Finality Provider Toolset Binaries + +Run the following command to build the binaries and +install them to your `$GOPATH/bin` directory: + +```shell +make install +``` + +This command will: +- Build and compile all Go packages +- Install binaries to `$GOPATH/bin`: + - `eotsd`: EOTS manager daemon + - `fpd`: Finality provider daemon +- Make commands globally accessible from your terminal + +### 2.3. Verify Installation + +Run the following command to verify the installation: + +```shell +fpd version +``` + +The expected output should be: + +```shell +# example output +version: v0.11.0 +commit: 7d37c88e9a33c0b6a86614f743e9426ce6e31d4a +``` + +If your shell cannot find the installed binaries, make sure `$GOPATH/bin` is in +the `$PATH` of your shell. Use the following command to add it to your profile +depending on your shell. + +```shell +echo 'export PATH=$HOME/go/bin:$PATH' >> ~/.profile +``` + +## 3. Setting up the EOTS Daemon + +The EOTS manager daemon is a core component of the finality provider +stack responsible for managing your EOTS keys and producing EOTS signatures +to be used for votes. In this section, we are going to go through +its setup and key generation process. + +### 3.1. Initialize the EOTS Daemon + +If you haven't already, initialize a home directory for the EOTS Manager +with the following command: + +```shell +eotsd init --home +``` + +If `eotsd.conf` already exists `init` will not succeed, if the operator wishes to +overwrite the config file they need to use `--force`. + +Parameters: +- `--home`: Directory for EOTS Manager configuration and data + - Default: `DefaultEOTSDir` the default EOTS home directory: + - `C:\Users\\AppData\Local\ on Windows` + - `~/.eotsd` on Linux + - `~/Library/Application Support/Eotsd` on MacOS + - Example: `--home ./eotsHome` + +### 3.2. Add an EOTS Key + +This section explains the process of setting up the private keys for the +EOTS manager. Operators *must* create an EOTS key before starting the +EOTS daemon. + +We will be using the [Cosmos SDK](https://docs.cosmos.network/v0.50/user/run-node/keyring) +backends for key storage. + +Since this key is accessed by an automated daemon process, it must be stored +unencrypted on disk and associated with the `test` keyring backend. +This ensures that we can access the eots keys when requested to promptly submit +transactions, such as block votes and public randomness submissions that are +essential for its liveness and earning of rewards. + +If you already have an existing key from Phase-1, proceed to +[Import an existing EOTS key](#321-import-an-existing-eots-key) + +#### 3.2.1. Create an EOTS key + +If you have not created an EOTS key, +use the following command to create a new one: + +``` shell +eotsd keys add --home --keyring-backend test +``` + +Parameters: +- ``: Name for your EOTS key (e.g., "eots-key-1"). We do not allow +the same `keyname` for an existing keyname. +- `--home`: Path to your EOTS daemon home directory (e.g., "~/.eotsHome") +- `--keyring-backend`: Type of keyring storage (`test`) + +The command will return a JSON response containing your EOTS key details: + +``` +{ + "name": "eots", + "pub_key_hex": + "e1e72d270b90b24f395e76b417218430a75683bd07cf98b91cf9219d1c777c19", + "mnemonic": "parade hybrid century project toss gun undo ocean exercise + figure decorate basket peace raw spot gap dose daring patch ski purchase + prefer can pair" +} +``` + +> **🔒 Security Tip**: The mnemonic phrase must be stored securely and kept private. +> It is the only way to recover your EOTS key if you lose access to it and +> if lost it can be used by third parties to get access to your key. + +#### 3.2.2. Import an existing EOTS key + +> ⚡ This section is for Finality Providers who already possess an EOTS key. +> If you don't have keys or want to create new ones, you can skip this section. + +There are 3 supported methods of loading your existing EOTS keys: +1. using a mnemonic phrase +2. importing the `.asc` file +3. importing a backed up home directory + +We have outlined each of these three paths for you below. + +#### Option 1: Using your mnemonic phrase + +If you are using your mnemonic seed phrase, use the following command to import +your key: + +```shell +eotsd keys add --home --recover --keyring-backend test +``` + +You'll be prompted to enter: +1. Your BIP39 mnemonic phrase (24 words) +2. HD path (optional - press Enter to use the default) + +> ⚡ The HD path is optional. If you used the default path when creating your key, +you can skip this by pressing `Enter` , which by default uses your original private +key. + +#### Option 2: Using your `.asc` file + +If you exported your key to a `.asc` file. The `.asc` file should be in the +following format: + +``` +-----BEGIN TENDERMINT PRIVATE KEY----- +salt: 35ED0BBC00376EC7FC696838F34A7C36 +type: secp256k1 +kdf: argon2 + +8VOGhpuaZhTPZrKHysx24OhaxuBhVnKqb3WcTwJY+jvfNv/EJRoqmrHZfCnNgd13 +VP88GFE= +=D87O +-----END TENDERMINT PRIVATE KEY----- +``` + +To load the key, use the following command: + +```shell +eotsd keys import --home --keyring-backend test +``` + +#### Option 3: Using a File System Backup + +If you backed up your entire EOTS home directory, +you can load it manually to the machine you intend to operate +the EOTS daemon on and specify its location as the `--home` argument. + +#### Verify the Key Import + +After importing, you can verify that your EOTS key was successfully loaded: + +```shell +eotsd keys list --home --keyring-backend test +``` + +Parameters: +* ``: Name of the EOTS key to verify +* `--keyring-backend`: Type of keyring backend to use (`test`) +* `--home`: Directory containing EOTS Manager configuration and data + +You should see your EOTS key listed with the correct details, confirming that +it has been imported correctly. + +> ⚠️ **Important**: +> If you are a finality provider transitioning your stack from Phase-1, +> make sure that you are using the same EOTS key that you +> registered in Phase-1. + +### 3.3. Starting the EOTS Daemon + +To start the EOTS daemon, use the following command: + +```shell +eotsd start --home +``` + +This command starts the EOTS RPC server at the address specified in `eotsd.conf` +under the `RPCListener` field (default: `127.0.0.1:12582`). You can override +this value by specifying a custom address with the `--rpc-listener` flag. + +```shell +2024-10-30T12:42:29.393259Z info Metrics server is starting +{"addr": "127.0.0.1:2113"} +2024-10-30T12:42:29.393278Z info RPC server listening{"address": "127.0.0.1:12582"} +2024-10-30T12:42:29.393363Z info EOTS Manager Daemon is fully active! +EOTS Manager Daemon is fully active! +``` + +>**🔒 Security Tip**: +> * `eotsd` holds your private keys which are used for signing +> * operate the daemon in a separate machine or network segment +> with enhanced security +> * only allow access to the RPC server specified by the `RPCListener` +> port to trusted sources. You can edit the `EOTSManagerAddress` in +> the configuration file of the finality provider to +> reference the address of the machine where `eotsd` is running + +## 4. Setting up the Finality Provider + +### 4.1. Initialize the Finality Provider Daemon + +To initialize the finality provider daemon home directory, +use the following command: + +```shell +fpd init --home +``` + +If `fpd.conf` already exists `init` will not succeed, if the operator wishes to +overwrite the config file they need to use `--force`. + + +> ⚡ Running this command may return the message +> `service injective.evm.v1beta1.Msg does not have cosmos.msg.v1.service proto annotation`, +> which is expected and can be ignored. + +### 4.2. Add key for the Babylon account + +Each finality provider maintains a Babylon keyring containing +an account used to receive BTC Staking reward commissions and pay fees for +transactions necessary for the finality provider's operation. + +Since this key is accessed by an automated daemon process, it must be stored +unencrypted on disk and associated with the `test` keyring backend. +This ensures that the finality provider daemon can promptly submit +transactions, such as block votes and public randomness submissions that are +essential for its liveness and earning of rewards. + +For the `fpd` keyring, the `test` backend will be exclusively used, and it is +mandatory that you follow this practice until automated key management becomes +available. Additionally, we are also exploring options to support different +withdrawal addresses, so that rewards can go to a separate address. + +It is also important to note that the finality provider daemon will refund +fees for the submission of valid votes as those are essential for the protocol. +All other transactions, will require gas, but will be happening infrequently +or only once. As this keyring is used for both earning and +operational purposes, we strongly recommend maintaining only the necessary +funds for operations in the keyring, and extracting the rest into +more secure locations. + +> ⚠️ **Important**: +> To operate your Finality Provider, ensure your Babylon account is funded. +> Block vote transactions have their gas fees refunded, but public randomness +> submissions require gas payments. For testnet, you can obtain funds from our +> testnet faucet. + +Use the following command to add the Babylon key for your finality provider: + +```shell +fpd keys add --keyring-backend test --home +``` + +The above `keys add` command will create a new key pair and store it in your keyring. +The output should look similar to the one below: + +``` json +{ + "address": "bbn19gulf0a4yz87twpjl8cxnerc2wr2xqm9fsygn9", + "name": "finality-provider", + "pubkey": { + "@type": "/cosmos.crypto.secp256k1.PubKey", + "key": "AhZAL00gKplLQKpLMiXPBqaKCoiessoewOaEATKd4Rcy" + }, + "type": "local" +} +``` + +### 4.3. Configure Your Finality Provider + +Edit the `fpd.conf` file in your finality provider home directory with the +following parameters: + +```shell +[Application Options] +EOTSManagerAddress = 127.0.0.1:12582 +RPCListener = 127.0.0.1:12581 + +[babylon] +Key = # the key you used above +ChainID = bbn-test-5 # chain ID of the Babylon chain +RPCAddr = http://127.0.0.1:26657 +GRPCAddr = https://127.0.0.1:9090 +KeyDirectory = # The `--home` path to the directory where the keyring is stored +``` + +> ⚠️ **Important**: Operating a finality provider requires a connection to a +> Babylon blockchain node. It is **highly recommended** to operate your own +> Babylon full node instead of relying on third parties. You can find +> instructions on setting up a Babylon node +> [here](https://github.com/babylonlabs-io/networks/tree/main/bbn-test-5/babylon-node/README.md). + +Configuration parameters explained: +* `EOTSManagerAddress`: Address where your EOTS daemon is running +* `RPCListener`: Address for the finality provider RPC server +* `Key`: Your Babylon key name from Step 2 +* `ChainID`: The Babylon network chain ID +* `RPCAddr`: Your Babylon node's RPC endpoint +* `GRPCAddr`: Your Babylon node's GRPC endpoint +* `KeyDirectory`: Path to your keyring directory (same as `--home` path) + +Please verify the `chain-id` and other network parameters from the official +[Babylon Networks +repository](https://github.com/babylonlabs-io/networks/tree/main/bbn-test-5/). + +### 4.4. Starting the Finality Provider Daemon + +The finality provider daemon (FPD) needs to be running before proceeding with +registration or voting participation. + +Start the daemon with: + +``` shell +fpd start --home +``` +An example of the `--home` flag is `--home ./fpHome`. + +The command flags: +- `start`: Runs the FPD daemon +- `--home`: Specifies the directory for daemon data and configuration + +The daemon will establish a connection with the Babylon node and +boot up its RPC server for executing CLI requests. + +You should see logs indicating successful startup: + +``` +[INFO] Starting finality provider daemon... +[INFO] RPC server listening on... +``` + +> ⚠️ **Important**: The daemon needs to run continuously. It's recommended to set +> up a system service (like `systemd` on Linux or `launchd` on macOS) to manage +> the daemon process, handle automatic restarts, and collect logs. + +The above will start the Finality provider RPC server at the address specified +in `fpd.conf` under the `RPCListener` field, which has a default value +of `127.0.0.1:12581`. You can change this value in the configuration file or +override this value and specify a custom address using +the `--rpc-listener` flag. + +All the available CLI options can be viewed using the `--help` flag. These +options can also be set in the configuration file. + +### 4.5. Interaction with the EOTS Manager + +There are two pieces to a finality provider entity: the EOTS manager and the +finality provider instance. These components work together and are managed by +separate daemons (`eotsd` and `fpd`). + +The EOTS manager is responsible for managing the keys for finality providers and +handles operations such as key management, signature generation, and randomness +commitments. Whereas the finality provider is responsible for creating and +registering finality providers and handling the monitoring of the Babylon chain. +The finality provider daemon is also responsible for coordinating various +operations. + +The interactions between the EOTS Manager and the finality provider happen +through RPC calls. These calls handle key operations, signature generation, +and randomness commitments. An easy way to think about it is the EOTS Manager +maintains the keys while the FP daemon coordinates any interactions with the +Babylon chain. + +The EOTS Manager is designed to handle multiple finality provider keys, operating +as a centralized key management system. When starting a finality provider instance, +you specify which EOTS key to use through the `--eots-pk` flag. This allows you +to run different finality provider instances using different keys from the same +EOTS Manager. Note that someone having access to your EOTS Manager +RPC will have access to all the EOTS keys held within it + +For example, after registering a finality provider, you can start its daemon by +providing the EOTS public key `fpd start --eots-pk ` +``` + +## 5. Finality Provider Operations + +### 5.1 Create Finality Provider + +The `create-finality-provider` command initializes a new finality provider +instance locally. + +``` shell +fpd create-finality-provider \ + --daemon-address 127.0.0.1:12581 \ + --chain-id bbn-test-5 \ + --eots-pk \ + --commission 0.05 \ + --key-name finality-provider \ + --moniker "MyFinalityProvider" \ + --website "https://myfinalityprovider.com" \ + --security-contact "security@myfinalityprovider.com" \ + --details "finality provider for the Babylon network" \ + --home ./fpHome +``` + + + +Required parameters: +- `--chain-id`: The Babylon chain ID (e.g., for the testnet, `bbn-test-5`) +- `--eots-pk`: The EOTS public key maintained by the connected EOTS manager + instance that the finality provider should use. If one is not provided the + finality provider will request the creation of a new one from the connected + EOTS manager instance. +- `--commission`: The commission rate (between 0 and 1) that you'll receive from + delegators +- `--key-name`: The key name in your Babylon keyring that your finality + provider will be associated with +- `--moniker`: A human-readable name for your finality provider + +> ⚠️ **Important**: The same EOTS key should not be used by different +> finality providers. This could lead to slashing. + +Optional parameters: +- `--website`: Your finality provider's website +- `--security-contact`: Contact email for security issues +- `--details`: Additional description of your finality provider +- `--daemon-address`: RPC address of the finality provider daemon + (default: `127.0.0.1:12581`) + +Upon successful creation, the command will return a JSON response containing +your finality provider's details: + +``` json +{ + "fp_addr": "bbn1ht2nxa6hlyl89m8xpdde9xsj40n0sxd2f9shsq", + "eots_pk_hex": + "cf0f03b9ee2d4a0f27240e2d8b8c8ef609e24358b2eb3cfd89ae4e4f472e1a41", + "description": + { + "moniker": "MyFinalityProvider", + "website": "https://myfinalityprovider.com", + "security_contact": "security@myfinalityprovider.com", + "details": "finality provider for the Babylon network" + }, + "commission": "0.050000000000000000", + "status": "CREATED" +} +``` + +The response includes: +- `fp_addr`: Your Babylon account address of the finality provider +- `eots_pk_hex`: Your unique BTC public key identifier +- `description`: Your finality provider's metadata +- `commission`: Your set commission rate +- `status`: Current status of the finality provider. + +Below you can see a list of the statuses that a finality provider can transition +to: +- `CREATED`: defines a finality provider that is awaiting registration +- `REGISTERED`: defines a finality provider that has been registered + to the consumer chain but has no delegated stake +- `ACTIVE`: defines a finality provider that is delegated to vote +- `INACTIVE`: defines a finality provider whose delegations are reduced to + zero but not slashed +- `JAILED`: defines a finality provider that has been jailed +- `SLASHED`: Defines a finality provider that has been permanently removed from + the network for double signing (signing conflicting blocks at the same height). + This state is irreversible. + +For more information on statuses please refer to diagram in the core documentation +[fp-core](fp-core.md). + +### 5.2. Register Finality Provider + +The `register-finality-provider` command registers your finality provider on the +Babylon chain. This command requires you to specify: + +1. The EOTS public key of the finality provider you wish to register +2. The Babylon account associated with your finality provider + (the one specified in the creation) having sufficient funds + to pay for the transaction fee. +3. A running fpd daemon + +``` shell +fpd register-finality-provider \ + \ + --daemon-address \ + --home +``` + +Parameters: +- ``: The EOTS public key of the finality provider you want to +register (e.g., `cf0f03b9ee2d4a0f27240e2d8b8c8ef609e24358b2eb3cfd89ae4e4f472e1a41`) +- `--daemon-address`: RPC address of the finality provider daemon + (default: `127.0.0.1:12581`) +- `--home`: Path to your finality provider daemon home directory (e.g., `~/.fpdHome`) + +If successful, the command will return a transaction hash: + +``` shell +{ "tx_hash": +"C08377CF289DF0DC5FA462E6409ADCB65A3492C22A112C58EA449F4DC544A3B1" } +``` + +You can verify the transaction was successful by looking up this transaction +hash on the Babylon chain. + + + + +### 5.3. Withdrawing Rewards + +As a participant in the Finality Provider Program, you will earn rewards that +can be withdrawn. The functionality for withdrawing rewards is currently under +development and will be available soon. Further updates will be provided once +this feature is implemented. + +### 5.4. Jailing and Unjailing + +A finality provider can be jailed for the following reasons: +1. Missing Votes + - Not submitting finality votes for a certain number of blocks + - Missing votes when the FP has positive voting power + +2. Missing Public Randomness + - Not committing public randomness for blocks + - Required before voting can occur + +The specific parameters specifying the exact metrics that are taken +into account for jailing and the period of unjailing +is controlled by the Babylon chain governance. + +When jailed, the following happens to a finality provider: +- Their voting power becomes `0` +- Status is set to `JAILED` +- Delegator rewards stop + +To unjail a finality provider, you must complete the following steps: +1. Fix the underlying issue that caused jailing +2. Wait for the jailing period to pass (if it was due to downtime) +3. Then send the unjail transaction to the + Babylon chain using the following command. + +```shell +fpd unjail-finality-provider --daemon-address --home +``` + +Parameters: +- ``: Your finality provider's EOTS public key in hex format +- `--daemon-address`: RPC server address of fpd (default: `127.0.0.1:12581`) +- `--home`: Path to your finality provider daemon home directory + +> ⚠️ Before unjailing, ensure you've fixed the underlying issue that caused jailing + +### 5.5. Slashing + +**Slashing occurs** when a finality provider **double signs**, meaning that the +finality provider signs conflicting blocks at the same height. This results in +the extraction of the finality provider's private key and their immediate +removal from the active set. + +> ⚠️ **Critical**: Slashing is irreversible and results in +> permanent removal from the network. + + \ No newline at end of file diff --git a/docs/finality-provider.md b/docs/finality-provider.md deleted file mode 100644 index 527eafc6..00000000 --- a/docs/finality-provider.md +++ /dev/null @@ -1,262 +0,0 @@ -# Finality Provider - -## 1. Overview - -The Finality Provider Daemon is responsible for monitoring for new Babylon blocks, -committing public randomness for the blocks it intends to provide finality signatures -for, and submitting finality signatures. - -The daemon can manage and perform the following operations for multiple finality -providers: - -1. **Creation and Registration**: Creates and registers finality providers to - Babylon. -2. **EOTS Randomness Commitment**: The daemon monitors the Babylon chain and commits - EOTS public randomness for every Babylon block each finality provider intends to - vote for. The commit intervals can be specified in the configuration. The EOTS - public randomness is retrieved through the finality provider daemon's connection - with the [EOTS daemon](eots.md). -3. **Finality Votes Submission**: The daemon monitors the Babylon chain and produces - finality votes for each block each maintained finality provider has committed to - vote for. - -The daemon is controlled by the `fpd` tool, which has overall commands for -interacting with the running daemon. - -## 2. Configuration - -The `fpd init` command initializes a home directory for the finality provider daemon. -This directory is created in the default home location or in a location specified by -the `--home` flag. - -```bash -fpd init --home /path/to/fpd/home/ -``` - -After initialization, the home directory will have the following structure - -```bash -ls /path/to/fpd/home/ - ├── fpd.conf # Fpd-specific configuration file. - ├── logs # Fpd logs -``` - -If the `--home` flag is not specified, then the default home directory will be used. -For different operating systems, those are: - -- **MacOS** `~/Users//Library/Application Support/Fpd` -- **Linux** `~/.Fpd` -- **Windows** `C:\Users\\AppData\Local\Fpd` - -Below are some important parameters of the `fpd.conf` file. - -**Note**: -The configuration below requires pointing to the path where this keyring is -stored `KeyDirectory`. This `Key` field stores the key name of the finality -provider wallet that is going to be used for interacting with the consumer -chain and to sign the messages of your finality provider. It will be specified -along with the `KeyringBackend` field in the next -[step](#3-add-key-for-the-consumer-chain). So we can ignore the setting of the -two fields in this step. - -```bash -[Application Options] -# RPC Address of the EOTS Daemon -EOTSManagerAddress = 127.0.0.1:12582 - -# RPC Address of the Finality Provider Daemon -RpcListener = 127.0.0.1:12581 - -[babylon] -# Name of the key of the finality provider to sign transactions with -Key = - -# Chain id of the chain to connect to -# Please verify the `ChainID` from the Babylon RPC node https://rpc.testnet3.babylonchain.io/status -ChainID = bbn-test-3 - -# RPC Address of Babylon node -RPCAddr = http://127.0.0.1:26657 - -# GRPC Address of Babylon node -GRPCAddr = https://127.0.0.1:9090 - -# Directory to store keys in -KeyDirectory = /path/to/fpd/home -``` - -To see the complete list of configuration options, check the `fpd.conf` file. - -**Additional Notes:** - -If you encounter any gas-related errors while performing staking operations, consider -adjusting the `GasAdjustment` and `GasPrices` parameters. For example, you can set: - -```bash -GasAdjustment = 1.5 -GasPrices = 0.002ubbn -``` - -## 3. Add key for the consumer chain - -The finality provider daemon requires the existence of a keyring that contains an -account for the finality provider with Babylon token funds to pay and sign -transactions. This key identifies the finality provider and will be also used -to pay for fees of transactions to the consumer chain. - -Use the following command to add the key: - -```bash -fpd keys add my-finality-provider -``` - -After executing the above command, the key name will be saved in the config file -created in [step](#2-configuration). - -## 4. Starting the Finality Provider Daemon - -You can start the finality provider daemon using the following command: - -```bash -fpd start --home /path/to/fpd/home -``` - -If the `--home` flag is not specified, then the default home location will be used. - -This will start the Finality provider RPC server at the address specified -in `fpd.conf` under the `RpcListener` field, which has a default value -of `127.0.0.1:12581`. You can change this value in the configuration file or override -this value and specify a custom address using the `--rpc-listener` flag. - -This will also start all the registered finality provider instances except for -slashed ones added in [step](#5-create-and-register-a-finality-provider). To start -the daemon with a specific finality provider instance, use the -`--eots-pk` flag followed by the hex string of the BTC public key of the finality -provider (`btc_pk_hex`) obtained -in [step](#5-create-and-register-a-finality-provider). - -```bash -fpd start - -2024-02-08T18:43:00.705008Z info successfully connected to a remote EOTS manager {"address": "127.0.0.1:12582"} -2024-02-08T18:43:00.712995Z info Starting FinalityProviderApp -2024-02-08T18:43:00.716682Z info RPC server listening {"address": "127.0.0.1:12581"} -2024-02-08T18:43:00.716979Z info Finality Provider Daemon is fully active! -``` - -All the available CLI options can be viewed using the `--help` flag. These options -can also be set in the configuration file. - -## 5. Create and Register a Finality Provider - -We create a finality provider instance through the -`fpd create-finality-provider` or `fpd cfp` command. The created instance is -associated with a BTC public key which serves as its unique identifier and a Babylon -account to which staking rewards will be directed. Note that if the `--key-name` flag -is not specified, the `Key` field of config specified -in [step](#3-add-key-for-the-consumer-chain) will be used. - -```bash -fpd create-finality-provider --key-name my-finality-provider \ - --chain-id bbn-test-3 --moniker my-name -{ - "fp_addr": "bbn19khdh5vf8zv9x49f84cfuxx5t45m7klwq827mp", - "btc_pk_hex": "d0fc4db48643fbb4339dc4bbf15f272411716b0d60f18bdfeb3861544bf5ef63", - "description": { - "moniker": "my-name" - }, - "status": "CREATED" -} -``` - -We register a created finality provider in Babylon through -the `fpd register-finality-provider` or `fpd rfp` command. The output contains -the hash of the Babylon finality provider registration transaction. - -```bash -fpd register-finality-provider \ - --eots-pk d0fc4db48643fbb4339dc4bbf15f272411716b0d60f18bdfeb3861544bf5ef63 -{ - "tx_hash": "800AE5BBDADE974C5FA5BD44336C7F1A952FAB9F5F9B43F7D4850BA449319BAA" -} - -``` - -A finality provider instance will be initiated and start running right after the -finality provider is successfully registered in Babylon. - -We can view the status of all the running finality providers through -the `fpd list-finality-providers` or `fpd ls` command. The `status` field can -receive the following values: - -- `CREATED`: The finality provider is created but not registered yet -- `REGISTERED`: The finality provider is registered but has not received any active - delegations yet -- `ACTIVE`: The finality provider has active delegations and is empowered to send - finality signatures -- `INACTIVE`: The finality provider used to be ACTIVE but the voting power is reduced - to zero -- `SLASHED`: The finality provider is slashed due to malicious behavior - -```bash -fpd list-finality-providers -{ - "finality-providers": [ - ... - { - "fp_addr": "bbn19khdh5vf8zv9x49f84cfuxx5t45m7klwq827mp", - "btc_pk_hex": "d0fc4db48643fbb4339dc4bbf15f272411716b0d60f18bdfeb3861544bf5ef63", - "description": { - "moniker": "my-name" - }, - "last_vote_height": 1 - "status": "REGISTERED" - } - ] -} -``` - -After the creation of the finality provider in the local db, it is possible -to export the finality provider information through the `fpd export-finality-provider` command. -This command connects with the `fpd` daemon to retrieve the finality -provider previously created using the flag `--eots-pk` as key. - -This command also has several flag options: - -- `--eots-pk` the hex string of the BTC public key. -- `--daemon-address` the RPC server address of `fpd` daemon. -- `--signed` signs the finality provider with the chain key of the PoS -chain secured as a proof of untempered exported data. -- `--key-name` identifies the name of the key to use to sign the finality provider. -- `--home` specifies the home directory of the finality provider daemon in which -the finality provider db is stored. -- `--passphrase` specifies the password used to encrypt the key, if such a -passphrase is required. -- `--hd-path` the hd derivation path of the private key. - -```shell -$ fpd export-finality-provider --eots-pk 02face5996b2792114677604ec9dfad4fe66eeace3df92dab834754add5bdd7077 \ ---home ./export-fp/fpd --key-name finality-provider --signed -``` - -The expected result is a JSON object corresponding to the finality provider information. - -```json -{ - "description": { - "moniker": "my-fp-nickname", - "identity": "anyIdentity", - "website": "www.my-public-available-website.com", - "security_contact": "your.email@gmail.com", - "details": "other overall info" - }, - "commission": "0.050000000000000000", - "fp_addr": "bbn19khdh5vf8zv9x49f84cfuxx5t45m7klwq827mp", - "btc_pk": "02face5996b2792114677604ec9dfad4fe66eeace3df92dab834754add5bdd7077", - "pop": { - "btc_sig": "sHLpEHVTyTp9K55oeHxnPlkV4unc/r1obqzKn5S1gq95oXA3AgL1jyCzd/mGb23RfKbEyABjYUdcIBtZ02l5jg==" - }, - "master_pub_rand": "xpub661MyMwAqRbcFLhUq9uPM7GncSytVZvoNg4w7LLx1Y74GeeAZerkpV1amvGBTcw4ECmrwFsTNMNf1LFBKkA2pmd8aJ5Jmp8uKD5xgVSezBq", - "fp_sig_hex": "8ded8158bf65d492c5c6d1ff61c04a2176da9c55ea92dcce5638d11a177b999732a094db186964ab1b73c6a69aaa664672a36620dedb9da41c05e88ad981edda" -} -``` diff --git a/docs/finality-toolset.png b/docs/finality-toolset.png deleted file mode 100644 index c165ba21..00000000 Binary files a/docs/finality-toolset.png and /dev/null differ diff --git a/docs/fp-core.md b/docs/fp-core.md index d522749e..99173686 100644 --- a/docs/fp-core.md +++ b/docs/fp-core.md @@ -10,7 +10,7 @@ A finality provider has the following 5 possible states: `Registered`, `Inactive`, `Active`, `Jailed`, `Slashed`. The state transition is depicted in the following diagram. -![Finality Provider Status Transition](./fp-status-transition.png). +![Finality Provider Status Transition](./static/fp-status-transition.png). ## Invariants diff --git a/docs/static/finality-provider-arch.png b/docs/static/finality-provider-arch.png new file mode 100644 index 00000000..2f202e9a Binary files /dev/null and b/docs/static/finality-provider-arch.png differ diff --git a/docs/fp-status-transition.png b/docs/static/fp-status-transition.png similarity index 100% rename from docs/fp-status-transition.png rename to docs/static/fp-status-transition.png