Архитектура Solana

Зачем это блокчейну?

В предыдущем модуле мы изучили Ethereum — “мировой компьютер” с Тьюринг-полной виртуальной машиной. Ethereum доказал, что на блокчейне можно выполнять произвольные вычисления, но заплатил за это скоростью: ~30 TPS, 12-секундные блоки и ~12.8 минут на финализацию.

Solana задала другой вопрос: что если переосмыслить каждый уровень стека? Вместо одной инновации (PoS вместо PoW) Solana заменила всё: консенсус, рассылку блоков, выполнение транзакций, хранение данных. Результат — ~4,000+ TPS, блоки каждые ~400ms и финализация за ~13 секунд.

# Ethereum vs Solana в числах:
# Ethereum: ~30 TPS, 12s блоки, ~12.8 мин финализация
# Solana:   ~4,000+ TPS, 400ms блоки, ~13s финализация

# Ключевое отличие в подходе:
# Ethereum: один EVM последовательно обрабатывает транзакции
# Solana: Sealevel параллельно обрабатывает независимые транзакции

# Аналогия:
# Ethereum -- один кассир в банке (все стоят в очереди)
# Solana -- 10 кассиров (параллельные очереди, если клиенты не конфликтуют)

Ethereum vs Solana: архитектурное сравнение

Прежде чем углубляться в отдельные инновации, посмотрим на полную картину. Каждый аспект архитектуры Solana отличается от Ethereum — это не “Ethereum, но быстрее”, а принципиально другой подход.

Ключевые архитектурные различия

Консенсус: Ethereum использует Casper FFG + LMD GHOST (два протокола для финализации и выбора форка). Solana использует Proof of History как криптографические часы и Tower BFT для голосования. Мы подробно разберем оба в следующих уроках.

Модель данных: Обе сети используют аккаунты, но в Ethereum контракт хранит и код, и данные в одном аккаунте. В Solana программа (код) и данные — это отдельные аккаунты. Программа stateless — она получает данные как аргументы.

# Ethereum: контракт = код + хранилище (одна сущность)
# contract Counter {
#     uint256 count;  // данные ВНУТРИ контракта
#     function increment() { count++; }
# }

# Solana: программа = только код (stateless)
# Данные хранятся в отдельных аккаунтах, принадлежащих программе
# program Counter {
#     fn increment(ctx: Context) {
#         let counter = &mut ctx.accounts.counter;  // данные СНАРУЖИ
#         counter.count += 1;
#     }
# }

Параллельное выполнение: EVM выполняет транзакции строго последовательно. Sealevel в Solana выполняет параллельно транзакции, которые не конфликтуют по аккаунтам. Для этого каждая транзакция заранее объявляет, какие аккаунты ей нужны (read/write).

Рынок комиссий: В Ethereum единый baseFee для всей сети. В Solana комиссии растут локально — только для “горячих” аккаунтов. Если популярный NFT-минт нагружает один аккаунт, остальные транзакции платят обычную комиссию.

8 инноваций Solana

Solana — это не одна идея, а 8 инноваций, работающих вместе на разных уровнях стека: консенсус, сеть, выполнение, хранение.

Интуитивное объяснение: аналогия с фабрикой

Представьте фабрику по сборке автомобилей:

Алгоритмический уровень: как это работает вместе

# Упрощенный цикл обработки транзакции в Solana:

# 1. Клиент отправляет транзакцию
tx = {
    "program": "counter_program_id",
    "accounts": [
        {"pubkey": "counter_pda", "is_writable": True},   # объявляем write
        {"pubkey": "authority", "is_signer": True},        # объявляем signer
    ],
    "data": b"increment",
}

# 2. Gulf Stream: tx пересылается НАПРЯМУЮ к текущему/следующему лидеру
#    (не ждет в mempool, как в Ethereum)

# 3. Лидер получает tx. PoH дает ей временную метку:
#    hash_n+1 = SHA-256(hash_n || tx_data)

# 4. Sealevel проверяет read/write множества:
#    Если tx_A пишет в account_X, а tx_B читает account_Y --
#    они выполняются ПАРАЛЛЕЛЬНО

# 5. Tower BFT: валидаторы голосуют за блок
#    Lockout удваивается с каждым новым голосом поверх

# 6. Turbine рассылает блок по сети (erasure coding)

# 7. Cloudbreak записывает обновления аккаунтов

Математический уровень: почему это быстрее

Пропускная способность блокчейна ограничена тремя факторами:

TPS = min(
    block_size / avg_tx_size,       # данные в блоке
    execution_capacity / avg_gas,    # вычислительная мощность
    network_bandwidth / block_size   # скорость сети
) / block_time

Solana оптимизирует все три одновременно:

Solana Runtime: SBF vs EVM

