# Staking Router v2. Outline

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

TLDR:
SR был наивный, чтобы работали DVT и CSM в нем не хватает фичей. Мы думаем в сторону модулей для институцианалов и рестейкинга (?)

TODO:
- Придумать вехи

## Scope

### Bonds
Эта часть мне видится одной из фундаментальных, которая может затронуть многие части протокола и потянуть за собой много изменений. Этот раздел должен ответить на следующие вопросы:
- Зачем нужен бонд
- К кому привязываются бонды. Считаю, что это должно быть свойство Нод операторов, которые в свою очередь должны иметь общий реестр. Бонд можно перемещать из одного модуля в другой, а пенальти (например в случае кражи мева) распространяется на бонд оператора во всех модулях
- Как обрабатывается сжигание бонда.
- Влияние бонда на порядок вывода валидаторов

- Зачем нужен бонд
- Слешинг
- Кража block fee
- Компенсация плохого перформанса
- Во время выхода. Проще, страховка может применится в некоторых случаях и через год и никогда. Другие части можно привязывать к фрейму
- Или сразу (за фрейм)? Лучше, так как страховка применяется тем же холдерам, что были во фрейме
- Может ли быть трешхолд?
Работа с DVT: валидатор может состоять из забондованных и не забондованных частей
MEV может украсть релей, а не валидатор. Нужен способ компенсации? (от ДАО или релея или самого НО)
Бонды - сущность оператора
Бонды не шарятся между модулями (?) нельзя сжигать бонд оператора в другом модуле. иначе в двт кластер может в момент стать недобонденным. С другой стороне надо выгонять такого оператора, если он не компенсирует.
- Должны ли мы расформировывать такой кластер? Почему бы и нет. Если мы хотим офборднуть малишиос НО, то стоит офбордить отовсюду
В каком порядке выводить валидаторов в случае если бонд нужно применить? что делать с кластерами?

Нужно ли депозитить бонд? Или хранить в steth
- Если считаем отдельно, то похоже нужен эфир
- Но конвертить сразу выгоднее

Можно попробовть зайти с количества валидаторов при расчёте пенальти (может быть деинсентивом для CSM)

Халвинг ревордов (любая невостребованная штука) можно отправлять в страховой фонд

### Automatic insurance cover (?)
- Автоприменение страховки это более общая штука чем бонды. Стоит рассмотреть их вместе
- Что будет если валидатор плохо перформит и уходит в минус
- В какой момент применить страховку?
- Нужно ли объединять валидаторов в группу (по нод оператору или кластеру)?
- валидатор всё же
- Что компенсировать?
- Если в рамках фрейма валидатор ушёл в минус?
- Если в рамках фрейма оператор ушёл в минус?
- Если валидатора на выходе имеет баланс меньше задепозиченного
- Как посчитать простои
- Через дельту балансов сложно. Непонятно как хэндлить скиминг. проверять каждый блок дорого, считать дельту балансов без скиминга не корректно
- Можно считать через экспериментальные эндпоинты https://ethereum.github.io/beacon-APIs/#/Rewards но в этом случае
- Можно по аттестациям. Добавить некоторый трешхолд, считать дельту до трешхолда, считать реворды

### Common operators registry (MVP)
- Нужен чтобы иметь перераспределять бонд между модулями
- Связывает оператора с:
- Репутацией
- Типом: соло, профи и т.д.

### IStakingModule interface update
Если у нас есть реджестри операторов, то нужны общие методы для работы с ними

### Trigerable exits (protocol)
- Иметь инструмент, который может тригерить вывод валидаторов, которые не вышли в отведённый срок через VEBO
- Иметь ручку для DAO, способную выводить валидаторов напрямую

### Fractional validator counts
Для DVT нужен особый аккаунтинг, дробное хранение числа валидаторов у нод оператора может решить проблемы:
- начисления наград
- бонда
Не факт что нужно на уровне стейкинг роутера
Если подружить это с MEB, то дробные депозиты хорошо ложатся. Можно считать в gwei

### MEB support

#### Изменения в протоколе
- Как хранить ключи и сигнатуры, должны ли сигнатуры быть кратны 32, все ли модули должны работать одинаково
- Как вести аккаунтинг депозитов на ключ
- Как мигрировать текущие модули и аккаунтинг задепозиченных валидаторов
- Нужно ли поддерживать несколько WC в протоколе на время миграции? Или срежем ключи?

#### Миграция на WC 2.0
Описать как будет происходить миграция
- Как объединять валидаторов (подписанное сообщение на CL?)

// Oracles

### Performance oracle (?)
Хорошо бы его иметь на уровне стейкинг роутера
- Распределение ревордов по разным параметрам (активные ключи, а внутри модуля по аттестациям) может привести к несправедливому распределению между участниками
- Это первый шаг к маркетплейсу между модулями. Распределение ревордов должно быть справедливым
- Репортить рут полного дерева во всем модулям (включая валидаторов), чтобы можно было использовать его для распределения ревордов по операторам внутри модулей. Подумать о DVT при распределении
- Репорт отрицательных значений
- Если только по оператору, должно ли это тригерить применение страховки? а по одному валидатору

### Extended oracle stage 3
- Уметь отправлять несколько транзакций чтобы доставлять больше данных (больше модулей – жирнее транза)
- Клейм ревордов внутри модулей (может быть аут оф скоуп)
- Возможно сделать на уровне роутера репорт withdrawn валидаторов

### Bunker
- Нужно пересмотреть бункер режим
- Если мы будем получать стейт по каждому слоту, то можем правильнее считать скимед реворды. Закроет часть найденных "уязвимостей" по входу в бункер режим.

### Reuse validator index
// TODO

### Vetting via DSM

## Out of the scope

### Restaking
Можно прикрутить сбоку от существующего SR, достаточно поменять только WC контракт.

### Institutional staking
Непонятно как делать, не лезет сейчас. Не факт, что потребуются отдельные WC и EL волты. Возможно можно по-другому дизайнить. Может вообще не нужно ничего делать, а обучить институционалов. Не похоже, что это должен быть стейкинг модуль: там больше про аккаунтинг, нежели про хранение ключей и нод операторов.