Pontemライブストリーム2022年9月2日：セキュリティ編

週刊ライブストリーム2022年9月2日：セキュリティ編

Pontem Network

Pontem Networkのホワイトリスト登録はこちらから！
アンバサダーも募集中です。Aptos Japanにもご参加ください。

当日の録画はこちら📹

Alejo：今週はゲストをお招きしています。Robertは、世界でも有数のMove監査人で、セキュリティの専門家であり、多くのプロジェクトやコアプロトコルを監査してきました。では、自己紹介をしてもらいましょう。

Robert：お招きいただきありがとうございます。私は、スマートコントラクトの監査企業OtterSecを経営しており、Move、VMレイヤーとAptos固有のSDKレイヤーを深く理解しています。過去には、Alameda ResearchやJump Cryptoなどと協力してきましたし、Pontemのコアコードの監査もしています。

Alejo：ありがとうございます。Moveのどんなところに魅力を感じていますか？他とはどのような違いがあるのでしょうか。また、セキュリティの分野では、どのようなパラダイムシフトが起きるとお考えですか？

Robert：Move言語は、とてもエキサイティングだと思います。MoveはブロックチェーンのためのRustと呼ぶべきもので、よりドメインに特化しているため、Rustが抱える多くの汎用的な問題を回避できます。例えば、Moveではデータを手動でシリアライズ、デシリアライズする必要がありません。Moveは高度な言語であり、開発者がより安全なプログラムを書けるよう、より多くのツールを提供しています。

技術的な話を少ししましょう。Moveの特徴として、VMが非常に多機能であることが挙げられます。リファレンスがMove VMのファーストクラスの価値としてネイティブに利用できるため、例えばバイコードで、リファレンスをスタックにプッシュしたり、直接デリファレンスしたりすることができます。Moveはよりドメイン/ブロックチェーンに特化した、ハイレベルな言語であり、セキュリティ上の多くの問題を解決してくれると思います。

Alejo：もう少し掘り下げましょう。「ファーストクラスの価値」とはどういう意味でしょうか？

Robert：ファーストクラスというのは、単に仮想マシンがネイティブにサポートしているという意味です。一方、Rustでデータをデシリアライズする場合、その値を何らかの中間表現で表現したり、バイトデータからプログラムが使用する表現に変換する必要があります。生のバイナリからRustで使える値に変換する中間段階が必要となるのです。一方、Moveでは、値を直接使うことができるため、この手順がなくなります。

Alejo：ETHはファーストクラスネイティブですか？CompoundやUNIトークンはファーストクラスのバリューなのでしょうか？

Robert：ETHの場合、コントラクトがあって、その値をロードするためのバックエンドが必要になるので、上位の構造そのものにファーストクラスでアクセスすることはできません。たとえば、トークンへのリファレンスを渡すことはできず、値を受け取るためには、コントラクトを呼び出す必要があります。コントラクトの状態はすべてコントラクトの中に格納されるので、中間的なステップが必要となります。

Alejo：では、ERC-20コントラクトのようなコントラクトを呼び出さなければならないということですね？

Robert：そうです。

Alejo：そのほうが効率的になるのですか？また、安全性に加えて、ガス代も節約できるのでしょうか？

Robert：その部分はガスの節約とは別の話になります。Moveは言語として、非常に高速に設計されており、スケーラブルなので、ユーザーにとってのコストも低くなるはずです。一方で、ガスはVMネイティブの概念に近いので、MoveのガスはETHやSolanaのガスとはまったく別の単位で表記されます。

Alejo：CosmosやPolkadotのようなものと比較するとどうなるでしょうか。MoveかEVMか？どのような点をチェックすべきでしょうか。

Robert：理論的には、コントラクトはどの言語でも書くことができます。イーサリアムやあらゆるチェーンでも、安全なコントラクトの例がたくさんあります。しかし、最大のポイントは、Moveはデフォルトでより安全であるということです。Moveを使えば、膨大な努力や注意を必要とすることなく、より安全なコントラクトを書くことができるのです。

Pontem Networkはセキュリティを最優先に構築を進めていますが、正直なところ、スマートコントラクトの開発者の中には、セキュリティにあまり関心がないか、その意味を理解していない人がたくさんいます。彼らはただ、できるだけ早くメインネットにデプロイできるようなコードを書いているだけで、結局は後で自分たちの足を引っ張ることになるのです。

