Чи може DFINITY, яка спеціалізується на базових технологіях, уявити Web3 по-справжньому?

Рекомендуємо: Ринок є бичачим і ведмежим і стикається з ситуацією в Україні, натисніть тут, щоб приєднатися до групи PANews для розігріву

Оригінальна назва: Інтерпретація нової офіційної книги DFINITY, публічного ланцюжка потенційних акцій Що лежить в основі технології в епоху підключення Web 3.0?

Автор: TinTinLand

1

Свинець

На початку лютого 2022 року Dmail, перша приватна електронна пошта, розроблена DApp на основі екосистеми DFINITY, отримала стратегічні інвестиції від Amino Capital. Повідомляється, що Dmail може відправляти електронні листи в традиційні поштові скриньки і з них, і в порівнянні з традиційними поштовими скриньками, Dmail з атрибутами блокчейна також може реалізовувати зашифровану передачу інформації та NFT імен поштових скриньок. Це підготовка комунікаційного програмного забезпечення в епоху Web 3.0, яке служить входом на децентралізовані веб-сайти та DApps у вигляді «цифрової ідентичності». Питання, яке я хочу поставити, чому Dmail вибрав Dfinity?

У порівнянні з публічними ланцюжками блокчейну, Dfinity з’являвся небагато разів. Коли була маленька іскра, не було DeFi-вогню, і не було місця в перший рік існування «NFT». Однак з моменту його запуску такі люди, як Dmail, нерідко отримують уявлення про те, як виглядатиме конкретна реалізація Web 3.0.

У липні 2020 року DFINITY випустила версію соціального програмного забезпечення для коротких відео з відкритим вихідним кодом «CanCan», яку ми можемо просто порівняти з Douyin of Web 2.0. CanCan заснований на мові програмування DFINITY, Motoko, і має менше 1 000 рядків коду. Це можна назвати дивовижним у порівнянні з десятками мільйонів рядків коду на Douyin та Facebook. При цьому код CanCan має відкритий вихідний код, а право власності на продукт не належить жодному централізованому органу. 1 жовтня того ж року DFINITY представила свою систему управління та економічну модель токенів, а оцінка проєкту колись досягла $9,5 млрд, увійшовши до п’ятірки найкращих. В кінці грудня того ж року була завершена етапна еволюція п’яти мереж від міді до ртуті. Домінік Вільямс, засновник і головний науковий співробітник DFINITY Foundation, заявив на форумі та церемонії нагородження FAT Value Era Summit 2020, що інтернет-комп’ютер є третьою великою інновацією блокчейну.

У цій статті буде інтерпретовано оригінальний текст офіційної книги DFINITY, починаючи з найнижчої логіки офіційного пояснення, щоб побачити, як DFINITY може почати з технологій, зламати великі технології Інтернету та дозволити різному програмному забезпеченню Web2.0 використовувати автономне програмне забезпечення та децентралізоване управління для досягнення синергії бізнесу з відкритим вихідним кодом, щоб по-справжньому реалізувати Web3.0; Читачі, які не мають досвіду роботи в індустрії блокчейну, можуть мати поріг читання під час читання цієї статті, але вони також можуть прокоментувати запитання, які виникнуть нижче, і вони можуть отримати несподівані відповіді.

2

Схема

Протягом всієї історії та поточного процесу блокчейну BTC приніс еру децентралізованих грошей, ETH представляє сферу операційних систем, Filecoin представляє сховище, а DFINITY представляє інновації в галузі обчислень та впровадження Web 3.0. Internet Computer (далі - IC) - це основна мережа, це протокол рівня 1, спрямований на розвиток децентралізованої загальнодоступної мережі, DFINITY - це відкритий віртуальний блокчейн-комп’ютер і технологія, що розширює екосистему Ethereum до широкого спектру сценаріїв бізнес-додатків. У цій статті ми будемо використовувати офіційний термін «Internet Computer» в офіційному документі для позначення ланцюжка «DFINITY», який зазвичай використовується в поточному сценарії спілкування. Цей розділ в основному пояснює технічні терміни, пов’язані з деякими мікросхемами, а також відмінності в технології та реалізації в порівнянні з іншими публічними ланцюгами, або яскраві точки в технології та функціях. Можна сказати, що IC – це нова спроба поєднання масштабованості, децентралізації та безпеки.

