スマートコントラクトに必要なもの

スマートコントラクトは便利です。
こういうことが起こったらこういう風に動作しなさいと、命令を下せばそのように動くのです。
だから相手に何かを期待しなくても信用しなくても、ただ契約の通りに動きます。

これが、一般的なスマートコントラクトの説明で良いかなぁと思います。

現実はいろいろと違ってきますので、その間を埋めていく説明に入っていきます。

まずは、契約という点です。
「勝手に動いてくれるからオッケーじゃん？」
じゃん！、なんですけども、そうは問屋が卸しません。

契約は文章で書かれておらずプログラミング言語で書かれているからです。

そこから次のような問題が出てきます。
１）契約通りのプログラムが書かれているかという問題
２）プログラムの書き方が正しいかという問題
３）正しいプログラムであったとして、それが実行されているかという問題
４）プログラムを動かしている土台が大丈夫か？という問題
５）契約のきっかけ、動作のトリガーとなるものを上手くとらえられるか問題
６）アップデートがうまくいくのかという問題

それぞれ説明していきます。

１）契約通りのプログラムが書かれているかという問題

まずこちらなんですが、現状のシステム契約においても問題となることが多いです。
定量的に数字で測れる部分はよいのです。「利用者がボタンを押して1秒以内に画面遷移する事」等ですね。
問題は「利用者が便利なボタン配置にしてください」というあやふやで定性的で個人の感覚に依存するようなもの。これは発注した責任者と技術者の意識の差で齟齬が生じることもあれば、一旦はOKした発注元が「利用者からのクレームが多すぎる」という事でやり直しになることだってあり得ます。利用者と作った側の意識の差ですね。

これは画面上の話なので、半ば笑い話の「あるある」で済まされますが、契約となるとそうはいかない。

例えばですよ、実際にニュースになったものですが「道路混雑をトークンエコノミーで解決できないか」というプロジェクトがあるようなのですね。それについては非常にプログラミング化が難しい。
機械学習以上をやらせるにしても、それを判断する人の倫理観や道徳観念に依存し、もっと言えばそれら教育データを作成する集団の価値観が反映されることが考えられます。

「トークンを払えば空いている道を通行する権利を買える。コストを払って快適さを買う。ノンビリでいいやという人はトークンを払わなくていい。
問題がない単純な契約に思えるよ？」

まぁ、読み進めてください。

仰る通り、基本、トークンを払えば空いている道を通る権利が与えられるわけです。
そこに、消防車などの救急車両が出てきたら？
ここは良識ある人でもない人でも、よほど意地悪な人でない限り道を譲るでしょうし、トークンを払わず空いている道を通っても仕方のないものとするでしょう。
では、救急車両で、それが近所でも有名な「死ぬ死ぬおじさん」が呼んだものだったら？つまり、もう死ぬかもしれない、と救急車を呼ぶのだけれど、実際には大したことがなくて、周りが迷惑するだけの人です、困ったものです。
いかがです？その救急車はトークンを払わずに空いている道を通るべきでしょうか？
ですがおじさんにも事情があります。身寄りがいないんですね。「このマンションで人が死んだなんて言われたら、他の人が嫌な気持ちになるだろう？マンションの値打ちだって下がってしまうかもしれない。だからマズいと思ったらつい呼んじゃうんだよ。申し訳ないと思ってる」そんなこと言われたら何も言えませんよね？
いかがです？先ほどと同じ問いを投げかけます。
その救急車はトークンを払わずに空いている道を通るべきでしょうか？

とまぁ、こんな簡単な「トークンを払えば空いている道を快適に通れる権利を買える」という仕組みであっても、例外を考える必要はあります。そしてそれを皆で納得する形に落とし込んでいくにはいろいろと問題があったりします。

現状のシステム開発でも、プログラムのバグではなく仕様設計の段階でのバグ、つまりは必要な機能が漏れているだとかは問題です。
私見では今後も問題になり続けると思いますし、クリプトエコノミクスの観点からも考慮外のエラーとして残り続けると思います。

だからこそ、というのも変ですが、どこまで行っても「人間の仕事」として残る分野だと思います。

２）プログラムの書き方が正しいかという問題

今、話題になっていますね、コード監査というやつです。
プログラムを書いたしテストもした。だけど大丈夫かわからない。
そこで第三者に監査をしてもらって少しでもバグを減らしましょう。
監査をしてもらえればOKというわけではありません。監査でできるのはバグを減らすことだと私は思っています。

具体的にイメージを説明します。
0.1％のバグがあるプログラムを監査します。かけられるリソースによって成果は変わってきます。
多くの人員×多くの時間×多くのノウハウ×適切なコミュニケーション
もう、いう事なしですね。その成果の逆数（×係数、多分係数をかけなくちゃいけないはず）をかければ、最終的なプログラムに残存しているバグが出ます。
（成果は1以上のはずだと思われるので）
つまりは潤沢なリソースを投入しても、バグを0にはできないという事です。
私の私見ですが、バグは事前に見つからないからこそバグなわけで。
だから、実運用に影響が出ないくらいまで下げられれば、後は我慢して使うしかないんじゃないかなぁと思います。

