Příručka pro začátečníky k TON: účty, tokeny a zabezpečení

Pozadí

TON (The Open Network) je decentralizovaná blockchainová platforma, kterou původně navrhl a vyvinul tým Telegramu. Cílem TON je poskytnout vysoce výkonnou a škálovatelnou blockchainovou platformu pro podporu rozsáhlých decentralizovaných aplikací (DApps) a chytrých smluv.

TON je jedinečný v tom, že se snadno používá, je hluboce integrován do služby Telegram a umožňuje běžným lidem snadno používat tokeny. Zároveň je ale komplexní, má architekturu odlišnou od ostatních blockchainů a používá nemainstreamový jazyk chytrých smluv FunC.

Dnes se budeme zabývat charakteristikami TON a bezpečností uživatelských aktiv z hlediska účtů, tokenů a transakcí.

Charakteristika TON

Generování účtů

Způsob generování adresy účtu na TON se liší od většiny blockchainů; jedná se o adresu chytrého kontraktu. Nejprve vše začíná soukromým klíčem. TON primárně používá Ed25519 algoritmus pro generování veřejného klíče, přičemž postup je následující:

Existují dvě podoby veřejného klíče: jedna je surový veřejný klíč vypočítaný ze soukromého klíče, který vypadá takto:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Druhý je „zkrácený“ veřejný klíč, který obsahuje některé informace a kontrolní bity a vypadá takto:

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Pokud si myslíte, že pouhé získání veřejného klíče vám umožní získat adresu účtu jako v případě Etherea, jste na omylu. Pouhé získání veřejného klíče uživatele k výpočtu adresy účtu nestačí.

Jak již bylo zmíněno, adresa uživatelského účtu je adresou inteligentního kontraktu, ale jak můžete nasadit inteligentní kontrakt, aniž byste měli účet?

Správná posloupnost je nejprve vypočítat adresu, získat určité počáteční množství tokenů a poté nasadit smlouvu. Postup výpočtu adresy účtu je znázorněn na následujícím obrázku:

Adresa uživatele má také více podob. Nejdříve je to nezpracovaná podoba, která vypadá takto:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Dále je k dispozici uživatelsky přívětivý formulář, který vypadá takto:

Hlavní síť:

• Odrazitelný: EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
• Neodrazitelné: UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnet:

• Odrazitelný: kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
• Neodrazitelné: 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Při pozorném sledování těchto adres zjistíte, že se liší pouze v prvních a posledních několika znacích, přičemž prostřední account_id je stejný.

Stále však nevidíme vztah mezi veřejným klíčem a adresou účtu.

Tajemství spočívá v initial data na začátku, který obsahuje veřejný klíč uživatele a umožňuje mu ovládat smlouvu peněženky. Číslo workchainId je snadno pochopitelné; TON není jen jeden řetězec, ale skládá se z mnoha střípků.

Každý střep je součástí celé sítě a spravuje konkrétní účty a transakce. Pro vyhledání a správu chytrých smluv je nutné určit, ve kterém shardu se nacházejí. Jaký je rozdíl mezi Bounceable a Non-bounceable?

To souvisí s tím, jak chytré kontrakty, ale pojďme se podívat dál.

Smlouva o peněžence

Níže je uveden úryvek zdrojového kódu smlouvy o uživatelské peněžence. Je z něj patrné, že při přijetí zprávy od uživatele se načtou čtyři parametry: stored_seqno, stored_subwallet, public_key a plugins:

wallet-v4-code.fc



() recv_external(slice in_msg) impure {

var signature = in_msg~load_bits(512);

var cs = in_msg;

var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));

throw_if(36, valid_until <= now());

var ds = get_data().begin_parse();

var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data

ds.end_parse();

throw_unless(33, msg_seqno == stored_seqno);

throw_unless(34, subwallet_id == stored_subwallet);

throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));

//...

}

Při nasazení této smlouvy s uživatelskou peněženkou jsou skutečně vyžadovány některé počáteční parametry, včetně 256bitového public_key. Tím je zajištěno, že každý uživatel má jedinečnou adresu smlouvy, i když používá stejný kód smlouvy.

Každá transakce iniciovaná uživatelem musí být podepsána pomocí in_msg, poté ověřena smlouvou peněženky (check_signature) a následně smlouva provede operace na blockchainu. Z toho můžeme odvodit, že veřejný klíč uživatele může odpovídat mnoha adresám peněženky.

