ZmnSCPxj - Smart Contracts Unchained 和訳

2021-02-06 19:00:12

匿名のビットコイン開発者、ZmnSCPxjが2019年に書いた記事が、自分がここ1年くらい感じてたことをきれいに整理できていたので感動し、翻訳して紹介させていただくことにしました。

https://zmnscpxj.github.io/bitcoin/unchained.html

テーマはブロックチェーンを利用しないスマートコントラクトプラットフォームです。
必要なデータは必要な人達だけが検証するclient side validationやレイヤー２などに通ずるアイデアなので、分散化マキシマリストの皆さんは楽しんでもらえると思います。

ちょっと技術的な話です。途中で数式やスクリプトがいくつか出てきますが、理解しなくても大丈夫です。ただ、そんなに難しい話ではありません。

～～和訳～～

はじめに

暗号通貨におけるスマートコントラクトは通常はブロックチェーン上のコンセンサスルールとして実装されてきました。

特に、スマートコントラクト言語のイノベーション(イーサリアムにおけるチューリング完全性によって自爆しうるという悪名高きメタバグ的「イノベーション」を含む)は多くの場合、最小限のプルーフオブコンセプトにさえブロックチェーンが必要でした。(MVPの段階ですらない言語にも当てはまる話です)

新しいブロックチェーンをローンチするには次のうち片方が必要になります：

独自のトークンを発行する
サイドチェーンとなり、既存のトークンを利用する

前者には、本来はトークンがサポートするべきイノベーションの目的自体がトークンをパンプすることだという批判が付きものです。後者には現在(2019年前半)のビットコインだとフェデレーションを使い、事実上メインチェーン上の資金を共同保管する必要があります。

この文章はそれらとは異なる、親となるブロックチェーンには最低限の機能のみを要求し、親となるブロックチェーンのトークンを再利用し、別のブロックチェーンを立ち上げることなく、またカストディアンによる盗難リスクを低減(排除ではない)する方法でスマートコントラクトプラットフォームを実現する提言です。現実的にはデプロイするのにフェデレーションが必要になるかもしれませんが、少なくともとても遅いデータベースを新たに作る必要はありません。

要約

スマートコントラクトプラットフォームがブロックチェーンのコンセンサスルールの一部である必要はありません。
このアイデアの実現も、現実的にはフェデレーションが必要となるでしょう。
このアイデアは通常の「スマートコントラクトを改善した」ブロックチェーンと比べてプライバシー面で優れます。
このメカニズムを使うと、参加者の合意によって違うスマートコントラクト(バグfixが施されたものなど)に乗り換えたり、スマートコントラクトプラットフォーム自体を乗り換えることができます。
2019年4月時点で実装が期待されているSegWit v1の改善によってこのメカニズムは更に改善されます。

エスクロー・プロトコル

エスクローは2-of-3マルチシグを用いて実装することができます。鍵の持ち主は売り手、買い手、エスクローです。

買い手と売り手が出来事に合意した場合は、2者でトランザクションを署名して正しい宛先にトークンを送ります。もし合意が得られない場合はエスクローサービスが仲裁して、トークンの正しい宛先を判断します。

これをエスクロー以外に2名以上いる状況にも適用できるプロトコルに一般化すると、出来事の結末が2つに大別できます：

全参加者がエスクローの仲裁なしに結果について合意する。
参加者のうち1人が異議を唱え、エスクローによる仲裁を依頼する。

2者のケースでは、2-of-3マルチシグが上記のコントラクトを実現する最適の手段でした。参加者がそれより多数の場合、次のいずれかの条件で使用できるスクリプトを使うことができます：

N人の参加者ごとに1つ鍵のあるN-of-Nマルチシグによる署名
エスクローサービスの鍵と、参加者すべてが知るがエスクローサービスは知らない鍵による2-of-2マルチシグによる署名

もしすべての参加者が合意に至ったら、1つ目の条件が満たされます。1人でも異議を唱える場合にはエスクローサービスが呼ばれ、トークンの宛先を判断し、参加者の誰かが参加者全員で共有している鍵を使ってエスクローが返した結果に署名します。

