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

Fumiya

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

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

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

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

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

管理企業向けの関数

基本的にはこの作業ができるアドレスはホワイトリストで限られることになりますので、特定のユーザー以外はこれらの作業はできません。特に設計において最重要箇所は 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]);
     }
}

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

このオーナー向けの関数も作り方が複数あります。この決定を下せるオーナーは誰なのでしょうか。具体的にはいくつかの方法が考えられ、その方法は運営企業・プロジェクトの性質を強く反映することになります。

ここで、期間の決定の関数を見てみましょう。面白いところは、 rentalLimitBlocks の部分です。引数で決定した期間 (30日スパン) に 30日で生成されるブロック数をかけています。これによって、特定のウォレットアドレスを持つ賃借人がいつまで借りられるのかを時間軸で表すことができます。このサンプルでは過半数のトークンを持つ人が主要オーナーとして主張し、さまざまなことを決定できる設計にします。そのためオーナーのみこのアクションができるようになっています。

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

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

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

これらの処理のポイントは 4. 所有権のクレイム です。このサンプルでは過半数のトークンを持った人が物件のコントロールをする権利を得ることができるような設定にしてあります。過半数のトークンを持っていると、オーナーシップ権限を行使することができる特権ユーザー (主要オーナー)になる権利が得られます。一度オーナーシップを取ると該当ユーザーは物件や貸与に関する決定を下せるようになります。

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

賃借人向けの関数

最後に賃借人の関数です。賃借人の実装は比較的容易です。賃料の受理と契約期間の確認ができれば 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 は非常に簡単な言語ですし、If 文、配列、連想配列(Map) さえ理解できれば全ての論理構造を理解できると言っても過言ではありません。また、基本的な所有の移転と支払い部分、投票部分などを含めた分量も少なく、大手企業のスマートコントラクトでも 1000 行いかないものもあります。まだ黎明期の状態ですので頑張って読んでみるのも良いかもしれません。

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