Почему разработка L2 упирается в пропускную способность
Пропускная способность любого блокчейна первого уровня фиксирована: блок вмещает строго ограниченный объём данных, и этот лимит нельзя расширить административно. Как только поток операций превышает порог, транзакции не отклоняются — они встают в очередь транзакций и ждут, пока освободится место в следующем блоке.
Дальше включается аукцион за это место. Стоимость транзакции считается по текущей загруженности, поэтому на пиковой нагрузке — запуск токена, массовая раздача, всплеск активности в приложении — плата вырастает в десятки раз за считанные минуты. Пользователь, который вчера отправлял операцию с минимальной платой, сегодня видит выросшую стоимость и просто закрывает интерфейс.
Продукт ломается не в момент явного отказа, а раньше. Задержка подтверждения растягивается с секунд до десятков минут, интерфейс показывает бесконечное «ожидание», балансы не сходятся, а сценарии, построенные на быстрой финальности — обмен, ставки, игровая механика, — становятся неработоспособными на всём интервале пика. В такие окна сеть теряет именно тех пользователей, которые пришли за скоростью, и возвращать их потом дороже, чем было бы удержать.
Разбираем, как это закрывается: где заканчивается ёмкость базового слоя и что именно даёт собственная сеть второго уровня.
Что даёт собственный роллап: скорость, стоимость, контроль
Пропускная способность перестаёт упираться в чужую сеть
Транзакции исполняются внутри вашего слоя, а в основную сеть уходит только сжатый пакет с результатом. Одна запись там несёт тысячи операций, поэтому пропускная способность при нагрузке растёт в разы, а не на проценты. Когда поток пользователей подскакивает, темп обработки задаёт ваш узел-упорядочиватель, а не общая очередь.
Комиссию задаёте вы, а не аукцион в основной сети
Плата за операцию определяется политикой вашего слоя: ровная ставка за газ вместо аукциона, где цена растёт от чужой активности. В пиковые часы комиссия не удваивается — её можно ограничить сверху для пользователя и удерживать предсказуемой при кратном росте потока. Расходы на сервис становятся планируемыми, а не зависящими от чужого трафика.
Отказ, который больше не останавливает сервис
Собственный роллап снимает целый класс отказов, связанный с перегрузкой основной сети: операции не зависают в ожидании включения в блок и не теряются при скачке платы. Если основная сеть тормозит, пакеты накапливаются и подтверждаются позже, а состояние слоя и операции пользователей продолжают идти. Сервис перестаёт зависеть от того, что происходит в общей сети.
Предсказуемое время подтверждения
Время подтверждения определяется архитектурой, а не текущей загрузкой: операция видна пользователю почти сразу, финальность наступает после публикации пакета и проверки. В схемах с доказательством валидности финальность приходит одним шагом, в схемах с окном оспаривания — по понятному регламенту. В обоих случаях задержка не зависит от чужого трафика.
Сравнение подходов: оптимистичные роллапы и ZK-доказательства
Архитектуру второго уровня выбирают не по «современности» решения, а по тому, какие гарантии получает пользователь и сколько он ждёт возврата средств. Ниже — три варианта, между которыми реально выбирают на старте проекта.
Оптимистичная и ZK-схема расходятся по трём осям: финальность расчётов, время вывода средств и модель безопасности — кто именно доказывает корректность и что происходит при нечестном поведении узла.
Выделенный канал стоит особняком: он не наследует защиту базового слоя в полном объёме, зато даёт контроль над правилами исполнения и пропускной способностью.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Оптимистичный роллап | Массовые транзакции, перенос существующей логики контрактов без переписывания, быстрый запуск | Вывод средств ждёт окончания периода оспаривания — обычно дни; финальность расчётов отложенная, нужны наблюдатели, готовые оспорить неверный блок |
| Доказательства с нулевым разглашением | Нужна быстрая финальность и короткое время вывода средств, высокая ценность операций | Генерация доказательств дороже по вычислениям, часть операций приходится ограничивать; сложнее собирать и поддерживать доказывающую подсистему |
| Выделенный канал | Собственные правила газа, предсказуемая пропускная способность, приватные операции | Модель безопасности своя: корректность обеспечивают валидаторы канала, а не базовый слой; выход из канала сложнее |
На практике схему подбирают под профиль нагрузки: где важны совместимость и стоимость исполнения — выигрывает оптимистичный путь; где критична быстрая финальность — доказательства с нулевым разглашением.
Разработка L2: аудит, схема сети, настройка и передача
Разработку L2 начинаем не с кода, а с разбора того, что уже есть: какие сценарии обслуживает сеть, кто и как часто пишет в неё, где проходит граница между основной цепочкой и вторым уровнем. Такой порядок экономит недели — переделать схему после запуска узлов дороже, чем уточнить её до первой транзакции.
Порядок работ
- Аудит сценариев. Разбираем потоки операций, пиковый профиль нагрузки, требования к времени подтверждения и то, кто держит ключи. Фиксируем, какие операции выносим на второй уровень, а какие оставляем в основной сети.
- Проектирование схемы сети. Выбираем модель сборки и доказывания, число узлов-валидаторов, топологию размещения, правила платы за вычисления и роли доступа. Здесь же определяем, как сеть переживёт падение отдельного узла.
- Настройка узлов. Поднимаем узлы, настраиваем синхронизацию, доступ к состоянию сети, мониторинг и резервные копии. Отдельно проверяем, что порядок запуска воспроизводится с нуля по инструкции.
- Связка с основной сетью. Настраиваем перевод активов между уровнями, задержки вывода и обработку откатов при перестройке цепочки.
- Проверка под нагрузкой. Прогоняем сценарии, повторяющие пиковый профиль, замеряем пропускную способность и время отклика, намеренно гасим узлы и смотрим на восстановление.
- Приёмка и передача. Отдаём документацию, доступы, регламенты обновления и разбора сбоев, обучаем команду — сеть должна обслуживаться без нас.
Каждый этап закрывается артефактом: отчётом, схемой, конфигурацией или протоколом испытаний. Приёмка идёт по согласованным заранее метрикам, а не по ощущению «вроде работает».
Комплект документации: схемы сети, политики доступа, регламенты
После запуска сети у команды остаётся не только работающий контур, но и пакет документов, по которому её можно эксплуатировать без нас. Мы отдаём его в той форме, в какой сами им пользуемся: без общих слов, с конкретными значениями и процедурами. Ниже — что входит в комплект.
- Конфигурации узлов — файлы настроек секвенсора, проверяющих узлов и узлов доступа к сети с построчным разбором: какие значения штатные, какие подбирались под вашу нагрузку и что произойдёт при отклонении.
- Схема топологии — как узлы связаны между собой, где проходит граница с основной сетью, какие каналы дублируются и какие точки отказа оставлены сознательно.
- Политики доступа и роли — матрица «роль → действие → ключ»: кто выпускает обновления контрактов, кто управляет кошельками, кто только читает метрики и почему первые два права не должны быть у одного человека.
- Регламент обновления — порядок выпуска новых версий контрактов и узлов: подготовка, окно работ, кто утверждает, как проверяется результат и по какому сценарию откатываемся.
- Инструкции для дежурной смены — что считать отклонением, какие сигналы требуют реакции внутри смены, какие ждут утра, в какой момент поднимают разработчиков.
- Порядок работы с ключами — где хранятся ключи подписи, как проходит ротация и что делать при компрометации.
- План восстановления — что и с какой периодичностью копируется, сколько занимает подъём сети с нуля на чистой инфраструктуре и кто отвечает за процедуру.
Как мы снимали пиковую нагрузку: метрики до и после
Что было до переезда
Клиент — сервис с потоком мелких операций: начисления, ставки, выводы. В пиковые часы базовый слой переставал принимать часть транзакций: доля отклонённых операций доходила до 8–9%, а подтверждение растягивалось до минуты и больше. Повторные попытки только усиливали давление — очередь не успевала разбираться, и сервис уходил в деградацию именно тогда, когда нагрузка была максимальной.
Что изменили и что получили
Развернули собственный второй уровень на оптимистичных роллапах: сотни действий клиентов пакуются в один пакет, а в Ethereum уходит одна сводка. Добавили очередь с приоритетами и повторной постановкой — под перегрузкой операция ждёт своей очереди, а не отваливается.
Метрики до и после: доля отклонённых операций упала с 8–9% до 0,3%, среднее подтверждение сократилось с 60 до 2–4 секунд, поведение на пике стало ровным. Нагрузочный прогон с трёхкратным превышением обычного трафика удерживали 40 минут — без роста очереди и без ручных вмешательств дежурного.
Главное — ушёл целый класс отказов: операции больше не теряются из-за переполнения блока базового слоя. Повторы вернулись в штатный режим, а пиковые инциденты перестали быть регулярной статьёй в отчёте дежурства.
Чем оптимистичный роллап отличается от ZK-роллапа?
Оба семейства решают одну задачу: исполнение переносится с основного слоя, а в сеть-расчётный слой (Ethereum) уходят данные и доказательство корректности состояния. Разница в том, как устроено это доказательство — от него зависят момент подтверждения, требования к проверяющей стороне и объём работ по сопровождению.
Оптимистичный роллап по умолчанию считает партию транзакций верной и оставляет окно на оспаривание. Пока окно открыто, вывод средств на основной слой ждёт, зато проверять в реальном времени нечего: достаточно одного честного участника, который при расхождении опубликует доказательство мошенничества. Проверяющей стороне хватает обычного узла — специальное оборудование не нужно, а стоимость проверки близка к нулю.
ZK-роллап прикладывает к каждой партии доказательство с нулевым разглашением, и контракт меняет состояние только после его проверки. Подтверждение приходит заметно быстрее и не зависит от того, есть ли рядом наблюдатели. Проверка доказательства на основном слое стоит дёшево, но генерация требует специализированного оборудования у оператора — этот ресурс и есть основная статья расходов схемы.
Сопровождение различается не меньше. В оптимистичной модели усилия уходят в экономику оспаривания, мониторинг и защиту от цензуры на стороне секвенсора. В ZK — в схемы доказательства и их аудит: изменение логики требует переработки схемы, повторной проверки и аккуратной процедуры обновления, поэтому команде нужны собственные криптографические компетенции.
Схему выбирают по приоритету: скорость окончательного подтверждения и независимость от наблюдателей — в пользу ZK; совместимость с существующими контрактами и инструментами, предсказуемое сопровождение — в пользу оптимистичной модели. Опишите сценарий — вернёмся с оценкой и планом по обоим вариантам, с указанием узкого места и способа его закрыть.
Типичные сомнения: безопасность, вывод средств, поддержка
Перед стартом работ инженеры заказчика задают одни и те же вопросы: как подтверждается корректность вычислений, что произойдёт при отказе узла-упорядочивателя, как выводятся средства и кто останется с сетью после запуска. Ниже — короткие ответы по существу.
Развёрнутые схемы, адреса контрактов и матрицу прав разбираем на этапе проектирования — по каждому пункту у вас остаётся документ, а не устное обещание.
Как подтверждается корректность вычислений и безопасность расчётов?
В Optimistic-схеме результат принимается без немедленной проверки, но остаётся окно оспаривания: любой участник пересчитывает переход состояния и подаёт доказательство ошибки — подделанный пакет откатывается. В ZK-схеме к каждому пакету прикладывается доказательство корректности, и проверяющий контракт отбрасывает пакет, если вычисления не сходятся с корнем состояния.
Что будет при отказе узла-упорядочивателя?
Держим горячий резерв и переносим очередь транзакций — простой измеряется минутами. Если откажет вся группа, участники отправляют транзакции напрямую через контракт базового слоя: растёт задержка подтверждения, но состояние и средства остаются в сети.
Как устроен вывод средств?
Вывод двухшаговый: инициирование на втором слое, затем подтверждение в базовом после окна оспаривания. В ZK-варианте ожидание короче — корректность уже подтверждена доказательством. Быстрый вывод через сторонние мосты подключаем отдельно, с оценкой их рисков и лимитов.
Кто поддерживает сеть после запуска?
Передаём регламент: мониторинг узлов и очереди, ротация ключей, плановые обновления, разбор инцидентов. Первые недели дежурим вместе с вашей командой, дальше — по согласованному уровню технической поддержки с заданным временем реакции.
Обсудим задачу: подберём схему и вернёмся с оценкой
Чтобы оценка была предметной, а не вилкой на глаз, нам нужны вводные данные от заказчика. Именно они определяют выбор между оптимистической схемой и доказательствами валидности, конфигурацию узлов и объём сопутствующей инфраструктуры.
- Сценарии, под которые нужен второй слой: платежи, обмен, игровая логика или внутренний учёт — от этого зависят модель комиссий и требования к пропускной способности.
- Профиль нагрузки: ожидаемое число операций в пике, доля простых переводов, приемлемое для пользователя время подтверждения.
- Требования к выводу средств: какое время финального вывода считается нормальным, нужен ли быстрый мост и кто держит ликвидность на стороне основной сети.
- Модель управления: кто владеет контрактами, кто и как обновляет логику, какие роли нужны для пауз и аварийной остановки.
- Интеграции: кошельки, биржи, индексаторы, аналитика и существующие сервисы, к которым новый слой должен подключаться.
- Ограничения по срокам и этапам: дата, к которой нужен рабочий контур, и что допустимо вынести во вторую очередь.
- Требования к проверкам: нужен ли внешний аудит, какие отчёты, доступы и схему развёртывания ожидает ваша команда.
Получив эти данные, мы вернёмся с оценкой объёма, планом работ по этапам и сроками каждого — от прототипа контура до запуска и передачи в эксплуатацию. Опишите задачу в удобном формате: переписка, звонок или короткое техническое резюме.
