Flow ブロックチェーン上で動くアプリを開発する際に、どのようなアーキテクチャにするべきか、いくつかの例を説明します。Ethereum との比較もあるので、Flow だとどのあたりが違うのかがよくわかると思います。

※本記事は、公式ドキュメント「Dapp Architectures on the Flow Blockchain」を日本語に翻訳して、いくつかの補足を加筆したものです。

• **Dapp のアーキテクチャ ・**ノン・カストディアルの Flow Dapp アーキテクチャ ・カストディアルの Flow Dapp アーキテクチャ ・バックエンド・レスの Flow Dapp アーキテクチャ

• **Dapp のインタラクション・シーケンス ・**ノン・カストディアル Dapp の NFT 購入 ・カストディアル Dapp の NFT 購入

• **補足 **・Ethereum Dapp のアーキテクチャ

• Ara による補足

この文書では、Flow ブロックチェーンのアプリが追従できる共通のソリューション・アーキテクチャを紹介します。また、一般的なユーザー・ジャーニーのために、ソリューション・コンポーネント間のインタラクション・シーケンスも示しています。

この文書の読者は、Flow アプリ開発の初期段階にある人です。Ethereum の経験を持つ開発者向けに、Ethereum Dapp のアーキテクチャと Flow Dapp のアーキテクチャの比較も行っています。

この文書は、Flow Developer Onboarding Guide の補助的なガイドとしてお読みください。

この本書では、さまざまなサードパーティーのサービスやソフトウェア・プロダクトについて言及していますが、これらの利用を推奨しているわけではありません。開発者の方は、ご自身のニーズに応じて、これらのプロダクトを評価する必要があります。

ノン・カストディアルの Dapp では、ユーザーは Blocto ウォレットのようなユーザーがコントロールするウォレットに、NFT などの資産を保有できます。

ノン・カストディアルのシナリオでは、アプリ設計において以下の点に注意してください。

• ウォレットとのインタラクション：Flow Client Library（FCL）は、Flow アプリのウォレットとのインタラクションを抽象化します。FCL をインテグレーションすることで、Dapp はウォレットに依存しなくなり、将来的に出てくる FCL 互換ウォレットでも利用できるようになります。

• ブロックチェーンのトランザクションの管理：ユーザーのトランザクションは通常、ウォレットサービスから署名をもらった後、UI クライアントの FCL コードによってブロックチェーンに送信されます。しかし、Dapps のバックエンドからブロックチェーンにトランザクションを送信しなければならない場合もあります（NFT の発行など）。Flow ブロックチェーンとやり取りするための SDK は、コミュニティ運営のものも含めていくつか用意されています。SDK は Flow ブロックチェーンのアクセスノードとやり取りします。スケーラビリティの急増に対応するために、Dapp のバックエンド内にキューイング・インフラ（Pub/Sub や SQS など）を持つことをお勧めします。

Dapp のバックエンドからのトランザクション管理を容易にするサードパーティーのサービスがいくつかあります 。

• Alchemy：Flow ブロックチェーン専用のアクセスノードを取得するために、Alchemy は Flow の Dapp 開発者向けにマネージド・アクセスノード・サービスを提供しています。Alchemy を利用することで、アプリ開発者は、アクセスノードを運営する運用上のオーバーヘッドなしに、Flow の公式アクセスノードのレート制限を回避できます。

• Tatum：Tatum は、Flowアカウントの作成、NFT や FLOW トークンの送付など、高レベルのブロックチェーン操作を Dapps に実行させるための REST API を提供します。場合によっては、Tatum は Flow SDK を使ったり、独自のスマートコントラクトを実装したりする必要性を完全に排除することができます。

• Wallet-API：Wallet-API は、バックエンドでトランザクションと管理者アカウントの鍵を管理するのに便利な方法になりえます。

ブロックチェーン・データへのアクセスと整理：

• Dapps は、Flow ブロックチェーン上の現在および過去のイベントやトランザクションを返すビジネスロジックを持つことが多いです。選択肢のひとつは、イベントを取得して、保持して、インデックスを作成することです。

• 一方で、Graffle や Tatum などのサードパーティ・サービスも REST API を提供しており、イベントやトランザクションなど Flow ブロックチェーンのデータを受け取るためのプログラマティックな通知 / webhook を提供しています。

• 具体的には、Graffle は Flow ブロックチェーン上の過去およびリアルタイムのイベントへの容易なアクセスを提供します。これらのサードパーティ・サービスは、Spork（訳注：定期的に行われる Flow のメンテナンス）を意識する要件から、アプリケーションを引き離すことができます。そうでなければ、過去のブロックチェーン・データを調べる際に、過去の Spork を横断してナビゲートするロジックをアプリケーションに追加しなければなりません。（訳注：過去の Spork に含まれる情報を取得するためには、過去の情報を保持している別の公式アクセスノードを利用する必要があります。）

