スマートコントラクト言語にチューリング完全性は本当に必要か？ーSolidityの課題と代替案

※本記事は海外著者からの寄稿記事となります。

スマートコントラクト言語にチューリング完全性は本当に必要か！？ーSolidityの課題と代替案

誰しもに、お気に入りの靴や、好きな食べ物があるのと同じように、誰にでもお気に入りのプログラミング言語があるでしょう。私がこの記事を書いているのは、あなたの好きな言語を諦めて欲しいからではありません。（どうか、私を信じてください、私はそんなことを言おうとは夢にも思いません）。

その代わりに、私は、私たちが一緒に旅をして、その旅が私たちに考える機会をもたらしてくれることを望みます。本稿では、「チューリング完全性」について議論し、スマートコントラクト開発におけるその有用性を評価するとともに、代替案を検討し、結果として同じ結論に到達できる期待を持っています。

※ネタバレ：本稿の結論は、EthereumのSolidityにスマートコントラクト開発言語を独占させるのは、ひどく愚かな考えである、ということです。

それでは始めましょう。

チューリング完全性とは

チューリング完全性についてよくご存知でない方に向けて、とても簡潔な説明をしたいと思います。過去に聞いたことがあるが、詳細を忘れてしまった方にとっては、記憶を呼び戻す手助けになると思います。

アラン・チューリングは数学者で、「チューリングマシン」と呼ばれる仮想マシンを発明しました。この仮想マシンは、無限量のメモリにアクセスし、メモリー内でいつ書き込み、読み取り、移動すべきかを決定するプログラムを実行します。

また、どのような条件下で終了し、次に何をすべきかについてもプログラムが指示します。これらの条件に合ったプログラムを記述できるプログラミング言語はチューリング完全言語と呼ばれています。アルゴリズム（プログラムの実行の結果なんらかの結果が得られる）を記述できることがチューリング完全言語の条件でもあります。

Tiobe Indexによると、昨今、人気のプログラミング言語のほとんどがチューリング完全（または、必要に応じてチューリング完全になる能力を持つ）です。意図的にチューリング不完全な言語は、BicoinScriptやCoq（機械的に証拠をチェックする相互作用の定理プログラム）のような特定の領域に特化したプログラミング言語です。

これらの言語は、意図的にセキュリティーを向上させる特性を持たせることを目的に、または再帰なしでも機能できるが故に、言語に再帰を備えていません。（これらのチューリング不完全な言語の開発者達は、チューリング完全な環境を作ること自体が過剰だとも考えています。）

基本的に、チューリング不完全な言語は、ある特定の目的に対して専門化されている一方で、チューリング完全な言語は、幅広く様々なケースに対応できる多目的なツールです。最初は「何にでも、便利なチューリング完全な言語を使うべきですよね？」と思うかもしれません。

実際に、とても柔軟性があります。このような多目的なツールは多くの状況で便利であり、必要に応じていつでも使えるよう備え持っておくのは良いことでしょう。しかし、自動車を修理するような（とても特定な）状況では、目的に応じた、専門的で、適切なツール（チューリング不完全な言語）を持っている方が良いでしょう。

簡潔に述べると、「チューリング完全な言語はより広く応用できるが、チューリング不完全な言語は特定の用途に適している」ということです。皆さんが、どのように考えるかは分かりませんが、個人的にはスマートコントラクトは専門化された特定の用途の一つだと考えています。

あなたは今、「でもなぁ・・・」と思っているかもしれません。そして、「スマートコントラクトには非常に多くの種類があり、現時点では、その大部分はSolidityで書かれていて、今のところ特に問題がないからなぁ・・・」と考えていることでしょう。

とても素晴らしい指摘ですね！

私は、あなたがその点を持ち出してくれて、とてもうれしいです。

スマートコントラクトとSolidityとチューリング完全性

このような複雑な問題は、常に専門家に頼るのが最善ですよね？そこで、ドイツのUniversity of Applied Science Ruhr West（ルール・ウェスト応用科学大学）のComputer Science Institute（コンピューターサイエンス学会）の論文を用いて解説します。

「スマートコントラクト言語はチューリング完全である必要があるか?」と題されたこの論文は、本稿の議題について、とても興味深い統計結果を数多く提供しています。

しかし、これらの統計を深く掘り下げる前に、一般的に認知されているSolidityがチューリング完全な言語であるが故に存在する欠陥のいくつかを簡単に確認しましょう。

EthereumのSolidityは欠点として、The DAOのハッキング（※当時の時価で150億円ものETHが盗難被害に）を可能にしたセキュリティ上の欠陥（再帰呼出の悪用）や、低品質なスマートコントラクトへの攻撃可能性（リエントランシ（再入）攻撃）、そしてコントラクトを実行するための手数料が事前に正確に予測できず、コントラクトの実行が途中で停止してしまうという課題（停止問題）を抱えています。

