区块链索引服务依赖于合约事件来帮助归档数据，并在一个漂亮的用户界面中给我们提供交易记录，其通常被称为“区块浏览器”，比如Etherscan。但恶意合约可以表现得无比“正常”，却会污染这些事件，从而欺骗区块浏览器，向毫无戒备的用户提供关于代币来源的误导性信息。
例如，恶意用户可以部署一个简单ERC20合约和“空投”代币给一群用户，在自动做市商上创建一个看起来健康的流动资金池，等待用户根据错误的宣传购买或出售代币，认为此代币是已知开发人员/实体的一部分。
分解
ERC20代币(它是代币接口的通用标准)是合约的属性、函数、输入、输出和事件的集合。只要我们的合约具有正确的函数特征，我们就可以在这些函数中使用自定义逻辑——即使是提供不正确数据的函数。
例如，如果合约部署者发送一个代币，我们可以让一些/所有区块浏览器向最终用户（在某些视图中）显示不同的地址。假设如下；
这不仅仅是ERC20的问题……受污染的数据可以被插入到任何代币标准事件中，如NFT (ERC721, ERC1155)，以迷惑用户和潜在投资者，让他们认为项目有特定的利益方/影响者，而实际上并没有。
这个问题并不“新鲜”，但我们写这篇文章是为了强调正在发生的事情，以及用户在“模仿”“看起来合法”的项目之前应该做些什么。
当区块浏览器看到交易发出的事件时，他们将其记录在他们的链下数据库中，并与其他数据建立关系，这样他们就可以建立一个很好的交易关系图，在他们的UI中显示给终端用户。
概念验证
我们将部署一个概念验证合约，使用一个老版本的 Solidity，同时也要证明它与任何Solidity版本或以太坊中的任何东西都没有问题，其是一个来自链下应用程序信任合约的信任问题。一般来说，对事件的继承信任是“正确”的，它是一种合约将可用数据提供给链下程序进行索引的方式。
在上面的合约(位于0x3afe99bd92b1aed3237196b26743681766d4940e)中，我们修改了逻辑，将 Transfer 事件中的发送者地址更改为流行区块浏览器上标记为“OpenSea：Wallet”的地址，前提是我们（创建合约的人）发送代币。
它所做的是，当区块浏览器索引该事件时，它从Transfer事件中看到地址为0x5b32…1073发送了代币，而不是实际的发起者0x11b6…04C9，这可能导致该方法被不良行为者利用，诱使用户认为;
让我们从合约部署者地址调用transfer()，看看区块浏览器索引了什么。我们只是将代币从我的地址(0x11b6…04C9)移动到一个目标地址(0x4bbe…1520)。
“OpenSea: Wallet”ERC20活动视图显示它似乎已经发送了一个名为OpenSeaRevenueShare的代币到目的地。
交易表明(在“token Transferred”中)“OpenSea: Wallet”将代币发送到目标地址。
目标地址显示“OpenSea: Wallet”给他们转移了10个代币。
寻找什么？
大多数这样的以利用用户的恶意合约都没有被“验证”，又因为我们只能接触到区块浏览器上的字节码，如果事件被污染了不良数据，再基于某些条件，都很难让用户进行验证，就像我们的概念验证一样。如果合约没有被验证，比如我们无法看到Solidity/Vyper/...代码，并且只暴露于字节码，那么在与合约交互之前，我们应该采取预防措施。
如果一个代币被“空投”给我们或其他实体，我们应该谨慎，特别是当我们试图在DEX上清算代币时，因为过去有一些事件是利用人为制造价格的方法从窃取的。
一种快速的方法是检查事件参数是否与交易发起者匹配，这并非万无一失，因为空投者有多发送方合约。例如，如果交易“From”字段与事件不匹配，请谨慎处理。
用不良数据污染事件的方法正在主网上进行。一个已知的问题。例如，如果我们在 Google BigQuery 上运行以下查询，我们就可以了解合约发生了什么，它们在发出事件来欺骗索引者，让他们认为Vitalik Buterin正在使用他们的代币。
例子
ElonPlaid (0 x907f3040e13bd57f3b00f89bb8ee19424a95b065)
在构造函数上发出一个被 Vitalik Buterins 地址污染的 Transfer() 事件，用于整个代币供应。
使用代币开始交易时，发出一个被Vitalik Buterin地址污染的Transfer()事件。
-
合约创造者向DEX (4ETH价值)提供流动性
-
三天后，移除6ETH的流动性，有2ETH的利润
KenshaInu (0 x3a7eaa257181719965f8ebe64bb7c13ffbbca36b)
在构造函数上发出一个被 Vitalik Buterins 地址污染的 Transfer() 事件，用于整个代币供应。
