Архитектура 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. Alpenglow объединяет механизмы Votor и Rotor для достижения мгновенной финальности.

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

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

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

Практика

В этом модуле мы будем работать с локальным 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 хешей создает верифицируемое доказательство времени и почему это ключ к быстрому консенсусу.