Ethereum でメッセージ入力メカニズムを使用するためのベスト プラクティス
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
、著者: Teller Core、翻訳および校正: Chen Liang & A Jian、Odaily の許可を得て転載。
分散型金融アプリケーションは、イーサリアム エコシステムにおいて初期の急成長カテゴリーですが、その重要な部分である情報入力メカニズム (オラクル、旧訳では「情報入力メカニズム」) がみんなの注目を集めています。情報入力メカニズムがなければ、分散型金融アプリケーションはオンチェーン データしか取得できず、実際のアプリケーション シナリオへの適応性は大幅に制限されます。また、多くのプロジェクトがすでにオフチェーンの情報入力メカニズムを使用していることを多くの人が知っているかもしれませんが、情報入力メカニズムの使用と関連するセキュリティ対策については誰もが理解していません。セキュリティを強化するために再設計される新しいプロジェクトや既存のプロジェクトがますます増えているため、この記事が情報入力メカニズムの使用方法に関するベスト プラクティスの参考として役立つことを願っています。メッセージ入力メカニズムの最適な設計原則とセキュリティ モデルについてはあまり説明しませんが、イーサリアム上でアプリケーションを構築する場合にメッセージ入力メカニズムを使用する方法についてのみ説明します。また、開発するアプリケーションがセキュリティ、検閲耐性、分散化を実現できることを望む場合は、イーサリアム スマート コントラクトを構築する際に次のような提案があります。
推奨事項 1: プロトコルでは情報入力メカニズムの設計と対話を優先する必要があります
情報入力メカニズムの最も単純な形式は、集中型入力メカニズムです。ユーザー (プロジェクト作成者) が価格情報を入力します。多くのプロトコルが起動時にこれを実行し、安全性を確保するために単純なマルチ署名のみを使用します。これらのプロトコルは「進歩的な分散化」の道を選択すると主張し（この声明には多くの問題があります）、将来的には分散化された情報入力メカニズムに切り替えると宣言しています。ハッカソンに参加するだけなら問題ありませんが、プロジェクトの初期段階では、集中型の情報入力機構の性能が分散型の情報入力機構に比べて高いため、安易にハッカソンを始めることができません。新しいプロジェクトをアップしました。正確な値が常に即座にチェーンにコミットされるという前提がある場合、システム容量とユーザー エクスペリエンスに関する設計上の決定は大きく異なります。
この進歩的な分散化のアイデアを実践するプロジェクトは現在、ユーザーが特定のエクスペリエンスを期待しているにもかかわらず、その製品が既存の分散化技術スタック上で安全に動作しないという厄介な状況にあります。彼らは、一元化されたマルチシグに複数の関係者を含めることで分散化を装うことを余儀なくされたり、缶の考え方を蹴飛ばして、パブリック チェーンのスケーラビリティという不可能な三角形が幸運にもうまく解決されることを期待したりします。ここで重要なのは、プロトコル設計の最初から分散型情報入力機構を考慮しなければ、分散型情報入力機構を既存プロトコルにアップデートすることは困難であるということである。
アドバイス 2: 情報入力メカニズムが常に迅速に応答することを信頼しないでください
イーサリアムはまだ新しいため、多くの場合、ブロックは数秒で生成されますが、頻繁に送金が行われる場合には、トランザクションの確認に時間がかかることがあります。ブロックチェーンゲーム「Cat Obsession」によるブロックチェーン封鎖事件や、送金手数料の高騰を引き起こした最近の「ブラックマンデー」事件を覚えている方もいると思いますが、この時ユーザーは信じられないほど高額な送金マイナー手数料を支払わなければなりませんでした。彼らの取引がスムーズに確認されるようにします。プロトコルのユーザーにはこれらの料金を支払う経済的インセンティブがあると思うとしても、本当に料金の支払いを強制されることを望んでいますか?
ネットワークの混雑の問題に加えて、開発者はイーサリアムのクラッシュという特殊なケースも考慮する必要があります。ブロックチェーン ネットワークが長期的に停止する可能性は低いですが、短期的に停止する可能性はあります。そのため、最終性のないオンチェーンおよびオフチェーン (多くの場合) の迅速な情報入力メカニズムの影響を考慮する必要があります。私たちは、プロトコルが正常かつタイムリーな動作を維持できることを常に望んでいますが、最終的な動作を確認するためにプロトコルを数分間実行する必要がある場合、情報入力メカニズムが情報を入力できない場合など、それができない場合があります。これは、情報入力メカニズムの時間枠を設計するためのすべてのスキームが推奨されないということではありません。情報入力メカニズムの実際的な操作間隔を設計することは良いことですが、安定した分散型金融プロトコルは、このような突然の極端な状況に備えるべきです。 . 準備をしてください。そのうちの 1 つは次のとおりです。
副題
推奨事項 3: 情報入力メカニズムが壊れている可能性があると想定する
情報入力メカニズムに最終性を想定しないでください。多くのプロトコルは、特定の操作を実行するために情報フィードを更新するという間違いを犯します（たとえば、デリバティブ契約は情報フィードが更新されたときにのみ決済されます）。これは間違いです。情報がメカニズムに誤って入力される事態を防ぐために、たとえそのようなことが起こらないことを願っていたとしても、標準的な操作手順を定めておく必要があります。
要約すると、情報入力メカニズムで発生する可能性のあるエラーには 2 種類あります。
メッセージ入力メカニズムが間違った値を送信しました。
メッセージ入力メカニズムがダウンしているため、メッセージをチェーンにプッシュしていません
最初のタイプの問題は、たとえば、集中型の価格フィード メカニズムを使用していて、価格プロバイダーが誤って価格に 10,000 を掛けた場合、この値で決着することは絶対に望ましくなく、フィード メカニズム自体さえもこの値は削除されました (Tellor メッセージ入力メカニズムでは、これは紛争を引き起こし、取り消されることになります) が、疑問は残ります。データが検証されるまでどのくらい待つのですか?
一部のスマート コントラクトでは、他のものよりも遅い/より堅牢なチェックおよび確認メカニズムが必要な場合があるため、これは最終的にはプロトコルの安定性に依存します。このメカニズムの好例は Maker プロトコルです。このプロトコルでは、情報入力メカニズムによって渡された情報は 1 時間の遅延で有効になります。しかし、これが必ずしも正しいとは考えず、慎重に考える必要があります。
情報入力メカニズムのメカニズムを損なう 2 つ目の方法は、より回りくどいものです。一例として、集中情報入力メカニズムが秘密鍵を失い、契約を更新できなくなる場合がありますが、このときデリバティブのスマートコントラクトはどうなりますか?情報入力メカニズムの活動に影響を与えるもう 1 つのことは、情報提供者が情報を迅速に提供しようとしないことです。イーサリアム ネットワークが混雑していて、トランザクションあたりのマイナー手数料が 20 ドルで、情報入力メカニズムがトランザクションあたりのトランザクション手数料を 1 ドルしか提供しないと仮定すると、提案 2 に戻り、スマート コントラクトの更新には数時間かかる可能性があります。 、これに備える必要があるかもしれませんが、情報プロバイダーがこの遅延を一方的に制御する能力があるかどうかも知っておく必要があります。テラー情報入力メカニズムでは、POW の競争を通じてデータをチェーン上に置くため、その活動はインセンティブメカニズムによって保証されます。より集中化された一部の情報入力メカニズムにはそのような保証がなく、情報入力メカニズムのプロバイダーはトランザクションの遅延を許容したり、賄賂や自らの立場に基づいてデータを検閲したりする可能性があります。
情報入力メカニズムに破損の疑いがある場合、または集中的なレビューが必要な場合には、次のような多くの対抗策があります (もちろん、それを使用しないことが最善であると考えています)。
コントラクトの実行を停止し、情報入力メカニズムが正しい値をフィードバックするのを待ちます。
複数の情報入力メカニズムを利用する
すべての資金を返却する / デフォルト値で決済を完了する
私たちが言及する情報入力メカニズムのバックアップとセキュリティは、主にプロトコル レベルに重点を置いており、統一されたパラダイムでそれぞれの場合にバックアップ オプションをどのように使用するかを表現することは困難ですが、すべての関係者がそのようなインセンティブを持たないようにする必要があります。これらのバックアップを個別に取得するオプションを使用する場合、バックアップ メカニズムの目的はネットワークを安全に保つことであり、悪意のある攻撃に別のパスを提供することではありません。
あなたが認めるか認めないかにかかわらず、攻撃者が情報入力メカニズムを侵害する方法は常に存在しますが、代償は異なります。このコストは、評判やチケットの購入にかかるコストである場合もあれば、プロジェクトによって発行されたトークンの市場価値の一部である場合もありますが、おそらくより多くの場合、情報プロバイダーを汚すコストや、関連する参加者をレビューするコストである場合があります。従来の集中型モデルと同様）。情報入力メカニズムを破るコストが実際にどれほど高くても、あるいは情報入力メカニズムを破るコストが一定ではないとしても、プロトコルのセキュリティについて一般的に理解しておく必要があります。いつか数百万ドル、さらには数十億ドルの資金を保有したいと考えているプロジェクトにとって、市場価値がわずか数百万ドルのトークンを使用して、情報入力メカニズムのセキュリティを裏付けたり、特定のグループの評判を裏付けたりすることです。大きなリスク。
結論は
情報入力メカニズムを破壊するコストを知ることで、プロトコル開発者は、システムの安定性を確保するためにどの程度のセキュリティ対策が必要かを理解できるようになります。1 つの情報入力メカニズムを使用すると、スマート コントラクト資産のセキュリティが保証されない可能性がありますが、複数の情報入力メカニズムを使用すると、この計画により、契約を攻撃するコストが大幅に増加します。現在、一部の人々は、新しいプロトコルが複数の情報入力メカニズムを契約に簡単かつ迅速に統合できるように、価格とデータフロー情報を標準化するイーサリアムアップグレード提案（EIP2362）を提出し始めています。
