Solana Turbine: Пояснення розповсюдження блоків

Розповсюдження блоків Solana Turbine описує, як дані блоку поділяються на шреди та розподіляються між валідаторами. Цифри в цій статті є історичними або цільовими значеннями, якщо явно не вказана дата; фактичний час слотів, топологія, втрата пакетів та поведінка реалізації варіюються.

Вступ: Чому розповсюдження блоків визначає швидкість блокчейну

Надсилання повного блоку тисячам валідаторів одночасно вимагало б від кожного валідатора завантажувати весь блок з одного джерела, створюючи вузьке місце пропускної здатності, яке погіршується в міру масштабування мережі. Solana (SOL), високопродуктивний блокчейн Рівня 1 (мережа розподіленого реєстру, яка записує та перевіряє транзакції без центрального органу), вирішує цю проблему за допомогою Turbine, свого спеціалізованого протоколу розповсюдження блоків.

Ранні матеріали Solana згадують теоретичну пропускну здатність близько 65 000 TPS і цільову тривалість слота близько 400 мілісекунд. Це швидше проектні орієнтири, ніж гарантовані вимірювання в реальному часі, і слот не завжди створює блок. Turbine — це механізм розповсюдження даних блоків, описаний у межах історичної архітектури Solana.

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

Далі розглядається визначення Turbine, його п’ятикроковий механізм, технічні параметри, внесок у продуктивність, компроміси щодо безпеки та порівняння з Ethereum і Avalanche.

У цій статті

• Що таке розповсюдження блоків Solana Turbine?
• Ключові терміни: Короткий довідник термінології Turbine
• Як Turbine розповсюджує блоки: Покрокове керівництво
• Технічні параметри Turbine
• Turbine та продуктивність Solana: Зв'язок розповсюдження блоків із TPS
• Чи безпечний Turbine? Модель безпеки та відомі вектори атак
• Solana Turbine проти Ethereum та інших блокчейнів Рівня 1
• Turbine в архітектурі Solana: Усі 8 інновацій
• Еволюція Turbine: Від 2017 року Whitepaper до сьогодні
• Часті питання про Solana Turbine
• Висновок: Чому Turbine важливий для майбутнього Solana
• Додаткове читання та першоджерела

Що таке розповсюдження блоків Solana Turbine?

Визначення

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

Turbine існує тому, що наївна трансляція не масштабується. Якби лідер блоку (валідатор, призначений для створення блоку для певного слота) надсилав весь блок безпосередньо кожному валідатору одночасно, кожному валідатору довелося б завантажувати повний блок незалежно. З понад 2000 активних валідаторів у мережі Solana такий підхід вимагав би пропускної здатності O(n) від одного джерела, що означає, що витрати на пропускну здатність зростають лінійно з кожним валідатором, доданим до мережі.

Turbine досягає масштабування пропускної здатності O(log n), запозичуючи основний принцип протоколу BitTorrent. Протокол розповсюдження файлів BitTorrent peer-to-peer ефективно передає великі файли, розділяючи їх на маленькі частини та розповсюджуючи ці частини через багато вузлів одночасно, а не обслуговуючи їх з одного сервера. Turbine застосовує ту саму ідею до розповсюдження блоків блокчейну: замість того, щоб лідер блоку передавав повний блок кожному валідатору, він фрагментує блок на шреди та спрямовує їх через багаторівневе дерево валідаторів, причому кожен рівень пересилає шреди далі по ланцюжку.

Аналогія має межі, які варто зазначити. BitTorrent працює як плоский peer-to-peer рій, де всі учасники вважаються рівними. Turbine використовує ієрархічне дерево з позиціонуванням на основі ваги стейку, що означає, що валідатори з більшою кількістю SOL у стейкінгу розміщуються ближче до вершини дерева і отримують шреди раніше. Ця відмінність важлива для розуміння як ефективності Turbine, так і компромісів у сфері безпеки.

