Как на самом деле работает крипта ч.2: Ethereum и Solana

В этой части мы представляем перевод следующих двух глав, посвящённых экосистемам Ethereum и Solana.

Если ты ещё не успел ознакомиться с первой частью, она лежит по этой ссылке.

Раздел I: Основные концепции

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

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

Но сила требует сложности. Биткоин превыше всего ставил простоту и безопасность. Ethereum выбрал другой путь. Он заменил прямолинейную транзакционную модель Биткоина системой аккаунтов, которая отслеживает сложное состояние приложений. Он разработал динамическую систему комиссий для управления вычислительными ресурсами. Он прошел через технический переход от Proof-of-Work к Proof-of-Stake. И он породил целую экосистему решений для масштабирования, чтобы справляться с реальным использованием.

Понимать Ethereum — значит осознавать, как эти части соединяются воедино: как система комиссий стимулирует эффективное использование ресурсов, как Proof-of-Stake защищает сеть и как решения второго уровня (Layer 2) делают платформу практически пригодной для повседневных приложений. Эта глава проведет тебя через эти основные механизмы, показывая инженерные решения, на которых держится сегодняшний масштабный эксперимент в области децентрализованных вычислений.

Виртуальная машина Ethereum (EVM)

В самом сердце Ethereum лежит Виртуальная машина Ethereum (EVM) — вычислительный движок, который одновременно исполняет код на тысячах компьютеров (называемых узлами или нодами). В отличие от Биткоина, который в первую очередь переводит ценность, Ethereum запускает смарт-контракты, превращая сеть из простой платежной системы в программируемый «мировой компьютер».

EVM работает как стековая виртуальная машина, обрабатывая инструкции подобно стопке тарелок, где ты можешь добавлять или удалять элементы только сверху. Она использует низкоуровневые инструкции, называемые опкодами (opcodes). К ним относятся такие операции, как ADD (сложение), MULTIPLY (умножение), STORE (сохранение) и CALL (вызов). Когда разработчики пишут смарт-контракты на высокоуровневых языках, таких как Solidity или Vyper, компиляторы переводят этот код в байт-код EVM (серию опкодов), который может исполнить любой узел Ethereum. Эта стандартизация гарантирует, что контракты ведут себя идентично, запущены ли они в Нью-Йорке, Сингапуре или Дубае.

Что отличает EVM, так это сочетание детерминированного исполнения с управлением постоянным состоянием. Каждый смарт-контракт поддерживает собственное пространство хранения, где он сохраняет данные между транзакциями. Когда кто-то взаимодействует с контрактом — например, обменивает токены на Uniswap или берет взаймы на Aave, — EVM исполняет соответствующий байт-код, читает и записывает данные в хранилище и обновляет балансы аккаунтов. Каждый узел независимо выполняет те же вычисления и проверяет, что они приходят к идентичным конечным состояниям. Этот процесс создает децентрализованный консенсус: Ethereum становится заслуживающим доверия без необходимости доверять какой-либо одной стороне, поскольку тысячи независимо работающих узлов подтверждают одни и те же результаты.

Каждая операция потребляет газ — комиссию, измеряемую в вычислительной работе. Газ служит двум критическим целям: он вознаграждает операторов узлов за выполнение вычислений и предотвращает спам, делая каждую операцию платной. Более сложные операции требуют больше газа, что объясняет, почему простые переводы стоят дешевле, чем развертывание запутанных смарт-контрактов. Это измерение гарантирует, что ни одна транзакция не будет выполняться бесконечно, что смягчает атаки, направленные на истощение ресурсов.

Механизм газа стремится оценивать операции примерно в соответствии с их реальным потреблением ресурсов. Ранние атаки использовали недооцененные операции, что заставило Ethereum со временем скорректировать стоимость опкодов. Эти корректировки повысили цены на операции, которые оказались слишком дешевыми по сравнению с их вычислительными требованиями, что уменьшило возможности для DoS-атак и стало лучше отражать базовые затраты ресурсов.

EVM превратилась в стандарт де-факто, вышедший далеко за пределы самого Ethereum. Большинство роллапов(Arbitrum, Optimism, Base) и многие альтернативные L1-сети приняли совместимость с EVM, что означает использование ими того же байт-кода. Эта совместимость создает огромную ценность: приложения типа Uniswap и Aave развертываются в этих сетях с минимальными изменениями, в то время как вся инфраструктурная экосистема (кошельки типа MetaMask, блокчейн-эксплореры, инструменты разработки, индексаторы) функционирует почти идентично во всех EVM-цепях. Новые блокчейны могут быстро нарастить активность, наследуя зрелый инструментарий Ethereum и привлекая существующих пользователей и разработчиков без необходимости изучать новые парадигмы. Эти сетевые эффекты укрепляют доминирование Ethereum.

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

Роллапы и другие решения для масштабирования решают это ограничение, перенося большую часть исполнения за пределы Ethereum, используя базовый слой в первую очередь для обеспечения доступности данных и окончательных расчетов. Они объединяют множество внесетевых транзакций в пакеты, отправляя обратно в Ethereum только сжатые данные и (в некоторых конструкциях) доказательства валидности. Это позволяет многим пользователям разделить стоимость газа одной транзакции на L1, что резко снижает комиссии и увеличивает эффективную пропускную способность, при этом наследуя безопасность Ethereum.

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

Система комиссий Ethereum

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

Газ питает вычислительный движок Ethereum так же, как топливо питает автомобиль. Каждая операция — от отправки ETH другу до исполнения сложного смарт-контракта — потребляет определенное количество этого вычислительного топлива. Простой перевод ETH между обычными кошельками сжигает 21 000 единиц газа, в то время как взаимодействие со смарт-контрактами требует пропорционально большего количества. Обмен токенов на Uniswap может потребовать 150 000 газа, а развертывание нового смарт-контракта может поглотить миллионы.

Обсуждая комиссии, пользователи Ethereum оперируют конкретными номиналами. В то время как «вей» (wei) представляет собой наименьшую возможную единицу эфира ($1 \text{ ETH} = 10^{18} \text{ wei}$), обсуждение комиссий обычно происходит в гвеях (gwei):

$$1 \text{ gwei} = 10^9 \text{ wei} = 10^{-9} \text{ ETH}$$

Это упрощает обсуждение цен на газ. Вместо того чтобы говорить «цена газа составляет 50 000 000 000 вей», люди говорят «50 гвей».

Ключевым этапом развития стал EIP-1559, который радикально изменил рынок комиссий на уровне протокола. До этого обновления в августе 2021 года пользователи участвовали в хаотичной аукционной системе, постоянно пытаясь перебить ставки друг друга за место в блоке: ты угадывал одну цену газа и надеялся, что она не окажется слишком низкой или излишне высокой. EIP-1559 ввел новый, более предсказуемый механизм комиссий по умолчанию с двумя компонентами: динамически регулируемой базовой комиссией (base fee) и чаевыми, устанавливаемыми пользователем. Большинство современных кошельков используют этот механизм по умолчанию. Устаревшие транзакции типа 0 («gasPrice») всё еще поддерживаются и ведут себя скорее как старый аукцион, так что дополнительная предсказуемость доступна, но не является строго обязательной для всех транзакций.

При отправке транзакций пользователи устанавливают maxFeePerGas (абсолютный максимум, который они готовы заплатить за единицу газа) и maxPriorityFeePerGas (необязательные чаевые валидаторам для более быстрого включения). Фактическая уплаченная цена газа рассчитывается как минимум из твоего максимального вознаграждения или суммы базовой комиссии и твоих чаевых (priority fee). Общая стоимость транзакции равна количеству использованного газа, умноженному на эту эффективную цену газа.

Каждый блок Ethereum имеет лимит газа, определяющий его емкость: максимальное количество газа, которое могут коллективно потребить все транзакции в этом блоке. Со времен EIP-1559 протокол стремится к использованию примерно половины этого лимита в каждом блоке и рассматривает этот таргет как «заполненность на 100%» для целей ценообразования. Когда спрос резко возрастает, блоки могут временно расширяться примерно вдвое выше таргета (вплоть до самого лимита газа), создавая так называемые «эластичные блоки».

Исторически Ethereum использовал лимит газа в 30 миллионов (с таргетом в 15 миллионов). В период 2024–2025 годов валидаторы постепенно подняли его примерно до 45 миллионов, а стандарт EIP-7935 (Фусака) устанавливает в конфигурациях клиентов дефолтный лимит газа в 60 миллионов на блок. Важное правило остается прежним: целевое использование газа всегда составляет половину от текущего лимита, а блоки могут растягиваться до двукратного размера этого таргета во время перегрузок.