Solana использует SBF (Solana BPF) — регистровую машину, компилируемую из Rust. Это фундаментально отличается от стекового EVM:

# EVM: стековая машина
# PUSH1 0x01  -> стек: [1]
# PUSH1 0x02  -> стек: [2, 1]
# ADD         -> стек: [3]        (снять 2, положить сумму)
# SSTORE      -> записать в storage slot

# SBF: регистровая машина
# mov64 r1, 1       -> регистр r1 = 1
# mov64 r2, 2       -> регистр r2 = 2
# add64 r1, r2      -> r1 = r1 + r2 = 3
# stxdw [r10-8], r1 -> записать r1 в память

# Регистровые машины ближе к реальным CPU,
# поэтому JIT-компиляция эффективнее

Alpenglow: следующий консенсус Solana

Важно: Solana движется к замене PoH + Tower BFT на Alpenglow — новый протокол с целевой финальностью ~100-150ms.

Что НЕ меняется: Модель аккаунтов, программы, Sealevel, Anchor — весь стек разработчика остаётся прежним. Alpenglow заменяет только консенсусный слой.

В этом курсе мы изучаем текущий PoH + Tower BFT, так как эти концепции фундаментальны для понимания архитектуры Solana.

Формально это предложение SIMD-0326, проголосованное валидаторами в августе-сентябре 2025 года: 98.27% “за” при 52% участия стейка. Alpenglow состоит из двух независимых механизмов, которые активируются последовательно:

• Votor — новый протокол голосования. Валидаторы шлют голоса не как on-chain транзакции, а как лёгкие UDP-сообщения друг другу, и BLS-агрегация сжимает тысячи подписей в одну. Это освобождает примерно три четверти block-space (раньше votes занимали большую часть TPS) и обеспечивает финальность за один или два раунда (100-150 ms).
• Rotor — замена Turbine для рассылки блоков: один-hop broadcast от лидера через малый набор relay-нод. Rotor включат отдельным SIMD позже; первая фаза Alpenglow стартует с Votor поверх существующего Turbine.

Целевой block time после полного запуска Alpenglow — порядка 200 ms (с текущих ~400 ms), а финальность падает с ~13 секунд до субсекундной. Mainnet-активация запланирована на конец 2026 года после прохождения аудитов и тестов в Agave.

Firedancer: client diversity для Solana

До 2024 года у Solana был фактически один валидаторский клиент — Agave (форк Solana Labs). Это противоположность Ethereum, где client diversity (Geth/Nethermind/Besu/Erigon + Lighthouse/Prysm/Teku/Nimbus) — осознанная защита от сетевых багов одного клиента.

Jump Trading (через Jump Crypto) написала независимую реализацию валидатора с нуля — Firedancer — на C++ с собственным сетевым стеком и target ~1M TPS на commodity hardware. Развёртывание идёт поэтапно:

• Frankendancer — гибрид: сетевой слой Firedancer + runtime Agave. Уже на mainnet с 2024 года; к октябрю 2025 у Frankendancer ~20.9% staked SOL на 207 валидаторах (с 8% в июне).
• Полный Firedancer — независимый клиент целиком (включая runtime). С июля 2025 голосует на mainnet, с октября 2025 производит блоки. К началу 2026 года накоплено 100+ дней runtime, 50K+ блоков и 20M+ голосов на нескольких validators Jump Trading.

Firedancer уже сегодня самый быстрый voter в сети: цикл “получить shred -> replay -> consensus -> отправить vote” укладывается в ~25 ms. С появлением второго независимого клиента у Solana впервые появилась настоящая client diversity — защита от network-halts, аналогичных halt’ам 2021-2022 годов.

Связка обновлений: Firedancer даёт пропускную способность и устойчивость, Alpenglow даёт финальность 100-150 ms. Вместе они формируют Solana 2026: target ~200 ms block time, sub-second finality, multi-client сеть.

Где это используется

Практика

В этом модуле мы будем работать с локальным Solana-кластером:

# Запуск локального валидатора (Docker):
docker compose -f labs/solana/docker-compose.yml up -d

# Проверка:
solana config set --url http://localhost:8899
solana cluster-version
solana airdrop 5

# Позже -- Anchor для разработки программ:
anchor build
anchor test

Что дальше?

В следующем уроке мы подробно разберем Proof of History — криптографические часы Solana. Вы увидите, как последовательная цепочка SHA-256 хешей создает верифицируемое доказательство времени и почему это ключ к быстрому консенсусу.

Solana и TON решают задачу масштабирования принципиально разными подходами: Solana параллелит транзакции внутри одной цепочки через Sealevel и read/write sets, а TON делит саму цепочку на до 2^60 шардов с автоматическим split/merge.