トレーダーが ezETH トークンで 2,600 万ドルを失う: メディアはユーザーを非難、ハッカーは ERC-20 の欠陥を指摘

• 私の名前はデキサランです。私はハッカーで、業界で最大規模のコンセンサスレベル攻撃を設計し、実行しました。2019年に私はEOSネットワークのメインネットをDDOS攻撃し、コンセンサスリソースモデルの欠陥を悪用して1か月間凍結させました。EOSは当時トップ7にランクされていました。( EOSGOレポート、コミュニティレポート)

  
  

• 私はイーサリアムクラシックのコア開発チームの創設者の一人です。（ Cointelegraphの記事）

  
  

• 私は、POW チェーン業界の悩みの種であった51% 攻撃を解決する一連のルールである、 Nakamoto コンセンサスの修正案を設計しました。

事故

あるユーザーが、ezETH トークンをスマート コントラクトに送信したことにより、2,600 万ドル相当を失いました。これはユーザーのミスであると主張する記事や Twitter スレッドが複数あります。たとえば、 CoinTelegraphによるこのスレッドなどです。

これは誤りです。同様のユーザーミスでは、Eth、NFT、またはERC-223トークンが失われることはありません。外部所有のアドレスへの転送とスマートコントラクトへの転送は動作が異なります。

ユーザーが間違ったアドレス（スマートコントラクトではない）や誰にも所有されていないアドレスにトークンを送信した場合、それはユーザーのミスになります。

ただし、この場合、ユーザーはスマート コントラクトにトークンを預けています。スマート コントラクトはこうしたミスを防ぐことになっており、確かにそれが可能です。たとえば、ユーザーが Ether (またはその他のネイティブ通貨)、NFT (ERC-721)、またはERC-223トークンを、それらを受け取るように設計されていないスマート コントラクトに預けた場合、トークンは失われません。トランザクション エラーが発生し、トークンの転送は行われません。

エラー処理は、ソフトウェア セキュリティの最も基本的な原則の 1 つです。呼び出しエラーを適切に処理できないようなソフトウェアの設計は、ガバナンス機能のonlyOwner修飾子が欠落しているのと同じであり、セキュリティ上の問題になります。

これはERC-20標準の問題です。エラー処理が不可能になるような設計になっています。そしてこれはセキュリティ上の問題です。ERC -20標準は安全ではありません。2023年に、 ERC-20標準の作成者自身が、これが標準のセキュリティ上の問題であることを確認しました。

私は2017年にこことここでこのことを報告しました。また、私は2017年にまさにこの問題を解決するためにERC-223標準を設計しました。ここにオリジナルのEIP-223スレッドがあり、この標準が金銭の損失を防ぐことが強調されています。

セキュリティ企業や開発者が、ミスを犯したユーザーを責めるのは非常に簡単です。しかし、ユーザーのミスに対処できない安全でない標準を使用してアプリケーションを構築し、このような悲惨な損害をもたらした開発者の責任です。

歴史

私は、これがユーザーに経済的損害を与える可能性があることを強調し、Ethereum Foundation に報告しました。彼らは何もしませんでした。7 年間も。

• 2017 年にはこの問題により 16,000 ドルの損失が発生しました。
• 2018年には200万ドルが失われた
• 2023年に6000万ドル
• 2024年11月1日には90,000,000ドル（ezETH契約で失われた2500万ドルを除く）がありました。
• 今では1億1500万ドル

私のチームは、失われたトークンの量を計算するスクリプトを開発しました。

https://dexaran.github.io/erc20-losses

• 2017年に別のユーザーが13万ドルを失いました。
• 2020年に、あるユーザーが生涯の貯蓄を失いました。
• 2023年に、ユーザーは1回の取引で24万ドルを失いました。
• その後、Poloniexのハッカーは250万ドルを失いました。

2017 年にこのセキュリティ問題のため ERC-20 標準の推進をやめるように要求しましたが、応答はありませんでしたhttps://github.com/ethereum/ethereum-org/issues/755 。

私はこの問題を、Ethereum で EIP を管理している EthereumCatHerders にエスカレートしました。

2023年に彼らは「当社はセキュリティ開示とは一切関係がなく、そのためのプロセスもありません」と返答しました。

