「Blockchain」タグの記事が9件件あります

DAGとは？ブロックチェーンとの違い​

**有向非巡回グラフ（Directed Acyclic Graph, DAG）**は、サイクルを形成しない有向エッジでノードを結んだデータ構造です。分散型台帳の文脈では、DAGベースの台帳はトランザクションやイベントを単一の直線的なチェーンではなく、網目状のグラフとして整理します。つまり、各ブロックが1つの前ブロックのみを参照する（直線的なチェーンを形成する）従来型のブロックチェーンと異なり、DAGでは1つのノードが複数の過去トランザクションやブロックを参照できます。その結果、トランザクションは時間順のブロックに一つずつ詰め込まれるのではなく、並列で承認できるようになります。

ブロックチェーンが多数のトランザクションを含むブロックの鎖に見えるとすれば、DAG型台帳は個々のトランザクションが枝分かれした樹や網のように見えます。DAGでは新しいトランザクションが1つ以上の既存トランザクションに接続（承認）できるため、次のブロックにまとめられるのを待つ必要がありません。この構造的な違いが、次のような要点につながります。

• 並列検証: ブロックチェーンではマイナーやバリデーターが1ブロックずつ追加するため、トランザクションは新しいブロックごとにバッチで承認されます。DAGでは複数のトランザクション（あるいは小さな“ブロック”）を同時に追加でき、各トランザクションがグラフの別の部分に接続できます。この並列化によって、ネットワークは一本の長いチェーンが伸びるのを待つ必要がなくなります。
• 全体順序がない: ブロックチェーンはすべてのトランザクションに一意の順番を与えます（各ブロックが直線的なシーケンスに位置づけられる）。対してDAG台帳はトランザクションの部分順序を形成します。“最新のブロック”が存在せず、グラフの先端（tip）が複数同時に存在し拡張されます。最終的にDAG内のトランザクションの順番や正当性を決めるためにコンセンサスプロトコルが必要になります。
• トランザクションの確定: ブロックチェーンではトランザクションがマイニング（あるいはバリデーション）されたブロックに取り込まれ、そのブロックがチェーンに受け入れられ（さらに追加のブロックが重なる）ことで確定します。DAGシステムでは、新しいトランザクション自身が過去トランザクションを参照することで承認に貢献します。例えばIOTAのTangle（DAG）では各トランザクションが過去2つのトランザクションを承認する必要があり、ユーザー同士が相互に検証する形になります。これにより、ブロックチェーンのマイニングに存在する「トランザクション送信者」と「検証者」の明確な区別がなくなり、トランザクションを発行する参加者が少しずつ検証作業も担います。

重要なのは、ブロックチェーンはDAGの特殊ケースであるという点です。つまりブロックチェーンは、単一チェーンに制約されたDAGと捉えることができます。どちらも分散型台帳技術（DLT）の一種であり、不変性や分散化などの目標を共有します。ただしDAG型台帳は構造的に「ブロックレス」あるいはマルチペアレントであり、実用上の性質が異なります。ビットコインやイーサリアムのような伝統的ブロックチェーンは直列に並ぶブロックを採用し、競合するブロック（フォーク）は破棄するのが普通です。一方DAG台帳は、矛盾しない限り、すべてのトランザクションを取り込んで整理しようとします。この根本的な違いが、後述する性能や設計上の差異を生みます。

技術的比較：DAG vs ブロックチェーン​

DAGとブロックチェーンの違いをより理解するために、アーキテクチャと検証プロセスを比較してみましょう。

• データ構造: ブロックチェーンはトランザクションをまとめたブロックを線形に連結し、各ブロックがただ1つの直前ブロックを指します。DAG台帳はグラフ構造を採用し、各ノードがトランザクションやイベントブロックを表し、複数の前ノードにリンクできます。この有向グラフは巡回しないため、リンクを「過去」に辿っても元のトランザクションに戻ってくることはありません。この性質が、参照先の後に必ず参照元が現れるようなトポロジカルソートを可能にします。要するに、ブロックチェーンは一次元の鎖、DAGは多次元のグラフです。
• スループットと並行性: この構造差により、スループットも異なります。ブロックチェーンは理想的な条件下でも1ブロックずつ追加します（しばしば各ブロックがネットワーク全体に検証・伝播されるのを待つ必要があります）。この制約が取引スループットに限界を与えます。例えばビットコインは平均5～7 TPS、クラシックPoWのイーサリアムは15～30 TPS程度です。DAGでは多くの新しいトランザクションやブロックを同時にレジャーへ追加できます。複数の枝が同時に成長し後で合流できるため、潜在的なスループットは劇的に高まります。最新のDAGネットワークでは数千TPSを謳い、従来の決済ネットワークに匹敵または上回る性能を示すものもあります。
• トランザクション検証プロセス: ブロックチェーンではトランザクションがメモリプールで待機し、マイナー／バリデーターが新ブロックにまとめた後、他のノードがチェーン履歴に照らして検証します。DAGでは検証がより継続的かつ分散的に進みます。新しいトランザクションが過去トランザクションを参照（承認）する検証アクションを担うためです。例えばIOTAのTangleでは、各トランザクションが有効性をチェックした上で小さなPoWを実行し、2つの先行トランザクションを承認します。Nanoのブロックラティス（DAG）では、各アカウントのトランザクションが独自チェーンを形成し、代表ノードによる投票で検証されます。結果的にDAGは検証作業を分散させ、単一のブロックプロデューサーがまとめて検証するのではなく、多数の参加者が並列に検証する構図になります。
• コンセンサス機構: ブロックチェーンもDAGも、台帳の状態（どのトランザクションが確定し、どの順番か）をネットワーク全体で合意する必要があります。ブロックチェーンではPoWやPoSにより次のブロックを生成し、「最長（あるいは最重）チェーンが勝つ」というルールが一般的です。DAGでは単一チェーンがないため、コンセンサスはより複雑になる傾向があります。ゴシップとバーチャル投票（Hedera Hashgraphなど）や、マルコフ連鎖モンテカルロによるティップ選択（IOTA初期）など、プロジェクトごとにアプローチが異なります。後ほど具体的な方式を紹介します。全般的に、DAGでネットワーク全体の合意を得る方がスループット面では高速になり得ますが、同時並行するトランザクション間のコンフリクト（ダブルスペンドなど）処理が難しくなるため、慎重な設計が不可欠です。
• フォーク処理: ブロックチェーンでは、ほぼ同時に2つのブロックが生成される「フォーク」が起こると、最終的に一方が勝者チェーンとして残り、もう片方は孤立ブロックとして破棄されます。この際の計算資源は無駄になります。DAGではフォークを追加の枝として受け入れる設計思想です。どちらの分岐もグラフに取り込み、コンセンサスアルゴリズムが最終的にどのトランザクションを確定させるか（競合はどう解決するか）を決めます。これにより、孤立ブロックに費やされた計算が無駄にならず、効率的です。例えばConfluxのTree-Graph（PoW型DAG）は、生成されたブロックを捨てずに全て台帳へ取り込み順序付けします。

まとめると、ブロックチェーンはシンプルで厳密に順序付けされた構造を提供し、検証はブロック単位で進みます。一方、DAGは複雑なグラフ構造によって非同期かつ並列にトランザクションを処理できるようにします。DAGベースの台帳はこの複雑さを管理するため追加のコンセンサスロジックが必要ですが、ネットワーク全体の能力を余すことなく活用できるため、スループットと効率の大幅向上が期待できます。

DAGベースのブロックチェーンシステムの利点​

DAGアーキテクチャは、従来型ブロックチェーンが抱えるスケーラビリティ・速度・コストの制約を克服するために導入されました。主な利点は次の通りです。

• 高いスケーラビリティとスループット: DAGネットワークは多数のトランザクションを並列処理できるため、高い取引処理性能を発揮します。単一チェーンのボトルネックがないため、TPS（秒間トランザクション数）はネットワーク活動に比例して伸びやすくなります。Hedera Hashgraphはベースレイヤーで1万TPS以上に対応できるとされ、ビットコインやイーサリアムを大幅に上回ります。実際にHederaは約3〜5秒でトランザクションを確定でき、PoWブロックチェーンの数分に比べて圧倒的に速いです。FantomのようなDAG型スマートコントラクトプラットフォームでも、通常負荷で1〜2秒程度の即時性に近いファイナリティを実現しています。こうしたスケーラビリティは、IoTマイクロペイメントやリアルタイムデータ処理など、高トラフィック用途に適しています。
• 低コスト（無料もしくは極小手数料）: 多くのDAG台帳は手数料がごくわずか、場合によっては完全無料です。一般的にマイナーによるブロック報酬や手数料に頼らない設計であり、IOTAやNanoでは必須手数料がありません。これはIoTのマイクロペイメントや日常利用に不可欠です。手数料が存在する場合（例：HederaやFantom）でも、ネットワークが高負荷でもブロックスペースの入札競争が起こりにくいため、非常に低く予測可能です。Hederaの送金手数料は約0.0001ドル（1万分の1ドル）とされ、従来チェーンの手数料と比べると桁違いに安いです。フォークによる無駄が少ないことも、間接的に低コスト維持に寄与します。
• 高速確定と低レイテンシ: DAGではトランザクションがグローバルなブロックに含まれるのを待つ必要がないため、確定が早くなります。多くのDAGは迅速なファイナリティを実現します。Hedera HashgraphはABFTコンセンサスにより数秒で100%確定します。Nanoでは代表ノードによる軽量投票のおかげで1秒未満で確定することが多いです。低レイテンシはユーザー体験を大きく向上させ、現実世界の支払いにも適しています。
• エネルギー効率: 多くのDAGネットワークはPoWマイニングのような計算集約型のプロセスを必要としないため、非常に低い電力で運用できます。PoSチェーンと比べても消費電力が少ないケースがあります。Hederaのトランザクション1件あたりの消費電力は約0.0001 kWhとされ、ビットコイン（1件あたり数百kWh）や多くのPoSチェーンより桁違いに少ないです。計算の無駄がなく、トランザクションが破棄されないことが効率化の要因です。DAGが広く採用されれば、大幅なエネルギー削減につながる可能性があります。Hederaのようにカーボンネガティブを宣言するプロジェクトもあり、持続可能なWeb3インフラとして注目されています。
• マイニング不要と検証の民主化: 多くのDAGでは一般ユーザーでも検証プロセスに参加できます。IOTAではトランザクションを発行するユーザーが他の2件を承認するため、検証作業がネットワークの末端まで分散します。高価なマイニング装置や大規模ステーキングが不要で、参加障壁が低いと言えます（ただしネットワークによってはバリデーターやコーディネーターを採用している場合もあります）。
• 高トラフィックへの対応力: ブロックチェーンでは高負荷時にメモリプールが溢れ、手数料が急騰します。DAGネットワークは並列性により、大量のトランザクションが流入しても複数の枝を広げて同時処理できるため、高負荷時もスムーズです。ハードキャップが緩く、横方向のスケールが可能です。そのためIoTデバイスの一斉通信やバイラルなDAppイベントなどでも遅延や手数料上昇が抑えられます。

要するに、DAG台帳は従来ブロックチェーンが苦手としてきた高速・低コスト・高スケールなトランザクション処理を実現します。ただし、その裏には特有のトレードオフや課題も存在し、後ほど詳しく触れます。

DAG型プラットフォームのコンセンサスメカニズム​

DAG台帳は単一のブロックチェーンを自然に生成しないため、トランザクションを検証し、ネットワーク全体の合意を得るための新しいコンセンサス機構が求められます。以下に代表的なアプローチを紹介します。

