Aloittelijan opas TONiin: Tilit, tunnukset ja turvallisuus

Tausta

TON (The Open Network) on hajautettu lohkoketjualusta, jonka Telegram-tiimi on alun perin suunnitellut ja kehittänyt. TONin tavoitteena on tarjota suorituskykyinen ja skaalautuva lohkoketjualusta, joka tukee laajamittaisia hajautettuja sovelluksia (DApps) ja älykkäitä sopimuksia.

TON on ainutlaatuinen siinä mielessä, että se on helppokäyttöinen ja syvälle Telegramiin integroitu, minkä ansiosta tavalliset ihmiset voivat helposti käyttää rahakkeita. Samalla se on monimutkainen, sillä sen arkkitehtuuri eroaa muista lohkoketjuista, ja se käyttää FunC-nimistä älykkäiden sopimusten kieltä, joka ei kuulu valtavirtaan.

Tänään keskustelemme TONin ominaisuuksista ja käyttäjien varojen turvallisuudesta tilien, polettien ja transaktioiden näkökulmasta.

TON:n ominaisuudet

Tilin luominen

TON:n tiliosoitteen luomismenetelmä poikkeaa useimmista lohkoketjuista; se on älykkään sopimuksen osoite. Ensinnäkin kaikki alkaa yksityisellä avaimella. TON käyttää ensisijaisesti Ed25519-algoritmia julkisen avaimen luomiseen, ja prosessi on seuraava:

Julkisesta avaimesta on kaksi muotoa: toinen on yksityisestä avaimesta laskettu raaka julkinen avain, joka näyttää seuraavalta:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Toinen on ”kaunisteltu” julkinen avain, joka sisältää joitakin tietoja ja tarkistusbittejä ja näyttää seuraavalta:

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Jos luulet, että vain julkisen avaimen hankkiminen mahdollistaa tilin osoitteen saamisen kuten Ethereumissa, olet väärässä. Pelkkä käyttäjän julkinen avain ei riitä käyttäjän tilin osoitteen laskemiseen.

Kuten mainittiin, käyttäjän tilin osoite on älysopimuksen osoite, mutta miten voit ottaa älysopimuksen käyttöön ilman tiliä?

Oikea järjestys on laskea ensin osoite, vastaanottaa jonkin verran merkkejä ja ottaa sitten sopimus käyttöön. Tilin osoitteen laskentaprosessi on esitetty seuraavassa kaaviossa:

Käyttäjän osoite on myös monessa eri muodossa. Ensinnäkin on raakamuoto, joka näyttää seuraavalta:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Sitten on käyttäjäystävällinen lomake, joka näyttää seuraavalta:

Mainnet:

• Pomppukykyinen: EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
• Ei-potkukelpoinen: UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnet:

• Pomppukykyinen: kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
• Ei-potkukelpoinen: 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Tarkkaan tarkastelemalla näitä osoitteita voit havaita, että ne eroavat toisistaan vain ensimmäisten ja viimeisten merkkien osalta, ja keskimmäinen account_id on sama.

Emme kuitenkaan vieläkään näe julkisen avaimen ja tilin osoitteen välistä suhdetta.

Salaisuus piilee alussa olevassa initial data:ssä, joka sisältää käyttäjän julkisen avaimen, jonka avulla käyttäjä voi hallita lompakkosopimusta. workchainId on helppo ymmärtää; TON ei ole vain yksi ketju, vaan se koostuu monista sirpaleista.

Kukin sirpale on osa koko verkkoa ja käsittelee tiettyjä tilejä ja tapahtumia. Älykkäiden sopimusten paikantamiseksi ja hallitsemiseksi on määritettävä, missä shardissa ne ovat. Mitä eroa on Bounceable:n ja Non-bounceable:n välillä?

Tämä liittyy tapaan, jolla älykkäät sopimukset toimii, mutta jatketaan tarkastelua pidemmälle.

Lompakko Sopimus

