Vitalik sobre el posible futuro de Ethereum (seis): The Splurge

En el diseño del protocolo de Ethereum, aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de la EVM, mientras que el resto está compuesto por diversos temas de nicho; eso es lo que significa la "Splurge" (Prosperidad).

Título original: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

Autor: Vitalik Buterin

Traducción: zhouzhou, BlockBeats

A continuación, el contenido original (editado para facilitar la lectura y comprensión):

Algunas cosas son difíciles de clasificar en una sola categoría. En el diseño del protocolo de Ethereum, hay muchos "detalles" que son muy importantes para el éxito de Ethereum. De hecho, aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de la EVM, mientras que el resto está compuesto por diversos temas de nicho; eso es lo que significa la "Splurge" (Prosperidad).

Hoja de ruta 2023: Splurge (Prosperidad)

Splurge: Objetivos clave

• Convertir la EVM en un "estado final" de alto rendimiento y estable
• Introducir la abstracción de cuentas en el protocolo, permitiendo que todos los usuarios disfruten de cuentas más seguras y convenientes
• Optimizar la economía de las tarifas de transacción, aumentando la escalabilidad y reduciendo el riesgo
• Explorar criptografía avanzada para mejorar significativamente Ethereum a largo plazo

Mejoras de la EVM

¿Qué problema resuelven?

Actualmente, la EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la expansión futura. Además, la EVM es poco eficiente y es difícil implementar muchas formas de criptografía avanzada, a menos que se admita explícitamente mediante precompilados.

¿Qué es y cómo funciona?

El primer paso de la hoja de ruta actual de mejoras de la EVM es el Formato de Objetos de la EVM (EOF), que está previsto para el próximo hard fork. EOF es una serie de EIP que especifican una nueva versión del código de la EVM, con muchas características únicas, siendo las más notables:

• Separación entre código (ejecutable pero no legible desde la EVM) y datos (legibles pero no ejecutables)
• Prohibición de saltos dinámicos, permitiendo solo saltos estáticos
• El código de la EVM ya no puede observar información relacionada con el gas
• Se añade un nuevo mecanismo explícito de subrutinas

Estructura del código EOF

Splurge: Mejoras de la EVM (continuación)

Los contratos antiguos seguirán existiendo y podrán crearse, aunque eventualmente podrían quedar obsoletos (o incluso forzados a convertirse en código EOF). Los contratos nuevos se beneficiarán de la eficiencia que aporta EOF: primero, mediante el bytecode ligeramente más pequeño gracias a las subrutinas, y luego, mediante nuevas funciones específicas de EOF o menores costos de gas.

Tras la introducción de EOF, las futuras actualizaciones serán más fáciles. Actualmente, la más desarrollada es la Extensión Aritmética Modular de la EVM (EVM-MAX). EVM-MAX crea un conjunto de nuevas operaciones específicas para aritmética modular y las coloca en un nuevo espacio de memoria inaccesible desde otros opcodes, permitiendo optimizaciones como la multiplicación de Montgomery.

Una idea más reciente es combinar EVM-MAX con la característica SIMD (Single Instruction Multiple Data). SIMD ha sido una idea en Ethereum durante mucho tiempo, propuesta inicialmente por Greg Colvin en la EIP-616. SIMD puede usarse para acelerar muchas formas de criptografía, incluyendo funciones hash, STARKs de 32 bits y criptografía basada en retículas. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una pareja natural.

El diseño aproximado de una EIP combinada partiría de la EIP-6690 y luego:

• Permitir (i) cualquier número impar o (ii) cualquier potencia de 2 hasta 2768 como módulo
• Para cada opcode de EVM-MAX (suma, resta, multiplicación), añadir una versión que ya no use 3 números inmediatos x, y, z, sino 7: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En código Python, estos opcodes funcionarían así:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

En la implementación real, esto se procesará en paralelo.

• Posiblemente añadir XOR, AND, OR, NOT y SHIFT (incluyendo circular y no circular), al menos para módulos potencia de 2. También añadir ISZERO (que empuja la salida al stack principal de la EVM), lo cual será lo suficientemente potente para implementar criptografía de curvas elípticas, criptografía de campos pequeños (como Poseidon, Circle STARKs), funciones hash tradicionales (como SHA256, KECCAK, BLAKE) y criptografía basada en retículas. Otras mejoras de la EVM también podrían implementarse, aunque hasta ahora han recibido menos atención.

Enlaces a investigaciones existentes

