Jeg ved, jeg ved. Der er mange kryptoprojekter, der er mange konsensus: baseret på arbejdskraft og ejerskab, guld, olie, bagte tærter (der er en, ja, ja). Hvad mere har vi brug for fra en? Dette er, hvad jeg foreslår at diskutere efter at have læst oversættelsen af den "lette" tekniske dokumentation af *Constellation-projektet (). Selvfølgelig er dette ikke en komplet beskrivelse af algoritmen, men jeg er interesseret i Habr-samfundets mening, er der et sted for sådan en konsensus at "være" eller er det unødvendigt?
Der er ikke mange flere bogstaver, så hvis du bare vil skrive "wow, så meget du kan om krypto", så lad være. Hvis du er interesseret i nye udviklinger inden for distribuerede systemer og har noget at dele i kommentarerne, så henvis venligst til kat.
P.S. Jeg er ikke forfatteren til teknologien, jeg kan ikke stå inde for den fuldstændige overførsel af essensen, så jeg vil med glæde modtage kommentarer med eventuelle ændringer.
Udvikling fra synkron til asynkron konsensus
Noder vælges ved hjælp af en deterministisk proces (den samme, der bruges i DHT'er såsom bittorrent), som dynamisk justerer nodernes ansvar for at "lette" validering eller, mere forståeligt nok, for at opnå konsensus. Vi udvælger grupper af 3 noder og kører konsensusrunder parallelt, så en node kan være facilitator i flere blokke. Dette giver os mulighed for at behandle transaktioner asynkront, hvilket i bund og grund betyder, at vi har flere blockchains, der dannes på samme tid. Processen er som et edderkoppespind, dannet af mange tråde, i modsætning til noder, der danner en enkelt kæde over tid. Asynkron eller parallel behandling er grundlaget for skalerbar programmering, fordi den tillader brugen af alle computerressourcer, hvilket fremskynder den samlede databehandling. Dette netværk kaldes en rettet acyklisk graf eller DAG i datalogi.
Kanalbredden af en lineær blockchain versus den multiplikative effekt af en DAG, hvor vi har flere parallelle blockchains.
Geometrisk implementering af lineær blockchain mod DAG. Sorte prikker er blokke, hvide prikker er noder
Vi bruger 3 noder i hver konsensusrunde, fordi det giver os nogle interessante matematiske processer til at ræsonnere om tilstanden, der danner et "overfladeplan" på tværs af dataene i form af forbundne trekanter. Protokollen bruger derefter trekanter til at sy sammen en optimal overflade, der ikke indeholder overflødige eller inkonsistente data og har de mindst mulige trekanter. Algoritmisk er dette analogt med et "minimumssnit" af en graf, og matematisk er det analogt med en afledt eller optimeringsfunktion (hvorfra funktionen finder den korteste vej, den kan krydse langs overfladen). Denne korteste vej svarer til optimal lagring af data (transaktioner) i en DAG. Modstridende trekantede "fliser", så overfladen af arrangementet er glat og fri for konflikter.
Geometrisk implementering af konfliktdetektering/håndtering. En modstridende blok skaber en ekstra overfladeflise. Vi fjerner yderligere overfladefliser for at opretholde en flad (= konfliktfri) eventoverflade.
Konsensus baseret på omdømme
I et optimalt decentraliseret p2p-omdømmesystem bør hver node selvstændigt kunne bestemme sin tillid til andre noder. Vores system bruger en speciel model, der inkluderer transitive relationer, eller relationer som en node har med andre noder, når der tildeles en global score. "Du er kun så god som dit selskab." Slutresultatet er en "skævhed" eller gradient baseret på transitiv tillid eller omdømme på tværs af alle noder i $DAG eller almindelig kanal. Dette kan opfattes som en børste eller ostehøvl, der sletter hen over et "overfladeplan" og vælger, hvilke "trekantede fliser" der skal slettes, og hvilke der skal forlades. Sådan fjerner konfliktlogik faktisk "trekantede fliser".
En DAG med en modstridende flise, der går gennem et "buet" rum, der er en gradient, der ligner en ostehøvl, og vil fjerne eller "slette" den modstridende flise.
Delvis/fuld nodeskalering
I netværksteori er den optimale allokering typisk kendt som "skalafri", hvilket kan beskrives som et hierarkisk arrangement med store centrale noder, der håndterer mange mindre perifere noder. Denne fordeling er synlig i naturen og frem for alt på internettet. Constellation bruger denne arkitektur til at "skalere ud" eller øge gennemløbet eller bredden af vores graf.
Effekten af hierarkisk opdeling. Vi kan tilføje flere noder ved at øge båndbredden
Hylochain - Kanalbaseret applikationssupport
Vores tilgang til applikationssupport kan opfattes som en "decentraliseret smart kontraktplatform." I stedet for et centralt netværk, der kører al logikken og behandler alle data fra applikationen, koordinerer Constellation applikationsdataene med "huskanaler", som kan opfattes som en tv-station, der udsender alle data fra husets system. Hver personalekanal kan implementere sin egen verifikationslogik for at løse orakelproblemet gennem end-to-end-godkendelse af dataproducenter og transitiv verifikation af sammensatte personalesystemer. Statskanalnetværk giver parallel support til applikationer, hvilket fremskynder adoptionstider, der er begrænset af traditionel synkron konsensus i et smart kontraktnetværk.
To standardkanaler, der er "kompatible" via $DAG-netværket. De kan interagere eller fortolkes, da de begge er "integreret" med $DAG ved at implementere hybrid $DAG + Channel noder.
Grunden til, at det hedder Hylochain, er, fordi vores tilgang til applikationssupport brugte den funktionelle programmeringsmodel Recursion Schemes til at skabe MapReduce-grænsefladen. Især kan hylomorphism og Metamorphism rekursionsskemaer integreres for at skabe verificerbare forespørgsler og streamforbindelser over native kanaler ved at validere algebraiske datatyper på samme måde, som op-koder for smarte kontrakter verificeres. Slutresultatet er en funktionel MapReduce-grænseflade, der er velkendt for dataingeniører og kompatibel med eksisterende big data-teknologi.
Hylomorphic og Metamorphic er standardkanaler til kontrast. I den metamorfe tilstand sendes data fra to almindelige kanaler til en blok i metakanalen. I Gilo tager vi den tidligere tilstand af en kanal og bruger den til at forespørge (stille et specifikt spørgsmål) to andre kanaler og derefter gemme forespørgselsresultatet i en blok.
Tokenomics og dens forbindelse med Hylochain
Når en indbygget kanal er oprettet, kan den integreres i $DAG-kanalen, men ved hjælp af ACI eller Application Chain Interface. Denne grænseflade er simpelthen et JSON-objekt med konfigurationsoplysninger og en offentlig nøgle forbundet med selve kanalen. Grunden til, at vi knytter en offentlig nøgle til en almindelig kanal, er for at skabe en mæglermekanisme for de almindelige kanaldata. Når den almindelige kanal er implementeret, konfigurerer udviklere selv, hvordan betalinger fra $DAG-netværket fordeles mellem noder og operatører.
Flow for køb af adgang til information eller ændring af information. Anmodningen sendes til $DAG, midler sendes til kanalkontoen, resultatet sendes til køberen, og transaktionskontrolsummen sendes til $DAG-netværket, som derefter frigiver midler til den almindelige kanal.
Kilde: www.habr.com