Turbine був розроблений Анатолієм Яковенком, співзасновником Solana Labs, і представлений в оригінальному whitepaper Solana Анатолія Яковенка (2017).). Протокол перебуває в безперервному виробництві з моменту запуску бета-версії основної мережі Solana в березні 2020 року.

Ключові терміни: Короткий довідник термінології Turbine

Перш ніж розглянути, як працює Turbine, ось основні терміни, які ви зустрінете в цій статті.

Як Turbine розповсюджує блоки: Покрокове керівництво

Turbine поширює блоки через п'ятиетапний процес: лідер блоку розділяє блок на шреди, кодування Ріда-Соломона створює пакети надлишковості, а отримані шреди проходять через дерево сусідства, зважене за стейком, поки кожен валідатор не отримає достатньо шредів для відновлення повного блоку. Кожен крок нижче повністю охоплює один етап цього процесу.

Крок 1: Лідер блоку створює блок

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

Лідер блоку збирає транзакції, передані протоколом Gulf Stream (протокол пересилання транзакцій Solana, який надсилає непідтверджені транзакції передбачуваному наступному лідеру до завершення поточного блоку), і збирає їх у повний блок. Після завершення збірки лідер блоку запускає процес Turbine.

Крок 2: Блок розділяється на пакети даних (шреди)

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

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

Розділення на шреди у Turbine — це не шардинг. Шардинг розділяє стан Блокчейн або обробку транзакцій між кількома паралельними підмережами, де різні групи валідаторів перевіряють різні частини стану. Turbine розділяє блок виключно для ефективності передачі: вся мережа валідаторів Solana перевіряє той самий повний стан блоку. Фрагментація — це механізм доставки, а не стратегія розділення даних.

Крок 3: Кодування Ріда-Соломона створює шреди надлишковості

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

Корисна аналогія: кодування Ріда-Соломона функціонує як QR-код. Навіть якщо частина QR-коду закрита або пошкоджена, у вцілілих частинах залишається достатньо закодованої надлишкової інформації, щоб розшифрувати повне повідомлення. Проте аналогія з QR-кодом має одне обмеження: QR-коди є статичними об'єктами, тоді як кодування Turbine працює з потоковою групою шредів із певним числовим порогом відновлення.

Згідно з реалізацією Solana, валідатори можуть відновити повний блок, якщо вони отримають приблизно дві третини від загальної кількості шредів (дані плюс кодування разом). Це означає, що протокол допускає втрату приблизно однієї третини пакетів до того, як відновлення стане неможливим. Кодування Ріда-Соломона — це зріла технологія, яка десятиліттями використовується в CD, DVD, супутниковому зв'язку та інших сферах, що підтверджує: механізм відмовостійкості Turbine базується на перевірених інженерних рішеннях, а не на експериментальних розробках. Технічні параметри взяті з Solana Whitepaper) та офіційної документації Turbine від Solana.).

Крок 4: Шреди розповсюджуються через дерево сусідства

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

Рівень 0 (Лідер блоку)
        |
        +-- Рівень 1: ~200 валідаторів (кожен отримує унікальний набір шредів)
                |
                +-- Рівень 2: до ~40 000 валідаторів (200 x 200, кожен валідатор Рівня 1 передає ще ~200 валідаторам)

Дерево сусідства охоплює весь активний набір валідаторів Solana (понад 2000 валідаторів згідно зі статистикою мережі Solana Foundation) протягом двох-трьох рівнів, враховуючи коефіцієнт розгалуження приблизно 200 на рівень. З двома рівнями дерево математично охоплює до 40 000 валідаторів (200 x 200), що значно перевищує поточну кількість активних вузлів.