Базовая комиссия устанавливается алгоритмически в зависимости от загруженности сети. Когда блоки используют больше целевого количества газа (более половины лимита), базовая комиссия в следующем блоке вырастает максимум на 12,5%. Когда они используют меньше таргета, она падает максимум на ту же величину. Высокий спрос автоматически повышает цены; низкий спрос снижает их через этот механизм самобалансировки.

Самым значимым новшеством является то, что происходит с комиссиями. Часть общей уплаченной комиссии, покрывающая базовую комиссию (использованный газ $\times$ base fee), сжигается, то есть уничтожается навсегда и выводится из обращения, что создает дефляционное давление на предложение ETH. Валидаторам достаются только чаевые (priority fee). Любая неиспользованная часть твоего maxFeePerGas возвращается тебе, а не выплачивается кому-либо. Это дает пользователям способ стимулировать быстрое включение в периоды нагрузки, предлагая более высокие чаевые без риска перманентно переплатить за газ.

В периоды устойчивого спроса сжигание базовой комиссии может превышать выпуск новых ETH в качестве вознаграждения за стейкинг, делая общее предложение чисто дефляционным (сокращающимся, а не растущим). Высокая нагрузка на сеть увеличивает скорость сжигания, сокращая предложение и потенциально поддерживая стоимость ETH. С момента «Слияния» (The Merge) в сентябре 2022 года наблюдались длительные периоды дефляции предложения ETH. Однако такие обновления, как Dencun и EIP-4844, сделали газ на L1 дешевле, что, в свою очередь, сократило объемы сжигаемых комиссий. С 2024 года возникали периоды, когда предложение ETH снова становилось чисто инфляционным, несмотря на механизм сжигания.

EIP-1559 снизил волатильность комиссий и радикально улучшил пользовательский опыт, сделав затраты более предсказуемыми. Пользователи могут устанавливать разумные максимальные комиссии, не опасаясь переплаты, а кошельки могут точнее оценивать расходы. Важно отметить, что это изменение модифицировало работу комиссий, не затрагивая механизм консенсуса Ethereum (система прошла через это обновление еще при Proof-of-Work и сохранила его после перехода на Proof-of-Stake). Обновление ввело новые правила валидации, которые должны соблюдать все узлы, включая алгоритм расчета базовой комиссии и механизм сжигания. Однако оно не решило всех проблем рынка комиссий. Такие вопросы, как цензура транзакций (когда валидаторы намеренно исключают определенные транзакции), остаются активными областями исследований; продолжается разработка предложений типа «списков включения» (inclusion lists), которые обязывали бы валидаторов включать определенные транзакции.

Как Ethereum идентифицирует аккаунты и активы

Хотя понимание газа помогает пользователям управлять расходами на транзакции, знание того, как Ethereum идентифицирует аккаунты и активы, не менее важно для эффективной навигации по экосистеме.

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

В Ethereum существует два типа аккаунтов. Внешние аккаунты (EOA) — это обычные пользовательские кошельки, контролируемые закрытыми ключами (например, «горячие» кошельки или аппаратные устройства). Аккаунты смарт-контрактов — это программируемые учетные записи, которые исполняют код при активации. У каждого участника в Ethereum (будь то человек или смарт-контракт) есть уникальный адрес, служащий его публичным идентификатором.

Эти адреса выглядят как криптографическая абракадабра: 40-символьная строка из цифр и букв, например 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. За этой, казалось бы, случайной последовательностью стоит математика. Для EOA адрес представляет собой последние 20 байт криптографического хеша открытого ключа аккаунта. Открытый ключ выводится из твоего закрытого ключа, поэтому твой адрес математически связан с ключом без его раскрытия.

Ethereum Name Service (ENS) решает проблему удобства, позволяя пользователям регистрировать человекочитаемые имена (например, alice.eth), которые разрешаются в эти шестнадцатеричные адреса. Эта система имен работает аналогично DNS для веб-сайтов, упрощая отправку средств и взаимодействие с аккаунтами без копирования длинных строк символов.

Смарт-контракты также получают адреса при развертывании, которые генерируются детерминированно на основе адреса создателя и других параметров.

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

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

До появления ERC-20 каждый новый токен был, по сути, уникальной «снежинкой», требовавшей написания кастомного кода для поддержки кошельками и биржами. ERC-20 изменил это, установив общий шаблон: каждый соответствующий стандарту токен должен реализовывать одни и те же базовые функции, такие как transfer(), approve() и balanceOf(). Эта внешне простая стандартизация породила то, что многие называют «Кембрийским взрывом» в DeFi.

Внезапно разработчики получили возможность создавать приложения, работающие с тысячами различных токенов, не прописывая код для каждого в отдельности. Децентрализованная биржа могла добавить любой токен ERC-20, протокол кредитования мог принимать любой ERC-20 в качестве залога, а пользователи могли беспрепятственно перемещать активы между различными приложениями. Эта компонуемость (возможность соединения различных протоколов как деталей Lego) стала одной из определяющих характеристик Ethereum, позволяя проводить сложные многошаговые операции, которые либо завершаются полностью, либо отменяются без частичного исполнения. В Главе VII эти DeFi-приложения рассматриваются подробно.

Экосистема продолжила эволюционировать с появлением дополнительных стандартов: ERC-721 и ERC-1155 для NFT (о чем пойдет речь в Главе XI) и множества других стандартов токенов, расширивших возможности Ethereum. Но всё это — EVM, рынок комиссий, система аккаунтов, стандарты токенов — зависит от того, согласятся ли тысячи валидаторов с состоянием сети. Подход Ethereum к достижению этого согласия фундаментально трансформировался в 2022 году.

Раздел II: Консенсус и стейкинг в Ethereum

В этом разделе рассматривается, как Ethereum достигает согласия относительно состояния своего блокчейна. В то время как Биткоин использует Proof-of-Work для достижения консенсуса, Ethereum перешел к принципиально иному подходу под названием Proof-of-Stake. Понимание этого сдвига требует сначала изучения того, как устроен процесс обновлений в Ethereum.

Как эволюционирует Ethereum: процесс EIP

Трансформация 2022 года произошла благодаря уникальной модели управления Ethereum. В отличие от традиционного ПО, где компания решает, какие функции создавать, Ethereum развивается через публичный, управляемый сообществом процесс, сосредоточенный вокруг предложений по улучшению Ethereum (EIP). Эти формальные предложения проходят через стадии (Draft, Review, Last Call и Final) с тщательным техническим обзором, анализом безопасности и тестированием в сетях типа Sepolia и Holesky перед развертыванием в основной сети (mainnet).

Core EIP модифицируют сам протокол, требуя скоординированных хардфорков (обратно несовместимых изменений протокола). Предложения ERC (Ethereum Request for Comment) определяют стандарты прикладного уровня, такие как токены ERC-20, которые делают различные приложения совместимыми. Крупные обновления объединяют несколько EIP под названиями вроде Shapella (вывод средств из стейкинга), Dencun (транзакции с «блобами» через EIP-4844) и Pectra (делегирование аккаунтов через EIP-7702).

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

Великий переход: от майнинга к стейкингу

Самой значимой трансформацией, порожденной этим процессом, стало «Слияние» (The Merge). 15 сентября 2022 года стало поворотным моментом в истории Ethereum. В этот день завершилось Слияние — многолетняя инженерная работа, в результате которой сеть перешла от энергозатратного майнинга к системе Proof-of-Stake. Это обновление ознаменовало переосмысление того, как Ethereum обеспечивает собственную безопасность.

Трансформация была беспрецедентной по масштабу. Майнеры Биткоина соревнуются в решении вычислительных задач, потребляя огромное количество электроэнергии. Новая система Ethereum полагается на валидаторов, которые блокируют собственные ETH в качестве залога. Эти валидаторы получают вознаграждение за честное поведение и сталкиваются с суровыми наказаниями за злонамеренные действия. Результат? Ethereum снизил потребление энергии более чем на 99,9%, сохранив сопоставимые гарантии безопасности.

Помимо энергоэффективности, Слияние перестроило саму архитектуру Ethereum: оно отделило уровень исполнения (execution layer, который обрабатывает транзакции) от уровня консенсуса (consensus layer, который принимает решения о порядке блоков и финальности). Это разделение, воплощенное в Beacon Chain, заложило фундамент для будущих улучшений масштабируемости, которые были бы невозможны при старой системе майнинга.

Как Ethereum достигает консенсуса

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

Время в Ethereum движется фиксированными отрезками: каждые 12 секунд отмечают слот, а каждые 32 слота (около 6,4 минуты) образуют эпоху. В каждом слоте протокол случайным образом выбирает одного валидатора для предложения нового блока, используя криптографическое «зерно» (seed), полученное из предыдущей эпохи, в то время как сотни других предоставляют аттестации — криптографические голоса, подтверждающие, что предложенный блок следует всем правилам.

