Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Building Signed Wallet Requests for the MyZubster Marketplace

2026年09月16日に「Dev.to」が公開したITニュース「Building Signed Wallet Requests for the MyZubster Marketplace」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

MyZubsterはEVMウォレットとオフチェーン署名でマーケットプレイスの依頼作成機能を実装した。これはブロックチェーン取引とは異なり、ガス代不要で支払いも発生しない。本人確認と意図の証明が目的で、リプレイ攻撃や条件変更に強く、各層の証拠を明確に分離する新しいアーキテクチャだ。

ITニュース解説

MyZubsterマーケットプレイスは、ユーザーが商品やサービスをリクエストする際の新しい仕組みとして、「署名付きウォレットリクエスト」を導入した。これは、イーサリアム仮想マシン(EVM)互換のウォレットと、ブロックチェーン上ではない場所で行われる暗号署名を利用するものだ。この新しい仕組みにより、ユーザーは自分のウォレットを使って安全にリクエストを作成できるようになった。

しかし、このリクエストにおける署名と、ブロックチェーン上で行われる一般的な取引とは明確な違いがある。この署名では、支払いは発生せず、ブロックチェーンの取引手数料であるガス代もかからない。また、単に売り手への連絡や出品のリクエストのためにブロックチェーン上に取引が送られることもない。このような設計は意図的なもので、それぞれの役割を明確に分離している。

これまでのマーケットプレイスでは、単にボタンをクリックするだけでは、誰がリクエストしたのか、どのような意図があったのかといった証拠が弱かった。MyZubsterでは、「誰がリクエストを作成したのか」「どのウォレットが署名したのか」「何をリクエストしたのか」「リクエスト時の経済条件はどうだったのか」「同じ承認が複数回使われていないか」「リクエスト内容が変更されていないか」といった疑問に答えられる、より強力な証拠が必要だった。同時に、すべてのマーケットプレイスでのやり取りをブロックチェーン上の取引にしたくなかった。そうすると、不必要なガス代が発生したり、ウォレット操作が煩雑になったり、ブロックチェーンの状態が複雑になったりするためだ。そのため、本人確認、意図の証明、支払い、そしてブロックチェーンに記録する証拠をそれぞれ独立した要素として扱うことにした。

新しいアーキテクチャは、まずユーザーがMyZubsterアカウントにEVMウォレットを接続するところから始まる。次に、MyZubsterはウォレットの所有者が本当にそのユーザー本人であることを確認するステップに進む。このウォレット所有権の確認は、「personal_sign」と呼ばれるウォレットの署名機能を使って行われる。MyZubsterは一時的な認証用の情報(チャレンジ)を生成し、ユーザーのウォレットにそれを署名してもらう。MyZubsterのシステムはこの署名を検証し、確認が取れたウォレットをユーザーのMyZubsterアカウントと紐付ける。ウォレットが接続された状態と、そのウォレットの所有者が確認された状態は異なるという点が重要だ。単にブラウザにウォレットアドレスが表示されているだけでは、そのウォレットをMyZubsterのユーザーが操作している証拠にはならないため、この検証は不可欠だ。

ウォレットの所有者確認が完了すると、ユーザーはマーケットプレイスの出品に対してリクエストを出せるようになる。ここで再び「personal_sign」による署名が使われるが、これは支払いを伴うブロックチェーン取引ではない。リクエストを送る前に、MyZubsterのサーバーはリクエスト内容をまとめた「正規のペイロード」を作成する。このペイロードには、出品の価格や通貨、取引モードといった経済的な条件の「スナップショット」が含まれる。ユーザーはこの内容を確認し、その条件に同意する意思表示として、自分のウォレットでメッセージに署名する。署名後、クライアント(ユーザーのブラウザ)はこの署名済みのリクエストをMyZubsterのサーバーに送信し、サーバーは署名を検証してから、リクエストを「リクエスト済み」の状態としてデータベースに記録する。この仕組みにより、ユーザーが確認し署名した経済条件と、実際にシステムが処理する条件が一致することが保証される。もし署名後に経済条件が変更された場合、リクエストは拒否され、ユーザーは新しい条件を確認して再度署名する必要がある。

