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; esto 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

El siguiente es 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; esto es lo que significa la "Splurge" (prosperidad).

Hoja de ruta 2023: Splurge

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, mejorando la escalabilidad y reduciendo el riesgo
• Explorar criptografía avanzada para mejorar significativamente Ethereum a largo plazo

Mejoras de la EVM

¿Qué problema resuelve?

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 eficiencia de la EVM es baja 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 de mejoras de la EVM es el Formato de Objeto de la EVM (EOF), que está previsto que se incluya en la próxima bifurcación dura. EOF es una serie de EIP que especifican una nueva versión del código de la EVM, con varias 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 mayor eficiencia que aporta EOF: primero, mediante el bytecode ligeramente reducido gracias a las subrutinas, y después, mediante nuevas funciones específicas de EOF o menores costes 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 de Aritmética Modular de la EVM (EVM-MAX). EVM-MAX crea un conjunto de nuevas operaciones específicas para la aritmética modular y las coloca en un nuevo espacio de memoria inaccesible desde otros códigos de operación, lo que permite 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 originalmente 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 código de operación EVM-MAX (suma, resta, multiplicación), añadir una versión que ya no use 3 números inmediatos x, y, z, sino 7 inmediatos: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En código Python, estos códigos de operación 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 rotaciones y no rotaciones), al menos para módulos potencia de 2. También añadir ISZERO (que empuja la salida a la pila principal de la EVM), lo que será lo suficientemente potente para implementar criptografía de curva elíptica, criptografía de campo pequeño (como Poseidon, Circle STARKs), funciones hash tradicionales (como SHA256, KECCAK, BLAKE) y criptografía basada en retículas. También pueden implementarse otras mejoras de la EVM, 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 la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento —en bifurcaciones 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 comprobación estática del código también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación de la EVM y otros beneficios. Se puede 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 por hacer es implementar funciones similares a EVM-MAX + SIMD y realizar pruebas comparativas del consumo de gas para diversas operaciones criptográficas.

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

L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente; si ambos no se ajustan de forma sincronizada, puede haber incompatibilidades con efectos adversos. Además, EVM-MAX y SIMD pueden reducir el coste 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 capaz de realizar las mismas tareas, posiblemente sin afectar mucho la eficiencia.

Abstracción de cuentas

¿Qué problema resuelve?

Actualmente, las transacciones solo pueden verificarse de una manera: firmas ECDSA. Originalmente, la abstracción de cuentas pretendía ir más allá, permitiendo que la lógica de verificación de la cuenta sea 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 como una práctica de seguridad recomendada)
• Carteras multifirma y carteras de recuperación social
• Usar una clave para operaciones de bajo valor y otra (o un conjunto de claves) para operaciones de alto valor

Permitir que los protocolos de privacidad funcionen sin relés, reduciendo significativamente su complejidad y eliminando un punto central de dependencia clave

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

MPC (cómputo multipartito) es una tecnología con más de 40 años de antigüedad, utilizada para dividir una clave en varias partes y almacenarlas en varios 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 la próxima bifurcación dura. 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), con el objetivo de 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 dio lugar a 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 externamente, es decir, controladas por firmas ECDSA).

Como se puede ver en el gráfico, aunque algunos desafíos (especialmente los de "conveniencia") pueden resolverse con tecnologías progresivas como el cómputo multipartito o EIP-7702, los principales objetivos de seguridad que motivaron originalmente la propuesta de abstracción de cuentas solo pueden lograrse retrocediendo y resolviendo el 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 implementar esto de una manera que sea amigable para mantener una red descentralizada y que prevenga ataques de denegación de servicio.

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

Si la función de verificación de 1000 cuentas depende de un único valor S, y el valor actual de S hace que las transacciones en el mempool sean válidas, entonces una sola transacción que cambie el valor de S podría invalidar todas las demás transacciones en el mempool. Esto permite a un atacante enviar transacciones basura al mempool a muy bajo coste, saturando los recursos de los nodos de la red.

