ウォレットの作成とインポート#

• ウォレットの作成

  一般的には、[1,n) に含まれる乱数を作成すれば、それは有効なウォレット秘密鍵と見なせます。そしてこの秘密鍵 d*G から得られる公開鍵を keccak256 で計算して得られるウォレットアドレスが、この秘密鍵の存在に対応する blockchain 上のウォレットになります。言い換えると、理論上ウォレットは常に blockchain 上に存在しており、そのアドレスに対応する秘密鍵を作成した時点で、あなたはその owner としてそれを有効化し利用できるようになります（他の人に使われていない場合）。

  ただし、毎回わざわざ乱数を作成してウォレットを生成するのは少し面倒ですし、ランダムな16進の大きな数を覚えるのも現実的ではありません。では、より簡単に、一定の規則に従った複数のウォレットをまとめて作成でき、復元時には覚えやすい共通の内容だけで一括復元できる方法はないのでしょうか。これが HD ウォレット（Hierarchical Deterministic Wallet）、あるいは現在最もよく使われているニーモニックウォレットです。

  これは BIP-39 によってニーモニックとその seed を生成し、BIP-32 によって seed から m を派生し、最後に BIP-44 に従って m/44‘/60’/acc‘/0/i の形式でウォレットを一括計算して生成します。

• ウォレットの復元/インポート

  通常のウォレットであれば、0x から始まるあの秘密鍵文字列を覚えていれば復元できます（驚異的な記憶力があれば）。

  より一般的な HD wallet では、上記の派生フローをたどることで、いくつかのよく使われるアドレスを復元します。具体的な手順は、BIP-39 でニーモニックを生成した後からそのまま接続できます。

検証とトランザクション#

ウォレットが起こす行動を、それがオンチェーン状態を直接変更できるかどうかで分けるなら、おおよそ検証とトランザクションの2種類に分けられます。

• 検証

  検証は文字どおり、以前の blog でも述べたように、EIP-191 のフィールド（一般には SIWE 形式）に署名し、その署名を受け取ったサービス側にウォレットの所有権を検証させるものです。

  
  dreaife.tokyo

  EOA向けのEVMウォレットログイン画面

  EVM/EOAウォレットログインの実装例をもとに、connect wallet、SIWE形式メッセージ、wagmi署名、nonce、バックエンド検証を整理し、アドレス接続と署名による所有権証明を分ける理由を解説します。

  dreaife.tokyo/jp/posts/evm-wallet-login/

  もちろん、ウォレットが署名のような単純な操作しかできないのであれば、ウォレットでできることはあまりにも少なくなります。そこで EIP-712 が登場しました。

  合意された署名フィールドを定義することで、ユーザーは署名するだけで DApp やその他のサービスに対し、オンチェーンのスマートコントラクトを呼び出すトランザクションを発行して署名内容を実行する権限を与えられます。これにより、ユーザーはオンチェーン資産をより便利に制御できます。

  もちろん、EIP-7702 のように EOA ウォレットへコントラクトウォレットに近い能力を持たせるプロトコルもありますが、ここでは主に EOA ウォレット関連を考えるため、深くは扱いません。

• トランザクション

  トランザクションは、ウォレットがオンチェーン状態を能動的に変更する基本的な方法です。通常は to｜value｜data｜nonce｜gas｜chainId といった基本内容を含みます。これらのフィールド内容を制御することで、ウォレットが発行するトランザクションは、送金、コントラクト呼び出し、コントラクトデプロイなどの基本操作を実行できます。

HD ウォレットの秘密鍵作成フロー#

ニーモニックの生成から、実際にウォレットアドレスを制御できる秘密鍵を派生するまでの一連の流れは、一般に次のようになります。

• BIP-39 でニーモニックと seed を生成する
• BIP-32 で seed からマスター鍵 m を派生する
• BIP-44 では Ethereum で使われる m/44’/60’/account’/0/i という派生ルールに従い、account と i によって決定論的に秘密鍵を派生する

