「Account Abstraction」タグの記事が 5 件 件あります

AllScale.ioは、新興市場のフリーランサーや中小企業を対象とした、トークンプロジェクトではない、正当なベンチャー支援を受けたステーブルコイン決済プラットフォームです。 2025年2月に設立され、YZi Labs、Draper Dragon、KuCoin Venturesなどの評判の高い暗号VCから650万ドルの支援を受けている同社は、Kraken、Capital One、Blockでの検証可能な経験を持つ身元が公開されたチームと、香港のCyberportインキュベーターからの機関投資家による支援という好ましい兆候を示しています。しかし、公開セキュリティ監査の欠如とプラットフォームの極端な若さ（設立1年未満）は、本格的な利用の前に慎重なデューデリジェンスを必要とします。

AllScaleの機能と解決する問題​

AllScaleは、従来の国際決済に苦しむ6億以上の世界の小規模事業者（フリーランサー、コンテンツクリエイター、中小企業、リモートコントラクター）向けに特別に設計された「世界初のセルフカストディ型ステーブルコインネオバンク」と位置付けています。根本的な問題は、国際フリーランサーが銀行口座の障壁、高額な電信送金手数料、通貨換算損失、そしてしばしば5営業日を超える決済遅延に直面することです。

このプラットフォームにより、企業は請求書を作成し、クライアントがどのように支払うか（クレジットカード、電信送金、または暗号資産）に関わらずUSDTまたはUSDCで支払いを受け取り、非カストディアルウォレットを通じて即座に資金にアクセスできます。主要な製品には、AllScale Invoice（2025年9月から稼働）、AllScale Pay（Telegram、WhatsApp、Lineを介したソーシャルコマース）、AllScale Payroll（国際コントラクター支払い）があります。同社は「見えない暗号資産」を強調しており、クライアントはブロックチェーンレールを使用していることを知らなくても、マーチャントはステーブルコインを受け取ることができます。

現在の開発段階: このプラットフォームは公開ベータ版であり、BNB Chainメインネットで動作する製品が稼働中です。ユーザーはdashboard.allscale.ioでダッシュボードにアクセスできますが、ウェイティングリストが適用される場合があります。

技術アーキテクチャはBNB Chainとアカウントアブストラクションに依存​

AllScaleは独自のチェーンを運用するのではなく、既存のブロックチェーンインフラストラクチャ上に構築されています。主要な技術スタックは以下の通りです。

パスキーベースのアプローチは、悪名高いシードフレーズ管理のUX摩擦を排除し、主流の採用への障壁を低くします。マルチチェーンペイマスターのスポンサーシップアーキテクチャが、舞台裏でトランザクションコストを処理します。

不足している点: AllScaleは公開GitHubリポジトリを一切持っていません—インフラストラクチャは独自のクローズドソースです。スマートコントラクトアドレスは公開されておらず、公開APIやSDKも利用できません。また、docs.allscale.ioの技術ドキュメントは、アーキテクチャ仕様ではなくユーザーガイドに焦点を当てています。この不透明性は、彼らの主張の独立した技術的検証を妨げます。

ネイティブトークンなし—プラットフォームはUSDTとUSDCを使用​

AllScaleはネイティブな暗号通貨トークンを持っていません。これは多くのWeb3プロジェクトとの決定的な違いです。ICO、IDO、トークンセール、投機的な資産は一切関与していません。同社は、エクイティ資金調達を行う従来のデラウェア州C法人として運営されています。

このプラットフォームは、主にUSDTとUSDCというサードパーティのステーブルコインを決済媒体として使用します。ユーザーはステーブルコインで支払いを受け取り、法定通貨またはカード支払いからの自動変換が行われます。BNB Chainとの統合により、USD1（Binance関連のステーブルコイン）へのアクセスも提供されます。

収益モデル（推定、非公開）:

• 請求書/決済処理の手数料
• 法定通貨からステーブルコインへの交換における為替スプレッド
• B2B給与管理サービス
• オン/オフランプ統合手数料

トークンの不在は、特定のリスク（投機的ボラティリティ、トークノミクス操作、規制上の証券に関する懸念）を排除しますが、エクイティ参加以外の投資家にとってトークンベースのエクスポージャーがないことも意味します。

身元が公開され、経歴が検証可能な4人の創業者​

AllScaleのチームは高い透明性を示しており、すべての創業者は検証可能な職務経歴とともに公に特定されています。

Shawn Pang（CEO兼共同創業者）: ウェスタン大学でコンピューターサイエンスとビジネスを専攻。Capital Oneで決済詐欺の元プロダクトマネージャー。TikTokカナダ初のPM。AI製品向けグロースマーケティングエージェンシーHashMatrixを共同設立。

Ruoyang "Leo" Wang（COO兼共同創業者）: トロント大学でコンピューター工学を専攻。PingCAP（分散データベース）、IBM、AMD、Scotiabankでの経歴。CP Clickmeでのスタートアップ経験あり。