• EOF: 
• EVM-MAX: 
• SIMD: 

Trabajo restante y compensaciones

Actualmente, EOF está previsto para el próximo hard fork. Aunque siempre existe la posibilidad de eliminarlo en el último momento (en forks anteriores se han eliminado funciones temporalmente), hacerlo supondría un gran reto. Eliminar EOF significaría que cualquier futura actualización de la EVM tendría que hacerse sin EOF, lo cual es posible, pero probablemente más difícil.

La principal compensación de la EVM es la complejidad de L1 frente a la complejidad de la infraestructura. EOF es una gran cantidad de código que debe añadirse a la implementación de la EVM, y la verificación estática del código también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, la implementación de la EVM y otros beneficios. Se podría decir que una hoja de ruta que priorice la mejora continua de Ethereum L1 debería incluir y basarse en EOF.

Un trabajo importante que queda es implementar funciones similares a EVM-MAX + SIMD y hacer benchmarks del consumo de gas para varias operaciones criptográficas.

¿Cómo interactúa con otras partes de la hoja de ruta?

L1 ajustando su EVM facilita que L2 también realice los ajustes correspondientes; si no se sincronizan, puede haber incompatibilidades y efectos negativos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de pruebas, haciendo que L2 sea más eficiente. También facilita reemplazar más precompilados por código EVM que puede realizar las mismas tareas, posiblemente sin afectar mucho la eficiencia.

Abstracción de cuentas

¿Qué problema resuelve?

Actualmente, las transacciones solo pueden ser verificadas de una manera: firmas ECDSA. Originalmente, la abstracción de cuentas buscaba ir más allá, permitiendo que la lógica de verificación de una cuenta fuera cualquier código EVM. Esto habilita una serie de aplicaciones:

• Cambiar a criptografía resistente a la computación cuántica
• Rotar claves antiguas (ampliamente considerado una buena práctica de seguridad)
• Billeteras multifirma y billeteras de recuperación social
• Usar una clave para operaciones de bajo valor y otra (o un conjunto) para operaciones de alto valor

Permitir que los protocolos de privacidad funcionen sin relays, reduciendo significativamente su complejidad y eliminando un punto central de dependencia

Desde que se propuso la abstracción de cuentas en 2015, sus objetivos se han ampliado para incluir muchos "objetivos de conveniencia", por ejemplo, que una cuenta sin ETH pero con algunos ERC20 pueda pagar gas con ERC20. A continuación, un gráfico resumen de estos objetivos:

MPC (computación multipartita) es una tecnología con 40 años de historia, utilizada para dividir una clave en varias partes y almacenarlas en diferentes dispositivos, generando firmas mediante técnicas criptográficas sin combinar directamente las partes de la clave.

EIP-7702 es una propuesta que se planea introducir en el próximo hard fork. EIP-7702 es el resultado de una creciente conciencia sobre la conveniencia de la abstracción de cuentas para beneficiar a todos los usuarios (incluidos los usuarios EOA), y busca mejorar la experiencia de todos los usuarios a corto plazo y evitar la división en dos ecosistemas.

Este trabajo comenzó con EIP-3074 y finalmente se concretó en EIP-7702. EIP-7702 proporciona las "funciones de conveniencia" de la abstracción de cuentas a todos los usuarios, incluidos los EOA actuales (cuentas controladas por firmas ECDSA).

Como se ve en el gráfico, aunque algunos desafíos (especialmente los de "conveniencia") pueden resolverse con tecnologías graduales como MPC o EIP-7702, los principales objetivos de seguridad que motivaron la propuesta original de abstracción de cuentas solo pueden lograrse volviendo al problema original: permitir que el código de contratos inteligentes controle la verificación de transacciones. Hasta ahora, esto no se ha implementado debido a los desafíos de hacerlo de forma segura.

¿Qué es y cómo funciona?

El núcleo de la abstracción de cuentas es simple: permitir que los contratos inteligentes inicien transacciones, no solo los EOA. Toda la complejidad proviene de hacerlo de una manera que sea amigable para una red descentralizada y resistente a ataques de denegación de servicio.

Un desafío típico clave es el problema de fallos múltiples:

Si 1000 cuentas tienen funciones de verificación que dependen de un solo valor S, y el valor actual de S hace que todas las transacciones en el mempool sean válidas, una sola transacción que cambie el valor de S puede invalidar todas las demás transacciones en el mempool. Esto permite a un atacante enviar transacciones basura al mempool a muy bajo costo, saturando los recursos de los nodos de la red.

