Einsteigerhandbuch zu TON: Konten, Token und Sicherheit

cd

Hintergrund

TON (The Open Network) ist eine dezentralisierte Blockchain-Plattform, die ursprünglich vom Telegram-Team konzipiert und entwickelt wurde. TON zielt darauf ab, eine leistungsstarke und skalierbare Blockchain-Plattform zur Unterstützung großer dezentraler Anwendungen (DApps) und intelligenter Verträge bereitzustellen.

TON ist insofern einzigartig, als dass es einfach zu benutzen ist, tief in Telegram integriert ist und es normalen Menschen ermöglicht, Token einfach zu benutzen. Gleichzeitig ist sie komplex, mit einer Architektur, die sich von anderen Blockchains unterscheidet, und sie verwendet eine nicht-mainstreamige Smart-Contract-Sprache namens FunC.

Heute werden wir die Eigenschaften von TON und die Sicherheit von Nutzervermögen aus der Perspektive von Konten, Token und Transaktionen diskutieren.

Merkmale von TON

Kontoerstellung

Die Methode zur Generierung einer Kontoadresse auf TON unterscheidet sich von den meisten Blockchains; es ist eine Smart-Contract-Adresse. Zunächst einmal beginnt alles mit einem privaten Schlüssel. TON verwendet in erster Linie den Ed25519 Algorithmus, um einen öffentlichen Schlüssel zu generieren, wobei der Prozess wie folgt aussieht:

Es gibt zwei Formen des öffentlichen Schlüssels: Der eine ist der rohe öffentliche Schlüssel, der aus dem privaten Schlüssel berechnet wird und wie folgt aussieht:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Der andere ist ein „verschönerter“ öffentlicher Schlüssel, der einige Informationen und Prüfbits enthält und wie folgt aussieht:

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Wenn Sie denken, dass Sie mit dem öffentlichen Schlüssel die Kontoadresse wie bei Ethereum ermitteln können, irren Sie sich. Allein der öffentliche Schlüssel des Nutzers reicht nicht aus, um die Kontoadresse des Nutzers zu berechnen.

Wie bereits erwähnt, ist die Adresse des Benutzerkontos eine Adresse für einen intelligenten Vertrag, aber wie kann man einen intelligenten Vertrag einsetzen, ohne ein Konto zu haben?

Die korrekte Reihenfolge besteht darin, zuerst die Adresse zu berechnen, einen Anfangsbetrag an Token zu erhalten und dann den Vertrag einzusetzen. Der Prozess der Berechnung der Kontoadresse ist im folgenden Diagramm dargestellt:

Die Adresse eines Benutzers kann auch in verschiedenen Formen vorliegen. Zunächst gibt es die Rohform, die wie folgt aussieht:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Dann gibt es ein benutzerfreundliches Formular, das wie folgt aussieht:

Hauptnetz:

Testnet:

Wenn Sie diese Adressen genau betrachten, können Sie feststellen, dass sie sich nur in den ersten und letzten Zeichen unterscheiden, wobei die mittlere account_id gleich ist.

Die Beziehung zwischen dem öffentlichen Schlüssel und der Kontoadresse ist jedoch immer noch nicht ersichtlich.

Das Geheimnis liegt in der initial data am Anfang, die den öffentlichen Schlüssel eines Nutzers enthält, der es dem Nutzer ermöglicht, den Wallet-Vertrag zu kontrollieren. Die workchainId ist leicht zu verstehen; TON ist nicht nur eine einzige Kette, sondern besteht aus vielen Scherben.

Jeder Shard ist ein Teil des gesamten Netzwerks und verwaltet bestimmte Konten und Transaktionen. Um Smart Contracts zu lokalisieren und zu verwalten, muss man angeben, in welchem Shard sie sich befinden. Was ist der Unterschied zwischen Bounceable und Non-bounceable?

Dies bezieht sich auf die Art und Weise, wie Smart Contracts funktioniert, aber lassen Sie uns noch weiter schauen.

Wallet-Vertrag