2.1 Протокол консенсусу

Розглядаючи IC та кілька інших великих публічних ланцюгів з точки зору протоколів консенсусу, IC використовує гібридну модель, керовану DAO, мережу, яка забезпечує багато переваг децентралізованого протоколу PoS, маючи при цьому ефективність дозволеного протоколу. Протоколи консенсусу Bitcoin, Ethereum і Algorand засновані на блокчейні з використанням Proof of Work (PoW) або Proof of Stake (POS). Хоча ці протоколи повністю децентралізовані, вони менш ефективні, ніж протоколи з дозволом.

DAO працюють за дозволеним протоколом консенсусу для кожної підмережі, і DAO вирішує, які організації можуть надавати копії вузлів, налаштовує мережу, надає інфраструктуру відкритих ключів і контролює версію протоколу, в якій розгортаються копії вузлів. DAO IC називається мережевою нервовою системою (NNS) і базується на протоколі Pos, тобто всі відповідні рішення приймаються членами спільноти, а право голосу членів спільноти визначається кількістю нативних токенів управління IC (ICP), які вони ставлять у NNS. Цей механізм управління на основі PoS дозволяє створювати нові підмережі та додавати або видаляти репліки вузлів з існуючих, а також розгортати оновлення програмного забезпечення та вносити інші корективи в мікросхему.

З цієї точки зору ми також можемо зрозуміти, чому DFINITY називає IC мережею реплікованих автоматів, тому що NNS сама по собі є реплікованою машиною станів. Як і інші державні машини, вони працюють у певній підмережі, і їхнє членство визначається тією самою системою управління на основі PoS, згаданою вище. При цьому підтримується база даних, звана реєстром, в якій фіксується, які репліки вузлів до якої підмережі належать, публічні ключі реплік вузлів і так далі. Таким чином, керуюча мережа DAO служить децентралізованим протоколом консенсусу, дозволяючи ІС отримати ефективний консенсус, але в той же час, завдяки механізму роботи DAO, ІС також зберігає існуючі переваги децентралізації.

Протокол консенсусу IC також використовує криптографію з відкритим ключем, таку як реєстр, який підтримується NNS, щоб прив’язати відкритий ключ до репліки та підмережі вузла, щоб сформувати єдине ціле, що називається криптографією з ланцюговим ключем, і IC також передбачає модель зв’язку для протоколу консенсусу та протоколу, який виконує машину стану реплікації: вона сподівається прийняти більш здійсненну та надійну асинхронну модель (для будь-якого надісланого повідомлення супротивник може затримати доставку будь-якого повідомлення на довільний час, тому немає обмежень у часі для доставки повідомлення), щоб впоратися з візантійськими невдачами. Однак в даний час не існує відомої консенсусної моделі, яка дійсно можлива в рамках асинхронної моделі, і в наступній інтерпретації архітектури ІС в цій статті буде більш детально пояснено технічний підхід до ІС для цієї реальної ситуації.

2.2 Криптографія ланцюгового ключа

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

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

Як бачимо, існує безліч інших застосувань цих порогових сигнатур в ІС. Його слід використовувати, щоб зробити кожну копію вузла в підмережі доступною для непередбачуваних псевдовипадкових цифр (похідних від таких порогових сигнатур). Це основа для випадкових маяків, які використовуються шаром консенсусу, і випадкових стрічок, що використовуються виконавчим шаром.

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

2.3 ICP

ІЦП має такі особливості:

Стейкінг NNS, тобто полегшення управління мережею.

ICP можна використовувати для стейкінгу в NNS, щоб отримати право голосу і, таким чином, брати участь у DAO, яка контролює мережу IC. Користувачі, які здійснюють стейкінг токенів у NNS та беруть участь в управлінні NNS, також отримують новостворені токени ICP як винагороду за голосування. Кількість винагород визначається політикою, встановленою та застосовною NNS.

Redeem Cycles, тобто як виробнича потужність.

ІЦП використовується для оплати користування ІС. Точніше, ICP може бути викуплений за цикли (тобто спалені), які можуть бути використані для оплати ресурсів (сховища, процесора та пропускної здатності), що використовуються для створення резервуарів та резервуарів. Відношення ВЧТ до циклу визначається ННС.

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

ICP використовується для оплати постачальникам вузлів – суб’єктам, які володіють і керують обчислювальними вузлами для розміщення копій вузлів, що входять до складу мікросхеми. NNS регулярно (наразі щомісяця) визначає новостворений ICP, який повинен отримати кожен постачальник вузлів, і передає його на свій рахунок. Відповідно до політики, встановленої та запровадженої NNS, оплата ICP ґрунтується на тому, що постачальник вузлів надає надійні послуги IC.

2.4 Виконання NNS

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

IC забезпечує середовище виконання для виконання програм Wasm всередині танка та зв’язку (за допомогою обміну повідомленнями) з іншими танками та зовнішніми користувачами. У той час як в принципі можна написати танкову програму на будь-якій мові, яка компілюється в Wasm, вищезгадана мова під назвою Motoko дуже узгоджується з семантикою операцій IC і може використовуватися в мікросхемах.

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

На додаток до Motoko, IC надає мову визначення інтерфейсу повідомлень і формат даних під назвою Candid, який використовується для мови фіксованого типу, мови високого рівня та міжмовної сумісності. Це дозволяє будь-яким двом танкам, навіть якщо вони написані різними мовами високого рівня, легко спілкуватися один з одним. Для того, щоб забезпечити повну підтримку розробки танків для будь-якої заданої мови програмування, на додаток до компілятора Wasm для цієї мови повинна бути надана спеціальна підтримка середовища виконання. В даний час, крім Motoko, IC також повністю підтримує розробку танків на мові програмування Rust.

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

2.5 Рішення NNS

У мережі блокчейн DFINITY BNS (Blockchain Neur System) - це система управління, на якій працює мережа, і це один з найважливіших будівельних блоків в мережі блокчейн, який може автоматично входити в систему і мати високий авторитет. Він бере на себе роль супервузла. Будь-яка людина бере участь в управлінні ННС, здійснюючи стейкінг ICP в так званих нейронах. Власники нейронів можуть пропонувати та голосувати за те, як слід змінити мікросхему, наприклад, топологію підмережі або протокол. Право голосу нейронів ґрунтується на PoS. Інтуїтивно кажучи, чим більше ICP ставиться, тим більше нейронних прав голосу. Однак право голосу також залежить від інших характеристик нейронів, наприклад, власники нейронів, які готові робити ставки на свої токени протягом більш тривалого періоду часу, отримують більшу право голосу.

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

Говорячи більш простою мовою, процес управління BNS поділяється на чотири фази: створення нейронів, пропозиція, голосування та виконання.

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

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

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

