Конвейеризация транзакций Solana: 4-этапный конвейер TPU

В этом техническом руководстве объясняется 4-этапный конвейер TPU для конвейеризации транзакций Solana и то, как он поддерживает параллельную обработку.

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

Конвейеризация транзакций Solana — это метод, с помощью которого Transaction Processing Unit в Solana проводит входящие транзакции через четыре последовательных этапа: выборка (Fetch), проверка подписи (SigVerify), банковские операции (Banking) и запись (Writing). Несколько пакетов транзакций проходят через эти этапы одновременно, так что пока один пакет записывается в реестр, следующий уже проходит валидацию, а третий уже загружается. Именно эта параллельная обработка позволяет Solana (SOL), нативному активу блокчейна Solana (распределенный реестр, в котором записываются все транзакции), достигать показателей пропускной способности, значительно превышающих большинство сетей Layer-1.

Solana была создана Анатолием Яковенко, бывшим инженером Qualcomm, который опубликовал Whitepaper Proof of History в 2017 году, представив механизм криптографических часов, делающий скорость конвейера возможной. Solana Labs, организация из Сан-Франциско, разработавшая протокол, внедрила конвейеризацию как основную функцию клиента валидатора. Результатом стала сеть, ставшая ведущей платформой для приложений децентрализованных финансов (DeFi), включая децентрализованные биржи, протоколы кредитования и ончейн рынки деривативов, которым требуется завершение транзакций менее чем за секунду.

Широко известная трилемма блокчейна утверждает, что блокчейны могут приоритизировать только два из трех свойств: масштабируемость, безопасность и децентрализованность. Конвейеризация транзакций Solana — это ее архитектурный ответ на проблему масштабируемости. В этой статье рассматривается, что такое конвейеризация, как механически работают четыре этапа TPU, как Proof of History обеспечивает работу конвейера, как Gulf Stream и Turbine обрабатывают входные и выходные данные конвейера, как Sealevel расширяет принцип конвейеризации на выполнение смарт-контрактов, как Solana сопоставляется с Ethereum по архитектуре, и в чем заключаются задокументированные компромиссы и ограничения конвейера.

Содержание

1. Что такое конвейеризация транзакций Solana? (И почему это важно для SOL)
2. Как работает конвейер TPU Solana: объяснение четырех этапов
3. Proof of History: криптографические часы, которые делают конвейеризацию возможной
4. Gulf Stream: как транзакции попадают в конвейер до его готовности
5. Аналогия с конвейером CPU: почему архитектура Solana должна быть знакома инженерам
6. Turbine: как выходные данные конвейера достигают сети
7. Sealevel: конвейеризация, расширенная на выполнение смарт-контрактов
8. Solana против Ethereum: сравнение архитектур конвейеров
9. Ограничения, перегрузки и честные компромиссы архитектуры конвейера Solana
10. Часто задаваемые вопросы о конвейеризации транзакций Solana
11. Конвейеризация транзакций Solana и инвестиционный тезис SOL

Что такое конвейеризация транзакций Solana? (И почему это важно для SOL)

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

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

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

Теоретический TPS Solana, согласно технической документации проекта, составляет примерно 65 000 транзакций в секунду. Это представляет собой максимум конвейера в идеальных условиях. Реальный TPS без учета голосований значительно ниже, обычно в диапазоне от 2000 до 4000 TPS в зависимости от нагрузки сети и состава транзакций. Solana учитывает транзакции голосования валидаторов отдельно от пользовательских транзакций (не являющихся голосованиями); общий показатель TPS, включая голосования, выше, но менее значим как метрика пропускной способности для пользователя. Для сравнения, Ethereum обрабатывает примерно от 15 до 30 транзакций в секунду на уровне Layer-1, а Bitcoin — примерно 7 транзакций в секунду.

Ключевые показатели

Конвейер TPU Solana создает новый блок каждые ~400 мс, что примерно в 30 раз быстрее, чем время блока Ethereum (~12 секунд). Теоретический TPS: ~65 000. Реальный TPS без учета голосований: ~2 000–4 000 (зависит от нагрузки сети).

