原作者：ヨハン
背景
TON (The Open Network) は、もともと Telegram チームによって設計および開発された分散型ブロックチェーン プラットフォームです。 TON の目標は、大規模な分散アプリケーション (DApps) とスマート コントラクトをサポートする、高性能でスケーラブルなブロックチェーン プラットフォームを提供することです。
TON は非常に特別で、使いやすく、Telegram と深く統合されているため、一般の人が簡単にトークンを使用できます。また、複雑であり、他のブロックチェーンとはまったく異なるアーキテクチャを持ち、非主流の FunC を使用しています。スマートコントラクト言語。今回はTONの特徴とユーザー資産のセキュリティ問題について、アカウント、トークン、トランザクションの観点から解説します。
TONの特徴
アカウントの生成
TON アカウントのアドレスは、ほとんどのブロックチェーンとは異なる方法で生成されます。これはスマート コントラクト アドレスです。まず、秘密キーを作成します。TON は主に Ed 25519 アルゴリズムを使用して公開キーを生成します。
公開キーには 2 つの形式があります。1 つは秘密キーから計算された元の公開キーで、次のようになります。
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
もう 1 つは「美しくされた」公開キーで、Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2 の形式で公開キーの情報とチェック ディジットを保持します
イーサリアムと同じように、公開キーを取得することでアカウント アドレスを取得できると考えるのは、単純すぎます。ユーザーの公開キーを取得するだけでは、ユーザーのアカウント アドレスを計算するのに十分ではありません。ユーザーのアカウント アドレスがスマート コントラクト アドレスであると言いましたが、アカウントすら持っていません。どうすればスマート コントラクトを展開できるでしょうか。正しい順序は、最初にアドレスを計算し、初期量のトークンを受信してから、コントラクトをデプロイすることです。アカウントアドレスの計算プロセスを次の図に示します。
ユーザーのアドレスにもさまざまな形式があります。最初の形式は次のようなものです。
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
次のようなユーザーフレンドリーなフォーム:
メインネット:
バウンス可能:
EQC0wbLt4Sqnb0pENTLEJYvMj5npx8R0cRoVLHi0MhjilkPX
バウンス不可:
UQC0wbLt4Sqnb0pENTLEJYvMj5npx8R0cRoVLHi0Mhjilh4S
テストネット:
バウンス可能:
kQC0wbLt4Sqnb0pENTLEJYvMj5npx8R0cRoVLHi0Mhjilvhd
バウンス不可:
0QC0wbLt4Sqnb0pENTLEJYvMj5npx8R0cRoVLHi0MhjilqWY
これらのアドレスを注意深く観察すると、最初と最後の文字が異なるだけで、真ん中の `account_id` は同じであることがわかります。ただし、公開鍵とアカウント アドレスの関係はまだわかりません。実際、謎は最初の「初期データ」にあり、これにはユーザーの公開鍵が含まれており、これを通じてユーザーはウォレット契約の所有権を制御します。 「workchainId」は簡単に理解できます。TON は単なる単一のチェーンではなく、各シャードがネットワーク全体の一部であり、特定のアカウントとトランザクションを処理します。スマート コントラクトを見つけて管理するには、スマート コントラクトがどのシャードに配置されているかを明確に示す必要があります。 「バウンス可能」と「バウンス不可」の違いは何ですか?これはスマート コントラクトの動作メカニズムに関連しています。引き続き以下を見てみましょう。
ウォレット契約
以下はユーザー ウォレット コントラクトのソース コードです。ユーザーのメッセージを受信するときに 4 つのパラメーター (stored_seqno、stored_subwallet、public_key、plugins) を読み取ることがわかります。
ウォレットv4コード.fc
() recv_external(slice in_msg) 不純 {
var 署名 = 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());
ds.end_parse();
throw_unless( 33, msg_seqno == storage_seqno);
throw_unless( 34, subwallet_id == storage_subwallet);
throw_unless( 35, check_signature(slice_hash(in_msg), 署名, public_key));
//...
}
そうです、このユーザーのウォレット コントラクトをデプロイするときは、256 ビットの public_key 情報を含むいくつかの初期パラメーターを渡す必要があります。これにより、同じコントラクト コードを使用するときに各ユーザーが独立したコントラクトを持つことが保証されます。ユーザーが開始するすべてのトランザクションは「in_msg」に署名する必要があり、その後、独自のウォレットコントラクトを通じて署名 (check_signature) を検証した後、コントラクトはチェーン上のすべてのオペレーションを呼び出します。ここから、ユーザーの公開鍵は実際には無数のウォレット アドレスに対応していると推測できます。完全に異なるコントラクト アドレスを取得するには、異なるソース コードまたは異なる初期化データを備えたウォレットをデプロイするだけで済みます。
ジェットントークン
トークンはチェーン上の資産を表すものであるため、理解する必要がある基本要素です。 Jetton は TON トークンの標準形式で、Jetton-minter と Jetton-wallet の 2 つのコントラクトで構成されます。
トークンが発行されると、Jetton-minter コントラクトが作成され、コントラクトの初期化によってトークンの総量、管理者、ウォレット コード、その他の情報が記録されます。
トークンがユーザーに配布されると、Minter コントラクトはユーザーのウォレット コントラクトをデプロイし、コントラクトの初期化時にユーザーの残高、所有権、トークン Minter コントラクト アドレス、ユーザー ウォレット コードおよびその他の情報を記録します。独立して。ここで作成されるコントラクトは、特定の Jetton トークンを管理するために使用されるウォレット コントラクトであり、ユーザーのアカウント ウォレット コントラクトとは異なります。ここでの owner_address はユーザーのアカウント ウォレット アドレスを記録します。
ユーザーのアリスがユーザーのボブに送金する場合、呼び出し関係は次のようになります。
アリスはオフチェーン APP に署名し、ウォレット コントラクトを呼び出して操作指示を発行します。これらの指示により、さらに彼女のトークン ウォレットが呼び出され、送金が行われます。ボブのトークン ウォレットがトークンを受信すると、ボブのウォレット コントラクト (つまり、Bob Jetton ウォレットの所有者アドレス) に通知します。トランザクション中にガスが残っている場合、応答アドレス (通常はアリスのアカウント契約) に返されます。
これは、Tonviewer ブラウザによって解析された Jetton トークン転送です。
ERC 20 転送では少なくとも 1 つのコントラクトを呼び出すだけで済みますが、Jetton トークン転送では少なくとも 4 つのコントラクトを呼び出す必要があります。これは、チェーン上で転送を同時に実行できるようにし、トランザクション効率を向上させるために行われます。
貿易
TON のアカウントに何かが発生すると、トランザクションがトリガーされます。最も一般的なイベントは、次のようなものです。
最初にコントラクトをトリガーする受信メッセージ (特別なトリガー メソッドがあります)
受信メッセージによって引き起こされるコントラクトのアクション (コントラクトのストレージの更新など) (オプション)
他の参加者への送信メッセージ (オプション)
取引する際に注意すべきいくつかの特徴があります。
1. 非同期: TON トランザクションは 1 回の呼び出しでは完了しません。一連の呼び出しを実行するには、複数の異なるスマート コントラクトにメッセージを渡す必要がある場合があります。シャード チェーン内のルーティングが異なるため、TON は複数のスマート コントラクト間のメッセージ配信の順序を保証できません。
2. 手数料: 非同期であるため、消費される手数料の見積もりが難しいという問題もあります。したがって、トランザクションを開始するとき、ウォレットは通常、手数料として追加のトークンを送信します。呼び出された契約に適切な手数料メカニズムがあれば、残りの手数料は最終的にユーザーのウォレットに返されます。ユーザーは、ウォレット トークンが突然減り、数分後には増えていくことに気づくかもしれません。これが理由です。
3. バウンス: バウンスはコントラクトのエラー処理メカニズムです。呼び出し側コントラクトが存在しないか、エラーがスローされた場合、トランザクションがバウンスに設定されている場合、バウンスされたメッセージは呼び出し側コントラクトに戻されます。たとえば、ユーザーが送金を開始し、呼び出しプロセスでエラーが発生した場合、ユーザーのウォレット契約が残高を復元できるようにバウンス メッセージが必要になります。スマート コントラクト間で送信されるほとんどすべての内部メッセージはバウンス可能である必要があります。つまり、「バウンス」ビットが設定されている必要があります。
資産のセキュリティ
TON にはセキュリティ上の問題を引き起こす可能性のある機能が多数あるため、ユーザーはいくつかの一般的な落とし穴にも注意する必要があります。
料金傍受攻撃
前述したように、ウォレットはトランザクション実行の失敗を防ぐために、より多くの手数料を送金する必要があることが多く、これにより攻撃者が悪を行う機会を見つけることができます。あなたがTONウォレットのユーザーであれば、常にウォレットにさまざまなNFTやトークンを受け取ったことがあるかもしれませんが、それは単なるジャンクトークンのエアドロップだと思っていましたが、取引情報を確認するとそうではないことがわかりました。お金を減らしますか？ただし、取引を開始する際に必要な手数料が非常に高額（1トン）であることが判明した場合、これは手数料詐欺である可能性があることに注意する必要があります。
攻撃者は慎重に構築されたトークンコントラクトを使用してウォレットの推定送金手数料を非常に高額に設定しましたが、実際の実行では手数料を保留するだけで送金メッセージは送信しませんでした。
最初と最後の番号釣り
ヘッド アンド テール番号フィッシングは TON に特有のものではありません。この種のフィッシング攻撃はすべての主要なパブリック チェーンに存在します。攻撃者は、ネットワーク全体のすべてのユーザー アドレスに対して同じ最初と最後の番号を持つ高度に模倣されたアカウントを生成し、ユーザーが送金を送信するときに、攻撃者はまた、その高度に模倣されたアカウントを使用して、ユーザーのアドレスに少額の送金を送信します。領収書を支払い記録に残します。受信側のユーザーがトークンを転送したい場合、履歴記録からアドレスをコピーする可能性があり、その際に攻撃者のアドレスに転送される可能性が高く、攻撃者は誤ったアドレスに転送する可能性があります。ユーザーの行動。
コメント釣り
TONは取引情報に転送する際にコメントを追加できます。この機能は通常、取引所でリチャージする際にユーザーIDをリマークする必要があります。ただし、この機能は悪意を持って悪用されることが多く、攻撃者はメモに不正な情報を書き込むことでユーザーの資産を詐取します。図に示すように:
ユーザーは、匿名電報番号 NFT に特別な注意を払う必要があります。ユーザーが匿名電報番号を使用して TG アカウントを開設したが、2 段階認証を開かなかった場合、NFT がフィッシングされると、ハッカーはターゲットの TG アカウントに直接ログインできます。その後、資産の盗難や欺瞞的な行為を実行します。
スマートコントラクトの脆弱性
スマート コントラクトのセキュリティの脆弱性は、スマート コントラクトに設定されているユーザーの資金に損害を与える可能性があります。ユーザーはプロジェクトを選択する際に十分に監査されたプロジェクトを選択する必要があります。 TON のスマート コントラクトは主に FunC 言語を使用してプログラムされていますが、より高度な Tact や低レベルの Fift も使用されており、これらはすべて非常に独自の言語です。新しいプログラミング言語は、新たなセキュリティ リスクをもたらします。特に開発者にとっては、安全なプログラミングの習慣を身に付け、セキュリティのベスト プラクティスを習得し、実稼働環境に展開する前に厳格なセキュリティ監査を受ける必要があります。この記事では、スペースの制限があります。今のところ、契約のセキュリティについては議論しないでください。
偽のリチャージ攻撃
ウォレットまたは取引所のユーザーは、偽のリチャージ攻撃に注意する必要があります。偽のリチャージ攻撃には通常、次の 2 種類があります。
偽造コインの場合、攻撃者はターゲット トークンと同じメタデータを持つトークンを発行します。自動エントリ プログラムがこれが正しいミンター コントラクトであるかどうかを確認しない場合、不正なエントリが発生します。
バウンス、TON の送金プロセスには 2 人のユーザーのウォレット コントラクト間の呼び出し関係が必要です。受信者のウォレット コントラクトが存在せず、トランザクションがバウンス可能に設定されている場合、メッセージはバウンスされ、元の資金が差し引かれます。送り主に返送する手数料。詳細に興味のある友人は、以前に公開した偽のリチャージ記事をチェックしてください。
要約する
この記事では、TON の公開鍵と秘密鍵の作成、ウォレット契約、トークン形式、トランザクション特性などの観点から TON の基本的な技術原則を紹介し、TON の使用過程で起こり得るセキュリティの問題についても説明します。誰もがインスピレーションをもたらします。
参考リンク:
