¿Qué es un log de eventos?
Un log de eventos es el registro que escribe un contrato EVM cuando ejecuta los opcodes LOG0–LOG4 (emit en Solidity). Cada entrada contiene la dirección del contrato emisor, hasta cuatro topics de 32 bytes y un campo data de longitud arbitraria. Decodificar un log consiste en hacer coincidir topics[0] con la firma de un evento, leer los parámetros indexed de los topics restantes y decodificar con ABI los parámetros no indexados a partir de data. Los exploradores lo hacen con el código fuente verificado; esta página lo hace solo a partir de la firma, para más de cuarenta eventos comunes, o a partir de cualquier ABI que pegues.
Cómo se codifica un log
| Campo | Contenido | Ejemplo (Transfer ERC-20) |
|---|---|---|
| address | El contrato que emitió el evento | 0xdAC17F958D2ee523a2206206994597C13D831ec7 (USDT) |
| topics[0] | keccak256 de la firma canónica | 0xddf252ad… = keccak256("Transfer(address,address,uint256)") |
| topics[1] | Primer parámetro indexado, rellenado a la izquierda hasta 32 bytes | dirección from |
| topics[2] | Segundo parámetro indexado | dirección to |
| data | Codificación ABI de todos los parámetros no indexados | value de 32 bytes |
Los parámetros indexados de tipo estático (address, enteros, bool, bytes1–32) se almacenan directamente en el topic. Los parámetros indexados de tipo dinámico (string, bytes, arrays, structs) se sustituyen por el hash Keccak-256 de su codificación, como describe la sección de eventos de la especificación ABI de Solidity; el decodificador los marca como hasheados.
Ejemplo práctico: una transferencia de USDT
Pulsa "Transfer ERC-20" arriba. topics[0] coincide con la firma Transfer y, como hay exactamente tres topics, se elige el diseño ERC-20 (dos direcciones indexadas) frente al ERC-721 (tres indexados). topics[1] se decodifica como from = 0xd8dA6BF2…96045, topics[2] como to = 0x1111…1111, y la única palabra de data 0x17d7840 es value = 25000000, que con los seis decimales de USDT equivale a 25 USDT. El mismo mecanismo decodifica un Swap de Uniswap V2 (dos direcciones indexadas, cuatro importes en data) o un TransferBatch ERC-1155, cuyo campo data contiene dos arrays dinámicos con offsets y longitudes.
Eventos reconocidos sin ABI
La tabla siguiente se genera en la página a partir de la misma lista de firmas que usa el decodificador, por lo que cada valor de topics[0] es una autocomprobación de la implementación de Keccak. Cubre Transfer y Approval de ERC-20 y ERC-721, ApprovalForAll, TransferSingle, TransferBatch y URI de ERC-1155, Deposit y Withdrawal de WETH, Swap, Sync, Mint, Burn y PairCreated de Uniswap V2, Swap, Mint, Burn, Collect y PoolCreated de Uniswap V3, OwnershipTransferred, Upgraded, AdminChanged y BeaconUpgraded de EIP-1967, los eventos de Initializable, Pausable y AccessControl, Approval, Permit, NonceInvalidation y Lockdown de Permit2, Deposit y Withdraw de ERC-4626, y ExecutionSuccess, ExecutionFailure, SafeMultiSigTransaction, cambios de owner y threshold, SafeSetup y ProxyCreation de Safe.
Entradas aceptadas
- Un único objeto de log
{"address","topics","data"}copiado de un explorador, viem, ethers o web3.py. - Un array de logs, el
resultdeeth_getLogso la respuesta JSON-RPC completa. - Un recibo de transacción: cada entrada de su array
logsse decodifica en orden, mostrando número de bloque, índice de log y hash de transacción. - Topics pegados uno por línea más el hex de data, para logs copiados de un trace o un depurador; las etiquetas como "topics[1]:" se ignoran.
- Un ABI opcional: un array JSON de fragmentos, un objeto con la clave
abi(artefactos de Hardhat y Foundry) o líneasevent …legibles. Los eventos del ABI tienen prioridad sobre la tabla integrada.
Relacionado: calcula el hash de topic de cualquier firma con la calculadora de selectores y topics, decodifica el calldata de la transacción con el decodificador ABI o inspecciona una transacción en bruto con el decodificador de transacciones de Ethereum.