TPU (Transaction Processing Unit) — это конвейер узла-лидера Solana, который принимает транзакции, проверяет подписи, отбирает и планирует их в партии, записывает события в поток Proof of History, формирует блок и распространяет его по сети. TPU создан под высокую параллельность по данным (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик) и работу со слотовым временем (см. Solana Proof of History (PoH): как работает «доказательство истории»), а на входе опирается на транспорт Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму.
Solana TPU — конвейер приёма и исполнения транзакций: коротко
- Вход по QUIC с контролем перегрузки и stake-QoS → меньше спама и джиттера.
- Быстрая sigverify (CPU/GPU) + дедупликация.
- Планирование партий на основе объявленных аккаунтов: независимые наборы исполняются параллельно (Sealevel).
- PoH-Recorder фиксирует последовательность событий внутри слота.
- Лидер собирает блок; финализация — голосами валидаторов (Tower BFT) в следующих слотах.
Роль TPU в архитектуре Solana
TPU соединяет сетевой приём транзакций и их исполнение в рантайме:
- Ingress: справедливый и устойчивый к спаму приём заявок.
- Execution: максимизация параллелизма за счёт модели аккаунтов и партий без write-конфликтов.
- Timing: согласование шагов с тик-ритмом PoH и границами слота.
С обзором протокола — Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel.
Этапы конвейера TPU (упрощённая схема)
1) Приём по QUIC (Ingress). Узел устанавливает QUIC-соединения, применяет flow control, лимиты на соединения/ключи/подсети и stake-weighted QoS. Дубликаты и устаревшие транзакции отбрасываются раннее. Подробнее — Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму.
2) Sigverify. Пакетная проверка подписей (часто с ускорением на GPU/многопоточности) и базовых инвариантов формата. Не прошедшие заявки отбраковываются.
3) Планирование и исполнение (Banking Stage). Транзакции группируются по несовпадающим наборам аккаунтов. Партии без write-пересечений исполняются параллельно, конфликты сериализуются. Здесь учитываются лимиты Compute Units и политика приоритета (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees и Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору). Архитектурные детали — Sealevel (Solana): параллельное исполнение, рантайм и планировщик.
4) PoH Recorder и границы слотов. События «якорятся» в поток Proof of History: формируется упорядоченная лента, которая задаёт ритм слотов и порядок внутри блока (Solana Proof of History (PoH): как работает «доказательство истории»).
5) Формирование и распространение блока. Лидер собирает валидный блок из исполненных партий и передаёт его остальным узлам (распространение/проверка). Далее валидаторы голосуют, двигая финализацию по Tower BFT (Solana Tower BFT: механизм финализации блоков и «лок-ауты» голосов).
Параллельное исполнение: почему TPU масштабируется
Секрет производительности — в заранее объявленных зависимостях. Каждая инструкция транзакции указывает аккаунты и права (read/write). Планировщик:
- строит «сетку независимости»;
- помещает совместимые транзакции в одну партию;
- минимизирует блокировки на «горячих» аккаунтах.
Это даёт почти линейную утилизацию ядер на независимых наборах данных и сглаживает хвостовые задержки p95/p99. См. Sealevel (Solana): параллельное исполнение, рантайм и планировщик.
Приоритет и локальные рынки комиссий
В Solana нет «глобального газа». Когда возникает конкуренция за один и тот же аккаунт (минт, ордербук, ликвидации), TPU видит локальные очереди. Порядок внутри них определяется эффективной ценой: базовая комиссия + Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору. Операции вне очагов проходят по базовой цене (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees).
Устойчивость к спаму: роль QUIC и QoS
Переключение на Solana QUIC: транспорт транзакций, приоритет и устойчивость к спаму дало:
- Back-pressure вместо «наводнения» UDP-пакетами;
- лимиты на соединения/ключи и stake-QoS;
- предсказуемые окна и меньше джиттера на входе TPU.
Итог — честный доступ к слоту и меньше «паразитных» ретраев.
Метрики TPU: что мониторить разработчикам/операторам
| Метрика | Что показывает | Интерпретация/реакция |
|---|---|---|
| Handshake/stream latency p95/p99 | Сетевые «узкие места» на ingress | Тюнинг окон QUIC, балансировка входа |
| Доля дубликатов/устаревших | Качество клиента отправителя | Снизить «бомбёжку», ретраи по слотам (1–3 попытки) |
| Share write-конфликтов | Архитектурные «горячие» аккаунты | Шардирование, «узкие» инструкции, разделение горячего/холодного |
| CU per tx / per batch | Дорогие пути исполнения | Профилирование, декомпозиция, кэш сериализации |
| p95/p99 до включения | Пользовательский UX | Подсказки по приоритету только в «очагах» |
Анти-паттерны отправителей (и как их исправить)
- Шторм дубликатов. Порождает дропы и ухудшает шансы. Делайте 1–3 ретрая с шагом по слотам.
- «Толстые» транзакции. Упираются в CU и залипают в очереди. Делите на узкие инструкции.
- Глобальные аккаунты. Один «общий» объект блокирует параллелизм. Делайте per-user/per-market состояние.
- Незаявленные зависимости. CPI не может подтянуть «новые» аккаунты — объявляйте всё на поверхности.
FAQ
TPU «ускорит» любую транзакцию, если заплатить больше? Нет. Доплата ускоряет только внутри локальной очереди вокруг «горячих» аккаунтов (Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору). Вне очагов переплата бессмысленна.
Почему блок иногда формируется с «пустотами»? Планировщик избегает конфликтов: если остались только пересекающиеся по записи транзакции, часть ядёр простаивает, пока не освободятся «замки».
Что влияет на финализацию после выпуска блока? Голоса валидаторов по Tower BFT (сетевые задержки, аптайм, доля стейка). Сама сборка — работа лидера, финализация — работа сети.