Jun Li & Khalil Lin（共同創業者）: 法務/コンプライアンスの専門知識を持つ追加の共同創業者で、OKXでの経歴も報じられています。LinkedInプロフィールが利用可能です。

Avrilyn Li（創業プロダクトマネージャー）: Ivey Business School出身のAI-to-Web3起業家で、給与製品を主導。

チームは、Binance、OKX、Kraken、Block（Square）、Amazon、Dell、HPでの集合的な経験を主張しています。チームの総人数は約7〜11名です。

資金調達と投資家​

注目すべき参加投資家には、KuCoin Ventures、Oak Grove Ventures、BlockBooster、Aptos、GSR Ventures、V3V Venturesが含まれます。エンジェル投資家にはGracy ChenとJedi Luがいます。同社は、政府支援のテクノロジーアクセラレーターである香港サイバーポートインキュベーションプログラムのメンバーです。

主要なセキュリティ懸念: 公開監査やバグバウンティプログラムなし​

これは調査における最も重要な危険信号です。 スマートコントラクトウォレットを通じてユーザー資金を扱っているにもかかわらず、以下の点が挙げられます。

• 認識されている企業（CertiK、Hacken、Trail of Bits、OpenZeppelin、SlowMist）による公開スマートコントラクト監査なし
• CertiK Skynetや類似のセキュリティデータベースに掲載なし
• Immunefi、HackerOne、Bugcrowdでのバグバウンティプログラムなし
• 保険または補償メカニズムの開示なし
• 公開されているセキュリティ開示ポリシーなし

AllScaleは、セルフカストディアーキテクチャ、自動化されたKYC/KYB/KYTコンプライアンス、パスキー用のハードウェアセキュリティモジュール（HSM）統合、2FAサポートなどのセキュリティ機能を主張しています。セルフカストディモデルはプラットフォームのカウンターパーティリスクを軽減します—もしAllScaleが侵害された場合でも、ユーザー自身のウォレットにある資金は、理論的にはカストディアルサービスにあるよりも安全であると言えます。

良い点として: AllScaleに関するセキュリティインシデント、ハッキング、またはエクスプロイトは報告されていません。しかし、プラットフォームの若さを考慮すると、このインシデントの欠如は、堅牢なセキュリティではなく、単に限定された露出を反映しているに過ぎない可能性があります。

競合環境と市場での位置付け​

AllScaleは、急速に進化するステーブルコイン決済分野で競合しています。

AllScaleの差別化要因:

• セルフカストディモデル（ユーザーが資金を管理）
• シードフレーズのUXを排除するパスキー認証
• アカウントアブストラクションによるガス代ゼロ
• 新興市場への注力（アフリカ、ラテンアメリカ、東南アジア）
• エンタープライズ向けとは異なり、「ラストマイル」の中小企業をターゲット

デメリット: 極端な若さ、小規模なチーム、限られた実績、確立された流通チャネルを持つ潤沢な資金を持つ既存企業との競合。

コミュニティの存在感は初期段階でB2B志向​

AllScaleは標準的なWeb3ソーシャルチャネルを維持しています。

• X (Twitter): @allscaleio（2025年4月から活動）
• Telegram: AllScaleHQコミュニティグループ
• Discord: コミュニティIDが公開されているアクティブなサーバー
• LinkedIn: AllScale Inc企業ページ
• ニュースレター: Substackの「The Stablecoin Scoop」

コミュニティは初期段階であり、主にAMAセッション、X Spaces、パートナーシップ発表を通じてエンゲージメントが行われています。AllScaleは、HashKey GroupおよびAmber Groupと共同で、香港でScale Stablecoin Summit（2025年6月）を開催しました。

従来のDeFi指標は適用されない: AllScaleは決済プラットフォームであり、DeFiプロトコルではないため、TVL（Total Value Locked、預かり資産総額）の指標は適用されません。このプラットフォームはDeFiLlamaやDune Analyticsには掲載されていません。ユーザー数と定着率の指標は投資家によって言及されていますが、公開されていません。

注目すべきパートナーシップには、BNB Chain（公式エコシステムパートナー）、Skill Afrika（アフリカのフリーランサーコミュニティ）、Ethscriptions（L1永続性）、Asseto（イールド製品向けRWAトークン化）が含まれます。

リスク評価: 中程度のリスクを持つ初期段階のベンチャー​

ポジティブな正当性を示す兆候​

• 身元が公開され、検証可能な職務経歴を持つチーム
• 評判の高い暗号VC（YZi Labs、Draper Dragon、Amber Group、KuCoin Ventures）
• 香港サイバーポートからの機関投資家による支援
• デラウェア州C法人としての法的構造
• BNB Chainメインネットで稼働中の製品
• 詐欺の申し立て、BBBの苦情、コミュニティの警告は見つからず
• 匿名チームに関する懸念なし
• 非現実的な利回り約束やトークン投機なし
• コンプライアンスを重視したポジショニング（GENIUS法、香港ステーブルコイン条例）

注意が必要な点​