Примечание к методологии TPS: Цифра ~65 000 является теоретическим максимумом из технической документации Solana. Реальная пропускная способность без учета голосований варьируется в зависимости от условий сети. Транзакции голосования исключены из показателя 2 000–4 000. Данные Ethereum представляют пропускную способность Layer-1 и не включают Layer-2 решения.

Механизм, который делает это возможным, — это Transaction Processing Unit (TPU) Solana, четырехэтапный конвейер, который работает внутри каждого лидера-валидатора. В следующем разделе объясняется, как этот конвейер функционирует механически.

Как работает конвейер TPU Solana: объяснение четырех этапов

Механизм, обеспечивающий скорость Solana, — это четырехэтапный конвейер, размещенный в Transaction Processing Unit (TPU), который работает внутри лидера-валидатора для каждого слота, одновременно обрабатывая несколько пакетов транзакций через специализированное оборудование на каждом этапе.

Что такое Transaction Processing Unit (TPU)?

В Solana Transaction Processing Unit (TPU) — это движок конвейера внутри каждого узла валидатора, который физически выполняет обработку транзакций. Это специфический термин Solana, не имеющий отношения к Tensor Processing Unit от Google, используемому в машинном обучении.

TPU работает исключительно на валидаторе-лидере в течение каждого слота продолжительностью около 400 мс. Не-лидеры запускают модуль валидации транзакций (TVU), который воспроизводит и проверяет блоки, созданные лидером. Solana определяет, какой валидатор выступает в роли лидера, с помощью детерминированного расписания лидеров (Leader Schedule), публикуемого заранее для каждой эпохи (примерно каждые 2–3 дня). Это расписание распределяет слоты лидера для каждого валидатора на основе его веса стейкинга. Именно это расписание делает возможной предварительную маршрутизацию транзакций в Gulf Stream, как описано в разделе Gulf Stream ниже.

Для получения технических подробностей об архитектуре TPU см. официальную документацию Solana по TPU) и документацию Solana по времени слотов.)

Четыре стадии конвейера TPU в Solana

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

1. Fetch (Получение): Сетевой стек получает пакеты необработанных транзакций через QUIC (современный транспортный протокол, заменивший исходное UDP-соединение для лучшего контроля перегрузок). Стадия Fetch — это «приемный док» конвейера. Она извлекает транзакции из предварительно загруженного буфера, который Gulf Stream уже успел заполнить до начала слота (Filled), и передает проверенные пакеты в SigVerify.

2. SigVerify (Проверка подписи): GPU проверяет криптографические подписи входящих транзакций. Каждая транзакция Solana включает одну или несколько цифровых подписей, которые должны быть проверены перед любым изменением состояния. Ускорение с помощью GPU позволяет выполнять тысячи проверок подписей параллельно на этом этапе. SigVerify — это контрольно-пропускной пункт аутентификации: прошедшие проверку транзакции переходят в Banking; не прошедшие — отбрасываются.

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

4. Writing (Запись): NVMe SSD записывают подтвержденные записи реестра на диск, а на этой стадии данные итогового блока транслируются остальной части сети через Turbine. Writing — это стадия диспетчеризации и учета: как только она завершается, блок появляется ончейн и начинается его распространение.

Основная механика конвейеризации работает одновременно на всех четырех этапах. Пока пакет N находится в Banking, пакет N-1 уже в Writing, а пакет N+1 — в SigVerify. Ни одна стадия не ждет, пока другая закончит свой текущий пакет, прежде чем начать следующий. Именно так конвейер достигает параллельной пропускной способности: каждая единица оборудования занята в каждый момент слота.

[НУЖНА ДИАГРАММА: DIAGRAM-01] Четырехстадийный конвейер, показывающий пакеты A, B, C, D на разных этапах одновременно. Пакет A: Writing (NVMe SSD). Пакет B: Banking (CPU). Пакет C: SigVerify (GPU). Пакет D: Fetch (сеть). Стрелки показывают продвижение каждого пакета через этапы И одновременную работу на всех четырех стадиях.

