Ky ky tekst është vazhdimi i një serie artikujsh, në të cilët shqyrtoj strukturën (ndoshta) të rrjetit të shpërndarë Telegram Open Network (TON) që pritet të dalë këtë vit. Unë përshkrova nivelin e tij më themelor - mënyrën e ndërveprimit të nodëve mes tyre.
Për rastin se e kujtoj, që zhvillimi i këtij rrjeti nuk ka lidhje me mua dhe të gjitha materialet janë marrë nga burime të hapura (edhe pse të paverifikuara) - (po ashtu ka një , e cila përmbledh në mënyrë shkurtore pikat kryesore), e cila u shfaq në fund të vitit të kaluar. Sasia e informacionit në këtë dokument, sipas mendimit tim, dëshmon për autenticitetin e tij, edhe pse nuk ka asnjë konfirmim zyrtar për këtë.
Sot do të shikojmë komponentin kryesor të TON - blockchain-in.
Koncepte Bazë
Llogari (account). Një grup të dhënash, i identifikuar nga një numër 256-bitësh account_id (shpesh ky është çelësi publik i pronarit të llogarisë). Në rastin themelor (shih më poshtë blockchain-i zero), këto të dhëna nënkuptojnë balancën e përdoruesit. "Të huazosh" një account_id mund ta bëjë kushdo, por të ndryshosh vlerën e tij mundesh vetëm sipas rregullave të caktuara.
Kontrata inteligjente (smart-contract). Në thelb - një rast i veçantë i llogarisë, e cila është e pasuruar me kodin e kontratës inteligjente dhe ruan variablat e saj. Në rastin e "portofolit", mund të depozitosh dhe tërheqësh para nga ai sipas rregullave relativisht të thjeshta dhe të përcaktuara më parë, por në rastin e kontratës inteligjente këto rregulla shkruhen në formën e kodit të saj (në një gjuhë programimi të plotë të Turing-ut).
Gjendja e blockchain-it (state of blockchain). Kështu, gjendja e të gjitha llogarive/konttratave inteligjente (në një kuptim abstrakt - një tabelë hash, ku çelësat janë identifikues të llogarive dhe vlerat janë të dhënat e ruajtura në llogari).
Mesazhi (message). MĂ« lart kam pĂ«rdorur shprehjen "depozitoni dhe tĂ«rhiqni para" - ky Ă«shtĂ« njĂ« shembull specifik i mesazhit ("tĂ« dĂ«rgojĂ« N gramĂ« nga llogaria account_1 nĂ« llogarinĂ« account_2"). ĂshtĂ« e qartĂ« se njĂ« mesazh tĂ« tillĂ« mund ta dĂ«rgojĂ« vetĂ«m njĂ« nodĂ« qĂ« zotĂ«ron çelĂ«sin privat tĂ« llogarisĂ« account_1 dhe qĂ« Ă«shtĂ« nĂ« gjendje ta konfirmojĂ« kĂ«tĂ« me nĂ«nshkrim. Rezultati i dĂ«rgimit tĂ« mesazheve tĂ« tilla pĂ«r njĂ« llogari normale Ă«shtĂ« rritja e balancĂ«s sĂ« saj, dhe pĂ«r kontratĂ«n inteligjente - ekzekutimi i kodit tĂ« saj (i cili do tĂ« procesojĂ« pranimin e mesazhit). Natyrisht, janĂ« tĂ« mundshme edhe mesazhe tĂ« tjera (tĂ« cilat transferojnĂ« jo sasi monetare, por tĂ« dhĂ«na tĂ« rastit mes kontratave inteligjente).
Transaksioni (transaction). Fakti i dĂ«rgimit tĂ« mesazhit quhet transaksion. Transaksionet ndryshojnĂ« gjendjen e blockchain-it. Blloqet nĂ« blockchain pĂ«rbĂ«hen pikĂ«risht nga transaksionet (regjistrimet e dĂ«rgimit tĂ« mesazheve). NĂ« kĂ«tĂ« kuptim, gjendja e blockchain-it mund tĂ« paraqitet si njĂ« bazĂ« tĂ« dhĂ«nash inkrementale â tĂ« gjitha blloqet janĂ« «dife» qĂ« duhet tĂ« aplikohen njĂ«ra pas tjetrĂ«s pĂ«r tĂ« marrĂ« gjendjen aktuale tĂ« DB-sĂ«. PĂ«r specifikat e paketimit tĂ« kĂ«tyre «difeve» (dhe rikthimin e gjendjes sĂ« plotĂ« mbi to) do tĂ« flitet nĂ« artikullin e ardhshĂ«m.
Blockchain në TON: çfarë është dhe përse?
Siç u pĂ«rmend nĂ« artikullin e kaluar, blockchain Ă«shtĂ« njĂ« strukturĂ« tĂ« dhĂ«nash, elementet (blloqet) e sĂ« cilĂ«s janĂ« renditur nĂ« njĂ« «zinxhir», dhe çdo bllok i ardhshĂ«m i zinxhirit pĂ«rmban hash-in e atij tĂ« mĂ«parshmi. NĂ« komentet u hodh njĂ« pyetje: pĂ«rse ka nevojĂ« pĂ«r njĂ« strukturĂ« tĂ« tillĂ« tĂ« dhĂ«nash, kur tashmĂ« kemi DHT â njĂ« tabelĂ« tĂ« shpĂ«rndarĂ« tĂ« hash-eve? ĂshtĂ« e qartĂ« se disa tĂ« dhĂ«na mund tĂ« ruhen edhe nĂ« DHT, por kjo pĂ«rshtatet vetĂ«m pĂ«r informacionin qĂ« nuk Ă«shtĂ« shumĂ« «sensitiv». Balancat e kriptomonedhĂ«s nuk mund tĂ« ruhen nĂ« DHT â nĂ« radhĂ« tĂ« parĂ« pĂ«r shkak tĂ« mungesĂ«s sĂ« verifikimeve pĂ«r integritetin. NĂ« thelb, e gjithĂ« kompleksiteti i strukturĂ«s sĂ« blockchain-it rritet pĂ«r tĂ« parandaluar ndĂ«rhyrjet nĂ« tĂ« dhĂ«nat qĂ« ruhen nĂ« tĂ«.
MegjithatĂ«, blockchain nĂ« TON duket edhe mĂ« i komplikuar se nĂ« shumicĂ«n e sistemeve tĂ« tjera tĂ« shpĂ«rndara â dhe ka dy arsye pĂ«r kĂ«tĂ«. E para â dĂ«shira pĂ«r tĂ« minimizuar nevojĂ«n pĂ«r forks. NĂ« kriptovalutat tradicionale, tĂ« gjitha parametrat janĂ« caktuar nĂ« fazĂ«n fillestare dhe çdo pĂ«rpjekje pĂ«r t'i ndryshuar ato çon praktikisht nĂ« shfaqjen e njĂ« «universi alternativ tĂ« kriptovalutĂ«s». Arsyja e dytĂ« â mbĂ«shtetje pĂ«r ndarjen (sharding, shardim) tĂ« blockchain-it. Blockchain Ă«shtĂ« njĂ« strukturĂ«, e cila nuk mund tĂ« bĂ«het mĂ« e vogĂ«l me kalimin e kohĂ«s; dhe zakonisht çdo nod, i cili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r funksionimin e rrjetit, detyrohet ta ruajĂ« atĂ« plotĂ«sisht. NĂ« sistemet tradicionale (centralizuara) pĂ«r tĂ« zgjidhur probleme tĂ« tilla aplikohet sharding: njĂ« pjesĂ« e regjistrimeve nĂ« DB ndodhet nĂ« njĂ« server, njĂ« pjesĂ« â nĂ« njĂ« tjetĂ«r, etj. NĂ« rastin e kriptomonedhave, njĂ« funksionalitet i tillĂ« Ă«shtĂ« ende mjaft i rrallĂ« â nĂ« veçanti pĂ«r shkak tĂ« faktit se Ă«shtĂ« e vĂ«shtirĂ« tĂ« shtohet sharding nĂ« njĂ« sistem ku ai nuk ishte parashikuar fillimisht.
Si do të planifikojë TON të zgjidhë të dy problemet e përmendura më sipër?
PĂ«rmbajtja e blockchain. Vorkchain.
SĂ« pari, le tĂ« flasim pĂ«r atĂ« se çfarĂ« planifikohet tĂ« ruhen nĂ« blockchain. Atje do tĂ« ruhen gjendjet e llogarive («portofolĂ«ve» nĂ« rastin bazik) dhe kontratat smart (pĂ«r thjeshtĂ«si, do tĂ« konsiderojmĂ« se Ă«shtĂ« e njĂ«jta gjĂ« si llogaritĂ«). NĂ« thelb, kjo do tĂ« jetĂ« njĂ« tabelĂ« hash standarde â identifikuesit do tĂ« shĂ«rbejnĂ« si çelĂ«sa account_id, ndĂ«rsa vlerat do tĂ« jenĂ« struktura tĂ« dhĂ«nash qĂ« pĂ«rmbajnĂ« gjĂ«ra tĂ« tilla si:
- bilanci;
- Kodi i kontratës smart (vetëm për kontratat smart);
- Depozita e të dhënave të kontratës smart (vetëm për kontratat smart);
- statistika;
- (opsionale) çelësi publik për transfertat nga llogaria, me default account_id;
- rendi i mesazheve dalëse (këtu regjistrohen për dërgim te marrësi);
- lista e mesazheve të fundit të dorëzuara për këtë llogari.
Siç u tha, blloqet pĂ«rbĂ«hen drejtpĂ«rdrejt nga transaksionet â mesazhe tĂ« dorĂ«zuara nĂ« llogaritĂ« e ndryshme account_id. MegjithatĂ«, pĂ«rveç account_id, mesazhet pĂ«rmbajnĂ« gjithashtu njĂ« fushĂ« 32-bit workchain_id â identifikuesi i ashtuquajtur vorkchain (workchain, blloku i punĂ«s). Kjo lejon qĂ« tĂ« ketĂ« disa blockchain tĂ« pavarur nga njĂ«ri-tjetri me konfiguracione tĂ« ndryshme. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, workchain_id = 0 konsiderohet rast special, vorkchain-i zero â bilancet qĂ« ndodhen aty do tĂ« korrespondojnĂ« me kriptovalutĂ«n TON (Grams). Me gjasĂ«, nĂ« fillim nuk do tĂ« ekzistojnĂ« tĂ« tjera vorkchain.
Shardchains. Paradigma e Sharding-ut të Pafund.
Por rritja e numrit tĂ« blockchain-ve nuk ndalon kĂ«tu. Le tĂ« kuptojmĂ« sharding-un. Imagjinoni se çdo llogari (account_id) ka blockchain-in e vet â aty ndodhen tĂ« gjitha mesazhet qĂ« i vijnĂ« â dhe gjendjet e tĂ« gjithĂ«ve kĂ«tyre blockchain-ve ruhen nĂ« node tĂ« veçanta.
Sigurisht, kjo Ă«shtĂ« shumĂ« e shpenzueshme: me siguri, nĂ« secilin nga kĂ«to shardchains (shardchain, blloku i shard-it) transaksionet do tĂ« mbĂ«rrijnĂ« shumĂ« rrallĂ«, dhe do tĂ« nevojiten shumĂ« node tĂ« fuqishme (pĂ«r t'u shkuar pĂ«rpara, vĂ«rej se bĂ«het fjalĂ« jo vetĂ«m pĂ«r klientĂ« nĂ« telefonat mobil â por pĂ«r serverĂ« tĂ« rĂ«ndĂ«sishĂ«m).
Prandaj, shardchains kombinon llogaritĂ« sipas prefikseve binarĂ« tĂ« identifikuesve tĂ« tyre: nĂ«se shardchain ka prefiks 0110, atĂ«herĂ« do tĂ« pĂ«rfshihen transaksionet e tĂ« gjitha account_id qĂ« fillojnĂ« me kĂ«to numra. Ky shard_prefix mund tĂ« ketĂ« njĂ« gjatĂ«si nga 0 deri nĂ« 60 bit â dhe e rĂ«ndĂ«sishme, mund tĂ« ndryshojĂ« dinamikisht.
Kur sa njĂ« nga shardchain-Ă«t fillon tĂ« pranojĂ« njĂ« numĂ«r tĂ« tepĂ«rt transaksionesh, nyjat qĂ« punojnĂ« mbi tĂ«, sipas rregullave tĂ« caktuara paraprakisht, "ndajnĂ«" atĂ« nĂ« dy fije tĂ« reja â prefikset e tyre do tĂ« jenĂ« njĂ« bit mĂ« tĂ« gjata (dhe pĂ«r njĂ«rĂ«n prej tyre ky bit do tĂ« jetĂ« 0, ndĂ«rsa pĂ«r tjetrĂ«n â 1). PĂ«r shembull, shard_prefix = 0110b do tĂ« ndahet nĂ« 01100b dhe 01101b. Nga ana tjetĂ«r, nĂ«se dy "fije" fqinjĂ« fillojnĂ« tĂ« ndihen mjaft komode (pĂ«r njĂ« periudhĂ« tĂ« caktuar), ato pĂ«rsĂ«ri do tĂ« bashkohen.
Pra, sharding-u bĂ«het "nga poshtĂ« lart" â ne supozojmĂ« se secili llogari ka shardin e vet, por ato â deri nĂ« njĂ« moment â janĂ« "ngjitur" sipas prefikseve. Kjo nĂ«nkupton Paradigma Infinite Sharding (paradigmĂ«n e sharding-ut tĂ« pafund).
VeçanĂ«risht do tĂ« doja tĂ« theksoja se workchain-Ă«t ekzistojnĂ« vetĂ«m nĂ« mĂ«nyrĂ« virtuale â nĂ« tĂ« vĂ«rtetĂ«, workchain_id Ă«shtĂ« njĂ« pjesĂ« e identifikuesit tĂ« caktuar tĂ« shardchain-it. Duke folur nĂ« njĂ« gjuhĂ« formale, çdo shardchain pĂ«rcaktohet nga njĂ« çift numrash (workchain_id, shard_prefix).
Korrigjimi i gabimeve. Bllokchain-et vertikale.
Tradicionalisht mendohet se çdo transaksion nĂ« blockchain Ă«shtĂ« "i gdhendur nĂ« gur". MegjithatĂ«, nĂ« rastin e TON-it parashikohet mundĂ«sia pĂ«r "tĂ« shkruar historinĂ«" â nĂ« rast se dikush (nĂ« kĂ«tĂ« rast, nyja-"peshkatar") dĂ«shmon se njĂ« nga blloqet Ă«shtĂ« nĂ«nshkruar nĂ« mĂ«nyrĂ« tĂ« gabuar. NĂ« kĂ«tĂ« rast, nĂ« shardchain-in pĂ«rkatĂ«s shtohet njĂ« bllok korrigjues, qĂ« pĂ«rmban hash-in e bllokut qĂ« po korrigjohet (e jo tĂ« bllokut tĂ« fundit nĂ« shardchain). Duke e para shardchain-in si njĂ« zinxhir blloqesh qĂ« i pĂ«rgjigjet horizontalisht, mund tĂ« thuhet se blloku korrigjues bashkĂ«lidhet me bllokun e gabuar jo nĂ« tĂ« djathtĂ«, por sipĂ«r â prandaj besohet se ai bĂ«het pjesĂ« e njĂ« "blockchain-i vertical tĂ« vogĂ«l". KĂ«shtu, mund tĂ« thuhet se shardchain-et janĂ« blockchain tĂ« dyanshĂ«m.
NĂ« rastin kur pas njĂ« bloku tĂ« gabuar blloqet e mĂ«vonshme referoheshin nĂ« ndryshimet e bĂ«rĂ« prej tij (dmth, ishin realizuar transaksione tĂ« reja mbi baza jo valide), ato blloqe gjithashtu do tĂ« kenĂ« shtresĂ«n e korrigjimit sipĂ«r. NĂ«se blloqet nuk preknin informatat "e goditura", ato nuk do tĂ« ishin tĂ« prekur nga kĂ«to "valĂ« korrigjuese". PĂ«r shembull, nĂ« ilustrimin e mĂ«sipĂ«rm, transaksioni i bllokut tĂ« parĂ« u cilĂ«sua si i pavlefshĂ«m, qĂ« rrit bilancin e llogarisĂ« C â prandaj transaksioni qĂ« ul bilancin e kĂ«tij llogarie nĂ« bllokun e tretĂ« gjithashtu duhet tĂ« anulohet, dhe mbi vetĂ« bllokun do tĂ« komitohet njĂ« bllok korrigjues.
Duhet tĂ« theksohet â ndonĂ«se blloqet korrigjuese shfaqen tĂ« pozicionuara "sipĂ«r" origjinalĂ«ve, nĂ« fakt ato do tĂ« shtohen nĂ« fund tĂ« pĂ«rkatĂ«sit blockchain (aty ku duhet tĂ« jenĂ« kronologjikisht). Pozicioni dy-dimensionale vetĂ«m tregon se nĂ« cilĂ«n pikĂ« nĂ« blockchain ato do tĂ« "lidhen" (pĂ«rmes hash-it tĂ« bllokut origjinal qĂ« ndodhet brenda tyre).
Mund tĂ« filozofojmĂ« separatisht pĂ«r sa e mirĂ« Ă«shtĂ« zgjidhja "tĂ« ndryshosh tĂ« kaluarĂ«n". Duket se, nĂ«se ne lejojmĂ« mundĂ«sinĂ« e shfaqjes sĂ« njĂ« blloku tĂ« gabuar nĂ« sharding, atĂ«r nuk duhet tĂ« pĂ«rjashtohet mundĂ«sia e shfaqjes sĂ« njĂ« blloku korrigjues tĂ« gabuar. KĂ«tu, sa mund tĂ« gjykoj, ndryshimi Ă«shtĂ« nĂ« numrin e nyjeve qĂ« duhet tĂ« arrijnĂ« konsensus mbi blloqet e reja â mbi çdo sharding do tĂ« punohet nga njĂ« "grup pune" i nyjeve (shumĂ« shpesh qĂ« ndryshojnĂ« pĂ«rbĂ«rjen e tyre), ndĂ«rsa futja e blloqeve korrigjuese do tĂ« kĂ«rkojĂ« miratimin e tĂ« gjitha nyjeve-validatore. MĂ« shumĂ« pĂ«r validatoret, grupet e punĂ«s dhe role tĂ« tjera tĂ« nyjeve do t'ju tregoj nĂ« artikullin tjetĂ«r.
Një blockchain, për të kontrolluar të gjithë
Më lart është përmendur shumë informacion mbi llojet e ndryshme të blockchain-ëve, që gjithashtu duhet të ruhet diku. Në veçanti, bëhet fjalë për informacionin e mëposhtëm:
- për numrin dhe konfigurimet e workchains;
- për numrin e sharding-ëve dhe prefikset e tyre;
- për cilat nyje janë përgjegjëse aktualisht për cilat sharding;
- hash-et e blloqeve të fundit të shtuar në të gjitha sharding.
Siç keni mundur tĂ« kuptoni, tĂ« gjitha kĂ«to gjĂ«ra regjistrohen nĂ« njĂ« tjetĂ«r depo-bllokchain â masterchain (masterchain, master blockchain). FalĂ« pranisĂ« sĂ« hash-eve nĂ« blloqet e tĂ« gjitha shardchains, ai e bĂ«n sistemin shumĂ« tĂ« lidhur. Kjo do tĂ« thotĂ« gjithashtu se gjenerimi i njĂ« blloku nĂ« masterchain do tĂ« ndodhĂ« menjĂ«herĂ« pas gjenerimit tĂ« blloqeve nĂ« shardchains - pritet qĂ« blloqet nĂ« shardchains tĂ« shfaqen pothuajse njĂ«kohĂ«sisht afĂ«rsisht çdo 5 sekonda, ndĂ«rsa njĂ« bllok tjetĂ«r nĂ« masterchain njĂ« sekondĂ« pas kĂ«saj.
Por kush do të jetë përgjegjës për realizimin e gjithë kësaj pune titanike - për dërgimin e mesazheve, ekzekutimin e kontratave inteligjente, formimin e blloqeve në shardchains dhe masterchain, dhe gjithashtu verifikimin e blloqeve për gabime? A do ta bëjnë gjithçka fshehtazi telefonat e miliona përdoruesve me klientin e instaluar të Telegramit? Ose ndoshta ekipi i Durov do të heqë dorë nga idetë e decentralizimit dhe do ta bëjnë këtë serverët e tyre si më parë?
Në të vërtetë, asnjë nga këto përgjigje nuk është e saktë. Por hapësira e këtij artikulli po mbaron shpejt, prandaj diskutimi mbi rolet e ndryshme të nyjeve (ju mund të keni vënë re përmendjen e disa prej tyre), si dhe mekanikat e funksionimit të tyre do të vazhdojë në pjesën tjetër.
Burimi: habr.com
