Ja viem, ja viem. Existuje veľa krypto projektov, existuje veľa konsenzov: na základe práce a vlastníctva, zlata, ropy, pečených koláčov (jeden je, áno, áno). Čo viac od jedného potrebujeme? Toto navrhujem prediskutovať po prečítaní prekladu „ľahkej“ technickej dokumentácie projektu *Constellation (). Samozrejme, toto nie je úplný popis algoritmu, ale zaujíma ma názor komunity Habr, existuje miesto pre takýto konsenzus, alebo je to zbytočné?
Nie je tam veľa ďalších písmen, takže ak chcete napísať len „wow, o kryptomenách čo najviac“, potom sa prosím zdržte. Ak vás zaujíma nový vývoj v oblasti distribuovaných systémov a máte čo zdieľať v komentároch, potom sa obráťte na kat.
PS Nie som autorom technológie, nemôžem ručiť za úplné odovzdanie podstaty, takže ak nejaké budú, budem rád, ak dostanem pripomienky s pozmeňujúcimi a doplňujúcimi návrhmi.
Vývoj od synchrónneho k asynchrónnemu konsenzu
Uzly sa vyberajú pomocou deterministického procesu (rovnakého, ktorý sa používa v DHT, ako je bittorrent), ktorý dynamicky upravuje zodpovednosti uzlov na „uľahčenie“ validácie alebo, pochopiteľnejšie, na dosiahnutie konsenzu. Vyberieme skupiny 3 uzlov a paralelne spustíme konsenzuálne kolá, takže jeden uzol môže byť facilitátorom vo viacerých blokoch. To nám umožňuje spracovávať transakcie asynchrónne, čo v podstate znamená, že sa vytvára viacero blockchainov súčasne. Proces je ako pavučina, tvorená mnohými vláknami, na rozdiel od uzlov tvoriacich po čase jeden reťazec. Asynchrónne alebo paralelné spracovanie je základom škálovateľného programovania, pretože umožňuje využitie všetkých počítačových zdrojov, čím sa zrýchľuje celkový výpočet. Táto sieť sa v informatike nazýva riadený acyklický graf alebo DAG.
Šírka kanála lineárneho blockchainu verzus multiplikačný efekt DAG, kde máme viacero paralelných blockchainov.
Geometrická implementácia lineárneho blockchainu proti DAG. Čierne bodky sú bloky, biele bodky sú uzly
V každom kole konsenzu používame 3 uzly, pretože nám to dáva niekoľko zaujímavých matematických procesov na uvažovanie o stave, ktoré tvoria „povrchovú rovinu“ naprieč dátami vo forme spojených trojuholníkov. Protokol potom používa trojuholníky na spojenie optimálneho povrchu, ktorý neobsahuje žiadne nadbytočné alebo nekonzistentné údaje a má najmenšie možné trojuholníky. Algoritmicky je to analogické s „minimálnym rezom“ grafu a matematicky je to analogické s derivačnou alebo optimalizačnou funkciou (z ktorej funkcia nájde najkratšiu cestu, ktorú môže prejsť po povrchu). Táto najkratšia cesta je ekvivalentná optimálnemu ukladaniu dát (transakcií) v DAG. Konfliktné trojuholníkové „dlaždice“, aby bol povrch podujatia hladký a bez konfliktov.
Geometrická implementácia detekcie/riešenia konfliktov. Konfliktný blok vytvára dodatočnú povrchovú dlaždicu. Odstránime ďalšie povrchové dlaždice, aby sme zachovali rovný (= bezkonfliktný) povrch podujatia.
Konsenzus založený na reputácii
V optimálnom decentralizovanom systéme reputácie p2p by mal byť každý uzol schopný nezávisle určiť svoju dôveru v ostatné uzly. Náš systém používa pri priraďovaní globálneho skóre špeciálny model, ktorý zahŕňa tranzitívne vzťahy alebo vzťahy, ktoré má uzol s inými uzlami. "Si len taký dobrý ako tvoja spoločnosť." Konečným výsledkom je „skosenie“ alebo gradient založený na tranzitívnej dôvere alebo reputácii vo všetkých uzloch v $DAG alebo bežnom kanáli. Možno si to predstaviť ako kefu alebo strúhadlo na syr, ktoré vymazáva cez „rovinu povrchu“ a vyberá, ktoré „trojuholníkové dlaždice“ sa majú vymazať a ktoré ponechať. Takto logika konfliktov v skutočnosti odstraňuje „trojuholníkové dlaždice“.
DAG s konfliktnou dlaždicou, ktorá prechádza „zakriveným“ priestorom, ktorý je spádom podobným strúhadlu na syr, a odstráni alebo „vymaže“ konfliktnú dlaždicu.
Čiastočné/úplné škálovanie uzla
V teórii siete je optimálna alokácia zvyčajne známa ako „bezškálové“, čo možno opísať ako hierarchické usporiadanie s veľkými centrálnymi uzlami, ktoré spravujú mnoho menších periférnych uzlov. Táto distribúcia je viditeľná v prírode a predovšetkým na internete. Constellation používa túto architektúru na „zmenšenie“ alebo zvýšenie priepustnosti alebo šírky nášho grafu.
Účinok hierarchického rozdelenia. Môžeme pridať ďalšie uzly zvýšením šírky pásma
Hylochain – podpora aplikácií založená na kanáloch
Náš prístup k podpore aplikácií si možno predstaviť ako „decentralizovanú platformu inteligentných zmlúv“. Namiesto centrálnej siete, ktorá prevádzkuje všetku logiku a spracováva všetky údaje z aplikácie, Constellation koordinuje údaje aplikácie s „domácimi kanálmi“, ktoré si možno predstaviť ako televíznu stanicu vysielajúcu všetky údaje z domáceho systému. Každý zamestnanecký kanál môže implementovať svoju vlastnú verifikačnú logiku na vyriešenie problému orákula prostredníctvom end-to-end autentifikácie producentov údajov a prechodného overovania zložených personálnych systémov. Siete štátnych kanálov poskytujú paralelnú podporu pre aplikácie, čím urýchľujú časy prijatia, ktoré sú obmedzené tradičným synchrónnym konsenzom v sieti inteligentných zmlúv.
Dva štandardné kanály, ktoré sú „kompatibilné“ prostredníctvom siete $DAG. Môžu interagovať alebo byť interpretované, pretože sú oba „integrované“ s $DAG nasadením hybridných $DAG + Channel uzlov.
Dôvod, prečo sa nazýva Hylochain, je ten, že náš prístup k podpore aplikácií využíval na vytvorenie rozhrania MapReduce funkčný programovací model Recursion Schemes. Najmä schémy rekurzie Hylomorphism a Metamorphism je možné integrovať na vytváranie overiteľných dotazov a prúdových spojení cez natívne kanály overením algebraických dátových typov rovnakým spôsobom, akým sa overujú operačné kódy pre inteligentné zmluvy. Konečným výsledkom je funkčné rozhranie MapReduce, ktoré poznajú dátoví inžinieri a je kompatibilné s existujúcou technológiou veľkých dát.
Hylomorphic a Metamorphic sú štandardné kanály pre kontrast. V metamorfnom stave sa údaje z dvoch bežných kanálov posielajú do bloku v metakanáli. V Gilo vezmeme predchádzajúci stav kanála a použijeme ho na dopytovanie (položenie konkrétnej otázky) dvoch ďalších kanálov a potom uložíme výsledok dotazu do bloku.
Tokenomika a jej prepojenie s Hylochainom
Po vytvorení natívneho kanála ho možno integrovať do kanála $DAG, ale pomocou rozhrania ACI alebo aplikačného reťazca. Toto rozhranie je jednoducho objekt JSON s konfiguračnými informáciami a verejným kľúčom spojeným so samotným kanálom. Dôvod, prečo spájame verejný kľúč s bežným kanálom, je vytvoriť mechanizmus sprostredkovania pre údaje bežného kanála. Po nasadení bežného kanála si vývojári nakonfigurujú, ako sa platby zo siete $DAG distribuujú medzi uzly a operátormi.
Tok pre nákup prístupu k informáciám alebo úpravu informácií. Požiadavka sa odošle $DAG, prostriedky sa odošlú na účet kanála, výsledok sa odošle kupujúcemu a kontrolný súčet transakcie sa odošle do siete $DAG, ktorá potom uvoľní prostriedky bežnému kanálu.
Zdroj: hab.com