Solana – блокчейн первого уровня с единым глобальным состоянием, который пытается увеличивать пропускную способность за счёт параллельного исполнения и мощного оборудования, а не дробления основной сети на отдельные роллапы. Его ключевая идея не сводится к короткому времени блока. Узлы получают проверяемую последовательность времени, заранее знают расписание лидеров и могут одновременно исполнять операции, которые не меняют одни и те же аккаунты.
Такой дизайн хорошо подходит для биржевых книг заявок, платежей и приложений с частыми действиями. Обратная сторона – высокие требования к валидаторам, сложная сетевая инженерия и чувствительность к ошибкам в программном обеспечении. Поэтому Solana стоит оценивать как цельную систему, а не как обещание определённого количества транзакций в секунду.
Proof of History не заменяет консенсус
Proof of History – последовательная цепочка хешей, по которой можно проверить, что между двумя событиями прошло определённое число вычислительных шагов. Она создаёт общий ориентир времени и помогает упорядочивать события без постоянных переговоров каждого узла со всеми остальными. Но PoH не решает, какая ветка реестра является канонической.
За выбор ветки отвечает proof of stake и консенсус Tower BFT. Валидаторы голосуют с весом своего делегированного SOL, а повторные голоса увеличивают период блокировки предыдущих решений. Лидер выбранного слота собирает транзакции, формирует блок и распространяет его частями через протокол Turbine. Другие валидаторы воспроизводят блок и голосуют за наблюдаемую ветку.
В обозревателях встречаются уровни processed, confirmed и finalized. Первый означает, что узел обработал операцию, второй – что за ветку проголосовало достаточно стейка, третий – что блок получил окончательность по правилам сети. Для крупного депозита нельзя заменять требование сервиса словом «успешно» из одного RPC.
Как Solana исполняет транзакции параллельно
Состояние хранится в аккаунтах. Программа содержит исполняемый код, а изменяемые данные лежат в отдельных аккаунтах, переданных инструкции. Транзакция заранее перечисляет аккаунты для чтения и записи. Среда Sealevel видит зависимости до исполнения и запускает независимые операции параллельно. Если две транзакции хотят записать один аккаунт, они должны ждать друг друга.
Это объясняет локальный характер перегрузки. Популярный торговый контракт или токен может конкурировать за один и тот же записываемый аккаунт, хотя в других частях сети остаётся свободная вычислительная ёмкость. Высокая общая производительность не гарантирует одинаковую доступность любого конкретного состояния.
Несколько инструкций одной транзакции атомарны: либо весь набор изменений проходит, либо состояние откатывается. Комиссия при этом списывается и при ошибке, потому что подписи проверены и вычислительная работа уже выполнена. Общий принцип разобран в инструкции о том, почему комиссия сохраняется у неудачной транзакции.
Комиссии и локальные рынки
Комиссия состоит из базовой части за подписи и необязательной платы за приоритет. В текущей модели половина базовой комиссии сжигается, половина достаётся производителю блока, а приоритетная часть полностью направляется валидатору. Приоритет рассчитывается по запрошенному лимиту compute units, поэтому завышенный лимит способен увеличить плату даже при меньшем фактическом расходе.
Планировщик также учитывает блокировки записываемых аккаунтов и стоимость операции. Это создаёт локальный рынок: участники конкретного востребованного состояния конкурируют друг с другом, не обязательно поднимая цену для всей сети. Автоматическая оценка кошелька остаётся прогнозом, а не обещанием включения.
История
Анатолий Яковенко сформулировал идею криптографических часов в 2017 году и опубликовал первую версию whitepaper. В конце того же года к проекту присоединился Радж Гокал, а в 2018 году бывшие коллеги Яковенко по Qualcomm Грег Фицджеральд и Стивен Акридж помогли превратить концепцию в работающий клиент на Rust.
Основная сеть в статусе Mainnet Beta начала работу в марте 2020 года. Быстрый рост DeFi, NFT и торговли выявил пределы ранней реализации: сеть несколько раз останавливалась из-за ошибок, перегрузки или проблем обработки блоков. Восстановление требовало координации валидаторов, что стало одним из главных аргументов критиков.
После особенно сложного периода 2021–2022 годов разработчики усилили управление трафиком, перешли на QUIC, добавили stake-weighted QoS и улучшили планировщик. В 2024 году разработка исходного клиента перешла от репозитория Solana Labs к Agave под управлением Anza. К 2026 году в mainnet выпускались не только Agave и промежуточный Frankendancer, но и самостоятельные версии Firedancer. Это снижает зависимость от одной кодовой базы, хотя совместимость клиентов создаёт собственную область тестирования.
Команда
Анатолий Яковенко и Радж Гокал остаются наиболее заметными сооснователями экосистемы. Solana Labs занимается продуктами и частью программного обеспечения, а не управляет всеми валидаторами. Некоммерческая Solana Foundation поддерживает развитие протокола, делегирование и экосистемные программы.
Anza развивает клиент Agave и исследования нового консенсуса, Jump Crypto создаёт Firedancer. Присутствие отдельных организаций важно: ошибка одной команды не должна автоматически означать ошибку всей сети. Но фактическая независимость определяется не числом репозиториев, а долей активного стейка на каждом клиенте и способностью операторов обновляться без синхронной команды.
Токен SOL и стейкинг
SOL оплачивает комиссии, служит залогом в proof of stake и используется как базовый актив приложений. Делегатор передаёт валидатору вес голоса, но не приватный ключ. Вознаграждение зависит от эмиссии, доли активного стейка, качества голосования и комиссии оператора.
Базовый график начинался с 8% годовой инфляции, снижал её на 15% в год и стремился к долгосрочному уровню 1,5%. Это параметры протокола, а не фиксированная доходность пользователя. Текущий темп нужно проверять через данные сети, потому что длительность эпох и будущие решения управления влияют на фактическую траекторию.
Нативный стейкинг отличается от ликвидного токена стейкинга. Во втором случае добавляются смарт-контракт, оператор пула, ликвидность и возможное отклонение цены производного актива. Перед оценкой доходности полезно отдельно проверить риски валидатора и штрафов в стейкинге.
Что пользователь должен проверять
- Кластер и адрес. Mainnet, devnet и testnet имеют разное состояние, а одинаковое название токена не подтверждает его mint.
- Статус финальности. Для биржи или моста ориентироваться на требуемый уровень подтверждения, а не только на появление подписи.
- Вычислительный лимит. Симуляция помогает оценить compute units, но состояние может измениться до исполнения.
- Программа и полномочия. Проверить адрес программы, возможность обновления и владельца upgrade authority.
- Стейкинг. Сравнить комиссию, аптайм, концентрацию стейка и используемый клиент валидатора.
Главные риски
Первый риск – остановка доступности при программной ошибке. Консенсус может сохранить целостность средств, но приложения и выводы всё равно станут недоступны. Второй – высокие требования к железу и сети, которые сужают круг экономически устойчивых операторов. Третий – концентрация стейка, RPC и инфраструктуры у крупных провайдеров.
Отдельно существуют риски приложений: обновляемые программы, оракулы, мосты, токены с административными ключами и вредоносные подписи. Скорость L1 не делает смарт-контракт безопасным. При межсетевом переводе нужно проверять обе цепочки и маршрут по инструкции о безопасном использовании моста.
Для инвестора важны эмиссия, доля застейканного предложения, распределение валидаторского дохода и спрос на SOL как газ. Эти показатели следует разбирать отдельно от числа транзакций, используя методику о том, как читать токеномику проекта.
Итог: Solana добивается скорости сочетанием криптографических часов, stake-weighted консенсуса, заранее объявленных зависимостей и параллельного исполнения. Сильная сторона сети – единое ликвидное состояние без ожидания между шардами. Основной компромисс – сложный высокопроизводительный клиент и более дорогая инфраструктура валидатора, поэтому надёжность нужно оценивать по разнообразию клиентов, истории сбоев и распределению стейка, а не по одной цифре TPS.
