アート作品の証明書をEthereumで管理するArt Blockchain Networkの設計

Tomohiro Nakamura
10 min readDec 20, 2019

--

この記事はQiita Ethereum Advent Calendar 2019 20日目の記事です。

こんにちは。フリーランスでスタートバーンという会社を手伝っているTomo(Twitter: HAIL)です。この会社はArt Blockchain Networkという、アート作品の所有権、著作権を管理するための証明書をつくるプロジェクトを今頑張っているのですが、今年や来年前半のリリースに向けてdAppsを今まさに作っている方、作ろうとしている方などに参考になるんじゃないかなと思い書くことにしました。ユーザビリティや開発のしやすさを高めるためには色々な側面から設計していかないといけません。読者の方のレベル感次第ですが、そこは知っとるわという場所は読み飛ばしてください。逆に、一個一個について深く深く知りたい方はもっと詳しい記事があるはず! 記事を探すか、大人しくスタートバーンに遊びに来てくださいw

なお、この記事全体に渡って、未リリースのプロダクトについて扱っていますので、あくまで開発途中のものの説明であり、ローンチまでに変わりうるものであることをご理解ください。

基本機能

  • アート作品を登録し証明書を発行できる
  • その証明書を移転することで所有権の移転が行える
  • 決済も管理することが出来る(on-chain in ETH, ERC20 or off-chain in fiat両方あり得る)
  • アーティスト本人やその代理人なども登録していくことにより、自身の作品が売買されたときにその代金の一部が還元されるような設定ができる
  • エンドユーザ(例えばアートを売買する人たち)は秘密鍵の管理に苦しむ必要がないようにする
  • エンドユーザはGas代を気にしなくて良い
  • スタートバーン自社のサービスだけではなく公共物として多くのサービスが利用していく
  • 一部の情報はプライバシーを考慮し秘匿化したい可能性が高い

道具たち

Ethereum

とりあえずなんでEthereumかというところからなのですが、

  1. 上に書いたとおり、様々なサービスが繋がっていくのですが、彼らにとっつきやすいものが良い。また一部のサービスは既にブロックチェーン上にサービスを展開しているものもある。連携していくにあたりなるべく現時点でメジャーなものが望ましい
  2. NFTのスタンダードが定まっている
  3. 美術作品は公共性の高いものであり、公開されたガバナンス体制が望ましい→パブリックチェーンが良い

などのまあ、一般的な理由ですね。今年や、来年の前半から運用をはじめていくなら、Ethereum良いだろうというところです。実際に、Ethereumを利用していることでコラボレーションが実現しそうな相手も見つかったりしています。

何年経ってもEthereumにいるかどうかというのは、まだ分かりません。Web3.0という大局以上の未来はあまり読んでも仕方がないかなと思います。最近もParityがEtehreumクライアントの開発をDAOに移行するわ、という事実上のリソース低減を発表したし、Ethereumの次のバージョンであるSerenityはまだ結構先だしと勿論不安要素もあるものの、後発のブロックチェーンたちもEVM互換性を持とうとしています(例: Substrate)。なので、ひとまず今使っていく分には最適解の1つであり、ただいつ他に移行するとなってもいいように準備やリサーチはしておこうな、という気持ちです。

OpenZeppelin

ERC721はさすがに説明の必要がないとして、OpenZeppelinは少しだけ説明すると、便利な開発用フレームワークと、tokenやmath、cryptographyなどの汎用的なものについて、(メジャーバージョンごととかではあるけど)監査済みコントラクト実装を提供してくれています。例えばERC721Full を継承する形でアート作品用の証明書を管理していくことになると思います。
Ethereumで継続的に改善されていくコントラクトを開発するときに気になるupgradabilityについてもカバーされていますOsukeさんの神ブログを読み、 delegatecall call やStorageの扱い方について理解した上でOpenZeppelinを使っていくのがいいんじゃないでしょうか。

Torus

ユーザの鍵管理どうする問題ですね。まだ人類にはWeb3.0が早いので、Web2.0の世界と繋げてあげないといけません。これを実現する方法はGSNとか色々提案されていますが、ABNではTorusかな〜〜と思っています。取引所用のサービスはもっとあるのですが、汎用的にdAppsで使えるサービスって実はそんなにないんですよね。Upvestなんかはもう一声〜と思いました。

