Fusaka - Все о новом Обновлении Ethereum
План:
- Что произошло 3.12.2025?
- Структура Ethereum
- Зачем вообще понадобилось это обновление?
- Ключевая проблема
- Решение: что такое PeerDAS?
- Что теперь меняется в Ethereum благодаря PeerDAS
- Про Osaka
- Про Fulu
- Что это дает обычным пользователям?
- Что это дает разработчикам?
- Что Fusaka значит для будущего Ethereum?
- Эпилог
Автор Статьи - https://t.me/code_vartcall
1. Что произошло 3.12.2025?
Представь себе обычный день для сети Ethereum.
Есть валидаторы, которые включают свои ноды.
Есть L2-сети - Arbitrum, Optimism, Base - которые крутятся поверх Ethereum и постоянно кидают в него данные.
Есть пользователи, которые просто хотят:
3. поиграть в какую-то on-chain игру,
4. сделать swap через Telegram-бота.
Под капотом всё это упирается в одну простую вещь: Ethereum обязан хранить и делать доступными данные, которые публикуют L2.
И с каждым месяцем этих данных становилось всё больше. Нагрузка росла.
Разработчики уже много лет говорили:
"Мы не можем бесконечно просто увеличивать лимиты. Нам нужна новая архитектура работы с данными. Нам нужен следующий шаг после Dencun."
Этот шаг и получил кодовое имя Fusaka.
Что такое Fusaka на человеческом языке?
Формально, Fusaka - сетевое обновление Ethereum, которое включает:
- Osaka - изменения на уровне исполнения (Execution Layer).
- Fulu - изменения на уровне консенсуса (Consensus Layer).
То есть 3.12.2025 - не "форк, где сеть разделилась", а момент, когда все основные клиенты Ethereum (Geth, Nethermind, Prysm, Lighthouse и т.д.) получили новые правила игры и дружно на них переключились.
Снаружи для пользователя это выглядело скучно: кошельки работали как обычно, блоки шли, газ платился. Но внутри протокола случилось важное: Ethereum научился по-новому работать с данными L2.
Момент активации
У каждого крупного обновления Ethereum есть определённый слот/высота блока, на котором оно активируется.
- скачали новую версию клиента,
- проверили, что код компилируется,
- протестировали в тестнетах,
- подготовились к апдейту.
Всё было заранее заложено в код:
"когда дойдём до такого-то блока - начинаем жить по новым правилам".
3 декабря 2025 года сеть дошла до этого блока.
старые клиенты, которые не обновились, просто больше не понимали новые правила, а обновлённые клиенты продолжили цепочку уже с активированным Fusaka.
Никакого драматичного раскола, как когда-то у Ethereum / Ethereum Classic, не произошло. Это был плавный переход.
Что именно поменялось концептуально в этот момент
- принимал от L2 данные в формате, заложенном после EIP-4844 (blobs);
- вынужден был полагаться на модель, где данные достаточно “толстые”, и нагрузка на узлы росла.
Появился новый формат и логика обработки данных, которые публикуют роллапы.
Execution Layer научился работать с частично кодированными сегментами данных,
Изменилась внутренняя структура того, как данные L2 связаны с блоками L1:
это всё ещё "данные на Ethereum", но уже с ориентацией на sampling, а не "скачать всё".
В протокол вошёл механизм Peer Data Availability Sampling. Валидаторы получили новые обязанности: не просто подтверждать блоки, но и случайно проверять маленькие куски данных, связанных с этими блоками.
Логика "что считать доступными данными" изменилась: теперь не требуется, чтобы каждый валидатор скачивал весь "пакет данных" целиком. То есть в момент активации Fusaka у сети как будто переключили режим работы с данными: с "тупо всё скачиваем" на "умно сэмплируем и доказываем доступность".
Что не изменилось?
- Балансы пользователей не менялись.
- Адреса, контракты, токены - остались теми же.
- Никаких "старый Ethereum / новый Ethereum" не появилось.
- Ни у кого не сгорели монеты, не нужно было мигрировать.
Обновление происходило на уровне протокола, а не на уровне UX.
Для обычного пользователя 3 декабря 2025 года был днём, когда:
Всё работало как обычно, но постепенно - в последующие дни/недели - комиссии в L2 начали становиться дешевле, а разработчики радостно говорили: "Всё, PeerDAS в деле, можно думать о следующем шаге - Danksharding".
2) Структура Ethereum
Fusaka - обновление, которое затрагивает оба уровня Ethereum:
И пока мы не поймем, что эти уровни разные, мы никогда не поймёт, что именно изменило Fusaka.
Про уровни и Ethereum под капотом 👇
Представь Ethereum как огромный город. В этом городе есть миллионы жителей: пользователи, биржи, DeFi-протоколы, смарт-контракты, игры, кошельки, роботы-арбитражники.
Все они живут и действуют внутри одной большой системы.
Но важно понять главное: весь этот город работает не как одно монолитное существо. У него есть две большие части, два "органа", два "уровня", которые отвечают за разные вещи. Именно эти уровни определяют, как Ethereum думает и как Ethereum действует.
Часть первая: Execution Layer - "тело" Ethereum
Это уровень, который выполняет действия.
Если продолжать метафору с городом:
- здесь строятся дома,
- заключаются сделки,
- подписываются контракты,
- происходят переводы средств,
- запускаются программы (смарт-контракты).
На Execution Layer Ethereum буквально считает, обрабатывает, выполняет.
Если пользователь делает swap или отправляет ETH - именно Execution Layer решает:
- достаточно ли средств,
- какая логика контракта,
- что случится с балансами,
- какие данные должны быть записаны в блок.
Это - "машина исполнения", EVM, логика транзакций.
Часть вторая: Consensus Layer - "мозг" Ethereum
Это уже совсем другая часть системы.
Если Execution Layer - то, что происходит, то Consensus Layer - то, как сеть договаривается, что произошло на самом деле.
- валидаторы, которые ставят свои 32 ETH,
- Proof-of-Stake,
- финализация блоков,
- правила честности,
- выбор того, какой блок является правильным.
Этот уровень не исполняет код. Он не считает смарт-контракты, не переводит токены. Он решает куда более важную вещь:
"Можем ли мы все согласиться, что именно этот блок - истина?"
Consensus Layer - "судья", "мозг", "законодатель", который гарантирует, что никто не может подделать историю транзакций.
Как эти два уровня работают вместе - история в одном абзаце
Каждый блок Ethereum - как письмо, которое нужно отправить:
Execution Layer пишет содержание письма: кто кому отправил деньги, какие смарт-контракты выполнились, какой код запустился.
Consensus Layer подписывает письмо и отправляет по почте, подтверждая, что оно легитимно, а не подделано.
Если бы существовал только Execution Layer - кто проверял бы, что данные честные?
Если бы существовал только Consensus Layer - что вообще подтверждать, если никто не выполняет логику?
Они существуют только вдвоём, как две стороны одного механизма.
3) Зачем вообще понадобилось это обновление?
Представь Ethereum как огромную трассу. Когда-то по ней спокойно ездили несколько машин: несколько тысяч пользователей, базовые dApp’ы, первые DeFi-проекты.
Но со временем эта трасса стала центром мирового трафика:
- десятки миллионов людей отправляют транзакции,
- биржи, DeFi, NFT, Telegram-боты - все работают поверх Ethereum,
- и самое главное: появились Layer-2, которые построены поверх Ethereum
- и публикуют в него свои данные.
И вот здесь появился узкий момент, который был невозможно игнорировать.
Проблема #1: взрывной рост L2
Arbitrum, Optimism, Base, zkSync, Starknet, Scroll - эти сети взорвали использование Ethereum.
- выпускать rollup-пакеты,
- публиковать огромные массивы данных,
- загружать state-diff’ы,
- отправлять proofs и calldata,
- производить тонны информации, которая должна быть размещена в Ethereum.
По мере роста пользователей L2 начали дышать вниз на L1 и давить на него.
Ethereum превращался в город, через который ежедневно проходит грузовой поток, который он не рассчитывал обслуживать.
Проблема #2: данные L2 дороги и тяжёлые
Каждый роллап обязан публиковать свои данные на Ethereum, иначе он будет:
Но публикация данных - самое дорогое действие в Ethereum.
Львиная доля комиссии в Arbitrum/Base/Optimism - это DA cost (data availability cost). То есть цена за размещение данных на Ethereum.
Чем больше пользователей → тем больше данных → тем выше стоимость → тем дороже становятся транзакции в L2.
И это превращалось в потолок масштабируемости.
Проблема #3: валидаторы Ethereum должны были скачивать ВСЕ данные
До Fusaka у валидаторов была проста, но жёсткая работа:
"Скачивай абсолютно весь пакет данных, который публикует каждый роллап."
Если роллап публикует 1 МБ, а их 5 - валидатор должен скачать 5 МБ.
Если завтра будет 50 роллапов - валидатор утонет.
- большие жёсткие диски,
- гигабайты трафика ежедневно,
- мощные машины,
- потеря децентрализации (не каждый может запустить узел).
Ethereum медленно, но уверенно шёл к тому, что валидаторы становятся слишком тяжёлыми.
Проблема #4: рост комиссии и падение децентрализации
Если валидаторы становятся "толстыми", то:
- сеть сжимается (меньше людей запускают свои ноды),
- стоимость транзакций растёт,
- становится труднее поддерживать сеть,
- L2 перестают быть дешёвыми,
- Ethereum теряет своё предназначение - быть доступным и масштабируемым.
Проблема #5: приближение к пределу (до Fusaka сеть уже работала на лимите)
После обновления Dencun и введения blob-данных (EIP-4844) - Ethereum получил временное облегчение.
Но уже летом 2025 года стало очевидно:
- blobs забиваются,
- роллапы начинают конкурировать за место,
- комиссия снова растёт,
- нагрузка снова растёт.
Ethereum, по сути, дошёл до архитектурного конца старой модели.
Именно поэтому понадобилось Fusaka
Fusaka - не "косметика", не "оптимизация", не "чуть улучшили скорость".
Это смена парадигмы, связанная с главным вопросом:
"Как сделать так, чтобы Ethereum мог обрабатывать 10-100x больше данных, не увеличивая требования к узлам и не поднимая комиссии?"
4) Ключевая проблема
история о том, как Ethereum начал спотыкаться не на скорости, а на данных
Чтобы понять, почему Fusaka — это большое дело, нужно понять одну ключевую вещь:
в Ethereum bottleneck уже давно не вычисления, не газ, не смарт-контракты.
bottleneck - "узкое место" системы.
История начинается с роллапов
Ethereum задумали как базовый слой ("уровень ноль"), а поверх него - быстрые, дешёвые Layer-2 сети:
Каждая из них работает примерно так:
- собирает транзакции внутри своей сети,
- обрабатывает их у себя,
- затем публикует данные на Ethereum, чтобы доказать, что они работают честно.
Вот это "публикует данные" - и есть самое важное.
Почему роллапы обязаны публиковать данные?
Потому что если они не публикуют данные в Ethereum, то:
- нельзя проверить, не обманывает ли оператор,
- нельзя доказать корректность их состояния,
- нельзя восстановить историю роллапа в случае аварии,
- нельзя убедиться, что деньги пользователей защищены.
Доступность данных - фундамент безопасности L2.
Без неё всё Web3 превращается в Web2: "поверь нам на слово". Ethereum не может этого допустить.
Но у этого правила есть тёмная сторона
Представь: каждый роллап обязан выкладывать в сеть огромные пакеты данных.
Кто должен скачивать эти данные?
Кто подтверждает, что они доступны?
Ответ: каждый валидатор Ethereum.
Валидаторы Ethereum до Fusaka жили по очень тяжёлому правилу
"Хочешь участвовать в консенсусе?
Тогда скачивай ВСЕ данные, которые размещают роллапы.
Если роллап публикует 1 МБ - скачай 1 МБ.
Если роллапов 50 - скачай 50 МБ.
Если данные растут - скачивай всё.
Это была модель "total download".
Почему это стало проблемой в 2025 году?
- L2 росли слишком быстро,
- данных становилось слишком много,
- blobs начали забиваться,
- нагрузка на диски и трафик валидаторов росла,
- и Ethereum столкнулся с угрозой потери децентрализации.
Запуск нормальной ноды становился всё тяжелее: нужен большой SSD, гигабайты трафика, мощный процессор. Если так продолжится - ноды смогут запускать только крупные компании. А это убивает идею Ethereum как децентрализованной сети.
Самое страшное: появлялся потолок масштабируемости
Ethereum мог поддерживать только ограниченное количество данных L2.
больше пользователей → больше данных → выше комиссии → меньше людей могут пользоваться сетью → сеть НЕ растёт.
Это тупиковая ветка. Ethereum не может стать мировым компьютером, если он упирается в пределы данных.
Суть ключевой проблемы в одном предложении
старый механизм "все валидаторы скачивают весь пакет данных полностью" - больше не масштабируется.
Это делало сеть: дорогой, медленной, тяжёлой, и подводило к панельному потолку эффективности.
Именно эту проблему должен был решить Fusaka
И именно для этого был разработан PeerDAS - решение, которое позволяет узлам не скачивать весь пакет данных, но всё равно гарантировать, что данные доступны.
Подробнее - в следующем пункте!
5) Решение: что такое PeerDAS?
история о том, как Ethereum научился видеть целое, проверяя только кусочки
Представь, что Ethereum стоит перед огромной проблемой:
- Роллапы приносят всё больше и больше данных.
- Валидаторы обязаны проверять весь этот поток.
- И если так продолжится, Ethereum просто задохнётся.
Это как если бы каждый человек в огромной библиотеке должен был прочитать каждую книгу, которая поступает в архив.
Но вот - появляется новая идея. Простая, гениальная и математически красивая.
История началась с одного вопроса
Учёные, разработчики и исследователи Ethereum задали себе вопрос:
"А что если валидаторы НЕ будут читать весь файл?
А вместо этого - проверят только маленькие кусочки?"
На первый взгляд звучит нелепо. Как можно убедиться, что большой файл целый, если проверить лишь часть? Но ответ был найден - в математике и кодировании данных.
PeerDAS родился из идеи "семплинга" - случайных проверок
- Роллап публикует большой массив данных.
- Этот массив кодируется (с помощью методов, похожих на Reed–Solomon).
- Он разбивается на очень много маленьких кусочков.
- Эти кусочки раздаются узлам.
- Каждый валидатор скачивает маленькую случайную часть - буквально крошки.
- Если все валидаторы говорят: "У меня всё ок"
- То с математической вероятностью, которая стремится к 100%, все данные действительно доступны.
Data Availability Sampling (DAS)
а в Ethereum - PeerDAS (потому что узлы делают sampling в peer-to-peer сети).
Базовая Аналогия
Представь огромную книгу на 500 страниц. Чтобы убедиться, что книга не потеряла страниц, ты зовёшь не одного человека, а тысячу. Каждый случайно открывает пару страниц и смотрит:
Если ни один человек не обнаружил проблемы - значит книга действительно целая.
Вместо книги - огромный массив данных роллапа.
Вместо людей - PoS-валидаторы.
Вместо страниц - кусочки данных.
Именно это и делает PeerDAS революционным
До Fusaka: каждый валидатор скачивает всё → дорого, тяжело, не масштабируется.
После Fusaka: каждый валидатор скачивает 1–2% данных → быстро, легко, огромная масштабируемость.
Но математика делает так, что сети всё равно достаточно этой информации, чтобы гарантировать полную доступность данных.
Почему это работает? (метафорически и в научной логике одновременно)
Потому что при использовании erasure coding и случайного sampling:
- если в данных есть "дыра" - высокая вероятность, что кто-то её найдёт;
- если хоть один валидатор найдёт недоступный кусок - блок считают недоступным;
- поэтому операторам роллапов невозможно публиковать неполные данные;
- а валидаторы не обязаны скачивать весь файл, чтобы быть уверенными.
PeerDAS - не просто оптимизация
Это фундаментальная смена архитектуры Ethereum: не "скачай всё", а "скачай немного, но достаточно, чтобы быть уверенным".
- Ethereum сможет поддерживать в 10–20 раз больше данных,
- комиссии на L2 упадут,
- сеть станет легче,
- децентрализация - выше.
PeerDAS = шаг к будущему Ethereum, когда сеть сможет обслуживать миллионы пользователей ежедневно без перегрузок.
6) Что теперь меняется в Ethereum благодаря PeerDAS
История о том, как сеть словно сняла тяжёлый рюкзак....
Представь, что Ethereum долгие годы шёл по горе с огромным рюкзаком. Этот рюкзак - данные, которые L2 публиковали каждую секунду. Он был нужен, но становился всё тяжелее. Шаги становились медленными. Любой подъём давался всё труднее. И казалось, что если так продолжится - вершину не покорить.
Это как если бы Ethereum поменял рюкзак на лёгкий экзоскелет.
Он может идти быстрее, дальше, выше.
Теперь объясню, что конкретно изменилось.
Ethereum теперь может обрабатывать НАМНОГО больше данных
валидаторы обязаны были скачивать весь объём данных, который публикуют роллапы.
они скачивают маленькие случайные куски.
сеть может поддерживать десятки роллапов, а в перспективе - сотни, без критической нагрузки.
Это как если бы пропускная способность Ethereum выросла не на 10–20%, а на порядок - 10x, 20x, 50x в будущем.
Узлы (ноды) становятся легче и доступнее
Это важнейшая часть. До Fusaka валидатор Ethereum - машина, которая каждый день качает гигабайты данных.
После Fusaka - компактный, лёгкий узел, которому нужны:
Запуск своей ноды становится проще. И это критично: чем легче нода - тем больше людей могут держать ноды → тем выше децентрализация.
Комиссии в L2 становятся ниже
Здесь прямая связь. Стоимость транзакции в любой L2 (Arbitrum, Base, Optimism) состоит из двух частей:
PeerDAS сильно снижает DA cost → значит: транзакции на L2 становятся дешевле.
И это не теория - это прямо влияет на:
- трейдеров,
- пользователей Telegram-ботов,
- NFT-маркетплейсы,
- DeFi-платформы,
- гейминговые проекты,
- любые массовые приложения.
То есть PeerDAS → дешёвые данные → дешёвые транзакции → Ethereum становится ближе к массовому рынку.
L2 больше не конкурируют между собой за место в данных
До Fusaka blobs были ограничены. L2-сети конкурировали за одно и то же пространство. Это как маленький почтовый ящик: все пытаются в него запихнуть свои письма.
После Fusaka - почтовый ящик стал огромным. Каждый роллап может публиковать данные без драк за место.
Ethereum становится значительно устойчивее при пиковых нагрузках
Сеть просто обязана выдерживать всплески данных. До Fusaka - иногда были перегрузки. После Fusaka - Ethereum готов к "чёрным лебедям".
Пиковая нагрузка теперь не ломает сеть.
Это открывает дверь к следующему этапу - Danksharding
PeerDAS - не конечная цель. Это фундамент, на котором строится следующее:
Danksharding
Danksharding - когда Ethereum сможет обрабатывать не просто больше данных…
а огромные массивы данных без ограничения. PeerDAS - первая версия data sampling.
Danksharding - уже полный шардированный L1 с полноценным DA sampling на огромных размерах.
То есть Fusaka - шаг к Ethereum, который сможет обслуживать миллиарды людей.
7) Про Osaka
Чтобы понять Osaka, давай вернёмся к метафоре города Ethereum. Мы уже говорили, что Execution Layer - тело, которое выполняет действия:
И вот что важно: Когда появилась идея PeerDAS, одного Consensus Layer было недостаточно. Сеть должна была научиться по-новому принимать и хранить данные, которые приходят от роллапов. Это та самая роль, которую взял на себя Osaka.
Osaka - обновление "органов чувств" и "мышц" Ethereum
Если Fulu - мозг, который научился новым правилам, то Osaka - тело, которое научилось по-новому воспринимать и обрабатывать данные.
Старый Execution Layer был рассчитан на:
Но PeerDAS приносит новый формат данных, и Execution Layer просто не мог работать с ними без обновления. Поэтому Osaka стал архитектурным апгрейдом EVM-клиентов.
Научил Ethereum понимать новый тип данных от L2
После Osaka: Ethereum научился понимать кодированные сегменты данных, которые создаёт PeerDAS:
- маленькие кусочки (DAS-chunks),
- фрагменты EDS (Extend Data Square),
- данные, которые должны быть проверены sampling’ом.
То есть теперь Execution Layer умеет разбирать новый формат данных.
Перестроил внутреннюю структуру хранения данных
После Osaka: Ethereum получил новую систему организации данных,
которая: хранит только нужную часть, отдаёт данные для sampling, синхронизирует PeerDAS-метаданные, минимизирует нагрузку на дисковые операции.
Это фундаментальное изменение.
Улучшил производительность узлов исполнения
Osaka включает серию изменений, которые:
- ускоряют обработку данных,
- уменьшают задержки,
- повышают Throughput (Пропускная способность),
- оптимизируют кэши и память,
- делают синхронизацию легче.
Это не маркетинг, а реальные изменения на уровне клиента:
- Geth работает быстрее,
- Nethermind эффективнее обрабатывает входящий поток,
- Erigon получает меньше нагрузки на диски.
Сделал Ethereum дружелюбным к ZK и ZK-роллапам
ZK-роллапы (Starknet, zkSync, Scroll) сильно зависят от больших объёмов пруфов.
- оптимизирует хранение этой информации
- ускоряет пути её валидации
- делает коммуникацию ZK-роллапов с L1 легче
Это подготовка к будущему ZK-ориентированному Ethereum.
Упростил жизнь L2-сетям
- Публикация данных стала проще
- Данные кодируются в новый формат
- Ethereum принимает их быстрее
- Комиссии стали предсказуемее.
Теперь L2 могут:
8) Про Fulu
как мозг Ethereum научился работать по-новому
Мы уже сказали, что Execution Layer - тело, машина исполнения.
Но любая машина бесполезна без мозга, который:
- следит за порядком,
- координирует участников,
- принимает решение, какой блок является истиной,
- поддерживает безопасность.
Это и есть Consensus Layer. И вот тут начинается реальная магия Fusaka: обновление Fulu касается именно этого уровня - уровня, который отвечает за то, чтобы Ethereum оставался честным и децентрализованным.
История начинается с валидаторов
Ты знаешь, что в Ethereum сейчас тысячи валидаторов. Каждый из них поставил 32 ETH и стал "охранником" сети. Их работа проста, но критична:
- они проверяют блоки
- подписывают их
- участвуют в комитете
- обеспечивают финализацию
- поддерживают безопасность Proof-of-Stake
Но до Fusaka у них была ещё одна обязанность.
"Скачивай все данные, которые приходят от роллапов."
Это превращалось в тяжёлую, почти невыносимую нагрузку. И вот здесь появляется Fulu.
Fulu - обновление, которое учит валидаторов работать в режиме PeerDAS
Если Osaka - обновление "тела", то Fulu - обновление "мозга". Именно Fulu включает новые правила консенсуса, которые позволяют валидаторам:
больше не скачивать весь пакет данных, а скачивать только маленькие случайные кусочки, и при этом гарантировать, что структура данных целая и доступна.
Data Availability Sampling
Но в Ethereum это сделано через логику Fulu.
Изменяет обязанности валидаторов
До Fulu: валидаторы скачивали весь набор данных, что публикуют L2.
После Fulu: валидаторы скачивают только случайные сегменты данных.
Это снимает гигантскую нагрузку, особенно когда несколько роллапов публикуют огромное количество пакетов.
Вводит новую систему ролей (duty scheduling)
Теперь валидаторы разделяются на группы для разных задач:
- одни участвуют в sampling,
- другие подтверждают блоки,
- третьи проверяют корректность данных,
- четвёртые участвуют в синхронизации метаданных PeerDAS.
Это архитектура, которая позволяет параллельно и эффективно распределять обязанности.
Уменьшает требование к аппаратным ресурсам PoS-нод
Fulu делает версии клиентов PoS: Lighthouse, Prysm, Teku, Nimbus гораздо легче.
Потому что теперь PoS-узлу не нужно скачивать мегабайты данных, которые публикуют L2 каждый блок.
Результат: Ethereum становится более децентрализованным.
Повышает устойчивость консенсуса
Когда PoS-валидаторы раньше должны были скачивать огромные объёмы данных:
узлы могли лагать, отставать, терять синхронизацию, попадать в ситуации near-slash, замедлять финализацию. Fulu решает это, потому что данные для sampling очень лёгкие.
Отдельная важная часть - логика проверки доступности данных
Fulu внедряет в Ethereum формальную логику:
"Блок признаётся валидным только если data sampling прошёл успешно."
если хоть один валидатор видит, что данные недоступны → блок считается недействительным
если sampling у всех валидаторов проходит → блок считается доступным
Эта логика защищает Ethereum от атак на доступность данных. И раньше такие атаки было сложно предотвратить без полного скачивания данных.
Fulu - мост к полноценному Danksharding
Danksharding - будущее Ethereum, где сеть будет обрабатывать огромные массивы данных. Fulu - шаг #1, без которого Danksharding невозможен.
- Обучает валидаторов sampling-логике
- Меняет метрики доступности
- Перестраивает правила консенсуса
- Готовит клиентов к будущему.
9) Что это дает обычным пользвателям?
Дешевле транзакции в Layer-2 сетях
Большинство людей сегодня пользуются не самим Ethereum L1, а сетями сверху: Arbitrum, Base, Optimism, zkSync, Starknet, Scroll. В их комиссии входит плата за размещение данных на Ethereum. Fusaka снижает эту стоимость → транзакции становятся дешевле:
swap за 0.02-0.05$ вместо 0.10-0.30$
дешевле использовать Telegram-ботов, DeFi и игры
Пользователь просто платит меньше.
Меньше резких скачков комиссий
Раньше, если в сети происходил хайп (дроп, мемкойн, памп):
После Fusaka, Ethereum обрабатывает больше данных без перегрузки.
комиссии стабильнее и предсказуемее
Это делает сеть комфортной для обычных пользователей.
Транзакции подтверждаются быстрее и без лагов
Когда L2 перестают бороться за место в данных:
Пользователь получает более плавный опыт: заплатил → подтвердилось быстро.
Приложения начинают работать лучше
Благодаря PeerDAS L2 могут обрабатывать намного больше операций.
- меньше перегрузок во время пиков
- больше пользователей может работать одновременно
- приложения могут становиться сложнее и мощнее
Для пользователя это выглядит как:
- DEX работает быстрее
- игра не тормозит
- NFT-платформы не падают при хайпе
- Claim токенов при airdrop не падает при нагрузке
Ethereum становится более децентрализованным и безопасным
С запуском PeerDAS валидаторам больше не нужно скачивать огромные объёмы данных.
Пользователь получает более надёжную сеть, даже если он этого не замечает.
Это подготовка к будущему, где комиссии станут ещё ниже
Fusaka - первый шаг к Danksharding. После него:
Пользователь получает не только текущие улучшения, но и движение к ещё более дешёвым и быстрым транзакциям.
10) Что это дает разработчикам?
Дешевле и предсказуемее L2 → больше пространства для логики
Для девелопера главное следствие: каждый swap(), mint(), bridge() на L2 стал дешевле и стабильнее по цене.
- Можно делать сложнее бизнес-логику в контрактах на L2, не убивая пользователей по газу.
- Меньше страха "ой, у нас 7 external calls, это будет стоить как крыло от Боинга".
- Можно смелее проектировать: сложные DeFi-протоколы (мульти-степ стратегии, агрегаторы), игры с частыми ончейн-обновлениями, social-приложения (лайки, репосты, комментарии on-chain).
Для Solidity-разработчика это ощущается как: L2 всё больше становится "как писать в локальной сети, но с секьюрностью Ethereum".
Rollup-first ментальность: новая норма разработки
Fusaka + PeerDAS усиливают тренд:
Разработка = сразу под L2, L1 в основном как settlement/DA.
Что это значит для девелопера:
- Если ты пишешь смарт-контракты на Solidity - по дефолту думаешь о деплое в Arbitrum/Base/Optimism, а не напрямую в L1.
- В твоём стеке по умолчанию: RPC L2, SDK L2 (Arbitrum SDK, OP Stack, Base, Linea, Scroll), бриджи и мессенджинг между L2/L1.
То есть Fusaka - ещё один аргумент в пользу:
"делай продукт сразу под L2, L1 оставь для very-core логики и сейфов ликвидности".
viem / ethers.js / web3.py: меньше боли при массовых вызовах
viem / ethers.js
const tx = await publicClient.writeContract({
address,
abi,
functionName: 'swap',
args: [...]
})const tx = await contract.swap(...args);
на Arbitrum/Base/Optimism - Fusaka даёт:
- Более стабильный maxFeePerGas / maxPriorityFeePerGas (меньше диких скачков).
- Меньше ситуаций, когда: "вчера стоило 0.2$, сегодня та же функция - 1.5quot;.
- Легче делать: бэкенды, которые исполняют пачки транзакций (бачинги, ротация позиций, арбитраж), высокочастотные скрипты (rebalancing, liquidation bots, MEV-lite стратегии).
web3.py
Если ты делаешь Python-скрипты:
tx = contract.functions.doSomething(...).build_transaction(...) signed = w3.eth.account.sign_transaction(tx, private_key=KEY) tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction)
- Скрипт, который раньше был "дорого гонять по 100 раз в день", становится реалистичным для постоянного запуска.
- Можно спокойнее закладывать автозапуски: обновление ордеров/лимитов, автоматические переводы, ребаланс портфелей.
По сути: Fusaka делает high-frequency-автоматизацию на L2 более экономичной.
Меньше ограничений по "что я могу себе позволить в архитектуре"
Раньше многие dev’ы резали функционал, потому что:
- "слишком много стейта → дорого"
- "слишком много ивентов → дорого"
- "слишком много логики → пользователи не будут платить"
Теперь, с более дешёвыми и масштабируемыми L2:
- Можно чаще писать события (events) для аналитики и индексации.
- Можно хранить больше метаданных on-chain, не вынося всё в off-chain.
- Можно добавлять защитные проверки, sanity-checks, fail-safe механизмы, не думая про каждый лишний require.
То есть Fusaka расширяет "диапазон допустимой сложности" для твоих контрактов.
Легче поднимать инфраструктуру: ноды, индексеры, тестовые стенды
- запускаешь свои ноды для dev/test,
- поднимаешь собственный RPC,
- строишь индексеры (The Graph, SubQuery, custom indexer на Python/Node),
- меньше трафика и нагрузки на full-ноды и валидаторские ноды.
- Разворачивать свой infrastructure stack становится чуть менее больно.
- Тимам, которые хотят уйти с "общих RPC" и поднять свои
- Энтузиастам, которые хотят дома держать ноду
- Тем, кто строит инструменты вокруг сети (сканеры, аналитика, мониторинги).
Бот-девелоперы, арбитражники, MEV-lite
- арбитражных ботов на Python/Node.js,
- Telegram/Web3 ботов (через viem/ethers.js),
- скрипты для мониторинга L2 и реакции на события:
Fusaka даёт:
- дешевле cost-per-action - каждое обращение к контракту через бота стоит меньше.
- Можно: чаще обновлять заявки, чаще пытаться зайти в сделку, чаще проверять состояние рынка.
Если раньше ты думал: "Ок, бот будет делать 5–10 транзакций в день, иначе слишком дорого", то теперь можно спокойно увеличивать частоту, особенно на Base/Arbitrum/Optimism.
Rollup dev / инфраструктура L2
Если смотреть вообще шире, на разработчиков самих L2:
- Fusaka с PeerDAS даёт пространство для повышения пропускной способности без убийства L1.
- Можно экспериментировать с: более высоким TPS, большим количеством публикуемых данных, более частыми батчами.
В перспективе это значит: роллап-команды могут улучшать UX (быстрее блоки, меньше задержки), а dev’ы на Solidity/TypeScript/Python просто пользуются этим как "новой нормой".
11) Что Fusaka значит для будущего Ethereum?
история о том, как сеть получила новый вектор развития
Представь Ethereum как огромный корабль, который идёт через океан. У него есть определённый маршрут - стать мировым децентрализованным компьютером. Но всё это время корабль нёс на себе огромный груз - данные роллапов.
Он двигался, но всё медленнее. Каждые несколько месяцев груз увеличивался, и становилось ясно: если что-то не поменять - корабль не дойдёт до цели.
Это разворот корабля на новую траекторию.
Это решение фундаментальной проблемы, которую Ethereum пытался решить с 2020 года (с момента появления rollups).
Теперь разберём, что именно это значит для будущего.
Fusaka - реальное начало эпохи "Ethereum как уровень данных"
Но до Fusaka Ethereum не мог масштабировать DA, а значит - L2 были ограничены.
- Ethereum становится по-настоящему данными-ориентированным блокчейном,
- Роллапы могут публиковать гораздо больше данных,
- Сеть наконец-то делает шаг от "одной магистрали" к "целой дорожной системе".
Это мост к Danksharding - главному обновлению десятилетия
распределённая публикация данных,
экстремальное масштабирование L2,
транзакции за копейки на всех роллапах.
Но Danksharding невозможен без:
- sampling,
- новой логики валидаторов,
- новой структуры данных EDS,
- разделения обязанностей на уровне консенсуса.
И Fusaka - первый рабочий шаг. Если раньше Danksharding казался теорией, то теперь у Ethereum появился реальный фундамент.
Fusaka делает Ethereum готовым к миру, где миллионы людей используют Web3 ежедневно
Раньше это было бы невозможно:
- слишком дорого,
- слишком нестабильно,
- слишком тяжело для нод,
- слишком медленно для массового использования.
- L2 получают возможность расти вширь,
- игры могут иметь миллионы on-chain-ивентов,
- SocialFi может жить ончейн,
- DeFi может работать без перегрузок.
Фактически, Fusaka переводит Ethereum в режим масштабирования под массовый рынок.
Fusaka увеличивает децентрализацию и безопасность Ethereum на годы вперёд
Потому что если сеть становится слишком тяжёлой:
1) Меньше людей могут запускать ноды
PeerDAS уменьшает нагрузку на узлы, это значит:
Ethereum не просто масштабируется - он масштабируется с сохранением децентрализации, что критически важно.
Fusaka меняет стандарты разработки: Rollup-first → окончательно
До Fusaka: многие проекты всё ещё деплоились на Ethereum L1, а L2 считались "дешёвыми вариантами".
- L1 становится "settlement слой + DA слой"
- Всё приложение живёт на L2
- Разработчики мыслят Rollup-first по умолчанию
Это как переход из Web1 → Web2. Сначала это казалось альтернативой, теперь - норма.
Fusaka делает Ethereum конкурентнее среди Layer-1 и DA конкурентов
Сейчас Ethereum конкурирует с:
Если Ethereum не масштабируется, он сдаёт позиции.
и укрепляет позицию Ethereum как главного settlement layer мира.
Fusaka - фундамент для десятилетия инноваций
После этого обновления Ethereum может спокойно:
обеспечивать огромные потоки данных,
запускать реальные Web3 соцсети,
строить игры уровня Fortnite/PUBG на L2,
обслуживать десятки миллионов пользователей.
Это не преувеличение. Это реальность, которую открывает PeerDAS.
12) Эпилог
Всем спасибо за прочтение данного материала! Уверен, он стал отправной точкой в вашем пути улучшения себя как web3-разработчика!
Fusaka - не просто очередное обновление Ethereum. Это фундаментальный шаг, который снимает главный барьер роста сети - работу с данными.
Благодаря PeerDAS Ethereum становится быстрее, дешевле, стабильнее и гораздо более масштабируемым.
Это первый реальный шаг к Danksharding и миру, где Web3 сможет обслуживать миллионы пользователей ежедневно.
Fusaka делает Ethereum готовым к будущему - и это будущее началось уже 3.12.2025....
Автор Статьи - https://t.me/code_vartcall