Консенсус Относительно Репутации Узла. Это Необходимо?

Знаю, знаю.

Криптопроектов много, консенсусов много: по труду и собственности, золоту, нефти, пирогам (есть один, да-да).

Что еще нам нужно от одного? Именно это я и предлагаю обсудить после прочтения перевода «облегчённой» технической документации проекта *Созвездие( Созвездие ).

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

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



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

Узлы выбираются с использованием детерминированного процесса (того же, который используется в DHT, например BitTorrent), который динамически корректирует обязанности узлов для «облегчения» проверки или, что более понятно, для достижения консенсуса.

Мы выбираем группы из 3 узлов и параллельно проводим раунды консенсуса, чтобы один узел мог быть посредником в нескольких блоках.

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

Этот процесс подобен паутине, состоящей из множества нитей, а не узлов, образующих с течением времени единую цепочку.

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

Эта сеть называется ориентированным ациклическим графом или DAG в информатике.



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

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



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

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

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

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

Алгоритмически это аналогично «минимальному разрезу» графа, а математически — аналогу производной или функции оптимизации (из которой функция находит кратчайший путь, который она может пройти по поверхности).

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

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



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

Геометрическая реализация обнаружения/обработки конфликтов.

Конфликтующий блок создает дополнительный тайл поверхности.

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



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

В оптимальной децентрализованной системе репутации p2p каждый узел должен иметь возможность независимо определять свое доверие к другим узлам.

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

«Вы хороши настолько, насколько хороша ваша компания».

Конечным результатом является «перекос» или градиент, основанный на транзитивном доверии или репутации между всеми узлами в $DAG или обычном канале.

Это можно представить как кисть или терку для сыра, которая стирает «плоскость поверхности» и выбирает, какие «треугольные плитки» стереть, а какие оставить.

Вот как конфликтная логика фактически удаляет «треугольные плитки».



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

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



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

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

Это распространение наблюдается в природе и, прежде всего, в Интернете.

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



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

· эффект иерархического разделения.

Мы можем добавить больше узлов, увеличив пропускную способность.



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

Наш подход к поддержке приложений можно рассматривать как «децентрализованную платформу смарт-контрактов».

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

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

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



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

Два стандартных канала, «совместимых» через сеть $DAG. Они могут взаимодействовать или интерпретироваться, поскольку оба «интегрированы» с $DAG путем развертывания гибридных узлов $DAG + Channel. Причина, по которой он называется Hylochain, заключается в том, что наш подход к поддержке приложений использовал модель функционального программирования Recursion Schemes для создания интерфейса MapReduce. В частности, схемы рекурсии Hylomorphism и Metamorphism могут быть интегрированы для создания проверяемых запросов и потоковых соединений по собственным каналам путем проверки алгебраических типов данных так же, как проверяются коды операций для смарт-контрактов.

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



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

Гиломорфный и Метаморфический — стандартные каналы контраста.

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

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



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

После создания собственного канала его можно интегрировать в канал $DAG, но с использованием ACI или интерфейса цепочки приложений.

Этот интерфейс представляет собой просто объект JSON с информацией о конфигурации и открытым ключом, связанным с самим каналом.

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

При развертывании обычного канала разработчики сами настраивают распределение платежей из сети $DAG между узлами и операторами.



Консенсус относительно репутации узла.
</p><p>
 Это необходимо?

Порядок приобретения доступа к информации или изменения информации.

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

Теги: #Криптовалюты #Распределенные системы #ИТ-стандарты #блокчейн #P2P #dag #Созвездие #доказательство репутации

Вместе с данным постом часто просматривают: