Ethereum ETH: Что задумал Виталик Бутерин? Судьба L2 блокчейнов...

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

В 2026 году такого объяснения уже недостаточно. 3 февраля Виталик Бутерин написал, что исходное представление о роли L2 в Ethereum больше не имеет смысла и сети нужен новый путь. 23 марта Ethereum Foundation впервые примерно за пять лет официально обновила модель отношений L1 и L2. Летом Бутерин заговорил о «третьей итерации» Ethereum.

Роллапы при этом никто не хоронит. Утверждённого «Ethereum 3.0» не существует, никто не принимал решения переписать протокол целиком, а значительная часть идей ниже остаётся исследованием, а не планом.

Меняется представление о разделении труда внутри Ethereum: где должна выполняться тяжёлая работа, кто её выполняет, кому достаточно проверить результат и как это влияет на сборку блоков, состояние сети, аккаунты и консенсус. Одни элементы этой картины уже работают, другие готовят для ближайших форков, третьи существуют только в R&D.

💪 Не забудьте подписаться: Crypto Headlines

1. Что теперь происходит с L2?

Старая модель держалась на жёстком разделении ролей. L1 должен оставаться настолько лёгким, чтобы его можно было проверять на обычном железе. Массовое исполнение уходит на роллапы, а сами роллапы со временем становятся trust-minimized — то есть сводят к минимуму необходимость доверять команде: доводят системы доказательств, убирают аварийные рычаги и превращаются в надёжные расширения одной экосистемы.

Осторожность была понятна. Пока каждый полноценный узел самостоятельно проверяет работу сети, увеличение нагрузки на L1 повышает требования ко всем, кто хочет проверять Ethereum независимо.

За последние годы обе части этой модели разошлись с ожиданиями.

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

Поэтому тезис «L1 почти нельзя масштабировать, всё исполнение нужно уносить наверх» перестал выглядеть безальтернативным.

С роллапами всё тоже оказалось сложнее. К концу августа 2026 года крупнейшие универсальные L2 не дошли до Stage 2 — стадии, где возможности команды и советов безопасности вмешиваться в работу сети сведены к минимуму. Централизованное секвенирование остаётся типичным: секвенсор определяет порядок транзакций и контролирует важную часть работы L2.

Не исчезла и фрагментация. Пользователь с активами в четырёх сетях фактически живёт в четырёх средах исполнения — со своими мостами, сроками вывода и допущениями безопасности.

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

Некоторые L2 к тому же сознательно хотят большей автономии: собственную экономику, правила исполнения и решения об обновлениях. Их интересы уже не укладываются в модель, где каждый роллап должен со временем стать чем-то вроде «фирменного шарда» Ethereum.

Поэтому меняется не сам подход с L2, а ожидание, что все роллапы в итоге придут к одной архитектуре.

На одном краю спектра — более тесная интеграция с Ethereum. Один путь — переход к Stage 2. Другой — native rollups, где проверку доказательств хотят перенести непосредственно в протокол Ethereum. Сегодня каждый роллап приносит на L1 собственный контракт-верификатор — программу, которая проверяет корректность его доказательств, — со своей реализацией и риском ошибок. Чем больше такой проверки Ethereum сможет выполнять по общим правилам, тем меньше дополнительных допущений понадобится каждому L2.

В перспективе сюда же относится синхронная композируемость: взаимодействие между разными средами должно стать ближе к взаимодействию приложений внутри одной сети.

Рядом — based rollups. В них порядок транзакций в той или иной форме наследуется от L1, вместо полной зависимости от собственного секвенсора. Это один из ответов на централизованное секвенирование, но пока исследуемый подход со своими компромиссами по задержке и экономике.

На другом краю — специализация: приватность, отдельные классы приложений, нестандартные виртуальные машины, сверхнизкая задержка, институциональные среды с ограниченным доступом. Такие сети вообще не обязаны быть «Ethereum, только дешевле».

Идею дифференциации публично поддержали и в Base, и в Optimism. L2 никуда не исчезают. Исчезает ожидание, что все они должны стать одной и той же разновидностью базового слоя со скидкой.

Bybit Card все еще доступна гражданам СНГ, без ограничений: Как получить

2. Почему Ethereum снова может масштабироваться без L2 блокчейнов