また、一度署名されたリクエストが繰り返し使われることを防ぐための対策も講じられている。MyZubsterが発行するチャレンジ(署名対象のメッセージ)には有効期限があり、一度リクエストの承認に使われると再利用できないように「消費」される。これにより、過去の署名が不正に利用される「リプレイアタック」を防ぎ、各リクエストが唯一の承認によって行われることを保証する。

さらに、システム内部でのデータの整合性を保つための工夫もされている。リクエストの承認に使われたチャレンジを無効化する処理と、リクエスト自体をデータベースに登録する処理は、一体の「データベーストランザクション」として実行される。これにより、もし途中でシステムエラーが発生しても、チャレンジだけが無効化されてリクエストは作成されない、といったデータ不整合の状態が発生することを防ぎ、常に両方の処理が成功するか、両方とも失敗するかのどちらかとなるように保証する。

ユーザーインターフェースでも、この仕組みの特性を分かりやすく伝える工夫がなされている。ユーザーが署名操作を行う際には、「この署名はマーケットプレイスリクエストを作成するものであり、支払いではないこと」「ブロックチェーン取引ではないこと」「ガス代は発生しないこと」といった重要な情報が明確に表示される。これは単なる技術的な仕様ではなく、MyZubsterのプロダクトデザインの一部として、ユーザーに安心感を与えるための配慮である。

MyZubsterのシステムでは、ブロックチェーンはマーケットプレイスのあらゆる活動を記録するために使われるわけではない。別途、MyZubsterが完了したマーケットプレイス活動の重要なデジタル証拠を、Baseのようなブロックチェーン上に固定する仕組みが存在する。これは、ユーザーのリクエスト署名とは意図的に区別されている。ブロックチェーンは、特定のデジタルデータ(ハッシュ値など)が存在し、いつ記録されたかという「不変のデジタル証拠」を提供する場所として活用される。しかし、ブロックチェーンは、物理的な商品が存在したか、サービスが実際に提供されたか、環境に関する主張が真実であるかといった、現実世界の事象を魔法のように証明するものではない。それらの主張については、別途独自の証拠が必要であるという明確な分離を保っている。

このアーキテクチャの真の価値は、単に「暗号ウォレットをマーケットプレイスに追加する」ことにとどまらない。目的は、アカウントの本人性、ウォレットの所有権、署名されたユーザーの意図、マーケットプレイスの状態、支払いの状態、デジタル証拠、そしてオプションのブロックチェーンへの固定という、それぞれ独立したレイヤーを、それぞれが異なる種類の証拠を提供するものとして接続することにある。これにより、すべてのやり取りをブロックチェーン上に置くよりも、はるかに有用で堅牢なシステムを構築できる。ブロックチェーンは、不変なデジタル固定が価値を生む場所で活用し、暗号署名はユーザーの承認と意図の証拠が必要な場所で活用し、従来のデータベースはアプリケーションの整合性を保つために活用される。支払いは独立した明示的な金融操作として扱われ、物理世界に関する主張はこれらすべてとは分離される。

現時点では、EVMウォレットの連携、ウォレット所有権の検証、チャレンジのリプレイ防止、署名付きマーケットプレイスリクエストの作成、V2経済スナップショットの組み込み、トランザクションによるリクエスト作成、そしてReactを用いたウォレットリクエストフローは実装済みであり、バックエンドおよびフロントエンドのテストも成功している。しかし、本番環境へのデプロイ、公開環境でのエンドツーエンド検証、より強力なドメインバインディング、レートリミットといったセキュリティ強化、支払い機能の本格的な実装、AIアシスタントによる出品作成支援などは、今後の段階で取り組むべき課題として残っている。MyZubsterは、何が署名され、何が支払われ、何が記録され、何が固定され、何が実際に検証されたのかを明確にすることを目標として、開発を進めている。

関連コンテンツ

関連IT用語

関連ITニュース