Механізм консенсусу Solana: PoH, Tower BFT, PoS

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

Механізм консенсусу Solana поєднує Proof of History для впорядкування за часом, Tower BFT для зваженого голосування відповідно до стейкінгу та Proof of Stake для участі валідаторів та стимулювання.

TL;DR: Solana використовує Proof of History для впорядкування за часом, Tower BFT для зваженого голосування відповідно до стейкінгу та вибору форку, а Proof of Stake для участі валідаторів та стимулювання. Пропускна здатність та підтвердження залежать від повного часу виконання, умов мережі, суміші транзакцій та рівня вимірюваної відданості.

Зміст

1. Що таке механізм консенсусу Solana?
2. Проблема, яку Solana була створена вирішити
3. Proof of History: Криптографічний годинник Solana пояснено
4. Tower BFT: Як валідатори досягають згоди
5. Як Proof of History, Tower BFT та Proof of Stake працюють разом
6. Як транзакція Solana досягає фінальності: Покроково
7. Продуктивність Solana: Швидкість, Пропускна здатність та Фінальність
8. Консенсус Solana проти Ethereum, Avalanche, Cardano та Polkadot
9. Сильні та слабкі сторони моделі консенсусу Solana
10. Як взяти участь: Стейкінг та валідація на Solana
11. Часті запитання
12. Ключові висновки

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

Solana запустила свою Mainnet Beta у березні 2020 року і швидко привернула увагу обробкою тисяч транзакцій за секунду за частки цента за транзакцію. Протоколи DeFi та ринки NFT, створені на Solana, залежать від цієї пропускної здатності; саме вона робить практичними ончейн-торгівлю в реальному часі, масові карбування NFT та платежі з мікрокомісіями. Але швидкість без надійності не є фундаментом, на якому варто будувати, і кілька резонансних збоїв між 2021 та 2023 роками поставили обґрунтовані питання щодо того, чи є архітектура протоколу надійною.

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

Що таке механізм консенсусу Solana?

Solana використовує гібридну систему консенсусу, що поєднує три компоненти: Proof of History (PoH), Tower BFT та Proof of Stake (PoS). Proof of History діє як криптографічний годинник, який встановлює часові мітки для транзакцій перед тим, як валідатори зв'яжуться. Tower BFT — це алгоритм візантійської відмовостійкості, який досягає консенсусу, використовуючи PoH як спільний годинник. Proof of Stake визначає, які валідатори беруть участь, і зважує їхні голоси на основі внесених у стейкінг SOL.

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

Ось як система працює на високому рівні:

1. Proof of History генерує безперервний, перевірений запис часу, яким користуються всі валідатори в мережі.
2. Валідатори (учасники мережі, які генерують та перевіряють блоки) призначаються до певних часових слотів залежно від кількості SOL, яку вони внесли в стейкінг.
3. Призначений лідер-валідатор для кожного слоту використовує часову шкалу PoH для встановлення часових міток і збирання транзакцій у блок.
4. Усі інші валідатори перевіряють блок і подають зважені голоси Tower BFT відповідно до стейкінгу; коли більше двох третин SOL, внесених у стейкінг, підтверджують блок, він досягає фінальності.

Поширений хибний уявлення: Solana не є блокчейном Proof of Work (тут немає вирішення обчислювальних головоломок або енергоємних обчислень). Називати Solana просто "блокчейном Proof of Stake" технічно правильно, але неповне. Це опускає Proof of History та Tower BFT, які є однаково центральними для того, як Solana досягає консенсусу. Повне та точне визначення: Solana використовує гібридну систему, що поєднує PoH, Tower BFT та PoS.

Проблема, яку Solana була створена вирішити

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

Трілема масштабованості блокчейну, фреймворк, популяризований співзасновником Ethereum Віталіком Бутеріним, описує, чому це складно. Трілема стверджує, що блокчейн може реально досягти щонайбільше двох з трьох властивостей одночасно: децентралізації, безпеки та масштабованості. Bitcoin, оригінальний блокчейн, надає пріоритет децентралізації та безпеці. Результатом є мережа, яка досягає приблизно 7 транзакцій за секунду з 10-хвилинними часовими проміжками блоків, властивості, які є безпечними та широко розподіленими, але роблять Bitcoin непрактичним для високочастотних застосувань. Ранній Ethereum стикався з подібними обмеженнями до свого власного шляху оновлення.

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

