NFT領域のL1リーディングプレイヤーFlowの技術調査 (NBA Top Shot, VIV3 を支える基盤インフラ)

前回の記事では、イーサリアムの課題を解決する新興ブロックチェーン技術 (Polygon, Flow, WAX, Ronin, Palette など) では、第一世代ブロックチェーン、ビットコイン、イーサリアムに続く、次世代ブロックチェーンを取り上げました。今回は、その中でもNFT領域でLayer1ブロックチェーンとしてリーディングプレイヤーのFlow Blockchainについて技術的な調査をしたいと思います。

Flow Blockchain について

Flow Blockchainは、CryptoKittiesで有名な Dapper Labs社によって独自に開発されたLayer1ブロックチェーンです。Layer1ですので、既存のビットコインやイーサリアムといったインフラを1から作る壮大なプロジェクトと言えます。

Flow Blockchainは、CryptoKitties の開発の中、イーサリアムの技術的な課題に直面した経験から、独自インフラを作るに至ったとのことです。CryptoKitties は大ヒットしましたが、その副作用として、当時のイーサリアム上で扱われていた総取引の12%を占めるなど、全ネットワークを詰まらせることになり、 取引手数料が高騰する問題に直面しました。つまり、イーサリアムでは取引処理能力と取引手数料に問題があったのです。

Flow Blockchainを開発する中で重視したポイントは、開発者向けのUX(開発しやすさ)と、ユーザー向けのUX(使いやすさ)の最大化と言われています。Flow上での開発をしやすくすることで多くのサービスが生まれ、ユーザーにとってインフラ側のストレスなくサービスを触ってもらうことを目指しました。具体的には、取引承認を分業する独自の仕組みを提供することで、オープンソース状態を担保しながら、1秒で10万取引を処理し、10秒でチェーン上のフィナリティを達成するに至っています。

現在、Dapper Labs社は、Flow Blockchainの普及活動をしているわけですが、その際アプリのコンテンツ選びはメインストリームを追求しました。メインストリームというのは、これまでがクリプトに詳しいクリプト層がユーザーだったのに対して、クリプトに詳しくなくても利用できる層へのアプローチという意味です。その一環として、世界中に熱狂的なファンを持つNBAへと働きかけ、ライセンス契約の獲得に成功し、2020年10月にNBA・NBA選手協会・Dapper Labs社の共同プロジェクトとしてFlow上の最初のアプリとなるNBA Top Shotをリリースしました。

また、Flow Blockchain は、VIV3 というNFTマーケットプレイスでも基盤インフラとして採用されています。

スマートコントラクトにおいては、依然イーサリアムが大きな存在ではありますが、その課題を解決する次世代ブロックチェーンであるFlowの今後の動向は注目すべきでしょう。

Flow Blockchain の技術的な調査について

次世代ブロックチェーンとして注目されるFlow Blockchainですが、本記事では DApps を構築する観点で、Flow Blockchainをどのように利用するのか、Flowの技術ドキュメントを調べてみたので簡単に解説していきたいと思います。

DAppsを構築する上で、1)スマートコントラクトの実装、2)フロントエンドの実装、3)デプロイ等のツール、の3点について説明します。

スマートコントラクトの実装

イーサリアムと同様、Flowでもブロックチェーン上で動作するプログラムのことをスマートコントラクトと呼びます。特徴的なのは、Flowのスマートコントラクトを記述するのは、リソース指向言語の Cadence（ケイデンス） という独自言語を使用する点です。

イーサリアムでスマートコントラクトを実装する場合 Solidity で記述する人が多いと思いますが、Cadenceでスマートコントラクトを記述するのは、単なる言語の違いではなく、Cadence 独自の設計思想を理解し、その思想に沿った実装をしていくことが必要となります。そのため、ラーニングコストは思っている以上にある気がします。

Cadenceでまず気づくのは、ここのユーザーを表す Account の位置づけがやや異なります。Flowでは、全てのステートは Account 内のストレージに保持され、種類は一つしかありません（イーサリアムのようにEOAとコントラクトアドレスの区別はない）。また、スマートコントラクトは、存在している Account の Storage 内にデプロイされます。コントラクトは、中立な存在ではなく、いずれかの Account の内部ストレージに格納されるのです。