Tras años de trabajo para ampliar las funciones y limitar el riesgo de denegación de servicio (DoS), finalmente se llegó a la solución para la "abstracción de cuentas ideal": ERC-4337.

ERC-4337 funciona dividiendo el procesamiento de las operaciones de usuario en dos etapas: verificación y ejecución. Todas las verificaciones se procesan primero, seguidas de todas las ejecuciones. En el mempool, solo se aceptan operaciones de usuario cuya verificación solo involucra su propia cuenta y no lee variables de entorno. Esto previene ataques de fallos múltiples. Además, se imponen estrictos límites de gas en el paso de verificación.

ERC-4337 fue diseñado como un estándar de protocolo adicional (ERC) porque en ese momento los desarrolladores de clientes de Ethereum estaban enfocados en la Merge y no tenían recursos para otras funciones. Por eso ERC-4337 usa objetos llamados operaciones de usuario en lugar de transacciones regulares. Sin embargo, recientemente nos dimos cuenta de la necesidad de escribir al menos parte de esto en el protocolo.

Dos razones clave son:

1. La ineficiencia inherente de EntryPoint como contrato: cada bundle tiene un coste fijo de unos 100,000 gas, más varios miles de gas adicionales por cada operación de usuario.
2. La necesidad de garantizar propiedades de Ethereum: como las garantías de inclusión creadas por la lista de inclusión, que deben transferirse a los usuarios de abstracción de cuentas.

Además, ERC-4337 amplía dos funciones:

• Paymasters: permite que una cuenta pague las tarifas en nombre de otra, lo que viola la regla de que la verificación solo puede acceder a la cuenta emisora, por lo que se introduce un tratamiento especial para garantizar la seguridad del mecanismo.
• Aggregators: soporta la agregación de firmas, como la agregación BLS o basada en SNARK. Esto es necesario para lograr la máxima eficiencia de datos en los Rollup.

Enlaces a investigaciones existentes

• Charla sobre la historia de la abstracción de cuentas:
• ERC-4337:
• EIP-7702:
• Código de BLSWallet (usa funciones de agregación):
• EIP-7562 (abstracción de cuentas escrita en el protocolo):
• EIP-7701 (abstracción de cuentas sobre EOF escrita en el protocolo):

Trabajo restante y compensaciones

Actualmente, el principal reto es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas escrita en el protocolo más popular recientemente es EIP-7701, que implementa la abstracción de cuentas sobre EOF. Una cuenta puede tener una sección de código separada para verificación; si la cuenta tiene esa sección, se ejecutará durante la verificación de las transacciones de esa cuenta.

Lo fascinante de este enfoque es que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas nativa:

1. Hacer de EIP-4337 parte del protocolo
2. Un nuevo tipo de EOA donde el algoritmo de firma es la ejecución de código EVM

Si comenzamos estableciendo límites estrictos a la complejidad del código ejecutable durante la verificación (sin acceso a estado externo, e incluso límites de gas tan bajos que no sean útiles para aplicaciones resistentes a la computación cuántica o de privacidad), la seguridad de este enfoque es clara: simplemente reemplaza la verificación ECDSA por la ejecución de código EVM de tiempo similar.

Sin embargo, con el tiempo, necesitaremos relajar estos límites, ya que permitir aplicaciones de privacidad sin relays y resistencia cuántica es muy importante. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de DoS, sin exigir que la verificación sea extremadamente simple.

La principal compensación parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para una solución más ideal". El enfoque ideal podría ser una solución híbrida: escribir rápidamente algunos casos de uso y dejar más tiempo para explorar otros. Otra opción es desplegar primero versiones más ambiciosas de abstracción de cuentas en L2. Sin embargo, esto enfrenta el reto de que los equipos de L2 deben confiar en la propuesta para implementarla, especialmente para garantizar que L1 y/o otras L2 puedan adoptar soluciones compatibles en el futuro.

Otro caso de uso que debemos considerar explícitamente son las cuentas de almacenamiento de claves, que almacenan el estado relacionado con la cuenta en L1 o una L2 dedicada, pero pueden usarse en L1 y cualquier L2 compatible. Hacerlo de manera efectiva puede requerir que L2 soporte opcodes como L1SLOAD o REMOTESTATICCALL, pero esto también requiere que la implementación de abstracción de cuentas en L2 soporte estas operaciones.

¿Cómo interactúa con otras partes de la hoja de ruta?

