Vitalik: RAI システムを例として、オラクル マシンを共同ステーキングする可能性を探ります

原作者：Vitalik Buterin

原文の編集: The Way of DeFi

原作者：

原文の編集: The Way of DeFi

RAI にとっての主な課題の 1 つは、特に金利が現在の約 -5% ～ -10% の水準よりも高い場合に、LP として行動する意欲のある ETH 保有者を見つけるのが難しいことです。この問題の主な理由は、現在、RAI CDP が利回りの源としてステーキングと競合していることです。

この問題の解決策として複数担保 RAI を検討している企業もあります。これについての私の個人的な見解は、DAIはすでに任意の（「現実世界の資産」を含む）多担保アルゴリズムのステーブルコインとしてニッチ市場を満たしているため、RAIエコシステムがこの分野で競争するのは意味がありません。したがって、私の意見では、RAI (またはフォーク) を複数担保にすることは、「複数担保」が非常に狭い形式の複数担保 (ETH および担保された ETH) を意味する場合にのみ意味があります。

この記事では、これを行うためのいくつかの方法について説明します。

画像の説明

Eigenlayer画像クレジット: Maze AI ツールによって生成

(単独の) ステーカーに、ステークした株式を CDP 担保として二重に使用させることはできますか?

は、特定の条件が満たされた場合にのみ資金を返すコントラクトに引き出しアドレスを設定することで、ステーカーが自分のステークを他のアプリケーションで再利用できるようにするツールのセットです。アイゲンレイヤーを使用するバージョンの RAI を作成することも考えられます。ユーザーは、RAI 債務を返済した後にのみ返還されるコントラクトに引き出しアドレスを設定することで、誓約した ETH を CDP に預け入れます。ユーザーが清算された場合、契約のロジックにより ETH の所有権が清算人に譲渡されます (これにより、プロトコルで可能な場合には直ちに引き出しもトリガーされます)。

このアプローチの主な課題は、通常の状況では非常にまれで非常に低いペナルティでうまく機能しますが、極端な場合にはシステムのセキュリティが大幅に低下する可能性があることです。特に、攻撃者が 51% 攻撃 (または、一部の提案者を斬るなどのより穏やかな攻撃) を実行しようとしている場合、システムの攻撃に使用されるすべてのバリデーターを RAI-CDP に入れ、可能な限り多くのバリデーターを RAI から取り出します。理にかなっています。

攻撃者がこれを行うと、事実上、システムから RAI を「盗み」、システムに RAI 建ての負債を負わせることになります。このシステムは、競売にかけて FLX または ETH の準備金を使用して RAI を買い戻すことで、迅速なリバランスを試みる可能性がありますが、依然として破産のリスクがあります。

RAI は Lido の stETH のみを使用できますか?

これは、RAI が上記の問題に対処しながら最小限の作業で済む可能性があるアプローチです。ただし、stETHのようなステーキングシステムをさらに統合すると、イーサリアムレベルのシステミックリスクにつながる可能性があるため、このアプローチには懸念があります。市場での優位性がさらに高まると、stETHを管理するシステムに大きな信頼がもたらされ、イーサリアムステーキング全体に新たな攻撃ベクトルが導入されることになる。これは、集中ステーキングデリバティブほど stETH には当てはまりませんが、それでもリスクです。

このため、私は、単一の支配的な流動性ステーキングデリバティブに関するネットワーク効果を回避するために、ステーキングされた ETH を担保として使用する方法を見つけようと強く思っています。また、RAI は担保資産の代替可能性を必要としないため (CDP は代替可能ではないため)、RAI は実際にソリューションの一部となり得ます。

アイデア 1: ステーカーとしてのオラクルRAI CDP (または RAI) を持つ人は誰でも、RAI のオラクル システムが自分の資金を盗むことはないという高い確信を持っています。 RAIオラクルがゼロに近いETH/USD価格を報告し始めた場合、すべてのCDPは清算され、その保有者には何も残らないことになります。 RAI保有者（おそらく最大の攻撃者が想定される）は、CDPを購入し、その中のETHを非常に安価で入手できるようになる。このため、Oracle システムに対する信頼は非常に真剣に受け止められる必要があります。特に、プロトコル投機トークン (ここでは FLX) の 51% が、長い遅延なしに直ちにオラクルプロバイダーの変更に投票することは不可能です (そうしないと、資金の総額がリスクにさらされている環境ではシステムが安定しません) FLX 実行の時価総額を超えています)。私自身のベストモデルの意見はおおよそ次のとおりです。

それで

の。

とにかく、重要な観察は、RAI保有者はすでにこのような方法で自分たちを台無しにしないという神託を信頼しているため、他のリスクの少ないセックスの方法でも神託を信頼しても、システムの脆弱性が増大することはないようだということです。

自然な選択: RAI 自体が Lido のコピーを作成します。CDP を作成するユーザーは、RAI オラクルをステーキング キーとして設定してこれらの資金をステーキングできます (おそらく、RAI オラクルは分散型バリデーターを集合的に実行できます)。ただし、CDP を出金アドレスとして設定します。

ここでの信頼レベルは、見かけほど高くありません。不正な RAI オラクルは、スラッシュまたは非アクティブな状態からの漏洩によって資金が侵害される可能性がありますが、攻撃者が攻撃する特殊な MEV 攻撃などのごく一部の例外を除いて、資金を盗むことはできません。二重提案の場合は削減されます。

しかし、まだ完璧ではありません。このまれで特別な攻撃は可能ですが、オラクルが賭け金を賭けるつもりかどうかは明らかではありません。ステーキングの法的リスクは、多くの法域において明確な言論の自由の「情報のみ」のカテゴリーに分類されるオラクルプロバイダーであることの法的リスクよりも高いようです。これはまた、彼らを攻撃する大きな動機を生み出します。DVT 。

アイデア 2: オラクルを 2-of2 ステーカーとして使用する

• これは、ユーザーがより多くの制御を保持し、オラクルへの信頼を減らすことができる代替手段です。オラクルに属する誓約キーの代わりに、誓約キーは P + Q になります。ここで、Q はオラクルに属するキー、P は CDP 所有者が保持するキーです。 BLS 署名のアルゴリズム特性により、オラクル マシンは Q で署名し、CDP 保有者は P 自体で署名し、2 つの署名を加算して P + Q を検証する署名を作成できます。これは基本的に 2-of2 です

• これにより、信頼プロパティが次のように強制されます。

• 神託だけでは CDP 保有者を没収することはできません。

• ブロック提案には CDP 保有者の署名が必要であるため、オラクル自体は提案者攻撃を実行できません。

• CDP 保有者は切りつけたり攻撃したりすることができないため、この方法でシステムの担保を侵害することはできません。

オラクルまたは CDP 保有者はオフラインになる可能性があります。この場合、相手はイグジットをトリガーし、ほとんど損失なく CDP を終了します。

極端なケースは、非アクティブなリーク中にオラクルまたは CDP ホルダーがオフラインになる場合です。この場合、いずれの当事者も相手方に損害を与えることがあります。

• 埋め込む

• この設計は DVT の特殊なケースです。

• これは 2-of-2 なので、ネットワークの観点から見ると最も単純なケースです。

1 of 2 (Oracle) は何千ものパートナーにサービスを提供しています。ただし、同じデータに署名するだけで、連携するすべての CDP にダウンロードできるように公開することができます。

ブロック生成を自律的に保つために、この特定のケースでは、提案者が署名するものを選択し、それを共同署名のためにオラクルに送信するシステムを使用できます。オラクルは、同じドメインの同じスロットで 2 つの異なるデータに同時に署名しないでください。これは、CDP を攻撃する目くらましのトリックと組み合わされる可能性があります。

これは実装する必要がある新しいテクノロジーであるため、実際に実現するには DVT チームの協力が必要になる可能性があります。一度構築すれば、操作はそれほど難しくないはずです。

アイデアの弱点 2