Путь к финальности (моменту, когда транзакция становится необратимой) проходит в два этапа. Сначала блок становится «обоснованным» (justified), когда он получает аттестации от как минимум двух третей валидаторов. Затем, в следующей эпохе, если еще одно супербольшинство подтверждает это обоснование, блок становится финальным. Этот процесс обычно занимает около 12,8 минуты. После финализации отмена транзакции потребовала бы скоординированной атаки, вызывающей суровые финансовые санкции, называемые слэшингом(slashing), размер которых растет пропорционально количеству вовлеченных валидаторов.

Для того чтобы стать валидатором, требуется застейкать минимум 32 ETH, но со времен хардфорка Pectра (EIP-7251) валидаторы могут увеличивать свой эффективный баланс (количество стейка, учитываемого при расчете силы голоса и наград) до 2048 ETH, что меняет ландшафт стейкинга. Хотя порог активации остается на уровне 32 ETH за один ключ валидатора, операторы теперь могут прикреплять дополнительные ETH к одному валидатору, чтобы пропорционально увеличить его вес при аттестации, награды и штрафы. Это снижает операционные издержки за счет меньшего количества ключей и аттестаций, но концентрирует стейк и потенциальный риск слэшинга на одном валидаторе. Изменение снижает стимул запускать множество валидаторов по 32 ETH. Крупные операторы могут консолидироваться в меньшее число валидаторов с более высоким стейком, в то время как соло-стейкеры могут продолжать работать со стандартными установками по 32 ETH.

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

Безопасность обеспечивается через слэшинг — механизм наказания за вредоносное поведение. Валидаторы, нарушающие правила (например, предлагающие конфликтующие блоки или дающие противоречивые аттестации), несут финансовые потери. Базовый штраф намеренно невелик: порядка сотых долей ETH для валидатора с 32 ETH и около половины ETH для полностью «раскачанного» валидатора с 2048 ETH по новым правилам Pectra. Это означает, что единичные ошибки не катастрофичны. Но коррелированные атаки наказываются гораздо суровее. Когда множество валидаторов ведут себя плохо одновременно, применяется штраф за корреляцию, который растет вместе с долей слэшнутых участников от общего числа валидаторов; крупные скоординированные атаки могут уничтожить значительную часть стейка каждого участника. Протокол также включает «утечку при неактивности» (inactivity leaks), которая постепенно истощает балансы офлайн-валидаторов во время затяжных разделений сети, позволяя оставшимся активным валидаторам восстановить супербольшинство и финализировать цепь.

Ликвидный стейкинг

Описанные выше требования к капиталу сформировали развитие экосистемы стейкинга в Ethereum. Стейкеры сталкиваются с трудным выбором: заблокировать токены, чтобы помочь защитить сеть и заработать награды, или оставить их ликвидными для других целей. Даже несмотря на то, что после обновления Shapella вывод средств стал возможен, выход из стейкинга не мгновенен. Тебе придется ждать в очереди, что может занять дни или даже больше, когда сеть загружена. Проблема ясна: застейканный капитал оказывается заблокированным и не может быть использован в более широкой экосистеме децентрализованных финансов (DeFi). Ты вынужден выбирать между получением дохода от стейкинга и гибкостью, позволяющей давать взаймы, торговать или обеспечивать ликвидность своих активов.

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

В этом пространстве доминируют два подхода:

Lido — безусловно, крупнейший провайдер LST, контролирующий более 85% этого рынка по состоянию на начало 2026 года и управляющий примерно 25% всех застейканных ETH. Он выпускает stETH — ребейзинговый токен (rebasing token), баланс которого автоматически растет ежедневно по мере накопления вознаграждений за стейкинг. Иными словами, количество токенов в твоем кошельке меняется со временем, вместо того чтобы росла цена каждого отдельного токена. Lido использует курируемый набор профессиональных операторов узлов (недавно расширенный за счет безразрешительного участия) и полагается на комитет, который ежедневно сообщает данные о балансах из Beacon Chain для работы механизма ребейзинга. Этот подход позволил Lido быстро масштабироваться и занять доминирующее положение на рынке LST.

Rocket Pool идет по более децентрализованному пути. Это второй по величине протокол с долей рынка около 5% на начало 2026 года, позволяющий тысячам независимых операторов запускать валидаторов. Он выпускает rETH, который работает иначе. Баланс твоих токенов остается неизменным, но его обменный курс к ETH растет по мере накопления наград. Протокол позволяет операторам создавать валидаторов, имея всего 8 ETH собственного капитала, в то время как остальная часть берется из депозитов пользователей. Это делает участие в качестве валидатора более доступным, сохраняя при этом принцип безразрешительного входа.

Ликвидный стейкинг дает явные преимущества, но он сопряжен с рисками, которые тебе необходимо понимать. Доминирование Lido порождает серьезные вопросы об управлении протоколом и устойчивости сети. Если слишком большая мощь стейкинга сконцентрируется в руках одного провайдера, это может поставить под угрозу безопасность и децентрализацию базовой сети. Уязвимости смарт-контрактов — еще одна острая проблема. Сегодня большинство учетных данных для вывода средств у валидаторов управляется вне сети (off-chain), что ограничивает возможность бага в протоколе напрямую опустошить балансы валидаторов. Однако баги всё равно могут сломать учет, неверно распределить награды или заблокировать вывод средств. Если будущие обновления перенесут больше контроля над выводами непосредственно в сеть (on-chain), радиус поражения таких багов может вырасти.

Штрафы валидаторов за плохое поведение или технические сбои затрагивают всех участников пула. Наконец, риск ликвидности может проявиться в периоды рыночного стресса. Токены LST могут торговаться ниже их реальной стоимости (мы видели дисконты stETH в 2022 году), что создает потенциальные убытки, если тебе нужно быстро выйти из позиции.

Когда консенсус обеспечен, а экономика стейкинга налажена, оставшимся узким местом Ethereum остается масштаб; отсюда и рост роллапов Второго уровня (Layer 2).

Раздел III: Масштабирование Ethereum и решения Layer 2

Революция роллапов

Вспомни раздел об EVM: каждый полный узел должен обрабатывать каждую транзакцию. Этот архитектурный выбор, необходимый для децентрализации и безопасности, ограничивает пропускную способность тем, что типичный узел на потребительском оборудовании может проверить и распространить в течение 12-секундного слота. Результат — порядка нескольких десятков простых транзакций в секунду, что слишком медленно для массового внедрения. Одно популярное приложение может перегрузить всю сеть, из-за чего комиссии за газ взлетают до сотен долларов за транзакцию в периоды пикового спроса.

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

Роллапы решают это ограничение, перенося большую часть вычислений за пределы Layer 1, при этом закрепляя безопасность в Ethereum. Транзакции исполняются в отдельной цепи Layer 2, которая работает гораздо быстрее и дешевле, потому что она не требует от каждого узла Ethereum повторно прогонять каждый шаг. Затем роллап отправляет сжатые данные транзакций (и, в зависимости от конструкции, доказательства или механизмы обнаружения мошенничества) обратно на Layer 1, который обеспечивает доступность данных, разрешение споров и окончательный расчет.

Это наследование безопасности работает в полной мере только тогда, когда доступность данных (data availability) обеспечивается самим Ethereum. Чтобы роллап был по-настоящему безопасным, любой должен иметь возможность восстановить его состояние из данных, опубликованных на Layer 1. Если данные транзакций исчезнут или станут недоступны, пользователи не смогут доказать владение своими средствами или оспорить невалидные переходы состояний. Роллапы, использующие внешнюю доступность данных (называемые «валидиумами» — validiums, так как они валидируют транзакции, но хранят данные в другом месте), жертвуют этой гарантией и требуют дополнительных предположений о доверии.

Распространенная критика подхода масштабирования через роллапы утверждает, что L2-сети вытягивают ценность из Ethereum, запуская собственные токены и отвлекая внимание инвесторов и капитал от ETH. Проблема сводится к двум основным моментам. Во-первых, пользователи в итоге спекулируют на токенах L2, а не на самом ETH. Во-вторых, ценные доходы от секвенсоров (сущностей, которые упорядочивают и упаковывают транзакции на L2) и комиссии за транзакции захватываются на уровне роллапа, вместо того чтобы течь обратно в базовый слой Ethereum.

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

Экосистема роллапов эволюционировала в два основных подхода, каждый из которых идет на свои компромиссы:

Optimistic Rollups: Доверяй, но проверяй

Оптимистичные роллапы (например, Arbitrum и Optimism) придерживаются философии «невиновен, пока вина не доказана». Они оптимистично предполагают, что все транзакции верны, и немедленно публикуют обновления состояния на Layer 1. Это предположение позволяет обеспечить быстрое исполнение и низкие затраты, но с важной оговоркой: существует период оспаривания продолжительностью около семи дней, в течение которого любой может предоставить доказательство мошенничества (fraud proof), если обнаружит невалидные транзакции.

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