これらの問題が存在する理由は、Solidityがチューリング完全な言語であることに帰結しますが、それでも、SolidityとEthereumは、そのチューリング完全性から、多くの利点を得ることができているので、これらの問題点を許容するだけの価値はあるのではないでしょうか。

本当にそうでしょうか！？

残念ながら、ドイツのルール・ウェスト応用科学大学のメンバーは異なる結論を導き出しました。彼らは、53,575ものスマートコントラクトをダウンロードし、それぞれのコーディングタイプを分析しました。彼らは論文の中で、「研究で提議された問（チューリング完全性は必要か？）に答えることを目的に分析を実施しました。

この分析では、抽出（ダウンロード）されたスマートコントラクトで使用されているフロー制御のメカニズムを識別し、それぞれのスマートコントラクトを対応する計算可能クラスに割り当て、チューリング完全性がコントラクトを実装する上で、本当に必要とされる割合をチェックしました。」と説明しています。

このデータの観察方法には2つの方法があります。厳密に言えば、全体の6.9%（53,575中、約3,697）だけが、スマートコントラクトとして機能するために、技術的にチューリング完全な言語を必要とします。

もう少し寛容に捉え、全体の35%がチューリング完全な言語を必要としていると仮定しても、まだ少ないと感じるでしょう。私は、仮に全体の半数がチューリング完全性を要求したとしても、依然としてセキュリティ問題とのトレードオフを考える価値ががない、とまで言い切ります。それでは、なぜSolidityはチューリング完全なのでしょうか?

Solidityの開発はJavascript、C++、Python、PowerShellといった他のチューリング完全な言語の影響を強く受けています。実際のところ、Solidityがチューリング完全な言語になる意図を持って開発されたと言い切るのは、少し無理があるかもしれません。

結局のところ、メリットが活用されていないのに、なぜわざわざプログラミング言語に欠陥を持ち込むのでしょうか。コーネル大学の博士課程（PHD）の学生であるPhilip Daian氏は、The DAOのハッキングの後、ブログ記事（この記事はとても興味深く素晴らしい）において「技術的にはEVMは意図した通りに動作していたのですが、Solidityがセキュリティ上の欠陥をコントラクトに持ち込んでしまいました。コミュニティだけでなく、言語の設計者自身がこのSolidityの欠陥を見落としていました。」と書きました。

代替案としてどのようなオプションが考えられるのか

独占状態は市場にとって悪く、その成長を妨げます。私たちは日頃、独占に反対し、その状態を解消しようとする政府の行動を支持していますが、なぜかスマートコントラクトに関しては、独占を受け入れようとしているフシがあります。このことを念頭に置いて、私たちの目の前にある２つの未来の可能性について言及します。

１つ目の可能性は、私たちがこれまでのSolidityに関する経験を活用し、そこから成長していくことです。私たちはSolidityを拡張し、Vyper（Solidityの次に使用されることを目的に設計されたチューリング不完全な言語）のような他の言語を拡張し、チューリング完全な言語がスマートコントラクトの世界にもたらす明らかな欠陥を無視し続けるのです。

２つ目の可能性は、ポートフォリオの分散化です。私は冒頭で、「好きなプログラミング言語を諦めるように説得する気はない」と言いましたが、私は嘘をつきました。現在のスマートコントラクトコミュニティにおける問題は、誰もがSolidityを使用するようにしつこく主張していることです。本質的に、私は必要性によって主張されるべきであり、ただ望むから主張されるべきではないと考えます。

ここで、スマートコントラクトの世界で使用されるプログラミング言語に関して、Solidityと真剣に競争しようとする代替候補について話をしましょう。その１つはWavesのRIDEです。

Wavesがこの戦いで重要な競争相手だと思う理由はいくつかあります。主要な理由の一つは、Wavesは2016年に登場し、機能するシステムを構築し、本日まで運用を続けているという事実です。この業界では頻繁に「新会社や新プロジェクトに関する憶測記事」を目にし、それらが「業界に革命を起こす」と誇張されます。Wavesは、誇張ではなく、実際に戦えるだけのプロダクトラインナップを有しています。

Wavesは独自のブロックチェーン、マルチプラットフォーム対応のウォレット、カスタムトークンの発行システムと分散型の取引プラットフォーム、そしてdAppsとの接続や署名を管理するためのセキュアなブラウザ拡張機能、そしてdAppsを構築する為に設計された専用プログラミング言語RIDEと洗練された開発ツールを有しています。競合としてWavesを挙げたのは、Wavesが競争力があり、真剣に取り組んでいる会社であること、そして、WavesのRIDEが、Solidityの代替手段として競争力のある選択肢であるからです。

