Ursprünglicher Autor: Johan

Hintergrund

TON (The Open Network) ist eine dezentrale Blockchain-Plattform, die ursprünglich vom Telegram-Team entworfen und entwickelt wurde. Ziel von TON ist die Bereitstellung einer leistungsstarken und skalierbaren Blockchain-Plattform zur Unterstützung großer dezentraler Anwendungen (DApps) und intelligenter Verträge.

TON ist so besonders, es ist einfach zu verwenden, es ist tief in Telegram integriert, was es für normale Menschen einfach macht, Token zu verwenden, es ist außerdem komplex, es hat eine völlig andere Architektur als andere Blockchains und es verwendet FunC, das nicht zum Mainstream gehört Intelligente Vertragssprache. Heute werden wir die Merkmale von TON- und Benutzer-Asset-Sicherheitsproblemen aus der Perspektive von Konten, Token und Transaktionen diskutieren.

Merkmale von TON

Kontoerstellung

Die TON-Kontoadresse wird anders als bei den meisten Blockchains generiert. Es handelt sich um eine Smart-Contract-Adresse. Beginnen Sie zunächst mit einem privaten Schlüssel, der hauptsächlich den Ed 25519-Algorithmus verwendet, um einen öffentlichen Schlüssel zu generieren.

Es gibt zwei Formen öffentlicher Schlüssel. Eine davon ist der ursprüngliche öffentliche Schlüssel, der aus dem privaten Schlüssel berechnet wird und wie folgt aussieht:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Der andere ist der „verschönerte“ öffentliche Schlüssel, der einige Informationen und Prüfziffern des öffentlichen Schlüssels enthält, in der Form: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Es wäre zu naiv zu glauben, dass man die Kontoadresse genauso wie bei Ethereum erhalten kann, indem man den öffentlichen Schlüssel erhält, um die Kontoadresse des Benutzers zu berechnen. Wir haben gerade gesagt, dass die Kontoadresse des Benutzers eine Smart-Contract-Adresse ist, aber wir haben nicht einmal ein Konto. Wie können wir einen Smart-Contract bereitstellen? Die richtige Reihenfolge besteht darin, zuerst die Adresse zu berechnen, eine anfängliche Menge an Token zu erhalten und dann den Vertrag bereitzustellen. Der Berechnungsprozess der Kontoadresse ist in der folgenden Abbildung dargestellt:

Die Adresse des Benutzers gibt es auch in vielen Formen. Die erste ist die Originalform, die wie folgt aussieht:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

und benutzerfreundliche Form, wie:

Hauptnetz:

Abprallfähig:

EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX

Nicht abprallbar:

UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnetz:

Abprallfähig:

kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd

Nicht abprallbar:

0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Wenn Sie diese Adressen genau beobachten, können Sie sehen, dass sie sich nur im ersten und letzten Zeichen unterscheiden und die „account_id“ in der Mitte gleich ist. Wir können jedoch immer noch nicht die Beziehung zwischen dem öffentlichen Schlüssel und der Kontoadresse erkennen. Tatsächlich liegt das Geheimnis darin, dass die „Anfangsdaten“ am Anfang den öffentlichen Schlüssel eines Benutzers enthalten, über den der Benutzer den Besitz des Wallet-Vertrags kontrolliert. „workchainId“ ist nicht nur eine einzelne Kette, sondern besteht aus vielen Shards. Jeder Shard ist Teil des gesamten Netzwerks und verarbeitet einen bestimmten Satz von Konten und Transaktionen. Um Smart Contracts zu lokalisieren und zu verwalten, ist es notwendig, klar anzugeben, in welchem ​​Shard sie sich befinden. Was ist der Unterschied zwischen „Bounceable“ und „Non-Bounceable“? Dies hängt mit dem Funktionsmechanismus intelligenter Verträge zusammen.

Wallet-Vertrag

Das Folgende ist ein Quellcode eines Benutzer-Wallet-Vertrags. Sie können sehen, dass beim Empfang der Nachricht des Benutzers vier Parameter (stored_seqno, gespeicherter_subwallet, public_key, Plugins) gelesen werden:

wallet-v4-code.fc

() recv_external(slice in_msg) unrein {

var Signatur = in_msg~load_bits( 512);

var cs = in_msg;

var (Subwallet_ID, gültig bis, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));

throw_if( 36, gültig bis <= jetzt());

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()); ;;#DieAnfangsdaten

ds.end_parse();

throw_unless( 33, msg_seqno == gespeicherte_seqno);

throw_unless(34, Unterwallet-ID == gespeichertes Unterwallet);

throw_unless( 35, check_signature(slice_hash(in_msg), Signatur, öffentlicher Schlüssel));

//...

}

Richtig, wenn Sie den Wallet-Vertrag dieses Benutzers bereitstellen, müssen Sie einige Anfangsparameter übergeben, darunter eine 256-Bit-Public-Key-Information. Dadurch wird sichergestellt, dass jeder Benutzer einen unabhängigen Vertrag hat, wenn er denselben Vertragscode verwendet. Alle vom Benutzer initiierten Transaktionen müssen mit „in_msg“ signiert werden. Nach der Überprüfung der Signatur (check_signature) über ihren eigenen Wallet-Vertrag ruft der Vertrag alle Vorgänge in der Kette auf. Daraus können wir auch schließen, dass der öffentliche Schlüssel eines Benutzers tatsächlich unzähligen Wallet-Adressen entsprechen kann. Sie müssen lediglich Wallets mit unterschiedlichen Quellcodes oder unterschiedlichen Initialisierungsdaten bereitstellen, um völlig unterschiedliche Vertragsadressen zu erhalten.

Jetton-Token

Token sind die Darstellung von Vermögenswerten in der Kette und daher ein grundlegendes Element, das wir verstehen müssen. Jetton ist die Standardform des 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 der Vertragsinitialisierung werden die Gesamtmenge der Token, Administratoren, Wallet-Codes und andere Informationen erfasst.

Wenn Token an Benutzer verteilt werden, stellt der Minter-Vertrag einen Wallet-Vertrag für den Benutzer bereit und zeichnet bei der Initialisierung des Vertrags den Kontostand, den Besitz, die Token-Minter-Vertragsadresse, den Benutzer-Wallet-Code und andere Informationen auf unabhängig. Beachten Sie, dass es sich bei dem hier erstellten Vertrag um einen Wallet-Vertrag handelt, der zur Verwaltung eines bestimmten Jetton-Tokens verwendet wird, der sich vom Wallet-Vertrag des Benutzerkontos unterscheidet. Die Owner_Address zeichnet hier die Wallet-Adresse des Benutzerkontos auf.

Wenn Benutzer Alice Geld an Benutzer Bob überweist, ist die Anrufbeziehung wie folgt:

Alice unterzeichnet die Off-Chain-APP und erteilt Betriebsanweisungen, indem sie ihren Wallet-Vertrag aufruft. Diese Anweisungen rufen außerdem ihre Token-Wallet auf, um die Übertragung durchzuführen. Wenn Bobs Token-Wallet den Token empfängt, benachrichtigt es Bobs Wallet-Vertrag (d. h. die Besitzeradresse von Bob Jetton-Wallet). Wenn während der Transaktion noch Gas übrig ist, wird es an die Antwortadresse, normalerweise Alices Kontovertrag, zurückgesendet.

Dies ist eine vom Tonviewer-Browser analysierte Jetton-Token-Übertragung:

Bei einer ERC 20-Übertragung muss nur mindestens ein Vertrag aufgerufen werden, während bei einer Jetton-Token-Übertragung mindestens vier Verträge aufgerufen werden müssen. Dies geschieht, um die gleichzeitige Ausführung von Übertragungen in der Kette zu ermöglichen und die Transaktionseffizienz zu verbessern.

Handel

Wenn einem Konto in TON etwas passiert, wird eine Transaktion ausgelöst. Das häufigste Ereignis ist der „Empfang einer Nachricht“.

  • Die eingehende Nachricht, die den Vertrag zunächst auslöst (es gibt eine spezielle Auslösemethode)

  • Vertragsaktionen, die durch eingehende Nachrichten verursacht werden, wie z. B. die Aktualisierung des Vertragsspeichers (optional)

  • Ausgehende Nachrichten an andere Teilnehmer (optional)

