Solana: Proof of History и параллелизм

В ноябре 2021 года Solana обработала 400,000 транзакций за секунду в стресс-тесте - и через час упала на 17 часов. Сеть, которая заявляет 65,000 TPS и слот каждые 400 миллисекунд, пережила больше 10 крупных outage-ей за два года. Как одна и та же архитектура может быть одновременно самой быстрой и самой нестабильной? Ответ - в четырёх инновациях, каждая из которых выжимает максимум из железа, но создаёт свои точки отказа. Сегодня мы разберём эти четыре механизма: криптографические часы, параллельный runtime, BitTorrent для блоков и forwarding без mempool.

• **DeFi на Solana** обрабатывает ~$2B объёма ежедневно: DEX-агрегаторы (Jupiter), лендинг (Marginfi, Kamino), перпы (Drift) - и всё это при комиссиях ~$0.001 за транзакцию, что невозможно на Ethereum L1
• **Helium** - децентрализованная wireless-сеть - мигрировала с собственного blockchain на Solana в 2023 году: 1 миллион IoT-хотспотов генерируют десятки тысяч транзакций ежедневно, и только throughput Solana позволил обрабатывать их с приемлемым latency
• **Visa** запустила пилот расчётов в USDC на Solana в 2023 году, выбрав сеть за sub-second finality и низкие комиссии - для системы, обрабатывающей 65,000 TPS в реальном мире, важна каждая миллисекунда

Предварительные знания

• The Consensus Problem: Why and How

Proof of History: криптографические часы

Главная проблема распределённых систем - **время**. Когда две ноды на разных континентах создают транзакции «одновременно», кто из них был первым? В Bitcoin этот вопрос решается грубой силой: блок каждые 10 минут, порядок - по цепочке блоков. Но 10 минут - это целая вечность. Анатолий Яковенко, инженер из Qualcomm, задал вопрос иначе: а что если создать **криптографическое доказательство того, что время прошло**, не полагаясь на часы других нод?

**Proof of History (PoH)** - это последовательная цепочка SHA-256 хешей, где каждый следующий хеш вычисляется от предыдущего. Это **verifiable delay function (VDF)**: невозможно вычислить хеш номер 1,000,000 не вычислив все предыдущие 999,999 хешей. Зато **проверить** можно параллельно - разделить цепочку на сегменты и проверять одновременно на разных ядрах.

PoH - это **не консенсус**. Это криптографические часы, которые дают всей сети единую точку отсчёта времени. Консенсус в Solana обеспечивает **Tower BFT** - модификация PBFT, которая использует PoH как источник времени вместо сетевых таймаутов. В классическом PBFT ноды обмениваются сообщениями «я готов», «я проголосовал», «я подтвердил» - и ждут ответов. Tower BFT заменяет эти таймауты на PoH-тики: голос валидатора «экспирируется» после определённого числа тиков, а не после wallclock-таймаута. Это снижает message complexity с O(n^2) до O(n).

**Почему SHA-256, а не специальный VDF?** Исследователи предлагали VDF на основе RSA или эллиптических кривых (Boneh et al., 2018), но SHA-256 имеет два преимущества: 1. десятилетия криптоанализа подтверждают его безопасность 2. hardware-ускорение SHA-256 хорошо изучено - валидаторы Solana используют GPU для параллельной верификации PoH-цепочки.

Sealevel: параллельное выполнение транзакций

Ethereum выполняет транзакции **строго последовательно**: EVM берёт транзакцию из блока, меняет глобальное состояние (balance, storage), берёт следующую. Даже если Алиса переводит Бобу, а Чарли деплоит контракт - они обрабатываются одна за другой. Почему? Потому что EVM работает с **глобальным состоянием**: любая транзакция может прочитать или изменить любой слот storage любого контракта. **Sealevel** - runtime Solana - решает эту проблему через радикально иную модель: **каждая транзакция заранее объявляет, какие аккаунты она будет читать и записывать**.

Ключевое отличие Solana от EVM: **программы (smart contracts) stateless - они не хранят данные**. Всё состояние живёт в **аккаунтах**, а программы - это чистые функции, которые принимают аккаунты на вход, обрабатывают и возвращают изменённое состояние. Это как разница между ООП и функциональным программированием: - **EVM**: объект `Contract` хранит свои данные внутри (storage slots), метод `transfer()` меняет внутреннее состояние - **Sealevel**: функция `process_transfer(account_a, account_b, amount)` принимает аккаунты как аргументы, модифицирует их, возвращает результат

