переслать оригинальный заголовок «Мы все строим одно и то же»

введение

этот пост анализирует следующее

• асинхронное выполнение - почему высокопроизводительные интегрированные блокчейны (например, SolanaиMonad) отделяет выполнение от согласования по порядку (последовательности).
• ленивая последовательность - как они будут отражать дизайн ленивого секвенсора (например, @astriaorg/hj6ccpp9t">astria).
• предварительное подтверждение - предварительные подтверждения на уровне ethereum l1 и основанных rollups.
• на основе против неоснованных - сравнение на основе роллапов + предварительных конфигураций против неоснованных роллапов + отката базового уровня.
• универсальная синхронная комбинируемость - через атомарное включение (из общих последователей) + криптографическая безопасность (например, AggLayerи / или в режиме реального времени).
• быстрые роллапы - роллапы должны быть основаны на быстром базовом уровне.
• тайминговые игры - Время - деньги, и как это лежит в основе расходящихся конечных игр между Solana и Ethereum.
• децентрализация для сопротивления цензуре - какразделение аттестанта-предлагающегочерезаукционы исполненияможет сохранить децентрализованных валидаторов, которые могут обеспечить устойчивость к цензуре с списки включения.

в последнюю очередь, и, самое главное, мы увидим, почемумы все строим одно и то же чертово делотак может быть, нам просто...

оптимизация репликации конечного автомата (smr)

мы начнем с основ, чтобы увидеть, что конечная цель для высокопроизводительных блокчейнов (например, Солана, Монада, @patrickogradyстратегия смягчения позволяет максимизировать прибыль строителей, чтобы минимизировать недействительные транзакции, подходы, которые подходят к (hypersdk) почти ленивый секвенсор(например, @astriaorg/hj6ccpp9t">astria). мы вернемся к этому позже, чтобы сравнить их с роллапами на основе Ethereum + предварительными конфигурациями.

последовательность против выполнения

блокчейны - этореплицированные автоматы состояний. децентрализованные узлы каждый держат и обновляют свою собственную копию состояния системы. для продвижения цепи узлы запускают функцию перехода состояния (stf) над текущим состоянием + новыми входами (например, новые транзакции). это производит новое состояние.

Мы будем использовать следующие термины в этом разделе:

• синтаксически допустимая - транзакция имеет правильную структуру и подпись.
• семантически допустимая - транзакция выполняет допустимый переход состояния (например, выплачивает необходимые сборы).
• последовательность - определение порядка и включения данных.
• выполнять - интерпретировать и действовать в соответствии с stf.
• создать блок (или часть блока/кусок/отрывок) из транзакций, хранящихся локально.
• проверить - выполнить необходимую синтаксическую и/или семантическую верификацию блока (или части блока/фрагмента).
• реплицировать - распространять блок (или частичный блок/фрагмент) на другие валидаторы.

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

Кроме того, узлы проверяют и реплицируют данные по всей сети. Узлы достигают согласия, чтобы сохранить последовательный вид цепочки.

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

В следующих разделах мы увидим, что ключевым пониманием эффективного конвейерного процесса является сосредоточение на достижении согласия по входным данным выполнения, а не по результатам выполнения. Для этого требуется снять некоторые ограничения относительно того, какие транзакции могут быть включены. Затем нам придется вновь ввести некоторые более слабые ограничения, чтобы обеспечить, что система остается полезной и устойчивой к атакам (например, избегая векторов DOS от транзакций, которые не платят комиссии).

традиционный СМР

традиционный smr (например, ethereum) тесно связывает упорядочивание и выполнение. Полные узлы непрерывно упорядочивают и выполняют все транзакции базового уровня - оба являются предпосылками для достижения консенсуса узлов. Кроме того, проверяя наличие всех данных блока (и упорядочивание их), узлы также должны выполнить блок для проверки того, что:

• все транзакции синтаксически и семантически допустимы
• вычисленное новое состояние соответствует предоставленному лидером

Валидаторы проголосуют за блок и начнут строить на нём только после независимой проверки его состояния. Это означает, что выполнение происходит как минимум дважды, прежде чем будет достигнуто согласие (т.е. производитель блока выполняет его построение + получающие валидаторы выполняют повторную проверку).

в этой традиционной модели и построение, и верификация включают выполнение.

исходный:@patrickogrady/rys8mdl5p# дело о укреплении развязанного воспроизведения состояния машины

стриминг smr

стриминговая smr (например, solana) - эффективная форма конвейеризации, при которойблок-продюсеры непрерывно «потоково» передают части блоков (называется дробитили фрагменты) по мере их построения. другие узлы непрерывно получают и проверяют (включая выполнение) эти фрагменты, даже когда остальная часть блока все еще строится. это позволяет следующему лидеру начать строить свой блок раньше.

исходный текст: @patrickogrady#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: укрепление децентрализованной репликации состояния машины

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

асинхронное выполнение

интегрированный подход

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

асинхронное выполнение удаляет выполнение из горячего пути консенсуса - узлы просто достигают консенсуса относительно упорядочивания данных, не выполняя эти данные. это более эффективно, поэтому СоланаиМонада Оба планируют реализовать асинхронное выполнение.

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

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

возможно, поэтомуКионе считает, что в конечном итоге каждый блокчейн будет использовать асинхронное выполнение, и это ключевой элемент Конечная цель Толи для соланы:

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

В настоящее время валидаторы переигрывают все транзакции как можно быстрее на каждом блоке и голосуют только после того, как полное состояние вычислено для блока. Цель этого предложения - разделить решение о голосовании за ветку от вычисления полного состояния перехода для блока.

Стоит отметить, что мы также хотим убедиться, что правда легко раскрывается пользователям, а это означает надежную поддержку легких клиентов. Некоторые из этих проектов, которые значительно задерживают выполнение, могут усложнить эту задачу (например, Solana рассматривает возможность требовать его только один раз за эпоху) по сравнению с другими, которые предоставляют корневое состояние с меньшей задержкой (например, как в hypersdk).

модульный подход

это разъединение последовательности и выполнения может показаться очень знакомым, потому что это также «модульный» подход! сочетайте различные слои, которые специализируются на разных задачах. разъединение последовательности и выполнения является ключевым принципом проектирования ленивых секвенсоров (например, astria):

• последовательность - узлы последователей только достигают согласия относительно порядка и доступности данных rollup (т. е. они упорядочивают, но не выполняют).
• исполнение - узлы Rollup выполняют свои соответствующие данные после того, как секвенсор его подтвердил.

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

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

В любом случае, нам нужна действительно большая и быстрая труба для упорядочивания данных:

однако стоит отметить, что в техническом плане вы можете использовать практически любую цепочку в качестве ленивого последовательного устройства. В конечном счете это просто большой поток данных. Роллап может наивно поместить свои произвольные данные на выбранную им базовую слой (будь то Ethereum, Bitcoin, Monad и т. д.), чтобы неявно использовать ее в качестве своего последователя. Затем роллап-узлы могут асинхронно выполнить данные после факта.

Разница на практике заключается в том, что цепочки, которые мы на самом деле называем «ленивыми секвенсорами», специализируются на этой задаче, что гораздо легче сказать, чем сделать (например, поддержка необходимых типов транзакций, предоставление простых интерфейсов, реализация инфраструктуры MEV, быстрое время слотов, надежное включение транзакций, высокая пропускная способность и т. д.). В результате, узлы для интегрированных цепочек в конечном итоге выполняют большую часть данных, которые они включают, в то время как ленивые секвенсоры оставляют это в первую очередь сверткам.

поэтому это не так просто, как «почему бы нам просто не использовать солану (или любую другую цепочку, когда это никогда не было целью дизайна) в качестве секвенсора роллапа?»:

• отсутствие необходимой инфраструктуры MEV, специально разработанной для роллапов (например, необходимая инфраструктура PBS, механизмы взаимодействия между цепями, композитор для абстрагирования платежей за комиссию для пользователей роллапов в базовом токене газа и т. д.)
• отсутствие собственных типов транзакций, предназначенных для публикации данных в роллапах.
• конкурировать с нативной средой исполнения (например, она специально разработана для использования всех или как можно большего количества предоставленных данных, оставляя меньше места и надежного включения транзакций и т. д.).
• конкурируя за общую поддержку разработчиков и приоритеты обновлений. вероятнее всего, вы склонны обратиться к протоколу и команде, специализирующейся на помощи в запуске роллапов и разработке протокола с учетом ваших потребностей, по сравнению с тем, где большинство сообщества считает роллапы несколько глупыми.

укрепление отсоединенного SMR

сейчас мы можем решить эти проблемы, возникающие из-за смягчения этих ограничений? В краткосрочной перспективе, да, наивные реализации действительно вносят проблемы, такие как разрешение недопустимых транзакций, которые не могут оплатить комиссию (что может стать вектором dos, если реализовано наивно), но их можно решить так, чтобы они не были серьезными проблемами.

мы не будем углубляться в детали здесь, но вы можете обратиться кПатрик О'Грэйдиудивительная работа на@patrickogradyvryx для укрепления отклеенной смр, toly’sконец асинхронного выполненияиРеализация Monad расходов на перевозкупо поводу того, как решить эти проблемы. опять же, решения этих проблем, неудивительно, выглядят практически одинаково как с модульной стороны, так и с интегрированной стороны.

tldr состоит в том, что вы можете ввести некоторые намного слабее ограничения (по сравнению с синхронным выполнением с полной проверкой), которые сохраняют большую часть преимуществ производительности, не оставляя открытыми множество атак.

актеры в протоколе против актеров вне протокола

Важно понимать, что вышеупомянутые процессы наивно учитывают только акторов внутри протокола. На самом деле, акторы вне протокола играют огромную роль в этих цепочках поставок транзакций. Это то, что мы ранее видели для (внутрипротокольных) валидаторов в традиционной SMR:

источник: @patrickogrady/rys8mdl5p#делаем-аргумент-за-репликацию-распределенных-состояний-dsmr">vryx: укрепление репликации распределенных состояний

на практике, однако, почти все валидаторы Ethereum выдают создание блока через MEV-boost Три лучших строителя (Beaver, Titan и Rsync) построили почти все эти блоки. Обратите внимание, что Beaver и RSynk цензурируют транзакции OFAC, в то время как Titan этого не делает.

источник: mevboost.pics

реле обрабатывают репликацию этих блоков для остальной части сети. Они также относительно тяжеловесные, с четырьмя лидирующими операторами (ultra sound, bloxroute, агностик и flashbots), которые передают подавляющее большинство блоков. Bloxroute и flashbots цензурируют сделки ofac, в то время как агностик и ultra sound этого не делают.

источник:mevboost.pics

Неудивительно, что мы здесь видим очень похожие тенденции в оптимизации задержки, как мы уже обсуждали ранее. Тенденция идет в сторону Оптимистичные эстафетыкоторые больше не выполняют проверку блока перед репликацией, потому что это просто быстрее. Ленивые последователи можно рассматривать как стимулирующие ретрансляционные сети.

эти примеры показывают, как МЭВ искажает стимулы к прибыли в этих системах. валидаторы передают производство блоков, потому что опытные строители могут захватить больше ценности по сравнению с наивно последовательными блоками.

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

Универсальная синхронная компонуемость

определения

Сейчас мы можем получить суверенитет и гибкость, которые предлагают модульные цепи, но объединить их, чтобы они чувствовали себя как целостная цепь? Можем ли мы иметь пирог и съесть его, или мы просто заканчиваем строить Солану с лишними шагами?

когда вы слышите людей говорящих о решении проблем с фрагментацией Rollup, вы, вероятно, слышали большие модные слова вокруг этого.универсальная синхронная компонуемость (USC). Однако, это, вероятно, была ваша реакция:

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

обратите внимание, что мы будем обсуждать «роллапы» на протяжении всего этого отчета, но многие из этих концепций также применимы к другим типам «l2s», таким как валидиумы.Я просто не хочу снова спорить о том, что такое l2.

в следующих примерах:

• r_а = свертка
• r_б = свертка b
• t_a1 = транзакция 1 на R_а
• t_b1 = транзакция 1 на r_б
• b_a1 = блок 1 на r_а
• b_b1 = блок 1 на r_b
  

обратите внимание, что мы определяем «время» как «высоту слота» здесь. время является чисто относительным для наблюдателя. единственное объективное представление времени, которое у нас есть, - это относительный порядок, установленный общим наблюдателем, т.е. общий консенсус (где этот «консенсус» может быть одним актером или децентрализованным механизмом).

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

• б_a1 перед b_a2
• б_В1 находится перед b_b2

однако, единственный способ утверждать:

• б_А1одновременно находится в b_b1, и поэтому
• Т_a1и т_b1 происходить синхронно, это, если
• они используют упорядочение, предоставленное общим согласием для данного слота.

Таким образом, межсетевая синхронная компонуемость по определению требует некоторого типа разделяемого секвенсора для этой высоты слота. Цепочки без него могут иметь только асинхронную компонуемость.

Однако обратите внимание, что у нас может быть асинхронная атомарная компонуемость. К сожалению, я часто замечаю, что люди используют термины «атомарный» и «синхронный» как взаимозаменяемые, но на самом деле это разные термины.

с этим разобрались, давайте посмотрим, сможем ли мы вернуть синхронную компоновку в модульные цепи. если сможем, то это может показаться neGate.io значением интегрированных цепей. вот краткое изложение, в которое мы окунемся:

• Совместное секвенирование может обеспечить синхронное атомарное включение само по себе (что намного слабее, чем компонуемость).
• совмещение общего последователя с каким-то механизмом криптографической безопасности (например, agglayer) может укрепить это гарантию включения в фактическую компоновку.
• гарантии безопасности, предоставляемые agglayer для безопасности межцепочной связи, также могут быть использованы без общего последователя (т. е. в асинхронной среде).
• мы также рассмотрим, как можно симулировать эффекты синхронной комбинируемости, хотя и менее эффективным с точки зрения капитала способом, используя криптоэкономику (прямая обеспеченность транзакций межцепочечного).

атомарная включенность - общая последовательность

общая последовательность означает, что для заданной высоты слота у одной сущности (т. е. "последователя" или "предлагающего") есть монопольное право на последовательность (т. е. предложение блоков для) нескольких цепей. Чтобы повторить, обычно говорят о таких общих последователяхленивые последователи. Они достигают консенсуса по упорядочиванию и доступности данных свертки, но не выполняют его. Они совершенно ничего не знают о конечных автоматах роллапов.

Как я уже писал ранееЭто означает, что ленивые общие последователи могут предоставить достоверное обязательство включить пакеты межцепочных транзакций (т.е. набор транзакций):

• атомарно - либо все транзакции будут включены, либо нет, и
• синхронно - одновременно (высота слота)

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

разделение блокчейн-цепочки

теперь, как именно мы это делаем без полного доверия к строителю и/или активному предлагателю общего порядка? если мы просто отправим две независимо подписанные транзакции (t₁и t₂) для каждого роллапа общий секвенсор все еще может решить включить только один из них или другой.

например, сегодня в evm нет понятия собственного формата пакета, поэтому поисковые системы полностью доверяют строителям/реле не распаковывать их. любой, кто видит пакет независимо подписанных транзакций до их подтверждения текущим лидером, может их распаковать. это в целом нормально, потому что строителям и реле выгодно поддерживать свою репутацию и защищать пакеты поисковика, но когда это доверие нарушается (или их обманывают нечестные участники, чтобы раскрыть транзакции),Разбунтовка может быть невероятно прибыльной.

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

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

это означает, что нам необходимо создать новую структуру транзакции для пакетов межцепочечных связей, которые не могут быть распакованонаивное решение состоит в том, чтобы «просто создать новый тип транзакции для этих роллапов», но это не так просто. это потребует изменений виртуальной машины для этих роллапов, что приведет к потере обратной совместимости. вы также будете тесно связывать роллапы, изменяя их автоматы состояний таким образом, чтобы каждая транзакция была действительна только вместе с другой, включенной.

Однако есть более чистый способ сделать это. вы также можете подписать каждую транзакцию в пакете хешем пакета, а затем добавить хеш-дайджест в поле свободной транзакции (например, calldata в evm). rollup должен изменить свою производную конвейера, чтобы проверять их, но vm может оставаться неизменным. с этим введением пользователи роллапа могут отправлять пакеты межцепочечных транзакций, которые они уверены, что не могут быть разобраны. попытка сделать это сделает их недействительными.

исходный: Бен Фиш

гарантии включения против государственных гарантий

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

• может обеспечить надежное выполнение атомной синхронной включенности для межцепочных пакетов (т.е. все транзакции будут включены или ни одна не будет)
• невозможно дать достоверные гарантии относительно итогового состояния, когда такие транзакции будут включены (например, возможно, что обе транзакции будут включены, но какая-то другая транзакция окажется перед ними и заставит их отмениться)

К сожалению, атомарная включенность сама по себе является гораздо более слабым гарантом. Этот обязательный аспект атомарной включенности достаточен для того, чтобы строитель имел высокую уверенность в том, что созданный им блок межсетевого переноса создаст желаемое состояние, если он будет подтвержден. Строитель обязательно знает желаемое состояние блока, потому что он выполнил его для его создания.

Однако у нас все еще есть проблема - как же все остальные будут с уверенностью знать, каким будет состояние?

рассмотрим пример:

• У нас есть два роллапа (RA и RB), совместно использующие один и тот же ленивый секвенсор
• я хочу использовать мост сжигания и выпуска между ra → rb, который одновременно сжигает на ra и выпускает на rb
• контракт моста по чеканке на rb требует гарантии перехода состояния на ra (сжигание), чтобы чеканить на rb, но контракт не может знать, был ли токен фактически сожжен на ra во время выполнения, потому что он не имеет доступа к состоянию ra.

если мы отправили правильный пакет, то ленивый последователь может гарантировать, что сжигающая транзакция была включена в поток транзакций для ra, но вы не знаете, например, может ли другая транзакция оказаться перед ней и аннулировать ее (что означает, что токены фактически не были сожжены).

Простое совместное использование ленивого секвенсора недостаточно для обеспечения доступа цепочек к состояниям друг друга во время выполнения пакета. Синхронная компонуемость требует возможности для машины состояний каждой цепочки получать доступ к состоянию другой цепочки (например, сам контракт моста на rb должен знать состояние ra) во время выполнения. Именно эта возможность обеспечивает полную компонуемость в пределах одной интегрированной цепочки.

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

Чтобы это исправить, нам нужно добавить какой-то другой механизм в дополнение к общей последовательности:

как мы упоминали, строитель лично знает, каким будет конечное состояние, если пакет включен атомарно. Так как же они могут дать достоверные гарантии, чтобы убедить всех остальных в том, каким будет конечное состояние, если их транзакции будут включены?

у них в целом есть два варианта:

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

криптоэкономическая безопасность - строительные облигации

Давайте рассмотрим пример, чтобы увидеть, как криптоэкономика может моделировать эффекты синхронной компонуемости. Классическим примером является кросс-цепочечный флэш-кредит. я хочу взять заимствование в виде флеш-займа на ra, использовать его для арбитража на rb и вернуть его на ra, все в одном слоте. это возможно, если эти протоколы defi здесь внедряют настраиваемую функциональность межцепочечного взаимодействия с помощью того, что мы будем называть «банковскими контрактами» на каждой стороне:

теперь к вопросу безопасности - контракт на ra и rb должен знать состояние цепей друг друга, чтобы сделать это безопасно, но мы ничего не сделали, чтобы решить эту проблему. Итак, криптоэкономическое «решение» здесь на самом деле довольно грубое - суперстроитель выступает в качестве поставщика ликвидности и вносит полную стоимость мгновенного кредита. Если транзакции не удалось, то протокол кредитования все равно сохраняет свою долю. Понятно, почему это не самое удовлетворительное «решение».

криптографическая безопасность - агглайер

что это

theAggLayerэто децентрализованный протокол, который обеспечивает три основных преимущества:

1. безопасность быстрой межцепочечной комбинируемости - она производит zk-доказательства, которые обеспечивают криптографическую безопасность aggchains для атомарной межцепочечной совместимости с низкой задержкой (т.е. быстрее, чем блоки Ethereum) при асинхронной или синхронной работе. дизайн уникальным образом изолирует цепные сбои, чтобы он мог поддерживать любую среду выполнения и доказательство.
2. Фунгибельность активов межцепочечного перекрестного связывания - это общий мост, обеспечивающий фунгибельность активов по всему агрегатному блоку (т. е. цепочкам, которые его используют), чтобы пользователи не оказались с кучей упакованных активов. Контракт моста находится на Ethereum, который является слой расчетов. (обратите внимание, что различные цепи все равно могут иметь различные предположения о безопасности из-за реализации, что рассматривается далее.)
3. оптимизация газа - это совокупность доказательств для aggchains, чтобы амортизировать постоянные расходы между многими цепочками. Общий депозитный контракт также оптимизирует затраты на газ, позволяя осуществлять прямые трансферы с l2 на l2 без касания l1.

source: Брендан Фармер, Агрегированные блокчейны

чтобы прояснить два распространенных заблуждения о том, чем не является Agglayer:

• Agglayer - это не просто сервис для подтверждения доказательств AggreGate.io - это запутывает, потому что на самом деле это доказательства AggreGate.io, и они называют это вещь «агрегацией». Однако основная цель Agglayer - агрегация цепей. Важное различие для целей этого сообщения заключается в том, что только агрегация доказательств сама по себе не делает ничего для достижения требуемых здесь гарантий безопасности.
• Агглайер и общие последователи не противопоставляются дизайнам - в то время как они не обязаны использоваться вместе, они, фактически, идеально дополняют друг другакоторые предоставляют различные гарантии. Agglayer полностью агностичен к тому, как упорядочиваются aggchains. Он не обрабатывает никакие сообщения между цепями, поэтому фактически явно полагается на инфраструктуру координации свободного рынка (например, ретрансляторы, строители, изолированные упорядочиватели, общие упорядочиватели и т. д.), чтобы составить цепи.

теперь давайте пройдемся по тому, как это работает.

мосты отстой

сегодня мост между роллапами отвратителен. Допустим, вы хотите мостить eth между двумя оптимистичными роллапами эфириума oru_aи oru_б:

• через мост на базе - вы заплатите дорогие газовые сборы ethereum l1 (т. е. мостик с oru_а → эфириум + эфириум → ору_b), а туда-обратно займет более недели (из-за окна надежности).
• Прямой роллап → роллап - упакованный эфир, который вы получаете на Oru_бна самом деле не будет обладать свойствами фангибильности со стандартным ETH для нас_a. путь зависимости от прохождения разных мостов нарушает взаимозаменяемость. например, если oru_aмост был осушен, тогда завернутый eth, который вы перенесли на orub, останется без поддержки, в то время как местный eth на oru_bбыло бы неплохо. Фрагментация ликвидности - это не то, что пользователи хотят. На практике пользователи могут обратиться к поставщикам ликвидности, чтобы осуществить прямой мост. Кто-то предоставит вам ETH на нашем сайте._б и храните свои средства на ORU_а. они могут вывести через местный мост и подождать, но им придется платить дорогие сборы за риск и высокие капитальные затраты, которые они несут.

Вы можете подумать, что zk rollups решают эту проблему сразу, но на самом деле нет. Наивные реализации все еще требуют отправки транзакций l1, что снова дорого и обычно довольно медленно (например, из-за времени финализации Ethereum, времени генерации доказательств, частоты публикации доказательств на практике и т. д.).

Пользователи не хотят с этим иметь дело. Они хотят просто иметь средства и использовать приложения. Мосты должны быть полностью абстрагированными - активы должны быть взаимозаменяемыми и перемещаться быстро, дешево и безопасно.

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

В результате токены также могут быть взаимозаменяемыми в AggChains. Связывание ETH с R_а → р_били r_с → r_бсжигает и чеканит тот же токен. это не обернутый актив блокировки и чеканки. это родной eth. это возможно, потому что все активы удерживаются вместе и урегулированы через унифицированный мост. это основная проблема для l2s сегодня, которую нужно решить.

однако, обратите внимание, что пользователь, удерживающий eth на r_avs. r_бможет иметь разные профили риска, если разные цепочки используют разные проверяющие (например, вы перешли с безопасной цепочки на цепочку с ошибкой в схеме). профили риска неизменны среди цепочек, использующих общие стандарты (что на практике является нормой сегодня). более унифицированные стандарты и формальная верификация только улучшат это со временем, даже при добавлении гетерогенных доменов.

пессимистические доказательства

aggchains отправляют свои обновления состояния и доказательства узлам, заложенным в agglayer, которые их организуют, генерируют обязательства по всем сообщениям и создают рекурсивные доказательства. Затем agglayer генерирует единственное доказательство zk aggreGate.iod (которое они называют «Пессимистическое доказательство") для расчета с эфириумом для всех аггчейнов. Поскольку агрегация доказательств здесь амортизирует затраты по сколь угодно многим цепочкам, с точки зрения затрат практично разместить их в Ethereum для быстрого расчета как можно скорее. Программа пессимистического доказательства написана на обычном коде Rust, использующем zkvm sp1 от Succinctдля удобства разработки и высокой производительности.

эти пессимистические доказательства подтверждают:

• межцепочечное бухгалтерское учет - доказывает, что все мостовые инварианты соблюдаются (т. е. ни одна цепь не может снять больше токенов, чем было внесено на нее).
• Действительность aggchains - доказывает, что каждая цепь обновила свое состояние верно, без эквивокаций цепей или недопустимых блоков.
• безопасность межцепных транзакций - подтверждает, что обновления состояния, которые являются результатом межцепных транзакций с более низкой задержкой, чем у эфириума, являются последовательными и могут быть безопасно урегулированы на уровне эфириума l1. это включает успешное атомарное выполнение межцепных пакетов как синхронно, так и асинхронно.

с помощью этого agglayer гарантирует, что расчеты происходят на ethereum только в том случае, если вышеперечисленные условия выполняются. если они не выполняются, то соответствующие цепочки не могут проводить расчеты. таким образом, agglayer может позволить координатору (например, общему последователю или построителю) передавать сообщения между цепочками с низкой задержкой, не доверяя этому координатору для обеспечения безопасности.

быстрая и безопасная межцепочечная совместимость

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

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

исходный: Брендан фармер, Агрегированные блокчейны

Возьмем наш пример из предыдущего примера:

• у нас есть два роллапа (р_a и r_б) совместное использование одного и того же ленивого секвенсора и agglayer
• Я отправляю пакет межцепочечного взаимодействия для одновременного сжигания эфира на r_аи майнить эфириум на r_б
• Супер Builder строит блок для обеих цепочек, делая это, который разделяет секвенсор
• контракт моста для чеканки на r_бможет оптимистично чеканить eth в зависимости от состояния r_a(в данном случае успешно выполнение eth сжигания)
• эти блоки и доказательства отправляются на agglayer, который доказывает, что обе цепочки действовали в допустимом режиме (как независимо, так и относительно друг друга), и что общий мост использовался безопасно

Для того, чтобы это было успешно рассчитано в Ethereum, обе ветви связки должны быть выполнены должным образом. Если одна из сторон потерпит неудачу, то блоки будут недействительными и не могут быть урегулированы. Это означает, что если, скажем, разделяемый секвенсор подписался на блоке, в котором ETH не был записан на r._aно добытый эфир на r_б, затем этот блок будет переорганизован. это обеспечивает безопасность всех цепочек и предотвращает установление нечестных межцепочечных действий.

Следует учитывать два момента, связанных с этими реорганизациями:

• они были бы невероятно короткими, потому что они были бы обнаружены и доказаны немедленно.
• они могут произойти только в том случае, если координатор (например, последователь и/или строитель) цепи, к которой вы подключены, активно злонамеренный.

Эти реорганизации должны быть чрезвычайно редкими и минимальными из-за вышеуказанных пунктов, но из-за этого Aggchains будут иметь полный контроль над тем, какие цепочки они хотят составлять атомарно и при каких предположениях доверия. Например, r_аможет принять состояние цепочки от r_б на основе консенсуса секвенсора, но для r_c Он также может захотеть представить доказательство, и для r_d Возможно, они хотят, чтобы они крипто-экономически обезопасили все межсетевые атомарные зависимости. Каждая цепочка может пойти на свои собственные настраиваемые компромиссы для низкой задержки и живости. Agglayer просто обеспечивает максимально гибкую и минимально самоуверенную основу для блокчейнов, чтобы иметь безопасное межсетевое взаимодействие.

вы также можете видеть здесь, почему такая конструкция на практике несовместима с дизайном fault proof. в теории они могли бы это сделать, но в этом случае было бы возможно столкнуться с невероятно глубокими реорганизациями. быстрое доказательство и урегулирование всех цепей ограничивает худший случай очень коротким, что также служит естественным сдерживающим фактором для любых злонамеренных попыток.

Изоляция неисправностей для гетерогенных доказательств

Важно отметить, что AggLayer уникальным образом позволяет использовать полностью гетерогенные цепочки. Вы можете иметь AggChain с любой кастомной виртуальной машиной, подтверждающим устройством, слоями DA и т.д., одновременно безопасно совместно используя мост со всеми.

Но как это возможно? Причина, по которой это обычно неприемлемо, заключается в том, что один неисправный участник (например, с ошибкой схемы) обычно может просто обмануть мост и слить с него все средства. Что ж, вот тут-то и приходит на помощь доказательство межсетевого учета, упомянутое выше. Эти доказательства гарантируют, что все инварианты моста соблюдены, так что даже в случае необоснованного доказательства могут быть слиты только средства, внесенные в затронутую цепь. Неисправность полностью изолирована.

Заслуживающий доверия нейтралитет

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

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

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

aggchains не требуют какой-либо конкретной виртуальной машины, среды выполнения, упорядочивателя, слоя da, токена стейкинга, токена газа или общего управления. Цепочки могут уходить, когда им захочется. Нет требований к доле доходов. Вам не нужно развертываться как L3 на чьей-то другой цепочке.

причины запуска l3s поверх общих l2s в большинстве своих случаев, на мой взгляд, были временными решениями, пока строятся архитектуры, аналогичные agglayer. однако, чтобы быть ясным, это совершенно правильная причина запустить их сегодня. v1 agglayer - это простой общий мостовой контракт. v2 с агрегацией доказательств и возможностью получения безопасной интероперабельности с низкой задержкой даже не запущен. вы не можете ожидать, что люди будут ждать годы, когда им срочно нужно запустить что-то сегодня, что обеспечит им самое быстрое распространение.

реальное время доказательства

хотя до практического использования в низколатентных средах осталось несколько лет, следует отметить, что реальное время доказательства также потенциально может использоваться вместе с общей последовательностью для обеспечения безопасности межцепочечных операций. Это также просто круто, поэтому мы кратко рассмотрим это. Более конкретно, «реальное время» доказательства означает доказательства, которые занимают меньше времени, чем интервалы слотов цепи. Рассмотрим снова пример моста между цепочками с монетизацией и сжиганием.

• У нас есть два роллапа (r_а и r_b) совместно используя один и тот же ленивый секвенсор
• я хочу использовать мост сжигания и эмиссии между ra → rb, который одновременно сжигает на ra и эмитирует на rb
• Super Builder создает кроссчейн-блок, который включает в себя набор этих кроссчейн-транзакций. Внутри блоков построитель включает доказательство перехода состояния, которое включается в другой накопительный пакет.

У нас уже была гарантия синхронного включения атомарных пакетов с помощью общего секвенсора, и теперь каждый контракт может проверять доказательство состояния другой цепочки, чтобы быть уверенным в том, что она будет успешно выполнена.

Для реального доказательства мы идеально хотим, чтобы время доказательства было только небольшой долей общего времени слота, таким образом максимизируя «окно синхронизации». Это часть времени слота, в которой вы можете обрабатывать транзакции, которые работают синхронно между цепями, так как вам нужно выделить достаточно времени в слоте, чтобы создать доказательство и поместить его в блок.

источник: Джастин Дрейк, доказательство в реальном времени

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

источник: Джастин Дрейк, реальное доказательство времени

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

сводка

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

Я ожидаю, что большая часть пользы от использования чего-то вроде Agglayer будет заключаться не только в синхронной настройке. Скорее, дело в том, что он может выступать в качестве формы абстракции цепочки кросс-роллапа. Сделайте так, чтобы многие цепочки казались более похожими на единое целое с важными для пользователя аспектами (например, более взаимозаменяемыми нативными активами, нативной функциональностью кроссчейн-приложений, быстрой совместимостью и т. д.).

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

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

простой факт состоит в том, что на данном этапе это также немного сложно для кого-либо объяснить. это не двоичное «все в криптовалюте синхронно» или «все асинхронно». Я думаю, что нам в основном нужно будет решить и двигаться в сторону последнего, но оба могут существовать по ситуации.

роллапы на основе Ethereum

хорошо, теперь у нас должна быть хорошая представление о пространстве решений для решения проблемы фрагментации в роллапах. следующий вопрос: как мы должны вовлекать базовый уровень во все это? какова роль эфириума здесь?

мы будем использовать следующие сокращения:

• bl - базовый уровень
• роллап на основе br
• preconfs - предварительные подтверждения

Если не указано иное, BL, о котором идет речь, — это Ethereum, а BRS — это Ethereum BRS. Тем не менее, основные понятия применимы в широком смысле, поскольку вы можете запустить BRS где угодно.

роллапсы на основе ванильного

несколько лет назад первоначальные реализации rollup были на самом делеПланировалось, что БРС, но были отказался в пользу централизованных секвенсоров для низкой латентности и высокой эффективности. то, что мы сейчас называем секвенированием на основе, Виталик называл «полный анархия«на тот момент это было относительно неудобно и неэффективно до развития инфраструктуры pbs ethereum (с опытными строителями).

brs затем вернулись в центр внимания в марте 2023 года,где они были определены следующим образом:

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

они должны предложить следующие преимущества:

«последовательность таких роллапов - основанная на последовательности - максимально проста и наследует жизнеспособность и децентрализацию L1. Кроме того, основанные на роллапах особенно экономически выровнены с их базовой L1.»

Конкретно, вы получаете реальное время безопасности Ethereum:

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

Быть основанным rollup - логический дизайн, как только вы выбрали базовый слой:

«Ethereum максимизирует эти два свойства, безопасность и доверенную нейтральность, это почти определение rollup, верно... rollup - это тот, который уже принял безопасностьное предположение Ethereum. Вы не добавляете новое предположение о безопасности. Вы не падаете на самое слабое звено. Вы просто повторно используете существующее предположение о безопасности. И второе - вы уже приняли Ethereum как доверенную нейтральную платформу, иначе вы бы выбрали другую цепочку. И теперь вы можете спросить себя, почему все не используют просто уровень одной последовательности?»

В своей самой простой форме, BRS, конечно, может достигнуть вышеуказанных целей дизайна. Если роллап не реализует свой собственный секвенсор, то, косвенно, текущий предложитель Ethereum решает, что будет включено каждые 12 секунд (слотное время Ethereum).

Однако, секвенирование на основе, по-прежнему, имеет свои недостатки, которые и есть почему rollups обычно реализуют свой собственный последователь:

• Быстрые предварительные проверки - пользователи Rollup не хотят ждать 12 секунд и более для блоков Ethereum.
• безопасные предварительные подтверждения - иногда блоки ethereum переорганизуются, поэтому пользователям приходится ждать еще дольше, чтобы быть в безопасности, что опять же не нравится пользователям. секвенсоры могут давать предварительные подтверждения, которые не зависят от нефинализированных блоков ethereum и, следовательно, не нуждаются в переорганизации, даже если сам ethereum переживает короткую переорганизацию.
• эффективная пакетная отправка - секвенцировщики могут пакетировать большой объем данных, сжимать его и периодически отправлять в бл, оптимизированном с точки зрения стоимости (например, обеспечивая полное использование блобов).

базовые роллапы + предварительные конференции

Итак, можем ли мы иметь нашу пирог и съесть его тоже? введитеоснованные предварительные конференции.

Мы кратко объясним интуицию, лежащую в основе предварительных конфигураций здесь, чтобы мы могли сравнить brs + предварительные конфигурации с традиционными rollups. Позднее мы вернемся, чтобы более подробно проанализировать предварительные конфигурации в целом (т. е. как br предварительные конфигурации, так и bl предварительные конфигурации на транзакциях ethereum l1).

Основная идея заключается в том, что преконфы BR должны исходить от BL Proposers. Чтобы предоставить преконфы, эти пропозиционеры должны внести некоторый залог (например, рестейкинг) и согласиться на дополнительные условия слэшинга (т.е. что преконфы, которые они предоставляют, действительно попадут в чейн, как было обещано). Любой инициатор, желающий это сделать, может выступать в качестве секвенсора BR и предоставлять преконфы.

стоит отметить, что предлагающие (т.е. валидаторы) фактически ожидают делегировать эту роль предоставления предварительных конфигураций более специализированным сущностям, известным как «Gate.ioways». предоставление предварительных конфигураций потребует относительно сложной сущности, и Ethereum хочет сохранить предлагающих недалекими.

Однако ожидается, что существующие реле также возьмут на себя эту роль. Gate.ioway будет только интерфейсом между пользователем и реле, поэтому добавление еще одного независимого элемента только увеличивает сложность и задержку (хотя задержка также может быть решена совместной локализацией). Реле уже доверяют строителям и предлагающим, поэтому мы добавляем еще одно требование к доверию им со стороны пользователей здесь.

Обратите внимание, что в настоящее время валидаторы выступают в качестве предлагателей блоков Ethereum, однако рассматривается обновление, в рамках которого сам протокол будет непосредственно аукционировать права на предложение черезАукционы исполнения. это позволило бы сложным субъектам приобретать права на предложение непосредственно, тем самым избегая необходимости в валидаторах (текущих предлагающих) делегировать их Gate.io, как это предусмотрено здесь.

в любом случае, важно, что любой предварительный конфигурация быстрее, чем консенсус эфириума (12с), требует доверенного третьего лица (дттп). будь то ваш дттп - это переставленный валидатор, стейкер аукцион исполненияПобедитель, deleGate.iod Gate.ioway или что-то еще - в основном он не может обеспечить безопасность эфира в режиме реального времени. Независимо от того, предоставляет ли Coinbase вам «базовый предварительный запрос» в качестве предлагающего эфира или «традиционный предварительный запрос» в качестве последовательности Rollup, вы доверяете Coinbase. Они также могут предоставить обеспечительный депозит в некотором количестве эфира, но в любом случае это не зависит от безопасности консенсуса Ethereum.

Мы должны заметить, что любой базирующийся на предварительной конфигурации дизайн неизбежно отвлекает от заявленных целей brs, с которыми мы начали (простота и безопасность bl).Основанные предварительные конференции становятся все более сложными, и они не могут обеспечить гарантии безопасности в режиме реального времени, как у эфириума.

однако вам следует сохранить возможность принудительного осуществления транзакции напрямую через транзакцию bl, если эти предварительные конференции выйдут из строя или начнут цензурировать. эти гарантии от ethereum должны стать еще сильнее, когда списки включения реализованы.

для brs - ttps предоставляет быстрые предварительные конференции, а bl обеспечивает окончательную безопасность.

небазовые роллапы + базовый откат

теперь рассмотрим традиционный (то есть неоснованный) rollup. собственный секвенсор (централизованный или децентрализованный) обеспечивает быстрые предварительные конфигурации. позже их пользователи получают полную безопасность Ethereum с задержкой. это включает в себя живость (рост журнала + сопротивление цензуре), которая происходит из некоторого типапринудительное включениеилиРезервное значение блокировкимеханизм.

как я отметил в Наследуют ли роллапы безопасность?:

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

Роллапы также могут предоставить «счастливый путь» для более свободного правила подтверждения (т. е. последователи) для лучшего пользовательского опыта, но они сохраняют резервный вариант в случае сбоя. Если ваш последователь останавливается, вы можете продолжать движение.

обратите внимание, чтовремя к окончательной безопасностиключевая переменная для оптимизации здесь:

предположение, что пользователи rollup могут откатиться к эквивалентной активности хост-цепи, предполагает, что вы можете получить принудительное включение точно со скоростью блоков хост-цепи (например, если секвенсор rollup вас цензурирует, то вы можете принудительно включить транзакцию в следующий блок ethereum).

На практике обычно имеется небольшая задержка. Если вы разрешите немедленное принудительное включение, вы можете подвергнутьсяприбыльная цензура mev среди прочих сложностей. однако, есть дизайны, которые могут обеспечивать практически мгновенные гарантии живостиот хостовой цепи (например, возможно, со скоростью нескольких блоков хостовой цепи, а не одного блока).

в этом духе, Sovereign labs имеет дизайнкоторый выполняет следующее:

• последовательность с разрешением - роллапы устанавливают разрешенного последователя, чьи транзакции обрабатываются немедленно после их включения в блок. поскольку у них есть блокировка записи на состояние роллапа, они могут предоставлять надежные предварительные подтверждения быстрее, чем время блока в блокчейне.
• основанная на последовательности - пользователи также могут напрямую отправлять транзакции на свой бл, но они обрабатываются с задержкой в n блоков (где n достаточно мал). Это значительно сокращает "время до окончательной безопасности", и на самом деле они даже называют этот дизайн "основанная на последовательности с мягкими подтверждениями" из-за этого! (обратите внимание, что эта определение brs будет конфликтовать с определением, которое мы предоставили ранее, то есть, что предлагающий bl должен иметь право упорядочивать br или быть им делегирован.iod).

для не-BRS - ttps обеспечивает быстрые предварительные конфигурации, а bl обеспечивает окончательную безопасность.

почему?

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

Эти BRS с предварительными подтверждениями больше не обеспечивают простоту или реальную безопасность Ethereum в реальном времени. Тогда, в чем смысл всего этого? Почему бы нам просто не улучшить откаты на «традиционных» роллапах? Что вообще такое «базовый роллап» на данный момент?

это на самом деле возвращается ко мнеДоказательство управления Пост за прошлый год, в котором я обсуждал фундаментальные варианты использования рестейкинга, специфичного для Ethereum:

1) технический (обязательства предложителя) - здесь нет другого выхода - если вы хотите достоверного обязательства по порядку блока Ethereum, оно должно поступить от проверяющих Ethereum.MEV-Boost++ является одним из примеров гипотетического приложения, которое может попасть в эту категорию.

2) Социальные сети - Я рассматриваю выравнивание Ethereum как основной вариант использования для большинства приложений на сегодняшний день, а не объединение экономической безопасности или децентрализации. Он собирается сказать: «Смотрите, мы проект EthereumЭто та же самая причина, по которой блокчейны продолжают называть себя Ethereum L2S независимо от архитектуры.

Мы можем модернизировать это в контексте задания вопроса, какова ценность "br + preconfs" по сравнению с "традиционным роллапом + быстрым откатом"?

1) Технические (Proposer commitments) - Ethereum BRS с преконфами имеют одно фундаментальное техническое преимущество - они могут получить надежное обязательство от текущего инициатора Ethereum в отношении включения и упорядочения содержимого блока Ethereum. Это потенциально ценно по тем же причинам, по которым мы потенциально хотим, чтобы несколько накопительных пакетов совместно использовали секвенсор. Если BL Proposer также является BR Proposer (т. е. секвенсором), то он может предоставить те же атомарные гарантии включения с BL, что и между любыми накопителями, совместно использующими секвенсор. У них монополия на обе сети. Насколько это ценно? Мы вернемся к этому чуть позже.

2) социальное (выравнивание/заслуживающий доверия нейтралитет) – любить или ненавидеть, Выравнивание Ethereumэто преимущество продажи, чтобы быть бр. я буду честен, я не знаю ничего о тайко за пределами того, что они парни br, и я, вероятно, не знал бы, кто они были, если бы они не были парнями br. каждый хочет хорошего совместного маркетинга. есть ценность в том, чтобы быть первыми здесь, но я подозреваю, что это не долговременное преимущество и не переносится на многие будущие потенциальные бр. аналогично, мы все слышали о первой группе avss, но вы можете назвать все текущие? я не могу.

На более высоком уровне вы не получите доступ ко всем накопителям Ethereum для выбора (гипотетического) «Общего секвенсора оптимизма» или «Общего секвенсора Arbitrum». Тем не менее, у вас есть больше шансов заставить их всех согласиться на «Ethereum Shared Sequencer». Ни нового токена, ни нового бренда, ни нового консенсуса. Если вы считаете, что для всех Ethereum L2 полезно объединиться в секвенировании, то этот заслуживающий доверия нейтралитет потенциально является самым сильным аргументом Шеллинга для достижения этой цели.

эта достоверная нейтральность, вероятно, самая ценная для разработчиков роллапов, пытающихся привлечь пользователей из разных экосистем (например, приложений с базовой инфраструктурой, таких как ens). Они могут быть неуверены в использовании оптимизации последователя, если это оттолкнет пользователей арбитрума, или наоборот.

мы рассмотрим каждый из них более подробно ниже.

достоверная нейтральность

Углубляясь в этот социальный аспект, блокчейн-релейтед стартапы (БР) часто рассматриваются как максимально «выровненные с Ethereum» вариант. Отдавая должное чьему-либо суждению о ценности этого факта, важно отметить, что это предполагает высокую степень доверия и нейтральности в процессе разработки любого БР.

достоверно нейтральный br легко создать в ванильном случае, но, как мы отметили, никто действительно не хочет этого. Предварительные конфигурации обязательно требуют, чтобы предлагающий включился в дополнительные условия снижения. Эти дополнительные условия снижения требуют, чтобы предлагающий использовал дополнительную систему (например, потенциально переставление eigenlayer, Симбиотический, или другой стандарт), чтобы взять на себя обязательство. Роллап может быть счастлив, если вы выберете достоверно нейтральный «секвенсор Ethereum» в абстрактном смысле, но достоверная нейтральность, скорее всего, будет утрачена, если вы используете проекты, финансируемые из частных источников, возможно, даже с собственными токенами.