Torusでは、ユーザはGoogleやFacebookなどのいわゆるOAuthログインを用います。なんだそれ中央集権やんけと思うかもしれませんが、まあそうでもない。あくまで秘密鍵へのアクセスにGoogleの認証を使おうという話で、Googleに沢山情報を吸い取られるわけじゃない。
そして、つまりOAuthを利用したCustodianなのかというと、そうでもない(と、少なくとも彼らは主張しているし、まあ同意できるw)。彼らは直接秘密鍵を生で保管しているのではなく、鍵の断片のようなものを分散ノード環境に置き、秘密鍵の漏洩リスクを極小化している。ビザンチン耐性を持った鍵断片管理システム的なものですね。

詳しくは公式より。

Gas代を負担させない(Meta Transaction)

これもよく言われることですが、鍵管理と同様、ユーザにGas代を負担してくれというのはしばしば無茶です。なので肩代わりしてあげる仕組みをMeta Transactionと言ったりします(EIP: 1776)。ユーザはトランザクションをEthereumに直接broadcastする代わりに、肩代わりしてくれるAPIサーバに送り、APIサーバはトランザクションをwrapしbroadcastする。Relayしてくれるコントラクトを経由して相手のコントラクトを叩きます。関数は以下のような感じになるでしょう。

function relayMetaTx(
uint8 sigV,
bytes32 sigR,
bytes32 sigS,
address destination,
bytes memory data,
address sender
) public {

ecrecoverを使って署名の検証(正しく期待しているユーザが署名しているか)を行い、検証された場合に destination.call(data) します。

結構実装方法も様々あるのですが、大事にしたのは汎用性です。叩く先の関数ごとに対応する関数を作るとか、相手のコントラクトごとに作るとかするとこの関数を呼び出すことはもう少し楽になります( relayTokenTransfer みたいなのを個別に作っていって、 data という形式ではなくて、その個別関数のパラメータを生で渡すとか)。でもそれよりも、入り口を一つにするというシンプルさを選択してこれを呼び出すためのサーバなりSDKを作るほうが得策かなというデザインです。

ガバナンス

ABNはスタートバーンのものではなく、参加するサービスを運営する企業みんなで管理するものなので、ガバナンスの仕組みが必要だと考えました。そこで所有権を管理するERC721のトークンとは別に、ERC20のガバナンス用のトークンを発行する予定です。
Tezosなんかもそうですが、スマートコントラクトのアップグレードや、他にも怪しいユーザのbanなど、サービスをまたがり影響を及ぼす意思決定についてはこのガバナンストークンのホルダーの投票により行われる予定です。実装の観点から言えば、重要な関数はガバナンスの投票からしかトリガーできないような modifier をつけておくような形になるでしょう。

コントラクト外観

詳しい説明はABNの詳細仕様の説明を多く含んでしまうのでやめておきますが、独立したOpenZeppelin SDKでデプロイされる塊がToken, Marketなどいくつかの単位であり、それらが互いを必要に応じて参照しあっているような様子がわかります。

プライバシーについて

秘匿化したい情報を含むトランザクションに関しては、まあオフチェーンでの権限管理や計算が妥当だろうなと思います。例えばStripeで決済を行ったとして、決済が行われた事自体はオンチェーンに書き込みたいが、その詳細は一部隠したいとする。そしたらStripeの取引IDのみをチェーン上に記載し、詳細はStripe上での権限の持ち主しか見れないとかすると、さすがにStripe上での情報はそう改ざんされないと考えれば仕様を満たせる。やりすぎると何がパブリックチェーンやねんとなるので、市場ニーズとバランスを気をつけながらという感じですね。後は、Enigma先生の完成が近づいてきていますから、要チェックやでと思っています。プライバシーを考慮した計算は、計算効率を考えて、TEEによる実行が妥当かなあと。

さらに気になる人は是非スタートバーンに遊びに来よう

こういうしっかりとしたdAppsを開発して、実際にコンテンツが載っていく日本発のプロダクトはまだまだ珍しいので、もうちょっと知りたいかも〜と思った人は是非お声がけくださいませ。以下のWantedlyからでもいいし、TwitterのDMやリプとかでもいいです。

それでは!

Merry Christmas and Happy New Year!

--

--