Nasazení různých smluv peněženky nebo použití různých inicializačních dat povede k úplně jiným adresám smluv.

Token Jetton

Token představuje aktivum v blockchainu, což z něj činí základní prvek, kterému musíme rozumět. Jetton je standardní forma tokenů TON a skládá se ze dvou smluv: Jetton-minter a Jetton-wallet.

Při vydání tokenu je vytvořen kontrakt Jetton-minter. Tato inicializace kontraktu zaznamenává informace, jako je celková zásoba tokenů, správce, kód peněženky a další podrobnosti.

Když jsou tokeny distribuovány uživatelům, smlouva Minter nasadí pro každého uživatele smlouvu peněženky. Během inicializace smlouvy zaznamená zůstatek uživatele, jeho vlastnictví, adresu tokenů smlouvy Minter, kód peněženky uživatele a další důležité informace. Každý uživatel má individuálně nasazenou smlouvu.

Je důležité si uvědomit, že zde vytvořená smlouva je smlouva peněženky pro správu konkrétních tokenů Jetton, která se liší od smlouvy peněženky uživatelského účtu. Zde zaznamenaná owner_address je adresa peněženky uživatelského účtu.

Když uživatel Alice předává tokeny uživateli Bob, je vztah vyvolání následující:

Alice podepíše transakci prostřednictvím aplikace mimo řetězec a odešle operační příkaz prostřednictvím smlouvy v peněžence. Tyto příkazy dále vyvolají její peněženku s tokeny k provedení převodu. Když Bobova peněženka s tokeny obdrží tokeny, oznámí to Bobově peněženkové smlouvě (adresa vlastníka Bobovy peněženky Jetton).

Pokud při transakci dojde ke zbytku plynu, bude vrácen na příslušnou adresu, obvykle na smlouvu o účtu Alice.

Níže je uveden příklad přenosu tokenu Jetton analyzovaného prohlížečem Tonviewer:

Zatímco převod ERC20 vyžaduje pouze jednu invokaci smlouvy, převod tokenu Jetton vyžaduje nejméně čtyři invokace smlouvy. Tato metoda je navržena tak, aby umožňovala souběžnost v řetězci, čímž se zvyšuje efektivita transakcí.

Transakce

Když na účtu TON nastane určitá událost, spustí se transakce. Nejčastější událostí je „přijetí zprávy“. Transakce zahrnuje následující prvky:

• Příchozí zpráva, která původně spouští smlouvu (k dispozici jsou speciální metody spouštění).
• Akce smlouvy vyplývající z příchozí zprávy, například aktualizace úložiště smlouvy (nepovinné).
• Odchozí zprávy odeslané ostatním účastníkům (nepovinné).

V souvislosti s transakcemi je třeba si uvědomit několik klíčových vlastností:

1. Asynchronní: Transakce TON nejsou dokončeny jedním voláním; mohou vyžadovat předání zprávy více různým chytrým smlouvám, aby se provedla série volání. Vzhledem k různému směrování v řetězcích sharded nemůže TON zaručit pořadí doručení zpráv mezi více chytrými kontrakty.
2. Poplatky: Asynchronní povaha transakcí představuje problém při odhadu spotřebovaných poplatků. Proto peněženky často posílají při zahájení transakce trochu tokenu navíc jako poplatek. Pokud má volaná smlouva dobrý mechanismus zpracování poplatků, zbývající poplatky se vrátí do peněženky uživatele. Uživatelé si mohou všimnout, že se tokeny v jejich peněžence náhle sníží a po několika minutách opět zvýší, což je způsobeno tímto mechanismem.
3. Bounce: Bounce je mechanismus pro zpracování chyb ve smlouvách. Pokud volaná smlouva neexistuje nebo vyhodí chybu a transakce je nastavena jako bounceable, bude volající smlouvě vrácena zpráva bounced. Pokud například uživatel iniciuje převod a během procesu dojde k chybě, je nutné odeslat zprávu bounce, aby smlouva v peněžence uživatele mohla obnovit svůj zůstatek. Téměř všechny interní zprávy odesílané mezi inteligentními kontrakty by měly být bounceable, což znamená, že by měly mít nastavený bit „bounce“.

Zabezpečení majetku

TON má mnoho funkcí, které mohou vést k problémům se zabezpečením, takže uživatelé si musí být vědomi některých běžných nástrah.

Útok na zadržování poplatků

Jak již bylo zmíněno, peněženky často potřebují poslat malý poplatek navíc, aby zabránily selhání transakce, což poskytuje příležitost pro útočníky. Pokud jste uživatelem peněženky TON, možná jste se setkali se situací, kdy vaše peněženka často přijímá různé NFT nebo tokeny.

Zpočátku se může zdát, že se jedná o odpadkové žetony, ale po kontrole podrobností o transakci zjistíte, že je lze prodat za značnou částku peněz. Při pokusu o zahájení transakce však zjistíte, že požadovaný poplatek je extrémně vysoký (1 TON). V tuto chvíli byste měli být obezřetní, protože by se mohlo jednat o podvod s poplatky.

Útočníci vytvoří pečlivě připravenou smlouvu o tokenu, která způsobí, že peněženka odhadne příliš vysoký poplatek za převod, ale ve skutečnosti je zadržen pouze poplatek a žádná zpráva o převodu není odeslána.

Phishing s první a poslední číslicí

Phishing s první a poslední číslicí není unikátní pro TON; tento phishingový útok existuje v mnoha hlavních blockchainech. Útočníci generují falešný účet pro každou uživatelskou adresu v síti se stejnou první a poslední číslicí.

Když uživatel iniciuje převod, útočník odešle také malý převod, který následuje po transakci uživatele, aby zanechal záznam v historii transakcí uživatele. Když chce uživatel příjemce poslat tokeny zpět, může zkopírovat adresu z historie transakcí, což může být adresa útočníka, což vede k převodu na nesprávnou adresu. Útočník přesně využil chování uživatele.

Komentář Phishing

Při převodu tokenů na platformě TON mohou uživatelé přidat komentář, který transakci popíše. Tato funkce se často používá při provádění vkladů na burzách, kde burzy obvykle vyžadují, aby uživatelé do komentáře k vkladu uvedli své ID uživatele. Tato funkce je však často zneužívána záškodníky, kteří do komentářů zapisují podvodné informace, aby ukradli majetek uživatelů. Příkladem může být např:

Uživatelé by měli být obzvláště obezřetní, pokud jde o „anonymní číslo telegramu“ NFT. Pokud uživatel aktivuje svůj účet Telegram s anonymním číslem Telegram, ale nepovolí dvoufázové ověřování a toto NFT je podvrženo, může se hacker přímo přihlásit k cílovému účtu Telegram a pokračovat v následné krádeži majetku a podvodných aktivitách.

Zranitelnosti inteligentních smluv

Bezpečnostní chyby v chytrých smlouvách mohou vést ke ztrátě finančních prostředků uložených ve smlouvě. Uživatelé by si měli vybírat projekty, které prošly důkladným auditem. Chytré kontrakty TON jsou programovány především v jazyce FunC, i když některé používají pokročilejší Tact nebo nižší úroveň Fift.

Všechny tyto jazyky jsou velmi originální. Nové programovací jazyky s sebou přinášejí nová bezpečnostní rizika, zejména pro vývojáře, kteří si musí osvojit bezpečné kódovací návyky, zvládnout osvědčené bezpečnostní postupy a před nasazením do produkčního prostředí podstoupit přísné bezpečnostní audity. Z důvodu omezeného prostoru se v tomto článku nebudeme podrobně zabývat zabezpečením smluv.

Útok na falešné vklady

Uživatelé peněženek nebo směnáren by si měli dávat pozor na útoky falešnými vklady, které mají obvykle dvě podoby:

1. Falešné žetony: Útočník vydá token s metadaty shodnými s cílovým tokenem. Pokud automatický vkladový program nezkontroluje, zda token pochází ze správné mincovní smlouvy, může to vést k nesprávným vkladům.
2. Bounce: Proces převodu TON vyžaduje vztah volání mezi smlouvami peněženek dvou uživatelů. Pokud smlouva peněženky příjemce neexistuje a transakce je nastavena jako odrazitelná, zpráva se odrazí a původní prostředky snížené o poplatek se vrátí odesílateli. Zájemci o podrobnosti se mohou podívat na náš předchozí článek o falešných vkladech.

Závěr

Tento článek představil některé základní technické principy TON z hlediska tvorby klíčů a peněženek, forem tokenů a vlastností transakcí. Zabýval se také potenciálními bezpečnostními problémy při používání TON a doufá, že vás inspiruje na vaší cestě za poznáním.