• 極端な若さ: 2025年2月設立、1年未満
• 資金を扱っているにもかかわらず公開セキュリティ監査なし
• バグバウンティプログラムなし
• 独立したユーザーレビューやコミュニティフィードバックなし
• クローズドソースのインフラストラクチャ—主張を独立して検証できない
• 報道は主にプレスリリースの配信であり、独立したジャーナリズムではない
• 中央集権化のリスク: 企業運営のプラットフォーム、BNB Chainへの依存
• 野心的なグローバル展開を実行する小規模なチーム（約7〜11名）

見つからなかった点（不在による潜在的なイエローフラッグ）​

• ユーザー指標の公開なし
• 収益額の公開なし
• 正式な諮問委員会なし
• 特定の規制ライセンスなし（香港のフレームワークはまだ発効していない）

最近の動向とロードマップ​

最近のマイルストーン（2025年）​

• 12月8日: 500万ドルのシードラウンドを発表（YZi Labsが主導）
• 11月: AllScale PayがBNB Chainで稼働。Skill Afrikaとの提携
• 10月: L1永続性のためのEthscriptionsとの提携
• 9月: AllScale Invoice製品のローンチ
• 8月: USD1サポートを含むBNB Chain統合
• 6月: Scale Stablecoin Summit Hong Kong開催。150万ドルのプレシード資金調達

今後の予定​

• 2026年第1四半期: ラテンアメリカ市場への拡大
• 将来: DeFiイールドオプション、クロスチェーン機能の拡張、B2Bエンタープライズソリューション

結論​

AllScale.ioは、詐欺の懸念ではなく、信頼できる投資家と透明性があり検証可能なチームに支えられた正当な初期段階のスタートアップとして登場しました。このプロジェクトは、新興市場のフリーランサーにとっての国際決済の摩擦という現実の市場問題を、アカウントアブストラクションとステーブルコインを活用した思慮深い技術アプローチで解決しようとしています。

しかし、本格的な利用の前に2つの重要な欠点に注意が必要です。それは、公開セキュリティ監査の完全な欠如と、独立した検証を妨げるクローズドソースのインフラストラクチャです。ユーザー資金を扱うプラットフォームにとって、これらの欠落はチームの資格に関わらず重大な懸念事項です。

全体的なリスク評価: 中程度。 このベンチャーは強い正当性を示す兆候がありますが、初期段階に固有のリスクを伴います。潜在的なユーザーは、セキュリティ監査が公開されるまで少額から始めるべきです。潜在的なパートナーは、技術仕様書と監査レポートへの直接アクセスを要求すべきです。このプロジェクトは、特に2026年第1四半期のセキュリティ監査発表に注目し、成熟するにつれて監視する価値があります。

ユーザーがネイティブトークン（SUI）を保持せずに dApp とシームレスにやり取りできる世界を想像してください。これはもはや遠い夢ではありません。Sui の Gas Station（Paymaster とも呼ばれる）を利用すれば、開発者がユーザーに代わってガス代を負担でき、Web3 への新規参入障壁を大幅に下げ、真に摩擦のないオンチェーン体験を実現できます。

本記事では、dApp をガスレス化するための完全ガイドを提供します。Sui Paymaster のコア概念、アーキテクチャ、実装パターン、ベストプラクティスを徹底解説します。

1. 背景とコアコンセプト：スポンサー付きトランザクションとは？​

ブロックチェーンの世界では、すべてのトランザクションにネットワーク手数料（「ガス」）が必要です。Web2 のシームレスな体験に慣れたユーザーにとって、これは大きな認知的・操作的ハードルとなります。Sui はこの課題に対し、プロトコルレベルで スポンサー付きトランザクション を提供しています。

基本的な考え方はシンプルです。ある当事者（スポンサー）が別の当事者（ユーザー）のトランザクションに対して SUI ガス代を支払うことを許可します。これにより、ユーザーのウォレットに SUI がゼロでもオンチェーンアクションを実行できます。

Paymaster ≈ Gas Station​

Sui エコシステムでは、スポンサー付きトランザクションのロジックは通常、オフチェーンまたはオンチェーンのサービス Gas Station（または Paymaster）が担います。その主な責務は以下の通りです。

1. トランザクションの評価：ユーザーから送られたガスレストランザクションデータ（GasLessTransactionData）を受け取ります。
2. ガスの提供：必要なガス代をロックし、割り当てます。これは多数の SUI Coin オブジェクトで構成されたガスプールで管理されます。
3. スポンサー署名の生成：スポンサーシップを承認した後、Gas Station はプライベートキーでトランザクションに署名（SponsorSig）し、支払い意思を証明します。
4. 署名済みトランザクションの返却：ガス情報とスポンサー署名が付加された TransactionData を返し、ユーザーの最終署名を待ちます。

要するに、Gas Station は dApp ユーザーの「車」（トランザクション）に燃料を供給するリフューリングサービスです。

2. ハイレベルアーキテクチャとインタラクションフロー​

典型的なガスレス取引は、ユーザー、dApp フロントエンド、Gas Station、Sui フルノードの 4 つが協調して動作します。シーケンスは以下の通りです。

フローの分解