Кто управляет конвейером? Валидаторы и расписание лидеров

Валидаторы Solana — это операторы узлов, которые физически запускают конвейер TPU. Каждый валидатор представляет собой выделенный сервер с программным обеспечением Solana, отвечающий либо за создание блоков (если он является текущим лидером), либо за проверку и воспроизведение блоков, созданных лидером (с использованием TVU).

Расписание лидеров определяет, какой валидатор запускает TPU для каждого слота ~400 мс. Расписание вычисляется детерминировано на основе набора валидаторов с учетом их веса стейкинга в начале каждой эпохи, поэтому валидаторы знают свои предстоящие слоты лидера на несколько дней вперед. Такая предсказуемость позволяет Gulf Stream предварительно направлять транзакции будущему лидеру до начала его слота, гарантируя, что буфер стадии Fetch будет полон в момент начала слота.

Запуск конвейера TPU требует оборудования корпоративного уровня: выделенный GPU для стадии SigVerify, многоядерный CPU для стадии Banking, корпоративные NVMe SSD для стадии Writing и высокоскоростное сетевое соединение для стадии Fetch. Эти требования существенно выше, чем пороги для оборудования валидаторов Ethereum, что создает компромисс в плане централизации, описанный в разделе об ограничениях. Актуальные спецификации оборудования для валидаторов см. в документации по требованиям к валидаторам Solana.)

Proof of History: криптографические часы, делающие конвейеризацию возможной

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

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

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

Анатолий Яковенко представил Proof of History в Whitepaper по Proof of History, опубликованном в 2017 году, опираясь на свой опыт работы с распределенными системами в компании Qualcomm.

PoH — это не Proof of Stake.

Proof of History НЕ является механизмом консенсуса Solana. Это криптографические часы, которые упорядочивают события и доказывают прошедшее время. Solana использует Proof of Stake (а именно Tower BFT, свою реализацию Practical Byzantine Fault Tolerance) в качестве механизма консенсуса, который определяет, какие валидаторы имеют экономическое право на участие и кто из них лидирует в каждом слоте. PoH обеспечивает упорядочивание и синхронизацию. Proof of Stake обеспечивает экономическую безопасность и устойчивость к атаке Сивиллы. Это разные функции.

Для полного объяснения того, как работает Proof of History, включая его криптографическую структуру и связь с механизмом консенсуса Solana, см. наш [специальный пояснительный материал по Proof of History].

PoH предоставляет часы. Gulf Stream гарантирует, что «входящие» конвейера всегда заполнены.

Gulf Stream: как транзакции попадают в конвейер до его готовности

Gulf Stream — это протокол пересылки транзакций Solana, и именно он гарантирует, что стадия конвейера Fetch никогда не простаивает в ожидании поступления транзакций. Большинство блокчейнов хранят неподтвержденные транзакции в глобальном мемпуле, где они ждут, пока какой-либо валидатор их подберет. В Solana нет глобального мемпула. Gulf Stream заменяет эту модель детерминированной предварительной маршрутизацией.

Механизм работает в четыре этапа:

1. Расписание лидеров Solana заранее публикует информацию о том, какой валидатор будет лидировать в каждом предстоящем слоте ~400 мс.
2. Когда пользователь или приложение отправляет транзакцию, Gulf Stream направляет ее напрямую валидатору, который будет лидировать в следующем подходящем слоте, а не в общий пул.
3. К моменту начала слота лидера его буфер на стадии Fetch уже предварительно заполнен транзакциями.
4. Стадия Fetch берет данные из этого предварительно загруженного буфера, а не ждет поступления транзакций во время слота.

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

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

Gulf Stream подключается напрямую к стадии Fetch.

Gulf Stream предварительно направляет транзакции к предстоящему лидеру, используя детерминированное расписание лидеров. Когда активируется стадия Fetch TPU валидатора, она получает данные из предварительно загруженного буфера, а не из глобального мемпула. Вот почему конвейер Solana в обычных условиях редко ждет ввода на стадии Fetch.