Después de años de trabajo para ampliar la funcionalidad y limitar el riesgo de denegación de servicio (DoS), finalmente se llegó a la solución para lograr 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 y todas las ejecuciones después. En el mempool, solo se aceptan operaciones de usuario cuya etapa de 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 fusión (Merge) y no tenían recursos para otras funciones. Por eso ERC-4337 utiliza objetos llamados operaciones de usuario en lugar de transacciones regulares. Sin embargo, recientemente nos hemos dado cuenta de que es necesario incorporar al menos parte de esto en el protocolo.

Las dos razones clave son:

1. La ineficiencia inherente de EntryPoint como contrato: cada paquete tiene un coste fijo de unos 100,000 gas, además de varios miles de gas adicionales por cada operación de usuario.
2. La necesidad de garantizar las propiedades de Ethereum: por ejemplo, las garantías de inclusión creadas por la lista de inclusión 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 remitente, por lo que se introduce un tratamiento especial para garantizar la seguridad del mecanismo de paymasters.
• 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 Rollups.

Enlaces a investigaciones existentes

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

Trabajo restante y compensaciones

Actualmente, lo principal que queda por resolver es cómo incorporar 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 la verificación; si la cuenta tiene esta sección, se ejecutará durante el paso de verificación de las transacciones provenientes de esa cuenta.

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

1. Incorporar EIP-4337 como 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 —no permitiendo acceso a estado externo, e incluso con límites de gas tan bajos que no sean útiles para aplicaciones resistentes a la computación cuántica o de privacidad—, entonces la seguridad de este enfoque es clara: simplemente reemplaza la verificación ECDSA por la ejecución de código EVM de duración similar.

