Původní autor: Johan
pozadí
TON (The Open Network) je decentralizovaná blockchain platforma původně navržená a vyvinutá týmem Telegram. TON si klade za cíl poskytovat vysoce výkonnou a škálovatelnou blockchain platformu pro podporu rozsáhlých decentralizovaných aplikací (DApps) a chytrých kontraktů.
TON je tak speciální, snadno se používá, je hluboce integrován s Telegramem, takže je pro běžné lidi snadné používat tokeny, je také komplexní, má zcela odlišnou architekturu než ostatní blockchainy a používá nemainstreamový FunC Chytrý smluvní jazyk. Dnes budeme diskutovat o charakteristikách TON a problémech s bezpečností uživatelských aktiv z pohledu účtů, tokenů a transakcí.
Vlastnosti TON
Generování účtu
Adresa účtu TON se generuje odlišně od většiny blockchainů. Jedná se o adresu chytré smlouvy. Nejprve spusťte soukromý klíč TON používá ke generování veřejného klíče především algoritmus Ed 25519.
Existují dvě formy veřejných klíčů Jeden je původní veřejný klíč vypočítaný ze soukromého klíče, který vypadá takto:
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
Druhým je „zkrášlený“ veřejný klíč, který nese některé informace a kontrolní číslice veřejného klíče, ve tvaru: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
Bylo by příliš naivní si myslet, že můžete získat adresu účtu stejně jako Ethereum získáním veřejného klíče Pouhé mít veřejný klíč uživatele k výpočtu adresy účtu uživatele nestačí. Právě jsme řekli, že adresa účtu uživatele je adresa chytré smlouvy, ale nemáme ani účet. Správná sekvence je nejprve vypočítat adresu, získat počáteční množství tokenů a poté můžete nasadit smlouvu. Proces výpočtu adresy účtu je znázorněn na obrázku níže:
Adresa uživatele má také mnoho podob. První je původní forma, která vypadá takto:
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
a uživatelsky přívětivý formulář, jako:
Mainnet:
Odrážedlo:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
Neodpovídající:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
Testnet:
Odrážedlo:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
Neodpovídající:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
Pokud budete tyto adresy pozorně sledovat, uvidíte, že se liší pouze v prvním a posledním znaku a `account_id` uprostřed je stejné. Stále však nevidíme vztah mezi veřejným klíčem a adresou účtu. Záhada ve skutečnosti spočívá v tom, že „počáteční data“ na začátku obsahují veřejný klíč uživatele, pomocí kterého uživatel ovládá vlastnictví smlouvy o peněžence. `workchainId` je snadné pochopit. Pro vyhledání a správu smart kontraktů je nutné jasně označit, ve kterém shardu se nacházejí. Jaký je rozdíl mezi „Odrazit se“ a „Neodrazit“? To souvisí s pracovním mechanismem chytrých kontraktů.
peněženková smlouva
Následuje zdrojový kód smlouvy uživatelské peněženky. Můžete vidět, že čte 4 parametry (stored_seqno, uložená_subwallet, public_key, plugins) při příjmu zprávy uživatele:
wallet-v4-code.fc
() recv_external(slice in_msg) nečisté {
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, uložená_podpeněženka, veřejný_klíč, pluginy) = (ds~load_uint( 32), ds~load_uint( 32), ds~load_uint( 256), ds~load_dict()); ;;##Počáteční údaje
ds.end_parse();
throw_unless( 33, msg_seqno == uložené_seqno);
throw_unless( 34, subwallet_id == uložená_subwallet);
throw_unless( 35, check_signature(slice_hash(in_msg), podpis, veřejný_klíč));
//...
}
Správně, při nasazování smlouvy o peněžence tohoto uživatele musíte zadat některé počáteční parametry, které zahrnují 256bitové informace o veřejném klíči. To zajišťuje, že každý uživatel má při použití stejné adresy smlouvy nezávislou smlouvu. Všechny transakce iniciované uživatelem musí podepsat `in_msg` a poté ověřit podpis (check_signature) prostřednictvím jejich vlastní smlouvy o peněžence a poté smlouva zavolá všechny operace v řetězci. Odtud také můžeme odvodit, že veřejný klíč uživatele může ve skutečnosti odpovídat bezpočtu adres peněženek. Stačí nasadit peněženky s různými zdrojovými kódy nebo různými inicializačními daty, abyste získali úplně jiné adresy smluv.
Jetton Token
Token je reprezentace aktiv v řetězci, takže je to základní prvek, kterému musíme porozumět. Jetton je standardní forma tokenu TON Jetton se skládá ze dvou smluv, Jetton-minter a Jetton-wallet:
Po vydání tokenu se vytvoří smlouva Jetton-minter. Inicializace smlouvy zaznamená celkové množství tokenů, administrátory, kódy peněženky a další informace.
Když jsou tokeny distribuovány uživatelům, smlouva Minter nasadí pro uživatele smlouvu o peněžence a zaznamená zůstatek uživatele, vlastnictví, adresu smlouvy o tokenu, kód uživatelské peněženky a další informace, když je smlouva inicializována. Každý uživatel nasadí smlouvu nezávisle . Všimněte si, že zde vytvořená smlouva je smlouvou o peněžence používanou ke správě konkrétního tokenu Jetton, která se liší od smlouvy o peněžence účtu uživatele. Adresa vlastníka zde zaznamenává adresu peněženky účtu uživatele.
Když uživatelka Alice převede peníze uživateli Bobovi, vztah volání je následující:
Alice podepíše off-chain APP a vydá provozní pokyny tím, že zavolá smlouvu na její peněženku. Tyto pokyny dále volají její peněženku s tokeny, aby provedl převod. Když Bobova peněženka token obdrží token, upozorní Bobovu smlouvu o peněžence (tj. adresu vlastníka Bob Jetton-wallet). Pokud během transakce zbývá plyn, bude vrácen na adresu pro odpověď, obvykle smlouvu o účtu Alice.
Toto je přenos tokenů Jetton analyzovaný prohlížečem Tonviewer:
Převod ERC 20 stačí zavolat alespoň na jednu smlouvu, zatímco převod pomocí tokenu Jetton musí zavolat alespoň čtyři smlouvy. To se provádí, aby bylo možné provádět převody v řetězci současně a zlepšit efektivitu transakcí.
obchod
Když se něco stane s účtem v TON, spustí to transakci. Nejběžnější událostí je „přijetí zprávy“.
Příchozí zpráva, která původně spouští smlouvu (existuje speciální metoda spouštění)
Akce smlouvy způsobené příchozími zprávami, jako je aktualizace úložiště smlouvy (volitelné)
Odchozí zprávy ostatním účastníkům (volitelné)
Při obchodování musíte věnovat pozornost několika charakteristikám:
1. Asynchronní: Transakce TON nejsou dokončeny v jednom hovoru. K provedení série hovorů může být nutné předat zprávy více různým inteligentním kontraktům. Vzhledem k různému směrování v řetězcích fragmentů nemůže TON zaručit pořadí doručení zpráv mezi více smart kontrakty.
2. Manipulační poplatky: Problém přináší i asynchronní charakter, to znamená, že spotřebované manipulační poplatky je obtížné odhadnout. Při zahájení transakce tedy peněženka obvykle pošle nějaké další tokeny jako manipulační poplatky. Pokud má volaná smlouva dobrý mechanismus manipulačních poplatků, zbývající manipulační poplatky budou nakonec vráceny do peněženky uživatele. Uživatelé si mohou všimnout, že tokenů peněženky se po několika minutách najednou zmenšuje a přibývá.
3. Bounce: Bounce je mechanismus pro zpracování chyb smlouvy, když volací kontrakt neexistuje nebo vyvolá chybu, pokud je transakce nastavena na bounce, pak bude vrácená zpráva vrácena zpět volajícímu kontraktu. Pokud například uživatel zahájí přenos a dojde k chybě v procesu volání, je potřeba zpráva o nedoručení, aby smlouva o peněžence uživatele mohla obnovit svůj zůstatek. Téměř všechny interní zprávy odesílané mezi smart kontrakty by měly být odrazitelné, tj. měl by být nastaven jejich „bounce“ bit.
Zabezpečení majetku
TON má mnoho funkcí, které mohou způsobit bezpečnostní problémy, takže uživatelé si také musí být vědomi některých běžných úskalí.
Útok za odposlech
Jak již bylo zmíněno výše, peněženky často potřebují posílat více manipulačních poplatků, aby se zabránilo selhání provádění transakcí, což útočníkům umožňuje najít příležitosti ke konání zla. Pokud jste uživatelem peněženky TON, možná jste se s touto situací setkali, vždy jste do své peněženky obdrželi různé NFT nebo tokeny. Mysleli jste si, že jde jen o nějaké nepotřebné tokeny, ale když jste zkontrolovali informace o transakci, zjistili jste, že nemůžete prodat je méně peněz? Při zahájení transakce však zjistíte, že požadovaný manipulační poplatek je extrémně vysoký (1 TON).
Útočník použil pečlivě vytvořenou tokenovou smlouvu, aby byl odhadovaný poplatek za převod peněženky extrémně vysoký, ale během skutečného provedení poplatek pouze zadržel a neodeslal přenosovou zprávu.
První a poslední číslo rybaření
Phishing typu head and tail number není pro TON jedinečný. Tento druh phishingového útoku existuje ve všech hlavních veřejných řetězcích. Útočník vygeneruje účet s vysokou imitací se stejným prvním a posledním číslem pro každou adresu uživatele v celé síti. Když uživatel odešle přenos, útočník také použije účet s vysokou imitací k odeslání malého převodu v uživateli. Ponechejte záznam v záznamu o platbě. Když chce přijímající uživatel přenést token zpět, může zkopírovat adresu z historického záznamu. V tuto chvíli je pravděpodobné, že bude zkopírována na adresu útočníka, což způsobí, že útočník může přesně předpovědět chování uživatele.
komentovat rybaření
TON může při převodu peněz přidat poznámku k zaznamenání informací o transakci Tato funkce se často používá při dobíjení na burzách obvykle vyžadují, aby si uživatelé při dobíjení poznamenali ID uživatele. Tato funkce je však často zneužívána se zlými úmysly, kdy útočníci okrádají uživatele o jejich majetek zapisováním podvodných informací do poznámek. Jak je znázorněno na obrázku:
Uživatelé musí věnovat zvláštní pozornost číslu anonymního telegramu NFT Pokud uživatel použije anonymní číslo telegramu k otevření účtu TG, ale neotevře dvoufázové ověření, jakmile je NFT phishing pryč, hackeři se mohou přihlásit přímo k cílovému TG. účtu a provádět následné odcizení majetku a klamavé jednání.
Zranitelnost inteligentní smlouvy
Chyby zabezpečení v inteligentních smlouvách poškodí finanční prostředky uživatelů umístěné v inteligentních smlouvách. Chytré smlouvy TON jsou programovány především pomocí jazyka FunC, ale používají také pokročilejší Tact nebo nižší úroveň Fift, což jsou všechny vysoce originální jazyky. Nové programovací jazyky přinesou nová bezpečnostní rizika Zejména pro vývojáře musí mít dobré návyky bezpečného programování, ovládat nejlepší bezpečnostní postupy a před nasazením do produkčního prostředí projít přísnými bezpečnostními audity o zabezpečení smlouvy zatím nemluvíme.
Falešný dobíjecí útok
Uživatelé peněženky nebo burzy musí věnovat pozornost útokům na falešné vklady Obvykle existují dva typy útoků na falešné vklady:
U padělaných mincí útočník vydá token se stejnými metadaty jako cílový token. Pokud program automatického zadávání nezkontroluje, zda se jedná o správnou mincovní smlouvu, povede to k nesprávnému zadání.
Bounce, proces převodu TON vyžaduje volací vztah mezi smlouvami o peněžence dvou uživatelů. Pokud smlouva o peněžence příjemce neexistuje a transakce je nastavena na možnost Bounceable, bude zpráva vrácena a původní prostředky budou odečteny z peněženky. manipulační poplatek zpět odesílateli. Přátelé, které zajímají podrobnosti, se mohou podívat na článek o falešném dobíjení, který jsme dříve zveřejnili.
Shrnout
Tento článek představuje některé základní technické principy TON z pohledu tvorby veřejného a soukromého klíče TON, smlouvy o peněžence, formuláře Tokenu, charakteristik transakce atd. a také se zabývá možnými bezpečnostními problémy v procesu používání TONu všichni se poučte.
Referenční odkazy:
https://docs.ton.org/
https://github.com/ton-blockchain/wallet-contract