Если Gulf Stream является входным механизмом конвейера, то Turbine — выходным.

Аналогия конвейера ЦП: Почему архитектура Solana должна быть знакома инженерам

Конвейер транзакций Solana заимствует тот же архитектурный принцип, который делает современные ЦП быстрыми: конвейерную обработку на уровне инструкций. Это не метафора. Дизайн архитектурно вдохновлен той же техникой пропускной способности, описанной в фундаментальном труде Паттерсона и Хеннесси Computer Organization and Design.

Конвейер инструкций ЦП работает следующим образом. Вместо того чтобы ждать полного завершения всех стадий обработки одной инструкции перед выборкой следующей, ЦП разбивает выполнение на последовательные стадии (Fetch, Decode, Execute, Write-back) и выполняет эти стадии одновременно для разных инструкций. Пока выполняется инструкция N, инструкция N+1 декодируется, а инструкция N+2 уже выбирается. Результатом является увеличение пропускной способности пропорционально количеству стадий конвейера, без необходимости ускорения какой-либо отдельной стадии.

Конвейер TPU Solana применяет тот же принцип к транзакциям. Сопоставление стадий прямое:

[ТРЕБУЕТСЯ ДИАГРАММА: DIAGRAM-02] Диаграмма сравнения бок о бок. Левая сторона: конвейер инструкций ЦП со стадиями Fetch, Decode, Execute, Write-back и волнообразными стрелками, показывающими параллельную обработку инструкций. Правая сторона: конвейер TPU Solana со стадиями Fetch, SigVerify, Banking, Writing и волнообразными стрелками, показывающими параллельную пакетную обработку. Линии сопоставления между аналогичными стадиями.

Где аналогия верна: Обе архитектуры достигают прироста пропускной способности, удерживая все стадии занятыми одновременно. Ни одна из них не ждет завершения одного элемента перед началом следующего. Обе обрабатывают элементы волнами, имея несколько элементов на разных стадиях в любой момент времени. Фундаментальное понимание идентично: последовательная обработка растрачивает мощности оборудования; параллелизм конвейера устраняет эту растрату.

Где аналогия нарушается: Три важных различия отличают конвейер Solana от конвейера ЦП.

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

Во-вторых, режимы сбоев различаются. Опасности конвейера ЦП включают зависимости данных (одной инструкции нужен результат предыдущей инструкции, которая еще не завершена) и ошибки предсказания ветвлений (процессор выбирал инструкции по неправильному пути). Опасности конвейера Solana иного рода: спам транзакций действует как структурная опасность, перегружая стадию Banking сверх ее пропускной способности, а сетевая перегрузка действует как условие остановки, замедляющее стадии Fetch и Writing. Это внешние опасности, обусловленные спросом, а не внутренние опасности, связанные с зависимостью данных.

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

Понимание этой аналогии и ее пределов отделяет поверхностные знания о скорости Solana от истинного архитектурного понимания.

Turbine: Как выход конвейера достигает сети

Turbine — это протокол распространения блоков Solana, и он отвечает за то, что происходит после завершения стадии Writing конвейера. Если Gulf Stream гарантирует, что конвейер всегда питается, то Turbine гарантирует, что выход конвейера достигает остальной сети максимально эффективно.

После того как стадия Writing фиксирует пакет подтвержденных транзакций в реестре, Turbine разбивает результирующий блок на более мелкие пакеты данных, называемые shreds, и распространяет их через сетевую структуру в виде дерева валидаторов. Вместо того чтобы транслировать полный блок всем валидаторам одновременно (что потребовало бы огромной исходящей пропускной способности от лидера), Turbine распределяет нагрузку по распространению по сети. Каждый валидатор в дереве получает подмножество shred'ов и пересылает их другим валидаторам далее по дереву, что в принципе похоже на то, как BitTorrent распространяет файлы, имея несколько узлов, разделяющих нагрузку по распространению. (Turbine использует структурированное дерево, а не swarm peer-to-peer, что является важным отличием для надежности сети.)