Уявіть цю структуру як мережу поштового сортування: центральний хаб надсилає партії регіональним сортувальним центрам, ті — місцевим поштовим відділенням, а останні — на індивідуальні адреси. Кожен рівень обробляє лише частину загального навантаження, і жоден вузол не несе повної вартості пропускної здатності. Однак, на відміну від нейтральної поштової системи, дерево сусідства Turbine зважене за стейком. Валідатори з більшою кількістю SOL, які було внесено в стейкінг за моделлю консенсусу Solana на основі Proof of Stake (Tower BFT), розташовуються ближче до вершини дерева, що гарантує їм найшвидше отримання шредів.

Топологія дерева також рандомізується для кожного слота за допомогою перевіреної випадковості, отриманої від годинника PoH. Це джерело випадковості, яке будь-який валідатор може незалежно перевірити, не довіряючи центральній стороні. Оскільки дерево змінюється в кожному слоті, зловмисні валідатори не можуть передбачити, хто буде їхнім сусідом у наступному раунді. Така рандомізація є основним захистом Turbine від атак затемнення (eclipse attacks), коли зловмисник намагається оточити цільового валідатора та заблокувати отримання шредів.

Результатом є масштабування пропускної здатності O(log n), що означає повільне зростання вимог до пропускної здатності порівняно з кількістю валідаторів. Ця властивість робить архітектуру Turbine все більш цінною зі зростанням кількості валідаторів Solana.

Крок 5: Валідатори відновлюють блок і голосують

Коли валідатор отримує достатньо шредів для досягнення порогу кодування (приблизно дві третини від загальної кількості шредів для цього блоку), він відновлює повний блок і надсилає свій голос у Tower BFT (Tower Byzantine Fault Tolerance) — Механізм консенсусу Solana на основі Proof of Stake. Валідатори не можуть голосувати до завершення відновлення, тому швидкість поширення через Turbine безпосередньо впливає на пропускну здатність консенсусу.

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

Що відбувається при втраті шредів?

Ключовий факт

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

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

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

У разі серйозної перевантаженості мережі, коли втрата пакетів є широко розповсюдженою в мережі, а не ізольованою на одному шляху, кілька валідаторів можуть не встигнути реконструювати свої блоки в межах вікна слота. Цей каскад сприяє пропускам слотів і, в екстремальних випадках, деградації мережі, яку Solana спостерігала під час великих подій перевантаження у 2021 та 2022 роках. Відтоді Solana Labs вдосконалила обробку перевантажень у Turbine у відповідь на ці події. Зв'язок між перевантаженням і пропусками слотів розглядається в розділі безпеки нижче.

Технічні параметри Turbine

У наступній таблиці підсумовано основні робочі параметри Turbine, взяті з офіційної документації Solana та Whitepaper Solana. Параметри можуть бути оновлені Solana Labs у міру розвитку протоколу; перевіряйте поточні значення в офіційній документації Solana щодо Turbine.

Turbine та продуктивність Solana: зв'язок поширення блоків із TPS

У Whitepaper Solana та пізніших коментарях згадувалася теоретична пропускна здатність близько 65 000 TPS. Фактична пропускна здатність залежить від дати, робочого навантаження, включення голосів, фільтрації та версії програмного забезпечення, тому діапазон живого TPS без урахування голосів не повинен подаватися без методології його вимірювання. Turbine є одним із компонентів результату, а не незалежною гарантією TPS.

Причинно-наслідковий ланцюжок працює наступним чином. Turbine поширює фрагменти достатньо швидко, щоб валідатори в мережі реконструювали блоки та голосували в межах приблизно 400-мілісекундного вікна слота. Консенсус триває. Починається наступний слот. Solana підтримує свій темп слотів. Оскільки кожен слот може містити тисячі транзакцій, підтримка цього темпу є тим, що забезпечує високий TPS. Перервіть темп затримками поширення — і TPS впаде; підтримуйте його — і TPS залишиться високим.

