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

Цей технічний посібник пояснює 4-етапний конвеєр TPU для транзакцій Solana та те, як він підтримує паралельну обробку.

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

Конвеєризація транзакцій Solana — це метод, за допомогою якого блок обробки транзакцій (TPU) Solana проводить вхідні транзакції через чотири послідовні етапи: Fetch (отримання), SigVerify (перевірка підпису), Banking (банківські операції) та Writing (запис). Кілька пакетів транзакцій проходять через ці етапи одночасно, так що поки один пакет записується в реєстр, наступний уже проходить валідацію, а третій — уже отримується. Саме ця паралельна обробка дозволяє Solana (SOL), нативному активу блокчейну Solana (розподілений реєстр, у якому записуються всі транзакції), досягати показників пропускної здатності, які значно перевищують показники більшості мереж Layer-1.

Solana була створена Анатолієм Яковенком, колишнім інженером Qualcomm, який у 2017 році опублікував Whitepaper Proof of History, представивши механізм криптографічного годинника, що робить можливою таку швидкість конвеєра. 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. Аналогія з конвеєром ЦП: Чому архітектура Solana має бути знайомою інженерам
6. Turbine: Як вихідні дані конвеєра потрапляють у мережу
7. Sealevel: Конвеєризація, розширена на виконання смартконтрактів
8. Solana проти Ethereum: Порівняння архітектури конвеєрів
9. Обмеження, перевантаження та чесні компроміси архітектури конвеєра Solana
10. Часті запитання про конвеєризацію транзакцій Solana
11. Конвеєризація транзакцій Solana та інвестиційна теза SOL

Що таке конвеєризація транзакцій Solana? (І чому це важливо для SOL)

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

Solana запозичила цю ідею у комп'ютерних процесорів. Сучасні центральні процесори досягають високої пропускної здатності завдяки конвеєризації на рівні інструкцій: поки одна інструкція виконується, наступна декодується, а та, що йде за нею, вже зчитується. Solana застосовує ту саму логіку до транзакцій на рівні валідатора. Повне зіставлення етапів ЦП з етапами TPU Solana наведено у розділі з аналогією ЦП нижче, але основний принцип ідентичний: тримати кожен етап зайнятим у будь-який момент часу.

Більшість блокчейнів обробляють транзакції послідовно, що означає, що валідатор повинен завершити всю обробку однієї транзакції (або пакету), перш ніж розпочати наступну. Ця послідовна модель створює стелю пропускної здатності, яка повністю визначається тим, наскільки швидко може працювати один ланцюжок операцій. Конвеєризація долає цю стелю, запускаючи кілька операцій паралельно на виділених апаратних компонентах, що зменшує затримку підтвердження (час між поданням транзакції та отриманням фіналізації) без необхідності прискорювати кожен окремий етап.

Теоретична швидкість TPS Solana, згідно з технічною документацією Solana, становить приблизно 65 000 транзакцій на секунду. Це максимальний показник конвеєра в ідеальних умовах. Реальний показник TPS без урахування голосувань (non-vote) істотно нижчий, зазвичай варіюючись від 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 мс слоту. Валідатори, які не є лідерами, запускають Unit Transaction Validation (TVU), який відтворює та перевіряє блоки, створені лідером. Solana визначає, який валідатор виступає лідером, за допомогою детермінованого Розкладу лідерів, опублікованого заздалегідь для кожної епохи (приблизно 2-3 дні), який призначає слоти лідера для кожного валідатора на основі його ваги стейку. Цей розклад дозволяє здійснювати попереднє маршрутизацію транзакцій Gulf Stream, як це обговорюється в розділі Gulf Stream нижче.

Щодо технічних деталей архітектури TPU, див. офіційну документацію Solana TPU) та документацію Solana щодо часу слотів.)

Чотири етапи конвеєра TPU Solana

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