• IOTA Tangle：ティップ選択と加重投票: IOTAのTangleはIoT向けに設計されたトランザクションのDAGです。マイナーが存在せず、各トランザクションが小さなPoWを実行して過去2つのトランザクションを承認します。ティップ（未承認トランザクション）の選択にはマルコフ連鎖モンテカルロ（MCMC）が採用され、最も重いサブタングルを優先して断片化を防ぎます。初期のIOTAでは、後続トランザクションからの累積的な承認によって確率的に確定していました。ただし、ネットワーク初期のセキュリティを確保するため、IOTA財団が運営する中央集権的なCoordinatorがマイルストーントランザクションを発行しファイナリティを担保していました。批判を受けたこの仕組みは「Coordicide」（IOTA 2.0）で廃止予定です。IOTA 2.0ではリーダーレスなナカモト型コンセンサスをDAG上で実現し、ノードがDAG上で投票を行います。ノードが新たなブロックを接続すると、そのブロックは参照するトランザクションの有効性に暗黙の投票を行います。ステーキングで選出されたバリデータ委員会がvalidation blockを発行し、十分な加重承認（approval weight）を得たトランザクションが確定します。つまりIOTAはティップ選択+Coordinatorから、DAG分岐に対する完全分散型投票へと進化し、安全性と迅速な合意形成を目指しています。
• Hedera Hashgraph：ゴシップとバーチャル投票（aBFT）: Hedera HashgraphはイベントのDAGと非同期ビザンチン耐性（aBFT）コンセンサスを組み合わせています。中核となるアイデアは“gossip about gossip”です。各ノードがトランザクション情報だけでなく、自身のゴシップ履歴を署名付きで他ノードに広めます。これにより、誰がどの情報をいつ受け取ったかを含むハッシュグラフ（イベントのDAG）が形成されます。このグラフを基にHederaはバーチャル投票を実施します。トランザクション順序を決めるための実際の投票メッセージを送信する代わりに、ノードはハッシュグラフの構造を解析して仮想的な投票をローカルでシミュレーションします。これによりコンセンサスタイムスタンプと完全なトランザクション順序が得られ、公正かつ確定的（受信時間の中央値で順序付け）な結果が保証されます。Hashgraphのコンセンサスはリーダーレスで、1/3までの悪意あるノードを許容するaBFTを実現します。実際にはHederaは39社の評議会ノードが運営する許可型ネットワークですが、地理的には分散しています。秒単位で最終確定する高速・高安全なコンセンサスが特徴です。アルゴリズムは特許化されていましたが2024年にオープンソース化され、DAG+革新的コンセンサス（ゴシップとバーチャル投票）の可能性を示しています。
• Fantom Lachesis：リーダーレスPoS aBFT: FantomはDAGベースのコンセンサスLachesisを採用したスマートコントラクトプラットフォームです。Hashgraphに着想を得たaBFT PoSプロトコルで、各バリデーターが受信したトランザクションをイベントブロックとしてまとめ、自身のローカルDAGに追加します。イベントブロックは過去イベントへの参照を含み、非同期にゴシップされます。バリデーターは、スーパー多数のノードが認識したイベントをマイルストーン（root event）として識別し、最終的にOpera Chain（線形なブロックチェーン）へコミットします。つまりDAGで高速非同期コンセンサスを実現し、最終結果を互換性の高い線形チェーンに変換する仕組みです。Fantomのトランザクションは1～2秒程度でファイナリティを得られ、ベンチマークでは数千TPSも可能とされます。Lachesisにはマイナーやリーダーが存在せず、全バリデーターがイベントブロックを生成しプロトコルが決定的に順序付けます。PoSによって安全性が担保され、aBFT特性により1/3のノード障害に耐えます。開発者にとってはEVM互換の通常のチェーンとして扱えるため、内部的にDAGを使いながら複雑さを隠蔽した好例です。
• NanoのOpen Representative Voting（ORV）: Nanoはブロックラティスと呼ばれるDAG構造を用いた決済特化の暗号資産です。各アカウントに固有のブロックチェーン（アカウントチェーン）が存在し、所有者だけが更新できます。これらの個別チェーンがDAGを形成し、アカウント間の送金は非同期的にリンクされます（送金側の送信ブロックと受信側の受信ブロック）。コンセンサスはOpen Representative Voting（ORV）で達成され、ユーザーが残高重みを代表ノードに委任し、代表がトランザクションの有効性に投票します。各トランザクションは個別に処理され（複数Txをまとめたブロックは存在しない）、投票重みの過半数（例：67%以上）が賛成すると確定します。正直なアカウント所有者は二重支出しないため、フォークは稀で悪意の試みに限られます。代表が迅速に否決できるため、1秒未満でファイナリティを得られることが多いです。ORVはPoSに似ており、投票重みが残高に比例しますが、ステーキング報酬や手数料がありません。マイニングもブロック生成も不要で、Nanoは無料かつ効率的に動作します。ただし代表ノードのオンライン状態に依存し、大きな投票重みが特定ノードに集中する傾向があり、ある種の中央集権リスクは存在します（ユーザーが代表を変更できるため、最終的な統制はコミュニティ側にあるとされています）。
• その他のアプローチ: ここまでに挙げた以外にもDAGベースのコンセンサスが存在します。
  • Avalancheコンセンサス（Avalanche/X-Chain）: AvalancheはDAGを活用したコンセンサスで、バリデーターがランダムに相互サンプリングを繰り返し、優先するトランザクション／ブロックを決めます。AvalancheのX-Chain（交換チェーン）はUTXOのDAGで、このサンプリングによって合意に達します。確率的ながら非常に高速かつスケーラブルで、トランザクションは約1秒で確定し、サブネットあたり4,500 TPSまで対応可能とされています。Snowballプロトコルと呼ばれるメタスタブルコンセンサスとDAG構造を組み合わせた独自の仕組みで、十分なステークがあれば誰でもバリデーターになれます。
  • Conflux Tree-Graph: ConfluxはビットコインのPoWをDAGブロックに拡張したプラットフォームです。ブロックが単一の親だけでなく既知のすべての過去ブロックを参照するTree-Graph構造を採用し、孤立ブロックを排除します。これによりPoWを利用しながらも、フォークを全て台帳に取り込み高いスループットを実現します。理論上は3,000～6,000 TPSに達するとされ、マイナーがチェーンの成長を待たず継続的にブロックを生成できます。ヘビエストサブツリー規則で順序付けと競合解決を行うPoW型DAGの代表例です。
  • 学術系プロトコル: SPECTREやPHANTOM（DAGlabsによる高速確定志向のblockDAG）、Aleph Zero（Aleph Zeroチェーンで使われるDAG aBFT）、Parallel Chains / Prism（並列サブチェーンとDAGでトランザクション確定を分担）、SuiのNarwhal & Bullshark（高スループットのDAGメモリプール＋独立した最終合意）など、研究段階や実装初期のDAGプロトコルも多数存在します。可用性と整合性を分離する設計が多く見られ、高速書き込みと一貫性の両立を狙っています。

このようにDAGプラットフォームは用途に合わせてコンセンサス設計を最適化しています。共通するテーマは、単一のシリアルボトルネックを避けることです。ゴシップ、投票、サンプリングなどの巧妙なアルゴリズムで並列活動を整序し、ネットワークを「一列のブロック生産者」に縛らない工夫がなされています。

ケーススタディ：主要なDAG型プロジェクト​

DAG型台帳を実装したプロジェクトは数多くあり、それぞれ設計思想や用途が異なります。代表的な例を見てみましょう。

• IOTA（The Tangle）: IOTAはIoT向けに設計された初期のDAG型暗号通貨の1つです。台帳であるTangleは各トランザクションが2件の過去トランザクションを承認するDAGで、手数料ゼロのマイクロペイメントをIoTデバイス間で可能にします。2016年にローンチされ、初期は攻撃防止のためIOTA財団がCoordinatorノードを運営していました。現在は投票型コンセンサスを導入し、完全分散化（Coordicide）を目指しています。理論上はトランザクションが多いほど速く確定する性質があり、テストネットでは数百TPSを確認済み。IOTA 2.0ではIoT需要に応じてスケールする見込みです。ユースケースはIoTとデータの完全性が中心で、センサーのデータストリーミング、車車間決済、サプライチェーン追跡、DID（IOTA Identity）などがあります。基盤レイヤーではスマートコントラクトを持たず、別レイヤーで対応する構造です。送信者が小さなPoWを行うことでトランザクションを無料化しているため、高頻度・低額の送受信に向いています。
• Hedera Hashgraph（HBAR）: HederaはHashgraphコンセンサス（Leemon Baird博士が発明）を採用したパブリックDLTです。2018年に開始され、GoogleやIBM、Boeingなど大企業からなる評議会がノードを運営します。ガバナンスは許可制で、現在は最大39ノードがコンセンサスを担当しますが、誰でもネットワークを利用可能です。HashgraphのDAGにより、最適条件で1万TPS超・3〜5秒のファイナリティを達成します。トークンサービス（HTS）、イベントログのためのコンセンサスサービス、EVM互換のスマートコントラクトなど、企業やWeb3ユースケースにフォーカスしています。Avery Dennisonによるサプライチェーン証跡、手数料の安さを活かしたNFT大量発行、広告テックでのマイクロペイメント、DIDソリューションなどが稼働中です。Hashgraphはフォークが発生せず、公平な順序決定を数学的に保証する点も特徴です。ノード数は限定されているものの、地理的分散と将来的なオープン化が計画されています。
• Fantom（FTM）: FantomはDAGコンセンサスLachesisを採用したレイヤー1スマートコントラクトプラットフォームです。2019年にローンチし、2021～2022年のDeFiブームでイーサリアム互換ながら高速・低コストである点が注目されました。OperaネットワークがLachesis aBFTを実行し、バリデーターがローカルDAGでイベントブロックを保持して合意に達し、最終的に線形チェーンへ確定させます。その結果、約1秒のファイナリティと数千TPS規模のスループットが可能です。FantomはEVM互換で、Solidityのスマートコントラクトや既存ツールをそのまま使えるため、DeFiプロジェクトの移植が進みました。DEX、レンディング、イールドファーミングなど多数のDAppに利用されており、NFTやゲームも展開されています。DAGプラットフォームとしては珍しく、数十の独立したバリデーターがネットワークを保護しており、許可不要で誰でもステーキング可能です。FTMトークンはステーキング、ガバナンス、手数料に使われ、取引コストは数セント以下とされています。
• Nano（XNO）: Nanoは2015年にRaiBlocksとして登場した軽量暗号通貨で、ブロックラティス構造のDAGを採用しています。主眼は即時・無料のP2Pデジタルキャッシュです。各アカウントが専用チェーンを持ち、送信者が自分のチェーンで送金ブロック、受信者が自分のチェーンで受信ブロックを発行します。非同期設計によりトランザクションを独立かつ並列に処理できます。Open Representative Voting（ORV）により、ユーザーが代表ノードを指名し、その投票で競合トランザクションを解決します。フォークは主に悪意の二重支出試行に限られ、代表が迅速に却下します。通常、1秒未満で確定します。マイニングや手数料がないため、代表ノードの運用はボランティアベースですが、取引サイズが小さく処理も軽量なので負担は小さく済みます。NanoはIoTやモバイルでも扱いやすい低消費電力で、主な用途は決済、オンラインチップ、海外送金などです。スマートコントラクトは備えていませんが、「支払いに特化して一つのことを突き詰める」設計になっています。
• Hedera vs IOTA vs Fantom vs Nano の比較表:

（表：主要なDAG型台帳プロジェクトの比較。TPS＝Transactions Per Second）

このほかにも、条件付き支払い・データ保存に焦点を当てたObyte（Byteball）、IoT向けのIoT Chain (ITC)、コンセンサスにDAGを活用する大型DeFiプラットフォームAvalanche、中国発の高スループットPoW DAGであるConflux、学術プロトタイプのSPECTRE/PHANTOMなど、多彩なDAG系プロジェクトが存在します。ここで挙げた4例（IOTA, Hedera, Fantom, Nano）は、ゼロ手数料IoTからエンタープライズ用途、DeFiスマートコントラクトチェーンまで、DAG構造が幅広い目的で活用されていることを示しています。

Web3エコシステムにおけるDAG技術のユースケース​

DAGベースのブロックチェーンは、その高性能と特異な性質から、特定のユースケースに特に適しています。以下はWeb3で注目される代表的および将来有望なユースケースです。