Es gibt mehrere Merkmale, auf die Sie beim Handel achten müssen:

1. Asynchron: TON-Transaktionen werden nicht in einem Aufruf abgeschlossen. Möglicherweise müssen Nachrichten an mehrere verschiedene Smart Contracts weitergeleitet werden, um eine Reihe von Aufrufen auszuführen. Aufgrund des unterschiedlichen Routings in Shard-Ketten kann TON die Reihenfolge der Nachrichtenzustellung zwischen mehreren Smart Contracts nicht garantieren.

2. Bearbeitungsgebühren: Auch die asynchrone Natur bringt ein Problem mit sich, das heißt, die verbrauchten Bearbeitungsgebühren sind schwer abzuschätzen. Daher sendet das Wallet beim Einleiten einer Transaktion in der Regel einige weitere Token als Bearbeitungsgebühren. Wenn der aufgerufene Vertrag über einen guten Bearbeitungsgebührenmechanismus verfügt, werden die verbleibenden Bearbeitungsgebühren schließlich in die Brieftasche des Benutzers zurückgezahlt. Aus diesem Grund können Benutzer beobachten, dass ihre Wallet-Tokens nach ein paar Minuten plötzlich weniger und dann mehr werden.

3. Bounce: Bounce ist ein Fehlerbehandlungsmechanismus des Vertrags. Wenn der aufrufende Vertrag nicht vorhanden ist oder einen Fehler auslöst und die Transaktion auf Bounce eingestellt ist, wird eine zurückgesendete Nachricht an den aufrufenden Vertrag zurückgesendet. Wenn beispielsweise ein Benutzer eine Überweisung initiiert und beim Aufrufvorgang ein Fehler auftritt, ist eine Bounce-Nachricht erforderlich, damit der Wallet-Vertrag des Benutzers seinen Kontostand wiederherstellen kann. Fast alle internen Nachrichten, die zwischen Smart Contracts gesendet werden, sollten bouncebar sein, d. h. ihr „Bounce“-Bit sollte gesetzt sein.

Vermögenssicherheit

TON verfügt über viele Funktionen, die Sicherheitsprobleme verursachen können, daher müssen Benutzer sich auch einiger häufiger Fallstricke bewusst sein.

Gebührenabfangangriff

Wie oben erwähnt, müssen Wallets oft höhere Bearbeitungsgebühren überweisen, um Fehler bei der Transaktionsausführung zu verhindern, was Angreifern Gelegenheiten bietet, Böses zu tun. Wenn Sie ein TON-Wallet-Benutzer sind, sind Sie möglicherweise schon einmal auf diese Situation gestoßen. Sie erhalten immer verschiedene NFTs oder Token in Ihrer Wallet. Sie dachten, es handele sich nur um Junk-Token-Airdrops, aber als Sie die Transaktionsinformationen überprüften, stellten Sie fest, dass dies nicht der Fall war weniger Geld verkaufen? Wenn Sie jedoch eine Transaktion einleiten, stellen Sie fest, dass die erforderliche Bearbeitungsgebühr extrem hoch ist (1 TONNE). Zu diesem Zeitpunkt müssen Sie darauf achten, dass es sich um einen Bearbeitungsgebührenbetrug handelt.

Der Angreifer nutzte einen sorgfältig konstruierten Token-Vertrag, um die geschätzte Übertragungsgebühr des Wallets extrem hoch zu machen. Bei der tatsächlichen Ausführung hielt er jedoch nur die Gebühr ein und verschickte keine Übertragungsnachricht.

Angeln mit der ersten und letzten Nummer

