Масштабируемость: каналы, сайдчейны и rollups

Мы построили свой блокчейн, разобрали Bitcoin, EVM и Solana. Везде упирались в одно и то же: каждый узел проверяет каждую транзакцию, поэтому пропускная способность сети ограничена самым слабым узлом, который мы хотим сохранить. Этот урок про то, как из этого выбираются на практике, и почему индустрия сошлась именно на rollup-ах, а не на «давайте просто увеличим блок».

Трилемма: почему нельзя всё сразу

Начнём с рамки, которую придумал Виталик Бутерин и которой пользуются все.

Трилемма звучит так: децентрализация, безопасность, масштабируемость, выбери два. Разберём, что тут с чем конфликтует.

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

Отсюда видно, почему прямолинейные решения не работают. Увеличили блок в десять раз: пропускная способность выросла в десять раз, требования к узлу тоже, число независимых проверяющих упало. Именно этот спор в 2017 расколол Bitcoin на BTC и BCH, и он же объясняет, почему Solana с её высокой пропускной способностью платит требованиями к валидатору, о которых мы говорили в уроке про её архитектуру.

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

Что именно масштабируем

Полезно различать три разных ресурса, которые часто путают в одно слово «TPS».

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

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

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

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

Каналы состояния: считаем вдвоём, в цепь пишем дважды

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

Мы это уже видели: Lightning поверх Bitcoin устроен ровно так, на HTLC и таймлоках.

За что платим:

• Только заранее известные участники. Канал не годится для «заплатить незнакомцу один раз».
• Заперт капитал. Пока канал открыт, деньги в нём не работают больше нигде.
• Требуется присутствие. Если контрагент опубликует старое состояние, оспорить его нужно за отведённое окно. Отсюда сторожевые сервисы, и отсюда же неприятная правда: пользователь обязан быть онлайн или доверять тому, кто онлайн за него.

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

Сайдчейны: своя цепь, свой риск

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

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

Классический пример цены такого решения это взлом моста Ronin в 2022 на 624 миллиона долларов: атакующему хватило контроля над пятью подписями из девяти. Ни одна строчка Ethereum при этом не была сломана, сломалась схема доверия сбоку. Мосты мы отдельно разберём в уроке про MEV, оракулы и мосты.

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

Rollup: исполнение вне цепи, данные в цепи

Теперь главная конструкция современного масштабирования.

Rollup держится на двух опорах, и обе обязательны.

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

Вторая опора: корректность перехода доказуема на L1. Здесь и проходит развилка на два вида.

Optimistic: считаем честным, пока не оспорили

Оператор публикует новый корень состояния и заявляет: вот результат, я всё посчитал верно. Никто ничего не проверяет заранее. Открывается окно споров, обычно семь дней. Любой наблюдатель, который пересчитал и увидел ложь, публикует доказательство мошенничества, и ложный батч откатывается, а залог лжеца сгорает.

Проверять весь батч на L1 было бы дороже, чем выполнить его там же, поэтому спор делают интерактивным: стороны бинарным поиском делят спорный отрезок вычислений пополам, пока не упрутся в одну машинную инструкцию, и вот её L1 уже исполняет сама за копейки. У Arbitrum эта машина построена на WASM, у OP Stack на MIPS.

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

ZK: считаем ложным, пока не доказали

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

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

Сравнение

Ось	Optimistic	ZK
Что публикуется	данные плюс заявленный корень	данные, корень и доказательство
Кто проверяет	наблюдатели, задним числом	контракт L1, сразу
Финальность вывода	после окна споров, обычно 7 дней	после проверки доказательства
Требование к безопасности	хотя бы один честный наблюдатель онлайн	корректность криптографии и схемы
Стоимость оператора	низкая	доказательство стоит вычислений
Совместимость с EVM	проще, исполняем обычную EVM	сложнее, EVM надо выразить в схеме

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