パンダでもわかる miyabi（３）スマートコントラクト

　やるやる詐欺で前回パート２を書いてからもう半年たってしまった。申し訳ない。その間に miyabi の露出もだいぶ進んだと思う。
　うれしいことに何人かの読者のかたからパート3を待っています、という言葉をいただいた。これも miyabi のユニークさが開発者の興味をそそるからだろう。

　さて遅くなってしまったが、miyabi の機能の中で私が一番好きな部分、スマートコントラクトについて説明しよう。
　スマートコントラクト全体について語るのではなく、私が最も好きな部分に、そしてそれこそが miyabi の特徴である部分について語ってみたい。

賢い契約　

　契約という概念は人類の歴史の中で徐々に発達していった。
　近代以前にも契約はあったが、当時の契約とは信義のようなものであった。誰と誰の間の契約なのかは本質的に重要で、その相手が死亡したり、裏切ったりすれば契約の価値はなくなってしまっていた。

　しかし近代に入り、特に金融が発達してくると、人から独立した契約という概念が生まれてきた。この新しい契約は人に縛られておらず、譲渡する事ができた。
　いわゆる債権である。国家が発行すれば国債だし、個人が発行すれば借金の証書となる。

　この概念があったから小判や金貨といった実際に価値のあるものを媒体にせずに、紙幣のようなものを使った経済に移行できたのだ。
　紙でできた紙幣は当初は金（ゴールド）の交換権であったというのは有名な話だろう。
　つまりこの紙を持っていけば中央銀行がゴールドと交換してくれるというわけだ。これはまさに契約だ。紙の持ち主にゴールドを与える。逆いえばゴールドを預かっているのと同じだ。

　これは契約の片方の主体、債権を持つほうが固定されていないからできることだということに注意しよう。
　債権を持つものが誰かは契約で固定されているわけではない。その契約が書かれた紙（契約書）を持っている人が債権を持っているのだ。

　この柔軟性は金融システムをどんどんリッチなものにしていった。例えば国債などには利子があり、定期的に利子を受け取れる。10年国債なら半年ごとに20回そのチャンスがある。そして満期日には額面通りの金額を手に入れることができる。だから21個の権利があるわけだ。だから4回だけ金利を手に入れてから、ほかの人に譲渡することもできる。

　これは権利者が契約に直接書かれていないからできることだ。もし直接記述されていたら、その都度権利者を変更した新しい契約を巻き直さなくてはならないだろう。

スマートコントラクト

　少し前置きが長くなったが、金融のことを語りたいわけではない。
　この譲渡可能な契約という概念は、まさにスマートコントラクトであるといいたいのだ。

　よくスマートコントラクトというと自動販売機の例が使われる。お金を入れてボタンを押せばジュースが出てくる、というわけだ。

　この文脈だと「自動」というところが強調されていると思う。確かにスマートコントラクトの重要な役割は、ブロックチェーンという衆人環視の下で不正なく自動的に処理を行うことであろう。

　しかしそこで終わってしまうのはもったいない。miyabi にはこのもう一つのスマートコントラクトの側面、「譲渡可能な契約」を実現するための機能が詰まっているのだ。

Asset Table 再入門

　miyabi の特徴といえば Asset Table だ。誰でも簡単にコインを作れる。金光さんでも作れる、という動画もあるくらいだ。

　しかし Asset Table はもっとすごい使い方がある。
　それが譲渡可能な契約を作れるということだ。
　Asset Table は譲渡可能な資産を定義できるのであった。だからこの資産と契約を結び付ければいいのだ。

　その方法は miyabi では大きく2つある。

方法１：ACL にスマートコントラクト ID

　１つ目はイーサリウム的な方法である。つまりそのアセットを移動させるときに特殊なことをしたり制限をしたり、あるいは「行使する」という機能を実装する方法である。

　これはそのコインを扱うスマートコントラクトを書けばいい。MoveAssetという名前の関数を書き、From,To,Amount といったパラメータをとり、普通に移動するとともに自分の追加したい機能を追加すればいい。

　例えば有効期限付きのコインを作るような場合にはこの手法が使える。移動するたびに手数料をとるなどもできるだろう。相手が KYC 済みかどうかをチェックするとかもできよう。

　あるいはそのコインを「行使」する、という機能をつけることもできる。行使することで例えば別のアセットを手に入れられる、というようなことが可能だ。

　しかし普通にこのようなメソッドを作っただけではうまくいかない。有効期限の例ではそのメソッドを使わないで直接 Asset Table を操作されてしまえば意味がないからだ。
　そこで miyabi では Asset Table へのアクセスをある特定のスマートコントラクトに制限させる機能がある。やり方は簡単だ。権限は通常 ACL で指定されるが、ここにスマートコントラクト ID を指定するだけだ。そして同時にほかの人からアクセスできないようにする。
　こうすることでまるでイーサリウムのように、その Asset Table はスマートコントラクトに閉じたデータになる。こうすれば MoveAsset するにはこのスマートコントラクトを必ず呼ばないといけない。だからルールを強制できるのだ。
　なおこの場合でも実際に MoveAsset するにはスマートコントラクトの呼び出しトランザクションに、そのコインの持ち主のサインが必要だ。それは背後にいる「理」がそのチェックをしているからで、唯一アクセス権のあるスマートコントラクトだからといって自由に他人の資産を動かせるわけではない。その点はイーサリウムとは大きく違う点だ。

