Консенсус на репутации ноды. Нужен ли?

Знаю-знаю. Криптопроектов тьма, есть куча консенсусов: на основе труда и владения, золота, нефти, выпеченных пирожков (есть и такой, да-да). Что нам ещё от одного? Это и предлагаю обсудить после прочтения перевода «облегченной» технической документации проекта *Созвездие (Constellation). Конечно, это не полное описание алгоритма, но мне интересно мнение комьюнити хабра, имеет ли место «быть» такому консенсусу или он даром не нужен?

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

P.S. Я не автор технологии, за полную передачу сути ручаться не могу, поэтому буду рад комментариям с поправками, если такие будут.

Эволюция от синхронных консенсусов к асинхронным

Узлы выбираются с использованием детерминированного процесса (того же, который используется в DHT, например, bittorrent), который динамически регулирует обязанности узлов для “облегчения” валидации или, что более понятно, для достижения консенсуса. Мы выбираем группы из 3 узлов и выполняем раунды консенсуса параллельно, чтобы один узел мог быть фасилитатором в нескольких блоках. Это позволяет нам обрабатывать транзакции асинхронно, что, по сути, означает, что у нас одновременно формируется несколько блокчейнов. Процесс подобен паутине, образованной множеством нитей, в отличие от узлов, формирующих одну цепочку с течением времени. Асинхронная или параллельная обработка являются основой масштабируемого программирования, поскольку оно позволяет использовать все ресурсы компьютера, ускоряя общие вычисления. Эта сеть называется ориентированным ациклическим графом или DAG в компьютерных науках.

Ширина канала линейного блокчейна против мультипликативного эффекта DAG, где у нас есть несколько параллельных блокчейнов.

Геометрическая реализация линейного блокчейна против DAG. Черные точки — это блоки, белые точки — это узлы

Мы используем 3 узла в каждом раунде консенсуса, потому что это дает нам некоторые интересные математические процессы для рассуждения о состоянии, формируя «плоскость поверхности» поперек данных в форме треугольников со связями. Затем протокол использует треугольники для «сшивания» оптимальной поверхности, которая не содержит избыточных или противоречивых данных и имеет минимально возможные треугольники. Алгоритмически — это аналогично «минимальному разрезу» графа, а математически — производной или функции оптимизации (из которых функция находит кратчайший путь, который она может пересечь по поверхности). Этот кратчайший путь эквивалентен оптимальному хранению данных (транзакций) в группе обеспечения доступности баз данных. Конфликтующие треугольные “плитки”, чтобы поверхность события была ровной и без от конфликтов.

Геометрическая реализация обнаружения / обработки конфликтов. Конфликтующий блок создает дополнительную плитку поверхности. Мы удаляем плитку дополнительной поверхности, чтобы поддерживать плоской (= бесконфликтную) поверхность событий.

Консенсус, основанный на репутации

В оптимальной децентрализованной p2p системе репутации каждый узел должен иметь возможность самостоятельно определять свое доверие к другим узлам. Наша система использует специальную модель, которая включает транзитивные отношения или отношения, которые узел имеет с другими узлами, при назначении глобальной оценки. “Вы так же хороши, как и ваша компания”. Конечным результатом является “искажение” или градиент, основанный на транзитивном доверии или репутации во всех узлах в $DAG или штатном канале. Это можно рассматривать как кисть или терку для сыра, которая стирает поверх “плоскости поверхности” и выбирает, какие “треугольные плитки” стереть, а какие оставить. Вот как логика конфликта на самом деле удаляет “треугольные плитки”.

DAG с конфликтующей плиткой, проходящей через “искривленное” пространство, которое является градиентом, похожим на терку для сыра, и собирается удалить или «стереть» конфликтующую плитку.

Частичное/полное масштабирование узла

В теории сетей, как правило, оптимальное распределение известно как “без масштабирования”, которое может быть описано как иерархическое расположение с большими центральными узлами, управляющими многими более мелкими периферийными узлами. Это распределение видно в природе и, прежде всего, в Интернете. Constellation использует эту архитектуру для “масштабирования”, или увеличения пропускной способности или ширины нашего Графа.

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

Hylochain — Поддержка приложений на основе каналов

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

Два штатных канала, которые ”совместимы” через сеть $DAG. Они могут взаимодействовать или интерпретироваться, поскольку оба они “интегрированы” с $DAG путем развертывания гибридных узлов $DAG + Канал.

Причина, по которой он называется Hylochain, заключается в том, что в нашем подходе к поддержке приложений использовалась функциональная модель программирования Recursion Schemes для создания интерфейса MapReduce. В частности, схемы рекурсии Hylomorphism (Гиломорфическая) и Metamorphism (Метаморфическая) могут быть интегрированы для создания проверяемых запросов и потоковых соединений по штатным каналам путем проверки алгебраических типов данных так же, как проверяются op-коды для умных контрактов. Конечным результатом является функциональный интерфейс MapReduce, который знаком инженерам данных и совместим с существующей технологией больших данных.

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

Токеномика и её связь с Hylochain

Когда штатный канал создан, он может быть интегрирован в канал $DAG, но с использованием интерфейса ACI или Application Chain Interface. Этот интерфейс представляет собой просто объект JSON с информацией о конфигурации и открытым ключом, связанным с самим каналом. Причина, по которой мы связываем открытый ключ со штатным каналом, заключается в создании брокерского механизма для данных штатного канала. Когда штатный канал развернут, разработчики настраивают сами, как платежи из сети $DAG распределяются между узлами и операторами.

Поток для покупки доступа к информации или модификации информации. Запрос направляется в $DAG, средства отправляются на счет канала, результат отправляется покупателю, а контрольная сумма транзакции отправляется в сеть $DAG, которая затем разблокирует средства для штатного канала.

Источник: habr.com