Alejo：では、エンドユーザーが、チームや開発者の行動による悪影響を受けないようにするにはどうすればよいのでしょうか？プロジェクトにおけるベストプラクティスとはどのようなものでしょうか？

Robert：ユーザーとしてできることは、注意を怠らないことだと思います。多くのプロジェクトがありますが、自分が関わるプロジェクトが実際に評判が良く、安全で、専門の監査法人と協力してコントラクトの監査を受けていることを確認することが、ある意味重要であり、セキュリティの脆弱性のリスクを軽減する最善の方法だと思います。もちろん、監査は完璧ではありませんから、何かを見落とす可能性は常にありますが、セキュリティに対するチームの姿勢は本当に重要なことなのです。セキュリティに気を配っているチームであれば、ただ製品を世に出すことが目的であるチームよりも、そのプロトコルに遥かに信頼を置くことができます。

Github リポジトリ上のコミットと監査報告書上のコミットを比較するのも一つの方法だと思います。もし異なるなら、そのチームと継続的な関わりがあるのか、それとも単にプロダクションやGithubにプッシュするだけで、追加の変更についてあまり相談していないのか、などを判断することができます。

Alejo：プロトコルとして、それを信頼できるようにする方法はあるのでしょうか？Githubで今公開されているバージョンが、監査されたものであることを、監査人として証明する方法はないでしょうか？例えばウォレットを活用するなど。

Robert：全ての監査報告書にはコミットハッシュが記載されており、レビューしたスタンプが押されます。ていることはご存じのとおりです。しかし、ウォレットの統合は良いアイデアで、私たちは実際にいくつかのウォレットと話をしています。ウォレットアプリにネイティブに、チェーン上のこのコードが監査人に承認されたものであることをユーザーが確認できる方法があれば、クールだと思います。理想的には、ユーザーが完全に信頼したいという場合、完全に検証されたコントラクトとしかやり取りしない、というようなオプションがあってもよいでしょう。そうすれば、コントラクトが自分の下で変更されたかどうかを知ることもできます。

Alejo：それはいいアイデアですね。どうすればこの機能を実現できるかを考え、ロードマップに追加するつもりです。これは、ウォレットのセキュリティにもつながる話です。ウォレットはメタバースへのインターフェースとなるものですが、ウォレットのセキュリティについてはどのようにお考えですか？最近では、またSolanaでハッキングがありました。ユーザーやプロジェクトがどのように自分たちを守ることができるのか、また、インターフェイスとしてのウォレットや、仲介者としてのブラウザをなくすことについては、どうお考えですか？

Robert：まず、セキュリティです。個人的には、ウォレットのセキュリティは、長い間、レーダーの下を飛んでいたようなものだと思っています。今回のSolanaイベント以前は、ウォレットが監査されているかどうかを気にする人は誰もいなかったのが実状です。考えてみれば、ウォレットは暗号の世界全体への橋渡しとなるものですから、その橋が危うくなれば、そこに関わる全てが危うくなる可能性があります。つまり、あなたにとっての単一障害点が存在するようなものです。

Solanaでの出来事については、実際に関係するチームと連携しています。私たちは調査結果を報告書にまとめ、Twitterのアカウントで公開しています。その概要は、ニーモニックまたはシークレットキーが誤って記録され、それがユーザーキーの漏洩につながったのではないかというものです。ここでの教訓は、機密性の高いユーザーデータを取り扱う際には、非常に注意しなければならないということです。そのデータが誤ってどこかに行ってしまわないようにしなければなりません。

今回の事故は、かなり巧妙なものであり、意図的にログを取ろうとしたわけではありませんでしたが、あるオブジェクトに誤って格納されてしまい、それがサーバーに送信されてしまったのです。このように、何重にも抽象化された仕組みがあり、それを理解するのに時間をかけなかったか、あるいは手遅れになるまで気づかなかったのでしょう。

Alejo：それは、本来監査報告書に記載されるようなことなのでしょうか。