RIDEは意図的にチューリング不完全な言語であり、開発者が（メリットが少ないのにリスクが高い）ナンセンスな環境でスマートコントラクトを構築することがなくなるように設計されています。

RIDEはこれを実現するために、２つのアプローチを採用しています。まず、RIDE言語はdAppsの開発に必要な基本的なスクリプト関数を提供します（同時にセキュリティ関連のエラーを減らすことが可能です）。次に、RIDEは再帰や複雑なループをサポートしていないため、セキュリティーの欠陥を簡単にテストすることが可能です。

また、再帰をサポートしないということは、セキュリティ上の欠陥をテストすることに役立つだけでなく、Wavesのブロックチェーン上でスマートコントラクトの実行に必要な手数料を計算する際にも重要です。再帰がないことで、プログラムの実行にかかる時間や複雑性を事前に計算できるため、実行前にコストを見積もることが可能です。そして、Ethereumとは異なり、実行されなかったスマートコントラクトの呼び出しに手数料が徴収されることがないのです。

あなたは今、「RIDEは意図的にチューリング不完全であるため、EVM向けに作成されたスマートコントラクトの大部分を処理できない」と考えているかもしれませんが、ドイツのコンピュータ科学者が以前に行った調査結果を振り返りましょう。検証された多数のスマートコントラクトのうち、実行の為にループを使用し、チューリング完全性を必要としたのは僅か7%未満でした。

この記事のメイントピックに対する、私の真剣な疑問は、「全体の7%にも満たない数のスマートコントラクトがSolidityにおけるチューリング完全な機能を利用しているに過ぎない状況で、なぜ私たちは（問題点が多い）チューリング完全な言語であるSolidityを使っているのだろうか！？」というものです。

論文：「Self-Reproducing Coins as Universal Turing Machine」によると、これらのチューリング完全なスマートコントラクトを必要とするdAppsの7%は、（理論的には）チューリング完全な機能を、多数の異なるトランザクションに亘って実装することで対応できるとしてます。彼らの研究では、UTXO（未使用のトランザクションアウトプット）モデルを利用した、小さく特定のセットの言語機能を使用し、シンプルなチューチング完全なマシンを構築することができました。

これらのトランザクションは、安全のためにインプットとアウトプットの両方のトランザクション状態によって厳しく制限され、無制限ループは意図的に実行不可能にされていました。同じ方法で、チューリング不完全なプログラミング言語としてのWavesのRIDEは、チューリング完全が根源的に内包する問題を引き起こすことなく、チューリング完全なスマートコントラクトを記述することが可能です。

Ethereumで確認できるこれらの問題は、何か大きな変更が行われない限り、悪化するのみです。既に今後数年間のロードマップは示されているため、この点において重要な変更を行う為の取り組みが行われていないことは既に分かっています。最終的にはPoWではなくPoSに移行する予定で、セキュリティを強化したければVyperを使って書き込むことも可能です。

しかし肝心なのは、チューリング完全性がEthereumのセールスポイントだったということです。Ethereumの創設者である、Vitalik Buterin氏はEthereumのホワイトペーパーで次のように認めています：

「チューリング不完全性はそれほど大きな制限ではありません。私たちが内部で検討したすべてのスマートコントラクトの例の中で、ループを必要としたものはこれまでに１つだけであり、そのループさえも１行のコードを２６回繰り返すことで取り除くことができました。

チューリング完全性の深刻な影響と限られた利点を考えると、なぜ、チューリング不完全な言語をEthereumは持たないのでしょうか。しかし、実際には、チューリング不完全性は、この問題に対する適切な解決策とは言えません。」

読者の皆さん、私たちは一緒に１つの長い旅を終えたところですが、開発者にとって、より重要なことは何でしょうか。それは、「ハッキングや悪意のある行動に自動的に対抗でき、明確で簡潔なコードを書くことが出来ること、あるいは、より品質の高いチューリング完全な言語で、コードを書くことが出来ること」ではないでしょうか？

EthereumとSolidityがスマートコントラクトとdAppsの領域で、新しい世界への扉を開いたことは否定できませんが、私たちがプログラミング技術を多様化し、現在の独占状態を打破するのにあまりにも長い時間を掛けてしまいました。

開発者にとって、代替手段としてチューリング不完全な言語へ切り替えることはそれほど大事ではありません。今後の記事で、コードサンプルや全体のプロセスを紹介して説明を行う予定です！是非、ご注目を！

※本稿の原文はHackernoonで公開されたもので、寄稿記事として筆者の許諾を得て、日本向けに再編集を行っていとなります。

Should Smart Contracts be Non-Turing Complete?

オリジナル記事はこちらから