
Los desarrolladores de Ethereum están reconsiderando en silencio uno de los componentes más básicos del protocolo: qué función hash criptográfica debe llevar a la red a su próxima era. El debate sobre las funciones hash de Ethereum ha resurgido ahora que un nuevo sistema de prueba llamado Flock ha eliminado una restricción que antes marcaba cada decisión: la necesidad de diseños aptos para circuitos como Poseidon. Al desaparecer ese requisito, los investigadores están comparando solo en términos de seguridad y velocidad SHA-2, SHA-3/Keccak, BLAKE2, BLAKE3 y una variante no estándar de SHA-2, y el análisis publicado en el foro de Ethereum Research explica con detalle cómo se ven de diferentes estas opciones cuando ya no se exige que sean compatibles con circuitos.
Ideas clave
Ethereum ya no necesita hashes amigables con circuitos porque Flock, un sistema de pruebas post-cuánticas para circuitos binarios, gestiona el hashing de manera eficiente independientemente del algoritmo elegido.
Las funciones hash sustentan las firmas de la capa de consenso, la construcción del árbol de estado, las pruebas de zkVM y las firmas de la capa de ejecución en todo el protocolo.
SHA-2 es rápido pero no es un oráculo aleatorio verdadero por una debilidad de extensión de longitud; SHA-3 ofrece un gran margen de seguridad pero funciona más lento; BLAKE2 y BLAKE3 son más rápidos pero con registros de criptoanálisis más “delgados”.
Los benchmarks muestran que BLAKE3 es la función hash más rápida para mensajes largos, mientras que SHA-3 es la más lenta entre los principales candidatos.
Una clasificación orientada a minimizar el riesgo coloca a SHA-3 en primer lugar; BLAKE2s y la variante de SHA-2 empatan en segundo y tercer lugar, con BLAKE3 clasificado más abajo.
Requisitos de Ethereum para funciones hash en la era post-cuántica
La elección de la función hash de Ethereum ya no está limitada por la eficiencia del circuito de prueba, lo que libera a los ingenieros para priorizar la seguridad y la velocidad bruta. Ese cambio es consecuencia directa de una nueva arquitectura de pruebas que entra en escena, y altera por completo el cálculo detrás de la selección de primitivas criptográficas para la red.
El sistema de pruebas de Flock elimina la restricción de hashes amigables con circuitos
Durante años, cualquier candidato a función hash para Ethereum tenía que ser eficiente dentro de circuitos de conocimiento-cero, lo que empujó al ecosistema hacia diseños algebraicos y “amigables con circuitos”, como Poseidon. Esa restricción ahora en gran medida ha desaparecido. Con la aparición de Flock, un sistema de pruebas post-cuánticas construido para circuitos binarios —en particular, hashes— Ethereum ya no necesita hashes específicos amigables con circuitos para protocolos cuya computación debe ser probada. En la práctica, esto significa que la red puede evaluar las funciones hash por sus méritos nativos, en lugar de forzar un compromiso entre solidez criptográfica y compatibilidad con el sistema de pruebas.
Casos de uso clave: consenso, árboles de estado, pruebas de zkVM y capa de ejecución
Las funciones hash siguen profundamente integradas en la arquitectura de Ethereum, y su rendimiento toca casi todas las capas del protocolo. Importan para las firmas de la capa de consenso que usan una variante de XMSS, para agregar esas firmas mediante un sistema de pruebas post-cuánticas, para construir el árbol de estado en la capa de ejecución y para esquemas de firmas de la capa de ejecución como SPHINCS+. Cada uno de estos casos se basa en hashing iterativo, donde las reglas de padding y el tamaño de bloque (chunk) del algoritmo elegido afectan directamente al rendimiento en el mundo real.
Comparando los principales candidatos a funciones hash
Ningún candidato gana de forma absoluta tanto en seguridad como en velocidad, y esa es exactamente la razón por la que los investigadores de Ethereum están realizando una comparación lado a lado en lugar de resolver la cuestión por defecto. El análisis reduce el campo a cinco opciones: SHA-2, SHA-3/Keccak, BLAKE2, BLAKE3 y una variante modificada de SHA-2.
SHA-2, su variante y SHA-3/Keccak: velocidad versus margen de seguridad
SHA-2 es rápido y está probado en batalla, pero no es un oráculo aleatorio tal cual porque tiene una vulnerabilidad de extensión de longitud, bien conocida, heredada de su construcción Merkle-Damgård. Una variante parcheada de SHA-2 corrige la brecha de indistinguibilidad mientras conserva la mayor parte del criptoanálisis original, aunque rompe la compatibilidad con el estándar y requiere un valor de inicialización no estándar.
SHA-3/Keccak, en cambio, aporta un alto margen de seguridad gracias a su construcción tipo esponja, y ha sobrevivido años de criptoanálisis sin una ruptura práctica. Sin embargo, esa seguridad tiene un costo: el gran estado interno de SHA-3 la vuelve notablemente más lenta tanto de forma nativa como dentro de circuitos de demostración en comparación con SHA-2 y la familia BLAKE.
La cuestión de la compatibilidad de BLAKE2, BLAKE3 y Keccak de Ethereum
BLAKE2 se encuentra entre las funciones hash más rápidas disponibles e incluye una función de compresión demostrablemente indistinguible, lo que le da una base de seguridad formal que SHA-2 no tiene. Su desventaja es el escrutinio: existen menos de 10 artículos de criptoanálisis sobre BLAKE2, muy por debajo de la cobertura que disfruta SHA-2 o SHA-3. BLAKE3 impulsa el rendimiento aproximadamente un 40% adicional al reducir el diseño de 10 rondas a 7 y al cambiar las operaciones internas del cifrador por bloques, pero esos cambios eliminan por completo la prueba de indistinguibilidad y rompen la compatibilidad con el criptoanálisis previo de BLAKE2; por tanto, su seguridad debe reevaluarse desde cero.
Hay un matiz adicional que afecta específicamente a Ethereum: la implementación de Keccak de la red difiere de la SHA-3 estandarizada en su esquema de padding. Ambas versiones son igualmente seguras en sus propios términos, pero no son interoperables en ninguna dirección, lo que añade una capa de complejidad de implementación que los clientes de Ethereum han tenido que sortear.
Seguridad, rendimiento y clasificación basada en el riesgo
Cuando los datos de seguridad y rendimiento se colocan lado a lado, los compromisos se vuelven más nítidos que lo que sugiere cualquier métrica por sí sola. Cada candidato protege frente a ataques de colisión y preimagen de formas diferentes, y cada uno se comporta de manera muy distinta cuando entran en juego benchmarks en hardware real.
Resistencia a colisiones y preimagen bajo escrutinio
La resistencia a ataques de colisión y preimagen es donde el historial de criptoanálisis separa con más claridad a los candidatos. Los ataques contra SHA-2 se mantienen muy lejos de lo práctico, dejando un margen cómodo. El diseño de SHA-3 solo se ha enfrentado a ataques limitados de colisión y preimagen, lo que refuerza su reputación por disponer de un amplio colchón de seguridad. BLAKE2s no tiene ataques publicados de colisión ni de “casi colisión” contra el hash completo. La estructura de BLAKE3 ha sido explorada con menos intentos de criptoanálisis hasta ahora, por lo que su resistencia a largo plazo está menos verificada que en su hermano mayor.
Resultados de benchmarks y posición de cada función hash
La velocidad bruta cuenta una historia muy distinta a la del escrutinio de seguridad. En el hashing de mensajes largos, BLAKE3 es el más rápido del grupo, mientras que SHA-3 es el más lento entre los principales candidatos probados. Esa brecha ilustra la tensión en el corazón del debate sobre seguridad criptográfica en Ethereum: la opción más rápida no es la más escrutada, y la opción más escrutada no es la más rápida.
Al sopesar el escrutinio de seguridad frente al rendimiento, la clasificación orientada a minimizar el riesgo coloca a SHA-3 en primer lugar, mientras que BLAKE2s y la variante de SHA-2 empatan en segundo y tercer lugar. BLAKE3 cae más abajo en la lista, lo que refleja su historial más “delgado” de criptoanálisis independiente pese a su sólido rendimiento bruto. En la práctica, este encuadre muestra por qué la elección no es solo técnica: es una apuesta por cuánto peso otorga la red a años de escrutinio público frente a cuánto valora recortar milisegundos en cada llamada de hash.
La implicación más amplia es que la decisión de hash post-Poseidon de Ethereum ahora depende menos de la eficiencia del circuito de demostración y más de cuánto riesgo criptográfico está dispuesto a asumir el protocolo a cambio de velocidad. Ese intercambio probablemente seguirá evolucionando a medida que BLAKE2 y BLAKE3 atraigan más criptoanálisis independiente con el tiempo.
Preguntas frecuentes
¿Por qué Ethereum ya no requiere funciones hash amigables con circuitos?
Porque el sistema de pruebas post-cuánticas Flock para circuitos binarios elimina la necesidad de hashes específicos amigables con circuitos.
¿Cuáles son los usos principales de las funciones hash en Ethereum hoy?
Las funciones hash se usan para firmas de la capa de consenso, agregando firmas con pruebas post-cuánticas, construyendo el árbol de estado, realizando pruebas de zkVM y firmas de la capa de ejecución.
¿Cómo se comparan SHA-2 y SHA-3 en contextos de Ethereum?
SHA-2 es rápido y está probado en batalla, pero sufre una vulnerabilidad de extensión de longitud, mientras que SHA-3 tiene un mayor margen de seguridad pero un rendimiento nativo y de circuitos más lento.
¿Cuáles son las principales ventajas y desventajas de BLAKE2 y BLAKE3?
BLAKE2 es rápido y tiene componentes de seguridad demostrables, pero con menos criptoanálisis; BLAKE3 es más rápido, pero carece de una prueba de indistinguibilidad y de compatibilidad con criptoanálisis retrospectivo.
Artículo producido con la asistencia de inteligencia artificial y revisado por el equipo editorial.
