ついこの間まで5年以上にわたり同じプロダクトをメンテしていてそのtipsをまとめたりしたんですが、今久しぶりに完全新規の開発をしていて、ハードルの下がり方がすごいのでシェアします。想定読者はEVMチェーン上(Ethereum, Base, Arbitrum, Polygon, ...)でサービス開発をしている、もしくはしようと思っているエンジニアです。別段超最新のstackでもないので、知っとるわ！　という方もいるかとは思いますが、そういう人は連絡ください。採用しますｗ

目的とStack

果たしたい目的は以下を考えます:

• EVM上で動作するwebアプリを爆速で開発したい

• フロントエンドもコントラクトも頻繁に実装が変わる中、それに対応するQA環境を爆速で整備したい

EVM上で動作するwebアプリのシステム構成としては、

1. フロントエンド

2. スマートコントラクト

3. オンチェーンデータをクエリできるAPI(The Graphなど)

4. 必要であればバックエンドやデータベース

だと思いますが、この記事では1, 2をメインでカバーし、3は軽く触れます。

Stack:

• フロントエンド: Next.js

  • ホスティング: Vercel

• Solidity開発、デプロイ: Foundry

• CI/CD: GitHub Actions

• テストネット: Tenderly

• レポジトリ・パッケージ: monorepo (Turborepoを採用しましたが何でも良い) , pnpm packages

作ったプロセス

1. monorepoをそのままLLMが使えるIDEで開き、爆速開発する

2. GitHubに変更をpushする

3. GitHub Actionが走る。この時点ではVercelのデプロイは行われない

4. コントラクトに変更がある場合は5, ない場合、つまりフロントエンドだけの変更の場合は8に進む

5. 新規のプライベートなテストネットが作成される

6. そのテストネットに必要なコントラクトがデプロイされる

7. デプロイされたコントラクトのアドレスがVercelの環境変数に記述される

8. Vercelのデプロイが走る

9. 変更で入った新機能をテストできるQA環境のできあがり！

主要プロセスの解説

monorepoをそのままIDEで開き、爆速開発する

これはなんていうか別にEVM開発に限らず、従来のフロントエンド、バックエンド開発でも同じですが、複数のシステムをまたいでLLMにファイルをメンションし、「このコントラクトの変更をもとにこのUIの挙動をこう変更してくれよな！」と命令するのが圧倒的に楽だと言うだけの話です。僕はIDEはCursor、モデルはGPT 5.2, Gemini 3あたりを使っていますが何を使おうがこの点に関してはほぼ一緒かなと思います。
参考までにファイル構成は以下のようになります。

# 省略しているフォルダやファイルも多くあります
.github/ # GitHub Actions
  workflows/
apps/
  web/ # Next.js
    src/
      app/ # Next.js App Router
packages/
  contracts/ ## Foundryプロジェクトのtop
    broadcast/
    script/
    src/
    subgraph/
pnpm-workspace.yaml # pnpm packagesの設定ファイル
turbo.json # Turborepoの設定ファイル

GitHub Actionが走る。この時点でVercelデプロイは行われない

コントラクトの変更やそれが動くテストネットのRPC URLなどを反映させたフロントエンドを自動でデプロイしたいので、push時点でのVercelデプロイはignore(キャンセル)させます。VercelはNext.jsアプリ直下に vercel.json を置くとそれを読んでくれます。

# apps/web/vercel.json
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "ignoreCommand": "bash ./scripts/vercel-ignore.sh"
}

scripts/vercel-ignore.sh にはどういうときにgit pushだけでデプロイが動いてほしいか、ほしくないかを記述しました。例えば、本番環境やステージングは動いてほしいとか、この環境変数が立っているときはしてほしいとか、開発のステージや要件次第。

コントラクトに変更がある場合は5, ない場合、つまりフロントエンドだけの変更の場合は8に進む

GitHub Actionの設定でこんな感じで記述しました。まあこんなの要件を伝えればAIが書いてくれるんで、新規で作っても以下をコピペして「こういう風に変えたい」とか言っても数分で終わるでしょう。

