Filecoin「ダブルスペンド事件」回顧:取引所の記帳が不正確
この記事はFilecoin Networkからのものです。
2021年3月18日、Filecoinのリモートプロシージャコール(RPC)コードに「深刻な脆弱性」が存在し、「ダブルスペンド」が発生したとの報道がありました。これらの主張は不正確であり、強い誤解を招くものです。
Lotusチームはこの報告を徹底的に調査し、FilecoinネットワークおよびRPC APIコードに関連する問題は見つかりませんでした。チェーン自体にはダブルスペンドの問題はなく、APIコードにもエラーはありません。取引所は誤った取引記録を修正し、APIの使用を正すために彼らの記帳システムの入金処理ロジックを見直しています。
事件の振り返り
事件報告 --- 今日早く、Lotusチームは取引所がLotus APIを誤って使用してFilecoinネットワーク内の送金/入金を計算しているとの報告を受けました。APIの誤使用は、ユーザーが取引所に自分のアカウントが取引所の記帳システムによって誤って重複記録されたと報告したことに起因しています。この問題は取引所の記帳システムで修正されました --- チェーン自体には重複記録はありません。
APIの誤解 --- この問題の核心は、Lotusのチェーン状態チェックAPIの誤った使用にあります。複数の類似メッセージを処理する際、その処理方法が期待されるものとは異なります。Lotus APIの出力を誤解すると、記帳システムは元のメッセージと置き換えメッセージの両方を同じ送信者と受信者としてカウントします。現時点では、この問題の影響を受けた取引所は1つだけです。
虚偽報道が記事の見出しに --- ネットワークの「ダブルスペンド」に関する不正確な主張がソーシャルメディアで広まり、記事の見出しにまで至りました。これらの報道の内容は調査され、誤情報であることが確認されました。チームはFilecoinネットワークやRPC APIコードに問題がないことを発見しました。事実を理解した後、多くのチームやメディア機関が報道を訂正しています。
取られている行動
影響を受けた取引所 --- 関連する取引所はAPIの誤使用を発見し、即座に行動を起こし、入金、出金、送金を停止しました。彼らは関連する誤った取引を修正し(この事件で資金の損失はありません)、Lotus APIの使用を推奨される方法に従って修正しています。
偶発的なケース --- 他の取引所も警告を受け、同様の誤りの影響を受けないようにコードロジックを見直しています。その多くのレビューはすでに完了しており、現時点では他にこのような方法でAPIを誤使用した取引所はないと認識しています。
Lotusチーム --- Lotusチームはすべての取引所と積極的に協力し、この行動を適切に処理し、APIドキュメントを改善するために努めています(https://github.com/filecoin-project/lotus/pull/5838)。これにより、他のすべての取引所がFilecoinのチェーン状態を正しくチェックできるようにします。
コミュニティとメディア --- 一部のチームは共同で努力し、メディアと連絡を取り、事件の詳細と事実を明確にし、誤情報を排除する手助けをしています。
コミュニティチーム --- コミュニティメンバーは、他のコミュニティメンバーが問題を正確かつ丁寧に報告する手助けをする方法を提供し、誤情報の意図しない拡散を避けるよう努めています。
技術的詳細
同じ情報 --- Lotusチームが知る限り、この問題は2つのメッセージが同じ送信者/受信者の詳細、同じnonceを持ちながら異なるGasパラメータを持っていることから生じています------同じtipsetに含まれています。このように2つの類似したメッセージが非常に一般的であり、メッセージのGas費を変更することでこのような2つの類似メッセージが形成されます。このような状況はFilecoinネットワークによって安全かつ正しく処理され、二重送金は発生しません:2つのメッセージのうち1つが実行され、もう1つは無視されます。
APIの誤使用--- しかし、チェーンのチェック方法によっては、メッセージが2回処理されたように見えることがあります。具体的には、関連する取引所はチェーン状態を処理するための誤った方法を使用しました------tipsetの各ブロックでChainGetBlockMessagesを呼び出し、その後これらのメッセージに対してStateGetReceiptを呼び出しました。
誤ったAPIの期待 --- 誤解を招くのは、StateGetReceiptが2つの類似メッセージに対して呼び出された場合(1つが実行され、もう1つがスキップされた場合)、同じ結果を提供し、両方のメッセージが実行されたように感じさせることです。これは直感に反する行動ですが、意図的に行われています。StateGetReceiptの主な使用シーンは、Lotusマイナーと取引処理の過程で使用されるイベント処理プログラムです。メッセージが置き換えられた場合、これらのモジュールは返された情報が元のメッセージに対応するのか、置き換えられたメッセージに対応するのかを気にしません------彼らはただメッセージがチェーン上で成功裏に実行されたかどうかを知りたいのです。私たちはここでのドキュメントに明確化を追加しました:https://github.com/filecoin-project/lotus/pull/5838。
正しいAPIの使用--- 大多数の取引所はChainGetParentMessagesとChainGetParentReceiptsを正しく使用して記帳し、チェーン上で実行されたメッセージと成功したメッセージを計算しています。これらはすべてLotus自体がチェーン状態計算プロセスで使用するAPIであり、使用者がこの方法でチェーン状態を正しく反映できることを保証します。各メッセージに対してStateReplayを実行することで、完全な呼び出し結果を得ることができ、使用者は返されたInvocResultのMsgCidとクエリメッセージのCIDを比較できます。これは取引所がチェーン状態を正しくチェックし、内部報告システムを同期させるための推奨手順です。












