DAOからの教訓

スマートコントラクト技術を現実世界に応用することに重点を置くことは、RSK（ルートストック）の目標の 1 つです。私たちは、DAO が古くからある信頼の問題を解決する革新的な新しい方法であることに興奮していますが、ビットコイン、そのブロックチェーン、スマートウォレット、暗号資産はすでに破壊的可能性を秘めており、これらのテクノロジーを使用して真の金融包摂を実現できると信じています。シンプルで明確なインテリジェント モジュールを使用すると、分析、推測、レビューが非常に簡単になり、これは当社の成功に不可欠です。

先月、クラウドファンディングで2億ドルを調達したThe DAOの立ち上げを目撃しました。 The DAO の創設者たちがこれほど巨額の資金を保護する準備ができていたかどうかは疑問です。結局のところ、DAO はまだテストされていない実験的なプロジェクトです。この記事では、DAO インシデントの主な原因をまとめ、RSK の設計を分析して、そのようなリスクを最小限に抑える方法について説明します。 RSK の目標は、階層化されたセキュリティ保証を提供することです。つまり、1 つの保護レイヤーが侵害されてもシステム全体がダウンすることはありません。 Ethereum には独自のセキュリティ モデルがあるため、DAO の事件を乗り越え、この事件後もさらに堅牢になります。結局のところ、この事件も大きな影響を受けたので、この深い教訓を学んでほしいと思います。

飛行機の飛行の例えを使うと

私たちのほとんどがビットコインを使い始めたとき（ビットコインを購入したり、支払いとして受け取ったり）、それはまだ実験段階であり、その機能はすべて開発中でした。ビットコインは、空中で修理しなければならない飛行機に何度も例えられてきました。しかし、ビットコインは一度も着陸することなく7年間飛行し続けている飛行機であり、だからこそ人々はビットコインを信頼できると呼び続けるのです。対照的に、多くの人が DAO に投資した時点では、そのコードはまだ実行されていませんでした。あなたは自分の命を自動飛行機操縦ソフトウェアに託しますか?そして、このソフトウェアは一度もテストされていません。残念ながら、DAO の投資家たちはまさにそれを実行したのです。彼らは注意深く調査することを忘れ、衝動的な行動によって罰せられました。 DAO 投資家のほとんどは少額の資金しか投資しておらず、基本的にはただ楽しみのためにギャンブルをしていただけだと言う人もいるでしょう (ハイエンドの人は盲目的に投資することが多いのは知っています)。しかし、DAO に数百万ドルを投資した機関投資家もいます。したがって、DAO の投資家はこの事故の責任の一部を負うべきです。

イーサリアム仮想マシンの設計

コンセンサス層の仕様を簡素化することは、Ethereum の設計目標の 1 つです。これは、さまざまな言語や制約にわたるプラットフォームの再利用性を高めるため、素晴らしい目標です。最小のチューリング完全な命令セットは 10 命令に制限できますが、Ethereum では、(a) 効率が低下し、(b) コンパイルされたコードの監査が困難になるため、そのような制限は課していません。つまり、Ethereum には 100 種類の異なるオペコードがあります。ただし、簡単にするために、呼び出しオペコードには、他のコントラクトを呼び出す関数と、イーサを送信する関数の 2 つの関数が含まれます。ただし、これら 2 つの関数の意味形式は非常に異なり、適用可能なコンテキストも大きく異なります。これは、DAO への攻撃につながった要因でもありました。興味深いことに、一時的なコントラクトを作成し、自己破壊オペコードを使用することで、Ethereum 仮想マシンは、ガスの消費量は多少増えるものの、関数を呼び出さずに Ether を送信する機能を間接的に実装できます。このことから、上位層の複雑さを軽減するために、仮想マシンはコードを呼び出さずに送信オペコードを提供する必要があるという結論を導き出すことができます。呼び出しの燃料供給を 2300 に制限することで、他の呼び出しは実行できなくなるため、安全であると主張する人もいるかもしれません。このアプローチは、VM が将来的にハードフォークを実装する可能性があることを考慮すると、機能しなくなります。これにより、操作の呼び出しコストが削減されるか、スマート コントラクトが自身で支払いを行えるようになります。したがって、基本的に、このアプローチは近視眼的であり、実際の問題を隠し、将来の改善を妨げます。 RSA では、宛先コントラクト内のコードを呼び出さない単純な送信オペコードを使用します。

反対する人もいるでしょう。ほとんどのスマート コントラクトは、Ether だけでなく暗号資産も扱うので、資産を送信すると、実際には資産発行コントラクトが呼び出されます。これらのケースには異なるシンボルが与えられ、制限が適用される場合があります。オペコードを送信することで、要求に応じて問題が修正されるだけではありません。

堅実性

