Оригінальна назва: "Turbine: Block Propagation on Solana"

Автор оригіналу: Райан Черн

Оригінальна збірка: Sharon, BlockBeats

Про автора: Автор цієї статті, Раян Черн, був колишнім інженером-стажером у Solana та співзасновником Quantum Labs. Зараз працює в Blackhawk Research, дослідницькому центрі криптовалют.

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

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

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

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

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

Що таке турбіна?

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

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

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

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

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

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

Як Turbine поширює блоки?

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

Потім повідомлення про голосування передаються між валідаторами, і ці повідомлення інкапсулюються в дані блоку, щоб відповідати статусу зобов’язання «підтверджено» або «завершено». Підтверджений блок – це блок, який отримав більшість голосів у реєстрі, а фінальний блок – це підтверджений блок із понад 31 підтвердженим блоком, побудованим поверх цільового блоку. Тут детально описано різницю в статусі зобов’язання. Ця частина консенсусу буде обговорена в наступній статті.

Візуалізація позиції Turbine у ​​життєвому циклі транзакції Solana

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

На високому рівні Turbine бере шарди та надсилає їх до попередньо визначеного набору валідаторів, який потім пересилає шарди до нового набору валідаторів. На діаграмі нижче узагальнено безперервне поширення сміття:

Як показано на малюнку вище, незважаючи на те, що це називається «блоковим розповсюдженням», дані поширюються на рівні фрагментів

У цьому прикладі валідатор 1 є призначеним лідером слота. Під час свого слоту (валідатор позначається як лідер для 4 послідовних слотів), валідатор 1 створює та пропонує блок. Валідатор 1 спочатку розбиває блок на підблоки, які називаються сегментами, за допомогою процесу, що називається подрібненням.

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

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

кодування стирання

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

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

На високому рівні, якщо лідер передає 33% пакетів блоку як код стирання, тоді мережа може відкинути будь-які 33% пакетів без втрати блоку. Лідер може динамічно регулювати це число (швидкість FEC) на основі умов мережі, беручи до уваги такі змінні, як нещодавно спостережена втрата пакетів у всій мережі та глибина дерева.

Для простоти розглянемо групу фрагментації зі співвідношенням FEC 4:4.

Приклад групи фрагментації: 4 з 8 пакетів можуть бути підроблені або втрачені без впливу на вихідні дані

Шарди даних — це часткові фрагменти вихідного блоку, створені лідером, тоді як сегменти відновлення — це блоки зі стиранням коду, створені Рідом-Соломоном.

Блоки на Solana зазвичай використовують FEC 32:32 (32 пакети з 64 можуть бути втрачені без повторної передачі). Як зазначено в документації Solana, наступні консервативні припущення мережі:

· Рівень втрати пакетів 15%

· 50k TPS генерує 6400 шардів за секунду

Показник FEC 32:32 забезпечує приблизно 99% успіху блокування. Крім того, лідери мають право підвищувати показник FEC, якщо вони вирішать збільшити ймовірність успішного блокування.

Зараз Turbine використовує UDP для розповсюдження блоків, що забезпечує величезні переваги затримки. За словами оператора валідатора, передача 6 Мб+ кодованих даних із стиранням від us-east-1 до eu-north-1 займає 100 мс за допомогою UDP проти 900 мс за допомогою TCP.

Турбінне дерево

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

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

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

2. Перемішування списків: список перемішується детермінованим способом. Це створить «дерево турбіни» з набору вузлів валідатора кожного шарда з використанням початкового числа, отриманого з ідентифікатора лідера слота, слота, індексу фрагмента та типу фрагмента. Нове дерево створюється для кожної групи фрагментів під час виконання, щоб зменшити потенційні ризики безпеки, пов’язані зі статичними структурами дерева.

3. Формування шару: потім вузли поділяються на шари, починаючи з верхньої частини списку. Розбиття базується на значенні DATA_PLANE_FANOUT, яке визначає ширину та глибину дерева турбіни. Це значення впливає на швидкість поширення фрагментів у мережі. Наразі DATA_PLANE_FANOUT дорівнює 6.

Добре відоме дерево Turbine гарантує, що кожен валідатор точно знає, де він відповідає за ретрансляцію цього фрагмента. Якщо припустити, що поточне значення DATA_PLANE_FANOUT дорівнює 6, дерево Turbine зазвичай складається з 4 або 5 переходів (залежно від кількості активних валідаторів).

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

Порівняння поширення блоків між Solana та Ethereum

Поширення блоків на Solana відрізняється від поширення на Ethereum. Ось деякі відмінності високого рівня:

1. Вимоги Solana до ідеальної пропускної здатності (>1 Гбіт/с) значно вищі, ніж у Ethereum (geth рекомендує >25 Мбіт/с). Ця вища вимога до пропускної здатності зумовлена ​​більшим розміром блоків Solana та швидшим часом блокування. Solana розроблено для ефективного використання всієї смуги пропускання для прискорення передачі даних, тим самим зменшуючи затримку. Хоча пікова пропускна здатність досягає 1 Гбіт/с, 1 Гбіт/с не використовується постійно. Архітектура Solana розроблена для роботи з піками попиту на пропускну здатність.

