Vitalik pide a los desarrolladores de ZK y FHE que "muestren directamente la tasa de cifrado": puede ver la diferencia de un vistazo y luego hablar sobre optimización

La tecnología de privacidad debe quedar clara de un vistazo. Vitalik Buterin pidió a los desarrolladores que, al hablar del rendimiento de ZK y FHE, muestren directamente el "índice de eficiencia".
(Resumen preliminar: La Fundación Ethereum estableció un "Grupo de Investigación de Privacidad" para promover seis hojas de ruta principales y lanzar completamente la competencia en el ámbito de la privacidad)
(Suplemento de antecedentes: La Fundación Ethereum lanzó un plan de privacidad de extremo a extremo, un enfoque triple para fortalecer la base de DeFi y el cumplimiento)

Contenido de este artículo

El cofundador de Ethereum, Vitalik Buterin, publicó recientemente un artículo En la plataforma X, al recomendar a los desarrolladores que evalúen las pruebas de conocimiento cero (ZK) y el cifrado totalmente homomórfico (FHE), deberíamos abandonar el indicador habitual de "N operaciones por segundo" y, en su lugar, centrarnos en la relación de eficiencia de "tiempo de cálculo de cifrado/tiempo de cálculo original". La intención es proponer un estándar de prueba más directo para la viabilidad de la tecnología de privacidad Web3.

Vitalik se centra en el índice de eficiencia

Las métricas de rendimiento tradicionales dependen en gran medida del entorno de hardware y no pueden revelar la verdadera carga causada por la capa de cifrado. Vitalik señala que si los desarrolladores saben que el cálculo original solo toma 1 milisegundo, pueden deducir directamente del índice de eficiencia cuánto tiempo se amplificará el cifrado.

Traducción del tweet de Vitalik:

Espero que más personas que utilizan ZK (conocimiento cero) y FHE (cifrado totalmente homomórfico) puedan usar valores de relación para expresar la sobrecarga adicional ("tiempo de cálculo bajo protección criptográfica" frente a "tiempo de cálculo original"), en lugar de simplemente decir "podemos hacer N operaciones por segundo".

Esto es más independiente del hardware y puede proporcionar una cifra muy informativa: si mi aplicación está protegida mediante criptografía en lugar de depender de la confianza, ¿cuánta eficiencia sacrificaré?

Esto también es generalmente mejor para realizar estimaciones, porque como desarrollador ya sé cuánto tiempo lleva el cálculo sin procesar, y simplemente tomo ese tiempo y lo multiplico por el multiplicador.

(Sí, sé que esto es difícil, porque las operaciones requeridas entre la "ejecución" y la "generación de una prueba" son de diferente naturaleza, especialmente involucrando SIMD/paralelización y patrones de acceso a la memoria, por lo que incluso la proporción aún se ve afectada por el hardware hasta cierto punto. Pero aun así, sigo pensando que expresar la sobrecarga como un múltiplo, aunque no perfecto, sigue siendo un buen indicador.)

Me gustaría que más personas de ZK y FHE dieran sus gastos generales como una proporción (tiempo para calcular en criptografía frente a tiempo para calcular sin procesar), en lugar de simplemente decir "podemos hacer N operaciones por segundo"

Es más independiente del hardware y proporciona un número muy informativo: ¿cuánta eficiencia tengo...?

— vitalik.eth (@VitalikButerin) 18 de octubre de 2025

Vitalik enfatizó que aunque esta proporción aún se verá afectada por el diseño de la memoria, el grado de paralelización y las diferencias en el conjunto de instrucciones, al menos permite a la comunidad "usar la misma regla" para medir diferentes soluciones.

Cuellos de botella en el rendimiento de ZK y FHE

ZK y FHE tienen funciones muy diferentes a la hora de proteger la privacidad del usuario, pero también enfrentan altos gastos generales. Una vez que aumenta la complejidad del circuito ZK, el tiempo de generación de la prueba puede tardar cientos de veces. El cuello de botella de FHE es aún más obvio. La versión FHE de inferencia de aprendizaje automático es 20.000 veces más lenta que el texto sin formato.

Estos retrasos dificultan la implementación de escenarios como DeFi, identidad descentralizada (DID) e IA en cadena, y también resaltan la importancia del marco del índice de eficiencia. Por lo tanto, Vitalik pide a todos que vean la carga de cada solución antes de que podamos hablar de optimización.

Camino de optimización y cooperación ecológica

La iniciativa de Vitalik anima a la comunidad a reasignar recursos de I+D. Se puede ver que, a corto plazo, la innovación a nivel de algoritmo sigue siendo el principal medio para reducir la proporción. El próximo mediano plazo es la actualización de los equipos informáticos GPU o ASIC, que se espera que reduzca el tiempo de cálculo del tiempo absoluto a un rango aceptable para los usuarios.

A largo plazo, el cifrado selectivo y la colaboración entre capas serán clave para impulsar la adopción masiva. Actualmente, la industria del cifrado está pro02mpndo la estandarización de circuitos ZK, la optimización del compilador FHE y el intercambio de pruebas fuera de la cadena. El objetivo es reducir el ratio de eficiencia sin debilitar la privacidad y ganar más escenarios para aplicaciones descentralizadas.