Znam, znam. Mnogo je kripto projekata, ima dosta konsenzusa: na osnovu rada i vlasništva, zlata, ulja, pečenih pita (postoji jedna, da, da). Šta nam više treba od jednog? Ovo je ono o čemu predlažem da razgovaramo nakon čitanja prijevoda "lake" tehničke dokumentacije *Constellation projekta (). Naravno, ovo nije potpuni opis algoritma, ali me zanima mišljenje habrske zajednice, da li postoji mjesto da takav konsenzus „bude“ ili je nepotreban?
Nema puno više slova, pa ako samo želite da napišete „vau, što više o kripto, molimo vas da se suzdržite. Ako ste zainteresovani za nova dostignuća u oblasti distribuiranih sistema i imate šta da podelite u komentarima, obratite se kat.
P.S. Nisam autor tehnologije, ne mogu jamčiti za potpuni prijenos suštine, pa će mi biti drago da dobijem komentare sa amandmanima, ako ih ima.
Evolucija od sinhronih ka asinkronim konsenzusima
Čvorovi se biraju korišćenjem determinističkog procesa (isti onaj koji se koristi u DHT-ovima kao što je bittorrent) koji dinamički prilagođava odgovornosti čvorova da bi „olakšao“ validaciju ili, što je razumljivije, da bi postigao konsenzus. Odabiremo grupe od 3 čvora i paralelno izvodimo krugove konsenzusa tako da jedan čvor može biti fasilitator u više blokova. Ovo nam omogućava da asinhrono obrađujemo transakcije, što u suštini znači da imamo više blokova koji se formiraju u isto vrijeme. Proces je poput paukove mreže, formirane od mnogih niti, za razliku od čvorova koji formiraju jedan lanac tokom vremena. Asinhrona ili paralelna obrada je osnova skalabilnog programiranja jer omogućava korištenje svih računarskih resursa, ubrzavajući cjelokupno računanje. Ova mreža se u računarskoj nauci naziva usmjereni aciklični graf ili DAG.
Širina kanala linearnog blockchaina naspram multiplikativnog efekta DAG-a gdje imamo više paralelnih blockchaina.
Geometrijska implementacija linearnog blockchaina u odnosu na DAG. Crne tačke su blokovi, bele tačke su čvorovi
Koristimo 3 čvora u svakom krugu konsenzusa jer nam daje neke zanimljive matematičke procese za razmišljanje o stanju, formirajući “površinsku ravan” preko podataka u obliku povezanih trokuta. Protokol zatim koristi trokute da spoji optimalnu površinu koja ne sadrži suvišne ili nekonzistentne podatke i ima najmanje moguće trokute. Algoritamski, ovo je analogno „minimalnom rezu” grafa, a matematički je analogno derivaciji ili optimizacijskoj funkciji (iz koje funkcija pronalazi najkraći put koji može preći duž površine). Ovaj najkraći put je ekvivalentan optimalnom pohranjivanju podataka (transakcija) u DAG-u. Konfliktne trouglaste „pločice“ tako da površina događaja bude glatka i bez sukoba.
Geometrijska implementacija detekcije/upravljanja konfliktom. Konfliktni blok stvara dodatnu površinsku pločicu. Uklanjamo dodatne površinske pločice kako bismo održali ravnu (= beskonfliktnu) površinu događaja.
Konsenzus zasnovan na reputaciji
U optimalnom decentralizovanom p2p sistemu reputacije, svaki čvor bi trebao biti u mogućnosti da samostalno odredi svoje povjerenje u druge čvorove. Naš sistem koristi poseban model koji uključuje tranzitivne odnose, ili odnose koje čvor ima sa drugim čvorovima, kada se dodjeljuje globalni rezultat. „Dobar si samo onoliko koliko ti je društvo.” Krajnji rezultat je "iskrivljenost" ili gradijent zasnovan na tranzitivnom povjerenju ili reputaciji u svim čvorovima u $DAG ili redovnom kanalu. Ovo se može smatrati četkom ili rende za sir koji briše preko "površinske ravni" i bira koje "trokutaste pločice" želite izbrisati, a koje ostaviti. Ovako konfliktna logika zapravo uklanja “trokutaste pločice”.
DAG sa konfliktnom pločicom prolazi kroz „zakrivljeni“ prostor koji je gradijent, sličan ribanju za sir, i uklanja ili „izbriše“ konfliktnu pločicu.
Djelomično/potpuno skaliranje čvora
U teoriji mreža, obično je optimalna alokacija poznata kao „bez skale“, što se može opisati kao hijerarhijski raspored sa velikim centralnim čvorovima koji upravljaju mnogim manjim perifernim čvorovima. Ova distribucija je vidljiva u prirodi i prije svega na internetu. Constellation koristi ovu arhitekturu za "skaliranje" ili povećanje propusnosti ili širine našeg grafikona.
Učinak hijerarhijske particije. Možemo dodati više čvorova povećanjem propusnog opsega
Hylochain - Podrška aplikacija zasnovana na kanalima
Naš pristup podršci aplikacijama može se smatrati „decentralizovanom platformom pametnih ugovora“. Umjesto centralne mreže koja pokreće svu logiku i obrađuje sve podatke iz aplikacije, Constellation koordinira podatke aplikacije sa "kućnim kanalima", koji se mogu smatrati televizijskom stanicom koja emituje sve podatke iz kućnog sistema. Svaki kanal osoblja može implementirati svoju vlastitu logiku verifikacije kako bi riješio problem orakula kroz end-to-end autentifikaciju proizvođača podataka i tranzitivnu verifikaciju kompozitnih sistema osoblja. Mreže državnih kanala pružaju paralelnu podršku za aplikacije, ubrzavajući vrijeme usvajanja koje je ograničeno tradicionalnim sinhronim konsenzusom u mreži pametnih ugovora.
Dva standardna kanala koja su “kompatibilna” preko $DAG mreže. Oni mogu biti u interakciji ili se tumače jer su oboje „integrirani“ sa $DAG primjenom hibridnih $DAG + Channel čvorova.
Razlog zbog kojeg se zove Hylochain je taj što je naš pristup podršci aplikacija koristio funkcionalni model programiranja Rekurzivne šeme za kreiranje MapReduce interfejsa. Konkretno, sheme rekurzije hilomorfizma i metamorfizma mogu se integrirati za kreiranje provjerljivih upita i stream veza preko izvornih kanala provjeravanjem 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.
Hylomorphic i Metamorphic su standardni kanali za kontrast. U metamorfnom stanju, podaci iz dva regularna kanala se šalju u blok u metakanalu. U Gilo-u, 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 njena veza sa Hylochainom
Jednom kada se kreira izvorni kanal, može se integrirati u $DAG kanal, ali koristeći ACI ili sučelje lanca aplikacija. Ovaj interfejs je jednostavno JSON objekat sa konfiguracionim informacijama i javnim ključem povezanim sa samim kanalom. Razlog zašto povezujemo javni ključ sa redovnim kanalom je stvaranje mehanizma za posredovanje za podatke redovnog kanala. Kada se postavi regularni kanal, programeri sami konfigurišu kako se uplate iz $DAG mreže distribuiraju između čvorova i operatera.
Tok za kupovinu pristupa informacijama ili modifikacija informacija. Zahtjev se šalje na $DAG, sredstva se šalju na račun kanala, rezultat se šalje kupcu, a kontrolna suma transakcije se šalje u $DAG mrežu, koja zatim oslobađa sredstva na redovni kanal.
izvor: www.habr.com