Однако рынок ответил на это трение появлением сторонних сервисов быстрого вывода. Провайдеры ликвидности, такие как Hop Protocol и Across Protocol, могут выдать пользователю его средства на Layer 1 немедленно, взимая комиссию за удобство. Эти провайдеры берут риск на себя в течение периода оспаривания. Если доказательство мошенничества аннулирует транзакцию, убытки несут они. Пользователи, которым нужна скорость, платят премию; те, кто готов ждать, могут вывести средства бесплатно.

ZK Rollups: Математическая определенность

ZK-роллапы (включая Starknet, zkSync и Scroll) используют совершенно иной подход. Вместо того чтобы предполагать валидность и ждать оспариваний, они используют доказательства валидности (advanced cryptographic techniques) — передовые криптографические методы, которые математически подтверждают корректность каждого пакета транзакций. Эти роллапы сначала фиксируют данные транзакций на Layer 1, а затем отправляют доказательство, которое подтверждает весь пакет.

Эти доказательства с нулевым разглашением (Zero-Knowledge) — сложнейшие математические инструменты. Они позволяют роллапу доказать, что тысячи транзакций были обработаны верно, без необходимости повторного исполнения их на Layer 1. Доказательство дает строгую криптографическую уверенность в валидности всего пакета (хотя, как и вся криптография, это опирается на надежность определенных математических допущений).

Разные ZK-роллапы используют разные системы доказательств с отличными свойствами. Scroll использует «чистые» SNARK, генерируя крошечные доказательства всего в несколько сотен байт, что минимизирует затраты на L1, но требует «доверенной установки» (trusted setup), где начальные параметры должны быть надежно созданы и уничтожены — подобно уничтожению формы после отливки мастер-ключа, чтобы никто не мог тайно чеканить новые. Starknet использует STARK, производя гораздо большие доказательства в сотни килобайт, но предлагая более сильные свойства безопасности: отсутствие доверенной установки, прозрачность и лучшую устойчивость к потенциальным квантовым компьютерам будущего. zkSync использует гибридный подход, генерируя доказательства STARK внутри системы для безопасности, а затем оборачивая их в SNARK для экономичной верификации в сети. Это всё еще требует доверенной установки для SNARK-обертки.

Преимущество перед оптимистичными роллапами очевидно. ZK-роллапы избегают недельных задержек вывода, которыми страдают оптимистичные системы. Как только доказательство валидности проверено на Layer 1, пользователи могут получить доступ к своим средствам без какого-либо периода оспаривания (хотя они всё равно ждут генерации и проверки доказательства, что обычно занимает от нескольких минут до нескольких часов в зависимости от нагрузки на систему). Однако эта безопасность дается дорогой ценой. Криптографический аппарат, необходимый для генерации этих доказательств, более сложен и вычислительно интенсивен, чем в оптимистичных подходах.

Дополнительные соображения о роллапах

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

На практике большинство роллапов в настоящее время полагаются на централизованные секвенсоры, чтобы обеспечить быстрые подтверждения, которых ожидают пользователи. В отличие от основной сети Ethereum, которая распределяет предложения блоков между тысячами валидаторов, эти роллапы используют одну сущность для упорядочивания транзакций и производства блоков. Хотя это представляет собой временное инженерное решение, а не постоянный дизайн, оно вносит потенциальные риски цензуры и единые точки отказа. Ведущие роллапы активно разрабатывают решения для устранения централизации секвенсоров при сохранении производительности. Сети общего секвенирования (shared sequencing) распределяют ответственность за упорядочивание между несколькими сторонами, создавая избыточность без потери скорости. Системы ротации секвенсоров периодически меняют сущность, занимающуюся упорядочиванием, предотвращая долгосрочный контроль со стороны одного участника. Списки включения (inclusion lists) обязывают секвенсоров включать определенные транзакции в заданные временные рамки, затрудняя цензуру. Предподтверждения (preconfirmations) позволяют секвенсорам давать «мягкие» обязательства о включении транзакции до формального консенсуса, улучшая пользовательский опыт при сохранении возможности отката через механизмы слэшинга и окна споров.

Системы доказательств продолжают развиваться в плане зрелости и охвата. Многие ZK-роллапы всё еще работают с «тренировочными колесами» (дополнительными механизмами безопасности, которые могут приостанавливать или переопределять систему на ранних этапах, пока технология взрослеет). Оптимистичные роллапы зависят от надежных систем доказательства сбоев (fault proof), которые всё еще дорабатываются и проходят проверку боем. Структуры комиссий сочетают затраты на исполнение в L2 с комиссиями за доступность данных на L1 и включение в блок. Кроме того, роллапы работают в различных режимах доступности данных. Истинные роллапы отправляют все данные в Ethereum, в то время как валидиумы используют внешнюю доступность данных или гибридные подходы, которые меняют экономию затрат на более жесткие требования к доверию.

Не все роллапы одинаково приоритезируют децентрализацию. Некоторые проекты сознательно выбирают централизованные архитектуры для достижения отзывчивости на уровне потребительских приложений. MegaETH, например, использует одного активного секвенсора и 10-миллисекундные «мини-блоки», стремясь к задержкам на миллисекундном уровне и пропускной способности порядка 100 000 транзакций в секунду. Такой дизайн принимает риски единой точки отказа и потенциальной цензуры в обмен на высокую скорость. Подобные подходы обнажают врожденные противоречия в дизайне блокчейнов: децентрализация, безопасность и производительность находятся в постоянной конкуренции, и разным приложениям требуются разные балансы.

Решение проблемы доступности данных

После того как роллапы были определены, основным фактором затрат стала доступность данных. До марта 2024 года роллапам приходилось хранить свои данные вечно в дорогом уровне исполнения Ethereum, из-за чего расходы на доступность данных составляли 80–95% от общих комиссий роллапов.

EIP-4844, реализованный в обновлении Dencun, фундаментально изменил эту экономику, введя транзакции с «блобами» (blob-carrying transactions). EIP-4844 ввел блобы с отдельным рынком комиссий и временным хранением ($\sim 18$ дней), что сократило расходы роллапов на DA (Data Availability). Эти блобы представляют собой большие пакеты данных (около 128 КБ каждый), которые временно живут на уровне консенсуса Ethereum перед автоматическим удалением (прунингом), создавая отдельный, гораздо более дешевый рынок данных, специально разработанный для роллапов.

Система поддерживает безопасность через KZG-обязательства (KZG commitments) — криптографические отпечатки, которые уникально идентифицируют содержимое каждого блоба. Представь, что роллапы арендуют место на билбордах в основной сети: они наклеивают огромный плакат (блоб), который висит там примерно 18 дней, после чего город его снимает. Город оставляет только запечатанную подписанную миниатюру, которая однозначно фиксирует содержание плаката (KZG-обязательство). Позже любой может верифицировать конкретный квадрат этого плаката с помощью крошечного чека (доказательства), при этом городу не нужно хранить весь плакат вечно.

Благодаря такой конструкции Ethereum создал два отдельных рынка комиссий: пространство блобов работает со своим собственным механизмом базовой комиссии (аналогично обычному ценообразованию газа), в то время как обычные комиссии за транзакции остаются без изменений. В обновлении Pectra стандарт EIP-7691 поднял лимиты блобов (таргет $3 \rightarrow 6$, максимум $6 \rightarrow 9$ на блок) и заставил комиссии за блобы падать агрессивнее, когда они недоиспользуются, что еще больше снизило затраты для роллапов, сохраняя цены отзывчивыми без резких скачков.

Этот дизайн является первым шагом к полному «данкшардингу» (danksharding) — долгосрочному видению Ethereum по масштабному расширению доступности данных. KZG-обязательства позволяют узлам проверять целостность блобов, оставаясь совместимыми с будущими обновлениями, которые позволят даже устройствам с ограниченными ресурсами проверять доступность данных, проверяя лишь небольшие случайные выборки (sampling), а не скачивая всё целиком.

Альтернативные решения доступности данных

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

Celestia представляет собой наиболее амбициозную альтернативу. Это специализированный блокчейн, который обеспечивает только консенсус и доступность данных, без исполнения кода. Его ключевое новшество — Data Availability Sampling, позволяющее даже устройствам с ограниченными ресурсами получать высокую уверенность в том, что полные данные блока были опубликованы, проверяя лишь небольшие случайные фрагменты. Система также позволяет разным роллапам эффективно доказывать включение своих данных без скачивания нерелевантной информации от других роллапов. Безопасность полагается на валидаторов и честное большинство независимых проверяющих (samplers), при этом полные узлы могут предоставлять доказательства мошенничества, если данные были закодированы неверно.

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

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

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

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

