Denne tekst er en fortsættelse af en række artikler, hvor jeg undersøger strukturen af det (formodentlig) distribuerede netværk Telegram Open Network (TON), som er ved at blive klargjort til udgivelse i år. I Jeg beskrev dets mest grundlæggende niveau - den måde, noder interagerer med hinanden.
For en sikkerheds skyld, så lad mig minde dig om, at jeg ikke har noget at gøre med udviklingen af dette netværk, og alt materialet blev hentet fra en åben (omend ubekræftet) kilde - (der er også en medfølgende , der kort skitserer hovedpunkterne), som udkom i slutningen af sidste år. Mængden af oplysninger i dette dokument indikerer efter min mening dets ægthed, selvom der ikke er nogen officiel bekræftelse på dette.
I dag vil vi se på hovedkomponenten i TON - blockchain.
Grundlæggende koncepter
Konto (konto). Et sæt data identificeret med et 256-bit nummer Konto-id (oftest er dette kontoejerens offentlige nøgle). I basistilfældet (se nedenfor nul arbejdskæde), henviser disse data til brugerens saldo. "Occupy" specifik Konto-id enhver kan, men dens værdi kan kun ændres i henhold til visse regler.
Smart kontrakt (Smart-kontrakt). I bund og grund er det et særligt tilfælde af en konto, suppleret med smart kontraktkode og lagring af dens variabler. Hvis du i tilfælde af en "pung" kan indbetale og hæve penge fra den i henhold til relativt enkle og forudbestemte regler, så er disse regler i tilfælde af en smart kontrakt skrevet i form af dens kode (i en vis Turing-komplet programmeringssprog).
Blockchain-stat (tilstand af blockchain). Sættet af tilstande for alle konti/smarte kontrakter (i abstrakt forstand, en hash-tabel, hvor nøglerne er kontoidentifikatorer, og værdierne er de data, der er gemt i konti).
besked (besked). Ovenfor brugte jeg udtrykket "kredit- og debetpenge" - dette er et særligt eksempel på en meddelelse ("overførsel" N gram fra konto konto_1 til konto konto_2"). Det er klart, at kun den node, der ejer kontoens private nøgle, kan sende en sådan besked konto_1 - og kan bekræfte dette med en underskrift. Resultatet af at levere sådanne beskeder til en almindelig konto er en stigning i dens saldo, og resultatet af den smarte kontrakt er udførelsen af dens kode (som vil behandle modtagelsen af beskeden). Selvfølgelig er andre meddelelser også mulige (overførsel ikke pengebeløb, men vilkårlige data mellem smarte kontrakter).
Transaktion (transaktion). Det, at en besked bliver leveret, kaldes en transaktion. Transaktioner ændrer tilstanden af blockchain. Det er transaktioner (postleveringsposter), der udgør blokkene i blockchainen. I denne henseende kan du tænke på tilstanden af blockchain som en inkrementel database - alle blokke er "diffs", der skal anvendes sekventielt for at få den aktuelle tilstand af databasen. Specifikationerne for emballering af disse "diffs" (og genoprettelse af den fulde tilstand fra dem) vil blive diskuteret i den næste artikel.
Blockchain i TON: hvad er det og hvorfor?
Som nævnt i forrige artikel, blockchain er en datastruktur, hvis elementer (blokke) er ordnet i en "kæde", og hver efterfølgende blok af kæden indeholder en hash af den forrige. Kommentarerne stillede spørgsmålet: hvorfor har vi overhovedet brug for sådan en datastruktur, når vi allerede har en DHT - en distribueret hash-tabel? Naturligvis kan nogle data gemmes i DHT, men dette er kun egnet til ikke alt for "følsomme" oplysninger. Kryptovaluta-saldi kan ikke opbevares i DHT – primært på grund af manglende kontrol vedr integritet. Faktisk vokser hele kompleksiteten af blockchain-strukturen for at forhindre interferens med de data, der er lagret i den.
Blockchainen i TON ser dog endnu mere kompleks ud end i de fleste andre distribuerede systemer – og af to årsager. Den første er ønsket om at minimere behovet for gafler. I traditionelle kryptovalutaer er alle parametre sat i den indledende fase, og ethvert forsøg på at ændre dem fører faktisk til fremkomsten af et "alternativt kryptovaluta-univers." Den anden grund er støtte til knusning (skæring, skæring) blockchain. Blockchain er en struktur, der ikke kan blive mindre over tid; og normalt er hver knude, der er ansvarlig for driften af netværket, tvunget til at gemme den fuldstændigt. I traditionelle (centraliserede) systemer bruges sharding til at løse sådanne problemer: nogle af posterne i databasen er placeret på en server, nogle på en anden osv. I tilfælde af kryptovalutaer er en sådan funktionalitet stadig ret sjælden – især på grund af det faktum, at det er svært at tilføje sharding til et system, hvor det ikke oprindeligt var planlagt.
Hvordan planlægger TON at løse begge ovenstående problemer?
Blockchain indhold. Arbejdskæder.
Først og fremmest, lad os tale om, hvad der er planlagt til at blive lagret i blockchain. Kontitilstandene (“wallets” i basissagen) og smarte kontrakter vil blive gemt der (for nemheds skyld antager vi, at dette er det samme som konti). I det væsentlige vil dette være en almindelig hash-tabel - nøglerne i den vil være identifikatorer Konto-id, og værdier er datastrukturer, der indeholder sådanne ting som:
- balance;
- smart kontraktkode (kun for smarte kontrakter);
- datalagring af smart kontrakt (kun for smarte kontrakter);
- Statistikker;
- (valgfri) offentlig nøgle til overførsler fra kontoen, som standard account_id;
- kø af udgående beskeder (her indtastes de til videresendelse til modtageren);
- en liste over de seneste beskeder leveret til denne konto.
Som nævnt ovenfor består blokkene i sig selv af transaktioner - meddelelser leveret til forskellige account_id-konti. Ud over account_id indeholder meddelelser dog også et 32-bit felt workchain_id — såkaldt identifikator arbejdskæde (arbejdskæde, fungerende blockchain). Dette giver dig mulighed for at have flere blockchains uafhængige af hinanden med forskellige konfigurationer. I dette tilfælde betragtes workchain_id = 0 som et specialtilfælde, nul arbejdskæde — det er saldi i den, der svarer til TON (Grams) kryptovaluta. Mest sandsynligt vil andre arbejdskæder i første omgang slet ikke eksistere.
Skærvekæder. Infinite Sharding-paradigme.
Men væksten i antallet af blockchains stopper ikke der. Lad os beskæftige os med skæring. Lad os forestille os, at hver konto (account_id) er tildelt sin egen blockchain - den indeholder alle de beskeder, der kommer til den - og tilstandene for alle sådanne blockchains er gemt på separate noder.
Selvfølgelig er dette meget spild: højst sandsynligt i hver af disse skårkæder (skårkæde, shard blockchain) transaktioner vil ankomme meget sjældent, og der vil være brug for en masse kraftfulde noder (i fremtiden bemærker jeg, at vi ikke kun taler om klienter på mobiltelefoner – men om seriøse servere).
Derfor kombinerer shardchains konti med de binære præfikser af deres identifikatorer: hvis en shardchain har et præfiks på 0110, vil den inkludere transaktioner af alle account_id'er, der begynder med disse tal. Det her shard_prefix kan have en længde fra 0 til 60 bit - og det vigtigste er, at det kan ændre sig dynamisk.
Så snart en af shardchains begynder at modtage for mange transaktioner, "deler" noderne, der arbejder på den, i henhold til forudbestemte regler, den i to børn - deres præfikser vil være en smule længere (og for en af dem vil denne bit være lig med 0, og for den anden - 1). For eksempel, shard_prefix = 0110b vil opdeles i 01100b og 01101b. Til gengæld, hvis to "nabo" shardchains begynder at føle sig trygge nok (i nogen tid), vil de smelte sammen igen.
Således udføres sharding "nedefra og op" - vi antager, at hver konto har sit eget shard, men foreløbig er de "limet sammen" af præfikser. Dette er, hvad det betyder Infinite Sharding-paradigme (uendeligt skæringsparadigme).
Separat vil jeg gerne understrege, at arbejdskæder kun eksisterer virtuelt - faktisk, workchain_id det er en del af identifikatoren for en specifik shardchain. I formelle termer er hver shardchain defineret af et par tal (workchain_id, shard_prefix).
Fejlretning. Lodrette blockchains.
Traditionelt anses enhver transaktion på en blockchain for at være "slået i sten." Men i tilfælde af TON er det muligt at "omskrive historien" - i tilfælde af at nogen (den såkaldte. fisker knude) vil bevise, at en af blokkene blev underskrevet forkert. I dette tilfælde tilføjes en speciel korrektionsblok til den tilsvarende shardchain, der indeholder hashen af selve blokken, der rettes (og ikke den sidste blok i shardchain). Tænker vi på shardchainen som en kæde af blokke, der er lagt horisontalt ud, kan vi sige, at den korrigerende blok er fastgjort til den fejlagtige blok ikke til højre, men ovenfra - så det anses for at blive en del af en lille "vertikal blockchain" . Således kan vi sige, at shardchains er todimensionelle blockchains.
Hvis ændringerne, der er foretaget af den, efter en fejlagtig blokering blev refereret af efterfølgende blokke (dvs. nye transaktioner blev foretaget baseret på ugyldige), føjes korrigerende dem også til disse blokke "øverst". Hvis blokkene ikke påvirkede den "berørte" information, gælder disse "korrigerende bølger" ikke for dem. For eksempel, i illustrationen ovenfor, blev transaktionen af den første blok, der øgede saldoen på konto C, anerkendt som forkert - derfor bør transaktionen, der reducerede saldoen på denne konto i den tredje blok, også annulleres, og en korrigerende blokering skal begås oven på selve blokken.
Det skal bemærkes, at selvom de korrigerende blokke er afbildet som placeret "over" de originale, vil de faktisk blive tilføjet til slutningen af den tilsvarende blockchain (hvor de skal være kronologisk). Den todimensionelle placering viser kun til hvilket punkt i blockchain de vil blive "linket" (via hashen af den oprindelige blok placeret i dem).
Du kan separat filosofere over, hvor god beslutningen om at "ændre fortiden" er. Det ser ud til, at hvis vi indrømmer muligheden for, at en forkert blok vises i shardchain, så kan vi ikke undgå muligheden for, at en fejlagtig korrigerende blok dukker op. Her er forskellen, så vidt jeg kan se, i antallet af noder, der skal nå konsensus om nye blokke - der vil være et relativt lille antal mennesker, der arbejder på hver shardchain."arbejdsgruppe» noder (som ændrer sin sammensætning ret ofte), og indførelsen af korrigerende blokke vil kræve samtykke fra alle validator noder. Jeg vil tale mere om validatorer, arbejdsgrupper og andre noderoller i den næste artikel.
Én blockchain til at styre dem alle
Der er en masse information listet ovenfor om de forskellige typer af blockchains, som i sig selv også burde være gemt et sted. Vi taler især om følgende oplysninger:
- om antallet og konfigurationer af arbejdskæder;
- om antallet af shardchains og deres præfikser;
- om hvilke knudepunkter der i øjeblikket er ansvarlige for hvilke shardchains;
- hashes af de sidste blokke tilføjet til alle shardchains.
Som du måske har gættet, er alle disse ting optaget i et andet blockchain-lager - masterchain (masterchain, master blockchain). På grund af tilstedeværelsen af hashes fra blokkene af alle shardchains i dens blokke, gør det systemet stærkt forbundet. Det betyder blandt andet, at genereringen af en ny blok i masterkæden vil ske umiddelbart efter genereringen af blokke i shardchains - det forventes, at blokke i shardchains vil dukke op næsten samtidigt cirka hvert 5. sekund, og den næste blok i shardchains. masterchain - et sekund efter det.
Men hvem vil være ansvarlig for implementeringen af alt dette titaniske arbejde - for at sende beskeder, udføre smarte kontrakter, danne blokke i shardchains og masterchain og endda kontrollere blokke for fejl? Vil alt dette blive gjort i hemmelighed af telefoner fra millioner af brugere med Telegram-klienten installeret på dem? Eller måske vil Durov-teamet opgive ideerne om decentralisering, og deres servere vil gøre det på den gammeldags måde?
Faktisk er hverken det ene eller det andet svar korrekt. Men margenerne af denne artikel er hurtigt ved at løbe ud, så vi vil tale om de forskellige roller af noder (du har måske allerede bemærket omtaler af nogle af dem), såvel som mekanikken i deres arbejde, i den næste del.
Kilde: www.habr.com