見出し画像

インシデントレポート ロータスのAPIで正確な記帳を

2021年3月18日付、公式ブログから翻訳
~~~~

2021年3月18日、Filecoinのリモートプロシージャコール(RPC)コードの「重大なバグ」により「二重支出」があったと報告がありました。しかしこれらの報告は誤りであり、誤解を招く恐れがあります。

Lotusチームはこの報告を徹底的に調査した結果、FilecoinネットワークやRPC APIコードには何の問題もありませんでした。ブロックチェーン自体にも二重支出はなく、APIコードにもバグはありません。問題の取引所では、すでに帳簿システムで不正な取引を元に戻し(資金の損失はありませんでした)、APIの使用方法を修正するために入金処理ロジックを見直しています。


問題発生の経緯とこれまでの対応
・本日未明、チームは、ある取引所がFilecoinネットワークでの送金/入金を評価するためにロータスのAPIを不正に使用しているという報告を受けました。この誤ったAPIの使用は、ユーザーが取引所の帳簿システムにおいて、入金したアカウントに2回誤って入金されたと報告したことで発見されました。これはその後、取引所の記帳システムで元に戻されました。チェーン自体には重複はありませんでした。
・この問題の核心は、Lotusのチェーン状態検査APIの不適切な使用にありました。このAPIは、複数の類似したメッセージを処理する際に、予想とは異なる動作をしました。LotusのAPIの出力を誤って解釈すると、簿記システムが同じ送信者と受信者を持つ元のメッセージと代替メッセージの両方をカウントしてしまう可能性があります。現在のところ、この問題の影響を受けた取引所は1つしかありません。
・ネットワーク上での「二重支出」に関する不正確な情報がソーシャルメディアで拡散され、記事の見出しにもなっていました。これらの主張の多くは、調査の結果誤りであることが判明しました。チームは、FilecoinネットワークやRPC APIコードに問題がないことを確認しました。事実を知った多くの団体や報道機関は、報道を訂正しています。
・問題となった取引所は、このAPIの悪用を把握し、入出金および送金を停止するための即時対応を行いました。また、問題となった不正な取引を元に戻し(この事件で資金が失われることはありませんでした)、推奨される使用方法に合わせて蓮のAPIの使用を修正しています。
・他の取引所も警告を受け、影響を受けていないことを確認するためにコードを見直しています。これらのレビューの多くは完了しており、現時点では、我々の知る限り、他の取引所がこのAPIをこのように悪用したことはありません。
・チームは、すべての取引所と積極的に協力し、この動作が正しく処理されるようにしています。また、他のすべての取引所が今後もファイルコインのチェーン状態を正しく検査できるように、APIドキュメントを改善しています。
・いくつかの組織は、メディアに連絡を取り、疑惑の事件の詳細と事実を明らかにし、誤った情報を払拭するために協力しています。
・コミュニティのメンバーは、誤って誤った情報を広めないように、他の人が問題を正確かつ思慮深く報告するための資料を作成しています。


今回の問題は、同じ送受信者情報と同じnonceを持ち、かつ異なるガスパラメータを持つ2つのメッセージが、同じtipsetに含まれていたことに起因するとチームは理解しています。このような類似した2つのメッセージは、メッセージに関連するガス料金を変更するための一般的なメッセージ交換の形式です。このような状況は、Filecoinネットワークによって安全かつ正しく処理され、2つの送金が行われることはありません。つまり2つのメッセージのうち1つが実行され、もう1つは無視されます。
しかし、チェーンの調べ方によっては、転送が2回処理されているように見えてしまうことがあります。具体的には、この取引所では、ChainGetBlockMessagesをtipset内のすべてのブロックで呼び出し、StateGetReceiptをこれらのメッセージのそれぞれで呼び出すという、チェーンの状態を処理する不正確な方法を使用していました。
混乱しているのは、2つの似たようなメッセージ(片方は実行され、もう片方はスキップされる)に対してStateGetReceiptを呼び出すと、どちらも実行されたメッセージに対応するという同じ結果が得られることです。これは確かに直感的ではありませんが、意図された動作です。StateGetReceiptメソッドの主な使用例は、Lotus Minerとディールメーキング・プロセスで使用されるイベント・ハンドラーです。置き換えられたメッセージの場合、これらのモジュールは、返されたレシートが元のメッセージに対応しているのか、置き換えられたものに対応しているのかは気にしません。 彼らは単に、メッセージがチェーン上で正常に実行されたかどうかを知りたいのです。ドキュメントに説明を追加しました。

ほとんどの取引所では、ChainGetParentMessagesとChainGetParentReceiptsを正しく使用して、チェーン上でどのメッセージが実行され、成功したかを把握するための帳簿をつけています。これらはLotus自身が状態を計算する際に使用するAPIなので、この方法でチェーンの状態を正しく反映させることができます。各メッセージに対してStateReplayを実行すると、完全なInvocationの結果が得られるので、返されたInvocResultのMsgCidと問い合わせたメッセージのCIDを比較することができます。これは、取引所がチェーンの状態を正しく検査し、内部の報告システムを同期させるために推奨される方法です。

~~~~

※当記事はご参考情報となります。正確性・真実性確認にはご自身で情報ソースを確認して下さい。
Protocol Labs公式からの情報更新を翻訳しております。
そのため、記事発行時点の内容のため、後日に内容が変更される可能性があります。更新情報は速やかに公表させていただきます。

いいなと思ったら応援しよう!