Alla on pätkä käyttäjän lompakkosopimuksen lähdekoodista. Siitä käy ilmi, että kun se vastaanottaa viestin käyttäjältä, se lukee neljä parametria: stored_seqno, stored_subwallet, public_key ja 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));

//...

}

Kun tämä käyttäjän lompakkosopimus otetaan käyttöön, se vaatii joitakin alkuparametreja, kuten 256-bittisen public_key:n. Näin varmistetaan, että jokaisella käyttäjällä on yksilöllinen sopimusosoite, vaikka hän käyttäisi samaa sopimuskoodia.

Jokainen käyttäjän aloittama transaktio on allekirjoitettava numerolla in_msg, minkä jälkeen lompakkosopimus tarkistaa sen (check_signature), minkä jälkeen sopimus suorittaa lohkoketjussa tapahtuvia operaatioita. Tästä voidaan päätellä, että käyttäjän julkinen avain voi vastata lukuisia lompakko-osoitteita.

Eri lompakkosopimusten käyttöönotto tai erilaisten alustustietojen käyttäminen johtaa täysin erilaisiin sopimusosoitteisiin.

Jetton Token

Token edustaa omaisuutta lohkoketjussa, mikä tekee siitä perustavanlaatuisen elementin, joka meidän on ymmärrettävä. Jetton on TON-tokenien vakiomuoto, ja se koostuu kahdesta sopimuksesta: Jetton-minter ja Jetton-lompakko.

Kun token lasketaan liikkeeseen, luodaan Jetton-minterisopimus. Tämä sopimuksen alustaminen tallentaa tietoja, kuten polettien kokonaistarjonta, ylläpitäjä, lompakkokoodi ja muita yksityiskohtia.

Kun rahakkeita jaetaan käyttäjille, Minter-sopimus ottaa käyttöön lompakkosopimuksen kullekin käyttäjälle. Sopimuksen alustamisen aikana se tallentaa käyttäjän saldon, omistusoikeuden, tokenin Minter-sopimusosoitteen, käyttäjän lompakkokoodin ja muut asiaankuuluvat tiedot. Jokaisella käyttäjällä on yksilöllisesti käyttöönotettu sopimus.

On tärkeää huomata, että tässä luotu sopimus on lompakkosopimus tiettyjen Jetton-tavaramerkkien hallintaa varten, mikä on eri asia kuin käyttäjän tilin lompakkosopimus. Tähän tallennettu owner_address on käyttäjän tilin lompakon osoite.

Kun käyttäjä Alice siirtää tunnuksia käyttäjälle Bob, kutsusuhde on seuraava:

Alice allekirjoittaa transaktion ketjun ulkopuolisen sovelluksen kautta ja lähettää toimintakäskyn lompakkosopimuksensa kautta. Nämä komennot kutsuvat edelleen hänen token-lompakkoaan suorittamaan siirron. Kun Bobin token-lompakko vastaanottaa tokenit, se ilmoittaa siitä Bobin lompakkosopimukselle (Bobin Jetton-lompakon omistajaosoite).

Jos tapahtuman aikana jää kaasua yli, se palautetaan asianmukaiseen osoitteeseen, yleensä Alicen tilisopimukseen.

Alla on esimerkki Tonviewer-selaimen jäsentämästä Jetton-token-siirrosta:

ERC20-siirto vaatii vain yhden sopimuskutsun, kun taas Jetton-token-siirto vaatii vähintään neljä sopimuskutsua. Tämä menetelmä on suunniteltu mahdollistamaan ketjun sisäinen samanaikaisuus, mikä parantaa transaktioiden tehokkuutta.

Tapahtumat

Kun TON-tilillä tapahtuu tietty tapahtuma, se käynnistää tapahtuman. Yleisin tapahtuma on ”viestin vastaanottaminen”. Tapahtuma sisältää seuraavat elementit:

