Еволюція Kadena, першого справжнього приватного блокчейна

Джордж Самман — консультант і радник із блокчейну та Криптовалюта , який нещодавно разом із KPMG написав фундаментальний звіт про архітектуру блокчейну.

Тут Самман пояснює, як алгоритм консенсусу, досягнутий Raft, був остаточно виправлений його далеким родичем Kadena.

Ця стаття охоплює блокчейн Kadena. Він використовує ScalableBFT, щоб запропонувати високу продуктивність (8 000-12 000 транзакцій на секунду) із повною реплікацією та розповсюдженням у раніше неможливих масштабах (ємність для понад 500 вузлів-учасників).

Це разом із багаторівневою моделлю безпеки та поступовим хешуванням забезпечує справді надійний блокчейн. Заснований на Raft і Juno, Kadena вбудовує повну мову розумних контрактів (Pact) у свій блокчейн, який можна запускати як публічні (звичайний текст) або приватні (зашифровані подвійним храповим механізмом) транзакції.

Це величезний крок вперед у просторі блокчейну, який, можливо, повністю представляє нове покоління Технології блокчейну завдяки введенню ідеї «повсюдного детермінізму».

Подібно до Bitcoin, блокчейн Kadena тісно інтегрований, і для розуміння того, на що він здатний і що ці можливості означають, потрібно охопити значну частину землі. Таким чином, я розбив статтю на три частини: 1) Вступ і Пліт, 2) Попередники Кадени – Тангароа & Юнона3) Блокчейн Kadena – ScalableBFT, Pact і Pervasive Determinism.

Частина 1: Вступ і алгоритм консенсусу Рафту

Історія Kadena — це цікаве прикладне дослідження в новій галузі консенсусних алгоритмів блокчейну та розподілених обчислень.

Kadena є «далеким родичем» Алгоритм рафтового консенсусу. Був використаний механізм консенсусу Raft Тангароа (Візантійський пліт, стійкий до відмов (BFT)) і проект JP Morgan Юнона (вилка Tangaroa), жоден з яких більше не знаходиться в активному розвитку.

Новий блокчейн Кворум JP Morgan

сильно відрізняється від Juno та використовує злиття ідей із бічних ланцюгів та Ethereum – публічні смарт-контракти дозволені в блокчейні на додаток до приватних контрактів, які представлені у вигляді зашифрованих хешів і відтворені через бічні канали.

Kadena — це «Juno наступного покоління». Він використовує новий, але пов’язаний протокол під назвою ScalableBFT, який був створений із відкритого вихідного коду проекту Juno і створений двома ключовими розробниками, які створили Juno. Перш ніж заглибитися в Kadena, необхідно обговорити коротку історію та опис Raft і попередників Kadena .

Пліт консенсус

Алгоритм консенсусу Raft — це єдина система на основі лідера для керування реплікованим журналом. Він використовує відтворену архітектуру кінцевого автомата та дає результат, еквівалентний Paxos, але структурно відрізняється.

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

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

Якщо послідовник не отримує повідомлення протягом цього періоду часу, він стає кандидатом і ініціює вибори. Кандидат, який отримує голоси від більшості повного кластеру (вузлів у мережі), стає новим лідером. Лідери зазвичай діють, поки не зазнають невдачі. Серцебиття надсилається, щоб переконатися, що лідер все ще там; якщо нічого не отримано, відбуваються нові вибори.

Рафт досягає консенсусу на наступних етапах:

• Кластер серверів вузлів Raft запускається з кожним вузлом, що запускається як «послідовник». Згодом ONE вузол закінчиться, стане кандидатом, набере більшість голосів і стане лідером.
• Кожен вузол зберігає журнал, що містить команди. Робота Лідера полягає в тому, щоб приймати нові команди, чітко впорядковувати команди у своєму журналі, копіювати свій журнал своїм послідовникам і, нарешті, інформувати послідовників, коли фіксувати журнали, які вони відтворили. Таким чином, алгоритм консенсусу забезпечує однаковий порядок журналів кожного сервера.
• Журнали є «зафіксованими», коли вони були репліковані на більшість вузлів. Лідер збирає кількість реплікацій і, коли буде видно більшість, фіксує власні нові записи в журналі та інформує своїх послідовників зробити те саме.
• Після «фіксації» команда в кожному записі журналу оцінюється кінцевим автоматом. Оскільки Raft байдужий до тіла команди, будь-який кінцевий автомат може обробити зафіксовані записи. Крім того, консенсус гарантує, що виконання команд завжди відбувається в тому самому порядку, що й команди надходять із Журналу, який строго впорядкований.
• Кінцеві автомати залишатимуться послідовними, доки виконання команд є детермінованим.
• Коли клієнт надсилає команду на ONE із серверів, цей сервер або пересилає команду лідеру, або є лідером. Лідер збирає нову команду, призначає їй індекс журналу, інкапсулює її в запис журналу та додає команду до незафіксованої частини свого журналу.
• Щоразу, коли лідер має незафіксовані записи, він копіює цю частину журналу своїм послідовникам. Коли лідер отримує інформацію про успішну реплікацію більшістю кластера, він фіксує нові записи та наказує своїм послідовникам зробити те саме.
• Кожного разу, коли фіксується новий запис журналу, консенсус щодо цього запису досягається. Потім він оцінюється кінцевим автоматом на кожному сервері.
• З цього моменту Raft закінчено, і розробники можуть вирішити, як обробляти відповіді; відповідь клієнту або очікування, поки клієнт запитає результат.

Відповіді клієнту, як правило, асинхронні.

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

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

Частина 2: Попередники Кадени – Тангароа та Юнона

Тангароа: перший крок до плоту BFT

Tangaroa — це візантійський відмовостійкий (BFT) варіант консенсусного алгоритму Raft, натхненний оригінальним алгоритмом Raft і алгоритмом Practical Byzantine Fault Tolerance (PBFT).

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

У стандартному Raft вам потрібно скопіювати запис журналу на більшість вузлів у кластері перед його фіксацією. Для консенсусних алгоритмів BFT, включно з Tangaroa, необхідний розмір кластера становить принаймні 2f + 1, де f — кількість відмов, які ви бажаєте терпіти (включно з вузлами, які вийшли з ладу, і з скомпрометованими вузлами). Консенсус досягається більшістю голосів кластера; якщо f <= 3, тоді розмір кластера = 7, а невізантійські вузли = 4. Деякі протоколи BFT можуть навіть вимагати 3f+1.

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

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

Вибори лідера та етапи

Tangaroa використовує Raft як основу для консенсусу; таким чином є єдиний лідер. У Tangaroa, як і в Raft, кожен вузол знаходиться в ONE з трьох станів: лідер, послідовник або кандидат.

Подібно до Raft, кожен вузол починається як послідовник, ONE з яких з часом закінчиться та викличе вибори. Переможець виборів залишається лідером до кінця терміну; терміни закінчуються, коли обирається новий лідер. Іноді вибори призводять до розділення голосів, і термін закінчується без лідера. У цьому випадку підписник знову встановлює тайм-аут (тайм-аути скидаються під час голосування або оголошення виборів) і знову починає процес голосування.

Щоб почати вибори, підписник збільшує свій поточний термін і надсилає RequestVote (RV) Віддалений виклик процедур (RPC) паралельно кожному з інших вузлів у кластері, запитуючи їхній голос. RPC, які використовує Tangaroa, подібні до RPC Raft, за винятком того, що кожен RPC підписується та перевіряється за допомогою підписів PPK.

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

Коли вузол Tangaroa отримує RV RPC із дійсним підписом, він негайно надає право голосу, лише якщо він наразі не має лідера (відбувається лише під час запуску). В іншому випадку починається процес, який Тангароа називає «Лінивим голосуванням».

Мета LazyVote полягає в тому, щоб захистити невізантійських послідовників від обрання нового лідера, якщо лідер не є помилковим; без ледачого голосування візантійський вузол міг би в будь-який час ініціювати повторні вибори та знищити систему. Коли підписник отримує новий RV, він зберігає RV і чекає виконання всіх наступних умов:

a) Тайм-аут виборів послідовника викликає пожежі до того, як він обробляє серцебиття свого поточного лідера. Якщо отримано серцебиття, LazyVote очищається.

b) Новий термін RV довший за поточний.