動的言語は、静的言語よりも検証（または推論）が難しいことで有名です。 Ethereum スマート コントラクトでは、動的言語コードは静的言語コードよりも多くのコンピューター リソースを消費します。 Solidity は JavaScript をベースにした静的言語です。静的な言語を選択すると第一印象は良くなりますが、なぜ言語をゼロから作り直す必要があるのか​​という疑問が生じます。ドメイン固有ではなく、スマート コントラクト専用に設計された機能を持たない言語。既存の言語で十分良いものはないのでしょうか？ QixCoin などの以前のスマート コントラクト プロジェクトは、RISC プロセッサ シミュレーターまたは x86 命令を実行するサンドボックスをベースとしており、プログラマーは主流の標準プログラミング言語とコンパイラーを使用できました。 Solidity は未熟です。たとえば、原因不明で Solidity が失敗するコントラクトがありました。 Solidity が不正なコードを生成する例にも遭遇しました。監査のために、コントラクト バイトコードではなく Ethereum コントラクト ソース コードを読み始めると、コンパイラの品質 (改ざんされたコンパイラのリスク) の問題が非常に重要になります。

DAO イベントに戻って、DAO のソース コードを見てみましょう。この脆弱性については十分に分析されているため、これ以上議論するつもりはありません。ハッカーが悪用する可能性のある 2 行のコードだけを見ていきます。

a) if (_recipient.call.value(_amount)()) {
b) (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false)の場合

最初の行の未定義のコントラクト _recipient は _amount の ether を送信しますが、メソッドは定義されていません。 2 行目では、fundsToBeMoved の Ether を送信する特定のメソッド (createTokenProxy) が呼び出されます。 Solity ドキュメント 0.2.0 には、次の警告があります: .value(x) または .gas(y) パラメータを追加して設定し、関数を呼び出してガスを送信すると、最後の括弧内のコンテンツのみが呼び出しアクションを実行します。 .gas() サフィックスが省略されている場合、未使用のガスが外部呼び出しに渡されるため、コントラクト再帰の脆弱性が存在します (ただし、これはドキュメントに明確に記載されていません)。呼び出し表記も非常に珍しいため、欠陥があると思います。まず、他の言語では、メソッド参照をこのような修飾子で変更することは許可されていないため、メソッド呼び出しが不明確になります。メソッド呼び出しにより、「createTokenProxy」が「value()」に置き換えられるようです。

強力でプログラマーにとって理解しやすい言語を作成するための研究が数多く行われてきました。 Golang、C#、Java は、人間の理解力、言語の表現力、記号の簡潔さの間で適切なバランスが取れている良い例です。 Solidity はそのような言語ではないようです。また、Serpent については情報や例がほとんどないため、使用はお勧めしません。

動作環境に関するヘルプ

スマート コントラクトのセキュリティは、コントラクト コード自体に完全に依存しているようです。 VM には再帰を制限する専用サービスがなく、Solidity ランタイムには再帰を防ぐシグナルがありません。 DAO におけるこのタイプの再帰脆弱性は 2014 年にはすでに知られていたため、このインシデントに備える時間は十分にありました。しかし、これらのツールはまだ成熟しておらず、高品質のツールが開発されるまでには数年かかることは明らかです。 Ethereum の分散型開発には多くの利点があるかもしれませんが、明確な指示が不足している、セキュリティ関連のアップグレードが無期限に延期されるなど、いくつかの欠点もあります。

RSK では、コントラクトがデフォルトで再入可能になるのを防ぐために、強化されたランタイム環境を提供する予定です。これによってすべての問題が解決されるわけではありませんが、ほとんどの人為的エラーは回避されます。
セキュリティ監査

セキュリティ監査を実施したことがある人なら誰でも、単一のセキュリティ監査ですべての潜在的な脆弱性をカバーできるわけではないことを知っているはずです。どの研究者や組織も、過去の経験に応じて、いくつかの問題を見逃してしまうことがあります。これは、まったく新しいテクノロジー (スマート コントラクト)、新しい言語 (Solidity)、新しい種類の攻撃 (ゲーム理論的など) で記述されたコードを扱う場合に特に当てはまります。セキュリティ監査の数、深さ、および資金は、監査コードに関連しています。新しいコードの作成には数百万ドルの費用がかかり、複数のセキュリティレビューを受ける必要があり、完成するには複数のチームの協力が必要になる場合があります。実際、これは Ethereum が行ったことであり、彼らはそれを監査するために LeastAuthority、Dejavu、Coinspect を雇いました。しかし、DAO の作成者はこれを行わず、イーサリアムの創設者も含まれる DAO の規制当局は DAO にそうするように助言すべきでした。

正規化