Если прежняя стратегия требовала очень осторожно расширять базовый слой, почему в 2026 году подход меняется?

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

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

Самый заметный пример — gas limit.

Сейчас один блок Ethereum может содержать операции с суммарным расходом до 60 млн gas. Gas здесь — не деньги и не количество транзакций, а условная мера вычислительной работы: простой перевод и сложный вызов смарт-контракта расходуют разное количество gas. Поэтому gas limit можно грубо представить как вычислительный бюджет одного блока.

На встрече участников разработки протокола Soldøgn более ста разработчиков и исследователей сошлись на ориентире около 200 млн gas на блок после Glamsterdam.

Это не означает, что после форка сеть автоматически переключится с 60 млн на 200 млн. Лимит меняют валидаторы. Кроме того, одновременно пересматривается стоимость отдельных операций в gas, поэтому будущие 200 млн нельзя буквально понимать как «в 3,3 раза больше сегодняшнего Ethereum».

Glamsterdam нацелен на четвёртый квартал 2026 года, но дата запуска в mainnet пока не объявлена. 20 августа на его правила перешёл первый публичный тестнет — отдельная экспериментальная сеть, где обновление проверяют до запуска в основной сети.

Почему нельзя просто увеличить вычислительный бюджет блока уже сейчас? Более тяжёлый блок нужно успеть выполнить, распространить по сети и проверить за ограниченное время. Чем выше нагрузка, тем выше требования к железу и соединению. Есть и долгосрочная проблема: дешёвая операция сегодня может создать запись, которую полным узлам придётся хранить годами.

Поэтому Glamsterdam — это не просто попытка поднять одно число. Форк готовит несколько изменений, которые должны сделать более тяжёлые блоки переносимыми для сети.

Первое — заранее сообщать узлу, к каким данным обратится блок. Для этого нужны Block-Level Access Lists (BAL) — по сути, список участков состояния, которые блок собирается читать или менять. Если две операции не затрагивают одни и те же данные, клиент заранее видит, что часть работы можно выполнять параллельно. Та же информация помогает при синхронизации и восстановлении состояния.

BAL сами по себе не превращают Ethereum в полностью параллельную систему. Они дают клиентам информацию, на основе которой такую обработку можно строить.

Второе изменение касается цены долговременного хранения. По оценкам из обсуждений разработчиков протокола, состояние Ethereum сейчас растёт примерно на 100 ГБ в год. EIP-8037 предлагает отдельно учитывать gas за создание состояния, чтобы разовое вычисление и запись, способная годами лежать на дисках полных узлов, не оплачивались по одной логике. Модель предложения откалибрована примерно на 120 ГиБ нового состояния в год при заложенных в неё допущениях.

Третий элемент — ePBS. Чтобы понять его роль, достаточно знать одну вещь: валидатор, которому выпало предложить блок, часто не собирает его сам. Этим занимаются профессиональные builders — участники, которые специализируются на формировании содержимого блока. ePBS встраивает это разделение ролей непосредственно в протокол.

Для масштабирования это важно из-за времени. Сборка, доставка и проверка большого блока должны уложиться в жёсткое расписание. ePBS меняет этот критический путь и должен дать больше времени для работы с тяжёлыми блоками и большими объёмами данных.

Glamsterdam важен не тем, что «даст 200 млн gas», а тем, что должен создать условия, при которых сеть сможет безопасно двигаться к более высокому лимиту.

3. Кто будет строить блоки — и кто сможет сказать «эту транзакцию не включаем»

У ePBS есть и другая сторона. Если профессиональный builder собирает содержимое блока, кто помешает ему просто игнорировать неугодные транзакции?

Сегодня builders передают готовые блоки валидаторам через внешние сервисы — релеи. Они умеют эффективнее упаковывать транзакции и извлекать MEV — дополнительную стоимость за счёт порядка и включения транзакций. Валидатору выгодно пользоваться их блоками. Но если крупных builders и релеев мало, вместе с эффективностью концентрируется и влияние на то, какие транзакции вообще попадут в блок.

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

После этого остаётся вопрос цензуры. Для него разрабатывается FOCIL — механизм списков обязательного включения. Комитеты валидаторов публикуют перечни транзакций, которые builder должен учитывать при формировании блока. Это защита от ситуации, когда публично видимую транзакцию можно просто сделать вид, что не заметили.