Cadenceで記述されたリソースは、中央集権的に一つのスマートコントラクトが管理するのではなく、個々のアカウントのストレージに保有分のリソースだけが保持されるようになります。イーサリアムでは、ある種中央集権的にデプロイされたスマートコントラクトが全てを管理するのが一般的です。例えば、ERC20トークンのスマートコントラクトは、全トークンホルダーの情報を内部メモリにマッピングテーブルで保持しています。一方で、Cadenceのスマートコントラクトでは、スマートコントラクト自体は所有者のアカウントのストレージにデプロイされ、保有トークン自体はそのトークン保有者のストレージに保持されます。これは、実世界のリアルなモノの感覚と近いのではないでしょうか（分散的な世界の表現）。

また、Account のストレージは、3つの領域に分けられています。常に実体はStorageに配備し、private や public にはその実体へのシンボリックリンクを貼るイメージに近いかと思います。

• Storage: アカウントに紐づく全てのリソースが格納されており、本人のみがアクセス可能
• private: 本人もしくは許可されたアカウントだけがアクセスできる領域 (トークンの引き出し等)
• public: 全てのアカウントがアクセスできる領域 (トークンの預け入れ等)

Cadenceでは、リソースは必ず一つの場所にしか存在せず、意図しないコピーや消失が起こせないようにする仕組みが言語体系に組み込まれています。常にリソースは、どこからどこに移動したのか明示的に記述する必要があります（リソースのコピーはできない）。

これらを見ただけでも Solidity の世界とは結構異なることがわかるかと思います。ただし、上記の点さえ理解しておけば、技術ドキュメントも充実していますし、Flow Tutorialsには、参考になるソースコードもあるので、独自のスマートコントラクトを実装できるのではないでしょうか。

フロントエンドの実装

フロントエンドを開発する上では、Flow App Quickstart が大変参考になります。アカウントのログイン/ログアウトから、既存のスマートコントラクトと通信をして、スマートコントラクトのステータス変更を行うまでのサンプルが載っています。npmで @onflow/fcl というライブラリをインストールすれば、スマートコントラクトとの通信はこのライブラリを経由して行えます。

気になる点としては、上記の@onflow/fclライブラリを利用して、fcl.logIn()やfcl.signUp()を用いて、アカウント作成しようとすると、下のようなポップアップが現れ、アカウント管理のプロバイダが制限される点です。

現在は、Dapperが選択できないため、基本、Blocto にてアカウント作成する必要があるのかと思います。イーサリアムの時には、ウォレットでアカウントを作成し、その秘密鍵を自身で保持して、metamask等でログインしていたので、体験的には大きく異なります。3rd partyのプロバイダに秘密鍵を預けるのは嫌だという声もありそうですが、従来のmetamaskプラグインを利用したアカウント管理はメインストリームにはハードルが高いわけで、これぐらいの落とし所がユーザー体験的には良いのかもしれません。しかし、既存のログイン機構があるサービスでは、どのように認証方法を統合するかはもう少し調べる必要がありそうです。

デプロイ等のツール

実装したスマートコントラクトを実際にデプロイするには、Flow CLI を利用します。CLIツールが充実しているので開発には困らないでしょう。

イーサリアムと同様、スマートコントラクトには特定のメソッドが実行された時などにイベントを発火させることができます。CLIツールを使えば、このイベントをウォッチすることもできそうです。

まとめ

以上、今注目されている Flow Blockchain について、簡単に技術的なチェックをしてみました。

リソース指向言語の Cadence の習得には、そのリソース指向の設計思想についてキャッチアップする必要があるので、多少のラーニングコストはあるとは思いますが、イーサリアムの開発経験豊富な Dapper Labs 社が独自に開発したブロックチェーンなので、示唆に富む仕様かとは思います。一度、触れてみて、アプリ開発に導入するかを検討してみるのも良いのではないでしょうか。