Раздел IV: Рестейкинг (Restaking)

Роллапы умножают транзакционную емкость Ethereum, перенося вычисления за пределы сети. Proof-of-Stake позволил осуществить другой вид умножения: возможность повторно использовать застейканный капитал в нескольких протоколах одновременно. Это новшество, называемое рестейкингом, представляет собой новый рубеж эффективности капитала со своим набором рисков и вознаграждений.

Основной механизм

Проект EigenLayer стал пионером этого подхода, создав систему, в которой валидаторы могут подписаться на защиту Активно валидируемых сервисов (AVS). Это внешние протоколы, которым нужна безопасность, обеспечиваемая реальными деньгами на кону. Для «нативного» рестейкинга валидаторы направляют свои учетные данные для вывода (withdrawal credentials) на EigenPod и делегируют полномочия оператору. В качестве альтернативы держатели токенов ликвидного стейкинга могут внести свои токены в стратегии EigenLayer. В обоих случаях участники обязуются следовать правилам выбранных ими AVS, и нарушение этих правил влечет за собой дополнительные штрафы слэшинга в дополнение к любым наказаниям на уровне самого Ethereum.

Множество протоколов теперь могут подключаться к массивному набору валидаторов Ethereum и миллиардам долларов, которые стоят за ними. Это обеспечивает разделяемую безопасность вместо создания отдельных систем с нуля. AVS охватывают широкий спектр приложений: уровни доступности данных типа EigenDA, сети оракулов, предоставляющие ценовые фиды, межсетевые мосты, секвенсоры роллапов и автоматизированные сети «киперов», поддерживающие DeFi-протоколы. Каждый AVS определяет собственные условия слэшинга — конкретные правила, которые валидаторы должны соблюдать, чтобы избежать штрафов. Сервис доступности данных может потребовать от валидаторов доказательства хранения определенных данных, в то время как сеть оракулов может слэшнуть валидаторов, чьи ценовые котировки слишком сильно отклоняются от консенсуса.

Техническая архитектура

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

Контракты стратегий (Strategy contracts) обрабатывают депозиты и выводы для рестейкинга на базе ERC-20. Когда пользователи вносят LST или другие поддерживаемые токены, эти стратегии отслеживают право собственности и управляют базовыми активами. Каждая стратегия представляет отдельный рестейкнутый токен: одна для stETH, другая для cbETH, EIGEN и так далее. Нативный рестейкинг отслеживается отдельно через EigenPods — экземпляры контрактов, которые удерживают учетные данные вывода валидатора и учитывают рестейкнутые в Beacon Chain эфиры. Такое модульное разделение позволяет EigenLayer поддерживать как производные ликвидного стейкинга, так и нативный стейкинг, избегая использования одного монолитного контракта для всех типов активов.

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

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

Различные AVS используют разные системы доказательств в зависимости от своих потребностей в безопасности. Некоторые полагаются на доказательства мошенничества (fraud proofs), которые предполагают честное поведение, если оно не оспорено. Если кто-то обнаружит нарушение в течение окна оспаривания, он может предоставить доказательства, запускающие слэшинг. Другие используют доказательства валидности (validity proofs) на базе криптографии с нулевым разглашением, которые математически гарантируют корректность перед любым изменением состояния. Третьи зависят от подписей комитета доверенных сторон, что быстрее и проще, но вводит предположения о доверии к честности и доступности этого комитета.

Модель безопасности EigenLayer включает комитеты вето как дополнительный уровень для критических решений по слэшингу. Вместо того чтобы разрешать немедленный автоматический слэшинг за любые нарушения, некоторые условия требуют одобрения комитета. Это предотвращает поспешное или ошибочное применение наказаний. Представь ошибку в AVS, которая неверно помечает честное поведение как вредоносное. Комитет вето может приостановить слэшинг, расследовать проблему и предотвратить несправедливые штрафы. Однако это вносит риск управления и потенциальные задержки в применении законных наказаний. Сама конструкция и реализация комитета вето эволюционировали вместе с запуском слэшинга, поэтому детали могут меняться.

Возможно, наиболее интригующим является то, что EigenLayer вводит интерсубъективный слэшинг, при котором некоторые нарушения не могут быть доказаны чисто программно (on-chain) и вместо этого полагаются на общее человеческое суждение (социальный консенсус) для принятия решения о наказании. Рассмотрим AVS-оракул, где валидаторы должны сообщать точные данные о цене. Если валидатор сообщает явно неверную цену (утверждая, что ETH торгуется по $1, когда все биржи показывают $3 000), нарушение очевидно для людей, но его трудно доказать в блокчейне без введения централизованных ценовых фидов. Интерсубъективный слэшинг позволяет разрешать такие случаи через социальный консенсус и процессы управления. Держатели токенов или назначенные комитеты голосуют за проведение слэшинга на основе внесетевых (off-chain) доказательств. Такая гибкость позволяет системе справляться со сложными сценариями реального мира, которые могут упустить чисто алгоритмические подходы, но она несет в себе риски управления и потенциал для спорных решений, разделяющих сообщество.

Текущая экономическая реальность

На бумаге рестейкинг выглядит как чистая победа: больше протоколов могут «арендовать» безопасность Ethereum вместо того, чтобы создавать собственные наборы валидаторов. На практике система всё еще находится на ранней стадии и несколько перекошена. Огромное количество ETH и токенов ликвидного стейкинга было рестейкнуто в EigenLayer и обертки ликвидного рестейкинга (LRT), но лишь подмножество AVS видит значимый реальный спрос сегодня. Большая часть дополнительных наград, которые сейчас получают рестейкеры, поступает из программ стимулирования, аирдропов и эмиссии токенов протоколов, а не от устойчивых доходов от комиссий, генерируемых самими AVS. На данный момент рестейкинг ведет себя не как зрелый класс активов с денежным потоком, а скорее как ставка с кредитным плечом на будущий успех экосистемы EigenLayer.

Это несовпадение во времени имеет большое значение. Дополнительные обязательства активны уже сегодня (добавочный риск смарт-контрактов, риск управления и риск коррелированного слэшинга в нескольких AVS), в то время как долгосрочные рынки комиссий, которые должны компенсировать риски рестейкерам, всё еще проектируются и проходят проверку боем. Когда ты слышишь заявления о «повторном использовании безопасности» или «разблокировании эффективности капитала», стоит помнить, что многие рестейкеры сейчас принимают на себя огромные хвостовые риски ради экономики, которая зависит от текущих стимулов и пока еще неопределенной кривой принятия AVS.

Ландшафт рисков

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

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

Задержки вывода средств могут длиться значительно дольше стандартных периодов разблокировки Ethereum. EigenLayer добавляет собственный период эскроу продолжительностью около двух недель (в настоящее время около 14–17 дней в зависимости от версии контракта) поверх таймингов выхода из Beacon Chain. Отдельные AVS или протоколы LRT (Liquid Restaking Token) могут накладывать дополнительные ограничения на вывод поверх этого.

Экосистема ликвидного рестейкинга вносит системные риски, которые накладываются на риски ликвидного стейкинга, обсужденные ранее. Могут возникнуть «каскады ликвидности», если токены LRT потеряют привязку (peg) к базовому ETH, что потенциально спровоцирует массовые выводы средств, создающие разрушительные петли обратной связи во всей экосистеме рестейкинга. Существует также риск базиса между доходностью базового стейкинга ETH и ценами токенов LRT, что усложняет жизнь пользователям, ожидающим предсказуемой доходности. Когда ты накладываешь рестейкинг поверх протоколов ликвидного стейкинга типа Lido или Rocket Pool, ты суммируешь несколько слоев риска смарт-контрактов, экономических допущений и потенциальных точек отказа.

Раздел I: Архитектура и исполнение

Solana представляет собой принципиально иной подход к масштабированию блокчейна. В то время как Ethereum (Глава II) и Bitcoin (Глава I) также являются блокчейнами первого уровня (L1) — то есть базовыми сетями, которые работают независимо и сами рассчитывают свои транзакции, — Solana идет на радикально иные инженерные компромиссы. Она ставит в приоритет чистую скорость и пропускную способность, а не низкие аппаратные требования, делая ставку на то, что мощные компьютеры будут дешеветь быстрее, чем будет расти спрос на блокчейн.

Большинство блокчейнов исполняют транзакции по одной внутри блоков. Когда ты отправляешь транзакцию в Ethereum, она ждет в очереди за всеми остальными и обрабатывается последовательно, чтобы избежать конфликтов. Масштабирование там обычно происходит за счет добавления сетей второго уровня (Layer 2) поверх основной, как описано в Главе II. Такой подход сохраняет умеренные требования к валидаторам и максимизирует децентрализацию, но вносит фрагментацию. Пользователям приходится перемещаться между разными сетями с разными токенами для оплаты комиссий, мостами и слоями совместимости.

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

