# Draft monitoring app after shappella upgrade. ## Description Необходимо задеприкеить текущий операторc виджет, поскольку он использует устаревшие контракты, а текущий вариант нужно переписать. В связи с этим, все метрики, которые есть на странице, должны быть перенесены на другой дашборд. Также нужно переписать валидацию, поиск и сабмит ключей, используя функционал KAPI, чтобы сабмит ключей был возможен под любым модулем. В связи с апгрейдом Lido до V2, необходима новая система, включающая несколько воркеров и дашборд. Задача дашборда - отображать все текущие характеристики с операторс виджета, а также смотреть данные в разбивке по модулям, операторам, такие как капасити по эфиру, ключам (вышедшим, застейканым), таргет лимит. Также нужна визуализация данных: как долго нод операторы выводят ключи, как много ключей потребуется вывести в ближайшее время (сколько ожидаем в ближайшем репорте). Визуализация данных должна поддерживать историчность, то есть дашборд должен уметь показывать данные по репортам за прошлый период. Кроме того, задача дашборда - отображать финализацию заявки: сколько сейчас нефинализированного steth в очереди, сколько во всех буферах: буфер, EL vault, WV vault. Задача демона - наполнять хранилище данными, чтобы дашборд мог отображать метрики с указанными фильтрами в удобном виде. Например, одна из детальных задач демона - хранить exit_epoch ключа. Другая задача системы - рассылать уведомления о предстоящем выводе ключей за день, 6 часов, 1 час. Вторая задача - рассылать алерты, если нод оператор задерживается с выводом ключа из сети. Предполагаем, весь этот функционал, может поставляться в docker-compose файле с подключенной и преднастроенной графаной для визуализации метрик, и рассылок нотофикаций **Ask:** - какие приложения или сервисы сейчас есть, которые так или иначе связаны с апгрейдом на в2 - какая судьба ждёт эти приложения. что мы дорабатывает, что деприкейтим – какие новые приложения нам нужны – по итогу должен получиться список приложений и сервисов тулинга после v2 с описанием ответственности каждого из приложений Answer: * https://github.com/lidofinance/depositor-bot (внесены правки) * https://github.com/lidofinance/ethereum-validators-monitoring balval * https://github.com/lidofinance/lido-council-daemon * https://github.com/lidofinance/lido-eth-api * https://github.com/lidofinance/lido-keys-api (создан) * https://github.com/lidofinance/lido-oracle (переделан) * https://github.com/lidofinance/validator-ejector (создан) Кажется, что апргрейд этих приложений не нужен. А вот * https://github.com/lidofinance/node-operators-widget * https://github.com/lidofinance/node-operators-widget-backend будут деприкейтиться и причины написаны как выше, так и ниже. ### Step 1: - [x] Make a survey of what metrics would be useful (asked about needed features) - [x] Make an approximate design of a new service [Monitoring app](https://miro.com/app/board/uXjVMNV5oZ4=/#tpicker-content) ### Step 2: 1. **Monitoring service** 1. Trasnfer current [operators widget](https://operators.lido.fi/) data into new storage 2. Daemon collector 1. Collect oracle reports from execution layer 2. Collect keys from KAPI for historical data 3. **[Exit monitoring]** Collect exit keys, and exit epoch 3. Daemon notifieler. When report's data strored then if some situation is triggerable then 1. Send notification to NOM "Exit is taking longer than expected" 2. Send notification to NOM "Upcoming key exits before (24h, 12h, 6h, 1h)" 4. Metrics will be displayd on grafana using direct accsess to db store 5. Some specific metrics can be display by [dune service](https://dune.com/home) 2. **Deprecation operators widget** 1. [node-operators-widget](https://github.com/lidofinance/node-operators-widget), [node-operators-widget-backend](https://github.com/lidofinance/node-operators-widget) 4. Remove stats from operators widget 5. Rewrite key finding, submiting, validating using **KAPI** (https://github.com/lidofinance/lido-keys-api) ### Step 3: **Monitoring service** 1. Detailed research which report's data need to store into db: 1. Research how to transfer data from [operator's widget](https://operators.lido.fi/) to new storage for displaing them in grafana. 2. Research which oracle reports we need to store 3. Interaction with KAPI service 4. After those actions, we will be ready to design db schema. 5. Attempt to connect store with grafana and visualization data with filters: staking router, date, nom 6. Got a decision - to use Grafana or to build custom frontend. **Operators widget** 1. Find out how to rewrite current system for using Kapi for searching and validation keys 2. Find out use new(and which contracts) for submitting keys into different modules. --- ### Staking modules dashboard - Можно задепрекейтить операторс виджет - поддерживает только один контракт - много проблем с бэкендом при валидации ключей - нужно переработать работу с ключами на KAPI на бэкенде - Дашборд должен отображать данные - общая сводка по всем модулям: капасити по эфиру, ключам, валидация ключей и т.д. - сводка по каждому модулю: сколько операторов, есть ли проблемы, капасти по ключам - сводка по НО - вынести всё что есть в операторс виджет в отдельный подмодуль, проработать общую страницу по всем моудлям, добавить нвоый функционал для модулей: вышедшие ключи, застаканные, таргет лимит и т.д. ### Валидация ключей Нужен бэкенд который будет валидировать ключи. Сейчас эту роль выполняет оператор виджет, но сейчаас источник ключей должен быть KAPI - валидация - алертинг - визуализация ### Сабмит ключей Текущий операторс виджет позволяет сабмитить ключи для NOR. Нужен более гибкий фронтенд, который позволит добавлять сабмитинг под любой модуль. стоит выгрузить в UI eth команду. Можно взять за основу текущий операторс виджет ### Поиск ключей Впринципе KAPI уже умеет это, может лучше отразить в доках ### Exit bus Вероятно нужен индекстор реквестов, который вычитывать события и складывать в какойто сторедж #### Визуализация - Нужны статистические данные о том как долго НО выводят ключи, чтобы видеть пробелмы и НО которые пытаются хитрить (есть теоретическая возможность в текущем конфиге контрактов) - Нужно видеть пробелмные места: какой НО и сколько ключей не выводит и как долго - Просятся предсказательные данные на основе данных из кнотракта: сколько мы ожидаем в ближайшем репорте - Будет полезно отразить сколько в предыдущих репортах было запрошено. Тоесть смотреть с двух сторон: со стороны НО и со стороны Оракула - Когда именно произошёл вывод ключа (изменился exit_epoch) - ... проработать детальнее на основе запросов от НОМ команды и фронтенд команды #### Алертинг - Алерты если реквесты долго не обрабатываются НО с разным интервалом ### Accounting oracle / Withdrawal queue Из интересного нам: оракул финализирует заявки в этом репорте и отчитывается о выводе ключей по модулям и НО ! Оракулы приносят данные раз в какое-то время, но больишнство данных которые нас интересуют они обновляются риалтайм, так как зависят от действий пользоватейлей. Предсказание бункера? Нужно было команде UI #### Визуализация - Сколько ключей у каждого НО выведено и и по каждому модулю (на дашборде стейкинг модулей) - Финализация заявок: сколько сейчас нефинализированного steth в очереди, сколько во всех буферах: буфер, EL vault, WV vault. Полезно чтобы понимать сколько заявок у нас покрывается и как. #### Алертинг - ... ### Motivation and collected requests. The text is collected from the [Draft for "monitoring app"](https://discord.com/channels/761182643269795850/1098584222668697600). What statistics should be displayed after upgrading the protocol to version v2. It is worth to pay attention, then different parties (NO, bizDev, Dao devs) see the common value in the **display which keys, as well as their order and belonging to the NO protocol requested for output**. Validators status by NO (Exited, Exiting, Delayed, Delinquent, during cooldown). In addition to the display of keys on the output, an important and complementary element is the **visualization of the number of tokens in the queue.** Working together (key dashboard + queue visualization) it will be possible to visually compare the state of the protocol and the need for actions of different actors in different situations.(NO, bunker mode, dev, easytrack or something external in world). The other features are additional to these 2 core ideas. "Стакан" - не важно. Алертинг Вход ? (https://operators.lido.fi/), нужно ли расширить текущий? Выход * https://github.com/lidofinance/depositor-bot * https://github.com/lidofinance/ethereum-validators-monitoring balval * https://github.com/lidofinance/lido-council-daemon * https://github.com/lidofinance/lido-eth-api * https://github.com/lidofinance/lido-keys-api * https://github.com/lidofinance/lido-oracle * https://github.com/lidofinance/node-operators-widget * https://github.com/lidofinance/node-operators-widget-backend * https://github.com/lidofinance/validator-ejector * Oracle reports * accounting https://github.com/lidofinance/lido-dao/tree/feature/shapella-upgrade/contracts/0.8.9/oracle * exit bus * staking router https://github.com/lidofinance/lido-dao/blob/feature/shapella-upgrade/contracts/0.8.9/StakingRouter.sol - contracts (https://github.com/lidofinance/lido-dao/tree/feature/shapella-upgrade) ## Notes * Кажется lido-eth-api стоит им же и оставить. Или переименовать в apr-api. Оно выполняет свою задачу. А если софт ставить у NO. То apr не нужен. ## Questions - Похоже здесь только про ключи в Exit Bus, но были запросы на апишку для других вещей типа предсказания бункера, аккаунтинга: - изменение tvl, el реворды и подобные штуки. **(Отобразил в списке задач)** - Возможно что-то из этого можно сторонними сервисами типа дюны закрыть, но надо явно хотелки выписать и расписать чем кони будут покрыты (Хотелки выписаны, **нужно обсудить с тобой**) - Непонятно что такое Withdraw NO stats. (**Просто задача, размышления**) - Если это апишка, будет ли она общедоступной? - Что будет с операторс виджет? Там много вопросов о том как нужно работать с другими модулями. Сейчас он работает с одним контрактом и загружает туда ключи. (**Добавил теги, где он может использоваться. Хорошо бы от тебя получить сп-к сервисов, которые для этого могут понадоиться.**) - Чем отличается визуализация queue от графаны в withdraw NO stats? (**Здесь нет ответа, частям задач приклетил теги**) - По схеме кажется что сервис Alerting for NO занимается фетчингом ключей, хотя он алёртинг. видимо нужен какой-то единый индексатор, а потом от него уже алертинг, дашборд, апишка (**Согласен. Мысль такая что нужно слушать евенты оракула, сопоставлять их с данными из keys api, и слать alert или notification потребителю**) - кликхаус кажется оверкил здесь, у нас всего 150к ключей, там на выход в ближайшие пару лет не должно быть больше 50-100к с учётом ротации(**Из 150к - согласен. Возможен ли экспонециальный рост данных, чтобы их потом было удобно крутить?Хочется предусмотреть это. А поднмать pg или другой стор - кажется значения не имеет**) и выборка видимо нам нужна будет только как счётчик по НО + конрктеные ключи, те что не выводятся по какой-то причине (единицы, может десятки) (**Не уверен. Анализ задачи показывает, что все таки какое-то хранилище нужно. Так нужно показывать исторические данные с разными фильтрами. Метрика, NO, staking router и т.д**) ## Node operators **Aim:** We need to know when a NO is not correctly processing exits, so we can contact them asap: ### Notifications - **Notification** Upcoming exits - is an indicator about why each key has the position it has (what's the modifier, if any? targetlimit? Delay? Over 1%?) - **ALERT**: Their exits are taking longer than expected - They have delayed exits (red), exits take >12h - They have delinquent exits (dark red) > 18h ### Visualization - Knowledge where NO is. Number of key in the exit queue, exit priority. - Total overdue validators (stuck - refunded > 0) - Target Limit ? (DiRay) - ***For example***: when user's click on NO on operators widget, he'will be redirected to a page with: - How many keys are refunded for an operator - Number of delays ever - Number of delinquencies ever - Status (Exited, Exiting, Delayed, Delinquent, during cooldown) - Epoch of exit, transaction and etc - Avg time to process an exit - i.e. next X keys to get deposited to - deposits to which modules/operators/keys over last X days ## Queue stats - Number of tokens in the queue - Number of requests. (how many requested already) - Number of validators we want to exit - from staking module we want to withdraw - Which NO - Average request completion time - Request amount - Avg exit requests per period - Maximum amount of request for the period - Number of finalized but not claimed requests - Exits WITHOUT exit bus ## Staking Router: - stake distribution per modules (desired share and actual) - keys summary per modules (exited / active / ready to deposit) - module fees per period ## Accounting: - TVL changes (breakdown for -- withdrawals vault inflow per period -- EL rewards vault inflow per period -- CL balance changes -- withdrawals finalization outflow - burnt stETH shares per period - stETH supply / unstETH demand (staking / unstaking) per period - distribution of TVL: -- idle (not deposited) -- holding (deposited and validating) -- unstaking (exit request sent) funds ## Oracle committee: - reports stats - time lags for each member - gas spending for each member - missed fastlane reports :::spoiler *Links. Work materials* ### Peers - Izzy - Eugune Mamin - Andrey Finaev (which apies endponts need to be implement) ## Sergey - То, что oracle репортит - accounting https://github.com/lidofinance/lido-dao/tree/feature/shapella-upgrade/contracts/0.8.9/oracle - exit bus - staking router доставать данные по модулям, https://github.com/lidofinance/lido-dao/blob/feature/shapella-upgrade/contracts/0.8.9/StakingRouter.sol - contracts (https://github.com/lidofinance/lido-dao/tree/feature/shapella-upgrade) https://docs.lido.fi/deployed-contracts/goerli ::: :::spoiler *Russian Draft text. It's specially hidden* ## Exit Bus ### Текущий статус - Кого запрашивали на выход - В каком репорте - Транзакция - Время запроса - Статус: вышел, не вышел, выходит - Эпоха выхода - ? - Статистика по выводам - Скорость вывода - Число выведенных, задержанных, застрявших ### Предсказание - Какой demand сейчас в WQ - Какое число валидаторов мы хотим вывести - Откуда будет вывод: из какого стейкинг модуля, какие НО ## Staking Router NO widget (https://operators.lido.fi/) устарел, так как появляются новые модули с которыми он не умеет работать. Можно в объединить это всё в апи работы с модулями. - Статистика: - общая: ключи, капасити, буфер в Lido, деманд в WQ - по модулям: ключи, капасиити... - по НО: сколько всего ключей, сколько лимит, сколько выше лимита и т.п. - статус НО: активен/неактивен, оштрафован (и до когда будет штраф) - Статус изи трека - Валидация ключей, дубликаты, алерты ### Accounting & bunker Возможно мы хотим объединить это в одну апишку - Статистика по финализации заявок - Деманд в очереди - Объём заявок - Предсказание бункера :::
Last changed by  
 
