ProHoster > Blogs > Administrācija > TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

Å is teksts ir turpinājums rakstu sērijai, kurā es aplÅ«koju (domājams) izplatÄ«tā tÄ«kla Telegram Open Network (TON) struktÅ«ru, kas tiek gatavota izlaiÅ”anai Å”ogad. IN iepriekŔējā daļa Es aprakstÄ«ju tā visvienkārŔāko lÄ«meni - veidu, kā mezgli mijiedarbojas viens ar otru.

Katram gadījumam atgādināŔu, ka man nav nekāda sakara ar Ŕī tīkla attīstību un viss materiāls ir savākts no atklāta (kaut arī nepārbaudīta) avota - dokuments (ir arī pavadoŔais broŔūra, īsi izklāstot galvenos punktus), kas parādījās pagājuŔā gada beigās. Informācijas apjoms Ŕajā dokumentā, manuprāt, liecina par tā autentiskumu, lai gan oficiāla apstiprinājuma tam nav.

Šodien mēs apskatīsim galveno TON sastāvdaļu - blokķēdi.

Pamatjēdzieni

Konts (konts). Datu kopa, kas identificēta ar 256 bitu skaitli Konta ID (visbiežāk Ŕī ir konta Ä«paÅ”nieka publiskā atslēga). Pamata gadÄ«jumā (skatÄ«t zemāk nulles darba ķēde), Å”ie dati attiecas uz lietotāja bilanci. "Okupēt" konkrēti Konta ID ikviens var, bet tā vērtÄ«bu var mainÄ«t tikai saskaņā ar noteiktiem noteikumiem.

Gudrs lÄ«gums (smart-lÄ«gums). Pēc bÅ«tÄ«bas tas ir Ä«paÅ”s konta gadÄ«jums, kas papildināts ar viedo lÄ«guma kodu un tā mainÄ«go uzglabāŔanu. Ja ā€œmakaā€ gadÄ«jumā naudu no tā var iemaksāt un izņemt pēc salÄ«dzinoÅ”i vienkārÅ”iem un iepriekÅ” noteiktiem noteikumiem, tad viedā lÄ«guma gadÄ«jumā Å”ie noteikumi ir rakstÄ«ti tā koda formā (noteiktā TjÅ«ringa komplektā programmÄ“Å”anas valoda).

Blockchain valsts (blokķēdes stāvoklis). Visu kontu/viedo līgumu stāvokļu kopa (abstraktā nozīmē jaucēj tabula, kur atslēgas ir konta identifikatori un vērtības ir kontos glabātie dati).