決済手段（注記：以下の決済手段を選ぶ際、Dapp 開発者は、自身のリーガル/コンプライアンス・デューディリジェンスを行う必要があります）：

• Dapp―ユーザー間の決済：アプリがユーザーに直接商品を販売する場合、以下の 2 つの方式があります。

• クレジットカード / ACH（自動決済機関）：従来の Web 2.0 方式で決済を行い、決済が成功した場合に NFT を送付します。Moonpay（※日本では利用不可）のように、クレジットカードを使って簡単に NFT 購入を可能にするサービスを提供する決済代行会社もあります。

• クリプト決済 / ステーブルコイン決済：ユーザーはウォレットから FLOW トークンや、FUSD などのステーブルコインを使って Dapps に支払うことができます。

• ユーザー間（P2P）決済：P2P 決済（マーケットプレイス型の Dapps でよく見られます）は、ユーザー同士がウォレットに保有する FLOW トークンや FUSD などのステーブルコインを使用して支払いを行います。

カストディアルの Dapps は、ユーザーの Flow アカウントの鍵をバックエンドに保管します。これにより、ユーザーはウォレットアカウントの管理から解放されます。

カストディアルのシナリオでは、Dapp 設計において以下の点に注意してください：

• **ウォレットとのインタラクション：**カストディアル・ウォレットは、外部ユーザーのウォレットと関与しません。アプリのバックエンドは、各ユーザーの Flow アカウントの鍵を保存・管理することによって、各ユーザーの「ウォレット」を保持する必要があります。Flow チームは、カストディアル・ウォレットの管理と、そのトランザクションを送信 / 管理するための「Wallet API」というすぐ使えるソリューションを提供しています。「Wallet API」を使う場合、お使いの UI クライアント / フロントエンドが「Wallet API」用の「FCL shim」とインテグレーションされることになります。これにより、デザイン変更時にカストディ・ウォレットとノン・カストディアル・ウォレットの切り替えを容易に行えます。ユーザーの Flow アカウントの秘密鍵は、常に KMS または同様の安全な Key Vault プロダクトに保管してください。KMS を使うことで、秘密鍵が人の目に触れることがないようにできます。「Wallet API」は、Google Cloud KMS とインテグレーションされています。

• ブロックチェーンのトランザクションの管理：これは、ノン・カストディアルの Dapp アーキテクチャにおける「ブロックチェーンのトランザクションの管理」と全く同じですが、「Wallet API」モジュールがトランザクションの送信 / 管理のためのほとんどの仕事を行います。

• ブロックチェーン・データへのアクセスと整理：ブロックチェーンデータへのアクセスは、ノン・カストディアルの Dapp アーキテクチャと全く同じように行います。

決済手段： これらの決済手段の選択肢のいずれについても、Dapp 開発者は、自身のリーガル / コンプライアンス・デューデリジェンスを行う必要があります。Stripe のような決済プロバイダでは、決済プロバイダの気まぐれで利用できなくなるリスクがあるかもしれません。また、P2P マーケットプレイスをホストする場合、マネー・サービス・ビジネス（MSB）のライセンス問題が発生する可能性があります。

Dapp―ユーザー間の決済：アプリがユーザーに直接商品を販売する場合、以下の 2 つの方式があります。

• クレジットカード / ACH（自動決済機関）：従来の Web2.0 方式で決済を行い、決済が成功した場合に NFT を送付します。

• クリプト / ステーブルコイン：2つの方法があります。 (1) Flow アカウントにクリプト / ステーブルコインを送る：Dapps は Flow アカウントの詳細をユーザーに見せて、ユーザーは MoonPay（※訳注：日本では利用不可）のようなサービスを使ってそのアカウントにクリプト / ステーブルコインを購入・送付します。 **(2) 決済処理業者に直接送る：**アプリの決済処理業者がクリプトを受け入れられる場合、アプリ開発者はユーザーに Flow のアカウント情報を持たせることなく、ユーザーからクリプトで支払いを行うようにさせます。

ユーザー間（P2P）決済：

• **クレジットカード / ACH（自動決済機関）：**この方法では、売り手はサブ・マーチャントとして決済処理業者のシステムに組み込まれ、買い手は決済処理業者を通じてクレジットカードまたは ACH で支払います。決済はすべて法定通貨で行われます。トランザクションが正常に完了すると、NFT だけブロックチェーン上で送付されます。

• **クリプト / ステーブルコイン：**この方式では、買い手は売り手に直接 FUSD や FLOW を送ります。Dapps はユーザーに Flow アカウントの詳細を公開する必要があり、ユーザーは MoonPay のようなサービスを使用してアカウントにクリプト / ステーブルコインを送付します。

いくつかのユースケースでは、開発者はバックエンド・レスな Dapp を作ることができます。バックエンドのない Dapp と対話するために、ユーザーは通常、静的なウェブページと対話します。

