Оригінальна назва: Alpenglow: новий консенсус для Solana
Оригінальні автори: Квентін Кніп, Кобі Слівінський та Роджер Ваттенхофер
Оригінальний переклад: zhouzhou,
Примітка редактора: Alpenglow — це новий консенсусний протокол, представлений Solana, який замінює попередні механізми TowerBFT та історичного доказу, запроваджуючи Votor та Rotor, оптимізуючи голосування та поширення даних, значно знижуючи затримки до 100–150 мілісекунд, забезпечуючи фіналізацію за секунди. Цей протокол посилив продуктивність, стійкість та масштабованість, дозволяючи Solana досягти швидкості реакції, що порівнянна з Web2.
Нижче наведено оригінальний зміст (для зручності читання оригінальний зміст було відредаговано):
Ми з гордістю представляємо Alpenglow, новий консенсусний протокол для Solana. Alpenglow — це консенсусний протокол, розроблений спеціально для глобальних високопродуктивних блокчейнів на основі Proof-of-Stake. Ми віримо, що запуск Alpenglow стане вирішальним моментом для Solana. Це не лише новий механізм консенсусу, але й найбільша зміна в основному протоколі з моменту заснування Solana.
Під час міграції до Alpenglow ми попрощаємося з рядом старих основних компонентів, особливо з TowerBFT та історичним доказом (Proof-of-History). Ми впровадили новий модуль Votor, який відповідає за логіку голосування та остаточного підтвердження блоків. Крім того, Alpenglow відмовився від комунікації на основі gossip, перейшовши на швидший прямий комунікаційний примітив.
Незважаючи на те, що це велика зміна, Alpenglow все ще базується на найбільшій перевазі Solana. Turbine зіграв ключову роль у успіху мережі Solana, вирішивши важливу проблему поширення даних. У традиційних блокчейнах лідери часто є вузьким місцем системи.
Технологія, що використовується в Turbine, розділяє кожен блок на багато менших фрагментів за допомогою кодування з виправленням помилок (erasure-coding) і швидко поширює їх. Ключовим моментом є те, що цей процес повністю використовує пропускну здатність усіх вузлів. Протокол передачі даних Rotor в Alpenglow продовжує та оптимізує дизайн Turbine.
Завдяки цим трансформаціям ми підняли продуктивність Solana на небачену висоту. При використанні TowerBFT від моменту генерації блоку до остаточного підтвердження проходить приблизно 12,8 секунди. Щоб зменшити затримку до підсумкової секунди, Solana впровадила концепцію «оптимістичного підтвердження».
А Alpenglow зможе подолати ці обмеження затримки. Ми очікуємо, що Alpenglow зможе знизити фактичний час остаточного підтвердження до приблизно 150 мілісекунд (медіана).
У деяких випадках остаточне підтвердження можна досягти навіть за 100 мілісекунд — це майже неймовірна швидкість для глобальних L1 блокчейн-протоколів. (Ці дані затримки базуються на результати моделювання поточного розподілу стейків у головній мережі та не включають обчислювальні витрати.)
Медійна затримка в 150 мілісекунд не тільки означає, що Solana швидша — це означає, що реактивність Solana може зрівнятися з інфраструктурою Web2, що має потенціал зробити технологію блокчейн життєздатною в нових сферах застосування, де потрібна реальна продуктивність.
!
Зображення вище показує розподіл затримок на різних етапах протоколу Alpenglow, коли лідер знаходиться у Цюріху, Швейцарія. Ми вибрали Цюріх як приклад, оскільки саме в цьому місті ми розробляли Alpenglow.
Кожен стовпчиковий графік показує середню затримку поточного вузла Solana у глобальному розподілі, відсортовану за відстанню до Цюриха.
На малюнку зображено симульовану затримку досягнення різних етапів протоколу Alpenglow для вузлів мережі, що відповідає частці вузлів мережі, які досягли цього етапу.
Зелені смуги означають затримку мережі. Виходячи з поточного розподілу вузлів у Solana, близько 65% вузлів стейкінгу знаходяться в межах 50 мс від затримки мережі від Цюріха. Хвіст затримки довший, і деякі вузли стейкінгу зазнають затримки понад 200 мілісекунд від мережі Цюріха.
Затримка в мережі є природним нижнім межем у наших графіках — наприклад, якщо певний вузол знаходиться на відстані 100 мілісекунд від Цюриха, то будь-якому протоколу, щоб завершити остаточне підтвердження блоку на цьому вузлі, знадобиться принаймні 100 мілісекунд.
Жовті стовпці відображають затримку протоколу Rotor (протокол поширення даних), це перша стадія протоколу Alpenglow.
Червона стовпчаста діаграма показує час, витрачений на нотаріальне голосування, яке отримало щонайменше 60% ваги стейку.
Сині стовпці - це остаточний час підтвердження.
Отже, звідки походить висока продуктивність Alpenglow?
Голосувальний компонент Alpenglow Votor реалізує надзвичайно ефективний механізм однораундного голосування: якщо 80% закладених вузлів беруть участь, блок може бути підтверджений за один раунд голосування; якщо лише 60% закладених вузлів реагують, він також може бути завершений за два раунди голосування. Ці два режими є інтегрованими і виконуються паралельно, і обирається той шлях, який є швидшим для остаточного підтвердження блоку.
Підпротокол поширення даних Alpenglow, Rotor, продовжує та оптимізує підхід Turbine. Подібно до Turbine, Rotor використовує свою пропускну здатність пропорційно залежно від ваги стейкінгу вузла, зменшуючи вузьке місце лідерів і досягаючи високої пропускної здатності. В результаті загальна пропускна здатність використовується майже до оптимального рівня. Одна з ідей дизайну Ротора полягає в тому, що насправді затримка поширення інформації в першу чергу обмежена затримкою мережі, а не швидкістю передачі або обчислень. Rotor використовує один шар ретрансляційних вузлів замість багатошарової деревоподібної структури Turbine, що зменшує кількість переходів мережі. Крім того, компанія Rotor представила новий механізм вибору вузла реле для підвищення надійності.
Alpenglow є результатом передових досліджень, які поєднують розподіл даних з кодуванням стирання з найсучаснішими механізмами консенсусу. Його інновації включають інтегрований механізм голосування в один або два раунди, що призводить до безпрецедентних затримок із завершенням блокування. У той же час він також вводить унікальний «механізм відмовостійкості 20+20»: навіть якщо умови мережі суворі, протокол все ще може працювати нормально, терплячи до 20% шкідливих вузлів стейкінгу та ще 20% вузлів, що не відповідають. Інші внески включають стратегію вибірки з низькою дисперсією.
Ми вже написали повний технічний білл, який детально описує Alpenglow. Білл не лише пояснює інтуїцію та цілі, що стоять за нашим дизайном, але й пояснює увесь протокол за допомогою зрозумілих визначень та псевдокоду. Крім того, він містить різноманітні симуляційні дані та обчислення, які допомагають читачам зрозуміти фактичну продуктивність Alpenglow, на завершення також надається повне доведення коректності.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Від TowerBFT до Alpenglow, Solana входить в епоху сотих часток секунди
Примітка редактора: Alpenglow — це новий консенсусний протокол, представлений Solana, який замінює попередні механізми TowerBFT та історичного доказу, запроваджуючи Votor та Rotor, оптимізуючи голосування та поширення даних, значно знижуючи затримки до 100–150 мілісекунд, забезпечуючи фіналізацію за секунди. Цей протокол посилив продуктивність, стійкість та масштабованість, дозволяючи Solana досягти швидкості реакції, що порівнянна з Web2.
Нижче наведено оригінальний зміст (для зручності читання оригінальний зміст було відредаговано):
Ми з гордістю представляємо Alpenglow, новий консенсусний протокол для Solana. Alpenglow — це консенсусний протокол, розроблений спеціально для глобальних високопродуктивних блокчейнів на основі Proof-of-Stake. Ми віримо, що запуск Alpenglow стане вирішальним моментом для Solana. Це не лише новий механізм консенсусу, але й найбільша зміна в основному протоколі з моменту заснування Solana.
Під час міграції до Alpenglow ми попрощаємося з рядом старих основних компонентів, особливо з TowerBFT та історичним доказом (Proof-of-History). Ми впровадили новий модуль Votor, який відповідає за логіку голосування та остаточного підтвердження блоків. Крім того, Alpenglow відмовився від комунікації на основі gossip, перейшовши на швидший прямий комунікаційний примітив.
Незважаючи на те, що це велика зміна, Alpenglow все ще базується на найбільшій перевазі Solana. Turbine зіграв ключову роль у успіху мережі Solana, вирішивши важливу проблему поширення даних. У традиційних блокчейнах лідери часто є вузьким місцем системи.
Технологія, що використовується в Turbine, розділяє кожен блок на багато менших фрагментів за допомогою кодування з виправленням помилок (erasure-coding) і швидко поширює їх. Ключовим моментом є те, що цей процес повністю використовує пропускну здатність усіх вузлів. Протокол передачі даних Rotor в Alpenglow продовжує та оптимізує дизайн Turbine.
Завдяки цим трансформаціям ми підняли продуктивність Solana на небачену висоту. При використанні TowerBFT від моменту генерації блоку до остаточного підтвердження проходить приблизно 12,8 секунди. Щоб зменшити затримку до підсумкової секунди, Solana впровадила концепцію «оптимістичного підтвердження».
А Alpenglow зможе подолати ці обмеження затримки. Ми очікуємо, що Alpenglow зможе знизити фактичний час остаточного підтвердження до приблизно 150 мілісекунд (медіана).
У деяких випадках остаточне підтвердження можна досягти навіть за 100 мілісекунд — це майже неймовірна швидкість для глобальних L1 блокчейн-протоколів. (Ці дані затримки базуються на результати моделювання поточного розподілу стейків у головній мережі та не включають обчислювальні витрати.)
Медійна затримка в 150 мілісекунд не тільки означає, що Solana швидша — це означає, що реактивність Solana може зрівнятися з інфраструктурою Web2, що має потенціал зробити технологію блокчейн життєздатною в нових сферах застосування, де потрібна реальна продуктивність.
!
Зображення вище показує розподіл затримок на різних етапах протоколу Alpenglow, коли лідер знаходиться у Цюріху, Швейцарія. Ми вибрали Цюріх як приклад, оскільки саме в цьому місті ми розробляли Alpenglow.
Кожен стовпчиковий графік показує середню затримку поточного вузла Solana у глобальному розподілі, відсортовану за відстанню до Цюриха.
На малюнку зображено симульовану затримку досягнення різних етапів протоколу Alpenglow для вузлів мережі, що відповідає частці вузлів мережі, які досягли цього етапу.
Зелені смуги означають затримку мережі. Виходячи з поточного розподілу вузлів у Solana, близько 65% вузлів стейкінгу знаходяться в межах 50 мс від затримки мережі від Цюріха. Хвіст затримки довший, і деякі вузли стейкінгу зазнають затримки понад 200 мілісекунд від мережі Цюріха.
Затримка в мережі є природним нижнім межем у наших графіках — наприклад, якщо певний вузол знаходиться на відстані 100 мілісекунд від Цюриха, то будь-якому протоколу, щоб завершити остаточне підтвердження блоку на цьому вузлі, знадобиться принаймні 100 мілісекунд.
Жовті стовпці відображають затримку протоколу Rotor (протокол поширення даних), це перша стадія протоколу Alpenglow.
Червона стовпчаста діаграма показує час, витрачений на нотаріальне голосування, яке отримало щонайменше 60% ваги стейку.
Сині стовпці - це остаточний час підтвердження.
Отже, звідки походить висока продуктивність Alpenglow?
Голосувальний компонент Alpenglow Votor реалізує надзвичайно ефективний механізм однораундного голосування: якщо 80% закладених вузлів беруть участь, блок може бути підтверджений за один раунд голосування; якщо лише 60% закладених вузлів реагують, він також може бути завершений за два раунди голосування. Ці два режими є інтегрованими і виконуються паралельно, і обирається той шлях, який є швидшим для остаточного підтвердження блоку.
Підпротокол поширення даних Alpenglow, Rotor, продовжує та оптимізує підхід Turbine. Подібно до Turbine, Rotor використовує свою пропускну здатність пропорційно залежно від ваги стейкінгу вузла, зменшуючи вузьке місце лідерів і досягаючи високої пропускної здатності. В результаті загальна пропускна здатність використовується майже до оптимального рівня. Одна з ідей дизайну Ротора полягає в тому, що насправді затримка поширення інформації в першу чергу обмежена затримкою мережі, а не швидкістю передачі або обчислень. Rotor використовує один шар ретрансляційних вузлів замість багатошарової деревоподібної структури Turbine, що зменшує кількість переходів мережі. Крім того, компанія Rotor представила новий механізм вибору вузла реле для підвищення надійності.
Alpenglow є результатом передових досліджень, які поєднують розподіл даних з кодуванням стирання з найсучаснішими механізмами консенсусу. Його інновації включають інтегрований механізм голосування в один або два раунди, що призводить до безпрецедентних затримок із завершенням блокування. У той же час він також вводить унікальний «механізм відмовостійкості 20+20»: навіть якщо умови мережі суворі, протокол все ще може працювати нормально, терплячи до 20% шкідливих вузлів стейкінгу та ще 20% вузлів, що не відповідають. Інші внески включають стратегію вибірки з низькою дисперсією.
Ми вже написали повний технічний білл, який детально описує Alpenglow. Білл не лише пояснює інтуїцію та цілі, що стоять за нашим дизайном, але й пояснює увесь протокол за допомогою зрозумілих визначень та псевдокоду. Крім того, він містить різноманітні симуляційні дані та обчислення, які допомагають читачам зрозуміти фактичну продуктивність Alpenglow, на завершення також надається повне доведення коректності.
「оригінальне посилання」
：