Знам-знам. Криптопроектите са много, има куп консенсуси: на базата на труд и собственост, злато, нефт, печен хляб (има и такъв, да-да). Какво друго ни е необходимо? Това и предлагам да обсъдим след прочитането на превода на „облекчената“ техническа документация на проекта *Созвездие (). Разбира се, това не е пълно описание на алгоритъма, но ми е интересно мнението на общността на Хабър, съществува ли такъв консенсус или е абсолютно ненужен?
Нататък буквите не са много, затова, ако просто искате да напишете „фу, колко може за крипта“, моля, въздържайте се. Ако ви интересуват новите разработки в сферата на разпределените системи и имате какво да споделите в коментарите, моля, продължете под хедъра.
P.S. Аз не съм автор на технологията, не мога да гарантирам пълно предаване на същността, затова ще се радвам на коментари с корекции, ако такива има.
Еволюция от синхронни консенсуси към асинхронни
Възлите се избират с помощта на детерминиран процес (същият, който се използва в DHT, например, битторент), който динамично регулира задълженията на възлите за „облекчаване“ на валидирането или, което е по-ясно, за постигане на консенсус. Избираме групи от 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