1. ユーザー が dApp UI 上でアクションを起こし、ガス情報なしのトランザクションデータを生成します。
2. dApp がこのデータを指定された Gas Station に送信し、スポンサーシップを依頼します。
3. Gas Station がリクエストの妥当性（例：ユーザーがスポンサー対象か）を検証し、ガスコインと署名を付与した半完成トランザクションを dApp に返します。
4. ユーザー はウォレット上で最終取引内容（例：「NFT を 1 枚購入」）を確認し、最終署名を行います。これにより、ユーザーは自らの意思とコントロールを保持します。
5. dApp はユーザー署名とスポンサー署名の両方が入った完全トランザクションを Sui フルノード に送信します。
6. トランザクションがオンチェーンで確定した後、Gas Station はイベントやレシートを監視し、必要に応じて Webhook で dApp に成功を通知できます。

3. 3 つのコアインタラクションモデル​

ビジネス要件に合わせて、以下の 3 つのモデルを単独または組み合わせて利用できます。

モデル 1：ユーザー発起 → スポンサー承認（最も一般的）​

標準的なモデルで、ほとんどの dApp インタラクションに適しています。

1. ユーザーが GasLessTransactionData を構築：dApp 内でアクションを実行。
2. スポンサーが GasData を付与し署名：dApp バックエンドが Gas Station に送信し、ガスコインとスポンサー署名を取得。
3. ユーザーが最終署名：ウォレットで取引内容を確認し署名。dApp がネットワークに送信。

セキュリティとユーザー体験のバランスが最適です。

モデル 2：スポンサー発起のエアドロップ／インセンティブ​

エアドロップや報酬付与、バッチ配布に最適です。

1. スポンサーが TransactionData を事前に作成し署名：プロジェクト側が取引（例：NFT エアドロップ）を組み立て、スポンサー署名を付与。
2. ユーザーの二重署名で実行：ユーザーは「事前承認済み」取引に対して 1 回だけ署名すれば完了。

クリック一つで報酬受取やタスク完了が可能になり、コンバージョン率が大幅に向上します。

モデル 3：ワイルドカード GasData（クレジットラインモデル）​

柔軟かつ許可ベースのモデルです。

1. スポンサーが GasData オブジェクトを転送：予算上限と有効期間を設定したガスコインをユーザーに直接所有権移転。
2. ユーザーは予算内で自由に使用：ユーザーはこのガスコインで任意の取引を支払える。
3. ガスコインの回収：残高がなくなるか期限切れになると、自動的に破棄またはスポンサーへ返却できるよう設計。

実質的に「ガス手数料クレジットカード」をユーザーに提供するイメージで、ゲームシーズン中のフリープレイ体験などに最適です。

4. 典型的な活用シナリオ​

Sui Paymaster の価値はガス代問題の解決だけでなく、ビジネスロジックと深く統合できる点にあります。

シナリオ 1：ペイウォール​

コンテンツプラットフォームや dApp サービスで、特定条件（例：VIP NFT 保有、会員レベル）を満たすユーザーのみ機能を提供したい場合。

• フロー：ユーザーがアクション要求 → dApp バックエンドが資格（NFT 所有等）を検証 → 条件合致なら Paymaster がガス代をスポンサー、合致しなければ署名リクエストを拒否。
• メリット：バックエンドで資格判定を行うため、ボットや不正利用に強い。スポンサー資金が無駄に消費されるリスクが低減。

シナリオ 2：ワンクリック決済​

e コマースやゲーム内購入で、決済プロセスを極限まで簡素化したい場合。

• フロー：ユーザーが「今すぐ購入」ボタンをクリック → dApp が transfer_nft_to_user 等のビジネスロジックを組み込んだトランザクションを生成 → ユーザーはビジネスロジックに対して署名するだけで、ガス代はスポンサーが負担。
• メリット：order_id などのビジネスパラメータを ProgrammableTransactionBlock に直接埋め込めるため、オンチェーン上で正確な注文紐付けが可能。

シナリオ 3：データアトリビューション​

ビジネス最適化に不可欠な正確なデータトラッキング。

• フロー：トランザクション生成時に一意の識別子（例：order_hash）をパラメータやイベントに書き込む。
• メリット：Gas Station が成功レシートを取得した際に、イベントやトランザクションデータから order_hash を抽出でき、オンチェーン状態変化とバックエンド注文を正確に紐付けられる。

5. コードスケルトン（Rust SDK ベース）​

以下はコアインタラクションを示す簡易コード例です。

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

完全な実装例は、公式 Sui ドキュメントの Gas Station Tutorial を参照してください。

6. リスクと保護策​

強力な機能である一方、プロダクション環境で Gas Station を運用する際は以下のリスクに注意が必要です。

