Base — это L2-сеть поверх Ethereum, построенная на стеке OP Stack и инкубируемая биржей Coinbase. Страница crypto:base описывает Base с точки зрения пользователя; здесь мы смотрим на архитектуру: из каких компонентов состоит сеть, какие доверительные допущения нужны и как устроены комиссии и доходы sequencer-а.
Что важно понимать про архитектуру Base:
- Base — optimistic rollup на OP Stack: исполнение на L2, урегулирование и оспаривание — в Ethereum L1.
- Ключевой операционный компонент — централизованный sequencer, который собирает и упорядочивает транзакции.
- Данные транзакций публикуются в Ethereum (DA-слой), что позволяет воспроизвести состояние L2 и даёт возможность форс-выхода.
- Канонический мост L1↔L2 реализован смарт-контрактами на Ethereum и Base; вывод подчинён challenge-периоду optimistic-модели.
- Комиссии пользователей разбиваются на часть, уходящую в L1 за данные, и маржу sequencer-а — источник дохода L2-сети.
Высокоуровневая схема: уровни архитектуры Base
По аналогии с общей архитектурой L2, Base можно разложить на несколько слоёв:
- Execution layer (исполнение)
EVM-совместимая среда, где выполняются смарт-контракты и транзакции пользователей. Для разработчика она выглядит как «обычный Ethereum»:
- те же типы транзакций;
- тот же язык (Solidity) и инструменты;
- те же базовые паттерны управления газом.
- Sequencer / Rollup node (упорядочивание)
Специальные узлы принимают транзакции, упорядочивают их, формируют L2-блоки и подготавливают батчи для L1.
В текущей модели это централизованный компонент, управляемый структурой, связанной с Coinbase.
- Data Availability (доступность данных)
Данные батчей публикуются в Ethereum (calldata / блобы), что делает состояние Base воспроизводимым. Это критично для безопасности optimistic rollup (см. доступность данных).
- Settlement и fraud-proof (урегулирование и оспаривание)
Набор смарт-контрактов на Ethereum:
- принимает батчи данных с L2;
- хранит коммитменты состояний;
- реализует challenge-период и логику fraud-proof (подробнее про модель — в rollup L2 и обзоре роллапов).
- Мост и вспомогательная инфраструктура
Канонический мост L1↔L2, RPC-узлы, индексаторы, аналитика и сервисы, обеспечивающие возможность работы dApp и пользователей.
Execution layer: EVM-среда Base
С точки зрения исполнения Base — EVM-сеть:
- смарт-контракты пишутся и деплоятся так же, как в Ethereum;
- используются те же фреймворки для разработки и тестирования;
- интерфейсы кошельков (MetaMask, Coinbase Wallet и др.) работают по стандартным EVM-паттернам.
Важные практические моменты:
- Адресное пространство.
Адреса контрактов на Base — отдельное пространство: даже если ABI совпадает с контрактом в Ethereum, адрес будет другим.
- Газ и единицы.
Газ измеряется в gas / gwei, комиссия платится в ETH (см. комиссии в Ethereum и gwei).
Внутренняя стоимость единицы газа на Base зависит от загруженности L2 и L1.
- Системные контракты.
Как и в других L2, существуют системные контракты, отвечающие за интеграцию с L1, маппинг адресов, обработку сообщений и т.п. Они управляются операторами L2 и обновляются через протокольные апгрейды.
Sequencer и rollup-узлы: как формируются блоки L2
Центральный элемент архитектуры Base — sequencer:
- Приём транзакций.
Узлы sequencer-а принимают транзакции через RPC/кошельки и внутренние каналы (например, из интерфейсов Coinbase).
- Упорядочивание и включение в блок.
Транзакции упорядочиваются по внутренним правилам (обычно — по gas price и времени), формируется L2-блок.
- Публикация состояния.
После исполнения блока обновлённое состояние L2 становится доступным для узлов Base и пользователей.
Это «быстрое» подтверждение: оно опирается на честность sequencer-а, а не на L1.
- Подготовка батчей для L1.
Через определённые интервалы времени sequencer/rollup-узел собирает блоки в батч, сжимает данные и отправляет их в Ethereum через контракт rollup-а.
С точки зрения доверия:
- пользователи полагаются на то, что sequencer честно упорядочивает и отправляет транзакции;
- отказ или цензура со стороны sequencer-а ухудшают UX (задержки, невозможность включить транзакцию), но не должны лишать пользователя средств — для этого существуют механизмы форс-выхода через L1-контракты.
DA и settlement на Ethereum: где хранится «правда»
Базовая гарантия безопасности Base связана с тем, как данные транзакций и состояния попадают в Ethereum:
- Публикация данных.
Батч содержит:
- сжатые данные транзакций L2;
- коммитменты к состояниям;
- служебную информацию для fraud-proof.
- Контракты rollup-а.
На уровне L1 работают специальные контракты:
- принимают батчи;
- проверяют базовые инварианты формата;
- запускают challenge-период, в течение которого батч может быть оспорен.
- Challenge-период.
До истечения этого окна состояние L2 считается «optimistic»:
предполагается, что оно корректно, пока никто не доказал обратного.
- Fraud-proof.
Если участник находит некорректное состояние:
- инициирует спор в L1;
- система разбивает исполнение на шаги и проверяет спорную часть;
- в случае обнаружения ошибки батч отклоняется, а инициатор некорректного состояния может потерять залог.
За счёт такой схемы даже при злонамеренном или ошибочном поведении sequencer-а у пользователей остаётся возможность подтвердить «правильное» состояние на L1 и вытянуть свои средства через мост.
Мост L1↔L2: канонический bridge и форс-выход
Для ввода и вывода средств между Ethereum и Base используется канонический мост (bridge):
- Депозит (L1 → Base).
Пользователь:
- отправляет токены в контракт моста на L1;
- ждёт подтверждения транзакции в Ethereum;
- получает «отзеркаленный» актив на Base после обработки события мостом.
- Вывод (Base → L1).
Процесс обратный:
- инициируется транзакцией на Base;
- формируется запись о запросе на вывод;
- после публикации соответствующего батча и истечения challenge-периода токены становятся доступными на L1.
- Форс-выход.
В архитектуре rollup важно, чтобы даже при проблемах с sequencer-слоем пользователь мог:
- взаимодействовать напрямую с L1-контрактами;
- завершить вывод при наличии корректных данных о состоянии, опубликованных ранее.
С точки зрения архитектуры мост Base — частный случай общего паттерна, разобранного в описании кросс-чейн моста. На уровне модели доверия к нему применимы общие риски, обсуждаемые в термине о рисках мостов.
Модель комиссий и доходы sequencer-а
Комиссия за транзакцию в Base обычно включает две компоненты:
- L2 execution fee.
Стоимость исполнения транзакции на L2 (EVM-газ, использование CPU/памяти и т.п.).
- L1 data fee (DA-компонента).
Доля затрат на публикацию данных батча в Ethereum:
- размер зависит от объёма данных и цен на газ в L1;
- в долгосрочной перспективе на неё сильно влияет развитие EIP-4844 и последующих апгрейдов (см. дорожную карту апгрейдов Ethereum).
Распределение платы:
- часть комиссии уходит в Ethereum как оплата газа за публикацию данных;
- оставшаяся часть становится доходом sequencer-а (и, как следствие, тем, кто его контролирует).
Такой дизайн создаёт отдельный экономический поток:
- L1 получает доход за хранение и обработку данных L2;
- L2-оператор (в случае Base — структура, связанная с Coinbase) получает маржу за исполнение и агрегацию транзакций.
Этот поток доходов и стимулы оператора подробно обсуждаются в модели рисков и стимулов L2.
Роль Coinbase в архитектуре Base
Роль Coinbase в Base можно условно разделить на несколько уровней:
- Оператор sequencer-а.
Управляет узлами, которые:
- принимают транзакции;
- формируют блоки L2;
- собирают и отправляют батчи в Ethereum.
- Инфраструктурный провайдер.
Обеспечивает:
- RPC-эндоинты (для приложений и пользователей);
- мониторинг, алертинг, DevOps-процессы;
- интеграции с централизованной биржей, кошельками и on-ramp-сервисами.
- Участник governance вокруг OP Stack / Superchain.
Как оператор крупной OP Stack-сети, Coinbase вовлечена в обсуждение развития стека, апгрейдов и стандартов (см. OP Stack).
С точки зрения архитектуры это означает, что:
- важные технические решения (тайминги батчей, параметры sequencer-а, политика обновлений) принимаются централизованным актором;
- пользователи и разработчики доверяют не только коду протокола, но и операционным процессам крупной компании.
Риски и ограничения архитектуры Base
Часть рисков Base общая для большинства optimistic rollup, часть — связана с ролью Coinbase.
Основные блоки:
- Централизация sequencer-а.
Пока sequencer контролируется одним оператором:
- возможны цензура транзакций, отказ в обслуживании, приоритетная обработка «своих» операций;
- при сбое инфраструктуры страдает UX (задержки, невозможность отправить транзакции).
- Управляемые апгрейды.
Обновления системных контрактов и клиентов проводятся централизованно:
- требуется доверие к процессу релизов;
- ошибки при апгрейдах могут приводить к временным блокировкам, остановкам моста и т.д.
- Зависимость от Ethereum.
Безопасность DA и fraud-proof опирается на Ethereum:
- изменение газовой политики или апгрейды L1 требуют адаптации стека;
- проблемы в Ethereum транслируются на Base.
- Мост и связанная инфраструктура.
Канонический мост и сторонние мосты добавляют собственные поверхности атаки:
- уязвимости в коде;
- ошибки конфигурации;
- компрометация ключей операторов.
Системную картину этих рисков удобно рассматривать через модель рисков L2 и материалы про архитектуру кросс-чейн мостов.
Практические выводы для разработчиков и интеграторов
Для разработчика, переносящего dApp на Base, архитектура даёт несколько выводов:
- Нужно понимать стоимость DA.
Оптимизируйте размер calldata, количество и частоту операций — от этого зависит компонент L1 data fee.
- Закладывайте допущения L2.
Планируйте работу протокола с учётом:
- возможных задержек с публикацией батчей;
- окна challenge-периода (особенно для выводов и критичных операций).
- Проверяйте поведение при деградации.
Проработайте сценарии:
- временной недоступности sequencer-а;
- повышенных комиссий;
- необходимости форс-выхода через L1.
- Учитывайте риски мостов.
Приём и вывод ликвидности, использование сторонних мостов и ликвидити-протоколов требуют отдельного анализа (см. мост между блокчейнами и риски мостов).