La lista de inclusión debe soportar transacciones de abstracción de cuentas. En la práctica, las necesidades de la lista de inclusión y del mempool descentralizado son muy similares, aunque la lista de inclusión es un poco más flexible. Además, la implementación de abstracción de cuentas debería coordinarse lo máximo posible entre L1 y L2. Si en el futuro esperamos que la mayoría de los usuarios utilicen rollups de almacenamiento de claves, el diseño de la abstracción de cuentas debe basarse en esto.

Mejoras de EIP-1559

¿Qué problema resuelve?

EIP-1559 se activó en Ethereum en 2021, mejorando significativamente el tiempo promedio de inclusión en bloque.

Tiempo de espera

Sin embargo, la implementación actual de EIP-1559 no es perfecta en varios aspectos:

1. La fórmula es ligeramente defectuosa: no apunta al 50% de los bloques, sino a aproximadamente el 50-53% de bloques llenos, dependiendo de la varianza (esto se relaciona con la "desigualdad aritmético-geométrica" en matemáticas).
2. No se ajusta lo suficientemente rápido en situaciones extremas.

La fórmula utilizada para los blobs (EIP-4844) fue diseñada específicamente para resolver el primer problema y es más simple en general. Sin embargo, ni EIP-1559 ni EIP-4844 intentan resolver el segundo problema. Por lo tanto, la situación actual es un estado intermedio confuso, con dos mecanismos diferentes, y existe la opinión de que ambos necesitan mejoras con el tiempo.

Además, hay otras debilidades en la fijación de precios de recursos en Ethereum no relacionadas con EIP-1559, pero que pueden resolverse ajustando EIP-1559. Uno de los principales problemas es la diferencia entre el caso promedio y el peor caso: los precios de los recursos en Ethereum deben fijarse para manejar el peor caso (un bloque usando todo el gas en un recurso), pero el uso promedio real es mucho menor, lo que lleva a ineficiencia.

¿Qué es el gas multidimensional y cómo funciona?

La solución a estos problemas de ineficiencia es el gas multidimensional: establecer diferentes precios y límites para diferentes recursos. Este concepto es técnicamente independiente de EIP-1559, pero la existencia de EIP-1559 facilita su implementación. Sin EIP-1559, empacar óptimamente un bloque con múltiples restricciones de recursos es un complejo problema de mochila multidimensional. Con EIP-1559, la mayoría de los bloques no alcanzan el límite en ningún recurso, por lo que un algoritmo simple de "aceptar cualquier transacción que pague suficiente tarifa" es suficiente.

Actualmente ya tenemos gas multidimensional para la ejecución y los data blobs; en principio, podemos extenderlo a más dimensiones: como calldata (datos de transacción), lectura/escritura de estado y expansión del tamaño del estado.

EIP-7706 introduce una nueva dimensión de gas, específicamente para calldata. Al mismo tiempo, unifica los tres tipos de gas en un solo marco (al estilo de EIP-4844), simplificando el mecanismo de gas multidimensional y resolviendo el defecto matemático de EIP-1559. EIP-7623 es una solución más precisa para el problema de recursos promedio vs. peor caso, limitando más estrictamente el calldata máximo sin introducir una dimensión completamente nueva.

Una línea de investigación adicional es resolver el problema de la tasa de actualización, buscando un algoritmo de cálculo de tarifa base más rápido que conserve los invariantes clave introducidos por el mecanismo de EIP-4844 (es decir, que el uso promedio a largo plazo se acerque al valor objetivo).

Enlaces a investigaciones existentes

• FAQ de EIP-1559: 
• Análisis empírico de EIP-1559: 
• Propuestas de mejora para ajustes rápidos: 
• Sección sobre el mecanismo de tarifa base en el FAQ de EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• Gas multidimensional: 

¿Qué trabajo queda por hacer y cuáles son las compensaciones?

Las principales compensaciones del gas multidimensional son dos:

1. Aumenta la complejidad del protocolo: introducir gas multidimensional hace que el protocolo sea más complejo.
2. Aumenta la complejidad del algoritmo óptimo para llenar bloques: el algoritmo óptimo para llenar bloques a capacidad también se vuelve más complejo.

La complejidad del protocolo es relativamente baja para calldata, pero para dimensiones de gas internas de la EVM (como lectura y escritura de almacenamiento), la complejidad aumenta. El problema es que no solo los usuarios establecen límites de gas, los contratos también lo hacen al llamar a otros contratos. Actualmente, solo pueden establecer límites unidimensionales.

