Найкращий механізм консенсусу завжди той, який відповідає потребам користувача.
Спікер: Учіха Мадара
РЕДАГУВАТИ: затяжки
Джерело:Deschool
Ця стаття є конспектами третього уроку університетського курсу web3 від DeSchool, лектором якого є Учіха Мадара. Вміст занадто сухий і не змішаний з водою. Рекомендується збирати його та перетравлювати повільно. Крім того, для полегшення розуміння в цю статтю внесено деякі зміни та доповнення відповідно до змісту курсу.
Основний зміст статті включає:
Вступ до алгоритму консенсусу
Класифікація консенсусних алгоритмів
Детальне пояснення консенсусних алгоритмів (PoW, PoS, PoH, PoA, PBFT тощо)
01 Вступ до механізму консенсусу
У комунікації та вивченні блокчейну «алгоритм консенсусу» є дуже часто згадуваним словником. Саме через існування алгоритму консенсусу можна гарантувати довіру до блокчейну.
**1. Навіщо нам механізм консенсусу? **
Так званий консенсус означає, що кілька людей досягають згоди. Наше життя сповнене механізмів досягнення консенсусу. Наприклад, компанії потрібні акціонери, щоб колективно обговорити рішення, а Стороні А та Стороні Б потрібно сісти й провести переговори, щоб підписати контракт. Цей процес є процесом досягнення консенсусу.
У системі блокчейн кожен вузол повинен узгодити свій обліковий запис з обліковими книгами інших вузлів. Якщо це в традиційному централізованому сценарії, це навряд чи є проблемою, оскільки існує центральний сервер, який є так званою головною бібліотекою, а інші підлеглі бібліотеки можна узгодити з головною бібліотекою.
Але в децентралізованому управлінні немає боса, тож як приймати рішення? У цей час для забезпечення консенсусу необхідний набір алгоритмів. Ось про що йтиметься в цій статті – про механізм консенсусу.
**2. Що таке механізм консенсусу? **
Механізм консенсусу (Consensus Mechanism) завершує перевірку та підтвердження транзакцій за дуже короткий проміжок часу через голосування спеціальних вузлів; для транзакції, якщо кілька вузлів з невідповідними інтересами можуть досягти консенсусу, ми можемо вважати, що вся мережа Щодо цього також існує консенсус.
Хоча консенсус (Consensus) і узгодженість (Consistency) вважаються приблизно еквівалентними в багатьох прикладних сценаріях, існують тонкі відмінності в їхніх значеннях: дослідження консенсусу зосереджено на процесі й алгоритмі досягнення консенсусу розподілених вузлів, тоді як дослідження узгодженості зосереджено на стабільному стан, нарешті досягнутий у процесі консенсусу вузла; крім того, більшість традиційних досліджень розподіленого консенсусу не розглядають візантійську проблему відмовостійкості, тобто передбачається, що немає візантійських вузлів, які зловмисно змінюють або підробляють дані. Адже в повністю відкритій і прозорій блокчейн-мережі немає гарантії, що всі вузли не будуть робити зло.
**3. Які проблеми може вирішити механізм консенсусу? **
Механізм консенсусу може вирішити проблему довіри в розподіленій системі та забезпечити узгодженість даних і безпеку між вузлами. У традиційній розподіленій системі, оскільки між вузлами немає механізму довіри, вона вразлива до атак і втручання з боку зловмисних вузлів, що призводить до збоїв системи або підробки даних. Крім того, до появи технології шифрування блокчейну зашифрована цифрова валюта, як і інші активи, могла нескінченно відтворюватися.Без централізованого агентства-посередника люди не мали можливості підтвердити, чи була витрачена сума цифрових грошей.
Простіше кажучи, механізм консенсусу може ефективно вирішити дві проблеми: проблему подвійних витрат (сума грошей витрачається двічі) і візантійську загальну проблему (шкідливі вузли підробляють дані).
4. Подвійна атака
** **
Механізм консенсусу може певною мірою вирішити атаку подвійних витрат: тобто сума грошей витрачається двічі або більше ніж двічі, що також називається «подвійними витратами». У грі в кішки-мишки Сяо Лізі зробив поведінку подвійних витрат, зробивши фальшивий чек.Оскільки перевірка чека потребує часу, він використав інформацію того самого чеку, щоб придбати товари багато разів протягом цієї різниці в часі.
Як ми всі знаємо, вузли блокчейну завжди вважають найдовший ланцюг правильним і продовжують працювати та розширювати його. Якщо два вузли транслюють різні версії нового блоку одночасно, робота виконуватиметься на основі блоку, отриманого першим, але інший ланцюжок також буде збережено, якщо останній стане найдовшим. Зачекайте, поки буде знайдено наступне підтвердження роботи, і один із ланцюжків виявиться довшим, тоді вузли, що працюють на іншому ланцюжку гілки, поміняються таборами.
Як досягаються подвійні витрати? Розділені на дві ситуації:
**(1) Подвійні витрати до підтвердження. **Транзакції з нульовим підтвердженням могли зрештою не бути записані в блокчейн. Якщо сума невелика, найкраще уникнути таких подвійних витрат, принаймні дочекавшись підтвердження.
**(2) Подвійні витрати після підтвердження. **Для реалізації потрібно контролювати понад 50% обчислювальної потужності. Тобто, схоже на невеликий форк, що поміщає транзакції для магазину в блоки-сиріти. Подібні подвійні витрати після підтвердження важко здійснити, але це лише теоретично.
** Є три найпоширеніші атаки подвійного витрачання: атака 51%, атака раси та атака Фінні. **
Атака 51%: атака 51% – це коли особа або група отримує контроль над 51% потужності хешування блокчейну, що означає, що вони мають можливість контролювати деякі аспекти проекту. У блокчейні з підтвердженням роботи, такому як біткойн, цього можна досягти шляхом отримання контролю над потужністю майнінгу в мережі. З іншого боку, для блокчейну з підтвердженням ставки, такого як Cardano, цього можна було б досягти, контролюючи 51% токенів, на які поставлено ставку.
Race Attack: користувач надсилає дві транзакції двом торговцям (або продавцю та користувачеві) одночасно. Таким чином, зловмисник отримує два комплекти товарів або отримує товари та відшкодовує початкову вартість транзакції.
Атака Finney: майнер майнить блок або серію блоків, які містять транзакції, які переказують гроші на його власну адресу. Видобуті блоки не публікуються, але зберігаються, поки майнер переказує гроші продавцю. Тоді торговець відпускає товари, за які майнер заплатив, перш ніж майнер опублікує викопаний ним блок. Потім майнери публікують викопані блоки, що стирає переказ торговцю, і торговець може заплатити за це зі своєї кишені.
Класичний випадок атаки подвійною квіткою:
У 2018 році зловмисник контролював понад 51% обчислювальної потужності в мережі BTG.За період контролю обчислювальної потужності він відправив певну кількість BTG на свій гаманець на біржі.Ця гілка отримала назву гілка А. У той же час надішліть ці BTG на інший гаманець, яким ви керуєте, і ця гілка називається гілкою B. Після підтвердження транзакції у відділенні A зловмисник негайно продає BTG, щоб отримати готівку. Згодом зловмисник майнить на гілці B. Оскільки він контролює понад 51% обчислювальної потужності, довжина гілки B незабаром перевищить довжину гілки A, і гілка B стане основним ланцюгом. Транзакції на гілці A Це буде відкочується для відновлення попереднього стану. BTG, які зловмисник обміняв на готівку перед тим, як повернув собі в руки, і ці BTG є втратою обміну. Таким чином зловмисник, покладаючись на понад 50% контролю обчислювальної потужності, реалізував «подвійну витрату» однієї і тієї ж криптовалюти.
5. Візантійські невдачі
** **
Проблема візантійських генералів — гіпотетична проблема, поставлена Леслі Лемпортом у 1980-х роках. Візантія була столицею Східної Римської імперії. Через величезну територію Візантійської Римської імперії на той час гарнізони кожної армії були далеко один від одного, а генерали могли доставляти повідомлення лише гінцями. На випадок війни генерали повинні розробити єдиний план дій.
Однак серед цих генералів є зрадники, які сподіваються підірвати послідовний план дій лояльних генералів, вплинувши на формування та поширення єдиного плану дій. Отже, генерали повинні мати заздалегідь визначену угоду про метод, щоб усі лояльні генерали могли домовитися. І жменька зрадників не може змусити вірних генералів будувати хибні плани. Іншими словами, суть проблеми візантійських генералів полягає в тому, щоб знайти спосіб змусити генералів досягти консенсусу щодо плану бою в недовірливому оточенні зрадників.
У розподіленій системі, особливо в мережевому середовищі блокчейн, це також схоже на візантійське загальне середовище, є нормальні сервери (схожі на лояльних візантійських генералів), є несправні сервери та сервери-саботажники (схожі на зрадницького візантійського генерала). Основою алгоритму консенсусу є формування консенсусу щодо стану мережі серед звичайних вузлів. Якщо є лише 3 вузли, проблема візантійських генералів є нерозв’язною.Якщо у вузлах є x вузлів проблеми, а сумарні точки менше 3x+1, проблема візантійських генералів не має розв’язку.
Поява біткойна легко вирішує цю проблему: він збільшує вартість передачі інформації, знижує швидкість передачі інформації та додає випадковий елемент, щоб лише один генерал міг транслювати інформацію протягом певного періоду часу. Перший генерал, який передає повідомлення, є першим комп’ютером, який знаходить дійсний хеш, і поки інші генерали отримують і перевіряють цей дійсний хеш та інформацію, що додається до нього, вони можуть лише оновлювати їх новою інформаційною копією книги, а потім перерахувати хеш-значення. Наступний генерал, який обчислює ефективне хеш-значення, може приєднати свою оновлену інформацію до ефективного хеш-значення та транслювати це всім. Змагання за обчисленням хешування потім починається з нової початкової точки. Завдяки безперервній синхронізації мережевої інформації всі комп’ютери в мережі використовують ту саму версію книги.
02 Класифікація консенсусних алгоритмів
1. Історія механізму консенсусу
Коли комп’ютери та мережі стали популярними в 1980-х і 1990-х роках, з’явилися спільні бази даних, щоб кілька користувачів могли отримати доступ до інформації, яку вони зберігають. Більшість із них мають центральну базу даних, до якої користувачі можуть отримати доступ із різних сайтів. Це налаштування перетворюється на централізовану мережу, де адміністратори надають дозволи користувачам і підтримують цілісність даних.
Ці спільні бази даних відомі як розподілені книги, оскільки вони записують інформацію та об’єднані в мережу для доступу багатьох користувачів у різних місцях. Однією з найважливіших проблем, яку необхідно вирішити, є запобігання підробці даних і несанкціонованому доступу, зловмисному чи ні. Потрібен спосіб автоматизації управління розподіленою базою даних, щоб гарантувати, що дані не змінюються.
Ця потреба призвела до створення розподіленого автономного консенсусу, де програми в мережі використовують криптографію для узгодження стану бази даних. Протокол призначений для досягнення за допомогою криптографічного алгоритму для створення довгого рядка буквено-цифрових чисел (хеш), який потім перевіряється програмою, що працює в мережі. Хеш змінюється лише тоді, коли змінюється інформація, що вводиться в алгоритм хешування, тому програми створені для порівняння хешів, щоб переконатися, що вони збігаються.
Коли кожна програма, що працює в мережі, створює відповідний хеш-рядок, кажуть, що дані досягли консенсусу в мережі. Таким чином, був створений механізм консенсусу, який зазвичай вказував на анонімного творця біткойнів Сатоші Накамото. Однак багато людей працювали над механізмом консенсусу роками до того, як Сатоші випустив білу книгу, яка прославила біткойн.
Вчені з обробки даних і комп’ютерів, такі як Моні Наор, Синтія Дворк, Адам Бек, Нік Сабо та багато інших, працювали над механізмами консенсусу в мережі та зробили свій внесок у їх розвиток.
2 Класифікація консенсусних алгоритмів
Відповідно до різних типів відмовостійкості алгоритми консенсусу можна розділити на дві категорії: алгоритм консенсусу CFT (невізантійська відмовостійкість, тобто шкідливі вузли не враховуються) і консенсусний алгоритм BFT (візантійська відмовостійкість, що є, розглядаються шкідливі вузли).
«Чи терпіти Візантію» означає, чи можна застосовувати алгоритм до мереж із низьким рівнем довіри. Загалом, візантійський відмовостійкий алгоритм повинен використовуватися в публічному ланцюжку, тоді як у ланцюжку альянсу він може бути обраний відповідно до ступеня довіри між учасниками альянсу.Якщо ступінь довіри високий, усі є добросовісним вузлом за замовчуванням і може використовувати алгоритм CFT (non-Byzantine fault-tolerant).
**Крім того, його можна розділити на дві категорії відповідно до узгодженості: **алгоритм імовірнісного консенсусу та алгоритм абсолютної узгодженості. Алгоритм імовірнісного консенсусу означає, що між різними розподіленими вузлами існує висока ймовірність того, що дані між вузлами є узгодженими, але все ще існує певна ймовірність того, що дані між деякими вузлами є неузгодженими. Наприклад, Proof of Work (PoW), Proof of Stake (PoS) і Delegated Proof of Stake (DPoS) — усі ймовірнісні консенсусні алгоритми.
Алгоритм абсолютної узгодженості означає, що в будь-який момент часу дані між різними розподіленими вузлами залишатимуться абсолютно узгодженими, і між різними вузлами не буде неузгодженості даних. Наприклад, алгоритм PAXOS і похідний від нього алгоритм RAFT.
Нижче наведено конкретний поділ і вступ відповідно до типу відмовостійкості.
Алгоритм консенсусу 3CFT
Невізантійська помилка Crash Fault Tolerance: підходить для мереж із високим ступенем довіри до вузла. В тому числі Паксос, Пліт.
Алгоритм консенсусу 4BFT
Перевірка наявності у вузла шкідливих візантійних помилок має тенденцію до децентралізованої структури, включаючи підтвердження роботи (PoW), підтвердження частки (PoS), делеговане підтвердження частки (DPoS), підтвердження повноважень (PoA) тощо.
03 Детальне пояснення алгоритму консенсусу
Ви трохи втомилися бачити це, натисніть улюблене, зробіть перерву та продовжуйте гризти найскладнішу частину цієї статті! Студенти з обмеженим часом можуть почати безпосередньо з третього алгоритму PoW.
1 Алгоритм Паксоса
** **
**Ознайомлення з алгоритмом: **У 1990 році алгоритм Paxos був запропонований Майстром Лампортом як алгоритм розподіленого консенсусу, заснований на передачі повідомлень, і отримав нагороду Тьюринга в 2013 році. З моменту появи Paxos він продовжував монополізувати алгоритм розподіленого консенсусу, в основному вирішуючи, як досягти консенсусу щодо конкретного значення в розподіленій системі. Процес консенсусу алгоритму Paxos полягає в тому, що Пропонент висуває пропозицію, щоб отримати підтримку більшості Акцепторів. Коли пропозиція отримує більше половини підтримки, результат розгляду надсилається всім вузлам для підтвердження. Під час цього процесу , якщо Пропонент зазнає невдачі, це може бути вирішено шляхом запуску механізму тайм-ауту.Якщо пропонент кожного нового раунду пропозицій зазнає невдачі, система ніколи не зможе досягти консенсусу. Але ймовірність цього вкрай мала.
Ранній базовий протокол Paxos був складним і відносно неефективним, тому пізніше була запропонована вдосконалена версія Paxos. Наприклад: Fast Paxos, Multi-Paxos і Byzanetine Paxos тощо.
**Випадок використання: **ZooKeeper
**Принцип алгоритму: **Алгоритм Paxos працює в асинхронній системі, яка допускає простої та збої, не вимагає надійної доставки повідомлень і може допускати втрату, затримку, розлад і повторення повідомлень. Він використовує механізм більшості (більшості), щоб забезпечити відмовостійкість 2f+1, тобто система з 2f+1 вузлами допускає одночасний збій більшості f вузлів. Поки є менше ніж (n-1)/2 відмов, Paxos досягає консенсусу. Ці помилки не можуть бути візантійськими, інакше доказ BFT буде порушено. Таким чином, передумова цього алгоритму полягає в припущенні, що повідомлення ніколи не можуть бути пошкоджені, і що вузли не можуть вступати в змову, щоб пошкодити систему.
Paxos проходить ряд раундів переговорів, у яких один вузол має стан «лідерства». Якщо лідера немає в мережі, прогрес буде зупинено, доки не буде обрано нового лідера або якщо старий лідер раптово повернеться в мережу.
Paxos поділяє ролі в системі на Пропонента, Приймача та Учня: Пропонент: Пропозиція. Інформація про пропозицію включає номер пропозиції (ідентифікатор пропозиції) і запропоновану вартість (значення). Акцептор: брати участь у прийнятті рішень і відповідати на пропозиції Заявників. Після отримання пропозиції пропозиція може бути прийнята. Якщо пропозиція прийнята більшістю акцептантів, пропозиція вважається схваленою. Учень: не беріть участь у прийнятті рішень, дізнайтеся останню погоджену пропозицію (вартість) від тих, хто пропонує/приймає.
2. Алгоритм плоту
**Ознайомлення з алгоритмом:**Алгоритм Raft (Replication and Fault Tolerant) — це спрощена реалізація пари алгоритмів Paxos. Назва Raft походить від акроніму «Reliable, Replicated, Redundant, And Fault-Tolerant» (надлишковий, стійкий до відмов»). raft робить багато приємних спрощень порівняно з Paxos із продовженням журналу. Це гарантує узгодженість системи, коли більше половини вузлів у системі, що складається з n вузлів, працюють нормально. На відміну від алгоритму Paxos, який безпосередньо походить від проблеми розподіленої узгодженості, алгоритм Raft пропонується з точки зору багатокопійного кінцевого автомата та використовується для керування реплікацією журналу багатокопійного кінцевого автомата. Наприклад, у системі з 5 вузлами 2 вузли можуть мати невізантійські помилки, такі як час простою вузла, розділ мережі та затримка повідомлення.
**Випадок використання: **Реплікація головного-підлеглого бази даних, ланцюжок альянсу.
Принцип алгоритму: У системі Raft є три ролі: Лідер, Послідовник і Кандидат. За звичайних обставин буде лише один лідер, а інші є послідовниками. І лідер буде відповідати за всі зовнішні запити, якщо вони не отримані машиною лідера, запит буде спрямовано до лідера. Зазвичай лідер надсилає повідомлення у фіксований час, тобто серцебиття (heartbeat), щоб сповістити послідовників, що лідер кластера все ще працює. Кожен підписник розробить механізм тайм-ауту (тайм-аут).Коли серцебиття не буде отримано протягом певного періоду часу (зазвичай 150 мс або 300 мс), система перейде в стан вибору.
У цей час кластер вступає в новий виборчий раунд (каденцію) і починає вибори.Якщо вибори успішні, то новий лідер приступає до роботи, інакше термін вважається закінченим і починається новий термін. і почнуться наступні вибори.
Вибори проводяться кандидатами. Це вимагає від кандидатів висувати себе та запитувати голоси з інших серверів у порядку черги, коли серце лідера зупиняється. Кожен сервер віддає лише один голос за або проти поточного кандидата в кожному турі виборів. Якщо ви не наберете більше половини голосів, ви пройдете в наступний тур виборів. Решта кандидатів продовжують висувати себе в порядку черги. поки не буде обраний керівник.
**Переваги алгоритму Raft: **Перший пункт — це простота. Якщо ми заглибимося в те, де Paxos є складнішим, ніж Raft, Хайді Ховард і Річард Мортьє виявили, що складність Paxos відображається в двох аспектах. По-перше, Raft фіксує журнали послідовно, тоді як Paxos дозволяє фіксувати журнали не по порядку, але вимагає додаткового протоколу для заповнення журнальних дірок, які можуть виникнути в результаті. По-друге, усі копії журналу в Raft мають однаковий індекс, термін і порядок, тоді як у Paxos ці терміни можуть відрізнятися.
По-друге, Рафт має ефективний алгоритм вибору лідера. Алгоритм вибору, наведений у документі Paxos, порівнює розмір ідентифікатора сервера.Коли кілька вузлів беруть участь у виборах одночасно, перемагає вузол із більшим ідентифікатором сервера. Проблема полягає в тому, що якщо лідеру, обраному таким чином, не вистачає деяких журналів, він не може негайно виконати операцію запису, і повинен спочатку скопіювати деякі журнали з інших вузлів. Журнал Raft завжди може вибрати вузол із журналом більшості, тому немає потреби наздоганяти журнал. Хоча іноді вибори повторюються через розподіл голосів, зазвичай це більш ефективний алгоритм виборів.
Для алгоритму Paxos, якщо сервер дуже сильно відстає, навіть на кілька днів у журналах, але в якийсь момент його обирають лідером, це призведе до блокування певного часу. В алгоритмі Raft вузол, журнал якого знаходиться позаду, ніколи не буде вибрано.
3 Підтвердження роботи (PoW)
Ознайомлення з алгоритмом: Комп’ютерна технологія, яка вперше була використана для боротьби зі спамом. У 2008 році Сатоші Накамото запропонував біткойн і блокчейн у документі про біткойн «Біткойн: однорангова електронна готівкова система» та інноваційно розробив алгоритм PoW, який було застосовано до біткойна для вирішення математичних головоломок для досягнення консенсусу. Основним змістом алгоритму є використання обчислювальної потужності для пошуку одноразового значення, яке задовольняє хеш блоку. Однак люди швидко виявили проблеми цього механізму консенсусу, тобто велике споживання енергії та контроль обчислювальної потужності великими майнінг-пулами все одно призведуть до проблем централізації.
Принцип алгоритму: Основна особливість системи підтвердження роботи полягає в тому, що клієнту потрібно виконати певну складну роботу, щоб отримати результат, але верифікатор може легко перевірити, чи виконав клієнт відповідну роботу через результат. . Основною особливістю цієї схеми є асиметрія: робота помірна для запитувача та легко перевірена для верифікатора. Він відрізняється від капчі, яка розроблена таким чином, щоб її легко розгадати людям, а не комп’ютерам.
Proof of Work (PoW) знаходить числовий Nonce шляхом обчислення, щоб хеш-значення вмісту після об’єднання даних транзакції відповідало вказаній верхній межі. Після того, як вузол успішно знаходить задовільне значення хеш-функції, він негайно розповсюдить упакований блок всій мережі, а вузли мережі перевірять його відразу після отримання широкомовного пакетного блоку.
Недоліки: Низька швидкість; величезне споживання енергії, що не корисно для навколишнього середовища; вразливість до "економії на масштабі".
Переваги: Ретельно протестовано з 2009 року та все ще широко використовується сьогодні.
4 Proof of Stake (PoS)
Ознайомлення з алгоритмом: У 2011 році Quantum було запропоновано на форумі Bitcointalk. У серпні 2012 року народився Peercoin, перший блокчейн-проект, заснований на консенсусі PoS. Peercoin є першим додатком, який реалізує алгоритм PoS. Відсоток у Peercoin — це вік монети, який є добутком кількості монет, які зберігає вузол, на час утримання. Ініціація транзакції споживає певну кількість віку монети, і щоразу, коли споживається вік монети 365, річний вийде процентна ставка 5%.
Користувачі: Ethereum(2.0), Conflux, Peercoin.
Принцип алгоритму: Наприклад, якщо хтось зберігає 100 доткойнів під час транзакції протягом 30 днів, тоді вік валюти становить 3000, а блок PoS знайдено пізніше, вік валюти скидається до 0, а відсотки виходить Це 0,05*3000/365=0,41 монет. Під час процесу консенсусу вузли отримують право на бухгалтерський облік через використаний вік монети. Чим більший вік монети споживає вузол, тим більший шанс отримати право на бухгалтерський облік. Принцип основного ланцюжка, встановленого алгоритмом, такий: ланцюжок, який споживає найбільшу кількість валют, є правильним і ефективним ланцюгом у системі.
Переваги: Немає потреби у потужному дорогому обладнанні для майнінгу. Зменшіть споживання ресурсів і зменшіть можливість атак на 51%.
Недоліки: це може змусити багатих накопичувати криптовалюту, утворюючи ефект Метью, що може спричинити інфляцію криптовалюти.
5 Доказ історії (PoH)
**Ознайомлення з алгоритмом: **Proof of history було створено Solana, високопродуктивним блокчейном, запущеним у 2018 році. Proof of history дозволяє учасникам мережі досягти консенсусу вчасно за допомогою перевіреної функції затримки, таким чином уникаючи «найдовшої» правило ланцюга.
PoH — це годинник мережі, а TowerBFT — її сторожова вежа, завданням якої є запобігання підробці параметрів часу зловмисними вузлами. Будь-який валідатор, який проголосував за блок, повинен дочекатися створення наступного блоку та отримати підтвердження від історії про те, що «минув час», перш ніж голосувати знову.
Solana вміло відокремлює часовий ланцюжок і стан на основі хешів. Замість того, щоб пов’язувати хеші кожного блоку разом, верифікатор у мережі хешує сам хеш у блоці. Цей механізм — PoH. PoH встановлює криптографічно перевірену послідовність подій у часі за допомогою високочастотної верифікованої функції затримки (VDF). По суті, це означає, що PoH схожий на криптографічний годинник, який допомагає мережі узгодити час і порядок подій, не чекаючи повідомлень від інших вузлів. Послідовний вихід історично перевірених хешів стану блокчейну дає послідовність подій, яку можна перевірити.
**Користувач:**Solana
Принцип алгоритму: Leader генерує мітку часу для кожного підпису даних (транзакція, яку необхідно підтвердити), і безпосередньо сортує транзакції, таким чином уникаючи проблеми сортування часу в PoS, і кожен верифікатор гарантії може перевіряти незалежно, що значно скорочує проблема зміни порядку часу під час перевірки, і потрібно лише перевірити підтвердження транзакції.
Переваги: низькі комісії, лише частка цента за транзакцію, висока швидкість транзакції, хороша масштабованість,
**Недоліки: **Занепокоєння щодо централізації, Solana наразі має менше 1200 валідаторів, які перевіряють транзакції у своїй мережі. Менше децентралізованих програм: часто називають вбивцею Ethereum. Згідно з його веб-сайтом, на Solana було створено понад 350 Dapps у порівнянні з майже 3000 на Ethereum, і саме тут Defi наразі потрібно більше часу на розробку та інновацій.
6 Підтвердження повноважень (PoA)
Ознайомлення з алгоритмом: його запропонував у 2017 році Гевін Вуд, співзасновник Ethereum (ETH) і Parity Technologies. Механізм PoA не майнить і не потребує токена. У вторинній блокчейн-мережі на основі PoA всі транзакції та блоки обробляються валідаторами. Вартість обслуговування платформи PoA низька, але в PoA верифікатором транзакцій і верифікаційного блокчейну має бути особа, яка може пройти перевірку надійності. Тому верифікатори PoA повинні приділяти велику увагу власній репутації. Репутація є дуже важливим активом у PoA. Як правило, валідатори розкривають свої справжні особи. В даний час технологія блокчейн, сформована цим механізмом консенсусу, в основному застосовується до мереж альянсів і приватних мереж з очевидними галузевими характеристиками.
Користувачі: PoA, Ethereum Kovantestnet, xDai, VeChain і логістична мережа Walmart.
Принцип алгоритму:
a. Вибрати авторитетний сертифікатор;
б. Кілька верифікаторів генеруватимуть блоки для запису транзакцій і отримають винагороду за блокування та комісію за транзакції. У PoA верифікатор є ключем до всього механізму консенсусу. Верифікатор отримує право гарантувати мережу, розміщуючи цей ідентифікатор в обмін на винагороду за блок. Якщо верифікатор діє зловмисно або вступає в змову з іншими верифікаторами протягом усього процесу, зловмисників можна видалити та замінити за допомогою керування в мережі. Існуючі юридичні засоби захисту від шахрайства застосовуються по всій мережі, щоб захистити учасників від зловмисних дій валідаторів.
перевага:
a. Вимагає меншої обчислювальної потужності, без майнінгу, енергозбереження та захисту навколишнього середовища;
b Перевірка є швидкою та підтримує швидші транзакції;
c. Верифікатори всієї мережі контролюють один одного, і вони можуть проголосувати за приєднання до досвідчених верифікаторів або усунення некваліфікованих верифікаторів у будь-який час
г. Хардфорки захищені законом, і кожен валідатор підписує юридичну угоду.
недолік:
a. Публічна ідентичність, конфіденційність і анонімність будуть зменшені
б) Валідатори позначаються як юридично забезпечені централізовані вузли повноважень
**7 Відкладене підтвердження роботи (**Відкладене підтвердження роботи, dPoW)
** **
**Вступ до алгоритму:**Перш ніж пояснювати DPoW, вам потрібно пояснити, що таке PoB. PoB (Proof of Burn) називається механізмом підтвердження спалювання, який є зобов’язанням голосувати за лідера мережі шляхом спалювання токенів у власних руках. Чим більше кількість спалених токенів, тим вище ймовірність досягнення лідерства в мережі.
У блокчейні на основі dPoW майнери більше не отримують жетони за майнінг, а «дерева», які можна спалити — спалювання дров. Майнери використовують власні обчислювальні потужності, щоб остаточно підтвердити своє робоче навантаження за допомогою алгоритму хешування, а потім отримати відповідну деревину, якою не можна торгувати. Коли деревина накопичиться до певної кількості, можна вирушати на місце згоряння, щоб спалити дрова.
Після розрахунку за набором алгоритмів особа, яка спалить більше дров або BP або група BP, може отримати право створити блок у наступному сегменті події та отримати винагороду (токен) після успішного створення блоку. Оскільки за певний проміжок часу може бути багато людей, які спалюють дрова, ймовірність створення блоку в наступний проміжок часу визначається кількістю дров, спалених самим. Чим більше спалено, тим вище ймовірність отримати право виробляти блоки в наступний період часу.
Це може досягти балансу між обчислювальною потужністю та правами на майнінг. Майнерам і майнінг-пулам з величезною обчислювальною потужністю не обов’язково ставати виробниками блоків. У маленьких шахтарів також є пружина, якщо вони наполегливо працюють і накопичують певну кількість деревини, вони також можуть виробляти блоки. Ефективність гарантована, кожен бере участь, а найпопулярніший спосіб участі гарантує концепцію децентралізації, що запобігає домінуванню в мережі організаціям з обчислювальною потужністю або власникам великих валют.
**Користувач:**Komodo
Принцип алгоритму: У системі dPoW є два типи вузлів: нотаріальні вузли та звичайні вузли. 64 нотаріальні вузли обираються зацікавленими сторонами блокчейну dPoW для додавання нотаріально засвідчених блоків із блокчейну dPoW до підключеного блокчейну PoW. Після додавання блоку хеш блоку додається до транзакції Bitcoin, підписаної 33 нотаріальними вузлами, і створює запис блоку dPow, хешований у блокчейні Bitcoin. Запис нотаріально засвідчено більшістю нотаріальних вузлів у мережі.
Щоб уникнути воєн майнінгу між нотаріальними вузлами та знизити ефективність мережі, Komodo розробила метод майнінгу з використанням механізму опитування, який має два режими роботи.
У режимі «Без нотаріуса» всі вузли мережі підтримують участь у майнінгу, що схоже на традиційний механізм консенсусу PoW. У режимі «Активні нотаріуси» мережеві нотаріуси здійснюють майнінг, використовуючи значно знижений рівень складності мережі. У режимі «нотаріальної активації» кожному нотаріусу дозволено використовувати свою поточну складність для видобутку блоку, тоді як інші нотаріальні вузли повинні використовувати 10-кратну складність видобутку, а всі звичайні ноди використовують 100-кратну складність нотаріальних вузлів для видобутку.
**Переваги: **Енергозбереження; підвищена безпека; може додати цінність іншим блокчейнам, непрямо надаючи біткойн (або будь-який інший ланцюжок безпеки), не сплачуючи ціну транзакцій біткойна (або будь-якого іншого ланцюга безпеки).
Недоліки: Лише блокчейни, що використовують PoW або PoS, можуть прийняти цей алгоритм консенсусу; у режимі «Активні нотаріуси» швидкість хешування різних вузлів (нотаріусів або звичайних вузлів) має бути відкаліброваною, інакше різниця між швидкістю хешування вибухне. .
Ознайомлення з алгоритмом. Механізм DPoS, також відомий як «Механізм підтвердження авторизації спільного використання» та «Механізм довіреної особи», був запропонований у квітні 2014 року Деном Ларімером (BM), головним розробником Bitshares. З певної точки зору DPOS трохи нагадує парламентську систему чи систему народних зборів. Якщо делегат не виконує своїх обов’язків (не створює блок, коли настає його черга), він видаляється зі списку, і мережа обирає новий супервузол на його заміну.
Для полегшення розуміння можна навести інший приклад. Уявіть собі компанію з 1000 співробітників, кожен з яких володіє різною кількістю акцій компанії. Час від часу співробітники можуть проголосувати за 10 осіб, яких вони найбільше вважають керівниками компанії, і права голосу кожного працівника пропорційні кількості акцій, якими він володіє. Після того, як усі проголосують, 10 осіб, які набрали найбільше голосів, стануть лідерами компанії.
Якщо керівник некомпетентний або робить щось шкідливе для компанії, працівник може відкликати голосування за лідера, щоб його голосування не потрапило в топ-10, тим самим звільнившись з керівництва.
Користувачі: BitShares, Steemit, EOS, Lisk, Ark.
**Переваги: **Енергозбереження; швидкий; високий трафік сайт Steemit використовує його. Час блокування EOS становить 0,5 секунди.
**Недоліки: **Трохи централізовано; учасники з високими ставками можуть голосувати за те, щоб стати валідатором (нещодавно це була проблема в EOS).
9 Practical Byzantine Fault Tolerance (PBFT)
** **
Ознайомлення з алгоритмом: в алгоритмі PBFT один вузол вважатиметься головним вузлом, а інші вузли — резервними. Усі вузли системи будуть спілкуватися один з одним, і кінцева мета полягає в тому, щоб кожен міг досягти консенсусу за принципом підкорення меншості більшості.
Процес консенсусу:
Клієнт надсилає запит до головного вузла для виконання операції
б) Головний вузол широкомовно передає цей запит кожному резервному вузлу
в. Усі вузли виконують операцію та повертають результат клієнту
г. Коли клієнт отримує f+1 ідентичних результатів від різних вузлів, процес завершується. f представляє максимальне значення можливих лежачих вузлів.
Ознайомлення з алгоритмом: Китайська блокчейн-спільнота NEO (раніше відома як Xiaoyi) запропонувала вдосконалений візантійський відмовостійкий алгоритм dBFT. Цей алгоритм спирається на ідею дизайну PoS на основі PBFT. Бухгалтер, а потім і бухгалтери досягають консенсус через візантійський відмовостійкий алгоритм. Цей алгоритм покращує відсутність остаточної узгодженості PoW і PoS, роблячи блокчейн придатним для фінансових сценаріїв.
Крім того, щоб вирішити проблему візантійських генералів, механізм «авторизованої візантійської відмовостійкості» є консенсусним алгоритмом, який гарантує відмовостійкість, реалізовану всередині блокчейну NEO. У цьому механізмі є два учасники, один – «бухгалтерський вузол» професійної бухгалтерії, а інший – звичайний користувач системи.
Звичайні користувачі голосують, щоб визначити облікові вузли на основі частки їхніх активів. Коли необхідно досягти консенсусу, із цих облікових вузлів випадковим чином вибирається речник для складання плану, а потім інші облікові вузли слідують візантійському відмовостійкому алгоритм.Тобто принцип меншості підкоряється більшості робить заяву.Якщо більше 66% вузлів згодні з планом спікера, досягається консенсус, інакше спікер переобирається і голосування повторюється.
Оскільки всі делегати можуть перевіряти пропозиції щодо блокування, легко зрозуміти, дійсні чи недійсні дані, надіслані доповідачем. Отже, якщо спікер нечесний і надсилає недійсну пропозицію двом третинам делегатів, блоки не збігатимуться, і власники вузлів не перевірятимуть їх. Консенсус досягається двома третинами голосів і обирається новий спікер.
**Користувач:**Neo
Процес консенсусу:
a. Будь-хто може бути представником, якщо він або вона відповідає вимогам. Усі власники токенів NEO можуть голосувати, делегати не є анонімними, і щоб стати власником вузла, потрібно 1000 GAS.
б) Доповідач обирається випадковим чином з числа делегатів.
в) Доповідач створює новий блок із транзакцій, які очікують перевірки. Потім спікер надсилає пропозицію обраним представникам. Вони повинні відстежувати всі транзакції та реєструвати їх у мережі.
г. Делегати можуть ділитися та порівнювати пропозиції, які вони отримали, щоб перевірити точність даних, а також чесність доповідачів. Якщо більше двох третин делегатів досягають консенсусу та підтверджують його, блок додається до блокчейну.
**Переваги: **Швидко (генерація блоку займає 15-20 секунд); велика пропускна здатність транзакцій, відсутність потреби в енергії, масштабованість і відсутність форків.
Недоліки: Немає анонімності, і для того, щоб бути обраним, потрібна справжня особа. Кожен змагається за те, щоб стати корінним ланцюгом. Може бути кілька кореневих ланцюгів.
Ознайомлення з алгоритмом: Принципи dBft і RPBFT подібні до PBFT, за винятком того, що не всі вузли беруть участь у консенсусі, але вузли поділяються на два типи:
a. Консенсусний вузол: вузол, який виконує консенсусний процес PBFT і має право генерувати блоки по черзі.
b. Верифікаційний вузол: не виконувати процес консенсусу, перевірити, чи є консенсусний вузол законним, заблокувати перевірку, після кількох раундів консенсусу він переключиться на консенсусний вузол
У циклічній візантійській відмовостійкості вузли консенсусу по черзі замінюються вузлами перевірки.
**Випадок використання: **Fisco-BCOS
**Переваги: **Швидкість передачі вище, ніж плітки, і немає надлишкових пакетів повідомлень
Розділяй і володарюй, вихідна пропускна здатність кожного вузла дорівнює O(1), сильна масштабованість
Недоліки: Проміжний вузол є єдиною точкою і вимагає додаткових стратегій відмовостійкості
12. AptosBFT
** **
Ознайомлення з алгоритмом: Це також похідний алгоритм від PBFT. Алгоритм консенсусу, названий на честь Aptos, базується на HotStuff, який базується на PBFT. Переваги цієї моделі алгоритму як цибуля і матрьошка, яку потрібно шар за шаром очищати. Кожен вузол спілкується лише з лідером, а не надсилає повідомлення лідеру та всім іншим «генералам». Лідер транслює повідомлення (пропонований блок) для голосування; кожен вузол надсилає свій голос лідеру, який зібрав повідомлення.
Випадок використання: Aptos
Нарешті, короткий зміст цієї частини додається:
**Крім того, існують незвичайні алгоритми консенсусу. **
У 2015 році професор Девід Мазьєр, головний науковий співробітник Stellar.org, запропонував Stellar Consensus Protocol (SCP). SCP розвинувся на основі Федеральної візантійської угоди та Ripple Agreement і є першим доведено безпечним механізмом консенсусу з чотирма ключові властивості децентралізованого контролю, низької затримки, гнучкої довіри та асимптотичної безпеки.
У тому ж році проект Sawtooth Lake від Hyperledger поєднав консенсус Ripple і SCP і запропонував алгоритм консенсусу голосування кворуму для роботи зі сценаріями додатків, які вимагають миттєвої завершеності транзакції.
У 2016 році лауреат премії Тюрінга та професор Массачусетського технологічного інституту Сівіо Мікалі запропонував швидкий візантійський відмовостійкий алгоритм консенсусу під назвою AlgoRand. Цей алгоритм використовує технологію криптографічної лотереї для вибору верифікатора та лідера процесу консенсусу, а також через розроблений ним BA* The Byzantine Fault Tolerant Protocol досягає консенсусу щодо нових блоків. AlgoRand вимагає дуже мало обчислень і дуже мало розгалужень, і вважається справді демократичною та ефективною технологією консенсусу розподіленої книги.
У 2017 році Корнельський університет запропонував новий алгоритм під назвою Sleepy Consensus (сплячий консенсус).Цей консенсус спрямований на те, що більшість великомасштабних вузлів консенсусу в Інтернет-середовищі можуть бути офлайн, і лише кілька вузлів знаходяться в режимі онлайн Реальність участі в процесі консенсусу. Це дослідження доводить, що традиційний алгоритм консенсусу не може гарантувати безпеку консенсусу в цьому середовищі.Однак, використовуючи неактивний алгоритм консенсусу, доки кількість чесних онлайн-вузлів перевищує кількість несправних вузлів, можна гарантувати безпеку та надійність.
##04 Резюме
Якщо ви вискочите з точки зору розробника та включите більше способів мислення, які поєднують політику та економіку, може виникнути більше консенсусних алгоритмів, таких як поєднання консенсусних методів, подібних до концепції PPP, які можуть не лише досягти характеру покарання за зловмисники сторони, але також може досягти мети економії обчислювальної потужності найбільш ефективно.
Коротше кажучи, механізм консенсусу є ядром технології блокчейн. Він може вирішити проблему довіри в розподіленій системі, забезпечити узгодженість даних і безпеку між вузлами, а також уникнути атак і втручання зловмисних вузлів, таким чином забезпечуючи блокову стабільність і надійність ланцюгової системи. У той же час механізм консенсусу також може вирішити проблему «подвійних витрат» і підвищити пропускну здатність і швидкість обробки системи блокчейн. Але різноманітні алгоритми консенсусу не є абсолютно безпечними, ефективними та децентралізованими.
Немає найкращого алгоритму, є лише алгоритм, який вам найбільше підходить. Вибір алгоритму консенсусу сильно залежить від сценарію застосування. Довірені середовища використовують Paxos або RAFT, дозволені альянси можуть використовувати PBFT, а неавторизовані ланцюги можуть використовувати PoW, PoS, консенсус Ripple тощо. **Найкращий механізм консенсусу завжди той, який відповідає потребам користувача. **
Довідка:
Що таке механізми консенсусу в блокчейні та криптовалюті?
Загроза подвійної атаки на блокчейн
Прочитайте 11 основних консенсусних алгоритмів в одній статті та досконало зрозумійте, що таке PoS, PoW, dPoW, PBFT і dBFT?
4Розуміння подвійних витрат і як запобігти атакам
5 Вступ до застосування візантійських механізмів консенсусу
6AptosBFT: все, що вам потрібно знати про консенсус BFT в Aptos
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Зрозумійте механізм консенсусу та 11 основних алгоритмів консенсусу в одній статті
Спікер: Учіха Мадара
РЕДАГУВАТИ: затяжки
Джерело:Deschool
Ця стаття є конспектами третього уроку університетського курсу web3 від DeSchool, лектором якого є Учіха Мадара. Вміст занадто сухий і не змішаний з водою. Рекомендується збирати його та перетравлювати повільно. Крім того, для полегшення розуміння в цю статтю внесено деякі зміни та доповнення відповідно до змісту курсу.
Основний зміст статті включає:
Вступ до алгоритму консенсусу
Класифікація консенсусних алгоритмів
Детальне пояснення консенсусних алгоритмів (PoW, PoS, PoH, PoA, PBFT тощо)
01 Вступ до механізму консенсусу
У комунікації та вивченні блокчейну «алгоритм консенсусу» є дуже часто згадуваним словником. Саме через існування алгоритму консенсусу можна гарантувати довіру до блокчейну.
**1. Навіщо нам механізм консенсусу? **
Так званий консенсус означає, що кілька людей досягають згоди. Наше життя сповнене механізмів досягнення консенсусу. Наприклад, компанії потрібні акціонери, щоб колективно обговорити рішення, а Стороні А та Стороні Б потрібно сісти й провести переговори, щоб підписати контракт. Цей процес є процесом досягнення консенсусу.
У системі блокчейн кожен вузол повинен узгодити свій обліковий запис з обліковими книгами інших вузлів. Якщо це в традиційному централізованому сценарії, це навряд чи є проблемою, оскільки існує центральний сервер, який є так званою головною бібліотекою, а інші підлеглі бібліотеки можна узгодити з головною бібліотекою.
Але в децентралізованому управлінні немає боса, тож як приймати рішення? У цей час для забезпечення консенсусу необхідний набір алгоритмів. Ось про що йтиметься в цій статті – про механізм консенсусу.
**2. Що таке механізм консенсусу? **
Механізм консенсусу (Consensus Mechanism) завершує перевірку та підтвердження транзакцій за дуже короткий проміжок часу через голосування спеціальних вузлів; для транзакції, якщо кілька вузлів з невідповідними інтересами можуть досягти консенсусу, ми можемо вважати, що вся мережа Щодо цього також існує консенсус.
Хоча консенсус (Consensus) і узгодженість (Consistency) вважаються приблизно еквівалентними в багатьох прикладних сценаріях, існують тонкі відмінності в їхніх значеннях: дослідження консенсусу зосереджено на процесі й алгоритмі досягнення консенсусу розподілених вузлів, тоді як дослідження узгодженості зосереджено на стабільному стан, нарешті досягнутий у процесі консенсусу вузла; крім того, більшість традиційних досліджень розподіленого консенсусу не розглядають візантійську проблему відмовостійкості, тобто передбачається, що немає візантійських вузлів, які зловмисно змінюють або підробляють дані. Адже в повністю відкритій і прозорій блокчейн-мережі немає гарантії, що всі вузли не будуть робити зло.
**3. Які проблеми може вирішити механізм консенсусу? **
Механізм консенсусу може вирішити проблему довіри в розподіленій системі та забезпечити узгодженість даних і безпеку між вузлами. У традиційній розподіленій системі, оскільки між вузлами немає механізму довіри, вона вразлива до атак і втручання з боку зловмисних вузлів, що призводить до збоїв системи або підробки даних. Крім того, до появи технології шифрування блокчейну зашифрована цифрова валюта, як і інші активи, могла нескінченно відтворюватися.Без централізованого агентства-посередника люди не мали можливості підтвердити, чи була витрачена сума цифрових грошей.
Простіше кажучи, механізм консенсусу може ефективно вирішити дві проблеми: проблему подвійних витрат (сума грошей витрачається двічі) і візантійську загальну проблему (шкідливі вузли підробляють дані).
4. Подвійна атака
**
**
Механізм консенсусу може певною мірою вирішити атаку подвійних витрат: тобто сума грошей витрачається двічі або більше ніж двічі, що також називається «подвійними витратами». У грі в кішки-мишки Сяо Лізі зробив поведінку подвійних витрат, зробивши фальшивий чек.Оскільки перевірка чека потребує часу, він використав інформацію того самого чеку, щоб придбати товари багато разів протягом цієї різниці в часі.
Як ми всі знаємо, вузли блокчейну завжди вважають найдовший ланцюг правильним і продовжують працювати та розширювати його. Якщо два вузли транслюють різні версії нового блоку одночасно, робота виконуватиметься на основі блоку, отриманого першим, але інший ланцюжок також буде збережено, якщо останній стане найдовшим. Зачекайте, поки буде знайдено наступне підтвердження роботи, і один із ланцюжків виявиться довшим, тоді вузли, що працюють на іншому ланцюжку гілки, поміняються таборами.
Як досягаються подвійні витрати? Розділені на дві ситуації:
**(1) Подвійні витрати до підтвердження. **Транзакції з нульовим підтвердженням могли зрештою не бути записані в блокчейн. Якщо сума невелика, найкраще уникнути таких подвійних витрат, принаймні дочекавшись підтвердження.
**(2) Подвійні витрати після підтвердження. **Для реалізації потрібно контролювати понад 50% обчислювальної потужності. Тобто, схоже на невеликий форк, що поміщає транзакції для магазину в блоки-сиріти. Подібні подвійні витрати після підтвердження важко здійснити, але це лише теоретично.
** Є три найпоширеніші атаки подвійного витрачання: атака 51%, атака раси та атака Фінні. **
Атака 51%: атака 51% – це коли особа або група отримує контроль над 51% потужності хешування блокчейну, що означає, що вони мають можливість контролювати деякі аспекти проекту. У блокчейні з підтвердженням роботи, такому як біткойн, цього можна досягти шляхом отримання контролю над потужністю майнінгу в мережі. З іншого боку, для блокчейну з підтвердженням ставки, такого як Cardano, цього можна було б досягти, контролюючи 51% токенів, на які поставлено ставку.
Race Attack: користувач надсилає дві транзакції двом торговцям (або продавцю та користувачеві) одночасно. Таким чином, зловмисник отримує два комплекти товарів або отримує товари та відшкодовує початкову вартість транзакції.
Атака Finney: майнер майнить блок або серію блоків, які містять транзакції, які переказують гроші на його власну адресу. Видобуті блоки не публікуються, але зберігаються, поки майнер переказує гроші продавцю. Тоді торговець відпускає товари, за які майнер заплатив, перш ніж майнер опублікує викопаний ним блок. Потім майнери публікують викопані блоки, що стирає переказ торговцю, і торговець може заплатити за це зі своєї кишені.
Класичний випадок атаки подвійною квіткою:
У 2018 році зловмисник контролював понад 51% обчислювальної потужності в мережі BTG.За період контролю обчислювальної потужності він відправив певну кількість BTG на свій гаманець на біржі.Ця гілка отримала назву гілка А. У той же час надішліть ці BTG на інший гаманець, яким ви керуєте, і ця гілка називається гілкою B. Після підтвердження транзакції у відділенні A зловмисник негайно продає BTG, щоб отримати готівку. Згодом зловмисник майнить на гілці B. Оскільки він контролює понад 51% обчислювальної потужності, довжина гілки B незабаром перевищить довжину гілки A, і гілка B стане основним ланцюгом. Транзакції на гілці A Це буде відкочується для відновлення попереднього стану. BTG, які зловмисник обміняв на готівку перед тим, як повернув собі в руки, і ці BTG є втратою обміну. Таким чином зловмисник, покладаючись на понад 50% контролю обчислювальної потужності, реалізував «подвійну витрату» однієї і тієї ж криптовалюти.
5. Візантійські невдачі
**
**
Проблема візантійських генералів — гіпотетична проблема, поставлена Леслі Лемпортом у 1980-х роках. Візантія була столицею Східної Римської імперії. Через величезну територію Візантійської Римської імперії на той час гарнізони кожної армії були далеко один від одного, а генерали могли доставляти повідомлення лише гінцями. На випадок війни генерали повинні розробити єдиний план дій.
Однак серед цих генералів є зрадники, які сподіваються підірвати послідовний план дій лояльних генералів, вплинувши на формування та поширення єдиного плану дій. Отже, генерали повинні мати заздалегідь визначену угоду про метод, щоб усі лояльні генерали могли домовитися. І жменька зрадників не може змусити вірних генералів будувати хибні плани. Іншими словами, суть проблеми візантійських генералів полягає в тому, щоб знайти спосіб змусити генералів досягти консенсусу щодо плану бою в недовірливому оточенні зрадників.
У розподіленій системі, особливо в мережевому середовищі блокчейн, це також схоже на візантійське загальне середовище, є нормальні сервери (схожі на лояльних візантійських генералів), є несправні сервери та сервери-саботажники (схожі на зрадницького візантійського генерала). Основою алгоритму консенсусу є формування консенсусу щодо стану мережі серед звичайних вузлів. Якщо є лише 3 вузли, проблема візантійських генералів є нерозв’язною.Якщо у вузлах є x вузлів проблеми, а сумарні точки менше 3x+1, проблема візантійських генералів не має розв’язку.
Поява біткойна легко вирішує цю проблему: він збільшує вартість передачі інформації, знижує швидкість передачі інформації та додає випадковий елемент, щоб лише один генерал міг транслювати інформацію протягом певного періоду часу. Перший генерал, який передає повідомлення, є першим комп’ютером, який знаходить дійсний хеш, і поки інші генерали отримують і перевіряють цей дійсний хеш та інформацію, що додається до нього, вони можуть лише оновлювати їх новою інформаційною копією книги, а потім перерахувати хеш-значення. Наступний генерал, який обчислює ефективне хеш-значення, може приєднати свою оновлену інформацію до ефективного хеш-значення та транслювати це всім. Змагання за обчисленням хешування потім починається з нової початкової точки. Завдяки безперервній синхронізації мережевої інформації всі комп’ютери в мережі використовують ту саму версію книги.
02 Класифікація консенсусних алгоритмів
1. Історія механізму консенсусу
Коли комп’ютери та мережі стали популярними в 1980-х і 1990-х роках, з’явилися спільні бази даних, щоб кілька користувачів могли отримати доступ до інформації, яку вони зберігають. Більшість із них мають центральну базу даних, до якої користувачі можуть отримати доступ із різних сайтів. Це налаштування перетворюється на централізовану мережу, де адміністратори надають дозволи користувачам і підтримують цілісність даних.
Ці спільні бази даних відомі як розподілені книги, оскільки вони записують інформацію та об’єднані в мережу для доступу багатьох користувачів у різних місцях. Однією з найважливіших проблем, яку необхідно вирішити, є запобігання підробці даних і несанкціонованому доступу, зловмисному чи ні. Потрібен спосіб автоматизації управління розподіленою базою даних, щоб гарантувати, що дані не змінюються.
Ця потреба призвела до створення розподіленого автономного консенсусу, де програми в мережі використовують криптографію для узгодження стану бази даних. Протокол призначений для досягнення за допомогою криптографічного алгоритму для створення довгого рядка буквено-цифрових чисел (хеш), який потім перевіряється програмою, що працює в мережі. Хеш змінюється лише тоді, коли змінюється інформація, що вводиться в алгоритм хешування, тому програми створені для порівняння хешів, щоб переконатися, що вони збігаються.
Коли кожна програма, що працює в мережі, створює відповідний хеш-рядок, кажуть, що дані досягли консенсусу в мережі. Таким чином, був створений механізм консенсусу, який зазвичай вказував на анонімного творця біткойнів Сатоші Накамото. Однак багато людей працювали над механізмом консенсусу роками до того, як Сатоші випустив білу книгу, яка прославила біткойн.
Вчені з обробки даних і комп’ютерів, такі як Моні Наор, Синтія Дворк, Адам Бек, Нік Сабо та багато інших, працювали над механізмами консенсусу в мережі та зробили свій внесок у їх розвиток.
2 Класифікація консенсусних алгоритмів
Відповідно до різних типів відмовостійкості алгоритми консенсусу можна розділити на дві категорії: алгоритм консенсусу CFT (невізантійська відмовостійкість, тобто шкідливі вузли не враховуються) і консенсусний алгоритм BFT (візантійська відмовостійкість, що є, розглядаються шкідливі вузли).
«Чи терпіти Візантію» означає, чи можна застосовувати алгоритм до мереж із низьким рівнем довіри. Загалом, візантійський відмовостійкий алгоритм повинен використовуватися в публічному ланцюжку, тоді як у ланцюжку альянсу він може бути обраний відповідно до ступеня довіри між учасниками альянсу.Якщо ступінь довіри високий, усі є добросовісним вузлом за замовчуванням і може використовувати алгоритм CFT (non-Byzantine fault-tolerant).
**Крім того, його можна розділити на дві категорії відповідно до узгодженості: **алгоритм імовірнісного консенсусу та алгоритм абсолютної узгодженості. Алгоритм імовірнісного консенсусу означає, що між різними розподіленими вузлами існує висока ймовірність того, що дані між вузлами є узгодженими, але все ще існує певна ймовірність того, що дані між деякими вузлами є неузгодженими. Наприклад, Proof of Work (PoW), Proof of Stake (PoS) і Delegated Proof of Stake (DPoS) — усі ймовірнісні консенсусні алгоритми.
Алгоритм абсолютної узгодженості означає, що в будь-який момент часу дані між різними розподіленими вузлами залишатимуться абсолютно узгодженими, і між різними вузлами не буде неузгодженості даних. Наприклад, алгоритм PAXOS і похідний від нього алгоритм RAFT.
Нижче наведено конкретний поділ і вступ відповідно до типу відмовостійкості.
Алгоритм консенсусу 3CFT
Невізантійська помилка Crash Fault Tolerance: підходить для мереж із високим ступенем довіри до вузла. В тому числі Паксос, Пліт.
Алгоритм консенсусу 4BFT
Перевірка наявності у вузла шкідливих візантійних помилок має тенденцію до децентралізованої структури, включаючи підтвердження роботи (PoW), підтвердження частки (PoS), делеговане підтвердження частки (DPoS), підтвердження повноважень (PoA) тощо.
03 Детальне пояснення алгоритму консенсусу
Ви трохи втомилися бачити це, натисніть улюблене, зробіть перерву та продовжуйте гризти найскладнішу частину цієї статті! Студенти з обмеженим часом можуть почати безпосередньо з третього алгоритму PoW.
1 Алгоритм Паксоса
**
**
Ранній базовий протокол Paxos був складним і відносно неефективним, тому пізніше була запропонована вдосконалена версія Paxos. Наприклад: Fast Paxos, Multi-Paxos і Byzanetine Paxos тощо.
Paxos проходить ряд раундів переговорів, у яких один вузол має стан «лідерства». Якщо лідера немає в мережі, прогрес буде зупинено, доки не буде обрано нового лідера або якщо старий лідер раптово повернеться в мережу.
Paxos поділяє ролі в системі на Пропонента, Приймача та Учня: Пропонент: Пропозиція. Інформація про пропозицію включає номер пропозиції (ідентифікатор пропозиції) і запропоновану вартість (значення). Акцептор: брати участь у прийнятті рішень і відповідати на пропозиції Заявників. Після отримання пропозиції пропозиція може бути прийнята. Якщо пропозиція прийнята більшістю акцептантів, пропозиція вважається схваленою. Учень: не беріть участь у прийнятті рішень, дізнайтеся останню погоджену пропозицію (вартість) від тих, хто пропонує/приймає.
2. Алгоритм плоту
**Ознайомлення з алгоритмом:**Алгоритм Raft (Replication and Fault Tolerant) — це спрощена реалізація пари алгоритмів Paxos. Назва Raft походить від акроніму «Reliable, Replicated, Redundant, And Fault-Tolerant» (надлишковий, стійкий до відмов»). raft робить багато приємних спрощень порівняно з Paxos із продовженням журналу. Це гарантує узгодженість системи, коли більше половини вузлів у системі, що складається з n вузлів, працюють нормально. На відміну від алгоритму Paxos, який безпосередньо походить від проблеми розподіленої узгодженості, алгоритм Raft пропонується з точки зору багатокопійного кінцевого автомата та використовується для керування реплікацією журналу багатокопійного кінцевого автомата. Наприклад, у системі з 5 вузлами 2 вузли можуть мати невізантійські помилки, такі як час простою вузла, розділ мережі та затримка повідомлення.
**Випадок використання: **Реплікація головного-підлеглого бази даних, ланцюжок альянсу.
Принцип алгоритму: У системі Raft є три ролі: Лідер, Послідовник і Кандидат. За звичайних обставин буде лише один лідер, а інші є послідовниками. І лідер буде відповідати за всі зовнішні запити, якщо вони не отримані машиною лідера, запит буде спрямовано до лідера. Зазвичай лідер надсилає повідомлення у фіксований час, тобто серцебиття (heartbeat), щоб сповістити послідовників, що лідер кластера все ще працює. Кожен підписник розробить механізм тайм-ауту (тайм-аут).Коли серцебиття не буде отримано протягом певного періоду часу (зазвичай 150 мс або 300 мс), система перейде в стан вибору.
У цей час кластер вступає в новий виборчий раунд (каденцію) і починає вибори.Якщо вибори успішні, то новий лідер приступає до роботи, інакше термін вважається закінченим і починається новий термін. і почнуться наступні вибори.
Вибори проводяться кандидатами. Це вимагає від кандидатів висувати себе та запитувати голоси з інших серверів у порядку черги, коли серце лідера зупиняється. Кожен сервер віддає лише один голос за або проти поточного кандидата в кожному турі виборів. Якщо ви не наберете більше половини голосів, ви пройдете в наступний тур виборів. Решта кандидатів продовжують висувати себе в порядку черги. поки не буде обраний керівник.
**Переваги алгоритму Raft: **Перший пункт — це простота. Якщо ми заглибимося в те, де Paxos є складнішим, ніж Raft, Хайді Ховард і Річард Мортьє виявили, що складність Paxos відображається в двох аспектах. По-перше, Raft фіксує журнали послідовно, тоді як Paxos дозволяє фіксувати журнали не по порядку, але вимагає додаткового протоколу для заповнення журнальних дірок, які можуть виникнути в результаті. По-друге, усі копії журналу в Raft мають однаковий індекс, термін і порядок, тоді як у Paxos ці терміни можуть відрізнятися.
По-друге, Рафт має ефективний алгоритм вибору лідера. Алгоритм вибору, наведений у документі Paxos, порівнює розмір ідентифікатора сервера.Коли кілька вузлів беруть участь у виборах одночасно, перемагає вузол із більшим ідентифікатором сервера. Проблема полягає в тому, що якщо лідеру, обраному таким чином, не вистачає деяких журналів, він не може негайно виконати операцію запису, і повинен спочатку скопіювати деякі журнали з інших вузлів. Журнал Raft завжди може вибрати вузол із журналом більшості, тому немає потреби наздоганяти журнал. Хоча іноді вибори повторюються через розподіл голосів, зазвичай це більш ефективний алгоритм виборів.
Для алгоритму Paxos, якщо сервер дуже сильно відстає, навіть на кілька днів у журналах, але в якийсь момент його обирають лідером, це призведе до блокування певного часу. В алгоритмі Raft вузол, журнал якого знаходиться позаду, ніколи не буде вибрано.
3 Підтвердження роботи (PoW)
Ознайомлення з алгоритмом: Комп’ютерна технологія, яка вперше була використана для боротьби зі спамом. У 2008 році Сатоші Накамото запропонував біткойн і блокчейн у документі про біткойн «Біткойн: однорангова електронна готівкова система» та інноваційно розробив алгоритм PoW, який було застосовано до біткойна для вирішення математичних головоломок для досягнення консенсусу. Основним змістом алгоритму є використання обчислювальної потужності для пошуку одноразового значення, яке задовольняє хеш блоку. Однак люди швидко виявили проблеми цього механізму консенсусу, тобто велике споживання енергії та контроль обчислювальної потужності великими майнінг-пулами все одно призведуть до проблем централізації.
**Приклади використання:**Bitcoin, ETH1.0, Litecoin, Conflux, Dogecoin.
Принцип алгоритму: Основна особливість системи підтвердження роботи полягає в тому, що клієнту потрібно виконати певну складну роботу, щоб отримати результат, але верифікатор може легко перевірити, чи виконав клієнт відповідну роботу через результат. . Основною особливістю цієї схеми є асиметрія: робота помірна для запитувача та легко перевірена для верифікатора. Він відрізняється від капчі, яка розроблена таким чином, щоб її легко розгадати людям, а не комп’ютерам.
Proof of Work (PoW) знаходить числовий Nonce шляхом обчислення, щоб хеш-значення вмісту після об’єднання даних транзакції відповідало вказаній верхній межі. Після того, як вузол успішно знаходить задовільне значення хеш-функції, він негайно розповсюдить упакований блок всій мережі, а вузли мережі перевірять його відразу після отримання широкомовного пакетного блоку.
Недоліки: Низька швидкість; величезне споживання енергії, що не корисно для навколишнього середовища; вразливість до "економії на масштабі".
Переваги: Ретельно протестовано з 2009 року та все ще широко використовується сьогодні.
4 Proof of Stake (PoS)
Ознайомлення з алгоритмом: У 2011 році Quantum було запропоновано на форумі Bitcointalk. У серпні 2012 року народився Peercoin, перший блокчейн-проект, заснований на консенсусі PoS. Peercoin є першим додатком, який реалізує алгоритм PoS. Відсоток у Peercoin — це вік монети, який є добутком кількості монет, які зберігає вузол, на час утримання. Ініціація транзакції споживає певну кількість віку монети, і щоразу, коли споживається вік монети 365, річний вийде процентна ставка 5%.
Користувачі: Ethereum(2.0), Conflux, Peercoin.
Принцип алгоритму: Наприклад, якщо хтось зберігає 100 доткойнів під час транзакції протягом 30 днів, тоді вік валюти становить 3000, а блок PoS знайдено пізніше, вік валюти скидається до 0, а відсотки виходить Це 0,05*3000/365=0,41 монет. Під час процесу консенсусу вузли отримують право на бухгалтерський облік через використаний вік монети. Чим більший вік монети споживає вузол, тим більший шанс отримати право на бухгалтерський облік. Принцип основного ланцюжка, встановленого алгоритмом, такий: ланцюжок, який споживає найбільшу кількість валют, є правильним і ефективним ланцюгом у системі.
Переваги: Немає потреби у потужному дорогому обладнанні для майнінгу. Зменшіть споживання ресурсів і зменшіть можливість атак на 51%.
Недоліки: це може змусити багатих накопичувати криптовалюту, утворюючи ефект Метью, що може спричинити інфляцію криптовалюти.
5 Доказ історії (PoH)
**Ознайомлення з алгоритмом: **Proof of history було створено Solana, високопродуктивним блокчейном, запущеним у 2018 році. Proof of history дозволяє учасникам мережі досягти консенсусу вчасно за допомогою перевіреної функції затримки, таким чином уникаючи «найдовшої» правило ланцюга.
PoH — це годинник мережі, а TowerBFT — її сторожова вежа, завданням якої є запобігання підробці параметрів часу зловмисними вузлами. Будь-який валідатор, який проголосував за блок, повинен дочекатися створення наступного блоку та отримати підтвердження від історії про те, що «минув час», перш ніж голосувати знову.
Solana вміло відокремлює часовий ланцюжок і стан на основі хешів. Замість того, щоб пов’язувати хеші кожного блоку разом, верифікатор у мережі хешує сам хеш у блоці. Цей механізм — PoH. PoH встановлює криптографічно перевірену послідовність подій у часі за допомогою високочастотної верифікованої функції затримки (VDF). По суті, це означає, що PoH схожий на криптографічний годинник, який допомагає мережі узгодити час і порядок подій, не чекаючи повідомлень від інших вузлів. Послідовний вихід історично перевірених хешів стану блокчейну дає послідовність подій, яку можна перевірити.
**Користувач:**Solana
Принцип алгоритму: Leader генерує мітку часу для кожного підпису даних (транзакція, яку необхідно підтвердити), і безпосередньо сортує транзакції, таким чином уникаючи проблеми сортування часу в PoS, і кожен верифікатор гарантії може перевіряти незалежно, що значно скорочує проблема зміни порядку часу під час перевірки, і потрібно лише перевірити підтвердження транзакції.
Переваги: низькі комісії, лише частка цента за транзакцію, висока швидкість транзакції, хороша масштабованість,
**Недоліки: **Занепокоєння щодо централізації, Solana наразі має менше 1200 валідаторів, які перевіряють транзакції у своїй мережі. Менше децентралізованих програм: часто називають вбивцею Ethereum. Згідно з його веб-сайтом, на Solana було створено понад 350 Dapps у порівнянні з майже 3000 на Ethereum, і саме тут Defi наразі потрібно більше часу на розробку та інновацій.
6 Підтвердження повноважень (PoA)
Ознайомлення з алгоритмом: його запропонував у 2017 році Гевін Вуд, співзасновник Ethereum (ETH) і Parity Technologies. Механізм PoA не майнить і не потребує токена. У вторинній блокчейн-мережі на основі PoA всі транзакції та блоки обробляються валідаторами. Вартість обслуговування платформи PoA низька, але в PoA верифікатором транзакцій і верифікаційного блокчейну має бути особа, яка може пройти перевірку надійності. Тому верифікатори PoA повинні приділяти велику увагу власній репутації. Репутація є дуже важливим активом у PoA. Як правило, валідатори розкривають свої справжні особи. В даний час технологія блокчейн, сформована цим механізмом консенсусу, в основному застосовується до мереж альянсів і приватних мереж з очевидними галузевими характеристиками.
Користувачі: PoA, Ethereum Kovantestnet, xDai, VeChain і логістична мережа Walmart.
Принцип алгоритму:
a. Вибрати авторитетний сертифікатор;
б. Кілька верифікаторів генеруватимуть блоки для запису транзакцій і отримають винагороду за блокування та комісію за транзакції. У PoA верифікатор є ключем до всього механізму консенсусу. Верифікатор отримує право гарантувати мережу, розміщуючи цей ідентифікатор в обмін на винагороду за блок. Якщо верифікатор діє зловмисно або вступає в змову з іншими верифікаторами протягом усього процесу, зловмисників можна видалити та замінити за допомогою керування в мережі. Існуючі юридичні засоби захисту від шахрайства застосовуються по всій мережі, щоб захистити учасників від зловмисних дій валідаторів.
перевага:
a. Вимагає меншої обчислювальної потужності, без майнінгу, енергозбереження та захисту навколишнього середовища;
b Перевірка є швидкою та підтримує швидші транзакції;
c. Верифікатори всієї мережі контролюють один одного, і вони можуть проголосувати за приєднання до досвідчених верифікаторів або усунення некваліфікованих верифікаторів у будь-який час
г. Хардфорки захищені законом, і кожен валідатор підписує юридичну угоду.
недолік:
a. Публічна ідентичність, конфіденційність і анонімність будуть зменшені
б) Валідатори позначаються як юридично забезпечені централізовані вузли повноважень
**7 Відкладене підтвердження роботи (**Відкладене підтвердження роботи, dPoW)
**
**
**Вступ до алгоритму:**Перш ніж пояснювати DPoW, вам потрібно пояснити, що таке PoB. PoB (Proof of Burn) називається механізмом підтвердження спалювання, який є зобов’язанням голосувати за лідера мережі шляхом спалювання токенів у власних руках. Чим більше кількість спалених токенів, тим вище ймовірність досягнення лідерства в мережі.
У блокчейні на основі dPoW майнери більше не отримують жетони за майнінг, а «дерева», які можна спалити — спалювання дров. Майнери використовують власні обчислювальні потужності, щоб остаточно підтвердити своє робоче навантаження за допомогою алгоритму хешування, а потім отримати відповідну деревину, якою не можна торгувати. Коли деревина накопичиться до певної кількості, можна вирушати на місце згоряння, щоб спалити дрова.
Після розрахунку за набором алгоритмів особа, яка спалить більше дров або BP або група BP, може отримати право створити блок у наступному сегменті події та отримати винагороду (токен) після успішного створення блоку. Оскільки за певний проміжок часу може бути багато людей, які спалюють дрова, ймовірність створення блоку в наступний проміжок часу визначається кількістю дров, спалених самим. Чим більше спалено, тим вище ймовірність отримати право виробляти блоки в наступний період часу.
Це може досягти балансу між обчислювальною потужністю та правами на майнінг. Майнерам і майнінг-пулам з величезною обчислювальною потужністю не обов’язково ставати виробниками блоків. У маленьких шахтарів також є пружина, якщо вони наполегливо працюють і накопичують певну кількість деревини, вони також можуть виробляти блоки. Ефективність гарантована, кожен бере участь, а найпопулярніший спосіб участі гарантує концепцію децентралізації, що запобігає домінуванню в мережі організаціям з обчислювальною потужністю або власникам великих валют.
**Користувач:**Komodo
Принцип алгоритму: У системі dPoW є два типи вузлів: нотаріальні вузли та звичайні вузли. 64 нотаріальні вузли обираються зацікавленими сторонами блокчейну dPoW для додавання нотаріально засвідчених блоків із блокчейну dPoW до підключеного блокчейну PoW. Після додавання блоку хеш блоку додається до транзакції Bitcoin, підписаної 33 нотаріальними вузлами, і створює запис блоку dPow, хешований у блокчейні Bitcoin. Запис нотаріально засвідчено більшістю нотаріальних вузлів у мережі.
Щоб уникнути воєн майнінгу між нотаріальними вузлами та знизити ефективність мережі, Komodo розробила метод майнінгу з використанням механізму опитування, який має два режими роботи.
У режимі «Без нотаріуса» всі вузли мережі підтримують участь у майнінгу, що схоже на традиційний механізм консенсусу PoW. У режимі «Активні нотаріуси» мережеві нотаріуси здійснюють майнінг, використовуючи значно знижений рівень складності мережі. У режимі «нотаріальної активації» кожному нотаріусу дозволено використовувати свою поточну складність для видобутку блоку, тоді як інші нотаріальні вузли повинні використовувати 10-кратну складність видобутку, а всі звичайні ноди використовують 100-кратну складність нотаріальних вузлів для видобутку.
**Переваги: **Енергозбереження; підвищена безпека; може додати цінність іншим блокчейнам, непрямо надаючи біткойн (або будь-який інший ланцюжок безпеки), не сплачуючи ціну транзакцій біткойна (або будь-якого іншого ланцюга безпеки).
Недоліки: Лише блокчейни, що використовують PoW або PoS, можуть прийняти цей алгоритм консенсусу; у режимі «Активні нотаріуси» швидкість хешування різних вузлів (нотаріусів або звичайних вузлів) має бути відкаліброваною, інакше різниця між швидкістю хешування вибухне. .
8 Авторизований PoS (DPoS, Делегований доказ частки)
Ознайомлення з алгоритмом. Механізм DPoS, також відомий як «Механізм підтвердження авторизації спільного використання» та «Механізм довіреної особи», був запропонований у квітні 2014 року Деном Ларімером (BM), головним розробником Bitshares. З певної точки зору DPOS трохи нагадує парламентську систему чи систему народних зборів. Якщо делегат не виконує своїх обов’язків (не створює блок, коли настає його черга), він видаляється зі списку, і мережа обирає новий супервузол на його заміну.
Для полегшення розуміння можна навести інший приклад. Уявіть собі компанію з 1000 співробітників, кожен з яких володіє різною кількістю акцій компанії. Час від часу співробітники можуть проголосувати за 10 осіб, яких вони найбільше вважають керівниками компанії, і права голосу кожного працівника пропорційні кількості акцій, якими він володіє. Після того, як усі проголосують, 10 осіб, які набрали найбільше голосів, стануть лідерами компанії.
Якщо керівник некомпетентний або робить щось шкідливе для компанії, працівник може відкликати голосування за лідера, щоб його голосування не потрапило в топ-10, тим самим звільнившись з керівництва.
Користувачі: BitShares, Steemit, EOS, Lisk, Ark.
**Переваги: **Енергозбереження; швидкий; високий трафік сайт Steemit використовує його. Час блокування EOS становить 0,5 секунди.
**Недоліки: **Трохи централізовано; учасники з високими ставками можуть голосувати за те, щоб стати валідатором (нещодавно це була проблема в EOS).
9 Practical Byzantine Fault Tolerance (PBFT)
**
**
Ознайомлення з алгоритмом: в алгоритмі PBFT один вузол вважатиметься головним вузлом, а інші вузли — резервними. Усі вузли системи будуть спілкуватися один з одним, і кінцева мета полягає в тому, щоб кожен міг досягти консенсусу за принципом підкорення меншості більшості.
Процес консенсусу:
Клієнт надсилає запит до головного вузла для виконання операції
б) Головний вузол широкомовно передає цей запит кожному резервному вузлу
в. Усі вузли виконують операцію та повертають результат клієнту
г. Коли клієнт отримує f+1 ідентичних результатів від різних вузлів, процес завершується. f представляє максимальне значення можливих лежачих вузлів.
Використовується: HyperLedgerFabric, Stellar, Ripple, Dispatch
**Переваги: ** Висока швидкість, можливість масштабування.
Недоліки: Зазвичай використовується в приватних і дозволених мережах.
10 Делегована візантійська відмовостійкість (dBFTDelegated Byzantine Fault Tolerance, dBFT)
Ознайомлення з алгоритмом: Китайська блокчейн-спільнота NEO (раніше відома як Xiaoyi) запропонувала вдосконалений візантійський відмовостійкий алгоритм dBFT. Цей алгоритм спирається на ідею дизайну PoS на основі PBFT. Бухгалтер, а потім і бухгалтери досягають консенсус через візантійський відмовостійкий алгоритм. Цей алгоритм покращує відсутність остаточної узгодженості PoW і PoS, роблячи блокчейн придатним для фінансових сценаріїв.
Крім того, щоб вирішити проблему візантійських генералів, механізм «авторизованої візантійської відмовостійкості» є консенсусним алгоритмом, який гарантує відмовостійкість, реалізовану всередині блокчейну NEO. У цьому механізмі є два учасники, один – «бухгалтерський вузол» професійної бухгалтерії, а інший – звичайний користувач системи.
Звичайні користувачі голосують, щоб визначити облікові вузли на основі частки їхніх активів. Коли необхідно досягти консенсусу, із цих облікових вузлів випадковим чином вибирається речник для складання плану, а потім інші облікові вузли слідують візантійському відмовостійкому алгоритм.Тобто принцип меншості підкоряється більшості робить заяву.Якщо більше 66% вузлів згодні з планом спікера, досягається консенсус, інакше спікер переобирається і голосування повторюється.
Оскільки всі делегати можуть перевіряти пропозиції щодо блокування, легко зрозуміти, дійсні чи недійсні дані, надіслані доповідачем. Отже, якщо спікер нечесний і надсилає недійсну пропозицію двом третинам делегатів, блоки не збігатимуться, і власники вузлів не перевірятимуть їх. Консенсус досягається двома третинами голосів і обирається новий спікер.
**Користувач:**Neo
Процес консенсусу:
a. Будь-хто може бути представником, якщо він або вона відповідає вимогам. Усі власники токенів NEO можуть голосувати, делегати не є анонімними, і щоб стати власником вузла, потрібно 1000 GAS.
б) Доповідач обирається випадковим чином з числа делегатів.
в) Доповідач створює новий блок із транзакцій, які очікують перевірки. Потім спікер надсилає пропозицію обраним представникам. Вони повинні відстежувати всі транзакції та реєструвати їх у мережі.
г. Делегати можуть ділитися та порівнювати пропозиції, які вони отримали, щоб перевірити точність даних, а також чесність доповідачів. Якщо більше двох третин делегатів досягають консенсусу та підтверджують його, блок додається до блокчейну.
**Переваги: **Швидко (генерація блоку займає 15-20 секунд); велика пропускна здатність транзакцій, відсутність потреби в енергії, масштабованість і відсутність форків.
Недоліки: Немає анонімності, і для того, щоб бути обраним, потрібна справжня особа. Кожен змагається за те, щоб стати корінним ланцюгом. Може бути кілька кореневих ланцюгів.
11. Rotation Practical Byzantine Fault Tolerance (RBPFT)
Ознайомлення з алгоритмом: Принципи dBft і RPBFT подібні до PBFT, за винятком того, що не всі вузли беруть участь у консенсусі, але вузли поділяються на два типи:
a. Консенсусний вузол: вузол, який виконує консенсусний процес PBFT і має право генерувати блоки по черзі.
b. Верифікаційний вузол: не виконувати процес консенсусу, перевірити, чи є консенсусний вузол законним, заблокувати перевірку, після кількох раундів консенсусу він переключиться на консенсусний вузол
У циклічній візантійській відмовостійкості вузли консенсусу по черзі замінюються вузлами перевірки.
**Випадок використання: **Fisco-BCOS
**Переваги: **Швидкість передачі вище, ніж плітки, і немає надлишкових пакетів повідомлень
Розділяй і володарюй, вихідна пропускна здатність кожного вузла дорівнює O(1), сильна масштабованість
Недоліки: Проміжний вузол є єдиною точкою і вимагає додаткових стратегій відмовостійкості
12. AptosBFT
**
**
Ознайомлення з алгоритмом: Це також похідний алгоритм від PBFT. Алгоритм консенсусу, названий на честь Aptos, базується на HotStuff, який базується на PBFT. Переваги цієї моделі алгоритму як цибуля і матрьошка, яку потрібно шар за шаром очищати. Кожен вузол спілкується лише з лідером, а не надсилає повідомлення лідеру та всім іншим «генералам». Лідер транслює повідомлення (пропонований блок) для голосування; кожен вузол надсилає свій голос лідеру, який зібрав повідомлення.
Випадок використання: Aptos
Нарешті, короткий зміст цієї частини додається:
**Крім того, існують незвичайні алгоритми консенсусу. **
У 2015 році професор Девід Мазьєр, головний науковий співробітник Stellar.org, запропонував Stellar Consensus Protocol (SCP). SCP розвинувся на основі Федеральної візантійської угоди та Ripple Agreement і є першим доведено безпечним механізмом консенсусу з чотирма ключові властивості децентралізованого контролю, низької затримки, гнучкої довіри та асимптотичної безпеки.
У тому ж році проект Sawtooth Lake від Hyperledger поєднав консенсус Ripple і SCP і запропонував алгоритм консенсусу голосування кворуму для роботи зі сценаріями додатків, які вимагають миттєвої завершеності транзакції.
У 2016 році лауреат премії Тюрінга та професор Массачусетського технологічного інституту Сівіо Мікалі запропонував швидкий візантійський відмовостійкий алгоритм консенсусу під назвою AlgoRand. Цей алгоритм використовує технологію криптографічної лотереї для вибору верифікатора та лідера процесу консенсусу, а також через розроблений ним BA* The Byzantine Fault Tolerant Protocol досягає консенсусу щодо нових блоків. AlgoRand вимагає дуже мало обчислень і дуже мало розгалужень, і вважається справді демократичною та ефективною технологією консенсусу розподіленої книги.
У 2017 році Корнельський університет запропонував новий алгоритм під назвою Sleepy Consensus (сплячий консенсус).Цей консенсус спрямований на те, що більшість великомасштабних вузлів консенсусу в Інтернет-середовищі можуть бути офлайн, і лише кілька вузлів знаходяться в режимі онлайн Реальність участі в процесі консенсусу. Це дослідження доводить, що традиційний алгоритм консенсусу не може гарантувати безпеку консенсусу в цьому середовищі.Однак, використовуючи неактивний алгоритм консенсусу, доки кількість чесних онлайн-вузлів перевищує кількість несправних вузлів, можна гарантувати безпеку та надійність.
##04 Резюме
Якщо ви вискочите з точки зору розробника та включите більше способів мислення, які поєднують політику та економіку, може виникнути більше консенсусних алгоритмів, таких як поєднання консенсусних методів, подібних до концепції PPP, які можуть не лише досягти характеру покарання за зловмисники сторони, але також може досягти мети економії обчислювальної потужності найбільш ефективно.
Коротше кажучи, механізм консенсусу є ядром технології блокчейн. Він може вирішити проблему довіри в розподіленій системі, забезпечити узгодженість даних і безпеку між вузлами, а також уникнути атак і втручання зловмисних вузлів, таким чином забезпечуючи блокову стабільність і надійність ланцюгової системи. У той же час механізм консенсусу також може вирішити проблему «подвійних витрат» і підвищити пропускну здатність і швидкість обробки системи блокчейн. Але різноманітні алгоритми консенсусу не є абсолютно безпечними, ефективними та децентралізованими.
Немає найкращого алгоритму, є лише алгоритм, який вам найбільше підходить. Вибір алгоритму консенсусу сильно залежить від сценарію застосування. Довірені середовища використовують Paxos або RAFT, дозволені альянси можуть використовувати PBFT, а неавторизовані ланцюги можуть використовувати PoW, PoS, консенсус Ripple тощо. **Найкращий механізм консенсусу завжди той, який відповідає потребам користувача. **