2. Solana використовує Turbine для розповсюдження блокових даних, тоді як Ethereum використовує стандартний протокол gossip. В Ethereum блокове розповсюдження даних відбувається простим способом: кожен вузол спілкується з усіма іншими повними вузлами в мережі. Щойно з’явиться новий блок, клієнт перевірить його, надіславши його одноранговим клієнтам і затвердивши транзакції в цьому блоці. Цей механізм підходить для Ethereum, оскільки він має менші розміри блоків і довший час блокування порівняно з Solana. Що стосується сукупних даних Ethereum L2 (за винятком валідіуму), то розповсюдження також відбувається за протоколом gossip, а дані блоку зберігаються в полі «calldata» блоку Ethereum L1.

3. Ethereum використовує TCP (через протокол DevP2P) для розповсюдження блоків, тоді як Solana використовує UDP (перехід на QUIC із певною підтримкою спільноти). Є деякі компроміси, які слід враховувати між UDP і QUIC:

· Односпрямований характер UDP призводить до меншої затримки порівняно з QUIC, отже, потреба в потоках QUIC. Дискусії щодо впровадження односпрямованого потоку в QUIC тривають;

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

Ці відмінності підкреслюють унікальні архітектурні рішення, прийняті Solana та Ethereum, які допомагають покращити їх відповідну продуктивність, масштабованість і надійність мережі. Для більш глибокого аналізу TCP, UDP та QUIC перегляньте нашу статтю про Solana та QUIC.

питання майбутніх досліджень

Розповсюдження блоків і доступність даних залишаються відкритими областями дослідження, і багато команд розробляють власні унікальні підходи. Хоча показники можуть продовжувати розвиватися, ми хотіли б надати огляд різних підходів і пов’язаних із ними компромісів:

1. Виникла дискусія щодо Turbine як механізму «доступності даних» (DA). Turbine діє як механізм доступності даних, при цьому всі дані блоку публікуються та завантажуються всіма іншими валідаторами на Solana. Тим не менш, Turbine не підтримує вибірку доступності даних (DAS), функцію, яка допомагає світловим вузлам перевіряти стан зі зниженими вимогами до обладнання. Це активний фокус розвитку для таких команд, як Celestia. Як і Turbine, DAS використовує кодування стирання, але робить це з явною метою виявлення та запобігання атакам приховування даних.

2. Tubrine втратив актуальність для Solana Virtual Machine (SVM) L2 (наприклад, Eclipse), оскільки не було встановлено валідатори для передачі даних між ними. У випадку Eclipse дані блоків публікуються в Celestia для забезпечення доступності даних — це дає змогу зовнішнім спостерігачам запускати докази шахрайства для забезпечення правильного виконання та переходів між станами. Eclipse стане однією з перших реалізацій SVM за межами самої мережі Solana. Pyth також розгалужив SVM для своєї власної мережі Oracle "Pythnet" і фактично запустив її як власну сайдчейн.

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

4. Турбіна надає пріоритет вузлам із вищою вагою для отримання блокових даних першими. Чи призведе це з часом до більшої централізації MEV?

5. Як різні підходи до доступності даних, такі як EigenDA (горизонтально масштабована одноадресна ретрансляція) і Celestia (вибірка доступності даних), порівнюються з Turbine у ​​виробництві з точки зору вихідної пропускної здатності та мінімізації довіри?

6. Firedancer розроблено для подальшого збільшення розповсюдження даних і оптимізовано для потужних з’єднань із пропускною здатністю 10 Гбіт/с. Як їх оптимізація системного рівня навколо Turbine працюватиме у виробництві на споживчому та професійному обладнанні?

7. Наразі всі вузли на Solana є повними вузлами (реалізація полегшеного клієнта все ще розробляється). Срірам Каннан (EigenLayer) нещодавно описав впровадження DAS-S поверх Turbine. Чи буде підтримка версії DAS для Turbine? Чи можна реалізувати легкі клієнти з DAS, щоб підтримувати високу пропускну здатність даних, у той час як легкі клієнти (зі значно меншими вимогами до ресурсів) задовольняють мінімізацію довіри?

на закінчення

Щиро вітаю! У цій статті ми розглянемо Turbine і те, як вона працює в ширшому просторі транзакцій Solana. Ми порівнюємо Turbine з іншими рішеннями щодо доступності даних і обговорюємо різні напрямки дослідження, відкриті в цій галузі. Протокол Turbine від Solana демонструє прагнення мережі досягти високої пропускної здатності та низької затримки шляхом використання структурованої топології мережі для ефективного розповсюдження блокових даних між валідаторами.

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

Рішення для ефективного розповсюдження та доступності даних ще далекі від завершення. Проте підхід і тверда прихильність Solana до оптимізації продуктивності мережі без шкоди для безпеки та мінімізації довіри були тепло схвалені.

Оригінальне посилання