1. IPFS点滴资讯首页
  2. 技术分享

有理有据 Filecoin官方火速澄清“双花不存在”!

官方表态:

据报道,2021年3月18日,由于Filecoin远程过程调用(RPC)代码中的“严重错误”,出现了“双花”。这些陈述是不正确的并且具有误导性。

Lotus团队已对报告进行了彻底调查,未发现Filecoin网络或RPC API代码有问题。Filecoin本身没有双花,API代码也没有错误。该交易所已在其簿记系统中恢复了不正确的交易,并正在审查其存款处理逻辑以更正其API使用情况。

有理有据 Filecoin官方火速澄清“双花不存在”!

技术说明和对应策略:

01
发生了什么
  • 问题报告。今天早些时候,Lotus团队收到一份报告,指出交易所错误地使用Lotus API来评估Filecoin网络中的转移/存款。用户的帐户被错误的记录了两次存款记录,用户报告了这种不正确的API使用情况。此问题之后在交易所的簿记中已被恢复—即Filecoin本身没有任何双花问题。
  • 交易所的API滥用。有问题的交换未正确检查链状状态、以及没有删除重复的具有相同发件人和收件人的多条消息。根本原因是Lotus API的使用不正确(不是API本身的错误)-未能按预期的方式工作。此簿记错误导致交易所错误地将帐户存款消息展现。到目前为止,我们只知道有一个受此API混乱影响的交易所。
  • 错误的报道成为头条新闻:有关网络“双花”的不正确陈述在社交媒体渠道中传播,并进入了文章头条。这些主张中的许多已被调查并确定为错误的描述。在了解了事实之后,许多团体和媒体机构正在纠正其报道。
  • Issue Report. Earlier today, the Lotus team received a report that an exchange was incorrectly using the Lotus APIs for evaluating transfers/deposits in the Filecoin Network. This incorrect API usage was discovered when a user reported that their account was incorrectly credited twice for a deposit in the exchange’s bookkeeping system. This has since been reverted in the exchange’s bookkeeping – there was no duplication on the chain itself.
  • API Confusion. The core of the issue was the improper usage of Lotus’ chain state inspection API, which behaved differently than expected when handling multiple similar messages. Misinterpreting the output of the Lotus API can cause a bookkeeping system to count both the original and a replacement message with the same senders and recipients. So far, we are only aware of one exchange affected by this issue.
  • False reports make headlines: Inaccurate statements around “double spends” on the network were propagated in social media channels, and made their way into article headlines. Many of these claims have been investigated and determined to be false. The team found no issues with the Filecoin network or the RPC API code. After learning the facts, many groups and media institutions are correcting their coverage.
02
采取的行动
 
  • 交易所受到影响。有问题的交易所发现此API被滥用,并已立即采取行动以停止存款,提款和转账。他们已还原了有问题的不正确交易(因此在此事件中没有资金损失),并且正在更正他们对Lotus API的使用,使其与建议的使用相匹配。
  • 其他交流。已通知其他交易所,并且正在审查其代码,以确保它们不受影响。这些审核中的许多审核已经完成-据我们所知,目前,没有其他交易所以这种方式滥用此API。
  • Lotus团队正在与所有交易所积极合作,以确保正确处理此行为,并改进API文档以确保所有其他人正确地检查Filecoin链状态。
  • 社区和媒体团队。一些组织正在共同努力,以发布正确的消息并澄清所指控事件的细节和事实,并帮助消除错误信息。
  • 社区团队。社区成员正在创建材料,以帮助其他人准确,客观地报告问题,以避免意外传播错误信息。
  • Exchange affected. The exchange in question caught this API misuse and has taken immediate action to halt deposits, withdrawals, and transfers. They have reverted the incorrect transaction in question (so no funds were lost in this incident), and are correcting their use of lotus APIs to match the recommended use.
  • Isolated instance. Other exchanges have been alerted and are reviewing their code to make sure they are not affected. Many of these reviews have already completed – to our knowledge, at this time, no other exchange has misused this API in this way.
  • Lotus Team. The Lotus team is actively working with all exchanges to ensure that this behavior is correctly handled, and improving the API documentation to ensure all others correctly inspect the Filecoin chain state going forward.
  • Community & Media Teams. A few organizations are working together to reach out to publications & clarify the details and facts of the alleged incident, and to help dispel misinformation.
  • Community Teams. Community members are creating materials to help others report problems accurately and thoughtfully to avoid accidentally spreading misinformation.
