Wiem wiem. Projektów kryptograficznych jest wiele, istnieje wiele konsensusów: opartych na pracy i własności, złocie, ropie, pieczonych ciastach (jest jeden, tak, tak). Czego więcej potrzeba od jednego? To właśnie proponuję omówić po przeczytaniu tłumaczenia „lekkiej” dokumentacji technicznej projektu *Constellation (). Nie jest to oczywiście pełny opis algorytmu, ale ciekawi mnie opinia społeczności Habr, czy jest miejsce na taki konsensus, aby „być”, czy też jest on zbędny?
Nie ma zbyt wielu listów, więc jeśli chcesz po prostu napisać „wow, jak najwięcej o kryptowalutach”, to proszę, powstrzymaj się. Jeśli interesują Cię nowości w dziedzinie systemów rozproszonych i masz coś do podzielenia się w komentarzach, to odsyłam do kat.
PS Nie jestem autorem technologii, nie mogę ręczyć za całkowite przekazanie esencji, dlatego chętnie przyjmę uwagi z ewentualnymi poprawkami.
Ewolucja od konsensusów synchronicznych do asynchronicznych
Węzły są wybierane przy użyciu procesu deterministycznego (tego samego, który jest stosowany w DHT, takich jak bittorrent), który dynamicznie dostosowuje obowiązki węzłów, aby „ułatwić” walidację lub, co bardziej zrozumiałe, osiągnąć konsensus. Wybieramy grupy po 3 węzły i przeprowadzamy rundy konsensusu równolegle, tak aby jeden węzeł mógł być moderatorem w wielu blokach. Dzięki temu możemy przetwarzać transakcje asynchronicznie, co zasadniczo oznacza, że jednocześnie tworzymy wiele łańcuchów bloków. Proces ten przypomina pajęczynę utworzoną z wielu nitek, a nie z węzłów tworzących z biegiem czasu pojedynczy łańcuch. Przetwarzanie asynchroniczne lub równoległe jest podstawą skalowalnego programowania, ponieważ pozwala na wykorzystanie wszystkich zasobów komputera, przyspieszając ogólne przetwarzanie. Sieć ta nazywana jest skierowanym grafem acyklicznym lub DAG w informatyce.
Szerokość kanału liniowego łańcucha bloków a efekt multiplikatywny DAG, w którym mamy wiele równoległych łańcuchów bloków.
Geometryczna implementacja liniowego blockchainu przeciwko DAG. Czarne kropki to bloki, białe kropki to węzły
W każdej rundzie konsensusu używamy 3 węzłów, ponieważ daje nam to kilka interesujących procesów matematycznych do wnioskowania o stanie, tworząc „płaszczyznę powierzchniową” na danych w postaci połączonych trójkątów. Następnie protokół wykorzystuje trójkąty do zszycia optymalnej powierzchni, która nie zawiera zbędnych ani niespójnych danych i ma najmniejsze możliwe trójkąty. Algorytmicznie jest to analogiczne do „minimalnego przecięcia” wykresu, a matematycznie jest analogiczne do pochodnej lub funkcji optymalizacji (z której funkcja znajduje najkrótszą ścieżkę, jaką może pokonać po powierzchni). Ta najkrótsza ścieżka jest równoznaczna z optymalnym przechowywaniem danych (transakcji) w DAG. Konfliktowe trójkątne „płytki” tak, aby powierzchnia wydarzenia była gładka i pozbawiona konfliktów.
Geometryczna implementacja wykrywania/obsługi konfliktów. Blok powodujący konflikt tworzy dodatkową płytkę powierzchniową. Usuwamy dodatkowe płytki powierzchniowe, aby zachować płaską (= bezkonfliktową) powierzchnię wydarzenia.
Konsensus oparty na reputacji
W optymalnym zdecentralizowanym systemie reputacji p2p każdy węzeł powinien być w stanie niezależnie określić swoje zaufanie do innych węzłów. Nasz system używa specjalnego modelu, który uwzględnia relacje przechodnie, czyli relacje, jakie węzeł ma z innymi węzłami podczas przypisywania wyniku globalnego. „Jesteś tak dobry, jak Twoje towarzystwo.” Efektem końcowym jest „pochylenie” lub gradient oparty na przechodnim zaufaniu lub reputacji we wszystkich węzłach w kanale $DAG lub zwykłym. Można to porównać do pędzla lub tarki do sera, która wymazuje „płaszczyznę powierzchni” i wybiera, które „trójkątne płytki” usunąć, a które pozostawić. W ten sposób logika konfliktu faktycznie usuwa „trójkątne kafelki”.
DAG ze sprzeczną płytką przechodzącą przez „zakrzywioną” przestrzeń, która jest gradientem, podobnym do tarki do sera i usunie lub „wymaże” sprzeczną płytkę.
Częściowe/pełne skalowanie węzłów
W teorii sieci optymalną alokację określa się zwykle jako „bezskalową”, co można opisać jako układ hierarchiczny z dużymi węzłami centralnymi zarządzającymi wieloma mniejszymi węzłami peryferyjnymi. Dystrybucja ta jest widoczna w przyrodzie, a przede wszystkim w Internecie. Constellation wykorzystuje tę architekturę do „skalowania” lub zwiększenia przepustowości lub szerokości naszego Grafu.
Efekt podziału hierarchicznego. Możemy dodać więcej węzłów, zwiększając przepustowość
Hylochain — obsługa aplikacji oparta na kanałach
Nasze podejście do wsparcia aplikacji można określić jako „zdecentralizowaną platformę inteligentnych kontraktów”. Zamiast centralnej sieci obsługującej całą logikę i przetwarzającej wszystkie dane z aplikacji, Constellation koordynuje dane aplikacji z „kanałami domowymi”, które można traktować jako stację telewizyjną nadającą wszystkie dane z systemu domowego. Każdy kanał personelu może wdrożyć własną logikę weryfikacji, aby rozwiązać problem Oracle poprzez kompleksowe uwierzytelnianie producentów danych i weryfikację przechodnią złożonych systemów personelu. Sieci kanałów stanowych zapewniają równoległą obsługę aplikacji, przyspieszając czas wdrożenia ograniczony przez tradycyjny konsensus synchroniczny w sieci inteligentnych kontraktów.
Dwa standardowe kanały, które są „kompatybilne” poprzez sieć $DAG. Mogą wchodzić w interakcje lub być interpretowane, ponieważ oba są „zintegrowane” z $DAG poprzez wdrożenie hybrydowych węzłów $DAG + Channel.
Nazywa się to Hylochain, ponieważ nasze podejście do obsługi aplikacji wykorzystywało funkcjonalny model programowania Recursion Schemes do stworzenia interfejsu MapReduce. W szczególności schematy rekurencji Hylomorphism i Metamorphism można zintegrować w celu tworzenia sprawdzalnych zapytań i połączeń strumieniowych przez kanały natywne poprzez walidację algebraicznych typów danych w taki sam sposób, w jaki weryfikowane są kody operacji dla inteligentnych kontraktów. Efektem końcowym jest funkcjonalny interfejs MapReduce, znany inżynierom danych i kompatybilny z istniejącą technologią dużych zbiorów danych.
Hylomorficzne i metamorficzne to standardowe kanały kontrastu. W stanie metamorficznym dane z dwóch zwykłych kanałów przesyłane są do bloku w metakanale. W Gilo bierzemy poprzedni stan kanału i używamy go do zapytania (zadania konkretnego pytania) dwóm innym kanałom, a następnie zapisujemy wynik zapytania w bloku.
Tokenomika i jej związek z Hylochainem
Po utworzeniu kanału natywnego można go zintegrować z kanałem $DAG, ale przy użyciu interfejsu ACI lub interfejsu łańcucha aplikacji. Interfejs ten to po prostu obiekt JSON z informacjami konfiguracyjnymi i kluczem publicznym powiązanym z samym kanałem. Powodem, dla którego kojarzymy klucz publiczny ze zwykłym kanałem, jest stworzenie mechanizmu brokerskiego dla danych zwykłego kanału. Po wdrożeniu zwykłego kanału programiści sami konfigurują sposób dystrybucji płatności z sieci $DAG pomiędzy węzłami i operatorami.
Przepływ zakupu dostępu do informacji lub modyfikacji informacji. Zapytanie wysyłane jest do $DAG, środki przesyłane są na konto kanału, wynik wysyłany jest do kupującego, a suma kontrolna transakcji przesyłana jest do sieci $DAG, która następnie uwalnia środki do zwykłego kanału.
Źródło: www.habr.com