Nachfolgend ist ein Ausschnitt aus dem Quellcode eines Benutzer-Wallet-Vertrags zu sehen. Er zeigt, dass er beim Empfang einer Nachricht vom Benutzer vier Parameter liest: stored_seqno, stored_subwallet, public_key und 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));

//...

}

Wenn dieser Vertrag für die Benutzergeldbörse eingesetzt wird, sind einige Anfangsparameter erforderlich, darunter eine 256-Bit-public_key. Dadurch wird sichergestellt, dass jeder Nutzer eine eindeutige Vertragsadresse hat, auch wenn er denselben Vertragscode verwendet.

Jede vom Nutzer initiierte Transaktion muss mit in_msg signiert und dann vom Wallet-Vertrag verifiziert werden (check_signature), woraufhin der Vertrag Operationen auf der Blockchain durchführt. Daraus lässt sich ableiten, dass der öffentliche Schlüssel eines Nutzers zahlreichen Wallet-Adressen entsprechen kann.

Der Einsatz unterschiedlicher Wallet-Verträge oder die Verwendung unterschiedlicher Initialisierungsdaten führt zu völlig unterschiedlichen Vertragsadressen.

Jetton-Marke

Ein Token stellt einen Vermögenswert auf der Blockchain dar und ist somit ein grundlegendes Element, das wir verstehen müssen. Jetton ist die Standardform von TON-Tokens und besteht aus zwei Verträgen: Jetton-Minter und Jetton-Wallet.

Wenn ein Token ausgegeben wird, wird ein Jetton-Minter-Vertrag erstellt. Bei dieser Vertragsinitialisierung werden Informationen wie der Gesamtbestand an Token, der Administrator, der Wallet-Code und andere Details aufgezeichnet.

Wenn die Token an die Nutzer verteilt werden, setzt der Minter-Vertrag für jeden Nutzer einen Wallet-Vertrag ein. Während der Vertragsinitialisierung werden das Guthaben des Nutzers, die Eigentumsverhältnisse, die Adresse des Minter-Vertrags für den Token, der Wallet-Code des Nutzers und andere relevante Informationen erfasst. Jeder Benutzer verfügt über einen individuell eingerichteten Vertrag.

Es ist wichtig zu beachten, dass es sich bei dem hier erstellten Vertrag um einen Wallet-Vertrag für die Verwaltung bestimmter Jetton-Token handelt, der sich von dem Wallet-Vertrag des Benutzerkontos unterscheidet. Die owner_address, die hier aufgezeichnet wird, ist die Adresse der Konto-Brieftasche des Benutzers.

Wenn Benutzerin Alice Token an Benutzer Bob überträgt, ist die Aufrufbeziehung wie folgt:

Alice signiert die Transaktion über eine Off-Chain-App und sendet einen operativen Befehl über ihren Wallet-Vertrag. Diese Befehle rufen ihre Token-Wallet auf, um die Übertragung durchzuführen. Wenn Bobs Token-Wallet die Token erhält, benachrichtigt sie Bobs Wallet-Vertrag (die Eigentümeradresse von Bobs Jetton-Wallet).

Wenn während der Transaktion Gas übrig bleibt, wird es an die entsprechende Adresse zurückgeschickt, in der Regel an Alices Kontovertrag.

Nachfolgend sehen Sie ein Beispiel für eine Jetton-Token-Übertragung, die vom Tonviewer-Browser geparst wurde:

Während eine ERC20-Übertragung nur einen einzigen Vertragsaufruf erfordert, sind für eine Jetton-Token-Übertragung mindestens vier Vertragsaufrufe erforderlich. Diese Methode wurde entwickelt, um Gleichzeitigkeit auf der Kette zu ermöglichen und die Effizienz der Transaktion zu verbessern.

Transaktionen

Wenn ein bestimmtes Ereignis in einem TON-Konto eintritt, löst es eine Transaktion aus. Das häufigste Ereignis ist der „Empfang einer Nachricht“. Eine Transaktion umfasst die folgenden Elemente:

Bei den Transaktionen sind einige wichtige Merkmale zu beachten:

  1. Asynchron: TON-Transaktionen werden nicht in einem einzigen Aufruf abgeschlossen; sie können die Weiterleitung von Nachrichten an mehrere verschiedene Smart Contracts erfordern, um eine Reihe von Aufrufen auszuführen. Aufgrund der unterschiedlichen Weiterleitung in den Sharded Chains kann TON die Reihenfolge der Nachrichtenübermittlung zwischen mehreren Smart Contracts nicht garantieren.
  2. Die Gebühren: Die asynchrone Natur von Transaktionen stellt eine Herausforderung bei der Schätzung der verbrauchten Gebühren dar. Daher senden Wallets oft einen kleinen zusätzlichen Token als Gebühr, wenn eine Transaktion initiiert wird. Wenn der aufgerufene Vertrag über einen guten Mechanismus zur Handhabung von Gebühren verfügt, werden die verbleibenden Gebühren an die Wallet des Nutzers zurückgegeben. Es kann vorkommen, dass Nutzer bemerken, dass ihre Wallet-Tokens plötzlich abnehmen und nach ein paar Minuten wieder ansteigen, was auf diesen Mechanismus zurückzuführen ist.
  3. Aufprall: Bounce ist ein Fehlerbehandlungsmechanismus in Verträgen. Wenn der aufgerufene Vertrag nicht existiert oder einen Fehler auslöst und die Transaktion als „bounceable“ eingestellt ist, wird eine Bounce-Nachricht an den aufrufenden Vertrag zurückgeschickt. Wenn ein Benutzer beispielsweise eine Überweisung veranlasst und während des Vorgangs ein Fehler auftritt, ist eine Bounce-Nachricht erforderlich, damit der Wallet-Vertrag des Benutzers sein Guthaben wiederherstellen kann. Fast alle internen Nachrichten, die zwischen intelligenten Verträgen gesendet werden, sollten „bounceable“ sein, d. h. ihr „bounce“-Bit sollte gesetzt sein.

Vermögenssicherheit

TON hat viele Funktionen, die zu Sicherheitsproblemen führen können, daher müssen sich die Benutzer einiger gängiger Fallstricke bewusst sein.

Angriff auf die Gebühreneinbehaltung

Wie bereits erwähnt, müssen Wallets oft eine kleine Zusatzgebühr senden, um ein Scheitern der Transaktion zu verhindern, was eine Gelegenheit für Angreifer darstellt. Wenn Sie eine TON-Wallet nutzen, sind Sie vielleicht schon einmal in eine Situation geraten, in der Ihre Wallet häufig verschiedene NFTs oder Token erhält.

Auf den ersten Blick scheinen diese Token wie Müll zu sein, aber wenn Sie die Transaktionsdetails überprüfen, stellen Sie fest, dass sie für einen beträchtlichen Geldbetrag verkauft werden können. Wenn Sie jedoch versuchen, eine Transaktion zu initiieren, stellen Sie fest, dass die erforderliche Gebühr extrem hoch ist (1 TON). An dieser Stelle sollten Sie vorsichtig sein, denn es könnte sich um einen Gebührenbetrug handeln.

Angreifer erstellen einen sorgfältig ausgearbeiteten Token-Vertrag, der die Wallet dazu veranlasst, eine übermäßig hohe Transfergebühr zu veranschlagen, aber in Wirklichkeit wird nur die Gebühr einbehalten und keine Transfernachricht gesendet.

Phishing mit erster und letzter Ziffer

Phishing mit der ersten und letzten Ziffer ist kein Einzelfall bei TON; dieser Phishing-Angriff existiert bei vielen großen Blockchains. Angreifer generieren ein gefälschtes Konto für jede Benutzeradresse im Netzwerk mit der gleichen ersten und letzten Ziffer.