Una solución simple es hacer que el gas multidimensional solo esté disponible dentro de EOF, ya que EOF no permite que los contratos establezcan límites de gas al llamar a otros contratos. Los contratos que no son EOF deben pagar todas las tarifas de gas (por ejemplo, si SLOAD usa el 0,03% del límite de gas de acceso a almacenamiento del bloque, los usuarios que no son EOF también pagarán el 0,03% del límite de gas de ejecución).

Más investigación sobre gas multidimensional ayudará a entender estas compensaciones y encontrar el equilibrio ideal.

¿Cómo interactúa con otras partes de la hoja de ruta?

La implementación exitosa de gas multidimensional puede reducir significativamente el uso de recursos en "el peor caso", disminuyendo la presión para optimizar el rendimiento, por ejemplo, para soportar árboles binarios basados en hash STARK. Establecer un objetivo claro para el crecimiento del tamaño del estado facilitará la planificación y estimación de necesidades para los desarrolladores de clientes en el futuro.

Como se mencionó antes, la existencia de EOF facilita la implementación de versiones más extremas de gas multidimensional, gracias a su característica de gas no observable.

Funciones de retardo verificables (VDFs)

¿Qué problema resuelven?

Actualmente, Ethereum utiliza aleatoriedad basada en RANDAO para seleccionar proponentes. La aleatoriedad de RANDAO funciona exigiendo a cada proponente revelar un secreto previamente comprometido, mezclando cada secreto revelado en la aleatoriedad.

Cada proponente tiene así "1 bit de poder de manipulación": puede cambiar la aleatoriedad no presentándose (a un costo). Esto es razonable para seleccionar proponentes, ya que es raro que renuncies a una oportunidad y obtengas dos nuevas. Pero para aplicaciones on-chain que requieren aleatoriedad, no es ideal. Lo ideal sería encontrar una fuente de aleatoriedad más robusta.

¿Qué es una VDF y cómo funciona?

Una función de retardo verificable es una función que solo puede calcularse secuencialmente y no puede acelerarse mediante paralelización. Un ejemplo simple es el hash repetido: for i in range(10**9): x = hash(x). El resultado, probado con SNARK, puede usarse como valor aleatorio.

La idea es elegir la entrada basada en información disponible en el tiempo T, pero el resultado no es conocido en T: solo estará disponible después de que alguien ejecute el cálculo completo tras T. Como cualquiera puede ejecutar el cálculo, no hay posibilidad de ocultar el resultado, ni de manipularlo.

El principal riesgo de las VDF es la optimización inesperada: que alguien encuentre una forma de ejecutarla más rápido de lo previsto, manipulando la información revelada en T.

La optimización inesperada puede ocurrir de dos formas:

1. Aceleración por hardware: alguien fabrica un ASIC que ejecuta el bucle de cálculo más rápido que el hardware existente.
2. Paralelización inesperada: alguien encuentra una forma de paralelizar la función y ejecutarla más rápido, aunque requiera 100 veces más recursos.

La tarea de crear una VDF exitosa es evitar ambos problemas y mantener la eficiencia práctica (por ejemplo, el problema de los métodos basados en hash es que probar el hash en tiempo real con SNARK requiere hardware pesado). La aceleración por hardware suele resolverse mediante la creación y distribución pública de un ASIC VDF casi óptimo por parte de un actor de interés público.

Enlaces a investigaciones existentes

• Sitio de investigación de VDF: 
• Reflexiones sobre ataques a VDF en Ethereum, 2018: 
• Ataques a la VDF MinRoot propuesta: 

¿Qué trabajo queda por hacer y cuáles son las compensaciones?

Actualmente, no existe una construcción de VDF que satisfaga completamente todos los requisitos de los investigadores de Ethereum. Se necesita más trabajo para encontrar tal función. Si se encuentra, la principal compensación será si incluirla o no: una simple compensación entre funcionalidad, complejidad del protocolo y riesgos de seguridad.

Si creemos que una VDF es segura pero resulta no serlo, dependiendo de cómo se implemente, la seguridad se degradará a la suposición de RANDAO (1 bit de poder de manipulación por atacante) o algo ligeramente peor. Por lo tanto, incluso si la VDF falla, no romperá el protocolo, pero sí afectará a las aplicaciones o nuevas funciones del protocolo que dependan fuertemente de ella.

¿Cómo interactúa con otras partes de la hoja de ruta?

