TON: Telegram Open Network. Část 2: Blockchainy, shardování

Tento text je pokračováním série článků, ve kterých zkoumám strukturu (předpokládaně) chystané distribuované sítě Telegram Open Network (TON), která by měla být uvedena na trh letos. předchozí části Ona nejzákladnější úroveň, na kterou jsem se zaměřil, je způsob interakce uzlů mezi sebou.

Pro jistotu připomínám, že se na vývoji této sítě nijak nepodílím a veškerý materiál je čerpán z otevřeného (i když neověřeného) zdroje — dokumentu (k němu je také přiložená brožura, která stručně shrnuje hlavní body), která se objevila na konci loňského roku. Rozsah informací v tomto dokumentu dle mého názoru naznačuje jeho pravost, ačkoliv neexistují žádná oficiální potvrzení.

Dnes se podíváme na hlavní komponent TON — blockchain.

Základní pojmy

Účet (account). Sada dat, identifikovaná 256bitovým číslem, account_id (většinou se jedná o veřejný klíč majitele účtu). V základním případě (viz níže nulový blockchain) se těmito daty rozumí zůstatek uživatele. „Vzít“ konkrétní zůstatek může kdokoliv, ale měnit jeho hodnotu lze jen podle určitých pravidel. account_id smart-contract

Chytrý kontrakt (). V podstatě se jedná o speciální typ účtu, který je doplněn kódem smart kontraktu a úložištěm jeho proměnných. Zatímco u „peněženky“ můžete relativně jednoduše přidávat a ubírat peníze podle předem stanovených pravidel, u smart kontraktu jsou tato pravidla zapsána v jeho kódu (v nějakém Turingovsky úplném programovacím jazyce).Stav blockchainu

state of blockchain (). Souhrn stavů všech účtů/smart kontraktů (v abstraktním smyslu — hashovací tabulka, kde klíči jsou identifikátory účtů a hodnotami jsou uložená data v účtech).). Už jsem použil výrazy „přidat a ubrat peníze“ — to je specifický příklad zprávy („převést

Zpráva (zprávaN gramů z účtu account_1 na účet account_2 “). Je zřejmé, že takovou zprávu může poslat pouze uzel, který vlastní soukromý klíč účtu— a je schopen to potvrdit podpisem. Výsledkem doručení takových zpráv obyčejnému účtu je zvýšení jeho zůstatku, zatímco smart kontraktu — vykonání jeho kódu (který zpracovává přijetí zprávy). Samozřejmě jsou možné i další zprávy (přenášející nikoliv peněžní částky, ale libovolné údaje mezi smart kontrakty). na účet transaction

Transakce (transaction). Fakt doručení zprávy se nazývá transakcí. Transakce mění stav blockchainu. Právě z transakcí (zápisů o doručení zpráv) se skládají bloky v blockchainu. V tomto ohledu si lze představit stav blockchainu jako inkrementální databázi — všechny bloky jsou „difíky“, které je třeba aplikovat postupně, abychom získali aktuální stav DB. O konkrétní podobě těchto „difíků“ (a o obnovení plného stavu na jejich základě) bude řeč v následujícím článku.

Blockchain v TON: co to je a k čemu to slouží?

Jak bylo zmíněno v předchozím článku, blockchain je struktura dat, jejíž prvky (bloky) jsou uspořádány do „řetězce“, a každý následující blok řetězce obsahuje hash předchozího. V komentářích byla položena otázka: proč vlastně taková datová struktura, když už máme DHT — distribuovanou hash tabulku? Je zřejmé, že některé údaje lze ukládat i v DHT, ale to je vhodné jen pro méně „citlivé“ informace. Zůstatky kryptoměn nelze ukládat do DHT — především kvůli nedostatku kontrol na integritu. Vlastně veškerá složitost struktury blockchainu vzniká za účelem prevence zásahů do uložených dat.

Blockchain v TON však vypadá ještě složitěji než v většině jiných distribuovaných systémů — a to z dvou důvodů. První je snaha minimalizovat potřebu v forkách. V tradičních kryptoměnách jsou všechny parametry nastaveny na počátečním stádiu a jakýkoli pokus o jejich změnu vede ve skutečnosti k vytvoření „alternativního vesmíru kryptoměn“. Druhým důvodem je podpora dělení (shardingu, šardování) blockchainu. Blockchain je struktura, která se s časem nemůže zmenšovat; a obvykle každý uzel odpovědný za funkčnost sítě musí uchovávat jeho kompletní kopii. V tradičních (centralizovaných) systémech se k řešení takových problémů používá sharding: část záznamů v DB je na jednom serveru, část na jiném atd. U kryptoměn je taková funkčnost zatím poměrně vzácná — zejména kvůli obtížím dodání sharding do systému, kde nebylo původně naplánováno.

Jakým způsobem tedy TON plánuje vyřešit oba výše uvedené problémy?

Obsah blockchainu. Vorkchainy.

Nejprve si povězme, co se plánuje uchovávat v blockchainu. Bude tam uchováváno stavy účtů (v základním případě „peněženek“) a chytré smlouvy (pro zjednodušení budeme považovat, že je to totéž jako účty). V podstatě to bude obyčejná hash tabulka - klíči v ní budou identifikátory account_id, a hodnotami budou datové struktury obsahující takové věci, jako jsou:

• zůstatek;
• kód chytré smlouvy (pouze pro chytré smlouvy);
• úložiště dat chytré smlouvy (pouze pro chytré smlouvy);
• statistika;
• (volitelně) veřejný klíč pro převody z účtu, ve výchozím nastavení account_id;
• fronta odchozích zpráv (sem se zapisují pro zasílání příjemci);
• seznam posledních doručených zpráv tomuto účtu.

Jak bylo uvedeno výše, přímo bloky se skládají z transakcí - zpráv, které byly doručeny různým účtům account_id. Nicméně kromě account_id zprávy také obsahují 32-bitové pole workchain_id — identifikátor tzv. vorkchainu (workchain, working blockchain). To umožňuje mít několik nezávislých blockchainů s různými konfiguracemi. Přitom workchain_id = 0 je považováno za zvláštní případ, nulový vorkchain — právě v něm se budou zůstatky shodovat s kryptoměnou TON (Grams). Pravděpodobně na začátku nebudou žádné jiné vorkchainy vůbec existovat.

Shardchainy. Nekonečná shardovací paradigma.

Ale na tom růst počtu blockchainů nekončí. Pojďme se podívat na shardování. Představme si, že každému účtu (account_id) je přiřazen jeho vlastní blockchain - v něm leží všechny příchozí zprávy - a stavy všech těchto blockchainů jsou uchovávány na samostatných uzlech.

Samozřejmě, to je velmi plýtvavé: pravděpodobně do každého z těchto shardchainů (shardchain, shard blockchain) budou transakce přicházet velmi zřídka, a mocných uzlů bude potřeba hodně (předem podotýkám, že se nejedná pouze o klienty na mobilních telefonech - ale o důležité servery).

Proto shardchainy sdružují účty podle binárních prefixů jejich identifikátorů: pokud má shardchain prefix 0110, budou do něj patřit transakce všech account_id, které začínají těmito číslicemi. Tento shard_prefix může mít délku od 0 do 60 bitů - a hlavní je, že se může dynamicky měnit.

Jakmile začne do jednoho z shardchainů proudit nadměrné množství transakcí, uzly pracující na něm podle předem definovaných pravidel "rozdělí" ho na dva podřetězce – jejich prefixy budou o jeden bit delší (a pro jeden z nich bude tento bit roven 0, zatímco pro druhý 1). Například, shard_prefix = 0110b se rozdělí na 01100b a 01101b. Na druhou stranu, pokud se dva "sousední" shardchainy začnou cítit dostatečně uvolněně (po určitou dobu), opět se sloučí do jednoho.

Takto se shardování děje "shora dolů" – předpokládáme, že každý účet má svůj shard, ale jsou – po určitou dobu – "slepeny" podle prefixů. To zahrnuje Infinite Sharding Paradigm (paradigmatu nekonečného shardování).

Je třeba zdůraznit, že workchainy existují pouze virtuálně – ve skutečnosti, workchain_id to je část identifikátoru konkrétního shardchainu. Řečeno formálně, každý shardchain je definován dvojicí čísel (workchain_id, shard_prefix).

Oprava chyb. Vertikální blockchainy.

Tradičně se má za to, že každá transakce v blockchainu je "vytesaná do kamene". Nicméně, v případě TON je zajištěna možnost "přepsat historii" – pokud někdo (tzv. uzel-"rybář") prokáže, že jeden z bloků byl podepsán nesprávně. V takovém případě je do odpovídajícího shardchainu přidán speciální opravný blok, který obsahuje hash opravovaného bloku (a ne posledního bloku ve shardchainu). Představíme-li shardchain jako horizontálně uspořádaný řetězec bloků, můžeme říci, že opravný blok se připojuje k chybovému bloku ne doprava, ale shora – proto se považuje, že se stává součástí malého "vertikálního blockchainu". Takto lze říci, že shardchainy jsou dvourozměrné blockchainy.

V případě, že po chybovém bloku odkázaly na provedené změny následující bloky (tzn. byly provedeny nové transakce na základě nevalidních), k těmto blokům se také „shora“ přidávají opravné. Pokud se bloky nedotýkaly „postižených“ informací, na ně se tyto „opravné vlny“ nešíří. Například v uvedené ilustraci byla za neplatnou uznána transakce prvního bloku, která zvyšuje zůstatek účtu C — proto musí být také zrušena transakce, která snižuje zůstatek tohoto účtu ve třetím bloku, a nad samotným blokem je zapsán opravný blok.

Je třeba poznamenat — ačkoli se opravné bloky zobrazeny jako umístěné „nad“ originálními, v praxi budou přidány na konec příslušného blockchainu (tam, kde by měly být chronologicky). Dvoubodové umístění pouze ukazuje, k jakému bodu v blockchainu budou „připojeny“ (prostřednictvím umístěného hashe originálního bloku).

Je možné samostatně filozofovat o tom, jak dobré je rozhodnutí „měnit minulost“. Zdálo by se, že pokud připouštíme možnost vzniku neplatného bloku v shardchainu, pak nelze připustit ani možnost vzniku chybného opravného bloku. Zde, jak můžu posoudit, je rozdíl v počtu uzlů, které musí dosáhnout konsensu o nových blocích — nad každým shardchainem bude pracovat relativně malá „pracovní skupina„ uzlů (poměrně často měnící svou sestavu), a přidání opravných bloků vyžaduje souhlas všech uzlů-validátorů. Více o validátorech, pracovních skupinách a dalších rolích uzlů povím v dalším článku.

Jeden blockchain, aby vládl všem

Výše bylo uvedeno mnoho informací o různých typech blockchainů, které by měly být také někde uloženy. Zejména jde o následující informace:

• o počtu a konfiguracích pracovníků;
• o počtu shardchainů a jejich prefiksech;
• o tom, které uzly jsou aktuálně odpovědné za které shardchainy;
• haše posledních přidaných bloků do všech shardchainů.

Jak jste již mohli uhádnout, všechny tyto věci jsou zaznamenávány do dalšího úložiště-blockchainu — masterchain (masterchain, master blockchain). Díky přítomnosti hashů všech shardových bloků ve svých blocích silně propojila systém. To také znamená, že generace nového bloku v masterchainu bude probíhat přímo po generaci bloků ve shardových blockchanech – očekává se, že bloky ve shardových blockchanech se objeví téměř současně přibližně každých 5 sekund, a následující blok v masterchainu – o sekundu později.

Ale kdo bude odpovědný za realizaci této titánské práce – za zprostředkování zpráv, provádění chytrých smluv, formulaci bloků ve shardových blockchanech a masterchainu, a ještě za kontrolu bloků na chyby? Opravdu to budou v tichosti dělat telefony milionů uživatelů s nainstalovaným klientem Telegramu? Nebo snad tým Durova se vzdá myšlenek decentralizace a vše budou dělat jejich servery po starém způsobu?

Ve skutečnosti ani jedna z těchto odpovědí není správná. Ale prostor tohoto článku se rychle blíží ke konci, proto o různých rolích uzlů (mohli jste si už všimnout některých zmínek o nich), a také o mechanismech jejich fungování se budeme bavit již v příští části.

Zdroj: habr.com