• IoT（モノのインターネット）: IoTでは多数のデバイスがデータを送信し、機器同士で支払いを行うケースが想定されます。IOTAなどのDAG台帳はまさにこのシナリオを念頭に設計されました。手数料ゼロのマイクロペイメントと高頻度の小額取引処理能力により、デバイスが動的に帯域やサービス料金を支払えます。例として、電気自動車が充電スタンドへ自動で少額決済したり、センサーがデータマーケットでリアルタイムに情報を販売したりできます。IOTAのTangleはスマートシティ実証やサプライチェーンIoT統合、センサーデータの検証付きストリーミングなどで活用されています。大規模IoTネットワークが発生させる膨大なトランザクションを捌けるスケーラビリティと低コストが大きな魅力です。
• DeFi（分散型金融）: DEX、レンディング、決済ネットワークなどのDeFiアプリケーションは高スループットと低レイテンシを求めます。DAG型スマートコントラクトプラットフォーム（例：Fantom、シンプルな資産転送に特化したAvalancheのX-Chainなど）は、混雑時でもトレードを高速・低コストで決済できる利点があります。2021年にはFantomがDeFiの活況を迎え、イーサリアムほどの混雑・高手数料に悩まされませんでした。迅速なファイナリティにより、取引不確実性（遅いチェーンでブロック確定を待つ間のリスク）も減少します。また、NanoのようなDAG通貨はピアツーピア送金やL2マイクロペイメントレールとしてDeFiの一端を担う可能性があります。高頻度トレードや複雑なDeFiトランザクションを滑らかに処理できる点も魅力です。
• NFTとゲーム: NFTブームでは、ミントや送付にかかる高額手数料が問題となりました。DAGネットワーク（HederaやFantomなど）では、NFTミントにかかるコストが数分の1セントに抑えられるため、ゲーム内アイテムやコレクティブル、大規模配布に向いています。Hedera Token Serviceは低コストでネイティブトークン・NFTを発行でき、コンテンツプラットフォームや大学証明書などで活用されています。ゲームではマイクロトランザクションが多発するため、遅延や手数料負担が少ないDAGは報酬配布やアイテム取引を高速化できます。人気ゲームやNFTコレクションが数百万人を集めてもネットワークが耐えられる高スループットは大きな武器です。
• 分散型ID（DID）と認証: IDシステムは不変の台帳でアイデンティティや資格情報をアンカーする必要があります。DAGは潜在的に数十億件規模のIDトランザクションを低コストで処理できるため有望です。IOTA Identityはdid:iotaメソッドを提供し、本人が管理するIDドキュメントをTangle上に参照できます。検証者はDAGから証明を取得できます。HederaもDID領域に注力し、大学の学位証明やワクチン証明、サプライチェーンのコンプライアンスログ（Hedera Consensus Service）などで利用されています。DAGは書き込みが安価で高速であり、鍵のローテーションや資格付与といったID状態の更新にも適します。Hashgraphのように秩序立ったタイムスタンプを提供する仕組みは、監査やコンプライアンスの記録にも有用です。
• サプライチェーンとデータ完全性: サプライチェーンでは商品が製造・輸送・検品など多くのイベントを生成します。HederaやIOTAはこれらイベントをDAG台帳へ記録し、改ざん耐性と透明性を提供します。高スループットのおかげで、巨大サプライネットワークの全品目スキャンにも耐えられます。低コストなので低価値イベントでも記録可能です。エネルギー網や通信などのIoTデータ完全性にも適しており、DAGにログを残して後から改ざんされていないことを証明できます。Constellation NetworkのDAGは大規模データ検証（米空軍のドローンデータなど）に焦点を当て、信頼性の高い大容量データ処理を実現しています。
• 決済と送金: 即時かつ無料のトランザクションは、NanoやIOTAのようなDAG通貨を決済用途に適しています。Nanoはオンラインチップや海外送金などで採用例があり、数セント単位の支払いも即座に行えます。DAGネットワークは高速決済レールとしてPOSシステムやモバイルアプリと統合できます。実店舗でのコーヒー代の支払いでも、遅延やコストを気にせずに済みます。HederaのHBARも高速・低手数料を活かした決済実証が進んでいます。高いキャパシティにより、ショッピングイベントなどのピーク時でも性能を維持できる点が利点です。
• リアルタイムデータフィードとオラクル: オラクルは外部データをスマートコントラクトに提供するため、大量のデータポイントを台帳に書き込む必要があります。DAG台帳は高スループットで、価格情報や天候データ、IoTセンサー読み取りなどをタイムスタンプ付きで記録できます。Hedera Consensus Serviceはオラクルプロバイダがデータを他チェーンへ供給する前にタイムスタンプを付ける用途で利用されています。データが鮮度を保ち、高速なストリームにも対応可能です。分散型Web3分析や広告でクリック・インプレッションを透明に記録する際も、DAGバックエンドが活躍します。

これらのユースケースに共通するのは、DAGネットワークがスケーラビリティ・スピード・コスト効率を提供し、分散化できる領域を拡大する点です。トランザクション頻度が高い場面（IoT、マイクロペイメント、機械データ）や、ユーザー体験として高速かつスムーズなやり取りが求められる場面（ゲーム、決済）で特に強みを発揮します。ただし、すべてのユースケースがDAGへ移行するわけではありません。既存ブロックチェーンの成熟度やセキュリティ、ネットワーク効果（例：Ethereumの巨大な開発者コミュニティ）が勝る場合もあります。それでもDAGは、従来チェーンが苦手とするシナリオで独自のポジションを築きつつあります。

DAGネットワークの課題​

利点が多い一方で、DAGベースの台帳には固有の課題も存在します。主要なものを確認しましょう。

• 成熟度と安全性: 多くのDAGコンセンサスアルゴリズムは比較的新しく、ビットコインやイーサリアムのように長年検証されたわけではありません。そのため未知の脆弱性や攻撃ベクトルが潜む可能性があります。複雑な構造が攻撃の余地を広げることも指摘されています。例えばDAGに大量の分岐（サブタングル）を注入して混乱させたり、並行構造を悪用して合意前にダブルスペンドを仕掛けたりする攻撃が考えられます。実際、IOTAは初期に不正送金事件が起こり、Coordinatorを一時停止した事例もあります。モデルの洗練が進む一方で、完全な安全性を証明するには時間が必要です。また、一部のDAG（Coordicide前のIOTAなど）は確率的ファイナリティしか提供しておらず、絶対確定までに不確実性が残る点が課題でした（HashgraphやFantomのように瞬時ファイナリティを提供する例もあります）。
• コンセンサスの複雑さ: DAGで合意を取るには、ゴシッププロトコルやバーチャル投票、ランダムサンプリングなど複雑なアルゴリズムが必要になります。その結果、コードベースが大きく複雑になり、バグのリスクが増加します。開発者が理解・監査しづらく、導入に慎重になる要因にもなります。チェーン最長規則のような単純明快さはなく、Hashgraphの仮想投票やAvalancheのランダムサンプルなどは直感的に理解しにくい部分があります。開発者ツールやライブラリもブロックチェーンに比べ成熟しておらず、開発体験はやや厳しいという指摘もあります。
• 分散性とのトレードオフ: 現状のDAG実装では、性能を優先するあまり分散性が犠牲になっている例があります。Hederaのように評議会ノードが固定されているケースでは、誰でもバリデータ参加できるわけではなく、中央集権的と批判されることがあります。IOTAは長らく中央Coordinatorに依存していました。Nanoでは大口保有者が代表ノードとして大きな投票権を持つことが多く（PoWチェーンにおけるマイニングプール集中に似ています）、権力集中リスクがあります。理論的には高度に分散したDAGネットワークも可能ですが、実際に大規模チェーン並みのノード数を確保できている例はまだ少数です。
• トラフィック依存性（安全性 vs スループット）: 一部のDAGネットワークは高いトランザクション量を前提に安全性を維持する設計です。IOTAでは多数の正直なトランザクションが相互に承認し合うことで、悪意ある分岐を押しのける「重さ」を獲得します。ネットワーク活動が低いと、ティップが承認されにくくなったり、攻撃者がグラフの一部を書き換えやすくなったりする恐れがあります。対照的にビットコインなどのブロックチェーンは、トランザクション数が少なくてもマイナーがブロックを拡張する限り安全性は維持されます。つまりDAGは高負荷時に強いが、低負荷時には性能や安全性が安定しない可能性があり、維持には工夫が要ります（IOTAのCoordinatorやバックグラウンドの維持トランザクションなど）。
• 順序決定と互換性: DAGは部分順序を生むため、最終的に決定的な順序を得るには複雑な処理が必要です。スマートコントラクトのように状態を持つシステムでは、トランザクションに完全な順序が必要で、並行に承認された取引がコンフリクトを起こす場合に全ノードで同一の結論を出す必要があります。Fantomのように最終的に線形チェーンを構築してEVMに対応する例もありますが、純粋なDAG上で状態管理を行うのは難しく、当初は支払い用途に焦点を絞ったプロジェクトが多かった理由でもあります。既存ブロックチェーンとの連携（例：DAGとEVMの接続）も非自明で、互換性確保には追加の仕組みが必要です。
• ストレージと同期: DAGが大量の並列トランザクションを許容すると、台帳サイズが急速に増大します。不要になった古いトランザクションを安全に剪定（プルーニング）するアルゴリズムや、全体を保持せずに検証できるライトクライアントの仕組みが必要です。研究分野では到達可能性の課題として、新規トランザクションが効率的に過去のトランザクションに接続できるか、履歴を安全に短縮できるかが議論されています。ブロックチェーンもデータ肥大化の問題は抱えますが、DAGの構造は残高計算や部分的な証明生成を複雑にする場合があります。
• 認知とネットワーク効果: 技術以外の面でも、DAGプロジェクトはブロックチェーンが支配する市場で実績を示す必要があります。多くの開発者・ユーザーはブロックチェーンに慣れ親しんでおり、既存チェーンのユーザーベースやツール、インフラの充実が参入障壁になります。DAGが「ブロックチェーンキラー」といった誇張的な宣伝をすると懐疑的な目で見られることもあります。実際に大規模ユーザーを獲得し、目に見える価値を証明するまで時間がかかります。取引所上場やカストディ対応、ウォレットサポートなど、エコシステム全体の整備も必要で、これは従来チェーンでも大きな課題です。

このように、DAGは性能向上の代わりに複雑さを受け入れていると言えます。コンセンサスの複雑化、一部実装での中央集権性、既存チェーンに匹敵する信頼の獲得など、多くの課題があります。研究コミュニティではこれらの問題が活発に議論されており、2024年のSoK論文ではDAGプロトコルの多様化とトレードオフの理解が進んでいることが示されています。プロジェクトの成熟に伴い、Coordinator撤廃やオープン参加、開発ツール改善などが期待されますが、DAGを採用する際にはこれらの点を考慮する必要があります。

採用動向と今後の展望​

DAGベースのブロックチェーン技術は、伝統的なブロックチェーンに比べればまだ普及の初期段階にあります。2025年時点で大規模にDAGを採用するパブリックDLTは、Hedera Hashgraph、IOTA、Fantom、Nano、Avalanche（一部コンポーネント）、その他数件に限られます。一方、チェーン型ブロックチェーンは依然として主流です。しかし、業界と学術界の双方でDAGへの関心が着実に高まっています。主なトレンドを整理します。

