回復する術はなく、YAM投票救出作戦は最初から失敗する運命にある

36 時間以内に建物が隆起し、数分以内に建物が崩壊するのを彼は目撃しました。

北京時間8月13日午前3時、注目のDeFiプロジェクトYAMファイナンスが流動性マイニングの開始を発表、わずか1日でロックされた資産の価値は6億ドルを超え、ロックされた資産の増加量と成長率は資産はほぼ狂気の状態に達しました。そして、この展開によれば、初期段階でプールに流動性を注入した一部の羊毛関係者の年利は200倍に近づく可能性もあり、狂気の度合いを示している。

しかし、皆がマイニングカーニバルに夢中になっているとき、事故が起こりました。

副題

ヤムイモの小さなサツマイモの保存方法は？

この脆弱性を発見した後、YAMチームは「救済作戦」を開始し、ガバナンス提案を提出するには16万の代表投票が必要であるとして、コミュニティに投票を呼び掛けた。この精力的なコミュニティ投票活動は間もなく完了します。

しかし、誰もがただの誤報だと思ったとき、北京時間8月13日午後16時1分、YAM創設者のブロック・エルモア氏が「皆さんごめんなさい、失敗しました」とツイートした。はぁ？

PeckShield のセキュリティ担当者が分析に介入した後、すぐに問題の本質を突き止めました。弾力的な供給メカニズム (リベース) にコード式のエラーがあり、2 回目のリベース時にシステムが自動的に 10 ^ 18 個の新しいトークンを発行しました。これが高レベルに維持されると、後続のリベースごとに指数関数的な増加が引き起こされ、Little Sweet Potato YAM の数が恐ろしい天文学的な数字に変わります。これは、コミュニティが後の段階でどのように投票を委託しても、システムを制御するのに十分な票を獲得することができず、システム全体が制御不能、マスター不在の状態に陥ることを意味します。

当初、YAM関係者は、この既存の抜け穴を修正するために、すべてのYAM保有者に対し、代理投票による投票「救済作戦」を完了するよう呼びかけた。しかし、ペックシールドのセキュリティ担当者によるさらなる分析により、YAM当局が控訴を始めた時点で、救出活動は実際には失敗する運命にあったことが判明した。

理由は 2 つあります。

1）時間が遅すぎます: YAM 関係者が 1 つの点を見落としている可能性があります。投票救援活動の準備が完了してから提案が実施されるまでには、少なくとも 12.5 時間かかります。現在の時間リズムによると、実施が発効するのはいつかです、2 番目のリベースはすでに完了しています。

2）新しくデプロイされたガバナンス契約は効果的に実行できません: 2 回目のリベース トリガーにより、担当者は実行時間後に新しいガバナンス コントラクトを実行すると予想していましたが、投票総数が総投票数の 4% に遠く及ばないことが判明しました。契約で合意されているため、効果的に実施することができません。

副題

まず、YAM スマート コントラクトの柔軟な供給メカニズム (リベース) を紹介します。

1) 市場価格の変動に応じてトークンの供給を動的に調整するシステムであり、市場価格が上昇すると、それに比例して追加トークンが発行され、単位トークンの価値が 1 ドルになるまで減額されます。

2) リベースは 1 日 2 回行われ、リベースごとにトークンの供給量が変化し、現在の市場価格に応じて一定量のトークンが発行または破棄されます。

提案の実行における重要な要素についてお話します。所有者が投票を委託し、投票数が全体の 1% を超えた場合、提案は実行および手配され、契約に応じた実行時間が必要となります。 12.5 時間待機し、提案が実行されると、投票数が全体の 4% を超える必要があります。この方法によってのみ、新しいガバナンス契約が実装されて発効し、プロジェクトが正常に動作し続けることができます。

上記の技術的なポイントを踏まえて、YAM の公式フォローアップスケジュールを見て、なぜこの救出活動が失敗する運命にあるのかを理解しましょう。

以下のタイムラインに示すように:

②最初のリベースが発生するタイミング コントラクトのバグによりtotalsupplyの資産が異常に高騰しており、担当者がバグの存在を発見し公開しました。

しかし事態は裏目に出て、当局が抜け穴を発見して投票の呼びかけを公表するには遅すぎ、成功する可能性のある唯一の黄金の緊急期間を逃した。さらに悪いことに、公式のタイムリズムによれば、新しいガバナンス契約が⑦の実行時刻に達すると、投票数は総量の4%を超えなければならず、この時点での総量は10^18*10倍に拡大しています。 ^18 、以前に蓄積された投票数はすでにバケツの一滴であり、まったく役に立ちません。

したがって、この救出作戦は最初から失敗する運命にあった。

以下では、このインシデントの詳細な分析を行います: (プロジェクト パーティの github アドレスhttps://github.com/yam-finance/yam-protocol）

画像の説明

図 1. 最初のリベースでのアセットの変更

上記のチェーンの情報として (https://oko.palkeo.com/) は、最初のリベースの後、totalSupply が 3,500,000* 10^18 から最大値まで急上昇していることを示しています。

コード内で何が起こったのかを確認するために、コードをさらに分析してみましょう。 まず、チェーン上の情報から、リベース操作が YAMRebaser コントラクトの YAMRebaser::rebase() 関数を呼び出していることがわかります (最初にこの関数をスキップし、これについては後で説明します)、YAM コントラクト (0xa923af6d05993495257a872ec69dbbf01501eb0e) の rebase() 関数を呼び出すことで totalSupply が再計算されることが最終的にわかりました (コード ロジックは以下の図 2 に示されています)。340 行目の totalSupply 割り当て操作では、次のことができます。このコード行には明らかなエラーがあることがわかります。BASE を除算しなかったため、totalSupply の値が 10^18 倍増加しました。

画像の説明

図 2. YAMToken::rebase() が異常に大きな totalSupply 値を取得する

そして 12 時間後、YAM は 2 回目のリベースをトリガーしました (https://oko.palkeo.com/画像の説明

図 3. 2 回目のリベース資産の変更

画像の説明

図 4. YAMRebaser::rebase() が間違った totalSupply を使用して initSupply を計算する

副題

なぜプロジェクト当事者の準備作業の完了が遅すぎたと言われるのでしょうか?

画像の説明

図 5. GovernmentAlpha::queue() 関数は eta (有効時間) を設定します

そして、なぜこれまで行われてきた救出活動が全く役に立たなかったと言えるのでしょうか？

画像の説明

図 6. GovernmentAlpha::execute() による提案ステータスのチェック

画像の説明

図 7. GovernmentAlpha::state() を実行すると Defeeted エラーが返される

画像の説明

図 8. GovernmentAlpha::quorumVotes() が間違った外れ値を返す

画像の説明

画像の説明

要約する

このYAM脆弱性イベントにより、最終的にガバナンスコントラクトの75万yCRVが永久ロックされ、急速に急落して短期間で回復できない状況となり、何人の人が高値で埋もれたか分かりませんが、これは今日の DeFi 流動性マイニングの最も真実な描写です。残酷で魔法的ではありませんか?プロジェクト当事者がコントラクトをデプロイする前に一度リベース プロセスをテストしていれば、抜け穴の存在を確実に見つけることができます。 DeFiプロジェクトにおけるセキュリティ監査の重要性を理解するだけで十分です。

要約すると、PeckShield はこれを利用して次のことをアドバイスしたいと考えています。ブロックチェーンの世界では、契約コードのすべての行に畏敬の念を抱くことが重要です。わずかな省略でも取り返しのつかない事態を引き起こす可能性があるためです。。結局のところ、コードは人間によって書かれており、抜け穴を完全に回避することは困難であるため、契約をオンラインで展開する前に、プロジェクト当事者が十分なテストと第三者によるセキュリティ監査作業を行う必要があります。潜在的な契約コードを早期に発見してトラブルシューティングします。セキュリティ侵害が発生してから修正しても遅すぎます。