<\/a><\/noindex><\/p>\nGrundl\u00e6ggende begreber<\/h3>\n <\/p>\n
Konto<\/strong> (account<\/em>). Et datas\u00e6t, der identificeres med et 256-bit nummer account_id<\/em> (normalt ejerens offentlige n\u00f8gle). I grundl\u00e6ggende tilf\u00e6lde (se nedenfor nul blockchain<\/em>), refererer disse data til brugerens saldo. Enhver kan \"l\u00e5ne\" et bestemt account_id<\/em> bel\u00f8b, men dets v\u00e6rdi kan kun \u00e6ndres efter bestemte regler.<\/p>\n<\/p>\n
Smartkontrakt<\/strong> (smart-contract<\/em>). I det v\u00e6sentlige en s\u00e6rlig type konto, som er suppleret med smartkontraktkode og opbevaring af dens variabler. Hvor man i tilf\u00e6lde af \"wallet\" kan inds\u00e6tte og tr\u00e6kke penge fra den efter relativt enkle og forudbestemte regler, er reglerne for smartkontrakten indskrevet i form af dens kode (i et Turing-komplet programmeringssprog).<\/p>\n<\/p>\n
Blockchain-tilstand<\/strong> (state of blockchain<\/em>). En samling af tilstande for alle konti\/smartkontrakter (i abstrakt forstand \u2014 en hash-tabel, hvor n\u00f8glerne er kontoidentifikatorer, og v\u00e6rdierne er de data, der opbevares i kontoerne).<\/p>\n<\/p>\n
Besked<\/strong> (message<\/em>). Jeg brugte ovenfor udtrykket \"inds\u00e6tte og tr\u00e6kke penge\" \u2014 dette er et s\u00e6rligt eksempel p\u00e5 en meddelelse (\"overf\u00f8re N gram<\/em> fra kontoen account_1<\/em> til kontoen account_2<\/em>\"). \u00c5benlyst kan kun en node, der ejer den private n\u00f8gle til kontoen, sende en s\u00e5dan meddelelse account_1<\/em> \u2014 og kan bekr\u00e6fte det med en underskrift. Resultatet af levering af s\u00e5danne meddelelser til en almindelig konto er en stigning i dens saldo, og i tilf\u00e6lde af en smartkontrakt er det udf\u00f8relsen af dens kode (som behandler modtagelsen af meddelelsen). Selvf\u00f8lgelig er der ogs\u00e5 andre meddelelser (der overf\u00f8rer ikke penge, men vilk\u00e5rlige data mellem smartkontrakter).<\/p>\n<\/p>\n
Transaktion<\/strong> (transaktion<\/em>). Leveringsfaktoren for en besked kaldes en transaktion. Transaktioner \u00e6ndrer blockchainens tilstand. Det er netop transaktioner (optegnelser over beskedlevering), der udg\u00f8r blokkene i blockchainen. I denne henseende kan man forestille sig blockchainens tilstand som en inkrementel database \u2014 alle blokke er \"diffs\", som skal anvendes sekventielt for at f\u00e5 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\u00e6ste artikel.<\/p>\n<\/p>\n
Blockchain i TON: hvad er det og hvorfor?<\/h3>\n <\/p>\n
Som n\u00e6vnt i den tidligere artikel, er blockchain en datastruktur, hvis elementer (blokke) er ordnet i en \"kjede\", og hver efterf\u00f8lgende blok i k\u00e6den indeholder et hash af den forrige<\/em>. I kommentarerne blev der stillet et sp\u00f8rgsm\u00e5l: hvorfor er en s\u00e5dan datastruktur overhovedet n\u00f8dvendig, n\u00e5r vi allerede har DHT \u2014 en distribueret hash-tabel? Det er \u00e5benlyst, at visse data ogs\u00e5 kan opbevares i DHT, men det er kun passende for ikke-alt for \"f\u00f8lsomme\" oplysninger. Kryptovalutaens saldi kan ikke opbevares i DHT \u2014 f\u00f8rst og fremmest p\u00e5 grund af manglende integritetskontroller . Egentlig vokser hele kompleksiteten i blockchain-strukturen for at forhindre indblanding i de data, der er gemt i den.<\/em>. Dog ser blockchain i TON endnu mere kompleks ud end i de fleste andre distribuerede systemer \u2014 og der er to grunde til det. Den f\u00f8rste er \u00f8nsket om at minimere behovet for<\/p>\n<\/p>\n
forks . I traditionelle kryptovalutaer er alle parametre defineret fra starten, og enhver fors\u00f8g p\u00e5 at \u00e6ndre dem resulterer faktisk i oprettelsen af et \"alternativt univers af kryptovalutaer\". Den anden grund er underst\u00f8ttelsen af partitionering (<\/em>shardingsharding<\/em>, ) af blockchainen. Blockchain er en struktur, der ikke kan blive mindre over tid; og s\u00e6dvanligvis er hver node, der er ansvarlig for netv\u00e6rkets funktion, n\u00f8dt til at gemme det fuldt ud. I traditionelle (centraliserede) systemer anvendes sharding til at l\u00f8se s\u00e5danne problemer: en del af optegnelserne i databasen er p\u00e5 \u00e9n server, en del p\u00e5 en anden, osv. I tilf\u00e6lde af kryptovalutaer er s\u00e5dan funktionalitet stadig ret sj\u00e6lden \u2014 is\u00e6r fordi det er sv\u00e6rt at tilf\u00f8je sharding i et system, der ikke oprindeligt var planlagt.<\/em>Hvordan planl\u00e6gger TON s\u00e5 at l\u00f8se begge ovenfor beskrevne problemer?<\/p>\n<\/p>\n
Hvordan planl\u00e6gger TON at l\u00f8se de to n\u00e6vnte problemer?<\/p>\n
<\/p>\n
Indholdet af blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Lad os f\u00f8rst tale om, hvad der planl\u00e6gges at blive gemt i blockchain. Der vil blive gemt kontostatusser (\"punge\" i den grundl\u00e6ggende version) og smarte kontrakter (for enkelhedens skyld vil vi antage, at dette er det samme som konti). I bund og grund vil det v\u00e6re en almindelig hash-tabel \u2014 n\u00f8glerne i den vil v\u00e6re identificeringsnumre account_id<\/strong>, og v\u00e6rdierne vil v\u00e6re datastrukturer, der indeholder s\u00e5danne ting som:<\/p>\n<\/p>\n
\nsaldo;<\/li>\n kode til den smarte kontrakt (kun for smarte kontrakter);<\/li>\n databasen for den smarte kontrakt (kun for smarte kontrakter);<\/li>\n statistik;<\/li>\n (valgfrit<\/em>) offentlig n\u00f8gle til overf\u00f8rsler fra kontoen, som standard account_id;<\/li>\nk\u00f8 af udg\u00e5ende beskeder (her registreres de til videresendelse til modtageren);<\/li>\n liste over de seneste leverede beskeder til denne konto.<\/li>\n<\/ul>\n<\/p>\n
Som n\u00e6vnt ovenfor best\u00e5r blokke direkte af transaktioner \u2014 beskeder, der er leveret til forskellige konti account_id. Men ud over account_id indeholder beskederne ogs\u00e5 et 32-bit felt workchain_id<\/em> \u2014 identifikatoren for den s\u00e5kaldte workchain<\/strong> (workchain<\/em>, arbejdende blockchain<\/em>). Dette g\u00f8r det muligt at have adskillige uafh\u00e6ngige blockchain med forskellige konfigurationer. Herudover betragtes workchain_id = 0 som et s\u00e6rligt tilf\u00e6lde, nul workchain<\/strong> \u2014 det er balancerne i denne, der svarer til kryptovalutaen TON (Grams). Sandsynligvis vil der slet ikke eksistere andre workchains i starten.<\/p>\n<\/p>\n
Shardchains. Infinite Sharding Paradigm.<\/h3>\n <\/p>\n
Men v\u00e6ksten i antallet af blockchains stopper ikke her. Lad os se n\u00e6rmere p\u00e5 sharding. Forestil dig, at hver konto (account_id) tildeles sin egen blockchain \u2014 her gemmes alle modtagne beskeder \u2014 og tilstandene for alle disse blockchains opbevares p\u00e5 separate noder.<\/p>\n
<\/p>\n
Selvf\u00f8lgelig er dette temmelig spild af ressourcer: sandsynligvis vil transaktionerne ind i hver af disse shardchains<\/strong> (shardchain<\/em>, shard blockchain<\/em>) komme meget sj\u00e6ldent, og der vil v\u00e6re behov for mange kraftige noder (for at sige det mildt, vi taler ikke bare om klienter p\u00e5 mobile telefoner \u2014 men om seri\u00f8se servere).<\/p>\n<\/p>\n
Derfor samler shardchains konti efter de bin\u00e6re pr\u00e6fikser for deres identifikatorer: hvis en shardchain har pr\u00e6fikset 0110, vil transaktioner fra alle account_id, der starter med disse cifre, inkluderes. Denne shard_prefix<\/em> kan have en l\u00e6ngde fra 0 til 60 bit \u2014 og det vigtigste er, at det kan \u00e6ndre sig dynamisk.<\/p>\n<\/p>\n
<\/p>\n
N\u00e5r en af shard-k\u00e6derne begynder at modtage et overdrevent antal transaktioner, vil de noder, der arbejder med den, i henhold til forudbestemte regler \"opdele\" den i to underk\u00e6der \u2014 deres pr\u00e6fikser vil v\u00e6re \u00e9t bit l\u00e6ngere (og for \u00e9n af dem vil dette bit v\u00e6re 0, mens det for den anden vil v\u00e6re 1). For eksempel, shard_prefix<\/em> = 0110<\/u>b opdeles i 0110<\/u>0b og 0110<\/u>1b. Hvis to \"nabo\" shard-k\u00e6der igen f\u00f8ler sig tilpas (i en periode), vil de fusionere igen.<\/p>\n <\/p>\n
Dermed foreg\u00e5r sharderingen \"bundet op\" \u2014 vi antager, at hver konto har sin egen shard, men de er - indtil videre - \"klistret\" sammen efter pr\u00e6fikser. Dette indeb\u00e6rer Infinite Sharding Paradigm<\/strong> (paradigmet for endel\u00f8s shardering<\/em>).<\/p>\n<\/p>\n
Det er v\u00e6rd at understrege, at workchains kun eksisterer i det virtuelle \u2014 i virkeligheden, workchain_id<\/em> det er en del af identifikatoren for den specifikke shard-k\u00e6de. Formelt set defineres hver shard-k\u00e6de af et par tal (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Fejlretning. Vertikale blokk\u00e6der.<\/h3>\n <\/p>\n
Det antages traditionelt, at enhver transaktion i en blokchain er \"hugget i sten\". Dog er der i tilf\u00e6lde af TON mulighed for at \"skrive historien om\" \u2014 hvis nogen (den s\u00e5kaldte fisker-node<\/em>) kan bevise, at en af blokkene blev underskrevet ukorrekt. I dette tilf\u00e6lde tilf\u00f8jes der en speciel korrigerende blok til den relevante shard-k\u00e6de, som indeholder hash-v\u00e6rdien af den blok, der rettes (og ikke den sidste blok i shard-k\u00e6den). Hvis man betragter shard-k\u00e6den som en k\u00e6de af blokke lagt horisontalt, kan man sige, at den korrigerende blok forbindelse til den fejlede blok ikke til h\u00f8jre, men ovenfra \u2014 derfor betragtes det, at den bliver en del af en lille \"vertikal blokchain\". Dermed kan man sige, at shard-k\u00e6der er 2D blokk\u00e6der<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Hvis der efter den fejlagtige blok henvises til \u00e6ndringer, som er foretaget af efterf\u00f8lgende blokke (dvs. der er foretaget nye transaktioner baseret p\u00e5 de ugyldige), vil der ogs\u00e5 blive tilf\u00f8jet korrektionsblokke \"ovenp\u00e5\" disse blokke. Hvis blokke ikke ber\u00f8rer den \"ramte\" information, str\u00e6kker disse \"korrektionsb\u00f8lger\" sig ikke til dem. For eksempel, i den ovenst\u00e5ende illustration blev transaktionen i den f\u00f8rste blok, der \u00f8ger saldoen p\u00e5 konto C, anerkendt som ugyldig \u2014 derfor skal transaktionen, der reducerer saldoen af denne konto i den tredje blok, ogs\u00e5 annulleres, og en korrektionsblok skal v\u00e6re commit-et ovenp\u00e5 selve blokken.<\/p>\n
<\/p>\n
Det skal bem\u00e6rkes \u2014 selvom korrektionsblokke vises som placeret \"ovenfor\" de originale, vil de faktiske blive skrevet til slutningen af den tilsvarende blockchain (d\u00e9r, hvor de kronologisk b\u00f8r 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).<\/p>\n
<\/p>\n
Man kan specielt overveje, hvor godt det er at \"\u00e6ndre fortiden\". Det ville synes, at hvis vi tillader muligheden for at der opst\u00e5r en fejlagtig blok i shardchainen, s\u00e5 kan vi ikke undg\u00e5 muligheden for at der ogs\u00e5 opst\u00e5r en fejlagtig korrektionsblok. Her er, s\u00e5 vidt jeg kan bed\u00f8mme, forskellen i antallet af noder, som skal n\u00e5 en konsensus om de nye blokke \u2014 p\u00e5 hver shardchain vil der arbejde relativt f\u00e5arbejdsgrupper<\/em>noder (der ofte \u00e6ndrer deres sammens\u00e6tning), mens indf\u00f8relsen af korrektionsblokke vil kr\u00e6ve enighed fra alle validator-noder<\/em>. Mere om validatorer, arbejdsgrupper og andre noderoller vil jeg tale om i den n\u00e6ste artikel.<\/p>\n<\/p>\n
En blockchain til at styre dem alle<\/h3>\n <\/p>\n
Der er n\u00e6vnt mange oplysninger om forskellige typer blockchainer ovenfor, som ogs\u00e5 b\u00f8r opbevares et sted. Is\u00e6r drejer det sig om f\u00f8lgende oplysninger:<\/p>\n
<\/p>\n
\nom antal og konfigurationer af workchains;<\/li>\n om antal shardchains og deres pr\u00e6fikser;<\/li>\n om hvilke noder der aktuelt er ansvarlige for hvilke shardchains;<\/li>\n hash'e af de senest tilf\u00f8jede blokke til alle shardchains.<\/li>\n<\/ul>\n<\/p>\n
Som du allerede kunne g\u00e6tte, bliver alle disse ting registreret i endnu en opbevaring-blockchain \u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Takket v\u00e6re tilstedev\u00e6relsen af hashes fra blokkene i alle shard-k\u00e6derne, g\u00f8r det systemet st\u00e6rkt sammenknyttet. Dette betyder ogs\u00e5, at genereringen af en ny blok i master-k\u00e6den vil finde sted direkte efter genereringen af blokke i shard-k\u00e6derne \u2014 det forventes, at blokke i shard-k\u00e6derne vises n\u00e6sten samtidig, cirka hver 5. sekund, og den n\u00e6ste blok i master-k\u00e6den vil komme sekunder efter dette.<\/p>\n<\/p>\n
Men hvem vil v\u00e6re ansvarlig for at udf\u00f8re alt dette titaniske arbejde \u2014 for at sende beskeder, udf\u00f8re smarte kontrakter, danne blokke i shard-k\u00e6derne og master-k\u00e6den, og samtidig tjekke blokke for fejl? Skal alt dette virkelig udf\u00f8res i det stille af telefoner fra millioner af brugere, der har Telegram-klienten installeret? Eller vil Durovs\u56e2\u961f m\u00e5ske opgive id\u00e9en om decentralisering, og s\u00e5 bliver det deres servere, der g\u00f8r det p\u00e5 gammeldags man\u00e9r?<\/p>\n
<\/p>\n
Faktisk er ingen af svarene rigtige. Men pladsen i denne artikel er hastigt ved at l\u00f8be ud, s\u00e5 samtalen om de forskellige roller for noderne (du har m\u00e5ske allerede bem\u00e6rket nogle af dem n\u00e6vnt), samt om mekanikernes arbejde vil blive taget op i den n\u00e6ste del.<\/p>\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"TON:](\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\")
<\/p>\n