<\/a><\/noindex><\/p>\nBasic Concepts<\/h3>\n <\/p>\n
Fi\u00f3k<\/strong> (account<\/em>). Egy adatcsomag, amelyet egy 256 bites sz\u00e1m azonos\u00edt, account_id<\/em> (t\u00f6bbnyire ez a fi\u00f3k tulajdonos\u00e1nak nyilv\u00e1nos kulcsa). Az alapvet\u0151 esetben (l\u00e1sd lentebb nulla munkal\u00e1nc<\/em>), ez alatt az adatok alatt a felhaszn\u00e1l\u00f3 egyenleg\u00e9t \u00e9rtj\u00fck. A konkr\u00e9t \"k\u00f6lcs\u00f6nz\u00e9st\" b\u00e1rki k\u00e9rheti, de az \u00e9rt\u00e9k m\u00f3dos\u00edt\u00e1sa csak meghat\u00e1rozott szab\u00e1lyok szerint lehets\u00e9ges. account_id<\/em> A \"Smart Contract\"<\/p>\n<\/p>\n
smart-contract<\/strong> (). L\u00e9nyeg\u00e9ben \u2014 egy fi\u00f3k k\u00fcl\u00f6n esete, kieg\u00e9sz\u00edtve a smart contract k\u00f3dj\u00e1val \u00e9s a v\u00e1ltoz\u00f3i t\u00e1rol\u00f3j\u00e1val. Ha a \"t\u00e1rca\" eset\u00e9ben a p\u00e9nz be- \u00e9s kifizet\u00e9s\u00e9t viszonylag egyszer\u0171, el\u0151re meghat\u00e1rozott szab\u00e1lyok szerint lehet v\u00e9grehajtani, a smart contract eset\u00e9ben ezek a szab\u00e1lyok a k\u00f3dj\u00e1ban vannak r\u00f6gz\u00edtve (valamilyen Turing-teljes programoz\u00e1si nyelven).<\/em>A blokkl\u00e1nc \u00e1llapota<\/p>\n<\/p>\n
state of blockchain<\/strong> (). Az \u00f6sszes fi\u00f3k\/smart contract \u00e1llapotainak \u00f6sszess\u00e9ge (abstrakt \u00e9rtelemben \u2014 hash-t\u00e1bla, ahol a kulcsok a fi\u00f3k azonos\u00edt\u00f3k, az \u00e9rt\u00e9kek pedig a fi\u00f3kokban t\u00e1rolt adatok).<\/em>). Feljebb haszn\u00e1ltam a \"be- \u00e9s kifizet\u00e9sek\" kifejez\u00e9st \u2014 ez egy konkr\u00e9t p\u00e9lda az \u00fczenetk\u00fcld\u00e9shez (\"\u00e1tutalni<\/p>\n<\/p>\n
\u00dczenet<\/strong> (\u00fczenet<\/em>N grammot a fi\u00f3kb\u00f3l<\/em> account_1 fi\u00f3kra<\/em> account_2 \"). Nyilv\u00e1nval\u00f3, hogy ilyen \u00fczenetet csak az a csom\u00f3pont k\u00fcldhet el, amely rendelkezik a fi\u00f3k priv\u00e1t kulcs\u00e1val<\/em>\u2014 \u00e9s k\u00e9pes ezt al\u00e1\u00edr\u00e1s\u00e1val meger\u0151s\u00edteni. Az \u00fczenetek a rendes fi\u00f3khoz val\u00f3 eljuttat\u00e1sa n\u00f6veli a fi\u00f3k egyenleg\u00e9t, a smart contract eset\u00e9ben pedig a k\u00f3dja v\u00e9grehajt\u00e1s\u00e1t eredm\u00e9nyezi (ami feldolgozza az \u00fczenet fogad\u00e1s\u00e1t). Nyilv\u00e1n m\u00e1s \u00fczenetek is lehets\u00e9gesek (amelyek nem p\u00e9nz\u00f6sszegeket, hanem tetsz\u0151leges adatokat hordoznak a smart contractok k\u00f6z\u00f6tt). fi\u00f3kra<\/em> transaction<\/p>\n<\/p>\n
A tranzakci\u00f3<\/strong> (transaction<\/em>). A sz\u00e1ll\u00edt\u00e1si \u00fczenet t\u00e9nye tranzakci\u00f3nak nevezik. A tranzakci\u00f3k megv\u00e1ltoztatj\u00e1k a blokkl\u00e1nc \u00e1llapot\u00e1t. A blokkok a blokkl\u00e1ncban val\u00f3j\u00e1ban tranzakci\u00f3kb\u00f3l (\u00fczenetk\u00e9zbes\u00edt\u00e9si feljegyz\u00e9sekb\u0151l) \u00e1llnak. Ebben az \u00e9rtelemben a blokkl\u00e1nc \u00e1llapot\u00e1t egy inkrement\u00e1lis adatb\u00e1zisk\u00e9nt lehet elk\u00e9pzelni \u2014 minden blokk egy \u201ediff\u201d, amelyet sorban kell alkalmazni a jelenlegi adatb\u00e1zis \u00e1llapot\u00e1nak el\u00e9r\u00e9s\u00e9hez. Az ezen \u201ediffek\u201d csomagol\u00e1s\u00e1nak \u00e9s a teljes \u00e1llapot helyre\u00e1ll\u00edt\u00e1s\u00e1nak r\u00e9szleteir\u0151l a k\u00f6vetkez\u0151 cikkben lesz sz\u00f3.<\/p>\n<\/p>\n
Blokkl\u00e1nc a TON-ban: mi ez \u00e9s mi\u00e9rt fontos?<\/h3>\n <\/p>\n
Ahogy az el\u0151z\u0151 cikkben eml\u00edtettem, a blokkl\u00e1nc egy adatstrukt\u00fara, amelynek elemei (blokkok) \u201el\u00e1ncba\u201d vannak rendezve, \u00e9s minden k\u00f6vetkez\u0151 blokk tartalmazza az el\u0151z\u0151 blokk hash-\u00e9t<\/em>. A hozz\u00e1sz\u00f3l\u00e1sok k\u00f6z\u00f6tt felmer\u00fclt a k\u00e9rd\u00e9s: mi\u00e9rt van egy\u00e1ltal\u00e1n sz\u00fcks\u00e9g ilyen adatstrukt\u00far\u00e1ra, amikor m\u00e1r van DHT \u2014 elosztott hash-t\u00e1bla? Nyilv\u00e1nval\u00f3, hogy bizonyos adatokat t\u00e1rolni lehet DHT-ben, de ez csak a nem t\u00fal \u201e\u00e9rz\u00e9keny\u201d inform\u00e1ci\u00f3k sz\u00e1m\u00e1ra alkalmas. A kriptovaluta egyenleg\u00e9t DHT-ben t\u00e1rolni nem lehet \u2014 els\u0151sorban a hi\u00e1nyz\u00f3 integrit\u00e1s-ellen\u0151rz\u00e9sek<\/em>. Az eg\u00e9sz blokkl\u00e1nc strukt\u00far\u00e1j\u00e1nak \u00f6sszetetts\u00e9ge az adatokban val\u00f3 beavatkoz\u00e1sok megakad\u00e1lyoz\u00e1s\u00e1\u00e9rt alakult ki.<\/p>\n<\/p>\n
Mindazon\u00e1ltal a TON blokkl\u00e1nc m\u00e9g bonyolultabbnak t\u0171nik, mint sok m\u00e1s elosztott rendszer \u2014 ennek k\u00e9t oka van. Az els\u0151 \u2014 a hardforkok sz\u00fcks\u00e9gess\u00e9g\u00e9nek minimaliz\u00e1l\u00e1s\u00e1ra ir\u00e1nyul\u00f3 t\u00f6rekv\u00e9s. . A hagyom\u00e1nyos kriptovalut\u00e1k eset\u00e9ben minden param\u00e9ter a kezdeti szakaszban van meghat\u00e1rozva, \u00e9s b\u00e1rmilyen v\u00e1ltoztat\u00e1si k\u00eds\u00e9rlet tulajdonk\u00e9ppen egy \u201ealternat\u00edv kriptovaluta univerzum\u201d l\u00e9trej\u00f6tt\u00e9hez vezet. A m\u00e1sodik ok \u2014 a blokkl\u00e1nc fragment\u00e1l\u00e1s\u00e1nak (<\/em>sharding) a t\u00e1mogat\u00e1sa. A blokkl\u00e1nc egy olyan strukt\u00fara, amely nem k\u00e9pes kicsiny\u00fclni az id\u0151 m\u00fal\u00e1s\u00e1val; \u00e9s \u00e1ltal\u00e1ban minden csom\u00f3pont, amely a h\u00e1l\u00f3zat m\u0171k\u00f6d\u00e9s\u00e9\u00e9rt felel\u0151s, k\u00e9nytelen azt teljes eg\u00e9sz\u00e9ben t\u00e1rolni. A hagyom\u00e1nyos (centraliz\u00e1lt) rendszerekben ilyen probl\u00e9m\u00e1k megold\u00e1s\u00e1ra sharding-ot alkalmaznak: az adatb\u00e1zis egy r\u00e9sze egy szerveren tal\u00e1lhat\u00f3, a m\u00e1sik r\u00e9sze pedig egy m\u00e1sikon, stb. A kriptovalut\u00e1k eset\u00e9ben ez a funkci\u00f3 egyel\u0151re meglehet\u0151sen ritka \u2014 r\u00e9szben az\u00e9rt, mert neh\u00e9z sharding-ot hozz\u00e1adni egy olyan rendszerhez, amelynek bevezet\u00e9se eredetileg nem volt tervezett.<\/em>, Hogyan tervezi a TON megoldani a fenti k\u00e9t probl\u00e9m\u00e1t?<\/em>) a blokkl\u00e1ncr\u00f3l. A blokkl\u00e1nc egy olyan strukt\u00fara, amely az id\u0151 m\u00fal\u00e1s\u00e1val nem k\u00e9pes cs\u00f6kkenni; \u00e1ltal\u00e1ban minden egyes csom\u00f3pont, amely a h\u00e1l\u00f3zat m\u0171k\u00f6d\u00e9s\u00e9\u00e9rt felel, k\u00e9nytelen azt teljes eg\u00e9sz\u00e9ben t\u00e1rolni. A hagyom\u00e1nyos (centraliz\u00e1lt) rendszerekben hasonl\u00f3 probl\u00e9m\u00e1k megold\u00e1s\u00e1ra sharding-ot alkalmaznak: az adatb\u00e1zis egyes bejegyz\u00e9sei egy szerveren tal\u00e1lhat\u00f3k, m\u00e1sok pedig egy m\u00e1sikon, \u00e9s \u00edgy tov\u00e1bb. A kriptovalut\u00e1k eset\u00e9ben ez a funkcionalit\u00e1s eddig meglehet\u0151sen ritka \u2014 r\u00e9szben az\u00e9rt, mert neh\u00e9z sharding-ot hozz\u00e1adni egy olyan rendszerhez, ahol azt kezdetben nem tervezt\u00e9k meg.<\/p>\n<\/p>\n
Hogyan tervezi a TON, hogy megoldja a fent eml\u00edtett probl\u00e9m\u00e1kat?<\/p>\n
<\/p>\n
A blokkl\u00e1nc tartalma. Workchain-ek.<\/h3>\n <\/p>\n
<\/p>\n
El\u0151sz\u00f6r is besz\u00e9lj\u00fcnk arr\u00f3l, hogy mi lesz t\u00e1rolva a blokkl\u00e1ncban. A blokkl\u00e1ncban az egyes fi\u00f3kok (a legegyszer\u0171bb esetben \u201ep\u00e9nzt\u00e1rc\u00e1k\u201d) \u00e9s okosszerz\u0151d\u00e9sek \u00e1llapotai fognak t\u00e1rol\u00f3dni (egyszer\u0171s\u00edt\u00e9sk\u00e9nt tegy\u00fck fel, hogy ezek megegyeznek a fi\u00f3kokkal). Gyakorlatilag ez egy szabv\u00e1nyos hash-t\u00e1bla lesz \u2014 a kulcsok az azonos\u00edt\u00f3k account_id<\/strong>, az \u00e9rt\u00e9kek pedig azok a strukt\u00far\u00e1k, amelyek az al\u00e1bbiakat tartalmazz\u00e1k:<\/p>\n<\/p>\n
\negyenleg;<\/li>\n okosszerz\u0151d\u00e9s k\u00f3dja (csak okosszerz\u0151d\u00e9sek eset\u00e9n);<\/li>\n okosszerz\u0151d\u00e9s adatainak t\u00e1rol\u00f3ja (csak okosszerz\u0151d\u00e9sek eset\u00e9n);<\/li>\n statisztika;<\/li>\n (opcion\u00e1lis<\/em>) nyilv\u00e1nos kulcs az fi\u00f3kb\u00f3l t\u00f6rt\u00e9n\u0151 \u00e1tutal\u00e1sokhoz, alap\u00e9rtelmezett \u00e9rt\u00e9k account_id;<\/li>\nkimen\u0151 \u00fczenetek sora (ide ker\u00fclnek az \u00fczenetek a c\u00edmzettnek val\u00f3 tov\u00e1bb\u00edt\u00e1sra);<\/li>\n a fi\u00f3khoz legut\u00f3bb k\u00e9zbes\u00edtett \u00fczenetek list\u00e1ja.<\/li>\n<\/ul>\n<\/p>\n
Mint m\u00e1r eml\u00edtett\u00fck, a blokkok val\u00f3j\u00e1ban tranzakci\u00f3kb\u00f3l \u00e1llnak \u2014 \u00fczenetekb\u0151l, amelyeket a k\u00fcl\u00f6nb\u00f6z\u0151 fi\u00f3kok account_id kapnak. Az account_id mellett az \u00fczenetek tartalmaznak egy 32 bites mez\u0151t workchain_id<\/em> \u2014 az \u00fagynevezett workchain<\/strong> (workchain<\/em>, munkablokkl\u00e1nc<\/em>). Ez lehet\u0151v\u00e9 teszi, hogy t\u00f6bb f\u00fcggetlen blokkl\u00e1nc l\u00e9tezzen elt\u00e9r\u0151 konfigur\u00e1ci\u00f3kkal. Ezzel egy\u00fctt a workchain_id = 0 k\u00fcl\u00f6nleges esetnek sz\u00e1m\u00edt, nulla workchain<\/strong> \u2014 a benne tal\u00e1lhat\u00f3 egyenlegek a TON kriptovalut\u00e1hoz (Grams) kapcsol\u00f3dnak. Val\u00f3sz\u00edn\u0171, hogy kezdetben m\u00e1s workchain-ek nem fognak egy\u00e1ltal\u00e1n l\u00e9tezni.<\/p>\n<\/p>\n
Shard l\u00e1ncok. V\u00e9gtelen Sharding Paradigma.<\/h3>\n <\/p>\n
De ezen a ponton a blokkl\u00e1ncok sz\u00e1m\u00e1nak n\u00f6veked\u00e9se m\u00e9g nem \u00e1ll meg. N\u00e9zz\u00fck meg a shardingot. K\u00e9pzelj\u00fck el, hogy minden egyes fi\u00f3knak (account_id) saj\u00e1t blokkl\u00e1nca van \u2014 ezen tal\u00e1lhat\u00f3ak az \u00f6sszes be\u00e9rkez\u0151 \u00fczenet \u2014 \u00e9s az ilyen blokkl\u00e1ncok \u00e1llapot\u00e1t k\u00fcl\u00f6n csom\u00f3pontokon t\u00e1rolj\u00e1k.<\/p>\n
<\/p>\n
Term\u00e9szetesen ez meglehet\u0151sen pazarl\u00f3: val\u00f3sz\u00edn\u0171, hogy ezekbe az shard l\u00e1ncokba<\/strong> (shardchain<\/em>, shard blokkl\u00e1ncba<\/em>) a tranzakci\u00f3k nagyon ritk\u00e1n \u00e9rkeznek, \u00e9s sok er\u0151forr\u00e1ssal rendelkez\u0151 csom\u00f3pontra lesz sz\u00fcks\u00e9g (el\u0151reugorva megjegyzem, hogy itt nem egyszer\u0171en mobiltelefonos kliensekr\u0151l besz\u00e9l\u00fcnk, hanem komoly szerverekr\u0151l).<\/p>\n<\/p>\n
Ez\u00e9rt a shard l\u00e1ncok a fi\u00f3kokat a kulcsaik bin\u00e1ris el\u0151tagjai szerint csoportos\u00edtj\u00e1k: ha a shard l\u00e1nc el\u0151tagja 0110, akkor minden account_id, ami ezekkel a sz\u00e1mokkal kezd\u0151dik, tranzakci\u00f3i be fognak ker\u00fclni. Ez a shard_prefix<\/em> hossza 0 \u00e9s 60 bit k\u00f6z\u00f6tt v\u00e1ltozhat \u2014 \u00e9s a legfontosabb, hogy dinamikusan v\u00e1ltozhat.<\/p>\n<\/p>\n
<\/p>\n
Amikor egy shardchain-re t\u00fal sok tranzakci\u00f3 \u00e9rkezik, a rajta dolgoz\u00f3 csom\u00f3pontok el\u0151re meghat\u00e1rozott szab\u00e1lyok szerint \"elosztj\u00e1k\" azt k\u00e9t ut\u00f3dra \u2014 a prefixeik egy bitnyivel hosszabbak lesznek (\u00e9s az egyik\u00fck eset\u00e9ben ez a bit 0, a m\u00e1sikn\u00e1l 1). P\u00e9ld\u00e1ul, shard_prefix<\/em> = 0110<\/u>a b el\u00e1gazik 0110<\/u>0b-re \u00e9s 0110<\/u>1b-re. Ezzel szemben, ha k\u00e9t \"szomsz\u00e9dos\" shardchain el\u00e9g k\u00e9nyelmesen \u00e9rzi mag\u00e1t (egy id\u0151 ut\u00e1n), \u00fajb\u00f3l \u00f6sszeolvadnak.<\/p>\n <\/p>\n
\u00cdgy a sharding \"alulr\u00f3l felfel\u00e9\" t\u00f6rt\u00e9nik - felt\u00e9telezz\u00fck, hogy minden fi\u00f3knak van egy saj\u00e1t shardja, de ezek - egy ideig - a prefixek ment\u00e9n \"\u00f6sszeragasztva\" vannak. Ez mag\u00e1ban foglalja Infinite Sharding Paradigm<\/strong> (a v\u00e9gtelen sharding paradigm\u00e1j\u00e1t.<\/em>).<\/p>\n<\/p>\n
K\u00fcl\u00f6n szeretn\u00e9m kiemelni, hogy a workchain-ek csak virtu\u00e1lisan l\u00e9teznek - val\u00f3j\u00e1ban, workchain_id<\/em> ez a konkr\u00e9t shardchain azonos\u00edt\u00f3ja. Form\u00e1lis nyelven fogalmazva, minden shardchain egy sz\u00e1m p\u00e1rja \u00e1ltal van defini\u00e1lva (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Hibajav\u00edt\u00e1s. F\u00fcgg\u0151leges blokkl\u00e1ncok.<\/h3>\n <\/p>\n
Hagyom\u00e1nyosan \u00fagy tekintik, hogy b\u00e1rmely tranzakci\u00f3 a blokkl\u00e1ncon \"k\u0151be v\u00e9sett\". Azonban a TON eset\u00e9ben lehet\u0151s\u00e9g van a \"t\u00f6rt\u00e9net \u00fajra\u00edr\u00e1s\u00e1ra\" - ha valaki (\u00fagynevezett \"hal\u00e1sz\" csom\u00f3pont<\/em>) bizony\u00edtja, hogy az egyik blokk hib\u00e1san lett al\u00e1\u00edrva. Ebben az esetben egy speci\u00e1lis korrekci\u00f3s blokk ker\u00fcl a megfelel\u0151 shardchainbe, amely a kijav\u00edtand\u00f3 blokk hash-\u00e9t tartalmazza (nem a shardchain utols\u00f3 blokkj\u00e1t). Ha a shardchain-t egy v\u00edzszintes blokk l\u00e1nck\u00e9nt k\u00e9pzelj\u00fck el, azt lehet mondani, hogy a korrekci\u00f3s blokk nem jobbra, hanem f\u00f6l\u00fcl kapcsol\u00f3dik a hib\u00e1s blokkhoz - ez\u00e9rt \u00fagy tekintj\u00fck, hogy a kis \"f\u00fcgg\u0151leges blokkl\u00e1nc\" r\u00e9sz\u00e9v\u00e9 v\u00e1lik. \u00cdgy kijelenthetj\u00fck, hogy a shardchain-ek k\u00e9t dimenzi\u00f3s blokkl\u00e1ncok.<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Ha egy hib\u00e1s blokkra hivatkoztak a k\u00e9s\u0151bbi blokkok (azaz, \u00faj tranzakci\u00f3k t\u00f6rt\u00e9ntek \u00e9rv\u00e9nytelen adatok alapj\u00e1n), akkor a korrekci\u00f3s blokkok is hozz\u00e1ad\u00e1sra ker\u00fclnek a hib\u00e1s blokk f\u00f6l\u00e9. Ha a blokkok nem \u00e9rintett\u00e9k a \"megs\u00e9r\u00fclt\" inform\u00e1ci\u00f3t, akkor ezek a \"korrekci\u00f3s hull\u00e1mok\" nem terjednek ki r\u00e1juk. P\u00e9ld\u00e1ul a fent eml\u00edtett illusztr\u00e1ci\u00f3ban az els\u0151 blokk tranzakci\u00f3ja lett \u00e9rv\u00e9nytelen, amely n\u00f6velte a C fi\u00f3k egyenleg\u00e9t \u2014 ez\u00e9rt a harmadik blokkban a fi\u00f3k egyenleg\u00e9t cs\u00f6kkent\u0151 tranzakci\u00f3t is \u00e9rv\u00e9nytelen\u00edteni kell, \u00e9s a blokk f\u00f6l\u00e9 egy korrig\u00e1l\u00f3 blokkot kell commit\u00e1lni.<\/p>\n
<\/p>\n
\u00c9rdemes megjegyezni \u2014 b\u00e1r a korrekci\u00f3s blokkok \u00fagy t\u0171nnek, hogy \"a\" eredeti blokkok felett helyezkednek el, val\u00f3j\u00e1ban a megfelel\u0151 blokkl\u00e1nc v\u00e9g\u00e9re lesznek fel\u00edrva (ott, ahol kronol\u00f3giailag helyezkednek el). A k\u00e9t dimenzi\u00f3s elhelyezked\u00e9s csak azt mutatja, hogy melyik ponthoz fognak \"csatlakozni\" a blokkl\u00e1ncban (az eredeti blokk hash-\u00e9n kereszt\u00fcl).<\/p>\n
<\/p>\n
Lehet k\u00fcl\u00f6nf\u00e9le filoz\u00f3fiai k\u00e9rd\u00e9seket feltenni arr\u00f3l, hogy mennyire j\u00f3 \u00f6tlet a \"m\u00falt megv\u00e1ltoztat\u00e1sa\". \u00dagy t\u0171nik, hogy ha megengedj\u00fck egy \u00e9rv\u00e9nytelen blokk megjelen\u00e9s\u00e9t a shard l\u00e1ncon, akkor nem hagyhatjuk figyelmen k\u00edv\u00fcl egy t\u00e9ves korrekci\u00f3s blokk megjelen\u00e9s\u00e9nek lehet\u0151s\u00e9g\u00e9t sem. Itt, ahogy tudom, a k\u00fcl\u00f6nbs\u00e9g a csom\u00f3pontok sz\u00e1m\u00e1ban rejlik, amelynek konszenzusra kell jutnia az \u00faj blokkokkal kapcsolatban \u2014 egy shard l\u00e1ncon viszonylag kicsi \"munkacsoport<\/em>\" csom\u00f3pont dolgozik (amely gyakran v\u00e1ltoztathatja \u00f6sszet\u00e9tel\u00e9t), de a korrekci\u00f3s blokkok hozz\u00e1ad\u00e1s\u00e1hoz minden valid\u00e1l\u00f3 csom\u00f3pont<\/em>egyet\u00e9rt\u00e9s\u00e9re van sz\u00fcks\u00e9g. A valid\u00e1torokr\u00f3l, munkacsoportokr\u00f3l \u00e9s m\u00e1s csom\u00f3ponti szerepekr\u0151l a k\u00f6vetkez\u0151 cikkemben fogok mes\u00e9lni.<\/p>\n<\/p>\n
Egy blokkl\u00e1nc, hogy mindent szab\u00e1lyozzon<\/h3>\n <\/p>\n
A fenti inform\u00e1ci\u00f3k alapj\u00e1n sokf\u00e9le blokk l\u00e1ncr\u00f3l van sz\u00f3, amit k\u00fcl\u00f6n is t\u00e1rolni \u00e9rdemes. K\u00fcl\u00f6n\u00f6sen a k\u00f6vetkez\u0151 inform\u00e1ci\u00f3k tekintet\u00e9ben:<\/p>\n
<\/p>\n
\na munkal\u00e1ncok sz\u00e1m\u00e1r\u00f3l \u00e9s konfigur\u00e1ci\u00f3j\u00e1r\u00f3l;<\/li>\n a shard l\u00e1ncokr\u00f3l \u00e9s azok prefixeir\u0151l;<\/li>\n arr\u00f3l, hogy mely csom\u00f3pontok felel\u0151sek a shard l\u00e1ncok\u00e9rt;<\/li>\n a legut\u00f3bb hozz\u00e1adott blokkok hash-ei minden shard l\u00e1ncra.<\/li>\n<\/ul>\n<\/p>\n
Ahogy m\u00e1r kital\u00e1lhatt\u00e1k, mindezek az adatok egy m\u00e1sik t\u00e1rol\u00f3 blokk l\u00e1ncban ker\u00fclnek r\u00f6gz\u00edt\u00e9sre \u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Az \u00f6sszes shard blokkj\u00e1nak hash-\u00e9nek megl\u00e9t\u00e9n\u00e9l fogva a rendszer er\u0151sen \u00f6sszekapcsol\u00f3dik. Ez azt is jelenti, hogy az \u00faj blokk gener\u00e1l\u00e1sa a masterchain-en k\u00f6zvetlen\u00fcl a shard chain-ek blokkjainak gener\u00e1l\u00e1sa ut\u00e1n fog megt\u00f6rt\u00e9nni - v\u00e1rhat\u00f3an a shard chain-ek blokkjai szinte egyszerre fognak megjelenni, k\u00f6r\u00fclbel\u00fcl 5 m\u00e1sodpercenk\u00e9nt, m\u00edg a k\u00f6vetkez\u0151 blokk a masterchain-en ennek m\u00e1sodperce ut\u00e1n fog k\u00f6vetkezni.<\/p>\n<\/p>\n
De ki lesz felel\u0151s az eg\u00e9sz \u00f3ri\u00e1si munka megval\u00f3s\u00edt\u00e1s\u00e1\u00e9rt - az \u00fczenetek tov\u00e1bb\u00edt\u00e1s\u00e1\u00e9rt, a okos szerz\u0151d\u00e9sek v\u00e9grehajt\u00e1s\u00e1\u00e9rt, a blokkok l\u00e9trehoz\u00e1s\u00e1\u00e9rt a shard chain-ekben \u00e9s a masterchain-en, nem is besz\u00e9lve a blokkok hib\u00e1inak ellen\u0151rz\u00e9s\u00e9r\u0151l? Vajon mindezt csendesen el fogj\u00e1k v\u00e9gezni a felhaszn\u00e1l\u00f3k milli\u00f3inak telefonjai, amelyeken a Telegram kliens van telep\u00edtve? Vagy tal\u00e1n a Durov csapat feladja a decentraliz\u00e1ci\u00f3 gondolat\u00e1t \u00e9s a r\u00e9gi m\u00f3dszerrel fogj\u00e1k v\u00e9gezni a szervereik?<\/p>\n
<\/p>\n
Val\u00f3j\u00e1ban egyik v\u00e1lasz sem helyes. De ennek a cikknek az oldala gyorsan fogyni kezd, ez\u00e9rt a csom\u00f3pontok elt\u00e9r\u0151 szerepeir\u0151l (m\u00e1r \u00e9szlelhette n\u00e9h\u00e1nyat a megeml\u00edt\u00e9sek k\u00f6z\u00fcl), valamint a m\u0171k\u00f6d\u00e9s\u00fck mechanizmus\u00e1r\u00f3l m\u00e1r a k\u00f6vetkez\u0151 r\u00e9szben fogunk besz\u00e9lni.<\/p>\n
Forr\u00e1s: 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