説明: EIP と ERC は、誰でも Ethereum に提出できる提案です。これらは、開発者が Ethereum の動作に適用する標準または変更になることがあります。これらは、github リポジトリ内のテキスト ファイルです。

背景: Ethereum プロジェクトの開始から 10 年が経過した現在でも、EIP のセキュリティ開示に対処するプロセスが確立されていません。

私は、セキュリティ開示を可能にするために EIP の動作を変更する方法を提案していました: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

私は ERC-20 に警告を追加し、EIP に問題を文書化することを提案しました。以下は彼らの電話です。彼らは、EIP-20 の脆弱性を明らかにする別の情報 EIP を作成する必要があると判断しました: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

私はそうしました。その後、彼らは私の開示EIPを拒否しました。

私は、EthereumMagicians フォーラムで説明した、2024 年に EIP の「セキュリティに関する考慮事項」セクションでセキュリティ開示を再び許可するという当初のアイデアを復活させる提案を思いつきました。

EIP 編集者との議論はこちらです: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

その結果、EIP 編集者は投票するつもりだと私に伝えました: https://github.com/ethcatherders/EIPIP/issues/349

私の提案は否決されました。EIP のセキュリティ開示に対処するプロセスはまだありません。ERC-20 の問題は修正されていません。問題として報告も文書化もされていないため、実装者は何度も同じ問題を再現し続けています。

不公平な監査人

私は個人的にこの問題を OpenZeppelin に報告し、修正を 3 回要求しました。

• 2018年https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729

  
  

• 2023年https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451

  
  

• 前の 2 つが却下された後、問題の重大性を示す方法で報告することに決め、OpenZeppelin 独自のルールに従って「重大なセキュリティ脆弱性」の基準に適合するため、バグ報奨金に提出しましたhttps://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

OpenZeppelin は「パッチ未適用の脆弱性の公開」を理由にこれを拒否しました (少なくとも、これがセキュリティ上の問題であることを確認しています)。

数日前の Devcon7 で、この問題に関して github で問題をクローズした OpenZeppelin の同じ人物に質問がありました: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

報告されてから6年が経ち、ユーザーに1億1500万ドルの損失をもたらしました。

彼らの返答は真実ではありません。 未解決の問題を抱える代わりに、彼らは私が提起した 3 つの問題を閉じ、私が行った提案をすべて拒否しました。

結論

1. イーサリアム財団は、エコシステムのユーザーが 1 億 1,500 万ドルの損失を被ったこの問題を指摘するあらゆる試みを検閲しています。この問題は発表されず、開示は適切に処理されず、実装者は新しいコントラクトでこの問題を再現し続けています。

   
   

   それを公表すれば、彼らの評判にあまりにも大きなダメージを与えると彼らは考えていると思います。

2. OpenZeppelin のような監査人もこの問題を公表していません。おそらく、監査した数百の ERC-20 契約にすでに「Secure」ラベルを付けているため、利益相反があるからでしょう。

   
   

3. 開発者たちは「標準をそのまま実装しているだけです」と言っています。

   
   

4. この標準は EIP プロセスによって管理されていますが、EIP プロセスはセキュリティ開示に対処するために構築されたものではありません。

EIP プロセスを変更する必要があります。ERC-20 の問題は公開され、適切に文書化される必要があります。理想的には、新しい標準を実装する必要があります。ERC-20 に一連の「バンドエイド」を適用して損害を軽減することは、何もしないよりはましですが、それ自体で問題を解決することにはなりません。

「問題はウォレット レベルで解決できる」と言っている人は、セキュリティの専門知識に欠けています。ソフトウェア セキュリティには、設計によるセキュリティという原則があります。つまり、安全でないソフトウェアを作成し、ユーザーに影響を与えないように使用方法を全員に伝えて、損害は発生しないふりをすることはできません。金融業界ではそうではありません。たとえば、Web デザインでは、誰かが Web ページに適切なフォントをロードできないことが障害のコストとなるため、このアプローチは有効かもしれません。金融業界では、これは数百万ドルの損失につながります。

人類文明の将来全体にわたって、すべてのウォレット開発者が常に必要な修正をすべて適切に実装することを保証することは絶対に不可能です。