Для Hegotá FOCIL имеет статус SFI — то есть запланирован к включению в этот форк.

FOCIL не устраняет MEV и не решает проблему приватных потоков ордеров, которые вообще не появляются в публичном мемпуле — общей очереди транзакций, видимых сети и ожидающих включения в блок. Не затрагивает он и централизованных секвенсоров L2.

За ePBS и FOCIL виден более широкий подход: тяжёлую специализированную работу можно отдавать профессиональным участникам, если остальные сохраняют возможность независимо проверить результат и достаточно широко влиять на включение транзакций.

Та же логика лежит в основе следующего, гораздо более глубокого изменения.

4. Проверить дешевле, чем повторить

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

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

Целевая модель сильнее разделяет выполнение и проверку. Тяжёлое вычисление выполняет prover — специализированный оператор с мощным оборудованием. Он исполняет блок и создаёт криптографическое доказательство правильности результата. Остальным участникам достаточно проверить это компактное доказательство, что намного дешевле полного переисполнения.

Ethereum пытается отвязать стоимость проверки блока от стоимости его исполнения.

Если такая модель заработает на L1, блок сможет содержать значительно больше работы, не заставляя каждую проверяющую ноду становиться столь же мощной, как машина prover'а.

При этом ориентир около 200 млн gas после Glamsterdam относится к более близкому горизонту и опирается прежде всего на ePBS, BAL и новую тарификацию состояния. Обязательная проверка L1 через доказательства остаётся более дальним направлением R&D.

У proof-based модели есть собственные ограничения. Доказательство подтверждает правильность вычисления, но не делает данные блока доступными — значит, пропускная способность и доступность данных никуда не исчезают. Производство доказательств требует серьёзных ресурсов и само может сконцентрироваться у небольшого числа операторов.

Есть и системный риск. Разнообразие клиентов сегодня защищает Ethereum от бага в одной реализации. Но если разные клиенты проверяют доказательства, построенные по одной и той же ошибочной схеме, этого уже недостаточно. Поэтому нужны несколько независимых систем доказательств и запасной путь проверки.

Наконец, сегодняшние результаты real-time proving показывают инженерную возможность, а не готовность протокола. Между «мы умеем доказать такой блок за нужное время» и «Ethereum проверяет блоки именно так» остаются спецификация, независимые реализации, аудит и длительное тестирование.

До сих пор доказательства прежде всего помогали роллапам убеждать Ethereum, что вычисления на L2 выполнены правильно. Теперь та же технология рассматривается как возможный базовый механизм проверки самого L1. Если этот путь дойдёт до mainnet, граница между тем, что Ethereum обязан вычислять сам, и тем, что ему достаточно лишь проверить, станет совсем другой.

5. Lean Ethereum: когда исследование начинает выглядеть как новая архитектура

Lean Ethereum появился не в 2026 году. Джастин Дрейк представил его ещё в 2025-м как программу переосмысления нижних слоёв протокола. В 2026 году эту линию связали с ближайшими форками через исследовательскую карту Strawmap, а Бутерин начал использовать Lean как рамку для «третьей итерации» Ethereum.

Справка: Strawmap — живой исследовательский черновик, который связывает ближайшие изменения протокола с более дальними направлениями R&D. Это не обязательное расписание и не единый утверждённый план.

За Lean уже стоят не только презентации. Есть экспериментальные сети devnet, где обкатывают ещё не готовые к mainnet решения, несколько независимых клиентских реализаций, прототипы новых схем подписей, рекурсивные доказательства блоков и работа над формальной верификацией — математической проверкой ключевых свойств протокола.

Самое радикальное направление Дрейк в феврале описал как в значительной степени переписывание уровня консенсуса — той части Ethereum, которая координирует валидаторов, определяет каноническую цепочку и отвечает за окончательность блоков.

Сегодня валидаторы используют BLS-подписи. Они удобны тем, что множество подписей можно объединять, но не считаются устойчивыми к будущим квантовым компьютерам. Большой набор валидаторов также означает больше состояния и больше сетевого обмена в каждом временном слоте. Финальность — момент, после которого блок считается окончательно закреплённым, — сейчас достигается за две эпохи, то есть за минуты.

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