Відмінність між теоретичним і фактичним TPS заслуговує на окрему увагу. Показник чистого TPS Solana (який може сягати вищих значень) включає транзакції голосування валідаторів, які є внутрішніми повідомленнями консенсусу і не представляють транзакції, подані користувачами. TPS без урахування голосів — показник, який більше можна порівняти з пропускною здатністю інших блокчейнів, — зазвичай становить від 2 000 до 4 000 під реальним навантаженням станом на 2024-2025 роки, згідно з документацією Solana Labs щодо продуктивності. Цифра 65 000 — це теоретична стеля за ідеальних умов; це не опис середньої поведінки мережі.

Дизайн пропускної здатності Turbine O(log n) також запобігає перетворенню рівня поширення на «вузьке місце» зі зростанням кількості валідаторів. При наївному підході до трансляції подвоєння кількості валідаторів подвоює пропускну здатність, необхідну від кожного вузла-відправника. Завдяки деревній структурі Turbine подвоєння кількості валідаторів додає лише один додатковий шар (приблизно на 200 валідаторів більше на кожен існуючий вузол), що означає, що вимоги до пропускної здатності зростають повільно, а не лінійно.

Ключовий висновок

Turbine не виконує транзакції; він поширює дані блоків. Продуктивність поширення може впливати на голосування та пропускну здатність, але Turbine не гарантує фіксований показник TPS, темп слотів або час фіналізації.

Чи безпечний Turbine? Модель безпеки та відомі вектори атак

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

Як рандомізована маршрутизація захищає від зловмисних валідаторів

Дерево сусідства перетасовується кожен слот з використанням верифікованої випадковості, отриманої з годинника Proof of History, що означає, що зловмисні валідатори не можуть передбачити, які валідатори будуть їхніми сусідами в наступному слоті. Це важливо, оскільки основним вектором атаки на багаторівневе дерево розподілу є атака затемнення (eclipse attack): зловмисник розміщує валідаторів навколо цільового валідатора і утримує фрагменти, перешкоджаючи цьому валідатору реконструювати блок і, отже, блокуючи його можливість голосувати.

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

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

Зважування за стейкінгом та занепокоєння щодо централізації

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

Чесна критика: валідатори з достатньо великою концентрацією стейкінгу теоретично могли б використовувати цей ранній доступ для спроб стратегій утримання блоків, затримуючи свій голос для отримання інформаційних переваг. Правила фіналізації консенсусу Tower BFT розроблені для обмеження життєздатності таких стратегій, а концентрація стейкінгу розподілена між приблизно 2 000+ активними валідаторами (згідно зі статистикою мережі Solana Foundation), що обмежує екстремальну концентрацію. Solana Foundation також запускає програми делегування стейкінгу, розроблені для більш широкого розподілу стейкінгу між меншими валідаторами. Проте структурна перевага для великих валідаторів є реальною, і її варто враховувати при будь-якій оцінці профілю децентралізації Solana.

Turbine, перевантаження мережі та історичні збої

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

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

Solana Turbine проти Ethereum та інших блокчейнів Рівня 1

Solana розповсюджує блоки швидше за Ethereum насамперед тому, що Turbine використовує ієрархічне дерево сусідства для паралельного розподілу шредів, тоді як Ethereum використовує протокол пліток (gossip protocol), де валідатори транслюють блоки випадковій підмножині пірів, які повторно транслюють їх своїм пірам, що є фундаментально повільнішою топологією при масштабуванні. У таблиці нижче порівнюються Solana, Ethereum та Avalanche за параметрами, які є найважливішими для розповсюдження блоків.

Одне розрізнення варто зробити явним: сама Solana використовує протокол пліток для обміну інформацією про кластер та метаданими протоколу, але Turbine замінює плітки для конкретного завдання розповсюдження блоків. Саме ієрархічне дерево Turbine перевершує плоску топологію пліток при розподілі блоків у великих масштабах.

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

