Tento text je pokračováním série článků, ve kterých zkoumám strukturu (pravděpodobně) distribuované sítě Telegram Open Network (TON), jejíž vydání se připravuje na letošní rok. V Popsal jsem jeho nejzákladnější úroveň – způsob vzájemné interakce uzlů.
Pro každý případ mi dovolte připomenout, že s rozvojem této sítě nemám nic společného a veškerý materiál byl shromážděn z otevřeného (i když neověřeného) zdroje - (existuje také doprovod , stručně nastíní hlavní body), který se objevil na konci loňského roku. Množství informací v tomto dokumentu podle mého názoru svědčí o jeho pravosti, ačkoli to není oficiálně potvrzeno.
Dnes se podíváme na hlavní složku TON – blockchain.
Základní pojmy
Účet (účet). Sada dat identifikovaná 256bitovým číslem Číslo účtu (nejčastěji se jedná o veřejný klíč vlastníka účtu). V základním případě (viz níže nulový pracovní řetězec), tyto údaje se týkají zůstatku uživatele. Konkrétní "Occupy". Číslo účtu kdokoli může, ale jeho hodnotu lze měnit pouze podle určitých pravidel.
Inteligentní smlouva (chytrá smlouva). V podstatě jde o speciální případ účtu, doplněný o kód smart kontraktu a uložení jeho proměnných. Pokud v případě „peněženky“ můžete vkládat a vybírat z ní peníze podle poměrně jednoduchých a předem daných pravidel, pak v případě chytré smlouvy jsou tato pravidla napsána ve formě jejího kódu (v určitém Turingově úplném programovací jazyk).
Stav blockchainu (stav blockchainu). Sada stavů všech účtů/smart kontraktů (v abstraktním smyslu hashovací tabulka, kde klíče jsou identifikátory účtů a hodnoty jsou data uložená na účtech).
zpráva (zpráva). Výše jsem použil výraz „kreditní a debetní peníze“ – toto je konkrétní příklad zprávy („převod N gramů z účtu účet_1 na účet účet_2"). Je zřejmé, že takovou zprávu může odeslat pouze uzel, který vlastní soukromý klíč účtu účet_1 - a může to potvrdit podpisem. Výsledkem doručování takových zpráv na běžný účet je navýšení jeho zůstatku a výsledkem smart kontraktu je provedení jeho kódu (který zpracuje příjem zprávy). Samozřejmě jsou možné i jiné zprávy (převádění nikoli peněžních částek, ale libovolných dat mezi smart kontrakty).
Transakce (transakce). Skutečnost, že je zpráva doručena, se nazývá transakce. Transakce mění stav blockchainu. Jsou to transakce (záznamy o doručení zpráv), které tvoří bloky v blockchainu. V tomto ohledu si stav blockchainu můžete představit jako přírůstkovou databázi – všechny bloky jsou „rozdíly“, které je třeba aplikovat postupně, abyste získali aktuální stav databáze. Specifika balení těchto „rozdílů“ (a obnovení plného stavu z nich) budou diskutována v příštím článku.
Blockchain v TON: co to je a proč?
Jak bylo zmíněno v předchozím článku, blockchain je datová struktura, 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 kladena otázka: proč vůbec potřebujeme takovou datovou strukturu, když už máme DHT - distribuovanou hashovací tabulku? Některá data lze samozřejmě uložit do DHT, ale to je vhodné pouze pro nepříliš „citlivé“ informace. Zůstatky kryptoměn nelze ukládat do DHT - především kvůli nedostatku kontrol integrita. Ve skutečnosti roste celá složitost struktury blockchainu, aby se zabránilo interferenci s daty v ní uloženými.
Blockchain v TON však vypadá ještě komplexněji než ve většině ostatních distribuovaných systémů – a to ze dvou důvodů. První je touha minimalizovat potřebu vidličky. U tradičních kryptoměn jsou všechny parametry nastaveny v počáteční fázi a jakýkoli pokus o jejich změnu ve skutečnosti vede ke vzniku „alternativního kryptoměnového vesmíru“. Druhým důvodem je podpora drcení (stříhání, stříhání) blockchain. Blockchain je struktura, která se v průběhu času nemůže zmenšit; a obvykle je každý uzel zodpovědný za provoz sítě nucen ji kompletně uložit. V tradičních (centralizovaných) systémech se k řešení takových problémů používá sharding: některé záznamy v databázi jsou umístěny na jednom serveru, některé na jiném atd. V případě kryptoměn je taková funkcionalita stále poměrně vzácná – zejména kvůli tomu, že je obtížné přidat sharding do systému, kde se původně neplánovalo.
Jak plánuje TON oba výše uvedené problémy vyřešit?
Blockchainový obsah. Pracovní řetězce.
Nejprve si promluvme o tom, co se plánuje uložit do blockchainu. Budou tam uloženy stavy účtů („peněženky“ v základním případě) a smart kontrakty (pro zjednodušení budeme předpokládat, že je to stejné jako u účtů). V podstatě půjde o běžnou hashovací tabulku – klíče v ní budou identifikátory Číslo účtua hodnoty jsou datové struktury obsahující takové věci jako:
- Zůstatek;
- kód inteligentní smlouvy (pouze pro chytré smlouvy);
- ukládání dat inteligentních smluv (pouze pro chytré smlouvy);
- statistika;
- (volitelné) veřejný klíč pro převody z účtu, standardně account_id;
- fronta odchozích zpráv (zde se zadávají pro přeposlání příjemci);
- seznam posledních zpráv doručených na tento účet.
Jak již bylo zmíněno výše, samotné bloky se skládají z transakcí – zpráv doručených na různé účty account_id. Zprávy však kromě account_id obsahují také 32bitové pole workchain_id — tzv. identifikátor pracovní řetězec (pracovní řetězec, fungující blockchain). To vám umožňuje mít několik nezávislých blockchainů s různými konfiguracemi. V tomto případě je workchain_id = 0 považováno za speciální případ, nulový pracovní řetězec — právě zůstatky v něm budou odpovídat kryptoměně TON (Grams). S největší pravděpodobností zpočátku nebudou jiné workchainy vůbec existovat.
Shardchains. Paradigma nekonečného ostření.
Růst počtu blockchainů tím ale nekončí. Pojďme se vypořádat se shardingem. Představme si, že každému účtu (account_id) je přidělen vlastní blockchain – obsahuje všechny zprávy, které k němu přicházejí – a stavy všech takových blockchainů jsou uloženy na samostatných uzlech.
To je samozřejmě velmi plýtvání: s největší pravděpodobností v každém z nich shardchains (shardchain, střep blockchainu) transakce dorazí velmi zřídka a bude potřeba mnoho výkonných uzlů (při pohledu do budoucna podotýkám, že nemluvíme jen o klientech na mobilních telefonech – ale o seriózních serverech).
Proto shardchainy kombinují účty podle binárních prefixů svých identifikátorů: pokud má shardchain prefix 0110, bude zahrnovat transakce všech account_id, které začínají těmito čísly. 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 jeden ze shardchainů začne přijímat příliš mnoho transakcí, uzly, které na něm pracují, jej podle předem stanovených pravidel „rozdělí“ na dvě potomky – jejich prefixy budou o jeden bit delší (a pro jednoho z nich bude tento bit rovná 0 a pro ostatní - 1). Například, shard_prefix = 0110b se rozdělí na 01100b a 01101b. Na druhé straně, pokud se dva „sousední“ shardchainy začnou cítit dostatečně uvolněně (po nějakou dobu), znovu se spojí.
Sharding se tedy provádí „zdola nahoru“ – předpokládáme, že každý účet má svůj vlastní shard, ale zatím jsou „slepeny“ pomocí prefixů. To je to, co to znamená Paradigma nekonečného ostření (paradigma nekonečného shardingu).
Samostatně bych rád zdůraznil, že pracovní řetězce existují pouze virtuálně – ve skutečnosti workchain_id je součástí identifikátoru konkrétního shardchainu. Formálně je každý shardchain definován dvojicí čísel (workchain_id, shard_prefix).
Oprava chyb. Vertikální blockchainy.
Tradičně je každá transakce na blockchainu považována za „pevnou“. V případě TON je však možné „přepsat historii“ – pro případ, že by někdo (tzv. rybářský uzel) prokáže, že jeden z bloků byl podepsán nesprávně. V tomto případě je do odpovídajícího shardchainu přidán speciální opravný blok, který obsahuje hash samotného opravovaného bloku (a nikoli posledního bloku ve shardchainu). Když si představíme shardchain jako řetězec bloků rozložených vodorovně, můžeme říci, že opravný blok je připojen k chybnému bloku ne zprava, ale shora - takže se má za to, že se stane součástí malého „vertikálního blockchainu“ . Můžeme tedy říci, že shardchainy jsou dvourozměrné blockchainy.
Pokud po chybném bloku byly jím provedené změny odkazovány následujícími bloky (tj. byly provedeny nové transakce na základě neplatných), jsou k těmto blokům „nahoře“ přidány také opravné. Pokud bloky neovlivnily „ovlivněné“ informace, tyto „opravné vlny“ se na ně nevztahují. Například na výše uvedeném obrázku byla transakce prvního bloku, zvyšující zůstatek účtu C, uznána jako nesprávná - proto by měla být také zrušena transakce snižující zůstatek tohoto účtu ve třetím bloku a opravný blok by měl být odevzdán na vrcholu samotného bloku.
Je třeba poznamenat, že ačkoli jsou opravné bloky zobrazeny jako umístěné „nad“ původními, ve skutečnosti budou přidány na konec odpovídajícího blockchainu (kde by měly být chronologicky). Dvourozměrné umístění pouze ukazuje, ke kterému bodu v blockchainu budou „propojeny“ (přes hash původního bloku, který se v nich nachází).
Můžete samostatně filozofovat o tom, jak dobré je rozhodnutí „změnit minulost“. Zdálo by se, že pokud připustíme možnost výskytu nesprávného bloku ve shardchainu, pak se nevyhneme možnosti, že se objeví chybný opravný blok. Zde, pokud mohu říci, je rozdíl v počtu uzlů, které musí dosáhnout konsensu o nových blocích – na každém shardchainu bude pracovat relativně malý počet lidí.“pracovní skupina» uzly (což poměrně často mění své složení) a zavedení opravných bloků bude vyžadovat souhlas všech validátorové uzly. O validátorech, pracovních skupinách a dalších rolích uzlů se více zmíním v příštím článku.
Jeden blockchain, který bude vládnout všem
Výše je uvedeno mnoho informací o různých typech blockchainů, které by samy o sobě měly být také někde uloženy. Konkrétně mluvíme o následujících informacích:
- o počtu a konfiguracích pracovních řetězců;
- o počtu shardchainů a jejich prefixech;
- o tom, které uzly jsou aktuálně zodpovědné za které shardchainy;
- hashe posledních bloků přidaných do všech shardchainů.
Jak jste možná uhodli, všechny tyto věci jsou zaznamenány v jiném blockchainovém úložišti – masterchain (mistrovský řetězec, mistrovský blockchain). Díky přítomnosti hashů z bloků všech shardchainů v jeho blocích je systém vysoce propojený. To mimo jiné znamená, že ke generování nového bloku v masterchainu dojde ihned po vygenerování bloků ve shardchainech – očekává se, že bloky ve shardchainech se objeví téměř současně přibližně každých 5 sekund a další blok v masterchain - sekundu po tom.
Ale kdo bude zodpovědný za implementaci celé této titánské práce - za odesílání zpráv, provádění chytrých kontraktů, vytváření bloků ve shardchainech a masterchainu a dokonce i za kontrolu chyb v blokech? Budou to vše tajně provádět telefony milionů uživatelů s nainstalovaným klientem Telegram? Nebo možná tým Durov opustí myšlenky decentralizace a jejich servery to budou dělat staromódním způsobem?
Ve skutečnosti není správná ani jedna, ani druhá odpověď. Okraje tohoto článku ale rychle docházejí, a tak si o různých rolích uzlů (zmínky o některých jste již možná všimli), stejně jako o mechanice jejich práce, povíme v příštím díle.
Zdroj: www.habr.com