Открытые проблемы и исследования

В 2024 году Виталик Бутерин опубликовал обновлённую roadmap Ethereum - и честно признал: половина пунктов помечена как «active research», без гарантий решения. Шардинг? Шесть лет работы, три смены стратегии, результат - EIP-4844 с blob'ами вместо обещанных 64 шардов. MEV? Flashbots создали MEV-Boost, но 90% блоков строятся двумя builder'ами - централизация вместо решения. Приватность? Tornado Cash под санкциями, а FHE в 10000 раз медленнее обычных вычислений. Формальная верификация? Стоит миллионы, а потери от багов - миллиарды. Блокчейн-индустрия стоит на пороге проблем, у которых пока нет ответов. Этот урок - карта территории, где заканчивается инженерия и начинается наука.

• **Ethereum Danksharding** - переход от execution sharding к data sharding после осознания, что atomic composability для 64 шардов - нерешаемая задача в текущем виде
• **Flashbots SUAVE** - попытка создать отдельный блокчейн для MEV-аукционов, потому что существующие решения (MEV-Boost) централизовали block building до 2-3 доминирующих builder'ов
• **Zama fhEVM** - Fully Homomorphic Encryption для EVM, позволяющий вычисления над зашифрованными данными, но с overhead ~1000x - на грани практической применимости

Предварительные знания

• Blockchain System Design (FAANG)

Sharding: нерешённые проблемы масштабирования

Sharding обещает горизонтальное масштабирование блокчейна - разделить сеть на параллельные «осколки», каждый обрабатывает свою порцию транзакций. Звучит просто: 64 шарда = 64x пропускная способность. Но на практике sharding порождает целое семейство проблем, многие из которых **до сих пор не имеют удовлетворительного решения**. Ethereum после шести лет исследований отказался от execution sharding в пользу danksharding - и даже этот путь полон открытых вопросов.

**Atomic composability** - фундаментальная проблема cross-shard транзакций. В монолитном блокчейне DeFi-протоколы свободно вызывают друг друга в одной транзакции: swap на Uniswap → deposit в Aave → borrow → hedge на dYdX. Всё атомарно - или выполняется целиком, или откатывается. В шардированной сети контракты живут в разных шардах. Cross-shard вызов - это **асинхронное сообщение**, не атомарная операция. Первая часть может выполниться, вторая - провалиться, и откатить первую уже нельзя.

**Single-Slot Finality (SSF)** - ещё одна открытая проблема. Сейчас Ethereum достигает finality за ~15 минут (2 эпохи). SSF обещает финальность за один слот (~12 сек), но требует, чтобы **все** ~1 млн валидаторов проголосовали за один слот. Текущие BLS-агрегации не справляются с таким объёмом подписей. Исследования идут в направлении **signature aggregation** (SNARK-based aggregation), **committee rotation** (подмножество валидаторов), и **orbit SSF** (Buterin, 2024) - но ни один подход пока не доказал работоспособность в production.

**State growth** - тихая катастрофа. Полная нода Ethereum хранит >300 ГБ state, и объём растёт с каждым блоком. Без решения - через 5-10 лет ноду смогут запускать только дата-центры, что убивает децентрализацию. Два направления исследований: **state expiry** (данные, к которым не обращались N эпох, «засыпают» и требуют witness для reactivation) и **statelessness** (ноды не хранят state, а получают witness в каждом блоке). Для statelessness нужны **Verkle trees** - замена Merkle Patricia Trie, дающая proof размером ~200 байт вместо ~4 КБ. Миграция Ethereum на Verkle trees - одна из самых масштабных инженерных задач в истории блокчейна.

**Verkle trees** - гибрид **Vec**tor commitments и Me**rkle** trees (отсюда название). Используют polynomial commitments (IPA или KZG) вместо хеширования, что радикально уменьшает размер proof. Ethereum планирует переход с MPT на Verkle, но миграция требует одновременного обновления формата state, proof generation и всех клиентов - процесс, который займёт несколько хардфорков.

MEV: экзистенциальная проблема и пути решения

**Maximal Extractable Value (MEV)** - прибыль, которую block producer может извлечь, переупорядочивая, вставляя или цензурируя транзакции в блоке. MEV - не баг, а **фундаментальное свойство** систем, где порядок транзакций имеет значение. Каждый незащищённый swap на DEX - возможность для sandwich-атаки. Каждая ликвидация - гонка ботов. По оценкам Flashbots, только на Ethereum извлечено >600M MEV с момента merge. Но проблема глубже: MEV угрожает **самим основам** блокчейна - децентрализации, censorship resistance и fairness.