здесь есть несколько открытых вопросов относительно залога:

размер залога

Ранние проекты предполагали, что инициаторам лично придется внести невероятно высокую сумму залога порядка 1000 ETH. Проблема в том, что, по сути, инициатор всегда может нарушить свое обещание deleGate.io и самостоятельно построить блок, двусмысленно относясь к преконфам. Это может быть невероятно ценно, и 1000 ETH значительно превышают самые высокие из когда-либо наблюдавшихся платежей, которые проходили через MEV-Boost с момента его создания. Недостатком является то, что это, конечно, неизбежно создает высокий барьер для входа для небольших предложений, в то время как более крупные (например, Coinbase) могли бы более разумно выставить 1000 ETH, получая вознаграждение на весь свой вес ставки (>13% от общего объема eth стейк) потому что регистрирующиеся лица могут предоставить единую обязательную сумму для всех своих валидаторов. естьдругие идеи, чтобы позволить предложителям с гораздо меньшими облигациямино, конечно, сопряжены с определенными компромиссами. пространство дизайна здесь просто неопределенно.

стоит отметить, что Аукционы исполненияэто беспокойство, так как мы можем предположить, что все предлагающие будут опытными действующими лицами, легко способными справиться с этим.

источник: Barnabé monnot, от mev-boost до epbs до aps