参考としてリンクを貼っておきます。

formalVerificationというのは数学的に、プログラムが仕様書通りの動作をする事を保証するもので、非常に強力だそうです。しかし、それを厳密に取り扱うことができる人は非常に少なく高コストです。

さらに、１）で記述した仕様バグがあれば、この検証自体が無意味です。

３）正しいプログラムであったとして、それが実行されているかという問題

これが今の「監査」というものに欠けているのでは？と勝手に私が危惧しているところです。
ノードを立てた事ある人いますか？
GITHUBからクローン作ってデプロイしますよね？
あれ、全てのノードがやってると思いますか？

ノードがある程度、どこかのコミュニティに支配されている場合、そこだけに出回っているプログラムがあったとして、それは気づかれないかもしれません。
OSSを謳っておきながら、実はクリーンなソースを世に見せつつ、実はFIAT回収を行うための詐欺装置なのかもしれません。

そこまで考えると何を信じればいいのかわからなくなりますが、だからこそ、ノードの分散性、だれもが参加・退出OKで、どの仮想通貨のノードを立ててもOKとなっていることで透明性を出している事の重要性がわかります。

一生懸命仕様を考えました、そのコード監査を行いました。
でも、実際に動いているのは全然違うものでした。

周りには喜劇かもしれませんが、それを信じていた人には悲劇です。
仮想通貨がもたらすトラストレスは、動いているプログラムへのトラストなのです。信頼先が無機物に代わっただけなのですね。

デプロイされているモノを抜いて逆コンパイルして差異がないことを確認するくらいの事はコード監査でやってもいいのかもしれません。

４）プログラムを動かしている土台が大丈夫か？という問題

これについては、何かの独壇場になっていいのか？という話です。
分散分散と言われておきながら、スマコンと言えばETHです。

それはなぜか。
そこは改めて考えてみる必要があるのかもしれません。

ゲームで例えれば、プレイステーションだけがダントツで使われている状況です。SONYがポシャッタら、家庭ゲーム業界が一気にダメになる事を意味します。

マズいでしょう？

今も普通に使われているプログラム言語で、JAVAというものがあります。

このプログラム言語が世に出た際のメリットの一つで「どんなOSでも動く」というものがあるのです。

実は、それまでのプログラム言語では、一回プログラムを書いてもOSや環境に応じて、少し手を加えなくてはいけないことが多かったようです。それが一気に解決した。みんなJAVAで書こう、というわけですね。

そうすると外部環境が変化しても理屈上はプログラムが動く、プログラムに依存していたビジネス活動が保たれます。

私は今後のスマートコントラクトは「一回かいたらいろいろな環境で動く」という仕組みになっていくんじゃないかなぁと思います。

まずは、スマコン自体が実用レベルに達しなければならない？おっしゃる通りです。だったらETHでSolidityやりましょうよ。クリプトゾンビとか。ねぇ？

あ、4章だったか、解凍が間違ってるやつありますよ。REDDITで記事がありました。公式もチェックしてるでしょうから今は直っているかもしれません。

５）契約のきっかけ、動作のトリガーとなるものを上手くとらえられるか問題

所謂オラクル問題です。

似たような話をしてもしょうがありません。買い手ても面白くありませんし。

気温の話をしますね。
真夏の天気ニュース、最高気温なんて聞くと結構驚きますよね。埼玉とか群馬とかどんだけ熱いんだよ、と。内陸部はそういうもんなのかなぁ？なんてひとしきり思います。
実は、聞いた話ですが、気温を測る環境が一定じゃないようなのです。

これじゃぁ、暑くて当然です。

同じことがスマートコントラクトでも起こる可能性があります。

「気温がN℃以上で○○してください」という契約で、その気温を入力される場所は？誰が入力するの？云々。

オラクル問題って大変です。

６）アップデートがうまくいくのかという問題

これは、修正ができない問題、と言い換えてもいいと思います。

何かアプリを出すと、「より良くしたい」と。特にエンジニアなら誰しもがそう思うはずなんです。でも、現状だとなかなか難しい。

その辺りをこちらで見ていただければと思います。

便利なスマートコントラクトですが、問題はあります。

ネガティブな事を言うな！と仰る方がいるかもしれませんが、私の記事で認識できたものがあればそれは一つ良い事なのかなと思います。

本当にネガティブなのは、不都合を見ようとしない事、
不都合を見ても見ないふりをして、解決しようとしない事だと思います。

まぁ、ぼちぼち。

ではでは

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