La VDF es una parte relativamente autónoma del protocolo de Ethereum. Además de aumentar la seguridad en la selección de proponentes, también tiene aplicaciones en (i) aplicaciones on-chain que dependen de aleatoriedad y (ii) mempools cifrados, aunque la creación de mempools cifrados basados en VDF aún depende de descubrimientos criptográficos adicionales.

Un punto a recordar es que, dada la incertidumbre del hardware, habrá cierto "margen" entre la generación de la salida de la VDF y su necesidad. Esto significa que la información estará disponible algunos bloques antes. Puede ser un costo aceptable, pero debe considerarse en el diseño de la finalización de un solo slot o la selección de comités.

Ofuscación y firmas de un solo uso: el futuro lejano de la criptografía

¿Qué problema resuelven?

Uno de los artículos más famosos de Nick Szabo es su ensayo de 1997 sobre el "protocolo de Dios". En él, señala que muchas aplicaciones multiparte dependen de un "tercero de confianza" para gestionar la interacción. Según él, el papel de la criptografía es crear un tercero de confianza simulado que haga el mismo trabajo, pero sin necesidad de confiar en ningún participante específico.

Hasta ahora, solo hemos logrado parcialmente ese ideal. Si solo necesitamos una máquina virtual transparente cuyos datos y cálculos no puedan ser apagados, censurados o manipulados, y la privacidad no es el objetivo, entonces la blockchain puede lograrlo, aunque con escalabilidad limitada.

Si la privacidad es el objetivo, hasta hace poco solo podíamos desarrollar protocolos concretos para aplicaciones específicas: firmas digitales para autenticación básica, firmas de anillo y firmas de anillo enlazables para anonimato, cifrado basado en identidad para cifrado conveniente bajo ciertas suposiciones de confianza, y firmas ciegas para efectivo electrónico tipo Chaum, etc. Este enfoque requiere mucho trabajo para cada nueva aplicación.

En la década de 2010, vimos por primera vez un enfoque diferente y más potente, basado en criptografía programable. En lugar de crear un nuevo protocolo para cada aplicación, podemos usar nuevos protocolos potentes (específicamente ZK-SNARKs) para añadir garantías criptográficas a cualquier programa.

Los ZK-SNARKs permiten a los usuarios probar cualquier declaración sobre los datos que poseen, y la prueba (i) es fácil de verificar y (ii) no revela nada más que la declaración en sí. Esto es un gran avance en privacidad y escalabilidad, comparable al impacto de los transformers en inteligencia artificial. Miles de años-persona de trabajo específico de aplicaciones son reemplazados por esta solución general que puede abordar problemas inesperadamente amplios.

Sin embargo, los ZK-SNARKs son solo el primero de tres primitivos universales extremadamente potentes. Estos protocolos son tan poderosos que me recuerdan a un conjunto de cartas muy poderosas en Yu-Gi-Oh!, el juego de cartas y programa de TV que jugaba de niño: las Cartas Dios Egipcias.

Las Cartas Dios Egipcias son tres cartas extremadamente poderosas, cuya creación se dice que puede ser mortal, y su poder es tal que están prohibidas en los duelos. De manera similar, en criptografía, tenemos este trío de protocolos "Dios Egipcio":

¿Qué son los ZK-SNARKs y cómo funcionan?

Los ZK-SNARKs son uno de los tres protocolos que ya tenemos, con un alto grado de madurez. En los últimos cinco años, la velocidad de los generadores de pruebas y la facilidad de desarrollo han mejorado enormemente, convirtiendo a los ZK-SNARKs en la base de la estrategia de escalabilidad y privacidad de Ethereum. Pero los ZK-SNARKs tienen una limitación importante: necesitas conocer los datos para probarlos. En cada aplicación ZK-SNARK, el estado debe tener un único "propietario" que debe estar presente para aprobar la lectura o escritura de ese estado.

El segundo protocolo, sin esa limitación, es el cifrado homomórfico completo (FHE). FHE permite realizar cualquier cálculo sobre datos cifrados sin verlos. Esto permite realizar cálculos sobre los datos del usuario en su beneficio, manteniendo la privacidad tanto de los datos como del algoritmo.

También permite ampliar sistemas de votación como MACI para obtener garantías de seguridad y privacidad casi perfectas. Durante mucho tiempo, se pensó que FHE era demasiado ineficiente para usarse en la práctica, pero ahora es lo suficientemente eficiente como para empezar a ver aplicaciones reales.