• Saapuva viesti, joka alun perin käynnistää sopimuksen (käytettävissä on erityisiä käynnistysmenetelmiä).
• Saapuneesta viestistä johtuvat sopimustoimet, kuten sopimuksen tallennuksen päivittäminen (valinnainen).
• Muille osallistujille lähetetyt lähtevät viestit (valinnainen).

Tapahtumiin liittyy useita keskeisiä ominaisuuksia, jotka on syytä ottaa huomioon:

1. Asynkroninen: TON-tapahtumia ei saada päätökseen yhdellä kutsulla, vaan ne saattavat vaatia viestien välittämistä useille eri älykkäille sopimuksille useiden kutsujen suorittamiseksi. Erilaisen reitityksen vuoksi TON ei voi taata viestien toimitusjärjestystä useiden älykkäiden sopimusten välillä.
2. Maksut: Tapahtumien epäsynkroninen luonne aiheuttaa haasteita kulutettujen maksujen arvioinnissa. Tämän vuoksi lompakot lähettävät usein hieman ylimääräistä tokenia maksuna, kun ne aloittavat transaktion. Jos kutsutussa sopimuksessa on hyvä maksujen käsittelymekanismi, jäljelle jäävät maksut palautetaan käyttäjän lompakkoon. Käyttäjät saattavat huomata, että heidän lompakkomerkkinsä arvo yhtäkkiä laskee ja sitten taas nousee muutaman minuutin kuluttua, mikä johtuu tästä mekanismista.
3. Ponnahda: Bounce on sopimusten virheenkäsittelymekanismi. Jos kutsuttua sopimusta ei ole olemassa tai jos se heittää virheen ja transaktio on asetettu pomppivaksi, kutsuvalle sopimukselle palautetaan pomppiviesti. Jos käyttäjä esimerkiksi aloittaa siirron ja prosessin aikana tapahtuu virhe, pomppuviesti on tarpeen, jotta käyttäjän lompakkosopimus voi palauttaa saldonsa. Lähes kaikkien älykkäiden sopimusten välillä lähetettävien sisäisten viestien pitäisi olla pomppivia, eli niiden ”bounce”-bitin pitäisi olla asetettu.

Omaisuuden turvallisuus

TONissa on monia ominaisuuksia, jotka voivat johtaa tietoturvaongelmiin, joten käyttäjien on oltava tietoisia joistakin yleisistä sudenkuopista.

Maksujen pidättäminen hyökkäys

Kuten mainittiin, lompakot joutuvat usein lähettämään pienen lisämaksun estääkseen transaktion epäonnistumisen, mikä tarjoaa mahdollisuuden hyökkääjille. Jos olet TON-lompakon käyttäjä, olet ehkä törmännyt tilanteeseen, jossa lompakkosi vastaanottaa usein erilaisia NFT:tä tai poletteja.

Aluksi nämä saattavat vaikuttaa roskapostilta, mutta kun tarkistat transaktiotiedot, huomaat, että niitä voi myydä huomattavaan rahasummaan. Kun kuitenkin yrität käynnistää transaktion, huomaat, että vaadittu maksu on erittäin korkea (1 TON). Tässä vaiheessa sinun tulisi olla varovainen, sillä kyseessä voi olla maksuhuijaus.

Hyökkääjät luovat huolellisesti laaditun token-sopimuksen, joka saa lompakon arvioimaan liian korkean siirtomaksun, mutta todellisuudessa vain maksu pidätetään eikä siirtoviestiä lähetetä.

Ensimmäinen ja viimeinen numero Phishing

Ensimmäisen ja viimeisen numeron tietojenkalasteluhyökkäys ei koske ainoastaan TON:ia, vaan tämä tietojenkalasteluhyökkäys on käytössä monissa suurissa lohkoketjuissa. Hyökkääjät luovat väärennetyn tilin jokaiselle verkon käyttäjäosoitteelle, jolla on sama ensimmäinen ja viimeinen numero.