• プロジェクト数と研究の増加: DAGやハイブリッドアーキテクチャを探る新プロジェクトが増えています。例えばAleph Zeroはプライバシー志向のネットワークで高速な順序決定にDAGコンセンサスを採用し、SuiやAptos（Move言語チェーン）はDAGベースのメモリプールや並列実行エンジンを導入しています。学術研究も活発で、SPECTRE、PHANTOM、GhostDAGなど新プロトコルの提案や、包括的な分析（SoK論文）が進んでいます。公平性確保、DAGの剪定、動的環境でのセキュリティなど、既存の弱点を克服する成果が今後の実装に取り入れられるでしょう。
• ハイブリッドモデルの主流化: 興味深い傾向として、従来型ブロックチェーンが内部的にDAGの概念を取り入れ性能を高める動きがあります。Avalancheは外見上ブロックチェーンですが、コアではDAGコンセンサスを用いており、DeFiやNFTで広く採用されています。ユーザーは基盤がDAGであると意識せずに利用でき、ニーズ（高速・低コスト）を満たせばDAGが自然に受け入れられることが示されました。FantomがOpera ChainでDAGを内蔵しつつ開発者には従来チェーンのインターフェースを提供したように、今後も内部エンジンとしてDAGを使いながら、表面はチェーン型に見せる戦略が増えるかもしれません。
• 企業・特定分野での採用: 高スループットやコスト予測性を求め、許可型ネットワークに抵抗の少ない企業はDAG台帳を検討する傾向があります。Hederaの評議会モデルは大手企業を惹き付け、金融資産のトークン化やソフトウェアライセンス管理などのユースケースを推進しています。電気通信の決済、広告インプレッション管理、銀行間送金などの業界コンソーシアムもDAGベースDLTを模索しています。IOTAはEU資金によるインフラプロジェクトやデジタルID、産業IoTでの試験導入に参加しており、これらが成功すれば業種横断的な採用につながる可能性があります。
• コミュニティと分散化の前進: 初期に批判された中央集権的要素は徐々に改善されつつあります。IOTAのCoordicideが成功すれば、ステーキングとコミュニティ主導のバリデーターによる完全分散化が実現します。Hederaもコードをオープンソース化し、長期的にはさらなるガバナンス分散を示唆しています。Nanoコミュニティも代表ノードの分散化を促進しています。こうした動きはDAGネットワークの信頼性向上に不可欠であり、Web3コミュニティとの親和性を高めるでしょう。
• 相互運用性とレイヤー2: DAGはスケーリングレイヤーや相互運用ネットワークとして活用される可能性もあります。たとえば、高速なレイヤー2としてDAGを用い、一定間隔でイーサリアムに結果をアンカーする方法が考えられます。あるいはDAGネットワークと既存ブロックチェーンをブリッジで接続し、資産を最も安価な場所に移して取引するアーキテクチャもあり得ます。ユーザー体験がシームレスであれば、高速DAG上で取引しつつ、最終的なセキュリティや決済をベースチェーンに依存するという使い分けが可能です。
• 将来展望：当面は補完的存在: 擁護者も認めるように、DAGはブロックチェーンを完全に置き換えるものではなく、補完的な選択肢として位置づけられています。当面はブロックチェーンとDAGが共存する異種ネットワーク環境が続き、それぞれが得意分野を担うでしょう。DAGはマイクロトランザクションやデータ記録など高頻度のバックボーンを担い、ブロックチェーンは高価値決済やシンプルで堅牢な用途に適している、といった棲み分けが想定されます。長期的には、DAGが十分なセキュリティと分散性を実証し続ければ、分散台帳の主流パラダイムになり得るという見方もあります。エネルギー効率の高さは、持続可能性を重視する規制環境にも合致するため、採用が後押しされるかもしれません。
• コミュニティの期待感: Web3コミュニティの一部では、「DAGこそ次世代DLT」という強い期待があります。「DAGは未来であり、ブロックチェーンはやがてダイヤルアップ回線のように古めかしく感じられる」という声も聞かれます。とはいえ、現実的な成果で証明する必要があります。分散性と安全性を犠牲にせず、スピードを両立できることをDAGが示さなければなりません。

総じて見ると、DAGの将来は慎重ながらも明るいと言えます。現状ではブロックチェーンが主流ですが、DAGプラットフォームは特定領域で存在感を高めており、研究の進展に伴って両者の優れた点を取り入れたハイブリッドな発展が期待されます。ブロックチェーンがDAG的な改良を取り入れ、DAGがブロックチェーンのガバナンスやセキュリティの知見を学ぶことで、相互補完的なエコシステムが形成されていくでしょう。スケーラビリティ・セキュリティ・分散性のトリレンマ解決に向け、DAGは重要な選択肢として注目すべき領域です。

Hederaの言葉を借りれば、DAG型台帳は「デジタル通貨と分散型テクノロジーの進化における有望な一歩」です。ブロックチェーンを完全に置き換える銀の弾丸ではなく、相互に刺激し合いながらDLT全体を前進させる重要なイノベーションとして位置づけられています。

参考文献: 本レポートの情報は、DAGコンセンサスに関する学術研究、IOTA・Hedera Hashgraph・Fantom・Nanoといったプロジェクトの公式ドキュメント／ホワイトペーパー、DAGとブロックチェーンの比較を扱った技術ブログや記事に基づいています。これらの資料が本稿の比較分析や利点、ケーススタディを支えています。Web3研究コミュニティにおける継続的な議論からも、スケーラビリティ・セキュリティ・分散性のトリレンマ解決に向けてDAGが重要なテーマであり続けることが示唆されています。

プライバシーは公共インフラになりつつあります。2025年、開発者にはデータ保存と同じくらい簡単に暗号化を行うツールが必要です。Mysten LabsのSealは、まさにそれを提供します—オンチェーンアクセス制御を備えた分散シークレット管理。このチュートリアルでは、アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセスポリシーを使用して安全なWeb3アプリケーションを構築する方法を教えます。

導入：なぜSealがWeb3にとって重要なのか​

従来のクラウドアプリケーションは、単一のプロバイダーが暗号化データへのアクセスを制御する集中型キー管理システムに依存しています。便利ですが、これは危険な単一障害点を作り出します。プロバイダーが侵害されたり、オフラインになったり、アクセスを制限することを決定した場合、あなたのデータはアクセス不可能または脆弱になります。

Sealは、このパラダイムを完全に変えます。Mysten LabsがSuiブロックチェーン向けに構築したSealは、分散シークレット管理（DSM）サービスで、以下を可能にします：

• アイデンティティベース暗号化：コンテンツが環境を離れる前に保護される
• 閾値暗号化：複数の独立したノード間でキーアクセスを分散
• オンチェーンアクセス制御：タイムロック、トークンゲーティング、カスタム認証ロジック
• ストレージ非依存設計：Walrus、IPFS、または任意のストレージソリューションと連携

安全なメッセージングアプリ、ゲート付きコンテンツプラットフォーム、タイムロック資産転送を構築する場合、Sealは必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。

はじめに​

前提条件​

開始する前に、以下があることを確認してください：

• Node.js 18+がインストールされていること
• TypeScript/JavaScriptの基本的な知識
• テスト用のSuiウォレット（Sui Walletなど）
• ブロックチェーンの概念の理解

インストール​

npm経由でSeal SDKをインストールします：

npm install @mysten/seal

ブロックチェーンインタラクション用にSui SDKも必要です：

npm install @mysten/sui

プロジェクトセットアップ​

新しいプロジェクトを作成し、初期化します：

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

シンプルなTypeScript設定を作成します：

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

コアコンセプト：Sealの仕組み​

コードを書く前に、Sealのアーキテクチャを理解しましょう：

1. アイデンティティベース暗号化（IBE）​

公開キーに暗号化する従来の暗号化とは異なり、IBEではアイデンティティ（メールアドレスやSuiアドレスなど）に暗号化できます。受信者は、そのアイデンティティを制御していることを証明できる場合にのみ復号化できます。

2. 閾値暗号化​

単一のキーサーバーを信頼する代わりに、Sealはt-of-n閾値スキームを使用します。3-of-5キーサーバーを設定することで、任意の3つのサーバーが協力して復号化キーを提供できますが、2つ以下では不可能です。

3. オンチェーンアクセス制御​

アクセスポリシーはSuiスマートコントラクトによって強制されます。キーサーバーが復号化キーを提供する前に、要求者がオンチェーンポリシー要件（トークン所有権、時間制約など）を満たしていることを確認します。

4. キーサーバーネットワーク​

分散キーサーバーはアクセスポリシーを検証し、復号化キーを生成します。これらのサーバーは、単一の制御点を確保しないよう、異なる当事者によって運営されます。

基本実装：最初のSealアプリケーション​

Suiブロックチェーンポリシーを通じてアクセスを制御し、機密データを暗号化するシンプルなアプリケーションを構築しましょう。

ステップ1：Sealクライアントの初期化​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // テストネット用のSuiクライアントを初期化
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // テストネットキーサーバーでSealクライアントを設定
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 2-of-3閾値
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

ステップ2：シンプルな暗号化/復号化​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 暗号化するデータ
  const sensitiveData = "これは私の秘密メッセージです！";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 特定のSuiアドレス用にデータを暗号化
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // オプション：メタデータを追加
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('暗号化されたデータ:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 後でデータを復号化（適切な認証が必要）
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('復号化されたデータ:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('暗号化/復号化に失敗しました:', error);
  }
}

basicExample();

Suiスマートコントラクトによるアクセス制御​

Sealの真の力は、プログラマブルアクセス制御にあります。特定の時間後にのみデータを復号化できるタイムロック暗号化の例を作成しましょう。

ステップ1：アクセス制御コントラクトのデプロイ​

まず、アクセスポリシーを定義するMoveスマートコントラクトが必要です：

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

ステップ2：Sealとの統合​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Sui上でアクセスポリシーを作成
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1分後にアンロック
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // ポリシーを作成するトランザクションを実行
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // あなたのSuiキーペア
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // このポリシーで暗号化
  const sensitiveData = "これは1分後にアンロックされます！";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('タイムロックされたデータが作成されました。1分後に復号化を試してください。');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

実用的な例​

例1：安全なメッセージングアプリケーション​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 暗号化されたメッセージを分散ストレージ（Walrus）に保存
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // ストレージから取得
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Sealで復号化
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Walrusストレージとの統合
    // 暗号化されたデータをWalrusにアップロードし
    // 取得用のblob IDを返します
  }

  private async retrieveFromWalrus(blobId: string) {
    // blob IDを使用してWalrusから暗号化されたデータを取得
  }
}

例2：トークンゲート付きコンテンツプラットフォーム​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // NFT所有権ポリシーを作成
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // NFTアクセス要件でコンテンツを暗号化
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFTホルダー用の特別な受信者
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // まずNFT所有権を確認
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('アクセスが拒否されました：必要なNFTが見つかりません');
    }

    // コンテンツを復号化
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // NFT所有権をチェックするMoveコントラクトを作成
    // ポリシーオブジェクトIDを返す
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // ユーザーが必要なNFTを所有しているかチェック
    // NFT所有権についてSuiにクエリ
  }
}

例3：タイムロック資産転送​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Sui上でタイムロックポリシーを作成
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 資産転送データを暗号化
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`資産は${new Date(unlockTimestamp)}までロックされています`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 資産転送を処理
    console.log('資産転送のロックが解除されました:', transferData);

    return transferData;
  } catch (error) {
    console.error('転送がまだアンロックされていないか、アクセスが拒否されました:', error);
    throw error;
  }
}

Walrus分散ストレージとの統合​

SealはSuiの分散ストレージソリューションであるWalrusとシームレスに連携します。両方を統合する方法は以下の通りです：

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Sealで暗号化
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // 暗号化されたデータをWalrusに保存
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // SealとWalrusの両方の情報を含む参照を返す
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Walrusから取得
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Sealで復号化
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 使用例
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('重要なドキュメントの内容');
  const recipientAddress = '0x...';

  // 暗号化して保存
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Blob IDで保存されました:', result.blobId);

  // 後で取得して復号化
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('取得されたデータ:', decrypted.toString());
}

閾値暗号化の高度な設定​

本番アプリケーションでは、複数のキーサーバーでカスタム閾値暗号化を設定したいでしょう：

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 複数の独立したキーサーバーで設定
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5閾値
    network: 'mainnet',
    // 高度なオプション
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "ミッションクリティカルな暗号化データ";

  // 高いセキュリティ保証で暗号化
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 最大セキュリティのため全5サーバーを要求
    customThreshold: 5,
    // 冗長性を追加
    redundancy: 2,
    accessPolicy: {
      // 多要素要件
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

セキュリティベストプラクティス​

1. キー管理​

// src/security-practices.ts

// 良い例：安全なキー導出を使用
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 良い例：キーを安全に保存（環境変数の例）
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 悪い例：キーをハードコードしない
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // これはしないでください！
);

2. アクセスポリシーの検証​

// 暗号化前に必ずアクセスポリシーを検証
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 受信者アドレスを検証
  if (!isValidSuiAddress(recipient)) {
    throw new Error('無効な受信者アドレスです');
  }

  // ポリシーが存在し有効であることをチェック
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('無効なアクセスポリシーです');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. エラーハンドリングとフォールバック​

