EN
前言
当你在区块链浏览器上查询交易时，是否只是查看概览和内部交易？那么事件日志呢？是否在不起眼的角落被你忽略了。
交易事件日志对于用户以及开发者来说实际上都是至关重要的。通过触发事件不仅能将链上智能合约的交易通知给外界，还能让智能合约开发者对合约进行测试、保证合约安全。
接下来就帮助大家详细理解下关于以太坊的事件日志以及关于它所延伸出来的一些 基础知识 。
事件
2.1 什么是事件？
事件，是能方便地调用以太坊虚拟机日志功能的接口。
而 Solidity 事件就是 EVM 的日志功能之上的抽象。应用程序可以通过以太坊客户端的 RPC 接口订阅和监听这些事件，允许我们打印在区块链上的信息。
所以通过 Solidity 事件，我们可以做到：
-
测试智能合约中的特定变量
-
索引变量以重建存储状态
-
监听事件用于改变前端状态
-
创建子图以更快地读取数据
2.2 声明和触发事件
我们以官方 ERC20 合约代码为例，在 IERC20.sol 文件中通过 event 关键字进行声明。
我们可以把事件看作是一个特殊类型，上面的代码中我们创建了一个名为 Transfer 的事件，在该事件中有两种参数类型：有索引 (indexed) 和无索引。其中 from 和 to 参数是有索引的，而 value 参数是没有索引的。
在 ERC20.sol 的 _transfer 函数中通过 emit 关键字触发相应事件（之前的版本里并不需要使用 emit）。
日志
3.1 什么是日志？
在以太坊中，日志是用来存储事件。当事件被调用时，会触发参数存储到交易的日志中。其不能被智能合约访问，但是可以提供关于交易和区块中发送的信息。
我们随意点开一条交易 (0x477ed7208127bea597142622d52df46d3e4967835bd3609995581eb5aaeeec3e)，查看其日志 Logs。
通过日志我们可以将日志分为四个部分：
1、Address: 地址。即发出事件的合约地址或者账户的地址。
2、Name: 名字。即触发的事件名及其参数。
3、Topics: 主题。即事件中有索引 (indexed) 的参数。
4、Data: 数据。即事件中没有索引的参数。
3.2 日志记录中的主题
上面我们有说到主题 (Topics)，接下来我们详细说下主题。
每个日志记录都包含「主题 (topics)」和「数据 (data)」。主题是 32 字节（256 位），用于描述事件中发生的事情。不同的操作码 (LOG0 LOG1 LOG2 LOG3 LOG4) 用以描述需要包含在日志记录中的主题数。
EVM 中有 5 个操作码用于触发事件日志并创建日志记录，分别是 LOG0，LOG1，LOG2，LOG3 以及 LOG4，它们用于描述智能合约中的事件，例如代币的转移、所有权的变更等。LOG1 即包含了一个主题，而单个日志记录中最多可以包含的主题就是 LOG4 的四个主题。
Topics0 通常为发生事件名称的签名（keccak256 的哈希值)，包括其参数的类型（address，uint256 等），Topics1 为第一个索引参数的值，Topics2 为第二个索引参数的值。
该主题中 Topics0 的值为 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef，其事件为上一行 Name 的内容。
而我们对事件 Transfer(address,address,uint256) 进行 keccak256 加密后得到的结果和 Name 的值一样，说明 Name 的值的确为事件名称的签名。当然，有一个例外是没有事件签名的，那就是触发「匿名事件」时。
Topics1 就是第一个索引参数的值，即 form 地址的值。 Topics2 就是第二个索引参数的值，即 to 地址的值。 从内部调用分析也能看到的确是这样。
主题只能包含 32 个字节的数据，所以像可能超过 32 个字节的内容如数组、字符串等的内容不能用作主题，如果要尝试包含大于 32 个字节的数据，则该主题必须进过 hash 计算，所以超过 32 个字节后最好当做数据包含在日志记录中。
3.3 日志记录中的数据
日志记录除了主题，还有一部分内容就是数据，数据就是事件的非索引参数的 ABI 编码或者 hash 值，我们可以使用 Dec 或 Hex 查看数据 data 的值。
数据和主题都有各自的优劣：
-
主题是可以搜索到的，数据不能搜索到。
-
数据比主题所需要的 gas 少。
由于主题是带有索引的参数，所以我们可以直接在日志中进行搜索，而数据是 ABI 编码或 hash 值，所以不能直接搜索。
根据黄皮书我们可以找到日志的相关 gas 成本，日志的基础费用是 375 gas，每个主题也是 375 gas，而数据字节的成本是 8 gas。
触发事件
接下来以一个实例进行说明触发事件，下面的代码实现了符合 ERC20 标准的代币合约所使用的转账事件。
然后我们看一下该事件的参数，其中 from 和 _to 地址都是有索引的， value 值是没有索引的。所以 _from 和 _to 地址会被当成主题，而 _value 值会被当成数据。
在 3.3 节中我们说到过主题能被搜索，而数据不能，所以我们能在日志中搜索 from 地址和 _to 地址值的相关转账日志，却不能够搜索到转账金额为 _value 值的转账日志。由于该事件具有 3 个主题（事件的签名， from，_to），所以该日志记录操作将使用 LOG3 操作码。
那如果我们想要找到数据的内容呢？这里就需要知道操作码在 EVM 中的参数。LOG3 虽然包含 3 个主题，在 EVM 中却有 5 个参数。
如果要读取数据的内容，通过以下的方式就可以从内存中读取事件数据了。
钓鱼
5.1 事件在钓鱼中的使用
前面介绍了那么多日志事件，那这些是如何和钓鱼联系到一起的呢？攻击者一般会通过日志事件伪装成 交易所 或者名人等给受害者转币（该币无实际交易价值，是钓鱼代币），受害者看到是交易所或者名人转来的代币则放松警惕，此时攻击者会引导受害者到有钓鱼代币的池子中，受害者看到该代币交易价值极高，会立刻授权进行交易，而此时就陷入了攻击者设置的圈套，攻击者会让受害者授权从而盗取走受害者 钱包 中的钱。
下图就是之前发生的一起钓鱼事件，攻击者伪装成 币安 热钱包给其他人转钓鱼代币。
我们可以在 BSC 浏览器上通过标签找到官方地址。
通过查询，发现 Binance Hot Wallet 6 地址正是 0x8894e0a0c962cb723c1976a4421c95949be2d4e3。
由于浏览器记录是根据事件来的，所以说 topics1 的值即 sender 的值就是 0x8894e0a0c962cb723c1976a4421c95949be2d4e3。
5.2 复现
下面是 BEP20 的伪代码，以 BNB Chain 主网为例进行复现，攻击者创建一个名为「Phishing Token」的钓鱼代币。。
如下图所示，新增 Binance 参数其值为 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3。
然后，我们要修改如下图红色标记代码，将 emit 触发事件中的 sender 地址修改为 Binance。
部署好 合约 后调用 transfer 函数将钓鱼代币转发给受害者。
查看交易信息，发现这里的 from 地址并不是攻击者的地址 0x95E2Ea34dEB5C0954B91a47f459770D20568A15B，而是 Binance: Hot Wallet 6 的地址 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3。
查看 Logs 日志，Topics1 记录的 sender 地址同样也是 Binance Hot Wallet 6 地址，而 Topics2 记录的 recipient 就是受害者的地址了。
总结
细节决定成败，不要认为事件日志是微不足道的沧海一粟。在区块链世界越是细节的地方越容易被黑客攻击利用，往往需要更加谨慎小心。同时需要注意的是，我们也不能因为日志所展示出来的内容掉入骗子设计好的骗局中。再次提醒大家，不要随意点击陌生链接，更不要随意授权他人。当我们更加深入理解事件日志的时候，才能更好的防止自己上当受骗。
参考文献
-
Solidity 中文文档
-
Solidity 中的事件和日志
-
Understanding event logs on the Ethereum blockchain
-
以太坊黄皮书 (2022-08-22)