Анатолій Яковенко, колишній інженер Qualcomm, який присвятив свою кар'єру роботі з розподіленими системами та синхронізацією годинника на апаратному рівні, визначив цю проблему комунікації часових міток як фундаментальне вузьке місце. Його ключова ідея: якщо валідатори зможуть спільно використовувати єдиний, криптографічно перевірений годинник, якому всі довіряють без необхідності обмінюватися часовими мітками один з одним, процес консенсусу може бути значно швидшим. У листопаді 2017 року Яковенко опублікував Solana: A new architecture for a high performance blockchain,), окресливши те, що стане Proof of History. Він заснував Solana Labs (комерційну компанію-розробника, що стоїть за протоколом Solana) разом з Грегом Фітцджеральдом та Раджем Гокалом, і ці троє запустили Mainnet Beta у березні 2020 року.

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

Proof of History: Криптографічний годинник Solana пояснено

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

PoH не є механізмом консенсусу. Це годинник, який робить механізм консенсусу Solana можливим.

Яку проблему вирішує Доказ історії?

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

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

Як працює Доказ історії: Ланцюжок хешів

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

Технічний механізм працює наступним чином:

1. Генератор PoH Solana починає з початкового хеш-значення.
2. Він застосовує криптографічну хеш-функцію SHA-256 до цього значення, генеруючи новий 256-бітний вихід.
3. Він негайно передає цей вихід як вхідні дані для наступної операції SHA-256.
4. Кожен хеш у ланцюжку записується разом із лічильником, створюючи перевірену послідовність, яка підтверджує, що минув реальний обчислювальний час.
5. Транзакції вставляються в ланцюжок хешів у певних позиціях, назавжди отримуючи часові мітки проти перевіреної послідовності ще до того, як валідатору потрібно буде зв'язатися з будь-яким іншим.

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

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

Технічний огляд: SHA-256 — це одностороння криптографічна хеш-функція: її легко обчислити в одному напрямку, але обчислювально неможливо її обернути. Послідовне з'єднання виходів SHA-256 надає PoH властивість "перевіреної затримки": для створення ланцюжка потрібен реальний час (послідовні обчислення не можна паралелізувати), але його можна дуже швидко паралельно перевірити будь-яким спостерігачем, який перевіряє кожен хеш проти попереднього. Це функціонально схоже на перевірену функцію затримки (VDF) — криптографічну конструкцію, яка вимагає мінімальної послідовної обчислювальної потужності для створення, але може бути швидко перевірена. Роль SHA-256 у PoH повністю відрізняється від його ролі в Bitcoin, де він використовується як конкурентна головоломка (пошук хешу нижче певного порогу). У PoH SHA-256 використовується для послідовного відліку часу, а не для конкурентних обчислень.

Доказ історії не є механізмом консенсусу Solana. Механізм консенсусу — це процес, за допомогою якого валідатори досягають згоди щодо того, які транзакції є дійсними та в якому порядку. PoH цього не робить. PoH записує порядок і час подій; Tower BFT — це алгоритм, який досягає консенсусу щодо дійсності цих подій.

PoH також не є Доказом частки (Proof of Stake). Proof of Stake визначає, хто економічно має право брати участь у консенсусі та яку вагу має їхній голос. PoH не визначає право участі або вагу голосу; він надає спільний годинник, який прискорює процес голосування.

Помилкове уявлення про те, що «Solana використовує Доказ історії» як повний механізм консенсусу, є однією з найпоширеніших помилок у публічних матеріалах про Solana. Це неточно, і це має значення: без Tower BFT і Proof of Stake, сам по собі PoH не надавав би жодних гарантій безпеки.

Tower BFT: Як валідатори досягають згоди

Tower BFT — це алгоритм консенсусу Solana, адаптація Practical Byzantine Fault Tolerance (PBFT), створена для використання PoH як спільного годинника. Він дозволяє валідаторам досягати згоди щодо стану блокчейну за допомогою зважених голосів, що залежать від стейкінгу. Оскільки валідатори використовують Proof of History як довірений годинник, Tower BFT вимагає значно менше раундів комунікації, ніж стандартні реалізації BFT, і фіналізує блоки приблизно за 400–800 мілісекунд за нормальних умов мережі.

Назва походить від проблеми візантійських генералів — класичного експерименту з розподілених систем, формалізованого Леслі Лемпортом у 1982 році. Проблема ставить питання: як група генералів може скоординувати атаку, якщо деякі з них можуть бути зрадниками, що надсилають неправдиву інформацію? Система є візантійсько-відмовостійкою (Byzantine Fault Tolerant), якщо вона може досягти правильного консенсусу, навіть коли деякі учасники діють зі злим умислом, надсилають неправдиві повідомлення або зазнають збоїв довільним чином.