c) Відправник Request є прийнятним кандидатом (дійсний підпис PPK і клієнт T забанив вузол).

d) Вузол, який отримує RV, не проголосував за іншого лідера на запропонований термін.

e) Кандидат ділиться префіксом журналу з вузлом, який містить усі зафіксовані записи. Вузол завжди відхиляє Request , якщо він все ще отримує серцеві повідомлення від поточного лідера, і ігнорує RPC RequestVote, якщо запропонований термін уже почався.

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

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

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

а) Перемагає на виборах, отримавши більшість голосів від кластера. Кандидат повинен зберегти ці голоси – RPC RequestVoteResponse (RVR) – для подальшого розповсюдження.

b) Інший вузол стає лідером

c) Минає певний період часу без переможця (тобто: відбувається ще один тайм-аут виборів)

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

Управління

Як і Рафт, Тангароа використовує випадкові тайм-аути, щоб ініціювати вибори лідера. Лідер кожного терміну періодично надсилає повідомлення (порожні AE RPC), щоб підтримувати свій авторитет. Якщо послідовник не отримує повідомлення від лідера протягом випадково вибраного періоду часу, тайм-ауту виборів, тоді він стає кандидатом і ініціює нові вибори.

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

Дані отримано

Дані (нові команди) надходять від клієнтів кластера Raft, які надсилають запити лідеру. Лідер копіює ці запити в кластер і відповідає клієнту, коли в кластері досягається кворум на цей Request.

Те, що є «Request», залежить від системи. Спосіб зберігання даних залежить від системи. Важливо, щоб стан зберігався на диску, щоб вузли могли відновити та запам’ятати інформацію, яку вони передали (за які вузли вони проголосували, які записи журналу вони додали ETC). Без цього протокол працювати не буде.

Tangaroa додає BFT до еволюції Raft

Юнона

Проект JP Morgan Juno є розгалуженням Tangoroa і був доказом концепції, завдяки якій вдалося масштабувати Tangaroa до 50 вузлів і збільшити швидкість транзакцій до 5000 транзакцій на секунду.

Команда JPM, що стоїть за Juno, побачила потенціал, який представляє підхід, подібний до Tangaroa, – високопродуктивний приватний блокчейн. Вони повторювали цю ідею протягом року та відкрили вихідний код проекту в лютому 2016 року. Вони додали мову смарт-контракту, виправили деякі помилки в дизайні та досягли 10-кратного підвищення продуктивності, що дозволило кількість вузлів, які голосували за зміну під час роботи системи. Juno дозволяла додавати та видаляти вузли та була розподіленою системою з дозволами, у якій були відомі всі вузли в мережі.

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

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

Частина 3: Блокчейн Kadena – ScalableBFT, Pact і Pervasive Determinism

Криптографія

На відміну від Raft, кожна репліка в системі BFT Raft (сімейство алгоритмів, що включає Tangaroa, Juno та Kadean’s ScalableBFT) обчислює криптографічний хеш щоразу, коли додає новий запис до журналу. Хеш обчислюється на основі попереднього хешу та щойно доданого запису журналу.

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

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

BFT Rafts широко використовує цифрові підписи для автентифікації повідомлень і перевірки їх цілісності. Це запобігає візантійському лідеру від зміни вмісту повідомлення або підробки повідомлень і захищає кластер загалом від великої кількості візантійських атак.

Консенсус

У Raft лідера обирають за допомогою випадкових тайм-аутів, які спонукають послідовника запропонувати себе як кандидата та Request голоси. ScalableBFT також робить це, але криптографічно захищеним способом. Наприклад, якщо Лідер стає недоступним, тайм-аут ініціює нові вибори, але процес виборів стійкий проти візантійських вузлів, які оголошують вибори. ScalableBFT вирішує проблеми, з якими зіткнулися Юнона та Тангароа щодо ледачого голосування.

Єдиними унікальними можливостями лідера є: 1) упорядкування нових транзакцій перед реплікацією та 2) реплікація нових транзакцій на вузли послідовника. З цього моменту всі вузли незалежно підтверджують дійсність консенсусу та цілісність окремої транзакції.

