SSP で Ethereum を送受信する

·8 分で読める·SSP Editorial Team 著
SSP Academy カバー:SSP で Ethereum を送受信する

SSP で Ethereum を送受信する

ETH をセルフカストディのウォレットに出し入れすることは、SSP を Ethereum 用に設定したあと最初に行うことの一つです。アカウントモデルと、SSP の 2-of-2 multisig が通常の Ethereum トランザクションにどう収まるかを理解すれば、これは簡単です。本ガイドでは、ETH の受け取り、送付、そして 2 台のデバイスで署名するときに裏側で実際に何が起きているのかを順に見ていきます。

SSP 内の ETH がまったく初めてなら、まず全体像をつかむために SSP の Ethereum から始め、それから実践的な送受信フローのためにここに戻ってきてください。

アカウントモデルのおさらい

内部的に、Ethereum は Bitcoin のようには動きません。Bitcoin ではウォレットが多数の未使用アウトプットをやりくりし、支払いのたびに新しいおつり用アドレスを生成します。Ethereum では、あなたのアカウントは残高を保持するだけの単一のアドレスです。ETH を受け取ると残高が増え、送ると減ります。考えるべきおつり用アドレスもアウトプットの選択もありません。

これはセルフカストディにとって実用的に二つの意味があります。第一に、同じアドレスを無期限に再利用できるので、バックアップし、確認し、共有すべきアドレスは一つだけです。第二に、すべてのトランザクションは順序付けが必要で、Ethereum は nonce と呼ばれるカウンターでそれを扱います——詳しくは後述します。

SSP では、この単一のアドレスがあなたの 2-of-2 multisig アカウントです。EVM チェーンでは ERC-4337 スマートコントラクトアカウント であり、チェーン上では普通のアドレスに見えても、二つの鍵が依然としてすべての支払いを管理します。

ETH を受け取る

受け取りは安全な側です。ウォレットから何も出ていかないからです。送り主にアドレスを渡し、ネットワークの確認を待ちます。

あなたの 0x アドレス

あなたの Ethereum 受取アドレスは 0x で始まり、その後に 40 個の十六進文字が続きます。SSP はそれをテキストとして、またスキャンできるコードとして表示するので、送り主が正確にコピーできます。Ethereum は一つのアドレスを再利用するため、支払いごとに新しいアドレスは必要ありません。

両方のデバイスでアドレスを確認する

セルフカストディはアドレスの確認をあなたに委ねます。コピーされたアドレスを攻撃者のものにすり替えるマルウェアは業界全体で現実的なリスクなので、これから共有しようとするアドレスが本当に自分のものかを確認してください。SSP は拡張機能と SSP Key の両方でアカウントを表示するので、各デバイスで先頭と末尾の文字を見て、一致していることを確かめましょう。同じ習慣は Bitcoin を SSP に受け取る ときにも当てはまります——誰かが送ってきたウェブページだけでなく、自分が管理するハードウェアで確認してください。

ETH と ERC-20 トークンに一つのアドレス

同じ 0x アドレスが ETH も ERC-20 トークンも受け取ります。トークンはあなたのアドレスに残高を記録するコントラクトの中に存在するからです。トークンごとに別のアドレスは必要ありません。必要なのは、送り主が正しいネットワークを使っていることを確かめることです。

正しいネットワークを選ぶ

これは EVM チェーンで資金を失う最も一般的な経路です。Ethereum メインネット上に存在するアドレスは Polygon、Base やその他の EVM チェーン上にも存在しますが、あるチェーンの残高は別のチェーンの残高ではありません。誰かが間違ったネットワークで ETH を送ると、あなたが見ているチェーンには届きません。アドレスを共有する前に、送り主と正確なネットワークについて合意し、SSP が同じチェーンに設定されていることを確認してください。第 3 回では Polygon、Base やその他の EVM チェーンで SSP を使う ことを詳しく扱います。

ETH を送る:2-of-2 の共同署名フロー

送るときに SSP の multisig 設計が表に出ます。単一鍵のウォレットは一度署名してブロードキャストします。SSP はあなたの二つの鍵を要求するので、フローには承認ステップが一つ余分に入ります——そしてそのステップこそがセキュリティモデルの肝です。

以下は送付のおおまかな形です。正確なラベルは変わりうるので一般的にとどめます:

  1. SSP Wallet 拡張機能で送付を選び、受取アドレスと金額を入力し、手数料を確認します。
  2. 拡張機能がトランザクションを構築し、鍵 1 で最初の署名を行います。
  3. スマートフォンの SSP Key がプッシュ通知を受け取ります。そこで同じ詳細を確認し、鍵 2 で共同署名します。
  4. 二つの署名が結合されると、トランザクションがネットワークにブロードキャストされます。

どのデバイスも単独では資金を動かせないため、あなたのブラウザだけを侵害した攻撃者はそれでも送ることができません。承認するにはあなたのスマートフォンも必要になります。EVM チェーンでは、SSP は Schnorr 集約を用いて二つの署名を一つにまとめるので、チェーンに届くのは二つの別々の署名ではなく単一のアカウント抽象オペレーションです。より深い仕組みは アカウント抽象のやり方による EVM multisig で扱います。

