Jeg ved, jeg ved. Der er mange kryptoprojekter, og der findes et væld af konsensus: baseret på arbejde og ejerskab, guld, olie, bagte tærter (ja, der er faktisk også sådan et, ja-ja). Hvad mere får vi ud af ét mere? Det er det, jeg foreslår, vi diskuterer efter at have læst oversættelsen af den "lettede" tekniske dokumentation for projektet *Constellation (). Selvfølgelig er det ikke en fuldstændig beskrivelse af algoritmen, men jeg er interesseret i communityets mening på habra, om sådan et konsensus har sin berettigelse, eller om det er unødvendigt?
Der er ikke mange bogstaver tilbage, så hvis du bare har lyst til at skrive "æh, hvor meget kan man tale om krypto", så bedes du undlade det. Hvis du er interesseret i nye udviklinger inden for distribuerede systemer og har noget at dele i kommentarerne, så vil jeg gerne have dig til at fortsætte.
P.S. Jeg er ikke teknologens skaber, jeg kan ikke garantere for den fulde overførsel af essensen, så jeg vil være glad for kommentarer med rettelser, hvis der er nogen.
Udviklingen fra synkrone konsensus til asynkrone
Noder vælges ved hjælp af en deterministisk proces (den samme, der anvendes i DHT, såsom bittorrent), som dynamisk regulerer noderne ansvar for at "lette" valideringen, eller mere forståeligt, for at nå til konsensus. Vi vælger grupper af 3 noder og udfører konsensus-runder parallelt, så én node kan fungere som facilitator i flere blokke. Dette gør det muligt for os at behandle transaktioner asynkront, hvilket i bund og grund betyder, at vi har flere blokchain, der dannes samtidig. Processen ligner et netværk, der dannes af mange tråde, i modsætning til noder, der former en enkelt kæde over tid. Asynkron eller parallel behandling er grundlaget for skalerbar programmering, da det muliggør maksimal udnyttelse af computerens ressourcer, hvilket fremskynder de samlede beregninger. Dette netværk kaldes en rettet acyklisk graf eller DAG inden for datalogi.
Bredde af linær blockchain kontra multiplikativ effekt af DAG, hvor vi har flere parallelle blockchain.
Geometrisk repræsentation af linær blockchain versus DAG. De sorte punkter er blokke, de hvide punkter er noder.
Vi bruger 3 noder i hver runde af konsensus, fordi det giver os nogle interessante matematiske processer til at overveje tilstanden, idet vi danner en "overfladeplan" på tværs af dataene i form af trekanter med forbindelser. Derefter bruger protokollen trekanterne til at "sy" den optimale overflade, som ikke indeholder overflødige eller modstridende data og har så få trekanter som muligt. Algoritmisk set svarer dette til et "minimum cut" af grafen, og matematisk set er det en afledt funktion eller en optimeringsfunktion (hvor funktionen finder den korteste vej, den kan krydse over overfladen). Denne korteste vej svarer til optimal opbevaring af data (transaktioner) i en database med høj tilgængelighed. Modstridende trekantede "fliser" sikrer, at begivenhedsoverfladen er flad og uden konflikter.
Geometrisk implementering af opdagelse / behandling af konflikter. En konfliktfyldt blok skaber en ekstra overfladeflise. Vi fjerner den ekstra overfladeflise for at opretholde en flad (= konfliktfri) begivenhedsoverflade.
Konsensus baseret på omdømme
I et optimalt decentraliseret p2p-reputationssystem skal hver node have mulighed for selv at vurdere sin tillid til andre noder. Vores system bruger en specialmodel, der inkluderer transitiv relationer eller relationer, som en node har med andre noder, når der tildeles en global vurdering. "Du er kun så god som dit selskab." Det endelige resultat er en "forvridning" eller gradient, baseret på transitiv tillid eller omdømme blandt alle noder i $DAG eller den etablerede kanal. Dette kan ses som en rive eller ostekniv, der visker over "overfladeplanen" og vælger, hvilke "trekantede fliser" der skal slettes, og hvilke der skal bevares. Det er sådan, konflikten faktisk fjerner "trekantede fliser".
DAG med en konfliktfyldt flise, der går gennem et "forvrænget" rum, som er en gradient, der ligner en ostekniv, og er klar til at fjerne eller "slette" den konfliktfyldte flise.
Delvis / fuld skalering af node
I teori om netværk er den optimale fordeling typisk kendt som "uden skalering", som kan beskrives som en hierarkisk placering med store centrale noder, der styrer mange mindre perifere noder. Denne fordeling kan ses i naturen og især på internettet. Constellation bruger denne arkitektur til "skalering", eller øgning af båndbredden eller bredden af vores Graf.
Effekten af hierarkisk opdeling. Vi kan tilføje flere noder ved at øge båndbredden.
Hylochain - Understøttelse af applikationer baseret på kanaler
Vores tilgang til applikationsunderstøttelse kan ses som en "Decentraliseret platform for smarte kontrakter". I stedet for et centralt netværk, der håndterer al logik og data fra applikationen, koordinerer Constellation applikationsdata med "stationære kanaler", som kan betragtes som en tv-station, der transmitterer alle data fra det stationære system. Hver stationær kanal kan implementere sin egen logik for validering, hvilket muliggør løsning af oracle-problemet ved hjælp af end-to-end autenticitet af dataleverandører og transitive validering af sammensatte stationære systemer. Netværk af stationære kanaler giver parallel applikationsunderstøttelse og fremskynder behandlingstiden, som i netværk med smarte kontrakter er begrænset af den traditionelle synkrone konsensus.
To stationære kanaler, som er "kompatible" gennem netværket $DAG. De kan interagere eller fortolkes, da begge er "integreret" med $DAG ved at implementere hybride noder $DAG + Kanal.
Årsagen til, at det hedder Hylochain, er, at vi i vores tilgang til applikationssupport har anvendt den funktionelle programmeringsmodel Recursion Schemes til at skabe et MapReduce-grænseflade. Især kan Hylomorphism (Hylomorfisk) og Metamorphism (Metamorfisk) rekursionsschemer integreres for at skabe verificerbare forespørgsler og strømforbindelser via statuteskanaler ved at kontrollere algebraiske datatyper på samme måde, som op-koder kontrolleres for smarte kontrakter. Det endelige resultat er et funktionelt MapReduce-grænseflade, som er velkendt blandt dataingeniører og kompatibelt med eksisterende big data-teknologi.
Hylomorphic og Metamorphic statuteskanaler for kontrast. I den metamorfiske tilstand sendes data fra de to statuteskanaler til en blok i metakanalen. I Hilo tager vi den tidligere tilstand af kanalen og bruger den til at anmode om (stille et specifikt spørgsmål) to andre kanaler, og gemmer derefter forespørgselsresultatet i blokken.
Tokenomics og dens forbindelse til Hylochain
Når en statuteskanal er oprettet, kan den integreres i kanalen $DAG, men ved hjælp af ACI-grænsefladen eller Application Chain Interface. Denne grænseflade er blot et JSON-objekt med konfigurationsinformation og en offentlig nøgle, der er knyttet til selve kanalen. Årsagen til, at vi knytter den offentlige nøgle til statuteskanalen, er at skabe en brokvægningsmekanisme til dataene fra statuteskanalen. Når statuteskanalen er implementeret, konfigurerer udviklerne selv, hvordan betalinger fra $DAG-netværket distribueres mellem noder og operatører.
Strøm til at købe adgang til information eller ændre information. Forespørgslen sendes til $DAG, midlerne sendes til kanalens konto, resultatet sendes til køberen, og transaktionens kontrolsum sendes til $DAG-netværket, som derefter låser midlerne for statuteskanalen.
Kilde: habr.com
