Disclaimer: обычно я пишу про крипту почти на ежедневной основе в канале миллениалы делают веб3, но когда удается найти что-то особенно интересное, получается лонгрид.

Вопрос масштабирования блокчейна волнует нас с вами давно и постоянно. Если попробовать порассуждать с нуля, вот нужно сделать так чтобы пропускная способность блокчейна была лучше.

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

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

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

Есть три вида лейер 2 скейлинга: state channels, plasma, rollups.

State channels — удобный инструмент для п2п рекуррентных платежей.

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

Ты кладешь в смарт контракт 10х и лочишь их там. после первого питч-дека ты попдисываешь офф-чейн сообщение "х" и отправляешь мне (в каком-то абстрактном смысле выписываешь чек).

После второго питч-дека ты подписываешь офф-чейн сообщение "2х" и отправляешь мне. после 6 питч-деков ты понимаешь, что больше питч-деков тебе не нужно, последнее офф-чейн сообщение от тебя было "6х", я публикую его он-чейн (только одно последнее) и оборачиваю в свою подпись. Смарт-контракт проверяет, что он-чейн сообщение "6х" было подписано сначала тобой а потом мной, отправляет 6х мне и вовзращает 4х тебе. Если по какой-то причине я не опубликую никакое сообщение он-чейн, то ты можешь инициировать withdrawal period (определенное количество дней) и если я никак не отреагирую, все 10х вернутся тебе. 

State channels могут процессить платежи в две стороны (то есть я тебе питч-деки, а ты мне конфеты и потом взаимозачет), включать больше чем две стороны.

Из ограничений: смарт-контракт не может взаимодействовать с внешним лицом, которое не было изначально заявлено как участник, state channel не может процессить платежи без конкретного оунера активов (например, DEXs), а также необходимо лочить капитал вначале (если операция достаточно сложная, скажем, строим дом, придется лочить много капитала).

Plasma

Смарт-контракт управляет plasma chain, chain присваивает ID каждому активу, который в сети размещается. У сети есть оператор (может быть централищованный, мультисиг, PoS, etc). Есть интервалы от 15 секунд до часа, каждый интервал оператор собирает все офф-чейн транзакции, полученные за период, и генерирует Merkle Tree, где под индексом х назодится транзакция с ID х, если транзакции с таким ID нет, ветка остается пустой. Он-чейн публикуется корень дерева, а ветки рассылаются владельцам активов. Чтобы получить свой актив, владелец актива публикует последнюю ветку, в которой он этот актив получил, начинается challenging period, когда любой может доказать или что "владелец актива" им не владеет на момент запроса тразнакции, или что после запроса транзакции актив был отправлен еще раз. Если во время challenging period транзакцию никто не обжалует, владелец актива может получить свой актив.

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