プログラマブル・エスクローサービスとしてのスマートコントラクトプラットフォーム

スマートコントラクトは資金がどのように支払われるかの条件を記述したものです。異議が起こった場合、スマートコントラクトが資金の行き先を決定します。

すると、スマートコントラクトに記載された条件を強制できるプラットフォームは、そのコントラクトの条件に従って誰がトークンを保有しているか判断するエスクローとして働きます。すなわち、スマートコントラクトプラットフォームはプログラマブルなエスクローサービスなのです。

Smart Contracts Unchained、あるいはイーサリアム・ブロックチェーンという無駄

スマートコントラクトプラットフォームは、１から新たなブロックチェーンを実装することなく、単純なスマートコントラクトが使用できる既存のブロックチェーンを使用することができます。

これはプラットフォームを前述したエスクローサービスのための簡単なスマートコントラクトを応用して実装して実現します。

エスクローサービスが保有する鍵は一般的なPay-to-Contractプロトコルを使用して、使用時にコントラクトの内容が改変されていないか検証されるようにします。例えば、スマートコントラクトプラットフォームの公開鍵E、スマートコントラクト自体のシリアル化をs、そして適切な暗号学的ハッシュ関数hを使い、そのコントラクトに使用する公開鍵Tは

T = E + h(E | s) * G

エスクローの秘密鍵をeと置くと、上記のTに対応する秘密鍵tは

t = e + h((e * G) | s)

n人の参加者の公開鍵P1, ..., Pn、そして参加者全員が知るがスマートコントラクトプラットフォームは知らない共有の公開鍵Cを使用すると、コントラクトのスクリプトは

OP_IF
    <n> <P1>...<Pn> <n>
OP_ELSE
    2 <T> <C> 2
OP_ENDIF
OP_CHECKMULTISIG

と表せます。各参加者はコントラクト言語のインタプリタを実行し、結果に合意した場合には各々の秘密鍵で署名します。しかし、もし誰かが異なる結果を主張した場合には、スマートコントラクトと関連する入力値をスマートコントラクトプラットフォームに送付します。プラットフォームはそのコントラクトに対応する鍵で署名し、参加者のうち誰でも共有の公開鍵Cを使ってトランザクションを完成させることができます。

プラットフォームが利益を出すには、おそらく使用のたびに手数料を要求することになるでしょう。

５文字の禁句「Tr*st」

スマートコントラクトプラットフォームは、少なくとも参加者の1名の協力がなければ資金を盗むことができません。完全にTr*stレスとは言えませんが、完全にカストディアルなサービスと比べると軽減されています。

Tr*stの問題はフェデレーション型のサイドチェーンと同様、スマートコントラクトプラットフォームをフェデレーションによって運営することで低減することができます。フェデレーションのメンバーの鍵をそれぞれ上記と同様にコントラクトごとに改変することで、フェデレーションが適切と判断したマルチシグスキームによって署名することができます。

例えば、9-of-12マルチシグによるフェデレーション型のスマートコントラクトプラットフォームはこのようなスクリプトを書くかもしれません：

OP_IF
    <n> <P1> ... <Pn> <n>
OP_ELSE
    <C> OP_CHECKSIGVERIFY 9 <T1>...<T12> 12
OP_ENDIF
OP_CHECKMULTISIG

メリット

このスキームはプライバシーを大幅に向上させます。コントラクトのすべての参加者がコントラクトの結果について合意する場合(これが大多数だと期待される)、プラットフォーム自体すらコントラクトの詳細はおろか存在自体を認知する必要がありません。これと比較して、ブロックチェーンを利用して「改善された」スマートコントラクトシステムにおいて、コントラクトは必ずオンチェーンに記述されることによって全世界の目に晒され、参加者のプライバシーや処理されるトークンのファンジビリティを損ないます。