• 二重支払い（Equivocation）：悪意あるユーザーが同一の Gas Coin を並行して複数トランザクションに使用しようとすると、Sui ネットワークでコインがロックされます。対策としては、ユーザーまたはトランザクションごとに一意の Gas Coin を割り当て、ブラックリストやレートリミットで署名リクエストを制御します。
• ガスプール管理：高並列環境では、単一の大口 SUI Coin がボトルネックになる可能性があります。Gas Station は大口コインを自動的に多数の小口コインに分割し、使用後に再集約できる仕組みが必須です。Shinami などのプロバイダーは成熟したマネージドサービスを提供しています。
• 認可とレートリミティング：厳格な認可ポリシーとレートリミットを設定し、IP、ウォレットアドレス、API トークン単位でスポンサーシップの上限や頻度を管理しないと、サービスが枯渇する危険があります。

7. エコシステムツール​

Sui エコシステムは Paymaster 開発・デプロイを支援するツールが豊富です。

• 公式 SDK（Rust / TypeScript）：sponsor_transaction_block() などの高レベル API が用意されており、統合コストを大幅に削減。
• Shinami Gas Station：ガスコインの自動分割・回収、メトリクス監視、Webhook 通知を含むフルマネージドサービスで、ビジネスロジックに集中できます。
• Enoki / Mysten デモ：コミュニティや Mysten Labs が提供するオープンソース実装が多数あり、独自サービス構築時のリファレンスとして活用可能。

8. 実装チェックリスト​

ガスレス時代への dApp アップグレードを始める前に、以下の項目を必ず確認してください。

• 資金フローの設計：スポンサー資金の出所、予算、補充戦略を定義し、ガスプール残高や消費レートの監視アラートを設定。
• アトリビューションフィールドの確保：取引パラメータに order_id や user_id などビジネス識別子用のフィールドを予約。
• 不正防止ポリシーの導入：認可、レートリミット、ロギングを本番前に実装。
• テストネットでのリハーサル：独自サービスでもサードパーティ Gas Station でも、テストネット／デブネットで同時実行・負荷テストを徹底。
• 継続的最適化：ローンチ後は成功率、失敗要因、ガスコストを定期的に分析し、予算や戦略をチューニング。

結論​

Sui Paymaster（Gas Station）は、単なるガス代負担ツールを超えたパラダイムです。「SUI を持たない」ユーザー体験と「取引単位でのオンチェーンアトリビューション」を同時に実現でき、開発者はビジネスロジックに専念できます。この記事で紹介した概念・アーキテクチャ・実装パターンを活用し、次世代のシームレスな dApp を構築しましょう。

ウォレットの摩擦を解消し、ユーザーの流入を維持し、成長の可能性を予測する方法

Web3 アプリが現代の Web2 サービスと同じようにシームレスなサインアップフローを持っていたらどうでしょうか？それが Sui ブロックチェーンにおける zkLogin の核となる約束です。これは Sui のための OAuth のように機能し、ユーザーは Google 、 Apple 、 X などの使い慣れたアカウントでサインインできます。その後、ゼロ知識証明（ZKP）によって、その Web2 の ID がオンチェーンの Sui アドレスに安全に紐付けられます。ウォレットのポップアップ、シードフレーズ、ユーザーの離脱はもうありません。

その影響は現実的かつ即座に現れます。すでに数十万の zkLogin アカウントが稼働しており、ケーススタディでは、従来のウォレットの障壁を取り除いた後、ユーザーのコンバージョン率がわずか 17% から 42% へと大幅に向上したことが報告されています。これがどのように機能し、あなたのプロジェクトに何をもたらすのかを詳しく見ていきましょう。

なぜウォレットが初回コンバージョンを妨げるのか​

あなたは画期的な dApp を構築しましたが、ユーザー獲得のファネルからユーザーが流出しています。その原因のほとんどは常に同じ、「ウォレットを接続（Connect Wallet）」ボタンです。標準的な Web3 のオンボーディングは、拡張機能のインストール、シードフレーズの警告、そして暗号資産の専門用語のクイズといった迷路のようなものです。

これは初心者にとって非常に大きな障壁です。UX 研究者によると、ウォレットのプロンプトが表示された瞬間に 87% という驚異的な離脱 が観察されました。ある興味深い実験では、そのプロンプトをチェックアウトプロセスの後の段階に移動させるだけで、完了率が 94% に跳ね上がりました。暗号資産に興味があるユーザーでさえ、主な恐怖は「間違ったボタンをクリックすると資金を失うかもしれない」というものです。このたった一つの威圧的なステップを取り除くことが、飛躍的な成長を解き放つ鍵となります。

zkLogin の仕組み（わかりやすい解説）​

zkLogin は、すべてのインターネットユーザーがすでに信頼している技術を使用することで、ウォレットの問題をエレガントに回避します。その魔法は、舞台裏でいくつかの迅速なステップによって行われます：