Вилучення анонімної участі є вимогою до дизайну приватних блокчейнів, і це дозволило використовувати високопродуктивний механізм BFT Consensus для заміни майнінгу. Основним доповненням ScalableBFT до сімейства BFT Rafts є можливість масштабування до 1000 вузлів без зниження пропускної здатності системи.

Кожна транзакція реплікується на кожен вузол. Коли більшість вузлів реплікують транзакцію, транзакція фіксується. Вузли збирають і поширюють інформацію (додатковий хеш) про те, що вони скопіювали, і використовують цю інформацію, щоб самостійно вирішувати, коли фіксувати (>50% інших вузлів надсилають їм додаткові хеші для незафіксованих транзакцій, з якими вони погоджуються).

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

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

Нарешті, крім того, що лідер реплікує нові транзакції на кожен вузол, вузли є більш-менш незалежними. Замість «синхронізації» вони транслюють кластеру «Я здійснив реплікацію до індексу журналу N, і він має інкрементальний хеш H» і збирають цю інформацію з інших вузлів – на основі результатів з інших вузлів кожен вузол може самостійно вирішити, чи кластер реплікувався після планки, необхідної для фіксації (більшість реплікації для деяких станом на ще незафіксований індекс журналу N).

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

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

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

Kadena використовує детермінований консенсус

Механізм консенсусу є детермінованим, якщо процес консенсусу повністю визначений у протоколі, і цей процес не використовує випадковість. Як було сказано вище, наприклад, Raft використовує рандомізовані тайм-аути, щоб ініціювати вибори, коли лідер падає (оскільки лідер T може повідомити «Я збираюся впасти», є тайм-аут, який спонукає вузол перевірити, чи лідер не працює), але вибори T є частиною консенсусу на рівні транзакцій, це натомість засіб пошуку вузла для оркестрування консенсусу.

ScalableBFT є детермінованим і посиленим таким чином, що:

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

Kadena спеціально розроблена для дозволених мереж, і тому передбачає, що певні атаки (наприклад, DoS) малоймовірні та знаходяться поза її контролем. Якби ONE сталося, система або заблокувалася б (кінець кінцем вичерпався час очікування всіх вузлів, але вибори ніколи не відбулися б), або простоїла б.

Щойно така подія завершиться, вузли повернуться до консенсусу, і все повернеться до нормального стану. Однак у дозволеній мережі адміністратори матимуть повний контроль і припинять з’єднання, яке спричиняє проблему.

Вибори лідера дуже схожі на Raft, оскільки будь-який вузол може бути обраний лідером, кожен вузол отримує ONE голос за термін, і вибори скликаються, коли спрацьовує випадковий тайм-аут ONE з вузлів (таймер скидається щоразу, коли вузол отримує повідомлення від лідера).

Найбільша різниця полягає в тому, що в Raft вузол, який отримує достатню кількість голосів, бере на себе лідерство, тоді як у ScalableBFT вузол, який отримує більшість голосів, розподіляє ці голоси між усіма іншими вузлами, щоб продемонструвати (у спосіб BFT), що він був обраний лідером у кластері.

Механізм ScalableBFT виправляє проблеми, які спостерігаються в Juno та Tangaroa, як-от «кандидат-втік», коли час очікування невізантійського вузла минув через мережевий розділ, але через те, що його термін було збільшено, він T може повернутися до консенсусу, і натомість продовжує тайм-аут, а потім збільшує свій термін («Runaway».)

Рафтовий консенсус гарантує суворе впорядкування та тиражування повідомлень; T має значення, що міститься в кожному повідомленні, і може варіюватися від випадкових чисел до зашифрованого тексту чи простих текстових смарт-контрактів. Kadena використовує рівень журналу як службу обміну повідомленнями під час роботи в зашифрованому контексті; подібно до того, як Signal може запускати шифрування протоколу Noise через SMS. ScalableBFT запускає Noise через блокчейн.

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

Модель безпеки/повсюдний детермінізм

Kadena використовує термін «всеохоплюючий детермінізм», щоб описати «ідею блокчейну, який використовує криптографію на основі PPK-Sig для гарантій авторства (наприклад, Bitcoin) і складається з повністю детермінованого консенсусного рівня на додаток до незавершеного Тьюринга рівня смарт-контракту з одним призначенням.

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