Cursive es una aplicación que utiliza computación multipartita y cifrado homomórfico completo (FHE) para descubrir intereses comunes de forma privada.

Sin embargo, FHE también tiene sus limitaciones: cualquier tecnología basada en FHE aún requiere que alguien posea la clave de descifrado. Puede ser una configuración distribuida M-de-N, e incluso puedes usar entornos de ejecución confiables (TEEs) como segunda capa de defensa, pero sigue siendo una limitación.

El siguiente protocolo, más potente que la combinación de los dos anteriores, es la ofuscación indistinguible (indistinguishability obfuscation). Aunque esta tecnología aún está lejos de madurar, desde 2020 tenemos protocolos teóricamente válidos basados en suposiciones de seguridad estándar, y recientemente se han comenzado a implementar.

La ofuscación indistinguible permite crear un "programa cifrado" que ejecuta cualquier cálculo, ocultando todos los detalles internos del programa. Por ejemplo, puedes poner una clave privada en un programa ofuscado que solo permita firmar números primos y distribuir ese programa. Otros pueden usarlo para firmar cualquier primo, pero no pueden extraer la clave. Sin embargo, su capacidad va mucho más allá: combinada con hash, puede implementarse cualquier otro primitivo criptográfico y más.

Lo único que no puede hacer un programa ofuscado es evitar ser copiado. Pero para eso, hay tecnologías aún más potentes en el horizonte, aunque dependen de que todos tengan una computadora cuántica: las firmas cuánticas de un solo uso (quantum one-shot signatures).

Combinando ofuscación y firmas de un solo uso, podemos construir terceros de confianza casi perfectos. El único objetivo que no puede lograrse solo con criptografía, y que aún requiere blockchain, es la resistencia a la censura. Estas tecnologías no solo pueden hacer que Ethereum sea más seguro, sino también permitir aplicaciones más potentes sobre él.

Para entender mejor cómo estos primitivos añaden capacidades, tomemos la votación como ejemplo clave. La votación es un problema interesante porque requiere muchas propiedades de seguridad complejas, incluyendo verificabilidad y privacidad muy fuertes. Aunque existen protocolos de votación seguros desde hace décadas, podemos complicarlo aún más exigiendo que maneje cualquier protocolo de votación: votación cuadrática, financiación cuadrática con restricciones de pares, financiación cuadrática por clúster, etc. En otras palabras, queremos que el paso de "conteo" sea un programa arbitrario.

Primero, supongamos que publicamos los resultados de la votación en la blockchain. Esto nos da verificabilidad pública (cualquiera puede verificar el resultado final, incluidas las reglas de conteo y elegibilidad) y resistencia a la censura (no se puede impedir votar). Pero no hay privacidad.

Luego, añadimos ZK-SNARKs, y ahora tenemos privacidad: cada voto es anónimo, asegurando que solo los votantes autorizados pueden votar y que cada uno solo puede votar una vez.

Después, introducimos el mecanismo MACI: los votos se cifran bajo la clave de descifrado de un servidor central. El servidor central realiza el conteo, elimina votos duplicados y publica una prueba ZK-SNARK del resultado. Esto mantiene las garantías anteriores (¡incluso si el servidor hace trampa!), pero si el servidor es honesto, añade una garantía de resistencia a la coacción: los usuarios no pueden probar cómo votaron, ni siquiera si quieren. Esto se debe a que, aunque pueden probar que votaron, no pueden probar que no votaron para anular ese voto. Esto previene sobornos y otros ataques.

Ejecutamos el conteo en FHE y luego hacemos un descifrado umbral N/2-de-N. Esto eleva la garantía de resistencia a la coacción a N/2-de-N, en lugar de 1-de-1.

Ofuscamos el programa de conteo y lo diseñamos para que solo pueda emitir el resultado si está autorizado, por ejemplo, mediante prueba de consenso de blockchain, prueba de trabajo o ambas. Esto hace que la garantía de resistencia a la coacción sea casi perfecta: en el caso de consenso de blockchain, se requeriría que el 51% de los validadores conspiren; en el caso de prueba de trabajo, incluso si todos conspiran, volver a contar con diferentes subconjuntos de votantes para intentar extraer el comportamiento de un votante sería extremadamente costoso. Incluso podemos hacer que el programa ajuste aleatoriamente el resultado final para dificultar aún más la extracción del comportamiento de un votante.

Añadimos firmas de un solo uso, un primitivo dependiente de la computación cuántica, que permite firmar solo una vez para un tipo específico de información. Esto hace que la garantía de resistencia a la coacción sea verdaderamente perfecta.