Однако, даже крупные операторы сомневаются в том, чтобы выставлять большие суммы, из-за возможных проблем с живостью, приводящих к сокращению (отказ в выполнении оператором, после чего наши предподтверждения снижаются перед их включением в блок — это все равно безопасно для пользователей и должно быть строго наказано).

тип залога

ванильный eth, вероятно, единственное достоверное нейтральное залоговое обеспечение в данной ситуации. однако естественно будет желание использовать более капиталоэффективные активы (например, steth). есть некоторые идеи о том, чтобы доверенное лицо занималось этим преобразованием, как описано mteam здесь.

платформа

было бы недостаточно “credibly neutral”, если “ethereum based preconfs” больше похожи на “eigenlayer based preconfs” или “symbiotic based preconfs.” есть команды, которые планируют двигаться в этом направлении, но это не строгое требование к использованию такой платформы. возможно создать общий и нейтральный стандарт для всех, и такая система, кажется, была бы лучше подготовлена для общего принятия, как наиболее основанный вариант.

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

Предварительные подтверждения

включение против предварительных конфигураций состояния

теперь мы более подробно рассмотрим предварительные подтверждения. хотя мы ранее обсуждали конкретный тип предварительных подтверждений (предварительные подтверждения br по состоянию), мы должны отметить, что это полностью общее понятие. вы можете предлагать предварительные подтверждения по bl-транзакциям в дополнение к brs, и вы можете предлагать различные уровни предварительных подтверждений:

• inclusion preconfs - это менее обязательное обязательство в том, что транзакция в конечном итоге будет включена в блокчейн.
• state preconfs - самое сильное обязательство в том, что транзакция в конечном итоге будет включена в блокчейн и является гарантией результирующего состояния.

последнее (предварительные конфигурации государства), конечно, то, что пользователи хотят видеть в своих кошельках:

Я обменял 1 ETH на $4000 USDC и заплатил 0,0001 ETH в качестве комиссии.

не включение предконфигураций:

моя транзакция, пытающаяся обменять 1 эфир на 4000 долларов USDC и оплатить до 0.0001 эфира в качестве комиссии, в конечном итоге попадет в цепочку, но может быть успешной, а может и неудачной, посмотрим

Тем не менее, мы должны отметить, что преконфы включения эффективно взаимозаменяемы с преконфами состояния в случае действий пользователя, предпринятых в неконфликтном состоянии (например, простые передачи, когда только сам пользователь может сделать транзакцию недействительной). В этом случае обещание, что, например, «перевод USDC Алисы Бобу будет включен в следующие несколько блоков», достаточно для кошелька, чтобы просто показать пользователю: «Вы отправили свои USDC Бобу».

как ни странно, более сильные обязательства (предварительные конференции государства) труднее получить. Фундаментально, они требуют достоверное обязательствоот лица сущности, которая в настоящее время обладает монополией на предложение блоков (т.е. на запись-блокировку состояния цепи). в случае предварительных конфигураций Ethereum L1 это всегда текущий предложитель Ethereum L1. в случае предварительных конфигураций BR это, вероятно, следующий предложитель Ethereum L1 в предварительном просмотре BR (тем самым делая их текущим предложителем для BR), как мы увидим ниже. термины предложитель и секвенсор обычно взаимозаменяемы, причем первый чаще используется в контексте L1, а второй в контексте L2.

ценообразование предварительные конференции

еще одно важное различие, которое нам нужно сделать, это какого типа состояние касается этих предварительных конфигураций:

• нетребовательное состояние - никому больше не нужен доступ к этому состоянию (например, Алиса хочет перевести USDC Бобу)
• спорное состояние - другие хотят получить доступ к этому состоянию (например, свопы в пуле eth/usdc amm)

Preconfs - это ограничения на то, какой блок в конечном итоге может быть создан. При прочих равных ограничение пространства поиска для строителей неизбежно может только уменьшить потенциальную ценность, которую они могут захватить, упорядочивая ее. Это означает, что меньшая ценность будет возвращена предлагающему. Чтобы сделать это стимулирующим с точки зрения выгодности, Gate.ioway должен взимать плату за preconf ≥ потенциальный mev, потерянный из-за ограничения результата.