Візьмемо як приклад транзакцію, яка завантажує новий модуль смарт-контракту під назвою «кредити». Скажімо, «кредити» імпортує інший модуль під назвою «платежі», який уже присутній у ланцюжку. Успішний імпорт лише «платежів» означає наступне (кожен повністю перевіряється за допомогою криптографічних засобів):

• Хто підписав транзакцію, яка завантажила «платежі»
• Які консенсусні вузли були в кластері на момент завантаження
• Які вузли консенсусу погодилися, що транзакція була дійсною
• Які ноди проголосували за поточного лідера на момент завантаження
• Хто був лідером
• Хто був попереднім керівником
• ETC

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

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

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

Я запитав Уілла Мартіно (співзасновника Kadena) про те, як це працює для кожного шару:

Яка ваша модель безпеки на рівні консенсусу?

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

Ми використовуємо хеші blake2 і номер терміна для визначення унікальності, дозволяючи клієнтам системи не хвилюватися про випадкове надсилання дублікатів або повторне надсилання команд шкідливим вузлом/людиною посередині (MITM). Ми використовуємо постійну безпеку, підхід на основі PPK-sig до перевірки авторства (або будь-який тип підходу, який можна зберегти на диску), який дуже схожий на те, як Bitcoin перевіряє транзакції, але на рівні консенсусу (на додаток до рівня транзакції).

Це протиставляється ефемерній безпеці, яка використовує захищені канали (TLS) для підтвердження авторства – значно гірший підхід, коли питання «хто надіслав транзакцію X?» відповідає не через PPK-криптографію, а через запит на рівні консенсусу, оскільки будь-який окремий вузол не здатний надати відповідь BFT.

Яка ваша модель безпеки на рівні транзакцій?

Ідеї ​​ефемерної та постійної безпеки охоплюють як консенсус, так і рівень транзакцій, оскільки саме консенсус передає окремі транзакції рівню виконання смарт-контракту. На рівні смарт-контракту/транзакції ми також використовуємо постійний захист, підтримуючи авторизацію відкритих ключів на рівні рядків у Pact.

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

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

Якщо те саме TLS-з’єднання використовується для подання транзакцій як генерального директора, так і секретаря, тоді логіка авторства та авторизації є моделлю «тому що я так сказав/довіряй мені» проти підходу PPK-sig, де ви перевіряєте відповідний ключ перед виконанням. Блокчейн Kadena розроблений, щоб довіряти якомога менше; якби ми знали про більш параноїдальний або тонкий підхід, ніж підписи PPK на рівні рядків, ми б використали його.

Яка ваша модель конфіденційної транзакції?

Ми використовуємо протокол Double-Ratchet (те, що використовують Signal, WhatsApp ETC для зашифрованих комунікацій), вбудований у блокчейн (зашифровані тіла транзакцій) для випадків використання для збереження Політика конфіденційності багатьох сторін. Ми працюємо з поняттям роз’єднаних баз даних через примітив «pact» у Pact – вони описують багатофазний робочий процес фіксації над роз’єднаними базами даних через зашифровані повідомлення.

Розумні контракти

Pact — це повноцінна мова смарт-контрактів, інтерпретатор якої побудовано на Haskell. У Kadena кожна транзакція є розумним контрактом, а мова розумного контракту Pact є відкритим. Pact орієнтований на базу даних, транзакційний, неповний за Тьюрингом, має одноразове призначення (змінні не можуть бути змінені протягом їхнього життя), і тому дуже піддається статичній перевірці.

Pact також інтерпретується – код, який ви пишете, виконується в ланцюжку, тоді як Solidity компілюється, що ускладнює перевірку коду, а також неможливо виправити проблеми безпеки в старих мовних версіях після компіляції. Pact постачається з власним інтерпретатором, але може працювати в будь-якому блокчейні з детермінованим введенням і може підтримувати різні серверні модулі, включаючи комерційну RDBMS. У блокчейні ScalableBFT він працює з швидким рівнем зберігання SQLite.

Блокчейн Kadena містить усі ці функції:

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

Ця стаття була раніше опублікована на Блог Sammantics і було відтворено тут з дозволу. Деякі зміни внесено для стилю та стислості.

Зображення гвинтиків через Shutterstock