Эта модель параллельного исполнения формирует архитектуру данных Solana. Состояние организовано вокруг модели аккаунтов, которая четко отделяет код программы от пользовательских данных. Программы живут в исполняемых аккаунтах, код которых фактически неизменяем. Пользовательское состояние живет в отдельных аккаунтах данных, которыми владеют эти программы. Компонуемость (composability) — способность программ взаимодействовать друг с другом — здесь прямолинейна. Программы вызывают друг друга через межпрограммные вызовы (CPI): по сути, одна программа просит другую выполнить операцию, передавая аккаунты в качестве входных данных. Среда выполнения (runtime) может проверить наличие всех необходимых аккаунтов еще до начала исполнения.

Типы адресов и управление аккаунтами

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

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

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

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

Аккаунты должны поддерживать минимальный баланс в лампортах (lamports — наименьшая единица Solana, аналогичная сатоши в Биткоине), чтобы оставаться «освобожденными от аренды» (rent-exempt). Это предотвращает раздувание состояния сети, требуя экономического обязательства за долгосрочное хранение данных. На практике это работает как авансовый залог за использование дискового пространства, а не как ежемесячная подписка.

Эти ограничения на исполнение и модель аккаунтов определяют то, как пользователи совершают транзакции. Следующий раздел рассматривает структуру транзакций, механику комиссий и пользовательский опыт (UX), который они обеспечивают.

Раздел II: Транзакции, комиссии и UX

Модель транзакций

Каждая транзакция включает сообщение (содержащее список аккаунтов, инструкции и недавний хеш блока — recent blockhash) вместе с необходимыми подписями Ed25519. Ed25519 — это современный алгоритм цифровой подписи, известный своей скоростью и безопасностью. За каждую транзакцию уплачивается базовая комиссия в размере 5 000 лампортов (примерно одна десятая цента за подпись). Пользователи также могут назначить бюджет вычислений (compute budget) и платить приоритетные комиссии за единицу вычислений, фактически обменивая деньги на скорость обработки. Лимиты единиц вычислений служат двум целям: они обеспечивают справедливость распределения ресурсов между пользователями и помогают планировщику (scheduler) предсказать время исполнения для оптимального параллелизма.

Политика комиссий значительно эволюционировала. Приоритетные комиссии полностью достаются текущему лидеру (валидатору, создающему текущий блок), в то время как базовые комиссии делятся между сжиганием и вознаграждением валидаторов (подробнее в Разделе IV). Важнейшим новшеством здесь являются локальные рынки комиссий, которые оценивают перегрузку на уровне конкретного аккаунта, а не всей сети. Глобальный рынок комиссий Ethereum (Глава II) работает иначе: все транзакции конкурируют за одно и то же место в блоке независимо от того, с какими контрактами они взаимодействуют. В идеале локальные рынки комиссий означают, что за взаимодействие с перегруженными аккаунтами платят больше, не снижая производительность для остальной части сети. На практике текущая реализация несовершенна. Во время экстремальных всплесков спама в 2024 и 2025 годах перегруженный трафик всё равно снижал общую производительность и приводил к повышенному уровню отброшенных транзакций.

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

Важно различать «отброшенные» (dropped) и «неудачные» (failed) транзакции. Отброшенные транзакцииникогда не попадают в блок из-за перегрузки сети, недостаточных приоритетных комиссий или истечения срока действия хеша блока; они не оставляют записи в блокчейне. Неудачные транзакции фактически обрабатываются и включаются в блок, но их выполнение отменяется (revert) из-за логических ошибок программы или невыполненных условий (например, избыточного проскальзывания цены). На практике пользователи и приложения смягчают проблему отброшенных транзакций, повторяя попытки с более высокими приоритетными комиссиями или используя сервисы, которые пересылают транзакции сразу нескольким лидерам.

Преимущество пользовательского опыта (UX)

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

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

Сеть значительно эволюционировала, пройдя через операционные трудности. Ранняя Solana страдала от сбоев, связанных с перегрузками, что часто подчеркивали критики. В частности, в феврале 2024 года в Solana произошел сбой длительностью около пяти часов, вызванный багом в кэше загрузчика программ. Тем не менее, системные обновления сетевого взаимодействия, распространения блоков и производительности среды выполнения значительно снизили частоту и тяжесть этих проблем, обеспечив более высокий уровень включения транзакций и общую надежность.

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

Раздел III: Консенсус, планирование и сетевое взаимодействие

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

Фундамент: Proof of History

На базовом уровне находится Proof of History (PoH) — механизм криптографического хронометража Solana. Представь это как проверяемые часы, которые создают непрерывную последовательность хешей, чтобы все могли договориться об относительном порядке событий еще до того, как они будут добавлены в блокчейн. PoH создает историческую запись, подтверждающую, что события произошли в определенной последовательности. Это позволяет валидаторам договариваться о порядке транзакций без длительного обмена сообщениями друг с другом. Эта система упорядочивания становится фундаментом для всего остального.

Консенсус, построенный на времени: Tower BFT

Tower BFT использует временные метки PoH для управления финальностью. Вместо того чтобы заставлять валидаторов постоянно общаться по поводу порядка блоков, Tower BFT использует запись временных меток как общую точку отсчета. Валидаторы отдают голоса за блоки (в зависимости от своего стейка), а временные метки PoH помогают предотвратить двусмысленность (голосование за конфликтующие блоки). Это обеспечивает гарантированную финальность в настоящее время примерно через 12,8 секунды, хотя на практике пользователи ощущают более быструю экономическую финальность, так как отмена транзакций становится крайне маловероятной уже после нескольких подтверждений.

Планирование лидеров и маршрутизация транзакций

Механизм хронометража PoH делает возможным предсказуемое планирование лидеров. Лидеры назначаются заранее в коротких слотах (примерно по 400 миллисекунд каждый). Слоты организованы в эпохи — периоды длительностью около двух дней, в течение которых график валидаторов остается фиксированным. В начале каждой эпохи сеть определяет, какие валидаторы будут лидерами в каких слотах на основе их стейка. Твой стейк определяет шансы быть выбранным лидером, с учетом периодов «разогрева» и «охлаждения» (warmup/cooldown) и некоторой случайности в графике.

Это предсказуемое планирование делает возможным Gulf Stream — протокол пересылки транзакций Solana. В отличие от блокчейнов, которые транслируют транзакции в публичный мемпул (как Bitcoin и Ethereum, описанные в Главах I и II), Solana отправляет их напрямую текущему и следующим лидерам. Такая прямая маршрутизация сокращает задержки, исключая фазу широковещательной рассылки, где транзакции иначе ждали бы в публичном пуле. Транзакции могут быть пересланы будущим лидерам еще до начала их слота, что позволяет мгновенно подтверждать их, как только слот лидера начнется.

Распространение данных: Turbine

Как только лидеры создают блоки, им нужно эффективно распространить их среди тысяч валидаторов. Turbineрешает это, разбивая блоки на маленькие фрагменты, называемые «шредами» (shreds). Вместо того чтобы отправлять целые блоки от точки к точке, Turbine организует валидаторов в древовидную структуру, где каждый узел получает шреды и пересылает их небольшой группе других валидаторов. Система включает избыточность при кодировании данных, поэтому даже если часть шредов потеряется в пути, валидаторы смогут восстановить целый блок из тех фрагментов, что они получили. Это предотвращает всплески нагрузки на пропускную способность и делает сеть устойчивой к целевому спаму против отдельных валидаторов.

Сетевая инфраструктура: QUIC

Базовый транспортный слой использует QUIC — современный интернет-протокол, разработанный для более быстрых и надежных соединений, чем традиционные решения. QUIC может обрабатывать несколько потоков данных через одно соединение, быстрее восстанавливается при потере пакетов и быстрее устанавливает связь. Solana реализует «Stake-weighted Quality of Service» (качество обслуживания на основе стейка) поверх QUIC, что означает, что валидаторы с большим стейком получают приоритет в пропускной способности. Это делает сеть более устойчивой к спаму от субъектов с малым весом в системе.

DoubleZero: Выделенная оптоволоконная инфраструктура

В то время как QUIC оптимизирует отдельные соединения, DoubleZero решает более фундаментальную проблему: ограничения самого публичного интернета. DoubleZero — это частная сетевая надстройка, соединяющая валидаторов через выделенные оптоволоконные линии — ту же инфраструктуру, на которую полагаются традиционные биржи, такие как Nasdaq и CME, для передачи данных на микросекундном уровне.

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

