Ky kyç teks Ă«shtĂ« vazhdimi i njĂ« serie artikujsh, nĂ« tĂ« cilat shqyrtoj strukturĂ«n e (supozuar) rrjetit tĂ« shpĂ«rndarĂ« Telegram Open Network (TON), qĂ« pritet tĂ« publikohet kĂ«tĂ« vit. NĂ« kam pĂ«rshkruar nivelin e tij mĂ« bazik â mĂ«nyrĂ«n se si nodet ndĂ«rveprojnĂ« me njĂ«ra-tjetrĂ«n.
PĂ«r çdo rast, kujtoj se nuk kam lidhje me zhvillimin e kĂ«tij rrjeti dhe tĂ« gjithĂ« materialin e kam marrĂ« nga njĂ« burim tĂ« hapur (edhe pse tĂ« pa verifikuar) â (ka njĂ« , e cila pĂ«rmbledh ngjarjet kryesore), qĂ« doli nĂ« fund tĂ« vitit tĂ« kaluar. Sasia e informacionit nĂ« kĂ«tĂ« dokument, sipas mendimit tim, tregon autenticitetin e tij, megjithĂ«se nuk ka konfirmime zyrtare pĂ«r kĂ«tĂ«.
Sot do tĂ« shikojmĂ« komponentin kryesor tĂ« TON â blockchain.
Koncepte themelore
Llogaria (account). Një grup të dhënash, i identifikuar me një numër 256-bitësh account_id (më së shpeshti është çelësi publik i pronarëve të llogarive). Në rastin bazik (shih më poshtë zero blockchain), këto të dhëna nënkuptojnë bilancin e përdoruesit. "Të marrë" një account_id mund të bëjë kushdo, por ndryshimin e vlerës së saj mund ta bëjë vetëm sipas rregullave të caktuara.
Kontrata e mençur (smart-contract). NĂ« thelb â njĂ« rast i veçantĂ« i llogarisĂ«, i plotĂ«suar me kodin e kontratĂ«s smart dhe depozitĂ«n e variablave tĂ« saj. NĂ« rastin e âportofolitâ, mund tĂ« depozitoni dhe tĂ«rhiqni para prej tij sipas rregullave relativisht tĂ« thjeshta dhe tĂ« parapara, ndĂ«rsa nĂ« rastin e kontratĂ«s smart kĂ«to rregulla janĂ« shkruar nĂ« formĂ«n e kodit tĂ« saj (nĂ« njĂ« gjuhĂ« programimi tĂ« plotĂ« Turing).
Shteti i blockchain-Ă«ve (state of blockchain). NjĂ« grumbull i tĂ« gjitha shteteve tĂ« llogarive/kontratave smart (nĂ« njĂ« kuptim abstrakt â njĂ« tabelĂ« hesi, ku çelĂ«sat janĂ« identifikuesit e llogarive dhe vlerat janĂ« tĂ« dhĂ«nat e ruajtura nĂ« llogari).
Mesazhi (message). MĂ« sipĂ«r kam pĂ«rdorur shprehjen âdepozituar dhe tĂ«rhequr paraâ â kjo Ă«shtĂ« njĂ« shembull i veçantĂ« i mesazhit (âtransfero 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Ă« nyje qĂ« zotĂ«ron çelĂ«sin e mbyllur tĂ« llogarisĂ«. account_1 â dhe nĂ« gjendje tĂ« konfirmojĂ« kĂ«tĂ« me njĂ« firmĂ«. Rezultati i dĂ«rgimit tĂ« kĂ«tij mesazhi nĂ« njĂ« llogari tĂ« zakonshme Ă«shtĂ« rritja e balancit tĂ« saj, ndĂ«rsa kontrata intelligente merr pĂ«rfundimin e kodit tĂ« saj (i cili do tĂ« pĂ«rpunojĂ« pranimet e mesazhit). Natyrisht, mesazhe tĂ« tjera janĂ« tĂ« mundshme (tĂ« cilat transferojnĂ« jo shuma monetare, por tĂ« dhĂ«na tĂ« rastĂ«sishme midis kontratave inteligjente).
Transaksioni (transaksioni). Fakti i dorĂ«zimit tĂ« mesazhit quhet transaksion. Transaksionet ndryshojnĂ« gjendjen e bllokut. PikĂ«risht nga transaksionet (regjistrimet e dorĂ«zimit tĂ« mesazheve) pĂ«rbĂ«hen blloqet nĂ« bllokchain. NĂ« kĂ«tĂ« aspekt, mund tĂ« imagjinoni gjendjen e bllokut si njĂ« bazĂ« tĂ« dhĂ«nash inkrementale â tĂ« gjitha blloqet janĂ« "differencat" qĂ« duhet tĂ« aplikohen njĂ«ra pas tjetrĂ«s pĂ«r tĂ« arritur gjendjen aktuale tĂ« DB. PĂ«r specifikĂ«n e paketimit tĂ« kĂ«tyre "differencave" (dhe rindĂ«rtimin e gjendjes sĂ« plotĂ« nĂ« bazĂ« tĂ« tyre) do tĂ« diskutohet nĂ« artikullin e ardhshĂ«m.
Bllokchain në TON: çfarë është dhe përse është?
Si u pĂ«rmend nĂ« artikullin e mĂ«parshĂ«m, bllokchain Ă«shtĂ« njĂ« strukturĂ« e tĂ« dhĂ«nave, elementet (blloqet) e sĂ« cilĂ«s janĂ« tĂ« renditura nĂ« "zinxhir", dhe çdo bllok i mĂ«tejshĂ«m i zinxhirit pĂ«rmban hash-in e bllokut tĂ« mĂ«parshĂ«m. NĂ« komentet u bĂ« pyetja: pse nevojitet njĂ« strukturĂ« e tillĂ« tĂ« dhĂ«nash, kur tashmĂ« kemi DHT â njĂ« tabelĂ« heshimi tĂ« shpĂ«rndarĂ«? PovrshĂ«m, disa tĂ« dhĂ«na mund tĂ« ruhen edhe nĂ« DHT, por kjo Ă«shtĂ« e pĂ«rshtatshme vetĂ«m pĂ«r informacionin qĂ« nuk Ă«shtĂ« shumĂ« "ndjeshĂ«m". Balancet e kriptovalutave nuk mund tĂ« ruhen nĂ« DHT â kryesisht pĂ«r shkak tĂ« mungesĂ«s sĂ« kontrollit mbi 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-i nĂ« TON duket madje 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 â sinqeriteti pĂ«r tĂ« minimizuar nevojĂ«n pĂ«r forks. NĂ« kriptovalutat tradicionale, tĂ« gjitha parametrat janĂ« vendosur nĂ« fazĂ«n fillestare dhe çdo pĂ«rpjekje pĂ«r t'i ndryshuar ato çon tĂ« paktĂ«n nĂ« shfaqjen e "universit tĂ« alternativĂ«" tĂ« kriptovalutĂ«s. Arsyja e dytĂ« â mbĂ«shtetje pĂ«r fragmentimin (sharding, shardimit) blockchain. Blockchain Ă«shtĂ« njĂ« strukturĂ« qĂ« nuk mund tĂ« bĂ«het mĂ« e vogĂ«l me kalimin e kohĂ«s; dhe zakonisht çdo nod qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r funksionimin e rrjetit Ă«shtĂ« i detyruar ta mbajĂ« atĂ« plotĂ«sisht. NĂ« sistemet tradicionale (centralizuese), pĂ«r tĂ« zgjidhur probleme tĂ« tilla, aplikohet sharding: njĂ« pjesĂ« e regjistrimeve nĂ« DB Ă«shtĂ« nĂ« njĂ« server, njĂ« pjesĂ« tjetĂ«r nĂ« njĂ« tjetĂ«r, etj. NĂ« rastin e kriptomonedhave, njĂ« funksionalitet i tillĂ« Ă«shtĂ« ende mjaft i rrallĂ« - veçanĂ«risht pĂ«r shkak se Ă«shtĂ« e vĂ«shtirĂ« tĂ« shtohet sharding nĂ« njĂ« sistem ku nuk Ă«shtĂ« planifikuar qĂ« nga fillimi.
Si do të zgjidhë TON të dyja problemet e mësipërisë?
PĂ«rmbajtja e blockchain-it. Workchains.
Së pari, le të flasim për atë që planifikohet të ruhet në blockchain. Do të ruhen aty gjendjet e llogarive ("kuletat" në rastin bazë) dhe smart kontratat (për thjeshtësi, do të marrim parasysh se kjo është e njëjta gjë si llogaritë). Në thelb, kjo do të jetë një tabelë zakonore me hash - identifikuesit do të jenë çelësat account_id, ndërsa vlerat do të jenë struktura të dhënash që përmbajnë gjëra si:
- bilanci;
- kode e smart kontratës (vetëm për smart kontratat);
- hapësirë të dhënash për kontraktet smart (për kontrata të mençura vetëm);
- statistika;
- (opsionale) çelësi publik për transfertat nga llogaria, nga e thënë default account_id;
- renditja e mesazheve në dalje (këtu regjistrohen për t'u dërguar marrësit);
- lista e mesazheve të fundit të dorëzuara në këtë llogari.
Siç u tha mĂ« sipĂ«r, bloket pĂ«rbĂ«hen drejtpĂ«rdrejt nga transaksionet â mesazhet e 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 workchain (workchain, blockchain nĂ« punĂ«). Kjo lejon tĂ« kemi disa blockchains tĂ« pavarura njĂ«ri nga tjetri me konfiguracione tĂ« ndryshme. NdĂ«rkohĂ«, workchain_id = 0 konsiderohet njĂ« rast tĂ« veçantĂ«, workchain me zero â balancet e ndodhur aty do tĂ« pĂ«rputhen me kriptomonedhĂ«n TON (Grams). Ndoshta, nĂ« fillim, nuk do tĂ« ketĂ« asnjĂ« workchain tjetĂ«r qĂ« ekziston.
Shardchains. Infinite Sharding Paradigm.
Por aqo, rritja e numrit tĂ« blockchain-eve nuk ndalet kĂ«tu. Le tĂ« shqyrtojmĂ« sharding-un. Imagjinoni se çdo llogari (account_id) ka njĂ« blockchain tĂ« vetin â nĂ« tĂ« ndodhen tĂ« gjitha mesazhet qĂ« i vijnĂ« â dhe gjendjet e tĂ« gjithĂ« kĂ«tyre blockchain-eve ruajnĂ« nĂ« nodet e veçanta.
Sigurisht, kjo Ă«shtĂ« shumĂ« e shtrenjtĂ«: pĂ«r tĂ« gjitha kĂ«to shardchains (shardchain, blockchain shard) transaksionet do tĂ« hyjnĂ« shumĂ« rrallĂ«, dhe do tĂ« nevojiten shumĂ« nodet e fuqishme (duke u pĂ«rpara, do tĂ« theksoj se nuk bĂ«het fjalĂ« vetĂ«m pĂ«r klientĂ«t nĂ« telefonat mobil â por pĂ«r servera tĂ« rĂ«ndĂ«sishĂ«m).
Prandaj, shardchains bashkojnĂ« llogaritĂ« sipas prefikseve binarĂ« tĂ« identifikatorĂ«ve tĂ« tyre: nĂ«se shardchain ka prefiksin 0110, atĂ«herĂ« nĂ« tĂ« 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 gjĂ«ja mĂ« e rĂ«ndĂ«sishme Ă«shtĂ« se ai mund tĂ« ndryshojĂ« dinamikisht.
Sapo qĂ« njĂ« nga shard chains fillon tĂ« marrĂ« njĂ« numĂ«r tĂ« tepruar transaksionesh, nodet qĂ« punojnĂ« mbi tĂ«, sipas rregullave tĂ« paracaktuara, "e çojnĂ« atĂ«" nĂ« dy nĂ«na â prefikset e tyre do tĂ« jenĂ« njĂ« bit mĂ« tĂ« gjatĂ« (dhe pĂ«r njĂ«rin prej tyre ky bit do tĂ« jetĂ« 0, ndĂ«rsa pĂ«r tjetrin do tĂ« jetĂ« 1). PĂ«r shembull, shard_prefix = 0110b do tĂ« behet 01100b dhe 01101b. Nga ana tjetĂ«r, nĂ«se dy "bashkĂ«" shard chains fillojnĂ« tĂ« ndjejnĂ« mjaft lirshmĂ«ri (pĂ«r njĂ« periudhĂ« tĂ« caktuar), ata do tĂ« bashkohen sĂ«rish.
KĂ«shtu, sharding bĂ«het "nga poshtĂ« lart" â ne supozojmĂ« se çdo llogari ka shardin e saj, por ato â deri nĂ« njĂ« moment â janĂ« "tĂ« ngjitura" sipas prefikseve. Kjo Ă«shtĂ« ajo qĂ« nĂ«nkupton Infinte Sharding Paradigm (paradigma e sharding-ut tĂ« pafund).
VeçanĂ«risht, do tĂ« doja tĂ« theksoj se work chains ekzistojnĂ« vetĂ«m nĂ« formĂ« virtuale â nĂ« tĂ« vĂ«rtetĂ«, workchain_id ato janĂ« njĂ« pjesĂ« e identifikuesit tĂ« caktuar tĂ« shard chain. TĂ« flasim nĂ« njĂ« gjuhĂ« formale, çdo shard chain pĂ«rcaktohet nga njĂ« çift numrash (workchain_id, shard_prefix).
Korrigjimi i gabimeve. Bllokchain-et vertikale.
Tradicionalisht, çdo transaksion nĂ« blockchain konsiderohet si "i gdhendur nĂ« gur". MegjithatĂ«, nĂ« rastin e TON, ekziston mundĂ«sia pĂ«r "tĂ« riparuar historinĂ«" â nĂ«se dikush (i quajtur nyja-"peshkatar") provon se njĂ« nga blloqet Ă«shtĂ« nĂ«nshkruar gabim. NĂ« kĂ«tĂ« rast, nĂ« shardchainin pĂ«rkatĂ«s shtohet njĂ« bllok korrigjues, qĂ« pĂ«rmban hash-in e bllokut qĂ« po korrigjohet (e jo bllokut tĂ« fundit nĂ« shardchain). Duke e para shardchainin si njĂ« zinxhir blloqesh tĂ« vendosur horizontalisht, mund tĂ« thuhet se blloku korrigjues lidhet me bllokun e gabuar jo nĂ« tĂ« djathtĂ«, por lart â prandaj konsiderohet se bĂ«het pjesĂ« e njĂ« "blockchain-i tĂ« vogĂ«l vertikal". KĂ«shtu, mund tĂ« thuhet se shardchainet janĂ« blockchaine dy-dimensionale.
NĂ« rast se pas njĂ« bloku tĂ« gabuar, blloqet e mĂ«passhme, qĂ« referoheshin nĂ« ndryshimet e bĂ«ra, kishin kryer transaksione tĂ« reja mbi baza jo tĂ« vlefshme, kĂ«tyre blloqeve gjithashtu u shtohen blloqe korrigjuese nga lart. NĂ«se blloqet nuk preknin informatat e "pĂ«rfshira", kĂ«to "valĂ« korrigjuese" nuk pĂ«rhapen mbi to. PĂ«r shembull, nĂ« ilustrimin e mĂ«sipĂ«rm, transaksioni i bllokut tĂ« parĂ«, i cili rrit bilancin e llogarisĂ« C, u njoh si i paqartĂ« â prandaj, transaksioni qĂ« ul bilancin e kĂ«saj llogarie nĂ« bllokun e tretĂ« gjithashtu duhet tĂ« anulohet, dhe mbi vetĂ« bllokun tĂ« komitohet njĂ« bllok korrigjues.
Duhet theksuar â megjithĂ«se blloqet korrigjuese shfaqen tĂ« vendosura "mbi" origjinalet, nĂ« fakt ato do tĂ« shkruhen nĂ« fund tĂ« bllokçenĂ«s pĂ«rkatĂ«se (aty ku duhet tĂ« jenĂ« kronologjikisht). Pozita dydimensionale tregon vetĂ«m se nĂ« cilĂ«n pikĂ« nĂ« bllokçenĂ« ato do tĂ« "lidhen" (pĂ«rmes hash-it tĂ« bllokut origjinal qĂ« ndodhen nĂ« to).
Mund tĂ« diskutohet veçmas se sa e mirĂ« Ă«shtĂ« zgjidhja "pĂ«r tĂ« ndryshuar tĂ« kaluarĂ«n". Duke u dukur, nĂ«se ne lejojmĂ« mundĂ«sinĂ« e shfaqjes sĂ« njĂ« bloku tĂ« gabuar nĂ« shardchain, nuk mund tĂ« pĂ«rjashtojmĂ« mundĂ«sinĂ« e shfaqjes sĂ« njĂ« bloku korrektiv tĂ« gabuar. KĂ«tu, sa mund tĂ« gjykoj, diferenca Ă«shtĂ« numri i nodĂ«ve qĂ« duhet tĂ« arrijnĂ« konsensus pĂ«r blloqet e rinj â mbi çdo shartchain do tĂ« punojnĂ« njĂ« numĂ«r relativisht tĂ« vogĂ«l "grup punuesânodĂ«shâ, (mjaft shpesh duke ndryshuar pĂ«rbĂ«rjen e saj), dhe miratimi i blloqeve korrektiv do tĂ« kĂ«rkojĂ« miratimin e tĂ« gjithĂ« nodĂ«ve tĂ« validimit. MĂ« shumĂ« rreth validuesve, grupeve tĂ« punĂ«s dhe roleve tĂ« tjera tĂ« nodĂ«ve do tĂ« flas nĂ« artikullin e ardhshĂ«m.
Një blockchain, për të udhëhequr të gjitha
Më sipër u përmend shumë informacion rreth llojeve të ndryshme të blockchains, të cilin vetë duhet ta ruajmë diku. Në veçanti, është fjala për të dhënat e mëposhtme:
- rreth numrit dhe konfigurimeve të workchain-ëve;
- rreth numrit të shardchain-ëve dhe prefikseve të tyre;
- rreth cilave nodë janë aktualisht përgjegjëse për cilat shardchain;
- hash-et e blloqeve të fundit të shtuar në të gjitha shartchain-et.
Si e keni kuptuar, tĂ« gjitha kĂ«to gjĂ«ra regjistrohen nĂ« njĂ« depo tjetĂ«r â masterchain (masterchain, master blockchain). FalĂ« pranishmĂ«risĂ« sĂ« hash-eve nĂ« blloqet e tĂ« gjitha shardchain-Ă«ve, ai e bĂ«n sistemin shumĂ« tĂ« lidhur. Kjo do tĂ« thotĂ« se krijimi i njĂ« blloku nĂ« masterchain do tĂ« ndodhĂ« menjĂ«herĂ« pas krijimit tĂ« blloqeve nĂ« shardchain-Ă« â pritet qĂ« blloqet nĂ« shardchain-Ă« tĂ« shfaqen pothuajse njĂ«kohĂ«sisht çdo 5 sekonda, ndĂ«rsa blloku tjetĂ«r nĂ« masterchain do tĂ« vijĂ« njĂ« sekondĂ« mĂ« vonĂ«.
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 smart contracts, formimin e blloqeve nĂ« shardchain-Ă« dhe masterchain, dhe gjithashtu kontrollimin e blloqeve pĂ«r gabime? A do ta bĂ«jnĂ« gjithçka nĂ« heshtje telefonat e miliona pĂ«rdoruesve me klientin e Telegram-it tĂ« instaluar nĂ« to? Ose ndoshta ekipi i Durov do tĂ« heqĂ« dorĂ« nga idetĂ« e decentralizimit dhe kjo do tĂ« bĂ«het nga serverĂ«t e tyre nĂ« mĂ«nyrĂ«n tradicionale?
Në të vërtetë, asnjëra nga përgjigjet nuk është e saktë. Por hapësirat në këtë artikull po përfundohen shpejt, prandaj diskutimi mbi rolet e ndryshme të nyjave (mund të keni vënë re përmendjen e disa prej tyre), si dhe mekanizmat e funksionimit të tyre do të vijojë në pjesën e ardhshme.
Burimi: habr.com
