この例では、DID Connect の一般的で強力なユースケースである、ユーザーにオンチェーン トランザクションへの署名と送信を要求して支払いを行う方法を示します。このパターンは、Eコマースのチェックアウト、サービスのサブスクリプション、コンテンツの購入など、トークンや資産の転送を必要とするあらゆるシナリオに最適です。
signature クレームを使用して、事前に構築されたトークン転送トランザクションに署名するようユーザーに要求します。
仕組み
このプロセスでは、アプリケーションがトランザクションを作成し、ユーザーのウォレットに署名を求めます。これにより、ユーザーは自分の資産を完全に管理でき、アプリケーションがユーザーの秘密鍵を扱うことは決してありません。
一般的なフローは次のとおりです。
トランザクションの作成
アプリケーションのバックエンドが支払いの詳細(金額、トークンの種類、受取人アドレスなど)を決定し、
@ocap/clientのようなライブラリを使用して生のトランザクションを構築します。クレームリクエスト
アプリケーションは DID Connect セッションを開始し、ユーザーに
signatureクレームを要求します。生のトランザクションデータは、このクレームリクエストに埋め込まれます。ユーザーの承認
ユーザーの DID Wallet はリクエストを受け取り、トランザクションをデコードし、人間が読める形式の要約(例:「'My App' に 100 ABC トークンを支払う」)を表示します。ユーザーはその後、秘密鍵でトランザクションを承認し署名することを選択できます。
レスポンスの処理
承認されると、ウォレットは署名済みのトランザクションをアプリケーションに送り返します。アプリケーションは署名を検証し、トランザクションをブロックチェーンにブロードキャストして支払いを完了させることができます。
このプロセス全体は安全で非管理型(ノンカストディアル)であり、シームレスな Web3 決済体験を提供します。
コード例
アプリケーションがユーザーに 100 ネイティブトークンの支払いを要求する例を構築してみましょう。
1. WalletAuthenticator の設定
まず、アプリケーションの詳細とチェーン情報で WalletAuthenticator を設定します。
Transaction Payment Authenticator Setup
import { WalletAuthenticator } from '@did-connect/lib';
import { fromRandom } from '@ocap/wallet';
// アプリケーションのウォレット
const appWallet = fromRandom();
const auth = new WalletAuthenticator({
wallet: appWallet,
baseUrl: 'https://yourapp.com',
appInfo: {
name: 'My Awesome App',
description: '支払いが必要なアプリ。',
icon: 'https://yourapp.com/logo.png',
link: 'https://yourapp.com',
},
chainInfo: {
host: 'https://beta.abtnetwork.io/api',
id: 'beta',
},
});2. Signature クレームの定義
次に、要求する claims を定義します。単一の signature クレームを使用します。クレーム関数内で、トランザクションを構築します。
これには、トランザクションをエンコードするための @ocap/client と、結果のバッファをウォレットが期待する形式である Base58 文字列に変換するための @ocap/util が必要です。
Create Transaction Signature Claim
import Client from '@ocap/client';
import { fromPublicKey } from '@ocap/wallet';
import { toBase58 } from '@ocap/util';
const client = new Client('https://beta.abtnetwork.io/api');
const NATIVE_TOKEN_ADDRESS = 'z35nB2SA6xxBuoaiuUXUw6Gah2SNU3UzqdgEt'; // ArcBlock チェーンのネイティブトークン
// Express.js ハンドラ用のクレームを定義
const claims = {
signature: async ({ userDid, userPk }) => {
// 1. トランザクションオブジェクトを構築
const txPayload = {
tx: {
from: userDid,
pk: userPk,
itx: {
to: appWallet.address, // アプリのアドレスに支払いを送信
tokens: [
{
address: NATIVE_TOKEN_ADDRESS,
value: '100000000000000000000', // 100 トークン(小数点以下 18 桁)
},
],
},
},
wallet: fromPublicKey(userPk),
};
// 2. トランザクションをバッファにエンコード
const encoded = await client.encodeTransferV2Tx(txPayload);
// 3. ウォレット用のクレームオブジェクトを返す
return {
type: 'fg:t:transaction', // ネイティブフレームワークのトランザクションを指定
data: toBase58(encoded.buffer), // トランザクションデータは Base58 でエンコードする必要がある
description: 'このトランザクションに署名して、100 トークンの支払いを完了してください。',
// requirement オブジェクトは、ウォレットがユーザーに明確な要約を表示するために使用されます
requirement: {
tokens: [
{
address: NATIVE_TOKEN_ADDRESS,
value: '100000000000000000000',
},
],
},
};
},
};
// ルートハンドラで、リクエスト URL を生成します
// const signed = await auth.sign({ context: { userDid, userPk }, claims });この例では:
userDidとuserPkは、ユーザーがウォレットを接続した後の DID Connect セッションコンテキストによって提供されます。- 標準的なトークン転送トランザクションを作成するために
client.encodeTransferV2Txを使用します。 toアドレスは、資金が送られるアプリケーションのウォレットアドレスです。requirementオブジェクトは、優れたユーザーエクスペリエンスのために非常に重要です。これにより、ウォレットはトランザクションを解析し、ユーザーに支払いを求められている内容を正確に表示できるため、悪意のある、または不正確なトランザクションに署名することを防ぎます。
3. ウォレットのレスポンスの処理
ユーザーがウォレットでトランザクションに署名した後、アプリケーションのコールバックエンドポイントは署名済みのトランザクションデータを受け取ります。その後、@ocap/client のようなライブラリを再度使用して、それをブロックチェーンにブロードキャストできます。
ウォレットのレスポンスを処理するハンドラの設定に関する完全なガイドについては、ウォレットのレスポンスの処理 ガイドを参照してください。
この例は、基本的な Web3 のインタラクションをカバーしています。signature クレームを活用することで、ユーザーのキーを管理することなく、支払いやその他のオンチェーンアクションを安全に要求できます。
クレームの別の実践的な応用例については、NFT ゲートアクセス の例をご覧ください。