Почему MEV - **экзистенциальная** проблема? Потому что она создаёт центростремительную силу. Чем больше MEV - тем выгоднее быть крупным валидатором с мощной инфраструктурой. Крупные игроки получают больше MEV → стейкают больше → получают ещё больше MEV. Результат: **централизация валидаторского набора**, что подрывает базовое обещание блокчейна. Кроме того, MEV-боты загрязняют mempool спамом - ~30% газа Ethereum тратится на failed MEV-транзакции.

**Proposer-Builder Separation (PBS)** - архитектурное решение: разделить роли того, кто **предлагает** блок (proposer), и того, кто его **строит** (builder). Proposer выбирает builder'а по ставке, не зная содержимого блока. Builder извлекает MEV, но конкурирует с другими builder'ами, отдавая большую часть прибыли proposer'у. Сейчас PBS работает через **MEV-Boost** (Flashbots) - внепротокольный механизм. Ethereum исследует **enshrined PBS** - встроить PBS в протокол, чтобы убрать зависимость от Flashbots. Но enshrined PBS порождает новые вопросы: как предотвратить builder centralization? Как обеспечить inclusion lists?

**MEV-Burn** - радикальное предложение (Justin Drake, 2023): вместо того чтобы перераспределять MEV, **сжигать** его. Builder платит bid за право построить блок, и этот bid не идёт proposer'у, а **уничтожается** - ETH навсегда выходит из обращения. Это устраняет стимул для proposer'ов выбирать builder'ов по MEV, делая систему более fair. Но MEV-burn не решает проблему censorship - builder всё ещё может исключать неугодные транзакции.

**Inclusion lists** - механизм censorship resistance для PBS. Proposer публикует список транзакций, которые builder **обязан** включить в блок. Если builder отказывается - блок невалиден. Это не позволяет builder'ам цензурировать транзакции (например, OFAC-санкционные адреса). Проблема: как определить размер inclusion list? Слишком маленький - бесполезен. Слишком большой - builder не может оптимизировать блок. Активная область исследований (FOCIL - Fork-Choice enforced Inclusion Lists).

Приватность и масштабируемость: невозможный компромисс?

Блокчейн по определению прозрачен: каждая транзакция, каждый balance, каждый вызов контракта - публичны. Для DeFi это означает, что **весь ваш финансовый профиль открыт**. Любой может видеть, сколько у вас ETH, какие позиции в Aave, когда вы продавали. Для enterprise-применений это стоп-фактор. Но добавление приватности в блокчейн - одна из самых сложных открытых проблем, потому что приватность **конфликтует** с масштабируемостью, compliance и самой моделью smart-контрактов.

ZK-proofs решают две совершенно разные задачи: **ZK для scaling** (ZK-rollups) доказывает корректность вычислений, не пересчитывая их на L1 - но сами данные остаются публичными. **ZK для privacy** (Zcash, Aztec) скрывает данные транзакций - отправитель, получатель, сумма - публикуя только proof валидности. Совместить оба свойства (и scaling, и privacy) - ключевая цель проектов вроде Aztec Network, но вычислительная стоимость ZK-proof для приватных вычислений на порядки выше, чем для публичных.

**MPC (Multi-Party Computation)** - альтернативный подход: несколько сторон совместно вычисляют функцию, при этом ни одна из них не видит входные данные других. Для DeFi это означает: несколько узлов совместно исполняют swap, каждый знает только свою часть. Проекты: **Partisia Blockchain** (MPC для smart-контрактов), **Nillion** (blind compute network). Trade-off: MPC требует коммуникации между участниками в процессе вычислений - O(n^2) сообщений для n участников, что ограничивает масштабируемость.

**Frontier:** ZK + FHE + MPC - конвергенция технологий. Представьте систему, где FHE обеспечивает encrypted state, ZK-proof подтверждает корректность вычислений над зашифрованными данными, а MPC распределяет ключ расшифровки. Каждая технология покрывает слабость другой. Проекты вроде **Sunscreen** и **Zama** уже исследуют такие гибриды. Но вычислительная стоимость комбинированных схем пока запредельна - это область, где аппаратное ускорение (GPU, FPGA, ASIC) станет определяющим фактором.

Формальные методы: математическая гарантия корректности

В 2016 году DAO hack потерял $60M из-за reentrancy bug - ошибки, которую мог бы поймать формальный анализ. В 2022 году Wormhole bridge потерял $320M из-за пропущенной проверки подписи. Ronin Bridge - $625M. **Суммарные потери от smart-contract багов превышают $5 миллиардов**. Формальные методы - математический инструментарий для **доказательства** корректности кода, не только тестирования. Но их применение в блокчейне сталкивается с уникальными вызовами: масштаб, стоимость и разрыв между академией и индустрией.