Традиційні BFT-системи, включно з основоположним алгоритмом PBFT, опублікованим Мігелем Кастро та Барбарою Лісков у 1999 році, вимагають, щоб менше третини всіх учасників були несправними або зловмисними. Для мережі зі 100 валідаторами до 33 можуть бути скомпрометовані, а решта 67 все одно можуть досягти правильного консенсусу. Ця властивість математично доводиться, що робить BFT-системи привабливими для критично важливих з точки зору безпеки додатків.

Solana's Tower BFT успадковує цю властивість. Атакуючому потрібно буде контролювати більше третини всіх внесених в стейкінг SOL, щоб зупинити мережу, і більше двох третин, щоб обійти консенсус. На відміну від мереж Proof of Work, де атакуючому потрібен 51% обчислювальної потужності, Tower BFT Solana вимагає контролю понад 33% усіх внесених в стейкінг SOL для зупинки мережі. Цей поріг загалом вважається складнішим для досягнення на практиці, оскільки він вимагає накопичення капіталу, а не лише обчислювальних ресурсів.

Технічний огляд: Стандартний PBFT вимагає складності повідомлень O(n²), де n — кількість валідаторів. Кожен валідатор повинен зв'язатися з кожним іншим валідатором для підтвердження згоди. Для мереж з тисячами валідаторів це створює надмірні комунікаційні витрати. Tower BFT зменшує ці витрати, використовуючи PoH як спільний годинник: оскільки всі валідатори погоджуються щодо часу з послідовності PoH без обміну повідомленнями один з одним, Tower BFT вимагає лише від валідаторів голосувати за дійсність блоку, а не за порядок часових міток. Механізм блокування додає ще одну ефективність: коли валідатор голосує за блок, він блокується на цей голос на експоненційно збільшений період часу. Зміна голосів вимагає вичікування періоду блокування, що створює економічний стримуючий фактор для реорганізацій і зменшує кількість раундів голосування, необхідних для досягнення фінальності.

Без спільного годинника валідатори в стандартній BFT-системі повинні надсилати один одному повідомлення з часовими мітками, щоб встановити порядок подій, додаючи комунікаційні витрати на кожному кроці. З PoH порядок вже встановлений і може бути перевірений кожним валідатором незалежно.

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

Розклад лідерів: Як Solana обирає валідаторів

На початку кожної епохи Solana обчислює детерміноване призначення того, хто з валідаторів буде лідером для кожного майбутнього слоту. Призначення пропорційне вазі стейку кожного валідатора: валідатор, що контролює 5% усіх застейканих SOL, буде призначений лідером приблизно для 5% усіх слотів в цій епосі.

Слот — це базова одиниця часу Solana, з цільовим часом приблизно 400 мілісекунд на слот (перевірте поточне значення на docs.solana.com на момент написання). Епоха охоплює приблизно 432 000 слотів, що становить приблизно два-три дні (перевірте на docs.solana.com на момент написання).

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

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

Як Proof of History, Tower BFT та Proof of Stake працюють разом

Proof of History, Tower BFT та Proof of Stake — це не три окремі механізми консенсусу, що працюють паралельно. Це три взаємозалежні рівні єдиної інтегрованої системи, кожен з яких вирішує різну частину проблеми розподіленого консенсусу.

Proof of Stake є економічною основою. Валідатори повинні вносити в стейкінг (блокувати) SOL для участі в консенсусі. Цей стейк створює фінансову зацікавленість: валідатори, які голосують неправильно або намагаються маніпулювати реєстром, ризикують втратити свої застейкані SOL через слешинг (перевірте поточні деталі реалізації слешингу на docs.solana.com, оскільки вони змінюються з оновленнями протоколу). Делегатори, тобто будь-який власник SOL, який не хоче запускати валідатор, можуть внести свої SOL в стейкінг для валідатора і заробити частку винагороди цього валідатора, пропорційну їхній делегації.

Після того, як Proof of Stake визначає, хто бере участь і з якою вагою, Proof of History надає часові рамки, які використовують ці учасники. Годинник PoH працює безперервно, створюючи перевірену послідовність хешів, яка ставить часову мітку кожній транзакції. Для встановлення порядку не потрібна міжвузлова комунікація, оскільки всі валідатори можуть незалежно перевірити послідовність PoH.

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

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

Як транзакція Solana досягає фінальності: Покроково

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

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

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

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

4. Виробництво блоків. У межах свого приблизно 400-мілісекундного вікна слоту лідер збирає всі транзакції з часовими мітками в блок. Оскільки транзакції надходять попередньо впорядковані за послідовністю PoH, лідеру не потрібно узгоджувати порядок з іншими валідаторами. Він просто будує блок відповідно до встановленої часової шкали.

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