1. 一時的なキーペア（Ephemeral Key Pair）: ユーザーがサインインしようとすると、ブラウザ内でローカルに一時的なシングルセッションキーペアが生成されます。これは、このセッションの間だけ有効な一時的なパスキーのようなものだと考えてください。
2. OAuth のプロセス: ユーザーは Google 、 Apple 、またはその他のソーシャルアカウントでサインインします。アプリはこのログインリクエストに、一意の値（ナンス / nonce）を巧みに埋め込みます。
3. ZKP サービス: ログインに成功すると、ZKP（ゼロ知識証明）サービスが暗号化された証明を生成します。この証明は、ユーザーの個人的な身元をオンチェーンで明かすことなく、「この OAuth トークンは一時的なパスキーの所有者を認証するものである」ことを確認します。
4. アドレスの導出: OAuth プロバイダーからのユーザーの JWT（JSON Web Token）と一意の ソルト（salt） を組み合わせて、永続的な Sui アドレスを決定論的に生成します。ソルトはクライアント側または安全なバックエンドで秘密に保持されます。
5. トランザクションの送信: アプリは一時的なキーでトランザクションに署名し、ZK 証明を添付します。Sui のバリデータはオンチェーンで証明を検証し、ユーザーが従来のウォレットを必要とすることなく、トランザクションの正当性を確認します。

ステップバイステップ導入ガイド​

準備はできましたか？ここでは TypeScript SDK を使用したクイックガイドを紹介します。原理は Rust や Python でも同じです。

1. SDK のインストール​

@mysten/sui パッケージには、必要なすべての zklogin ヘルパーが含まれています。

pnpm add @mysten/sui

2. キーとナンスの生成​

まず、一時的なキーペアと、Sui ネットワーク上の現在のエポック（epoch）に関連付けられたナンスを作成します。

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. OAuth へのリダイレクト​

使用しているプロバイダー（Google 、 Facebook 、 Apple など）に適した OAuth ログイン URL を構築し、ユーザーをリダイレクトします。

4. JWT のデコードとユーザーソルトの取得​

ユーザーがログインしてリダイレクトで戻ってきた後、URL から id_token を取得します。それを使用してバックエンドからユーザー固有のソルトを取得し、Sui アドレスを導出します。

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. ZK 証明のリクエスト​

JWT をプルーバー（prover）サービスに送信して ZK 証明を取得します。開発用には Mysten の公開プルーバーを使用できます。本番環境では、独自にホストするか、Enoki のようなサービスを使用する必要があります。

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. 署名と送信​

次に、トランザクションを構築し、送信者をユーザーの zkLogin アドレスに設定して実行します。SDK が zkLoginInputs（証明）の添付を自動的に処理します。 ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // 任意の Move 呼び出し
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // ここで魔法が起こります
});

7. セッションの維持​

よりスムーズなユーザー体験のために、キーペアとソルトを暗号化して IndexedDB やローカルストレージに保存します。セキュリティ向上のため、数エポックごとにこれらをローテーションすることを忘れないでください。

KPI 予測テンプレート​

zkLogin がもたらす違いは、単なる質的なものではなく、数値化できるものです。一般的なオンボーディング・ファネルと、zkLogin を活用したファネルを比較してみましょう。

👉 この数値が意味すること： 10,000 人のユニークビジターを誘導するキャンペーンにおいて、初日のオンチェーンアクションが 300 件にとどまるか、2,500 件を超えるかの違いになります。

ベストプラクティスと注意点​

さらにシームレスな体験を提供するために、以下のプロのヒントを参考にしてください。

• スポンサー付きトランザクション (Sponsored Transactions) を活用する： ユーザーの最初の数回のトランザクション手数料を肩代わりしましょう。これにより、あらゆる摩擦が取り除かれ、驚くほどスムーズな「アハ体験」を提供できます。
• ソルト (Salts) の扱いに注意する： ユーザーのソルトを変更すると、新しいアドレスが生成されます。信頼できるリカバリパスを管理している場合にのみ行ってください。
• Sui アドレスを表示する： サインアップ後、ユーザーにオンチェーンアドレスを表示しましょう。これにより、上級ユーザーが後で必要に応じて、従来のウォレットにアドレスをインポートできるようになります。
• リフレッシュループを防止する： JWT と一時的なキーペア (ephemeral keypair) を有効期限が切れるまでキャッシュし、ユーザーに繰り返しログインを求めないようにします。
• プルーバーのレイテンシを監視する： 証明生成 (proof-generation) の往復時間に注意してください。2 秒を超える場合は、レスポンスを速く保つために、リージョンごとのプルーバーのホスティングを検討してください。

BlockEden.xyz が提供する価値​

zkLogin はユーザー向けのフローを最適化しますが、それをスケールさせるにはバックエンドの新たな課題が生じます。そこで BlockEden.xyz の出番です。

• API レイヤー: 当社の高スループットで地理的にルーティングされた RPC ノードは、ユーザーの場所に関係なく、zkLogin トランザクションを最小限のレイテンシで処理することを保証します。
• オブザーバビリティ (観測可能性): 証明のレイテンシ、成功/失敗の比率、コンバージョンファネルの健全性などの主要な指標を追跡するための、標準搭載のダッシュボードを提供します。
• コンプライアンス: 法定通貨へのブリッジを行うアプリ向けに、オプションの KYC モジュールを提供しており、ユーザーの確認済み ID から直接コンプライアンスに準拠したオンランプ (入金) が可能です。