　次に「行使」するとほかのコインが手に入れられる、という例を考えてみよう。
　この場合その新しいコインの AssetTable のテーブルオーナーの ACL にスマートコントラクト ID を指定することで達成できる。
　「行使」メソッドの内部で From に指定されたアドレスから指定の量のコインを例えば Void などに移動させて、代わりに新しいコインを発行してそれを To のアドレスに送るだけだ。
　先ほどの例と同じように「行使」メソッドの呼び出しは From アドレスのオーナーにより署名されなければならない。そうしなければ最初の Void に移動させる部分で失敗するからだ。

　miyabi では ACL にスマートコントラクト ID を指定することができる。この機能を使って柔軟に AssetTable に機能や制約（つまり契約に必要な条件）を追加できることがわかるだろう。

方法２：アドレスにスマートコントラクト ID

　もう一つの方法はスマートコントラクト自身に資産を持たせる方法だ。

　契約の所有者、つまり債権者は何かしらの権利を有するのであった。金本位制ならゴールドを引き出す権利のように。
　しかし方法１で説明したやり方でゴールド引き出しを実装してしまうと、それはつまり無尽蔵にゴールドを引き出せることになってしまう。行使して手に入れるのが全く新しいアセットならあまり問題にならないが、既存のアセットを手に入れるような場合には問題であろう。

　そのような時にはそのスマートコントラクトに、裏付けとなる原資産を持たせればいいのだ。
　つまりゴールドをそのスマートコントラクトに持たせればいい。そして行使時には新しく発行するのではなく、自分の持っているゴールドを移動させるのだ。

　どうやってスマートコントラクトに資産を持たせるかというと、これも簡単。スマートコントラクト ID をあたかもアドレスだと思ってそこに送るだけだ。
　通常 AssetTable ではオーナーの署名がなければコインを移動できないが、オーナーがスマートコントラクトの場合には、そのスマートコントラクトが命令を出せばOK、ということになっている。

　これもイーサリウムではおなじみだろう。イーサリウムのスマートコントラクトも、はた目からはただのアドレスなのでそこに ETH を送ることができ、その ETH はそのスマートコントラクトからしか操作できない。
　しかしイーサリウムだと ETH にしかこれは当てはまらない。そのほかの独自通貨は結局その独自通貨に結びついたスマートコントラクトによって自由に操作できてしまうのだ。miyabi ではこのオーナーチェックが「理」によってされるために、どのような AssetTable でも ETH と同じように扱われる。ここが大きな違いだ。

　さてスマートコントラクトが AssetTable のオーナーになれるというのはほかにもいろいろと応用方法がある。

　例えば借金だ。借金をスマートコントラクトで表現し譲渡可能にした場合、最後に返済をしなければならない。しかし例えば債権者が３人いるような場合だとか、端数は切り捨てになっているだとかの複雑な契約の場合に、債務者がいきなり債権者に返済するのは間違いのもとになる。
　そんな場合にいったんスマートコントラクトに返済する、という方法をとれる。その後ゆっくりとスマートコントラクトが返済処理を行えばよい。この方法なら十分な額を返済できない場合の債権者の優先順位なども、スマートコントラクトで制御することが可能だろう。

　ほかの例ではP2P保険があげられる。
　この保険はあるマラソン大会でけがをした時のための保険で、１００人から５００コインずつ掛け金を集める。期限までに１００人集まらない場合は、出資者に返却する。
　マラソン大会中にけがをした人は自分のけがの証拠とともに保険適用メソッドを呼ぶ。それに対してのこりの９９人は投票を行う。過半数の承認が得られれば、５００００コインが支払われる。誰もケガしなければ出資者に５００コインずつ戻ってくる。

　このような保険も miyabi なら簡単に実装できる。この保険をスマートコントラクトにしてしまえばいいのだ。そして掛け金をスマートコントラクトが直接管理する。
　この場合プログラムにバグがあっても、掛け金の合計以上支払われることはない。例えば２人目のけが人が申請して全員承認したとしても、すでに掛け金はなくなっているので無限に資金が増えるようなことは起きない。
　実際このような特殊な状況をスマートコントラクトが想定しておらず、プログラムに穴があるようなことは起きえるだろう。その時に miyabi であれば掛け金以上の損害は出ないことが保証されるのだ。

まとめ

　miyabi のスマートコントラクトは AssetTable と結びつくことで非常に豊かな表現力を手に入れる。

　これは「譲渡可能な契約」という概念が豊かな概念だからだ。
　この記事を読んでいただいた皆さんも、ぜひ面白い応用方法を見つけていただければと思う。近々ハッカソンをやろうと思っているので、ユニークなアイデアがあればぜひ参戦してもらいたい。

（お知らせ）bitFlyer Blockchainでは仲間を募集しています！