Это особенно важно для обновлений консенсуса, описанных ниже. Модель финальности Alpenglow зависит от того, получают ли валидаторы сообщения и отвечают ли на них в очень узких временных окнах. Если распространение идет нестабильно, голоса приходят с опозданием, формирование кворума замедляется, и финальность занимает больше времени. Сокращая разрыв в задержках между валидаторами, DoubleZero обеспечивает более быструю финализацию и более равномерное распространение блоков. Инфраструктура также поддерживает мультикаст (multicast), тиражируя данные внутри сети и доставляя их валидаторам одновременно, а не через последовательные соединения «точка-точка».

Alpenglow: Обновление всего стека

Интегрированная система из PoH, Tower BFT, Gulf Stream, Turbine и QUIC, описанная выше, представляет собой текущую рабочую инфраструктуру Solana, развивавшуюся годами. Понимание этого фундамента важно, потому что Alpenglow — запланированное обновление — представляет собой фундаментальный отход от него. Вместо того чтобы постепенно улучшать отдельные компоненты, Alpenglow полностью перестраивает ядро консенсуса и коммуникацию при голосовании.

Alpenglow заменяет основные механизмы консенсуса переработанными альтернативами. Votor, новый метод голосования, позволяет валидаторам обмениваться голосами напрямую друг с другом и формировать сертификаты, доказывающие, что достаточное количество стейка пришло к согласию. Это заменяет Tower BFT в качестве основного механизма финальности. Вместо того чтобы выстраивать цепочки из нескольких раундов голосования, как делает Tower BFT, валидаторы агрегируют голоса вне сети и подтверждают финальность за один-два раунда.

Votor запускает два пути финализации параллельно, адаптируясь к условиям сети. Если блок получает подавляющую поддержку (80% стейка и более) в первом раунде, он финализируется немедленно. Если поддержка составляет от 60% до 80%, начинается второй раунд. Если второй раунд также преодолевает порог в 60%, блок финализируется. Такой дизайн обеспечивает финальность даже когда части сети недоступны, позволяя системе работать стабильно, а не замирать.

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

Alpenglow также вводит модель устойчивости «20+20»: безопасность (safety) сохраняется до тех пор, пока не более 20% общего стейка ведет себя злонамеренно, а живучесть (liveness) сохраняется, даже если дополнительные 20% находятся в офлайне. Это означает, что Alpenglow может выдержать до 40% сети в нерабочем или враждебном состоянии, сохраняя финальность — значительное улучшение по сравнению с текущими порогами.

В рамках Alpenglow механизм Proof of History фактически выводится из эксплуатации. Система заменяет PoH фиксированным графиком слотов и локальными таймерами, удаляя ключевой архитектурный элемент, определявший Solana с момента её создания. Это самое значительное изменение на уровне протокола в истории сети.

В симуляциях Alpenglow достигает медианной финальности около 100–150 миллисекунд (по сравнению с нынешними 12,8 секундами). Это цифры на основе симуляций, которые еще не учитывают полные вычислительные издержки. Помимо чистой производительности, быстрая финальность дает преимущества в безопасности: она сокращает окно, в течение которого атакующий может попытаться реорганизовать недавние блоки, и ограничивает возможности для определенных видов арбитража.

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

MEV и создание блоков

В условиях маршрутизации через Gulf Stream и потенциально более быстрой финальности Alpenglow, динамика извлечения ценности и упорядочивания транзакций становится особенно важной.

Лидероцентричная архитектура, при которой Gulf Stream направляет транзакции напрямую лидерам, имеет последствия, выходящие за рамки задержек. В большинстве блокчейнов ожидающие транзакции находятся в публичной зоне ожидания (мемпуле), где любой может их увидеть до включения в блок. Эта видимость позволяет извлекать MEV (максимальную извлекаемую ценность, подробно в Главе VIII) — прибыль от переупорядочивания, вставки или цензурирования транзакций. Трейдеры могут увидеть твой ожидающий обмен и поставить свою сделку первой, зарабатывая за твой счет. Поскольку Solana направляет транзакции напрямую лидерам, её MEV-ландшафт устроен иначе.

Многие валидаторы сейчас запускают Jito-Solana — модифицированный клиент, позволяющий проводить аукционы «бандлов» (пакетов транзакций). Это опциональная инфраструктура (не встроенная в протокол), получившая широкое распространение. «Серчеры» (искатели) могут упаковывать транзакции в бандлы, симулировать их вне сети и платить чаевые за включение. Валидаторы, использующие Jito, создают блоки, объединяя обычные транзакции (упорядоченные по приоритетным комиссиям) и прибыльные бандлы (упорядоченные по чаевым). Эта система возникла органично, создав MEV-рынок, интегрированный на уровне валидаторов, а не через отдельные ретрансляторы.

Два дополняющих тренда еще сильнее меняют этот слой создания блоков. BAM (Block Assembly Marketplace) — это переосмысление конвейера транзакций от Jito. Вместо того чтобы лидер слота единолично определял порядок, BAM вставляет рыночный слой и слой конфиденциальности, разделяя упорядочивание и исполнение. Транзакции попадают в доверенные среды исполнения (TEE), что означает: ни валидаторы, ни создатели блоков не видят «сырое» содержание транзакций до того, как установится их порядок. Это предотвращает оппортунистическое поведение вроде фронтраннинга.

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

Raiku: Гарантии детерминированного исполнения

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

Raiku заполняет этот пробел. Он предоставляет слой планирования и аукционов, который работает рядом с набором валидаторов Solana, давая приложениям программируемую детерминированную среду предварительного исполнения без изменения консенсуса L1. Raiku достигает гарантированного исполнения через два типа транзакций: Ahead-of-Time (AOT) для заранее запланированных рабочих процессов и Just-in-Time (JIT) для нужд исполнения в реальном времени. Этот инфраструктурный слой позволяет приложениям предлагать гарантии исполнения, приближающиеся к централизованным системам, сохраняя преимущества расчетов в блокчейне.

Техническая инфраструктура, описанная в этом разделе, формирует затраты и потоки доходом, которые определяют, кто участвует в сети и как.

Раздел IV: Экономика, стейкинг и управление

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

Токеномика и денежно-кредитная политика

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

График инфляции начался с 8% в год и снижается на 15% ежегодно (темп дезинфляции), пока не достигнет конечного уровня в 1,5% годовых. Этот уровень должен быть достигнут примерно к 2031 году, после чего инфляция стабилизируется навсегда. Такой дизайн гарантирует достаточное вознаграждение за стейкинг для мотивации валидаторов даже по мере взросления сети, избегая при этом гиперинфляции, которая обесценила бы токен за десятилетия.

Однако инфляция — это лишь одна сторона уравнения. Сжигание комиссий вносит дефляционное давление. Solana навсегда сжигает 50% базовой комиссии за транзакцию, выводя SOL из обращения; остальные 50% идут лидеру блока. Приоритетные комиссии (чаевые за вычисления) полностью достаются лидеру и не сжигаются.

В периоды экстремальной активности скорость сжигания теоретически может превысить инфляцию, делая SOL временно дефляционным. На практике текущий объем транзакций не достигает этого порога стабильно, но механизм создает прямую связь между использованием сети и динамикой предложения токенов.

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

Механика стейкинга и экономика валидаторов

Стейкинг в Solana работает через модель делегирования, при которой держатели SOL могут делегировать токены валидаторам, не передавая право владения ими. В отличие от модели Ethereum (Глава II), требующей минимум 32 ETH для соло-валидаторов, Solana позволяет нативно делегировать любую сумму напрямую. Делегаторы получают вознаграждение пропорционально своему стейку за вычетом комиссии валидатора (обычно от 0% до 10%). Это создает конкурентный рынок, где валидаторы должны балансировать между доходом от комиссий и привлечением достаточного стейка для поддержания прибыльности.

Процесс включает временные ограничения. Активация и деактивация стейка происходят на границах эпох (каждые 2–3 дня). Эти задержки предотвращают резкие перемещения капитала, которые могли бы дестабилизировать консенсус.

Экономика запуска валидатора

Экономика валидатора сложна: топовое оборудование, терабайты ежемесячного трафика, корпоративные сети, инфраструктура дата-центров и комиссии за транзакции голосования (около $4 000 в месяц) в сумме дают операционные расходы порядка $5 000 ежемесячно. Также требуются квалифицированные специалисты для поддержания надежности.

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

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

Давление централизации и безопасность сети

Количество валидаторов значительно снизилось — с пика в 2 000 до примерно 800 активных узлов к январю 2026 года. Это порождает вопросы о децентрализации.

Однако само число валидаторов — это лишь часть правды. Важнее то, как стейк распределен между ними. Всего от 19 до 22 крупных валидаторов контролируют достаточно стейка, чтобы достичь «порога суперменьшинства» (примерно одна треть общего стейка) — это объем, необходимый для остановки консенсуса сети.

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

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