リリースの準備はいいですか？​

扱いにくく、威圧的なウォレットフローの時代は終わりました。zkLogin サンドボックスを立ち上げ、BlockEden のフルノードエンドポイントを接続して、ユーザーに「ウォレット」という言葉を一切意識させることなく、サインアップのグラフが右肩上がりに伸びていく様子を見守りましょう。 😉

長年、暗号業界は重大なユーザビリティ課題――ウォレット――に悩まされてきました。従来のウォレットは外部所有アカウント（EOA）と呼ばれ、非常に厳格です。シードフレーズを一度でも失うと資金は永遠に失われます。すべての操作には署名が必要で、ガス代はチェーンのネイティブトークンで支払わなければなりません。この扱いにくくハイリスクな体験が、主流への採用を阻んでいます。

そこで登場したのが アカウント抽象化（AA） です。これはブロックチェーンとのインタラクションを根本から変えるパラダイムシフトです。AA の本質は、ユーザーのアカウントをプログラム可能なスマートコントラクトに変換し、ソーシャルリカバリやワンクリック取引、柔軟なガス支払いといった機能を解放することです。

この賢い未来への旅路は、次の 3 つの異なる道で進行しています：実績のある ERC-4337、効率的な ネイティブ AA、そして期待の高い EIP-7702。それぞれのアプローチが開発者とユーザーにもたらす意味を見ていきましょう。

💡 パス 1： パイオニア — ERC-4337​

ERC-4337 は、コアプロトコルを変更せずに Ethereum および EVM 系チェーンにアカウント抽象化をもたらした画期的な技術です。既存システムの上にスマートレイヤーを追加したイメージです。

新しいトランザクションフローは次の要素で構成されます：

• UserOperations：ユーザーの「意図」(例： “100 USDC を ETH にスワップ”) を表す新しいオブジェクト。
• Bundlers：オフチェーンのアクターで、UserOperations を集めてバンドルし、ネットワークに送信します。
• EntryPoint：バンドルされた操作を検証・実行するグローバルスマートコントラクト。

メリット：

• ユニバーサル互換性：任意の EVM チェーンにデプロイ可能。
• 柔軟性：ゲーム向けセッションキー、マルチシグセキュリティ、Paymaster によるガススポンサーシップなど豊富な機能を実装可能。

トレードオフ：

• 複雑性とコスト：Bundler の運用が必要で、3 つのアプローチの中で最もガスコストが高くなります。すべての操作が追加の EntryPoint ロジックを通過するためです。そのため、採用はガスコストが低い L2（Base、Polygon など）で主に進んでいます。

ERC-4337 は他の AA ソリューションが走れる道を切り開き、需要を証明し、より直感的な Web3 体験の基盤を築きました。

🚀 パス 2： 統合された理想 — ネイティブ アカウント抽象化​

ERC-4337 がアドオンであるのに対し、ネイティブ AA はブロックチェーンの基盤そのものにスマート機能を組み込んでいます。zkSync Era や Starknet などは、設計段階から AA をコア原則として構築されています。これらのネットワークでは、すべてのアカウントがスマートコントラクトです。

メリット：

• 効率性：プロトコルに AA ロジックが組み込まれているため、余分なレイヤーがなく、ERC-4337 と比べてガスコストが大幅に低減。
• 開発者に優しい：Bundler や別個のメモプールを管理する必要がなく、トランザクションフローが標準的なものに近い。

トレードオフ：

• エコシステムの分散：ネイティブ AA はチェーン固有です。zkSync のアカウントは Starknet のものとは異なり、どちらも Ethereum メインネットのネイティブアカウントではありません。これにより、複数チェーンを横断するユーザーや開発者にとって体験が分断されます。

ネイティブ AA は効率性の「究極形」を示しますが、その採用はホストチェーンの成長に依存します。

🌉 パス 3： 実用的な橋渡し — EIP-7702​

Ethereum の 2025 年「Pectra」アップグレードに含まれる予定の EIP-7702 は、既存の EOA ユーザーに AA 機能を提供する画期的な提案です。ハイブリッドアプローチを採用し、EOA が 一時的にスマートコントラクトへ権限を委譲 できるようにします。

つまり、EOA に一時的なスーパーパワーを付与するイメージです。資金やアドレスを移行する必要はなく、トランザクションに認可情報を付加するだけで、バッチ処理（例：承認＋スワップをワンクリック）やガススポンサーシップが可能になります。

メリット：

• 下位互換性：既存の膨大な資金が保管された EOA と互換性があり、移行不要。
• 低複雑性：標準のトランザクションプールを使用するため、Bundler が不要でインフラが大幅に簡素化。
• 大衆採用の触媒：すべての Ethereum ユーザーが即座にスマート機能を利用できるため、UX 改善の波が急速に広がる可能性があります。

トレードオフ：

• 「完全な」AA ではない：EIP-7702 は EOA 自体の鍵管理問題を解決しません。秘密鍵を失えば資金は失われます。主に取引機能の拡張に焦点を当てています。

正面比較： 明確な対比​

