不動産ブロックチェーンの情報ハブ
NFTに配当機能をつけてみよう!

NFTに配当機能をつけてみよう!

George
George
Expert - 専門2022年4月14日 00時00分

この記事では不動産NFTをつくる際の配当機能の実装方法について考察していきます。

今回の記事は技術的な内容を含みますがコードはあまり出てきません。主に実装方やロジックや、それに伴う税などの観点にも留意しながらまとめていきますので、不動産NFT化の大枠をつかみたい方は是非お読みください。

以前 ERC-20 で配当を実装する方法をこちらの記事で紹介しました。この方法は単純でわかりやすい一方であくまでもファンジブルトークンであるため以下の様な問題を孕みます。

  • ERC-20 には特定トークン1枚に対する「所有者」という概念がなく、また現在の所有者リストを取得することが比較的面倒
  • トークン所有者および持分にかかるメタ情報をオフチェーンで管理する際、データの管理が複雑になる可能性がある
  • FIATで表せない小数点単位の持分が実現しうるため、永遠に取り戻せない端数が存在しうる
  • 上記で書いたような問題の多くはコントラクトの設計や利用規約で回避は可能。しかし、コントラクトの複雑性が上がるほか、利用規約の導入はクロスプラットフォームやDEXにおける流通の障壁になりうる
  • また不動産持分をNFTとして表現した方が、2022年時点においてはユーザーにとって直感的である可能性にも言及したいと思います。Uniswap のようなサービスで取引をするよりもOpensea などで取引をし、さまざまなプラットフォームで不動産持分の所有を客観的に示せた方が使い勝手が良いかもしれません。

    一方で必ずしも「NFT にしなくても良いのではないか」という意見もあるでしょう。配当金を受け取る文脈だと、流動性プールに仮想通貨を入れた時に受け取る LPトークンはERC-20トークンです。流動性マイニング(イールドファーミング) などで持分にかかる収益を得ることに慣れたユーザーに対して資産を提供したい場合は ERC-20の方が使い勝手が良いですし、DeFi に接続して、もしくは接続された際に小数点以下のトークン持分の所有を表現したい時には ERC-20 が適していると言えます。(ちなみに流動性プールにかんしてはこちらの記事をご覧下さい。)

    また前回の記事ではERC-20で配当機能の実装をしたため、所有持分移転にかかる権利移転を表現するために追加の連想配列(mapping)を要したほか、トークン譲渡の度に保持するデータの更新処理が入ります。ガス代は馬鹿になりませんよね。

    ERC-721 で表現される NFT はそもそも「特定の権利の所有」を表すものであり、最大供給量もファンジブルトークンと比べると比較的少量です。概念として ERC-20 で追加表現しなければいけない部分をスキップした実装にできる可能性があるためガス代も比較的安価になる可能性があります。

    さて、前置きが長くなりましたが、これから ERC-721 での配当機能実装をみてきたいと思います。

    ガス代節約の2つのアプローチと、実装の3パターン

    やはり実装において悩まさせられるのがガス代です。

    ガス代の節約を考えると大きく分けると以下の2つのアプローチがあります。

  • ガス代を仕組み設計で節約する
  • ガス代を技術設計で節約する
  • 仕組み設計で節約する方法は、あくまでも ERC-20 や ERC-721 の基本から大きく外れず、実装も最小限にして、プロセスやフローなどによってガス代を節約するものです。一方で、技術設計で節約することは Meta Transaction を使いリレイヤーに一部の処理を委任することによってガス代を節約することを指しています。

    この記事では、主に仕組み設計とそれにかかる技術的な要素でガス代を節約する方法をみていきたいと思います。

    実装では今回3つのパターンを考えました。

    パターン①: 賃料が発生する度にNFTのアドレスに賃料分のファンジブルトークンを送る。

    パターン②: 賃料が発生する度にNFTの価値が上がっていく (引き出さない前提でオフチェーンに履歴保存)

    パターン③: 賃料が発生する度にスマートコントラクトに賃料が振り込まれ、一旦累積賃料はスマートコントラクトのアドレスに保持される。NFT 所有者は好きなタイミングで収益を引き出せる

    ①は「とりあえずモノを送りつける」パターンで、その反対に③は「引き出さないとモノを取得できない」パターンです。

    ②は①と③の中間に位置し、「実物のモノは送りつけないが、価値の増分だけ概念として送りつける」パターンになっています。

    それぞれを見ていきましょう。

    パターン①: 賃料収入発生の度にNFT所有者のアドレスにファンジブルトークンを送りつける

    一般的な不動産の場合、賃料収入がある度に口座にお金が振り込まれます。これを暗号資産の世界で再現する形で、毎回賃料収入が発生する度に振込のトランザクションが発生することになります。

    メリット

  • 仕組みが非常にわかりやすい。ユーザーはNFTを保持するだけでよい
  • ユーザー側のアドレスに直接仮想通貨がドロップされることになり、ユーザー側のガス代が発生しない
  • デメリット

  • サービス提供側もしくは貸主側に多額のガス代が発生する。結局そのぶんがユーザー側の利益から省かれるためユーザーも被害を被る
  • 所有者が多くなればなるほどガス代は高くなる。
  • NFT が共有持分を表現する場合、このケースにおける発行上限は少なめに設定されることになります。

    5000万円の物件があったとして、1円ごとに分割して最大5000万人がトークンを持つことになるとガス代は膨大になりますが、100万円ごとに分割して最大50人がトークンを持つようにすればガス代は安くなります。ガス代は譲渡する代金の何%という決まり方をしないため、送りつけるパターンの場合は特に上限人数を決める必要が出てきます。

    ちなみに余談ですが、技術的には Solidity の中で mapping を利用してウォレットアドレスに対する所有持分を記録した場合、人数が増えてもそこまでガスが上がることはありません。mapping は Constant time search です。O(1) となるので、オブジェクトの数が増えてもGas代への影響は限定的です。一方で Array は Linear time search であり、O(n) となるので、オブジェクトの数が増えれば増えるほど Gas を使うことになります。

    パターン②: NFT に対する価値の付与 (引き出さない前提でオフチェーンに保存)

    一般的に定期的な賃料収入は、発生する度に銀行口座に振込されたほうが自然な考え方ですが、概念上は NFT に対して「賃料収入発生の都度、付加価値をメタデータとして付与した」と表現をすることは可能です。

    ゲームでも、NFT のパラメータとして情報を更新していくことができますよね。例えば STEPN や Axie Infinity ではレベル上げをしていき NFT の価値を高めることができます。これを不動産の世界でもやってしまおうということです。

    ちなみに、STEPN などのゲームデータはどこに入っているのでしょうか。Solana の Explorer でスニーカーのメタデータを見てみると以下のようになっています。

    次に https://api.stepn.io にホストされているエンドポイントを辿って行ってみましょう。すると以下のページにたどり着きました。つまり、STEPN のスニーカーのデータは最終的に STEPN が運営する中央管理型のDBに溜められていることになります。

    {
      "name": "Sneaker #456347552",
      "symbol": "",
      "description": "NFT Sneaker, use it in STEPN to move2earn",
      "seller_fee_basis_points": 400,
      "image": "https://arweave.net/0x0000000000000000000000000000000",
      "external_url": "https://stepn.com",
      "properties": {
        "files": [
          {
            "uri": "https://arweave.net/0x00000000000000000000000000000000",
            "type": "image/png"
          }
        ],
        "category": "image",
        "creators": [
          {
            "address": "STEPN00000000000000000000000000000000",
            "share": 100
          }
        ]
      },
      "attributes": [
        {
          "trait_type": "Sneaker type",
          "value": "Walker"
        },
        // ...
        {
          "trait_type": "Badge",
          "value": "None"
        }],
      "collection": {
        "name": "Sneaker",
        "family": "STEPN"
      }
    }
    json

    では不動産の場合はどうでしょうか。不動産NFTの場合は「中央管理者に依頼すればいつでも引き出し可能な利益得る権利」が付属するトークンとして流通させることができるかもしれません。

    実物の不動産でローンを組んで物件を購入している場合、不動産所有者は賃料収入をローンの返済に充てなければいけないため、そのためには毎月お金を引き出さなければなりません。しかしNFTとして小口化した場合はその限りではありません。そのため、価値がどんどん膨らんでいくトークンを、その価値ごと流通させることができる可能性があります。

    この場合はそもそも「スマートコントラクト内で利益を引き出す」処理が想定されず、また多くの実装をオフチェーンの中で完結できるので実装が非常に楽になりますし、セキュリティの面でも懸念が比較的少なくなります。このモデルを採用すると一部が中央管理なサービスになってしまうデメリットはありますが、うまくオフチェーンのデータを使うことによってコストをかけずに受益権を仮想的に実現し、お金を管理することができるでしょう。

    しかし上記で述べたメリットは、同時に大きなデメリットでもあることを忘れてはなりません。

    このスマートコントラクト事態に、溜まった利益を引き出す処理を追加導入するのは非常に難しいと考えられます。そもそも中央管理のサーバーでしか配当のステータスが保存されていないため、それらのサーバーとのやりとりが必要になるほか、中央管理のサーバーがハッキング被害にあった場合には目も当てられません。ハッキング対策のためにゼロトラストなクラウドインフラの運用にチャレンジしても良いかもしれませんが、そんなことをするくらいなら、そもそもブロックチェーンではなく全てをRDBで管理すべきでしょう。

    また根本のお話になってしまいますが、「価値の担保」がどの様になされるのかは気になるところです。スマートコントラクトとして引き出す機能が備わっていないほか、価値の担保が中央の管理者の存在に依存する場合、このトークンが客観的に見て安全であるとは言いづらいでしょう。

    STEPN の仕組みををそのまま不動産の世界に持っていくにはもう一捻り必要だと言えます。

    メリット

  • ガス代を抑えることができる
  • デメリット

  • 処理が分散化してないので中央サーバーが単一障害点になりうる
  • スマートコントラクトベースで蓄積された賃料収入の裏付けがないトークンの価値担保に関する課題
  • パターン③: 賃料が発生する度にスマートコントラクトに賃料が振り込まれ、一旦累積賃料はスマートコントラクトのアドレスに保持される。NFT 所有者は好きなタイミングで収益を引き出せる

    パターン③は少し技術的な話題になりますが、NFTで配当機能を実装する場合には一番自然な実装方法になるかもしれません。

    わかりにくい場合は飛ばして最後のメリットの部分だけでも眺めていただけたらと思います。

    筆者が記事執筆時にスマートコントラクトにおける配当の実装について調べていると、一番多かった実装例がパターン③でした。見つかったコードベースの多くは実験の域を出ていませんが、チュートリアルとして図説までされている例として、技術的な面でこちらは比較的参考になるかと思います。

    この実装の難しい点は、不動産の分割所有NFTが100個あった場合、その100人が違うタイミングで引き出すことになるところでしょう。この場合、実装においては以下に留意する必要があります。

    ① NFT所有者100人のうち、一部の所有者は配当を引き出し、一部の所有者は引き出さないため、それぞれ違う(概念上の)残高を同一口座(コントラクト)に所有していることが表現されている

    ② 配列のループを避け、ガスの効率化が実現されている

    ③ 引き出し以外のタイミングにおける配当計算を避け、最低限の回数で配当の実現ができる仕様になっている

    ④ 賃料収入は割り切れない場合がある。適切な演算が組み込まれている(除算の結果、余りを永久に失うなどのミスをしない) → こちらの記事が参考になります

    先ほどの技術記事で紹介したアプローチでは ERC-20を用いていますが、あくまでも所有を表すためにはERC-20 でなくても問題ありません。こちらのサンプルでは不動産を15%所有している人間もいれば、60%所有している人間もいますが、その分割モデルをやめ、NFTとして分割すれば管理や転送が非常に楽になります。パターン②の実装をオフチェーンではなくオンチェーン上で実装するイメージです。

    ERC-721 はもうすでに所有を表す機構が備わっているため、パターン③で ERC-721 の標準に加えて実装すべき部分は非常に限定的です。特筆すべき部分だけ以下にまとめました。

    以下の例ではNFT には ID があります。100人いたとすると、ID は100種類存在することになります。そのため理論上の実装は以下の様になるでしょう。(サンプルの手順を例示しているのでわかりやすい様にケタが大きくなっています)

    スマートコントラクトの初期化処理 (constructor)

  • Token ID と引き出し済み金額のマッピングwithdrawn_dividend_mappingを作成しておく {token_id: withdrawn_amount}
  • 配当予定金の預け入れ処理

  • 0x123... のコントラクトアドレスの transfer() をコールし、100eth を預け入れる
  • スマートコントラクトの transfer() 関数はオーバーライドされており cumulative_dividend_amount 変数を +100 する
  • 配当の引き出し処理

  • 0x456のウォレットアドレスを持ち、配当を受け取る権利を表すNFTの TokenId: 55 をそのウォレットアドレスに所有しているA さんが 0x123... にあるスマートコントラクトの withdraw() をコールし、指定した金額の配当、今回の場合 0.5 を要求する。(A さんはこの時点で 1eth 引き出すことができる)
  • withdraw() 関数では、コール元のウォレットアドレス0x456を引数にbalanceOf()関数をコールし、該当ウォレットアドレスの所有する Token ID を見つけだす。
  • Token ID を見つけ出したらマッピングの値に引き出した金額を追加する。すると {55: 0.5}になる。
  • ①cumulative_dividend_amount / totalSupply() - withdrawn_dividend_mapping[55] つまり100 / 100 - 0 = 1 なので、スマートコントラクトから 1eth を上限としてお金を引き出せることになります。
  • このように、新しい概念としてcumulative_dividend_amountwithdrawn_dividend_mappingを追加するだけで配当機能を表現することができました。こちらの実装で、先述した以下の条件をクリアすることができます。

    ① NFT所有者100人のうち、一部の所有者は配当を引き出し、一部の所有者は引き出さないため、それぞれ違う(概念上の)残高を同一口座(コントラクト)に所有していることが表現されている

    ② 配列のループを避け、ガスの効率化が実現されている

    ③ 引き出し以外のタイミングにおける配当計算を避け、最低限の回数で配当の実現ができる仕様になっている

    また大きなメリットとして、この実装の場合 NFT に配当金を貯めたまま、その累積収益込みで NFT を販売することができるようになります。

    収益を引き出す際に100万円溜まった後に引き出す場合のgas代は、100万円という数字に対してインパクトが少ないですが、5000円だけ収益をあげた後にNFTを手放したい場合、5000円のために数千円の gas代を払うのは非常に馬鹿らしいですよね。それだったら + 5000 円の価値を載せてNFTごと売ってしまう方が手続きも楽ですし全体の手数料も安くなります。

    メリット

  • ガス代を抑えることができる
  • ユーザーは引き出したい時に引き出すことができ、引き出し可能な累積収益をのせたまま NFT を売却することもできる。
  • 処理は分散化されている。
  • まとめ

    ①〜③まで、配当機能を NFT として実装する際のパターンを見てきました。NFT にすると配当昨日の表現は比較的わかりやすく実装できることが示せたと思います。

    NFT にすることでわかりやすく持分を示せるほか、配当を NFTが内部で保持するパラメータの様に貯めていくことで「成長させる」感覚を生み出し、ある種のゲーミフィケーションに繋げることができる可能性があるほか、OpenSea などへの出品も容易になるメリットがあります。

    ここで記事の最初の話題に戻りますが、一方で DeFi への接続を考えた時、ERC-20 での実装も十分考えうることには留意したいと思います。今後DeFi プロトコルがレンディングなどのために用いる資産として、このような不動産裏付けのトークンが選ばれる可能性は十分にあります。その時に一口 50 万からしか買えなかったり、オークション形式でしか入手できなかったり、そもそもファンジブルトークンよりも流動性の低い不動産NFTは敬遠される可能性があるでしょう。もっとも、NFT を裏付けにしたレンディングプロトコルの開発も進んでいるので一概に「できない」とは言えません。

    このように不動産を分割する際に「そのトークンでユーザーに何をさせたいのか」に着目すると自ずとどの標準をつかってトークンを実装するかは見えてくると思われます。 是非皆様も不動産のトークン化をする際には用途をはっきりさせた上で適切な標準を選んでいただけたらと思います。

    Read Next