Turbine відрізняється від протоколу BitTorrent двома способами, які наведена вище таблиця не повністю відображає. BitTorrent використовує плоский піринговий рій, де всі учасники рівні; Turbine використовує ієрархічне дерево з позиціями вузлів, зваженими за стейком. BitTorrent не має часових обмежень на збірку файлів; Turbine має доставити дані в межах 400-мілісекундного вікна слота, інакше консенсус буде пропущено. Ці розбіжності є відповідями на специфічні вимоги блокчейну, з якими модель BitTorrent не стикається.

Розповсюдження Snowflake/Snowball DAG в Avalanche використовує інший підхід: повторне випадкове опитування невеликих підмножин валідаторів для досягнення імовірнісного консенсусу без моделі єдиного лідера блоку. Цей дизайн забезпечує сублінійне масштабування пропускної здатності через вибірку, а не через дерево, і забезпечує швидшу фіналізацію, ніж Ethereum, водночас фундаментально відрізняючись від підходу Turbine на основі шредів. Кожен дизайн робить різні компроміси між швидкістю та децентралізацією з одного боку, та відмовостійкістю і складністю з іншого. Таблиця представляє ці компроміси; оголошення однієї архітектури кращою було б неправильним представленням простору проектування.

Turbine в архітектурі Solana: Всі 8 інновацій

Turbine є однією з восьми архітектурних інновацій, які Анатолій Яковенко представив у білій книзі Solana 2017 року, кожна з яких призначена для усунення певного вузького місця в інфраструктурі блокчейну. Повний список:

• Proof of History (PoH): Криптографічний механізм відліку часу Solana, функція перевіреної затримки, яка створює історичний запис порядку подій без необхідності спілкування валідаторів для узгодження часу. PoH не є механізмом консенсусу; це годинник. Він визначає структуру слотів, у межах якої працює Turbine.
• Tower BFT: Механізм консенсусу Solana на основі Proof of Stake, варіант Practical Byzantine Fault Tolerance (PBFT), який використовує годинник PoH для зменшення витрат на обмін повідомленнями при досягненні фіналізації.
• Turbine: Розповсюдження блоків, тема цієї статті. Turbine розподіляє щойно створені блоки всім валідаторам через шреди та дерево сусідства.
• Gulf Stream: Протокол пересилання транзакцій Solana. Gulf Stream просуває непідтверджені транзакції вперед до очікуваного лідера наступного блоку ще до того, як поточний блок буде фіналізовано, скорочуючи час, необхідний лідеру для збирання блоку.
• Sealevel: Механізм паралельного виконання смартконтрактів Solana, який обробляє тисячі смартконтрактів, що не перекриваються, одночасно, а не послідовно.
• Pipelining: Конвеєр обробки транзакцій, який призначає різні етапи валідації транзакцій виділеному обладнанню, дозволяючи одночасно валідувати кілька блоків на різних етапах обробки.
• Cloudbreak: Горизонтально масштабована база даних акаунтів Solana, оптимізована для одночасного читання та запису на апаратному забезпеченні валідатора.
• Archivers: Вузли зберігання розподіленого реєстру, які переносять історичні дані блокчейну з валідаторів на окремий рівень зберігання, знижуючи вимоги до обладнання валідаторів.

Gulf Stream і Turbine працюють послідовно протягом життєвого циклу транзакції. Gulf Stream спрямовує непідтверджені транзакції вперед до очікуваного лідера блоку до початку створення блоку; потім Turbine розповсюджує отриманий блок назовні всім валідаторам після завершення створення. Разом ці два протоколи керують повним життєвим циклом транзакції від подання до розповсюдження по всій мережі.

Ці вісім інновацій були представлені Анатолієм Яковенком, співзасновником Solana Labs, в оригінальній білій книзі Solana, опублікованій у 2017 році.

Перспектива валідатора