6. Голосування Tower BFT. Після отримання шредів блоку та реконструкції повного блоку інші валідатори перевіряють, що послідовність PoH є дійсною і що транзакції сформовані правильно. Кожен валідатор подає зважений за стейком голос Tower BFT щодо дійсності блоку. Валідатори з більшою кількістю застейканих SOL мають пропорційно більшу вагу в цьому голосуванні. Голоси поширюються мережею, коли валідатори сигналізують про своє підтвердження.

7. Фінальність. Коли валідатори, що колективно представляють понад дві третини всього застейканого SOL, підтвердили блок, він досягає фінальності Tower BFT і назавжди записується в реєстр. Цей поріг супербільшості є тією ж вимогою 2/3+, яка лежить в основі теорії відмовостійкості до візантійських збоїв: вона гарантує, що консенсус зберігається, навіть якщо до однієї третини учасників, зважених за стейком, є несправними або зловмисними.

Термінологія фінальності: Цільовий час слоту не те саме, що оптимістичне підтвердження, укорінення або економічна фінальність. Додатки повинні обирати рівень підтвердження відповідно до своїх вимог до ризику та перевіряти поточну поведінку кластера.

Продуктивність Solana: Швидкість, Пропускна здатність та Фінальність

Швидкість Solana є результатом не одного дизайнерського вибору. Це сукупний ефект чотирьох архітектурних рішень, що працюють у координації: Proof of History, Tower BFT, протокол Gulf Stream Solana та протокол поширення блоків Turbine Solana.

Чому Solana працює швидко? Чотири причини

1. Доказ історії (Proof of History) забезпечує перевірене посилання на порядок, що може зменшити накладні витрати на координацію часу; валідатори все ще обмінюються голосами та мережевими даними.
2. Tower BFT вимагає менше раундів голосування, ніж стандартні реалізації BFT, оскільки всі валідатори мають спільний PoH-годинник і їм не потрібно узгоджувати час.
3. Пересилання, кероване лідерами (Leader-aware forwarding) надсилає транзакції майбутнім лідерам до початку їхніх слотів, що може зменшити традиційне чергування в мемпулі, хоча й не усуває повністю конкуренцію за затримку чи комісію.
4. Протокол розповсюдження блоків Turbine від Solana розподіляє блоки невеликими фрагментами через деревоподібну структуру, а не транслює повні блоки всім валідаторам одночасно, зменшуючи вимоги до пропускної здатності в великих мережах.

Теоретична максимальна пропускна здатність Solana становить історичну теоретичну цифру приблизно 65 000 транзакцій на секунду за ідеальних мережевих умов. Ця цифра є орієнтиром, а не описом типової продуктивності. Пропускна здатність реальної основної мережі історично становила в середньому від 2 000 до 4 000 TPS, з піками під час періодів високого попиту. Розрив між теоретичним максимумом і середнім показником реального світу відображає затримки розповсюдження в мережі, географічний розподіл валідаторів та накладні витрати програмного забезпечення, які не враховуються в орієнтирах за ідеальних умов. Перевірте поточні дані з Solscan (solscan.io) на момент написання.

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

Для порівняння: Ethereum, який перейшов від Proof of Work до Proof of Stake у вересні 2022 року, тепер досягає приблизно 15–30 TPS на своєму Рівні 1, при цьому повна економічна фіналізація триває приблизно 12–15 хвилин через епохи контрольних точок Casper FFG (перевірити на ethereum.org). Консенсус Nakamoto Bitcoin досягає приблизно 7 TPS з імовірнісною фіналізацією, яка триває приблизно 60 хвилин через 6 підтверджень блоку.

Розрив у фіналізації між Solana та Ethereum Рівня 1 є суттєвим. Чи має цей розрив значення для конкретного випадку використання, залежить від застосунку. Мережі Рівня 2 Ethereum (Arbitrum, Optimism та інші) пропонують швидшу фіналізацію, ніж Ethereum L1, хоча вони працюють за допомогою механізмів, відмінних від консенсусу Solana.

Консенсус Solana порівняно з Ethereum, Avalanche, Cardano та Polkadot

Solana — не єдиний високопродуктивний блокчейн, і її механізм консенсусу — не єдиний підхід до швидкої, масштабованої фіналізації транзакцій. Ось як система PoH + Tower BFT + PoS від Solana порівнюється архітектурно та за показниками продуктивності з найвизначнішими альтернативами.

