Tech Do | メディアドゥの技術ブログ 

株式会社メディアドゥのエンジニアによるブログです。

ブロックチェーンとマーケットプレイスの技術選択 ~Part1.Web3の難しさ~

この記事は7月13日に行われたサブカル業界Developers 勉強会 Vol.1にて行われたパネルディスカッションの様子を書き起こした記事になります。

全3パートに分かれており、本記事はその1つ目になります。他のパートについては下記リンク先にてご覧ください。
1. Web3の難しさ
2. ブロックチェーンでコンテンツを扱う難しさ
3. FanTopにおける今後の取り組み

モデレーターとパネリスト

モデレーター

川田 寛(VP of Engineering)
パネリスト
濱口 賢人(シニアエンジニア)・ 菊地 諒(リードエンジニア)

ブロックチェーンをWebサービスで扱う上での課題とは

川田:
ではまず1つ目のテーマとして、Web3の難しさを取り上げたいと思います。Web2.0と言われていた時代では、裏側にRDBMSやKVSのようなストレージがあり、表側には画面を表示するクライアントがあって、その間にアプリケーションが挟まっている、というのがざっくりとした仕組みでした。

Web3では、ブロックチェーンが入ってくることにより、様々な技術課題が出てきたかなと思います。この辺り、まずは濱口さんにお聞きします。メディアドゥのNFTマーケットプレイス「FanTop」ではまさにWebでブロックチェーンを扱っていますが、その上での課題や難しい点はどこにありますか?

濱口:
FanTopでは、ユーザーが獲得したデジタルグッズをNFTとして扱います。Web2.0的な世界観で配信されてきたファイルそのものの販売や、閲覧権限の付与ではなく、デジタル資産として価値が永続化するものとして作っています。

デジタル資産の永続化を実現するために、ブロックチェーンを中心としたシステム設計を行っています。そのブロックチェーン上にデジタル資産となるアイテムの情報や、ウォレットの持ち主であるユーザーを保有者として書き込みます。そうしないとNFT配信として成り立ちません。

Web2.0的な世界観では、ユーザーとコンテンツを結ぶシステム作りのために、データベースやサーバーを構築し、自分たちの手の内で作ります。これは「オフチェーン(ブロックチェーンの外にあるもの)ファースト」と呼びます。それに対して、ブロックチェーンが中心にあり、そこにユーザー情報やデジタルアイテムの情報が書き込まれ、それをオフチェーン側にデータをコピーして利用する考え方を「オンチェーンファースト」と呼びます。

このオンチェーンファーストでシステム設計を行うことで、開発自体のハードルも上がってしまう点が、ブロックチェーンを扱う難しさだと考えています。

川田:
ブロックチェーンでは、従来のWebアプリケーションのようにリアルタイムで応答させることが難しいように思います。実際FanTopを作ってみて、その辺りに難しさを感じましたか?

濱口:
そうですね。例えばMySQLなどのRDBMSでデータ管理をしていて、ユーザーがデジタルアイテムを購入すると、トランザクションを発行してデータを書き込みます。この処理はよほどデータベースが肥大化していない限り、一瞬で処理が完了すると思います。

それに対して、FanTopで採用しているFlowのようなブロックチェーンで一番難しいところは、実際にデータの書き込みを、Flowトランザクションとして発行します。この時、実際にブロックチェーンに書き込まれるまでに数十秒というタイムラグが発生する点です。

そもそもFlowには、ブロックが積み上がっていく速度が2.5秒に1ブロックという制約があります。そのため、データの書き込みや保有権の移動などを依頼するFlowトランザクションは確定するのに数十秒かかります。

そのタイムラグありきのデータ変更を、オフチェーンでいかに円滑に連携するかという点が難しい部分です。

川田:
ありがとうございます。では続いて菊地さんはいかがでしょう。ブロックチェーンをWebプラットフォームで扱う上での課題や悩みはありますか?

菊地:
私が感じているのは、Web3の技術自体の変化がもの凄く早いということです。日々エコシステムが変化しています。そうした状況でスマートコントラクトを開発する際には、その変化に対応し続けないといけません。そこが難しいところだと感じています。

一例ですが、Flowの中で動かすスマートコントラクトでは、Cadenceという言語を利用します。このCadenceの仕様は何度か変更されています。一番大きいものとして、最近Secure Cadenceという機能がリリースされました。これにより、今までコントラクトをメインネットでデプロイする際には、Flowチームのセキュリティチェックが必要だったのですが、誰でもデプロイできるように変更されました。

この変更によって、Cadence言語自体の仕様も変わり、安全性も十分に確保されました。その結果、これまでメインネットで動いていたスマートコントラクトの挙動が全部変わってしまうことになり、1週間くらいで対応しなければなりませんでした。

川田:
なるほど。ブロックチェーンは結構安定して動いているイメージが合ったのですが、破壊的な変更が行われることもあるのですね。

Web3技術について話し合う2人

Web3における認証

川田:
では続いて、ブロックチェーンをWebプラットフォーム上で扱う上で、アーキテクチャにも影響があると思います。この点について印象深いことはありますか?

濱口:
一番大きかったのは、認証の仕組みが従来と全く異なることです。Web2.0の時代では、大抵メールアドレスとパスワードの組み合わせでサーバーにアクセスして、アクセスした人が本人であるというのを確認する流れになっていると思います。

それに対してWeb3では、ユーザーの手元にあるウォレットを使います。ウォレットの中にはペア鍵である秘密鍵/公開鍵の内、秘密鍵が保存されています。その秘密鍵を使って、ブロックチェーンに対するリクエスト内容に署名を行ってアクセスします。それを受け取ったサーバーは、ブロックチェーン上にあるユーザーの公開鍵を取得して、アクセスが本物であるか検証する仕組みになります。これは従来のセッション管理の仕組みとは全く異なる流れです。

こういう部分を踏まえてログインシーケンスを設計したり、先ほどのCadence自体の言語仕様や関連ライブラリのアップデートへの対応などがアーキテクチャに強く影響を与えていると思います。

川田:
メールアドレスとパスワードによる認証や、OAuthなどを使ってログインするのは普通になっていますし、とうに枯れた技術になっていると思います。これは今後も変わらないと思っていたのですが、Web3ではそうもいかないということなのですね。なかなか技術は一つに定まるものではないのだなと感じますね。