# 例えば .github/workflows/qa-main.yml 
jobs:
  changes:
    if: github.event_name == 'workflow_dispatch' || vars.QA_MAIN_ENABLED == 'true'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      contracts_changed: ${{ steps.diff.outputs.contracts_changed }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - id: diff
        run: |
          set -euo pipefail
          BEFORE="${{ github.event.before }}"
          AFTER="${{ github.sha }}"
          if [ -z "$BEFORE" ] || [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
            echo "contracts_changed=true" >> "$GITHUB_OUTPUT"
            exit 0
          fi
          if git diff --name-only "$BEFORE" "$AFTER" | grep -q '^packages/contracts/'; then
            echo "contracts_changed=true" >> "$GITHUB_OUTPUT"
          else
            echo "contracts_changed=false" >> "$GITHUB_OUTPUT"
          fi

これで contracts_changed が true ならコントラクト変更あり、 false ならコントラクト変更無しということでどのステップに進むかを指示するわけですね。

新規のプライベートなテストネットが作成される

ここからはTenderlyのVirtual TestNetsというプロダクトを使います。これは自分たち専用のテストネットを、既存のチェーンをforkする形で作れるプロダクトです。例えば「Base mainnetの最新blockをforkしたチェーン作って」みたいな感じです。

TenderlyはGitHub Actionsを用意してくれているのでそれを使います。使い方例は以下、レポジトリはここです。

jobs:
  qa:
    steps:
      - name: Create Tenderly Virtual TestNet
        if: inputs.run_tenderly || inputs.run_foundry || (inputs.run_vercel && inputs.vercel_update_env) # 走らせる条件。要件次第
        uses: Tenderly/vnet-github-action@v1.0.17
        with:
          mode: CD
          access_key: ${{ secrets.tenderly_access_token }}
          account_name: ${{ inputs.tenderly_account_name }}
          project_name: ${{ inputs.tenderly_project_name }}
          testnet_name: ${{ inputs.testnet_name }} # 特に何も入れないでもユニークな名前が割り当てられます
          network_id: |
            ${{ inputs.tenderly_network_id }}
          chain_id_prefix: ${{ inputs.chain_id_prefix }}
          state_sync: ${{ inputs.state_sync }}
          public_explorer: ${{ inputs.public_explorer }}

これで自分たち専用の、どこかのチェーンをforkしたテストネットが作成されました。

そのテストネットに必要なコントラクトがデプロイされる

まずデプロイにはgasが必要なので、それを送ります。自分たちのテストネットでやりたい放題して大丈夫ですから、なんのトークンでも送れる機能があります。fork元のチェーンにあるトークンならなんでもいけます。下はシンプルにETHを送るときですね。 tenderly_setBalance という命令を使っているのが分かると思います。

jobs:
  qa:
    steps:
      ...

      - name: Fund deployer (Tenderly unlimited faucet)
        if: inputs.run_foundry
        env:
          ADMIN_RPC_URL: ${{ env.ADMIN_RPC_URL }}
          DEPLOYER_ADDRESS: ${{ inputs.deployer_address }}
          DEPLOYER_BALANCE_WEI_HEX: ${{ inputs.deployer_balance_wei_hex }}
        run: |
          set -euo pipefail
          [ -n "${ADMIN_RPC_URL:-}" ] && echo "::add-mask::$ADMIN_RPC_URL"
          curl -sS "${ADMIN_RPC_URL}" \
            -X POST \
            -H "Content-Type: application/json" \
            -d '{
              "jsonrpc": "2.0",
              "method": "tenderly_setBalance",
              "params": [["'"${DEPLOYER_ADDRESS}"'"], "'"${DEPLOYER_BALANCE_WEI_HEX}"'"],
              "id": 1
            }'

そしたらコントラクトをデプロイしましょう。デプロイするスクリプトは一つにまとめておいたほうが楽かなとは思いますが、複数実行してもいいでしょう。

jobs:
  qa:
    steps:
      ...

      - name: Install Foundry
        if: inputs.run_foundry
        uses: foundry-rs/foundry-toolchain@v1

      - name: Deploy contracts with Forge Script
        if: inputs.run_foundry
        working-directory: ${{ inputs.foundry_dir }}
        env:
          PRIVATE_KEY: ${{ inputs.deployer_private_key }} # 基本使って捨てるQA環境用なので、漏れてもいい前提の鍵を利用するのをおすすめします。漏れちゃいけない鍵の管理は各自考えましょう
          RPC_URL: ${{ env.RPC_URL }}
        run: |
          set -euo pipefail
          forge script script/${{ inputs.forge_script_file }} \
            --rpc-url "$RPC_URL" \
            --private-key "$PRIVATE_KEY" \
            --broadcast \
            -vvv

デプロイされたコントラクトのアドレスがVercelの環境変数に記述される

forge script コマンドは broadcast/{{Chain ID}}/{{スクリプトファイル名}}/run-latest.jsonにデプロイ結果を記述するので、そこからデプロイされたコントラクトのアドレスを抜き出します。

jobs:
  qa:
    steps:
      ...

      - name: Extract deployed contract addresses
        if: inputs.run_foundry
        env:
          FOUNDRY_DIR: ${{ inputs.foundry_dir }}
          CHAIN_ID: ${{ env.CHAIN_ID }}
          FORGE_SCRIPT_FILE: ${{ inputs.forge_script_file }}
        run: |
          set -euo pipefail
          CONTRACTS_ENV_FILE="/tmp/contracts.env"
          : > "$CONTRACTS_ENV_FILE"

          bash ./scripts/ci/extract-foundry-address.sh "${FOUNDRY_DIR}" "${CHAIN_ID}" "${FORGE_SCRIPT_FILE}" "${CONTRACTS_ENV_FILE}"

          # Export for subsequent steps as environment variables.
          cat "$CONTRACTS_ENV_FILE" >> "$GITHUB_ENV"

          echo "Extracted:"
          cat "$CONTRACTS_ENV_FILE" || true

scripts/ci/extract-foundry-address.sh で抜き出しているわけですが、このコードはちょっと長いので割愛します。まあAIに言えば秒で100行書いてくれますから。注意点としては、proxyパターンを使っているときに、例えば ABCToken をデプロイしたので NEXT_PUBLIC_CONTRACT_ABCTOKEN 環境変数を作成したいのに、 NEXT_PUBLIC_ERC1967PROXY なんてproxyコントラクト名の環境変数を作成されても困ります。なので使ってるパターンやproxyの種類に応じてスクリプトを調整しましょう。大丈夫です、まあAIに言えば略

さて、環境変数一覧ができあがりましたから、それを実際にVercelに反映しましょう。反映するのは

• 作られたテストネットのRPC URL

• 作られたテストネットのChain ID

• デプロイされたコントラクトのアドレス(複数)

です。ちょっと長いのでまあ参考程度に。一点気をつけるところとしては、 FORCE_BUILD_KEY というのをいじっていますが、これは上の vercel.json でデプロイする条件を厳しくしているので、その条件をこの後通過するよう(e.g. ./scripts/vercel-ignore.sh が 1 を返すように) 1 true などの値に設定しています。

jobs:
  qa:
    steps:
      ...

      - name: Upsert Vercel env (RPC/ChainId/Contracts + force-build=1)
        if: inputs.run_vercel && inputs.vercel_update_env
        env:
          VERCEL_TOKEN: ${{ secrets.vercel_token }}
          VERCEL_PROJECT: ${{ secrets.vercel_project }}

          VERCEL_ENV_TARGET: ${{ inputs.vercel_env_target }}
          FORCE_BUILD_KEY: ${{ inputs.force_build_key }}
          NEXT_PUBLIC_QA_RPC_URL_KEY: ${{ inputs.next_public_rpc_key }}
          NEXT_PUBLIC_QA_CHAIN_ID_KEY: ${{ inputs.next_public_chain_key }}

          RPC_URL: ${{ env.RPC_URL }}
          CHAIN_ID: ${{ env.CHAIN_ID }}
        run: |
          set -euo pipefail

          if [ -z "${VERCEL_TOKEN:-}" ] || [ -z "${VERCEL_PROJECT:-}" ]; then
            echo "ERROR: missing Vercel secrets (vercel_token/vercel_project)." >&2
            exit 1
          fi

          if ! command -v jq >/dev/null 2>&1; then
            sudo apt-get update -y
            sudo apt-get install -y jq
          fi

          # Read contract envs from the persisted file (preferred) or from current environment (fallback).
          CONTRACT_KVS="$(cat /tmp/contracts.env 2>/dev/null | grep '^CONTRACT_' || true)"
          if [ -z "$CONTRACT_KVS" ]; then
            CONTRACT_KVS="$(env | grep '^CONTRACT_' || true)"
          fi

          payload=$(jq -n \
            --arg target "${VERCEL_ENV_TARGET}" \
            --arg forceKey "${FORCE_BUILD_KEY}" \
            --arg rpcKey "${NEXT_PUBLIC_QA_RPC_URL_KEY}" \
            --arg chainKey "${NEXT_PUBLIC_QA_CHAIN_ID_KEY}" \
            --arg rpcVal "${RPC_URL}" \
            --arg chainVal "${CHAIN_ID}" \
            '[
              {key:$forceKey, value:"1", type:"encrypted", target:[$target]},
              {key:$rpcKey,   value:$rpcVal, type:"encrypted", target:[$target]},
              {key:$chainKey, value:$chainVal, type:"encrypted", target:[$target]}
            ]'
          )

          while IFS= read -r line; do
            [ -z "$line" ] && continue
            key="${line%%=*}"
            val="${line#*=}"
            payload=$(jq \
              --arg target "${VERCEL_ENV_TARGET}" \
              --arg k "NEXT_PUBLIC_${key}" \
              --arg v "${val}" \
              '. + [{key:$k, value:$v, type:"encrypted", target:[$target]}]' \
              <<<"$payload"
            )
          done <<<"$CONTRACT_KVS"

          echo "$payload" > /tmp/vercel-env-payload.json

          curl -sS -X POST "https://api.vercel.com/v10/projects/${VERCEL_PROJECT}/env?upsert=true" \
            -H "Authorization: Bearer ${VERCEL_TOKEN}" \
            -H "Content-Type: application/json" \
            --data-binary @/tmp/vercel-env-payload.json