Реалізація: Тільки зараз є інтерпретація консенсусу ІС виконавчого рівня, яка конкретна реалізація впровадження системи управління BNS? ПРОПОЗИЦІЯ ПАСИВНОГО ВИКОНАННЯ В ОСНОВНОМУ ВКЛЮЧАЄ ЗМІНУ ПАРАМЕТРІВ СМАРТ-КОНТРАКТІВ НА DFINITY, ТАКИХ ЯК ПАРАМЕТРИ СТЕЙКІНГУ НЕЙРОНІВ. Оновлені параметри пропозиції будуть пасивно записані в базу даних смарт-контрактів BNS і вступлять в силу безпосередньо при їх подальшому виконанні. Існує особливий випадок, коли пропозиція знаходиться поза контролем смарт-контракту BNS, наприклад, пов’язана з регуляторним рівнем BNS, який вимагатиме активного правозастосування людини, щоб перевизначити частину DFINITY «код є закон». Наприклад, модифікація вразливостей у системному коді або заморожування смарт-контрактів чи нейронів, які порушують правила BNS. Активний процес виконання реалізується шляхом виклику спеціальних кодів операцій, доданих до EVM. Операція цього кроку є більш гуманною та розумною, ніж нинішні «код є закон» та «код – це все» у нинішньому світі блокчейну. З точки зору людської природи, охоплення сценаріїв, коли код не може приймати рішення, може забезпечити більш ефективне та розумне управління, і певною мірою це також справді торкається основної мети «консенсусу».

3

Інтерпретація архітектури

Протокол IC складається з чотирьох рівнів (як показано на малюнку нижче), а саме рівня P2P, рівня консенсусу, рівня маршрутизації та рівня виконання. У цій частині ця стаття лише інтерпретує ролі та функції чотирирівневої архітектури, а також аналізує побудову загальної архітектури. ДЛЯ БІЛЬШ ДЕТАЛЬНОГО РОЗУМІННЯ СПЕЦИФІКИ ТЕХНІЧНОЇ РЕАЛІЗАЦІЇ КОНКРЕТНОГО ШАРУ, БУДЬ ЛАСКА, ЗВЕРНІТЬСЯ ДО ОРИГІНАЛЬНОГО ОФІЦІЙНОГО ДОКУМЕНТА DFINITY.

3.1 P2P-шар

Рівень P2P служить рівнем в рівні протоколу комп’ютера Інтернет для отримання і впорядкування повідомлень, і його завдання полягає в доставці повідомлень протоколу в копії вузлів підмережі.

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

Ми можемо зрозуміти, що рівень P2P в основному забезпечує канал трансляції «найкращих зусиль», тобто якщо чесна копія ноди транслює повідомлення, повідомлення в кінцевому підсумку буде прийнято всіма міськими вузлами підмережі.

P2P-рівень розроблений з наступними цілями:

Обмежені ресурси. Всі алгоритми працюють з обмеженими ресурсами (пам’ять, пропускна здатність, процесор).

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

Висока ефективність. Висока пропускна здатність важливіша за низьку затримку. ВИСОКА ПРОПУСКНА ЗДАТНІСТЬ ТАКОЖ Є ПРИЧИНОЮ ТОГО, ЩО DFINITY ЕФЕКТИВНІШИЙ ЗНИЗУ, НІЖ ІНШІ ПУБЛІЧНІ МЕРЕЖІ.

Захист від DOS/СПАМУ. Вузли, що вийшли з ладу, не вплинуть на зв’язок між чесними репліками вузлів.

3.2 Рівень консенсусу

3.2.1 Огляд рівня консенсусу

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

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

Активний: Усі репліки вузлів повинні оновлювати свій статус одна за одною.

Мета проектування рівня консенсусу IC насправді проста для розуміння: коли є окремі шкідливі вузли, продуктивність буде гнучко знижуватися. Як і багато інших протоколів консенсусу, протокол консенсусу IC заснований на блокчейні. У міру просування протоколу дерево блоків з блоком генезису як кореневим вузлом продовжуватиме зростати. Кожен блок, що не є генезисом, містить корисне навантаження, яке складається з ряду входів і хешу батьківського блоку.

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

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

3.2.2 Припущення

Як обговорювалося в частині II, ІС висуває наступну гіпотезу:

Підмережа містить n копій вузлів і максимум f

