Оригинальное название: «Объяснитель коренных пород».

Автор: Официальный Оптимизм

Составитель: Фрэнк, Foresight News

Bedrock — это название первой официальной версии OP Stack, набора бесплатных модульных компонентов с открытым исходным кодом, предназначенных для обеспечения роста Optimism.

Обзор улучшений

Bedrock усовершенствовал своего предшественника, в том числе:

  • Снизьте комиссию за транзакции, используя оптимизированное пакетное сжатие транзакций и Ethereum в качестве уровня доступности данных;

  • Снижение задержки при упаковке транзакций L1 в сводные данные за счет лучшей обработки реорганизаций L1;

  • Включите модульные системы проверки за счет повторного использования кода;

  • Улучшите производительность узла за счет устранения задолженностей по проектированию.

более низкие комиссии

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

Bedrock также исключает все затраты на газ, связанные с выполнением EVM, при отправке данных в L1, что снизит затраты еще на 10% по сравнению с предыдущими версиями протокола.

Более короткий срок кредитования депозита

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

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

Улучшенное модульное доказательство

Bedrock абстрагирует систему доказательств от стека OP, чтобы при объединении можно было использовать доказательства сбоев или доказательства достоверности (например, zk-SNARK) для подтверждения правильного выполнения после ввода в объединение. Эта абстракция также позволит использовать Cannon для доказательства. системная ошибка.

Улучшена производительность узла

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

Это позволяет распределить стоимость обновлений Merkle Trie по нескольким транзакциям, что при текущих объемах транзакций снижает рост данных состояния примерно на 15 ГБ в год.

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

Улучшенный эквивалент Ethereum

Bedrock с самого начала разрабатывался так, чтобы быть максимально «совместимым» с Ethereum, и многие отклонения от Ethereum в предыдущих версиях протокола были устранены, в том числе:

  • Модель «Одна транзакция на блок»;

  • Настройте код операции для получения информации о блоке L1;

  • Отдельные поля комиссий L1/L2 в API JSON-RPC;

  • Пользовательское представление ERC20 балансов ETH.

Bedrock также добавил поддержку EIP-1559, реорганизацию блокчейна и другие функции Ethereum, присутствующие в L1.

Принципы дизайна

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

Модульный

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

Это позволяет ему адаптироваться к будущему развитию экосистемы Ethereum с гибкой архитектурой, такой как:

  • Узел объединения отделен от клиента выполнения;

  • Модульная отказоустойчивая конструкция.

повторное использование кода

Bedrock использует существующую архитектуру и инфраструктуру Ethereum, когда это возможно. Этот подход позволяет OP Stack унаследовать преимущества безопасности и эффекта Линди от проверенной в боевых условиях базы кода, используемой в основной сети Ethereum.

Вы найдете примеры этого по всему дизайну, в том числе:

  • минимально модифицированный клиент исполнения;

  • Контракты EVM вместо предварительно скомпилированного клиентского кода.

Эквивалент Эфириума

Bedrock спроектирован так, чтобы быть максимально совместимым с существующим опытом разработчиков Ethereum, но есть некоторые исключения из-за фундаментальных различий между L1 и накопительным пакетом: разные модели комиссий, более быстрое время блокировки (2 секунды против 12 секунд) и специальные типы транзакций, включая депозитные транзакции L1.

Эти исключения включают в себя:

  • Проверка ошибок исполняющих клиентов Ethereum, предназначенная для подтверждения минимальных модификаций;

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

протокол

Объединения строятся на основе доступности данных (обычно это блокчейн L1, такой как Ethereum). В наиболее распространенной конфигурации протокол объединения создает «каноническую цепочку L2» из двух основных источников информации:

  • Данные транзакции публикуются секвенсором в L1;

  • Депозитные транзакции передаются счетами и смарт-контрактами в мостовой контракт на L1.

Ниже приведены основные положения договора:

  • Путем прямого взаимодействия со смарт-контрактом на L1 депозит записывается в «стандартную цепочку L2»;

  • Вывод средств записывается в «каноническую цепочку L2» и неявно запускает взаимодействие со смарт-контрактами и учетными записями на L1;

  • Пакеты — это записи данных, соответствующие пакетам при объединении;

  • Вывод блоков — это то, как интерпретировать чтение данных на L1, чтобы понять «каноническую цепочку L2»;

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

депозит