Ziņa (ziņa). IepriekÅ” es izmantoju izteicienu ā€œkredÄ«ta un debeta naudaā€ ā€” Å”is ir konkrēts ziņojuma piemērs (ā€œpārskaitÄ«jums N grami no konta konts_1 uz kontu konts_2"). AcÄ«mredzot Ŕādu ziņojumu var nosÅ«tÄ«t tikai tas mezgls, kuram pieder konta privātā atslēga konts_1 - un spēj to apstiprināt ar parakstu. Šādu ziņojumu piegādes uz parasto kontu rezultāts ir tā bilances pieaugums, un viedā lÄ«guma rezultāts ir tā koda izpilde (kas apstrādās ziņojuma saņemÅ”anu). Protams, ir iespējami arÄ« citi ziņojumi (nevis naudas summu, bet patvaļīgu datu pārsÅ«tÄ«Å”ana starp viedajiem lÄ«gumiem).

DarÄ«jums (darÄ«jums). Faktu, ka ziņojums tiek piegādāts, sauc par darÄ«jumu. DarÄ«jumi maina blokķēdes stāvokli. TieÅ”i darÄ«jumi (ziņu piegādes ieraksti) veido blokus blokķēdē. Å ajā sakarā jÅ«s varat uzskatÄ«t blokķēdes stāvokli kā pieaugoÅ”u datu bāzi - visi bloki ir ā€œdiffsā€, kas ir jāpiemēro secÄ«gi, lai iegÅ«tu paÅ”reizējo datu bāzes stāvokli. Å o ā€œdifuā€ iepakoÅ”anas (un pilnā stāvokļa atjaunoÅ”anas no tiem) specifika tiks apspriesta nākamajā rakstā.

Blockchain TON: kas tas ir un kāpēc?

Kā minēts iepriekŔējā rakstā, blokķēde ir datu struktÅ«ra, kuras elementi (bloki) ir sakārtoti ā€œÄ·Ä“dēā€, un katrs nākamais ķēdes bloks satur iepriekŔējā jaucējkrānu.. Komentāros tika uzdots jautājums: kāpēc mums vispār ir vajadzÄ«ga Ŕāda datu struktÅ«ra, ja mums jau ir DHT - sadalÄ«ta hash tabula? AcÄ«mredzot dažus datus var saglabāt DHT, taču tas ir piemērots tikai ne pārāk ā€œsensitÄ«vaiā€ informācijai. KriptovalÅ«tas atlikumus nevar glabāt DHT ā€” galvenokārt tāpēc, ka trÅ«kst pārbaužu integritāte. Faktiski visa blokķēdes struktÅ«ras sarežģītÄ«ba pieaug, lai novērstu tajā saglabāto datu traucējumus.

Tomēr TON blokķēde izskatās vēl sarežģītāka nekā lielākajā daļā citu izplatÄ«to sistēmu - un divu iemeslu dēļ. Pirmais ir vēlme samazināt vajadzÄ«bu pēc dakÅ”as. Tradicionālajās kriptovalÅ«tās visi parametri tiek iestatÄ«ti sākotnējā stadijā, un jebkurÅ” mēģinājums tos mainÄ«t faktiski noved pie "alternatÄ«vas kriptovalÅ«tas visuma" raÅ”anās. Otrs iemesls ir atbalsts saspieÅ”anai (sadalÄ«Å”ana, sadalÄ«Å”ana) blokķēde. Blockchain ir struktÅ«ra, kas laika gaitā nevar kļūt mazāka; un parasti katrs par tÄ«kla darbÄ«bu atbildÄ«gais mezgls ir spiests to pilnÄ«bā uzglabāt. Tradicionālajās (centralizētajās) sistēmās Ŕādu problēmu risināŔanai tiek izmantota sadalÄ«Å”ana: daļa ierakstu datubāzē atrodas vienā serverÄ«, daļa citā utt. KriptovalÅ«tu gadÄ«jumā Ŕāda funkcionalitāte joprojām ir diezgan reta - jo Ä«paÅ”i tāpēc, ka ir grÅ«ti pievienot sharding sistēmai, kur tas sākotnēji nebija paredzēts.

Kā TON plāno atrisināt abas iepriekÅ” minētās problēmas?

Blockchain saturs. Darba ķēdes.

TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

Pirmkārt, parunāsim par to, ko plānots glabāt blokķēdē. Tur tiks saglabāti kontu stāvokļi (bāzes gadÄ«jumā "maki") un viedie lÄ«gumi (vienkārŔības labad pieņemsim, ka tas ir tas pats, kas konti). BÅ«tÄ«bā Ŕī bÅ«s parasta hash tabula ā€“ atslēgas tajā bÅ«s identifikatori Konta ID, un vērtÄ«bas ir datu struktÅ«ras, kas satur tādas lietas kā:

  • lÄ«dzsvars;
  • viedā lÄ«guma kods (tikai viedajiem lÄ«gumiem);
  • viedo lÄ«gumu datu glabāŔana (tikai viedajiem lÄ«gumiem);
  • statistika;
  • (pēc izvēles) publiskā atslēga pārskaitÄ«jumiem no konta, pēc noklusējuma account_id;
  • izejoÅ”o ziņojumu rinda (Å”eit tie tiek ievadÄ«ti pārsÅ«tÄ«Å”anai adresātam);
  • uz Å”o kontu piegādāto jaunāko ziņojumu saraksts.

Kā minēts iepriekÅ”, paÅ”i bloki sastāv no transakcijām - ziņojumiem, kas tiek piegādāti uz dažādiem account_id kontiem. Tomēr ziņojumos papildus konta_id ir arÄ« 32 bitu lauks darba ķēdes_id ā€” tā sauktais identifikators darba ķēde (darba ķēde, darbojas blokķēde). Tas ļauj jums izveidot vairākas viena no otras neatkarÄ«gas blokķēdes ar dažādām konfigurācijām. Å ajā gadÄ«jumā workchain_id = 0 tiek uzskatÄ«ts par Ä«paÅ”u gadÄ«jumu, nulles darba ķēde ā€” tieÅ”i tajā esoÅ”ie atlikumi atbildÄ«s kriptovalÅ«tai TON (Grams). Visticamāk, sākumā citas darba ķēdes vispār nepastāvēs.

Shardchains. Bezgalīgas sadalīŔanas paradigma.

Bet blokķēžu skaita pieaugums ar to neapstājas. Tiksim galā ar ŔķelÅ”anos. Iedomāsimies, ka katram kontam (account_id) ir pieŔķirta sava blokķēde ā€“ tajā ir visi ziņojumi, kas tam nonāk ā€“ un visu Ŕādu blokķēžu stāvokļi tiek glabāti atseviŔķos mezglos.

Protams, tas ir ļoti izŔķērdÄ«gi: visticamāk, katrā no tiem shardchains (shardchain, shard blockchain) darÄ«jumi ieradÄ«sies ļoti reti, un bÅ«s nepiecieÅ”ami daudz jaudÄ«gu mezglu (skatoties uz priekÅ”u, atzÄ«mēju, ka mēs nerunājam tikai par klientiem mobilajos tālruņos - bet gan par nopietniem serveriem).

Tāpēc shardchains apvieno kontus pēc to identifikatoru binārajiem prefiksiem: ja shardchain prefikss ir 0110, tad tajā tiks iekļauti visu account_ids darÄ«jumi, kas sākas ar Å”iem cipariem. Å is shard_prefix var bÅ«t garums no 0 lÄ«dz 60 bitiem - un galvenais ir tas, ka tas var dinamiski mainÄ«ties.

TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

TiklÄ«dz viens no shardchainiem sāk saņemt pārāk daudz transakciju, mezgli, kas pie tā strādā, saskaņā ar iepriekÅ” noteiktiem noteikumiem to ā€œsadalaā€ divos pakārtotos - to prefiksi bÅ«s vienu mazliet garāki (un vienam no tiem Å”is bits bÅ«s vienāds ar 0, bet otram - 1). Piemēram, shard_prefix = 0110b sadalÄ«sies 01100b un 01101b. Savukārt, ja divas ā€œkaimiņķēdesā€ sāks justies pietiekami viegli (kādu laiku), tās atkal saplÅ«st.

Tādējādi sadalÄ«Å”ana notiek ā€œno apakÅ”as uz augÅ”uā€ - mēs pieņemam, ka katram kontam ir sava Ŕķemba, bet pagaidām tos ā€œsalÄ«mē kopāā€ ar prefiksiem. Tas ir tas, ko tas nozÄ«mē BezgalÄ«gas sadalÄ«Å”anas paradigma (bezgalÄ«gas sadalÄ«Å”anas paradigma).

AtseviŔķi vēlos uzsvērt, ka darba ķēdes pastāv tikai virtuāli ā€“ patiesÄ«bā, darba ķēdes_id tā ir daļa no noteiktas shardchain identifikatora. Formālā izteiksmē katru shardchain nosaka skaitļu pāris (darba ķēdes_id, shard_prefix).

Kļūdu laboÅ”ana. Vertikālās blokķēdes.

Tradicionāli jebkurÅ” darÄ«jums blokķēdē tiek uzskatÄ«ts par ā€œakmenÄ« iecirstuā€. Tomēr TON gadÄ«jumā ir iespējams ā€œpārrakstÄ«t vēsturiā€ - ja kāds (tā sauktais. zvejnieka mezgls) pierādÄ«s, ka viens no blokiem ir parakstÄ«ts nepareizi. Å ajā gadÄ«jumā attiecÄ«gajai shardchain tiek pievienots Ä«paÅ”s korekcijas bloks, kas satur paÅ”a labojamā bloka jaucējkodu (nevis pēdējo shardchain bloku). Domājot par shardchain kā horizontāli izkārtotu bloku ķēdi, varam teikt, ka korektÄ«vais bloks ir piestiprināts kļūdainajam blokam nevis pa labi, bet no augÅ”as - tāpēc tiek uzskatÄ«ts, ka tas kļūst par daļu no nelielas ā€œvertikālās blokķēdesā€ . Tādējādi mēs varam teikt, ka shardchains ir divdimensiju blokķēdes.

TON: Telegram atvērtais tīkls. 2. daļa: Blockchains, sharding

Ja pēc kļūdaina bloka uz tā veiktajām izmaiņām atsaucās nākamie bloki (t.i., tika veikti jauni darÄ«jumi, pamatojoties uz nederÄ«giem), Å”iem blokiem ā€œaugŔāā€ tiek pievienoti arÄ« labojoÅ”ie. Ja bloki neietekmēja ā€œietekmētoā€ informāciju, Å”ie ā€œkorektÄ«vie viļņiā€ uz tiem neattiecas. Piemēram, attēlā augŔā pirmā bloka darÄ«jums, palielinot konta C atlikumu, tika atzÄ«ts par nepareizu - tāpēc arÄ« treÅ”ajā blokā ir jāatceļ darÄ«jums, kas samazina Ŕī konta atlikumu, un koriģējoÅ”ais bloks. bÅ«tu jāveic virs paÅ”a bloka.

JāatzÄ«mē, ka, lai gan koriģējoÅ”ie bloki ir attēloti kā novietoti ā€œvirsā€ oriÄ£inālajiem blokiem, patiesÄ«bā tie tiks pievienoti attiecÄ«gās blokķēdes beigām (kur tiem jābÅ«t hronoloÄ£iski). Divdimensiju atraÅ”anās vieta parāda tikai to, uz kuru blokķēdes punktu tie tiks ā€œsaistÄ«tiā€ (izmantojot tajos esoŔā sākotnējā bloka hash).

Varat atseviŔķi pafilozofēt par to, cik labs ir lēmums ā€œmainÄ«t pagātniā€. Å Ä·iet, ka, ja mēs pieļaujam nepareiza bloka parādÄ«Å”anās iespēju shardchain, tad mēs nevaram izvairÄ«ties no kļūdaina korektÄ«va bloka parādÄ«Å”anās. Å eit, cik es varu spriest, atŔķirÄ«ba ir mezglu skaitā, kuriem jāpanāk vienprātÄ«ba par jauniem blokiem - pie katras shardchain strādās salÄ«dzinoÅ”i neliels cilvēku skaits.darba grupaĀ» mezgli (kas diezgan bieži maina savu sastāvu), un koriģējoÅ”u bloku ievieÅ”anai bÅ«s nepiecieÅ”ama visu piekriÅ”ana validatora mezgli. Vairāk par validētājiem, darba grupām un citām mezglu lomām pastāstÄ«Å”u nākamajā rakstā.

Viena blokķēde, lai pārvaldītu tos visus

IepriekÅ” ir daudz informācijas par dažāda veida blokķēdēm, kuras paÅ”as arÄ« kaut kur bÅ«tu jāglabā. Jo Ä«paÅ”i mēs runājam par Ŕādu informāciju:

  • par darba ķēžu skaitu un konfigurācijām;
  • par shardķēžu skaitu un to prefiksiem;
  • par to, kuri mezgli paÅ”laik ir atbildÄ«gi par kuriem shardchainiem;
  • pēdējo bloku hashes, kas pievienotas visām shardchains.

Kā jÅ«s varētu uzminēt, visas Ŕīs lietas tiek ierakstÄ«tas citā blokķēdes krātuvē - meistarķēde (meistarķēde, galvenā blokķēde). Sakarā ar to, ka tā blokos ir jaucējvārdi no visu shardķēžu blokiem, tas padara sistēmu ļoti savienotu. Tas cita starpā nozÄ«mē, ka jauna bloka Ä£enerÄ“Å”ana galvenajā ķēdē notiks uzreiz pēc bloku Ä£enerÄ“Å”anas shardchains - ir sagaidāms, ka bloki shardchains parādÄ«sies gandrÄ«z vienlaikus aptuveni ik pēc 5 sekundēm, un nākamais bloks masterchain - sekunde pēc tam.

Bet kurÅ” bÅ«s atbildÄ«gs par visa Ŕī titāniskā darba ievieÅ”anu - par ziņojumu sÅ«tÄ«Å”anu, viedo lÄ«gumu izpildi, bloku veidoÅ”anu shardchain un masterchain un pat pārbaudi, vai blokos nav kļūdu? Vai to visu slepeni darÄ«s miljoniem lietotāju tālruņi, kuros ir instalēts Telegram klients? Vai varbÅ«t Durova komanda atteiksies no decentralizācijas idejām un viņu serveri darÄ«s to vecmodÄ«gi?

PatiesÄ«bā ne viena, ne otra atbilde nav pareiza. Bet Ŕī raksta piemales ātri izsÄ«kst, tāpēc nākamajā daļā mēs runāsim par dažādām mezglu lomām (iespējams, jÅ«s jau pamanÄ«jāt dažus no tiem pieminēt), kā arÄ« to darba mehāniku.

Avots: www.habr.com

Pievieno komentāru