このシステムの最大の脆弱性は、非アクティブなリークです。これは、オフラインのオラクルによってのみ引き起こされる可能性があるためです。しかし、そのリスクを受け入れても問題ないと思います。残高が 16 ETH を下回ると、バリデーターは自動的に終了して ETH を引き出します。したがって、1.5倍の通常のETHを提供する代わりに、2倍の担保要件でステーキングされたETHを単純に受け入れることができます。Puffer多くのバリデーターが同時にリークした場合、一度に数個しか終了できないというエッジケースがあるため、一部のバリデーターは 16 ETH 未満のリークに対してさらに罰せられますが、これはイーサリアムステーキングプロトコルが変更される可能性があります。ご要望がございましたら修正がなかったとしても、誠実なバリデーターによって管理されている残高の割合が 2/3 以上に戻る前に、16 ETH をはるかに下回る大規模なバリデーター漏洩による、非常に極端な攻撃 (50% 以上がオフライン) が必要となるでしょう。

もう 1 つの大きな欠点は、主な懸念が悪意のあるオラクル スラッシュではなく、悪意のあるまたは不注意によるオラクルのオフライン化である世界ではうまく機能しないことです。これは、(i) 技術的な習熟度よりも誠実さを重視して最適化しているため、オラクルが低品質のステーカーであると予想しているか、(ii) オラクルが信頼できるハードウェアを使用しており、ユーザーがこれが (部分的な) 信頼の前提であることを受け入れているためであると考えられます (「

）。これらの弱点に対処するために、以下のアイデア 3 を提案します。

アイデア 3: 階層型セキュリティのための半信頼されたオラクル

オラクルの大部分が誠実であることが保証できる場合は、他のアプローチにより、残っている信頼の問題が解決されます。
3 つの定数を定義します。
N: オラクル システム内のオラクルの総数。

k 1 : CDP保有者とメッセージに署名できるオラクルの数(例、k 1 ~= 0.2 * N)

• k 2 : CDPホルダーなしで連携してメッセージに署名できるオラクルの数(例: k 2 ~= 0.8 * N)

• オラクルには次の 2 つの秘密共有キーを維持する必要があります。

Q1、k の 1-of-N 秘密分散

P + Q2、k 2-of-N 秘密分散 (各 CDP 所有者に対する後者)

• Q1 の場合、オラクルは CDP 保有者と共同署名でき、Q2 の場合、独立して署名できます。

• k 1 + k 2 = N (例: k 1 = N/5 および k 2 = 4 N/5 ) の場合、これにより、どちらの場合でもスラッシュおよび非アクティブ リークが発生しないことが保証されます。

k2 オラクル以上は正直です (独立してメッセージに署名できるため、悪意のある CDP 保有者は共同署名する k1 クォーラムを見つけることができません)。

少なくとも k 1 個のオラクルは正直であり、CDP 保有者も正直です (2 つのグループは一緒にメッセージに署名できますが、残りのオラクルは署名もブロックもできないため)。

このスタイルは Rollup のフェーズ 1 補助輪に似ており、両方を部分的に信頼し、一方を過度に信頼しない方法として 2 つのセキュリティ モデル間に線形混合を作成します。

• この設計は、アイデア 1 と 2 (または「CDP 保有者が自分自身に署名できる」提案) を一般化したものと見なすことができることに注意してください。k 1 と k 2 は、誰を信頼するかというトレードオフの空間全体を探索するために、必要に応じて調整できます。 。

• これらのアプローチの一般的な利点 (アイデア 1/2 または 3)

• 信頼性があり中立であり、外部依存を導入しません。参加者のみを信頼し、より高度な信頼が与えられています。

ユーザーが CDP を誓約し、同時に保持できる利点を実感してください。

• 既存の流動性担保デリバティブのネットワーク効果を不必要に促進することは避けてください。代わりに、プログラムによって維持されるステーブルコインは、（安定した）液体担保デリバティブです。

• アイデア 1、アイデア 2、アイデア 3 を比較する

• 実装の容易さの順にランク付けされます。アイデア 1 > アイデア 2 > アイデア 3

• 悪いお告げを防ぐことでランク付けされ、アイデア 3 > アイデア 2 > アイデア 1

悪質な CDP 保有者に対する保護によってランク付けされています。アイデア 3 > アイデア 2 > アイデア 1