🥇Консенсус на репутацията на възела. Нужен ли е?

Знам, знам. Има много криптопроекти, с хиляди консенсуси: на база на труд и собственост, злато, нефт и изпечени питки (има и такъв, да-да). Какво ново от един? Това и предлагам да обсъдим след прочитането на "облекчената" техническа документация на проекта *Созвездие (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, който е познат на данни инженери и е съвместим с съществуващата технология за големи данни.

Хиломорфни и метаморфни стандартни канали за контраст. В метаморфното състояние данните от два стандартни канала се изпращат в блок в метаканала. В Хило взимаме предишното състояние на канала и го използваме, за да запитаме (да зададем конкретен въпрос) два други канала, а след това запазваме резултата от запитването в блока.

Токеномика и нейното свързване с Hylochain

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

Поток за закупуване на достъп до информация или модификация на информация. Заявката се отправя към $DAG, средствата се изпращат в сметката на канала, резултатът се изпраща на купувача, а контролната сума на транзакцията се изпраща в мрежата $DAG, която след това отключва средствата за стандартния канал.