Vercelのデプロイが走る

Vercelにはgit pushやVercel CLI/UIでの手動デプロイの他に、Deploy Hookを呼ぶことでデプロイするという方法が用意されているので、それを使います。 Settings → Gitにあります。

      - name: Trigger Vercel Deploy Hook
        if: inputs.run_vercel
        env:
          HOOK: ${{ secrets.vercel_deploy_hook_url }}
        run: |
          set -euo pipefail
          if [ -z "${HOOK:-}" ]; then
            echo "ERROR: missing vercel_deploy_hook_url secret." >&2
            exit 1
          fi
          curl -sS -X POST "$HOOK"

これでデプロイされたNext.jsアプリは新しく作られた専用テストネットを向いていて、新規追加や変更されたコントラクトにアクセスできています。一度仕組み化してしまえば、Git pushだけで全てが起こります。

一応、フロントエンド上の設定例は以下です。

import type { Chain } from 'viem'
...

  const rpcUrl = process.env.NEXT_PUBLIC_QA_RPC_URL
  const chainIdRaw = process.env.NEXT_PUBLIC_QA_CHAIN_ID
  if (!rpcUrl || !chainIdRaw) return null

  const id = Number(chainIdRaw)
  if (!Number.isFinite(id) || id <= 0) return null

  const chain: Chain = {
    id,
    name: 'Tenderly QA',
    nativeCurrency: { name: 'Ether', symbol: 'ETH', decimals: 18 },
    rpcUrls: {
      default: { http: [rpcUrl] },
      public: { http: [rpcUrl] },
    },
    testnet: true,
  }