以下、それぞれの手順を詳しく紹介します。

ニーモニックと seed の生成#

ニーモニックの生成

• ランダムエントロピー entropy を生成する

  BIP-39 でニーモニックを生成する際、まず 128/160/192/224/256 bit の乱数を生成します。

  それぞれ 12語/15語/18語/21語/24語のニーモニックに対応します。ここでは 256bit entropy、つまり24語のニーモニック生成を例にします。

• entropy に対して SHA-256 を計算し、新しい 256bit の数を得る

• 長さ ENT/32 の checksum を取る

  言い換えると、まず SHA-256 計算後のデータから checksum を計算し、その checksum 結果の先頭から ENT/32 の長さ分を取ります。256bit の乱数の場合、checksum の先頭 8bit を取ることになります。

• entropy と checksum を連結し、256bit+8bit、つまり 264bit の数を得る

• ここでこのデータを 11bit ごとに分割すると、264/11 = 24 グループになります。これが 256bit が24語のニーモニックに対応する理由です

• その後、各グループについて、2048（$2^{11}$）個の BIP-39 wordlist から対応する word を選びます

• この時点で得られた24個の word が、一般に HD ウォレットで使われるニーモニックです

次に、ニーモニックから seed を生成します。

ここでは PBKDF2-HMAC-SHA512 によって 512bit の seed を計算します。具体的な計算は次のとおりです。

$PBKDF2-HMAC-SHA512(password=mnemonic ,salt="mnemonic"+password,iteration=2048,dkLen=64bytes)$

つまり、utf8 byte stream 化したニーモニックを password とし、salt を “mnemonic”+password として、HMAC-SHA512 を iteration=2048 回実行します。最初の U1 は、ニーモニックと password、および block_index によって計算されます（U1=HMAC(password,salt || INT(block_index))）。その後の U2 以降は、前回計算された $U_{i-1}$ を key として HMAC-SHA512 を計算します（U2=HMAC(password, U1)）。

これにより最終的に計算される最初の block の result = U1 xor U2 xor … xor U2048 となります。512bit の出力が要求長である 64byte に一致するため、block は1つだけです。このとき出力される result が、BIP-39 の規則に従って生成された seed になります。

マスター鍵 m の派生#

BIP-32 によると、上で計算した seed に対してもう一度 HMAC-SHA512 を実行して I を得ます。具体的には次のとおりです。

$I = HMAC-SHA512(key = \text{``Bitcoin seed''}, data = seed)$

この時点で 512bit の I が得られます。256bit の長さに従って、これを左右2つの 256bit の数に分割できます。

左側の $I_L$ は master private key として、右側の $I_R$ は master chain code として使われます。

これらは次の BIP-44 の派生計算で使用されます。

特定の鍵の派生計算#

次は、BIP-44 がどのようにマスター鍵から m/44’/60’/account’/0/i のパスに沿って、BIP-32 により特定の鍵を計算するよう定めているかです。

ここから secp256k1 楕円曲線の群演算の範囲に入るため、基礎知識がない場合は、以前書いた原理の証明もぜひ見てください（

dreaife.tokyo

EOAウォレットの署名検証とその関連内容について

EOAウォレットの署名検証を、secp256k1、ECDSAのr/s/v、公開鍵復元、keccak-256によるアドレス計算から整理し、SIWEログインで秘密鍵を渡さず所有権を確認する仕組みを解説します。

dreaife.tokyo/jp/posts/eoa-sign-verify/