// 堅牢なエラーハンドリング
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('アクセスが拒否されました：権限を確認してください');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // バックアップ設定で再試行
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('利用可能なキーサーバーが不十分です');
    } else {
      throw new Error(`復号化に失敗しました: ${error.message}`);
    }
  }
}

4. データ検証​

// 暗号化前にデータを検証
function validateDataForEncryption(data: Buffer): boolean {
  // サイズ制限をチェック
  if (data.length > 1024 * 1024) { // 1MB制限
    throw new Error('暗号化するにはデータが大きすぎます');
  }

  // 機密パターンをチェック（オプション）
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('警告：データに潜在的に機密のパターンが含まれています');
  }

  return true;
}

パフォーマンス最適化​

1. バッチ操作​

// 効率性のため複数の暗号化をバッチ処理
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. キーサーバーレスポンスのキャッシュ​

// レイテンシを減らすためキーサーバーセッションをキャッシュ
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Seal統合のテスト​

ユニットテスト​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal統合', () => {
  it('データを正常に暗号化および復号化する必要があります', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('テストメッセージ');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('テストメッセージ');
  });

  it('アクセス制御ポリシーを強制する必要があります', async () => {
    // 権限のないユーザーが復号化できないことをテスト
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('秘密'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('アクセスが拒否されました');
  });
});

本番環境へのデプロイ​

環境設定​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // セキュリティ設定
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1時間
  retryAttempts: 3
};

モニタリングとログ​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] ${recipient}用にデータ${encryptionId}を暗号化しました`);
    // モニタリングサービスに送信
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 復号化 ${encryptionId}: ${success ? '成功' : '失敗'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] キーサーバー ${serverUrl}: ${status}`);
  }
}

リソースと次のステップ​

公式ドキュメント​

• Sealドキュメント: https://seal-docs.wal.app/
• GitHubリポジトリ: https://github.com/MystenLabs/seal
• Suiドキュメント: https://docs.sui.io/
• Walrusドキュメント: https://docs.wal.app/

コミュニティとサポート​

• Sui Discord: コミュニティサポートのため#sealチャンネルに参加
• GitHub Issues: バグ報告と機能リクエスト
• 開発者フォーラム: ディスカッション用Suiコミュニティフォーラム

探索すべき高度なトピック​

1. カスタムアクセスポリシー: Moveコントラクトで複雑な認証ロジックを構築
2. クロスチェーン統合: 他のブロックチェーンネットワークでSealを使用
3. エンタープライズキー管理: 独自のキーサーバーインフラストラクチャを設定
4. 監査とコンプライアンス: 規制環境向けのログとモニタリングを実装

サンプルアプリケーション​

• 安全なチャットアプリ: Sealによるエンドツーエンド暗号化メッセージング
• ドキュメント管理: アクセス制御付きエンタープライズドキュメント共有
• デジタル権利管理: 使用ポリシー付きコンテンツ配信
• プライバシー保護分析: 暗号化データ処理ワークフロー

結論​

Sealは、Web3におけるプライバシーと暗号化をインフラストラクチャレベルの関心事にする根本的な変化を表しています。アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセス制御を組み合わせることで、開発者に真に安全で分散化されたアプリケーションを構築するための強力なツールを提供します。

Sealで構築することの主な利点には以下があります：

• 単一障害点の排除: 分散キーサーバーが中央権威を排除
• プログラマブルセキュリティ: スマートコントラクトベースのアクセスポリシーが柔軟な認証を提供
• 開発者フレンドリー: TypeScript SDKが既存のWeb3ツールとシームレスに統合
• ストレージ非依存: Walrus、IPFS、または任意のストレージソリューションと連携
• 本番環境対応: エンタープライズセキュリティ標準でMysten Labsが構築

ユーザーデータの保護、サブスクリプションモデルの実装、複雑なマルチパーティアプリケーションの構築のいずれであっても、Sealは自信を持って構築するために必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。

今日から構築を始めて、プライバシーを公共インフラストラクチャの基本的な部分にする開発者の成長するエコシステムに参加しましょう。

構築を始める準備はできましたか？ @mysten/sealをインストールして、このチュートリアルの例を試してみてください。分散ウェブは、プライバシーとセキュリティを第一に考えるアプリケーションを待っています。

はじめに​

StripeのTempoは、高速で低コストのステーブルコイン決済処理に中核的に焦点を当てた、新しく立ち上げられたLayer-1（L1）ブロックチェーンネットワークです。このプロジェクトは、決済大手のStripeと著名な暗号通貨ベンチャーキャピタル企業であるParadigmによって共同インキュベートされました。当初から「決済ファースト」のブロックチェーンとして位置付けられ、現実世界の金融シナリオの厳しいスケールとパフォーマンス要件を満たすように設計されています。2025年に、Tempoはプライベートテストネット段階に入り、Visa、Deutsche Bank、Shopify、OpenAIを含む数社の重量級パートナーと機能を共同設計・検証しています。開発者コミュニティにとって、Tempoの出現は新しい機会を提示します—ステーブルコインと商用ユースケース向けに最適化された基盤インフラ上で、次世代の決済アプリケーションを構築することです。このガイドでは、開発者がTempoと技術的に統合する方法、利用可能なリソースやコミュニティ、そしてこの成長するエコシステムに参加する方法について詳述します。

1. 技術統合：L1 Tempoでの構築​

Tempoの中核設計哲学は、Ethereumとの完全な互換性の道を選ぶことで開発者の参入障壁を下げることです。これは、開発者が既存の成熟したツールと知識ベースを使用して構築できることを意味します。TempoのアーキテクチャはReth（Paradigmが主導するEthereumクライアントのRust実装）に基づいており、Ethereumスマートコントラクトとその開発者ツールチェーンと自然に互換性があります。

その主要な技術的特徴と統合ポイントは次のとおりです：

• EVMとスマートコントラクト： TempoはSolidityスマートコントラクトとEthereum Virtual Machine（EVM）を完全にサポートします。開発者は、Hardhat、Truffle、Foundryなどの標準フレームワーク、およびethers.js、web3.jsなどのライブラリを使用して、スマートコントラクトの記述、テスト、デプロイを行えます。Web3開発者にとって、このシームレスな互換性は学習曲線がほとんどないことを意味します。既存のdApp、ウォレット（MetaMaskなど）、開発ツールはTempoで「そのまま」動作し、Ethereumから成熟したアプリケーションの簡単な移行への道筋を築きます。

• 高スループットと確定性： Tempoは決済シナリオの速度要件に向けて深く最適化されています。その設計目標は、**毎秒100,000トランザクション（TPS）**を超える処理能力を達成し、サブ秒決定論的確定性に到達することです。これは、トランザクションが一度確認されると不可逆であることを意味し、従来の確率的確認（Proof-of-Workなど）で発生する可能性のあるトランザクション再編成（reorg）のリスクを排除します。この高いパフォーマンスと確実性は、POS（販売時点）システム、取引所、マイクロペイメントなど、厳格な即時決済要件を持つアプリケーションにとって重要です。

• ステーブルコインネイティブ設計： ほとんどの汎用パブリックチェーンとは異なり、Tempoネットワークはトランザクション手数料（Gas）を支払うために揮発性のネイティブトークンに依存しません。そのネットワークでのトランザクション手数料は、主要なステーブルコイン（USDC、USDTなど）を使用して直接支払うことができます。これを実現するために、プロトコルは自動マーケットメーカー（AMM）を統合し、手数料支払いの「発行者中立性」を確保するために、バックグラウンドで異なるステーブルコイン間のスワップを自動的に処理できます。開発者とユーザーにとって、これは大幅にエクスペリエンスを向上させます。トランザクションコストが法定通貨価値（例：常に約$0.001）に安定して紐付けられ、ネイティブトークン価格の変動による不確実性を回避できるためです。

• 決済指向の機能： Tempoは、金融および決済アプリケーション向けに調整されたいくつかの機能をプロトコルレベルで追加します。これには次が含まれます：

  • 「ペイメントレーン」： 決済タイプのトランザクションを他のタイプのオンチェーン活動（複雑なDeFi操作など）から分離することで、これらのレーンは決済の低レイテンシと高優先度を確保します。
  • ネイティブバッチ転送： Account Abstractionなどの技術を活用し、単一のトランザクションで複数のアドレスへの支払いを効率的に送信することをサポートし、給与や供給業者の支払いなどのシナリオで非常に実用的です。
  • トランザクションメモフィールド： このフィールドはISO 20022金融メッセージング標準と互換性があり、請求書参照番号やコンプライアンスデータなどのメタデータをオンチェーントランザクションに添付できるため、企業の財務調整プロセスが大幅に簡素化されます。
  • オプショナルプライバシー： プロトコルは、商業的に機密な情報を保護するための企業コンプライアンスニーズを満たすオプショナルトランザクションプライバシー機能をサポートします。

• Stripe API経由の統合： Stripeは、Tempoを既存の製品スイートに深く統合し、開発者に2つの統合パスを提供する予定です。1つ目は直接オンチェーン開発で、Web3開発者が慣れ親しんだツールチェーンを使用してTempo上に直接スマートコントラクトをデプロイします。2つ目はStripeの高レベルAPI経由の統合で、これはブロックチェーンの複雑さを完全に抽象化します。例えば、StripeのBridgeプラットフォーム（クロスチェーンステーブルコインフロー用のツール）は、将来Tempoをその中核決済レールの1つとして使用します。開発者は慣れ親しんだStripeのREST APIを呼び出して決済や転送を開始するだけで、Stripeシステムがバックグラウンドで自動的にTempoネットワーク上で実行します。これにより、ノード管理や秘密鍵署名などの基盤的な詳細を心配することなく、ブロックチェーンの速度とコストの利点を享受できます。

2. 開発者ドキュメント、チュートリアル、オンボーディングリソース​

2025年後半現在、Tempoはまだプライベートテストネット段階にあり、公式開発者ドキュメントが活発に作成中です。しかし、Tempoの公式ウェブサイトでは、*「開発者向けの包括的な技術ドキュメントが近日公開予定」*であることが確認されています。

その間、興味のある開発者は以下のチャネルを通じて予備情報を入手できます：

• 公式ウェブサイトとFAQ： Tempoの公式ウェブサイトとそのよくある質問（FAQ）ページを訪問することで、その設計哲学、中核機能、汎用ブロックチェーンとの違いについて高レベルの概要を得られます。
• テストネットアクセスの申請： 興味のある開発者や企業は、Tempoウェブサイト（partners@tempo.xyz）で提供されているチャネルを通じて申請を送信し、初期の探索とプロトタイピングのためにプライベートテストネットへのアクセスを得ることができます。

Stripeの開発者エクスペリエンスへの一貫した焦点に基づいて、公式ドキュメントがリリースされた際には以下のリソースが含まれることが期待できます：

• 入門ガイド： 開発者が開発環境をセットアップし、Tempoテストネットに接続し、最初のスマートコントラクトをデプロイする方法を案内する詳細なチュートリアル。
• APIリファレンスとSDKドキュメント： Stripe API統合パスの完全な技術リファレンス、およびTempoプロトコルとやり取りするためのJSON-RPCエンドポイントのドキュメント。
• チュートリアルとサンプルアプリケーション： Tempo上で一般的な決済アプリケーションを構築する方法を示すオープンソースのサンプルコードとプロジェクト。
• ベストプラクティス： セキュリティ、コンプライアンス、パフォーマンス最適化、その他の分野に関する専門的なアドバイス。

Stripeは明確で高品質なAPIドキュメントで有名であり、Tempoのドキュメントも同じ基準を維持すると考える十分な理由があります。

3. Stripeの開発者エンゲージメントチャネルとコミュニティ​

Stripeには成熟した活発な開発者コミュニティエコシステムがあります。Tempoについて最新情報を得て技術サポートを受けたい開発者には、以下の公式チャネルが利用可能です：