もう１つのメリットはスマートコントラクトに致命的なバグが発見された場合、参加者が集まってコントラクトを「実行しない」という選択肢を取ることができ、その場合にコントラクト外での合意によって資金を移動することができます。例えば、バグが修正された同一のコントラクトに合意することができます。つまり、コントラクトにバグがあった場合も修正するのにブロックチェーンをロールバックする必要はなく、スマートコントラクトプラットフォームに知らせる必要すらありません。

さらなるメリットはスマートコントラクトプラットフォームが消滅しても大丈夫なことです。プラットフォームがある日消えてしまっても、参加者は全員の合意のもとコントラクト通りのトランザクションを作成できます。もしプラットフォームのコードがオープンソースであれば、新たなスマートコントラクトプラットフォームの実装が立ち上がり、バグがあった場合と同様の方法で参加者は新しいプラットフォームに切り替えることができます。

これらのメリットはすべてスクリプトの最初の条件「全員の合意があれば、プラットフォームの介入なしに何でもできる」が存在することで成立しています。

参加者によって選ばれるフェデレーション

現在フェデレーション式サイドチェーンとして実装されているスマートコントラクトプラットフォームは固定のメンバーの署名に依存しています。

しかし、本稿のメカニズムはブロックチェーンを必要としないため、プラットフォームの参加者全員の合意が必要な巨大なルールセットも必要ありません。

簡単に言うと、このメカニズムではプラットフォームではなく参加者自身がフェデレーションのメンバーを選定することができます。

もしフェデレーションのメンバーの役目を果たしても良いということを表明できれば、コントラクトの参加者はそのような主体からフェデレーションを選定し、十分な合意と見なされる閾値を選択することまでできます。

ビットコインの進歩で更に改善予定

2019年中盤時点でビットコインに今後導入予定の改善によって、Smart Contracts Unchainedのポテンシャルが更に強化されます。

MuSigおよびSchnorr署名

MuSigはthreshold multisignature keysというものの生成を可能にします。これによってm-of-nのフェデレーションをコントラクト上では1つの公開鍵で表現できます。さらに、参加者全員の合意を表すn-of-nマルチシグも1つの公開鍵として表現できます。

Taproot

スクリプトの半分は参加者全員によるn-of-nマルチシグです。もう片方は少し複雑で、シングルシグとthreshold multisignatureからなります(プラットフォームがフェデレーションの場合)。これはTaprootの活用が最適なユースケースです。

Taprootの使用によって、参加者全員の合意が取れた際にはスマートコントラクトプラットフォームを使用したことすら公開されないため、プライバシーが大きく向上されます。

SIGHASH_NOINPUT

参加者の誰かが異議を唱えた場合も、プラットフォームがどのUTXOに異議が唱えられているか知ることがないほうが良いです。SIGHASH_NOINPUTで署名することによって、プラットフォーム側はどのUTXOが支払われているか知る必要はなくなり、コントラクトの内容と入力、そして使用されるUTXOの金額のみを知れば良いことになります。

もしスマートコントラクトプラットフォームの作成した署名がオンチェーンで使用された場合、プラットフォームはブロックチェーン上を監視することでどのUTXOが使用されているか確認できます。

ただし、コントラクトの結果を決定づけるこの署名の存在自体が、参加者全員が自身の鍵でその結果と同一のトランザクションに署名するよう説得することに使えます。UTXOがプラットフォームの署名によって使用可能になったため、署名を拒否しても得られるものはなく、自発的に署名すればプライバシーが得られるからです。

Taproot向けに改変したメカニズム

以上のことから、メカニズムをTaprootアドレスに対して支払うように改変することができます。Taprootアドレスの公開鍵は参加者全員のn-of-nマルチシグであり、Taproot scriptは

<T> OP_CHECKDLSVERIFY <C> OP_CHECKDLS

となります。Tはコントラクトに合わせて改変されたフェデレーションのthreshold multisignature public keyで、Cは参加者全員のみが知る共有の公開鍵です。

結論

