## Введение

В процессе работы над Lido V2 наша команда (Tooling/Validator Set) столкнулась с определенными вызовами: тестировать работу контрактов и их интеграцию с нашими офчейн сервисами на отдельном тестнете. Для этого была разработана lido-cli — консольная утилита, позволяющая менять состояния контрактов, отслеживать определенные состояния. Данное решение очень помогло при тестировании zhejiang и goerli.

Но данное решение не закрыло все потребности:
- Нам нужны форки существующих сетей. Такие форки поднимает команда эфира при разработке новых версий клиентов. (ganache, hardhat)
- Нужна сеть с опубликованными смарт-контрактами, а это в свою очередь замедляло работу: мы каждый раз ждали, пока кто-нибудь зальет/обновит их на zhejiang
- Нужно глубоко погрузиться в работу консольной утилиты, ведь она предоставляет низкоуровневый интерфейс
- Мы нуждаемся в запущенной сети, а хотелось бы запускать свою
- Так же хотелось бы иметь возможность поднимать ноды, которые в процессе разработки. Например, сейчас идет разработка функционала ончейн валидации ключей и нам бы очень помогло окружение, которое позволит поднять ноду с определенной гит ветки и запустить тесты, чтобы проверить сколько тратиться газа при валидации ключей

Помимо технических потребностей сформировалось видение, что нам не хватает процессов тестирования новых нод/контрактов/интеграций поставленных на поток.

Просумировав наши потребности и боли, у нас появилась идея реализовать проект, который будет решать вышеозвученные задачи.

В процессе рассуждения о продуктовой трансформации, которая сейчас проходит, мы с командой думали о направлениях, которые мы бы хотели развивать.

Данный проект, кажется нужным, так как есть уже есть запросы и предполагаемые клиенты и он может стать продуктом.

Обычно, рассуждения о продуктах начинаются с вопроса "Кто наш клиент?".

## Кто наш клиент

##### Команда Validator Set
- тестирование офчейн приложений на отдельной сети
- данное окружение можно будет передать всем разработчикам staking модулей
- сможем сами тестировать интеграции и давать подробные баг-репорты. Как пример: в данный момент мы разрабываем интеграцию simple-SVT модуля.

##### Протокольная команда
- снизит нагрузку на команду смарт-контракт разработчиков: процесс работы Lido будет более прозрачен
- другим командам не придется глубоко вникать в работу смарт-контрактов, тк у них будет окружение для запуска Lido

##### Командам разработки офчейн приложений
- запускаем сеть в одну команду
- другой командой создаем необходимое состояние
- тестируем приложение

##### Команда НОМов
- можно быстро запустить тестовую сеть на своем компьютере
- проверить новый стейкинг модуль, какую-либо другую интеграцию

##### Внешние команды
- к нам поступал запрос от команды Nimbus, спрашивали, есть ли у нас окружение, чтобы запустить keys-api на их ноде с предустановленным состоянием

- так же это будет полезно для разработчиков стейкинг модулей
- уверен, что запросов было больше, но я не занимался иследованием

##### Новички
- продробно задокументированный процесс работы приложения (стейты) является хорошим анбординг материалом
- понизит порог входа в Lido

---

## Структура проекта

Проект состоит из двух частей:
- node-bootstrap-engine
- node-state-engine

## node-bootstrap-engine

Данный проект предназначен для удобного запуска всех инвариантов EL/CL нод и валидаторов.

Мы хотим тестировать приложения еще до того, как появится публичный тестнет, так же хотим быть более гибкими в вопросах тестирования: проверять приложения на всех типах нод.

Как я понял, эту часть делает Раман.

## node-state-engine

Декларативное описание состояний блокчейна: сборка, публикация контрактов и заполнения стейта под все варианты тестирования и предоствление удобного апи для работы во всех окружениях: nodejs, python

Данный проект не является самостоятельным, а тесно связан с Lido.

State engine состоит из двух вариантов использования:
- установка состояния/тестирование на hardhat ноде
- установка состояния/тестирование на реальной связке EL/CL

##### Почему разделяем на два разных юзкейса?

Hardhat предоставляет гибкое API, которого нет в обычных нодах: снапшоты, откат состояния, быстрая очистка состояния.

##### Почему не локальные e2e тесты? зачем описывать состояния в отдельном репозитории?

- Описание состояний отнимает очень много времени
- Состояния не уникальны
- В некоторых кейсах нам нужно тестировать смарт-контракты, которые еще в разработке и их нет на тестовых сетях

## Концепт
На данный момент реализован концепт: https://github.com/lidofinance/node-state-engine

В репозитории более продробно описана идея и путь к реализации