В последнее время многие обсуждения в Crypto Twitter вращаются вокруг децентрализации L2. Достаточно ли децентрализован накопительный пакет, который мы создаем? Они уже на пути к децентрализации? Это имеет значение?
Я рассмотрю эти темы в этой статье. Прежде чем я углублюсь, если вы еще не знаете, как на самом деле работают Rollup, я предлагаю вам быстро прочитать эту статью: Rollups для чайников.
Идея Rollup на самом деле довольно проста: он хочет, чтобы участники вне сети проводили транзакции, которые затем можно было бы легко проверить в сети. С помощью Rollup «доверие» базового уровня распространяется на действия за пределами его блокчейна. Взамен Rollup платит небольшую плату (арендную плату) за использование этого доверия.
Так нужен ли нам децентрализованный Rollup?
Интуитивный ответ: обязательно нужно! Это дух блокчейна.
Однако я также считаю, что ответ на этот вопрос не может быть простым «да» или «нет». Скорее, он охватывает несколько аспектов, которые необходимо анализировать по отдельности. Далее я рассмотрю этот вопрос с трех точек зрения: философии, технологии и экономики.
Философская перспектива
Давайте начнем с разговора на более высокий уровень: зачем нам децентрализация?
Потому что мы хотим будущего без разрешений, которое способствует открытым инновациям. Мы хотим, чтобы пользователи могли создавать новые вещи без каких-либо ограничений и без необходимости доверять какой-либо отдельной сущности.
За короткую историю блокчейна у нас было много анонимных разработчиков, создававших удивительные вещи. Фактически, сам биткойн был создан анонимным лицом, и вскоре он может стать глобальной платежной валютой, используемой большей частью мира. В этом сила беспрепятственных инноваций!
Блокчейн позволяет нам работать с людьми, у которых нет ничего общего, и мы знаем, что у них нет возможности подорвать это доверие.
—— Престон Эванс
Децентрализованная основа ненадежных сетей, таких как Биткойн и Эфириум, позволяет нам строить такое будущее. Очевидно, что любая цепочка, имеющая доверительные отношения с этими блокчейнами, например Rollup, также должна быть децентрализована!
На самом деле возникает интересный и важный вопрос:
Если Rollup не децентрализован, значит ли это, что Ethereum не децентрализован?
Несколько оптимистичный взгляд на это заключается в том, что в мире без разрешений накопительным пакетам должно быть разрешено создавать все, что они хотят, включая (но не ограничиваясь) разрешенные цепочки, и пользователи этого накопительного пакета по-прежнему смогут использовать базовый уровень безопасности. . Пока базовый уровень децентрализован, а Rollup «полностью реализован» (подробнее о «полной реализации» мы поговорим в техническом разделе), даже разрешенные цепочки должны быть безопасными для использования.
Но реальность такова, что большинство накопительных пакетов сегодня еще не достигли стадии полной реализации и не обеспечивают пользователям необходимый уровень безопасности и надежности.
Чтобы по-настоящему понять проблемы децентрализации и безопасности Rollup, нам нужно взглянуть на него с первых принципов. Мало кто может объяснить основные принципы блокчейна лучше Шрирама Каннана.
Блокчейн — это распределенная книга, и разные узлы в сети следуют заранее определенным правилам протокола, чтобы достичь консенсуса в отношении состояния книги. В зависимости от того, как эти узлы видят сеть, у них могут быть разные правила для подтверждения правильного состояния их собственной леджерной сети.
Полные узлы и легкие клиенты, особенно в Rollup, имеют разные правила подтверждения. В традиционном смарт-контракте Rollup (SCR) смарт-контракт (проверочный мост) имеет свои собственные правила подтверждения. Если неблагоприятных событий нет, эти правила подтверждения в конечном итоге совпадают в так называемых «областях согласованности». Как следует из названия, в зоне консенсуса все участники имеют одинаковое представление о сети (и одинаковую историю в леджере).
Если все правила подтверждения безопасны, ничего плохого не произойдет. Как поделился Sreeram в сообщении выше, 5 свойств в основном определяют безопасность этих правил подтверждения.
Рост леджера — цепочка свертки должна продолжать расти (живучесть)
Устойчивость к цензуре — все пользователи должны иметь возможность включить любую транзакцию в базовый уровень
Устойчивость к реструктуризации - транзакции не могут быть отозваны после завершения
Доступность данных - данные о транзакциях должны быть где-то опубликованы
Валидность - транзакции и переходы между состояниями должны быть действительными
Первые 2 свойства определяют «живое» состояние системы, а последние 3 свойства определяют «безопасное» состояние.
Давайте рассмотрим эти проблемы с точки зрения разных участников Rollup и посмотрим, какие из них можно смягчить без децентрализации.
Разные участники полагаются на разные механизмы обеспечения безопасности и жизнеспособности.
Полный узел:
Если вы запускаете полный узел, у вас есть доступ к опубликованным данным и вы можете проверить их напрямую. Затем вы можете использовать эти данные для самостоятельного выполнения транзакций и определения достоверности транзакций и окончательного состояния свертки после этих транзакций.
Остальными условиями безопасности, таким образом, являются активность и устойчивость к рекомбинации. Для устойчивости к реорганизации полные узлы полагаются на валидаторы базовой цепочки и протокол консенсуса, который он использует, в то время как для обеспечения жизнеспособности полные узлы полагаются на реализацию Sequencer и Rollup.
Легкий клиент:
Большинство пользователей взаимодействуют с блокчейном, используя легкие клиенты для получения данных блокчейна. Световые узлы бывают нескольких типов:
Валидаторы состояний — проверяют правильность переходов между состояниями
Data Availability Verifier — проверка доступности данных
Полный валидатор - проверяет все вышеперечисленное
Если вы запускаете облегченный клиент полного валидатора, вы можете проверить, доступны ли данные с помощью выборки доступности данных, проверить правильность переходов состояний с помощью доказательств достоверности или доказательств мошенничества, а также проверить, соответствует ли состояние консенсусу базового уровня (в Ethereum выше). , можно сделать, следуя комитету по синхронизации).
Тогда оставшееся условие безопасности — живость, а легкий клиент зависит от секвенсора и реализации Rollup.
Встроенный смарт-контракт (проверочный мост):
В традиционном SCR «правило подтверждения» смарт-контракта заключается в применении всех 5 свойств безопасности:
Рост реестра благодаря протоколу замены секвенсора
Сопротивляйтесь цензуре, добиваясь включения
Опирается на предыдущее состояние для антирекомбинации
Реализуйте доступность данных, отправив DA на базовый уровень
*Действительность подтверждается доказательством действительности/мошенничества
Полные узлы SCR полагаются на смарт-контракты для обеспечения соблюдения свойств живучести. Они получают сопротивление реорганизации от базового слоя.
Легкие узлы полагаются на смарт-контракты для улучшения свойств жизнеспособности и поглощения DA и сопротивления реорганизации от базового уровня. Они могут проверять доказательства действительности самостоятельно или с помощью смарт-контрактов.
Консенсус SCR заключается в том, чтобы следовать канонической цепочке, определенной смарт-контрактом.
А как насчет суверенных роллапов?
Суверенные накопительные пакеты не имеют смарт-контрактов (мосты проверки) для обеспечения соблюдения условий действительности или жизнеспособности. Вместо этого они окажутся «скатывающимися вниз» к нижестоящим узлам Rollup. Эти узлы по-прежнему полагаются на доступность данных и устойчивость к реорганизации базового уровня.
Как и в SCR, в узлах Sovereign Rollup требуется некоторый механизм для реализации свойства живучести. Чтобы определить каноническую цепочку, они выбрали независимые механизмы, такие как широковещательная передача доказательств p2p.
Какое отношение все это имеет к децентрализации?
Будь то накопительный пакет смарт-контракта или суверенный накопительный пакет, свойство живучести исходит из правильной реализации накопительного пакета. Как мы видели выше, правильная реализация Rollup должна включать два важных компонента:
Механизм обязательного включения;
Протокол замены секвенсора.
Механизмы обязательного включения помогают повысить устойчивость к цензуре. Этот механизм позволяет пользователям «принудительно включать» свои транзакции непосредственно в базовый уровень. Затем любой пользователь накопительного пакета может принудительно вывести свои средства обратно на базовый уровень. Следовательно, даже если есть только один централизованный узел подборки, он не может подвергнуть цензуре пользователей, пока существует зрелый механизм обязательного включения.
Но достаточно ли этого?
Даже если пользователи могут выйти из системы, это может означать, что у L2 не будет особого стимула продолжать работу, если большинство пользователей вернутся на L1. Кроме того, механизм обязательного включения обычно имеет длительное время ожидания и может быть довольно дорогим в реализации для обычного пользователя. Цензуроустойчивость, обеспечиваемая этим механизмом, не совсем практична (или в реальном времени), мы можем назвать ее «слабой цензурой».
Затем у нас есть последний атрибут активности — рост леджера.
Если централизованный ордер сделает что-то плохое, он может остановить рост цепочки Rollup, просто остановив производство блоков. Если это произойдет, пользователь ничего не сможет сделать, чтобы накопительный пакет снова «ожил».
Чтобы решить эту проблему, нам нужен протокол замены сортировщика.
Идея протокола замены секвенсора заключается в том, что если секвенсор ведет себя злонамеренно, Rollup может запустить новый секвенсор посредством управления. Один из способов добиться этого — заменить централизованные узлы заказов децентрализованными протоколами заказов. Если заказчик децентрализован и не монополизирует сборку блоков Rollup, то заблокировать цепочку Rollup будет практически невозможно.
Таким образом, в то время как пользовательские средства всегда в безопасности в Rollups благодаря механизму обязательного включения, создание надежного протокола замены заказчика помогает поддерживать Rollups в живых и обеспечивает практическую защиту от цензуры в реальном времени.
это все?
не полностью. С технической точки зрения есть еще один аспект, который следует учитывать:
Что, если бы сами смарт-контракты могли быть обновлены центральным комитетом Rollup? Допустим, в настоящее время Rollup реализован правильно, но завтра комитет соглашается, что нам больше не нужны смарт-контракты, а вместо этого транслируются доказательства состояния Rollup в p2p-сеть.
Если вы, как пользователь накопительного пакета, не согласны с таким обновлением, вы должны иметь возможность выйти из накопительного пакета до того, как обновление будет реализовано (хотя это не очень удобно для пользователя и может быть вредно для бизнеса). Этого можно добиться с помощью «отложенных обновлений управления», таких как «период уведомления», после которого будут реализованы обновления. Пользователи, не согласные с обновлениями, могут отказаться в течение периода уведомления.
Крайняя степень децентрализации — иметь полностью неизменяемые смарт-контракты. Эти контракты не регулируются каким-либо кошельком с мультиподписью или другим комитетом, и после развертывания их нельзя будет обновить.
Конечно, в этом есть свои проблемы. Если в коде есть какие-либо ошибки или какое-то важное событие требует обновления смарт-контракта, единственный вариант для Rollup — это разветвление на новый смарт-контракт, в то время как средства пользователя застревают в старом контракте.
К сожалению, текущее состояние Rollup далеко от полной реализации, о которой мы говорили выше. Большинство накопительных пакетов все еще находятся на стадии «исследования», пытаясь правильно их реализовать.
Согласно L2 BEAT, Fuel v1 и DeGate — единственные два накопительных пакета, которые созрели для достижения всех условий активности и безопасности.
Экономическая перспектива
Наконец, давайте взглянем на экономику агрегации с точки зрения пользователей и операторов агрегации:
Пользовательский опыт: пользователи должны получать низкие цены и не должны слишком долго ждать транзакций;
Суммарная прибыль: секвенсоры и держатели токенов должны быть прибыльными.
Пользовательский опыт оптимизируется, когда пользователи получают быстрые и дешевые услуги транзакций.
Скорость завершения транзакций зависит от скорости завершения базового уровня. Транзакции могут считаться окончательными всякий раз, когда данные на L1 завершены. Однако пользователи, использующие полные узлы, также могут достичь мгновенной завершенности, просто выполняя транзакции и определяя конечное состояние.
Но не для всех практично запускать полный узел. Таким образом, централизованный сортировщик полезен, поскольку он может предоставить пользователям «мягкое подтверждение» того, что их транзакция включена в блок и будет завершена. Этого достаточно для большинства случаев использования. Однако он опирается на централизованные учреждения, которые могут принимать неблагоприятные меры.
В то время как некоторые протокольные решения, альтернативные заказчику, отказываются от этого свойства (как невыгодного для пользователей), другие решения, такие как внешняя схема консенсуса PoS Espresso, могут предоставлять аналогичные гарантии предварительного подтверждения без риска централизованного заказчика.
А как насчет стоимости пользователей?
Явная стоимость транзакции Rollup обычно составляет:
Стоимость газа L2 = Стоимость газа L1 + Плата за секвенсор. Рациональные централизованные сортировщики всегда хотят максимизировать свою прибыль, даже если это означает перекладывание более высоких затрат на пользователей. Однако стоит отметить, что это также не обязательно может быть решено с помощью децентрализованного механизма сортировки. Даже узлы PoS в децентрализованном ордере хотят максимизировать свою прибыль.
На самом деле это создает проблему несоответствия, когда Rollup может не захотеть передавать прибыль внешним секвенаторам.
Прибыль от агрегации: помимо комиссий за секвенсор, агрегация также может получать прибыль, извлекая MEV из пользовательских транзакций. Этот MEV часто трудно атрибутировать, потому что трудно выяснить, включает ли заказчик в пакет транзакций некоторые из своих собственных опережающих транзакций.
Если Rollup будет заменен внешним консенсусом PoS, они передадут этот MEV внешнему оператору.
Стоит отметить, что обе эти проблемы передачи доходов Rollup внешним механизмам могут быть решены с помощью «соглашений о сделках» между Rollup и внешними механизмами.
Однако, как объяснялось в выступлении Джона Шарбонно во время модульного саммита и в последующем посте, лучше было бы, чтобы делегат управления Rollup упорядочивал набор проверенных узлов. Эти узлы могут быть стратегически выбраны так, чтобы они были географически рассредоточены, и управление может просто выгнать злоумышленников.
Это может быть решение, которое убивает двух зайцев одним выстрелом, поскольку оно позволяет Rollup сохранять прибыль внутри компании, а также смягчает недостатки централизованных сортировщиков.
Но, наоборот, в случае ограниченной ротации секвенсора, секвенсор может вести себя недальновидно, что может привести к монопольному ценообразованию/взвинчиванию цен, что еще больше нанесет ущерб интересам пользователей, принесенных в жертву Rollup.
В любом случае, чтобы Rollup был рентабельным для пользователей, необходим какой-то протокол замены сортировщика.
в заключение
Независимо от того, какой путь выберет Rollup, крайне важно, чтобы он был нацелен на полную реализацию с зрелым протоколом замены секвенсора, обязательным включением и механизмами обновления управления отставанием. Если есть механизм обязательного включения и отложенных обновлений, средства пользователей будут в безопасности независимо от того, централизован сортировщик или нет.
Тем не менее, надежный протокол замены секвенсора может улучшить гарантии жизнеспособности и потенциально улучшить экономические показатели для пользователей Rollup.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Интерпретация важности децентрализации Rollup с разных точек зрения
Автор оригинала: Шиваншу Мадан
Оригинальный сборник: Луффи, Foresight News
В последнее время многие обсуждения в Crypto Twitter вращаются вокруг децентрализации L2. Достаточно ли децентрализован накопительный пакет, который мы создаем? Они уже на пути к децентрализации? Это имеет значение?
Я рассмотрю эти темы в этой статье. Прежде чем я углублюсь, если вы еще не знаете, как на самом деле работают Rollup, я предлагаю вам быстро прочитать эту статью: Rollups для чайников.
Идея Rollup на самом деле довольно проста: он хочет, чтобы участники вне сети проводили транзакции, которые затем можно было бы легко проверить в сети. С помощью Rollup «доверие» базового уровня распространяется на действия за пределами его блокчейна. Взамен Rollup платит небольшую плату (арендную плату) за использование этого доверия.
Так нужен ли нам децентрализованный Rollup?
Интуитивный ответ: обязательно нужно! Это дух блокчейна.
Однако я также считаю, что ответ на этот вопрос не может быть простым «да» или «нет». Скорее, он охватывает несколько аспектов, которые необходимо анализировать по отдельности. Далее я рассмотрю этот вопрос с трех точек зрения: философии, технологии и экономики.
Философская перспектива
Давайте начнем с разговора на более высокий уровень: зачем нам децентрализация?
Потому что мы хотим будущего без разрешений, которое способствует открытым инновациям. Мы хотим, чтобы пользователи могли создавать новые вещи без каких-либо ограничений и без необходимости доверять какой-либо отдельной сущности.
За короткую историю блокчейна у нас было много анонимных разработчиков, создававших удивительные вещи. Фактически, сам биткойн был создан анонимным лицом, и вскоре он может стать глобальной платежной валютой, используемой большей частью мира. В этом сила беспрепятственных инноваций!
Блокчейн позволяет нам работать с людьми, у которых нет ничего общего, и мы знаем, что у них нет возможности подорвать это доверие.
—— Престон Эванс
Децентрализованная основа ненадежных сетей, таких как Биткойн и Эфириум, позволяет нам строить такое будущее. Очевидно, что любая цепочка, имеющая доверительные отношения с этими блокчейнами, например Rollup, также должна быть децентрализована!
На самом деле возникает интересный и важный вопрос:
Если Rollup не децентрализован, значит ли это, что Ethereum не децентрализован?
Несколько оптимистичный взгляд на это заключается в том, что в мире без разрешений накопительным пакетам должно быть разрешено создавать все, что они хотят, включая (но не ограничиваясь) разрешенные цепочки, и пользователи этого накопительного пакета по-прежнему смогут использовать базовый уровень безопасности. . Пока базовый уровень децентрализован, а Rollup «полностью реализован» (подробнее о «полной реализации» мы поговорим в техническом разделе), даже разрешенные цепочки должны быть безопасными для использования.
Но реальность такова, что большинство накопительных пакетов сегодня еще не достигли стадии полной реализации и не обеспечивают пользователям необходимый уровень безопасности и надежности.
Итак, какова правильная реализация Rollup? Давайте посмотрим:
Техническая перспектива
Чтобы по-настоящему понять проблемы децентрализации и безопасности Rollup, нам нужно взглянуть на него с первых принципов. Мало кто может объяснить основные принципы блокчейна лучше Шрирама Каннана.
Блокчейн — это распределенная книга, и разные узлы в сети следуют заранее определенным правилам протокола, чтобы достичь консенсуса в отношении состояния книги. В зависимости от того, как эти узлы видят сеть, у них могут быть разные правила для подтверждения правильного состояния их собственной леджерной сети.
Полные узлы и легкие клиенты, особенно в Rollup, имеют разные правила подтверждения. В традиционном смарт-контракте Rollup (SCR) смарт-контракт (проверочный мост) имеет свои собственные правила подтверждения. Если неблагоприятных событий нет, эти правила подтверждения в конечном итоге совпадают в так называемых «областях согласованности». Как следует из названия, в зоне консенсуса все участники имеют одинаковое представление о сети (и одинаковую историю в леджере).
Если все правила подтверждения безопасны, ничего плохого не произойдет. Как поделился Sreeram в сообщении выше, 5 свойств в основном определяют безопасность этих правил подтверждения.
Первые 2 свойства определяют «живое» состояние системы, а последние 3 свойства определяют «безопасное» состояние.
Давайте рассмотрим эти проблемы с точки зрения разных участников Rollup и посмотрим, какие из них можно смягчить без децентрализации.
Разные участники полагаются на разные механизмы обеспечения безопасности и жизнеспособности.
Полный узел:
Если вы запускаете полный узел, у вас есть доступ к опубликованным данным и вы можете проверить их напрямую. Затем вы можете использовать эти данные для самостоятельного выполнения транзакций и определения достоверности транзакций и окончательного состояния свертки после этих транзакций.
Остальными условиями безопасности, таким образом, являются активность и устойчивость к рекомбинации. Для устойчивости к реорганизации полные узлы полагаются на валидаторы базовой цепочки и протокол консенсуса, который он использует, в то время как для обеспечения жизнеспособности полные узлы полагаются на реализацию Sequencer и Rollup.
Легкий клиент:
Большинство пользователей взаимодействуют с блокчейном, используя легкие клиенты для получения данных блокчейна. Световые узлы бывают нескольких типов:
Если вы запускаете облегченный клиент полного валидатора, вы можете проверить, доступны ли данные с помощью выборки доступности данных, проверить правильность переходов состояний с помощью доказательств достоверности или доказательств мошенничества, а также проверить, соответствует ли состояние консенсусу базового уровня (в Ethereum выше). , можно сделать, следуя комитету по синхронизации).
Тогда оставшееся условие безопасности — живость, а легкий клиент зависит от секвенсора и реализации Rollup.
Встроенный смарт-контракт (проверочный мост):
В традиционном SCR «правило подтверждения» смарт-контракта заключается в применении всех 5 свойств безопасности:
Полные узлы SCR полагаются на смарт-контракты для обеспечения соблюдения свойств живучести. Они получают сопротивление реорганизации от базового слоя.
Легкие узлы полагаются на смарт-контракты для улучшения свойств жизнеспособности и поглощения DA и сопротивления реорганизации от базового уровня. Они могут проверять доказательства действительности самостоятельно или с помощью смарт-контрактов.
Консенсус SCR заключается в том, чтобы следовать канонической цепочке, определенной смарт-контрактом.
А как насчет суверенных роллапов?
Суверенные накопительные пакеты не имеют смарт-контрактов (мосты проверки) для обеспечения соблюдения условий действительности или жизнеспособности. Вместо этого они окажутся «скатывающимися вниз» к нижестоящим узлам Rollup. Эти узлы по-прежнему полагаются на доступность данных и устойчивость к реорганизации базового уровня.
Как и в SCR, в узлах Sovereign Rollup требуется некоторый механизм для реализации свойства живучести. Чтобы определить каноническую цепочку, они выбрали независимые механизмы, такие как широковещательная передача доказательств p2p.
Какое отношение все это имеет к децентрализации?
Будь то накопительный пакет смарт-контракта или суверенный накопительный пакет, свойство живучести исходит из правильной реализации накопительного пакета. Как мы видели выше, правильная реализация Rollup должна включать два важных компонента:
Механизмы обязательного включения помогают повысить устойчивость к цензуре. Этот механизм позволяет пользователям «принудительно включать» свои транзакции непосредственно в базовый уровень. Затем любой пользователь накопительного пакета может принудительно вывести свои средства обратно на базовый уровень. Следовательно, даже если есть только один централизованный узел подборки, он не может подвергнуть цензуре пользователей, пока существует зрелый механизм обязательного включения.
Но достаточно ли этого?
Даже если пользователи могут выйти из системы, это может означать, что у L2 не будет особого стимула продолжать работу, если большинство пользователей вернутся на L1. Кроме того, механизм обязательного включения обычно имеет длительное время ожидания и может быть довольно дорогим в реализации для обычного пользователя. Цензуроустойчивость, обеспечиваемая этим механизмом, не совсем практична (или в реальном времени), мы можем назвать ее «слабой цензурой».
Затем у нас есть последний атрибут активности — рост леджера.
Если централизованный ордер сделает что-то плохое, он может остановить рост цепочки Rollup, просто остановив производство блоков. Если это произойдет, пользователь ничего не сможет сделать, чтобы накопительный пакет снова «ожил».
Чтобы решить эту проблему, нам нужен протокол замены сортировщика.
Идея протокола замены секвенсора заключается в том, что если секвенсор ведет себя злонамеренно, Rollup может запустить новый секвенсор посредством управления. Один из способов добиться этого — заменить централизованные узлы заказов децентрализованными протоколами заказов. Если заказчик децентрализован и не монополизирует сборку блоков Rollup, то заблокировать цепочку Rollup будет практически невозможно.
Таким образом, в то время как пользовательские средства всегда в безопасности в Rollups благодаря механизму обязательного включения, создание надежного протокола замены заказчика помогает поддерживать Rollups в живых и обеспечивает практическую защиту от цензуры в реальном времени.
это все?
не полностью. С технической точки зрения есть еще один аспект, который следует учитывать:
Что, если бы сами смарт-контракты могли быть обновлены центральным комитетом Rollup? Допустим, в настоящее время Rollup реализован правильно, но завтра комитет соглашается, что нам больше не нужны смарт-контракты, а вместо этого транслируются доказательства состояния Rollup в p2p-сеть.
Если вы, как пользователь накопительного пакета, не согласны с таким обновлением, вы должны иметь возможность выйти из накопительного пакета до того, как обновление будет реализовано (хотя это не очень удобно для пользователя и может быть вредно для бизнеса). Этого можно добиться с помощью «отложенных обновлений управления», таких как «период уведомления», после которого будут реализованы обновления. Пользователи, не согласные с обновлениями, могут отказаться в течение периода уведомления.
Крайняя степень децентрализации — иметь полностью неизменяемые смарт-контракты. Эти контракты не регулируются каким-либо кошельком с мультиподписью или другим комитетом, и после развертывания их нельзя будет обновить.
Конечно, в этом есть свои проблемы. Если в коде есть какие-либо ошибки или какое-то важное событие требует обновления смарт-контракта, единственный вариант для Rollup — это разветвление на новый смарт-контракт, в то время как средства пользователя застревают в старом контракте.
К сожалению, текущее состояние Rollup далеко от полной реализации, о которой мы говорили выше. Большинство накопительных пакетов все еще находятся на стадии «исследования», пытаясь правильно их реализовать.
Согласно L2 BEAT, Fuel v1 и DeGate — единственные два накопительных пакета, которые созрели для достижения всех условий активности и безопасности.
Экономическая перспектива
Наконец, давайте взглянем на экономику агрегации с точки зрения пользователей и операторов агрегации:
Пользовательский опыт оптимизируется, когда пользователи получают быстрые и дешевые услуги транзакций.
Скорость завершения транзакций зависит от скорости завершения базового уровня. Транзакции могут считаться окончательными всякий раз, когда данные на L1 завершены. Однако пользователи, использующие полные узлы, также могут достичь мгновенной завершенности, просто выполняя транзакции и определяя конечное состояние.
Но не для всех практично запускать полный узел. Таким образом, централизованный сортировщик полезен, поскольку он может предоставить пользователям «мягкое подтверждение» того, что их транзакция включена в блок и будет завершена. Этого достаточно для большинства случаев использования. Однако он опирается на централизованные учреждения, которые могут принимать неблагоприятные меры.
В то время как некоторые протокольные решения, альтернативные заказчику, отказываются от этого свойства (как невыгодного для пользователей), другие решения, такие как внешняя схема консенсуса PoS Espresso, могут предоставлять аналогичные гарантии предварительного подтверждения без риска централизованного заказчика.
А как насчет стоимости пользователей?
Явная стоимость транзакции Rollup обычно составляет:
Стоимость газа L2 = Стоимость газа L1 + Плата за секвенсор. Рациональные централизованные сортировщики всегда хотят максимизировать свою прибыль, даже если это означает перекладывание более высоких затрат на пользователей. Однако стоит отметить, что это также не обязательно может быть решено с помощью децентрализованного механизма сортировки. Даже узлы PoS в децентрализованном ордере хотят максимизировать свою прибыль.
На самом деле это создает проблему несоответствия, когда Rollup может не захотеть передавать прибыль внешним секвенаторам.
Прибыль от агрегации: помимо комиссий за секвенсор, агрегация также может получать прибыль, извлекая MEV из пользовательских транзакций. Этот MEV часто трудно атрибутировать, потому что трудно выяснить, включает ли заказчик в пакет транзакций некоторые из своих собственных опережающих транзакций.
Если Rollup будет заменен внешним консенсусом PoS, они передадут этот MEV внешнему оператору.
Стоит отметить, что обе эти проблемы передачи доходов Rollup внешним механизмам могут быть решены с помощью «соглашений о сделках» между Rollup и внешними механизмами.
Однако, как объяснялось в выступлении Джона Шарбонно во время модульного саммита и в последующем посте, лучше было бы, чтобы делегат управления Rollup упорядочивал набор проверенных узлов. Эти узлы могут быть стратегически выбраны так, чтобы они были географически рассредоточены, и управление может просто выгнать злоумышленников.
Это может быть решение, которое убивает двух зайцев одним выстрелом, поскольку оно позволяет Rollup сохранять прибыль внутри компании, а также смягчает недостатки централизованных сортировщиков.
Но, наоборот, в случае ограниченной ротации секвенсора, секвенсор может вести себя недальновидно, что может привести к монопольному ценообразованию/взвинчиванию цен, что еще больше нанесет ущерб интересам пользователей, принесенных в жертву Rollup.
В любом случае, чтобы Rollup был рентабельным для пользователей, необходим какой-то протокол замены сортировщика.
в заключение
Независимо от того, какой путь выберет Rollup, крайне важно, чтобы он был нацелен на полную реализацию с зрелым протоколом замены секвенсора, обязательным включением и механизмами обновления управления отставанием. Если есть механизм обязательного включения и отложенных обновлений, средства пользователей будут в безопасности независимо от того, централизован сортировщик или нет.
Тем не менее, надежный протокол замены секвенсора может улучшить гарантии жизнеспособности и потенциально улучшить экономические показатели для пользователей Rollup.