Partnered With:

Filecoin official report: Not "double-flowered" due to improper use of the Transaction Platform Status Checking API

Read this article in 9 Minutes

The Lotus team did a thorough investigation of the report and did not find any issues with the Filecoin network and RPC API code.

Original source: Filecoin Network

On March 18, 2021, there were reports of a "double flower" due to a "serious vulnerability" in Filecoin's remote procedure call (RPC) code. These statements are incorrect and strongly misleading.

The Lotus team did a thorough investigation of the report and did not find any issues with the Filecoin network and RPC API code. There are no double-flowered issues with the chain itself, and there are no errors in the API code. The trading platform has corrected the incorrect transaction records within the trading platform and is reviewing the recharge processing logic in their billing system to correct their API usage.

Event review

Incident Report & NBSP; -- Earlier today, the Lotus team received a transaction platform error using the Lotus API to calculate transfers/deposits in the Filecoin network. The API was used incorrectly because users reported that their accounts had been mistakenly recorded by the trading platform accounting system. The issue has been reinstated in the trading platform bookkeeping system - there are no duplicates recorded on the chain itself.

API misunderstanding & have spent At the heart of the problem was the misuse of Lotus's chain status checking API, which handled multiple similar messages differently than expected. Misunderstanding the output of the Lotus API causes the billing system to count both the original message and the replacement message as the same sender and receiver. So far, we are only aware of one trading platform affected by this issue.

The false report became the headline. -- Incorrect statements about online "double flowers" spread through social media channels and made their way into article titles. The contents of these reports have been investigated and determined to be misinformation. The team did not find problems with the Filecoin network or RPC API code. After learning the facts, many teams and media organizations are correcting their stories.

Action being taken

Affected Trading Platforms - The trading platforms concerned discovered this incorrect use of the API and have taken immediate action to stop recharge, withdrawals and transfers. They have recovered the erroneous trade (so no money was lost in this incident) and are correcting their use of the Lotus API to comply with recommended usage practices.

Casual Case & NBSP; Other trading platforms have been alerted and are reviewing their code logic to ensure they are not affected by the same error. Many of these reviews have already been completed -- as far as we know, no other trading platform has misused the API in this way.

The Lotus team & have spent - Lotus team is actively cooperate with all the trading platform, to ensure the correct processing this behavior, and improve the API documentation (https://github.com/filecoin-project/lotus/pull/5838), to ensure that all other trading platform right inspection Filecoin state of chain.

Community and Media & NBSP; -- A number of teams are working together to reach out to the media to clarify the details and facts of the alleged incident and to help eliminate misinformation.

Community Team & NBSP; Community members provide ways to help other community members report problems accurately and thoughtfully, avoiding the accidental spread of misinformation.

The technical details

Same information & NBSP; - & have spent As far as the Lotus team knew the problem arose from having two messages with the same sender/receiver details, the same nonce but with different GAS parameters -- contained in the same tipset. It is very common to have two similar messages like this, such as replacing a message with a change in the Gas charge of the same message. Such cases are handled safely and correctly by the Filecoin network and do not result in two transfers: one of the two messages is executed and the other ignored.

Incorrect use of API&NBSP; However, depending on how people check the chain, it will appear as if the message has been processed twice. Specifically, the trading platform in question used the wrong way of handling chain status -- calling ChaingetBlockMessages on each block of a TIPSET and then calling StateReceipt on those messages.

Wrong API Expectations The error-prone part is that when StateReceipt is called on two similar messages (one is executed and the other is skipped), it will give the same result as if both messages were executed. This is a counterintuitive act, to be sure, but it is intentional. StateGetReceipt application scenarios are mainly used in the process of Lotus miners and processing trade event handlers (https://github.com/filecoin-project/lotus/blob/79a8ff04fd5362a367fd7d6469e5287a47baa571/chain/events/events_called.go#L586). In the case of a message being replaced, these modules don't care whether the information returned corresponds to the original message or to the replacement message -- they just want to know whether the message executed successfully on the chain. We have added clarification in the documentation here:https://github.com/filecoin-project/lotus/pull/5838.

Use the correct API&NBSP; -- Most platforms correctly use ChaingetParentMessages and ChaingetParentReceipts to account for what messages are executed on the chain and what messages are successful. These are APIs that Lotus itself uses during chain state calculations to ensure that the user correctly reflects the state of the chain in this way. Perform StaterePlay on each message to get the complete result of the invocation, so that the consumer can compare the MsgCid in the returned InvoCsult to the CID of the query message. This is how the recommended trading platform correctly checks the status of the chain and keeps the internal reporting system in sync.