<\/a><\/noindex><\/p>\nP\u00f5hidokumendid<\/h3>\n <\/p>\n
Konto<\/strong> (account<\/em>). Teatud andmekogum, mida identifitseerib 256-bitine number account_id<\/em> (enamasti on see konto omaniku avalik v\u00f5ti). Baastasemel (vt allpool null plokiahel<\/em>), nende andmete all m\u00f5istetakse kasutaja taset. \"Laenata\" saab iga\u00fcks, kuid selle v\u00e4\u00e4rtust saab muuta ainult kindlate reeglite j\u00e4rgi. account_id<\/em> Nutikas leping<\/p>\n<\/p>\n
smart-contract<\/strong> (). Sisuliselt on see konto erijuhtum, millele on lisatud nutika lepingu kood ja selle muutujate hoidla. Kui \"rahakoti\" puhul saab raha kontole kanda ja sealt v\u00e4lja v\u00f5tta suhteliselt lihtsate ja eelnevalt m\u00e4\u00e4ratletud reeglite alusel, siis nutika lepingu puhul on need reeglid kirjas tema koodis (m\u00f5nes Turingu t\u00e4isv\u00f5imes programmeerimiskeeles).<\/em>Plokiahela olek<\/p>\n<\/p>\n
state of blockchain<\/strong> (). K\u00f5igi kontode\/nutika lepingute olekute kogum (abstraktses m\u00f5ttes \u2014 h\u00e4shtabel, kus v\u00f5tmed on konto identifikaatorid ja v\u00e4\u00e4rtused on kontodes hoitavad andmed).<\/em>). \u00dclalpool kasutasin v\u00e4ljendit \"kanda raha\" \u2014 see on eriline n\u00e4ide s\u00f5numist (\"kanda<\/p>\n<\/p>\n
Teade<\/strong> (message<\/em>N grammi kontolt<\/em> account_1 kontole<\/em> account_2 \"). Ilmselgelt saadab sellise s\u00f5numi vaid s\u00f5lm, kellel on konto privaatv\u00f5ti.<\/em>\u00bb). Ilmselt v\u00f5ib sellise s\u00f5numi saata ainult s\u00f5lm, millel on konto privaatv\u00f5ti kontole<\/em> \u2014 ja suudab seda kinnitada allkirjaga. Selliste s\u00f5numite saatmise tulemuseks tavalisele kontole on selle tasakaalu suurenemine, samas kui nutilepingule toimub olemasoleva koodi t\u00e4itmine (mis t\u00f6\u00f6tleb s\u00f5numi vastuv\u00f5tmist). Loomulikult on v\u00f5imalikud ka muud s\u00f5numid (mida kantakse, edastades mitte rahasummasid, vaid suvalisi andmeid nutilepingute vahel).<\/p>\n<\/p>\n
Tehing<\/strong> (tehing<\/em>). S\u00f5numi kohaletoimetamise fakti nimetatakse tehinguks. Tehingud muudavad plokiahela seisundit. Just tehingutest (s\u00f5numite kohaletoimetamise registreerimise) koosnevad plokid plokiahelas. Sellest vaatepunktist v\u00f5ib plokiahela seisundit kujutada kui inkrmenteerivat andmebaasi \u2014 k\u00f5ik plokid on \u201ediffid\u201d, mis tuleb j\u00e4rjestikulised rakendada, et saada praegune andmebaasi seisund. T\u00e4psemalt nende \u201ediffide\u201d pakkimise kohta (ja t\u00e4ieliku seisundi taastamise kohta nende p\u00f5hjal) r\u00e4\u00e4gime j\u00e4rgmises artiklis.<\/p>\n<\/p>\n
Plokiahel TONis: mis see on ja milleks seda vaja?<\/h3>\n <\/p>\n
Nagu mainitud eelnevas artiklis, plokiahel on andmestruktuur, mille elemendid (plokid) on j\u00e4rjestatud \u201eahelasse\u201d ja iga j\u00e4rgmine ahelaplokke sisaldab eelneva h\u00e4s\u0161i<\/em>. Kommentaarides esitati k\u00fcsimus: miks on selline andmestruktuur \u00fcldse vajalik, kui meil on juba DHT \u2014 jaotatud h\u00e4shtabel? On ilmne, et teatud andmeid saab salvestada ka DHT-s, kuid see sobib ainult mitte liiga \u201etundlikule\u201d teabele. Kr\u00fcptorahade saldod ei saa DHT-sse salvestada \u2014 eelk\u00f5ige seet\u00f5ttu, et seal puuduvad kontrollid puutumatuse<\/em>. Tegelikult tuleneb plokiahela struktuuri kogu keerukus selleks, et v\u00e4ltida sekkumist selle salvestatud andmetesse.<\/p>\n<\/p>\n
Kuid plokiahel TONis n\u00e4eb v\u00e4lja isegi keerukam kui enamik teisi jaotatud s\u00fcsteeme \u2014 ja sellel on kaks p\u00f5hjust. Esiteks \u2014 soov minimeerida vajadust haakimiste<\/em>. Traditsioonilistes kr\u00fcptovaluutades on k\u00f5ik parameetrid m\u00e4\u00e4ratud alguses ja iga nende muutmise katse viib tegelikult \u201ealternatiivse kr\u00fcptovaluuta universumi\u201d loomiseni. Teine p\u00f5hjus \u2014 toetada jaotamist (shardimist<\/em>, jagamine<\/em>) blokcheini. Blokcheyn on struktuur, mis ei suuda aja jooksul v\u00e4heneda; ja tavaliselt peab iga s\u00f5lme, mis vastutab v\u00f5rgu t\u00f6\u00f6korras hoidmise eest, selle t\u00e4iesti hoidma. Traditsioonilistes (tsentraliseeritud) s\u00fcsteemides kasutatakse sarnaste probleemide lahendamiseks l\u00f5hestamist: osa andmetest andmebaasis on \u00fchel serveril, teine osa teisel jne. Kr\u00fcptoraha puhul on selline funktsionaalsus senini \u00fcsna haruldane \u2014 eelk\u00f5ige seet\u00f5ttu, et on keeruline lisada l\u00f5hestamist s\u00fcsteemi, kus seda ei olnud algselt kavandatud.<\/p>\n<\/p>\n
Kuidas kavatseb TON lahendada m\u00f5lemad \u00fclaltoodud probleemid?<\/p>\n
<\/p>\n
Blokcheini sisu. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Esiteks r\u00e4\u00e4gime sellest, mida on plaanis blokcheinis hoida. Seal hoitakse kontode (algses juhtumis \u201erahakotid\u201c) ja nutilepingute olekuid (lihtsuse p\u00e4rast arvame, et need on samad, mis kontod). Tegu on p\u00f5him\u00f5tteliselt tavalise hash-tabeliga \u2014 v\u00f5titena on seal identifikaatorid account_id<\/strong>, v\u00e4\u00e4rtustena aga andmestruktuurid, milles sisalduvad sellised asjad nagu:<\/p>\n<\/p>\n
\nsaldo;<\/li>\n nutilepingu kood (ainult nutilepingute puhul);<\/li>\n nutilepingu andmehoidla (ainult nutilepingute puhul);<\/li>\n statistika;<\/li>\n (valikuline<\/em>) avalik v\u00f5ti kontolt \u00fclekannete jaoks, vaikimisi account_id;<\/li>\nv\u00e4ljuvate s\u00f5numite j\u00e4rjekord (siia need kantakse saatmiseks adressaadile);<\/li>\n viimasele sellele kontole edastatud s\u00f5numite nimekiri.<\/li>\n<\/ul>\n<\/p>\n
Nagu varem \u00f6eldud, koosnevad plokid otseselt tehingutest \u2014 s\u00f5numitest, mis on edastatud erinevatele kontodele account_id. Kuid lisaks account_id-le sisaldavad s\u00f5numid ka 32-bitist v\u00e4lja workchain_id<\/em> \u2014 identifikaator nii-\u00f6elda. workchain<\/strong> (workchain<\/em>, t\u00f6\u00f6tav blokchaing<\/em>). See v\u00f5imaldab omada mitmeid omavahel s\u00f5ltumatuid blokchaine erinevate konfigureeringutega. Samal ajal on workchain_id = 0 erijuhtum, nullworkchain<\/strong> \u2014 just selle saldo vastab TON (Grams) kr\u00fcptorahale. T\u00f5en\u00e4oliselt ei eksisteeri algusaegadel teisi workchain'e \u00fcldse.<\/p>\n<\/p>\n
Shardchains. L\u00f5pmatu l\u00f5hestamise paradigma.<\/h3>\n <\/p>\n
Kuid blockchain'ide arvu kasv ei peatu siin. Vaatame shardimist. Kujutame ette, et iga\u00fchele (account_id) on eraldatud omaenda blockchain - seal on k\u00f5ik tema saadetud s\u00f5numid - ja k\u00f5ikide selliste blockchain'ide olekud salvestatakse eraldi s\u00f5lmedes.<\/p>\n
<\/p>\n
Muidugi on see \u00fcsna raiskav: t\u00f5en\u00e4oliselt saab igasse neist shardchain'idesse<\/strong> (shardchain<\/em>, shard blockchain<\/em>) tehingud saavad v\u00e4ga harva, ja palju j\u00f5ulisi s\u00f5lmi on vaja (r\u00e4\u00e4kinud ette, tuletan meelde, et jutt ei k\u00e4i mitte lihtsalt mobiilsete klientide kohta - vaid t\u00f5siste serverite kohta).<\/p>\n<\/p>\n
Seet\u00f5ttu koondavad shardchain'id kontod oma identifikaatorite binaarsete prefikside j\u00e4rgi: kui shardchain'il on prefiks 0110, siis kuuluvad sinna k\u00f5ik account_id, mis algavad nende numbritega. See shard_prefix<\/em> v\u00f5ib olla pikkusega 0 kuni 60 bitti - ja mis peamine, see v\u00f5ib d\u00fcnaamiliselt muutuda.<\/p>\n<\/p>\n
<\/p>\n
Niipea, kui \u00fchte shardchain'i hakkab j\u00f5udma liiga palju tehinguid, siis selle kallal t\u00f6\u00f6tavad s\u00f5lmed vastavalt eelnevalt m\u00e4\u00e4ratletud reeglitele \"lahutavad\" selle kaheks t\u00fctar\u00fcksuseks - nende prefiksid on \u00fche bitiga pikemad (ja \u00fchele neist on see bit 0, teisele aga 1). N\u00e4iteks, shard_prefix<\/em> = 0110<\/u>b lahustub 0110<\/u>0b ja 0110<\/u>1b. Omakorda, kui kaks \"naaberriiki\" shardchain'i hakkavad end piisavalt mugavalt tundma (mingi perioodi jooksul), siis nad liituvad taas \u00fcksiksuse.<\/p>\n <\/p>\n
Nii tehakse shardimine \"alt \u00fcles\" - me eeldame, et igal kontol on oma shard, kuid need on - k\u00fcll hetkel - \"liimitud\" prefikside j\u00e4rgi. See ongi see, mida t\u00e4hendab Infinite Sharding Paradigm<\/strong> (l\u00f5putu shardimise paradigma<\/em>).<\/p>\n<\/p>\n
Erakordselt tahaks r\u00f5hutada, et workchain'id eksisteerivad ainult virtuaalselt - tegelikult, workchain_id<\/em> on see konkreetse shardchain'i identifikaatori osa. Formaalset keelt kasutades m\u00e4\u00e4ratleb iga shardchain paar numbreid (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Vigade parandamine. Vertikaalsed blockchain'id.<\/h3>\n <\/p>\n
Traditsiooni kohaselt peetakse, et iga blockchain'is olev tehing on \"kivisse raiutud\". Siiski, TON'i korral on ette n\u00e4htud v\u00f5imalus \"ajalugu \u00fcmber kirjutada\" - juhul, kui keegi (nn \"kalamehe\" s\u00f5lm<\/em>) t\u00f5estab, et \u00fcks plokk on allkirjastatud valesti. Sellisel juhul lisatakse vastavasse shard-ahelasse spetsiaalne parandav plokk, mis sisaldab parandatava ploki (mitte shard-ahela viimase ploki) h\u00e4shti. Kujutades shard-ahelat horisontaalse plokkide ahelana, v\u00f5ib \u00f6elda, et parandav plokk kinnitatakse vale ploki juurde mitte paremale, vaid \u00fclevalt - seet\u00f5ttu loetakse, et see muutub v\u00e4ikese 'vertikaalse plokiahela' osaks. Seega v\u00f5ib \u00f6elda, et shard-ahelad on kahem\u00f5\u00f5tmelised plokiahelad<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Juhul, kui vale ploki tehtud muudatustele viitasid sellele j\u00e4rgnenud plokid (st valeandmete p\u00f5hjal tehti uusi tehinguid), lisatakse ka nendele plokkidele '\u00fclevalt' parandavad plokid. Kui plokid ei puudutanud 'm\u00f5jutatuid' andmeid, ei laiene need 'parandavad lained' neile. N\u00e4iteks, nagu \u00fclaltoodud joonisel, tunnistati esimese ploki tehing vale, mis suurendas konto C saldo - seet\u00f5ttu peab ka selle konto saldo v\u00e4hendav tehing kolmandas plokis olema t\u00fchistatud ja parandav plokk peab olema kirjutatud otse selle ploki peale.<\/p>\n
<\/p>\n
Tuleb m\u00e4rkida, et ehkki parandavad plokid kuvatakse 'originalide' kohal, kirjutatakse nad tegelikult vastava plokiahela l\u00f5ppu (seal, kus nad kronoloogiliselt paiknema peavad). Kahem\u00f5\u00f5tmeline paigutus n\u00e4itab vaid, millisele plokiahela punktile nad 'kinnitatakse' (kasutades nende algse ploki h\u00e4shti).<\/p>\n
<\/p>\n
V\u00f5ib eraldi filosoofeerida selle \u00fcle, kui hea on otsus 'mineviku muutmine'. Tundub, et kui me lubame vale ploki tekkimist shard-ahelas, siis ei saa me v\u00e4listada ka vale parandava ploki v\u00f5imalust. Siin, kui ma \u00f5igesti aru sain, on erinevus s\u00f5lmede arvus, mis peavad uute plokkide \u00fcle konsensusele j\u00f5udma - iga shard-ahela kallal t\u00f6\u00f6tab suhteliselt v\u00e4iket\u00f6\u00f6r\u00fchm<\/em>s\u00f5lmede (mis sageli muudavad oma koosseisu), samas kui parandavate plokkide lisamine n\u00f5uab k\u00f5igi kehtivate s\u00f5lmede<\/em>konsensust. Rohkem r\u00e4\u00e4gin kehtijatest, t\u00f6\u00f6r\u00fchmades ja muudest s\u00f5lmede rollidest j\u00e4rgmises artiklis.<\/p>\n<\/p>\n
\u00dcks plokiahel, et k\u00f5ike juhtida<\/h3>\n <\/p>\n
\u00dclaltoodud on palju teavet erinevate plokiahelate t\u00fc\u00fcpide kohta, mida tuleb samuti kuskil salvestada. Eelk\u00f5ige r\u00e4\u00e4gime j\u00e4rgmiste andmete kohta:<\/p>\n
<\/p>\n
\nt\u00f6\u00f6tajate arvu ja konfiguratsioonide kohta;<\/li>\n \u0161ardhahelate arvu ja nende eesliidete kohta;<\/li>\n millised s\u00f5lmed vastutavad praegu milliste \u0161ardhahelate eest;<\/li>\n viimati lisatud plokkide hash'id k\u00f5ikidesse \u0161ardhahelatesse.<\/li>\n<\/ul>\n<\/p>\n
Nagu te juba v\u00f5isite arvata, salvestatakse k\u00f5ik need asjad veel \u00fchte plokiahelasse - meisterplokiahel<\/strong> (masterchain<\/em>, master blockchain<\/em>). T\u00e4nu sellele, et selle plokkides on hash'id k\u00f5igi \u0161ardhahelate plokkidest, muudab see s\u00fcsteemi tugevalt \u00fchendatuks. See t\u00e4hendab ka, et uue ploki genereerimine meisterplokiahelas toimub otse p\u00e4rast plokkide genereerimist \u0161ardhahelates - oodatakse, et plokid \u0161ardhahelates ilmuvad peaaegu samaaegselt iga viie sekundi tagant, ning j\u00e4rgmine plokk meisterplokiahelas ilmub sekund p\u00e4rast seda.<\/p>\n<\/p>\n
Aga kes on vastutav kogu selle titaanliku t\u00f6\u00f6 teostamise eest - s\u00f5numite edastamine, nutilepingute t\u00e4itmine, plokkide genereerimine \u0161ardhahelates ja meisterplokiahelas, ning plokkide vigade kontrollimine? Kas k\u00f5ik seda teevad vaikselt miljonite kasutajate telefonid, millel on installitud Telegrami klient? V\u00f5i loobub Durovi meeskond detsentraliseerimise ideedest ja teeb seda nende serverid vanamoodsalt?<\/p>\n
<\/p>\n
Tegelikult ei ole kumbki vastus \u00f5ige. Kuid selle artikli lehed l\u00f5ppevad kiiresti, seega on jutt erinevatest s\u00f5lmede rollidest (te olete ehk juba m\u00f5ned neist mainimisi m\u00e4rganud) ning nende t\u00f6\u00f6mehhanismidest j\u00e4rgmises osas.<\/p>\n
Allikas: 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