03
技术细节
  • 相同的消息。Lotus团队了解到,此问题是由于两条消息共享相同的发送者/接收者详细信息和相同的随机数,但具有不同的gas参数而引起的。两条类似的消息是消息替换的一种常见形式,用于更改与消息相关的gas费。Filecoin网络可以安全,正确地处理这种情况,不会导致进行两次传输:更不会导致执行两条消息中的一条,而忽略另一条消息。
  • 错误使用API。然而,基于一个人如何检查链,这可以表现出转移被处理了两次的样子。具体来说,交易使用了错误的方式来处理链状态-调用提示ChainGetBlockMessages集中的每个块,然后在每个消息上调用StateGetReceipt。
  • 错误的API。令人困惑的是,当StateGetReceipt在两个相似的消息(其中一个已执行,另一个已被跳过)上被调用时,它将提供相同的结果:两者都对应于已执行的消息。诚然,这是违反直觉的,但却是有意的行为。该方法的主要用例StateGetReceipt是在Lotus Miner和交易过程中使用的事件处理程序中。在替代消息的情况下,这些模块都不会关心返回的收据是否对应于原始消息,他们只是想知道消息是否在链上被成功执行。
  • 使用正确的API。大多数交易所都正确地使用ChainGetParentMessages和ChainGetParentReceipts进行簿记,以找出链上已执行并成功执行了哪些消息。这些是Lotus自己在状态计算过程中使用的API,因此可以确保以这种方式正确反映链状态。执行StateReplay对每一个消息都反馈给大家充分调用结果,所以大家可以比较MsgCid在返回InvocResult与查询消息的CID。这是我们比较建议交易所所采用的方式,以正确检查链状态并保持其内部报告系统同步。
  • Same messages. The Lotus team understands that the problem arose from two messages sharing the same sender/receiver details and the same nonce, but with different gas parameters — being included in the same tipset. Two similar messages like this are a common form of message replacement to change the gas fees associated with a message. Such a situation is safely and correctly handled by the Filecoin network, and does not lead to two transfers being made: one of the two messages is executed, the other is ignored.
  • Incorrect use of API. However, based on how one inspects the chain, this can present the appearance that the transfer is processed twice. Specifically, this exchange was using an inaccurate way of processing the chain state – calling ChainGetBlockMessages on every block in a tipset, and then calling StateGetReceipt on each of these messages.
  • API Usage Misunderstanding. The confusion is that when StateGetReceipt is called on the two similar messages (one of which is executed, and the other of which is skipped), it will provide the same result: both corresponding to the message that was executed. This is admittedly counter-intuitive, but intended, behavior. The primary use-case of the StateGetReceipt method is in the event handler used by the Lotus Miner and deal-making process. In the event of a replaced message, these modules do not care if the returned receipt corresponds to the original message, or a replacement one — they simply want to know if the message successfully executed on chain. We have added clarification to the documentation here:
  • Using the correct APIs. Most exchanges are correctly using ChainGetParentMessages and ChainGetParentReceipts for bookkeeping to figure out what messages were executed and succeeded on chain. These are the APIs used by Lotus itself during state computation, so you are guaranteed to correctly reflect chain state this way. Performing StateReplay on each of the messages will give you the full invocation result so you can compare the MsgCid in the returned InvocResult with the CID of the queried message. This is the recommended path for exchanges to correctly inspect chain state and keep their internal reporting systems in sync.

点对点科技简介

点对点科技深耘IPFS与Filecoin技术,坚持区块链技术改变未来的信念。点对点 IPFS 数据中心是目前国内技术领先,性价比高、保障优的投资标的。自建杭州数据中心,合作数据中心分布于上海、宁波、河北、香港、斯德哥尔摩(瑞典)等地。点对点数据中心具有优秀的硬件配置与目前国内优质的网络节点资源。点对点科技力求将IPFS爱好者升级为IPFS领军者与受益者,让IPFS颠覆传统互联网,共同开启 WEB 3.0时代。

想了解更多区块链知识吗?关注我吧!

Filecoin测试网二阶段昨日重启,点对点出块第一! | 点滴资讯

原创文章,作者:点点滴滴,如若转载,请注明出处:http://ipfsdrop.com/wiki/youliyouju-filecoinguanfanghuosuchengqingshuanghuabucunzai/

发表评论

电子邮件地址不会被公开。 必填项已用*标注