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

• ウォレットの作成

  一般に、[1,n)の範囲に収まる乱数を生成すれば、有効なウォレット秘密鍵として使用できます。その秘密鍵dからd*Gで得られる公開鍵をkeccak256で計算して導出したウォレットアドレスが、この秘密鍵に対応するブロックチェーン上のウォレットです。言い換えれば、理論上ウォレットは常にブロックチェーン上に存在しており、そのアドレスに対応する秘密鍵を作成すれば、まだ誰にも使われていない限り、そのownerとしてウォレットを有効化し、使用できるようになります。

  しかし、ウォレットを生成するたびに専用の乱数を作成する必要があるのは少々面倒です。また、ランダムな16桁の大きな数を覚えることも簡単ではありません。それでは、一定の規則に従う複数のウォレットを一括で作成し、復元時には覚えやすい1つの共通情報だけですべてを復元する方法はないのでしょうか。そこで登場するのがHDウォレット（Hierarchical Deterministic Wallet）、つまり現在最も一般的に使用されているニーモニックウォレットです。

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

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

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

  より一般的なHD walletの場合は、前述の導出フローをたどって、よく使われるアドレスを復元します。具体的な手順は、BIP-39によるニーモニックの生成からそのまま連続しています。

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

ウォレットが開始する操作を、オンチェーン状態を直接変更できるかどうかで分類すると、おおむね検証とトランザクションの2種類に分けられます。

• 検証

  検証とは、その名のとおり、以前のブログでも説明したように、EIP-191形式のフィールド（一般にはSIWE形式）に署名し、署名を受け取ったサービス側にウォレットの所有権を検証してもらうことです。

  
  dreaife.tokyo

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

  React/wagmi製のEVMウォレットログインを例に、接続、サーバー発行nonce、SIWEメッセージ、署名、バックエンドでのアドレス復元を追い、アドレス接続と管理権の証明を分ける理由を解説します。

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

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

  共通認識できる署名フィールドを定義することで、ユーザーは署名するだけで、DAppやその他のサービスにトランザクションの開始を許可できます。それによってオンチェーンのスマートコントラクトから署名内容を実行でき、ユーザーはオンチェーン資産をより簡単かつ便利に管理できます。

  このほか、EOAウォレットにコントラクトウォレットに近い機能を持たせるEIP-7702のようなプロトコルもありますが、ここでは主に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を求め、その結果の先頭から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)$

つまり、UTF-8バイトストリーム化したニーモニックをpasswordとし、saltを「mnemonic」+passwordとして、HMAC-SHA512をiteration=2048回実行します。最初のU1はニーモニック、password、block_indexから計算し（U1=HMAC(password,salt || INT(block_index))）、U2以降は前回の計算結果$U_{i-1}$を用いて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ずつ、左右それぞれ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ウォレットの署名検証とその関連事項について

secp256k1の有限体と点演算からECDSAのr/s/v署名と公開鍵復元を導出し、SIWEを例に、サーバーが秘密鍵に触れずメッセージハッシュとkeccak-256でEOAアドレスの管理権を検証する仕組みを解説します。

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

• 導出パスm/44’/60’/account’/0/i

  まず、導出パスとは何かを説明します。

  導出パスは、マスターキーmをルートノードとする深さ6階層のツリーとして理解できます。各階層には$2^{32}$個の数値がありますが、通常はその半分、つまり$2^{31}$個だけを使用します。各階層の数値の右上に付く‘によってhardenedかどうかが決まり、その階層の数値iをそのまま使用するか（[0,$2^{31}$)）、i‘=i+$2^{31}$として使用するかが決まります。

  また、このhardenedマークは、子ノードを計算するときの計算方法にも影響します。

  mに続く44’/60’/account’/0/iの5階層には、それぞれ次の意味があります。

  • 44‘：BIP-44で規定されたpurpose
  • 60’：Ethereumで使用するcoin type
  • account‘：導出時に選択するアカウント番号
  • 0：external chain。通常の受取アドレスとして一般的に使用
  • i：各アカウントのi番目のアドレス

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

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

  $$$$

  ここで$serP(pPk*G)$は、0x02/0x03 || (pPk*G)_xを意味します。pPk*Gは親ノードの公開鍵であり、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を計算できます。

  $$$$

  ここで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に従って階層ごとに導出し、最終的に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 transactionとします。エンコード済みのトランザクションは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を基準に記述しています。

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

一般にトランザクションは、アプリケーションの呼び出し時、またはウォレット内で内容を構築して署名し、完成したトランザクションをRPCへ送信してブロードキャストし、オンチェーンへ取り込ませます。おおまかなフローは次のとおりです。

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

ここでは、ウォレットがサービス側に対して、ユーザーがそのウォレットを制御していることを証明します。具体的な内容については、前述のブログを参照してください（

dreaife.tokyo

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

React/wagmi製のEVMウォレットログインを例に、接続、サーバー発行nonce、SIWEメッセージ、署名、バックエンドでのアドレス復元を追い、アドレス接続と管理権の証明を分ける理由を解説します。

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

EIP-712：コントラクトに権限を付与できる検証方式#

EIP-712は、EIP-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タイプのEIP-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／その他の主体がトランザクションを構築
     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
  }