• Stripe Developer Discord： これは12万人以上のメンバーを持つ大規模コミュニティで、Stripeエンジニアが直接参加して質問に答えています。Tempoの最新発表、技術討論、コミュニティサポートはすべてここで見つけることができます。
• オンラインフォーラムとQ&Aプラットフォーム： StripeチームはStack Overflow（stripeタグを使用）とTwitter/X（@StripeDev）に投稿された質問を積極的にモニタリングし、回答しています。
• Stripeブログとニュースレター： これは公式情報、詳細な技術記事、製品アップデートの主要チャネルです。Tempoの主要なマイルストーンとケーススタディはここで公開されます。
• 開発者イベントとウェビナー： Stripeは定期的にオンラインとオフラインのイベントを主催しています。特に、その年次開発者カンファレンスStripe Sessionsは、しばしば主要な製品発表のプラットフォームとなり、将来的にはTempo専用の技術セッションとワークショップを特集する可能性があります。

これらの確立されたチャネルを活用することで、開発者は簡単に情報を得、問題を解決し、Tempoに興味を持つ他の開発者とつながることができます。

4. Tempoエコシステムに貢献する機会​

Tempoが内部インキュベーションプロジェクトからオープンなパブリックネットワークに移行する中で、開発者はアプリケーション構築以外にも様々な方法でエコシステムに参加し貢献することができます：

• オープンソース貢献： TempoはオープンソースのRethクライアントをベースにしており、独自の中核コンポーネントも段階的にオープンソース化されることが期待されています。開発者はコードをレビューし、課題を提出し、改善を提案し、さらにはプロトコルのパフォーマンスとセキュリティを共同で向上させるために直接コードを貢献することもできるでしょう。
• バリデーター参加とネットワークガバナンス： Tempoのバリデーターノードは現在、許可制モデルで創設パートナーによって運営されていますが、長期計画は許可なしモデルへの移行です。その時点で、技術的に有能な開発者や組織は誰でもバリデーターノードを運営し、ネットワークコンセンサスに参加し、ネットワークを保護しながらステーブルコイン形式でトランザクション手数料を得ることができます。ネットワークが分散化するにつれて、コミュニティガバナンスメカニズムも確立され、開発者がプロトコルアップグレードの決定に参加できるようになるかもしれません。
• プロトコル改善提案（TIP）： 開発者は、新機能を提案したり既存メカニズムの最適化を提案するためにTempo改善提案（TIP）を書いて議論することで、EthereumのEIPモデルからインスピレーションを得て、プロトコルの進化に直接影響を与えることができます。
• ハッカソンと開発者チャレンジに参加： StripeとParadigmの両方には開発者イベントをサポートする伝統があります。Tempoの開発者ツールチェーンが成熟すれば、専用のハッカソントラックや賞金チャレンジがあり、開発者がその上でイノベーションを起こすことを奨励することが予見できます。
• コミュニティ教育と知識共有： 初期参加者として、開発者は技術ブログの執筆、ビデオチュートリアルの作成、コミュニティでの質問回答、技術カンファレンスでの講演によって自らの経験と洞察を共有し、開発者コミュニティ全体の成長を支援できます。

Tempoエコシステムは構築の初期段階にあり、開発者が様々な方法で深く関わり、その未来を形作る貴重な機会を提供しています。

5. 開発者向けのインセンティブとグラントプログラム​

現在、StripeはTempo開発者向けのグラントプログラムやインセンティブを正式には発表していません。同時に、Tempoの設計では新しい投機的ネイティブトークンの発行を明示的に除外しています。しかし、これはエコシステムが開発者サポートを欠いていることを意味するものではありません。将来のインセンティブはより多くユーティリティとエコシステム構築に焦点を当てることが予見でき、以下が含まれる可能性があります：

• エコシステムファンド： Stripe、Paradigm、または独立財団によって設立され、Tempoエコシステム向けの重要なインフラ（ウォレット、エクスプローラー、分析ツールなど）や有望なアプリケーションを構築するチームに直接グラントを提供。
• ハッカソン賞金とバウンティ： 競技を通じて開発者にインセンティブを与え、特定機能のオープンソースライブラリ開発などの特定開発タスクにバウンティを投稿。
• パートナーインセンティブ： Tempoをビジネスに統合することを選択する企業パートナーに対して、Stripeは手数料削減、優先技術サポート、共同マーケティング推進などの商業的インセンティブを提供するかもしれません。
• バリデーター報酬： ネットワークが許可なしモデルに移行すれば、バリデーターノードの運営とトランザクション処理により、ステーブルコイン建てのトランザクション手数料から継続的な収入の流れが提供されます。
• 戦略的投資： Tempo上で優秀な製品やサービスを構築するスタートアップに対して、StripeやParadigmからの戦略的投資や潜在的な買収も重要なインセンティブです。

要約すると、Tempoのインセンティブモデルはトークン投機よりも現実世界の価値構築を中心に回ることになります。

6. Tempoに関するイベント、ワークショップ、ミートアップ​

Tempoについて学び、コミュニティとつながりたい開発者は、以下のタイプのイベントに注意を払うことができます：

• Stripe Sessions： Stripeの年次開発者カンファレンスは、Tempoの公式ロードマップと主要アップデートを得るための最重要な場所です。
• Paradigm Frontiers： 最先端の暗号技術の開発者向けにParadigmが主催し、将来のイベントではTempoの詳細な技術セッションとハッカソンチャレンジが含まれる可能性があります。
• フィンテックと暗号業界カンファレンス： Money20/20やConsensusなどの主要カンファレンスでの決済イノベーションに関する議論は必然的にTempoを含み、その市場ポジショニングと商業応用の展望を理解する良い機会となります。
• ローカルミートアップとオンラインウェビナー： Stripeやローカル開発者コミュニティが組織するより小規模なイベントは、より直接的な相互作用と実践的な学習体験を提供することが多いです。
• グローバルハッカソン： ETHGlobalのような大規模なハッカソンイベントでは、将来Tempoがスポンサープラットフォームとして特集される可能性があり、開発者が国際舞台でイノベーションを起こす機会を提供します。

結論​

StripeのTempoブロックチェーンは、従来のフィンテックの厳格さと暗号世界の開放性を融合した、開発者にユニークな交差点を提供します。開発者はそのEthereum互換性を活用して慣れ親しんだツールで迅速に開始することも、StripeのAPIを通じてTempoの強力な機能を既存ビジネスにシームレスに統合することもできます。プロジェクトはまだ初期段階にあり、ドキュメントやサポートプログラムの多くがまだ開発中ですが、StripeとParadigmの強力なバッキングは開発者エクスペリエンスと技術的進歩への高いコミットメントを示しています。既存のリソースを積極的に使用し、コミュニティに参加し、関連イベントに参加することで、開発者は現実世界の決済問題の解決に焦点を当てたブロックチェーンネットワークにおける貴重な初期段階の機会を掴むことができます。

1. 流動性とSui DeFiの成長​

図：Sui の DeFi TVL（青線）と DEX ボリューム（緑棒）は 2025 年第2四半期までに劇的に成長しました。

総ロック価値（TVL）急増： Sui ネットワークの DeFi 流動性は過去 1 年で爆発的に拡大しました。2024 年末の $600M TVL** から、2025 年中頃には **$ 2B 超 に急上昇しました。実際、2025 年 5 月 21 日には $2.55B TVL** のピークを記録し、第2四半期の大半で **$ 2B 超 を維持しました。この 300% + の増加（2025 年第2四半期までの 480% の伸び）により、Sui の TVL は数十億ドル規模に達しました。流動性の増加は $ 1.8B 超の TVL をもたらし、主要な DEX とレンディング プロトコルが牽引しています。

Sui の DEX は $1.2B** 超の取引ボリュームを処理し、流動性提供者は **$ 500M 超の報酬を獲得しました。流動性の増加は $ 102M 超の BTC 系資産が Sui のレンディング プラットフォームに流入したことでも裏付けられます。

2. 主要な DEX とプロトコル​

• Cetus：Sui 上で最大級の AMM として機能し、流動性プールは $ 300M 超をロックしています。集中型流動性提供とマルチプール戦略により、スリッページを最小化しつつ取引手数料を最大化しています。
• Bluefin：高速取引と機関投資家向け機能を提供。第2四半期には Spot 2.0 アップグレードで MEV 抵抗型 RFQ マッチングを実装し、低レイテンシ取引を実現しました。
• Momentum：CLMM（集中型流動性プール）を導入し、資本効率を向上させました。第2四半期には $ 150M 超の流動性を集中させ、スリッページを 0.1% 未満に抑えました。
• Magma：ALMM（適応型流動性マーケットメイカー）を展開し、流動性の動的再配分と低スリッページ取引を実現しました。

2. アカウント抽象化とユーザー体験の向上​

Sui のアカウント抽象化は、ユーザーがウォレットや認証手段をシームレスに切り替えられるように設計されています。これにより、以下が可能になりました。

• ソーシャルログイン：Google、Twitter、Discord などの ID プロバイダーでのサインインが可能です。
• マルチシグウォレット：複数署名者がトランザクションを承認でき、資金の安全性が向上します。
• プラグイン認証：ZK プルーフや生体認証を組み込んだカスタム認証モジュールを簡単に統合できます。

これらの機能により、Sui の DeFi エコシステムは $ 1.8B 超の TVL を達成し、ユーザーエクスペリエンスが大幅に向上しました。

3. 次世代プリミティブとイノベーション​

ネイティブステーブルコイン​

• Agora Finance の AUSD：2024 年末にリリースされた完全 USD バックのステーブルコイン。2025 年第2四半期までに循環供給は数千万単位に達し、規制対応型代替資産として広く採用されました。
• Bucket Protocol の BUCK：過剰担保型ステーブルコインで、USD にペッグされています。2025 年第2四半期には $60M –$ 66M の供給に達し、プロトコル全体の TVL の $ 69M を支えました。
• Ondo Finance の USDY：米国短期国債利回りをトークン化したイールドベアリングステーブルコイン。2025 年までに Sui エコシステム内で $ 200M 超の資産を管理しています。

BTCfi（Bitcoin DeFi）イノベーション​

• Threshold Network の tBTC：2025 年第2四半期に Sui 上でリリースされ、$ 500M 超 の BTC 流動性を提供。ユーザーは BTC をロックせずに 1:1 の tBTC をミントし、貸付や取引に利用できます。
• Stacks の sBTC：2025 年第2四半期までに TVL の 10% 超が BTC 系資産で構成され、$ 102M 超の Bitcoin ベース資産が Sui のレンディング プラットフォームにロックされました。

高性能 DEX と HFT​

• Bluefin Institutional HFT：2025 年第3四半期にインスティテューショナル向け高頻度取引戦略を導入。Sui の並列実行により、取引レイテンシがミリ秒単位に短縮され、MEV 抵抗型 RFQ マッチングが実装されました。

新しい金融商品とパートナーシップ​

• Graviton：シリーズ A で $ 50M を調達し、モジュラー型トレーディング・レンディング・クロスマージニングプラットフォームを構築中。dYdX に匹敵するプロフェッショナル向け DeFi スーパ―アプリを目指しています。
• xMoney / xPortal：Sui ベースの資産で利用できる MasterCard を開発中。小売ユーザーが日常の支払いに暗号資産を使用できるようになります。
• 21Shares：米国で SUI 上場投資信託（ETF）を申請。伝統的投資家に Sui エコシステムへのエクスポージャーを提供します。

4. 開発者コミュニティとエコシステムの活性化​

2025 年中頃、Sui のオープンソース Move エコシステムは週次コミット数とリポジトリフォーク数で Solana と Near を上回り、ツールチェーン、zk‑proof 統合、クロスチェーンプロトコル開発が急増しています。ハッカソンプロジェクトではオンチェーンオプション市場、分散型保険、インテントベース貸付などが試みられ、Lotus Finance が分散型オプション AMM として Q2 にローンチしました。さらに、Google Cloud との提携によりオンチェーンデータインデックスと AI 推論ツールが提供され、AI オラクルを活用した動的価格設定や BTC ステーキングサービス（SatLayer）などの新プリミティブが実装されています。

5. まとめ​