Rootstockのようなフェデレーション式サイドチェーンは、主なイノベーションがスマートコントラクトプラットフォームである以上、無駄です。しかしながら、本稿で示したように、フェデレーションはブロックチェーンほど非効率的なものを新たに実装することなくスマートコントラクトプラットフォームの役割を果たすことができます。代わりにビットコイン・ブロックチェーンを改変せずに使用することができるのです。更に、プライバシーやコントラクトのアップデートなどの面でのメリットは、フェデレーションによってコントロールされていないとされるイーサリアムの存在意義に疑問を呈します。

Liquidは少なくとも本稿の仕組みでは実現できない秘匿トランザクションやアセットを扱えます。しかし、Simplicityやコベナンツなどのスマートコントラクトに関するイノベーションはLiquidの代わりに本稿で示したメカニズムを利用してプロトタイプすることもできます。

ビットコインスクリプトはブロックの検証にかかる時間を限定するために多くの制限があります。この制限に縛られない単純なスマートコントラクトプラットフォームは、コントラクトの結果の強制にブロックチェーンを利用しないため、ビットコインスクリプトの制限を気にせずスマートコントラクトを記述することができます。

余談：フェデレーション型パーミッションドブロックチェーンはSmart Contracts Unchainedで実装したほうが良い

ブロックチェーンはあまりにもバズワード化しすぎたため、「パーミッションド」ブロックチェーンという不思議な構想まで生まれるようになりました。

ブロックチェーンは多くの人々を平等に扱い合意を形成する遅いデータベースです。パーミッションが必要なブロックチェーンはブロックチェーンの重荷を引き継ぎ、パーミッションレスのメリットを失っています。

そのようなブロックチェーンにおいて、トランザクションの順序は固定された署名者数名、事実上のフェデレーションによって決定されています。また、一般のノードは検証作業を行わず(大変なため)、トランザクションの検証はこの固定されたブロック生成者たちに任せるものだと考えられています。

このようなブロックチェーンは本稿で提案したSmart Contracts Unchainedを用いて実装したほうが良いと考えられます。フェデレーションは必要以上に制限の厳しいブロックチェーンを毎ブロック署名する代わりに、コントラクトの結果に合意が得られなかったときのみビットコイン・ブロックチェーンにおいてトランザクションを署名すれば良いはずです。

パーミッションドブロックチェーンと比較してのメリットは下記の通りです：

多くの場合、パーミッションドブロックチェーンは業界を横断して使うものとして提案されます。署名者たちは通常、業界内の大企業です。しかし、署名者たちはパーミッションドブロックチェーン上のトランザクションを全て知ることになるため、大企業によるカルテルの形成が助長され、小規模な競合にとって不利です。Smart Contracts Unchainedは異議がない通常の結末はプライベートなので、このような事態を防ぎます。
署名者が悪意のある、もしくは破壊的な行動を取ったときに、署名者の役割から外すことが不可能だったり非現実的だったりします。そのような事態が発生したときに悪意のある署名者の存在によってパーミッションドブロックチェーンが使用できず、ブロックチェーン外での業界内の経済活動も難しい場合には業界全体が硬直してしまいかねません。Smart Contracts Unchainedは業界標準のコントラクトでも参加者たちがフェデレーションの構成を改変することができ、問題となる署名者を排除できます。
商業や工業における契約はビットコインによってサポートされる単純なコントラクトよりは遥かに複雑なことが多いです。そのような複雑なコントラクトのデプロイ後にバグが発覚すると厄介な状況に置かれる可能性があります。パーミッションドブロックチェーンはバグのあるコントラクトのデプロイをロールバックすることができますが、他の執行時間が重要なトランザクションもロールバックの巻き添えになることから、大規模な問題発生時にのみ利用されると考えられます。利用者が少ないコントラクトにバグが見つかった際に、業界を巻き込んでロールバックされるとは考えにくく、バグが放置される可能性が高いです。Smart Contracts Unchainedでは、参加者が合意によってバグの含まれないコントラクトに乗り換えることができます。

プライベートでパーミッションドなブロックチェーンに実用性はほぼありませんが、もし特定の業界が経済的な交流を標準化して表現することにメリットを見出したとしても、それはSmart Contracts Unchainedで実装すれば事足ります。