Ja znam ja znam. Puno je kripto projekata, puno je konsenzusa: na temelju rada i vlasništva, zlata, ulja, pečenih pita (ima jedan, da, da). Što nam više treba od jednog? O tome predlažem raspravu nakon čitanja prijevoda "lake" tehničke dokumentacije projekta *Constellation (). Naravno, ovo nije potpuni opis algoritma, ali me zanima mišljenje Habr zajednice, postoji li mjesto za takav konsenzus "biti" ili je nepotreban?
Nema više slova, pa ako samo želite napisati "vau, koliko god možete o kriptovaluti", suzdržite se. Ako ste zainteresirani za nova dostignuća u području distribuiranih sustava i imate što podijeliti u komentarima, onda se obratite kat.
PS Ja nisam autor tehnologije, ne mogu jamčiti za potpuni prijenos suštine, pa će mi biti drago primiti komentare s izmjenama, ako ih bude.
Evolucija od sinkronih do asinkronih konsenzusa
Čvorovi se biraju pomoću determinističkog procesa (istog onog koji se koristi u DHT-ovima kao što je bittorrent) koji dinamički prilagođava odgovornosti čvorova kako bi se "olakšala" provjera valjanosti ili, što je razumljivije, kako bi se postigao konsenzus. Odabiremo grupe od 3 čvora i paralelno izvodimo runde konsenzusa tako da jedan čvor može biti moderator u više blokova. To nam omogućuje asinkronu obradu transakcija, što u biti znači da imamo više blockchaina koji se formiraju u isto vrijeme. Proces je poput paukove mreže koju čine mnoge niti, za razliku od čvorova koji tijekom vremena tvore jedan lanac. Asinkrona ili paralelna obrada osnova je skalabilnog programiranja jer omogućuje korištenje svih resursa računala, ubrzavajući sveukupno računalstvo. Ova mreža se u informatici naziva usmjereni aciklički graf ili DAG.
Širina kanala linearnog blockchaina u odnosu na multiplikativni učinak DAG-a gdje imamo više paralelnih blockchaina.
Geometrijska implementacija linearnog blockchaina protiv DAG-a. Crne točke su blokovi, bijele točke su čvorovi
Koristimo 3 čvora u svakom krugu konsenzusa jer nam to daje neke zanimljive matematičke procese za razmišljanje o stanju, tvoreći "površinu" preko podataka u obliku povezanih trokuta. Protokol zatim koristi trokute za spajanje optimalne površine koja ne sadrži suvišne ili nedosljedne podatke i ima najmanje moguće trokute. Algoritamski, to je analogno "minimalnom rezu" grafa, a matematički, analogno je derivaciji ili optimizacijskoj funkciji (iz koje funkcija pronalazi najkraći put koji može prijeći duž površine). Ovaj najkraći put je ekvivalentan optimalnom pohranjivanju podataka (transakcija) u DAG. Konfliktne trokutaste "pločice" tako da je površina događaja glatka i bez sukoba.
Geometrijska implementacija otkrivanja/rukovanja sukobima. Sukobni blok stvara dodatnu površinsku pločicu. Uklanjamo dodatne površinske pločice kako bismo održali ravnu (= bez sukoba) površinu događaja.
Konsenzus temeljen na reputaciji
U optimalnom decentraliziranom p2p sustavu reputacije, svaki bi čvor trebao moći samostalno odrediti svoje povjerenje u druge čvorove. Naš sustav koristi poseban model koji uključuje tranzitivne odnose, odnosno odnose koje čvor ima s drugim čvorovima, prilikom dodjele globalne ocjene. “Dobar si onoliko koliko je dobra tvoja tvrtka.” Krajnji rezultat je "iskrivljenost" ili gradijent temeljen na tranzitivnom povjerenju ili reputaciji u svim čvorovima u $DAG ili regularnom kanalu. Ovo se može zamisliti kao četka ili ribež za sir koji briše preko "površinske ravnine" i odabire koje će "trokutaste pločice" obrisati, a koje ostaviti. Ovako konfliktna logika zapravo uklanja "trokutaste pločice".
DAG s proturječnom pločicom prolazi kroz "zakrivljeni" prostor koji je gradijent, sličan ribežu za sir, i uklonit će ili "izbrisati" proturječnu pločicu.
Djelomično/puno skaliranje čvora
U teoriji mreža, obično je optimalna raspodjela poznata kao "bez razmjera", što se može opisati kao hijerarhijski raspored s velikim središnjim čvorovima koji upravljaju mnogo manjih perifernih čvorova. Ova distribucija vidljiva je u prirodi i prije svega na internetu. Constellation koristi ovu arhitekturu za "razmjerno smanjivanje" ili povećanje propusnosti ili širine našeg grafikona.
Učinak hijerarhijske particije. Možemo dodati više čvorova povećanjem propusnosti
Hylochain - Podrška aplikacija temeljena na kanalu
Naš pristup podršci aplikacijama može se smatrati "decentraliziranom platformom za pametne ugovore". Umjesto središnje mreže koja pokreće svu logiku i obrađuje sve podatke iz aplikacije, Constellation koordinira podatke aplikacije s "kućnim kanalima", koji se mogu zamisliti kao televizijska postaja koja emitira sve podatke iz kućnog sustava. Svaki kanal osoblja može implementirati vlastitu logiku provjere kako bi riješio problem oraclea kroz end-to-end provjeru autentičnosti proizvođača podataka i tranzitivnu provjeru kompozitnih sustava osoblja. Mreže državnih kanala pružaju paralelnu podršku za aplikacije, ubrzavajući vrijeme usvajanja koje je ograničeno tradicionalnim sinkronim konsenzusom u mreži pametnih ugovora.
Dva standardna kanala koji su "kompatibilni" preko $DAG mreže. Oni mogu komunicirati ili se tumačiti jer su oboje "integrirani" s $DAG-om uvođenjem hibridnih čvorova $DAG + Channel.
Razlog zbog kojeg se zove Hylochain je taj što je naš pristup podršci aplikacijama koristio funkcionalni programski model Recursion Schemes za stvaranje sučelja MapReduce. Konkretno, sheme rekurzije Hylomorphism i Metamorphism mogu se integrirati za stvaranje provjerljivih upita i strujnih veza preko izvornih kanala potvrđivanjem algebarskih tipova podataka na isti način na koji se provjeravaju operativni kodovi za pametne ugovore. Krajnji rezultat je funkcionalno sučelje MapReduce koje je poznato inženjerima podataka i kompatibilno s postojećom tehnologijom velikih podataka.
Hilomorfni i metamorfni su standardni kanali za kontrast. U metamorfnom stanju, podaci iz dva regularna kanala šalju se u blok u metakanalu. U Gilou uzimamo prethodno stanje kanala i koristimo ga za upit (postavljanje određenog pitanja) dva druga kanala, a zatim pohranjujemo rezultat upita u blok.
Tokenomika i njezina povezanost s Hylochainom
Jednom kada se izvorni kanal stvori, može se integrirati u $DAG kanal, ali koristeći ACI ili Application Chain Interface. Ovo sučelje jednostavno je JSON objekt s informacijama o konfiguraciji i javnim ključem povezanim sa samim kanalom. Razlog zašto pridružujemo javni ključ redovnom kanalu je stvaranje mehanizma posredovanja za podatke redovnog kanala. Kada se regularni kanal implementira, programeri sami konfiguriraju kako se plaćanja iz $DAG mreže distribuiraju između čvorova i operatera.
Tijek za kupnju pristupa informacijama ili izmjene informacija. Zahtjev se šalje $DAG-u, sredstva se šalju na račun kanala, rezultat se šalje kupcu, a kontrolni zbroj transakcije šalje se $DAG mreži, koja zatim oslobađa sredstva u uobičajeni kanal.
Izvor: www.habr.com