Может ли DFINITY, специализирующаяся на базовых технологиях, представить, что Web3 действительно будет реализован?

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

Оригинальное название: Интерпретация новой белой книги DFINITY, публичной сети потенциальных акций Какая технология лежит в основе в эпоху подключения Web 3.0?

Автор: TinTinLand

1

Свинец

В начале февраля 2022 года Dmail, первое частное почтовое децентрализованное приложение, разработанное на основе экосистемы DFINITY, получило стратегические инвестиции от Amino Capital. Сообщается, что Dmail может отправлять электронные письма на традиционные почтовые ящики и из них, и по сравнению с традиционными почтовыми ящиками, Dmail с атрибутами блокчейна также может реализовать зашифрованную передачу информации и NFT имен почтовых ящиков. Это подготовка к коммуникационному программному обеспечению в эпоху Web 3.0, которое служит входом на децентрализованные веб-сайты и DApps в виде «цифровой идентичности». Вопрос, который я хочу задать, заключается в том, почему Dmail выбрал Dfinity?

По сравнению с публичными цепочками блокчейна, Dfinity появлялся не так много раз. Не было пожара DeFi, когда была маленькая искра, и не было заработка места в первый год «NFT». Тем не менее, с момента его запуска такие люди, как Dmail, нередко получают представление о том, как будет выглядеть конкретная реализация Web 3.0.

В июле 2020 года DFINITY выпустила версию с открытым исходным кодом социального программного обеспечения для коротких видео «CanCan», которое мы можем просто сравнить с Douyin из Web 2.0. CanCan основан на языке программирования DFINITY, Motoko, и содержит менее 1000 строк кода. Это можно назвать удивительным по сравнению с десятками миллионов строк кода на Douyin и Facebook. При этом код CanCan имеет открытый исходный код, а право собственности на продукт не принадлежит какому-либо централизованному органу. 1 октября того же года DFINITY представила свою систему управления и экономическую модель токенов, а оценка проекта однажды достигла $9,5 млрд, войдя в пятерку лучших. В конце декабря того же года была завершена эпохальная эволюция пяти сетей от меди до ртути. Доминик Уильямс, основатель и главный научный сотрудник DFINITY Foundation, заявил на «2020 FAT Value Era Summit Forum and Awards Ceremony», что интернет-компьютер является третьей великой инновацией блокчейна.

В этой статье мы будем интерпретировать оригинальный текст белой книги DFINITY, начиная с самой низкой логики официального объяснения, чтобы увидеть, как DFINITY может начать с технологий, сломать большие технологии в Интернете и позволить различному программному обеспечению Web2.0 использовать автономное программное обеспечение и децентрализованное управление для достижения синергии бизнеса с открытым исходным кодом, чтобы по-настоящему реализовать Web3.0; Читатели, не имеющие опыта работы в блокчейн-индустрии, могут иметь порог чтения при чтении этой статьи, но они также могут прокомментировать вопросы, которые возникают ниже, и они могут получить неожиданные ответы.

2

Очертание

На протяжении всей истории и текущего процесса блокчейна BTC принес эру децентрализованных денег, ETH представляет собой область операционных систем, Filecoin представляет собой хранилище, а DFINITY представляет инновации в вычислительной сфере и внедрение Web 3.0. Internet Computer (далее – IC) – основная сеть, протокол уровня 1, направленный на разработку децентрализованной публичной сети, DFINITY – это открытый виртуальный блокчейн-компьютер и технология, расширяющая экосистему Ethereum на широкий спектр сценариев бизнес-приложений. В этой статье мы будем использовать официальный термин «компьютер Интернета» в техническом документе для обозначения цепочки «DFINITY», которая обычно используется в текущем сценарии связи. В этом разделе в основном объясняются технические термины, используемые в некоторых ИС, а также различия в технологии и реализации по сравнению с другими публичными сетями, а также яркие моменты в технологии и функциях. Можно сказать, что IC — это новая попытка сочетания масштабируемости, децентрализации и безопасности.

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

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

DAO работают по протоколу консенсуса с разрешениями для каждой подсети, и DAO решает, какие сущности могут предоставлять копии узлов, настраивает сеть, предоставляет инфраструктуру открытых ключей и контролирует версию протокола, в которой развертываются копии узлов. DAO IC называется Network Nervous System (NNS) и основана на протоколе POS, то есть все соответствующие решения принимаются членами сообщества, а право голоса членов сообщества определяется количеством нативных токенов управления IC (ICP), которые они размещают в NNS. Этот механизм управления на основе PoS позволяет создавать новые подсети и добавлять или удалять реплики узлов из существующих, а также развертывать обновления программного обеспечения и вносить другие корректировки в ИС.

