Wiem, wiem. Jest mnóstwo projektów kryptograficznych, a rodzajów konsensusu jest całe mnóstwo: od pracy i posiadania, przez złoto, ropę, aż po upieczone ciastka (tak, taki też istnieje). Co nam jeszcze po jednym? To proponuję omówić po przeczytaniu tłumaczenia 'ulepszonej' dokumentacji technicznej projektu *Constellation (). Oczywiście, to nie jest pełny opis algorytmu, ale interesuje mnie opinia społeczności Habr, czy taki konsensus ma sens, czy jest zupełnie niepotrzebny?
Dalej liter nie ma wiele, więc jeśli tylko chcesz napisać 'fuj, ile można pisać o kryptowalutach', to proszę, powstrzymaj się. Jeśli interesują Cię nowe rozwiązania w zakresie systemów rozproszonych i masz coś do dodania w komentarzach, to zapraszam pod tekst.
P.S. Nie jestem autorem technologii, więc nie mogę zagwarantować pełnego oddania jej sedna, dlatego będę wdzięczny za komentarze z poprawkami, jeśli takie będą.
Ewolucja od synchronicznych konsensów do asynchronicznych
Węzły są wybierane za pomocą deterministycznego procesu (tego samego, który jest używany w DHT, na przykład w BitTorrent), który dynamicznie reguluje obowiązki węzłów w celu 'ułatwienia' weryfikacji lub, co bardziej zrozumiałe, osiągnięcia konsensusu. Wybieramy grupy z trzech węzłów i przeprowadzamy rundy konsensusu równolegle, aby jeden węzeł mógł pełnić rolę moderatora w kilku blokach. Pozwala nam to przetwarzać transakcje asynchronicznie, co w zasadzie oznacza, że równolegle formuje się wiele łańcuchów bloków. Proces przypomina pajęczynę, utworzoną z wielu nici, w przeciwieństwie do węzłów, które tworzą jeden łańcuch z upływem czasu. Asynchroniczne lub równoległe przetwarzanie jest podstawą skalowalnego programowania, ponieważ pozwala wykorzystać wszystkie zasoby komputera, przyspieszając ogólne obliczenia. Ta sieć nazywa się grafem acyklicznym skierowanym, czyli DAG w informatyce.
Szerokość kanału liniowego łańcucha bloków a efekt multiplicacyjny DAG, gdzie mamy kilka równoległych łańcuchów bloków.
Geometryczna realizacja liniowego łańcucha bloków w porównaniu do DAG. Czarne punkty to bloki, białe punkty to węzły.
Używamy 3 węzłów w każdej rundzie konsensusu, ponieważ daje nam to interesujące procesy matematyczne do rozważania stanu, formując „płaszczyznę powierzchni” wzdłuż danych w formie trójkątów z powiązaniami. Następnie protokół używa trójkątów do „zszywania” optymalnej powierzchni, która nie zawiera nadmiarowych lub sprzecznych danych i ma minimalną możliwą liczbę trójkątów. Algorytmicznie jest to analogiczne do „minimalnego przekroju” grafu, a matematycznie — pochodnej lub funkcji optymalizacji (z której funkcja znajduje najkrótszą drogę, jaką może przemierzyć po powierzchni). Ta najkrótsza droga odpowiada optymalnemu przechowywaniu danych (transakcji) w grupie zapewniającej dostępność baz danych. Konfliktujące trójkątne „płytki”, aby powierzchnia zdarzenia była gładka i wolna od konfliktów.
Geometryczna realizacja wykrywania/obsługi konfliktów. Konfliktujący blok tworzy dodatkową płytkę powierzchni. Usuwamy płytkę dodatkowej powierzchni, aby utrzymać płaską (= wolną od konfliktów) powierzchnię zdarzeń.
Konsensus oparty na reputacji
W optymalnym zdecentralizowanym systemie p2p reputacji każdy węzeł powinien mieć możliwość samodzielnego określenia swojego zaufania do innych węzłów. Nasz system korzysta z specjalnego modelu, który uwzględnia relacje przejrzyste lub relacje, które węzeł ma z innymi węzłami, przy przyznawaniu globalnej oceny. „Jesteś tak dobry, jak twoja firma”. Ostatecznym wynikiem jest „zniekształcenie” lub gradient oparty na przejrzystym zaufaniu lub reputacji we wszystkich węzłach w $DAG lub standardowym kanale. Można to postrzegać jako tarkę do sera, która zdziera powierzchnię „płaszczyzny powierzchni” i wybiera, które „trójkątne płytki” zetrzeć, a które zostawić. Tak właśnie logika konfliktu w rzeczywistości usuwa „trójkątne płytki”.
DAG z konfliktującą płytką przechodzącą przez „zakrzywioną” przestrzeń, która jest gradientem podobnym do tarki do sera, i ma na celu usunięcie lub „zetrzeć” konfliktującą płytkę.
Częściowe/pełne skalowanie węzła
W teorii sieci, optymalne rozmieszczenie, znane jako „bez skalowania”, zazwyczaj opisuje się jako hierarchiczne usytuowanie z dużymi centralnymi węzłami zarządzającymi wieloma mniejszymi węzłami peryferyjnymi. Takie rozmieszczenie jest widoczne w naturze, a przede wszystkim w Internecie. Constellation wykorzystuje tę architekturę do „skalowania”, czyli zwiększenia przepustowości lub szerokości naszego Grafu.
Efekt hierarchicznego podziału. Możemy dodać więcej węzłów, zwiększając szerokość przepustowości.
Hylochain — Wsparcie aplikacji opartych na kanałach.
Nasze podejście do wsparcia aplikacji można postrzegać jako „zdysocjowaną platformę inteligentnych kontraktów”. Zamiast centralnej sieci wykonującej całą logikę i przetwarzającej wszystkie dane z aplikacji, Constellation koordynuje dane aplikacji z „kanałami państwowymi”, które można traktować jako stację telewizyjną, transmitującą wszystkie dane z systemu państwowego. Każdy kanał państwowy może wdrażać własną logikę weryfikacji, co pozwala rozwiązać problem z oracle'ami poprzez end-to-end weryfikację producentów danych i proste sprawdzanie złożonych systemów państwowych. Sieci kanałów państwowych zapewniają równoległe wsparcie aplikacji, przyspieszając czas akceptacji, który w sieci z inteligentnymi kontraktami ogranicza się do tradycyjnego synchronizowanego konsensusu.
Dwa kanały państwowe, które są „kompatybilne” przez sieć $DAG. Mogą ze sobą współdziałać lub być interpretowane, ponieważ oba są „zintegrowane” z $DAG poprzez wdrażanie hybrydowych węzłów $DAG + Kanał.
Powód, dla którego nazywa się to Hylochain, polega na tym, że w naszym podejściu do wsparcia aplikacji wykorzystano funkcyjną model programowania Schematy Rekurencji dla stworzenia interfejsu MapReduce. W szczególności schematy rekurencji Hylomorfizmu i Metamorfizmu mogą być zintegrowane w celu tworzenia weryfikowalnych zapytań i połączeń strumieniowych przez standardowe kanały poprzez weryfikację algebraicznych typów danych tak, jak weryfikuje się op-kody dla inteligentnych kontraktów. Ostatecznym rezultatem jest funkcjonalny interfejs MapReduce, który jest znany inżynierom danych i jest zgodny z istniejącą technologią big data.
Hylomorficzne i Metamorficzne standardowe kanały dla kontrastu. W stanie metamorfowym dane z dwóch standardowych kanałów są wysyłane do bloku w metakanale. W Hilo bierzemy poprzedni stan kanału i wykorzystujemy go do zadania (zdefiniowania konkretnego pytania) dwóch innych kanałów, a następnie zapisujemy wynik zapytania w bloku.
Tokenomika i jej związek z Hylochain
Gdy standardowy kanał jest stworzony, można go zintegrować z kanałem $DAG, ale przy użyciu interfejsu ACI lub Application Chain Interface. Ten interfejs to po prostu obiekt JSON zawierający informacje o konfiguracji i publiczny klucz powiązany z samym kanałem. Powód, dla którego łączymy publiczny klucz ze standardowym kanałem, polega na stworzeniu mechanizmu pośredniczenia dla danych standardowego kanału. Gdy standardowy kanał jest wdrożony, deweloperzy sami decydują, jak płatności z sieci $DAG są rozdzielane między węzły i operatorów.
Strumień zakupu dostępu do informacji lub modyfikacji informacji. Zapytanie jest kierowane do $DAG, środki są wysyłane na konto kanału, wynik jest wysyłany do kupującego, a suma kontrolna transakcji jest wysyłana do sieci $DAG, która następnie odblokowuje środki dla standardowego kanału.
Źródło: habr.com
