もし不動産NFTを実装したらこうなるかも Part 1

Fumiya

この記事では「もし不動産NFTを実装したら」を題材に、実装面を見ていきたいと思います。

* この記事の内容は NFT のセキュリティ及び技術基準を保証するものではございません。

不動産をトークンにする際の決め事を整理

不動産をトークンにすることを考える際にいくつか考えることがあります。まずどのチェーンにのせるのか。そしてどのトークン標準をベースに作成するかです。それぞれみていきましょう。

1. チェーンの選定

パブリックチェーンにしてもプライベートチェーンにしても、様々な選択肢があります。選定条件を挙げると枚挙に暇がありませんが、今回は以下の5つの条件のプライオリティを挙げてみます。(順不同です)

①二次流通マーケットへのアクセス

②トランザクションのコストが安い

③トランザクションが高速

④日本市場における対象仮想通貨の流通

⑤実装の容易性

それぞれを解説します。

①は具体的に OpenSea のようなマーケットが存在することで誰もが買いやすくなることが望ましいでしょう。そうなると Ethereum、Polygon、Solana(今後サポート) が有意義な選択肢になります。

②と③に関して考えると Ethereum は選択肢からはずれそうです。不動産商品特性上、高い利回りを削り出すためには手数料を安くする必要があります。せっかくブロックチェーンの採用で経費を削減できるのに高額なガス代がかかっていては本末転倒です。

④に関しては熟考する必要があるでしょう。Web3 ではグローバルな戦いをして然るべきという論説もありますし、それは間違いではないでしょう。ローカルなトークンにした瞬間に市場が一気に小さくなることは言うまでもありません。しかし記事執筆時に盛り上がりを見せている STEPN は日本のユーザーが圧倒的に多いですし、VeryLongAnimals の NFT の所有者の多くは日本人です。このようにある一定のユーザー層を狙いに行く戦略を取るのであれば「日本における話題性」を考えても良いかもしれません。またトークン化する対象はホテルのような利用可能性がある不動産になる可能性もあります。その際には NFT のターゲットは「その施設を利用できる人」がメインターゲットになり得ます。

日本においては Bitcoin や Ethereum の保有者は多いですが、Polygon の Matic や Solana は保有者が比較的少ないと言えるでしょう。

⑤ に関しては、トークンスタンダードを利用した開発およびリファレンスの有無です。スマートコントラクトはブロックチェーンにデプロイした瞬間から攻撃対象になりえます。コードのセキュリティを高めることは最重要な項目ですが、中の実装が複雑になればなるほど脆弱性を孕むことになります。セキュリティを高める良い方法として考えうるのは「シンプルな実装にする」ということですが、それはカスタムの実装部分を最小限にし、先人たちの知恵(スタンダード)を最大限活用することで実現可能です。過去に事例が多い EVM ベースのスマートコントラクトをサポートしているチェーンが望ましいかもしれません。メタデータも必須の情報を除いてオフチェーンに置いておくことが良いでしょう。なお⑤に関しては「Solidity のサンプルコードが多いからコピペできる」ということには必ずしもなりませんのでお間違いのないように。

今回は二次流通マーケットが開かれており、安価・比較的高速で、Solidity での開発ができる Polygon を選んでみます。その場合、OpenSea のテンプレートが GitHub に公開されていたり、OpenZeppelin の GitHub があるのでそれをスタート地点にすることができるでしょう。

2. トークンスタンダードの選定

トークン標準は ERC-20 と ERC-721 以外にもたくさんあります。チェーンを選定した時点で選定できる標準もいくぶんか変わってくるでしょう。例えば、Klaytn のチェーンでは KIP-7 および KIP-17 が存在します。今回は記事の題名からしてノンファンジブルと決め込んでしまっていますが、米不動産ブロックチェーンの RealT のように ERC-20 なファンジブルトークンを採用するのも一つの手段です。 また、それ以外の可能性があるトークンスタンダードを考えると、ハイブリッド型の ERC-1155 を使うのは有効な手でしょう。それ以外には、分割所有を表現する場合にはERC-864 も採用可能です。そして特定のアドレスから定期入金(サブスクリプション)を可能にする ERC-948 を使えばブロックチェーン上での賃貸を実現できるかもしれません。 今回はチェーン選定の⑤に記述したような事例の有無を考え、また Opensea などにおける対応を考え、ERC-721 か ERC-1155 のトークンスタンダードを活用する方向性でいきます。

ではこれから ERC-721 なのか、ERC-1155 なのか決めていきましょう。このことを考えるには「そもそも不動産トークンで何を表現したいのか」を決める必要があります。

いくつかのパターンが考えられますので見ていきましょう。

① 1つの不動産を表す NFT と n個の共同持分を表すファンジブルトークン

概念として1つの不動産がある。それに伴い不動産全体を表す一点物の NFT があり、それを表す ERC-721 トークンが 1 つ存在する。不動産の持分は同価値のERC-20トークンで表現される。

→ 不動産を表す概念と持分の概念が分離

② n個の共同持分を表すファンジブルトークン

概念としてn分割された不動産がある。その分割分の ERC-20 トークンが n個存在する。不動産の持分にかかる表現は ERC-20 トークンにより実現される。

→ ①の概念から不動産を表すERC-721トークンを排除。= 概念として存在することは自明なので省略

③ n個の共同持分を表すNFT

概念としてn分割された不動産がある。それに伴い分割された同価値の不動産持分を表す n 件の NFT があり、それを表す 同価値のERC-721 トークンが n個存在する。不動産の持分にかかる表現は ERC-721 内で完結する。

→ オンラインゲームで1000ユーザーのみが取得対象の限定アイテムを持っているのと同様

④ ホテルの利用権 / 賃貸の利用権を表すNFT

集団投資スキームでトークン化をする場合、不動産特定共同事業法や金融商品取引法における枠組みと同等の枠組みを外観として持つ可能性がある。その場合、トークンの取り回しが法的な観点で非常に難しくなるほか、NFTとしての軽量な取り回しが不可能になることが予想される。それを避けるために「不動産の共同持分」ではなく「月日に対応する利用権」というかたちで権利を分割。

→ 宿泊券をトレードをする概念

特に④は賃貸の他、ホテルなどの事業で活用可能かもしれません。例えばホテルは平日と休日で価格が異なるため、平日と土日祝日で価値の異なる NFT が発行される可能性があります。この場合 ERC-1155 を使うと異なる価値・発行数のトークンを一つにまとめて表現することができます。今回は④番を試してみるので ERC-1155 を検討してみます。ここまで決まったら ERC-1155 のトークンの基本部分を書いてみましょう。ERC-1155 では複数の NFT を作ることができますので、試しに以下のように書いてみました。

// SPDX-License-Identifier: MIT
pragma solidity ^ 0.8.13;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/utils/Strings.sol";

contract ResortMemberships is ERC1155 {
    uint256 public constant SATURDAY = 0;
    uint256 public constant SUNDAY = 1;
    uint256 public constant WEEKDAYS = 2;

    constructor() ERC1155("https://propwavejp.github.io/propwavejp-contents/lets-issue-property-backed-nft-token/metadata/{id}.json") {
        _mint(msg.sender, SATURDAY, 52, "");
        _mint(msg.sender, SUNDAY, 52, "");
        _mint(msg.sender, WEEKDAYS, 260, "");
    } 
    function uri(uint256 _tokenId) override public view returns (string memory) {
	    return string(
		    abi.encodePacked(
                "https://propwavejp.github.io/propwavejp-contents/lets-issue-property-backed-nft-token/metadata/",
		        Strings.toString(_tokenId),
		        ".json"
		    )
	    );
    }
}

スマートコントラクトを Rinkeby のテストネットにデプロイしたら Opensea で確認をします。

ここまでのまとめ

この記事では導入として、どのように不動産のNFTを書き始めるのかを見ていきました。しかし上記で示したスマートコントラクトはただの NFTで、不動産の特性を一つも持っていません。この NFT はアートとしての価値を持たせることはできるかもしれませんが、受益権や会員権、利用権を示すような仕組みが何一つ備わっていないため、このままでは使うことが難しいでしょう。

そのため、実装にあたって次に決めるべき項目は「不動産トークンに何の役割を持たせるか」ということでしょう。トークンは必要最低限の役割を持つべきです。役割が多いからと言って不必要な実装をあれこれ詰め込むのはセキュリティや取り回しの観点で悪手でしょう。

今回のトークン化のテーマは不動産です。その性質上不動産の所有・管理・運営が必要になります。まず、不動産の法的な所有者を定めなければいけないほか、仮想通貨で納税はできないので固定資産税を払うために現金の処理をする人間や銀行口座が必要です。またメンテナンスや清掃などを業者に頼む際に発生したコストや円建ての賃料収入、施設利用にかかる収益に伴う会計処理も必要です。つまるところ、非中央集権型の何がしかのトークンやスマートコントラクトを作っても、オペレーションの一部は個人や法人に依存する可能性が高いことになります。

ここで答えなければならない問いは「どこまでトークン内で完結させることにこだわるのか」ということと「このトークンの利用可能性はプラットフォームや世界を飛び越えても担保されるのか」ということでしょう。こと不動産トークンに限って言えば全ての柔軟性やエコノミクスをトークン内部の実装として完結させる必要はないかもしれません。このことは実装において十分に考える必要があります。

次回の記事では NFT に対してどのような機能を持たせるのかを中心に見ていきたいと思います。