La ofuscación indistinguible también permite otras aplicaciones potentes. Por ejemplo:

1. DAOs, subastas on-chain y otras aplicaciones con estado secreto interno arbitrario.
2. Configuración de confianza verdaderamente universal: alguien puede crear un programa ofuscado con una clave, ejecutar cualquier programa y proporcionar la salida, usando hash(key, program) como entrada. Dado ese programa, cualquiera puede poner el programa 3 en sí mismo, combinando la clave previa del programa y su propia clave, extendiendo la configuración. Esto puede usarse para generar una configuración de confianza 1-de-N para cualquier protocolo.
3. Verificación de ZK-SNARKs con solo una firma: esto es fácil de implementar, configurando un entorno confiable donde alguien crea un programa ofuscado que solo firma mensajes con la clave si el ZK-SNARK es válido.
4. Mempool cifrado: las transacciones cifradas se vuelven muy fáciles, de modo que solo pueden descifrarse cuando ocurre un evento on-chain futuro. Esto puede incluir la ejecución exitosa de una VDF.

Con firmas de un solo uso, podemos proteger la blockchain contra ataques de reversión de finalidad del 51%, aunque los ataques de censura siguen siendo posibles. Primitivos similares permiten la moneda cuántica, resolviendo el problema del doble gasto sin blockchain, aunque muchas aplicaciones más complejas aún requieren cadena.

Si estos primitivos se vuelven lo suficientemente eficientes, la mayoría de las aplicaciones del mundo podrían descentralizarse. El principal cuello de botella será verificar la corrección de la implementación.

A continuación, algunos enlaces a investigaciones existentes:

• Protocolo de ofuscación indistinguible (2021): 
• Cómo la ofuscación puede ayudar a Ethereum: 
• Primera construcción conocida de firmas de un solo uso: 
• Intento de implementación de ofuscación (1): 
• Intento de implementación de ofuscación (2): 

¿Qué trabajo queda por hacer y cuáles son las compensaciones?

Queda mucho trabajo por hacer. La ofuscación indistinguible sigue siendo muy inmadura, y las construcciones candidatas son increíblemente lentas (o más), imposibles de usar en aplicaciones. La ofuscación indistinguible es "teóricamente" de tiempo polinomial, pero en la práctica puede tardar más que la vida del universo. Los protocolos recientes han mejorado los tiempos, pero el coste sigue siendo demasiado alto para el uso común: un implementador estimó un año de ejecución.

Las computadoras cuánticas ni siquiera existen: todas las construcciones que ves en internet son prototipos que no pueden hacer más de 4 bits de operaciones, o ni siquiera son computadoras cuánticas reales, aunque tengan partes cuánticas, no pueden ejecutar cálculos significativos como el algoritmo de Shor o Grover. Recientemente hay señales de que las "verdaderas" computadoras cuánticas no están tan lejos. Sin embargo, incluso si aparecen pronto, pasarán décadas antes de que la gente común pueda usarlas en sus laptops o teléfonos, y antes de que las instituciones puedan romper la criptografía de curvas elípticas.

Para la ofuscación indistinguible, una compensación clave es la suposición de seguridad: hay diseños más agresivos usando suposiciones especiales, que suelen ser más rápidos pero a veces se rompen. Con el tiempo, podríamos entender mejor las retículas y proponer suposiciones más robustas. Sin embargo, ese camino es más arriesgado. El enfoque más conservador es usar solo protocolos cuya seguridad se reduzca a suposiciones "estándar", pero eso podría significar esperar más tiempo para protocolos suficientemente rápidos.

¿Cómo interactúa con otras partes de la hoja de ruta?

La criptografía extremadamente potente podría cambiar radicalmente el juego, por ejemplo:

1. Si la verificación de ZK-SNARKs se vuelve tan simple como una firma, podríamos no necesitar protocolos de agregación; podríamos verificar directamente en cadena.
2. Las firmas de un solo uso podrían significar protocolos de prueba de participación más seguros.
3. Muchos protocolos de privacidad complejos podrían reemplazarse por una EVM privada.
4. El mempool cifrado sería más fácil de implementar.

Al principio, los beneficios aparecerán en la capa de aplicación, ya que el L1 de Ethereum debe ser conservador en sus suposiciones de seguridad. Sin embargo, el uso solo en la capa de aplicación podría ser disruptivo, como lo fue la aparición de los ZK-SNARKs.