Позиція в дереві сусідства Turbine впливає на вимоги до обладнання валідатора. Валідатори, розташовані на Рівні 1 (ближче до лідера блоку), отримують шреди першими та повинні пересилати їх приблизно 200 валідаторам Рівня 2, що вимагає вищої пропускної здатності висхідного каналу, ніж у валідаторів Рівня 2, які пересилають дані лише своєму призначеному підсусідству. Рівень стейку визначає позицію в дереві: валідатори з вищим стейком займають позиції Рівня 1 і повинні забезпечувати відповідні ресурси. Операторам слід звертатися до поточних рекомендацій щодо апаратного забезпечення від Solana Labs, оскільки мінімальні специфікації змінилися з моменту запуску основної мережі.

Еволюція Turbine: Від 2017 року (Whitepaper) до сьогодні

Turbine була вперше описана в оригінальній білій книзі Solana, написаній Анатолієм Яковенком із Solana Labs у 2017 році, що робить її одним із основоположних архітектурних рішень протоколу, а не функцією, доданою пізніше. Специфікація 2017 року встановила основний дизайн: фрагментація блоків на основі шредів, розгалужене дерево для розповсюдження та кодування стирання Ріда-Соломона для відмовостійкості.

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

Після стресових подій у мережі в 2021 та 2022 роках Solana Labs виконала інженерні вдосконалення механізмів Turbine для обробки заторів, зокрема коригування способу постановки в чергу та передавання пакетів шредів за високого навантаження на мережу. Ці вдосконалення не змінили фундаментальну архітектуру протоколу, але поліпшили його поведінку на крайніх межах робочого діапазону.

Turbine наразі працює в безперервній промисловій експлуатації понад чотири роки в мережі, що обробляє мільйони транзакцій щодня. Цей експлуатаційний запис дає чітку відповідь на запитання, чи є Turbine перевіреним підходом або експериментальним: це промисловий протокол, випробуваний у реальних умовах на масштабі, з задокументованою інженерною спадкоємністю, яка простежується до специфікації 2017 року. Поточні параметри протоколу та нещодавні інженерні зміни дивіться в Solana Labs engineering blog.

Поширені запитання про розповсюдження блоків Solana Turbine

Наступні запитання охоплюють найпоширеніші звернення щодо дизайну та продуктивності Solana Turbine.

Що таке Solana Turbine?

Turbine — це протокол, який Solana використовує, щоб доставити щойно створені блоки до кожного валідатора в мережі в межах свого 400 мс слот-вікна. Він працює шляхом фрагментації блоків на шреди та маршрутизації їх через ієрархічне дерево «сусідств», при цьому кодування з виправленням помилок Reed-Solomon обробляє будь-які пакети, втрачені під час передавання. Результат — швидке, ефективне за пропускною здатністю розповсюдження блоків, яке масштабується в міру зростання набору валідаторів.

Що таке шред у Solana?

Шред — це фундаментальний пакет даних, який використовує Turbine для передавання блоків, розміром приблизно 1,5 КБ. Є два типи: дата-шреди, що переносять оригінальний вміст блоку, і кодувальні шреди — це надлишкові пакети, згенеровані за допомогою кодування Reed-Solomon, які дозволяють відновити блок, навіть якщо деякі дата-шреди були втрачені під час передавання.

Як Turbine розповсюджує дані блоку?

Лідер блоку розбиває блок на дата-шреди та генерує кодувальні шреди за допомогою кодування Reed-Solomon. Ці шреди проходять через дерево «сусідств»: лідер блоку надсилає їх приблизно 200 валідаторам Рівня 1, кожен із яких пересилає їх приблизно 200 валідаторам Рівня 2, охоплюючи весь активний набір валідаторів у межах двох-трьох рівнів і завершуючи в межах приблизно 400 мс слот-вікна.

Чому Solana швидша за Ethereum у розповсюдженні блоків?

Solana використовує ієрархічне дерево «сусідств» Turbine, яке розповсюджує шреди паралельно через багатьох валідаторів одночасно, досягаючи масштабування пропускної здатності O(log n). Ethereum використовує протокол пліток (gossip), який потребує кількох послідовних раундів випадкового повторного ретранслювання між вузлами, щоб охопити всю мережу, що призводить до часу блоку приблизно 12 секунд проти приблизно 400 мс слот-часу в Solana. Обидва дизайни відображають усвідомлені архітектурні пріоритети.