С этой точки зрения мы также можем понять, почему DFINITY называет IC сетью реплицируемых конечных автоматов, потому что NNS сама по себе является реплицируемым конечным автоматом. Как и другие конечные автоматы, они работают в определенной подсети, и их членство определяется той же системой управления на основе PoS, о которой говорилось выше. В то же время поддерживается база данных, называемая реестром, в которой записывается, какие реплики узлов к какой подсети принадлежат, открытые ключи реплик узлов и так далее. Таким образом, сеть управления DAO служит децентрализованным протоколом консенсуса, позволяющим IC получать эффективный консенсус, но в то же время, из-за механизма работы DAO, IC также сохраняет существующие преимущества децентрализации.

Протокол консенсуса IC также использует криптографию с открытым ключом, такую как реестр, поддерживаемый NNS, для привязки открытого ключа к реплике узла и подсети для формирования единого целого, что называется криптографией с цепным ключом, и IC также предусматривает модель связи для протокола консенсуса и протокола, который выполняет конечный автомат репликации: он надеется принять более осуществимую и надежную асинхронную модель (для любого отправленного сообщения злоумышленник может задержать доставку любого сообщения на произвольное время, поэтому нет ограничений по времени для доставки сообщения) для борьбы с византийскими сбоями. Тем не менее, в настоящее время не существует известной модели консенсуса, которая была бы реально осуществима в рамках асинхронной модели, и в следующей интерпретации архитектуры ИС в этой статье более подробно будет объяснен технический подход к ИС для этой реальной ситуации.

2.2 Криптография с цепным ключом

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

Основное применение этих пороговых сигнатур заключается в том, что отдельные выходные данные одной подсети могут быть проверены другой подсетью или внешним пользователем, а проверка может быть выполнена просто путем проверки реализации электронной подписи с помощью открытого ключа подписи проверки измененной подсети (первой подсети).

Как мы видим, существует множество других применений этих пороговых сигнатур в ИС. Он должен использоваться для того, чтобы сделать каждую копию узла в подсети доступной для непредсказуемых псевдослучайных цифр (производных от таких пороговых сигнатур). Это основа для случайных маяков, используемых уровнем консенсуса, и случайных лент, используемых уровнем исполнения.

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

2.3 ВЧП

ICP имеет следующие особенности:

Стейкинг NNS, т.е. облегчение управления сетью.

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

Redeem Cycles, т.е. как производственная сила.

ICP используется для оплаты использования IC. В частности, ICP может быть использован для циклов (т.е. сожжен), которые могут быть использованы для оплаты ресурсов (хранилища, процессора и пропускной способности), используемых для создания танков и танков. Отношение ВЧД к циклу определяется ННС.

Поставщики нод платные, т.е. выдаются в качестве вознаграждения участникам.

ICP используется для оплаты поставщикам узлов — организациям, которые владеют и управляют вычислительными узлами для размещения копий узлов, составляющих IC. NNS регулярно (в настоящее время ежемесячно) определяет новоиспеченный ICP, который должен получить каждый поставщик узлов, и выпускает его на свою учетную запись. В соответствии с политиками, установленными и применяемыми NNS, оплата ICP зависит от поставщика узла, предоставляющего надежные услуги IC.

2.4 Выполнение NNS

Как упоминалось ранее, конечный автомат репликации ИС может выполнять произвольные программы. Базовая вычислительная единица в ИС называется танком, и это во многом то же самое, что и процесс, содержащий программу и ее состояние (которое меняется со временем). Программа танка закодирована на WebAssembly (далее Wasm), который представляет собой двухмеханизмный формат инструкций, основанный на стекированной виртуальной машине. Wasm — это стандарт с открытым исходным кодом, и хотя он изначально был разработан для обеспечения высокопроизводительных веб-приложений, он также хорошо подходит для вычислений общего назначения.

ИС обеспечивает среду выполнения программ Wasm внутри резервуара и связи (посредством обмена сообщениями) с другими резервуарами и внешними пользователями. В то время как в принципе можно написать программу танка на любом языке, который компилируется в Wasm, вышеупомянутый язык под названием Motoko очень хорошо согласуется с семантикой операций ИС и может быть использован в ИС.

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