Депозит представляет собой транзакцию на L1 и будет включен в накопительный пакет. По определению, депозиты гарантированно включаются в «каноническую цепочку L2» как средство предотвращения цензуры или контроля над L2.

Любое сообщение, доставленное с L1

Депозитные операции – это агрегированные операции, выполняемые в рамках депозита. В Bedrock депозиты являются полностью универсальными транзакциями Ethereum, например, счета в Ethereum или смарт-контракты могут создавать «депозитные» контракты.

Bedrock определяет депозитный контракт, доступный на L1: это смарт-контракт, с которым могут взаимодействовать учетные записи L1 и смарт-контракты для записи на L2. Депозитные транзакции на L2 вытекают из транзакций, выпущенных этим депозитным договором, и включают ожидаемые параметры, такие как откуда, куда и данные.

Подробную информацию см. в разделе «Спецификации депозитного договора».

Купите гарантированный газ L2 на L1

Бедрок также разъяснил механизм сжигания газа и рынок комиссий за депозит. Газ, потраченный на L2 посредством депозитных транзакций, приобретается на L1 посредством сжигания газа.

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

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

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

Для более подробного объяснения, пожалуйста, прочтите спецификации протокола в разделе депозитов.

Снять деньги

Снятие средств — это межуровневые транзакции, инициированные на уровне L2 и завершающиеся транзакциями, выполненными на уровне L1. Стоит отметить, что счета L2 могут использовать снятие средств для вызова контрактов L1 или перевода ETH со счетов L2 на счета L1.

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

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

Двухэтапный процесс вывода средств

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

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

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

Подробную информацию см. в разделе «Спецификации соглашения о выходе».

Пакеты

В Bedrock для передачи сообщений между L1 и L2 определен проводной формат (т. е. L2 извлекает блоки из L1, L2 записывает транзакции в L1), этот проводной формат предназначен для снижения стоимости записи в L1 и сложности программного обеспечения до минимума.

Оптимизация сжатия данных

Для оптимизации сжатия данных списки транзакций L2 (называемые пакетами секвенсора) организованы в группы объектов (называемые каналами). Максимальный размер каждого канала можно определить в настраиваемом параметре, который первоначально будет установлен на 9,5 МБ. Эти каналы. ожидается, что он будет сжат с использованием функции сжатия и отправлен на уровень L1.

пакетная параллельная подача

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

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

Минимизация газа Эфириума

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

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

Примечание. Вскоре Ethereum будет обновлен до новой версии, которая включает EIP-4844, который вводит отдельный рынок комиссий за запись данных и увеличивает верхний предел объема данных, которые протокол Ethereum готов хранить. Ожидается, что это изменение приведет к дальнейшему снижению. количество затрат, связанных с публикацией в L1.

Более подробное объяснение можно найти в спецификации формата кабеля.

Блочная вилка

В Bedrock протокол разработан так, чтобы время депозитов на L1 было связано с созданием блоков «канонической цепочки L2». Это чистая функция записи данных в L1 через свойства секвенсора, депозита и блока L1.

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

Гарантированный депозит на счет

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

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

В Bedrock введено понятие «эпохи секвенирования»: это диапазон блоков L2, полученных из серии блоков L1. Каждая эпоха идентифицируется «номером эпохи», который равен номеру в окне сортировки. Порядковый номер первого блока L1. Размер эпох может варьироваться с некоторыми ограничениями.

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

Обратите внимание, что в версии Bedrock целевой интервал блокировки на L2 настроен на 2 секунды.

Обработка временных меток L1 и L2

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

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

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

Окно сортировки содержит блоки, что зависит от размера окна сортировки: фиксированный параметр конфигурации уровня свертки должен быть не менее 2, увеличение его даст секвенсору больше возможностей для сортировки транзакций L2 по депозитам, понижение для секвенирования Более строгое время окно, представленное сервером для отправки «транзакций дозатора». Это компромисс между созданием возможностей MEV и увеличением сложности программного обеспечения.

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

Блок-вилка трубопровода

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

Доказательство отказа

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

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

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

Для получения полной информации прочтите спецификацию протокола в разделе «Корневое предложение для вывода L2».

осуществлять

В Bedrock стек OP должен в значительной степени полагаться на указанное в Ethereum разделение технических задач, отражая разделение между уровнем исполнения Ethereum и уровнем консенсуса.

Поэтому Bedrock таким же образом ввел разделение клиентов исполнения и узлов объединения.