2025 年の Sui DeFi エコシステムは、流動性の拡大、抽象化によるユーザー体験の向上、そして次世代プリミティブの波 によって急速に成熟しています。主要 DEX（Cetus、Bluefin、Momentum）とレンディング プラットフォーム（Suilend、SuiLend など）が深い流動性を支え、アカウント抽象化が新規ユーザー層を呼び込み、ネイティブステーブルコインや BTCfi、先進的 AMM、パーペチュアル・フューチャー、実世界資産トークンが DeFi の可能性を拡大しています。インフラプロバイダー、トラディショナル金融機関、クロスチェーンネットワークとのハイプロファイルなパートナーシップが Sui の勢いをさらに加速させ、2025 年までに リーディング DeFi ハブ としての地位を確固たるものにしています。

出典：

• Sui Foundation – Sui Q2 2025 DeFi Roundup (July 15, 2025)
• Sui Foundation – NEAR Intents Brings Lightning-Fast Cross-chain Swaps to Sui (July 17, 2025)
• Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (May 1, 2025)
• Sui Foundation – All About Account Abstraction (Oct 4, 2023)
• Ainvest News – Sui Network TVL Surpasses $ 1.4B Driven by DeFi Protocols (Jul 14, 2025)
• Ainvest News – Sui DeFi TVL Surges 480% to $ 1.8B... (Jul 12, 2025)
• Suipiens (Sui community) – tBTC Integration Brings Bitcoin Liquidity to Sui (Jul 17, 2025)
• Suipiens – Inside Suilend: Sui’s Leading Lending Platform (Jul 3, 2025)
• The Defiant – Ondo to Bring RWA-Backed Stablecoins onto Sui (Feb 7, 2024)
• Official Sui Documentation – Intro to Sui: User Experience (account abstraction features)

2025年5月7日、EthereumのPectraアップグレード（Prague + Electra）がメインネットにリリースされました。開発者にとって最も目に見える変更の一つがEIP-7702で、これは外部所有アカウント（EOA）が資金を移行したりアドレスを変更したりすることなく、スマートコントラクトロジックを「マウント」できるようにします。ウォレット、dapp、リレイヤーを構築している場合、これはスマートアカウントUXへのより簡単な道筋を提供します。

以下は実装重視の簡潔なガイドです：実際に出荷されたもの、7702がどのように動作するか、純粋なERC-4337よりもいつ選択するべきか、そして今日適用できるコピー&ペースト可能なスカフォールド。

実際に出荷されたもの​

• EIP-7702はPectraの最終範囲に含まれています。 Pectraハードフォークのメタ-EIPは、含まれる変更の中に7702を正式にリストしています。
• アクティベーション詳細： Pectraは2025年5月7日のエポック364032でメインネット上でアクティベートされ、すべての主要テストネットでの成功したアクティベーションに続きました。
• ツールチェーン注記： Solidity v0.8.30は、Pectra互換性のためにデフォルトEVMターゲットをpragueに更新しました。コンパイラとCIパイプラインをアップグレードする必要があります、特に特定のバージョンを固定している場合。

EIP-7702—どのように動作するか（詳細）​

EIP-7702は新しいトランザクションタイプと、EOAがその実行ロジックをスマートコントラクトに委任するメカニズムを導入します。

• 新しいトランザクションタイプ（0x04）： タイプ4トランザクションにはauthorization_listという新しいフィールドが含まれます。このリストには一つ以上の認証タプル—(chain_id, address, nonce, y_parity, r, s)—が含まれ、それぞれEOAの秘密鍵で署名されています。このトランザクションが処理されると、プロトコルはEOAのコードフィールドに委任インジケーターを書き込みます：0xef0100 || address。それ以降、EOAへのすべての呼び出しは指定されたaddress（実装）にプロキシされますが、EOAのストレージとバランスコンテキスト内で実行されます。この委任は明示的に変更されるまで有効です。
• チェーンスコープ： 認証はchain_idを提供することでチェーン固有にできるか、chain_idが0に設定されている場合はすべてのチェーンに適用できます。これにより、ユーザーが各チェーンに対して新しい認証に署名することなく、同じ実装コントラクトを複数のネットワークにデプロイできます。
• 取り消し： EOAを元の非プログラマブル動作に戻すには、実装addressがゼロアドレスに設定された別の7702トランザクションを送信するだけです。これにより委任インジケーターがクリアされます。
• セルフスポンサード vs. リレー： EOA自身がタイプ4トランザクションを送信することも、サードパーティのリレイヤーがEOAの代わりに送信することもできます。後者はガスレスユーザーエクスペリエンスを作成するために一般的です。nonceハンドリングは方法によって若干異なるため、この区別を正しく管理するライブラリを使用することが重要です。

セキュリティモデルの変化： 元のEOA秘密鍵がまだ存在するため、新しい7702トランザクションを送信して委任を変更することで、常にスマートコントラクトルール（ソーシャルリカバリーや支出制限など）を上書きできます。これは根本的な変化です。tx.originを使用してEOAからの呼び出しであることを確認するコントラクトは再監査が必要です、7702がこれらの前提を破る可能性があるためです。フローを適切に監査してください。

7702かERC-4337か？（そして組み合わせるべき時）​

EIP-7702とERC-4337の両方がアカウント抽象化を可能にしますが、異なるニーズに対応します。

• EIP-7702を選ぶべき時…
  • ユーザーに資金を移行させたりアドレスを変更させることなく、既存のEOAに即座のスマートアカウントUXを提供したい場合。
  • 新機能で段階的にアップグレードできるチェーン間での一貫したアドレスが必要な場合。
  • アカウント抽象化への移行を段階的に進めたい場合、シンプルな機能から始めて時間をかけて複雑さを追加する。
• 純粋なERC-4337を選ぶべき時…
  • 製品が完全なプログラマビリティと複雑なポリシーエンジン（マルチシグ、高度な回復など）を最初から必要とする場合。
  • 既存のEOAを持たない新しいユーザー向けに構築している場合、新しいスマートアカウントアドレスと関連する設定が受け入れられる。
• 両方を組み合わせる： 最も強力なパターンは両方を使用することです。EOAは7702トランザクションを使用してERC-4337ウォレット実装をそのロジックとして指定できます。これによりEOAは4337アカウントのように動作し、既存の4337インフラストラクチャによってバンドル、ペイマスターによるスポンサー、処理が可能になります—すべてユーザーが新しいアドレスを必要とすることなく。これはEIPの著者によって明示的に推奨される前方互換パスです。

適用可能な最小限の7702スカフォールド​

実装コントラクトとそれを有効化するクライアントサイドコードの実用的な例を以下に示します。

1. 小さく監査可能な実装コントラクト​

このコントラクトコードは指定されるとEOAのコンテキスト内で実行されます。小さく監査可能に保ち、アップグレードメカニズムの追加を検討してください。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice EIP-7702で指定された時にEOAコンテキストから呼び出しを実行します。
contract DelegatedAccount {
    // 他のコントラクトとの衝突を避けるためのユニークなストレージスロット。
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // オプション：特定の関数を呼び出せるユーザーを制限するチェックを追加。
        _;
    }

    function initialize() external payable onlyEOA {
        // EOAのストレージにシンプルなワンタイム初期化フラグを設定。
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // すでに初期化済みの場合はrevert
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. viemでEOAにコントラクトを指定（タイプ4 tx）​

viemのような現代的なクライアントは、認証に署名してタイプ4トランザクションを送信する組み込みヘルパーを持っています。この例では、relayerアカウントがeoaをアップグレードするためのガスを支払います。

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. リレイヤー（ガススポンサー）とアップグレードされるEOAを定義
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. EOAが実装コントラクトを指す認証に署名
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // EOA自身がこれを送信する場合は追加：executor: 'self'
});