В дополнение к Motoko, IC предоставляет язык определения интерфейса сообщений и формат данных под названием Candid, который используется для языка высокого уровня фиксированного типа и межъязыковой совместимости. Это позволяет любым двум танкам, даже если они написаны на разных языках высокого уровня, легко взаимодействовать друг с другом. Для того, чтобы обеспечить полную поддержку разработки танков для любого языка программирования, в дополнение к компилятору Wasm для этого языка должна быть предоставлена специальная поддержка среды выполнения. В настоящее время, помимо Motoko, IC также полностью поддерживает разработку танков на языке программирования Rust.

В результате ИС поддерживают более безопасные и межъязыковые языки программирования, что является одним из важных факторов, делающих разработчиков более эффективными и безопасными при создании ИС.

2.5 Решения NNS

В блокчейн-сети DFINITY BNS (Blockchain Nervous System) — это система управления, на которой функционирует сеть, и это один из самых важных строительных блоков в сети блокчейн, который может автоматически входить в систему и иметь высокие полномочия. Он берет на себя роль суперноды. Любой человек участвует в управлении ННС, размещая ICP в так называемых нейронах. Держатели нейронов могут предлагать и голосовать за то, как следует изменить ИС, например, топологию подсети или протокол. Право голоса Neurons основано на PoS. Интуитивно понятно, что чем больше ICP поставлено в стейкинг, тем больше нейронных прав голоса. Тем не менее, право голоса также зависит от других характеристик нейронов, таких как держатели нейронов, которые готовы размещать свои токены в течение более длительного периода времени, получают большее право голоса.

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

Говоря простым языком, процесс управления BNS разделен на четыре этапа: создание нейронов, предложение, голосование и исполнение.

Создание нейронов: Как упоминалось выше, блокчейн Neurosystem позволяет пользователям использовать ICP для создания нейронов для голосования. Создать нейрон может каждый, а в будущем могут быть созданы десятки тысяч нейронов, которые будут коллективно выражать волю сообщества, опосредованную алгоритмами.

Предложения: Любой пользователь, работающий с нейронами, может внести предложение в BNS, и BNS рассмотрит это предложение на основе разумности предложения и того, содержит ли оно решение. Пользователь, который делает предложение, должен заплатить два сбора: один — заплатить профессиональным рецензентам и нейронам, участвовавшим в голосовании, а другой — депозит предложения, который будет возвращен нейрону после принятия предложения, и эта сумма может быть установлена для поощрения высококачественных предложений.

Голосование: Помимо автора предложения, другие пользователи также должны внести токены в стейкинг нейронов на этапе голосования и иметь возможность активно голосовать или следить за голосованием. Пользователи, обладающие способностью к независимому суждению, могут активно голосовать, и сценарий последующего голосования подходит для некоторых пользователей, которые не могут точно оценить предложения. После закрытия времени голосования BNS собирает результаты работы нейросети и автоматически определяет, одобрено предложение или нет.

Реализация: Только что была проведена интерпретация консенсуса IC на уровне исполнения, какова конкретная реализация реализации системы управления BNS? ПРЕДЛОЖЕНИЕ ПО ПАССИВНОМУ ИСПОЛНЕНИЮ В ОСНОВНОМ СВЯЗАНО С ИЗМЕНЕНИЕМ ПАРАМЕТРОВ СМАРТ-КОНТРАКТОВ НА DFINITY, ТАКИХ КАК ПАРАМЕТРЫ СТЕЙКИНГА НЕЙРОНОВ. Обновленные параметры предложения будут пассивно записываться в базу данных смарт-контрактов BNS и вступят в силу непосредственно при их последующем выполнении. Существует особый случай, когда предложение находится вне контроля смарт-контракта BNS, например, связанный с нормативным уровнем BNS, который потребует активного применения человеком для переопределения части DFINITY «код — это закон». Например, модификация уязвимостей в системном коде или замораживание смарт-контрактов или нейронов, нарушающих правила BNS. Активный процесс выполнения реализуется путем вызова специальных кодов операций, добавленных в EVM. Операция этого шага более гуманна и разумна, нежели нынешние «код — это закон» и «код — это все» в нынешнем мире блокчейна. С точки зрения человеческой природы, освещение сценариев, в которых код не может принимать решения, может привести к более эффективному и интеллектуальному управлению, и в некоторой степени это также действительно затрагивает основную цель «консенсуса».

3

Интерпретация архитектуры

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

3.1 Уровень P2P

Уровень P2P служит слоем в уровне протокола компьютера Интернет для получения и упорядочения сообщений, и его задачей является доставка сообщений протокола в копии узлов подсети.

Существует два типа сообщений протокола: сообщения, используемые для достижения консенсуса, и входные сообщения, инициированные внешними пользователями.

