<\/a><\/noindex><\/p>\nPodstawowe poj\u0119cia<\/h3>\n <\/p>\n
Konto<\/strong> (account<\/em>). Zbi\u00f3r danych identyfikowany przez 256-bitow\u0105 liczb\u0119 account_id<\/em> (najcz\u0119\u015bciej jest to klucz publiczny w\u0142a\u015bciciela konta). W podstawowym przypadku (patrz poni\u017cej zerowy workchain<\/em>), pod tymi danymi rozumie si\u0119 saldo u\u017cytkownika. \u201ePo\u017cyczy\u0107\u201d konkretne account_id<\/em> mo\u017ce ktokolwiek, ale zmienia\u0107 jego warto\u015b\u0107 mo\u017cna tylko wed\u0142ug okre\u015blonych zasad.<\/p>\n<\/p>\n
Smart kontrakt<\/strong> (smart-contract<\/em>). W zasadzie jest to szczeg\u00f3lny przypadek konta, wzbogacony kodem smart kontraktu i magazynem jego zmiennych. Je\u015bli w przypadku \u201eportfela\u201d mo\u017cna wprowadza\u0107 i wyp\u0142aca\u0107 pieni\u0105dze na podstawie stosunkowo prostych i wcze\u015bniej okre\u015blonych zasad, to w przypadku smart kontraktu te zasady s\u0105 zapisane w formie jego kodu (w jakim\u015b j\u0119zyku programowania Turing-complete).<\/p>\n<\/p>\n
Stan blockchaina<\/strong> (state of blockchain<\/em>). Zbi\u00f3r stan\u00f3w wszystkich kont\/smart kontrakt\u00f3w (w sensie abstrakcyjnym \u2014 tabela haszowa, gdzie kluczami s\u0105 identyfikatory kont, a warto\u015bciami \u2014 dane przechowywane na kontach).<\/p>\n<\/p>\n
Komunikat<\/strong> (message<\/em>). Wspomnia\u0142em wcze\u015bniej o wyra\u017ceniu \u201ewprowadza\u0107 i wyp\u0142aca\u0107 pieni\u0105dze\u201d \u2014 to szczeg\u00f3lny przypadek wiadomo\u015bci (\u201eprzenie\u015b\u0107 N gram\u00f3w<\/em> z konta account_1<\/em> na konto account_2<\/em>\u201d). Oczywi\u015bcie, tak\u0105 wiadomo\u015b\u0107 mo\u017ce wys\u0142a\u0107 tylko w\u0119ze\u0142, kt\u00f3ry posiada prywatny klucz konta. account_1<\/em> \u2014 i potrafi to potwierdzi\u0107 podpisem. Efektem dostarczenia takich wiadomo\u015bci do zwyk\u0142ego konta jest zwi\u0119kszenie jego salda, a dla smart kontraktu \u2014 wykonanie jego kodu (kt\u00f3ry obs\u0142u\u017cy przyj\u0119cie wiadomo\u015bci). Oczywi\u015bcie mo\u017cliwe s\u0105 tak\u017ce inne wiadomo\u015bci (przenosz\u0105ce nie pieni\u0119\u017cne kwoty, ale dowolne dane mi\u0119dzy smart kontraktami).<\/p>\n<\/p>\n
Transakcja<\/strong> (transakcja<\/em>). Fakt dostarczenia wiadomo\u015bci nazywa si\u0119 transakcj\u0105. Transakcje zmieniaj\u0105 stan blockchaina. To w\u0142a\u015bnie z transakcji (rekord\u00f3w o dostarczeniu wiadomo\u015bci) sk\u0142adaj\u0105 si\u0119 bloki w blockchainie. W tym kontek\u015bcie stan blockchaina mo\u017cna wyobrazi\u0107 sobie jako inkrementaln\u0105 baz\u0119 danych \u2014 wszystkie bloki s\u0105 \u201ediffami\u201d, kt\u00f3re nale\u017cy stosowa\u0107 sekwencyjnie, aby uzyska\u0107 aktualny stan bazy danych. O specyfice pakowania tych \u201ediff\u00f3w\u201d (i przywracaniu pe\u0142nego stanu na ich podstawie) mowa b\u0119dzie w nast\u0119pnym artykule.<\/p>\n<\/p>\n
Blockchain w TON: co to jest i po co?<\/h3>\n <\/p>\n
Jak wspomniano w poprzednim artykule, blockchain to struktura danych, kt\u00f3rej elementy (bloki) s\u0105 uporz\u0105dkowane w \u201e\u0142a\u0144cuch\u201d, a ka\u017cdy kolejny blok \u0142a\u0144cucha zawiera w sobie hash poprzedniego<\/em>. W komentarzach zadano pytanie: po co w og\u00f3le potrzebna jest taka struktura danych, skoro mamy ju\u017c DHT \u2014 rozproszon\u0105 tabel\u0119 haszy? Oczywi\u015bcie, \u017ce pewne dane mo\u017cna przechowywa\u0107 i w DHT, ale to nadaje si\u0119 tylko dla nieco \u201ewra\u017cliwych\u201d informacji. Nie mo\u017cna przechowywa\u0107 sald kryptowalut w DHT \u2014 przede wszystkim z powodu braku kontroli nad integralno\u015bci\u0105<\/em>. W\u0142a\u015bciwie ca\u0142a z\u0142o\u017cono\u015b\u0107 struktury blockchaina wynika z potrzeby zapobiegania ingerencjom w przechowywane w nim dane.<\/p>\n<\/p>\n
Jednak blockchain w TON wygl\u0105da jeszcze bardziej skomplikowanie ni\u017c w wi\u0119kszo\u015bci innych rozproszonych system\u00f3w \u2014 i s\u0105 ku temu dwa powody. Pierwszy \u2014 ch\u0119\u0107 minimalizacji potrzeby fork\u00f3w<\/em>. W tradycyjnych kryptowalutach wszystkie parametry s\u0105 ustalone na pocz\u0105tkowym etapie, a ka\u017cda pr\u00f3ba ich zmiany prowadzi w praktyce do powstania \u201ealternatywnego wszech\u015bwiata kryptowalut\u201d. Drugi pow\u00f3d \u2014 wsparcie dla fragmentacji (shardingu<\/em>, shardowanie<\/em>) blockchain. Blockchain is a structure that cannot become smaller over time; and usually, each node responsible for the network's operation must store it completely. In traditional (centralized) systems, sharding is used to solve such problems: part of the database records is on one server, part is on another, and so on. In the case of cryptocurrencies, such functionality is still quite rare\u2014mainly because it is difficult to add sharding to a system where it was not originally planned.<\/p>\n<\/p>\n
How does TON plan to address both of the aforementioned issues?<\/p>\n
<\/p>\n
Content of the blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
First of all, let's talk about what will be stored in the blockchain. It will store the states of accounts (or 'wallets' in the basic case) and smart contracts (for simplicity, let's consider them the same as accounts). Essentially, this will be a regular hash table\u2014its keys will be identifiers account_id<\/strong>, and the values will be data structures containing things like:<\/p>\n<\/p>\n
\nbalance;<\/li>\n smart contract code (only for smart contracts);<\/li>\n smart contract data storage (only for smart contracts);<\/li>\n statistics;<\/li>\n (optionally<\/em>) a public key for outgoing transactions from the account, by default account_id;<\/li>\na queue of outgoing messages (they are entered here for forwarding to the recipient);<\/li>\n a list of the last messages delivered to this account.<\/li>\n<\/ul>\n<\/p>\n
As mentioned above, blocks directly consist of transactions\u2014messages delivered to various accounts account_id. However, in addition to account_id, messages also contain a 32-bit field workchain_id<\/em> \u2014 the identifier of the so-called workchain<\/strong> (workchain<\/em>, working blockchain<\/em>). This allows for several independent blockchains with different configurations. In this case, workchain_id = 0 is considered a special case, the zero workchain<\/strong> \u2014 the balances contained in it will correspond to the TON cryptocurrency (Grams). Most likely, there will be no other workchains initially.<\/p>\n<\/p>\n
Shardchains. Infinite Sharding Paradigm.<\/h3>\n <\/p>\n
Jednak wzrost liczby blockchain\u00f3w na tym si\u0119 nie zatrzymuje. Przyjrzyjmy si\u0119 shardingu. Wyobra\u017amy sobie, \u017ce ka\u017cdemu kontu (account_id) przydzielony jest w\u0142asny blockchain \u2014 w nim znajduj\u0105 si\u0119 wszystkie nadchodz\u0105ce wiadomo\u015bci \u2014 a stany wszystkich takich blockchain\u00f3w s\u0105 przechowywane na oddzielnych w\u0119z\u0142ach.<\/p>\n
<\/p>\n
Oczywi\u015bcie to do\u015b\u0107 marnotrawne: najprawdopodobniej do ka\u017cdego z tych shardchain\u00f3w<\/strong> (shardchain<\/em>, shard blockchain<\/em>) transakcje b\u0119d\u0105 wp\u0142ywa\u0107 bardzo rzadko, a potrzeba b\u0119dzie wielu pot\u0119\u017cnych w\u0119z\u0142\u00f3w (w przesz\u0142o\u015bci zaznacz\u0119, \u017ce mowa tutaj nie tylko o klientach na telefonach kom\u00f3rkowych \u2014 ale o powa\u017cnych serwerach).<\/p>\n<\/p>\n
Dlatego shardchainy \u0142\u0105cz\u0105 ze sob\u0105 konta na podstawie binarnych prefiks\u00f3w ich identyfikator\u00f3w: je\u015bli shardchain ma prefiks 0110, to trafi\u0105 do niego transakcje wszystkich account_id, kt\u00f3re zaczynaj\u0105 si\u0119 od tych cyfr. Ten shard_prefix<\/em> mo\u017ce mie\u0107 d\u0142ugo\u015b\u0107 od 0 do 60 bit\u00f3w \u2014 a co najwa\u017cniejsze, mo\u017ce si\u0119 dynamicznie zmienia\u0107.<\/p>\n<\/p>\n
<\/p>\n
Gdy tylko do jednego z shardchain\u00f3w zaczyna nap\u0142ywa\u0107 zbyt wiele transakcji, w\u0119z\u0142y pracuj\u0105ce nad nim wed\u0142ug wcze\u015bniej okre\u015blonych zasad \u201edziel\u0105\u201d go na dwa potomne \u2014 ich prefiksy b\u0119d\u0105 o jeden bit d\u0142u\u017csze (i dla jednego z nich ten bit b\u0119dzie r\u00f3wny 0, a dla drugiego \u2014 1). Na przyk\u0142ad, shard_prefix<\/em> = 0110<\/u>b podzieli si\u0119 na 0110<\/u>0b i 0110<\/u>1b. Z drugiej strony, je\u015bli dwa \u201es\u0105siednie\u201d shardchainy zaczn\u0105 czu\u0107 si\u0119 wystarczaj\u0105co swobodnie (przez pewien czas), ponownie si\u0119 po\u0142\u0105cz\u0105.<\/p>\n <\/p>\n
W ten spos\u00f3b sharding odbywa si\u0119 \u201eod do\u0142u do g\u00f3ry\u201d \u2014 zak\u0142adamy, \u017ce ka\u017cde konto posiada sw\u00f3j shard, ale s\u0105 one \u2014 przez jaki\u015b czas \u2014 \u201epo\u0142\u0105czone\u201d w oparciu o prefiksy. To jest to, co oznacza Infinite Sharding Paradigm<\/strong> (paradigma niesko\u0144czonego shardingu<\/em>).<\/p>\n<\/p>\n
Osobno pragn\u0119 podkre\u015bli\u0107, \u017ce workchainy istniej\u0105 tylko wirtualnie \u2014 w rzeczywisto\u015bci, workchain_id<\/em> to cz\u0119\u015b\u0107 identyfikatora konkretnego shardchainu. M\u00f3wi\u0105c formalnie, ka\u017cdy shardchain jest definiowany przez par\u0119 liczb (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Korygowanie b\u0142\u0119d\u00f3w. W poziome blockchainy.<\/h3>\n <\/p>\n
Tradycyjnie uwa\u017ca si\u0119, \u017ce ka\u017cda transakcja w blockchainie jest \u201ewyryta w kamieniu\u201d. Jednak w przypadku TON przewidziano mo\u017cliwo\u015b\u0107 \u201eprzepisywania historii\u201d \u2014 w przypadku, gdy kto\u015b (tzw. w\u0119ze\u0142-\u201erybak\u201d<\/em>) udowodni, \u017ce jeden z blok\u00f3w zosta\u0142 podpisany nieprawid\u0142owo. W takim przypadku do odpowiedniego shardchain dodawany jest specjalny blok korekcyjny, zawieraj\u0105cy hash samego korygowanego bloku (a nie ostatniego bloku w shardchain). Przedstawiaj\u0105c shardchain jako poziom\u0105 lini\u0119 blok\u00f3w, mo\u017cna stwierdzi\u0107, \u017ce blok korekcyjny jest pod\u0142\u0105czany do b\u0142\u0119dnego bloku nie z boku, a z g\u00f3ry \u2014 dlatego uwa\u017ca si\u0119, \u017ce staje si\u0119 cz\u0119\u015bci\u0105 ma\u0142ego \u201epionowego blockchaina\u201d. W ten spos\u00f3b mo\u017cna stwierdzi\u0107, \u017ce shardchain s\u0105 dwuwymiarowymi blockchainami<\/em>.<\/p>\n<\/p>\n
<\/p>\n
W przypadku gdy po b\u0142\u0119dnym bloku nast\u0119pne bloki odnosi\u0142y si\u0119 do jego zmian (tj. dokonano nowych transakcji na podstawie niewa\u017cnych), do tych blok\u00f3w r\u00f3wnie\u017c \u201ez g\u00f3ry\u201d dodawane s\u0105 bloki korekcyjne. Je\u015bli bloki nie dotyka\u0142y \u201edotkni\u0119tych\u201d informacji, te \u201efale korekcyjne\u201d na nie nie maj\u0105 wp\u0142ywu. Na przyk\u0142ad w powy\u017cszej ilustracji transakcja pierwszego bloku, zwi\u0119kszaj\u0105ca saldo konta C, zosta\u0142a uznana za nieprawid\u0142ow\u0105 \u2014 dlatego transakcja, kt\u00f3ra zmniejsza saldo tego konta w trzecim bloku, r\u00f3wnie\u017c musi by\u0107 anulowana, a na samym bloku commitowany jest blok korekcyjny.<\/p>\n
<\/p>\n
Nale\u017cy zauwa\u017cy\u0107 \u2014 chocia\u017c bloki korekcyjne s\u0105 przedstawiane jako umiejscowione \u201enad\u201d oryginalnymi, faktycznie zostan\u0105 one zapisane na ko\u0144cu odpowiedniego blockchaina (tam, gdzie powinny znajdowa\u0107 si\u0119 chronologicznie). Dwuwymiarowe umiejscowienie jedynie pokazuje, do kt\u00f3rego momentu w blockchainie b\u0119d\u0105 \u201epod\u0142\u0105czone\u201d (poprzez zawarty w nich hash oryginalnego bloku).<\/p>\n
<\/p>\n
Mo\u017cna osobno rozwa\u017cy\u0107, jak dobre jest rozwi\u0105zanie \u201ezmieniania przesz\u0142o\u015bci\u201d. Wydaje si\u0119, \u017ce je\u015bli dopuszczamy mo\u017cliwo\u015b\u0107 pojawienia si\u0119 nieprawid\u0142owego bloku w shardchainie, to nie mo\u017cemy nie dopu\u015bci\u0107 tak\u017ce do mo\u017cliwo\u015bci powstania b\u0142\u0119dnego bloku korekcyjnego. Tutaj, o ile mog\u0119 s\u0105dzi\u0107, r\u00f3\u017cnica tkwi w liczbie w\u0119z\u0142\u00f3w, kt\u00f3re musz\u0105 osi\u0105gn\u0105\u0107 konsensus w sprawie nowych blok\u00f3w \u2014 nad ka\u017cdym shardchainem b\u0119dzie pracowa\u0107 stosunkowo niewielka \u201egrupa robocza<\/em>\u201d w\u0119z\u0142\u00f3w (do\u015b\u0107 cz\u0119sto zmieniaj\u0105ca sw\u00f3j sk\u0142ad), a wprowadzenie blok\u00f3w korekcyjnych b\u0119dzie wymaga\u0142o zgody w\u0142a\u015bciwie wszystkich w\u0119z\u0142\u00f3w-walidator\u00f3w<\/em>. Wi\u0119cej o walidatorach, grupach roboczych i innych rolach w\u0119z\u0142\u00f3w opowiem w nast\u0119pnym artykule.<\/p>\n<\/p>\n
Jeden blockchain, aby rz\u0105dzi\u0107 wszystkimi<\/h3>\n <\/p>\n
Powy\u017cej wymieniono wiele informacji na temat r\u00f3\u017cnych rodzaj\u00f3w blockchain\u00f3w, kt\u00f3re same w sobie r\u00f3wnie\u017c powinny by\u0107 gdzie\u015b przechowywane. W szczeg\u00f3lno\u015bci mowa o nast\u0119puj\u0105cych informacjach:<\/p>\n
<\/p>\n
\no liczbie i konfiguracjach workflow\u00f3w;<\/li>\n o liczbie shardchain\u00f3w i ich prefiksach;<\/li>\n o tym, kt\u00f3re w\u0119z\u0142y obecnie odpowiadaj\u0105 za kt\u00f3re shardchainy;<\/li>\n hashe ostatnio dodanych blok\u00f3w do wszystkich shardchain\u00f3w.<\/li>\n<\/ul>\n<\/p>\n
Jak ju\u017c mog\u0142e\u015b si\u0119 domy\u015bli\u0107, wszystkie te rzeczy s\u0105 zapisywane w jeszcze jednym magazynie blockchain \u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Dzi\u0119ki obecno\u015bci w jego blokach hashy blok\u00f3w wszystkich shardchain\u00f3w, tworzy to silnie powi\u0105zan\u0105 system. Oznacza to, \u017ce generacja nowego bloku w masterchainie b\u0119dzie mia\u0142a miejsce bezpo\u015brednio po generacji blok\u00f3w w shardchainach \u2014 oczekuje si\u0119, \u017ce bloki w shardchainach b\u0119d\u0105 pojawia\u0107 si\u0119 niemal jednocze\u015bnie co oko\u0142o 5 sekund, a nast\u0119pny blok w masterchainie \u2014 sekund\u0119 p\u00f3\u017aniej.<\/p>\n<\/p>\n
Ale kto b\u0119dzie odpowiedzialny za realizacj\u0119 tej tytanicznej pracy \u2014 za przesy\u0142anie wiadomo\u015bci, wykonywanie smart kontrakt\u00f3w, formowanie blok\u00f3w w shardchainach i masterchainie, a tak\u017ce za weryfikacj\u0119 blok\u00f3w pod k\u0105tem b\u0142\u0119d\u00f3w? Czy\u017cby to mia\u0142y by\u0107 niepostrze\u017cenie telefon\u00f3w milion\u00f3w u\u017cytkownik\u00f3w z zainstalowanym klientem Telegramu? A mo\u017ce zesp\u00f3\u0142 Durov\u00f3w zrezygnuje z idei decentralizacji i to b\u0119d\u0105 robi\u0107 ich serwery po staro\u015bwiecku?<\/p>\n
<\/p>\n
W rzeczywisto\u015bci ani jedna, ani druga odpowied\u017a nie jest poprawna. Ale ko\u0144ca tego artyku\u0142u szybko si\u0119 zbli\u017ca, wi\u0119c rozmowa o r\u00f3\u017cnych rolach w\u0119z\u0142\u00f3w (mog\u0142e\u015b ju\u017c zauwa\u017cy\u0107 wzmianki o niekt\u00f3rych z nich), a tak\u017ce o mechanizmach ich dzia\u0142ania odb\u0119dzie si\u0119 ju\u017c w nast\u0119pnej cz\u0119\u015bci.<\/p>\n
\u0179r\u00f3d\u0142o: 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