Head-and-Tail-Phishing gibt es nicht nur bei TON. Diese Art von Phishing-Angriff gibt es in allen großen öffentlichen Ketten. Der Angreifer erstellt für jede Benutzeradresse im gesamten Netzwerk ein High-Imitation-Konto mit denselben Vor- und Nachnamen. Wenn der Benutzer eine Überweisung sendet, verwendet der Angreifer auch das High-Imitation-Konto, um eine kleine Überweisung an den Benutzer zu senden Hinterlassen Sie einen Beleg im Zahlungsprotokoll. Wenn der empfangende Benutzer einen Token zurückübertragen möchte, kopiert er möglicherweise die Adresse aus dem historischen Datensatz. Zu diesem Zeitpunkt wird sie wahrscheinlich an die Adresse des Angreifers kopiert, was dazu führt, dass der Angreifer die Übertragung an die falsche Adresse durchführt das Verhalten des Benutzers.

Kommentar Angeln

TON kann beim Überweisen von Geld einen Kommentar hinzufügen, um die Transaktionsinformationen zu notieren. Diese Funktion wird häufig beim Aufladen an Börsen verwendet. Normalerweise müssen Benutzer beim Aufladen die Benutzer-ID notieren. Diese Funktion wird jedoch häufig in böswilliger Absicht ausgenutzt, indem Angreifer Benutzer um ihr Vermögen betrügen, indem sie betrügerische Informationen in Notizen schreiben. Wie im Bild gezeigt:

Benutzer müssen der Anonymous Telegram Number NFT besondere Aufmerksamkeit schenken. Wenn der Benutzer die Anonymous Telegram Number verwendet, um ein TG-Konto zu eröffnen, aber die Zwei-Schritt-Verifizierung nicht öffnet, können sich Hacker nach dem Diebstahl der NFT direkt bei der Ziel-TG anmelden Kontodiebstahl und anschließende Vermögensdiebstahl sowie betrügerisches Verhalten.

Schwachstelle bei Smart Contracts

Sicherheitslücken in Smart Contracts führen zu Schäden an den in Smart Contracts angelegten Geldern. Benutzer müssen bei der Auswahl von Projekten gut geprüfte Projekte auswählen. Die Smart Contracts von TON werden hauptsächlich mit der FunC-Sprache programmiert, nutzen aber auch das fortgeschrittenere Tact oder das untergeordnete Fift, bei denen es sich allesamt um sehr originelle Sprachen handelt. Neue Programmiersprachen bringen neue Sicherheitsrisiken mit sich. Sie müssen über gute Gewohnheiten für sicheres Programmieren verfügen, die besten Sicherheitspraktiken beherrschen und sich strengen Sicherheitsüberprüfungen unterziehen, bevor sie in der Produktionsumgebung bereitgestellt werden Ich werde vorerst nicht über die Vertragssicherheit sprechen.

Gefälschter Aufladeangriff

Wallet- oder Exchange-Benutzer müssen auf Fake-Deposit-Angriffe achten. Normalerweise gibt es zwei Arten von Fake-Deposit-Angriffen:

  • Bei gefälschten Münzen stellt der Angreifer einen Token mit denselben Metadaten wie der Ziel-Token aus. Wenn das automatisierte Eingabeprogramm nicht prüft, ob es sich um den richtigen Minter-Vertrag handelt, führt dies zu einer falschen Eingabe.

  • Bounce, der Übertragungsprozess von TON erfordert eine Aufrufbeziehung zwischen den Wallet-Verträgen der beiden Benutzer. Wenn der Wallet-Vertrag des Empfängers nicht vorhanden ist und die Transaktion auf „Bounceable“ eingestellt ist, wird die Nachricht zurückgesendet und das ursprüngliche Geld vom Konto abgezogen Bearbeitungsgebühr. Rücksendung an den Absender. Freunde, die sich für die Details interessieren, können sich den Artikel über gefälschte Aufladungen ansehen, den wir zuvor veröffentlicht haben.

Zusammenfassen

In diesem Artikel werden einige grundlegende technische Prinzipien von TON aus der Perspektive der Erstellung öffentlicher und privater Schlüssel, des Wallet-Vertrags, der Token-Form, der Transaktionsmerkmale usw. vorgestellt und auch mögliche Sicherheitsprobleme bei der Verwendung von TON erörtert Jeder lernt. Bringen Sie Inspiration mit.

Referenzlinks:

https://docs.ton.org/

https://github.com/ton-blockchain/wallet-contract