Denne teksten er en fortsettelse av en serie artikler der jeg undersøker strukturen til det (antagelig) distribuerte nettverket Telegram Open Network (TON), som forberedes for utgivelse i år. I Jeg beskrev det mest grunnleggende nivået - måten noder samhandler med hverandre.
Bare i tilfelle, la meg minne deg på at jeg ikke har noe å gjøre med utviklingen av dette nettverket, og alt materialet ble hentet fra en åpen (om enn ubekreftet) kilde - (det er også en medfølgende , som kort skisserer hovedpunktene), som dukket opp på slutten av fjoråret. Mengden informasjon i dette dokumentet indikerer etter min mening dets autentisitet, selv om det ikke er noen offisiell bekreftelse på dette.
I dag skal vi se på hovedkomponenten i TON - blokkjeden.
Enkle konsepter
Konto (konto). Et sett med data identifisert av et 256-biters tall konto-ID (oftest er dette den offentlige nøkkelen til kontoeieren). I grunntilfellet (se nedenfor null arbeidskjede), refererer disse dataene til brukerens saldo. "Occupy"-spesifikk konto-ID alle kan, men verdien kan bare endres i henhold til visse regler.
Smart kontrakt (smart-kontrakt). I hovedsak er det et spesielt tilfelle av en konto, supplert med smart kontraktskode og lagring av variablene. Hvis du i tilfelle av en "lommebok" kan sette inn og ta ut penger fra den i henhold til relativt enkle og forhåndsbestemte regler, så i tilfelle av en smart kontrakt er disse reglene skrevet i form av dens kode (i en viss Turing-komplett programmeringsspråk).
Blockchain-stat (tilstanden til blokkjede). Settet med tilstander for alle kontoer/smarte kontrakter (i abstrakt forstand, en hashtabell, der nøklene er kontoidentifikatorer og verdiene er dataene som er lagret i kontoene).
Beskjed (melding). Ovenfor brukte jeg uttrykket "kreditt- og debetpenger" - dette er et spesielt eksempel på en melding ("overføring" N gram fra konto konto_1 til konto konto_2"). Det er klart at bare noden som eier kontoens private nøkkel kan sende en slik melding konto_1 - og kan bekrefte dette med en signatur. Resultatet av å levere slike meldinger til en vanlig konto er en økning i saldoen, og resultatet av den smarte kontrakten er utførelse av koden (som vil behandle mottak av meldingen). Selvfølgelig er andre meldinger også mulige (overføring ikke pengebeløp, men vilkårlige data mellom smarte kontrakter).
Transaksjon (Transaksjonen). Det at en melding blir levert kalles en transaksjon. Transaksjoner endrer tilstanden til blokkjeden. Det er transaksjoner (postleveringsposter) som utgjør blokkene i blokkjeden. I denne forbindelse kan du tenke på tilstanden til blokkjeden som en inkrementell database - alle blokker er "diffs" som må brukes sekvensielt for å få den nåværende tilstanden til databasen. Spesifikasjonene for å pakke disse "diffene" (og gjenopprette den fullstendige tilstanden fra dem) vil bli diskutert i neste artikkel.
Blockchain i TON: hva er det og hvorfor?
Som nevnt i forrige artikkel, blokkkjede er en datastruktur, hvis elementer (blokker) er ordnet i en "kjede", og hver påfølgende blokk i kjeden inneholder en hash av den forrige. Kommentarene stilte spørsmålet: hvorfor trenger vi i det hele tatt en slik datastruktur når vi allerede har en DHT - en distribuert hashtabell? Det er klart at noen data kan lagres i DHT, men dette er kun egnet for ikke for "sensitiv" informasjon. Saldoer i kryptovaluta kan ikke lagres i DHT – først og fremst på grunn av manglende kontroller på integritet. Faktisk vokser hele kompleksiteten til blokkjedestrukturen for å forhindre forstyrrelse av dataene som er lagret i den.
Imidlertid ser blokkjeden i TON enda mer kompleks ut enn i de fleste andre distribuerte systemer – og av to grunner. Den første er ønsket om å minimere behovet for gafler. I tradisjonelle kryptovalutaer settes alle parametere i det innledende stadiet, og ethvert forsøk på å endre dem fører faktisk til fremveksten av et "alternativt kryptovalutaunivers." Den andre grunnen er støtte for knusing (skjæring, skjæring) blokkjede. Blockchain er en struktur som ikke kan bli mindre over tid; og vanligvis blir hver node som er ansvarlig for driften av nettverket tvunget til å lagre den fullstendig. I tradisjonelle (sentraliserte) systemer brukes sharding for å løse slike problemer: noen av postene i databasen ligger på en server, noen på en annen osv. Når det gjelder kryptovalutaer, er slik funksjonalitet fortsatt ganske sjelden – spesielt på grunn av det faktum at det er vanskelig å legge til sharding i et system der det ikke opprinnelig var planlagt.
Hvordan planlegger TON å løse begge de ovennevnte problemene?
Blockchain-innhold. Arbeidskjeder.
Først av alt, la oss snakke om hva som er planlagt lagret i blokkjeden. Kontotilstandene («lommebøker» i basistilfellet) og smarte kontrakter vil bli lagret der (for enkelhets skyld vil vi anta at dette er det samme som kontoer). I hovedsak vil dette være en vanlig hash-tabell - nøklene i den vil være identifikatorer konto-ID, og verdier er datastrukturer som inneholder slike ting som:
- balansere;
- smart kontraktkode (kun for smarte kontrakter);
- datalagring for smart kontrakt (kun for smarte kontrakter);
- statistikk;
- (valgfritt) offentlig nøkkel for overføringer fra kontoen, som standard account_id;
- kø av utgående meldinger (her legges de inn for videresending til mottaker);
- en liste over de siste meldingene levert til denne kontoen.
Som nevnt ovenfor består blokkene i seg selv av transaksjoner - meldinger levert til ulike account_id-kontoer. Men i tillegg til account_id inneholder meldinger også et 32-bits felt workchain_id — såkalt identifikator arbeidskjede (arbeidskjede, fungerende blokkjede). Dette lar deg ha flere blokkjeder uavhengig av hverandre med forskjellige konfigurasjoner. I dette tilfellet anses workchain_id = 0 som et spesialtilfelle, null arbeidskjede — det er saldoene i den som vil tilsvare TON (Grams) kryptovaluta. Mest sannsynlig vil andre arbeidskjeder til å begynne med ikke eksistere i det hele tatt.
Shardchains. Infinite Sharding Paradigm.
Men veksten i antall blokkjeder stopper ikke der. La oss håndtere skjæring. La oss forestille oss at hver konto (account_id) er tildelt sin egen blokkjede – den inneholder alle meldingene som kommer til den – og tilstandene til alle slike blokkkjeder lagres på separate noder.
Selvfølgelig er dette veldig bortkastet: mest sannsynlig i hver av disse shardchains (shardchain, shard blockchain) transaksjoner vil komme svært sjelden, og det vil være behov for mange kraftige noder (når jeg ser fremover, merker jeg at vi ikke bare snakker om klienter på mobiltelefoner – men om seriøse servere).
Derfor kombinerer shardchains kontoer med de binære prefiksene til identifikatorene deres: hvis en shardchain har et prefiks på 0110, vil den inkludere transaksjoner for alle account_id-er som begynner med disse tallene. Dette shard_prefix kan ha en lengde fra 0 til 60 biter - og hovedsaken er at den kan endre seg dynamisk.
Så snart en av shard-kjedene begynner å motta for mange transaksjoner, "deler" nodene som jobber med den, i henhold til forhåndsbestemte regler, den i to barn - prefiksene deres vil være en bit lengre (og for en av dem vil denne biten være lik 0, og for den andre - 1). For eksempel, shard_prefix = 0110b vil dele seg i 01100b og 01101b. På sin side, hvis to "nabo" shardchains begynner å føle seg trygge nok (i en stund), vil de slå seg sammen igjen.
Dermed gjøres sharding "fra bunnen og opp" - vi antar at hver konto har sin egen shard, men foreløpig er de "limt sammen" av prefikser. Dette er hva det betyr Infinite Sharding Paradigm (uendelig sharding-paradigme).
Separat vil jeg understreke at arbeidskjeder bare eksisterer praktisk talt - faktisk, workchain_id det er en del av identifikatoren til en spesifikk shardchain. I formelle termer er hver shardchain definert av et par tall (workchain_id, shard_prefix).
Feilretting. Vertikale blokkjeder.
Tradisjonelt anses enhver transaksjon på en blokkjede for å være "satt i stein." Når det gjelder TON, er det imidlertid mulig å "omskrive historien" - i tilfelle noen (den såkalte. fisker knute) vil bevise at en av blokkene ble signert feil. I dette tilfellet legges en spesiell korreksjonsblokk til den tilsvarende shardchain, som inneholder hashen til selve blokken som korrigeres (og ikke den siste blokken i shardchain). Når vi tenker på shardchain som en kjede av blokker lagt ut horisontalt, kan vi si at den korrigerende blokken er festet til den feilaktige blokken ikke til høyre, men ovenfra - så det anses at den blir en del av en liten "vertikal blokkjede" . Dermed kan vi si at shardchains er todimensjonale blokkjeder.
Hvis, etter en feilaktig blokkering, endringene gjort av den ble referert til av påfølgende blokker (dvs. nye transaksjoner ble gjort basert på ugyldige), blir korrigerende også lagt til disse blokkene "på toppen". Hvis blokkene ikke påvirket den "berørte" informasjonen, gjelder ikke disse "korrigerende bølgene" for dem. For eksempel, i illustrasjonen ovenfor, ble transaksjonen til den første blokken, som øker saldoen på konto C, gjenkjent som feil - derfor bør transaksjonen som reduserer saldoen på denne kontoen i den tredje blokken også kanselleres, og en korrigerende blokkering bør forpliktes på toppen av selve blokken.
Det skal bemerkes at selv om de korrigerende blokkene er avbildet som plassert "over" de originale, vil de faktisk bli lagt til på slutten av den tilsvarende blokkjeden (hvor de skal være kronologisk). Den todimensjonale plasseringen viser bare til hvilket punkt i blokkjeden de vil bli "lenket" (via hashen til den opprinnelige blokken som ligger i dem).
Du kan separat filosofere over hvor god beslutningen om å "endre fortiden" er. Det ser ut til at hvis vi innrømmer muligheten for at en feil blokk vises i shardchain, så kan vi ikke unngå muligheten for at en feilaktig korrigerende blokk vises. Her, så vidt jeg kan se, er forskjellen i antall noder som må nå konsensus om nye blokker - det vil være et relativt lite antall personer som jobber på hver shardchain."arbeidsgruppe» noder (som endrer sammensetningen ganske ofte), og innføring av korrigerende blokker vil kreve samtykke fra alle validatornoder. Jeg skal snakke mer om validatorer, arbeidsgrupper og andre noderoler i neste artikkel.
Én blokkjede for å styre dem alle
Det er oppført mye informasjon ovenfor om de forskjellige typene blokkjeder, som i seg selv også bør lagres et sted. Spesielt snakker vi om følgende informasjon:
- om antall og konfigurasjoner av arbeidskjeder;
- om antall shardchains og deres prefikser;
- om hvilke noder som for øyeblikket er ansvarlige for hvilke shardchains;
- hashes av de siste blokkene lagt til alle shardchains.
Som du kanskje har gjettet, er alle disse tingene registrert i en annen blokkjedelagring - mesterkjede (mesterkjede, master blockchain). På grunn av tilstedeværelsen av hashes fra blokkene til alle shardchains i blokkene, gjør det systemet svært tilkoblet. Dette betyr blant annet at genereringen av en ny blokk i masterkjeden vil skje umiddelbart etter genereringen av blokker i shardchains - det forventes at blokker i shardchains vil vises nesten samtidig omtrent hvert 5. sekund, og neste blokk i shardchains. masterchain - et sekund etter det.
Men hvem vil være ansvarlig for implementeringen av alt dette titaniske arbeidet - for å sende meldinger, utføre smarte kontrakter, danne blokker i shardchains og masterchain, og til og med sjekke blokker for feil? Vil alt dette gjøres i hemmelighet av telefonene til millioner av brukere med Telegram-klienten installert på dem? Eller kanskje Durov-teamet vil forlate ideene om desentralisering og deres servere vil gjøre det på den gamle måten?
Faktisk er verken det ene eller det andre svaret riktig. Men marginene til denne artikkelen renner raskt ut, så vi vil snakke om de forskjellige rollene til noder (du har kanskje allerede lagt merke til omtale av noen av dem), samt mekanikken i arbeidet deres, i neste del.
Kilde: www.habr.com