Мы можем понять, что уровень P2P в основном обеспечивает канал вещания «наилучших усилий», т.е. если честная копия узла транслирует сообщение, то сообщение в конечном итоге будет получено всеми городскими узлами в подсети.

Уровень P2P предназначен для достижения следующих целей:

Ограниченные ресурсы. Все алгоритмы работают с ограниченными ресурсами (память, пропускная способность, процессор).

Приоритет. В зависимости от конкретных атрибутов, таких как тип, размер и поворот, разные сообщения будут сортироваться с разными приоритетами. И правила для этих приоритетов могут меняться со временем.

Высокоэффективный. Высокая пропускная способность важнее, чем низкая задержка. ВЫСОКАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ ТАКЖЕ ЯВЛЯЕТСЯ ПРИЧИНОЙ ТОГО, ЧТО DFINITY БОЛЕЕ ЭФФЕКТИВЕН СНИЗУ, ЧЕМ ДРУГИЕ ПУБЛИЧНЫЕ СЕТИ.

Анти-DOS/SPAM. Сбои узлов не повлияют на обмен данными между честными репликами узлов.

3.2 Уровень консенсуса

3.2.1 Общие сведения об уровне консенсуса

Задача уровня консенсуса IC состоит в том, чтобы отсортировать входные сообщения, чтобы гарантировать, что все реплики узлов обрабатывают входные сообщения в одном и том же порядке. В литературе существует множество протоколов, посвященных этому вопросу. IC принимает новый протокол консенсуса, который будет описан общим языком в этой статье. Любой безопасный протокол консенсуса должен обеспечивать два атрибута, а именно:

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

Активно: все реплики узлов должны обновлять свое состояние по одной.

Цель разработки уровня консенсуса IC на самом деле проста: при наличии отдельных вредоносных узлов производительность будет гибко снижаться. Как и многие протоколы консенсуса, протокол консенсуса IC основан на блокчейне. По мере развития протокола дерево блоков с генезис-блоком в качестве корневого узла будет продолжать расти. Каждый негенезис-блок содержит полезную нагрузку, состоящую из ряда входных данных и хэша родительского блока.

Честные реплики имеют согласованное представление дерева блоков: хотя каждая реплика может иметь разное локальное представление дерева блоков, все реплики узла видят одно и то же дерево блоков. Кроме того, по мере развития протокола в дереве блоков всегда будет путь для завершения блока. Опять же, честные реплики узлов имеют согласованное представление этого пути: хотя каждая реплика узла может иметь разное локальное представление пути, все реплики узлов видят один и тот же путь. Входные данные в загрузке блоков вдоль этого пути являются отсортированными входными данными, которые будут обрабатываться исполнительным уровнем ИС.

Протокол консенсуса полагается на электронные подписи для проверки сообщений в копии узла. Для этого каждая копия узла связывается с открытым ключом проверки подлинности для протокола подписи. Корреляцию между репликой узла и открытым ключом можно получить из реестра, поддерживаемого NNS. Это также согласуется с ролью и ролью криптографии с цепным ключом в ИС, упомянутой выше.

3.2.2 Допущения

Как обсуждалось во второй части, IC выдвигает следующую гипотезу:

Подсеть содержит 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 Уровень трассировки

Как уже говорилось ранее, основной вычислительный блок в ИС называется танком. ИС обеспечивает операционную среду, в которой программы могут выполняться в резервуаре и могут взаимодействовать (посредством сообщений) с другими резервуарами и внешними пользователями. Уровень консенсуса упаковывает входные данные в загрузку блока, и как только блок подтверждается красным, соответствующая нагрузка передается на уровень маршрутизации сообщений и обрабатывается средой выполнения. Затем уровень выполнения обновляет состояние в соответствующем резервуаре в конечном автомате репликации и передает выходные данные на уровень маршрутизации сообщений для обработки.

Необходимо различать два типа входов:

Входящее сообщение: сообщение от внешнего пользователя.

Сообщения между подсетями: Сообщения от танков в других подсетях.

Также можно выделить два типа вывода:

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

Сообщения между подсетями: сообщения, передаваемые в другие резервуары подсети.

При получении загрузок из консенсуса входные данные в этих загрузках помещаются в разные очереди ввода. Для каждого резервуара C в подсети существует несколько входных очередей: входящее сообщение в C, отдельный резервуар C’ для связи с C’ и межподсетевое сообщение от C к C’.

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

В дополнение к этим очередям вывода существует также структура исторических данных для входящих сообщений. После того, как входящее сообщение было обработано резервуаром, ответ на это входящее сообщение записывается в эту структуру данных. На этом этапе внешний пользователь, предоставивший входящее сообщение, сможет получить соответствующий ответ. (Примечание. История входящего трафика не хранит полную историю всех входящих сообщений).