Здесь снова работает идея из предыдущей главы: если сеть умеет дёшево проверять компактное доказательство большой работы, стоимость поддержки огромного количества участников уже не обязана расти почти линейно вместе с их числом.

Насколько далеко можно довести эту логику, показывает исследовательский проект Extremely Lean Chain. В нём рассматривается архитектура примерно с шестью байтами состояния на одного валидатора, ежедневными STARK-доказательствами балансов и теоретической возможностью поддерживать миллионы валидаторов.

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

Статус всей программы остаётся исследовательским. Ничто из этого не принято как замена нынешнего консенсусного слоя Ethereum — Beacon Chain. Даже внутри Lean нет одного согласованного конечного дизайна. Devnet тоже не следует путать с mainnet: до запуска понадобятся отдельная спецификация, независимые реализации и длительное тестирование.

Lean уже нельзя назвать набором идей на бумаге — есть код, прототипы и экспериментальные сети. Но утверждённым планом Ethereum он от этого не становится.

6. Самая тяжёлая проблема — память Ethereum

В январе Бутерин сформулировал полезную иерархию: проще всего масштабировать вычисление, сложнее — данные, а сложнее всего — состояние.

Вычисление разовое: блок исполнили — работа закончилась. Большой объём данных тоже не обязательно хранить одинаковым образом вечно: их доступность можно распределять и проверять выборкой.

С состоянием всё иначе. Состояние Ethereum — это актуальные балансы, код смарт-контрактов и хранимые ими данные. Отдельная запись может оставаться нужной неопределённо долго. Пока она актуальна, полные узлы должны её хранить и уметь предоставить.

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

За последние два года изменилось и представление о том, как решать проблему архитектурно.

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

Отодвинулась и идея одного универсального механизма устаревания состояния. Вместо единого правила для любых данных исследуется архитектура, где разные типы состояния могут жить по разным правилам.

Некоторым данным не нужны все возможности обычного хранилища смарт-контракта. Одноразовой метке, например, достаточно ответить на вопрос: использовали её уже или нет. Другой пример — логика UTXO, знакомая по Bitcoin: записи создаются и затем тратятся, а не бесконечно обновляются. Если данным достаточно более ограниченной модели, сеть потенциально может хранить их дешевле.

В личном представлении Бутерина о возможном Ethereum примерно к 2030 году остаётся сравнительно небольшой объём «старого» полностью динамического состояния и на порядки больший объём состояния с более ограниченными правилами. Названные им цифры — иллюстрация идеи, а не план сети.

Ethereum постепенно уходит от представления, что любой тип данных должен жить внутри одной универсальной модели памяти. Если данным нужны разные свойства, возможно, и храниться они должны по-разному.

7. Аккаунты, приватность и квантовый дедлайн

Изменения в кошельках и подписях обычно обсуждают в контексте UX. В 2026 году у них появился более широкий архитектурный смысл.

Отправная точка уже работает в mainnet. EIP-7702 позволяет обычному адресу делегировать выполнение коду смарт-аккаунта, сохраняя сам адрес. Делегирование действует, пока владелец его не изменит или не отзовёт.

Один из возможных следующих шагов — нативная абстракция аккаунта через Frame Transactions (EIP-8141). По состоянию на 28 августа предложение имеет для Hegotá статус SFI, то есть запланировано к включению, хотя дата самого форка в mainnet ещё не определена.

Справка: account abstraction означает, что правила авторизации транзакций и оплаты газа можно задавать программируемой логикой аккаунта, а не только жёстко заданной схемой протокола.

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

Квантовая устойчивость поэтому перестала быть темой из очень далёкого будущего. Уязвимых поверхностей несколько: подписи обычных аккаунтов, BLS-подписи в консенсусе, криптографические конструкции доступности данных и отдельные части систем доказательств. Одним форком всё это не заменить; мигрировать придётся не только протоколу, но и огромному слою инфраструктуры и пользовательских активов.

Третья линия — приватность. Её всё меньше рассматривают как функцию отдельного приложения и всё чаще — как свойство, которое приходится продумывать на нескольких уровнях сразу. Что пользователь записывает и читает? Что видит RPC-провайдер — сервер, через который кошелёк запрашивает данные у сети? Можно ли связать запрос с IP-адресом? Какие адреса кошелёк ненамеренно связывает между собой?

