たまにはポエムを書きます。
パブリックな「スマートコントラクトプラットフォーム」の定義
スマートコントラクトの定義は曖昧で共通認識は定まっていませんが、本記事ではブロックチェーン上でユーザーが自由にプログラムコードを記述することができるプラットフォームのことを「スマートコントラクトプラットフォーム」と呼ぶことにします。具体的にはEthereum、Lisk、Expanse、Rise（時価総額順）などです。
The DAO事件から見えること
これらのプラットフォームは、どんなプログラムも動作させることのできる分散型コンピュータとして大きな利点ばかり以前は宣伝されてきましたが、The DAO事件から欠点も見えてきました。それは、①プログラムには必ずバグがつきまとう、②そのバグを容易に修正することができない、ということです。
①については、ある意味常識的な話でどんなプラットフォームを利用していようがプログラムを書く上でバグはつきものであり、どんな優秀なプログラマーであろうがバグを一つも出さないというのは不可能と言えます。従来のプログラムは例えバグが発生してもすぐ修正しても済む話なので大抵大きな問題にはなりませんが（時には大きな問題になることもありますが）、Ethereumの場合はそのバグをたとえ発見しても迅速に修正することが難しいので致命的になり得ます。
バグの修正能力をどこまで柔軟に持たせるか
そこで、このようなプラットフォームはどこまでバグに対して柔軟に対処させるか、ということが問題になります。Ethereum上で一度動かしたスマートコントラクトは永遠に止めることができないために事件は起きてしまいました。しかし、ではEthereum上のスマートコントラクトに全くバグに対する耐性がないかというとそういうわけではありません。Ethereum上のプログラム（スマートコントラクト）は他のプログラムからのトランザクションを受けて実行させることができるので、例えばバグを修正した新たなプログラムを作成し、元のプログラムから新しいプログラムに内部の保存データを移し「バージョンアップ」することも可能です。The DAOの場合は修正のために内部トークンの保有者の投票による賛成が必要であり「バージョンアップ」のハードルが非常に高かったので、迅速に対応することができず、バグが修正されることなく終了ということになってしまいました。
今回は正確にはバグ修正というかたちではありませんでしたが、ハードフォークもバグ修正の方法の一つといえるでしょう。
事件から感じたのは、バグを修正する「権力者」をスマートコントラクトに対して置くことが現段階ではまだまだ必要であるということです。
※超単純なプログラムであったり、十分な期間十分な人間によって安全だと確認されたプログラムはこの限りでありません。
完全な「信用が不必要」（trustless）は不可能
バグを修正する権力者を置くことは、当然その権力者がプログラムを悪意を持って改変する可能性があるということなので、プログラムを利用する上では権力者を信用しなければなりません。これは、信用が不必要（trustless）というEthereumなどの分散型プラットフォームの理念と真っ向から対立するものとも言えます。
しかし、コードを簡単に修正できないようにすれば「信用」が必要なくなるわけではありません。多くの人はプログラムコードを読むことができないので、プログラムを書いた人間、あるいはそのプログラムを監査してバグがないと発信する人間を信用せざるを得ません。仮にどんな言語で書かれたプログラムも完璧に読める天才であったとしても、いちいち自分が利用するプログラムのソースコードをすべて読み込むのは非現実的です。
そして、trustlessだったはずのコードに裏切られるかたちで事件が起きてしまいました。いろいろな意見があると思いますが、個人的にはThe DAOのコードを書いた開発者が無能だとかコードをチェックした開発者が無能であるとは思いません。プログラムにバグは必ずつきものなのです。
Ethereumのハードフォークには違和感
当初は特に書きませんでしたが、私自身はEthereumのソフトフォークにもハードフォークにも反対でした。なぜなら、Ethereum本体のバグではなくThe DAOのコードのバグであったことと、The DAO（+Ethereum）はそもそもこのようなバグに対して最初から迅速・柔軟に修正できる能力を放棄することによって「trustless」の理念を宣伝していたと思っていたからです。当初掲げていた理念と真逆のことを宣言されては違和感を感じてしまいます。唯一納得でき得る根拠は、ETHが盗難されることで将来Proof of Stakeに移行する際の懸念となるというものでしたが、この点もメインの根拠として議論されていたわけではなくまたPoS実装自体はまだまだ先でいくらでも対応のしようがあると思うので、それでも不十分であると感じていました。
ちなみにEthereum Classicにも反対です。フォーク前だったら支持したでしょうが、マイナーがフォークを支持した後の今となっては、ETCはReplay Attackなどの混乱を生むだけですし、開発を行う上でも余計複雑になって結果的にEthereum全体のマイナスとなると思うからです。
「ロールバック」を是とするならEthereumよりLisk
結果的にEthereumのコミュニティはハードフォークを支持して、コード上で書くことによって強制的に引き出されたETHを移動させて実質的な「ロールバック」を行うことになりました。
しかし、もし「ロールバック」を良しとするのであれば、Ethereumはベストの選択肢ではないと思います。なぜなら、Ethereum本体とは直接関係ないはずの一ユーザーが書いただけの一つのコントラクトコードの脆弱性のせいでEthereumの全利用者を巻き込まなければならないからです。
Liskのようにプログラムごとに独自のブロックチェーンを立ち上げるサイドチェーンを利用していれば、本体のブロックチェーンへの影響は最小限にそのサイドチェーンやプログラムの利用者の範囲内だけでロールバックが可能です。サイドチェーンであればコンセンサスアルゴリズムを自由に選ぶこともできるので、プログラムの修正もより柔軟に行うことが可能で、迅速な修正・対応を目的とするのであればEthereumよりもLiskが優れていると言えます。
※コンセプトだけを見ればLiskは優れていると感じていますが、個人的には開発チームの開発力に対する懸念やスマートコントラクト(DApps)の開発コミュニティがEthereumに比べて非常に小さいことなどから、必ずしもLisk自体が成功できるとは思っていません。
Ethereumの理想は遠い？
プログラムからバグを完全になくすことは不可能ですが、十分に単純であったりかなり長い期間、多くの人による検証が行われればある程度までバグの混入確率を減らすことは可能です。十分長い期間を掛ければ当初Ethereumが提唱していた改ざん・検閲不可能で止めることができないスマートコントラクトを安全に実行することもできるかもしれません。
しかし、利用者からみればコード開発者やそのコードを信用するのが完全に不要になることは永遠にありません。0か100かという話ではなく、どこにどの程度信用を置くのかということになってくるのでしょう。