Есть два момента, которые необходимо уточнить, во-первых, состояние реплики узла включает в себя состояние резервуара, а также «состояние системы». «Состояние системы» включает в себя очереди, потоки данных и структуры данных из истории входящего трафика, упомянутые выше. В результате и уровень маршрутизации сообщений, и уровень выполнения участвуют в обновлении и поддержании состояния реплики подсети. Все это состояние должно быть обновлено с полным детерминизмом, чтобы все узлы поддерживали одно и то же состояние.

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

Объяснение и объяснение уровня маршрутизации дают нам более четкое понимание того, как протокол консенсуса передается в протокол консенсуса и из него через маршрутизацию сообщений, и как он связан с уровнем исполнения, чтобы способствовать координации и согласованности протокола консенсуса.

3.4 Уровень исполнения

Среда исполнения обрабатывает по одному входу за раз, который берется из одной из входных очередей и направляется в резервуар, в зависимости от состояния входных данных и резервуара, среда исполнения обновляет состояние резервуара и может дополнительно добавлять сообщения в очередь вывода. и обновите журнал входящего трафика (возможно, вместе с ответом на предыдущее входящее сообщение). В заданном повороте среда выполнения будет обрабатывать несколько входных данных. Планировщик определяет, какие входы будут выполняться в каком порядке для данного хода. Вместо того, чтобы вдаваться в подробности о планировщике, мы выделим некоторые из целей:

Она должна быть детерминированной, т.е. зависеть исключительно от заданных данных;

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

Количество работ, выполненных в каждом раунде, измеряется циклами и должно быть близко к некоторому заранее определенному количеству.

Еще одна задача, с которой приходится сталкиваться среде выполнения, — это ситуация, когда один из резервуаров одной подсети генерирует сообщения между подсетями быстрее, чем другие подсети могут потреблять. В ответ на эту ситуацию мы внедрили механизм саморегулирования для замедления производства резервуара. Существует множество других задач по управлению ресурсами и бухгалтерскому учету, которые должны выполняться средой выполнения, но все эти задачи должны выполняться детерминированно.

4

Криптография с цепным ключом

В синопсисе мы объясняем, что протокол консенсуса IC также использует технику криптографии с открытым ключом - криптографию с цепным ключом, а важной частью криптографии с цепным ключом является пороговая подпись. На самом деле, криптография с цепным ключом включает в себя сложный набор методов, используемых для надежного и безопасного поддержания конечных автоматов репликации на основе блокчейна с течением времени, в совокупности известных как методы эволюции цепочки. Каждая подсеть работает в рамках эпох, содержащих несколько раундов (обычно около нескольких сотен). Технология эволюции цепочек позволяет выполнять многие из основных задач обслуживания, которые выполняются для каждой эпохи: сборку мусора, быструю переадресацию, изменение членов подсети, активную пересылку секретов и обновление протокола.

Понимание технологии эволюции цепи, то есть понимание технической реализации безопасности протокола консенсуса IC. Технология эволюции цепи состоит из двух основных компонентов: сводных блоков и догоняющих пакетов (CUP).

4.1 Сводный блок

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

В сценарии со структурой пороговых значений f + 1/n для каждой эпохи создается новый ключ подписи;

В сценарии со структурой пороговых значений n-f/n ключ подписи повторно используется один раз в эпоху.

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

4,2 ЧАШКИ

Разобравшись с кратким обзором, давайте взглянем на catch-up пакеты, или 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 добавляет в основу элементы мудрости толпы, но не с целью создания идеальной архитектуры кода, а с целью того, чтобы система могла быстро корректировать правила. Это не только технологическое творение, но и сияющая человеческая природа. В мире блокчейна установление, поддержание и модификация консенсуса не могут быть просто кодифицированы, но сущностью ядра должны быть люди. Действительный и справедливый консенсус между группами, ориентированными на человека, лежит в основе индустрии блокчейна и привлекает множество децентрализованных децентрализованных децентрализованных приложений.

В этой статье цитируется и интерпретируется часть содержания белой книги IC, в которой более подробно описывается NNS, статус аутентификации каждого раунда подсетей на уровне консенсуса, вызовы запросов и обновлений входных сообщений, распределенное распределение ключей в криптографии с цепочечным ключом, схемы PVSS, основные протоколы и протоколы повторного использования и так далее. Для разработчиков, которые хотят получить более полное и подробное представление о технологии, лежащей в основе ИС, чтение оригинального технического документа может предоставить более подробные объяснения и объяснения.