Sealevel использует **read/write locks** на уровне аккаунтов - по аналогии с базами данных: - Несколько транзакций могут **читать** один аккаунт одновременно (shared read lock) - Только одна транзакция может **писать** в аккаунт (exclusive write lock) - Если транзакция объявила `isWritable: true` для аккаунта - другие транзакции с тем же аккаунтом ждут На практике это даёт значительный параллелизм: в типичном блоке Solana ~70-80% транзакций работают с разными аккаунтами и выполняются параллельно на разных ядрах CPU.

**Почему Ethereum не может просто добавить параллелизм?** Проекты вроде **Sei** и **Monad** реализуют **optimistic parallel execution**: запускают транзакции параллельно, а если обнаруживают конфликт - откатывают и перевыполняют последовательно. Это работает, но менее эффективно, чем подход Solana, где конфликты известны **до** выполнения. Цена за параллелизм Solana - разработчик обязан заранее перечислить все аккаунты, что усложняет некоторые паттерны (например, composability между DeFi-протоколами).

Turbine: распространение блоков как BitTorrent

Solana производит блоки каждые ~400 мс. При throughput в тысячи транзакций блок может весить **сотни килобайт**. Если лидер отправляет блок **каждому** валидатору напрямую - при 2,000+ валидаторов это гигабайты исходящего трафика за секунду. В Ethereum это не проблема: блок раз в 12 секунд, ~100 KB. В Solana при 400 мс на блок и 2,000 валидаторов - прямая рассылка физически невозможна. **Turbine** решает эту задачу, разбивая блок на мелкие пакеты и распространяя их иерархически - по принципу BitTorrent.

Turbine работает в три этапа: 1. **Shredding** - лидер разбивает блок на **shreds** (фрагменты по ~1280 байт, размер UDP-пакета) 2. **Erasure coding** - добавляет избыточные shreds через Reed-Solomon коды: из 32 shreds данных создаётся 32 parity-shreds, и для восстановления блока достаточно **любых 32 из 64** 3. **Tree propagation** - валидаторы организованы в дерево (turbine tree): лидер отправляет shreds первому слою, те - второму, и так далее

**Почему erasure coding критически важен при turbine tree?** Если нода на слое 1 упала или злонамеренна - все 200 нод слоя 2, которые от неё зависят, не получат shreds. Reed-Solomon codes позволяют восстановить полный блок из **любых 50%** пакетов. Даже если половина нод на пути молчит - блок восстанавливается. Для сравнения: в Ethereum gossip-протокол пересылает **весь блок целиком** каждому пиру. Это надёжно, но медленно и дорого по bandwidth. Turbine жертвует простотой ради пропускной способности - и это критично при 400 мс на блок.

**Turbine tree - вектор атаки.** Злонамеренный валидатор на слое 1 может целенаправленно не пересылать shreds, создавая «тень» для всех нод ниже по дереву. Solana митигирует это через: 1. рандомизацию позиций в дереве каждый слот 2. erasure coding для восстановления потерь 3. repair-протокол - ноды запрашивают недостающие shreds у соседей. Тем не менее, атаки на turbine tree были реальным вектором при outage-ах Solana в 2022.

Gulf Stream: forwarding без mempool

В Bitcoin и Ethereum транзакции попадают в **mempool** - очередь неподтверждённых транзакций. Каждая нода хранит свою копию mempool-а, и когда наступает время создать блок, лидер (майнер/валидатор) выбирает транзакции оттуда. Проблема: mempool - это **10,000+ нод**, каждая из которых хранит и ретранслирует одни и те же транзакции. На пике нагрузки mempool Ethereum может содержать 100,000+ транзакций, занимая гигабайты RAM. Solana отказывается от mempool полностью. **Gulf Stream** перенаправляет транзакции **напрямую ожидаемому лидеру** - ещё до того, как он начнёт производить блок.

Это возможно благодаря **Leader Schedule** из PoH: расписание лидеров известно на всю эпоху (~2 дня вперёд). Каждый валидатор знает, кто будет лидером через 2-3 слота. Поэтому вместо broadcast в mempool клиент (кошелёк) отправляет транзакцию **текущему лидеру и нескольким следующим по расписанию**.

**Trade-off**: Gulf Stream перекладывает больше доверия на leader schedule. Если лидер злонамеренный - он видит входящие транзакции раньше всех и может извлекать MEV (Maximal Extractable Value). В Ethereum существует **PBS (Proposer-Builder Separation)** и **MEV-Boost** для разделения ролей. В Solana аналогичную роль играет **Jito** - protocol-aware MEV infrastructure: - **Jito Block Engine** - внешний builder, который собирает bundles транзакций - **Jito-Solana** - модифицированный клиент, принимающий bundles от block engine - **Tips** вместо priority fees - MEV-searchers платят tips за включение bundle Jito MEV-протокол обрабатывает ~50-60% транзакций в Solana mainnet, что делает его де-факто стандартом.