Robert：はい。開発者がこのようなことを行う場合は、非常に注意深くなければならないと思います。特に何に焦点を当てるかということを明確にして、外部の企業を雇うか、あるいは、機密性の高いユーザーデータが意図しない形で流出する可能性があるこの種のエッジケースを探すのに多くの時間を費やす必要があります。今回のことは、世に出回っているウォレットにとっても警鐘となるものだと思います。多くのウォレットがありますが、正直なところ、その多くはセキュリティについて気にしていません。実際にPhantom以外のウォレットにも問題を発見し、既に報告してあります。度重なるSolanaでのインシデントをきっかけに、ウォレット側でもセキュリティに注目が集まることを期待しています。

Alejo：この単一障害点は、実はかなり怖いことなのです。Metamaskを使っている人がどれだけいるか考えてみてください。この問題をどう解決すればいいのか。完璧な分散型ウォレットというのは誕生するのでしょうか？

Robert：個人的には、ユーザーとして、もっとセキュリティを重視するように働きかけることが解決策になると思います。強力なセキュリティパートナーを持っているウォレットとしか取引しない。そのウォレットがセキュリティを確保するためにどのような監査を受けたのか、質問してみることが大切です。分散型のウォレットがどのように機能するかは、まだよくわかりません。ウォレットのコードはある程度中央集権的である必要があります。

Alejo：では、ウォレットもスマートコントラクトDAppsと同様に、監査を徹底し、報告書を公開すべきだということでしょうか？

Robert：ウォレットのセキュリティは、dAppsと同様、いやそれ以上に重要だと思います。ウォレットはセキュリティに気を配る必要がありますし、ユーザーも自分が使うウォレットのセキュリティを高める必要があります。結局のところ、セキュリティに対するニーズはユーザーから来るものでなければなりません。もしユーザーがセキュリティを気にしないのであれば、ウォレットも気にしないでしょう。しかし、ユーザーがセキュリティを求めるなら、ウォレットもコードを監査してもらうインセンティブを持つようになるのではないでしょうか。

Alejo：個人情報の流出だけでなく、こんな懸念もあります。中央集権化、あるいは中央障害点であるということは、ウォレットが多くの情報を持っているということであり、その情報は、ユーザーの取引に基づいて利益を上げようとするトレーダーにとって非常に価値のあるものとなります。人々は「フロントランニング」「バックランニング」「サンドイッチ攻撃」という問題も抱えています。この点についても、あなたのお考えをお聞かせください。

Robert：何らかの情報を持っていれば、それを悪用される可能性はあると思います。ほとんどの場合、利益を得るためにメンプールを見たり、チェーン上で起きていることを観察したりしているように思います。

Alejo：ウォレットは、こうした情報の発信源になっているのではないでしょうか？というのも、ウォレットはゲートキーパーではなく、トランザクションを通過させ、どのバリデーターがそれを拾うかを選択するような存在に思えるからです。

Robert：確かに、ウォレットの決済フローは非常に興味深いものとなります。今すぐ対応できるウォレットがあるかはわかりませんが、可能性はあると思います。最初に思ったのは、MEVを行うのはおそらくバリデーターではなく外部検索でしょう。だから、ウォレットがそれをやるとしたら、フラッシュスポットのようにトランザクションをストリーミングできるどこかのマーケットプレイスか何かに接続することになるでしょう。また、正直なところ、ユーザーとの信頼関係が損なわれるため、このようなことをするべきではないと思っています。

Alejo：そこに流れていることが分かっているということは、誰かがやっている、という議論になると思います。このようなことが起こっているのだから、それをオンチェーンにして、効率的な市場が発展するようにするべきではないでしょうか？フロントランされそうになっても、少なくともその分のお金は戻ってくるような安全なサロンをどうやって作ればいいのでしょうか？誰かがやってくれるのであれば、利益を一番に考えてくれるその誰かにやらせてあげればいいのではないでしょうか。

Robert：それは公平ですね。私も、注文の流れとブロックでの注文と、どちらが重要なのか明確にはわかりません。どちらも重要だと思いますが、最終的にはバリデータ自身が報酬を得ることになると思います。なぜなら、バリデータはすべてのトランザクションを受け取るので、オーダーの流れをコントロールするだけでなく、順序もコントロールしているからです。どのブロックが実際に生成されるかは、バリデータがコントロールしており、そのようなことに手を出さないようにしているのだと思います。

Alejo：問題は、みんながMetamaskを使っていて、Metamaskがデフォルトで全てを同じバリデーターに送っているとしたら、それは利益相反であるということです。トランザクションの送信先を認識する方法はあるかもしれませんが、そうすると、トランザクションの進行がかなり遅くなる可能性があります。

Robert：ただ、支払い注文の流れについては、Redditで大きな議論になっていますね。私は、これはあまり良いことではないと思います。ユーザーがどう受け止めるかという点で、ちょっとリスキーだと思います。

Alejo：何らかの形で料金を徴収して、AWSサーバーの代金を前払いしてもらうか。あるいは、料金は発生しないが、スプレッドとでも呼ぶべきものを支払うか。いずれにせよ、コストを透明化した上で、ユーザーに判断してもらう必要があるかもしれませんね。

Robert：実際に起きていることをユーザーが理解し、その側面を知っているのであれば問題ないことだと思います。ただ、ユーザーにはきちんと伝える必要があります。

Alejo：伝統的なハイテク企業の出身者は、素早く行動して物事を壊し、その失敗から学んでプロセスを改善することを良しとします。Robert、そしてJeffの考えをお聞かせください。

Jeff：私のバックグラウンドは教育で、その後Web3スペースにシフトした経緯があり、新しいプラットフォームのセキュリティに関するこのトピックは大好きです。私はコホートを運営して、開発者をトレーニングしていますが、まず最初にする話は安全なコントラクトとインフラを作るための方法についてです。監査やチェックは必要ですが、その過程ですべてをテストするための方法を、初日から開発者に教える必要があるということです。先ほどのお話のように、誰かが誤ってコードの中で何かをしてしまい、それがバレなければ何十億円ものお金になるわけですから、一歩間違えれば大変なことになります。ですから、セキュリティに強い人材を育成することは、製品のリリースと同じくらい大切なことだと思います。

Alejo：ちなみに、今後、実際にMove VMをCosmosでテストする予定です。Libra VMをフォークしてWasmに対応させ、CosmosのSDKで遊ぶことができます。Polkadotパラチェーンもありますし。現在は、Aptosに焦点を当てていますが、Cosmosにもアプローチしていきます。

さて、速く動いて速く壊すというテーマについてですが、実はKusama/Polkadotのエコシステムから、テストについて学んだことがあります。私は、アプリに2つのバージョンを持たせるというアイデアが好きです。1つはイミュータブルで変更不可能なもので、誰もマルチシグナルアクセスができないようにします。誰もそれを変更することはできません。監査に合格しているため、不具合がある可能性はありますが、そうでないことを祈ります。でも、そのフォークをアップグレード可能にして、素早くリリースできるようにしたらどうでしょう？この場合は、「これはまだ完全に監査されていないので、テスト中です」と言えばいいんです。そうすれば、素早く行動し、テストし、実験し、壊して、コードだけでなく、ゲーム理論さえも壊してしまうような、想定外の事態も得ることができます。これについて、ご意見をお聞かせください。

Robert：面白いデザインですね。私が一番気になるのは、ユーザーはどれを使えばいいのか、どうやって知ることができるのかということです。問題は、ユーザーがリスクの評価方法を知らないことだと思います。スマートコントラクトにしても、ハッキングされる確率を知ることは非常に困難です。私たちですらよく分かっていません。この場合、同じアプリに2つのバージョンがあり、一方はより安全で、一方はそれほど安全でないとしたら、よりリスクを負うことを厭わないユーザーは、常に出荷されている方を使うことができると思うんです。しかし、現実的には、どちらかがハッキングされた場合、その対応で一種のPRクライシスになると思います。

Alejo：そういう意味では、「this-thing-will-get-hacked.com」と「this-thing-is-not-going to get-hacked-(hopefully).com 」というような、より近い位置づけになりますね。自己責任で利用し、失う覚悟がある以上のお金をつぎ込まないように、巨大な免責事項をあらゆるところに書いておけばいいのです。

Jeff：インセンティブ付きのテストネットも良いモデルです。テストネットに参加し、フィードバックをするよう人々にインセンティブを与え、彼らに有用なトークンで報酬を与えれば多くの人々を捲き込んで実際にテストすることができます。