Wenn ein Nutzer eine Überweisung veranlasst, sendet der Angreifer im Anschluss an die Transaktion des Nutzers auch eine kleine Überweisung, um einen Eintrag in der Transaktionshistorie des Nutzers zu hinterlassen. Wenn der Empfänger Token zurücksenden möchte, kopiert er möglicherweise die Adresse aus seinem Transaktionsverlauf, die die Adresse des Angreifers sein könnte, was zu einer Überweisung an eine falsche Adresse führt. Der Angreifer hat das Verhalten des Benutzers genau ausgenutzt.

Kommentar Phishing

Bei der Übertragung von Token auf TON können die Benutzer einen Kommentar hinzufügen, um die Transaktion zu vermerken. Diese Funktion wird häufig bei Einzahlungen auf Börsen verwendet, da die Börsen in der Regel verlangen, dass die Benutzer ihre Benutzer-ID in den Einzahlungskommentar aufnehmen. Diese Funktion wird jedoch häufig von böswilligen Akteuren ausgenutzt, die betrügerische Informationen in die Kommentare schreiben, um das Vermögen der Nutzer zu stehlen. Zum Beispiel:

Benutzer sollten bei der NFT „Anonyme Telegrammnummer“ besonders vorsichtig sein. Wenn ein Benutzer sein Telegram-Konto mit einer anonymen Telegram-Nummer aktiviert, aber die Zwei-Schritt-Verifizierung nicht aktiviert hat, und diese NFT gefälscht wird, kann sich der Hacker direkt in das Telegram-Konto des Ziels einloggen und mit dem anschließenden Diebstahl von Vermögenswerten und betrügerischen Aktivitäten fortfahren.

Schwachstellen bei intelligenten Verträgen

Sicherheitsschwachstellen in intelligenten Verträgen können zum Verlust der im Vertrag gespeicherten Gelder führen. Nutzer sollten Projekte wählen, die einer gründlichen Prüfung unterzogen wurden. Die Smart Contracts von TON werden hauptsächlich in der FunC-Sprache programmiert, obwohl einige die fortgeschrittenere Tact- oder die niedrigere Fift-Sprache verwenden.

Alle diese Sprachen sind sehr originell. Neue Programmiersprachen bringen neue Sicherheitsrisiken mit sich, insbesondere für die Entwickler, die sich sichere Programmiergewohnheiten aneignen, die besten Sicherheitspraktiken beherrschen und sich strengen Sicherheitsprüfungen unterziehen müssen, bevor sie in der Produktionsumgebung eingesetzt werden. Aus Platzgründen wird in diesem Artikel nicht näher auf die Vertragssicherheit eingegangen.

Angriff auf gefälschte Einlagen

Nutzer von Geldbörsen sollten sich vor gefälschten Einzahlungen in Acht nehmen, die in der Regel in zwei Formen auftreten:

  1. Gefälschte Token: Ein Angreifer gibt einen Token aus, dessen Metadaten mit denen des Ziel-Tokens identisch sind. Wenn das automatisierte Einzahlungsprogramm nicht prüft, ob der Token vom richtigen Minter-Vertrag stammt, kann dies zu falschen Einzahlungen führen.
  2. Aufprall: Der Überweisungsprozess von TON erfordert eine Aufrufbeziehung zwischen den Wallet-Verträgen zweier Nutzer. Wenn der Wallet-Vertrag des Empfängers nicht existiert und die Transaktion als „bounceable“ (abprallbar) eingestuft wird, wird die Nachricht zurückgeschickt und der ursprüngliche Betrag, abzüglich der Gebühr, wird an den Absender zurückgegeben. Wer sich für die Details interessiert, kann unseren früheren Artikel über gefälschte Einzahlungen lesen.

Schlussfolgerung

In diesem Artikel wurden einige grundlegende technische Prinzipien von TON aus der Perspektive der Schlüssel- und Brieftaschenerstellung, der Tokenformen und der Transaktionsmerkmale vorgestellt. Außerdem wurden potenzielle Sicherheitsprobleme bei der Verwendung von TON erforscht, in der Hoffnung, Ihre Lernreise zu inspirieren.

Ähnliche Artikel
↑
Die mobile Version verlassen