Это достаточно просто, когда MEV потеряно ~0 (например, в случае передачи USDC). В этом сценарии взимание некоторой номинальной фиксированной платы может быть разумным. Но у нас есть большая проблема - как нам ценить предварительные конфликты в спорных состояниях? Ценообразование предварительных конфликтов заранее по сравнению с моментом их возникновения кажется менее выгодным. При прочих равных условиях для строителя наиболее прибыльно подождать до последней возможной секунды, чтобы захватить и точно оценить MEV.

давайте предположим, что есть достаточный спрос пользователей на быстрые предварительные конфирмации для спорных состояний (учитывая как опытных искателей, так и обычных пользователей), так что иногда будет определенная цена, которая будет выгодна для всех. Теперь, как именно выставляется цена на предварительную конфирмацию для транзакции на спорном состоянии, которую вы могли бы включить в любой момент в течение следующих 12 секунд, потенциально отказываясь от более прибыльных возможностей, которые больше не будут возможны?

Преконфы о спорном состоянии, передаваемые по всему блоку, будут конфликтовать с тем, как строители создают блоки. Точное ценообразование Preconfs требует оценки в режиме реального времени влияния MEV от его включения сейчас, а не отсрочки, что означает выполнение и моделирование возможных результатов. Это означает, что Gate.ioway теперь должен быть очень сложным поисковиком/строителем.

мы уже предположили, что Gate.ioway и реле объединятся. если им нужно будет постоянно оценивать предварительные конференции, то они также объединятся с билдером. мы также приняли то, что usc ускорит объединение билдера и проверяющего. также кажется,торги исполнения будет продавать права на предложение напрямую опытным акторам (вероятно, строителям), способным установить их цену.

это помещает всю цепочку поставки транзакций ethereum l1 и br в одну коробку, которая обладает монопольным блокировкой записи на состояние всех цепей на этот период.

Политика упорядочения службы preconf неясна (например, всегда ли они запускают FCFS или упорядочивают их другим способом). Кроме того, Gate.ioway потенциально может проводить аукцион по всем преконфам (например, позволяя пользователям делать ставки на преконфы), хотя неясно, как будет выглядеть такой дизайн, и это обязательно будет означать более высокую задержку.

проблема честной биржи

Существует справедливая проблема обмена с преконфами, когда Gate.ioway на самом деле не имеет прямого стимула выпускать преконфы.

рассмотрим следующий пример:

• текущий Gate.ioway имеет монополию в течение 12с
• Пользователь отправляет запрос на транзакцию preconf прямо в начале слота (t = 0)
• Gate.ioway ждет до t = 11.5, чтобы выпустить все предварительные подтверждения, сделанные во время своего слота, оставив 500 мс буфер, чтобы включить их все в свой блок. В это время они могут решить, какие предварительные подтверждения включить, если они прибыльны, и какие исключить.

в данном сценарии пользователь может заплатить за предварительную конфигурацию, даже если фактически не получит ее до конца слота. Gate.ioway также может просто отказаться от нее в конце слота, если они решат, что это не выгодно. Это удержание со стороны Gate.ioway не является объективно признанным дефектомно это может быть интерсубъективно приписываемо)

На самом деле, у Gate.ioways есть стимул удерживать преконфы до конца. Там, где есть информационная асимметрия, есть и mev. Сохранение конфиденциальности транзакций позволит застройщику иметь более актуальное представление о состоянии мира, что позволит ему лучше оценивать риски и улавливать MEV. нет консенсуса по поводу набора преконфов, предоставляемых пользователям, поэтому Gate.ioway не может быть привлечен к ответственности.

Должны быть установлены стандартыи ожидания от предварительного подтверждающего лица, чтобы сразу же публично обсуждать все предварительные конфы. это даст пользователям то, что они хотят немедленно, и позволит другим видеть, что Gate.ioway предоставляет ожидаемые услуги. если они не сделают этого в будущем, то пользователи не будут доверять им и платить им за предварительные конфы. репутация Gate.ioway имеет значение. сказанное можно также.чрезвычайно ценный Быть нечестным здесь и вернуться против преконфов.

предварительные конфигурации базового слоя L1

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

например, Болт Это один из таких протоколов, который хочет позволить инициаторам Ethereum брать на себя надежные обязательства в отношении содержимого своего блока. Зарегистрированные проposеры могут запускать Bolt sidecar, чтобы получать preconf-запросы от пользователей, подтверждать их, а затем отправлять эту информацию ретрансляторам и построителям, которые могут возвращать блоки, которые учитывают эти ограничения (т.е. чтобы они возвращали блок, включающий транзакции, которым автор предложения передал преконфы).

важно отметить здесь, чтоBolt v1описанный здесь метод поддерживает только простую предварительную обработку транзакций для неспорных состояний, где только пользователь может аннулировать предварительную обработку. Как мы уже обсуждали, это самые простые и слабые обязательства в обеспечении.

У всех этих команд есть большие амбиции (например, предварительные конференции штата, аукционы частичных блоков, аукционы слотов или частичные аукционы слотов), так что их останавливает?

• Ответственность - нарушения обязательств должны быть доказуемы на цепочке блоков для объективного снижения. Довольно легко доказать включение транзакции, но не так ясно, как обеспечить исполнение других обязательств, таких как аукционы слотов.
• требования к капиталу - предоставление произвольных обязательств означает, что стоимость нарушения обязательства может быть произвольно высокой. Вероятно, Gate.ioways в конечном итоге потребуется заложить огромные суммы (например, тысячи эфиров), чтобы предоставить их. Возможно, они в конечном итоге будут объединены, что будет выгодно крупнейшим субъектам (например, крупным торговым фирмам или coinbase), и исключит меньшие субъекты.
• ценообразование - вокруг вопросов того, как ценить что-то вроде непрерывно транслируемого состояния, есть много открытых вопросов, даже если мы решим, что это возможно и ценно.
• Участие в сети - это, возможно, самый важный и фундаментальный момент. Как мы упоминали, только текущий предложитель, у которого есть запись-блокировка на состоянии, может предоставить обязательства, такие как предварительные подтверждения состояния. В теории 100% предложителей могут присоединиться к этой системе и имитировать это. На практике это не произойдет.