未来は収束し、ユーザー中心になる​

この 3 つの道は相互排他的ではなく、ウォレットの摩擦をなくす未来へと収束しています。

1. ソーシャルリカバリが標準化 🛡️： “鍵を失う＝資金を失う” 時代は終わります。AA によりガーディアンベースのリカバリが可能となり、自己管理資産が従来の銀行口座と同等の安全性と寛容さを得ます。
2. ゲーム UX の再構築 🎮：セッションキーにより、毎回の “取引承認” ポップアップが不要になり、Web3 ゲームが Web2 と同等のスムーズさを実現します。
3. ウォレットはプログラム可能なプラットフォーム：ユーザーは “DeFi モジュール” や “セキュリティモジュール” を自由に追加でき、例えば自動イールドファーミングや大口送金時の 2FA などを実装可能です。

Blockeden.xyz のような開発者・インフラプロバイダーにとって、この進化は大きなチャンスです。Bundler、Paymaster、各種 AA 標準の複雑さは、堅牢で抽象化されたインフラを提供する余地を広げます。目指すは、開発者が AA 機能をシームレスに統合でき、ウォレットがチェーンに応じて ERC-4337、ネイティブ AA、または EIP-7702 を自動的に選択して利用できる統一体験です。

ウォレットはついに相応のアップグレードを迎えました。静的な EOA から動的でプログラム可能なスマートアカウントへの移行は、単なる改善ではなく、次の十億ユーザーにとって Web3 を安全かつアクセスしやすくする革命です。

こんにちは、ブロックチェーンブログへ再びようこそ！ 本日は、コンセンサス層のプロトコル変更を必要とせずにイーサリアムへアカウント抽象化を導入するエキサイティングな新提案「ERC-4337」について掘り下げます。この提案は上位レイヤーのインフラストラクチャに依存して目標を達成します。ERC-4337 が提供するもの、そして現在のイーサリアムエコシステムの制約にどのように対処するかを見ていきましょう。

ERC-4337 とは？​

ERC-4337 は、別個の mempool と「UserOperation」と呼ばれる新しい疑似トランザクションオブジェクトを使用してイーサリアムにアカウント抽象化を導入する提案です。ユーザーは UserOperation オブジェクトを代替 mempool に送信し、そこで「bundler」と呼ばれる特別なアクターがそれらをまとめてトランザクションにパッケージし、専用コントラクトへの handleOps 呼び出しを行います。このトランザクションはブロックに取り込まれます。

この提案の目的は以下の通りです：

1. 任意の検証ロジックを持つスマートコントラクトウォレットをプライマリアカウントとして使用できるようにする。
2. 外部所有アカウント（EOA）を完全に不要にする。
3. 任意の bundler がアカウント抽象化されたユーザー操作をブロックに含めるプロセスに参加できるようにし、分散性を確保する。
4. すべての活動を公開 mempool 上で行い、特定アクターの直接通信アドレスをユーザーが知る必要をなくす。
5. bundler に対する信頼前提を排除する。
6. イーサリアムのコンセンサス変更を不要とし、迅速な採用を可能にする。
7. プライバシー保護アプリケーション、アトミックなマルチオペレーション、ERC-20 トークンでのガス支払い、開発者スポンサー付きトランザクションなど、さまざまなユースケースをサポートする。

後方互換性​

ERC-4337 はコンセンサス層を変更しないため、イーサリアム自体の直接的な後方互換性問題はありません。ただし、ERC-4337 が導入される前のアカウントは validateUserOp 関数を持たないため、新システムと簡単に互換化できません。この課題は、検証ロジックをラッパーとして再実装し、元のアカウントの信頼できるオペレーション送信者として設定することで解決できます。

参考実装​

ERC-4337 の技術的詳細をさらに深く学びたい方は、以下のリポジトリをご参照ください。
https://github.com/eth-infinitism/account-abstraction/tree/main/contracts

セキュリティ上の考慮点​

ERC-4337 のエントリーポイントコントラクトは、システム全体の信頼の中枢となるため、徹底的な監査と形式的検証が必須です。このアプローチは個々のアカウントに対する監査負荷を軽減しますが、エントリーポイントコントラクトにセキュリティリスクが集中する点に注意が必要です。

検証すべき主な主張は次の二つです：

1. 任意のハイジャックに対する安全性：エントリーポイントは、対象アカウントの validateUserOp が合格した場合にのみ、そのアカウントを汎用的に呼び出します。
2. 手数料の流出に対する安全性：エントリーポイントが validateUserOp を呼び出し合格した場合、op.calldata と同一の calldata で汎用呼び出しを行う必要があります。

結論​

ERC-4337 はコンセンサス層のプロトコル変更を必要とせずにイーサリアムへアカウント抽象化を導入するエキサイティングな提案です。上位レイヤーのインフラストラクチャを活用することで、分散性・柔軟性・多様なユースケースの可能性が広がります。セキュリティ上の課題は残りますが、本提案はイーサリアムエコシステムとユーザー体験を大幅に向上させる潜在力を秘めています。