What went well мы стартанули воут для sdvt и собрали кворум обновили DSM у всех консулов обновили КАПИ у всех оракл-холдеров несмотря на все тяжелые моменты - мы сделали деплой What went wrong Кирилл и Миша работали ночью Процесс просекко зафейлилсяВитя: это не так. Есть ожидание, что команда, которая готовит релиз, сама его толкает. Она просит помощи и задает вопросы. Ожидать, что просекко будет овнить и тянуть этот процесс - бессмысленно. За неделю до релиза просекко и дао опс махали флагом, что в таком состоянии релиз выпускать нельзя. У нас было ожидание, что команды хорошо понимают процесс, учитывая, что ранее участвовали в релизах. У нас нет единой карты, что нужно для релиза - это тейкэвей, который ДАо опс взяли в работу - помощь командам в подготовке релизов. Миша: как идея в хелпдеске кидаешь запрос и ставить дедлайн для просекко.

What went well? started automated tests for apps по деплой скриптам мы успеваем к дедлайну по KAPI, Oracles, Council мы успели What went bad/poorly? move to another country difficulties [[Eddort]] hard time to get someone to make review bad evaluation of our capacity and performance capabilities tricky, unclear, messy communication with other teams

Summary Multi-thread Multi-processing Implementation worker-threads cluster, child-process Communication

Why Show NOs how it's working - Ejector, KAPI + Oracle Check-lists Validators [x] Prepare 5 NOs for Zhejiang [x] Create 10 validators for each new NO [x] Run 5 instances of Prysm Validator with 10 keys each [x] Ensure Validators are attestating

New tooling will require some DevOps work. Proper Prometheus + Grafana monitoring should be used for every tool. KAPI should be deployed no matter Node Operator runs Oracle or DSM. KAPI will need PostgreSQL DB, Consensus and Execution Nodes. Ejector should be deployed to support withdrawals. It will require Consensus, Execution Node. In case Node Operator runs Oracle, it should be updated and Node Operator will have to deploy two new oracles and archive Execution node. In case Node Operator runs DSM, it should be updated and KAPI plugged in too with Consensus and Execution nodes. Dependencies

Hardware requirements 2-core CPU 1GB RAM Nodes requirements Execution Node (full node, archiveness is not important) Consensus Node Software requirements Docker + docker-compose (if using docker)

Glossary: NoA = Node Operator AValidators count: 100 Validators:PKey0 ... PKey100 NoB = Node Operator B Validators count: 50

1. Hey hey! Hello everyone, thanks for coming! I am Kirill Minenko, I work on Tooling at Lido. Today I wanna talk about the tooling for Node Operators version 2. 2. v2 tooling scope First I will tell you about scope of changes pause Then I will mention our schedule pause And then will go through technical stuff, and it's ok if you don't get it at first, it took quite a long time for me to understand technical details.

Problem breakdown Recently Lido introduced MEV Boost Relay Allowed List (https://docs.lido.fi/contracts/mev-boost-relays-allowed-list) contract that contains a list of allowed relays to be used in Node Operators MEV-Boost instances. The number of relays and relay urls in the contract are subject to change. After The Merge and MEV integration Node Operators should maintain an up to date list of relays urls in their infrastructure. For now, it could be done by manually copying one or more relays from the contract to application configurations that works with MEV, like Vouch and MEV-Boost. The Problem: The list of allowed relays in the contract can be changed frequently, so Node Operators will have to manually change (or re-deploy) their application configurations. Solution: