Vodnik za začetnike za TON: računi, žetoni in varnost

cd

Ozadje

TON (The Open Network) je decentralizirana platforma veriženja blokov, ki jo je prvotno zasnovala in razvila ekipa Telegrama. Cilj TON je zagotoviti visoko zmogljivo in skalabilno platformo veriženja blokov za podporo obsežnim decentraliziranim aplikacijam (DApps) in pametnim pogodbam.

TON je edinstven, saj je enostaven za uporabo in tesno povezan s programom Telegram, kar običajnim ljudem omogoča enostavno uporabo žetonov. Hkrati pa je kompleksen, saj ima arhitekturo, ki se razlikuje od drugih verig blokov, in uporablja nemainstreamovski jezik pametnih pogodb, imenovan FunC.

Danes bomo razpravljali o značilnostih sistema TON in varnosti sredstev uporabnikov z vidika računov, žetonov in transakcij.

Značilnosti TON

Ustvarjanje računov

Način ustvarjanja naslova računa v verigi blokov TON se razlikuje od večine verig blokov; to je naslov pametne pogodbe. Najprej se vse začne z zasebnim ključem. TON za generiranje javnega ključa uporablja predvsem algoritem Ed25519, pri čemer je postopek naslednji:

Obstajata dve obliki javnega ključa: ena je neobdelani javni ključ, izračunan iz zasebnega ključa, ki je videti takole:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Drugi je “polepšani” javni ključ, ki vsebuje nekaj informacij in kontrolnih bitov in je videti takole:

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Če mislite, da boste s pridobitvijo javnega ključa lahko pridobili naslov računa kot v Ethereumu, se motite. Zgolj javni ključ uporabnika ni dovolj za izračun naslova uporabniškega računa.

Kot smo že omenili, je naslov uporabniškega računa naslov pametne pogodbe, toda kako lahko namestite pametno pogodbo, če nimate računa?

Pravilno zaporedje je, da najprej izračunate naslov, prejmete začetno količino žetonov in nato namestite pogodbo. Postopek izračuna naslova računa je prikazan v naslednjem diagramu:

Uporabnikov naslov je prav tako na voljo v več oblikah. Najprej je na voljo neobdelana oblika, ki je videti kot:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Nato je na voljo uporabniku prijazen obrazec, ki je videti takole:

Glavno omrežje:

Testnet:

Če pozorno opazujete te naslove, lahko vidite, da se razlikujejo le v prvih in zadnjih nekaj znakih, medtem ko je srednjih account_id znakov enakih.

Vendar še vedno ne vidimo povezave med javnim ključem in naslovom računa.

Skrivnost se skriva v initial data na začetku, ki vsebuje uporabnikov javni ključ, ki uporabniku omogoča nadzor nad pogodbo denarnice. Številko workchainId je enostavno razumeti; TON ni le ena veriga, temveč je sestavljena iz številnih delcev.

Vsak del je del celotnega omrežja, ki upravlja določene račune in transakcije. Za iskanje in upravljanje pametnih pogodb je treba določiti, v katerem shardu se nahajajo. Kakšna je razlika med Bounceable in Non-bounceable?

To je povezano z načinom inteligentne pogodbe delujejo, vendar si poglejmo še naprej.

Pogodba o denarnici

Spodaj je prikazan izsek izvorne kode pogodbe za uporabniško denarnico. Iz njega je razvidno, da ob prejemu sporočila od uporabnika prebere štiri parametre: stored_seqno, stored_subwallet, public_key in 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));

//...

}

Ko je ta pogodba za uporabniško denarnico nameščena, zahteva nekaj začetnih parametrov, vključno z 256-bitno kodo public_key. To zagotavlja, da ima vsak uporabnik edinstven naslov pogodbe, tudi če uporablja isto kodo pogodbe.

Vsako transakcijo, ki jo sproži uporabnik, je treba podpisati z in_msg, nato jo pogodba denarnice preveri (check_signature), nakar pogodba izvede operacije v verigi blokov. Iz tega lahko sklepamo, da lahko uporabnikovemu javnemu ključu ustrezajo številni naslovi denarnic.

Če namestite različne pogodbe za denarnice ali uporabite različne inicializacijske podatke, boste dobili povsem različne naslove pogodb.

žeton Jetton

Žeton predstavlja sredstvo v verigi blokov, zato je temeljni element, ki ga moramo razumeti. Jetton je standardna oblika žetonov TON in je sestavljen iz dveh pogodb: Jetton-minter in Jetton-wallet.

Ob izdaji žetona se ustvari pogodba Jetton-minter. Pri tej inicializaciji pogodbe se zabeležijo informacije, kot so skupna zaloga žetonov, skrbnik, koda denarnice in druge podrobnosti.

Ko se žetoni razdelijo uporabnikom, pogodba Minter za vsakega uporabnika pripravi pogodbo za denarnico. Med inicializacijo pogodbe zabeleži uporabnikovo stanje, lastništvo, naslov pogodbe Minter za žetone, kodo uporabnikove denarnice in druge pomembne informacije. Vsak uporabnik ima individualno nameščeno pogodbo.

Pomembno je opozoriti, da je tukaj ustvarjena pogodba pogodba denarnice za upravljanje določenih žetonov Jetton, ki se razlikuje od pogodbe denarnice uporabniškega računa. Tukaj zapisan owner_address je naslov denarnice uporabniškega računa.

Ko uporabnica Alice prenese žetone uporabniku Bobu, je razmerje vpoklica naslednje:

Alica podpiše transakcijo prek aplikacije zunaj verige in pošlje operativni ukaz prek svoje pogodbe v denarnici. Ti ukazi bodo dodatno pozvali njeno denarnico s žetoni, da izvede prenos. Ko Bobova denarnica s žetoni prejme žetone, o tem obvesti pogodbo Bobove denarnice (naslov lastnika Bobove denarnice Jetton).

Če med transakcijo ostane plin, se vrne na ustrezen naslov, običajno na pogodbo o računih Alice.

Spodaj je prikazan primer prenosa žetona Jetton, ki ga razčleni brskalnik Tonviewer:

Medtem ko je za prenos žetona ERC20 potreben le en sklic pogodbe, so za prenos žetona Jetton potrebni vsaj štirje klici pogodbe. Ta metoda je zasnovana tako, da omogoča sočasnost na verigi in tako izboljša učinkovitost transakcij.

Transakcije

Ko se na računu TON zgodi določen dogodek, se sproži transakcija. Najpogostejši dogodek je “prejem sporočila”. Transakcija vključuje naslednje elemente:

V zvezi s transakcijami je treba upoštevati več ključnih značilnosti:

  1. Asinhrono: Transakcije TON se ne zaključijo z enim samim klicem, temveč je za izvedbo niza klicev morda potreben prenos sporočil več različnim pametnim pogodbam. Zaradi različnega usmerjanja v razdrobljenih verigah TON ne more zagotoviti vrstnega reda dostave sporočil med več pametnimi pogodbami.
  2. Pristojbine: Asinhrona narava transakcij predstavlja izziv pri ocenjevanju porabljenih provizij. Zato denarnice ob začetku transakcije pogosto pošljejo nekaj dodatnega žetona kot pristojbino. Če ima klicana pogodba dober mehanizem za ravnanje s pristojbinami, se preostale pristojbine vrnejo v uporabnikovo denarnico. Uporabniki lahko opazijo, da se žetoni njihove denarnice nenadoma zmanjšajo in po nekaj minutah spet povečajo, kar je posledica tega mehanizma.
  3. Bounce: Bounce je mehanizem za ravnanje z napakami v pogodbah. Če klicana pogodba ne obstaja ali vrže napako in je transakcija nastavljena kot odbitna, se kličoči pogodbi vrne sporočilo o odbitju. Če na primer uporabnik sproži prenos in med postopkom pride do napake, je potrebno sporočilo bounce, da lahko pogodba uporabnikove denarnice obnovi svoje stanje. Skoraj vsa notranja sporočila, poslana med pametnimi pogodbami, morajo biti odbijajoča, kar pomeni, da morajo imeti nastavljen bit “bounce”.

Varnost sredstev

TON ima veliko funkcij, ki lahko povzročijo varnostne težave, zato se morajo uporabniki zavedati nekaterih pogostih pasti.

Napad na odtegovanje pristojbin

Kot smo že omenili, morajo denarnice za preprečitev neuspešne transakcije pogosto poslati nekaj dodatnih pristojbin, kar je priložnost za napadalce. Če ste uporabnik denarnice TON, ste morda naleteli na situacijo, ko vaša denarnica pogosto prejema različne NFT ali žetone.

