Generador de Hash Keccak-256 desde Texto Online (Ethereum / EVM)
Calcula hashes Keccak-256 exactos para Ethereum, contratos inteligentes de Solidity y la EVM (Ethereum Virtual Machine). Genera automáticamente el selector de función de 4 bytes (Method ID) y los tópicos de eventos ERC-20 y, con la entrada hexadecimal (bytes), también calcula direcciones a partir de claves públicas y ranuras de almacenamiento de mappings, con salida Web3 con prefijo 0x en tiempo real.
¿Qué es Keccak-256 y por qué es el Pilar Fundamental de Ethereum y la EVM?
Keccak-256 es la función hash criptográfica universal sobre la que descansa toda la arquitectura de seguridad, direccionamiento y ejecución de la red Ethereum y de cualquier cadena de bloques compatible con la EVM (Ethereum Virtual Machine). Diseñada por el equipo de Guido Bertoni, Joan Daemen, Michaël Peeters y Gilles Van Assche, Keccak fue adoptada por Ethereum en 2014 —antes de la estandarización final de SHA-3 por el NIST— y se ha mantenido inalterada como el estándar de facto indiscutible del ecosistema Web3.
En el desarrollo con el lenguaje Solidity, Keccak-256 es la primitiva criptográfica nativa más invocada a través de la función global keccak256(bytes memory). Cada interacción en la blockchain —desde la transferencia de tokens ERC-20 y NFTs ERC-721, pasando por la validación de firmas criptográficas ECDSA (EIP-712), hasta la resolución de nombres descentralizados en ENS (Ethereum Name Service)— depende directamente de la solidez matemática de Keccak-256.
Aplicaciones Prácticas de Keccak-256 en el Ecosistema Ethereum
Keccak-256 interviene en los componentes más críticos de la máquina virtual de Ethereum:
- Derivación de Direcciones de Billetera (Ethereum Addresses): Las direcciones públicas de Ethereum (como
0x71C...) no son la clave pública en sí, sino los últimos 20 bytes (160 bits) del hash Keccak-256 de la clave pública elíptica secp256k1 no comprimida de 64 bytes: $$\text{Ethereum Address} = \text{Últimos 20 bytes}(\text{Keccak-256}(\text{Public Key}))$$ - Selectores de Funciones de Contratos (Method IDs de 4 Bytes): Cuando una billetera o dApp envía una transacción para ejecutar una función de un contrato inteligente, los primeros 4 bytes de los datos de la transacción (calldata) corresponden a los primeros 4 bytes del hash Keccak-256 de la firma canónica de la función sin espacios: $$\text{Method ID} = \text{Keccak-256}(\text{"transfer(address,uint256)"})[0 \dots 3] = \mathtt{0xa9059cbb}$$ Nuestra herramienta calcula y resalta automáticamente este selector de 4 bytes para que puedas inspeccionar transacciones en Etherscan o depurar llamadas en Foundry y Hardhat.
- Firmas de Eventos y Tópicos (Log Topics): Cuando un contrato emite un evento, el primer tema indexado (
Topic 0) en el recibo de la transacción es exactamente el hash Keccak-256 de la firma del evento: $$\text{Topic 0} = \text{Keccak-256}(\text{"Transfer(address,address,uint256)"})$$ Es el valor0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3efque aparece como primer tópico de todos los eventosTransferde tokens ERC-20 en Etherscan. - Cálculo de Ranuras de Almacenamiento (Storage Slots para Mappings): Para acceder a los datos de una clave en un mapping de Solidity (por ejemplo,
mapping(address => uint256) balancesen el slot $p$), la EVM localiza el valor calculando el hash concatenado de la clave y el número de slot: $$\text{Slot Index} = \text{Keccak-256}(\text{key} \parallel \text{slot } p)$$
Vectores de Prueba Oficiales de Keccak-256 para Solidity y Web3
A continuación se detallan los vectores de verificación canónicos utilizados universalmente en pruebas unitarias de Solidity y librerías como ethers.js, viem y web3.py:
| Texto / Firma de Función | Selector EVM (4 bytes) | Hash Completo Keccak-256 (32 bytes) |
|---|---|---|
"" (cadena vacía) | 0xc5d24601 | 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 |
"transfer(address,uint256)" | 0xa9059cbb | 0xa9059cbb2ab09eb219583f4a59a5d0623ade346d962bcd4e46b11da047c9049b |
"balanceOf(address)" | 0x70a08231 | 0x70a08231b98ef4ca268c9cc3f6b4590e4bfec28280db06bb5d45e689f2a360be |
"approve(address,uint256)" | 0x095ea7b3 | 0x095ea7b334ae44009aa867bfb386f5c3b4b443ac6f0ee573fa91c4608fbadfba |
"transferFrom(address,address,uint256)" | 0x23b872dd | 0x23b872dd7302113369cda2901243429419bec145408fa8b352b3dd92b66c680b |
Modo hexadecimal: calcula Keccak-256 sobre bytes, no sobre texto
Por defecto la herramienta codifica lo que escribes como texto UTF-8. Pero muchas operaciones de Ethereum aplican Keccak-256 a bytes en bruto, y si escribieras 0x1234 como texto se hashearían los seis caracteres ASCII "0x1234", no los dos bytes 0x12 y 0x34. Marca la casilla "Entrada en hexadecimal (bytes)" para que la entrada se interprete como bytes. Se acepta el prefijo 0x (también repetido en cada bloque), los espacios y saltos de línea se ignoran, y cada byte necesita exactamente dos dígitos.
| Caso de uso | Entrada hexadecimal (bytes) | Resultado Keccak-256 |
|---|---|---|
| Dirección a partir de una clave pública (clave privada = 1): los últimos 20 bytes del hash son la dirección | 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 (coordenadas X e Y de 32 bytes, sin el prefijo 04) | 0xc0a6c424ac7157ae408398df7e5f4552091a69125d5dfcb7b8c2659029395bdf → dirección 0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf |
Ranura de almacenamiento de un mapping(address => uint256) en el slot 0, para la clave 0x…0001 | 0x0000000000000000000000000000000000000000000000000000000000000001 seguido de 0x0000000000000000000000000000000000000000000000000000000000000000 (clave y slot rellenados a 32 bytes) | 0xada5013122d395ba3c54772283fb069b10426056ef8ca54750cb9bb552a59e7d |
El botón "Clave pública → dirección (hex)" carga el primer ejemplo con un clic. En la ranura de un mapping, para claves de tipo valor (address, uint256, bool…) la clave se rellena con ceros a 32 bytes y se concatena con el número de slot, también de 32 bytes. Ten en cuenta que el resultado muestra el hash completo: para obtener una dirección debes quedarte con sus últimos 40 caracteres hexadecimales.
¿Por qué SHA3-256 del NIST produce un resultado diferente al de Solidity?
Un error extremadamente frecuente entre desarrolladores de blockchain es utilizar librerías o herramientas etiquetadas genéricamente como "SHA-3" para calcular hashes de Ethereum, descubriendo que el valor no coincide con el obtenido en Solidity o Etherscan.
Esto ocurre porque el NIST FIPS 202 SHA3-256 utiliza el byte de relleno 0x06 (añadiendo dos bits de dominio 01), mientras que Keccak-256 de Ethereum utiliza el byte de relleno 0x01 original. Nuestro convertidor implementa de manera estricta y nativa la variante Keccak-256 (Ethereum EVM), garantizando una compatibilidad del 100% con Solidity y herramientas Web3. Si necesitas la variante oficial del gobierno estadounidense, utiliza nuestro Generador SHA3-256.
Preguntas Frecuentes sobre el Generador de Hash Keccak-256 (FAQ)
¿Cómo se calcula un selector de función de Solidity con esta herramienta?
Simplemente introduce la firma canónica de la función en el área de texto, respetando los nombres exactos de los tipos sin espacios (por ejemplo: transferFrom(address,address,uint256)). La herramienta calculará inmediatamente el hash completo y extraerá los primeros 4 bytes con el prefijo 0x en la casilla superior de "EVM Selector", listos para copiar con un solo clic.
¿Esta herramienta soporta empaquetado como abi.encodePacked()?
Nuestra calculadora procesa cadenas de texto plano codificadas en UTF-8, lo que equivale exactamente al comportamiento de keccak256(bytes("mi texto")) o keccak256(abi.encodePacked("mi texto")) en Solidity para cadenas alfanuméricas. Si concatenas varios textos sin delimitadores, el resultado en la herramienta coincidirá punto por punto con la salida del contrato inteligente. Para valores binarios como bytes32, address o uint256 (por ejemplo, el resultado de abi.encode), activa la casilla de entrada hexadecimal para hashear los bytes exactos.
¿Por qué el hash de "0x1234" no coincide con el de mi contrato?
Porque en modo texto se hashean los caracteres, no los bytes: "0x1234" son seis caracteres ASCII. Si tu contrato hashea los dos bytes 0x1234, marca "Entrada en hexadecimal (bytes)" y vuelve a calcular. Si tampoco coincide, comprueba que no haya espacios ni saltos de línea sobrantes en una firma de función y que uses tipos canónicos (uint256, no uint): la herramienta te avisa de ambos casos.
¿Se envían las firmas o textos a algún servidor?
No. El algoritmo Keccak-256 está programado íntegramente en JavaScript del lado del cliente utilizando enteros BigInt de 64 bits para una velocidad máxima. Ninguna consulta ni dato introducido se almacena ni se transmite por internet.