Kun käyttäjä aloittaa siirron, hyökkääjä lähettää myös pienen siirron käyttäjän tapahtuman jälkeen, jotta käyttäjän tapahtumahistoriaan jää merkintä. Kun vastaanottajakäyttäjä haluaa lähettää poletteja takaisin, hän saattaa kopioida transaktiohistoriastaan osoitteen, joka voi olla hyökkääjän osoite, mikä johtaa siirtoon väärään osoitteeseen. Hyökkääjä on hyödyntänyt käyttäjän käyttäytymistä tarkasti.

Kommentti Phishing

Kun käyttäjät siirtävät poletteja TONissa, he voivat lisätä kommentin, jolla he voivat kommentoida tapahtumaa. Tätä ominaisuutta käytetään usein, kun tehdään talletuksia pörsseihin, joissa pörssit yleensä vaativat käyttäjiä sisällyttämään käyttäjätunnuksensa talletuksen kommenttiin. Tätä ominaisuutta käyttävät kuitenkin usein hyväkseen pahantahtoiset toimijat, jotka kirjoittavat kommentteihin vilpillisiä tietoja varastamaan käyttäjien varoja. Esim:

Käyttäjien tulisi olla erityisen varovaisia ”Anonymous Telegram Number” NFT:n suhteen. Jos käyttäjä aktivoi Telegram-tilinsä nimettömällä Telegram-numerolla, mutta ei ota käyttöön kaksivaiheista tarkistusta, ja tämä NFT on väärennetty, hakkeri voi kirjautua suoraan kohteena olevalle Telegram-tilille ja jatkaa varojen varastamista ja petollisia toimia.

Älykkään sopimuksen haavoittuvuudet

Älykkäiden sopimusten tietoturva-aukot voivat johtaa sopimukseen tallennettujen varojen menetykseen. Käyttäjien tulisi valita hankkeita, jotka on tarkastettu perusteellisesti. TONin älysopimukset on ohjelmoitu pääasiassa FunC-kielellä, vaikka jotkut käyttävät edistyneempää Tactia tai alemman tason Fiftiä.

Kaikki nämä kielet ovat hyvin omaperäisiä. Uudet ohjelmointikielet tuovat mukanaan uusia tietoturvariskejä erityisesti kehittäjille, joiden on harjoiteltava turvallisia koodaustottumuksia, hallittava parhaat tietoturvakäytännöt ja läpäistävä tiukat tietoturvatarkastukset ennen käyttöönottoa tuotantoympäristöön. Tilan rajallisuuden vuoksi tässä artikkelissa ei käsitellä sopimusturvallisuutta yksityiskohtaisesti.

Väärennetty talletus hyökkäys

Lompakon tai valuutanvaihtopalvelun käyttäjien tulisi olla tietoisia väärennetyistä talletushyökkäyksistä, joita on yleensä kahdessa muodossa:

1. Väärennetyt merkit: Hyökkääjä antaa tunnuksen, jonka metatiedot ovat identtiset kohdetunnuksen kanssa. Jos automaattinen talletusohjelma ei tarkista, onko token oikeasta louhintasopimuksesta, se voi johtaa virheellisiin talletuksiin.
2. Ponnahda: TON:n siirtoprosessi edellyttää kahden käyttäjän lompakkosopimusten välistä yhteyttä. Jos vastaanottajan lompakkosopimusta ei ole olemassa ja jos transaktio on asetettu pomppivaksi, viesti pomppaa takaisin ja alkuperäiset varat, joista on vähennetty maksu, palautetaan lähettäjälle. Yksityiskohdista kiinnostuneet voivat tutustua aiempaan artikkeliin väärennetyistä talletuksista.

Päätelmä

Tässä artikkelissa esiteltiin eräitä TONin teknisiä perusperiaatteita avaimen ja lompakon luomisen, tokenien muotojen ja transaktio-ominaisuuksien näkökulmista. Siinä myös tutkittiin mahdollisia turvallisuuskysymyksiä TONin käytön yhteydessä, ja toivomme, että se innostaa sinua oppimaan.