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