Sin embargo, con el tiempo, necesitaremos relajar estos límites, ya que permitir aplicaciones de privacidad sin relés y resistencia cuántica es muy importante. Para ello, debemos encontrar formas más flexibles de abordar el riesgo de DoS, sin exigir que el paso de 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 obtener una solución más ideal"; el enfoque ideal podría ser algún tipo de método híbrido. Un método híbrido sería implementar rápidamente algunos casos de uso y dejar más tiempo para explorar otros. Otro método sería implementar primero una versión más ambiciosa de la abstracción de cuentas en L2. Sin embargo, esto enfrenta el desafío de que los equipos de L2 deben tener confianza en la propuesta para implementarla, especialmente para garantizar que L1 y/o otras L2 puedan adoptar una solución compatible 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 en una L2 dedicada, pero pueden usarse tanto en L1 como en cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero esto también requiere que la implementación de la 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 admitir transacciones de abstracción de cuentas. En la práctica, los requisitos de la lista de inclusión y los de un mempool descentralizado son muy similares, aunque la lista de inclusión es un poco más flexible. Además, la implementación de la abstracción de cuentas debe coordinarse tanto como sea 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 de bloques.

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 bloques llenos, sino aproximadamente al 50-53%, dependiendo de la varianza (esto está relacionado 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 sencilla 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 necesitarán mejoras con el tiempo.

Además, hay otras debilidades en la fijación de precios de los recursos de Ethereum no relacionadas con EIP-1559, pero que pueden abordarse ajustando EIP-1559. Uno de los principales problemas es la diferencia entre el caso promedio y el peor caso: el precio de los recursos en Ethereum debe establecerse para manejar el peor caso, es decir, que todo el gas de un bloque consuma un recurso, pero el uso promedio real es mucho menor, lo que conduce a ineficiencias.

¿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 sería un complejo problema de mochila multidimensional. Con EIP-1559, la mayoría de los bloques no alcanzan la capacidad máxima en ningún recurso, por lo que un algoritmo simple como "aceptar cualquier transacción que pague suficiente tarifa" es suficiente.

Actualmente, ya tenemos Gas multidimensional para la ejecución y los blobs de datos; en principio, podemos extenderlo a más dimensiones: como calldata (datos de transacción), lecturas/escrituras 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, que aborda 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 abordar el problema de la tasa de actualización, buscando un algoritmo de cálculo de tarifa base más rápido, manteniendo las invariantes clave introducidas por el mecanismo de EIP-4844 (es decir, que a largo plazo, el uso promedio se acerque exactamente 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. Aumentar la complejidad del protocolo: introducir Gas multidimensional hace que el protocolo sea más complejo.
2. Aumentar 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 las dimensiones de gas internas de la EVM (como lecturas y escrituras 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 al realizar operaciones de almacenamiento (por ejemplo, si SLOAD consume 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 comprender estas compensaciones y a 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 en gran medida el uso de recursos en ciertos "peores casos", reduciendo así la presión para optimizar el rendimiento, por ejemplo, para admitir árboles binarios basados en hash STARKed. 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ó anteriormente, 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 resuelve?

Actualmente, Ethereum utiliza aleatoriedad basada en RANDAO para seleccionar proponentes. La aleatoriedad de RANDAO funciona exigiendo a cada proponente que revele 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 simplemente no presentándose (a un coste). Esto es razonable para la selección de proponentes, ya que es poco común renunciar a una oportunidad para obtener dos nuevas. Pero para aplicaciones on-chain que requieren aleatoriedad, esto no es ideal. Idealmente, deberíamos 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 un SNARK, puede usarse como valor aleatorio.

La idea es elegir la entrada basada en información disponible en el tiempo T, mientras que la salida no es conocida en T: solo estará disponible después de que alguien ejecute completamente el cálculo 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 descubra cómo ejecutar la función más rápido de lo previsto, manipulando la información revelada en T.

La optimización inesperada puede ocurrir de dos maneras:

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, incluso si requiere 100 veces más recursos.

La tarea de crear una VDF exitosa es evitar ambos problemas, manteniendo la eficiencia práctica (por ejemplo, un 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 abordarse mediante la creación y distribución de un ASIC VDF casi óptimo por parte de un participante de interés público.

Enlaces a investigaciones existentes

• Sitio web de investigación sobre VDF: 
• Pensamientos 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 a los investigadores de Ethereum en todos los aspectos. 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 características 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 de la selección de proponentes, tiene aplicaciones en (i) aplicaciones on-chain que dependen de la aleatoriedad y (ii) mempools encriptados, aunque la creación de mempools encriptados basados en VDF aún depende de descubrimientos criptográficos adicionales que no han ocurrido.

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. Esto puede ser un coste 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 resuelve?

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 las interacciones. En su opinión, el papel de la criptografía es crear un tercero de confianza simulado que haga el mismo trabajo, sin necesidad de confiar en ningún participante específico.

Hasta ahora, solo hemos logrado parcialmente este 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 básico, cifrado basado en identidad para cifrado más conveniente bajo ciertas suposiciones, y firmas ciegas para dinero electrónico tipo Chaum, etc. Este enfoque requiere mucho trabajo para cada nueva aplicación.

En la década de 2010, vislumbramos por primera vez un enfoque diferente y más poderoso, basado en criptografía programable. En lugar de crear un nuevo protocolo para cada aplicación, podemos usar potentes nuevos protocolos —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; lo comparo con el impacto de los transformers en inteligencia artificial. Miles de años-persona de trabajo específico de aplicaciones son de repente reemplazados por esta solución general capaz de abordar problemas inesperadamente amplios.

Sin embargo, los ZK-SNARKs son solo el primero de tres primitivos generales extremadamente poderosos. 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 televisión que jugaba de niño: las cartas de los dioses egipcios.

Las cartas de los dioses egipcios son tres cartas extremadamente poderosas, cuya fabricación, según la leyenda, podría ser mortal, y su poder es tal que están prohibidas en los duelos. De manera similar, en criptografía, tenemos este conjunto de tres protocolos de dioses egipcios:

¿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 piedra angular de la estrategia de escalabilidad y privacidad de Ethereum. Pero los ZK-SNARKs tienen una limitación importante: necesitas conocer los datos para probarlos. El estado en cada aplicación de ZK-SNARK debe tener un único "propietario" que debe estar presente para aprobar la lectura o escritura de ese estado.

El segundo protocolo, sin esta limitación, es el cifrado homomórfico completo (FHE), que permite realizar cualquier cálculo sobre datos cifrados sin verlos. Esto permite realizar cálculos sobre los datos de los usuarios en su beneficio, manteniendo la privacidad de los datos y 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 finalmente es lo suficientemente eficiente como para empezar a ver aplicaciones reales.

Cursive es una aplicación que utiliza cómputo multipartito 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. Esto puede ser una configuración distribuida M-de-N, e incluso puedes usar entornos de ejecución confiables (TEEs) para una segunda capa de protección, pero sigue siendo una limitación.

El siguiente es el tercer protocolo, que es aún más poderoso que la combinación de los dos anteriores: 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 ha comenzado a implementarlos.

La ofuscación indistinguible permite crear un "programa cifrado" que realiza 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 este programa a otros. Ellos pueden usar el programa para firmar cualquier número 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.

La única cosa que un programa ofuscado no puede hacer es evitar que se copie. Sin embargo, para esto, hay tecnologías aún más poderosas en el horizonte, aunque dependen de que todos tengan una computadora cuántica: firmas de un solo uso cuánticas (quantum one-shot signatures).

Combinando ofuscación y firmas de un solo uso, podemos construir terceros de confianza prácticamente 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 comprender mejor cómo estos primitivos añaden capacidades adicionales, tomemos la votación como ejemplo clave. La votación es un problema interesante porque requiere muchas propiedades de seguridad complejas, incluida una verificabilidad y privacidad muy fuertes. Aunque existen protocolos de votación con fuertes propiedades de seguridad desde hace décadas, podemos complicar el desafío exigiendo el diseño de un protocolo capaz de manejar cualquier tipo de votación: como 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 si el resultado final es correcto, incluidas las reglas de conteo y elegibilidad) y resistencia a la censura (no se puede impedir que la gente vote). Pero no tenemos privacidad.

Luego, añadimos ZK-SNARKs. 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, donde los votos se cifran con 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 demostrar cómo votaron, incluso si quieren. Esto se debe a que, aunque pueden demostrar su voto, no pueden demostrar que no votaron para anularlo. Esto previene sobornos y otros ataques.

Realizamos el conteo en FHE y luego una computación de 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 diseñamos el programa ofuscado para que solo pueda emitir resultados cuando esté autorizado, por ejemplo, mediante una prueba de consenso de blockchain, una prueba de trabajo o ambas. Esto hace que la garantía de resistencia a la coacción sea casi perfecta: en el caso del consenso de blockchain, se requeriría la colusión del 51% de los validadores; en el caso de la 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 individual.

Añadimos firmas de un solo uso, un primitivo basado en computación cuántica que permite que una firma solo se use 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 y ejecutar cualquier programa y proporcionar la salida, introduciendo hash(key, program) como entrada. Dado dicho 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; se configura un entorno de confianza para que alguien cree un programa ofuscado que solo firme 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 incluso la ejecución exitosa de una VDF verificable.

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

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 las implementaciones.

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 (si no más), hasta el punto de ser inutilizables en aplicaciones. La ofuscación indistinguible es "teóricamente" de tiempo polinómico, pero en la práctica puede tardar más que la vida útil del universo. Los protocolos recientes han mejorado los tiempos de ejecución, pero el coste sigue siendo demasiado alto para el uso regular: un implementador estima un año de ejecución.

Las computadoras cuánticas ni siquiera existen todavía: todas las construcciones que ves en Internet son prototipos que no pueden hacer más de 4 bits de cómputo, o no son computadoras cuánticas sustanciales, aunque pueden tener partes cuánticas, pero no pueden ejecutar algoritmos significativos como 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, puede que pasen décadas antes de que la gente común pueda usar computadoras cuánticas en sus portátiles o teléfonos, antes de que las instituciones poderosas puedan romper la criptografía de curva elíptica.

Para la ofuscación indistinguible, una compensación clave es la suposición de seguridad; existen diseños más agresivos que usan suposiciones especiales. Estos diseños suelen tener tiempos de ejecución más realistas, pero las suposiciones especiales a veces terminan siendo rotas. Con el tiempo, podríamos entender mejor las retículas y proponer suposiciones más resistentes. Sin embargo, este camino es más arriesgado. El enfoque más conservador es ceñirse a protocolos cuya seguridad se reduce a suposiciones "estándar", pero esto podría significar que tardaremos más en obtener protocolos lo suficientemente rápidos.

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

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

1. Si obtenemos verificación de ZK-SNARKs tan simple como una firma, podríamos no necesitar ningún protocolo de agregación; podríamos verificar directamente en la 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 permanecer conservador en cuanto a suposiciones de seguridad. Sin embargo, el uso solo en la capa de aplicación podría ser revolucionario, como lo fue la aparición de los ZK-SNARKs.