Совместимый с конвейеризацией дизайн здесь имеет значение: shred'ы начинают распространяться по остальной сети, пока лидирующий валидатор уже обрабатывает следующий пакет транзакций через конвейер. Распространение блоков и производство блоков выполняются параллельно. Сетевое распространение блока N не создает паузы в производстве блока N+1.

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

Входной/выходной интерфейс вокруг конвейера TPU:

Gulf Stream: вход конвейера (предварительно направляет транзакции к предстоящему лидеру до начала слота). Turbine: выход конвейера (распространяет проверенные данные блоков в виде shred'ов через сеть дерева валидаторов). Вместе они гарантируют, что конвейер TPU не будет простаивать ни на одном конце.

Turbine обрабатывает выход конвейера на уровне блоков. Sealevel распространяет принцип конвейеризации глубже, до уровня выполнения смарт-контрактов.

Sealevel: Конвейеризация, распространенная на выполнение смарт-контрактов

Конвейер транзакций не останавливается на TPU. Sealevel распространяет тот же принцип параллельной обработки на выполнение смарт-контрактов, и это одно из наиболее недооцененных архитектурных преимуществ Solana.

Sealevel — это параллельная среда выполнения смарт-контрактов Solana. Он позволяет тысячам смарт-контрактов (называемых программами в архитектуре Solana, что является отличием от терминологии Ethereum, важным для разработчиков) выполняться одновременно, а не последовательно. EVM (Ethereum Virtual Machine) Ethereum обрабатывает смарт-контракты в одном потоке, что означает, что только один контракт может выполняться за раз в блоке. Sealevel использует все доступные ядра ЦП для параллельного выполнения нескольких программ.

Механизм зависит от модели учета учетных записей (аккаунтов) Solana. Каждая транзакция Solana должна заранее объявлять, из каких учетных записей она будет читать и в какие записывать. Sealevel использует эти объявления для сортировки транзакций в непересекающиеся группы: транзакции, обращающиеся к разным учетным записям, могут выполняться одновременно без риска конфликтов состояния, в то время как транзакции, которые используют одни и те же учетные записи, должны обрабатываться последовательно для обеспечения корректности.

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

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

Чтобы подробнее узнать, как объявления учетных записей и модель учета учетных записей Solana работают на практике, ознакомьтесь с нашей статьей [Модель учета учетных записей Solana: объяснение].

Solana против Ethereum: Сравнение архитектуры конвейера

Разница в производительности между Solana и Ethereum связана с фундаментальным архитектурным выбором: параллельная обработка в конвейере против последовательного выполнения транзакций.

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

В отличие от этого, параллельный конвейер TPU Solana обрабатывает несколько пакетов транзакций одновременно на четырех выделенных аппаратных стадиях. ГП ускоряет проверку подписи. ЦП одновременно применяет изменения состояния к неконфликтующим программам через Sealevel. NVMe SSD обрабатывают записи, в то время как Turbine параллельно выполняет распространение. Эта конструкция обеспечивает значительно более высокую пропускную способность первого уровня (L1), но требует значительно большего объема оборудования и создает более концентрированный набор валидаторов примерно из 2 000 активных валидаторов.

Цифры производительности конкретны. Время формирования блока в Ethereum составляет примерно 12 секунд; время слота в Solana — примерно 400 миллисекунд. Пропускная способность L1 Ethereum составляет примерно от 15 до 30 транзакций в секунду; реальная пропускная способность Solana (без учета голосов) составляет примерно от 2 000 до 4 000 транзакций в секунду в зависимости от сетевых условий. (Для сравнения, Bitcoin обрабатывает примерно 7 транзакций в секунду.) Решения второго уровня (L2) Ethereum, включая Arbitrum и Optimism, значительно увеличивают эффективную пропускную способность Ethereum сверх его базовой пропускной способности L1, что важно учитывать при сравнении необработанных показателей L1.

Подробное сравнение того, как эти архитектуры соотносятся по инвестиционным и 개발 dimensям, см. в нашем полном сравнении архитектуры Solana и Ethereum.).

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

Ограничения, перегрузки и честные компромиссы конвейерной архитектуры Solana

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