プロジェクトとしては、テストネットをゲーム化することでユーザーをテストネットを利用でき、最終的には全員にメリットが生じるわけですから。そこでの目標は「壊すこと」です。彼らは、製品を実際に壊すことで、インセンティブ付きのテストネットでより多くのトークンを獲得できる仕組みがいいでしょう。「これを使ってはいけません」とスクリーンに赤で表示しても使おうとする人は出てきてしまうものです。それであれば、「使って壊してくれたら、トークンをあげます」と言った方がいいのです。

この話を聞いている人の何割かは「それは開発者でないとできない」と思っていることでしょう。開発者だけでなく、一般のユーザーにも、技術的な観点ではなく、ユーザーとしての観点から、無造作に自分の開発したものを使ってもらい、それを壊してもらう仕組みが有用ではないでしょうか。

Alejo：私がインセンティブ付きテストネットのアーキテクチャについて考えているのは、別のネットワークを作るには2つの方法があるということで、自分のノードをスピンアップする方法です。そこで問題になるのは、そこに価値が流れないと、スパム対策ができないということです。ですから、私はKusamaのアイデアのように、本当に価値のある場所にリリースするというアイデアが好きなのです。

Aptosのメインネットでローンチした場合と、devnetでローンチした場合の違いは、Aptos devnetでは、トランザクションを送信するためにAptosトークンが必要なので、スパムをすることができないことです。スパム対策が施された実環境でこれを起動するにはどうすればいいのでしょうか？それには、何らかの形で実世界での価値が必要だと思います。そのためには、実環境での利用が必要です。完全な保護下に置いておいたのでは、壊れる可能性のあるものを全てテストしていることにはなりませんし、野放しにしておくと、スパム対策にもなりません。

Jeff：そうですね。では、テストトークンにゲームの要素を採り入れるのはどうでしょうか？それを使うだけでポイントが貯まり、後で実際の価値と交換できる仕組みです。参加者はプレイしてポイントを獲得し、ある閾値を超えると賞品を手に入れ、ある時点で実際の価値と交換することができます。この手法ではゲームに参加したがる人たちを十分に惹きつけ、他の方法では得られないようなフィードバックを得ることができるはずです。これは、うまくいく可能性があります。

Robert：懸念されるのは、それが実現可能かどうかという点でしょう。トークンの使用が実世界で価値を持つ場合、そのゲームの仕組み自体を悪用する可能性があるかもしれません。

Alejo：どのような仕組みであれ、スパム対策は現実世界の価値です。そのためにはコストがかかります。トークンに現実世界の価値があるという考え方は、明らかに哲学的なものだと思います。

例えば、ビットコインのクローンを作り、世に送り出したとします。そこに現実世界での価値はあるでしょうか？誰かがそれをスパム攻撃できるのであれば、それは実世界の価値ではないでしょう。しかし、誰かがスパム攻撃をするためにAptosトークンを必要とするならば、少なくとも現実世界の価値と結びつけ始めていることが分かります。私がボットで、1000ドルのガソリン代を使ってコインを手に入れ、このコインは1000ドルの価値があるとしましょう。この場合に、世界に送り出して何が起こるかテストしてみるのです。バグや脆弱性に対する報奨金と関連付ける必要があると思います。

Robert：もうひとつの懸念は、バグの多くがエッジケースであるため、意図的にコードを読み進めない限り、バグを見つけるのが非常に困難であるということです。時には、UIからバグを発見できないこともあります。UIは安全に使えても、UIを少し修正したり、独自のカスタムコントラクトを呼び出したりすると、悪用されてしまうこともあるのです。

Alejo：私が考えているケースとして、例えば、Aaveがv7に取り組んでいて、世界で誰もやったことがないようなまったく新しいイノベーションを考えているとします。彼らは1000万件の監査を受けることができますが、誰かが、このトークンを使ってこの融資をしたらどうなるかを考え、それを他のブリッジから持ってくるために、それを世に送り出す必要があります。そこにはコードにない奇妙なゲーム理論や経済攻撃が起こるかもしれません。実際の環境にないものをどうやってテストするべきなのでしょう？もし彼らがバージョンを公開して、それを人々に広めようとしているのであれば、実際に製品版でなくても、人々が本番環境でテストできるような方法があるのではないかと思います。これを安全に行う方法はあるのでしょうか？

