# Onboarding ## Деплой модуля - DONE - Ждём Мишу, должно быть готово на этой неделе - Согласовать с Иззи параметры модуля. 1% target share. 5+5% fee ## Подготовка - Завести EOA с права на модуль (Жора) - DONE - Добавлять операторов - Выставлять таргет валидатор лимит - Тестовый эфир для депозитов на новых валидаторов - DONE - Посчитать относительно текущего количества валидаторов (дял первой итерации, будет менятсья по мере онбординга операторов в курейтед модуль) - Есть мультисиг с 2.6М эфира ## Процесс онбординга Нужен документ - Лимиты на одновременное число валидаторов - Будет понятно после разговора с Иззи, в зависимости от того сколько валидаторов можно ранить одновременно без рисков для функционирования тестнета (Иван) - Процесс подключения к сандбоксу (могут быть разные акторы: QA, новые контрибьютеры) (Ваня) - QA - есть сценарии, в которых они хотят гонять свои тесткейсы. Нужно заалайниться (поговорить с Викой) - Шаги онбординга - https://docs.lido.fi/guides/node-operators/general-overview - Генерация EOA для оператора - Пополнить баланс тестовым эфиром (лучше чтобы сам взял через https://holesky-faucet.pk910.de/) - В гайде можно углубиться - отразить какие кошельки (WalletConnect?) - Добавление оператора (со стороны онбордящего) - Могут быть 2 сценария: через голосование и с EOA с нужной ролью. Через голсоование нужны будут LDO чтобы протащить голосование - https://github.com/lidofinance/lido-cli - Генерация ключей - https://github.com/ethereum/staking-deposit-cli - Запуск валидаторов - Где запускать? (наш сервер или собственный). Можем попросить у Девопс команды виртуалку с запущенными нодами. Можно описать два процесса: на нашей виртуалке и на собственном железе (ноды + валидатор клиент) - Ноды (могут быть проблемы при запуске на собственных мощностях) - Установить fee-recipient и рассказать что это онбордящемуся - Загрузка ключей - Делается оператором через UI: https://operators-holesky.testnet.fi/ - загружаем депозит дату - Ветим ключи (поднимаем лимит) https://easytrack-holesky.testnet.fi/start-motion - Закидываем эфир в буфер - Проверяем withdrawal queue и depositable ether - Депозитим - Ждём депозита от DSM - Проверяем на https://operators-holesky.testnet.fi/ что ключи перешли в состояние used - Проверка работоспособности валидаторов - Наблюдение за E-V-M, MEV - Можно рассказать про мониторинг (E-V-M) https://github.com/lidofinance/ethereum-validators-monitoring/ - Мониторинг ревордов и работы валидаторов - Запуск софта для вывода валидаторов (после того как валидаторы получили индекс) - Сделать преподписи и запусть эджектор - https://docs.lido.fi/guides/node-operators/exits/introduction - https://github.com/lidofinance/validator-ejector/ - Можем захотеть проверять подписи заранее, чтобы не депозитить валиадторов, которые могли были ошибочно сгенерированны из другого мнемоника - Офбординг - Установить таргет валидатор лимит - Сделать заявку на выход - Подтвердить выход через эджектора - Тушим валидаторов ## Онбординг со стороны пользователя - Получить немного эфира из фаусета - Застейкать его через наш UI https://stake-holesky.testnet.fi/ - Сделать withdrawal заявку https://stake-holesky.testnet.fi/withdrawals/request - Склеймить заявку ## Голосование // TODO ? - Голосование с помощью TRP
Last changed by  
 
George Avsetsin
105

Read more

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
Draft monitoring app after shappella upgrade.

Description Необходимо задеприкеить текущий операторc виджет, поскольку он использует устаревшие контракты, а текущий вариант нужно переписать. В связи с этим, все метрики, которые есть на странице, должны быть перенесены на другой дашборд. Также нужно переписать валидацию, поиск и сабмит ключей, используя функционал KAPI, чтобы сабмит ключей был возможен под любым модулем. В связи с апгрейдом Lido до V2, необходима новая система, включающая несколько воркеров и дашборд. Задача дашборда - отображать все текущие характеристики с операторс виджета, а также смотреть данные в разбивке по модулям, операторам, такие как капасити по эфиру, ключам (вышедшим, застейканым), таргет лимит. Также нужна визуализация данных: как долго нод операторы выводят ключи, как много ключей потребуется вывести в ближайшее время (сколько ожидаем в ближайшем репорте). Визуализация данных должна поддерживать историчность, то есть дашборд должен уметь показывать данные по репортам за прошлый период. Кроме того, задача дашборда - отображать финализацию заявки: сколько сейчас нефинализированного steth в очереди, сколько во всех буферах: буфер, EL vault, WV vault. Задача демона - наполнять хранилище данными, чтобы дашборд мог отображать метрики с указанными фильтрами в удобном виде. Например, одна из детальных задач демона - хранить exit_epoch ключа. Другая задача системы - рассылать уведомления о предстоящем выводе ключей за день, 6 часов, 1 час. Вторая задача - рассылать алерты, если нод оператор задерживается с выводом ключа из сети. Предполагаем, весь этот функционал, может поставляться в docker-compose файле с подключенной и преднастроенной графаной для визуализации метрик, и рассылок нотофикаций Ask:

5/11/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