標準化されたモデルを使用してスマート コントラクトを設計し、静的/動的検証を使用してコードの正確性を検証することは、セキュリティ監査に置き換えることはできません。正規化されたアプローチは常に強力な根拠となってきましたが、そのようなモデルを実装するのは困難です。ドメイン固有言語 (DSL) は、より広範囲のバグを回避します。問題は、標準化にはコストがかかるため、無視されてしまうことが多いことです。ここでもう一つの教訓があります。安全性はコストに関するものです。 RSK と Ethereum に特化した新しい標準化ツールの登場を期待しています。ただし、Java (JML、KeY) などの従来のプログラミング言語向けに設計されたツールはすでに多数存在しているため、RSA はスマート コントラクトを Java で実行できるように同様のツール チェーンを作成しました。私たちはこのツールチェーンを使用して、高リスクの契約を開発することを楽しみにしています。

漸進的な地方分権化

DAO のような組織を作成する際の難しさは、コードの正確性を保証することだけでなく、投票システムの動的な性質によって潜在的な欠陥が発生する可能性があり、予測が難しいことにもあります。投票を組織することは複雑な人的プロセスであり、正式なものになるまでには試行錯誤が必要です。合理的なアプローチは、(n,m) マルチ署名を介して公証人のグループによって管理される契約から始めることです。これは、単純かつ直接的な方法でアップグレードおよび改善できます。ここで、n は単に多数派を表し、必要な公証人の合意が得られるまで n が徐々に増加します。最後に、契約が実際の環境でテストされたとき、一定期間後にマルチ署名機能が自動的に削除されました。 DAO はおそらく初期段階ではこうした指導をほとんど行わなかったが、そうすることで成功の可能性が大幅に高まった。

このような原則は、RSK のハイブリッド コンセンサス システムに組み込まれています。最初は公証人の確認が必要ですが、融合マイニング コントラクトの登場により、公証人の確認の数は削減されます。このアプローチは漸進的分散化と呼ばれ、スマート コントラクトやコンセンサス システムに使用できます。

リスクを無視する

これまで、セキュリティ監査レポートを処理しているときに、「そのような攻撃条件は絶対に発生しないので脆弱性はない」、「攻撃を実行するのは難しすぎる」、「そのような問題を修正すると実用性に影響する」などのフィードバックを受け取ったことが何度もありました。現実のすべてが、これらの主張が支持できないことを示しています。ソフトウェアの変更によって潜在的な脆弱性が活性化される可能性があるため、後でソフトウェアをアップグレードすると、以前は休止状態だったコードが実行され、突然脆弱性になります。攻撃の複雑さの評価はさらに間違っています。ハッカーは、被害者よりもはるかに高い利益と作業負荷を正しく評価しますが、被害者はハッカーの能力についてまったく知りません。実用性についての議論はさらに支持できない。たとえソフトウェアが非常に実用的であったとしても、一度ハッキングされてしまったら、二度とそれを使う人はいるでしょうか?再帰呼び出しの問題は、既知で文書化されている脆弱性の良い例ですが、これを真剣に受け止める人はほとんどいません。

文書の不足

Ethereum 開発者は、スマート コントラクトの作成に関連する設計パターン、よくある間違い、誤解、およびセキュリティのベスト プラクティスを文書化する専用の Web サイトを緊急に必要としています。 RSKでは、スマートコントラクトのセキュリティに特化したリソーススペースを設け、標準の策定に参加する研究者も募集します。私たちには、スマートコントラクトのハッキングチャレンジのためのプラットフォームを作成し、ハッキングコンテスト（Capture the Flag CTF に似たもの）を開催するという中期計画があります。

RSK セキュリティ保証パートナープログラム

RSK はセキュリティ企業と連携して、スマート コントラクトのセキュリティの最終ラインを保証します。これにより、スタートアップ企業は、完全なコード監査の前に、セキュリティの最初のレイヤーとして、スマート コントラクトのセキュリティ脆弱性に対してコードをテストできます。このプログラムにご興味のあるすべてのコンピューター セキュリティ企業のご参加をお待ちしております。
要約する

スマート コントラクトの分野はまだ初期段階であり、間違いは避けられません。より多くのツールとドキュメントが利用可能になるまで、スマート コントラクト プログラミングに「多層防御パラダイム」を採用し、脆弱性の影響を軽減するために、できるだけ多くのセキュリティ保護層を追加する必要があります。あいまいなプログラミングセマンティクスとドキュメントの欠如により、人為的エラーが増幅されます。 RSK とそのエコシステムは、DAO 事件から十分な教訓を学び、RSK が成熟したツールセットを使用して契約開発を正しい軌道に乗せるように努めています。私たちは、スマートコントラクト企業とプラットフォームにセキュリティ監査を実施することを奨励し、投資家とユーザーには慎重かつ厳格な評価を実施することを奨励しています。