Репліки вузлів, що вийшли з ладу, можуть демонструвати довільну, зловмисну (тобто візантійську невдачу) поведінку. Ми припускаємо, що зв’язок є асинхронним і що немає попереднього обмеження на затримку повідомлень між репліками вузлів, тобто асинхронна модель, згадана вище. На цьому етапі планування обміну повідомленнями може бути абсолютно ворожим. Згідно з цим слабким припущенням зв’язку, протокол консенсусу IC може забезпечити безпеку. Але для забезпечення активності нам потрібно припустити певну форму часткової синхронізації, що означає, що мережа залишається періодично синхронізованою через короткі проміжки часу. При такому інтервалі синхронізації вся неподана інформація буде подана протягом часу, тобто фіксованого терміну δ. Часовий ліміт δ заздалегідь невідомий (протокол ініціалізує обґрунтоване граничне значення, але динамічно коригує значення та збільшує граничне значення, коли ліміт часу занадто малий). Незалежно від того, чи є мережа асинхронною або частково синхронною, ми припускаємо, що повідомлення, надіслані чесною реплікою вузла іншій репліці вузла, зрештою будуть доставлені.

3.2.3 Огляд протоколу

Як і багато інших протоколів консенсусу, протокол консенсусу IC заснований на блокчейні. У міру просування протоколу, блокові дерева (див., наприклад, 3.2.4) з блоком генезису, оскільки кореневий вузол буде продовжувати зростати. Кожен блок, що не є генезисом, містить корисне навантаження, яке складається з ряду входів і хешу батьківського блоку. Чесні репліки мають послідовний вигляд дерева фрагментів: хоча кожна репліка може мати різний локальний вигляд дерева фрагментів, усі репліки вузла бачать одне й те саме дерево фрагментів. Крім того, у міру просування протоколу в дереві блоків завжди буде шлях для завершення блоку. Аналогічно, чесні репліки вузлів мають послідовне представлення цього шляху, і хоча кожна репліка вузла може мати різне локальне представлення шляху, всі репліки вузлів бачать один і той же шлях. Вхідні дані в навантаженнях блоків по цьому шляху були відсортовані і оброблені виконавчим шаром, що інтерпретується в попередньому розділі.

3.2.4 Практичний приклад

На зображенні нижче показано дерево блоків. Кожен блок позначений висотою блоку (30, 31, 32, ··· ) і ранжування блок-генераторів, яке показує, що кожен блок у дереві блоків нотаріально завірений і позначений символом N. Це означає, що нотаріально завірені блоки в кожному дереві блоків підтримуються нотаріальним засвідченням не менше n-f копій різних вузлів. Можна з’ясувати, що на зазначеній висоті блоку може бути більше одного нотаріально завіреного блоку. Наприклад, на висоті блоку 32 ми можемо побачити 2 нотаріально завірених блоки, один запропонований генератором блоків у ранзі 1, а інший запропонований рангом 2, і те ж саме відбувається на висоті блоку 34. Ми також бачимо, що блоки висотою 36 також явно підтверджуються, що позначається символом F. Це означає, що n-f копій різних вузлів підтримали остаточне підтвердження блоку, а це означає, що ці копії вузлів (або, принаймні, чесні копії вузлів) не підтримують нотаріальне засвідчення будь-якого іншого блоку. Вважається, що всі предки, чий блок заповнений сірим кольором, отримали неявне остаточне підтвердження.

**3.2.5 Неупередженість **

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

3.3 Рівень маршрутизації

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

Слід розрізняти два типи входів:

Ingress Message: повідомлення від зовнішнього користувача.

Повідомлення між підмережами: повідомлення з танків в інших підмережах.

Ми також можемо розрізняти два типи виведення:

Відповідь на вхідне повідомлення: відповідь на повідомлення про вхід (яке може бути отримано зовнішніми користувачами).

Повідомлення між підмережами: повідомлення, які передаються в інші резервуари підмережі.

