Это продолжение начальной темы о двойном управлении 18. Ссылка на эту тему содержит важный контекст, поэтому, если у Вас есть время, прочтите ее.
С тех пор, как последняя версия дизайна механизма была предложена в этом посте 5, участники протокола, работающие над DG, сделали несколько итераций, чтобы учесть полученные отзывы и сделать механизм более простым, менее хрупким и эффективным.
Прежде чем представить обновленную версию, позвольте мне обрисовать проблему, которую мы пытаемся решить, и вкратце проследить цепочку рассуждений, которая привела нас к предлагаемому решению.
В настоящее время код протокола Lido и его параметры контролируются Lido DAO посредством голосования токенами LDO. Протокол берет 5% от вознаграждения за ставку и направляет их в казну DAO (еще 5% распределяются среди операторов узлов, участвующих в протоколе).
Хотя держатели LDO, как правило, должны быть мотивированы поддерживать благосостояние протокола, поскольку это отражается в цене токенов LDO, это не обязательно означает, что держатели LDO эффективно представляют пользователей протокола. Например, представьте, что владельцы LDO коллективно решают увеличить плату за протокол: хотя это может положительно сказаться на ближайшем благосостоянии владельцев LDO, это явно противоречит интересам, по крайней мере, некоторой части пользователей протокола.
Это можно обобщить как проблему принципала и агента (PAP) между DAO (агентом) и пользователями протокола (принципалом). Проблема существует потому, что у владельцев LDO нет таких же стимулов, как у пользователей.
Более того, как подчеркивает Виталик в своем эссе Moving beyond coin voting 9, PAP усугубляется тем, что экономическая заинтересованность в доходах протокола может быть отделена от права управления: можно исказить стимулы держателей токенов DAO, подкупив их или взяв токен для голосования DAO на открытом рынке, чтобы попытаться получить достаточно права голоса для продвижения изменений, которые противоречат интересам как DAO, так и пользователей протокола.
Присутствие PAP не очень хорошо, но можно утверждать, что, если пользователи поймут, что текущий агент не представляет их достаточно хорошо, они всегда могут выйти из протокола и выбрать другого агента, который лучше соответствует их интересам, или даже решить полностью удалить агента с помощью соло-стакинга.
Это очень важный механизм, известный как голосование ногами. Теоретически, это должно защитить пользователей от негативных последствий любого несоответствия стимулов между ними и DAO или любой атаки на DAO. Однако на практике и в конкретном случае жидкого стейблинга Ethereum эффективность голосования ногами ограничена из-за ряда действующих факторов.
Первый фактор - это специфика работы PoS в Ethereum. Чтобы снять ETH с валидатора, необходимо дождаться полного выхода из валидатора, а все выходы из валидатора Ethereum обрабатываются через единую очередь с ограниченной пропускной способностью. Это означает, что время, необходимое для выхода из протокола, зависит от внешних внепротокольных факторов и может варьироваться на порядки. Это, в свою очередь, означает, что наложение статического таймлока на решения DAO не может гарантировать, что любой пользователь успеет покинуть протокол до того, как DAO применит изменение, не отвечающее его интересам.
Второй фактор заключается в том, что значительная часть пользователей выбирает ликвидный стейблинг, потому что хочет перераспределить стейблкоины в другие виды экономической деятельности, в результате чего токены ликвидного стейблинга (LST) широко используются в DeFi, включая протоколы, вывод средств из которых требует дополнительного времени (например. рынки кредитования). Это добавляет еще одну внешнюю зависимость, которая может помешать пользователям покинуть протокол в заранее установленные сроки.
Третий фактор обусловлен информационной асимметрией между пассивным большинством и активным образованным меньшинством пользователей: правильная оценка всех рисков, связанных с конкретным управленческим решением, включая хвостовые риски, требует знаний, которыми большинство пользователей не обладают. Сообщение о потенциальных негативных последствиях решения DAO через социальный слой занимает дополнительное время, что снижает вероятность того, что пассивное большинство покинет протокол до того, как решение станет исполняемым.
Lido DAO создала ряд протоколов управления для снижения информационной асимметрии (например, фреймворк GOOSE, Подгруппа операторов узлов, фреймворк LIP, обязательство по минимальному количеству аудитов любого изменения кода мейннета), но все они являются соглашениями социального уровня между текущими держателями LDO и, таким образом, не могут защитить от внешней атаки на DAO.
Конечным решением проблемы является минимизация управления и, в конечном счете, окостенение кода и параметров протокола. Нет риска управления, если ничем не управляют.
Постепенное сведение к минимуму сферы управления - это то, что авторы протокола считают необходимостью в ближайшие годы. Однако пока спецификация Ethereum не остынет, возможность обновления кода может быть снижена лишь до определенной степени (например. см. EIP-7002 5, EIP-7251 6). Кроме того, любой неизменяемый код должен быть формально проверен на уровне байткода, чтобы исключить возможность того, что ошибка компилятора приведет к появлению неисправимой уязвимости.
Существует также слой протокола fungibility, который служит механизмом оценки риска/вознаграждения и распределяет ETH между различными подмножествами валидаторов таким образом, чтобы сбалансировать доходность и риски полученного набора валидаторов. Риски здесь включают в себя хвостовые риски, которые набор валидаторов создает для сети Ethereum, например. цензурируемость и корреляционные риски сокращения. В настоящее время ведутся исследования (последнюю итерацию см. в этом отчете 6 ) на тему того, можно ли оценить эти риски протоколом с помощью гаджета-оракула, не вызывающего доверия и приносящего необходимую информацию на цепочке, но это долгосрочная работа, и пока неясно, как можно практически достичь желаемого результата. До тех пор, пока в протоколе не будет реализован такой механизм доверия, на уровне слияния должно быть определенное управление.
Еще одна потенциальная область исследований - поиск способов введения явного отказа от использования новых версий кода и наборов параметров для держателей stETH и интеграций. Пока неясно, можно ли это сделать, не нарушая взаимозаменяемость LST и не приводя к фрагментации ликвидности, что, учитывая, что ликвидность является одним из основных факторов, побуждающих пользователей к LST, уничтожит конкурентоспособность протокола по отношению к другим децентрализованным и централизованным провайдерам ликвидных ставок. Тем не менее, это интересное направление исследований.
Теперь, когда мы установили, что протоколу придется жить с каким-то управлением, по крайней мере, в среднесрочной перспективе, давайте посмотрим, как мы можем минимизировать <a href="https://notes.ethereum.org/@mikeneuder/magnitude-and-direction"> the риски, которые создает такое управление 1.
Как было отмечено в первом разделе, общая проблема может быть разложена на 1) наличие PAP и 2) ограниченную эффективность голосования ногами. Поэтому в идеале мы хотели бы внедрить некий механизм, улучшающий как согласованность между DAO и пользователями протокола, так и эффективность голосования ногами.
Именно здесь мы приходим к предлагаемой схеме двойного управления. Она направлена на следующие улучшения:
Обзор предлагаемой конструкции механизма и некоторые идеи для будущих исследований в области минимизации рисков управления можно найти в этой заметке: <a href="https://hackmd.io/@skozin/r17mlW2la"" > https://hackmd.io/@skozin/r17mlW2la 37.
Следует отметить, что стейкеры - не единственная категория пользователей протокола; существуют также операторы узлов. Одним из потенциальных будущих направлений исследований является поиск способов повысить эффективность голосования операторов узла за ноги, например. Позволяет подмножеству стейкеров и операторов узлов координировать форк протокола и DAO, перенаправляя учетные данные валидаторов на новый контракт (в настоящее время не поддерживается уровнем консенсуса).
Еще одно направление будущих исследований - изучение нетоковых и гибридных методов управления 2.
После этого должно произойти несколько событий, прежде чем дизайн будет окончательно доработан, в результате чего появится более официальное предложение по улучшению Лидо (LIP), которое будет представлено на голосование DAO и соответствующий документ Architecture Decision Record (ADR):
Эта тема направлена на достижение 3, в то время как авторы протокола работают над 1 и 2 (оба находятся в стадии разработки), поэтому любая обратная связь будет высоко оценена!
Важно подчеркнуть, что, хотя двойное управление является (по моему мнению) важным шагом в снижении рисков управления протоколом, это ни в коем случае не последний шаг. Некоторые из идей по дальнейшим улучшениям можно найти в документе по проектированию механизма, ссылка на который приведена выше, и я приглашаю всех заинтересованных обсудить эти и любые другие потенциальные улучшения, разместив тему на этом форуме.
Это продолжение начальной темы о двойном управлении 18. Ссылка на эту тему содержит важный контекст, поэтому, если у Вас есть время, прочтите ее.
С тех пор, как последняя версия дизайна механизма была предложена в этом посте 5, участники протокола, работающие над DG, сделали несколько итераций, чтобы учесть полученные отзывы и сделать механизм более простым, менее хрупким и эффективным.
Прежде чем представить обновленную версию, позвольте мне обрисовать проблему, которую мы пытаемся решить, и вкратце проследить цепочку рассуждений, которая привела нас к предлагаемому решению.
В настоящее время код протокола Lido и его параметры контролируются Lido DAO посредством голосования токенами LDO. Протокол берет 5% от вознаграждения за ставку и направляет их в казну DAO (еще 5% распределяются среди операторов узлов, участвующих в протоколе).
Хотя держатели LDO, как правило, должны быть мотивированы поддерживать благосостояние протокола, поскольку это отражается в цене токенов LDO, это не обязательно означает, что держатели LDO эффективно представляют пользователей протокола. Например, представьте, что владельцы LDO коллективно решают увеличить плату за протокол: хотя это может положительно сказаться на ближайшем благосостоянии владельцев LDO, это явно противоречит интересам, по крайней мере, некоторой части пользователей протокола.
Это можно обобщить как проблему принципала и агента (PAP) между DAO (агентом) и пользователями протокола (принципалом). Проблема существует потому, что у владельцев LDO нет таких же стимулов, как у пользователей.
Более того, как подчеркивает Виталик в своем эссе Moving beyond coin voting 9, PAP усугубляется тем, что экономическая заинтересованность в доходах протокола может быть отделена от права управления: можно исказить стимулы держателей токенов DAO, подкупив их или взяв токен для голосования DAO на открытом рынке, чтобы попытаться получить достаточно права голоса для продвижения изменений, которые противоречат интересам как DAO, так и пользователей протокола.
Присутствие PAP не очень хорошо, но можно утверждать, что, если пользователи поймут, что текущий агент не представляет их достаточно хорошо, они всегда могут выйти из протокола и выбрать другого агента, который лучше соответствует их интересам, или даже решить полностью удалить агента с помощью соло-стакинга.
Это очень важный механизм, известный как голосование ногами. Теоретически, это должно защитить пользователей от негативных последствий любого несоответствия стимулов между ними и DAO или любой атаки на DAO. Однако на практике и в конкретном случае жидкого стейблинга Ethereum эффективность голосования ногами ограничена из-за ряда действующих факторов.
Первый фактор - это специфика работы PoS в Ethereum. Чтобы снять ETH с валидатора, необходимо дождаться полного выхода из валидатора, а все выходы из валидатора Ethereum обрабатываются через единую очередь с ограниченной пропускной способностью. Это означает, что время, необходимое для выхода из протокола, зависит от внешних внепротокольных факторов и может варьироваться на порядки. Это, в свою очередь, означает, что наложение статического таймлока на решения DAO не может гарантировать, что любой пользователь успеет покинуть протокол до того, как DAO применит изменение, не отвечающее его интересам.
Второй фактор заключается в том, что значительная часть пользователей выбирает ликвидный стейблинг, потому что хочет перераспределить стейблкоины в другие виды экономической деятельности, в результате чего токены ликвидного стейблинга (LST) широко используются в DeFi, включая протоколы, вывод средств из которых требует дополнительного времени (например. рынки кредитования). Это добавляет еще одну внешнюю зависимость, которая может помешать пользователям покинуть протокол в заранее установленные сроки.
Третий фактор обусловлен информационной асимметрией между пассивным большинством и активным образованным меньшинством пользователей: правильная оценка всех рисков, связанных с конкретным управленческим решением, включая хвостовые риски, требует знаний, которыми большинство пользователей не обладают. Сообщение о потенциальных негативных последствиях решения DAO через социальный слой занимает дополнительное время, что снижает вероятность того, что пассивное большинство покинет протокол до того, как решение станет исполняемым.
Lido DAO создала ряд протоколов управления для снижения информационной асимметрии (например, фреймворк GOOSE, Подгруппа операторов узлов, фреймворк LIP, обязательство по минимальному количеству аудитов любого изменения кода мейннета), но все они являются соглашениями социального уровня между текущими держателями LDO и, таким образом, не могут защитить от внешней атаки на DAO.
Конечным решением проблемы является минимизация управления и, в конечном счете, окостенение кода и параметров протокола. Нет риска управления, если ничем не управляют.
Постепенное сведение к минимуму сферы управления - это то, что авторы протокола считают необходимостью в ближайшие годы. Однако пока спецификация Ethereum не остынет, возможность обновления кода может быть снижена лишь до определенной степени (например. см. EIP-7002 5, EIP-7251 6). Кроме того, любой неизменяемый код должен быть формально проверен на уровне байткода, чтобы исключить возможность того, что ошибка компилятора приведет к появлению неисправимой уязвимости.
Существует также слой протокола fungibility, который служит механизмом оценки риска/вознаграждения и распределяет ETH между различными подмножествами валидаторов таким образом, чтобы сбалансировать доходность и риски полученного набора валидаторов. Риски здесь включают в себя хвостовые риски, которые набор валидаторов создает для сети Ethereum, например. цензурируемость и корреляционные риски сокращения. В настоящее время ведутся исследования (последнюю итерацию см. в этом отчете 6 ) на тему того, можно ли оценить эти риски протоколом с помощью гаджета-оракула, не вызывающего доверия и приносящего необходимую информацию на цепочке, но это долгосрочная работа, и пока неясно, как можно практически достичь желаемого результата. До тех пор, пока в протоколе не будет реализован такой механизм доверия, на уровне слияния должно быть определенное управление.
Еще одна потенциальная область исследований - поиск способов введения явного отказа от использования новых версий кода и наборов параметров для держателей stETH и интеграций. Пока неясно, можно ли это сделать, не нарушая взаимозаменяемость LST и не приводя к фрагментации ликвидности, что, учитывая, что ликвидность является одним из основных факторов, побуждающих пользователей к LST, уничтожит конкурентоспособность протокола по отношению к другим децентрализованным и централизованным провайдерам ликвидных ставок. Тем не менее, это интересное направление исследований.
Теперь, когда мы установили, что протоколу придется жить с каким-то управлением, по крайней мере, в среднесрочной перспективе, давайте посмотрим, как мы можем минимизировать <a href="https://notes.ethereum.org/@mikeneuder/magnitude-and-direction"> the риски, которые создает такое управление 1.
Как было отмечено в первом разделе, общая проблема может быть разложена на 1) наличие PAP и 2) ограниченную эффективность голосования ногами. Поэтому в идеале мы хотели бы внедрить некий механизм, улучшающий как согласованность между DAO и пользователями протокола, так и эффективность голосования ногами.
Именно здесь мы приходим к предлагаемой схеме двойного управления. Она направлена на следующие улучшения:
Обзор предлагаемой конструкции механизма и некоторые идеи для будущих исследований в области минимизации рисков управления можно найти в этой заметке: <a href="https://hackmd.io/@skozin/r17mlW2la"" > https://hackmd.io/@skozin/r17mlW2la 37.
Следует отметить, что стейкеры - не единственная категория пользователей протокола; существуют также операторы узлов. Одним из потенциальных будущих направлений исследований является поиск способов повысить эффективность голосования операторов узла за ноги, например. Позволяет подмножеству стейкеров и операторов узлов координировать форк протокола и DAO, перенаправляя учетные данные валидаторов на новый контракт (в настоящее время не поддерживается уровнем консенсуса).
Еще одно направление будущих исследований - изучение нетоковых и гибридных методов управления 2.
После этого должно произойти несколько событий, прежде чем дизайн будет окончательно доработан, в результате чего появится более официальное предложение по улучшению Лидо (LIP), которое будет представлено на голосование DAO и соответствующий документ Architecture Decision Record (ADR):
Эта тема направлена на достижение 3, в то время как авторы протокола работают над 1 и 2 (оба находятся в стадии разработки), поэтому любая обратная связь будет высоко оценена!
Важно подчеркнуть, что, хотя двойное управление является (по моему мнению) важным шагом в снижении рисков управления протоколом, это ни в коем случае не последний шаг. Некоторые из идей по дальнейшим улучшениям можно найти в документе по проектированию механизма, ссылка на который приведена выше, и я приглашаю всех заинтересованных обсудить эти и любые другие потенциальные улучшения, разместив тему на этом форуме.