• 派生パス m/44’/60’/account’/0/i

  まず、派生パスとは何かを紹介します。

  派生パスは、マスター鍵 m をルートノードとする深さ6層の数として理解できます。各層は $2^{32}$ の数です。ただし、この $2^{32}$ の数については、一般にはその半分、つまり $2^{31}$ の数だけを使用します。これは各層の数字の右上にある ‘ が hardened かどうかによって、その層の数字 i を単に i（[0,$2^{31}$)）として使うのか、それとも i‘=i+$2^{31}$ として使うのかが決まるためです。

  同時に、この hardened マークは子ノードを計算する際の計算方式にも影響します。

  m の後ろにある 44’/60’/account’/0/i の5層の意味は、それぞれ次のとおりです。

  • 44‘：BIP-44 で規定された目的
  • 60’：Ethereum で使われる coin type
  • account‘：派生時に選択するアカウント番号
  • 0：external chain、一般に通常の受取アドレスに使われる
  • i：各アカウントにおける i 番目のアドレス

• non-hardened 子ノードの計算方式

  ある層の子ノードの数字 i について、親ノードの秘密鍵 IL（以下 pPk）と chainCode IR（以下 pCc）を使い、次の式で子ノードの I を計算できます。

  $$I = HMAC-SHA512(key=pCc,data=(serP(pPk*G) || ser32(i))$$

  ここで、$serP(pPk*G)$ は 0x02/0x03 || (pPkG)_x を意味します。pPkG は親ノードの公開鍵であり、0x02 か 0x03 かは、計算された親ノード公開鍵（mod p）の y/p-y が奇数か偶数かによって決まります。

  得られた I についても同様に、256bit の長さに従って左右の IL と IR に分割します。

  その子ノードの秘密鍵 child private key は (IL+parent private key) mod n になります。

  子ノードの child chain code は IR になります。

• hardened 子ノードの計算方式

  ある層の子ノードの数字 i’ について、親ノードの秘密鍵 IL（以下 pPk）と chainCode IR（以下 pCc）を使い、次の式で子ノードの I を計算できます。

  $$I = HMAC-SHA512(key=pCc,password=(0x00 || ser256(pPk) || ser32(i + 2^{31}))$$

  ここで 0x00 は秘密鍵 pPk を直接使用することを意味するため、公開鍵の y の奇偶を判断する必要はありません。

  得られた I についても同様に、256bit の長さに従って左右の IL と IR に分割します。

  その子ノードの秘密鍵 child private key は (IL+parent private key) mod n になります。

  子ノードの child chain code は IR になります。

• 最終的に得られる秘密鍵

  m/44’/60’/account’/0/i に従って層を1つずつ派生していき、最終的に address_index i のリーフノードに到達します。この選択されたノード上で計算されるその子ノードの child private key が、そのアカウントアドレスの秘密鍵 d です。実際のアカウントアドレスは、通常どおり秘密鍵 d*G を keccak256 で計算し、後ろ20byte を取ることで得られます。

  同時に、このアドレスについては、EIP-55 の checksum によって通常のアドレスを大文字小文字混在のアドレスに変換し、アドレス形式の正当性（文字列形式/入力ミスのチェック）を保証する方法があります。

  EIP-55 は、アドレス内の文字自体は変更せず、そのアドレスの keccak256 計算結果に基づいて大文字小文字だけを変更する方式です。i 番目の文字が a-f の場合、その keccak256 計算結果に対応する i 番目が 8 以上なら大文字にし、それ以外は変更しません。

トランザクションの構造#

通常の EIP-1559/type2 トランザクションの内部構造は、おおよそ次のようになります。

1
type: 0x02
2

3
chainId
4
nonce
5

6
maxPriorityFeePerGas
7
maxFeePerGas
8
gasLimit
9

10
to
11
value
12
data
13

14
accessList
15

16
signatureYParity
17
signatureR
18
signatureS

これは単に属性を列挙したものです。未署名のトランザクションは、一般にはより json に近い形式になります。

1
{
2
  chainId: 1,
3
  nonce: 42,
4
  to: "0xContractOrEOA...",
5
  value: "1000000000000000000",
6
  data: "0x...",
7
  gasLimit: "21000",
8
  maxFeePerGas: "...",
9
  maxPriorityFeePerGas: "..."
10
}

署名後は、検証時の署名結果と同じように r/s/v が出力され、それらを上記 json の末尾に追加します。

その後、以下の構造に従って、トランザクション内容と署名から構成されるトランザクションを bytes 列にエンコードし、raw signed trans action とします。このエンコード済みトランザクションは、RPC に送信してブロードキャストし、オンチェーン化の準備を行えます。

1
0x02 || rlp([
2
  chainId,
3
  nonce,
4
  maxPriorityFeePerGas,
5
  maxFeePerGas,
6
  gasLimit,
7
  to,
8
  value,
9
  data,
10
  accessList,
11
  yParity,
12
  r,
13
  s
14
])

各フィールドの役割は次のとおりです。

• chainId: 同じトランザクションが別のチェーンでリプレイされるのを防ぐ
• nonce: アカウントのトランザクション番号。同じトランザクションの重複実行を防ぎ、トランザクション順序も決定する（ここでの nonce は現在のチェーン上で操作ウォレットに対する nonce であり、前回トランザクションの nonce から必ず +1 の順序で進む必要がある点に注意）
• to: 送信先アドレス。空の場合はコントラクトデプロイ
• value: 付随して送信するネイティブ通貨の数量
• data/input: コントラクト呼び出しの calldata、またはコントラクトデプロイ時の init code
• gasLimit: このトランザクションが消費できる gas の最大量
• maxFeePerGas: ユーザーが支払ってもよい最高単価
• maxPriorityFeePerGas: validator/proposer へのチップ上限
• signature: EOA ウォレットによるトランザクション内容への署名

手数料モデル#

手数料モデルは一般に次のように分けられます。

ここでは主に現在よく使われる基本的なトランザクションのみを考えるため、上記構造は type2 を参考にして記述しています。

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

1つのトランザクションは、一般に何らかのアプリケーションを呼び出す際、あるいはウォレット内でその内容を構築して署名し、その後、構築済みのトランザクション内容を RPC に送信してオンチェーンへブロードキャストします。おおよその流れは次のようになります。

SIWE 標準による通常のウォレット所有権検証#

これは、あるウォレットが呼び出し先のサービスに対して、ユーザーがそのウォレットの制御権を持っていることを証明するものです。具体的な内容は、上で載せた blog を参照できます（

dreaife.tokyo

EOA向けのEVMウォレットログイン画面

EVM/EOAウォレットログインの実装例をもとに、connect wallet、SIWE形式メッセージ、wagmi署名、nonce、バックエンド検証を整理し、アドレス接続と署名による所有権証明を分ける理由を解説します。

dreaife.tokyo/jp/posts/evm-wallet-login/

EIP-712、コントラクトに権限付与できる検証#

EIP-712 は、712 署名内容に同意したことを示す権限付与の検証です。ただしこれはトランザクションにおける署名により近く、コントラクト呼び出しに必要なパラメータへ署名することで、コントラクト（この種の権限付与をサポートしているもの）内であなた名義の資産を操作することを許可します。もちろんこれはあくまで署名であり、この署名内容によってオンチェーン状態を変更したい場合、サービス側がこの署名と呼び出し内容をトランザクションにまとめ、その署名対象のコントラクトへ渡して呼び出す必要があります。

• 署名内容

  署名内容は一般に次のような形式になります。

  1
  {
  2
    types: {
  3
      EIP712Domain: [
  4
        { name: "name", type: "string" },
  5
        { name: "version", type: "string" },
  6
        { name: "chainId", type: "uint256" },
  7
        { name: "verifyingContract", type: "address" }
  8
      ],
  9
      Permit: [
  10
        { name: "owner", type: "address" },
  11
        { name: "spender", type: "address" },
  12
        { name: "value", type: "uint256" },
  13
        { name: "nonce", type: "uint256" },
  14
        { name: "deadline", type: "uint256" }
  15
      ]
  16
    },
  17
    primaryType: "Permit",
  18
    domain: {
  19
      name: "DemoToken",
  20
      version: "1",
  21
      chainId: 1,
  22
      verifyingContract: "0xTokenContract..."
  23
    },
  24
    message: {
  25
      owner: "0xUser...",
  26
      spender: "0xDappOrRouter...",
  27
      value: "1000000000000000000",
  28
      nonce: 0,
  29
      deadline: 1710000000
  30
    }
  31
  }

  ここで、types はデータ構造を定義するために使います。primaryType は署名の主構造で、Permit、Order、Forward、Request などがあります。domain は署名の適用範囲を指定します。message はユーザーが実際に権限付与する内容です。

• EIP-712 の署名から使用までの流れ

  たとえば permit 型の 712 では、ユーザー owner が署名し、spender というアドレスが value 数量の token を deadline まで使用でき、nonce が n であることを許可します。その後、この権限付与を署名として DApp に返し、DApp はこの権限付与と内容を使って permit( owner, spender, value, deadline, v, r, s) というトランザクションを発行します。呼び出されたコントラクトは署名が署名内容と一致することを検証した後、権限付与内容に基づいて状態を変更します。

  具体的な内容は次のとおりです。

  1. プロトコル/コントラクトがまず署名可能な構造を定義する Permit(owner, spender, value, nonce, deadline)
  2. DApp が EIP-712 typed data を構築する types、domain、primaryType、message を含む
  3. ウォレットが署名内容を表示する ユーザーは、どの DApp、どのチェーン、どのコントラクト、どのような権限付与内容なのかを確認する
  4. ユーザー確認後、EOA 秘密鍵で署名する ウォレットが digest を計算する: keccak256(“\x19\x01” || domainSeparator || hashStruct(message)) そして r/s/v を署名する
  5. ウォレットが signature を DApp / サービス側に返す この時点ではまだオンチェーンではなく、gas も状態変化もない
  6. DApp / relayer / その他の人が1つのトランザクションを構築する message 内のフィールド + signature を一緒にコントラクトへ渡す
  7. コントラクトがオンチェーンで同じ digest を再構築する その後 ecrecover / ECDSA.recover で signer を復元する
  8. コントラクトが署名の正当性をチェックする signer が owner と等しいか nonce が未使用か deadline が期限切れでないか chainId / verifyingContract / domain が一致するか
  9. チェックに通過した後、コントラクトが状態変更を実行する たとえば allowance の設定、注文成立、meta transaction の実行
  10. nonce を消費する 同じ署名が再利用されることを防ぐ

EOA/HD ウォレット#

ウォレット作成について、現在の実装は一般的なウォレットや ethers ライブラリのデフォルトと同じく、デフォルトで第0 account の第0アドレスの秘密鍵を取得します。具体的な実装は以下のとおりで、使用パスは m/44‘/60’/0‘/0/0 です。主に ethers の Wallet を使って createRandom で作成し、直接 new/HDNodeWallet.fromPhrase でインポートします。

1
const DEFAULT_DERIVATION_PATH = "m/44'/60'/0'/0/0";
2

3
function createWallet() {
4
  const nextWallet = ethers.Wallet.createRandom();
5
  selectWallet(nextWallet, "Created wallet");
6
}
7

8
function importWallet() {
9
  const nextWallet = new ethers.Wallet(importKey.trim());
10
  selectWallet(nextWallet, "Imported wallet");
11
}
12

13
function importSeedPhrase() {
14
  const phrase = seedPhrase.trim().replace(/\s+/g, " ");
15
  const nextWallet = ethers.HDNodeWallet.fromPhrase(
16
    phrase,
17
    "",
18
    DEFAULT_DERIVATION_PATH
19
  );
20
  selectWallet(nextWallet, `Imported seed phrase at ${DEFAULT_DERIVATION_PATH}`);
21
}

EIP-191 通常署名#

1
function personalSignEnvelope(message: string) {
2
  const byteLength = ethers.toUtf8Bytes(message).length;
3
  return `0x19 || "Ethereum Signed Message:\n${byteLength}" || utf8(message)`;
4
}
5

6
async function signMessage() {
7
  const activeWallet = requireWallet();
8
  const nextSignature = await activeWallet.signMessage(message);
9
  setSignature(nextSignature);
10
}
11

12
function verifyMessage() {
13
  const recovered = ethers.verifyMessage(message, signature);
14
  const digest = ethers.hashMessage(message);
15
  setRecoveredAddress(recovered);
16
}

EIP-712 署名#

• 署名内容の構築と検証

  1
  const typedDomain = {
  2
    name: "EOA Wallet Lab",
  3
    version: "1",
  4
    chainId: BigInt(typedChainId || "1"),
  5
    verifyingContract: typedVerifier || ZERO_ADDRESS
  6
  };
  7
  
  8
  const typedTypes = {
  9
    LoginRequest: [
  10
      { name: "owner", type: "address" },
  11
      { name: "statement", type: "string" },
  12
      { name: "nonce", type: "string" },
  13
      { name: "deadline", type: "uint256" }
  14
    ]
  15
  };
  16
  
  17
  const typedValue = {
  18
    owner: wallet?.address || ZERO_ADDRESS,
  19
    statement: typedStatement,
  20
    nonce: typedNonce,
  21
    deadline: BigInt(typedDeadline || "0")
  22
  };
  23
  
  24
  async function signTypedData() {
  25
    const activeWallet = requireWallet();
  26
    const nextSignature = await activeWallet.signTypedData(
  27
      typedDomain,
  28
      typedTypes,
  29
      typedValue
  30
    );
  31
    setTypedSignature(nextSignature);
  32
  }
  33
  
  34
  function verifyTypedData() {
  35
    const recovered = ethers.verifyTypedData(
  36
      typedDomain,
  37
      typedTypes,
  38
      typedValue,
  39
      typedSignature
  40
    );
  41
    const digest = ethers.TypedDataEncoder.hash(typedDomain, typedTypes, typedValue);
  42
    setTypedRecovered(recovered);
  43
  }

• type2 トランザクション構築署名

  1
  function buildTxRequest(): ethers.TransactionRequest {
  2
    return {
  3
      type: 2,
  4
      to,
  5
      value: ethers.parseEther(txValue || "0"),
  6
      data,
  7
      chainId: BigInt(txChainId || "1"),
  8
      nonce: Number(txNonce || "0"),
  9
      gasLimit: BigInt(txGasLimit || "21000"),
  10
      maxFeePerGas: ethers.parseUnits(txMaxFee || "1", "gwei"),
  11
      maxPriorityFeePerGas: ethers.parseUnits(txPriorityFee || "1", "gwei")
  12
    };
  13
  }
  14
  
  15
  async function signTransaction() {
  16
    const activeWallet = requireWallet();
  17
    const signed = await activeWallet.signTransaction(buildTxRequest());
  18
    const parsed = ethers.Transaction.from(signed);
  19
  
  20
    setRawTx(signed);
  21
    setTxHash(parsed.hash || "");
  22
  }
  23
  
  24
  function verifyRawTransaction() {
  25
    const parsed = ethers.Transaction.from(rawTx);
  26
    setTxHash(parsed.hash || "");
  27
    setTxSigner(parsed.from || "");
  28
  }

• トランザクションのブロードキャスト

  1
  async function broadcastTransaction() {
  2
    const signed = rawTx || (await requireWallet().signTransaction(buildTxRequest()));
  3
    const provider = new ethers.JsonRpcProvider(rpcUrl);
  4
    const parsed = ethers.Transaction.from(signed);
  5
  
  6
    const response = await provider.broadcastTransaction(signed);
  7
  
  8
    setRawTx(signed);
  9
    setTxHash(parsed.hash || response.hash);
  10
    setTxSigner(parsed.from || "");
  11
    setBroadcastHash(response.hash);
  12
  
  13
    const receipt = await provider.waitForTransaction(response.hash, 1, 60_000);
  14
  }