The Graph連携

詳細は割愛しますが、その新規テストネット上で動くsubgraphのデプロイも自動化で来ます。ここに公式ドキュメントがあるのでどうぞ！

以上、Ethereum開発が楽になった話でした。

余談ですが、この仕組みの構築にかかった時間は数時間でした。数時間でこれが達成できる理由は言わずもがなですが、

1. Tenderly, Vercel, Foundryなど素晴らしいツールが揃っていること

2. AIがコードをすぐに書いてくれること

3. 自分がAIに適切な指示ができること

です。適切な指示にはやはり経験が物を言います。できるかどうかも見当がつかないことを指示したり質問するのは人間には難しいためです。こういう記事を読んで、新しくEthereum開発の世界に入ってくる人の知識・経験の足しになり、サービスを開発していく助けになれば嬉しいです。

最後に、TanéではEthereumエコシステム上でサービスを作る仲間を募集しています。興味のある方はXのDMあたりで連絡ください。よろしくお願いします！

https://mirror.xyz/0xtomo.eth/uMrMMzPFbK2gEkusMNZ66qQQbQr9LjCNWeBd2U5tnBM

前の記事で、EIP-7702はブロックチェーン玄人にとっては有力なオプションで、既存または新規のEOAに code をセットしてAccount Abstractionを含むコントラクトウォレット(e.g. smart account)のメリットを享受するといい、しかしブロックチェーンにもセキュリティにも疎い初心者ユーザには使いづらいのではないか? 引用すると

実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code をセットさせたいのではないか? その code にユーザが乗り換えようとしたとき、最初の code とデータに互換性はあるのか?

のような懸念を書きました。しかし、さらに考えを進めたり最近のサイトをいくつか見ているうちに、思った以上に簡単で、セキュアで、コストも低いウォレット管理が初心者にも提供できるのではないかと思うに至りました。もはや Smarter EOA という標題を超えて、EOAを全く意識しないことも可能そうです。例として、使う技術は以下が考えられます。

• EIP-7702

• WebAuthn

  • Passkey

  • ES256, P-256( secp256r1 )

• RIP-7212

• ( <iframe> )

上記の殆どは以下2つのサイトで使用されています。

https://gelato-eip-7702-demo.vercel.app/

https://eip7702.rath.fi/

下のサイトはほぼ間違いなく上のサイトのコード(ソースコードリンク)を参考にして作られていますが、まず上のサイトは以下のログイン(Connect Wallet)、トランザクション体験を提供しています。

1. ランダムなEthereumの秘密鍵( secp256k1 ECDSA)をフロントエンドで生成。EOAアドレスAが導出される

2. EIP-7702で、そのアドレスAの code に、既にデプロイされているコントラクトウォレット実装をセット

3. Passkey + WebAuthnを使って、P-256( secp256r1 ECDSA )の秘密鍵、公開鍵(以下 es256PubKey )を生成。256の後が k か r かが上と異なることに注意。秘密鍵自体は例えばMacOSで言うとKeychainに保存され、値を見ることはできないが任意のメッセージに署名することができる。コントラクトウォレットの初期化プロセスとして es256PubKey に他のコントラクト実行の権限を与える。コードは以下の authorize execute 関数を参照。RIP-7212は、 以下の P256.verify(digest, signature, key.publicKey) の、この実行をしていいかを検証する部分を安価にするための仕組み

   1. 背景として、P-256/ES256による署名はPasskeyのベースであるFIDO2/WebAuthnのデフォルト署名形式であり、Ethereumにおけるデフォルト署名形式と互換性がありません

    /// @notice Authorizes a new public key.
    /// @param publicKey - The public key to authorize.
    /// @param expiry - The Unix timestamp at which the key expires.
    function authorize(
        ECDSA.PublicKey calldata publicKey,
        uint256 expiry
    ) public returns (uint32 keyIndex) {
        if (msg.sender != address(this)) revert InvalidAuthority();

        Key memory key = Key({
            authorized: true,
            expiry: expiry,
            publicKey: publicKey
        });
        keys.push(key);
        emit Authorised();
        return uint32(keys.length - 1);
    }

    // /// @notice Executes a set of calls on behalf of the Authority, provided a P256 signature over the calls and a public key index.
    // /// @param calls - The calls to execute.
    // /// @param signature - The P256 signature over the calls: `p256.sign(keccak256(nonce ‖ calls))`.
    // /// @param keyIndex - The index of the authorized public key to use.
    // /// @param prehash - Whether to SHA-256 hash the digest.
    function execute(
        bytes memory calls,
        ECDSA.Signature memory signature,
        uint32 keyIndex,
        bool prehash
    ) public {
        bytes32 digest = keccak256(abi.encodePacked(nonce++, calls));
        if (prehash) digest = sha256(abi.encodePacked(digest));

        Key memory key = keys[keyIndex];
        if (!key.authorized) revert KeyNotAuthorized();
        if (key.expiry > 0 && key.expiry < block.timestamp) revert KeyExpired();

        if (!P256.verify(digest, signature, key.publicKey)) {
            revert InvalidSignature();
        }
        emit Executed();
        multiSend(calls);
    }

この仕組みが凄いのは、ステップ1で作られたランダムなアドレスAの秘密鍵が、ステップ3終了時点でもう破棄可能で、これ以降、そのウォレットを使ってなんらかのトランザクションを起こしたいときにはEOAを気にすることなくPasskeyによる認証をすれば良い。多くのデバイスでは指紋認証や顔認証など手軽さ・簡単さは満点、セキュリティについては少なくとも鍵の保管場所という意味では十分な強度を手に入れていることです。

しかしながら、下のサイトについては上のようにオンチェーンでのES256/P-256署名検証はされていません(トランザクション例)。何故かと言うと下のサイトはEthereum Sepoliaテストネットで動いており、そこではRIP-7212は利用できず、オンチェーンでの検証はコスト大幅高に繋がるためです。このプロポーザルは元々EIP-7212、つまりEthereumを含む殆ど全てのEVMチェーンにて利用できることを想定して提案されたようですが、途中でL1に比べ変更が容易であるRollupチェーンでの利用を目指すRIPに移行したようです。

• secp256k1(Ethereum標準)の署名からアドレスを復元するコストは3,000gas以下程度

• RIP-7212 を用いたP-256( secp256r1 )のそれは数千~数万 gas程度

• secp256r1 の検証をSolidityで実装した場合: 数百万gas程度

  • Daimoプロジェクトによる実装が33万gasを達成したとされたが長い間更新されていない……?

RIP-7212 もしくは他のなんらかの手段(例えばオフチェーンでの検証 + ZKなど……?)で安価な検証ができたとすると、指紋認証だけで、webブラウザ上でウォレットを作成してその後も認証・署名できます。

他の小さな問題を解決するためにinline frame ( <iframe> )あたりが多用されていくかと思います。これは新しい仕組みでもなんでもなく、Google AdsenseのバナーやX(Twitter)のポストを表示したりするのに使われている、他のドメインのHTMLを埋め込むためのものです。これが何故有効かというと、WebAuthnをユーザの認証に使うにあたりサービスが利用するID(Relying Party ID, RP ID)はサービスのホスト名(e.g. app.uniswap.org)を利用する決まりになっており、サービスをまたいで(e.g.someapp.com anotherapp.com 間で)同じ鍵、ひいては同じウォレットの認証をすることに支障が出てしまうためです。そこで、iframeによるウォレットの仕組みを提供しているドメインのHTMLを埋め込むことで、サービス間で同じウォレットを利用することができるでしょう。 勿論、逆にあるサービスは別のコントラクトウォレット実装を使う必要があることを理由として、iframeを使わず自分たちのドメインによるWebAuthn認証を好むかもしれません。テクニカルな知識を持たないユーザにどう危ないサイトを警告するのか、危ないサイトが作られることを防止するのか(例としては、ウォレット提供側はサービスのドメインをホワイトリスト制にしたり)というセキュリティ上の課題はあるものの、便利なUXを提供する手段が増えたのは単純に良いことかと思います。

まだ情報がかなり少ないですが、Portoなどはこの記事に挙げた仕組みの多くを活用していくような記述が見られます。

このように、他のいくつかのEIP, RIPやPasskeyなどのWebの先進技術と組み合わせることで、EIP-7702は非常に多くのユーザに対しウォレットUXの改善をもたらし得ると感じました。コストの関係でまずはL2での利用が目立つかも知れませんが、L1も追いついていくでしょう。楽しみですね！

Who I am

• Crypto、特にEthereum界隈に2018年ぐらいからいる。はじめて参加したDevconは大阪。Bitcoinを持ち始めたのは2017年1月

• Startbahnという会社のCTOをやっており、5年ほど前からマスに向けたweb3サービスを提供している

• Azuki owner(#439)

• そこそこ色んなdAppsを触ってきましたがDeFiをめちゃくちゃやる方ではない

Wallets that we used

使ってきたEthereumウォレットは

• MetaMask

• Brave Wallet

• Phantom

• Bitget Wallet

• Binance Wallet

とCrypto分かる人の中ではおそらく極めて普通。開発しているプロダクト内では、Crypto全然分からない人向けにはWeb3Auth(旧Torus)を用いて、EmailやGoogleログインなどで秘密鍵を取得し認証する仕組みを採用してきました。余談ですが、弊社プロダクトの2020年リリース当時、

• 一般の人が使えて

  • GoogleなどのOAuth認証を含む

• Custodialではなく(鍵全体に対するアクセスをサービス提供者が持たない)

• dAppsにConnect Walletできる(e.g. 決まったトランザクションだけではなく任意のメッセージに署名できる)

ウォレットに選択肢は殆どありませんでした。今ではPrivyなどの採用を多く見かけますね。

Ambire Wallet

ここから本題に入っていきますが、最近推しのウォレットができました。2024年秋のDevcon Bangkokの前から目をつけていて中の人とも話して気にはなっていたAmbire Walletです。モバイルアプリも提供されていますが、今v1からv2への移行期ということで、先にv2が採用されているChrome Extentionだけを今は利用しています。もし招待コードが必要でしたら、 cb81584f8cc8 を利用していただけたら幸いです。

Account Abstraction(ERC-4337)ウォレットでのTXが非常に見やすいです。

ERC-20トークンである $USDC のApprovalと, $WALLET とのSwapが一つのトランザクション内で行われたことがよく分かります。

Gas Tankという機能を使って、一つのチェーンに $USDC などをガス代用にdepositしておくことで、このウォレットからの(基本的に)あらゆるチェーンでのあらゆるトランザクションの手数料をそこから支払うこともできます。 Particleが少し前からGas Abstractionと言っていましたが、一般的な機能になってきましたね、素晴らしい。

ちなみに、このウォレットのインタフェース上でのSwapは現時点で0.25%の手数料が取られます。僕はこのウォレットを推しますが、利用は自己責任でお願いいたします🙏

Execute AA transaction and connect the wallet

このウォレットを使ってdApps、例としてNFTマーケットプレイスであるMagic EdenにConnectしてみましょう。

普通のEthereumウォレット(EOA, Externally Owned Address)と同様に決まった書式のメッセージに署名を求められます。ウォレットアイコンの左上にある SA はERC-4337を利用した Smart Account を意味します。

また、既にEtherScan(や同系列のBaseScanなど)も既にこれらのトランザクションを非常に上手く表示する機能を搭載してくれています。是非Ambireで一つトランザクションを実行してexplorerで確認してみてください。

EIPs/ERCs

関連するEIP/ERCについても考えていきましょう。

• 4337

• 1271

  • 6492

• 7702

ERC-4337は、Account Abstractionを利用したウォレットインタフェースの中で、おそらく一番利用されているものです。ユーザは生のトランザクションではなく、UserOperation というオブジェクトに署名をして、 Bundler という役割を行っている相手(ノード)にそれを投げます。この一つの UserOperation は複数のコントラクト実行、例えば上の例で言うと

1. $USDCコントラクトの Approve をするための関数

2. DEXコントラクトのSwap用の関数

の実行を含んでいて、これらはEOAの世界では2つのトランザクションに別々に署名が必要でガス代も多めにかかっていたところが、1つになっています。

ERC-1271は、どうコントラクトウォレットの署名を検証するのかを規定しています。おそらく上でSwapのトランザクションにおいても、Magic EdenへのConnectにおいても、該当ウォレットのisValidSignature関数を実行することで認証しています。これはEOAにおける、dAppsバックエンドがsecp256k1 ECDSA署名から ecrecover アルゴリズムを利用して署名元のEthereumアドレスを復元し、署名したと言っているアドレスと一致するかを検証することで認証していたものなどを代替するものです。

ERC-6492はそれを補完するものです。Contract Walletを含むコントラクトのデプロイにはコストがかかるため、オンチェーンでそのウォレットがトランザクションを実行するまではデプロイを控えたい。しかしERC-1271は既にそのネットワークにデプロイされているコントラクトに対してしか実行できないという弱点を、そのデプロイや検証のバイトコードをオフチェーンでも実行する仕組みを提供することで補完しています。結構前ですが、それを使った認証を実装したコードも書いてみた( web server contracts がそれぞれフロントエンド, バックエンド, コントラクトに対応しています)ので気になる方は参照してみてください。

EIP-7702は、比較的新しいもので、今ちょうどEthereum L1ではテストネットにはリリース済み、メインネットには近々リリースされるPectra(execution layerへのPragueリリースとconsensus layerへのElectraリリースの総称)に含まれています。他のEVM L1やL2も対応を複数発表しています。表題は Smarter EOA で、ERC-4337を代表としたAccount Abstractionを含むContract Walletの考えは素晴らしく、また長期的には全面的に採用されていくべきもの。しかし現在ユーザはEOAに慣れきっているため、橋渡しをしていく意味で短中期的にユーザはあくまでEOAを使っているがContract Walletの機能を享受できるようにしよう、というものです。技術的な詳細はこの動画が分かりやすいです。こちらについてもHello World的なコードを書いてみたので気になる方はどうぞ。かいつまんで言うと、Pectra以降、各EOAにはコード( code )をセットすることができるようになり、Contract Walletをアドレスや鍵を変えずに利用することができます。セットできるコードは1つです。以下はEIP-7702を享受している、つまり code がセットされているEOAが、トランザクションのFromにもToにも使われうることを示します。前者は今まで通りそのEOAの鍵を利用してトランザクションを発行した場合、後者は code を他のEthereum Address(EOAかもしれないしコントラクトかもしれない)が実行した場合です。EIP-7702以前は、(ネイティブ通貨(e.g. $ETH )のtransferを除き)EOAは常に署名をする側、つまりFromでしかあり得ませんでした。

(Explorerはローカルで動作するOtterscanを利用しています👏)

上の例で、Block 5の時点で既に0x709… は 0xf39… に一定の権限を付与されているため、その権限に基づきトランザクションを実行しています。 0xf39… がERC-4337のウォレットで、 0x709… が UserOperation に署名するEOAという図式を代替したと言っていいでしょう。一方で、 0xf39… の秘密鍵は依然としてフルの権限を持っているため、Block 6において別のトランザクションを実行しています。これが、このEIPがEOAとContract Walletの世界の橋渡しをする Smarter EOA の中身です。

So, who should use what now?

さて、では我々Crypto慣れている勢と、Crypto何も分からない勢はどのウォレットを使うべきなのでしょうか。

比較的簡単なのは前者です。既にMetaMaskに代表されるEOAウォレットを使って色んなアプリを利用しているでしょうから、徐々にAmbireやParticleなどのERC-4337対応のウォレットに移行していけばいいでしょう。上でMagic EdenへのConnectを紹介しましたが、本記事執筆時点でAmbire Walletを利用した、Ledgerデバイスで署名するERC-4337アカウントではMagic Eden, Uniswap, OpenSeaにはConnectできましたが、記事が書かれているMirrorにはConnectできませんでした。初期に比べて格段にサポートが良くなっていて、実用し始めるには十分と思いますが、まだ全てのアプリで使う準備ができているとは言えないでしょう。また、既に利用しているEOAのトランザクション履歴を大事にしたい場合には、そのEOAに好きな code をセットして、EIP-7702ウォレットとして利用していくのも有力な選択肢と言えます。

後者については個人的にはいまだに凄く良い解がありません。EIP-7702の開発者はこのユーザ群のbootstrapを一つの目的として掲げています。実際にこのユーザ群にとって良い選択肢である一方で、無知なユーザに必要以上の権限委譲をさせてしまう危険性を孕んでいると感じました。ウォレットやdAppの提供者は、ユーザのEOAに「この code をセットしませんか」と促すことができます。その code はユーザが理解していない副作用を持つかもしれません。また、セットできる code は一つなので、ウォレット提供者はともかくdAppがそれをセットするのは、他のdAppも違う code をセットさせたいのではないか? その code にユーザが乗り換えようとしたとき、最初の code とデータに互換性はあるのか? などを考えると、対象ユーザ群のリテラシが低いことを認識しているからこそ気が引けます。これらの理由から、このEIPを利用した素晴らしいユースケースは出てくることが期待できる反面、良からぬ事故が起きてしまうことも想定されるし、dapp開発者として利用することを躊躇してしまう場面もあります。結局のところ、よりTrustfulだがメールが使えれば使えるPrivyのような選択肢のほうが期待値的に良いUXを与えるのが現状という気がします。

以上です。お読みくださりありがとうございました。質問があればいつでもTwitterなどでくださればと思います。また、より詳しい方や似た悩みをお持ちの人がいれば是非話させてください！