MEV-Boost, более простой продукт с многолетней историей, который невероятно выгоден в эксплуатации, имеет >92% участиедля контекста (вероятно, даже немного выше, так как это не учитываетминимальная ставка. новая услуга предварительной настройки, безусловно, получит гораздо меньшую долю участия. но даже если она сможет подняться до ~90%, это не кажется полезным продуктом для обычных пользователей. вы не можете говорить пользователям 10% времени "извините, сейчас нет доступных предварительных настроек, зайдите позже."

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

предварительные конфигурации rollup на основе l2

br preconfs должны поступать от bl предложителей (вот почему они «основаны»). для этого им необходимо заложить некоторое обеспечение и принять дополнительные условия снижения (т.е. то, что предоставляемые ими preconfs действительно попадут на цепочку, как обещано). любой предложитель, готовый сделать это, может выступить в качестве br секвенсора и предоставить preconfs.

Важно, что эти br preconfs - это не просто preconfs включения, а preconfs состояния. Это возможно потому, что br выбирают дизайн, в котором они предоставляют монополию на вращающийся секвенсор bl proposers, которые регистрируются в Gate.io.

сегодня один валидатор ethereum служит предложителем для каждого слота, и расписание предложителей всегда известно для текущей эпохи и следующей. эпоха состоит из 32 слотов, поэтому мы всегда знаем следующих 32-64 предложителей в определенное время. дизайн работает, предоставляя следующему активному последователю (т.е. следующему последователю в предвидении) монопольные права на упорядочение транзакций для brs, присоединившихся к этой системе предварительной конфигурации. Gate.ioways должен подписать, чтобы продвинуть состояние цепочек br.

Обратите внимание, что каждый инициатор (даже те, кто не выбрал быть Gate.ioway) имеет право, но не обязан, включать транзакции, которые были предоставлены преконфами секвенсорами (т.е. те пропозиционеры, которые выбрали быть Gate.ioway). Они могут выступать в качестве включателя, если у них есть полный список транзакций, которые были предварительно подтверждены до этого времени (секвенсор может создать BLOB-объект BLOB, содержащий транзакции BR, и сплетничать о них).

источник:Последовательность Ethereum, Джастин Дрейк

поток транзакций работает следующим образом:

1. пользователь br отправляет свою транзакцию следующему последователю в просмотре вперед (предлагающий слот n+1 на рисунке ниже)
2. секвенсор немедленно предоставляет предварительное подтверждение для полученного состояния (например, пользователь обменял 1 eth на 4000 долларов usdc на br и заплатил 0,0001 eth в качестве комиссии)
3. На этом этапе любой включатель может включить последовательную транзакцию (инициатор слота n делает это на рисунке ниже)

источник: Последовательность Ethereum, Джастин Дрейк

Если другие инклюзионы не включают преконфы, то секвенсор, который их дал, может просто включить их в чейн, когда наступит его очередь выступать в качестве BL Proposer. Например, на изображении выше предположим, что слот N Includer решил не включать преконфы, которые выдал слот N+1 секвенсор. Тогда секвенсор слота N+1 будет отвечать за включение всех преконфов, которые он выдал во время слота N, и слота N+1, когда он отправляет свой блок BL для N+1. Это позволяет секвенсору уверенно выдавать преконфы в течение всего периода между ними и тем, кто был последним секвенсором.

для упрощения вышеизложенного, мы только предположили, что предложитель l1 будет выполнять эту предконференционную роль. Как описано ранее, это, однако, не является вероятным. Для этого потребуется сложная сущность, которая будет определять цены на предконфы, запускать полные узлы для всех brs, иметь защиту от dos и достаточную пропускную способность для всех br transactions и т.д. Ethereum хочет, чтобы валидаторы были очень несложными, поэтому предложители, вероятно, будут outsourcить предконфы другой сущности таким же образом, как они outsourcят полное производство блоков l1 через mev-boost сегодня.

заявители могут делегировать Gate.io Gate.ioways как по onchain, так и по offchain механизмам, и это можно сделать до самого конца их слота. как уже отмечалось ранее, на практике эту роль, скорее всего, будут выполнять ретрансляторы. также возможно, что им придется объединиться с разработчиками.

источник: На основе секвенирования, Джастин Дрейк

как было описано ранее, только одной сущности может быть делегировано быть Gate.ioway в определенное время. это необходимо для обеспечения надежных предварительных установок состояния. пользовательские интерфейсы (например, кошельки типа metamask) будут следить за тем, кто следующий Gate.ioway, и отправят пользовательские транзакции туда.

эфириум-роллапы - насколько они будут основаны?

с достаточным объемом информации на месте - следует ли основываться на роллапах Ethereum? Здесь действительно есть два вложенных вопроса:

1. должны ли множество эфириумных роллапов использовать общего секвенсора?
2. если да, должен ли это быть основанный последователь (т. е. включая предлагателей блоков ethereum и окружающую инфраструктуру mev)?

Во-первых, важно отметить, что вы можете совместно использовать секвенсор с другими цепочками на нерегламентированной основе. Например, инициатор предложения Ethereum может секвенировать для вас один блок, если он предложит самую высокую цену, а затем какой-то другой консенсус BFT может секвенировать ваш следующий блок, если он предложит самую высокую цену. Тем не менее, это по-прежнему требует, чтобы цепочка полностью согласилась на этот единый общий аукцион, который может проходить синхронно с этими другими цепочками, поэтому по-прежнему существуют компромиссы в отношении контроля и гибкости (например, время совместного блока). Просто сущность победившего секвенсора может смещаться.

независимо от этого, давайте просто предположим, что условие 1 выполнено. Я думаю, у нас в настоящее время есть убедительные доказательства того, что существует достаточный спрос на использование децентрализованного общего последователя. даже если им мало важен «общий аспект», я думаю, что здесь есть невероятно высокая ценность в возможности приобретения децентрализованного последователя как услуги на полках (на самом деле, я думаю, что здесь самая большая ценность).

теперь, должен ли этот общий секвенсор быть основанным на Ethereum секвенсором?

технические (обязательства инициатора)

Я не вижу убедительного технического аргумента в пользу использования секвенсора на базе Ethereum. Любая совместимость между BRS и Ethereum L1 будет крайне ограничена из-за невозможности надежно выполняться против L1 (т. е. отсутствия постоянной блокировки записи в состоянии L1), длительных времен блоков (12 секунд) и того факта, что транзакции BRS, которые хотели бы взаимодействовать с L1, затем должны будут переорганизовываться рядом с ним. Здесь нет бесплатного обеда. Это не открывает никаких ценных пользовательских продуктов по сравнению с любым другим внешним общим секвенсором.

Основная ценность, которую я вижу, заключается в том, что добавление Ethereum L1 в этот более крупный комбинаторный аукцион может привести к созданию более высокой общей стоимости на Gate.io.позволить l1 захватить больше ценности. взяв эту логику на крайности, мы, вероятно, должны поместить все в мире на одном аукционе. этот универсальный аукцион также должен продавать билеты на концерт Тейлор Свифт. я пока не там.

это просто для того, чтобы подчеркнуть, что создание и вовлечение всех в этот общий аукцион имеет реальную техническую и социальную сложность, которая имеет реальную стоимость, и, на мой взгляд, вероятно, перевешивает любую теоретическую дополнительную созданную здесь ценность. вы можете легко создать гораздо более эффективное техническое решение для запуска этого с первых принципов, если мы не пытаемся привязать его к ethereum l1 (например, просто создать простой быстрый механизм согласования, построенный для этой цели). не говоря уже о том, что такой комбинаторный аукцион создал бы экспоненциальное возрастание сложности.

На практике у меня есть серьезный риск, что это может быть крайне контрпродуктивным для Ethereum, поскольку эта предварительная конфигурация на основе MEV, кажется, потенциально акселерационна в отношении инфраструктуры MEV, когда снабжение Ethereum уже в некоторой степени хрупкое. Это рискует подвергнуть опасности децентрализацию и устойчивость к цензуре сети - самые важные вещи, которые делают ее ценной в первую очередь.

социальное (достоверная нейтральность)

Я вижу действительно веский социальный аргумент за секвенсором на основе Ethereum.

как отмечалось ранее, безусловно, «выравнивание» является продажей для первого brs. это нормально, но я не думаю, что это продлится. быть первым br - это круто, быть восьмым - уже нет. должна быть какая-то другая добавленная стоимость.

Я думаю, что заслуживающая доверия нейтральность секвенсора на основе Ethereum потенциально является такой ценностью. Это, пожалуй, самый сильный аргумент в пользу такой конструкции, по крайней мере. Есть много сетей, которые хотят получить децентрализованный секвенсор из коробки. Если мы в конечном итоге сможем спроектировать достаточно инфраструктуры поверх этой штуки, чтобы улучшить кроссчейн-UX, то еще лучше. Из проектов, которые хотят иметь такой дизайн, я полагаю, что многие из них не решаются «выбрать чью-либо сторону» с каким-либо сторонним протоколом. Как отмечалось ранее, представьте, что вы — цепочка приложений с базовой общей инфраструктурой, такой как ENS, и вам нужен накопительный пакет. Вы же не хотите выбрать (гипотетический) общий секвенсор Arbitrum и отключить толпу оптимизма, или наоборот.

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

стоит отметить, что есть также обоснованная критика, что здесь «нейтральность» означает «эфириум». то есть его основное мотивирование заключается в пользе эфириума и его прилегающей инфраструктуры. и конечно, такая система будет выгодна для этих сторон. это означало бы больше захвата стоимости для эфира как актива и больше прибыльности для разработчиков, ретрансляторов и искателей эфира.

роллапы на основе быстрого

быстрые базовые слои

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

Как уже отмечалось, что если мы просто разработаем эту вещь с нуля. Не имея дела с техническим долгом и решениями существующей цепочки. Какой является очевидным способом построения этой вещи...

Ранее мы обсуждали, что единственной технической причиной для того, чтобы быть br с предварительными подтверждениями для данного bl (например, Ethereum), является то, что его предлагающий может предоставить достоверные обязательства в определенные моменты относительно синхронного атомарного включения с bl.

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

почему бы нам просто не использовать быстрый лингвистический блок (bl) для брс?

Это решает практически все сложные крайние случаи и проблемы, которые у нас были раньше. Мы не хотим странных крайних случаев, когда у Gate.io возникают сбои живости (которые здесь имеют тот же результат, что и сбои безопасности), мы не хотим, чтобы они отказывались от обещанных предварительных конфигураций (т.е. сбои безопасности), и мы не хотим реорганизации Ethereum. Вот почему существует консенсус.

слои мертвы, да здравствуют слои последовательности!

большинство разговоров о ленивых последователях рассматривает их как последователя rollup, который затем выгружает свои данные на какой-то другой слой данных. например, первые два rollup-а astria ( ФормаиПламяCelestia будет использоваться ими в качестве своего уровня da. консенсус астрии будет упорядочивать эти rollups, затем он будет передавать их данные в celestia.

Эта комбинация особенно хороша, потому что они очевидно дополняют друг друга - Astria предоставляет всю инфраструктуру последовательности, а Celestia обеспечивает верификацию с минимальным доверием черезвыборка доступности данных (das).

Однако Astria также может использоваться для последовательности роллапа, который является собственным для Ethereum, Bitcoin, Solana или чего угодно еще, что вы хотите. Например, его даже можно настроить для использования в качестве предварительной конференции для Ethereum «brs с предварительными конференциями» (например, вместо централизованного Gate.ioway, поскольку ленивый секвенсор в основном является поощренным и децентрализованным ретранслятором).

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

однако, как я отметил вНаследуют ли роллапы безопасность?, быстрые цепочки, такие как Astria, технически могут добавить медленный путь для DAS (для улучшения проверяемости), а медленные цепочки, такие как Celestia, могут добавить быстрый путь для секвенирования (с предположением о доверии большинства и без DAS), так называемый "быстрые блоки медленные квадраты.”

переход к вертикальной интеграции специализированных слоев, таких как секвенирование или дас, еще более сузил бы различие между модульными и интегрированными блокчейнами. то же самое относится к вертикальной интеграциисистема расчетовчерез добавлениеУчетные записи ZK-проверки до базового уровня Celestia.

однако есть смысл в том, чтобы эти сервисы оставались раздельными, а не объединялись. это модульный подход, который позволяет роллапам выбирать те функции, которые они хотят взять готовыми (например, я хочу купить децентрализованную последовательность с быстрыми блоками, но я не хочу платить за das, или наоборот). исследователи показали, что им нужны das, но пользователи пока показали, что им нужны просто быстрые блоки.

услуги пакетирования, как в «быстрые блоки медленные квадраты"был бы очень мнениями и интегрированным. это неизбежно добавит сложности и затраты. влияние длины слота наигры со временем(и, следовательно, потенциальная децентрализация), которая теперь является повсеместной на платформе Ethereum, также является одним из аспектов, которые следует учитывать.

быстрый слой основы против медленного + предварительных конфигураций

но вы также можете использовать astria как bl для rollups. shared sequencers можно рассматривать как bls, оптимизированные для brs своих собственных.

когда ваш bl быстр, ваш br не нуждается в предварительных подтверждениях, потому что он просто получает быстрые подтверждения из коробки! затем ваш rollup фактически получает реальную безопасность вашего bl, в отличие от brs + preconfs, которые обязательно теряют это.

brs без предварительных конфирмаций являются наиболее логичным способом построения rollup. Вот почему сегодняшние rollup-ы все начинаются там:

Ясно, что блокчейн с быстрыми блоками решает большинство наших проблем в «основанных на роллапах + предварительных конфигурациях». Общие последователи естественно строятся больше на подходе первых принципов «просто разработчики приложений хотят запустить быструю, надежную и децентрализованную цепь - как я могу дать им это?» Попытка добавить предварительные конфигурации после факта на более медленный базовый уровень, как, например, Ethereum, приводит к сложностям, описанным выше.

мы все строим одно и то же

модульность неизбежна

Таким образом, мы увидели, как мы можем объединять модульные цепочки Gate.io вместе, обеспечивая универсальную синхронную компоновку (usc). Конечно, есть компромиссы, но они вводят существенную степень единства, сохраняя при этом гораздо большую гибкость, чем при использовании единственного конечного автомата. Есть также очень убедительный аргумент для меня в том, что асинхронная компоновка - все, что нам нужно для подавляющего большинства случаев использования. Нам нужна низкая задержка, производительность и хороший UX. Интернет асинхронен и работает довольно круто, абстрагируя это все. Компоновка - огромное добавление стоимости криптовалют, но компоновка ≠ синхронность.

Вне зависимости от преимуществ гибкости и суверенитета, большинство людей согласятся, что в конечном итоге нам понадобятся множество цепей для масштабирования. Это означает, что мы в конечном итоге столкнемся с множеством систем, которые нам нужно объединить, поэтому модульное направление здесь неизбежно.

эфириум + предконфы → солана?

Сейчас давайте сравним конечные игры здесь. В частности, мы сравним конечную игру Solana с конечной игрой Ethereum, если он пойдет по этому пути максимизации единства и пользовательского опыта с использованием роллапов на основе базиса + предварительных конфигураций.

в этом видении у нас есть несколько этих BR, использующих основанный на Ethereum последователь. Gate.ioways непрерывно передают Proposer-Promised (т. е. без какого-либо веса согласия) Preconfs пользователям с низкой задержкой, затем эфириумные пропозеры время от времени фиксируют их в полный блок. это может показаться знакомым, потому что это в значительной степени то, что мы описывали ранее для Solana с потоковой передачей фрагментов!

Итак, это просто более сложный Solana? Большая разница здесь во времени слотов:

попытка добавить это поверх медленной цепи явно представляет проблемы с первого взгляда:

• консенсус Ethereum слишком медленен для пользователей, поэтому единственный способ получения нейтрального быстрого пользовательского опыта - это обещанные предварительные подтверждения от предлагателя на добровольной основе. Его основное узкое место сегодня - это агрегация подписей из-за огромного размера набора валидаторов (MaxEB и улучшенная агрегация подписей может помочь здесь).
• это приводит к гораздо более длительным монополиям предложителей, обеспечивая большие стимулы и свободу захватить больше MEV, действуя нечестно (например, удерживая предварительные подтверждения).
• если Gate.ioways начнет задерживать или удерживать предварительные подтверждения, то худший вариант для пользователей сводится к зависимости от времени слотов ethereum. даже если производители блоков solana остановят непрерывное построение блоков и потоковую передачу в рамках своих выделенных монополий (поэтому для них, скорее всего, рационально делать это в определенной степени по той же самой причине), то в худшем случае придется полагаться на быстро вращающуюся консенсусную сеть. Четырехместный монополия сегодня необходима для надежности сети.
• На практике вероятно будет очень мало Gate.ioways, по крайней мере на старте, что приведет к более централизованному операторскому набору по сравнению с цепочками, такими как Solana.
• потенциально чрезвычайно высокие требования к залогу для инициаторов (отмечая, что пространство дизайна все еще находится в процессе работы).
• опасения по поводу проблем с живостью здесь являются чрезвычайно дорогими (поскольку проблемы с живостью оператора, приводящие к отклоненным предварительным конференциям, приводят к сбоям безопасности для пользователей и, следовательно, должны быть существенно снижены).

все это решается с быстрым консенсусом. все эти системы буквально те, для которых мы создаем системы bft в первую очередь. почему бы ethereum просто не ускорить свой консенсус? есть ли какие-то менее очевидные компромиссы при наличии очень низких задержек времени блоков на базовом уровне?

К счастью, у меня нет ничего лучше делать, чем писать эссе о том, хорошо ли более короткие времена блоков. Большая озабоченность более короткими временами слотов связана с централизацией валидаторов и операторов. Конкретно существуют опасения относительно взаимодействия коротких времен слотов сигры по времени

Мы видим, что игры с таймингом уже развиваются на Ethereum. Предлагающие предлагают блоки позже в своих слотах, зарабатывая больше денег за счет других. Реле также предлагают "игры по времени как услуга«причем они также задерживают блоки позже в слоте:

исходный: Данные всегда

время игр были огромной темой обсуждения на несколько известномПодкаст Justin против Toly Banklessиз нескольких недель назад:

допустим, вы на 100 мс быстрее всех остальных

если у вас есть слоты на 1s, вы можете заработать на 10% больше, чем все остальные

если у вас есть слоты на 10s, вы можете заработать на 1% больше, чем все остальные

— Джон Шарбонно (@jon_charb) 4 июня 2024 года

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

лично я нахожу сложным игнорировать важность времени здесь:

• мы уже видим их на практике в ethereum сегодня.Аргумент Соланыэто происходит только потому, что МЭВ стало социально приемлемым в Ethereum раньше, но это неубедительно, когда былосильное общественное возмущение против игр на время в самом начале что с тех пор превратилось в признаниеэтой новой реальности, которая должна быть спроектирована.
• Вознаграждения за МЭВ значительны - мы уже говорим о миллиарды долларов в платежах MEV здесь, а не копейки под диванной подушкой. Даже заработать на этом «всего на несколько процентов больше» — это огромные деньги.
• даже если вы не верите, что стейкеры достаточно чувствительны к доходности на грани,фактические операторы ведут бизнеси это сразу же отражается на их финансовых результатах.
• Солане легче полагаться на альтруистичных крупных заинтересованных сторон(например, фонд и крупные инвесторы) в более ранней стадии своего развития, ноэто неустойчиво, поскольку любая сеть децентрализуется дальше.

Я ясно думаю, что в том направлении, которое выбирают и Solana, и Ethereum, есть огромное значение. Если ничего другого, мы сможем увидеть, как все это проявится на практике. Стратегически я также думаю, что Ethereum должен опираться на то, что делает его отличным здесь. Максимизировать децентрализацию как средство достижения устойчивости к цензуре в условиях противостояния. Ethereum сделало много жертв, чтобы сохранить невероятно децентрализованный протокол, потому что это необходимость для долгосрочной игры. У него нет аналогов в разнообразии клиентов, распределении собственности сети, заинтересованных сторон экосистемы, децентрализации операторов и др. Если (и скорее всего, когда) Solana столкнется с серьезным давлением цензуры в будущем, станет все более очевидно, почему Ethereum принял такие решения.

preconf.wtf только что произошло в зуберлине на прошлой неделе, и, возможно, неудивительно, все говорили о предконференциях и основанных на них rollup. и это было действительно круто. но лично я нашелВыступление Виталиканасписки включения одного бита на аттестантаи разговор о БарнабеПерегрузите предложителя выполнения вместо (от mev-boost к epbs к aps)быть самым важным для будущего Ethereum.

исходный текст: Барнабе Монно, От mev-boost к epbs и aps

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

Однако мы уже довольно глубоко зашли в «централизованное производство», не внедрив более сильных защит от цензуры, таких как списки включений. Фактически, Ethereum находится наполовину на нижней строке на этой картинке ниже (говорю наполовину, потому что цензура на самом деле не черно-белая, и Ethereum имеет только «слабую цензуру», то есть большинство, но не все блоки подвергаются цензуре, поэтому вам может просто прийтись немного подождать, а затем вы будете включены):

исходный: Доказательство управления

Эмпирически, цепочка поставок MEV Ethereum L1 в настоящее время в реальном времени цензурирует больше блоков, чем любой из этих L2 с централизованными последователями.

l2s уже могут получить окончательный cr l1 (который все еще очень хорош) без основания. Основанные предварительные конфигурации не получают реальной безопасности протокола ethereum в реальном времени, они получают реальную безопасность небольшого количества относительно централизованных поставщиков инфраструктуры вокруг него. Для лучшего реального времени cr лучшим вариантом, вероятно, будет передача последовательности некоторого типа децентрализованному последователю, работающему на простом bft consensus. Это будет гораздо более надежно, чем централизация многих цепей в настоящее время относительно централизованного узкого места. Эта ситуация может улучшиться с изменениями, такими как аукционы исполнения и списки включения, но это не совсем прямо за углом.

Учитывая все это, мне не ясно, что расширение зависимости от инфраструктуры MEV Ethereum L1, а затем укрепление ее для L2, является отличной идеей на данном этапе, когда несколько людей строят и передают все блоки Ethereum, большинство безцензурных блоков Ethereum сегодня опираются на единственного строителя (titan), и ни один из cr-инструментов еще не внедрен в протокол. Это кажется агрессивно ускоряющимся на хрупком месте. Ethereum, конечно, должен работать над улучшением UX L2, но не за счет всех основных свойств, которые мы хотели получить в первую очередь.

заключение

мы все строим одно и то же.

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

Тонкие технические различия между ними могут на практике иметь значимые последствия для того, где они в конечном итоге окажутся, и мы не можем недооценивать, насколько большую роль играет зависимость от пути в этих системах, даже когда они сходятся к схожим эндшпилям.

Кроме того, довольно невозможно рассуждать о некоторых вещах.Как выразился Виталик:

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

как и при eip-1559, нам удалось разобраться с помощью теории. мы посетили несколько прекрасных экономических конференций и узнали о опасностях первичных аукционов и о том, как они плохи, и выяснили, что вторичные аукционы не являются надежными, а затем обнаружили, что давайте используем механизм, который устанавливает фиксированную цену на каждый блок, и мы смогли сделать многое с микроэкономикой.

но aps не такой, правда? а вопрос, будет ли aps приводить к тому, что citadel или jane street или justin sun или кто-то другой будет производить 1% всех блоков ethereum или 99%, очень очень сложно, вероятно, невозможно выяснить из первых принципов.

Итак, то, что я хочу увидеть на данный момент, это живые эксперименты... Лично для меня разница между сегодняшним днем и тем, что я чувствую себя по-настоящему комфортно с APS, в основном заключается в том, что APS успешно работают на Ethereum L2, который имеет среднюю ценность, активность, сообщество и фактическую конкуренцию, происходящую и которая длится в течение года, возможно, дольше в течение года, и мы действительно можем увидеть некоторые живые последствия».

Итак, да, я тоже не знаю, что произойдет. Нам просто придется подождать и посмотреть. В любом случае, пока мы все сходимся к чему бы это ни было, у нас гораздо больше общего, чем нечего, поэтому давайте убедимся, что...

отказ:

1. эта статья взята из [ dba]. переслать оригинальный заголовок «Мы все строим одно и то же». Все авторские права принадлежат оригинальному автору [Джон Шарбонно]. если есть возражения против этой перепечатки, пожалуйста, свяжитесь сGate.io изучениекоманда, и они незамедлительно справятся с этим.
2. отказ от ответственности: мнения и взгляды, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate.io Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.