Чи є Turbine безпечним?

Turbine включає рандомізовану маршрутизацію (дерево «сусідств» перетасовується кожен слот із використанням підтверджуваної випадковості), надлишковість Reed-Solomon (допускаючи приблизно одну третину втрати пакетів) та позиціонування, зважене за обсягом внесеного в стейкінг. Рандомізована маршрутизація значно ускладнює виконання атак типу затемнення (eclipse). Зважування за стейкінгом вводить помірний компроміс щодо централізації: валідатори з більшим обсягом вносити в стейкінг отримують шреди раніше, створюючи структурну перевагу, яку частково компенсують правила консенсусу Tower BFT.

Що стається, якщо шреди втрачаються?

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

Чи створює Turbine ризики централізації?

Зважування Turbine за обсягом вносити в стейкінг справді створює структурну перевагу для валідаторів із великим стейкінгом, які отримують шреди раніше й займають вищі позиції в дереві «сусідств». Це реальний компроміс. Пом’якшувальними чинниками є розподіл Solana між понад 2000 активних валідаторів, правила консенсусу Tower BFT, що обмежують цінність раннього доступу до шредів, а також програми делегування стейкінгу від Solana Foundation, спрямовані на розширення розподілу стейкінгу.

Хто створив Solana Turbine?

Turbine був розроблений Анатолієм Яковенком, співзасновником Solana Labs, і вперше описаний у Whitepaper Solana, опублікованому в 2017 році. Solana Labs (інженерна організація, відмінна від Solana Foundation, яка займається управлінням екосистемою) підтримує та продовжує розвивати протокол.

Як Turbine пов’язаний із Gulf Stream?

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

Скільки TPS може обробляти Solana?

Turbine працює в продакшені з 2020 року і був вдосконалений у відповідь на реальні умови. Зі зростанням кількості валідаторів Solana властивість масштабування O(log n) стає все більш важливою: кожне подвоєння набору валідаторів додає лише один рівень дерева замість подвоєння витрат на пропускну здатність. Саме ця властивість робить дизайн довговічним у великих масштабах. Швидкість і надійність пропаганди блоків Turbine також роблять Solana життєздатним інфраструктурним рівнем для високочастотних децентралізованих фінансових (DeFi) додатків, де затримка пропаганди безпосередньо впливає на результати підтвердження транзакцій.

Ключовий висновок

Turbine є інженерною основою, яка робить твердження Solana про швидкість достовірними. Розуміння того, як він фрагментує блоки на шматки, маршрутизує їх через дерево сусідства, зважене за стейком, і відновлює втрачені пакети за допомогою кодування з виправленням помилок Reed-Solomon, є найчіткішим способом оцінити, чи ґрунтуються ці твердження про продуктивність на надійній архітектурі. Дизайн має справжні сильні сторони та справжні компроміси; обидва заслуговують на увагу в будь-якій чесній технічній оцінці інфраструктури Solana.

Подальше читання та першоджерела

Наступні першоджерела надають технічну основу для тверджень, зроблених у цій статті.

• Пропаганда блоків Turbine (Solana Docs): Офіційна технічна документація для Turbine, яку підтримують інженери Solana Labs.
• Оригінальний Whitepaper Solana від Анатолія Яковенка (2017): Засновницька специфікація для Turbine та всіх восьми архітектурних інновацій Solana.
• Інженерний блог Solana Labs: Останні інженерні оновлення, покращення протоколу та аналізи причин збоїв від Solana Labs.
• GitHub Solana: вихідний код Turbine:) Вихідний код для розробників, які хочуть безпосередньо вивчити реалізацію Turbine.
• Мережева статистика Solana Foundation: Поточна кількість валідаторів, дані розподілу стейків та показники стану мережі.

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