Robert：経済設計やインセンティブモデルは、より理にかなっているかもしれません。なぜなら、素人でも内部の問題を見つけられる可能性があるからです。

Alejo：そうですね。もしハッキングができたら、報奨金やホワイトハットハッカーへの報酬が与えられるべきですから専門家でもいいわけです。それは、目に見える現実的な価値であるべきです。「もし壊したら、この値段だ」という具合に。Jeffが言っていたのもそういうことだと思います。これはいいアイデアだと思います。

Robert：それも有効だと思います。コントラクトや設計に目を向けるよう、コミュニティにインセンティブを与える様々な方法があるはずです。

Alejo：さてここでもう一つ質問を紹介しましょう。彼の質問はちょっと聞き取りにくかったのですが、たぶん最初の質問は、「実際に捕捉された脆弱性はあるのか」「このプロセスはどのようなものなのか」だと思います。

これらは全て報告書に掲載されますし、問題があれば監査機関と緊密に連携してリアルタイムに修正します。誰でも読めるようにレポートを公開し、安心して製品を使っていただけるようにしていくつもりです。これは、まったく新しいエコシステムにおいて、まったく新しい製品をリリースするプロセスなので、非常に慎重でなければなりません。Pontemの全ての製品は、リリース前に複数の監査を受けていきます。

Robertが監査を手伝ってくれるおかげで、予定通りにリリースの準備が整う予定です。また、前述のように、ウォレットに対するハッキングテストを数多く行う予定です。これは非常に重要なことです。Aptosが本稼働すれば、メインネットでこれらの製品を使うことができるようになります。今は全て開発者ネットワーク上で動いています。liquidswap.comをチェックして、試してみてください。

さて、コミュニティとセキュリティの関係について、ロバートさんのお考えをお聞かせください。

Robert：ユーザーの維持は、最も厄介なことの1つだと思います。dAppsはもちろん、特にウォレットでは、ユーザーのランディングページをマネタイズするのが基本だと思います。だからMetamaskは比較的高い手数料を取ることができ、そうやって収益化しているのです。セキュリティについては、私たちは直接コミュニティと仕事をしているわけではありませんが、コミュニティをとても大切にしているプロトコルと仕事をしていると思いますし、私たちもできるだけコミュニティで活動しようと思っているので、例えばこのイベントにも参加しているわけです。

プロトコルはもちろん、ユーザーからのフィードバックを聞き、監査法人としてユーザーにどう対応するのがベストなのかを理解しようとするのは良いことです。結局のところ、私たちは皆、ユーザーのために奉仕しており、この場所を皆にとってより良いものにするためにベストを尽くそうとしているからです。

Alejo：そうですね。そして、安全だと感じられれば、人々はこの場所に留まりたいと思うのではないでしょうか。人々が安全だと感じられるようにすることが一番の優先事項であることに間違いありません。

Robert：その通りです。最近、暗号分野はセキュリティの問題でネガティブな注目を浴びています。でも、私たちが大切にしていることのひとつは、できれば私たちが扱うプロトコルがそうした問題に直面することがないようにすることです。それが目標です。

私の方からは以上です。本当に楽しかったですし、私を呼んでくださってありがとうございました。

Alejo：ご出演ありがとうございました。次回また、他のゲストもお呼びする予定です。また来週お会いしましょう！

Pontem Networkの記事をお読みいただきありがとうございます。今後もチェーンやプロジェクトの枠を超えて、暗号/ブロックチェーン分野全体の発展に向けた情報材料の共有に取り組んでいきます。

Pontem Network

Pontem Networkは、最も高い生産性と安全性を持ち、スケーラブルなブロックチェーンであるAptosの基盤となるdAppsと開発ツールを構築している製品スタジオです。私たちはAptosチームと共に、私たちは世界中の最初の10億人のブロックチェーンユーザーを参加させることのできるエコシステムを構築しています。Pontem Networkの製品は、Move言語とMove VMを使用しています。これらは、元々Metaが支援するブロックチェーンであるDiemのために開発された技術です。

Pontem Networkの将来的なトークンリリースに向けたホワイトリスト登録はこちらから！また、アンバサダーも募集中です。