Выполнить клиента

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

С помощью Bedrock OP Stack стремится повторно использовать собственную спецификацию клиента исполнения Ethereum и многие из его операций исполнения. В этом выпуске Bedrock продемонстрировал крайне ограниченную модификацию клиента Ethereum — go-ethereum, с разницей менее 2000 строк кода.

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

Обработка депозитных операций

Для представления депонированных транзакций в сводном виде вводится дополнительный тип транзакции. Реализация клиентов, реализующих этот новый тип транзакции, основана на стандарте транзакций типа EIP-2718.

Взимать комиссию за транзакцию

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

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

Еще одна плата за доступность данных. Затраты на доступность данных связаны с записью пакетных транзакций в L1 и предназначены для покрытия сборов секвенсора за отправку пакетных транзакций в L1.

В Bedrock часть платы за доступность данных определяется на основе информации в смарт-контракте системы объединения под названием GasPriceOracle, который основан на атрибутах блока L1, вставленных в начале каждой эпохи в процессе создания блока. Полученная информация о цене газа. обновляется.

Bedrock указывает, что обе стоимости добавляются в одно поле при использовании JSON-RPC.

узел свертки

В отличие от Ethereum, у Bedrock нет консенсуса PoS. Напротив, консенсус «канонической цепочки L2» определяется путем образования блоков. Клиент выполнения OP Stack взаимодействует с новым компонентом, который реализует разветвление блоков, называемым узлом объединения, который взаимодействует с клиентом выполнения, используя тот же API-интерфейс движка, что и Ethereum.

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

Ниже приведены различные варианты использования узлов объединения:

Проверьте «каноническую цепочку L2»

Самый простой способ запуска узлов объединения — просто следовать «канонической цепочке L2». В этом режиме узел объединения не имеет одноранговых узлов и строго используется для чтения данных из L1 и интерпретации данных в соответствии с правилами протокола деривации блоков.

Одной из целей такого узла является проверка того, что любые выходные корни, совместно используемые другими узлами или опубликованные на L1, верны в соответствии с определением протокола. Кроме того, инициаторы, которые намереваются отправить выходные корни в L1, могут сами использовать optimism_outputAtBlock для генерации необходимых им выходных корней и возврата 32-байтового хеша, соответствующего выходному корню L2.

Для этого узлам нужно только следовать за «завершенным» заголовком блока. Термин «финализированный» относится к консенсусу Ethereum PoS (т.е. каноническому и практически необратимому), а «финализированный» заголовок блока L2 — это область «канонической цепочки L2», полученная только из «финализированного» большого блока L1. голова.

Участие в сети L2

Самый распространенный способ использования узла объединения — участие в сети других узлов объединения, отслеживание процессов и статуса L2. В этом режиме узел объединения одновременно считывает данные и передает полученные данные из L1, интерпретирует их в блоки и принимает входящие транзакции от пользователей и одноранговых узлов в сети других узлов объединения.

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

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

  • Заголовки небезопасных блоков L2 включают небезопасные блоки, которые не были производными от L1. Эти блокировки возникают либо из-за работы узла объединения в качестве секвенсора, либо из-за небезопасной синхронизации с секвенсором. Его также называют «последним» заголовком блока. В случае разногласий всегда выбирайте безопасный заголовок блока L2 вместо небезопасного заголовка блока L2. Когда возникает разногласие, небезопасная часть цепочки реорганизуется;

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

Сортировка транзакций

Третий способ использования узлов объединения — упорядочивание транзакций. В этом режиме узлы объединения будут создавать новые блоки поверх небезопасных заголовков блоков L2. В настоящее время в сети OP Stack имеется только один секвенсор.

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

Дозатор

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

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

Стандартный мостовой контракт

Bedrock также включает в себя пару бридж-контрактов для наиболее распространенных типов депозитов, называемых стандартными бридж-контрактами. Эти контракты инкапсулируют контракты на ввод и вывод средств, обеспечивая простой интерфейс для ввода и вывода токенов ETH и ERC-20.

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

Для получения дополнительной информации см. раздел «Спецификация стандартного протокола межцепочного моста».

Пушка

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

дальнейшее чтение

Спецификации протокола

Спецификация протокола определяет технические детали стека OP и является наиболее актуальным источником информации о внутренней работе протокола.

Основная разница

Подробную информацию о различиях между Bedrock и предыдущими версиями см. в разделе «Чем отличается Bedrock».