**Формальная верификация** - доказательство, что программа соответствует спецификации для **всех** возможных входов. Не 1000 тестов, не 1 миллион - а **математическая гарантия** для бесконечного множества. В контексте smart-контрактов: доказать, что «ни при каких условиях невозможно вывести больше токенов, чем было депонировано». Для этого нужны: 1. формальная спецификация - что программа должна делать 2. формальная модель - что программа реально делает, и (3) proof - что модель соответствует спецификации.

**TLA+ (Temporal Logic of Actions)** - язык спецификации Лесли Лампорта, применяемый для формальной верификации распределённых систем. Amazon использует TLA+ для DynamoDB и S3. В блокчейне: **Informal Systems** верифицировали Tendermint consensus на TLA+, обнаружив баг в алгоритме, пропущенный тысячами часов тестирования. **Apalache** - model checker для TLA+, автоматически проверяющий спецификации. Проблема: TLA+ описывает **модель** системы, а не сам код - нужен отдельный шаг доказательства, что код соответствует модели.

**Cost-benefit парадокс формальных методов:** верификация одного smart-контракта стоит 500K-5M и занимает 3-12 месяцев. Для стартапа, запускающего DeFi-протокол - неподъёмно. Но стоимость уязвимости - десятки и сотни миллионов. Решение исследуется в нескольких направлениях: **automated verification tools** (Certora Prover, Halmos) снижают стоимость до дней вместо месяцев; **verified libraries** (OpenZeppelin) позволяют строить из уже проверенных блоков; **certified compilers** (KEVM) гарантируют, что если исходный код верен - bytecode тоже верен.

**Model checking для консенсуса:** Tendermint, Ethereum Casper, Avalanche - все эти консенсус-протоколы имели баги, обнаруженные через формальный анализ. В 2019 году TLA+-спецификация Tendermint выявила edge case в алгоритме, где две трети валидаторов могли финализировать конфликтующие блоки при определённой последовательности timeout'ов. Баг существовал годы и не обнаруживался тестами. Формальная верификация консенсус-протоколов - одна из немногих областей, где cost-benefit однозначно положительный: цена ошибки - потеря всей сети.

Итоги

• **Sharding** обещает горизонтальное масштабирование, но atomic composability (cross-shard транзакции), single-slot finality и state growth (~300 ГБ) остаются нерешёнными. Ethereum сменил стратегию на danksharding, а переход на Verkle trees для statelessness - инженерная задача на годы
• **MEV** - не баг, а фундаментальное свойство систем, где порядок транзакций имеет значение. Encrypted mempools, PBS, SUAVE, fair ordering - каждый подход решает часть проблемы, но ни один не устраняет MEV целиком. MEV-burn предлагает сжигать, а не перераспределять извлечённую ценность
• **Приватность** конфликтует с масштабируемостью и compliance. ZK для privacy, FHE (вычисления над зашифрованными данными), MPC - три подхода с разными trade-offs. Privacy pools (Buterin, 2023) ищут компромисс между анонимностью и регуляторными требованиями
• Помните roadmap Бутерина с пометкой «active research»? **Формальные методы** - от static analysis до theorem proving - единственный путь к математическим гарантиям корректности, но стоимость верификации ($500K-5M) создаёт парадокс: дорого верифицировать, но ещё дороже не верифицировать при потерях в $5B+

Связанные темы

Открытые проблемы блокчейна связывают фундаментальные концепции, изученные ранее:

• Data Availability — DAS (Data Availability Sampling) - ключевой компонент danksharding, определяющий, как ноды проверяют доступность данных без полной загрузки
• MEV: Maximal Extractable Value — Фундамент понимания MEV-проблемы - sandwich-атаки, frontrunning, searchers и builders, которые MEV-mitigation стремится нейтрализовать
• Zero-Knowledge Proofs: основы — ZK-proofs лежат в основе как scaling (ZK-rollups), так и privacy (Zcash, Aztec) - два применения одной технологии с разными trade-offs
• Формальная верификация — Базовые концепции формальных методов - инварианты, pre/post-conditions, model checking - которые масштабируются до верификации целых протоколов

Вопросы для размышления

• Ethereum отказался от execution sharding в пользу danksharding (data sharding + L2 для execution). Означает ли это, что идея шардирования состояния и исполнения принципиально тупиковая - или просто требует технологий, которых пока нет (например, ZK для cross-shard composability)?
• MEV-burn предлагает сжигать MEV вместо перераспределения. Но если MEV сжигается - у searchers и builders нет стимула оптимизировать порядок транзакций. Может ли это привести к менее эффективному рынку? Есть ли «оптимальный» уровень MEV?
• FHE позволяет вычисления над зашифрованными данными, но с overhead ~1000x. Закон Мура предсказывает удвоение производительности каждые 2 года. Сколько «поколений Мура» нужно, чтобы FHE стал практичным? Или нужен фундаментально другой подход (FHE-ASIC, квантовые вычисления)?

Связанные уроки

• crypto-34-zkp-basics