Sprva se zdi, da so to smeti, ki jih je mogoče prodati za precejšen znesek denarja, vendar ko preverite podrobnosti transakcije, ugotovite, da jih je mogoče prodati za precejšen znesek denarja. Ko pa poskušate sprožiti transakcijo, opazite, da je zahtevana pristojbina izjemno visoka (1 TON). Na tej točki morate biti previdni, saj bi lahko šlo za prevaro s pristojbinami.

Napadalci ustvarijo skrbno pripravljeno pogodbo o žetonu, zaradi katere denarnica oceni previsoko pristojbino za prenos, vendar se v resnici zadrži le pristojbina, sporočilo o prenosu pa se ne pošlje.

Prva in zadnja številka phishing

Goljufanje s prvo in zadnjo številko ni značilno samo za TON; ta napad se pojavlja v številnih večjih verigah blokov. Napadalci ustvarijo ponarejen račun za vsak uporabniški naslov v omrežju z enako prvo in zadnjo številko.

Ko uporabnik sproži prenos, napadalec pošlje tudi manjši prenos, ki sledi transakciji uporabnika, in tako pusti zapis v zgodovini uporabnikovih transakcij. Ko želi uporabnik prejemnik poslati žetone nazaj, lahko kopira naslov iz zgodovine transakcij, ki je lahko napadalčev naslov, kar povzroči prenos na napačen naslov. Napadalec je natančno izkoristil vedenje uporabnika.

Komentar Phishing

Pri prenosu žetonov na portalu TON lahko uporabniki dodajo komentar, s katerim opišejo transakcijo. Ta funkcija se pogosto uporablja pri pologih na borzah, kjer borze od uporabnikov običajno zahtevajo, da v komentar pologa vključijo svoje uporabniško ime. Vendar to funkcijo pogosto izkoriščajo zlonamerni akterji, ki v komentarje zapišejo goljufive informacije in tako ukradejo sredstva uporabnikov. Na primer:

Uporabniki morajo biti še posebej previdni pri “anonimni številki telegrama” NFT. Če uporabnik aktivira svoj račun Telegram z anonimno številko Telegram, vendar ne omogoči dvostopenjskega preverjanja, in je ta NFT prevaran, se lahko heker neposredno prijavi v ciljni račun Telegram ter nadaljuje s krajo sredstev in goljufijami.

Ranljivosti pametnih pogodb

Varnostne ranljivosti v pametnih pogodbah lahko privedejo do izgube sredstev, shranjenih v pogodbi. Uporabniki morajo izbrati projekte, ki so bili temeljito revidirani. Pametne pogodbe TON so v glavnem programirane v jeziku FunC, čeprav nekatere uporabljajo naprednejši jezik Tact ali nižjo raven Fift.

Vsi ti jeziki so zelo izvirni. Novi programski jeziki prinašajo nova varnostna tveganja, zlasti za razvijalce, ki morajo prakticirati varne kodirne navade, obvladati najboljše varnostne prakse in opraviti stroge varnostne revizije, preden jih namestijo v produkcijsko okolje. Zaradi omejenega prostora v tem članku ne bomo podrobno obravnavali varnosti pogodb.

Napad z lažnim depozitom

Uporabniki denarnic ali menjalnic morajo biti pozorni na napade z lažnimi pologi, ki so običajno v dveh oblikah:

  1. Ponarejeni žetoni: Napadalec izda žeton z metapodatki, ki so enaki ciljnemu žetonu. Če samodejni program za deponiranje ne preveri, ali je žeton iz pravilne pogodbe rudarja, lahko pride do nepravilnih deponiranj.
  2. Bounce: Postopek prenosa TON zahteva razmerje klica med pogodbami denarnic dveh uporabnikov. Če prejemnikova denarnica ne obstaja in je transakcija nastavljena kot odbitna, se sporočilo odbije in prvotna sredstva, zmanjšana za pristojbino, se vrnejo pošiljatelju. Tisti, ki jih zanimajo podrobnosti, si lahko ogledajo naš prejšnji članek o lažnih pologih.

Zaključek

V tem članku so bila predstavljena nekatera temeljna tehnična načela TON z vidika ustvarjanja ključev in denarnic, oblik žetonov in značilnosti transakcij. Obravnaval je tudi morebitna varnostna vprašanja pri uporabi TON in upal, da bo navdihnil vaše učno potovanje.

Related Articles
↑
Exit mobile version