Коли надходять навантаження від консенсусу, входи в цих навантаженнях розміщуються в різних чергах входів. Для кожного танка C в підмережі існує кілька черг входу: повідомлення про вхід до C, окремий резервуар C’ для зв’язку з C і повідомлення між підмережами від C до C’.

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

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

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

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

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

3.4 Рівень виконання

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

Вона повинна бути детермінованою, тобто залежати виключно від даних даних;

Він повинен справедливо розподіляти робоче навантаження між резервуарами (але оптимізувати пропускну здатність, а не затримку).

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

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

4

Криптографія ланцюгового ключа

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

Розуміння технології еволюції ланцюга, тобто розуміння технічної реалізації безпеки протоколу консенсусу IC. Технологія еволюції ланцюга складається з двох основних компонентів: сумарних блоків і пакетів наздоганяння (CUP).

4.1 Підсумковий блок

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

У сценарії з пороговою структурою f + 1/n генерується новий ключ підпису для кожної епохи;

У сценарії з пороговою структурою n-f/n, ключ підпису повторно передається один раз на епоху.

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

4,2 ЧАШКИ

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

Корінь хеш-дерева Меркеля для всього реплікованого стану (на відміну від часткового стану кожного раунду валідації в главі 1.6).

вік.

Випадковий маяк для першого кола епохи.

Порогова сигнатура підмережі для (n - f)/n для вищевказаних полів.

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

4.3 Реалізація технології еволюції ланцюга

Збір сміття: Оскільки CUP містить інформацію про певну епоху, кожна копія вузла може безпечно очистити всі оброблені вхідні дані до цієї епохи, а також повідомлення рівня консенсусу, які впорядкували ці входи.

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

На наведеній нижче схемі зображено швидкий рух вперед. Тут припустимо, що нам потрібна репліка вузла, яка повинна наздогнати в точці відліку епохи, (скажімо) з висотою блоку 101 і CUP. Цей CUP містить корінь реплікованого дерева Меркла з висотою блоку 101, підсумковий блок з висотою блоку 101 і випадковий маяк з висотою блоку 101. Вузол використовує підпротокол синхронізації станів, щоб отримати весь статус реплікації висоти блоку 101 від своїх вузлів і перевіряє цей стан за допомогою дерева Меркла в CUP. Після отримання цього стану, копія вузла може брати участь у протоколі, отримувати блоки з висотою блоку 102, 103 і т.д. (та інші повідомлення, пов’язані з консенсусом) від однорангового вузла, а також оновлювати копію свого стану реплікації. Якщо його вузли мають підтверджені блоки на більш високому рівні, копія вузла обробить (а також нотаріально завірить і доопрацює) ті доопрацьовані блоки, отримані від вузлів, в найкоротші терміни (настільки швидко, наскільки це дозволяє рівень виконання).

5

Епілогом

Як і Ethereum, бачення DFINITY полягає в тому, щоб створити «світовий суперкомп’ютер» за допомогою вищезгаданої часткової інтерпретації та технічного пояснення його офіційного документа. СК в рамках цього бачення мають чудову можливість для реалізації.

Ми бачимо технологічні інновації та технічну можливість IC для реалізації свого бачення з гібридної моделі DAO протоколу консенсусу, з технологічної інновації швидкої генерації блоків і високої пропускної здатності, а також з нейронної системи BNS та її екологічної схеми управління. На відміну від нинішнього коду Ethereum, який є законом, управління кодом IC додає до основи елементи мудрості натовпу не з метою створення ідеальної архітектури коду, а з метою того, щоб система могла швидко коригувати правила. Це не тільки технологічне творіння, а й сяюча людська натура. У світі блокчейну встановлення, підтримка та модифікація консенсусу не можуть бути просто кодифіковані, але суть ядра повинні складати люди. Дійсний і справедливий консенсус між групами, орієнтованими на людину, лежить в основі блокчейн-індустрії та привабливості багатьох децентралізованих Dapps.

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