Denne tekst er en fortsættelse af en serie artikler, hvor jeg undersøger strukturen af det (sandsynligvis) kommende distribuerede netværk, Telegram Open Network (TON), i år. Jeg har beskrevet dens mest grundlæggende niveau — hvordan noder interagerer med hinanden.
Jeg vil minde om, at jeg ikke har nogen forbindelse til udviklingen af dette netværk, og alt materiale er hentet fra en offentlig (selv om den ikke er bekræftet) kilde — (der medfølger også en , der kortfattet opsummerer de vigtigste punkter), som dukkede op i slutningen af sidste år. Mængden af information i dette dokument vidner efter min mening om dets autencitet, selvom der ikke er nogen officielle bekræftelser på det.
I dag vil vi se på den primære komponent i TON — blockchain.
Grundlæggende begreber
Konto (account). Et datasæt, der identificeres med et 256-bit nummer account_id (normalt ejerens offentlige nøgle). I grundlæggende tilfælde (se nedenfor nul blockchain), refererer disse data til brugerens saldo. Enhver kan "låne" et bestemt account_id beløb, men dets værdi kan kun ændres efter bestemte regler.
Smartkontrakt (smart-contract). I det væsentlige en særlig type konto, som er suppleret med smartkontraktkode og opbevaring af dens variabler. Hvor man i tilfælde af "wallet" kan indsætte og trække penge fra den efter relativt enkle og forudbestemte regler, er reglerne for smartkontrakten indskrevet i form af dens kode (i et Turing-komplet programmeringssprog).
Blockchain-tilstand (state of blockchain). En samling af tilstande for alle konti/smartkontrakter (i abstrakt forstand — en hash-tabel, hvor nøglerne er kontoidentifikatorer, og værdierne er de data, der opbevares i kontoerne).
Besked (message). Jeg brugte ovenfor udtrykket "indsætte og trække penge" — dette er et særligt eksempel på en meddelelse ("overføre N gram fra kontoen account_1 til kontoen account_2"). Åbenlyst kan kun en node, der ejer den private nøgle til kontoen, sende en sådan meddelelse account_1 — og kan bekræfte det med en underskrift. Resultatet af levering af sådanne meddelelser til en almindelig konto er en stigning i dens saldo, og i tilfælde af en smartkontrakt er det udførelsen af dens kode (som behandler modtagelsen af meddelelsen). Selvfølgelig er der også andre meddelelser (der overfører ikke penge, men vilkårlige data mellem smartkontrakter).
Transaktion (transaktion). Leveringsfaktoren for en besked kaldes en transaktion. Transaktioner ændrer blockchainens tilstand. Det er netop transaktioner (optegnelser over beskedlevering), der udgør blokkene i blockchainen. I denne henseende kan man forestille sig blockchainens tilstand som en inkrementel database — alle blokke er "diffs", som skal anvendes sekventielt for at få den aktuelle tilstand af databasen. Om detaljerne ved indpakningen af disse "diffs" (og genskabelsen af den samlede tilstand ud fra dem) vil der blive talt i næste artikel.
Blockchain i TON: hvad er det og hvorfor?
Som nævnt i den tidligere artikel, er blockchain en datastruktur, hvis elementer (blokke) er ordnet i en "kjede", og hver efterfølgende blok i kæden indeholder et hash af den forrige. I kommentarerne blev der stillet et spørgsmål: hvorfor er en sådan datastruktur overhovedet nødvendig, når vi allerede har DHT — en distribueret hash-tabel? Det er åbenlyst, at visse data også kan opbevares i DHT, men det er kun passende for ikke-alt for "følsomme" oplysninger. Kryptovalutaens saldi kan ikke opbevares i DHT — først og fremmest på grund af manglende integritetskontroller . Egentlig vokser hele kompleksiteten i blockchain-strukturen for at forhindre indblanding i de data, der er gemt i den.. Dog ser blockchain i TON endnu mere kompleks ud end i de fleste andre distribuerede systemer — og der er to grunde til det. Den første er ønsket om at minimere behovet for
forks . I traditionelle kryptovalutaer er alle parametre defineret fra starten, og enhver forsøg på at ændre dem resulterer faktisk i oprettelsen af et "alternativt univers af kryptovalutaer". Den anden grund er understøttelsen af partitionering (shardingsharding, ) af blockchainen. Blockchain er en struktur, der ikke kan blive mindre over tid; og sædvanligvis er hver node, der er ansvarlig for netværkets funktion, nødt til at gemme det fuldt ud. I traditionelle (centraliserede) systemer anvendes sharding til at løse sådanne problemer: en del af optegnelserne i databasen er på én server, en del på en anden, osv. I tilfælde af kryptovalutaer er sådan funktionalitet stadig ret sjælden — især fordi det er svært at tilføje sharding i et system, der ikke oprindeligt var planlagt.Hvordan planlægger TON så at løse begge ovenfor beskrevne problemer?
Каким же образом TON планирует решить обе вышеописанных проблемы?
Indholdet af blockchain. Workchains.
Lad os først tale om, hvad der planlægges at blive gemt i blockchain. Der vil blive gemt kontostatusser ("punge" i den grundlæggende version) og smarte kontrakter (for enkelhedens skyld vil vi antage, at dette er det samme som konti). I bund og grund vil det være en almindelig hash-tabel — nøglerne i den vil være identificeringsnumre account_id, og værdierne vil være datastrukturer, der indeholder sådanne ting som:
- saldo;
- kode til den smarte kontrakt (kun for smarte kontrakter);
- databasen for den smarte kontrakt (kun for smarte kontrakter);
- statistik;
- (valgfrit) offentlig nøgle til overførsler fra kontoen, som standard account_id;
- kø af udgående beskeder (her registreres de til videresendelse til modtageren);
- liste over de seneste leverede beskeder til denne konto.
Som nævnt ovenfor består blokke direkte af transaktioner — beskeder, der er leveret til forskellige konti account_id. Men ud over account_id indeholder beskederne også et 32-bit felt workchain_id — identifikatoren for den såkaldte workchain (workchain, arbejdende blockchain). Dette gør det muligt at have adskillige uafhængige blockchain med forskellige konfigurationer. Herudover betragtes workchain_id = 0 som et særligt tilfælde, nul workchain — det er balancerne i denne, der svarer til kryptovalutaen TON (Grams). Sandsynligvis vil der slet ikke eksistere andre workchains i starten.
Shardchains. Infinite Sharding Paradigm.
Men væksten i antallet af blockchains stopper ikke her. Lad os se nærmere på sharding. Forestil dig, at hver konto (account_id) tildeles sin egen blockchain — her gemmes alle modtagne beskeder — og tilstandene for alle disse blockchains opbevares på separate noder.
Selvfølgelig er dette temmelig spild af ressourcer: sandsynligvis vil transaktionerne ind i hver af disse shardchains (shardchain, shard blockchain) komme meget sjældent, og der vil være behov for mange kraftige noder (for at sige det mildt, vi taler ikke bare om klienter på mobile telefoner — men om seriøse servere).
Derfor samler shardchains konti efter de binære præfikser for deres identifikatorer: hvis en shardchain har præfikset 0110, vil transaktioner fra alle account_id, der starter med disse cifre, inkluderes. Denne shard_prefix kan have en længde fra 0 til 60 bit — og det vigtigste er, at det kan ændre sig dynamisk.
Når en af shard-kæderne begynder at modtage et overdrevent antal transaktioner, vil de noder, der arbejder med den, i henhold til forudbestemte regler "opdele" den i to underkæder — deres præfikser vil være ét bit længere (og for én af dem vil dette bit være 0, mens det for den anden vil være 1). For eksempel, shard_prefix = 0110b opdeles i 01100b og 01101b. Hvis to "nabo" shard-kæder igen føler sig tilpas (i en periode), vil de fusionere igen.
Dermed foregår sharderingen "bundet op" — vi antager, at hver konto har sin egen shard, men de er - indtil videre - "klistret" sammen efter præfikser. Dette indebærer Infinite Sharding Paradigm (paradigmet for endeløs shardering).
Det er værd at understrege, at workchains kun eksisterer i det virtuelle — i virkeligheden, workchain_id det er en del af identifikatoren for den specifikke shard-kæde. Formelt set defineres hver shard-kæde af et par tal (workchain_id, shard_prefix).
Fejlretning. Vertikale blokkæder.
Det antages traditionelt, at enhver transaktion i en blokchain er "hugget i sten". Dog er der i tilfælde af TON mulighed for at "skrive historien om" — hvis nogen (den såkaldte fisker-node) kan bevise, at en af blokkene blev underskrevet ukorrekt. I dette tilfælde tilføjes der en speciel korrigerende blok til den relevante shard-kæde, som indeholder hash-værdien af den blok, der rettes (og ikke den sidste blok i shard-kæden). Hvis man betragter shard-kæden som en kæde af blokke lagt horisontalt, kan man sige, at den korrigerende blok forbindelse til den fejlede blok ikke til højre, men ovenfra — derfor betragtes det, at den bliver en del af en lille "vertikal blokchain". Dermed kan man sige, at shard-kæder er 2D blokkæder.
Hvis der efter den fejlagtige blok henvises til ændringer, som er foretaget af efterfølgende blokke (dvs. der er foretaget nye transaktioner baseret på de ugyldige), vil der også blive tilføjet korrektionsblokke "ovenpå" disse blokke. Hvis blokke ikke berører den "ramte" information, strækker disse "korrektionsbølger" sig ikke til dem. For eksempel, i den ovenstående illustration blev transaktionen i den første blok, der øger saldoen på konto C, anerkendt som ugyldig — derfor skal transaktionen, der reducerer saldoen af denne konto i den tredje blok, også annulleres, og en korrektionsblok skal være commit-et ovenpå selve blokken.
Det skal bemærkes — selvom korrektionsblokke vises som placeret "ovenfor" de originale, vil de faktiske blive skrevet til slutningen af den tilsvarende blockchain (dér, hvor de kronologisk bør befinde sig). Den todimensionale placering viser blot, hvilket punkt i blockchainen de vil blive "hooket op" til (gennem hash'en af den originale blok, som de indeholder).
Man kan specielt overveje, hvor godt det er at "ændre fortiden". Det ville synes, at hvis vi tillader muligheden for at der opstår en fejlagtig blok i shardchainen, så kan vi ikke undgå muligheden for at der også opstår en fejlagtig korrektionsblok. Her er, så vidt jeg kan bedømme, forskellen i antallet af noder, som skal nå en konsensus om de nye blokke — på hver shardchain vil der arbejde relativt fåarbejdsgruppernoder (der ofte ændrer deres sammensætning), mens indførelsen af korrektionsblokke vil kræve enighed fra alle validator-noder. Mere om validatorer, arbejdsgrupper og andre noderoller vil jeg tale om i den næste artikel.
En blockchain til at styre dem alle
Der er nævnt mange oplysninger om forskellige typer blockchainer ovenfor, som også bør opbevares et sted. Især drejer det sig om følgende oplysninger:
- om antal og konfigurationer af workchains;
- om antal shardchains og deres præfikser;
- om hvilke noder der aktuelt er ansvarlige for hvilke shardchains;
- hash'e af de senest tilføjede blokke til alle shardchains.
Som du allerede kunne gætte, bliver alle disse ting registreret i endnu en opbevaring-blockchain — masterchain (masterchain, master blockchain). Takket være tilstedeværelsen af hashes fra blokkene i alle shard-kæderne, gør det systemet stærkt sammenknyttet. Dette betyder også, at genereringen af en ny blok i master-kæden vil finde sted direkte efter genereringen af blokke i shard-kæderne — det forventes, at blokke i shard-kæderne vises næsten samtidig, cirka hver 5. sekund, og den næste blok i master-kæden vil komme sekunder efter dette.
Men hvem vil være ansvarlig for at udføre alt dette titaniske arbejde — for at sende beskeder, udføre smarte kontrakter, danne blokke i shard-kæderne og master-kæden, og samtidig tjekke blokke for fejl? Skal alt dette virkelig udføres i det stille af telefoner fra millioner af brugere, der har Telegram-klienten installeret? Eller vil Durovs团队 måske opgive idéen om decentralisering, og så bliver det deres servere, der gør det på gammeldags manér?
Faktisk er ingen af svarene rigtige. Men pladsen i denne artikel er hastigt ved at løbe ud, så samtalen om de forskellige roller for noderne (du har måske allerede bemærket nogle af dem nævnt), samt om mekanikernes arbejde vil blive taget op i den næste del.
Kilde: habr.com
