現状のスマートコントラクトの使いどころを考える

ブロックチェーンの使いどころは、多くの方が認識しているかと思います。
・落ちることが許されない
・データが書き換えられていないことが高い確率で保障されている事が必要
・処理量が少なくても許容されるところ
といったところでしょうか。

データとしての質について、補足します。
高価で利害関係者が多い、というだけではありません。
「履歴を前提としている」記録である、という性質です。

説明します。
ブロックチェーンでは修正がなかなかに難しい。
だから、何かを記録してそれが間違っていれば「さっきのは間違い」という記録をして正しい記録を書く、という手順になると認識しています。
（SQLがわかる方向けに書くと、UPDATEはなく、修正の履歴をINSERTするというケースです（最悪DELETE＋INSERTのようなケースでないと親和性がなさそう）UPDATEがあるものでも見せ方次第ですが、頻繁なUPDATEを前提としたものは現状難しそうです）

土地の登記簿なんてものは、この観点からも、ブロックチェーンと非常に相性がいいと思うのです。分筆なども含めて履歴ですから。

今回は現状のスマートコントラクトの使いどころです
先日の「スマートコントラクトのコードは多様であるべきか否か」
では、賃貸契約を例に挙げ、プログラムの使いまわしができるような、単純で使われる数が多い部分からスマートコントラクトが使われていくという予想を立てました。

今回は具体例を他にも挙げていきたいと思います。
さて

こちらの引用リツイート、ドタキャンによる居酒屋の被害を報じる日経新聞さんの記事です。

P2Pで顧客が居酒屋に予約を取るという線が考えられます。
幹事が担保をスマートコントラクト上において予約。居酒屋さんは安心です。
しかしそれでは不十分で、幹事が一人だけ損をする可能性があるのですね。（参加者はバックレ）
だから、
１）参加予定者の担保を集めて幹事に送付
２）幹事は自分のものを加えた担保をもって、居酒屋とP2Pで予約を設定
３）そのまま予約が履行されればOK。キャンセルされた場合も担保があるので現状の「ドタキャンによる損害が補充されない問題」は解決

ツイートで私が書いたのは、ピザ屋さんなどを想定しています。
実際にこういう嫌がらせがあるらしいのです。
名前と住所を知っている誰かがTELを利用してピザでもなんでも、嫌がらせをしたい相手に大量に注文する。
それによって、注文を受けた店（宅配ピザ屋）も、嫌がらせをされる方も損害を受ける、と。

それを今までの流れを踏襲して解決するのであれば
１）TELでの注文時に担保（料金）を供託して注文
２）そのまま物の受け取り確認がされれば担保は料金として店に回収される。いたずらであれば、物は無駄になってしまいますが、担保を回収することで金銭的なダメージは防ぐことができる
という感じです。

どちらも最終決定時のデータ入力に問題は残っています。

居酒屋の場合、元々の契約としてキャンセル料に100％取られない場合が問題となります。
キャンセルする場合、幹事が店にTELでその旨を告げるのが普通でしょう。そこで店側がどういうデータを入力するかです。
当日キャンセルでも20％返金という場合、店側が契約履行というデータを入力すると100％の担保が店側に移ってしまいます。
なので、キャンセルする際に客側がキャンセルという情報の入力を行い、店側がそれを了解するという形になるでしょう。
店側がキャンセルの了解をするのは、客側がキャンセルの情報を入力した後だけにするのですね。

宅配ピザ屋の場合、客が正当な注文をして、店側が物を提供しないうちに「いたずらだった」というデータを入力すると料金だけを盗られてしまいます。
なので、物を配達した際に、客側に「物を受け取った」か「いたずらだった」かのデータを入力してもらう必要があります。
先ほどの居酒屋と同じく、その客側の入力があって初めて店側も徴収を行えるようにします。

この場合、居酒屋と違って登場人物が「いたずらをするもの、されるもの、店」という三人登場します。複雑です。
上記の案は実は解決案になっていません。「いたずらだった」というデータ入力を客側からもらえるとは限らないからです。
つまり、店に対する嫌がらせの場合です。

実際には実店舗の信用というものがあるので考えなくていいことかもしれません。日常を考えるとここまで考えなくていいことかもしれません。

その信用を前提とすると

こういうものがありますので、ピザ屋の場合はスマートコントラクトを使わなくてもいいかもしれません。

しかし、P2Pであり、トラストレスという理念を前提とすると、考えなくてよい事では無いように思います。

上記をそれぞれの企業や契約者がいちいちプログラムを組んでいては面倒です。
なので
１）恐らく民間の業界団体、居酒屋連合やピザ屋連合が「こんな感じの仕組み」と「そこで動くスマートコントラクト」を作り出し
２）「それでやってみるか」と納得した消費者がそれを利用すると決める
３）消費者は担保用（後の料金に変換）に資産をデジタルに換える
４）消費者等が、必要データを入力、担保を供する事などによりスマートコントラクト起動
５）実作業との業務フローは恐らくケースバイケース
という流れで、進んでいくと思います。

多分最初は仕組みが良くなかったりして、作ったプログラムを何回か捨てることになるんだろうな、とは思います。

まとめます。
先日の賃貸契約に加えて、居酒屋の予約やピザ屋での注文を例に具体的に考えてみました。
賃貸契約に比べて、一つの注文の金額が少ないので普及は賃貸契約の方が早いかもしれません。
実際に契約が履行されなくても飲んでしまえる損失額の場合があるからです。
一方で、居酒屋のドタキャンはニュースにまでなっています。かなりの損失が出ていることの証左です。
さらに、金額が少ない＝使われる回数が多い、という事でもあります。洗練されるチャンスは大きいように思います。
（じっくり時間をかければ穴のないプログラムができるかというとそうでもなく、実際に使われないと気付かない穴はあるように思います。）

ではでは
---------------------------------------------------------
・かんがえる、かがんでいる人　
・Steemit 
・Twitter 
----------------------------------------------------------