// 3. リレイヤーがタイプ4トランザクションを送信してEOAのコードを設定し、initialize()を呼び出す
const hash = await client.sendTransaction({
  to: eoa.address, // 宛先はEOA自身
  authorizationList: [authorization], // 新しいEIP-7702フィールド
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. これで、EOAは追加の認証なしに新しいロジックで制御できます
// 例えば、トランザクションを実行するには：
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. 委任を取り消す（プレーンEOAに戻す）​

アップグレードを元に戻すには、EOAにゼロアドレスを実装として指定する認証に署名させ、別のタイプ4トランザクションを送信します。その後、eth_getCode(eoa.address)への呼び出しは空のバイトを返すはずです。

本番環境で機能する統合パターン​

• 既存ユーザーのためのインプレースアップグレード： dappで、ユーザーがPectra互換ネットワークにいるかどうかを検出します。もしそうなら、ワンタイム認証署名をトリガーするオプションの「アカウントアップグレード」ボタンを表示します。古いウォレットを持つユーザーのためのフォールバック経路（クラシックなapprove + swapなど）を維持します。
• ガスレスオンボーディング： 初期タイプ4トランザクションをスポンサーするためにリレイヤー（バックエンドまたはサービス）を使用します。継続的なガスレストランザクションには、既存のペイマスターと公開メンプールを活用するためにERC-4337バンドラーを通してユーザー操作をルーティングします。
• クロスチェーン展開： すべてのチェーンで同じ実装コントラクトを指定するためにchain_id = 0認証を使用します。その後、アプリケーションロジック内でチェーンごとに機能を有効または無効にできます。
• 監視可能性： バックエンドはタイプ4トランザクションをインデックス化し、どのEOAがアップグレードされたかを追跡するためにauthorization_listを解析する必要があります。トランザクション後、eth_getCodeを呼び出してEOAのコードが委任インジケーター（0xef0100 || implementationAddress）と一致することを確認して変更を検証します。

脅威モデルとGotcha（これをスキップしないでください）​

• 委任は永続的： EOAの実装コントラクトへの変更を、標準的なスマートコントラクトアップグレードと同じ重要度で扱ってください。これには監査、明確なユーザーコミュニケーション、理想的にはオプトインフローが必要です。新しいロジックをユーザーに静かにプッシュしないでください。
• tx.origin地雷： msg.sender == tx.originを使用してEOAから直接呼び出されたことを確認していたロジックは今では潜在的に脆弱です。このパターンはEIP-712署名や明示的許可リストなど、より堅牢なチェックで置き換える必要があります。
• Nonce計算： EOAが自身の7702トランザクションをスポンサーする場合（executor: 'self'）、認証nonceとトランザクションnonceが特定の方法で相互作用します。リプレイ問題を避けるために、これを正しく処理するライブラリを常に使用してください。
• ウォレットUXの責任： EIP-7702仕様は、dappがユーザーに任意の指定への署名を求めるべきではないと警告しています。提案された実装を検証し、安全であることを確認するのはウォレットの責任です。ウォレット仲介セキュリティのこの原則に従うようにUXを設計してください。

7702が明確な勝利となる場合​

• DEXフロー： マルチステップのapproveとswapはexecuteBatch関数を使用してシングルクリックに結合できます。
• ゲームとセッション： ユーザーが新しいウォレットを作成・資金提供することなく、限られた時間またはスコープでセッションキーのような特権を付与します。
• 企業とフィンテック： スポンサー付きトランザクションを有効にし、会計とアイデンティティのために各チェーンで同じ企業アドレスを維持しながらカスタム支出ポリシーを適用します。
• L2ブリッジとインテント： 異なるネットワーク間で一貫したEOAアイデンティティを持つ、よりスムーズなメタトランザクションフローを作成します。

これらのユースケースは、ERC-4337によって約束された同じコアベネフィットを表していますが、今では単一の認証だけですべての既存EOAで利用可能です。

出荷チェックリスト​

プロトコル​

• ノード、SDK、インフラプロバイダーがタイプ4トランザクションとPectraの「prague」EVMをサポートすることを確認。
• 新しいトランザクションでauthorization_listフィールドを解析するようにインデクサーと分析ツールを更新。

コントラクト​

• 必須機能（バッチング、取り消しなど）を持つ最小限の監査済み実装コントラクトを開発。
• メインネットにデプロイする前にテストネットで取り消しと再指定フローを徹底的にテスト。

クライアント​

• クライアントサイドライブラリ（viem、ethersなど）をアップグレードし、signAuthorizationとsendTransaction機能をテスト。
• セルフスポンサーとリレイの両方のトランザクションパスがnonceとリプレイを正しく処理することを確認。

セキュリティ​

• コントラクトからtx.originに基づくすべての前提を削除し、より安全な代替手段に置き換える。
• ユーザーアドレスでの予期しないコード変更を検出し、疑わしいアクティビティについてアラートするデプロイ後監視を実装。

結論： EIP-7702は、すでに使用されている数百万のEOAに対するスマートアカウントUXへの低摩擦オンランプを提供します。小さく監査された実装から始め、ガスレスセットアップにリレイパスを使用し、取り消しを明確で簡単にすれば、完全なアカウント抽象化の90%の利益を提供できます—アドレス変更と資産移行の痛みなしに。

長年にわたって、Ethereum Name Service（ENS）は多くの人にとって暗号通貨愛好家のためのニッチなツール、つまり長くて扱いにくいウォレットアドレスを人間が読める.eth名に置き換える方法と見なされていました。しかし2025年には、その認識は時代遅れです。ENSは、シンプルな名前をポータブルで検証可能で統一されたアンカーとして、企業のデジタル・プレゼンス全体のプログラマブル・ブランド・アイデンティティの基盤レイヤーに進化しました。

もはや単にbrand.ethの話ではありません。brand.comを暗号通貨対応にし、従業員に検証可能な役割を発行し、単一の真実の正典的ソースを通じて顧客との信頼を構築することです。これは、なぜENSが今重要なのか、そして今日それを実装する方法についての企業向けガイドです。

要約

• ENSは名前（例：brand.ethまたはbrand.com）をウォレット、アプリ、ウェブサイト、検証済みプロフィールデータにマップするプログラマブル・アイデンティティに変換します。
• DNSドメインを放棄する必要はありません：ガス不要DNSSECにより、brand.comはセットアップ時にオンチェーン手数料なしでENS名として機能できます。
• .ethの価格は透明で更新ベース（短い名前ほど高価）で、収益はENS DAOを通じて公共善プロトコルに資金を提供します。
• alice.brand.ethやsupport.brand.comなどのサブ名により、NameWrapper「fuses」と有効期限によって時間制限され制約された役割、特典、アクセスを発行できます。
• ENSはENSv2でコア機能をL2に移行中で、CCIP‑Readを通じた信頼最小化解決により、コスト、速度、スケールにとって重要です。

現代企業にとってENSが重要な理由​

企業にとって、アイデンティティは断片化されています。ウェブサイト用のドメイン名、マーケティング用のソーシャルメディアハンドル、決済や運営用の別個のアカウントがあります。ENSはこれらを統一し、単一で権威あるアイデンティティレイヤーを作成する方法を提供します。

• 統一された人間が読めるアイデンティティ： その中核で、ENSは記憶しやすい名前を暗号学的アドレスにマップします。しかし、その力は単一のブロックチェーンをはるかに超えています。マルチチェーン対応により、brand.ethはBitcoin財務、Solana運営ウォレット、Ethereumスマートコントラクトを同時に指すことができます。ブランドの名前は、web3エコシステム全体での決済、アプリケーション、プロフィールのための単一でユーザーフレンドリーなアンカーになります。

• 深いエコシステム統合： ENSはニッチプロトコルへの投機的賭けではなく、web3プリミティブです。主要ウォレット（Coinbase Wallet、MetaMask）、ブラウザ（Brave、Opera）、分散型アプリケーション（Uniswap、Aave）でネイティブにサポートされています。GoDaddyなどのパートナーがENSを統合するとき、それはweb2とweb3インフラの融合を示しています。ENSを採用することで、ブランドを広大で相互運用可能なネットワークに接続しています。

• 豊富で検証可能なプロフィールデータ： アドレス以外にも、ENS名はアバター、メール、ソーシャルメディアハンドル、ウェブサイトURLなどのプロフィール情報の標準化されたテキストレコードを保存できます。これにより、ENS名は正典的で機械可読な名刺になります。サポート、マーケティング、エンジニアリングツールはすべて同じ検証済みソースから取得でき、一貫性を確保し、ユーザーとの信頼を構築できます。

2つの入り口：.eth vs. "独自DNSを持参"​

ENSの開始は柔軟で、一緒に使用できる（そして使用すべき）2つの主要なパスを提供します。

1. brand.ethを登録​

これはweb3ネイティブなアプローチです。.eth名を登録すると、ブランドのエコシステムへのコミットメントを示すクリプト・ネイティブ資産が得られます。プロセスは直接的で透明です。

• 明確な料金スケジュール： スクワッティングを防ぎプロトコルに資金を提供するため、料金はETHで年間支払われます。価格は希少性に基づきます：5文字以上の名前はわずか年5ドル、4文字の名前は年160ドル、3文字の名前は年640ドルです。
• プライマリ名の設定： brand.ethを所有したら、会社のメインウォレットの「プライマリ名」（リバースレコードとも呼ばれる）として設定する必要があります。これは、ウォレットとdappsが長いアドレスの代わりに記憶しやすい名前を表示できる重要なステップで、ユーザーエクスペリエンスと信頼を大幅に向上させます。

2. ENS内でbrand.comを強化（移行不要）​

貴重なweb2ドメインを放棄する必要はありません。ガス不要DNSSECという機能のおかげで、既存のDNSドメインを暗号ウォレットにリンクし、完全に機能するENS名に効果的にアップグレードできます。

• オーナーにとってゼロ・オンチェーン・コスト： このプロセスにより、brand.comはドメイン所有者がオンチェーン取引を送信することなく、ENSエコシステム内で解決可能になります。
• メインストリーム・レジストラー・サポート： GoDaddyは既にこのENS機能を使用したワンクリック「Crypto Wallet」レコードでこれを合理化しています。DNSSECをサポートする他の主要レジストラーもENSと連携するよう設定できます。

実用的なアドバイス： 両方を実行してください。web3ネイティブオーディエンスと財務業務にはbrand.ethを使用します。同時に、ブランドフットプリント全体を統一し、既存のユーザーベースにシームレスな橋渡しを提供するため、brand.comをENSに持参します。

ゼロから1への展開：1週間計画​

ENSの展開は複数四半期のプロジェクトである必要はありません。集中したチームは約1週間で堅実なプレゼンスを確立できます。

• 1〜2日目：名前とポリシー brand.ethを取得し、ガス不要DNSSEC方法を使用して既存のDNS名をリンクします。これは、正典的なスペル、絵文字の使用、正規化ルールについての内部ポリシーを確立する時期でもあります。ENSは名前のバリエーションを処理するためにENSIP-15と呼ばれる標準を使用しますが、ブランドに対するフィッシング攻撃を防ぐためにホモグリフ（似て見える文字）を認識することが重要です。

• 3日目：プライマリ名とウォレット 会社の財務、業務、決済ウォレットについて、treasury.brand.ethまたは類似の名前に解決されるようプライマリ名（リバースレコード）を設定します。この機会を使用して、マルチコインアドレスレコード（BTC、SOLなど）を入力し、ENS名に送信された支払いがチェーンに関係なく正しくルーティングされることを確認します。

• 4日目：プロフィールデータ プライマリENS名の標準化されたテキストレコードを入力します。最低限、email、url、com.twitter、avatarを設定します。公式アバターは、対応ウォレットで即座の視覚的検証を追加します。セキュリティ強化のため、公開PGPキーも追加できます。

• 5日目：サブ名 従業員用のalice.brand.ethや部門用のsupport.brand.comなどのサブ名の発行を開始します。NameWrapperを使用して、例えばサブ名の転送を防ぐセキュリティ「fuses」を適用します。契約終了や従業員離職時にアクセスを自動的に取り消すため、有効期限を設定します。

• 6日目：ウェブサイト/ドキュメント ウェブプレゼンスを分散化します。プレスキット、利用規約、ステータスページをIPFSやArweaveなどの分散ストレージネットワークに固定し、contenthashレコードを通じてENS名にリンクします。ユニバーサルアクセスのため、ユーザーはeth.limoなどのパブリックゲートウェイを通じてこのコンテンツを解決できます。

• 7日目：プロダクトに統合 独自のアプリケーションでENSの使用を開始します。viemとensjsなどのライブラリを使用して名前を解決し、ユーザー入力を正規化し、アバターを表示します。アドレスを検索する際は、ユーザーのプライマリ名を表示するためリバース検索を実行します。ENSv2のL2アーキテクチャに対してアプリが将来対応できるよう、CCIP-Readをサポートするリゾルバーゲートウェイを使用することを確認します。

素早く効果を発揮する一般的パターン​

設定後、ENSは即座に価値を提供する強力で実用的な使用例をアンロックします。

• より安全でシンプルな支払い： 長くエラーが起こりやすいアドレスをコピー・ペーストする代わりに、請求書にpay.brand.ethを載せます。すべてのマルチコインアドレスを1つの名前の下に公開することで、顧客が間違ったアドレスやチェーンに資金を送信するリスクを大幅に削減できます。

• 真正なサポートとソーシャルプレゼンス： ENSテキストレコードで公式ソーシャルメディアハンドルを公開します。一部のツールは既にこれらのレコードを検証でき、なりすましに対する強力な防御を作成できます。support.brand.eth名は、専用サポートウォレットや安全なメッセージングエンドポイントに直接指すことができます。

• 分散化されたウェブプレゼンス： contenthashを使用してbrand.ethに改ざん証拠のあるステータスページや重要なドキュメントをホストします。リンクがオンチェーンであるため、単一プロバイダーによって削除されることがなく、必須情報により高度な回復力を提供します。

• プログラマブルな組織図： 内部ツールやトークンゲート化チャネルへのアクセスを付与するemployee.brand.ethサブ名を発行します。NameWrapper fusesと有効期限により、組織全体の動的、プログラマブル、自動取り消し可能なアイデンティティシステムを作成できます。

• ガス軽量ユーザーエクスペリエンス： ロイヤリティIDやチケットをサブ名として発行するなどの大量使用例では、オンチェーン取引は遅すぎて高価です。CCIP-Readを使用したオフチェーンリゾルバーを使用します。この標準により、ENS名をL2や従来のデータベースからでも信頼最小化された方法で解決できます。Uniswap（uni.eth）やCoinbase（cb.id）などの業界リーダーは、既にこのパターンを使用してユーザーアイデンティティシステムをスケールしています。

スキップすべきではないセキュリティとガバナンス​

プライマリENS名をプライマリドメイン名のように扱ってください：重要な会社インフラの一部として。

• 「オーナー」と「マネージャー」の分離： これは中核的なセキュリティ原則です。名前を転送する権限を持つ「オーナー」役割は、コールドストレージマルチシグウォレットで保護されるべきです。IPアドレスやアバターなどの日常的なレコードを更新できる「マネージャー」役割は、よりアクセスしやすいホットウォレットに委任できます。この権限分離により、鍵が侵害された場合の爆発半径を大幅に削減できます。

• NameWrapper保護の使用： サブ名を発行する際、CANNOT_TRANSFERなどのfusesをバーンして特定の従業員にロックしたり、CANNOT_UNWRAPでガバナンスポリシーを強制したりするためNameWrapperを使用します。すべての権限は制御する有効期限によって管理され、デフォルトで時限アクセスを提供します。

• 更新の監視： 支払い漏れで.eth名を失わないでください。更新日をカレンダー化し、.eth名には90日の猶予期間があるが、サブ名のポリシーは完全にあなた次第であることを覚えておいてください。

開発者クイックスタート（TypeScript）​

viemなどの現代的ライブラリを使用して、アプリにENS解決を統合するのは簡単です。このスニペットは、名前からアドレスまたはアドレスから名前を検索する方法を示しています。

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
import { normalize, getEnsAddress, getEnsName, getEnsAvatar } from "viem/ens";

const client = createPublicClient({ chain: mainnet, transport: http() });

export async function lookup(nameOrAddress: string) {
  if (nameOrAddress.endsWith(".eth") || nameOrAddress.includes(".")) {
    // 名前 → アドレス（ENSIP-15に従って入力を正規化）
    const name = normalize(nameOrAddress);
    const address = await getEnsAddress(client, {
      name,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    const avatar = await getEnsAvatar(client, { name });
    return { type: "name", name, address, avatar };
  } else {
    // アドレス → プライマリ名（リバースレコード）
    const name = await getEnsName(client, {
      address: nameOrAddress as `0x${string}`,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    return { type: "address", address: nameOrAddress, name };
  }
}