Когда конвейер перегружен: как возникают перегрузки

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

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

Для документированной истории сетевых событий Solana и их причин ознакомьтесь с нашей статьей [Сбои сети Solana: история и что они означают для инвесторов].

Solana внесла несколько архитектурных изменений с 2022 года для решения проблемы перегрузки конвейера:

• Принятие протокола QUIC: Solana заменила исходное UDP-соединение на стадии Fetch (Получение) на QUIC (современный транспортный протокол, который обеспечивает управление перегрузкой и управление соединениями, которых нет в UDP). QUIC позволяет стадии Fetch более интеллектуально управлять приемом транзакций при высокой нагрузке, снижая эффективность дешевого спама транзакций.
• Приоритет качества обслуживания на основе стейкинга (SWQoS): Solana внедрила приоритет качества обслуживания на основе стейкинга (SWQoS), который приоритизирует транзакции, переданные от валидаторов с большим весом стейкинга. Это снижает способность участников с низким стейкингом забивать конвейер спам-транзакциями, которые потребляют пропускную способность стадии Банкинга за счет законных пользовательских транзакций.
• Приоритетные комиссии: Пользователи могут прикреплять приоритетные комиссии к транзакциям, сигнализируя о готовности платить за более быструю обработку через конвейер в периоды высокого спроса.
• Firedancer: Firedancer, независимая реализация клиента валидатора, разработанная Jump Crypto, находится в разработке и направлена на существенное увеличение пропускной способности конвейера и повышение устойчивости сети за счет предоставления альтернативного клиента, снижающего риск единой реализации.

Компромисс в отношении централизации: высокие требования к оборудованию

Высокие требования Solana к оборудованию валидаторов создают заметный компромисс в плане централизации. Для работы конвейера TPU требуются корпоративная GPU для этапа SigVerify, многоядерный CPU для этапа Banking, корпоративные NVMe SSD для этапа Writing и высокоскоростное сетевое соединение для Fetch и Turbine. Эти спецификации создают значительные финансовые барьеры для домашних валидаторов.

Результатом является более концентрированный набор валидаторов, чем в Ethereum. У Solana примерно 2 000 активных валидаторов; у Ethereum — около 900 000 или более (обе цифры колеблются и должны проверяться по текущим сетевым данным). Solana Labs и Solana Foundation открыто признали этот компромисс: требования к оборудованию являются осознанным следствием выбора дизайна, ориентированного на пропускную способность, и отражают позицию Solana на оси «масштабируемость-децентрализация» трилеммы блокчейна. Приемлемость этого компромисса зависит от приоритетов оценивающего.

Часто задаваемые вопросы: Конвейеризация транзакций Solana

Что такое блок обработки транзакций (TPU) Solana?

Блок обработки транзакций (TPU) Solana — это движок конвейера внутри узла валидатора, который физически обрабатывает транзакции. Это термин Solana, совершенно не связанный с Tensor Processing Unit от Google, используемым в машинном обучении. TPU работает только на лидере-валидаторе в течение каждого слота длительностью ~400 мс и функционирует в четыре этапа: Fetch (получение), SigVerify (проверка подписи), Banking (банковское дело/обработка) и Writing (запись). Валидаторы, не являющиеся лидерами, запускают TVU (Transaction Validation Unit — блок валидации транзакций) для проверки и воспроизведения блоков.

Что такое Proof of History и как это связано с конвейеризацией?

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

Что такое Gulf Stream в Solana?

Gulf Stream — это протокол пересылки транзакций Solana без мемпула. Вместо того чтобы удерживать неподтвержденные транзакции в глобальном пуле, Gulf Stream использует детерминированный график лидеров для направления транзакций непосредственно будущему лидеру-валидатору до начала его слота. Когда активируется этап Fetch лидера, он берет данные из предварительно загруженного буфера. Именно благодаря этой предварительной маршрутизации Solana может поддерживать время слота ~400 мс без ожидания поступления транзакций на этапе Fetch.

Что такое Sealevel?

