Хабрахабр

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть