不動産ブロックチェーンの情報ハブ
不動産取引のブロックチェーンのスマートコントラクトをちょっと覗いてみよう!

不動産取引のブロックチェーンのスマートコントラクトをちょっと覗いてみよう!

George
George
Expert - 専門2021年12月20日 00時00分

これまでの投稿では、不動産ブロックチェーンのプロジェクトを多く扱ってきました。一部の読者の方は「不動産のブロックチェーン上での取引を実装したい」と思われているかもしれません。この記事はそんなプロフェッショナルの皆様のための記事です。2回に分けて「不動産取引をスマートコントラクトで実装するとは如何いうことか」について取り扱っていきます。

不動産取引のブロックチェーンのスマートコントラクトをちょっと覗いてみよう!

に引き続き、第 2回目は何の取引が実装されるのか、エキスパートの皆様に詳細の内容をお届けしたいと思います。

取引のスマートコントラクト

スマートコントラクトの中にはさまざまな処理を入れ込む必要があります。今回は比較的簡便なブロックチェーン上での不動産の取引事項を挙げてどのような取引があるのかみていきましょう。それぞれ、下記のようなプロセスに分別されます。

  • 管理企業向け
  • オーナー
  • 賃借人
  • 管理企業向けの関数

  • ステークホルダーの追加処理:シェアホルダー配列にシェアホルダーを追加します引数:シェアホルダーのウォレットアドレス (type: address)
  • ステークホルダーを削除処理:シェアホルダー配列から該当シェアホルダーを削除します引数:シェアホルダーのウォレットアドレス (type: address)
  • 新しい手数料/税率を設定処理:手数料などを変更することができます。引数:パーセンテージ (type: uint8)
  • 収益配分処理:蓄積された資金は、トークン所有者の保有割合に応じて、各シェアホルダーの収益配列に分配されます。また賃料が支払われるたびに、管理企業は収益を得ることができます。引数:N/A
  • 差押処理:運営者は無制限の権利を持つので、すべての利害関係者からすべての資産を差し押さえることができる。シェアホルダーから株を買うためにも使われる引数:① 移動元シェアホルダーのウォレットアドレス (type: address)、② 移動先シェアホルダーのウォレットアドレス (type: address)、③移動するトークン (type: uint256)
  • 基本的にはこの作業ができるアドレスはホワイトリストで限られることになりますので、特定のユーザー以外はこれらの作業はできません。特に設計において最重要箇所は 5番の差押えでしょう。ここをどのように制度上設計するのかが重要です。もしもプラットフォームが DAO のような性質を持った管理主体により運営された場合、この権利を強くし過ぎてしまうと分散の意味がなくなってしまいます。また、4番の収益配分も重要です。

    4番はサンプルのコードを見てみましょう。基本的にコントラクトにたまった値を配分することになります。これは賃料が発生した時に管理者が実行することとなります。\

    function distribute() public onlyManagement{
         uint256 _accumulatedValue = accumulatedValue;
         for (uint256 s = 0; s < shareholders.length; s += 1){
             address shareholder = shareholders[s];
             uint256 _shares = showSharesOf(shareholder);
             uint256 ethToReceive = (_accumulatedValue/(totalSupply))*_shares;
             accumulatedValue = accumulatedValue - ethToReceive;
             revenues[shareholder] = revenues[shareholder] + ethToReceive;
             emit RevenuesDistributed(shareholder, ethToReceive, revenues[shareholder]);
         }
    }
    solidity

    オーナー向け (主要オーナー) の関数

  • 賃借人の決定処理:誰が物件を借りるのかを決めます引数:賃借人のウォレットアドレス (type: address)
  • 期間の決定処理:どの期間物件を貸すのかを決めます引数:最大の月数 (type: unit8)
  • 月額賃料の決定処理:月額の賃料を決定します引数:月額賃料 (type: uint256)
  • このオーナー向けの関数も作り方が複数あります。この決定を下せるオーナーは誰なのでしょうか。具体的にはいくつかの方法が考えられ、その方法は運営企業・プロジェクトの性質を強く反映することになります。

  • 中央集権方の管理企業 (中央集権型 / 委任型)特定のアドレスの保有者のみが命令をくだせれば良い
  • トークンの過半数保有者 / 最大所有者 (株式会社型)トークンの保有数に応じてスマートコントラクトが実施可能かどうかの認可判断がされる
  • DAO (直接投票制 / 間接投票制 など、主に分散型)投票コントラクトでステークしているトークンに応じて実施を決定
  • ここで、期間の決定の関数を見てみましょう。面白いところは、 rentalLimitBlocks の部分です。引数で決定した期間 (30日スパン) に 30日で生成されるブロック数をかけています。これによって、特定のウォレットアドレスを持つ賃借人がいつまで借りられるのかを時間軸で表すことができます。このサンプルでは過半数のトークンを持つ人が主要オーナーとして主張し、さまざまなことを決定できる設計にします。そのためオーナーのみこのアクションができるようになっています。

    function limitAvancedRent(uint8 _monthsToLimit) onlyOwner public{
      rentalLimitBlocks = _monthsToLimit * blocksPer30Day;
      emit PrePayRentLimit (_monthsToLimit);
    }
    solidity

    オーナー向け (一般オーナー) の関数

    一般的なオーナー、特にトークンのトレードと分配益の受益を主たる目的として物件を所有するオーナー向けの関数になります。

  • 持分の販売(オファー)処理:シェアホルダーは特定の価格でトークンを販売することができます引数: トークン数 (type: uint256)、価格 (type: uint256)
  • 持分の購入処理:売り手から売り手価格トークン数 でトークンを買うことができます引数: トークン数 (type: address)、取得元アドレス (type: address)
  • トークンの転送処理:トークンの転送に使います。直接も使えますが、一般的には 2. 持分の購入 の関数や 5. 引き出し の関数から呼び出され、利用されます。引数:転送されるアドレス (type: address)、トークン数(type: uint256)
  • 所有権のクレイム処理:50% 以上のトークンを持つ人はコントラクトの中で主要オーナーの変数 (例えば mainOwner) に自身のアドレスをセットすることできるようになります。引数: N/A
  • 引き出し処理:トークン保有者が収益を引き出すことができます引数: N/A
  • これらの処理のポイントは 4. 所有権のクレイム です。このサンプルでは過半数のトークンを持った人が物件のコントロールをする権利を得ることができるような設定にしてあります。過半数のトークンを持っていると、オーナーシップ権限を行使することができる特権ユーザー (主要オーナー)になる権利が得られます。一度オーナーシップを取ると該当ユーザーは物件や貸与に関する決定を下せるようになります。

    function claimOwnership () public {
      require(shares[msg.sender] > (totalSupply / 2) && msg.sender != mainPropertyOwner,"エラー, 過半数以上のトークンを持っていないか、もうすでにオーナーです");
      mainPropertyOwner = msg.sender;
      emit MainPropertyOwner(mainPropertyOwner);
    }
    solidity

    賃借人向けの関数

  • 賃料の支払い

    処理:賃料を払います引数:月数 (type: uint8)

  • 最後に賃借人の関数です。賃借人の実装は比較的容易です。賃料の受理と契約期間の確認ができれば OK です。下記のように 占有期間と支払い期間のパラメータがあるとすると、それぞれをチェックして借りることができるか (=払うことができるか) のチェックをすることになります。

    このスマートコントラクトでは自動的に賃貸の権利を与えてしまっていますが、現実を考えると身元確認が必要ですし、2021 年の段階では日本においては電子契約での賃貸は不可能になっています。エージェントを経由せずに自ら賃貸をしたとしても電子契約は不可で紙面による契約が必要不可欠です。一方で無償で貸す使用貸借や、占有せずに一部だけを使う利用契約の場合は電子の契約書でも可能であります。定期借家契約・普通借家契約 の電子化は2022年の 5月より解禁される予定になっておりますので、施行に期待を寄せたいと思います。

    一方で電子契約にしたとしても、これらの契約を結ぶのにスマートコントラクトで十分かというとそうではないので注意が必要です。これらの処理は今後もほぼ確実にオフチェーンで行われていくでしょう。

    //
    // 1次流通市場における初めての契約の場合 (Mint されたばかりの状態)
    //
    // 空き家である場合、借りることができる
    if (paidTo[leaseholder] == 0 && occupiedTo < block.number) {
      paidTo[leaseholder] = block.number + _incrementedBlocks;
      rentFrom = block.number;
    }
    // 空き家でないので、期間が終わった時から借りられる
    else if (paidTo[leaseholder] == 0 && occupiedTo > block.number) {
      paidTo[leaseholder] = occupiedTo + _incrementedBlocks;
      rentFrom = occupiedTo;
    }
    
    //
    // 2次流通市場 における契約
    //
    // 契約中である場合、期間が終わった時から借りられる
    else if ( paidTo[leaseholder] > block.number) {
      paidTo[leaseholder] += _incrementedBlocks;
      rentFrom = occupiedTo;
    }
    // 空き家ではない場合、期間が終わった時から借りられる
    else if (paidTo[leaseholder] < block.number && occupiedTo>block.number) {
      paidTo[leaseholder] = occupiedTo +_incrementedBlocks;
      rentFrom = occupiedTo;
    }
    // 空き家の場合、借りることができる
    else if (paidTo[leaseholder] < block.number && occupiedTo<block.number) {
      paidTo[leaseholder] = block.number + _incrementedBlocks;
      rentFrom = block.number;
    }
    occupiedTo  = paidTo[leaseholder];
    solidity

    まとめ

    この記事ではサンプルの実装を元に、管理企業、オーナー、賃貸人に対する処理を見てきました。スマートコントラクトの実装は非常に重要で、関数ひとつとっても、その企業が本当にやりたいことが見えてきます。もしあなたがプログラムを書かない人だったとしても、Solidity は非常に簡単な言語ですし、If 文、配列、連想配列(Map) さえ理解できれば全ての論理構造を理解できると言っても過言ではありません。また、基本的な所有の移転と支払い部分、投票部分などを含めた分量も少なく、大手企業のスマートコントラクトでも 1000 行いかないものもあります。まだ黎明期の状態ですので頑張って読んでみるのも良いかもしれません。

    一方で最後の章に書いた通り、多くの処理はこれからもオフチェーン上にのってくることでしょう。オフチェーン連携も今後進んでいく分野と目されています。Chainlink など、ブロックチェーンネットワークと外部システムをつなぐミドルウェアの情報もキャッチアップする必要があります。例えば『CitaDAO が Chainlink を統合し、DeFi にトークン化された不動産を導入』のように、オフチェーン連携をプロジェクト開始初期から強固に進めようとしている組織もあります。今後はこういった全体の連携に気を配りながら、各種企業・プレイヤーがどのように戦うもしくは協業する姿勢を見せるのかには注目が集まるところでしょう。

    Read Next