Также как и state channels плазма не может процессить платежи без конкретного оунера активов (например, DEXs). Также плазма не работает для кейсов, когда стейт актива можно поменять независимо от оунера актива (eg. account-based systems, where you can increase someone's balance without their consent).

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

Нужно что-то другое... нужны роллапы!

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

Роллапы — более гибридная система: они выносят офф-чейн вычисления и хранение state, но часть даты они оставляют он-чейн. Также роллапы используют всевозможную магию математики для сжатия данных где это возможно (заменяя пачки данных на вычисления с меньшим весом). Для сравнения перевести ERC-20 токен на эфире стоит 45 000 газа, а на rollup layer 2 — 300 газа. Роллапы проивзодят абсолютно все операции он-чейн, что делает это решение наиболее секьюрным. Почему комьюнити ethereum активно работает над роллапами — потому что они более универсальны: в целом на роллапе можно запустить EVM (то есть перенести туда дапп без какого-либо дополнительного кода)

Как именно работают роллапы

Так как мы все равно имеем дело с Merkle tree логично что у нас есть state root (само дерево хранится офф-чейн, но при необходимости его можно пересчитать он-чейн). любой может опубликовать новый бэтч транзакций с предыдущим стейт рут и новым стейт рут. если стейт руты метчатся, то назначается новый стейт рут. Также роллап может работать с внешними переменными (теми что не влияют на стейт рут дерева). в этом случае транзакция которая подтверждает новый бэтч, должна также вызвать смарт-контракт, который совершит необходимые операции со внешними переменными.

Возникает вопрос: а как понять, что новый стейт рут верный, если его может просто записать любой желающий?

Здесь возникает два вида роллапов: zk-rollups & optimistic rollups

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

zk-rollups — каждый бэтч включает криптографическое доказательство -- ZK-SNARK (с использованием PLONK protocol), который доказывает что новый стейт рут корректен для этого бэтча. 

Сравнение двух роллапов:

1/ цена бэтча
оптимистик — 40к газа 
zk — 500к газа (вычисление ZK-SNARK достаточно затратно)

2/ Withdrawal period
оптимистик — до недели (ждем пока могут найти ошибку и обжаловать (= опубликовать он-чейн доказательство некорректности
zk — считай моментально

3/ Сложность технологий
оптимистик — легко и понятно 
zk — ZK-SNARK новая сложная штука мы пока не очень хорошо умеем с ней работать

4/ Универсальность
оптимистик — очень близко к мейннету эфира
zk — пока не очень (опять виноваты снарки) но над этим работают, например, выдумали более математический язык Cairo

5/ Стоимость газа за транзакцию 
оптимистик — выше
zk — ниже (так как не меняется стейт рут)

6/ стоимость офф-чейн вычисления
оптимистик — дешевле
zk — дороже (опять же потому что снарки вычислительно-обременительные)

Рискованность затеи

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

Как происходит сжатие данных 

Чтобы перевести один эфир: на эфире — 110 байт, на роллапе — 12 байт. 

На чем экономим

1/ нам не нужен nonce — мы можем получить его из предыдущего стейт рута. 

2/ адрес из 20 символов можно заменить на более короткий индекс из 4 символов (добавляя к дереву поддерево которое будет хранить индексы)

3/ можно агрегировать много подписей в один блок и валидировать разом

4/ можно хранить значения в экспоненциальном виде (1-3 символа)

5/ можно фиксировать цену на газ (или использовать ограниченное количество опций) или унести оплату газа из протокола

6/ можно установить фиксировнное количество газа или потолок количества газа на бэтч

7/ в случае с zk верификация транзакции может осуществляться полностью офф-чейн, так как не влияет на стейт рут

В оптимистик роллапе при желании приватности каждую на каждую транзакцию придется отдельно применять зкСНАРК (500 байт), в то время как в зк-роллапе зкСНАРК применяется на весь бэтч сразу.

Со всеми этими трюками, эффект роллапа достигает 100х относительно сети эфира.

Кто может предлагать бэтчи транзакций

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

Дальше подходы разнятся

1/ полная анархия: кто угодно предлагает в любое время. возникает проблема параллельных бэтчей и впустую расходуемых ресурсов.

2/ sequencer подтверждает бэтчи. за исключением withdrawals (там другой механизм) -- но это централизовано 

3/ Sequencer auction: sequencer выбирается каждый период заново (например так работает MEV аукцион)

4/ Random selection from PoS set: все желающие быть секвенсером стейкают определенное количество токена сети и каждый бэтч секвенсер выбирается заново (недостаток -- появляется барьер входа в виде необзодимости лочить капитал)

5/ DPoS voting: секвенсер выбирается аукцином, но если люди им недовольны -- имеют право провести голосование за то чтоб выбрать нового (снова аукционом)

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

Какие сложности пока есть в роллапах

Это непривычно для юзеров, а значит кошельки и прочий масс-маркет не очень спешат добавлять роллапы и объяснять юзерам зачем это нужно.

Cross-rollup transactions.

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

Можно ли скрестить плазму и роллапы чтобы вышло что-то дельное заточенное под узкие юзкейсы?

Обещание pre-confirmation транзакции для лучшего юзер экспириенса, когда секвенсер обещает заранее включить транзакцию в след бэтч и страдает экономически если транзакция не валидна и в итоге он ее не может включить.

Что делать если назначенный секвенсер внезапно пропал?

Создание zkEVM (ну тут вот только был релиз полигона, и scroll тоже работает в ту же сторону).

Больше о веб3 простыми словами в канале миллениалы делают веб3