Vím, vím. Kryptoprojektů je spousta, existuje hromada konsensů: na základě práce a vlastnictví, zlata, ropy, upečených koláčků (ano, i takový existuje). Co nám ještě přidá jeden navíc? To bych rád prodiskutoval po přečtení překladu "zjednodušené" technické dokumentace projektu *Souhvězdí (). Samozřejmě, že to není úplný popis algoritmu, ale zajímá mě názor komunity Habra, zda takový konsensus má smysl, nebo je zbytečný?
Dál už není moc písmen, takže pokud máte chuť napsat "fuj, už tolik o krypto", prosím, zdržte se. Pokud vás zajímají nové vývoje v oblasti distribuovaných systémů a máte o čem se podělit v komentářích, prosím, pokračujte dále.
P.S. Nejsem autor technologie, za plné pochopení podstaty nemohu ručit, budu tedy rád za komentáře s opravami, pokud nějaké budou.
Evoluce od synchronních konsensů k asynchronním
Uzly jsou vybírány pomocí deterministického procesu (toho samého, který se používá v DHT, například bittorrent), který dynamicky reguluje povinnosti uzlů pro "usnadnění" validace, nebo jinak řečeno, pro dosažení konsensu. Vybíráme skupiny z 3 uzlů a provádíme kola konsensu paralelně, aby jeden uzel mohl být facilitátorem v několika blocích. To nám umožňuje zpracovávat transakce asynchronně, což v podstatě znamená, že se formují několik blockchainů zároveň. Proces je podobný pavučině vytvořené mnoha vlákny, na rozdíl od uzlů, které vytvářejí jednu řetězovou formu během času. Asynchronní nebo paralelní zpracování je základním kamenem škálovatelného programování, neboť umožňuje využít všechny zdroje počítače a zrychlit celková výpočty. Tato síť se nazývá orientovaný acyklický graf nebo DAG v počítačových vědách.
Šířka kanálu lineárního blockchainu versus multiplikační efekt DAG, kde máme několik paralelních blockchainů.
Geometrická realizace lineárního blockchainu versus DAG. Černé tečky jsou bloky, bílé tečky jsou uzly.
Používáme 3 uzly v každém kole konsensu, protože to nám poskytuje zajímavé matematické procesy pro úvahy o stavu, vytvářející "rovinu povrchu" napříč daty ve formě trojúhelníků se vazbami. Protokol poté používá trojúhelníky k "sešívání" optimálního povrchu, který neobsahuje nadbytečná nebo protichůdná data a má minimální možné trojúhelníky. Algoritmicky to odpovídá "minimálnímu řezu" grafu a matematicky je to derivace nebo optimalizační funkce (z níž funkce nachází nejkratší cestu, kterou může pře-cross přes povrch). Tato nejkratší cesta je ekvivalentní optimálnímu ukládání dat (transakcí) ve skupině zajistit datové dostupnosti. Konfliktní trojúhelníkové "dlaždice" zajišťují, že povrch události je hladký a bez konfliktů.
Geometrická realizace detekce / zpracování konfliktů. Konfliktní blok vytváří další dlaždici povrchu. Odstraňujeme dlaždici dodatečného povrchu, abychom udrželi plochý (= bezkonfliktní) povrch událostí.
Konsensus založený na reputaci
V optimálním decentralizovaném p2p systému reputace by každý uzel měl mít možnost samostatně posoudit svou důvěru k ostatním uzlům. Náš systém používá speciální model, který zahrnuje tranzitivní vztahy nebo vztahy, které má uzel s jinými uzly, při přiřazení globálního hodnocení. "Jste tak dobří, jaká je vaše společnost." Konečným výsledkem je "zkreslení" nebo gradient vycházející z tranzitivní důvěry nebo reputace ve všech uzlech v $DAG nebo standardním kanálu. To lze považovat za struhadlo nebo bruskou na sýr, které setí povrch "roviny povrchu" a vybírá, které "trojúhelníkové dlaždice" setřít a které nechat. Takto logika konfliktu ve skutečnosti odstraňuje "trojúhelníkové dlaždice".
DAG s konfliktní dlaždicí procházející "zkresleným" prostorem, který je gradientem podobným struhadlu na sýr, a připravuje se na odstranění nebo "setření" konfliktní dlaždice.
Částečné / úplné škálování uzlu
V teorii sítí je optimální rozložení obvykle označováno jako „bez škálování“, což lze popsat jako hierarchické uspořádání s velkými centrálními uzly, které spravují mnohé menší periferní uzly. Toto rozložení je viditelné v přírodě a především na internetu. Constellation používá tuto architekturu pro „škálování“, neboli zvyšování propustnosti nebo šířky našeho Grafu.
Efekt hierarchického dělení. Můžeme přidat více uzlů, čímž zvýšíme šířku propustnosti.
Hylochain — Podpora aplikací založených na kanálech.
Náš přístup k podpoře aplikací lze považovat za „decentralizovanou platformu chytrých smluv“. Místo centrální sítě, která vykonává veškerou logiku a zpracovává všechna data z aplikace, Constellation koordinuje data aplikace pomocí „státních kanálů“, které lze považovat za televizní stanici, vysílající všechna data ze státního systému. Každý státní kanál může implementovat svou vlastní logiku ověřování, což umožňuje řešit problém oracle skrze důkladnou verifikaci výrobců dat a tranzitivní ověřování složených státních systémů. Sítě státních kanálů poskytují paralelní podporu aplikací, čímž urychlují čas akceptace, který je v síti chytrých smluv omezen tradičním synchronním konsensem.
Dva státní kanály, které jsou „kompatibilní“ přes síť $DAG. Mohou interagovat nebo být interpretovány, neboť oba jsou „integrované“ s $DAG prostřednictvím nasazení hybridních uzlů $DAG + Kanál.
Důvod, proč se to nazývá Hylochain, spočívá v tom, že v našem přístupu k podpoře aplikací byla použita funkční model programování Recursion Schemes pro vytvoření rozhraní MapReduce. Zejména mohou být schémata rekursivního Hylomorphismu a Metamorphismu integrována pro vytváření verifikovatelných dotazů a streamových spojení přes standardní kanály tím, že se kontrolují algebraické datové typy stejně jako se kontrolují op-kódy pro chytré kontrakty. Konečným výsledkem je funkční rozhraní MapReduce, které je známo datovým inženýrům a je kompatibilní se stávajícími technologiemi velkých dat.
Hylomorfní a metamorfní standardní kanály pro kontrast. Ve metamorfním stavu jsou data z obou standardních kanálů odesílána do bloku v metakanálu. V Hylu bereme předchozí stav kanálu a použijeme ho k dotazu (vložíme konkrétní otázku) na další dva kanály, a poté ukládáme výsledek dotazu do bloku.
Tokenomika a její spojení s Hylochain
Když je standardní kanál vytvořen, může být integrován do kanálu $DAG, ale s použitím rozhraní ACI neboli Application Chain Interface. Toto rozhraní je prostě objekt JSON s informacemi o konfiguraci a veřejným klíčem spojeným s tímto kanálem. Důvod, proč spojujeme veřejný klíč se standardním kanálem, spočívá v vytvoření zprostředkovatelského mechanismu pro data standardního kanálu. Když je standardní kanál nasazen, vývojáři si sami nastavují, jak se platby z $DAG sítě distribuují mezi uzly a operátory.
Tok pro nákup přístupu k informacím nebo modifikaci informací. Dotaz je směrován do $DAG, prostředky jsou zaslány na účet kanálu, výsledek je zaslán kupujícímu a kontrolní součet transakce je zaslán do sítě $DAG, která pak uvolňuje prostředky pro standardní kanál.
Zdroj: habr.com