Ethereum (після Merge, вересень 2022) тепер використовує Gasper, систему консенсусу, що поєднує LMD-GHOST (правило вибору ланцюга, яке обирає ланцюг з найбільшою кількістю накопичених підтверджень валідаторів) і Casper FFG (гаджет фіналізації, який періодично створює контрольні точки ланцюга). Ethereum перейшов від Proof of Work до Proof of Stake 15 вересня 2022 року. Архітектурний контраст із Solana є значним: Gasper від Ethereum досягає безпеки та децентралізації завдяки величезній кількості валідаторів (приблизно 900 000 або більше валідаторів, перевірити на beaconcha.in на момент написання) за рахунок пропускної здатності. Solana досягає пропускної здатності завдяки механізму годинника PoH та ефективності Tower BFT, але зі значно меншою кількістю валідаторів.

Avalanche (C-Chain) використовує Snowman consensus, варіант лінійного ланцюга протоколу консенсусу Avalanche. Snowman є імовірнісним і заснованим на вибірці, а не детермінованим BFT: валідатори неодноразово вибирають випадкові підмножини інших валідаторів для оцінки згоди. Опубліковані показники пропускної здатності та фіналізації варіюються залежно від дати, навантаження та методу вимірювання, тому для порівняння слід використовувати поточні першоджерела. Архітектурний контраст полягає в тому, що Avalanche використовує повторну субвибірку, тоді як Solana використовує голосування, зважене за стейком, побудоване навколо посилання на порядок PoH.

Cardano використовує Ouroboros Praos, поточну версію основної мережі сімейства консенсусу Ouroboros PoS. Ouroboros був першим доказово безпечним протоколом PoS, опублікованим у рецензованих наукових виданнях з формальними математичними доказами безпеки. Дизайн Cardano явно надає пріоритет формальній коректності та доказам безпеки над сирою пропускною здатністю. Реальна TPS на основній мережі Cardano становить приблизно 250 (перевірити на момент написання). Філософія дизайну порівняно з Solana пряма: Solana надає пріоритет пропускній здатності завдяки архітектурним інноваціям; Cardano надає пріоритет формальній доказовості властивостей безпеки через академічну строгість.

Polkadot (релейний ланцюг) використовує BABE (Blind Assignment for Blockchain Extension) для створення блоків і GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) для фіналізації, досягаючи приблизно 1 000 TPS на релейному ланцюзі з фіналізацією від приблизно 12 до 60 секунд. Архітектура релейного ланцюга Polkadot плюс парачейни фундаментально відрізняється від монолітного дизайну ланцюга Solana, що робить прямі порівняння продуктивності складнішими, ніж свідчать лише цифри в таблиці.

Усі цифри є орієнтовними. Показники продуктивності варіюються залежно від умов мережі; теоретичні максимуми відображають потужність за ідеальних умов. Перевірте поточні дані з офіційної документації (docs.solana.com, ethereum.org, Solana Beach, beaconcha.in) перед прийняттям будь-яких рішень. Кількість валідаторів часто змінюється.

Сильні сторони та обмеження моделі консенсусу Solana

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

Сильні сторони:

• Цільові показники низької затримки підтвердження. Solana може забезпечити швидке оптимістичне підтвердження, але рівень підтвердження та економічна фіналізація повинні бути розрізнені.
• Дизайн з високою пропускною здатністю. Історичні орієнтири ілюструють архітектурну потужність, тоді як реальна пропускна здатність залежить від навантаження, обліку голосів, валідаторів, перевантаження та версій програмного забезпечення.
• Низькі комісії за транзакції. Висока пропускна здатність означає нижчу конкуренцію за комісії між транзакціями, зберігаючи витрати на рівні часток цента для більшості операцій.
• Пересилання транзакцій без мемпулу. Протокол Gulf Stream від Solana усуває проблему «зали до зустрічі», зменшуючи затримку підтвердження шляхом попереднього маршрутизації транзакцій до відомих майбутніх лідерів.
• Енергоефективність. Proof of Stake не вимагає енергоємних обчислень, ставлячи енергетичний слід Solana в принципово іншу категорію порівняно з Proof of Work Bitcoin.

Обмеження:

• Історія збоїв мережі. Solana пережила кілька повних зупинок мережі між 2021 і 2023 роками, що створило реальні занепокоєння щодо надійності, які повинен зважити будь-який інвестор або розробник.
• Менше валідаторів, ніж в Ethereum. Відносно невелика кількість валідаторів створює інший профіль децентралізації порівняно з мережами, що мають сотні тисяч валідаторів.
• Високі вимоги до обладнання створюють бар'єр для участі. Запуск валідатора Solana потребує обладнання серверного класу, яке більшість людей не можуть собі дозволити або обслуговувати, що обмежує можливість прямої участі в консенсусі.
• Залежність від одного клієнта валідатора (до Firedancer). Донедавна майже всі валідатори Solana використовували один і той самий програмний клієнт, що створювало єдину точку відмови у разі виявлення помилок у цьому клієнті.
• Концентрація стейкінгу серед провідних валідаторів. Значна частина від загального обсягу SOL в стейкінгу зосереджена у невеликої кількості валідаторів, що впливає на коефіцієнт Накамото.

