Znam, znam. Ima mnogo kripto projekata, razne vrste konsenzusa: na osnovu rada i vlasništva, zlata, nafte, pa čak i peciva (da, da, to postoji). Što nam još treba od jednog? To predlažem da razgovaramo nakon čitanja prevoda "olakšane" tehničke dokumentacije projekta *Zvezdasti (). Naravno, ovo nije potpuno objašnjenje algoritma, ali me zanima mišljenje zajednice Haba, ima li smisla postojati takvom konsenzusu ili je to nepotrebno?
Nema mnogo slova, pa ako vam se samo čini da treba da napišete "ufu, koliko se može o kriptovalutama", onda vas molim da suzdržite. Ako vas zanimaju nova istraživanja u oblasti distribuiranih sistema i imate šta da podelite u komentarima, slobodno nastavite.
P.S. Nisam autor tehnologije, ne mogu jamčiti za potpunu prenosljivost suštine, zato ću biti zahvalan za komentare sa ispravkama, ako ih bude.
Evolucija od sinhronih konsenzusa ka asinhronim
Čvorovi se biraju koristeći deterministički proces (isti onaj koji se koristi u DHT, na primer, BitTorrent), koji dinamički prilagođava obaveze čvorova za 'olakšavanje' validacije ili, što je razumljivije, postizanje konsenzusa. Biramo grupe od 3 čvora i obavljamo runde konsenzusa paralelno, tako da jedan čvor može biti facilitator u više blokova. Ovo nam omogućava da obradimo transakcije asinhrono, što suštinski znači da se istovremeno formira nekoliko blokčeina. Proces je sličan mreži koju čini mnogo niti, za razliku od čvorova koji formiraju jednu lančanu tokom vremena. Asinhrona ili paralelna obrada osnova je skalabilnog programiranja, jer omogućava korišćenje svih resursa računara, ubrzavajući ukupna izračunavanja. Ova mreža se zove usmereni aciklični graf ili DAG u računarstvu.
Širina kanala linearnih blokčeina naspram multiplicativnog efekta DAG, gde imamo nekoliko paralelnih blokčeina.
Geometrijska realizacija linearnih blokčeina naspram DAG. Crne tačke — to su blokovi, bele tačke — to su čvorovi.
V vsakem krogu soglasja uporabljamo 3 vozlišča, ker nam to omogoča nekatere zanimive matematične procese za razmišljanje o stanju, ki oblikujejo "površinsko območje" čez podatke v obliki trikotnikov s povezavami. Protokol nato uporablja trikotnike za "šivanje" optimalne površine, ki ne vsebuje odvečnih ali nasprotujočih si podatkov ter ima minimalno možno število trikotnikov. Algoritmično je to podobno "minimalnemu prerezu" grafa, matematično pa derivativni ali funkciji optimizacije (pri kateri funkcija najde najkrajšo pot, ki jo lahko prečka po površini). Ta najkrajša pot je enaka optimalnemu shranjevanju podatkov (transakcij) v skupini za zagotavljanje razpoložljivosti podatkovnih baz. Konfliktni trikotniki "ploščice", da površina dogodka ostane gladka in brez konfliktov.
Geometrijska realizacija odkrivanja / obdelave konfliktov. Konfliktni blok ustvari dodatno ploščico površine. Odstranimo dodatno ploščico površine, da ohranimo gladko (= brezkonfliktno) površino dogodkov.
Soglasje, temelječe na ugledu
V optimalnem decentraliziranem p2p sistemu ugleda mora imeti vsako vozlišče možnost samostojno določiti svoje zaupanje do drugih vozlišč. Naš sistem uporablja posebno zasnovan model, ki vključuje tranzitivne odnose ali odnose, ki jih ima vozlišče z drugimi vozlišči, pri dodeljevanju globalne ocene. "Dober si, kolikor je dobra tvoja družba". Končni rezultat je "izkrivljenje" ali gradient, osnovan na tranzitivnem zaupanju ali ugledu med vsemi vozlišči v $DAG ali standardnem kanalu. To lahko gledamo kot ribico ali grater za sir, ki briše površino "površinskega območja" in izbira, katere "trikotne ploščice" obrisati, ter katere ohraniti. Tako logika konflikta dejansko odstrani "trikotne ploščice".
DAG s konfliktno ploščico, ki poteka skozi "ukrivljen" prostor, ki je gradient, podoben graterju za sir, in se nahaja, da odstrani ali "zbriše" konfliktno ploščico.
Delna / popolna razširitev vozlišča
V teoriji omrežij je optimalna razporeditev običajno znana kot "brez skaliranja", kar lahko opišemo kot hierarhično postavitev z velikimi centralnimi vozlišči, ki nadzorujejo mnoga manjša periferna vozlišča. Ta razporeditev je vidna v naravi in, predvsem, na internetu. Constellation uporablja to arhitekturo za "skaliranje", ali povečanje propustnosti ali širine našega Graf.
Učinek hierarhičnega razdeljevanja. Lahko dodamo več vozlišč, kar povečuje širino pasu.
Hylochain - Podpora aplikacijam, temelječim na kanalih
Naš pristop k podpori aplikacij lahko obravnavamo kot "decentralizirano platformo pametnih pogodb". Namesto da bi centralizirana mreža izvajala vso logiko in obdelovala vse podatke iz aplikacije, Constellation usklajuje podatke aplikacije z "državnimi kanali", ki jih lahko obravnavamo kot televizijsko postajo, ki predvaja vse podatke iz državnega sistema. Vsak državni kanal lahko izvaja svojo logiko preverjanja, kar omogoča reševanje problema orakov z verifikacijo pristnosti proizvajalcev podatkov in tranzitivnim preverjanjem sestavljenih državnih sistemov. Mreže državnih kanalov zagotavljajo paralelno podporo aplikacij, kar pospešuje čas odločitve, ki je v omrežju s pametnimi pogodbami omejeno z tradicionalnim sinhronim konsensom.
Dva državna kanala, ki sta "združljiva" prek omrežja $DAG. Lahko medsebojno delujeta ali se interpretirata, saj sta oba "integrirana" z $DAG z uvajanjem hibridnih vozlišč $DAG + Kanal.
Razlog, da se imenuje Hylochain, je v tem, da smo v našem pristopu k podpori aplikacij uporabili funkcijski model programiranja Recursion Schemes za ustvarjanje vmesnika MapReduce. Še posebej se lahko schemi Hylomorphism (Hylomorfizem) in Metamorphism (Metamorfizem) integrirata za ustvarjanje preverljivih poizvedb in tokovnih povezav preko običajnih kanalov s preverjanjem algebrajskih tipov podatkov, tako kot se preverjajo op-kode za pametne pogodbe. Končni rezultat je funkcionalni vmesnik MapReduce, ki je inženirjem podatkov poznan in združljiv z obstoječo tehnologijo velikih podatkov.
Hylomorphic in Metamorphic običajni kanali za kontrast. V metamorfnem stanju se podatki iz dveh običajnih kanalov pošljejo v blok v metakanalu. V Hilo vzamemo prejšnje stanje kanala in ga uporabimo, da zaprosimo (postavimo specifično vprašanje) dva druga kanala, nato pa shranimo rezultat poizvedbe v bloku.
Tokenomika in njen odnos do Hylochain
Ko je običajni kanal ustvarjen, ga je mogoče integrirati v kanal $DAG, vendar z uporabo vmesnika ACI ali Application Chain Interface. Ta vmesnik je preprosto JSON objekt z informacijami o konfiguraciji in javnim ključem, povezanem z samim kanalom. Razlog, da povežemo javni ključ z običajnim kanalom, je ustvarjanje brokerskega mehanizma za podatke običajnega kanala. Ko je običajni kanal nameščen, razvijalci nastavijo sami, kako se plačila iz omrežja $DAG porazdelijo med vozli in operaterji.
Tok za nakup dostopa do informacij ali sprememb informacij. Poizvedba se pošlje v $DAG, sredstva se pošljejo na račun kanala, rezultat je poslan kupcu, kontrolna vsota transakcije pa se pošlje v omrežje $DAG, ki nato odklene sredstva za običajni kanal.
Izvor: habr.com
