В последнее время многие обсуждения в Твиттере вращаются вокруг децентрализации L2. Достаточно ли децентрализованы накопительные пакеты, которые мы создаем? Или они хотя бы на пути к децентрализации? Это имеет значение?
Идея Rollup проста: мы хотим, чтобы участники вне сети могли проводить транзакции, которые затем можно было бы легко проверить в сети. С помощью Rollup базовый уровень позволяет использовать свою базу «доверия» для действий, которые происходят за пределами его непосредственной сферы. Взамен Rollup платит небольшую плату (арендную плату) за использование этого доверия.
Так нужны ли нам децентрализованные роллапы?
Интуитивный ответ - да! Именно в этом духе мы строим блокчейн.
Однако я считаю, что ответ на этот вопрос не может быть простым да или нет. Вместо этого он имеет несколько аспектов, которые необходимо анализировать по отдельности. В следующих главах я рассмотрю этот вопрос с трех точек зрения: философской, технологической и экономической. ****Эти три пункта не обязательно являются исчерпывающими или исключительными, но они должны давать хорошее общее представление о проблеме. **
1. Философская перспектива
Давайте начнем с разговора на более высокий уровень — зачем нам децентрализация?
Потому что мы хотим будущего без разрешений, которое способствует открытым инновациям. Мы хотим, чтобы пользователи могли создавать новые вещи без каких-либо ограничений и без необходимости доверять какой-либо отдельной сущности.
За короткую историю блокчейна у нас было много анонимных разработчиков, создававших удивительные вещи. Фактически, сам биткойн был создан анонимным лицом — скоро он может стать валютой, которую большинство людей в мире использует для глобальных платежей! В этом сила беспрепятственных инноваций!
Блокчейн позволяет нам сотрудничать с людьми, у которых нет ничего общего, и мы знаем, что у них нет возможности подорвать это доверие — Престон Эванс
Децентрализованная основа ненадежных сетей, таких как Биткойн и Эфириум, позволяет нам строить такое будущее. Тогда очевидно, что любая цепочка, имеющая доверительные отношения с этими цепочками, например Rollups, также должна быть децентрализована!
На самом деле возникает интересный и важный вопрос:
**Если Rollup не децентрализован, значит ли это, что Ethereum не децентрализован? **
Немного оптимистичный взгляд на это заключается в том, что в мире без разрешений накопительным пакетам должно быть разрешено создавать все, что они хотят, включая (но не ограничиваясь) полностью разрешенные цепочки, и пользователи этого накопительного пакета должны по-прежнему иметь возможность использовать безопасность в базовый слой. Даже разрешенные цепочки должны быть безопасными для использования, пока базовый уровень децентрализован, а объединение «полностью» реализовано (мы поговорим о «полностью реализовано» в техническом разделе).
Но реальность такова, что большинство сегодняшних роллапов еще не достигли стадии полной реализации и не обеспечивают пользователям желаемого уровня безопасности и недоверия.
Итак, как же выглядит правильная реализация rollup? Давайте посмотрим:
2. Технология
Чтобы по-настоящему понять проблему децентрализации и безопасности на уровне Rollup, нам нужно взглянуть на нее с первых принципов. Не многие люди могут объяснить основные принципы блокчейна лучше, чем Шрирам Каннан.
Блокчейн — это распределенный реестр, в котором различные узлы в сети следуют определенному протоколу, чтобы достичь консенсуса в отношении состояния реестра. В зависимости от того, как эти узлы видят сеть, у них могут быть разные правила подтверждения правильного состояния сети в их собственном реестре.
Например, в протоколе Ethereum Gasper есть два разных правила подтверждения — доступное правило (на основе самой тяжелой цепочки) и окончательное правило (на основе блоков, подтвержденных гаджетом).
Полные узлы имеют другие правила подтверждения, особенно в сводках, чем легкие клиенты. В традиционном объединении смарт-контрактов (SCR) смарт-контракт (проверочный мост) имеет свои собственные правила подтверждения. Если неблагоприятных событий нет, эти правила подтверждения в конечном итоге совпадают в так называемых «областях согласованности». Как следует из названия, в зонах консенсуса все участники имеют одинаковое представление о сети (и имеют одинаковую историю в своих реестрах).
Если все правила подтверждения безопасны, ничего плохого не произойдет. Как поделился Sreeram в сообщении выше, 5 свойств в основном определяют безопасность этих правил подтверждения.
Рост реестра — цепочка свертки должна продолжать расти (живучесть)
Защита от цензуры — все пользователи должны иметь возможность включать любые транзакции в базовый уровень
Сопротивление реструктуризации — транзакцию не следует восстанавливать после ее завершения
Доступность данных — данные о транзакциях должны быть где-то опубликованы
Действительность — транзакции и переходы между состояниями должны быть действительными
Первые 2 свойства вместе определяют «живое» состояние системы, а последние 3 свойства определяют «безопасное» состояние.
Давайте посмотрим на каждый из них с точки зрения различных участников агрегации и посмотрим, какие из них можно смягчить без децентрализации.
Разные участники полагаются на разные механизмы обеспечения безопасности и жизнеспособности.
Полный узел:
Если вы запускаете полный узел, у вас есть доступ к опубликованным данным и вы можете проверить их напрямую. Затем вы можете использовать эти данные для самостоятельного выполнения транзакций и определения достоверности транзакций и конечного состояния свертки после этих транзакций.
Остальными условиями безопасности, таким образом, являются свойства активности и устойчивость к рекомбинации. В последнем случае полные узлы полагаются на валидаторы базовой цепочки и протокол консенсуса, который они используют, в то время как для свойств живучести полные узлы полагаются на реализации секвенсора и свертки.
Легкий клиент:
Большинство пользователей используют кошельки, встроенные в легкие узлы, или используют сторонние сервисы для получения данных блокчейна и взаимодействия с блокчейном. Световые узлы могут быть различных типов:
State Validator — проверка правильности переходов между состояниями
DA Validator — проверяет доступность данных
**проверка консенсуса — проверка подтверждения консенсуса базового уровня или **
полный верификатор — проверяет все вышеперечисленное
Если вы запускаете легкий клиент с полным валидатором, вы можете проверить доступность данных с помощью выборки доступности данных, вы можете проверить действительность переходов состояний с помощью доказательств достоверности или доказательств мошенничества, вы также можете проверить, что состояние было завершено на базе Консенсус уровня (в Ethereum это можно сделать, следуя комитету по синхронизации).
Оставшееся условие безопасности — это свойство живучести, и легкие клиенты полагаются на реализации секвенсора и свертки.
Встроенный смарт-контракт (проверочный мост):
В традиционном SCR «правило подтверждения» смарт-контракта заключается в применении всех 5 свойств безопасности:
Рост реестра благодаря протоколу замены секвенсора
Сопротивляйтесь цензуре, добиваясь включения
Создавать сопротивление реорганизации только поверх предыдущего состояния
Доступность данных достигается за счет отправки DA на базовом уровне
Проверка действительности с помощью доказательства действительности/мошенничества
Полные узлы SCR полагаются на смарт-контракты для обеспечения свойств живучести. Они «поглощают» сопротивление реструктуризации базового слоя.
Легкие узлы полагаются на смарт-контракты для улучшения свойств жизнеспособности и поглощения DA и сопротивления реорганизации от базового уровня. Они могут проверить подтверждение действительности самостоятельно или с помощью смарт-контрактов.
Консенсус SCR заключается в том, чтобы следовать канонической цепочке, определенной смарт-контрактом.
** А как насчет Sovereign Rollup? **
Суверенные накопительные пакеты не имеют смарт-контрактов (проверочных мостов) для обеспечения соблюдения условий действительности или жизнеспособности. Вместо этого они окажутся «свернутыми» к нижестоящему узлу свертки. Эти узлы по-прежнему поглощают сопротивление DA и Reorg от базового слоя.
Так же, как и в SCR, в суверенных узлах объединения требуется некоторый механизм для реализации свойства живучести. Чтобы определить каноническую цепочку, они выбрали независимые механизмы, такие как широковещательная передача доказательств p2p.
Какое отношение все это имеет к децентрализации?
Будь то накопительный пакет смарт-контрактов или суверенный накопительный пакет, свойство живучести зависит от правильной реализации накопительного пакета. Как мы видели выше, правильная реализация агрегации должна включать два важных компонента:
механизмы обязательного включения и
Протокол замены секвенсора
Обязательное включение помогает укрепить сопротивление цензуре. Этот механизм позволяет пользователям «принудительно включать» свои транзакции непосредственно в базовый уровень. Затем любой пользователь в накопительном пакете может принудительно вернуться на базовый уровень со своими средствами. Следовательно, даже если есть только один централизованный узел подборки для агрегации, он не может подвергнуть цензуре пользователей, пока существует зрелый механизм принудительного применения.
Но достаточно ли этого?
Даже если пользователи могут выйти из системы, это может означать, что если большинство пользователей вернутся к L1, у предприятия не будет особого стимула продолжать работу. Кроме того, механизм обязательного включения обычно имеет длительное время ожидания и может быть довольно дорогим в реализации для обычного пользователя. Сопротивление цензуре, обеспечиваемое этим механизмом, не совсем практично (или в режиме реального времени). Эту ситуацию можно назвать «слабой цензурой».
Затем у нас есть последний атрибут живучести — рост леджера
Если централизованный подборщик станет вредоносным, он может остановить рост сводной цепочки, просто остановив производство блоков. Если это произойдет, пользователь или компания ничего не смогут сделать, чтобы снова «оживить» накопительный пакет.
Чтобы решить эту проблему, нам нужен протокол замены секвенсора.
Идея протокола замены секвенсора заключается в том, что если секвенсор ведет себя злонамеренно, совокупное управление может запустить секвенсор. Один из способов добиться этого — заменить централизованные узлы секвенсора децентрализованным протоколом секвенсора. Если сортировщик децентрализован и не монополизирует строительные блоки объединения, остановить объединение практически невозможно.
Таким образом, в то время как пользовательские средства всегда в безопасности в Rollups благодаря механизму обязательного включения, создание надежного протокола замены заказчика помогает поддерживать Rollups в рабочем состоянии и обеспечивает практическую защиту от цензуры в режиме реального времени.
это все?
Не совсем. С технической точки зрения есть еще один аспект, который следует учитывать:
Что, если бы сами смарт-контракты могли быть обновлены объединенным центральным комитетом? Допустим, накопительные пакеты в настоящее время реализованы правильно, но завтра комитет соглашается, что нам больше не нужны смарт-контракты, а вместо этого транслируются доказательства состояния накопительных пакетов в сеть p2p.
Если вы, как пользователь накопительного пакета, не согласны на такое обновление, вы должны иметь возможность выйти из накопительного пакета до того, как обновление будет реализовано (хотя, опять же, это нехорошо для пользователя и может плохо сказаться на бизнесе). Этого можно достичь с помощью «отложенных обновлений управления». Это как бы "период уведомления", после которого обновление будет реализовано. Пользователи, не согласные с обновлениями, могут отказаться в течение периода уведомления.
Крайняя степень децентрализации — это возможность иметь полностью неизменяемые смарт-контракты. Эти контракты не регулируются каким-либо кошельком с мультиподписью или другим комитетом, и после развертывания их нельзя будет обновить.
Конечно, в этом есть свои проблемы. Если в коде есть какие-либо ошибки или какое-то важное событие требует обновления смарт-контракта, единственный вариант для узла агрегации — это разветвление на новый смарт-контракт, оставляя средства пользователя в старом контракте.
Текущее состояние
К сожалению, текущее состояние Rollup далеко от полной реализации, о которой мы говорили выше. Большинство накопительных пакетов все еще находятся на стадии «тренировочных колес», пытаясь сделать все правильно.
Согласно L2BEAT, Fuel v1 и DeGate — единственные два агрегата, которые созрели для достижения всех условий активности и безопасности.
3. Экономика
Давайте посмотрим на экономику Rollup с точки зрения пользователей и операторов Rollup:
1) Пользовательский опыт — пользователи должны получать низкие цены и не должны слишком долго ждать транзакций.
2) Прибыль от агрегации — сортировщикам и держателям токенов должно быть выгодно работать с агрегацией.
Пользовательский опыт оптимизируется, когда пользователи получают быстрые и дешевые транзакции.
Скорость, с которой завершаются транзакции, зависит от скорости, с которой завершаются блоки базового уровня. Транзакции могут считаться окончательными всякий раз, когда данные на L1 завершены. Однако пользователи, использующие полные узлы, также могут добиться мгновенной завершенности, просто выполнив транзакции и определив конечное состояние.
Но не для всех практично запускать полный узел. Таким образом, централизованный подборщик полезен, поскольку он может предоставить пользователям «мягкое подтверждение» того, что их транзакция включена в блок и будет завершена. Этого достаточно для большинства случаев использования. Однако это предполагает опору на центральную партию, которая может действовать против нее.
В то время как некоторые альтернативные протокольные решения секвенсора (например, основанные на Rollups) отказываются от этого свойства в ущерб пользователям, другие решения (например, внешний консенсус POS (например, Espresso)) могут предоставлять аналогичные гарантии предварительного подтверждения, не подвергаясь следующему риску: централизованные секвенсоры.
Как насчет стоимости для пользователя?
Явная цена транзакции Rollup обычно составляет:
Стоимость газа L2 = Стоимость газа L1 + Плата за секвенсор
Централизованный заказчик, действующий рационально, всегда стремится максимизировать собственную прибыль, даже если это означает перекладывание более высоких затрат на пользователей. Однако стоит отметить, что это также не обязательно может быть решено с помощью децентрализованного механизма сортировки. Даже POS-узлы в децентрализованном ордере хотят максимизировать свою прибыль.
На самом деле это создает проблему рассогласования, когда агрегат может не захотеть передавать прибыль внешнему сортировщику.
Прибыль от агрегирования. Помимо комиссий за секвенсор, Rollup также может получать прибыль, извлекая MEV из массовых пользовательских транзакций. Этот MEV часто трудно атрибутировать, потому что трудно выяснить, включил ли заказчик какие-либо из своих собственных предварительных транзакций в пакет.
** Если накопительный пакет будет заменен внешним консенсусом POS, они передадут этот MEV внешним операторам. **
Стоит отметить, что обе эти проблемы, связанные с передачей дохода от накопительных транзакций внешним механизмам, могут быть решены с помощью «торговых соглашений» между накопительными средствами и внешними механизмами, в которых могут быть разрешены сборы и MEV, генерируемые внутренними и перекрестными транзакциями агрегированных транзакций. Перенаправляет обратно к сводке.
Однако, как объяснялось в выступлении Джона Шарбонно во время модульного саммита и в последующих сообщениях, лучше было бы иметь сводный порядок делегатов управления для набора разрешенных узлов. Эти узлы могут быть стратегически выбраны так, чтобы они были географически рассредоточены, и управление может просто выгнать злоумышленников.
**Это может быть решение «две птицы – одна цель», так как оно позволяет агрегировать маржу внутри компании, а также смягчает неблагоприятные последствия централизованных сортировщиков. **
Но противоположность этому заключается в том, что при ограниченной ротации сортировщиков сортировщики могут вести себя неблизоруко, что может привести к монопольному ценообразованию/взвинчиванию цен за счет пользователей агрегации.
В любом случае ясно, что необходим какой-то протокол замены секвенсора, чтобы суммирование было рентабельным для пользователей. Является ли это доказательством управления, механизмом внешнего консенсуса или чем-то еще, это обсуждение для другой статьи.
4. Вывод
Надеюсь, теперь стало ясно, что какой бы путь ни выбрал Rollup, крайне важно, чтобы целью была полная реализация с зрелыми механизмами замены сортировщика, принудительного включения и обновлений управления отставанием. Даже если это просто обязательное включение и отложенные обновления, пользовательские средства в безопасности, когда Rollup полностью реализован, независимо от того, является ли координатор централизованным.
Однако надежный протокол замены секвенсора может улучшить гарантии жизнеспособности и потенциально улучшить экономические показатели пользователей Rollup.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Взгляните на важность децентрализации Rollup с трех точек зрения
Автор: Шиваншу Мадан; Составитель: Huohuo/Vernacular Blockchain
В последнее время многие обсуждения в Твиттере вращаются вокруг децентрализации L2. Достаточно ли децентрализованы накопительные пакеты, которые мы создаем? Или они хотя бы на пути к децентрализации? Это имеет значение?
Идея Rollup проста: мы хотим, чтобы участники вне сети могли проводить транзакции, которые затем можно было бы легко проверить в сети. С помощью Rollup базовый уровень позволяет использовать свою базу «доверия» для действий, которые происходят за пределами его непосредственной сферы. Взамен Rollup платит небольшую плату (арендную плату) за использование этого доверия.
Так нужны ли нам децентрализованные роллапы?
Интуитивный ответ - да! Именно в этом духе мы строим блокчейн.
Однако я считаю, что ответ на этот вопрос не может быть простым да или нет. Вместо этого он имеет несколько аспектов, которые необходимо анализировать по отдельности. В следующих главах я рассмотрю этот вопрос с трех точек зрения: философской, технологической и экономической. ****Эти три пункта не обязательно являются исчерпывающими или исключительными, но они должны давать хорошее общее представление о проблеме. **
1. Философская перспектива
Давайте начнем с разговора на более высокий уровень — зачем нам децентрализация?
Потому что мы хотим будущего без разрешений, которое способствует открытым инновациям. Мы хотим, чтобы пользователи могли создавать новые вещи без каких-либо ограничений и без необходимости доверять какой-либо отдельной сущности.
За короткую историю блокчейна у нас было много анонимных разработчиков, создававших удивительные вещи. Фактически, сам биткойн был создан анонимным лицом — скоро он может стать валютой, которую большинство людей в мире использует для глобальных платежей! В этом сила беспрепятственных инноваций!
Децентрализованная основа ненадежных сетей, таких как Биткойн и Эфириум, позволяет нам строить такое будущее. Тогда очевидно, что любая цепочка, имеющая доверительные отношения с этими цепочками, например Rollups, также должна быть децентрализована!
На самом деле возникает интересный и важный вопрос:
**Если Rollup не децентрализован, значит ли это, что Ethereum не децентрализован? **
Немного оптимистичный взгляд на это заключается в том, что в мире без разрешений накопительным пакетам должно быть разрешено создавать все, что они хотят, включая (но не ограничиваясь) полностью разрешенные цепочки, и пользователи этого накопительного пакета должны по-прежнему иметь возможность использовать безопасность в базовый слой. Даже разрешенные цепочки должны быть безопасными для использования, пока базовый уровень децентрализован, а объединение «полностью» реализовано (мы поговорим о «полностью реализовано» в техническом разделе).
Но реальность такова, что большинство сегодняшних роллапов еще не достигли стадии полной реализации и не обеспечивают пользователям желаемого уровня безопасности и недоверия.
Итак, как же выглядит правильная реализация rollup? Давайте посмотрим:
2. Технология
Чтобы по-настоящему понять проблему децентрализации и безопасности на уровне Rollup, нам нужно взглянуть на нее с первых принципов. Не многие люди могут объяснить основные принципы блокчейна лучше, чем Шрирам Каннан.
Блокчейн — это распределенный реестр, в котором различные узлы в сети следуют определенному протоколу, чтобы достичь консенсуса в отношении состояния реестра. В зависимости от того, как эти узлы видят сеть, у них могут быть разные правила подтверждения правильного состояния сети в их собственном реестре.
Например, в протоколе Ethereum Gasper есть два разных правила подтверждения — доступное правило (на основе самой тяжелой цепочки) и окончательное правило (на основе блоков, подтвержденных гаджетом).
Полные узлы имеют другие правила подтверждения, особенно в сводках, чем легкие клиенты. В традиционном объединении смарт-контрактов (SCR) смарт-контракт (проверочный мост) имеет свои собственные правила подтверждения. Если неблагоприятных событий нет, эти правила подтверждения в конечном итоге совпадают в так называемых «областях согласованности». Как следует из названия, в зонах консенсуса все участники имеют одинаковое представление о сети (и имеют одинаковую историю в своих реестрах).
Если все правила подтверждения безопасны, ничего плохого не произойдет. Как поделился Sreeram в сообщении выше, 5 свойств в основном определяют безопасность этих правил подтверждения.
Первые 2 свойства вместе определяют «живое» состояние системы, а последние 3 свойства определяют «безопасное» состояние.
Давайте посмотрим на каждый из них с точки зрения различных участников агрегации и посмотрим, какие из них можно смягчить без децентрализации.
Разные участники полагаются на разные механизмы обеспечения безопасности и жизнеспособности.
Полный узел:
Если вы запускаете полный узел, у вас есть доступ к опубликованным данным и вы можете проверить их напрямую. Затем вы можете использовать эти данные для самостоятельного выполнения транзакций и определения достоверности транзакций и конечного состояния свертки после этих транзакций.
Остальными условиями безопасности, таким образом, являются свойства активности и устойчивость к рекомбинации. В последнем случае полные узлы полагаются на валидаторы базовой цепочки и протокол консенсуса, который они используют, в то время как для свойств живучести полные узлы полагаются на реализации секвенсора и свертки.
Легкий клиент:
Большинство пользователей используют кошельки, встроенные в легкие узлы, или используют сторонние сервисы для получения данных блокчейна и взаимодействия с блокчейном. Световые узлы могут быть различных типов:
Если вы запускаете легкий клиент с полным валидатором, вы можете проверить доступность данных с помощью выборки доступности данных, вы можете проверить действительность переходов состояний с помощью доказательств достоверности или доказательств мошенничества, вы также можете проверить, что состояние было завершено на базе Консенсус уровня (в Ethereum это можно сделать, следуя комитету по синхронизации).
Оставшееся условие безопасности — это свойство живучести, и легкие клиенты полагаются на реализации секвенсора и свертки.
Встроенный смарт-контракт (проверочный мост):
В традиционном SCR «правило подтверждения» смарт-контракта заключается в применении всех 5 свойств безопасности:
Полные узлы SCR полагаются на смарт-контракты для обеспечения свойств живучести. Они «поглощают» сопротивление реструктуризации базового слоя.
Легкие узлы полагаются на смарт-контракты для улучшения свойств жизнеспособности и поглощения DA и сопротивления реорганизации от базового уровня. Они могут проверить подтверждение действительности самостоятельно или с помощью смарт-контрактов.
Консенсус SCR заключается в том, чтобы следовать канонической цепочке, определенной смарт-контрактом.
** А как насчет Sovereign Rollup? **
Суверенные накопительные пакеты не имеют смарт-контрактов (проверочных мостов) для обеспечения соблюдения условий действительности или жизнеспособности. Вместо этого они окажутся «свернутыми» к нижестоящему узлу свертки. Эти узлы по-прежнему поглощают сопротивление DA и Reorg от базового слоя.
Так же, как и в SCR, в суверенных узлах объединения требуется некоторый механизм для реализации свойства живучести. Чтобы определить каноническую цепочку, они выбрали независимые механизмы, такие как широковещательная передача доказательств p2p.
Какое отношение все это имеет к децентрализации?
Будь то накопительный пакет смарт-контрактов или суверенный накопительный пакет, свойство живучести зависит от правильной реализации накопительного пакета. Как мы видели выше, правильная реализация агрегации должна включать два важных компонента:
механизмы обязательного включения и
Протокол замены секвенсора
Обязательное включение помогает укрепить сопротивление цензуре. Этот механизм позволяет пользователям «принудительно включать» свои транзакции непосредственно в базовый уровень. Затем любой пользователь в накопительном пакете может принудительно вернуться на базовый уровень со своими средствами. Следовательно, даже если есть только один централизованный узел подборки для агрегации, он не может подвергнуть цензуре пользователей, пока существует зрелый механизм принудительного применения.
Но достаточно ли этого?
Даже если пользователи могут выйти из системы, это может означать, что если большинство пользователей вернутся к L1, у предприятия не будет особого стимула продолжать работу. Кроме того, механизм обязательного включения обычно имеет длительное время ожидания и может быть довольно дорогим в реализации для обычного пользователя. Сопротивление цензуре, обеспечиваемое этим механизмом, не совсем практично (или в режиме реального времени). Эту ситуацию можно назвать «слабой цензурой».
Затем у нас есть последний атрибут живучести — рост леджера
Если централизованный подборщик станет вредоносным, он может остановить рост сводной цепочки, просто остановив производство блоков. Если это произойдет, пользователь или компания ничего не смогут сделать, чтобы снова «оживить» накопительный пакет.
Чтобы решить эту проблему, нам нужен протокол замены секвенсора.
Идея протокола замены секвенсора заключается в том, что если секвенсор ведет себя злонамеренно, совокупное управление может запустить секвенсор. Один из способов добиться этого — заменить централизованные узлы секвенсора децентрализованным протоколом секвенсора. Если сортировщик децентрализован и не монополизирует строительные блоки объединения, остановить объединение практически невозможно.
Таким образом, в то время как пользовательские средства всегда в безопасности в Rollups благодаря механизму обязательного включения, создание надежного протокола замены заказчика помогает поддерживать Rollups в рабочем состоянии и обеспечивает практическую защиту от цензуры в режиме реального времени.
это все?
Не совсем. С технической точки зрения есть еще один аспект, который следует учитывать:
Что, если бы сами смарт-контракты могли быть обновлены объединенным центральным комитетом? Допустим, накопительные пакеты в настоящее время реализованы правильно, но завтра комитет соглашается, что нам больше не нужны смарт-контракты, а вместо этого транслируются доказательства состояния накопительных пакетов в сеть p2p.
Если вы, как пользователь накопительного пакета, не согласны на такое обновление, вы должны иметь возможность выйти из накопительного пакета до того, как обновление будет реализовано (хотя, опять же, это нехорошо для пользователя и может плохо сказаться на бизнесе). Этого можно достичь с помощью «отложенных обновлений управления». Это как бы "период уведомления", после которого обновление будет реализовано. Пользователи, не согласные с обновлениями, могут отказаться в течение периода уведомления.
Крайняя степень децентрализации — это возможность иметь полностью неизменяемые смарт-контракты. Эти контракты не регулируются каким-либо кошельком с мультиподписью или другим комитетом, и после развертывания их нельзя будет обновить.
Конечно, в этом есть свои проблемы. Если в коде есть какие-либо ошибки или какое-то важное событие требует обновления смарт-контракта, единственный вариант для узла агрегации — это разветвление на новый смарт-контракт, оставляя средства пользователя в старом контракте.
Текущее состояние
К сожалению, текущее состояние Rollup далеко от полной реализации, о которой мы говорили выше. Большинство накопительных пакетов все еще находятся на стадии «тренировочных колес», пытаясь сделать все правильно.
Согласно L2BEAT, Fuel v1 и DeGate — единственные два агрегата, которые созрели для достижения всех условий активности и безопасности.
3. Экономика
Давайте посмотрим на экономику Rollup с точки зрения пользователей и операторов Rollup:
1) Пользовательский опыт — пользователи должны получать низкие цены и не должны слишком долго ждать транзакций.
2) Прибыль от агрегации — сортировщикам и держателям токенов должно быть выгодно работать с агрегацией.
Пользовательский опыт оптимизируется, когда пользователи получают быстрые и дешевые транзакции.
Скорость, с которой завершаются транзакции, зависит от скорости, с которой завершаются блоки базового уровня. Транзакции могут считаться окончательными всякий раз, когда данные на L1 завершены. Однако пользователи, использующие полные узлы, также могут добиться мгновенной завершенности, просто выполнив транзакции и определив конечное состояние.
Но не для всех практично запускать полный узел. Таким образом, централизованный подборщик полезен, поскольку он может предоставить пользователям «мягкое подтверждение» того, что их транзакция включена в блок и будет завершена. Этого достаточно для большинства случаев использования. Однако это предполагает опору на центральную партию, которая может действовать против нее.
В то время как некоторые альтернативные протокольные решения секвенсора (например, основанные на Rollups) отказываются от этого свойства в ущерб пользователям, другие решения (например, внешний консенсус POS (например, Espresso)) могут предоставлять аналогичные гарантии предварительного подтверждения, не подвергаясь следующему риску: централизованные секвенсоры.
Как насчет стоимости для пользователя?
Явная цена транзакции Rollup обычно составляет:
Стоимость газа L2 = Стоимость газа L1 + Плата за секвенсор
Централизованный заказчик, действующий рационально, всегда стремится максимизировать собственную прибыль, даже если это означает перекладывание более высоких затрат на пользователей. Однако стоит отметить, что это также не обязательно может быть решено с помощью децентрализованного механизма сортировки. Даже POS-узлы в децентрализованном ордере хотят максимизировать свою прибыль.
На самом деле это создает проблему рассогласования, когда агрегат может не захотеть передавать прибыль внешнему сортировщику.
Прибыль от агрегирования. Помимо комиссий за секвенсор, Rollup также может получать прибыль, извлекая MEV из массовых пользовательских транзакций. Этот MEV часто трудно атрибутировать, потому что трудно выяснить, включил ли заказчик какие-либо из своих собственных предварительных транзакций в пакет.
** Если накопительный пакет будет заменен внешним консенсусом POS, они передадут этот MEV внешним операторам. **
Стоит отметить, что обе эти проблемы, связанные с передачей дохода от накопительных транзакций внешним механизмам, могут быть решены с помощью «торговых соглашений» между накопительными средствами и внешними механизмами, в которых могут быть разрешены сборы и MEV, генерируемые внутренними и перекрестными транзакциями агрегированных транзакций. Перенаправляет обратно к сводке.
Однако, как объяснялось в выступлении Джона Шарбонно во время модульного саммита и в последующих сообщениях, лучше было бы иметь сводный порядок делегатов управления для набора разрешенных узлов. Эти узлы могут быть стратегически выбраны так, чтобы они были географически рассредоточены, и управление может просто выгнать злоумышленников.
**Это может быть решение «две птицы – одна цель», так как оно позволяет агрегировать маржу внутри компании, а также смягчает неблагоприятные последствия централизованных сортировщиков. **
Но противоположность этому заключается в том, что при ограниченной ротации сортировщиков сортировщики могут вести себя неблизоруко, что может привести к монопольному ценообразованию/взвинчиванию цен за счет пользователей агрегации.
В любом случае ясно, что необходим какой-то протокол замены секвенсора, чтобы суммирование было рентабельным для пользователей. Является ли это доказательством управления, механизмом внешнего консенсуса или чем-то еще, это обсуждение для другой статьи.
4. Вывод
Надеюсь, теперь стало ясно, что какой бы путь ни выбрал Rollup, крайне важно, чтобы целью была полная реализация с зрелыми механизмами замены сортировщика, принудительного включения и обновлений управления отставанием. Даже если это просто обязательное включение и отложенные обновления, пользовательские средства в безопасности, когда Rollup полностью реализован, независимо от того, является ли координатор централизованным.
Однако надежный протокол замены секвенсора может улучшить гарантии жизнеспособности и потенциально улучшить экономические показатели пользователей Rollup.