Чому мережа Solana виходила з ладу?

Історичні збої Solana не були спричинені помилками в алгоритмах консенсусу Proof of History або Tower BFT. Сам дизайн консенсусу не порушувався. Задокументованими першопричинами великих збоїв були вичерпання програмних ресурсів і помилки реалізації: спам транзакціями, що перевантажував пам'ять валідаторів, програмні помилки в клієнті валідатора, що призводили до збоїв, і вичерпання ресурсів, викликане подіями високого попиту, включаючи ажіотаж навколо мінту NFT та сплески активності DeFi.

Конкретні події ілюструють цю закономірність. У вересні 2021 року в Solana стався 17-годинний збій, спричинений потоком транзакцій від події IDO, який переповнив пам'ять валідаторів і спровокував форк мережі, що вимагав скоординованого перезапуску. У січні 2022 року другий значний збій стався через вичерпання ресурсів в умовах високої пропускної здатності. Протягом 2022 року відбулося ще кілька подій часткової деградації (перевірте конкретні дати та тривалість у звітах Solana Foundation на момент прочитання, оскільки список задокументованих інцидентів розширився). Різниця між цими подіями та збоєм алгоритму консенсусу має значення для оцінки довгострокової життєздатності Solana: несправний алгоритм консенсусу вимагав би переробки протоколу, тоді як вичерпання програмних ресурсів є інженерною проблемою, яку можна виправити.

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

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

Децентралізація та концентрація валідаторів: Solana має приблизно 1500 або більше активних валідаторів на момент написання (перевірте поточну кількість в аналітиці валідаторів Solana Beach). Ethereum має приблизно 900 000 або більше валідаторів (перевірте на beaconcha.in). Різниця суттєва і відображає апаратний бар'єр для валідації в Solana: запуск валідатора Solana потребує приблизно 128 ГБ або більше оперативної пам'яті, високопродуктивного NVMe SSD-накопичувача ємністю 2 ТБ або більше та мережевого з'єднання не менше 1 Гбіт/с (перевірте поточні специфікації на docs.solana.com/running-validator на момент прочитання). Навпаки, валідатори Ethereum можуть працювати на споживчому обладнанні разом із 32 ETH.

