Основная задача мев-мониторинга собирать данные с разных источников. Ниже указана схема данных и короткое описание.

#### slot_storage
Table with indexed slots
- `slot_number` - `integer`, slot number in consensus layer
- `is_block_indexed` - `boolean`, true if an block data from CL is indexed for this slot: `propose_status`, `block_number`, `block_hash`, `validator_index` (if proposal is not missed)
- `is_validator_indexed` - `boolean`, true if a validator data is indexed: `pubkey`, `validator_index`
- `is_operator_indexed` - `boolean`, true if slot belonging to the Lido operators is indexed: `operator_index`
- `is_payload_indexed` - `boolean`, true if a payload source is indexed: `relay_pubkey`, `builder_pubkey`, `signed_bid_balue`, `indirect_fee_recipient`
- `is_value_indexed` - `boolean`, true if `delta_balance` of the block is indexed
- `is_payment_indexed` - `boolean`, true if the payment transaction from a builder to a proposer is indexed: `indirect_payment_value`
- `propose_status` - `enum`
- `0` - Not found. This usually means a missed porposal
- `1` - Missed. Reserved for future iterations. The same as the previous one, only with explicit confirmation, since some API providers can return an error if their node is not synced
- `2` - Proposed
- `spec` - `string`, consensus version for the block
- `phase0`
- `altair`
- `bellatrix`
- `pubkey` - `string`, validator public key
- `validator_index` - `integer`, validator index on consensus layer
- `operator_index` - `integer`, operator index in the node operators registry
- `fee_recipient` - `string`, the block fee recipient
- `indirect_fee_recipient` - `string`, fee recipient address, that received a reward with a transaction. Address is extracted from relay data API or from payment transaction
- `block_number` - `integer`, block number on Execution Layer
- `block_hash` - `string`, block hash on Execution Layer
- `delta_balance` - `numeric`, wei, the difference between the block fee_recipient address balance of the current block and the previous one. May not be accurate if there was a withdrawal from FR address in the block
- `indirect_payment_value` - `numeric`, wei, value in a transaction from `fee_recipient` to `indirect_fee_recipient`
- `relay_pubkey` - `string`, relay public key
- `builder_pubkey` - `string`, builder public key
- `signed_bid_value` - `numeric`, wei, bid value that was promised by a builder. Should match to `indirect_payment_value` or `delta_balance` if a payment transaction was not used

### Auxiliary tables

#### allowed_relay_storage
Table with list of relays. Functionality in development, data scheme may change.
- `pubkey` - `string`, relay pubkey
- `url` - `string`, relay url
- `type` - `enum`
- `0` - optional
- `1` - required
- `removed` - `boolean`, whether the relay has been removed from the contract

#### fee_recipient_storage
Table with identified fee recipient addresses
- `address` - `string`, ethereum address
- `type` - `enum`
- `0` - zero address
- `1` - unknown address
- `2` - Lido address

### Registry tables

#### registry_key
Table with synchronized data on operator's keys from the registry
- `index` - `integer`, key index in the node operator registry contract
- `operator_index` - `integer`, operator index in the node operator registry contract
- `key` - `string`, public key
- `deposit_signature` - `string`, signature over deposit data
- `used` - `boolean`, whether the key has been used

#### registry_meta
Table with meta data of last registry update
- `block_number` - `integer`, block number of the last registry update
- `block_hash` - `string`, block hash of the last registry update
- `keys_op_index` - `integer`, incremental index stored in the contract, representing the state of the keys (changes with each key update)
- `timestamp` - `integer`, unix timestamp of the last registry update

#### registry_operator
Table with synchronized data on operators from the registry
- `index` - `integer`, operator index in the node operator registry contract
- `active` - `boolean`, whether the operator is active
- `name` - `string`, operator name
- `reward_address` - `string`, address to which the operator receives rewards
- `staking_limit` - `integer`, limit of keys that can be used for deposits
- `stopped_validators` - `integer`, number of stopped validators
- `total_signing_keys` - `integer`, total number of submitted keys
- `used_signing_keys` - `integer`, number of keys that were used for deposits

## Полезные ссылки

Документ про работу Relay мониторинга
https://hackmd.io/@5ilhalsuSjKOnS2sxpkVJw/H1hz4LUjn

Обзорная статья про MEV в эфире
https://forklog.com/cryptorium/chto-takoe-mev-v-ethereum-i-kak-on-izmenitsya-posle-perehoda-na-pos