George Avsetsin
303

Read more

Sandbox module

Деплой модуля

11/29/2023
Untitled

Это первый документ из предстоящей серии документов по спецификации Staking Router. Объём видится огромным и я бы хотел подойти к этом процессу итеративно. Документ представляет собой заголовки и размышления о тех частях, который на мой взгляд должны быть включены в грядущую спецификацию и следующий апгрейд роутера. На этой стадии хотелось бы определиться со скоупом того, что мы хотим проработать детальнее, а что отбросить.

10/9/2023
Manual Exit Bus Monitoring

The manual how to use the Lido CLI to track the status of validator exits. Install CLI Use the steps from readme in a repository to install the CLI: https://github.com/lidofinance/lido-cli#installation Unsettled requests Takes data from the Consensus Layer on a head block and matches it with the requested validators for each operator based on lastRequestedIndex. All validators whose index <= lastRequestedIndex are considered requested. ## Returns a list of operators and validators that were requested but not exited

5/12/2023
Lido Report and incidents Off-Chain

Findings Report CRITICAL No issues found MAJOR [ACKNOWLEDGED] Abnormal CL rebase condition of the bunker mode depends on the manipulatable value of the WithdrawalVault balance in abnormal_cl_rebase.py Description The function _calculate_cl_rebase_between_blocks in the AbnormalClRebase class uses the WidthrawalVault balance to calculate the difference in the rebase between blocks. WithdrawalVault is a contract, which balance can be manipulated by sending ether directly to the contract. This will increase the expected rebase value at the end of the frame and allow the attacker to prevent bunker mode from activation. def _calculate_cl_rebase_between_blocks(

5/9/2023
Read more from George Avsetsin
Published on HackMD