共同署名の習慣は、精神としては SSP で Bitcoin を送る ことと同一です。違うのは基盤となるトランザクション形式だけです。

トランザクションのライフサイクル

送付を短いパイプラインとして思い描くと役立ちます:

  • 構築——拡張機能がトランザクションを組み立てます:受取人、金額、gas の設定、そして次の nonce。
  • 署名——鍵 1 が拡張機能で署名します。
  • 共同署名——あなたがプッシュを承認したあと、鍵 2 が SSP Key で署名します。
  • 送信済み / 保留中——結合されたトランザクションがブロードキャストされ、ブロックに取り込まれるのを待って mempool に滞在します。
  • 確認済み——バリデーターがそれをブロックに取り込みます。以降のブロックごとに確認が増え、巻き戻しが難しくなります。

トランザクションはチェーン上で確認されて初めて最終になります。それまでは保留中で、場合によっては置き換え可能です。Etherscan のような公開ブロックエクスプローラーにトランザクションハッシュを貼り付ければ、どのトランザクションの進行状況も追えます。

nonce を理解する

nonce は、あなたのトランザクションを順序付けるアカウントごとのカウンターです。最初のトランザクションは nonce 0 を使い、次は 1、という具合です。ネットワークはそれらを厳密に順番どおりに処理します。

この順序付けには実用的な帰結があります。あるトランザクションが保留中で詰まると——たいていは現在の状況に対して gas 価格が低すぎたためです——後続のすべてのトランザクションがその後ろで滞ります。ネットワークはより高い nonce へ飛び越さないからです。対処法は詰まったトランザクションを置き換えることです:同じ nonce でより高い手数料のトランザクションを再送し、バリデーターが新しい版を選べるようにします。ウォレットはこれをよく「高速化」または「置き換え」操作として提示します。SSP は置き換えに対しても 2-of-2 の共同署名を依然として要求します。新しいトランザクションだからです。

nonce を手作業で触ることはめったにありません——SSP が記入します——が、それが存在すると知っていれば、保留中のトランザクションがなぜ後ろのものを足止めするのかが分かります。

gas、高い視点から

すべての Ethereum トランザクションは gas を要し、ETH で支払われます。これは ERC-20 トークンを動かすときでも当てはまります:トークンは Ethereum トランザクションに乗って運ばれ、そのトランザクションには計算のための ETH が必要です。実用的な原則は、gas を賄えるよう少額の ETH 残高を常に持っておくことです。さもないと、トークン残高が十分でも gas 不足で送付が失敗することがあります。

EIP-1559 の下での gas の価格付けは、ネットワークが定める基本手数料と、より早く取り込まれるために加える優先チップに分かれます。ここでは簡潔にとどめます。全体像——基本手数料、チップ、なぜ手数料が急騰するのか、セルフカストディでどう選ぶか——については セルフカストディ利用者向けに解説する Ethereum の gas 手数料 を読んでください。

ETH と ERC-20 トークン

ETH は Ethereum のネイティブ資産であり、gas を支払うものです。ERC-20 トークンは、あなたのアドレスに対して残高を追跡するスマートコントラクトによって定義される別個の資産です。トークンを送ることは技術的には単なる価値移転というよりコントラクトとのやり取りですが、SSP では同じ構築・署名・共同署名・ブロードキャストのフローに従います。

一部のトークン操作では、別のコントラクトがあなたに代わってトークンを動かせるようになる前に、一度きりの承認(approval)が必要です——スワップや DeFi でよくあります。承認はそれ自体が一つの話題で、ここでは範囲外です。支出の承認を求めるプロンプトはトークンとのやり取りの通常の一部であり、同じ 2-of-2 共同署名がそれを守る、とだけ知っておいてください。

送る前の実用的な注意

  • 正しいネットワーク。 チェーンが受取人の想定と一致することを確認します。Base 上の ETH は Ethereum メインネット上の ETH ではありません。
  • アドレスの形式。 Ethereum アドレスは 0x に 40 個の十六進文字が続きます。貼り付けてください、決して打ち直さず、両方のデバイスで先頭と末尾を確認します。
  • ENS 名。 一部のウォレットでは、生のアドレスの代わりに name.eth のような読みやすい名前へ送れます。どのアドレスとも同じように扱い、承認する前に、それが想定どおりの受取人に解決されることを確認してください。
  • gas 用に ETH を残す。 トークンだけの残高では自分の gas を払えません。少し ETH を持っておきましょう。

Ethereum トランザクションがどう構成されるかというプロトコルレベルの詳細については、公式の Ethereum トランザクションのドキュメント が確かな参考になります。

まとめ

SSP で ETH を受け取るとは、確認済みの 0x アドレスを正しいネットワークで共有することです。送るときには意図的なステップが一つ加わります——SSP Key の共同署名——これが単一障害点を二つに変えます。gas 用に少し ETH を手元に置き、トランザクションが滞ったら nonce に注意し、毎回ネットワークを確認すれば、SSP での日々の ETH の移動は当たり前のことになります。ここからは gas 手数料の記事 が自然な次の一読です。

この記事をシェアする

関連記事