Модель безопасности Solana имеет свои особенности. В отличие от большинства PoS-цепей, Solana на данный момент не применяет слэшинг в основной сети. Валидаторы не теряют застейканные SOL автоматически за ошибки вроде голосования за конфликтующие блоки или нахождение в офлайне. Сообщество предпочло избежать случайных потерь стейка из-за честных ошибок, полагаясь на репутацию и упущенную экономическую выгоду как на сдерживающие факторы. Вопрос о том, достаточно ли этих стимулов без автоматических штрафов, остается открытым.

Управление и механизмы обновления

Модель управления Solana не предусматривает обязательного ончейн-голосования. Она опирается на оффчейн-координацию, консенсус валидаторов и влияние Фонда Solana. Это отдает приоритет скорости и прагматизму над формальными демократическими процессами.

Изменения протокола проходят через процесс SIMD (Solana Improvement Document). Любой может предложить SIMD для обсуждения. Существенные изменения требуют поддержки крупных валидаторов и разработчиков. Фонд Solana, наряду с такими игроками, как Solana Labs, Anza, Jump Crypto и Jito Labs, обладает значительным неформальным влиянием.

Валидаторы принимают окончательные решения, выбирая, обновлять ли клиентское ПО. Новые релизы используют «feature gates» — функции, которые по умолчанию отключены. Как только супербольшинство валидаторов обновится и поддержка станет очевидной, основные участники активируют функцию через ончейн-инструкцию.

Эти экономические и операционные реалии напрямую определяют, как разработчики строят приложения на Solana.

Раздел V: Стек разработчика и стандарты

Ограничения, обеспечивающие производительность Solana, формируют весь опыт разработки. Строить на Solana — значит работать в рамках осознанных лимитов, которые делают исполнение кода достаточно предсказуемым для параллельной обработки.

Среда исполнения

Разработчики Solana пишут смарт-контракты в основном на Rust (хотя поддерживаются C/C++). Программы компилируются в портативный формат инструкций, который сеть может проанализировать перед развертыванием, гарантируя, что код не выйдет за пределы «песочницы» и не потребит неограниченные ресурсы.

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

Виртуальная машина Solana (SVM)

Термин SVM охватывает всю среду исполнения Solana: саму виртуальную машину, загрузчики программ, системные вызовы, модель аккаунтов и параллельный планировщик Sealevel.

В своей основе SVM — это регистровая виртуальная машина. В отличие от стековой EVM Ethereum, регистровая VM работает скорее как физический процессор, храня значения в нумерованных регистрах для быстрого доступа. Этот архитектурный выбор обеспечивает более высокую производительность, необходимую для интенсивного параллельного исполнения.

Программы взаимодействуют с блокчейном через узкий набор разрешенных операций: чтение и запись аккаунтов, вызов других программ и доступ к состоянию сети через специальные аккаунты только для чтения — sysvars. В SVM нет доступа к файловой системе или сети. Этот минималистичный интерфейс делает исполнение предсказуемым, а аудит программ — более простым.

Безопасность программ и «песочница»

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

Однако это не защищает от логических ошибок. Большинство крупных взломов на Solana произошли не из-за выхода из «песочницы», а из-за изъянов в логике самих приложений. Это как разница между побегом из тюрьмы и ситуацией, когда охранника убеждают открыть дверь.

Создание программ: Anchor и инструменты разработки

Низкоуровневый интерфейс SVM очень сложен. На практике почти никто не пишет программы напрямую. Фреймворк Anchor стал стандартом де-факто — это как React для веб-разработки.

Anchor автоматизирует нудные и чреватые ошибками аспекты: генерирует IDL (машиночитаемые описания интерфейса), проверяет порядок аккаунтов в транзакциях и предоставляет шаблоны для частых операций (перевод токенов и т.д.). Это ускоряет разработку и сокращает количество багов.

Архитектура токенов: Стандартизация вместо копирования

Подход Solana к токенам раскрывает фундаментальную философию дизайна. Вместо того чтобы каждый токен был отдельным смарт-контрактом, все SPL-токены управляются одной проверенной программой, которую используют все. Создание нового токена не требует развертывания нового кода. Ты просто создаешь аккаунт «минт» (mint), которым управляет существующая программа SPL Token.

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

Ассоциированные токен-аккаунты (Associated Token Accounts) доводят эту стандартизацию до управления счетами. Система автоматически выводит стандартный адрес аккаунта для каждой пары «кошелек-токен». Это исключает ошибки пользователей при отправке токенов на неправильные адреса.

Стандарт Token-2022 развивает эту модель, добавляя новые функции при сохранении обратной совместимости: «хуки» на перевод (transfer hooks) для роялти или комплаенса, конфиденциальные переводы на базе криптографических доказательств и другие расширения.

Управление развернутыми программами

Неизменяемость блокчейна создает проблему: баги случаются, но код вечен. Solana предлагает прагматичное решение через Upgradeable Loader. Программы могут назначить «authority» (обычно мультисиг-кошелек команды), который может развертывать новые версии программы по тому же адресу. Когда программа становится зрелой, это право можно отозвать, сделав её окончательно неизменяемой.

Масштабирование коллекций NFT: Сжатие состояния (State Compression)

Традиционные NFT требуют отдельных аккаунтов для каждого предмета, за которые нужно платить аренду. Для коллекции в 1 миллион NFT это стоило бы около $250 000.

Сжатие состояния решает это с помощью деревьев Меркла. Детальные данные NFT хранятся вне сети (off-chain), а в блокчейне хранится только «корень» дерева — криптографический отпечаток всей коллекции. Чтобы доказать владение, пользователь предоставляет краткое доказательство Меркла.

Экономика меняется радикально: коллекция в 1 миллион NFT обходится дешевле $100 вместо $250 000, что делает возможными игровые ассеты и программы лояльности в промышленных масштабах.

Раздел VI: Производительность и её компромиссы

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

Проблема роста данных

Высокая пропускная способность приводит к быстрому разрастанию блокчейна. Полный архив Solana (около 350 ТБ) растет примерно на 90 ТБ в год. Это создает иную экономику инфраструктуры по сравнению с другими сетями. Хранение архива такого масштаба обходится примерно в $40 000 в месяц. Важно понимать: обычные валидаторы и RPC-узлы обрезают (prune) историю и не сталкиваются с такими требованиями. Эти цифры касаются только архивных узлов.

Стратегии смягчения

Solana решает эти проблемы через два подхода: операционный и архитектурный.

Большинство узлов снижают нагрузку через прунинг (удаление старых данных). Узлы загружаются из «снимков» (snapshots) состояния, а не проигрывают всю историю с нуля, что сохраняет время синхронизации приемлемым. Исторические данные обычно переносятся в специализированную инфраструктуру и сторонние индексаторы.

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

Разнообразие клиентов и Firedancer

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

Solana исторически полагалась на одну ветку кода (Agave и форки типа Jito-Solana). Эта монокультура была слабостью сети. Firedancer, разрабатываемый Jump Crypto, — это независимая реализация валидатора на языке C, призванная устранить эту уязвимость.

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

Переходная версия, Frankendancer, сочетающая сетевые модули Firedancer с рантаймом Agave, вышла в основную сеть в сентябре 2024 года. К началу 2026 года всё еще невозможно запустить полный валидатор Firedancer без компонентов Agave. Полное развертывание остается делом будущего, но сам процесс подталкивает обе команды к улучшению производительности и надежности.

Раздел VII: Соответствие сценариям использования и паттерны дизайна

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

Где Solana сияет

Торговля мемкоинами — здесь Solana нашла идеальное соответствие продукта рынку (PMF). Низкие комиссии и скорость позволяют проводить быстрые экспериментальные сделки. Экосистема сделала ставку на мобильные приложения (Phantom, Moonshot), которые ощущаются как обычные приложения в телефоне, а не сложные блокчейн-плагины.

Помимо спекуляций, эти свойства позволяют создавать сложную финансовую инфраструктуру. Книги лимитных ордеров (CLOB) обеспечивают более эффективное использование капитала, чем пассивные пулы ликвидности (AMM). Solana также позволяет создавать «проактивные AMM», которые следят за внешними рынками в реальном времени.

Видение Solana — стать «децентрализованным Nasdaq». Продукты типа xStocks уже приносят токенизированные акции прямо в сеть, позволяя им торговаться со скоростью блокчейна и преимуществами компонуемости.

Ограничения и компромиссы

Несмотря на силу, архитектура Solana создает компромиссы. Проекты, для которых максимальная децентрализация и низкий порог входа для «домашних» узлов важнее производительности, могут предпочесть другие сети. Среда разработки на Rust также требует более глубоких знаний, чем Solidity в Ethereum, хотя Anchor упрощает задачу.

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

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