1. Fetch: Мережевий стек отримує необроблені пакети транзакцій через QUIC (сучасний транспортний протокол, який замінив початкове UDP-з'єднання для покращеного контролю перевантаження). Етап Fetch є приймальним доком конвеєра. Він витягує транзакції з попередньо завантаженого буфера, який Gulf Stream вже виконав до початку слоту, і передає перевірені пакети до 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 забезпечує економічну безпеку та захист від Sybil. Це різні функції.

Для повного пояснення роботи 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 запозичує той самий архітектурний принцип, який робить сучасні ЦП швидкими: конвеєризація на рівні інструкцій. Це не метафора. Дизайн архітектурно натхненний тією ж технікою пропускної здатності, описаною у фундаментальному тексті Паттерсона та Хеннесі "Організація та дизайн комп'ютерів".

Конвеєр інструкцій ЦП працює наступним чином. Замість того, щоб чекати, поки одна інструкція завершить усі етапи обробки перед отриманням наступної, ЦП розбиває виконання на послідовні етапи (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 розподіляє навантаження поширення по мережі. Кожен валідатор у дереві отримує підмножину фрагментів і передає їх іншим валідаторам далі по дереву, за принципом подібним до того, як BitTorrent поширює файли, коли кілька вузлів розподіляють навантаження поширення. (Turbine використовує структуроване дерево, а не P2P-мережу, що є важливим розходженням для надійності мережі.)

Дизайн, сумісний із конвеєризацією, тут має значення: фрагменти починають поширюватися мережею, тоді як лідер-валідатор вже обробляє наступний пакет транзакцій через конвеєр. Поширення блоків та виробництво блоків працюють паралельно. Поширення блоку N у мережі не створює паузи у виробництві блоку N+1.

Інженерна перевага полягає в тому, що Solana досягає високої пропускної здатності блоків без необхідності використання корпоративного рівня вихідного зв'язку на кожному вузлі валідатора. Тільки лідер-валідатор несе повне навантаження з виробництва; поширення розподіляється по всій мережі.

Обгортка входу/виходу навколо конвеєра TPU:

Gulf Stream: вхід конвеєра (попередньо маршрутизує транзакції до майбутнього лідера до початку слоту). Turbine: вихід конвеєра (розподіляє валідовані дані блоку як фрагменти через мережу дерев валідаторів). Разом вони гарантують, що конвеєр TPU ніколи не буде простоювати на жодному кінці.

Turbine обробляє вихід конвеєра на рівні блоку. Sealevel поширює принцип конвеєризації глибше, до рівня виконання смартконтрактів.

Sealevel: Конвеєризація, розширена до виконання смартконтрактів

Конвеєризація транзакцій не зупиняється на TPU. Sealevel поширює той самий принцип паралельної обробки на виконання смартконтрактів, і це одна з найбільш недооцінених архітектурних переваг Solana.

Sealevel — це паралельне середовище виконання смартконтрактів Solana. Воно дозволяє тисячам смартконтрактів (названих програмами в архітектурі Solana, що є відмінністю від термінології Ethereum, яка важлива для розробників) виконуватися одночасно, а не послідовно. EVM Ethereum (Ethereum Virtual Machine) обробляє смартконтракти в одному потоці, що означає, що за блок може виконуватися лише один контракт за раз. Sealevel використовує всі доступні ядра ЦП для паралельного виконання кількох програм.

Механізм залежить від моделі акаунтів Solana. Кожна транзакція Solana повинна заздалегідь оголосити, з яких акаунтів вона буде читати дані та в які записувати. Sealevel використовує ці оголошення для сортування транзакцій у групи, що не перекриваються: транзакції, які звертаються до різних акаунтів, можуть виконуватися одночасно без ризику конфліктів станів, тоді як транзакції зі спільними акаунтами повинні оброблятися послідовно для збереження коректності.

Ця вимога щодо попереднього оголошення є конструктивним обмеженням, яке розробники Solana повинні враховувати при архітектурному проектуванні програм. Програми повинні попередньо оголошувати всі акаунти, до яких вони матимуть доступ, що відрізняється від більш дозвільної моделі доступу до стану в Ethereum, де доступ до сховища смартконтракту не оголошується заздалегідь.

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

Для глибшого ознайомлення з тим, як працюють оголошення акаунтів та модель акаунтів Solana на практиці, дивіться нашу статтю [Solana Account Model Explained].

Solana проти Ethereum: порівняння архітектури конвеєрів

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

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

На противагу цьому, паралельний конвеєр TPU Bybit обробляє кілька пакетів транзакцій одночасно на чотирьох виділених апаратних етапах. GPU прискорює перевірку підписів. CPU одночасно застосовує зміни стану в програмах, що не конфліктують, через Sealevel. NVMe SSD обробляють записи, поки Turbine паралельно запускає розповсюдження. Цей дизайн забезпечує значно вищу пропускну здатність рівня 1 (Layer-1), але вимагає значно потужнішого обладнання та створює більш концентрований набір валідаторів — приблизно 2000 активних учасників.

Показники продуктивності є конкретними. Час блоку Ethereum становить приблизно 12 секунд; час слота Solana — приблизно 400 мілісекунд. TPS рівня 1 в Ethereum становить приблизно від 15 до 30; реальний TPS Solana без урахування голосувань — приблизно від 2000 до 4000 залежно від умов мережі. (Для порівняння масштабів: Bitcoin обробляє приблизно 7 транзакцій на секунду.) Рішення другого рівня (Layer-2) для Ethereum, включаючи Arbitrum та Optimism, суттєво збільшують ефективну пропускну здатність Ethereum за межі його базового рівня 1, що є важливим контекстом при порівнянні необроблених показників рівня 1.

Для детального аналізу порівняння цих архітектур у розрізі інвестицій та розробки дивіться наше повне порівняння архітектур Solana та Ethereum.

Жодна архітектура не є однозначно кращою. Обидві представляють свідомі компроміси в межах широко цитованої Трилеми блокчейну. Ethereum пожертвував пропускною здатністю заради децентралізації та багатої екосистеми другого рівня. Solana пожертвувала децентралізацією заради пропускної здатності рівня 1. Який компроміс краще підходить для конкретного застосунку чи інвестиційної тези, залежить від специфічних вимог.

Обмеження, перевантаження та чесні компроміси конвеєрної архітектури Solana

Архітектура конвеєра Solana забезпечує задокументовані переваги в продуктивності, але вона також несе задокументовані компроміси. Розуміння обох аспектів необхідне для будь-якої серйозної оцінки мережі, як для розробки, так і для інвестування.

Коли конвеєр перевантажується: як працює затори

Перевантаження конвеєра виникає, коли обсяг транзакцій перевищує потужність обробки етапу Banking. Послідовність подій є специфічною. Етап Banking відстає від обсягу вхідних транзакцій. Оскільки дизайн Gulf Stream від Bybit не передбачає наявності мемпулу та постійного буфера транзакцій, транзакції, які не можуть бути оброблені швидко, відхиляються, а не ставляться в чергу. Користувачі отримують помилки «термін дії транзакції закінчився» і повинні надсилати їх повторно. При екстремальних рівнях перевантаження валідатори можуть випадати з консенсусу, оскільки конвеєр не може обробляти транзакції голосування достатньо швидко відносно загального обсягу транзакцій, що призводить до зупинки мережі.

Solana переживала значні збої в роботі мережі у вересні 2021 року, січні 2022 року та травні 2022 року, серед інших періодів. Причини не були однаковими. У деяких випадках надмірний обсяг транзакцій перевантажував потужність етапу Banking. В інших випадках причиною були скоординовані кампанії спаму транзакціями, помилки програмного забезпечення або збої консенсусу, не пов’язані з межами пропускної здатності конвеєра. Приписувати всі збої Solana лише конвеєризації було б неточно. Обмеження пропускної здатності конвеєра, коли вони були перевищені за певних умов, сприяли деяким випадкам збоїв, тоді як інші збої мали окремі першопричини.

Для ознайомлення із задокументованою історією подій у мережі Solana та їх причинами дивіться нашу статтю [Solana Network Outages: History and What They Mean for Investors].

Архітектурні рішення Solana для боротьби з перевантаженням

З 2022 року Solana внесла кілька архітектурних змін, щоб вирішити проблему перевантаження конвеєра:

• Впровадження протоколу QUIC: Solana замінила оригінальне UDP-з'єднання на етапі Fetch на QUIC (сучасний транспортний протокол, який забезпечує контроль перевантаження та керування з'єднанням, чого не має UDP). QUIC дозволяє етапу Fetch більш інтелектуально керувати прийомом транзакцій під високим навантаженням, знижуючи ефективність дешевого спаму транзакціями.
• Stake-Weighted Quality of Service (SWQoS): Solana впровадила якість обслуговування з урахуванням стейкінгу (SWQoS), яка пріоритезує транзакції, що передаються від валідаторів з більшою вагою стейкінгу. Це обмежує можливість суб'єктів з низьким стейкінгом наповнювати конвеєр спам-транзакціями, які споживають потужність етапу Banking за рахунок легітимних транзакцій користувачів.
• Пріоритетні комісії: Користувачі можуть додавати пріоритетні комісії до транзакцій, сигналізуючи про готовність платити за швидшу обробку через конвеєр у періоди високого попиту.
• Firedancer: Firedancer — це незалежна реалізація клієнта валідатора, розроблена Jump Crypto, яка зараз перебуває в стадії розробки та має на меті суттєво збільшити пропускну здатність конвеєра та покращити стійкість мережі, надаючи альтернативний клієнт, що знижує ризик використання єдиної реалізації.

Компроміс щодо централізації: високі вимоги до обладнання

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

Результатом є більш концентрований набір валідаторів, ніж Ethereum. Solana має приблизно 2000 активних валідаторів; Ethereum має приблизно 900 000 або більше (обидві цифри коливаються і повинні бути перевірені відповідно до поточних мережевих даних). Solana Labs та Solana Foundation відкрито визнали цей компроміс: вимоги до обладнання є свідомим наслідком вибору дизайну пріоритету пропускної здатності, що відображає позицію Solana на осі масштабованості-децентралізації Трилеми блокчейну. Чи є цей компроміс прийнятним, залежить від того, що надає перевагу оцінювач.

Поширені запитання: Конвеєрна обробка транзакцій Solana

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

Блок обробки транзакцій Solana (TPU) — це рушій конвеєра всередині вузла валідатора, який фізично обробляє транзакції. Це термін 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 для не-голосувальних транзакцій зазвичай коливається від 2000 до 4000, залежно від навантаження на мережу, складу типів транзакцій та продуктивності валідаторів. Solana враховує транзакції голосування валідаторів окремо від транзакцій користувачів; загальна кількість, включаючи голосування, вища, але менш значуща як метрика продуктивності для користувача.

Чому Solana швидша за Ethereum?

Чотириступеневий паралельний конвеєр TPU Solana обробляє кілька пакетів транзакцій одночасно, тоді як EVM Ethereum обробляє транзакції послідовно в одному потоці. Результат: час слоту Solana становить приблизно 400 мілісекунд порівняно з ~12-секундним часом блоку Ethereum, а TPS рівня 1 Solana становить приблизно 2000–4000 порівняно з ~15–30 у Ethereum. Обидві архітектури представляють свідомі дизайнерські рішення з різними компромісами щодо Трилеми блокчейну.

Що відбувається, коли конвеєр Solana перевантажується?

Коли обсяг транзакцій перевищує обробну потужність стадії Banking, Solana відкидає транзакції замість того, щоб ставити їх у чергу, оскільки дизайн Gulf Stream без мемпулу не підтримує постійний буфер. Уражені транзакції повертають помилку «термін дії транзакції сплив» і їх потрібно повторно надсилати. При сильному перевантаженні обробка транзакцій голосування може відставати, що призводить до виходу валідаторів із консенсусу. QUIC та SWQoS зменшують вплив перевантаження, спричиненого спамом, хоча граничне обмеження потужності залишається відомим архітектурним компромісом.

Дізнайтеся більше про SOL на Bybit

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

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

Конвеєрна обробка транзакцій Solana та інвестиційна теза SOL

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

Для інвесторів, які володіють Solana (SOL) або оцінюють її, розуміння конвеєра означає розуміння технічної основи диференціації продуктивності Solana. Перевага архітектури у швидкості є структурною, а не випадковою. Вона походить від конкретних інженерних рішень щодо застосування принципів паралельної обробки на кожному рівні життєвого циклу транзакції.

Ці інженерні рішення несуть реальні компроміси. Події перевантаження 2021 і 2022 років продемонстрували, що дизайн без мемпулу та гранична стеля пропускної здатності стадії Banking є реальними обмеженнями під час ворожих або екстремальних умов навантаження. Високі вимоги до обладнання валідаторів призводять до більш концентрованого набору валідаторів, ніж Ethereum, що представляє свідому позицію на осі масштабованості-децентралізації Трилеми блокчейну. Постійна архітектурна еволюція Solana, включаючи впровадження QUIC, розгортання SWQoS та клієнт Firedancer, що розробляється Jump Crypto, відображає протокол, який активно працює над підвищенням цих лімітів. Це — траєкторії розвитку, а не вирішені проблеми.

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

Відмова від відповідальності: Ця стаття призначена виключно для освітніх цілей і не є інвестиційною, фінансовою, торговою або будь-якою іншою формою поради. Solana (SOL) — це криптовалюта. Криптовалюти є високо волатильними активами і несуть значний ризик втрат. Завжди проводьте власне дослідження і консультуйтеся з кваліфікованим фінансовим радником перед прийняттям інвестиційних рішень.

Пов'язані матеріали з цієї теми:

• Solana vs. Ethereum: Full Architecture Comparison: повне порівняння архітектури Solana та Ethereum