Já vím, já vím. Existuje mnoho krypto projektů, existuje mnoho konsensů: na základě práce a vlastnictví, zlata, ropy, pečených koláčů (jeden existuje, ano, ano). Co víc od jednoho potřebujeme? Toto navrhuji prodiskutovat po přečtení překladu „odlehčené“ technické dokumentace projektu *Constellation (). Samozřejmě to není úplný popis algoritmu, ale zajímá mě názor komunity Habr, existuje místo pro takový konsenzus, aby „byl“ nebo je to zbytečné?
Není tu mnoho dalších písmen, takže pokud chcete napsat jen „wow, co nejvíce o kryptoměnách“, pak se prosím zdržte. Pokud vás zajímají novinky v oblasti distribuovaných systémů a chcete se o něco podělit v komentářích, podívejte se prosím na kat.
PS Nejsem autorem technologie, nemohu ručit za kompletní převod esence, takže budu rád za případné připomínky s pozměňovacími návrhy.
Vývoj od synchronního k asynchronnímu konsensu
Uzly jsou vybírány pomocí deterministického procesu (stejného, jaký se používá v DHT, jako je bittorrent), který dynamicky upravuje odpovědnosti uzlů, aby „usnadnil“ validaci nebo, což je pochopitelnější, k dosažení konsenzu. Vybereme skupiny 3 uzlů a paralelně spustíme kola konsenzu, takže jeden uzel může být facilitátorem ve více blocích. To nám umožňuje zpracovávat transakce asynchronně, což v podstatě znamená, že se vytváří více blockchainů současně. Proces je jako pavučina, tvořená mnoha vlákny, na rozdíl od uzlů tvořících v průběhu času jeden řetězec. Asynchronní nebo paralelní zpracování je základem škálovatelného programování, protože umožňuje využití všech počítačových zdrojů a zrychluje celkové výpočty. Tato síť se v informatice nazývá směrovaný acyklický graf nebo DAG.
Šířka kanálu lineárního blockchainu versus multiplikativní efekt DAG, kde máme více paralelních blockchainů.
Geometrická implementace lineárního blockchainu proti DAG. Černé tečky jsou bloky, bílé tečky jsou uzly
V každém kole konsensu používáme 3 uzly, protože nám to poskytuje zajímavé matematické procesy pro uvažování o stavu, které tvoří „povrchovou rovinu“ napříč daty ve formě spojených trojúhelníků. Protokol pak pomocí trojúhelníků spojí dohromady optimální povrch, který neobsahuje žádná nadbytečná nebo nekonzistentní data a má nejmenší možné trojúhelníky. Algoritmicky je to obdoba „minimálního řezu“ grafu a matematicky obdoba derivační nebo optimalizační funkce (z níž funkce najde nejkratší cestu, kterou může po povrchu ujet). Tato nejkratší cesta je ekvivalentní optimálnímu ukládání dat (transakcí) v DAG. Konfliktní trojúhelníkové „dlaždice“, aby byl povrch události hladký a bez konfliktů.
Geometrická implementace detekce/zvládání konfliktů. Konfliktní blok vytváří další povrchovou dlaždici. Odstraňujeme další povrchové dlaždice, abychom zachovali rovný (= bezkonfliktní) povrch akce.
Konsensus založený na pověsti
V optimálním decentralizovaném reputačním systému p2p by měl být každý uzel schopen nezávisle určit svou důvěru v ostatní uzly. Náš systém používá při přidělování globálního skóre speciální model, který zahrnuje tranzitivní vztahy nebo vztahy, které má uzel s jinými uzly. "Jsi jen tak dobrý jako tvoje společnost." Konečným výsledkem je „zešikmení“ nebo gradient založený na tranzitivní důvěře nebo pověsti napříč všemi uzly v $DAG nebo běžném kanálu. To si lze představit jako štětec nebo struhadlo na sýr, které maže přes „rovinu povrchu“ a vybírá, které „trojúhelníkové dlaždice“ se mají vymazat a které ponechat. Takto logika konfliktů ve skutečnosti odstraňuje „trojúhelníkové dlaždice“.
DAG s konfliktní dlaždicí procházející „zakřiveným“ prostorem, který je gradientní, podobný struhadlu na sýr, a odstraní nebo „vymaže“ konfliktní dlaždici.
Částečné/úplné škálování uzlu
V teorii sítí je obvykle optimální alokace známá jako „bezškálová“, což lze popsat jako hierarchické uspořádání s velkými centrálními uzly spravujícími mnoho menších periferních uzlů. Toto rozšíření je viditelné v přírodě a především na internetu. Constellation využívá tuto architekturu k „zmenšení“ neboli zvýšení propustnosti nebo šířky našeho grafu.
Efekt hierarchického dělení. Můžeme přidat další uzly zvýšením šířky pásma
Hylochain – kanálová podpora aplikací
Náš přístup k podpoře aplikací lze považovat za „decentralizovanou platformu inteligentních smluv“. Namísto centrální sítě provozující veškerou logiku a zpracování všech dat z aplikace Constellation koordinuje data aplikace s „domácími kanály“, které si lze představit jako televizní stanici vysílající všechna data z domácího systému. Každý zaměstnanecký kanál může implementovat svou vlastní ověřovací logiku k vyřešení problému věštce prostřednictvím end-to-end autentizace producentů dat a tranzitivního ověřování kompozitních personálních systémů. Sítě státních kanálů poskytují paralelní podporu pro aplikace a zrychlují doby přijetí, které jsou omezeny tradičním synchronním konsensem v síti inteligentních smluv.
Dva standardní kanály, které jsou „kompatibilní“ prostřednictvím sítě $DAG. Mohou interagovat nebo být interpretovány, protože jsou oba „integrované“ s $DAG nasazením hybridních uzlů $DAG + Channel.
Důvod, proč se nazývá Hylochain, je ten, že náš přístup k podpoře aplikací používal k vytvoření rozhraní MapReduce funkční programovací model Recursion Schemes. Konkrétně lze integrovat schémata rekurze Hylomorphism a Metamorphism pro vytváření ověřitelných dotazů a streamování spojení přes nativní kanály ověřováním algebraických datových typů stejným způsobem, jakým se ověřují operační kódy pro chytré kontrakty. Konečným výsledkem je funkční rozhraní MapReduce, které je známé datovým inženýrům a je kompatibilní se stávající technologií velkých dat.
Hylomorphic a Metamorphic jsou standardní kanály pro kontrast. V metamorfním stavu jsou data ze dvou běžných kanálů odesílána do bloku v metakanálu. V Gilo vezmeme předchozí stav kanálu a použijeme jej k dotazování (položení konkrétní otázky) dvou dalších kanálů a pak uložíme výsledek dotazu do bloku.
Tokenomika a její spojení s Hylochainem
Jakmile je vytvořen nativní kanál, lze jej integrovat do kanálu $DAG, ale pomocí rozhraní ACI nebo aplikačního řetězce. Toto rozhraní je jednoduše objekt JSON s konfiguračními informacemi a veřejným klíčem spojeným se samotným kanálem. Důvod, proč spojujeme veřejný klíč s běžným kanálem, je vytvořit zprostředkovatelský mechanismus pro data běžného kanálu. Když je nasazen běžný kanál, vývojáři sami nakonfigurují, jak jsou platby ze sítě $DAG distribuovány mezi uzly a operátory.
Tok pro nákup přístupu k informacím nebo úpravu informací. Požadavek je odeslán $DAG, prostředky jsou odeslány na účet kanálu, výsledek je zaslán kupujícímu a kontrolní součet transakce je odeslán do sítě $DAG, která pak uvolní prostředky běžnému kanálu.
Zdroj: www.habr.com