Коефіцієнт Накамото Solana (мінімальна кількість суб'єктів, яким потрібно було б домовитися для компрометації консенсусу) історично коливався від приблизно 19 до 31 валідатора, хоча цей показник змінюється зі зміною розподілу стейкінгу. Перевірте поточний коефіцієнт у звітах про децентралізацію Solana Foundation або Nakaflow на момент прочитання. Топ-20 валідаторів історично контролювали значну частку від загального обсягу SOL в стейкінгу (перевірте поточний відсоток концентрації на Solana Beach). Solana Foundation керує програмою делегування, спеціально розробленою для розподілу стейкінгу серед менших валідаторів та покращення цього коефіцієнта, забезпечуючи структурну протидію концентрації. Поріг безпеки Tower BFT означає, що зловмиснику потрібно буде контролювати більше однієї третини всіх SOL в стейкінгу, щоб зупинити мережу, і більше двох третин, щоб скасувати консенсус, що є високою вимогою до капіталу, яка масштабується залежно від того, наскільки сконцентрованим є цей стейкінг на практиці.

Як взяти участь: Стейкінг та валідація в Solana

Власники SOL можуть брати участь у механізмі консенсусу Solana двома способами: безпосередньо керуючи нодою валідатора або делегуючи SOL існуючому валідатору. Перший шлях вимагає значних інвестицій в обладнання та технічних знань. Другий доступний будь-якому власнику SOL із сумісним гаманцем.

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

Вимоги для запуску валідатора Solana

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

• CPU: висока продуктивність в одному потоці; рекомендації щодо конкретних моделей оновлюються в офіційній документації.
• RAM: рекомендований мінімум 128 ГБ; 256 ГБ або більше для найкращої продуктивності.
• Сховище: високопродуктивний NVMe SSD; рекомендується 2 ТБ або більше.
• Мережа: з'єднання мінімум 1 Гбіт/с; рекомендується 10 Гбіт/с для конкурентоспроможної продуктивності.
• SOL в стейкінгу: достатня кількість самостійно внесених у стейкінг токенів або делегованих спільнотою токенів, щоб зробити роботу економічно вигідною. Протокол не встановлює обов'язкового мінімуму для запуску валідатора, але валідатори з дуже малим стейкінгом отримують дуже малі винагороди.

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

Як вносити в стейкінг SOL: нативний стейкінг та опціони ліквідного стейкінгу

Делегування SOL наявній ноді валідатора є доступним шляхом для більшості учасників. Механіка працює наступним чином.

Нативний стейкінг: використовуючи сумісний гаманець, такий як Phantom або Solflare, будь-який власник SOL може делегувати свої токени валідатору на свій вибір. Делегування дозволяє отримувати частку винагород від інфляції цього валідатора, пропорційно делегованій сумі. Поточний стейкінг APY варіюється залежно від параметрів інфляції мережі та загальної кількості SOL у стейкінгу (перед прийняттям будь-яких рішень щодо стейкінгу перевірте дані на Solana Beach). Існує період очікування для зняття з делегування тривалістю приблизно дві епохи, що становить приблизно чотири-п'ять днів, перш ніж SOL у стейкінгу знову стане ліквідним (перевірте на docs.solana.com на момент прочитання).

Рідкий стейкінг: Протоколи, зокрема Marinade Finance (який випускає токени mSOL) та Jito (який випускає токени jitoSOL), дозволяють користувачам вносити в стейкінг SOL, зберігаючи ліквідність. Замість того, щоб безпосередньо блокувати SOL у валідатора та чекати закінчення періоду охолодження для доступу до них, користувачі рідкого стейкінгу отримують ліквідний токен, що представляє їхні SOL у стейкінгу плюс накопичені винагороди, і який можна обміняти в будь-який час. Ці токени рідкого стейкінгу є частиною протоколів DeFi, що працюють на Solana, і несуть власний ризик смартконтракту, окрім базової економіки стейкінгу.

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

Часті запитання про механізм консенсусу Solana

Який механізм консенсусу використовує Solana?

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

Чи є Solana блокчейном Proof of Stake?

Solana використовує Proof of Stake як рівень економічної безпеки, тому називати її PoS-блокчейном технічно правильно. Однак це неповне визначення. Сам по собі Proof of Stake не пояснює, як Solana досягає консенсусу. Повний механізм потребує Proof of History (криптографічний годинник, який встановлює черговість без зв'язку між валідаторами) та Tower BFT (алгоритм голосування, який забезпечує фіналізацію). Точний опис: Solana використовує гібридну систему консенсусу PoH + Tower BFT + PoS.

Наскільки швидка Solana порівняно з Ethereum?

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

Чому мережа Solana виходить з ладу?

Історичні збої в мережі Solana були спричинені вичерпанням програмних ресурсів та помилками реалізації, а не збоями в алгоритмах консенсусу Proof of History або Tower BFT. Задокументовані причини включають спам транзакцій, що перевантажує обсяг пам'яті валідаторів, програмні помилки в клієнті валідатора та вичерпання ресурсів під час подій з високим попитом, таких як мінти NFT та сплески активності DeFi. Збій у вересні 2021 року тривав приблизно 17 годин і був спричинений флудом під час IDO-події. Покращення з моменту пікового періоду збоїв 2021–2022 років включають мережевий протокол QUIC, пріоритезацію транзакцій на основі стейкінгу та постійне вдосконалення клієнтів валідаторів. Перевіряйте поточний стан надійності мережі в блозі Solana Foundation на момент прочитання.

Що таке Proof of History?

Proof of History (PoH) — це криптографічний механізм відліку часу, винайдений Анатолієм Яковенком і представлений у його Whitepaper за листопад 2017 року «Solana: нова архітектура для високопродуктивного блокчейну». PoH створює безперервний запис, що піддається перевірці, про те, коли відбулися події, шляхом послідовного ланцюжка хеш-виходів SHA-256. Це не механізм консенсусу. Це криптографічний годинник, який дозволяє фактичному алгоритму консенсусу Solana, Tower BFT, працювати з набагато меншою кількістю раундів зв'язку. Докладнішу інформацію дивіться в розділі Proof of History вище.

Хто винайшов механізм консенсусу Solana?

Анатолій Яковенко, колишній інженер Qualcomm, представив Proof of History у фундаментальному Whitepaper Solana у 2017 році. Яковенко став співзасновником Solana Labs разом із Грегом Фіцджеральдом та Раджем Гокалом, які зробили свій внесок у ширшу реалізацію протоколу. PoH забезпечує верифікований орієнтир упорядкування, що може зменшити деякі витрати на координацію часу, але він не усуває необхідність комунікації для консенсусу.

Скільки валідаторів у Solana?

На момент написання статті Solana має приблизно 1500 або більше активних валідаторів; перевірте поточну цифру в аналітиці валідаторів Solana Beach для отримання актуальних даних. Для порівняння, Ethereum має приблизно 900 000 або більше валідаторів (перевірте на beaconcha.in). Різниця в кількості валідаторів відображає різницю у вимогах до апаратного забезпечення: валідаторам Solana потрібне обладнання серверного класу з 128 ГБ або більше оперативної пам'яті, тоді як валідатори Ethereum можуть працювати на обладнанні споживчого класу разом із 32 ETH.

Що таке Tower BFT?

Tower BFT — це алгоритм консенсусу Solana, створений як адаптація PBFT, що використовує Proof of History як спільний годинник. Валідатори віддають зважені за стейкінгом голоси за блоки; блок досягає фіналізації, коли його підтверджують валідатори, що представляють понад дві третини всіх SOL, внесених в стейкінг. Цей поріг супербільшості 2/3+ означає, що мережа витримує до однієї третини учасників (зважених за стейкінгом), які діють зловмисно, без втрати цілісності консенсусу.

Чи використовує Solana делегований Proof of Stake?

Стейкінг у Solana технічно подібний до делегованого Proof of Stake (DPoS) тим, що власники SOL можуть делегувати кошти валідаторам, не запускаючи власний вузол. Однак він відрізняється від традиційних систем DPoS одним ключовим аспектом: немає фіксованого, обраного набору валідаторів-делегатів. Будь-який валідатор може залучати делегування на відкритому ринку. Точніше, Solana використовує систему PoS зі зваженим стейкінгом та відкритим делегуванням, що працює як рівень економічної безпеки поверх PoH та Tower BFT, а не традиційну архітектуру DPoS із фіксованим пулом делегатів.

Чи краща Solana за Ethereum?

Жодна мережа не є об'єктивно кращою. Кожна робить різні архітектурні компроміси, придатні для різних випадків використання. Історичні вимірювання зазвичай показують вищу пропускну здатність базового рівня та нижчі комісії у Solana, тоді як час підтвердження залежить від рівня зобов'язань та умов мережі. Ethereum має більшу спільноту розробників і широку екосистему Рівня 2. Кількість валідаторів сама по собі не є мірилом децентралізації; розподіл стейкінгу, різноманітність клієнтів, концентрація операторів та вимоги до апаратного забезпечення також мають значення. Правильний вибір залежить від додатка та моделі ризику.

Досліджуйте SOL на Bybit

Читачі можуть переглянути поточну ринкову інформацію про SOL) або порівняти доступні продукти SOL Bybit Earn.). Bybit Bybit Earn є централізованим продуктом і не повинен описуватися як нативний стейкінг валідатора Solana; умови, зберігання, доступність та ризики відрізняються.

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

• Механізм консенсусу Solana — це гібридна система: Proof of History (криптографічний годинник) + Tower BFT (алгоритм узгодження) + Proof of Stake (рівень економічної безпеки). Жоден компонент окремо не становить цей механізм.

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

• Збої в мережі Solana були спричинені вичерпанням програмних ресурсів, а не збоями в PoH або Tower BFT. Дизайн консенсусу не порушився. Покращення, включаючи мережевий протокол QUIC, пріоритезацію комісій на основі стейкінгу та клієнт Firedancer, спрямовані на зниження ризику майбутніх зупинок.

• Консенсус Solana швидший за Ethereum Рівень 1 та Bitcoin, досягаючи фіналізації менш ніж за 1,3 секунди порівняно з 12–15 хвилинами для Ethereum Рівень 1 та приблизно 60 хвилинами для Bitcoin, але ця швидкість має свої компроміси: менша кількість валідаторів, вищі вимоги до апаратного забезпечення та занепокоєння щодо концентрації стейкінгу.

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

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

Щоб брати участь у механізмі консенсусу Solana, дивіться розділи про стейкінг та валідацію вище або відвідайте офіційну документацію Solana за адресою docs.solana.com.

Додатково для ознайомлення:

• Solana: Нова архітектура для високопродуктивного блокчейну:) Whitepaper Анатолія Яковенка від листопада 2017 року
• Офіційна документація Solana: специфікації протоколу, вимоги до обладнання, посібники зі стейкінгу
• Аналітика валідаторів Solana Beach: поточна кількість валідаторів, розподіл стейку та статистика мережі

Пов'язане читання

• Solana Proof of History
• Solana Architecture
• Solana Speed