このような Dapp では、すべてのビジネスロジックがブロックチェーンのスマートコントラクトとフロントエンドに存在することになります。しかし、Dapp の状態はブロックチェーンに保存されます。過去のブロックチェーン・データを効率的に照会するために、Graffle のような外部サービスを利用できます。

アプリの開発者や管理者は、ブロックチェーンと直接対話しながらアプリの設定や更新を行います。バックエンド・レス型のアプリは、高度な分権化を実現します。アプリの開発者がいなくなっても、ユーザーにサービスを提供し続けることができます。

以下のシーケンス図は、ノン・カストディアル Dapp における、2 つの異なる NFT 購入フローを示しています。

1. NFT の買い手は、アプリの決済処理業者を通じてクレジットカードで支払い、アプリ開発者は法定通貨で支払いを受け取る

2. NFT の買い手は、クリプト / ステーブルコインのトークンを使ってアプリ開発者に支払う

NFT の購入者は、Moonpay、Wyre、Ramp などのサービスを使って、クレジットカードでクリプトを購入することもできます。

上記のシーケンス図は、Blocto ウォレットのモバイルアプリ版とのインタラクションを示しています。Blocto ウォレットはウェブ上からも使用することができ、Dapp の内部で、魅力的なユーザー体験を提供します（**Vault by CNN **を参照）。

以下の図は、カストディアル Dapp の環境においてクレジットカードを使った NFT 購入を示しています。決済処理はオフチェーンで行われ、Dapp は法定通貨で支払い額を回収します。ブロックチェーン上で発生するトランザクションは、NFT の発行（および、在庫を持っている Dapps の場合は保管）と、購入者のアカウントへの送付のみです。

Ethereumは、メジャーな汎用スマートコントラクトのブロックチェーン・プラットフォームの 1 つです。Ethereum 上で開発される Dapps は、主に分権化に重点を置いています。Ethereum の Dapps によくあるパターンと、Flow ブロックチェーンにおける同等のものについて説明します

Ethereum 上に構築された Dapps に共通するテーマ：

• ウォレットとのインタラクション：Ethereum の Dapps の多くは、フロントエンドに web3js ライブラリを採用し、ウォレットとのインタラクションを抽象化しています。web3js のおかげで、アプリは個々のウォレットの複雑さを意識する必要がありません。Flow ブロックチェーンでは、web3js に相当するのは FCL です。

• ブロックチェーンのトランザクションの管理：トランザクションを送信するためのアクセス API を提供する、公式の Ethereum ノードはありません。Ethereum の Dapp プロジェクトは、一般的に自分たちのフルノードを実行しません。その代わりに、Infura（または Alchemy）のようなサービスを利用して、トランザクションを確実に送信・管理します。Alchemy は、Flow ブロックチェーンに対してもサービスを提供している。Tatum と Graffle は、Flow ブロックチェーン上で、Ethereum 上のInfuraと同等のサービスを提供しています。

• ブロックチェーン・データへのアクセスと整理：Etherscan のような成熟したプロジェクトが、Ethereum エコシステムには多数あって、ブロックチェーンのデータを収集、保持、インデックス化し、API を通じてブロックチェーンへのアクセスサービスを提供しています。ほとんどの Ethereum Dapps は、ブロックチェーンへのクエリにこれらのサービスを使っています。Graffle と Flowscan は、Flow ブロックチェーン上の Etherscan に相当するものです。

• 決済手段：分権化を重視する Ethereum の Dapps では、決済のためにステーブルコインなどのトークンを使うことがほとんどです。

下図は、Ethereum Dapp とのインタラクション・シーケンスの例です。

さいごに少しだけ、私の経験による補足と、所感を共有します。

• ノン・カストディアルのところで説明されていた「Wallet API」についてですが、こちらは Go 言語の実装になっており、API のインターフェースは非常に参考になります。しかしながら、そのままプロダクトに利用できるレベルかというと、多少つくりが雑なところもあります。流用する場合は、一定の調査と、場合によっては手直しが必要になるかと思います。また「FCL shim」についてはまだ情報が出たばかりなので、どのようなものが提供されるかは要注目です。

• Alchemy などのノードサービスを使うと、Flow のアクセスノードを用意できますが、少し注意点があります。Flow ではノードの種類が複数あり、アクセスノードだけホストしたとしても、その中で別の種類のノードとやり取りをしている箇所があるため、完全にノードを自分でコントロールできるわけではありません。しかし最近の話題として、Ethereum のアーカイブノードのようなノードを Flow のアクセスノードでも実現できるようにする動きがあるので、今後に期待しています。

• Moonpay が日本でも使えたら・・・と思います。

• Flow で web3.js に相当するものは FCL ですが、個人的には web3.js や ethers.js よりも FCL のほうが抽象度が高く、スマートに実装できると感じます。

• エコシステム的にはまだ未熟なところも多いですが、ものすごいスピードで成長していることを実感しています。

以上になります。読んでいただきありがとうございました。