Gulf Stream также влияет на **confirmation latency**. Поскольку транзакция попадает к лидеру практически мгновенно (1-2 сетевых хопа вместо gossip по всей сети), подтверждение приходит за ~400 мс (один слот). Для сравнения: - **Bitcoin**: ~60 минут (6 подтверждений) - **Ethereum**: ~12 секунд (1 слот) + ~13 минут для finality (2 эпохи) - **Solana**: ~400 мс (optimistic confirmation), ~12-13 секунд (rooted finality - когда 2/3+ валидаторов подтвердили)

**QUIC вместо UDP.** Изначально Solana использовала raw UDP для Gulf Stream. Это привело к spam-атакам в 2022: боты заливали лидера миллионами транзакций. В 2023 Solana перешла на **QUIC** (HTTP/3 transport) - это обеспечило rate limiting на уровне транспорта, TLS-аутентификацию и flow control. Переход на QUIC значительно снизил успешность spam-атак.

Итоги

• **Proof of History** - последовательная SHA-256 хеш-цепочка, работающая как криптографические часы: генерация строго последовательна (O(N)), а верификация параллельна (O(N/k)). PoH - не консенсус, а **источник времени**, который Tower BFT использует вместо сетевых таймаутов, снижая message complexity до O(n)
• **Sealevel** выполняет транзакции **параллельно**, потому что каждая транзакция заранее объявляет свои аккаунты (read/write). Программы stateless, состояние в аккаунтах - read/write locks позволяют Sealevel распределять независимые транзакции по ядрам CPU без speculative execution
• **Turbine** решает проблему bandwidth при 400 мс блоках: shredding (фрагментация на ~1.2 KB), erasure coding (восстановление из 50% пакетов) и tree propagation (иерархическая рассылка с fanout ~200) - вдохновлён BitTorrent
• **Gulf Stream** устраняет mempool: транзакции пересылаются напрямую ожидаемому лидеру, что возможно благодаря детерминистическому leader schedule из PoH. Цена - бОльшее доверие к лидеру (MEV через Jito), но выигрыш - confirmation за ~400 мс
• Помните вопрос из начала: как одна архитектура может быть самой быстрой и самой нестабильной? Каждая из четырёх инноваций (PoH, Sealevel, Turbine, Gulf Stream) оптимизирует свой bottleneck, но создаёт жёсткие зависимости - сбой одного компонента каскадирует на остальные. Это фундаментальный trade-off: максимальная оптимизация vs устойчивость к сбоям

Связанные темы

Solana развивает идеи консенсуса, распределённых систем и параллельных вычислений:

• Проблема консенсуса: зачем и как — Tower BFT построен на идеях PBFT, но заменяет сетевые таймауты на PoH-тики - это снижает message complexity и ускоряет finality
• DAG-based консенсус: Avalanche, Narwhal — Solana и DAG-протоколы решают одну задачу (параллелизм) разными путями: Sealevel параллелит execution внутри одной ноды, Narwhal параллелит data dissemination между нодами
• Move-based блокчейны: Sui и Aptos — Sui использует object-centric модель (похожую на аккаунты Solana) для параллельного выполнения, но с DAG-консенсусом (Narwhal/Bullshark) вместо leader-based Tower BFT
• P2P-сети и gossip-протоколы — Turbine заменяет классический gossip-протокол иерархическим tree propagation - trade-off между latency, bandwidth и отказоустойчивостью

Вопросы для размышления

• Solana требует от валидаторов 256 GB RAM и 10 Gbps соединение. Ethereum работает на 8 GB RAM и домашнем интернете. Какой подход в долгосрочной перспективе лучше для децентрализации - и меняется ли ответ по мере удешевления оборудования?
• Gulf Stream пересылает транзакции напрямую лидеру, давая ему преимущество в виде раннего доступа к транзакциям (MEV). Как бы вы спроектировали систему, которая сохраняет низкий latency Gulf Stream, но снижает MEV-возможности лидера?
• Solana пережила множество outage-ей, тогда как Bitcoin работает без остановки с 2009 года. Означает ли это, что подход Solana (максимальная оптимизация каждого слоя) фундаментально менее надёжен, чем подход Bitcoin (простота + большие запасы по времени)? Или outage-и - это «болезни роста» новой архитектуры?

Связанные уроки

• dist-12-consistency