Особенно легко недооценить приватность чтения. Иногда для раскрытия дополнительной информации не нужна никакая транзакция: обычный запрос баланса через публичный RPC уже может связать адрес с сетевыми метаданными пользователя.

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

Ethereum не обещал приватность по умолчанию и не объявлял единого квантового форка. Изменилось другое: обе задачи уже влияют на сегодняшние архитектурные решения — вплоть до выбора будущей структуры хранения состояния.

8. Как далеко это может зайти — и почему Ethereum потом хочет остановиться

Самая громкая идея всей картины касается EVM — и одновременно относится к самому далёкому горизонту.

Бутерин описывал возможный Ethereum, в котором самый нижний технический слой исполнения становится проще и удобнее для криптографических доказательств. В качестве такого слоя он упоминал наборы инструкций RISC-V или leanISA.

Нынешняя EVM в такой архитектуре не обязательно исчезает. Она может сохраниться сверху как слой совместимости: привычные Ethereum-контракты работают в знакомой среде, но под ней находится более простой механизм исполнения, к которому EVM компилируется.

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

Это личное представление Бутерина, а не дорожная карта. Он сам относит сценарий к далёкому будущему и считает, что подробно развивать его даже в Strawmap пока рано. На ближайшем горизонте направление фактически обратное: zkEVM первого типа должна максимально сохранять нынешние правила EVM, чтобы доказательства можно было использовать без замены существующей модели исполнения. LeanVM при этом не является новой прикладной виртуальной машиной для приложений.

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

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

Бутерин называет этот подход soft lean-and-done — условно, «упростить, а затем почти перестать менять». Сначала протокол предлагается упростить, сделать его ключевые свойства пригоднее для формальной верификации и позволить клиентам сильнее специализироваться. После основного цикла перестройки изменения должны в основном свестись к исправлениям безопасности и небольшим улучшениям с высокой ценностью.

В долгосрочном представлении Бутерина Ethereum мог бы приблизиться по стабильности протокола к Bitcoin. Получается почти парадоксальная конструкция: замена консенсуса, архитектуры проверки, структуры состояния, модели аккаунтов и, возможно, нижнего слоя исполнения рассматривается как путь к системе, которую затем можно будет почти не трогать.

Но и это долгосрочная философия конкретного исследователя, а не обязательство Ethereum.

Ближайший календарь хорошо показывает разницу между большими архитектурными идеями и тем, как осторожно они доходят до mainnet. В феврале Glamsterdam ожидали в первой половине 2026 года, а Hegotá — позже в том же году. В апреле стало ясно, что ePBS сложнее, чем предполагалось. К августу Glamsterdam нацелен уже на четвёртый квартал 2026-го, а Hegotá сдвинулся на 2027 год. Первый публичный тестнет Glamsterdam появился только в августе.

По состоянию на 28 августа и FOCIL, и Frame Transactions имеют для Hegotá статус SFI — запланированы к включению. Десятки других идей находятся на более ранних стадиях или остаются исследованием. У Lean нет ни обязывающего расписания, ни одного форка, в который должна войти вся программа.

Чем дальше горизонт, тем смелее архитектура; чем ближе основная сеть, тем осторожнее процесс. Это, пожалуй, самый полезный принцип для чтения новостей об Ethereum в ближайшие годы.

Если основные исследовательские линии в итоге сойдутся, Ethereum может выглядеть так: значительно более мощный L1; тяжёлые вычисления выполняют специализированные участники, а независимая проверка остаётся дешёвой; профессиональная сборка блоков сохраняется, но возможность влиять на включение транзакций распределяется шире; разные типы состояния хранятся по разным правилам; аккаунты постепенно переводятся на новую криптографию; консенсус становится проще, быстрее и устойчивее к квантовым атакам.

L2 при этом не исчезают. Часть теснее встраивается в Ethereum, другая сильнее уходит в специализацию.

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

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

если Ethereum действительно станет намного быстрее, дешевле и технологически сильнее — означает ли это автоматически, что экономически сильнее станет ETH?

👇 Ознакомьтесь с нашим материалом для Premium-читателей.