Sealevel — это параллельная среда выполнения смарт-контрактов Solana. Она позволяет тысячам смарт-контрактов (называемых программами в архитектуре Solana) выполняться одновременно, требуя, чтобы каждая транзакция заранее декларировала, какие аккаунты она будет читать и записывать. Sealevel выявляет непересекающиеся транзакции и запускает их параллельно на всех доступных ядрах процессора, распространяя тот же принцип параллельной обработки с конвейера TPU на уровень исполнения смарт-контрактов.

Вызывает ли конвейеризация транзакций Solana сбои в сети?

Перегрузка конвейера способствовала некоторым сбоям в работе Solana, но не всем. Когда объем транзакций превышает пропускную способность этапа Banking, дизайн без мемпула приводит к сбросу транзакций, а не к их постановке в очередь, и при экстремальной перегрузке валидаторы могут выйти из консенсуса. В Solana также случались сбои, вызванные программными ошибками, отказами консенсуса и скоординированным спамом транзакций, не связанным с лимитами пропускной способности конвейера. Внедрение QUIC и SWQoS с 2022 года сократило количество сбоев, вызванных перегрузками.

Каков реальный TPS Solana?

Теоретический TPS Solana составляет примерно 65 000, что представляет собой максимум конвейера в идеальных условиях согласно технической документации Solana. Реальный TPS без учета голосов обычно составляет от 2 000 до 4 000 в зависимости от нагрузки сети, состава типов транзакций и производительности валидаторов. Solana считает транзакции голосования валидаторов отдельно от пользовательских транзакций; общая сумма с учетом голосов выше, но она менее значима как метрика производительности для пользователя.

Почему Solana быстрее, чем Ethereum?

Используйте страницу цены Solana), чтобы изучить текущие рыночные данные SOL, или перейдите на спот рынок SOL/USDT), если торговля на споте соответствует вашим целям. Торговая активность на Bybit отличается от отправки ончейн транзакции Solana; при внесении или выводе SOL в сети Solana может взиматься сетевая комиссия.

Опытные трейдеры деривативами также могут изучить бессрочный рынок SOLUSDT.). Деривативы сопряжены с дополнительным риском и не дают права собственности на спот SOL.

Конвейеризация транзакций Solana и инвестиционный тезис SOL

Конвейеризация транзакций Solana — это реальная архитектурная инновация, а не маркетинговое заявление. Четырехступенчатый конвейер TPU представляет собой последовательный инженерный подход к пропускной способности Layer-1. Proof of History обеспечивает криптографические часы, которые позволяют конвейеру продвигаться вперед без задержек сетевого консенсуса. Gulf Stream осуществляет предварительную загрузку входных данных конвейера. Turbine распределяет выходные данные конвейера. Sealevel переносит тот же принцип параллелизма на исполнение смарт-контрактов.

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

Эти инженерные решения влекут за собой реальные компромиссы. События с перегрузкой сети в 2021 и 2022 годах продемонстрировали, что дизайн без мемпула и потолок пропускной способности этапа Banking являются реальными ограничениями в условиях враждебной или экстремальной нагрузки. Высокие требования к оборудованию валидаторов приводят к созданию более концентрированного набора валидаторов, чем в Ethereum, что представляет собой осознанную позицию на оси «масштабируемость-децентрализация» трилеммы блокчейна. Текущая архитектурная эволюция Solana, включая внедрение QUIC, развертывание SWQoS и разработку клиента Firedancer компанией Jump Crypto, отражает стремление протокола активно работать над повышением этих лимитов. Это траектории развития, а не решенные проблемы.

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

Отказ от ответственности: Эта статья предназначена только для образовательных целей и не является инвестиционным советом, финансовым советом, торговым советом или любым другим видом консультации. Solana (SOL) — это криптовалюта. Криптовалюты — это высоко волатильные активы, несущие значительный риск потери средств. Всегда проводите собственное исследование и консультируйтесь с квалифицированным финансовым консультантом перед принятием инвестиционных решений.

Связанное чтение по этой теме:

• Solana против Ethereum: полное сравнение архитектур:) полное сравнение архитектур Solana и Ethereum