В этом документе анализируются ключевые технологии общих секвенаторов: высокая устойчивость к цензуре, простота развертывания, совместимость, быстрота определения и мгновенность. Теория агрегации открывает для него новую перспективу, а вертикальная интеграция направляет его дальнейшее развитие.
Оригинальное название: "The Shared Sequencer"
Автор: MAVEN11
Сборник: Kxp, BlockBeats
Представьте, на что было бы похоже, если бы Rollup «из коробки» мог достичь высокой степени устойчивости к цензуре, простоты развертывания, функциональной совместимости, быстрой завершенности, живучести и демократизации MEV. Это может показаться грандиозной целью, но с появлением Shared Sequencer она может вскоре стать реальностью. Однако не все накопительные пакеты одинаковы, поэтому нам необходимо подумать о том, как распределять вознаграждения и MEV в общей сети секвенсоров. В этой статье мы исследуем, как реализуются сети с общим ранжированием, и свойства, которых можно достичь.
Общие сети секвенсора впервые были представлены Алексом Беккетом, позже Эваном Форбсом (и Радиусом) из команд Celestia и Espresso, а новая статья Джона Шарбонно раскрывает эту тему более подробно. Джош, Джордан и их команда Astria создают первую готовую к производству сеть секвенаторов с общим доступом. Astria Shared Orderer Network — это модульная цепочка блоков, которая объединяет и упорядочивает транзакции Rollup, не выполняя их.
В настройках Astria сортировщик отправляет упорядоченные блоки на уровень DA, а также на узлы Rollup. Накопители получают мягкие гарантии окончательности от заказчика и жесткие гарантии окончательности от уровня DA (после того, как блоки завершены), а затем они будут выполнять действительные транзакции.
Сеть общих секвенсоров, по сути, представляет собой группу секвенсоров, совместимых с Rollup, и, как следует из ее названия, она может предоставлять услуги для различных Rollup. Это имеет различные компромиссы и свойства, которые мы подробно рассмотрим позже. Во-первых, мы должны описать наиболее важные свойства сортировщика (или набора сортировщиков). В Rollup основным требованием к секвенсору или группе секвенсоров является устойчивость к цензуре или живучесть (некоторые из которых исходят от базового уровня, а также безопасность). Это означает, что действующая транзакция, представленная заказчику, должна быть включена в цепочку в течение конечного времени (параметр timeout). Группе общих заказов нужно только убедиться, что транзакции включены в блоки (т. е. crLists).
Удовлетворить одновременно сопротивление цензуре и оперативность довольно сложно, как мы обрисовали во второй части Modular MEV. В алгоритме консенсуса, таком как Tendermint, вы можете обеспечить восстановление после атаки. Однако в случае нападения вы теряете непосредственность. По сути, требование ко всем остальным подборщикам подписывать блок вместо выбора пользовательской мастерноды, вероятно, не оптимально. Хотя это повышает устойчивость к цензуре, это происходит за счет «централизации» и извлечения MEV в одну мастерноду. Другой доступный механизм сортировки можно сравнить с Multiplicity от Duality, который является их небольшим инструментом для немастернод (или сортировщиков) для включения других транзакций в блоки. В целом, в большинстве согласованных протоколов трудно добиться сопротивления цензуре и немедленного реагирования после атаки.
Другим алгоритмом консенсуса, который можно использовать, является HotStuff 2, который обеспечивает немедленность в случае атаки.
Это позволяет избежать ожидания максимальной сетевой задержки (тайм-аута) в случае цензуры или отсутствия подписи для выбора новой мастерноды. Причина, по которой он может быть интересным алгоритмом консенсуса для децентрализованного набора заказчиков, заключается в том, что он решает проблему немедленности в консенсусе без добавления дополнительного этапа. Если мастернода знает самую высокую блокировку (наибольшее количество участников, согласившихся на определенный выход) и может убедить честные стороны, проблема решена. Если нет, то честная мастернода после определенного момента может взять на себя управление продвижением, помогая следующей мастерноде. Например, узлу Hotstuff не нужно подтверждать сообщение о переключении перед уведомлением нового мастера, но он может напрямую переключиться на новое представление и уведомить нового мастера.
Разница с Tendermint заключается в том, что, хотя оба они двухфазные (Hotstuff1 имеет три, Hotstuff2 — два), Tendermint имеет линейную коммуникацию, но не отвечает, в то время как Hotstuff2 реактивен. Если есть цепочка честных мастернод, протокол отвечает положительно, так как все шаги, кроме предложения первой мастерноды, зависят от получения объема информации на предыдущем шаге. В настройках общего ордера это позволяет протоколу достичь большей оперативности, не возвращаясь к нижнему уровню, но не отменяя эту возможность.
Построение общих групп сортировщиков
Некоторым заказчикам разрешено отправлять транзакции на расчетный уровень (уровень, на котором находится Rollup). Вы можете присоединиться к этой группе подборщиков, если выполнены определенные требования и не достигнуто необходимое количество производителей блоков. Это оптимизирует задержку, пропускную способность и многое другое. Эти требования аналогичны тем, которые необходимы для того, чтобы стать валидатором блокчейна. Например, вы должны соответствовать определенным требованиям к оборудованию, а также внести первоначальный депозит, особенно если вы хотите обеспечить уверенность в финансовых условиях.
Общая группа заказов (или любая децентрализованная группа заказов) состоит из нескольких компонентов, которые работают вместе для обеспечения правильной обработки транзакций, в том числе:
Предоставьте JSON-RPC для каждого свертки для отправки транзакции (для неполных операторов узла) на узел в качестве пула памяти, а затем создайте и отсортируйте. В мемпуле нужен какой-то механизм для определения очереди, а также процесса выбора транзакций, чтобы обеспечить эффективное построение блоков.
Алгоритм построения блока/пакета, отвечающий за обработку транзакций в очереди и преобразование их в блоки или пакеты. Этот шаг может также включать сжатие для уменьшения размера результирующего блока (так называемое сжатие данных). Как уже упоминалось, это должно быть отдельно от Proposer, по сути, PBS. Данные могут быть сжаты различными способами, например:
Нет RLP-кодирования — однако для этого может потребоваться децентрализованный набор сортировщиков, чтобы помочь нормализовать передачу данных между узлами, тем самым экономя место.
Опустить одноразовый номер (уникальный номер, подтверждающий достоверность данных в конкретном блоке) — его можно пересчитать во время выполнения, взглянув на предыдущее состояние цепочки.
Упрощение цены на газ - установите газ на основе фиксированного диапазона цен.
Упрощение газа - Помимо цены на газ, есть еще и система нумерации газа.
Заменить адрес индексом — Rollup может хранить индекс сопоставленного адреса вместо сохранения полного адреса.
Значения выражены в экспоненциальном представлении — поля значений в транзакциях Ethereum выражены в вэй, поэтому значения большие. Вы не можете опустить числовые поля или сократить их до фиксированного набора значений. Однако вы можете записать его в экспоненциальном представлении, чтобы оптимизировать хранение данных:
Отсутствие полей данных: поля данных не требуются для простых переводов, но необходимы для более сложных транзакций.
Замените отдельные подписи агрегированными подписями BLS: подписи являются крупнейшим компонентом транзакций Ethereum. Вместо хранения каждой подписи вы можете хранить агрегированные подписи BLS для определенного количества транзакций. Вы также можете проверить совокупную подпись BLS на соответствие набору сообщений и набору отправителей, чтобы убедиться в ее достоверности.
Используйте поле «От» в качестве индекса: как и поле «Кому», вы можете использовать поле «От» в качестве индекса для сопоставления.
Интересная концепция «модульного» дизайна заключается в том, что вы можете вносить коррективы и компромиссы по мере необходимости, чтобы он работал для вашего накопительного пакета.
Уровень одноранговой сети позволит заказчикам получать транзакции от других заказчиков и распространять блоки после создания. Этот шаг имеет решающее значение для обеспечения эффективной работы общего секвенсора в нескольких сводках.
Алгоритм ротации мастеров для общих наборов заказов (консенсус не требуется в случае выбора одного мастера). Вы можете установить только алгоритм ротации главного узла или выбрать маршрут производителя блоков с несколькими параллельными потоками, предложенный Duality.
Алгоритмы консенсуса, такие как вышеупомянутый Tendermint или Hotstuff2, могут гарантировать, что узлы Rollup согласуются с последовательностью, предложенной реестром.
RPC-клиент для отправки блоков/пакетов на базовый уровень консенсуса DA+, чтобы блоки/пакеты можно было безопасно добавлять на уровень DA, обеспечивая «окончательную» завершенность и делая все данные транзакций доступными в цепочке.
Разделите роли строителей и производителей блоков, чтобы обеспечить справедливость и последовательность и избежать кражи MEV. Также удаляет выполненную сортировку, что важно для оптимизации эффективности, снижения PGA и увеличения CR.
Узлы свертки получают упорядоченные блоки от сортировщика для мягкой отправки и получают упорядоченные блоки слоя DA для жесткой отправки. *
Данные о вызовах сначала публикуются в базовой сети, где выполняется консенсус, чтобы гарантировать транзакции пользователей и сводных данных. Затем узел Rollup выполняет транзакцию и отправляет функцию перехода состояния в каноническую цепочку Rollup. Сеть общих заказчиков обеспечивает Rollup оперативностью и устойчивостью к цензуре. Роллапы сохраняют свой суверенитет, поскольку все данные транзакций хранятся на базовом уровне, что позволяет им разветвляться от общего ордера в любое время. Корень состояния функции перехода состояния свертки (STF) вычисляется из корней транзакций (входных данных), отправленных из общего ордера на уровень DA. В Celestia корни состояния генерируются, когда данные добавляются в цепочку и достигается консенсус. Поскольку у вас уже есть корень транзакции (и все доступные данные), Celestia может предоставить легкие клиенты (ноды Rollup, работающие на Celestia) с небольшим доказательством включения.
Чтобы обеспечить ожидаемый пользовательский опыт, узлы Rollup получают упорядоченные блоки (которые также отправляются на уровень DA). Это может предоставить Rollup мягкие детерминированные гарантии — гарантии того, что блоки в конечном итоге будут упорядочены по порядку на уровне DA, после чего узлы Rollup выполнят транзакции и предоставят новые корни состояния.
Создание блока и слот
Чтобы определить время создания блока, секвенсору необходимо установить слот. Секвенсор должен отправлять пакеты через фиксированные интервалы (обычно X секунд), где X — время слота. Это гарантирует, что транзакции обрабатываются быстро и эффективно, потому что в противном случае мастернода для определенного слота истечет время ожидания и потеряет вознаграждение за подпись (и вознаграждение за выполнение). Например, время блока Celestia (согласно спецификациям GitHub) составляет около 15 секунд. Поскольку это известно, мы можем сделать некоторые предположения о том, сколько «слотов/блоков» у нас может быть от общего набора координаторов до уровня DA, а узлы свертки загружаются в финализированные блоки. В этом отношении мы можем обратиться к оптимизированным Tendermint или Hotstuff2.
В одном и том же слоте мы можем отправлять несколько пакетов транзакций, при условии, что дизайн включает механизмы для полных узлов Rollup для их эффективной обработки в один блок (в пределах этого периода времени и параметров тайм-аута). Это помогает оптимизировать создание блоков и обеспечивает быструю обработку транзакций. Кроме того, слоты также могут использоваться для облегчения выбора главных узлов сортировщика. Например, вы можете случайным образом выбрать главный узел слота из пула ставок на основе веса ставок. Лучше всего делать это таким образом, чтобы сохранить конфиденциальность и использовать что-то вроде тайных выборов лидера для минимизации цензуры или даже установить технологию распределенного валидатора, такую как решения наподобие Obol/SSV. Задержка и время слота оказывают большое влияние на отправку блоков и сборку протокола. Поэтому нам нужно посмотреть, как это повлияет на систему. У Bloxroute есть отличные исследования и данные, в частности, по Ethereum. В MEV-Boost участвующие производители блоков (валидаторы или секвенсоры в случае Rollup) запрашивают GetHeader у ретранслятора. Это дает им значение ставки блока, которое является значением конкретного блока. Это может быть блок с наибольшим значением, полученным каждый раз. Для каждого слота валидаторы обычно запрашивают GetHeader примерно через 400 мс после запуска слота — из-за большого количества валидаторов ретрансляторам часто приходится отправлять многочисленные запросы. Это также может произойти с большими общими группами сортировщиков. Это означает, что вам нужна инфраструктура для облегчения этого процесса.
Ретрансляторы также помогают разделить строителей и производителей блоков, а также проверяют, построили ли строители правильные блоки. Они также проверяют правильность оплаты сборов и служат защитой от DoS-атак. Кроме того, они в основном являются хранителями блоков и занимаются регистрацией валидаторов. Это особенно важно в архитектуре неограниченного секвенсора, поскольку вам нужно отслеживать, кто участвовал, а кто нет (например, уровень синхронизации, рассмотренный ранее).
Что касается времени блока (т. е. блоков, отправленных создателями), то оно обычно составляет около 200 миллисекунд. В основном они начинают выполняться до/после примерно 200 мс, хотя, как и GetHeader, существуют значительные различия. Если билдер отправит блок на несколько ретрансляторов, это вызовет значительную задержку. Bloxroute также рассмотрел, что происходит, когда блоки отправляются на несколько ретрансляторов. Как и следовало ожидать, задержка распространения блока на большее количество ретрансляторов будет больше. В среднем второму ретранслятору требовалось 99 миллисекунд, чтобы провести блок, третьему — 122 миллисекунды, а четвертому — 342 миллисекунды.
Что мы, вероятно, узнали за последние несколько месяцев, так это то, что RPC очень важен для блокчейнов. Это огромная нагрузка без надлежащей инфраструктуры, и наличие надлежащего варианта RPC также имеет решающее значение. В этом случае RPC важен для розничных инвесторов, отправляющих свои транзакции в RPC (и в публичный мемпул). Bloxroute провел небольшой тест с 20 транзакциями, отправленными на различные RPC, и измерил время, необходимое для включения каждой транзакции в блок.
Источник: Bloxroute Labs
Интересно, что некоторые RPC не включают транзакции до тех пор, пока не пройдет несколько блоков, в зависимости от того, какой билдер выиграет в следующем блоке. Если RPC отправляет транзакцию большему количеству сборщиков, то вероятность быстрого включения выше. Хотя инициаторы транзакций могут использовать свое уникальное положение для потока заказов к конкретным строителям или даже создавать свои собственные блоки.
Их производительность также интересна в статистике производительности эстафеты Ethereum. Это помогает нам глубже понять, как PBS работает в мире с несколькими валидаторами, сборщиками и ретрансляторами, чего мы надеемся достичь с помощью обновления Rollup. У Метрики есть отличные статистические данные по этому вопросу, и все точки данных связаны с ними.
Важно отметить, что пропущенные ставки происходят, когда ожидается, что ретранслятор сделает ставку, но не делает ставки. Целевые ожидания исходят от валидаторов, зарегистрированных в конкретном ретрансляторе для любого заданного слота. Это не является ошибкой реле как таковой и не обрабатывается таким образом на уровне протокола.
Источник: app.metrika.co
Если происходит сбой (например, реле, обслуживающее недопустимый блок), и он виноват, это будет считаться сбоем. Обычно это происходит нечасто и в основном связано с ошибками при регистрации (например, лимиты газа или сборы, которые не соответствуют регистрации для определенного валидатора). Еще реже встречаются сбои уровня консенсуса, которые несовместимы с правилами уровня консенсуса Ethereum, такие как неправильные слоты или родительские хэши, не выровненные с предыдущим блоком и т. д.
С точки зрения задержки (например, времени, которое требуется валидатору для получения заголовка блока, созданного компоновщиком), данные очень непротиворечивы. Хотя есть некоторые отклонения, например, запрошенный ретранслятор находится в другом географическом местоположении, чем выбранный валидатор.
Источник: app.metrika.co
Что касается строителей, общее количество строителей на MEV-boost составляет около 84 человек, при этом три лучших строителя строят около 65% построенных блоков. Хотя это может вводить в заблуждение, поскольку они также являются самыми продолжительными сборщиками. Результаты аналогичны, если сократить временные рамки. Количество фактически активных строителей намного меньше: 35 за последние 30 дней и 24 за последнюю неделю. Конкуренция жесткая, и обычно побеждает сильнейший строитель. Исключительный поток заказов может уже существовать, что только усугубит ситуацию. Мы ожидаем, что распределение сборщиков останется относительно централизованным (поскольку это гонка за оптимальный поток заказов и оптимизацию оборудования), если мы не внесем серьезные изменения в настройку. Хотя это и не является фундаментальной проблемой, это по-прежнему центральная сила в стеке, и мы хотели бы услышать идеи о том, как бросить вызов статус-кво здесь. Если вы заинтересованы в более глубоком изучении этой (серьезной) проблемы, мы настоятельно рекомендуем прочитать статьи Quintus о потоке заказов, аукционах и централизации.
Что касается роли Builder в будущем стеке модульности, мы почти уверены (по крайней мере, в настройке Cosmos SDK) мы увидим настройку модулей Builder, подобную Skip/Mekatek. Другим решением является настройка типа SUAVE, например, специальная глобальная цепочка строителей, предоставляющая услуги построения блоков и предпочтения ставок для любого количества цепочек для обеспечения PBS. Позже мы более подробно рассмотрим это решение и предоставим некоторые ответы на вопросы, которые здесь не рассматриваются.
Что касается реле, мы настоятельно рекомендуем прочитать статью Анкита Чиплункара из Frontier Research и Майка Нойдера из Ethereum Foundation под названием «Оптимистические реле и где их найти». В этом посте подробно рассказывается, как работают реле в MEV-boost, их текущие компромиссы и эксплуатационные расходы, а также некоторые изменения, которые могут повысить эффективность. Интересно, что запуск реле в MEV-Boost в настоящее время стоит около 100 000 долларов в год, согласно оценкам Flashbot.
Детерминированный
Прежде чем мы поговорим о детерминизме модульных блокчейнов (как они выглядят в настоящее время), давайте взглянем на нашу предыдущую статью «Модульный MEV». Обратите внимание, что это не «официальный» и не всеобъемлющий взгляд на окончательность, но мы считаем, что он наиболее точно отражает нюансы окончательности свертки для простоты понимания.
Pending_On_L2: заказчик объединения представляет собой мягкое обязательство о том, что транзакция пользователя в конечном итоге будет зафиксирована и завершена на базовом уровне его безопасности.
Finality_On_L2: Секвенсор зафиксировал функцию перехода состояния Rollup, и блок был добавлен в каноническую цепочку Rollup.
Pending_On_L1: функция ввода или вывода/перехода состояния транзакции была опубликована в L1, но подтверждение достоверности еще не выдано, или период арбитража еще не закончился — для этого требуется Ethereum в течение двух последовательных эпох. Это момент, когда большинство оптимистичных накопительных пакетов говорят, что они достигли окончательности, но на этом этапе все еще существует произвольный 7-дневный период испытаний в соответствии со спецификацией межсетевого моста.
Окончательность_On_L1: для Optimistic Rollup закончился арбитражный период или опубликованное и проверенное доказательство действительности было подтверждено квалифицированным большинством в двух последовательных эпохах.
Теперь в Sovereign Shared Sort Rollup это выглядит немного по-другому, попробуем объяснить это на схеме:
В этом случае теоретически мы можем получить детерминизм на L1 раньше, чем на L2 и т. д.? Да, в этом случае L2 все-таки суверенен. Это предполагает, что нет никаких доказательств мошенничества и периодов оспаривания, или вы используете доказательство действительности.
Так как же нам достичь этих уровней завершенности? Завершенность блока достигается, когда в каноническую цепочку добавляется блок, который нельзя отозвать. Однако здесь есть свои нюансы, в зависимости от полных или легких узлов. В случае упорядоченного блока он является детерминированным, если он включен в блок уровня DA. Блоки (с корнями состояния) применяются с помощью полных узлов/валидаторов Rollup, что дает им гарантию действительного корня состояния, полученного из упорядоченных блоков базового уровня. Для детерминизма за пределами полных узлов (например, для легких клиентов или мостов между цепями) вы должны быть уверены в достоверности этого корня состояния. Здесь вы можете использовать один из методов, описанных ниже. Кроме того, другой подход заключается в том, чтобы заставить валидаторов нести ответственность за правильное доказательство корня состояния (оптимистический маршрут) через залог и последующее доказательство мошенничества. Дополнительно можно предоставить подтверждение действительности (ЗК).
Различные способы достижения завершенности блока:
С помощью Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) и других вероятностных методов.
Доказуемый метод с помощью достаточного количества членов комитета, подписывающих блоки. (например, Tendermint 2/3, Hotshot2 или другие типы PBFT)
Зависит от порядка транзакций/блоков на уровне DA и его правил, а именно правил выбора канонической цепочки и форка.
Мы можем достичь различных типов завершенности с помощью различных механизмов.
Одним из типов окончательности является «мягкая завершенность» (например, ожидание), которая может быть достигнута путем избрания одного лидера. В этом случае каждый слот будет иметь только один или ноль блоков (зафиксированных или нет), и уровень синхронизации может безопасно предположить последовательность транзакций в этих блоках.
Другим типом окончательности является «доказуемая завершенность», которая обеспечивает более сильные гарантии (по существу окончательные), чем мягкая окончательность. Для достижения доказуемой окончательности большинство заказчиков должны подписать блок, тем самым выразив свое согласие с тем, что блок является каноническим. Хотя этот подход хорош, в нем может не быть необходимости, если были реализованы выборы одного лидера, поскольку он, по сути, гарантирует блочный порядок. Очевидно, это зависит от конкретного реализуемого алгоритма выбора лидера. Например, это реализация на 51%, реализация на 66% или один лидер (желательно случайный (VRF) и тайные выборы). Если вы хотите узнать больше о детерминизме в Ethereum, прочитайте эту статью, которую мы настоятельно рекомендуем, и статью, которую мы порекомендуем позже для неограниченных наборов сортировщиков.
лицензированный, полулицензионный или неразрешенный
Чтобы предотвратить потенциальные DoS-атаки, необходимо установить экономические барьеры для присоединения к группе заказчиков и отправки транзакций на уровень заказчиков. В ограниченных (конечное количество сортировщиков) и неограниченных (неограниченное количество сортировщиков) группах должны быть установлены экономические барьеры для отправки пакетов на уровень DA, чтобы предотвратить уровень синхронизации (распространение блоков между сортировщиками) Замедление или DDoS-атака . Однако сам уровень DA также обеспечивает некоторую защиту, поскольку отправка данных на него требует затрат (da_fee). Залог, необходимый для присоединения к неограниченной группе, должен покрывать любые дополнительные расходы, необходимые для предотвращения рассылки спама на уровне синхронизации. С другой стороны, маржа, необходимая для присоединения к ограниченной группе, будет зависеть от спроса (сбалансированного с точки зрения затрат и доходов).
Для неограниченного набора сортировщиков мы не можем добиться доказуемой окончательности на уровне сортировщика (поскольку мы никогда точно не знаем, сколько активных избирателей/подписавшихся). С другой стороны, в ограниченной группе коортеров доказуемая завершенность может быть достигнута большинством коортеров, подписывающих блоки. Это требует, чтобы уровень синхронизации знал об уровне секвенсора и о том, сколько секвенсоров активно в любой момент времени, что требует дополнительных затрат. В ограниченном наборе сортировщиков (например, до 100) вы также можете оптимизировать количество сортировщиков для повышения «производительности», хотя и за счет децентрализации и устойчивости к цензуре. Важность ограниченных групп и экономических гарантий для обеспечения «быстрой» доказуемой определенности также детерминистична.
Типы неограниченного сортировщика и ограниченного сортировщика также отражены в традиционных блокчейнах, например, PoS (Casper+LMD-GHOST) в Ethereum использует неограниченный тип, а цепочка на основе Cosmos SDK/Tendermint использует ограниченный тип. Интересная мысль: ожидаем ли мы увидеть экономику, подобную доказательству доли, и варианты от сообщества вокруг общих заказчиков? В связи с этим мы наблюдаем движение к централизации некоторых сущностей (поэтому неограниченность не имеет большого значения, если у вас уже есть какие-то крупные провайдеры/пулы proof-of-stake). Хоть они и «прячут» централизацию, в конце концов, вы все равно можете майнить, если хотите. С идеологической точки зрения выбор почти всегда должен быть неограниченным, но помните, что экономические принципы в любом случае делают их очень похожими. Независимо от того, кто является участниками, экономика того, что вы платите, должна быть одинаковой, например, стоимость DA и стоимость оборудования (хотя это может быть уменьшено за счет количества доказательств доли, которые вы распределяете и испытываете, а также эффективности). эксплуатации инфраструктуры). Даже в ограниченном мире PoS мы видели, как группа поставщиков инфраструктуры стала крупнейшими и наиболее распространенными валидаторами почти во всех цепочках. В большинстве цепочек Cosmos зависимости между валидаторами уже очень велики, и это, безусловно, представляет опасность для децентрализации и сопротивления цензуре указанных цепочек. Тем не менее, совсем другой факт заключается в том, что любой розничный инвестор может поставить любую сумму с любым валидатором по своему выбору. К сожалению, это обычно ставится в начало списка, и жизнь продолжается. Мы снова спрашиваем: ожидаем ли мы подобной экономической модели в модульном мире? Хотелось бы, чтобы это было не так, но со специализацией вам часто требуется наилучшее соответствие — и они, как правило, являются профессиональными поставщиками доказательств доли. Мы также рассмотрим эти экономические вопросы в отдельной главе позже.
Однако во всех этих вопросах важно помнить одну важную вещь: самое главное — это аутентификация конечного пользователя, которая доступна всем, где бы они ни находились (даже в Гизе) через легкие клиенты и пирамиду DAS).
Источник: @JosephALChami
Вот компромиссы и преимущества ограниченных и неограниченных сортировщиков:
Неограниченный набор сортировщиков:
Любой, у кого достаточно облигаций/стейкинга, может стать сортировщиком = высокая степень децентрализации
Выбор одного лидера невозможен, так как сортировщик практически бесконечен.
Возможен неединый выбор лидера через VRF, но определить параметры VRF затруднительно, т.к. неизвестно, сколько будет заказчиков. Это также должны быть тайные выборы лидера, если это возможно, чтобы избежать DoS-атак.
Отсутствие выборов лидера = пустая трата ресурсов. Проблема: Создание блоков — это, по сути, свободное соревнование, и выигрывает тот, кто представит первый действительный блок/партию, а все остальные проигрывают. · · · Нет доказуемой достоверности на уровне заказчика, только вероятностный: например, LMD Ghost+Casper
Окончательность достигается только после того, как пакеты будут записаны на уровень DA (ограничено только базовым временем блока, 15 секунд в случае Celestia).
Неограниченные множества «лучше» устойчивы к цензуре, чем ограниченные множества.
Ограниченное множество сортировщиков:
Это одно из решений Эфириума для детерминизма одного слота и наличие суперкомитета «большинства».
Существует ограничение на количество секвенсоров, разрешенных в любой момент времени.
Ограниченные множества более сложны, чем неограниченные множества.
Могут быть реализованы выборы одного лидера, обеспечивающие сильную детерминированную гарантию для уровня сортировщика.
Уровень синхронизации должен понимать набор ордеров, чтобы определить, какие блоки действительны.
Запись наборов сортировщиков (или изменений наборов) в блоки расчетного уровня (такие как правила выбора ответвлений), которые записываются на уровень DA, позволяет уровню синхронизации независимо определять набор сортировщиков. Например, это то, что делает накопительный пакет Sovereign Labs: изменения коллекции записываются в доказательство достоверности, публикуемое на уровне DA.
Строгие гарантии окончательности уровня заказчика могут не понадобиться, если уровень DA достаточно быстр (однако большинство современных неоптимизированных настроек уровня расчетов имеют время блока не менее 10+ секунд).
Существует значительное пространство для разработки того, как эти наборы сортировщиков контролируются, а новые элементы добавляются или удаляются. Например, будет ли это достигнуто с помощью управления держателями токенов (как насчет множества разных токенов и накопительных пакетов, использующих коллекции?). Это означает, что сигнализация об изменениях вне сети может быть возможна благодаря социальному консенсусу (например, возьмем Ethereum в качестве примера). Однако помните, что фактический консенсус в сети четко установлен, и наказания за нарушение правил консенсуса уже существуют.
Экономический механизм для общих сортировщиков
Экономика совместного использования сети секвенсоров допускает некоторые интересные варианты. Как мы обсуждали ранее, валидаторы в общей сети заказов не сильно отличаются от типичных валидаторов L1. Сеть, в которой он участвует, просто более оптимизирована для выполнения одной задачи — получения намерений (ранее PBS) и, следовательно, предложения и заказа транзакций. Как и у «обычных» валидаторов, здесь есть компоненты дохода и затрат. С обеих сторон уравнения сети, в которых участвуют валидаторы, обладают большой гибкостью, подобно обычному L1.
Доход поступает от пользователей или роллапов, с которыми они в конечном итоге хотят взаимодействовать, уплачивая определенную плату за использование общего секвенсора. Эта плата может быть в процентах от снятых MEV (ввод цифр может быть затруднен для приблизительного определения), межсетевыми переводами стоимости, газом или фиксированной комиссией за взаимодействие. Наиболее подходящее решение для получения дохода может состоять в том, чтобы платить общему заказчику меньше стоимости, чем дополнительная стоимость, полученная с помощью общего заказа Rollup, наряду с преимуществами общей безопасности и ликвидности. Но недостатком этого является то, что трудно количественно оценить преимущества децентрализации другой части стека. Однако по мере того, как общая сеть заказов вырастает в собственную экосистему, ее способность взимать комиссионные может увеличиваться. Это в значительной степени связано с присущей им способностью легко агрегировать с определенной экономией за счет масштаба. По мере того, как к сети будет присоединяться все больше накопительных пакетов и приложений, все больше и больше междоменных MEV смогут извлекаться.
С точки зрения стоимости, общие сети заказов также имеют конкурирующие варианты. Они могут легко финансировать использование своей сети, оплачивая стоимость публикации на уровне DA или даже стоимость взаимодействия с приложениями в Rollup. Это похоже на стратегию, используемую компаниями Web 2.0, где вы берете на себя первоначальные убытки от привлечения пользователей (или объединения) в надежде, что их долгосрочный доход перевесит комиссионные. Еще один более новый или крипто-родной метод — разрешить Rollup оплачивать сборы DA с помощью собственного токена. Здесь уровень общего сортировщика несет риск ценообразования между токеном, необходимым для публикации данных на уровне DA, и собственным токеном Rollup. По сути, это по-прежнему общие первоначальные затраты на сортировщик, но он обеспечивает согласованность экосистемы за счет получения токена «поставщика» (т. е. накопительного пакета). Это чем-то похоже на конструкцию склада, которую мы объясняли в документе AppChain, и для снижения затрат можно использовать различные формы DA. Различные уровни DA будут предлагать разные цены из-за использования, возможности пользователей легко проверять через облегченный клиент или просто выбирать разные размеры блоков. Наконец, общий ордер может также пакетировать транзакции перед публикацией на уровне DA. В случае с ZKR это может снизить транзакционные издержки за счет определенного количества балансов транзакций, а с точки зрения ORU вы можете выполнять различные оптимизации газовой пакетной обработки, которые мы сейчас можем наблюдать на различных накопительных пакетах. Это уменьшит объем данных, которые необходимо опубликовать на уровне DA, тем самым снизив стоимость сети с общим секвенсором и повысив рентабельность всей сети. Это произойдет за счет ограничения совместимости и изменения времени завершения блока (детерминизм на L1, как упоминалось ранее).
В целом, экономика совместного использования сети секвенсоров позволяет проводить интересные эксперименты и стратегии начальной загрузки. По нашим оценкам, ключевое отличие будет заключаться в размере экосистемы, поэтому количество междоменных MEV больше, чем аспект затрат. Мы также настоятельно рекомендуем ознакомиться с записью в блоге команды Espresso об общих заказах, они также охватывают экономические компромиссы (и положительные стороны) этих типов сетей. Чтобы показать, почему Rollup заинтересован в использовании общих сортировщиков (помимо экономических), мы можем рассмотреть это с точки зрения теории агрегации.
Теория агрегации и общие сортировщики
Другой способ описать свойства общих сортировщиков — через призму теории агрегации. Теория агрегации относится к концепции того, как платформа или агрегатор систематически интегрирует другие платформы и их пользователей, чтобы привлечь значительное внимание пользователей. Вы, по сути, переводите игру от распределения ограниченного ресурса (например, пространства блоков) к необходимости контролировать обильные ресурсы (опять же, в этом примере имеет смысл пространство блоков). Теория агрегации фактически объединяет поставщиков и продукты (например, Rollup и Blockspace) в опыт суперпользователя для обслуживания объединенной пользовательской базы. По мере роста сетевого эффекта этих агрегаторов эти отношения становятся все более эксклюзивными. Когда это происходит, пользовательский опыт становится ключевым отличием между аналогичными настройками. Если есть стимулы для привлечения новых пользователей (например, хороший пользовательский опыт и лучшая функциональная совместимость), маловероятно, что Rollup переместится в свою собственную сеть или другую настройку, поскольку сетевые эффекты стимулируют появление новых поставщиков и присоединение новых пользователей. Это создает эффект маховика не только с точки зрения поставщика и пользователя, но и с точки зрения совокупной устойчивости к цензуре.
Источник: Теория агрегации 2015 г., Бен Томпсон
В области общих сортировщиков теория агрегации может рассматриваться как «комбинация» и федерация различных накопительных пакетов, использующих схожие вертикали стека, что расширяет возможности самих себя и других, позволяя пользователям получать одинаковый опыт.
Провайдеры (такие как Rollups) теоретически не являются исключительными для общего набора координаторов, но на практике набор общих координаторов, его сводки и пользователи извлекают выгоду из ряда циклов сетевых эффектов, которые приводят к более широкому использованию этих сверток. Эти преимущества упрощают интеграцию Rollup и пользователей в общий стек, поскольку они могут потерять больше, если не будут участвовать. Хотя эти преимущества могут быть трудно увидеть, когда у вас есть только два накопительных пакета, совместно использующих один и тот же набор секвенсора, они становятся более очевидными по мере того, как вы добавляете в уравнение все больше и больше накопительных пакетов и пользователей. Общие наборы сортировщиков имеют прямое отношение к пользователям, поскольку они упорядочивают свои транзакции, даже если сами пользователи не знают, что взаимодействуют с ними, поскольку, с их точки зрения, они просто используют свертки, с которыми у них есть причина взаимодействовать ( Это означает, что заказы/сортировщики становятся эксклюзивными). Единственная стоимость этих сортировщиков — это стоимость оборудования для их запуска, если пространство блока и защищающие его токены ценны для конечного пользователя. Плата за транзакции оцифровывается, выплачивается из кошельков пользователей и, возможно, в будущем может быть даже абстрагирована за счет таких усовершенствований, как платежные хосты в абстракции аккаунта (однако кто-то должен будет нести расходы на DA, заказ и исполнение).
Это имеет больше смысла, если учесть предыдущую компанию Джоша и Джордана в Астрии — Google. С момента своего создания продукты Google были вдохновлены идеей AT, особенно в поиске Google, который создается путем модульного разделения отдельных страниц и статей, что делает их доступными напрямую через окно глобального поиска.
В случае с общим набором сортировщиков пользователи, использующие накопительные пакеты (те, кто использует общий набор сортировщиков), несут все более низкие затраты на приобретение, поскольку по мере увеличения числа поставщиков (агрегированных сортировщиков) они, скорее всего, будут привлечены к набору. . Это означает, что в большинстве случаев агрегатор (или мультиагрегатор) имеет возможный беспроигрышный эффект, поскольку ценность агрегатора увеличивается с увеличением количества поставщиков (конечно, если пользовательский опыт хороший). Напротив, в одной последовательной сети привлечение клиентов ограничивается одной сетью и ее приложениями. Если пользователи хотят использовать приложение Rollup в другом Rollup, им придется (в рамках текущих ограничений) полностью выйти из сети. Это означает, что пользовательская привязанность и ценность не очень высоки, а также это означает, что в любой момент, если другая экосистема Rollup будет высоко оценена (или имеет больше стимулов), капитал может быть потерян.
Сводка атрибутов и компромиссов
Атрибуты
Общий набор сортировщиков — это сеть свертки, которая объединяет и сортирует транзакции для нескольких сверток. Эти накопительные пакеты используют один и тот же сортировщик. Такое объединение ресурсов означает, что накопительные пакеты получают более надежную экономическую безопасность и возможности защиты от цензуры, которые могут обеспечить быстрые мягкие детерминированные гарантии и условные транзакции между накопительными пакетами.
Прямо сейчас много шума вокруг атомарности среди роллапов, которые используют один и тот же набор сортировщиков, в основном вокруг того, является ли он атомарным по умолчанию, а это не так. Однако, если рассматриваемые свертки реализуют функции перехода состояния друг друга (STF) как зависимости между ними, включая условные транзакции, то они действительно могут достичь атомарности между ними - до тех пор, пока их выравнивание слота/блока (как с общими наборами сортировщиков). В этом случае, чтобы получить атомарную интероперабельность, вам действительно нужно запустить легкий клиент цепочки B в цепочке A и наоборот (аналогично тому, как работает IBC). Чтобы еще больше усилить интероперабельность мер безопасности (помимо того, чтобы доверять одному полному узлу как легкому узлу), вы можете реализовать ZKP (Proof of State), чтобы решить «проблему оракула» обеспечения правильности состояния. Это позволит лучше увидеть, попала ли условная транзакция или что-то подобное в канонический мост между ними. Доказательства мошенничества также возможны, но, очевидно, оставят период оспаривания (это означает, что третья сторона покроет стоимость этого риска). Кроме того, в случае легких клиентов (а не полных узлов) отставание будет как минимум на один блок из-за ожидания заголовка подписи + окна защиты от мошенничества (если есть).
Мы считаем, что проблема «межсетевого моста», скорее всего, будет решена с помощью облегченных клиентов и доказательств с нулевым разглашением. Проблема с использованием облегченного клиента (а не смарт-контракта) в этом случае заключается в том, что хард-форки (обновления и т. д.) на стороне узла Rollup должны координировать друг с другом, чтобы их мост работал (точно так же, как IBC должен включить тот же модуль состояния). Если вы хотите глубже погрузиться в эту конкретную тему (и как ее решить), мы настоятельно рекомендуем ознакомиться с этой презентацией.
Причина, по которой общие ордера так хорошо масштабируются, заключается в том, что они не выполняют и не сохраняют никакого состояния (как это делают сегодня централизованные ордера). То же самое касается самих узлов Rollup (если только они не хотят атомарности между собой — например, легкий клиент/доказательство состояния). Эти узлы выполняют только транзакции, допустимые для их свертки, и любые допустимые для них условные междоменные транзакции. Если узел Rollup должен выполнять и сохранять состояние для нескольких Rollup, это затрудняет масштабируемость и снижает децентрализацию (и, следовательно, устойчивость к цензуре). Это также усиливает концепцию разделения производителей блоков и сборщиков блоков (PBS). Хотя нам все еще нужно полностью разделить строителей и производителей блоков. В текущей настройке ордера по сути являются строителем и производителем блоков (хотя они и не выполняют транзакции). Идеальная установка может быть такой, при которой заказчик существует только для того, чтобы слепо подписывать блоки из высокооптимизированной установки компоновщика и обеспечивать правильную реализацию блоков (при обеспечении высокой степени экономической уверенности и устойчивости к цензуре для этой сертификации). Таким образом, они могут обеспечить высокую степень безопасности и обязательств, чтобы гарантировать мягкую завершенность для узлов Rollup.
Для условных транзакций перекрестного свертывания они также существуют, чтобы помочь узлам свертывания (исполнителям) предоставлять корни промежуточного состояния, обеспечивая атомарность между свертываниями.
компромисс
Вышеупомянутый параметр тайм-аута оказывает интересное влияние на MEV и включение транзакций в зависимости от механизма мастерноды/консенсуса в наборе заказчиков. Например, если параметр тайм-аута описан как относительно короткий в нашей цепочке приложений для конкретного приложения, крайне важно, чтобы производители блоков децентрализованного набора заказчиков публиковали данные как можно быстрее. В таком мире вы можете увидеть конкуренцию между «валидаторами», которые соревнуются за звание мастер-узлов и делают ставки на уровне DA за блочное пространство до тех пор, пока это не перестанет быть прибыльным.
Как писал Эван в своем первоначальном посте о ленивом заказе на форумах Celestia, ожидание публикации транзакций на базовом уровне (в данном случае Celestia) перед их выполнением очень неэффективно. Поскольку теперь вы ограничены временем блокировки базового слоя, которое слишком долго, чтобы ждать взаимодействия с пользователем. Для лучшего взаимодействия с пользователем общий ордер предоставляет накопительные пакеты с мягкими детерминированными обязательствами (как описано ранее), которые обеспечивают пользователям пользовательский опыт, к которому они привыкли в существующих централизованных накопительных пакетах (при сохранении децентрализации и высокой устойчивости к цензуре). Мягкие обязательства — это, по сути, просто обязательства по окончательному порядку транзакций, но подкрепленные серьезными экономическими гарантиями и быстрым завершением после их выпуска. Это также покрывается доказательствами мошенничества (как упоминалось во введении). Фактическая жесткая завершенность достигается после того, как все данные транзакции будут опубликованы на базовом уровне (это означает, что L1 фактически достигает более быстрой окончательности). Это зависит от того, использует ли Rollup доказательства мошенничества или доказательства с нулевым разглашением для подтверждения суверенитета, что происходит в Rollup. Причина такого разделения состоит в том, чтобы убрать огромное узкое место переходов состояний из сортировщика. Вместо этого узлы Rollup работают только с теми узлами, которые действительны для них (это означает, что мы должны добавить условные транзакции, подтверждение состояния или легкую проверку узлов для надлежащей совместимости). Жесткий детерминизм по-прежнему зависит от базового слоя (но это может достигать 15 секунд на Celestia, а также является детерминированным в Tendermint), что дает нам относительно быстрые гарантии жесткого детерминизма на Rollup.
Используйте доказательства с нулевым разглашением внутри сети, чтобы оптимизировать проверку и размер транзакции (например, публиковать только различия в состоянии, но это повышает уровень доверия до тех пор, пока ZKP не будет опубликован). Как упоминалось ранее, эти доказательства состояния можно использовать для упрощения и ускорения взаимодействия подключенных цепочек/агрегатов (без ожидания окон вызова).
Недостатком этих условных транзакций является то, что они, вероятно, будут более дорогими, требуя более высоких затрат на проверку и выпуск (например, стоимость проверки заголовка блока Tendermint, которая субсидируется в цепочке Cosmos), и добавляют некоторую задержку в систему ( но все же быстрее, чем изолированные накопительные пакеты намного быстрее). Атомарность, достигаемая за счет вертикально разделяемой интеграции, может компенсировать эти проблемы.
На этапе начальной загрузки нового накопительного пакета использование общего набора сортировщиков имеет большой смысл, и преимущества, которые вы получаете как поставщик, скорее всего, перевесят некоторые компромиссы, на которые вы, возможно, будете «вынуждены» пойти на уровне рва. Однако для уже зрелого роллапа, где много транзакций и экономической активности, наверное, не имеет смысла отказываться от части рва.
В связи с этим возникает вопрос, нужно ли нам аналогичное взвешенное экономическое/транзакционное (для каждого свертывания) перераспределение извлеченных MEV, чтобы побудить уже зрелые свертывания присоединиться к общему набору — или даже не дать чрезвычайно зрелым свертываниям создать собственную сеть. Все это довольно теоретически, но это, несомненно, интересный мыслительный процесс в отношении того, как MEV в общих вертикальных мирах будут представлены между множеством Rollup с различными уровнями активности. Например, если уникальный накопительный пакет, создающий ценность, делится частью этой прибыли с другими (вероятно, не принося большой «ценности») через набор Sequencer Set, то у них должно быть больше причин для перехода в свою собственную разрозненную систему. У Sreeram от EigenLayr также есть некоторые мысли по этому поводу, которые мы также рекомендуем прочитать.
Это становится все более важным, если учесть, что поисковые компании несут значительные технические затраты на разработку новых цепей, поэтому стандартизация и обеспечение некоторой независимости над «своими» MEV может быть хорошим началом. На практике в MEV доминирующий интерфейс (или программное обеспечение) может победить, но на самом деле монетизировать это программное обеспечение за счет запуска критических частей инфраструктуры очень сложно (что приводит к централизации). На рыночном уровне то, что предоставляет общий ордер, в основном представляет собой общий мемпул для нескольких поставщиков с централизованным аукционом, что может привести к более здоровой конкуренции.
Проблема здесь в том, что если два накопительных пакета запускают сортировщики в общем наборе, то может быть выбран накопительный пакет с «менее экономичным» значением (A), чтобы предложить накопительный пакет с большим количеством MEV + сборы от накопительного пакета (B). . С точки зрения Rollup B, они, по сути, упускают некоторую ценность, которую при изолированном подходе оставили бы для себя.
Устранение компромиссов совместимости
Еще одно замечание о компромиссах, связанных с функциональной совместимостью, и еще один способ решения некоторых проблем:
Целью общей сети заказов является предоставление канонической гарантии для нескольких цепочек, что в данном случае, очевидно, является большим преимуществом. Это можно комбинировать с механизмом, гарантирующим эффективные переходы состояний между накопительными пакетами. Это может быть подход на основе комитета (например, PoS), защищенные доказательства (оптимистический подход) или предпочитаемый нами подход — ZKP, подкрепленный подписями комитета. Поскольку общие сортировщики являются «ленивыми», они создают суперблоки только для сортировки транзакций нескольких сверток, а выполнение конкретной транзакции предоставляется конкретному свертыванию. Доказательства состояния (например, Лагранжа, Аксиомы или Геродота и т. д.) — все это возможные решения для потенциального получения доказательств окончательности для суверенных сверток. Вы даже можете добавить доказательства экономически гарантированной окончательности с помощью таких вещей, как пулы ставок, EigenLayr и т. д. Основная идея заключается в том, что общий сортировщик обеспечивает экономическую гарантию упорядочения, а доказательства достоверности, генерируемые в результате этой сортировки, являются детерминированными. Основная идея заключается в том, что Rollups могут выполнять транзакции синхронно друг с другом. Например, сеть из двух узлов Rollup может условно знать, что обе истории Rollup действительны, через ZKP и доступные данные (данные, опубликованные на эффективном уровне DA). Публикуя один префикс блока агрегации из обеих сетей A и B, узел агрегации может одновременно урегулировать два агрегации. Следует отметить, что условные кросс-агрегированные транзакции потребляют ресурсы из двух отдельных систем посредством совместного выполнения, поэтому атомарные (или синхронные) кросс-агрегированные транзакции, вероятно, будут дороже, чем интра-транзакции с одиночным свертыванием.
Succinct также осветил межсетевые «атомарные» транзакции между роллапами с общими заказчиками (и общими средствами защиты от мошенничества) в рамках экосистемы гиперцепей Optimism, которые можно посмотреть здесь. Кроме того, как выразился Бо Ду из Polymer: «Атомарные транзакции между цепочками подобны получению блокировок между сегментами базы данных при записи».
Будущее вертикальной интеграции
Возможная внутренняя работа цепей SUAVE уже подробно исследована Джоном Шарбонно и др., поэтому мы не будем вдаваться в подробности. Если вы хотите более подробное описание, вы можете проверить его статью. Тем не менее, мы считаем, что вертикальная интеграция заслуживает отдельного введения, чтобы подчеркнуть, насколько мы можем быть модульными (и почему), а также представить некоторые проблемы и проблемы, связанные с вертикальной интеграцией.
В то время как текущая общая схема ордеров Astria, Espresso и Radius очень модульная, ордера по-прежнему действуют как строители и производители блоков (хотя в случае Astria они не выполняют транзакции). Astria с самого начала активно встраивала PBS в свою архитектуру.
Если PBS не встроен в протокол, есть несколько способов реализовать PBS (хотя и с разной степенью децентрализации). Такие продукты, как SUAVE, используют автономные модели, такие как MEV-Boost, или реализуют модули-конструкторы, такие как модули Cosmos SDK, созданные Mekatek и Skip.
Стоит отметить, что ни один из этих методов не является взаимоисключающим. У вас есть возможность использовать несколько различных методов и позволить любому выразить свои предпочтения. Таким образом, у вас могут быть исполнители, конкурирующие за заполнение этих вакансий. Добавление дополнительных опций всегда хорошо (и согласуется с нашей верой в модульность). Тем не менее, разные реализации будут иметь разные компромиссы. Например, в таком случае, как SUAVE, вы можете добавить защиту конфиденциальности с помощью технологии SGX или Crypto и добавить к истине экономическую безопасность Crypto, вместо того, чтобы полагаться на полностью доверенного централизованного компоновщика PBS. (Спасибо Джону Шарбонно за его отзыв здесь).
Вертикальная интеграция в цепочку компоновщика обеспечивает справедливость без использования ярлыков, увеличения задержки и снижения производительности. Следовательно, цепочка сборщика должна быть сильно оптимизирована и может потребовать дорогого и мощного оборудования (что приводит к централизации). Это означает, что для проверки конечного пользователя нам, вероятно, потребуются какие-то легкие узлы (хотя им придется доверять полным узлам) или использовать настройку типа подтверждения состояния, чтобы убедиться, что цепочка и пользователи имеют доказательство того, что предпочтения ставок заполнены и блоки правильные Construct.
Цепочка, подобная этой, может быть очень тяжелой (мы хотим этого избежать), хотя эти транзакции с большим количеством состояний будут иметь приоритет через смарт-контракты. В случае приоритетной заявки она либо заполняется, либо не заполняется (на короткий период времени), поскольку заявки обычно действительны только в течение короткого периода времени, в зависимости от предпочтений. Это означает, что мы можем реализовать очень эффективное (и раннее) истечение состояния для ставок, что позволит нам сократить данные и сохранить цепочку «чистой». Эта дата истечения должна быть достаточно длинной, чтобы по-прежнему можно было выполнять заявки в первую очередь, но слишком сильное ее снижение сделает почти невозможным достижение форвардных фьючерсов на блочное пространство. Нам не нужно обновлять и извлекать контракты с истекшим сроком действия, поскольку они не должны существовать вечно (в отличие от приложений). от решения Joachim Neu), чтобы сделать его более «безопасным» и заслуживающим доверия.
Как упоминалось ранее, необходимость проверки «подлинности» SUAVE может быть ограничена «jusha» (продвинутыми пользователями) платформы, поскольку большинство пользователей и клиентов SUAVE могут получить от нее большие экономические выгоды. Это может подтолкнуть нас к тому, чтобы позволить людям запускать полные узлы только в том случае, если они хотят пройти валидацию, хотя это исключает подавляющее большинство людей (можно сказать, что им не нужно валидировать). Это (на наш взгляд) противоположность Crypto, где мы предпочли бы реализовать «ненадежную» проверку SUAVE с помощью проверки состояния или легких клиентских реализаций.
Причина, по которой это необходимо, заключается в том, что вы хотите убедиться, что ваш приоритет ставки был заполнен правильно и что блок был заполнен правильной информацией при оплате (чтобы избежать повторного набора и других ошибок). По сути, это проблема оракула — на самом деле ее можно решить с помощью доказательства состояния (как в случае со всеми SUAVE). Однако эти доказательства состояния вызывают другую проблему при пересечении цепочек: как передать эту информацию по цепочкам таким образом, чтобы она не была подделана или скрыта? Для этого может потребоваться пройти через сильную экономическую завершенность (например, предложенную Лагранжианом), и в этом случае вы можете использовать валидаторы повторного стейкинга EigenLayr, чтобы доказать завершенность и подлинность цепочки, и иметь очень сильные экономические ограничения. Затем возникает еще одна проблема (например, в контракте о торгах оговаривается, что «оракульная машина» — в данном случае повторно залогодатель — определила заложенный Токен и обеспечила экономическую привязку — но как мы можем прийти к консенсусу между Внешним сокращением этого? вы можете написать критерии сокращения, это не является согласованным, что означает, что социальное сокращение будет использоваться с помощью смарт-контрактов (что почти никогда не бывает «честным» и может вызвать проблемы).В настоящее время это имеет место в EigenLayr. .
Итак, где это нас оставляет? Возможно, до тех пор, пока мы не получим «ненадежное» слэшинг в цепочке за пределами консенсуса, таким цепочкам, как SUAVE, могут понадобиться свои собственные алгоритмы консенсуса и криптоэкономическая безопасность, чтобы доказать предпочтения ставок и создать уверенность в блоке. стоимость его строительных блоков намного выше, чем его собственная криптоэкономическая безопасность.
Кроме того, в цепях типа SUAVE и междоменных MEV еще много места для дизайна.Вот некоторые возможные направления исследований:
Сопоставление намерений и системы, основанные на намерениях
Выпуклая оптимизация в мультиактивной торговле
ДСЛ
Перераспределение MEV
Отсроченная война
Проблема масштабирования с одним набором акторов, но необходимо создать несколько конечных автоматов Rollup.
Выражение предпочтения
Что касается выражения предпочтения, то для взаимодействия со смарт-контрактом в EVM необходимо отправить вызов контракта (сообщение) конкретной функции по адресу развернутого кода, содержащего инструкцию выполнения. Хотя пользователи вводят данные, они могут не иметь контроля над выводом из-за возможной сохранения состояния.
Напротив, системы дизайна выражения предпочтений (такие как SUAVE и Anoma) требуют, чтобы пользователи подписывали предпочтения только залогом, который выплачивается строителям и производителям блоков, если предпочтения искателя удовлетворены. Для сложной комбинаторной логики, такой как последовательности транзакций для искателей и сборщиков MEV, может потребоваться реализация разных языков и виртуальных машин. Это новое пространство дизайна, которому в последнее время уделяется много внимания, особенно архитектуре Anoma. Кроме того, мы настоятельно рекомендуем эту короткую статью.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
4D Detailed Shared Sorter: принцип работы, теория агрегации и вертикальная интеграция
Оригинальное название: "The Shared Sequencer"
Автор: MAVEN11
Сборник: Kxp, BlockBeats
Представьте, на что было бы похоже, если бы Rollup «из коробки» мог достичь высокой степени устойчивости к цензуре, простоты развертывания, функциональной совместимости, быстрой завершенности, живучести и демократизации MEV. Это может показаться грандиозной целью, но с появлением Shared Sequencer она может вскоре стать реальностью. Однако не все накопительные пакеты одинаковы, поэтому нам необходимо подумать о том, как распределять вознаграждения и MEV в общей сети секвенсоров. В этой статье мы исследуем, как реализуются сети с общим ранжированием, и свойства, которых можно достичь.
Общие сети секвенсора впервые были представлены Алексом Беккетом, позже Эваном Форбсом (и Радиусом) из команд Celestia и Espresso, а новая статья Джона Шарбонно раскрывает эту тему более подробно. Джош, Джордан и их команда Astria создают первую готовую к производству сеть секвенаторов с общим доступом. Astria Shared Orderer Network — это модульная цепочка блоков, которая объединяет и упорядочивает транзакции Rollup, не выполняя их.
В настройках Astria сортировщик отправляет упорядоченные блоки на уровень DA, а также на узлы Rollup. Накопители получают мягкие гарантии окончательности от заказчика и жесткие гарантии окончательности от уровня DA (после того, как блоки завершены), а затем они будут выполнять действительные транзакции.
Сеть общих секвенсоров, по сути, представляет собой группу секвенсоров, совместимых с Rollup, и, как следует из ее названия, она может предоставлять услуги для различных Rollup. Это имеет различные компромиссы и свойства, которые мы подробно рассмотрим позже. Во-первых, мы должны описать наиболее важные свойства сортировщика (или набора сортировщиков). В Rollup основным требованием к секвенсору или группе секвенсоров является устойчивость к цензуре или живучесть (некоторые из которых исходят от базового уровня, а также безопасность). Это означает, что действующая транзакция, представленная заказчику, должна быть включена в цепочку в течение конечного времени (параметр timeout). Группе общих заказов нужно только убедиться, что транзакции включены в блоки (т. е. crLists).
Удовлетворить одновременно сопротивление цензуре и оперативность довольно сложно, как мы обрисовали во второй части Modular MEV. В алгоритме консенсуса, таком как Tendermint, вы можете обеспечить восстановление после атаки. Однако в случае нападения вы теряете непосредственность. По сути, требование ко всем остальным подборщикам подписывать блок вместо выбора пользовательской мастерноды, вероятно, не оптимально. Хотя это повышает устойчивость к цензуре, это происходит за счет «централизации» и извлечения MEV в одну мастерноду. Другой доступный механизм сортировки можно сравнить с Multiplicity от Duality, который является их небольшим инструментом для немастернод (или сортировщиков) для включения других транзакций в блоки. В целом, в большинстве согласованных протоколов трудно добиться сопротивления цензуре и немедленного реагирования после атаки.
Другим алгоритмом консенсуса, который можно использовать, является HotStuff 2, который обеспечивает немедленность в случае атаки.
Это позволяет избежать ожидания максимальной сетевой задержки (тайм-аута) в случае цензуры или отсутствия подписи для выбора новой мастерноды. Причина, по которой он может быть интересным алгоритмом консенсуса для децентрализованного набора заказчиков, заключается в том, что он решает проблему немедленности в консенсусе без добавления дополнительного этапа. Если мастернода знает самую высокую блокировку (наибольшее количество участников, согласившихся на определенный выход) и может убедить честные стороны, проблема решена. Если нет, то честная мастернода после определенного момента может взять на себя управление продвижением, помогая следующей мастерноде. Например, узлу Hotstuff не нужно подтверждать сообщение о переключении перед уведомлением нового мастера, но он может напрямую переключиться на новое представление и уведомить нового мастера.
Разница с Tendermint заключается в том, что, хотя оба они двухфазные (Hotstuff1 имеет три, Hotstuff2 — два), Tendermint имеет линейную коммуникацию, но не отвечает, в то время как Hotstuff2 реактивен. Если есть цепочка честных мастернод, протокол отвечает положительно, так как все шаги, кроме предложения первой мастерноды, зависят от получения объема информации на предыдущем шаге. В настройках общего ордера это позволяет протоколу достичь большей оперативности, не возвращаясь к нижнему уровню, но не отменяя эту возможность.
Построение общих групп сортировщиков
Некоторым заказчикам разрешено отправлять транзакции на расчетный уровень (уровень, на котором находится Rollup). Вы можете присоединиться к этой группе подборщиков, если выполнены определенные требования и не достигнуто необходимое количество производителей блоков. Это оптимизирует задержку, пропускную способность и многое другое. Эти требования аналогичны тем, которые необходимы для того, чтобы стать валидатором блокчейна. Например, вы должны соответствовать определенным требованиям к оборудованию, а также внести первоначальный депозит, особенно если вы хотите обеспечить уверенность в финансовых условиях.
Общая группа заказов (или любая децентрализованная группа заказов) состоит из нескольких компонентов, которые работают вместе для обеспечения правильной обработки транзакций, в том числе:
Предоставьте JSON-RPC для каждого свертки для отправки транзакции (для неполных операторов узла) на узел в качестве пула памяти, а затем создайте и отсортируйте. В мемпуле нужен какой-то механизм для определения очереди, а также процесса выбора транзакций, чтобы обеспечить эффективное построение блоков.
Алгоритм построения блока/пакета, отвечающий за обработку транзакций в очереди и преобразование их в блоки или пакеты. Этот шаг может также включать сжатие для уменьшения размера результирующего блока (так называемое сжатие данных). Как уже упоминалось, это должно быть отдельно от Proposer, по сути, PBS. Данные могут быть сжаты различными способами, например:
Отсутствие полей данных: поля данных не требуются для простых переводов, но необходимы для более сложных транзакций.
Замените отдельные подписи агрегированными подписями BLS: подписи являются крупнейшим компонентом транзакций Ethereum. Вместо хранения каждой подписи вы можете хранить агрегированные подписи BLS для определенного количества транзакций. Вы также можете проверить совокупную подпись BLS на соответствие набору сообщений и набору отправителей, чтобы убедиться в ее достоверности.
Используйте поле «От» в качестве индекса: как и поле «Кому», вы можете использовать поле «От» в качестве индекса для сопоставления.
Интересная концепция «модульного» дизайна заключается в том, что вы можете вносить коррективы и компромиссы по мере необходимости, чтобы он работал для вашего накопительного пакета.
Алгоритм ротации мастеров для общих наборов заказов (консенсус не требуется в случае выбора одного мастера). Вы можете установить только алгоритм ротации главного узла или выбрать маршрут производителя блоков с несколькими параллельными потоками, предложенный Duality.
Алгоритмы консенсуса, такие как вышеупомянутый Tendermint или Hotstuff2, могут гарантировать, что узлы Rollup согласуются с последовательностью, предложенной реестром.
RPC-клиент для отправки блоков/пакетов на базовый уровень консенсуса DA+, чтобы блоки/пакеты можно было безопасно добавлять на уровень DA, обеспечивая «окончательную» завершенность и делая все данные транзакций доступными в цепочке.
Разделите роли строителей и производителей блоков, чтобы обеспечить справедливость и последовательность и избежать кражи MEV. Также удаляет выполненную сортировку, что важно для оптимизации эффективности, снижения PGA и увеличения CR.
Данные о вызовах сначала публикуются в базовой сети, где выполняется консенсус, чтобы гарантировать транзакции пользователей и сводных данных. Затем узел Rollup выполняет транзакцию и отправляет функцию перехода состояния в каноническую цепочку Rollup. Сеть общих заказчиков обеспечивает Rollup оперативностью и устойчивостью к цензуре. Роллапы сохраняют свой суверенитет, поскольку все данные транзакций хранятся на базовом уровне, что позволяет им разветвляться от общего ордера в любое время. Корень состояния функции перехода состояния свертки (STF) вычисляется из корней транзакций (входных данных), отправленных из общего ордера на уровень DA. В Celestia корни состояния генерируются, когда данные добавляются в цепочку и достигается консенсус. Поскольку у вас уже есть корень транзакции (и все доступные данные), Celestia может предоставить легкие клиенты (ноды Rollup, работающие на Celestia) с небольшим доказательством включения.
Чтобы обеспечить ожидаемый пользовательский опыт, узлы Rollup получают упорядоченные блоки (которые также отправляются на уровень DA). Это может предоставить Rollup мягкие детерминированные гарантии — гарантии того, что блоки в конечном итоге будут упорядочены по порядку на уровне DA, после чего узлы Rollup выполнят транзакции и предоставят новые корни состояния.
Создание блока и слот
Чтобы определить время создания блока, секвенсору необходимо установить слот. Секвенсор должен отправлять пакеты через фиксированные интервалы (обычно X секунд), где X — время слота. Это гарантирует, что транзакции обрабатываются быстро и эффективно, потому что в противном случае мастернода для определенного слота истечет время ожидания и потеряет вознаграждение за подпись (и вознаграждение за выполнение). Например, время блока Celestia (согласно спецификациям GitHub) составляет около 15 секунд. Поскольку это известно, мы можем сделать некоторые предположения о том, сколько «слотов/блоков» у нас может быть от общего набора координаторов до уровня DA, а узлы свертки загружаются в финализированные блоки. В этом отношении мы можем обратиться к оптимизированным Tendermint или Hotstuff2.
В одном и том же слоте мы можем отправлять несколько пакетов транзакций, при условии, что дизайн включает механизмы для полных узлов Rollup для их эффективной обработки в один блок (в пределах этого периода времени и параметров тайм-аута). Это помогает оптимизировать создание блоков и обеспечивает быструю обработку транзакций. Кроме того, слоты также могут использоваться для облегчения выбора главных узлов сортировщика. Например, вы можете случайным образом выбрать главный узел слота из пула ставок на основе веса ставок. Лучше всего делать это таким образом, чтобы сохранить конфиденциальность и использовать что-то вроде тайных выборов лидера для минимизации цензуры или даже установить технологию распределенного валидатора, такую как решения наподобие Obol/SSV. Задержка и время слота оказывают большое влияние на отправку блоков и сборку протокола. Поэтому нам нужно посмотреть, как это повлияет на систему. У Bloxroute есть отличные исследования и данные, в частности, по Ethereum. В MEV-Boost участвующие производители блоков (валидаторы или секвенсоры в случае Rollup) запрашивают GetHeader у ретранслятора. Это дает им значение ставки блока, которое является значением конкретного блока. Это может быть блок с наибольшим значением, полученным каждый раз. Для каждого слота валидаторы обычно запрашивают GetHeader примерно через 400 мс после запуска слота — из-за большого количества валидаторов ретрансляторам часто приходится отправлять многочисленные запросы. Это также может произойти с большими общими группами сортировщиков. Это означает, что вам нужна инфраструктура для облегчения этого процесса.
Ретрансляторы также помогают разделить строителей и производителей блоков, а также проверяют, построили ли строители правильные блоки. Они также проверяют правильность оплаты сборов и служат защитой от DoS-атак. Кроме того, они в основном являются хранителями блоков и занимаются регистрацией валидаторов. Это особенно важно в архитектуре неограниченного секвенсора, поскольку вам нужно отслеживать, кто участвовал, а кто нет (например, уровень синхронизации, рассмотренный ранее).
Что касается времени блока (т. е. блоков, отправленных создателями), то оно обычно составляет около 200 миллисекунд. В основном они начинают выполняться до/после примерно 200 мс, хотя, как и GetHeader, существуют значительные различия. Если билдер отправит блок на несколько ретрансляторов, это вызовет значительную задержку. Bloxroute также рассмотрел, что происходит, когда блоки отправляются на несколько ретрансляторов. Как и следовало ожидать, задержка распространения блока на большее количество ретрансляторов будет больше. В среднем второму ретранслятору требовалось 99 миллисекунд, чтобы провести блок, третьему — 122 миллисекунды, а четвертому — 342 миллисекунды.
Что мы, вероятно, узнали за последние несколько месяцев, так это то, что RPC очень важен для блокчейнов. Это огромная нагрузка без надлежащей инфраструктуры, и наличие надлежащего варианта RPC также имеет решающее значение. В этом случае RPC важен для розничных инвесторов, отправляющих свои транзакции в RPC (и в публичный мемпул). Bloxroute провел небольшой тест с 20 транзакциями, отправленными на различные RPC, и измерил время, необходимое для включения каждой транзакции в блок.
Источник: Bloxroute Labs
Интересно, что некоторые RPC не включают транзакции до тех пор, пока не пройдет несколько блоков, в зависимости от того, какой билдер выиграет в следующем блоке. Если RPC отправляет транзакцию большему количеству сборщиков, то вероятность быстрого включения выше. Хотя инициаторы транзакций могут использовать свое уникальное положение для потока заказов к конкретным строителям или даже создавать свои собственные блоки.
Их производительность также интересна в статистике производительности эстафеты Ethereum. Это помогает нам глубже понять, как PBS работает в мире с несколькими валидаторами, сборщиками и ретрансляторами, чего мы надеемся достичь с помощью обновления Rollup. У Метрики есть отличные статистические данные по этому вопросу, и все точки данных связаны с ними.
Важно отметить, что пропущенные ставки происходят, когда ожидается, что ретранслятор сделает ставку, но не делает ставки. Целевые ожидания исходят от валидаторов, зарегистрированных в конкретном ретрансляторе для любого заданного слота. Это не является ошибкой реле как таковой и не обрабатывается таким образом на уровне протокола.
Источник: app.metrika.co
Если происходит сбой (например, реле, обслуживающее недопустимый блок), и он виноват, это будет считаться сбоем. Обычно это происходит нечасто и в основном связано с ошибками при регистрации (например, лимиты газа или сборы, которые не соответствуют регистрации для определенного валидатора). Еще реже встречаются сбои уровня консенсуса, которые несовместимы с правилами уровня консенсуса Ethereum, такие как неправильные слоты или родительские хэши, не выровненные с предыдущим блоком и т. д.
С точки зрения задержки (например, времени, которое требуется валидатору для получения заголовка блока, созданного компоновщиком), данные очень непротиворечивы. Хотя есть некоторые отклонения, например, запрошенный ретранслятор находится в другом географическом местоположении, чем выбранный валидатор.
Источник: app.metrika.co
Что касается строителей, общее количество строителей на MEV-boost составляет около 84 человек, при этом три лучших строителя строят около 65% построенных блоков. Хотя это может вводить в заблуждение, поскольку они также являются самыми продолжительными сборщиками. Результаты аналогичны, если сократить временные рамки. Количество фактически активных строителей намного меньше: 35 за последние 30 дней и 24 за последнюю неделю. Конкуренция жесткая, и обычно побеждает сильнейший строитель. Исключительный поток заказов может уже существовать, что только усугубит ситуацию. Мы ожидаем, что распределение сборщиков останется относительно централизованным (поскольку это гонка за оптимальный поток заказов и оптимизацию оборудования), если мы не внесем серьезные изменения в настройку. Хотя это и не является фундаментальной проблемой, это по-прежнему центральная сила в стеке, и мы хотели бы услышать идеи о том, как бросить вызов статус-кво здесь. Если вы заинтересованы в более глубоком изучении этой (серьезной) проблемы, мы настоятельно рекомендуем прочитать статьи Quintus о потоке заказов, аукционах и централизации.
Что касается роли Builder в будущем стеке модульности, мы почти уверены (по крайней мере, в настройке Cosmos SDK) мы увидим настройку модулей Builder, подобную Skip/Mekatek. Другим решением является настройка типа SUAVE, например, специальная глобальная цепочка строителей, предоставляющая услуги построения блоков и предпочтения ставок для любого количества цепочек для обеспечения PBS. Позже мы более подробно рассмотрим это решение и предоставим некоторые ответы на вопросы, которые здесь не рассматриваются.
Что касается реле, мы настоятельно рекомендуем прочитать статью Анкита Чиплункара из Frontier Research и Майка Нойдера из Ethereum Foundation под названием «Оптимистические реле и где их найти». В этом посте подробно рассказывается, как работают реле в MEV-boost, их текущие компромиссы и эксплуатационные расходы, а также некоторые изменения, которые могут повысить эффективность. Интересно, что запуск реле в MEV-Boost в настоящее время стоит около 100 000 долларов в год, согласно оценкам Flashbot.
Детерминированный
Прежде чем мы поговорим о детерминизме модульных блокчейнов (как они выглядят в настоящее время), давайте взглянем на нашу предыдущую статью «Модульный MEV». Обратите внимание, что это не «официальный» и не всеобъемлющий взгляд на окончательность, но мы считаем, что он наиболее точно отражает нюансы окончательности свертки для простоты понимания.
Pending_On_L2: заказчик объединения представляет собой мягкое обязательство о том, что транзакция пользователя в конечном итоге будет зафиксирована и завершена на базовом уровне его безопасности.
Finality_On_L2: Секвенсор зафиксировал функцию перехода состояния Rollup, и блок был добавлен в каноническую цепочку Rollup.
Pending_On_L1: функция ввода или вывода/перехода состояния транзакции была опубликована в L1, но подтверждение достоверности еще не выдано, или период арбитража еще не закончился — для этого требуется Ethereum в течение двух последовательных эпох. Это момент, когда большинство оптимистичных накопительных пакетов говорят, что они достигли окончательности, но на этом этапе все еще существует произвольный 7-дневный период испытаний в соответствии со спецификацией межсетевого моста.
Окончательность_On_L1: для Optimistic Rollup закончился арбитражный период или опубликованное и проверенное доказательство действительности было подтверждено квалифицированным большинством в двух последовательных эпохах.
Теперь в Sovereign Shared Sort Rollup это выглядит немного по-другому, попробуем объяснить это на схеме:
В этом случае теоретически мы можем получить детерминизм на L1 раньше, чем на L2 и т. д.? Да, в этом случае L2 все-таки суверенен. Это предполагает, что нет никаких доказательств мошенничества и периодов оспаривания, или вы используете доказательство действительности.
Так как же нам достичь этих уровней завершенности? Завершенность блока достигается, когда в каноническую цепочку добавляется блок, который нельзя отозвать. Однако здесь есть свои нюансы, в зависимости от полных или легких узлов. В случае упорядоченного блока он является детерминированным, если он включен в блок уровня DA. Блоки (с корнями состояния) применяются с помощью полных узлов/валидаторов Rollup, что дает им гарантию действительного корня состояния, полученного из упорядоченных блоков базового уровня. Для детерминизма за пределами полных узлов (например, для легких клиентов или мостов между цепями) вы должны быть уверены в достоверности этого корня состояния. Здесь вы можете использовать один из методов, описанных ниже. Кроме того, другой подход заключается в том, чтобы заставить валидаторов нести ответственность за правильное доказательство корня состояния (оптимистический маршрут) через залог и последующее доказательство мошенничества. Дополнительно можно предоставить подтверждение действительности (ЗК).
Различные способы достижения завершенности блока:
С помощью Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) и других вероятностных методов.
Доказуемый метод с помощью достаточного количества членов комитета, подписывающих блоки. (например, Tendermint 2/3, Hotshot2 или другие типы PBFT)
Зависит от порядка транзакций/блоков на уровне DA и его правил, а именно правил выбора канонической цепочки и форка.
Мы можем достичь различных типов завершенности с помощью различных механизмов.
Одним из типов окончательности является «мягкая завершенность» (например, ожидание), которая может быть достигнута путем избрания одного лидера. В этом случае каждый слот будет иметь только один или ноль блоков (зафиксированных или нет), и уровень синхронизации может безопасно предположить последовательность транзакций в этих блоках.
Другим типом окончательности является «доказуемая завершенность», которая обеспечивает более сильные гарантии (по существу окончательные), чем мягкая окончательность. Для достижения доказуемой окончательности большинство заказчиков должны подписать блок, тем самым выразив свое согласие с тем, что блок является каноническим. Хотя этот подход хорош, в нем может не быть необходимости, если были реализованы выборы одного лидера, поскольку он, по сути, гарантирует блочный порядок. Очевидно, это зависит от конкретного реализуемого алгоритма выбора лидера. Например, это реализация на 51%, реализация на 66% или один лидер (желательно случайный (VRF) и тайные выборы). Если вы хотите узнать больше о детерминизме в Ethereum, прочитайте эту статью, которую мы настоятельно рекомендуем, и статью, которую мы порекомендуем позже для неограниченных наборов сортировщиков.
лицензированный, полулицензионный или неразрешенный
Чтобы предотвратить потенциальные DoS-атаки, необходимо установить экономические барьеры для присоединения к группе заказчиков и отправки транзакций на уровень заказчиков. В ограниченных (конечное количество сортировщиков) и неограниченных (неограниченное количество сортировщиков) группах должны быть установлены экономические барьеры для отправки пакетов на уровень DA, чтобы предотвратить уровень синхронизации (распространение блоков между сортировщиками) Замедление или DDoS-атака . Однако сам уровень DA также обеспечивает некоторую защиту, поскольку отправка данных на него требует затрат (da_fee). Залог, необходимый для присоединения к неограниченной группе, должен покрывать любые дополнительные расходы, необходимые для предотвращения рассылки спама на уровне синхронизации. С другой стороны, маржа, необходимая для присоединения к ограниченной группе, будет зависеть от спроса (сбалансированного с точки зрения затрат и доходов).
Для неограниченного набора сортировщиков мы не можем добиться доказуемой окончательности на уровне сортировщика (поскольку мы никогда точно не знаем, сколько активных избирателей/подписавшихся). С другой стороны, в ограниченной группе коортеров доказуемая завершенность может быть достигнута большинством коортеров, подписывающих блоки. Это требует, чтобы уровень синхронизации знал об уровне секвенсора и о том, сколько секвенсоров активно в любой момент времени, что требует дополнительных затрат. В ограниченном наборе сортировщиков (например, до 100) вы также можете оптимизировать количество сортировщиков для повышения «производительности», хотя и за счет децентрализации и устойчивости к цензуре. Важность ограниченных групп и экономических гарантий для обеспечения «быстрой» доказуемой определенности также детерминистична.
Типы неограниченного сортировщика и ограниченного сортировщика также отражены в традиционных блокчейнах, например, PoS (Casper+LMD-GHOST) в Ethereum использует неограниченный тип, а цепочка на основе Cosmos SDK/Tendermint использует ограниченный тип. Интересная мысль: ожидаем ли мы увидеть экономику, подобную доказательству доли, и варианты от сообщества вокруг общих заказчиков? В связи с этим мы наблюдаем движение к централизации некоторых сущностей (поэтому неограниченность не имеет большого значения, если у вас уже есть какие-то крупные провайдеры/пулы proof-of-stake). Хоть они и «прячут» централизацию, в конце концов, вы все равно можете майнить, если хотите. С идеологической точки зрения выбор почти всегда должен быть неограниченным, но помните, что экономические принципы в любом случае делают их очень похожими. Независимо от того, кто является участниками, экономика того, что вы платите, должна быть одинаковой, например, стоимость DA и стоимость оборудования (хотя это может быть уменьшено за счет количества доказательств доли, которые вы распределяете и испытываете, а также эффективности). эксплуатации инфраструктуры). Даже в ограниченном мире PoS мы видели, как группа поставщиков инфраструктуры стала крупнейшими и наиболее распространенными валидаторами почти во всех цепочках. В большинстве цепочек Cosmos зависимости между валидаторами уже очень велики, и это, безусловно, представляет опасность для децентрализации и сопротивления цензуре указанных цепочек. Тем не менее, совсем другой факт заключается в том, что любой розничный инвестор может поставить любую сумму с любым валидатором по своему выбору. К сожалению, это обычно ставится в начало списка, и жизнь продолжается. Мы снова спрашиваем: ожидаем ли мы подобной экономической модели в модульном мире? Хотелось бы, чтобы это было не так, но со специализацией вам часто требуется наилучшее соответствие — и они, как правило, являются профессиональными поставщиками доказательств доли. Мы также рассмотрим эти экономические вопросы в отдельной главе позже.
Однако во всех этих вопросах важно помнить одну важную вещь: самое главное — это аутентификация конечного пользователя, которая доступна всем, где бы они ни находились (даже в Гизе) через легкие клиенты и пирамиду DAS).
Источник: @JosephALChami
Вот компромиссы и преимущества ограниченных и неограниченных сортировщиков:
Неограниченный набор сортировщиков:
Ограниченное множество сортировщиков:
Это одно из решений Эфириума для детерминизма одного слота и наличие суперкомитета «большинства».
Существует значительное пространство для разработки того, как эти наборы сортировщиков контролируются, а новые элементы добавляются или удаляются. Например, будет ли это достигнуто с помощью управления держателями токенов (как насчет множества разных токенов и накопительных пакетов, использующих коллекции?). Это означает, что сигнализация об изменениях вне сети может быть возможна благодаря социальному консенсусу (например, возьмем Ethereum в качестве примера). Однако помните, что фактический консенсус в сети четко установлен, и наказания за нарушение правил консенсуса уже существуют.
Экономический механизм для общих сортировщиков
Экономика совместного использования сети секвенсоров допускает некоторые интересные варианты. Как мы обсуждали ранее, валидаторы в общей сети заказов не сильно отличаются от типичных валидаторов L1. Сеть, в которой он участвует, просто более оптимизирована для выполнения одной задачи — получения намерений (ранее PBS) и, следовательно, предложения и заказа транзакций. Как и у «обычных» валидаторов, здесь есть компоненты дохода и затрат. С обеих сторон уравнения сети, в которых участвуют валидаторы, обладают большой гибкостью, подобно обычному L1.
Доход поступает от пользователей или роллапов, с которыми они в конечном итоге хотят взаимодействовать, уплачивая определенную плату за использование общего секвенсора. Эта плата может быть в процентах от снятых MEV (ввод цифр может быть затруднен для приблизительного определения), межсетевыми переводами стоимости, газом или фиксированной комиссией за взаимодействие. Наиболее подходящее решение для получения дохода может состоять в том, чтобы платить общему заказчику меньше стоимости, чем дополнительная стоимость, полученная с помощью общего заказа Rollup, наряду с преимуществами общей безопасности и ликвидности. Но недостатком этого является то, что трудно количественно оценить преимущества децентрализации другой части стека. Однако по мере того, как общая сеть заказов вырастает в собственную экосистему, ее способность взимать комиссионные может увеличиваться. Это в значительной степени связано с присущей им способностью легко агрегировать с определенной экономией за счет масштаба. По мере того, как к сети будет присоединяться все больше накопительных пакетов и приложений, все больше и больше междоменных MEV смогут извлекаться.
С точки зрения стоимости, общие сети заказов также имеют конкурирующие варианты. Они могут легко финансировать использование своей сети, оплачивая стоимость публикации на уровне DA или даже стоимость взаимодействия с приложениями в Rollup. Это похоже на стратегию, используемую компаниями Web 2.0, где вы берете на себя первоначальные убытки от привлечения пользователей (или объединения) в надежде, что их долгосрочный доход перевесит комиссионные. Еще один более новый или крипто-родной метод — разрешить Rollup оплачивать сборы DA с помощью собственного токена. Здесь уровень общего сортировщика несет риск ценообразования между токеном, необходимым для публикации данных на уровне DA, и собственным токеном Rollup. По сути, это по-прежнему общие первоначальные затраты на сортировщик, но он обеспечивает согласованность экосистемы за счет получения токена «поставщика» (т. е. накопительного пакета). Это чем-то похоже на конструкцию склада, которую мы объясняли в документе AppChain, и для снижения затрат можно использовать различные формы DA. Различные уровни DA будут предлагать разные цены из-за использования, возможности пользователей легко проверять через облегченный клиент или просто выбирать разные размеры блоков. Наконец, общий ордер может также пакетировать транзакции перед публикацией на уровне DA. В случае с ZKR это может снизить транзакционные издержки за счет определенного количества балансов транзакций, а с точки зрения ORU вы можете выполнять различные оптимизации газовой пакетной обработки, которые мы сейчас можем наблюдать на различных накопительных пакетах. Это уменьшит объем данных, которые необходимо опубликовать на уровне DA, тем самым снизив стоимость сети с общим секвенсором и повысив рентабельность всей сети. Это произойдет за счет ограничения совместимости и изменения времени завершения блока (детерминизм на L1, как упоминалось ранее).
В целом, экономика совместного использования сети секвенсоров позволяет проводить интересные эксперименты и стратегии начальной загрузки. По нашим оценкам, ключевое отличие будет заключаться в размере экосистемы, поэтому количество междоменных MEV больше, чем аспект затрат. Мы также настоятельно рекомендуем ознакомиться с записью в блоге команды Espresso об общих заказах, они также охватывают экономические компромиссы (и положительные стороны) этих типов сетей. Чтобы показать, почему Rollup заинтересован в использовании общих сортировщиков (помимо экономических), мы можем рассмотреть это с точки зрения теории агрегации.
Теория агрегации и общие сортировщики
Другой способ описать свойства общих сортировщиков — через призму теории агрегации. Теория агрегации относится к концепции того, как платформа или агрегатор систематически интегрирует другие платформы и их пользователей, чтобы привлечь значительное внимание пользователей. Вы, по сути, переводите игру от распределения ограниченного ресурса (например, пространства блоков) к необходимости контролировать обильные ресурсы (опять же, в этом примере имеет смысл пространство блоков). Теория агрегации фактически объединяет поставщиков и продукты (например, Rollup и Blockspace) в опыт суперпользователя для обслуживания объединенной пользовательской базы. По мере роста сетевого эффекта этих агрегаторов эти отношения становятся все более эксклюзивными. Когда это происходит, пользовательский опыт становится ключевым отличием между аналогичными настройками. Если есть стимулы для привлечения новых пользователей (например, хороший пользовательский опыт и лучшая функциональная совместимость), маловероятно, что Rollup переместится в свою собственную сеть или другую настройку, поскольку сетевые эффекты стимулируют появление новых поставщиков и присоединение новых пользователей. Это создает эффект маховика не только с точки зрения поставщика и пользователя, но и с точки зрения совокупной устойчивости к цензуре.
Источник: Теория агрегации 2015 г., Бен Томпсон
В области общих сортировщиков теория агрегации может рассматриваться как «комбинация» и федерация различных накопительных пакетов, использующих схожие вертикали стека, что расширяет возможности самих себя и других, позволяя пользователям получать одинаковый опыт.
Провайдеры (такие как Rollups) теоретически не являются исключительными для общего набора координаторов, но на практике набор общих координаторов, его сводки и пользователи извлекают выгоду из ряда циклов сетевых эффектов, которые приводят к более широкому использованию этих сверток. Эти преимущества упрощают интеграцию Rollup и пользователей в общий стек, поскольку они могут потерять больше, если не будут участвовать. Хотя эти преимущества могут быть трудно увидеть, когда у вас есть только два накопительных пакета, совместно использующих один и тот же набор секвенсора, они становятся более очевидными по мере того, как вы добавляете в уравнение все больше и больше накопительных пакетов и пользователей. Общие наборы сортировщиков имеют прямое отношение к пользователям, поскольку они упорядочивают свои транзакции, даже если сами пользователи не знают, что взаимодействуют с ними, поскольку, с их точки зрения, они просто используют свертки, с которыми у них есть причина взаимодействовать ( Это означает, что заказы/сортировщики становятся эксклюзивными). Единственная стоимость этих сортировщиков — это стоимость оборудования для их запуска, если пространство блока и защищающие его токены ценны для конечного пользователя. Плата за транзакции оцифровывается, выплачивается из кошельков пользователей и, возможно, в будущем может быть даже абстрагирована за счет таких усовершенствований, как платежные хосты в абстракции аккаунта (однако кто-то должен будет нести расходы на DA, заказ и исполнение).
Это имеет больше смысла, если учесть предыдущую компанию Джоша и Джордана в Астрии — Google. С момента своего создания продукты Google были вдохновлены идеей AT, особенно в поиске Google, который создается путем модульного разделения отдельных страниц и статей, что делает их доступными напрямую через окно глобального поиска.
В случае с общим набором сортировщиков пользователи, использующие накопительные пакеты (те, кто использует общий набор сортировщиков), несут все более низкие затраты на приобретение, поскольку по мере увеличения числа поставщиков (агрегированных сортировщиков) они, скорее всего, будут привлечены к набору. . Это означает, что в большинстве случаев агрегатор (или мультиагрегатор) имеет возможный беспроигрышный эффект, поскольку ценность агрегатора увеличивается с увеличением количества поставщиков (конечно, если пользовательский опыт хороший). Напротив, в одной последовательной сети привлечение клиентов ограничивается одной сетью и ее приложениями. Если пользователи хотят использовать приложение Rollup в другом Rollup, им придется (в рамках текущих ограничений) полностью выйти из сети. Это означает, что пользовательская привязанность и ценность не очень высоки, а также это означает, что в любой момент, если другая экосистема Rollup будет высоко оценена (или имеет больше стимулов), капитал может быть потерян.
Сводка атрибутов и компромиссов
Атрибуты
Общий набор сортировщиков — это сеть свертки, которая объединяет и сортирует транзакции для нескольких сверток. Эти накопительные пакеты используют один и тот же сортировщик. Такое объединение ресурсов означает, что накопительные пакеты получают более надежную экономическую безопасность и возможности защиты от цензуры, которые могут обеспечить быстрые мягкие детерминированные гарантии и условные транзакции между накопительными пакетами.
Прямо сейчас много шума вокруг атомарности среди роллапов, которые используют один и тот же набор сортировщиков, в основном вокруг того, является ли он атомарным по умолчанию, а это не так. Однако, если рассматриваемые свертки реализуют функции перехода состояния друг друга (STF) как зависимости между ними, включая условные транзакции, то они действительно могут достичь атомарности между ними - до тех пор, пока их выравнивание слота/блока (как с общими наборами сортировщиков). В этом случае, чтобы получить атомарную интероперабельность, вам действительно нужно запустить легкий клиент цепочки B в цепочке A и наоборот (аналогично тому, как работает IBC). Чтобы еще больше усилить интероперабельность мер безопасности (помимо того, чтобы доверять одному полному узлу как легкому узлу), вы можете реализовать ZKP (Proof of State), чтобы решить «проблему оракула» обеспечения правильности состояния. Это позволит лучше увидеть, попала ли условная транзакция или что-то подобное в канонический мост между ними. Доказательства мошенничества также возможны, но, очевидно, оставят период оспаривания (это означает, что третья сторона покроет стоимость этого риска). Кроме того, в случае легких клиентов (а не полных узлов) отставание будет как минимум на один блок из-за ожидания заголовка подписи + окна защиты от мошенничества (если есть).
Мы считаем, что проблема «межсетевого моста», скорее всего, будет решена с помощью облегченных клиентов и доказательств с нулевым разглашением. Проблема с использованием облегченного клиента (а не смарт-контракта) в этом случае заключается в том, что хард-форки (обновления и т. д.) на стороне узла Rollup должны координировать друг с другом, чтобы их мост работал (точно так же, как IBC должен включить тот же модуль состояния). Если вы хотите глубже погрузиться в эту конкретную тему (и как ее решить), мы настоятельно рекомендуем ознакомиться с этой презентацией.
Причина, по которой общие ордера так хорошо масштабируются, заключается в том, что они не выполняют и не сохраняют никакого состояния (как это делают сегодня централизованные ордера). То же самое касается самих узлов Rollup (если только они не хотят атомарности между собой — например, легкий клиент/доказательство состояния). Эти узлы выполняют только транзакции, допустимые для их свертки, и любые допустимые для них условные междоменные транзакции. Если узел Rollup должен выполнять и сохранять состояние для нескольких Rollup, это затрудняет масштабируемость и снижает децентрализацию (и, следовательно, устойчивость к цензуре). Это также усиливает концепцию разделения производителей блоков и сборщиков блоков (PBS). Хотя нам все еще нужно полностью разделить строителей и производителей блоков. В текущей настройке ордера по сути являются строителем и производителем блоков (хотя они и не выполняют транзакции). Идеальная установка может быть такой, при которой заказчик существует только для того, чтобы слепо подписывать блоки из высокооптимизированной установки компоновщика и обеспечивать правильную реализацию блоков (при обеспечении высокой степени экономической уверенности и устойчивости к цензуре для этой сертификации). Таким образом, они могут обеспечить высокую степень безопасности и обязательств, чтобы гарантировать мягкую завершенность для узлов Rollup.
Для условных транзакций перекрестного свертывания они также существуют, чтобы помочь узлам свертывания (исполнителям) предоставлять корни промежуточного состояния, обеспечивая атомарность между свертываниями.
компромисс
Вышеупомянутый параметр тайм-аута оказывает интересное влияние на MEV и включение транзакций в зависимости от механизма мастерноды/консенсуса в наборе заказчиков. Например, если параметр тайм-аута описан как относительно короткий в нашей цепочке приложений для конкретного приложения, крайне важно, чтобы производители блоков децентрализованного набора заказчиков публиковали данные как можно быстрее. В таком мире вы можете увидеть конкуренцию между «валидаторами», которые соревнуются за звание мастер-узлов и делают ставки на уровне DA за блочное пространство до тех пор, пока это не перестанет быть прибыльным.
Как писал Эван в своем первоначальном посте о ленивом заказе на форумах Celestia, ожидание публикации транзакций на базовом уровне (в данном случае Celestia) перед их выполнением очень неэффективно. Поскольку теперь вы ограничены временем блокировки базового слоя, которое слишком долго, чтобы ждать взаимодействия с пользователем. Для лучшего взаимодействия с пользователем общий ордер предоставляет накопительные пакеты с мягкими детерминированными обязательствами (как описано ранее), которые обеспечивают пользователям пользовательский опыт, к которому они привыкли в существующих централизованных накопительных пакетах (при сохранении децентрализации и высокой устойчивости к цензуре). Мягкие обязательства — это, по сути, просто обязательства по окончательному порядку транзакций, но подкрепленные серьезными экономическими гарантиями и быстрым завершением после их выпуска. Это также покрывается доказательствами мошенничества (как упоминалось во введении). Фактическая жесткая завершенность достигается после того, как все данные транзакции будут опубликованы на базовом уровне (это означает, что L1 фактически достигает более быстрой окончательности). Это зависит от того, использует ли Rollup доказательства мошенничества или доказательства с нулевым разглашением для подтверждения суверенитета, что происходит в Rollup. Причина такого разделения состоит в том, чтобы убрать огромное узкое место переходов состояний из сортировщика. Вместо этого узлы Rollup работают только с теми узлами, которые действительны для них (это означает, что мы должны добавить условные транзакции, подтверждение состояния или легкую проверку узлов для надлежащей совместимости). Жесткий детерминизм по-прежнему зависит от базового слоя (но это может достигать 15 секунд на Celestia, а также является детерминированным в Tendermint), что дает нам относительно быстрые гарантии жесткого детерминизма на Rollup.
Используйте доказательства с нулевым разглашением внутри сети, чтобы оптимизировать проверку и размер транзакции (например, публиковать только различия в состоянии, но это повышает уровень доверия до тех пор, пока ZKP не будет опубликован). Как упоминалось ранее, эти доказательства состояния можно использовать для упрощения и ускорения взаимодействия подключенных цепочек/агрегатов (без ожидания окон вызова).
Недостатком этих условных транзакций является то, что они, вероятно, будут более дорогими, требуя более высоких затрат на проверку и выпуск (например, стоимость проверки заголовка блока Tendermint, которая субсидируется в цепочке Cosmos), и добавляют некоторую задержку в систему ( но все же быстрее, чем изолированные накопительные пакеты намного быстрее). Атомарность, достигаемая за счет вертикально разделяемой интеграции, может компенсировать эти проблемы.
На этапе начальной загрузки нового накопительного пакета использование общего набора сортировщиков имеет большой смысл, и преимущества, которые вы получаете как поставщик, скорее всего, перевесят некоторые компромиссы, на которые вы, возможно, будете «вынуждены» пойти на уровне рва. Однако для уже зрелого роллапа, где много транзакций и экономической активности, наверное, не имеет смысла отказываться от части рва.
В связи с этим возникает вопрос, нужно ли нам аналогичное взвешенное экономическое/транзакционное (для каждого свертывания) перераспределение извлеченных MEV, чтобы побудить уже зрелые свертывания присоединиться к общему набору — или даже не дать чрезвычайно зрелым свертываниям создать собственную сеть. Все это довольно теоретически, но это, несомненно, интересный мыслительный процесс в отношении того, как MEV в общих вертикальных мирах будут представлены между множеством Rollup с различными уровнями активности. Например, если уникальный накопительный пакет, создающий ценность, делится частью этой прибыли с другими (вероятно, не принося большой «ценности») через набор Sequencer Set, то у них должно быть больше причин для перехода в свою собственную разрозненную систему. У Sreeram от EigenLayr также есть некоторые мысли по этому поводу, которые мы также рекомендуем прочитать.
Это становится все более важным, если учесть, что поисковые компании несут значительные технические затраты на разработку новых цепей, поэтому стандартизация и обеспечение некоторой независимости над «своими» MEV может быть хорошим началом. На практике в MEV доминирующий интерфейс (или программное обеспечение) может победить, но на самом деле монетизировать это программное обеспечение за счет запуска критических частей инфраструктуры очень сложно (что приводит к централизации). На рыночном уровне то, что предоставляет общий ордер, в основном представляет собой общий мемпул для нескольких поставщиков с централизованным аукционом, что может привести к более здоровой конкуренции.
Проблема здесь в том, что если два накопительных пакета запускают сортировщики в общем наборе, то может быть выбран накопительный пакет с «менее экономичным» значением (A), чтобы предложить накопительный пакет с большим количеством MEV + сборы от накопительного пакета (B). . С точки зрения Rollup B, они, по сути, упускают некоторую ценность, которую при изолированном подходе оставили бы для себя.
Устранение компромиссов совместимости
Еще одно замечание о компромиссах, связанных с функциональной совместимостью, и еще один способ решения некоторых проблем:
Целью общей сети заказов является предоставление канонической гарантии для нескольких цепочек, что в данном случае, очевидно, является большим преимуществом. Это можно комбинировать с механизмом, гарантирующим эффективные переходы состояний между накопительными пакетами. Это может быть подход на основе комитета (например, PoS), защищенные доказательства (оптимистический подход) или предпочитаемый нами подход — ZKP, подкрепленный подписями комитета. Поскольку общие сортировщики являются «ленивыми», они создают суперблоки только для сортировки транзакций нескольких сверток, а выполнение конкретной транзакции предоставляется конкретному свертыванию. Доказательства состояния (например, Лагранжа, Аксиомы или Геродота и т. д.) — все это возможные решения для потенциального получения доказательств окончательности для суверенных сверток. Вы даже можете добавить доказательства экономически гарантированной окончательности с помощью таких вещей, как пулы ставок, EigenLayr и т. д. Основная идея заключается в том, что общий сортировщик обеспечивает экономическую гарантию упорядочения, а доказательства достоверности, генерируемые в результате этой сортировки, являются детерминированными. Основная идея заключается в том, что Rollups могут выполнять транзакции синхронно друг с другом. Например, сеть из двух узлов Rollup может условно знать, что обе истории Rollup действительны, через ZKP и доступные данные (данные, опубликованные на эффективном уровне DA). Публикуя один префикс блока агрегации из обеих сетей A и B, узел агрегации может одновременно урегулировать два агрегации. Следует отметить, что условные кросс-агрегированные транзакции потребляют ресурсы из двух отдельных систем посредством совместного выполнения, поэтому атомарные (или синхронные) кросс-агрегированные транзакции, вероятно, будут дороже, чем интра-транзакции с одиночным свертыванием.
Succinct также осветил межсетевые «атомарные» транзакции между роллапами с общими заказчиками (и общими средствами защиты от мошенничества) в рамках экосистемы гиперцепей Optimism, которые можно посмотреть здесь. Кроме того, как выразился Бо Ду из Polymer: «Атомарные транзакции между цепочками подобны получению блокировок между сегментами базы данных при записи».
Будущее вертикальной интеграции
Возможная внутренняя работа цепей SUAVE уже подробно исследована Джоном Шарбонно и др., поэтому мы не будем вдаваться в подробности. Если вы хотите более подробное описание, вы можете проверить его статью. Тем не менее, мы считаем, что вертикальная интеграция заслуживает отдельного введения, чтобы подчеркнуть, насколько мы можем быть модульными (и почему), а также представить некоторые проблемы и проблемы, связанные с вертикальной интеграцией.
В то время как текущая общая схема ордеров Astria, Espresso и Radius очень модульная, ордера по-прежнему действуют как строители и производители блоков (хотя в случае Astria они не выполняют транзакции). Astria с самого начала активно встраивала PBS в свою архитектуру.
Если PBS не встроен в протокол, есть несколько способов реализовать PBS (хотя и с разной степенью децентрализации). Такие продукты, как SUAVE, используют автономные модели, такие как MEV-Boost, или реализуют модули-конструкторы, такие как модули Cosmos SDK, созданные Mekatek и Skip.
Стоит отметить, что ни один из этих методов не является взаимоисключающим. У вас есть возможность использовать несколько различных методов и позволить любому выразить свои предпочтения. Таким образом, у вас могут быть исполнители, конкурирующие за заполнение этих вакансий. Добавление дополнительных опций всегда хорошо (и согласуется с нашей верой в модульность). Тем не менее, разные реализации будут иметь разные компромиссы. Например, в таком случае, как SUAVE, вы можете добавить защиту конфиденциальности с помощью технологии SGX или Crypto и добавить к истине экономическую безопасность Crypto, вместо того, чтобы полагаться на полностью доверенного централизованного компоновщика PBS. (Спасибо Джону Шарбонно за его отзыв здесь).
Вертикальная интеграция в цепочку компоновщика обеспечивает справедливость без использования ярлыков, увеличения задержки и снижения производительности. Следовательно, цепочка сборщика должна быть сильно оптимизирована и может потребовать дорогого и мощного оборудования (что приводит к централизации). Это означает, что для проверки конечного пользователя нам, вероятно, потребуются какие-то легкие узлы (хотя им придется доверять полным узлам) или использовать настройку типа подтверждения состояния, чтобы убедиться, что цепочка и пользователи имеют доказательство того, что предпочтения ставок заполнены и блоки правильные Construct.
Цепочка, подобная этой, может быть очень тяжелой (мы хотим этого избежать), хотя эти транзакции с большим количеством состояний будут иметь приоритет через смарт-контракты. В случае приоритетной заявки она либо заполняется, либо не заполняется (на короткий период времени), поскольку заявки обычно действительны только в течение короткого периода времени, в зависимости от предпочтений. Это означает, что мы можем реализовать очень эффективное (и раннее) истечение состояния для ставок, что позволит нам сократить данные и сохранить цепочку «чистой». Эта дата истечения должна быть достаточно длинной, чтобы по-прежнему можно было выполнять заявки в первую очередь, но слишком сильное ее снижение сделает почти невозможным достижение форвардных фьючерсов на блочное пространство. Нам не нужно обновлять и извлекать контракты с истекшим сроком действия, поскольку они не должны существовать вечно (в отличие от приложений). от решения Joachim Neu), чтобы сделать его более «безопасным» и заслуживающим доверия.
Как упоминалось ранее, необходимость проверки «подлинности» SUAVE может быть ограничена «jusha» (продвинутыми пользователями) платформы, поскольку большинство пользователей и клиентов SUAVE могут получить от нее большие экономические выгоды. Это может подтолкнуть нас к тому, чтобы позволить людям запускать полные узлы только в том случае, если они хотят пройти валидацию, хотя это исключает подавляющее большинство людей (можно сказать, что им не нужно валидировать). Это (на наш взгляд) противоположность Crypto, где мы предпочли бы реализовать «ненадежную» проверку SUAVE с помощью проверки состояния или легких клиентских реализаций.
Причина, по которой это необходимо, заключается в том, что вы хотите убедиться, что ваш приоритет ставки был заполнен правильно и что блок был заполнен правильной информацией при оплате (чтобы избежать повторного набора и других ошибок). По сути, это проблема оракула — на самом деле ее можно решить с помощью доказательства состояния (как в случае со всеми SUAVE). Однако эти доказательства состояния вызывают другую проблему при пересечении цепочек: как передать эту информацию по цепочкам таким образом, чтобы она не была подделана или скрыта? Для этого может потребоваться пройти через сильную экономическую завершенность (например, предложенную Лагранжианом), и в этом случае вы можете использовать валидаторы повторного стейкинга EigenLayr, чтобы доказать завершенность и подлинность цепочки, и иметь очень сильные экономические ограничения. Затем возникает еще одна проблема (например, в контракте о торгах оговаривается, что «оракульная машина» — в данном случае повторно залогодатель — определила заложенный Токен и обеспечила экономическую привязку — но как мы можем прийти к консенсусу между Внешним сокращением этого? вы можете написать критерии сокращения, это не является согласованным, что означает, что социальное сокращение будет использоваться с помощью смарт-контрактов (что почти никогда не бывает «честным» и может вызвать проблемы).В настоящее время это имеет место в EigenLayr. .
Итак, где это нас оставляет? Возможно, до тех пор, пока мы не получим «ненадежное» слэшинг в цепочке за пределами консенсуса, таким цепочкам, как SUAVE, могут понадобиться свои собственные алгоритмы консенсуса и криптоэкономическая безопасность, чтобы доказать предпочтения ставок и создать уверенность в блоке. стоимость его строительных блоков намного выше, чем его собственная криптоэкономическая безопасность.
Кроме того, в цепях типа SUAVE и междоменных MEV еще много места для дизайна.Вот некоторые возможные направления исследований:
Что касается выражения предпочтения, то для взаимодействия со смарт-контрактом в EVM необходимо отправить вызов контракта (сообщение) конкретной функции по адресу развернутого кода, содержащего инструкцию выполнения. Хотя пользователи вводят данные, они могут не иметь контроля над выводом из-за возможной сохранения состояния.
Напротив, системы дизайна выражения предпочтений (такие как SUAVE и Anoma) требуют, чтобы пользователи подписывали предпочтения только залогом, который выплачивается строителям и производителям блоков, если предпочтения искателя удовлетворены. Для сложной комбинаторной логики, такой как последовательности транзакций для искателей и сборщиков MEV, может потребоваться реализация разных языков и виртуальных машин. Это новое пространство дизайна, которому в последнее время уделяется много внимания, особенно архитектуре Anoma. Кроме того, мы настоятельно рекомендуем эту короткую статью.