Nuevo artículo de Vitaliks: El posible futuro de Ethereum, The Splurge

Título original: Posibles futuros del protocolo Ethereum, parte 6: El derroche

Artículo original de @VitalikButerin

Traducción original: zhouzhou, BlockBeats

A continuación se muestra el contenido original (para facilitar su lectura y comprensión, se ha reorganizado el contenido original):

Algunas cosas son difíciles de clasificar en una sola categoría, y en el diseño del protocolo Ethereum, hay muchos detalles que son muy importantes para el éxito de Ethereum. De hecho, aproximadamente la mitad del contenido involucra diferentes tipos de mejoras de EVM, y el resto se compone de varios temas de nicho. Esto es lo que significa florecer.

Hoja de ruta 2023: Prosperidad

Prosperidad: un objetivo clave

Llevar el EVM a un estado final estable y de alto rendimiento

Introducir la abstracción de cuentas en el protocolo, lo que permite a todos los usuarios disfrutar de cuentas más seguras y convenientes.

Optimizar la economía de las tarifas de transacción, aumentar la escalabilidad y reducir el riesgo

Explorando avanzado criptoLa grafía mejorará significativamente Ethereum a largo plazo

En este capítulo

Mejoras en EVM

Abstracción de cuenta

Mejoras de la EIP-1559

VDF (Función de retardo verificable)

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

Mejoras en EVM

¿Qué problema se resolvió?

El EVM actual 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 realización de extensiones adicionales. Además, el EVM es ineficiente y resulta difícil implementar muchas formas de criptografía avanzada a menos que se admita explícitamente mediante precompilación.

¿Qué es y cómo funciona?

El primer paso en la hoja de ruta actual de mejora de EVM es el formato de objeto EVM (EOF), cuya inclusión está prevista en la próxima bifurcación dura. EOF es una serie de EIP que especifican una nueva versión del código EVM con una serie de características únicas, Lo más notable:

• Separación entre código (que se puede ejecutar pero no se puede leer desde el EVM) y datos (que se pueden leer pero no se pueden ejecutar)

• Los saltos dinámicos están prohibidos, solo se permiten saltos estáticos.

• El código EVM ya no puede observar información relacionada con el combustible

• Se agregó un nuevo mecanismo de subrutina explícito

Estructura del código EOF

Boom: Mejoras en EVM (continuación)

Los contratos de estilo antiguo seguirán existiendo y podrán crearse, aunque es probable que con el tiempo se vayan eliminando gradualmente (quizás incluso se los obligue a convertirse al código EOF). Los contratos de estilo nuevo se beneficiarán de las ganancias de eficiencia que aporta el EOF, primero en un código de bytes ligeramente más pequeño a través de la función de subrutina y, más adelante, en forma de nueva funcionalidad específica de EOF o de menores costos de gas.

Después de la introducción de EOF, las actualizaciones posteriores se volvieron más fáciles y la más desarrollada en la actualidad es Extensión aritmética modular EVM (EVM-MAX) EVM-MAX crea un nuevo conjunto de operaciones específicamente para operaciones modulares y las coloca en un nuevo espacio de memoria al que no pueden acceder otros códigos de operación, lo que hace posible utilizar optimizaciones como Multiplicación de Montgomery .

Una idea más nueva es combinar EVM-MAX con la función de instrucción única y múltiples datos (SIMD). SIMD ha existido durante mucho tiempo como un concepto de Ethereum, propuesto por primera vez por Greg Colvins EIP-616 SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidas las funciones hash, las STARK de 32 bits y la 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.

Un diseño aproximado para un EIP combinado comenzaría con EIP-6690, luego:

• Permite (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), agregue una versión que use 7 valores inmediatos en lugar de 3 x, y, z: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En el código Python, estos códigos de operación funcionan de la siguiente manera:

• para i en rango(cuenta):
  mem[z_start + z_skip * conteo] = op(
  mem[x_inicio + x_saltar * conteo],
  mem[y_start + y_skip * conteo]
  )

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

• Es posible que se añadan XOR, AND, OR, NOT y SHIFT (tanto con bucle como sin bucle), al menos para módulos de potencias de 2. También se puede añadir ISZERO (que envía la salida a la pila principal de EVM), que será lo suficientemente potente como para implementar criptografía de curva elíptica, criptografía de dominio pequeño (como Poseidon, Circle STARKs), funciones hash tradicionales (como SHA 256, KECCAK, BLAKE) y criptografía basada en celosía. También son posibles otras actualizaciones de EVM, pero hasta ahora han recibido menos atención.

Enlaces a investigaciones existentes

Fin de año: https://evmobjectformat.org/

EVM-MÁXIMO: https://eips.ethereum.org/EIPS/eip-6690

SIMPLEMENTE: https://eips.ethereum.org/EIPS/eip-616

Trabajo restante y compensaciones

Actualmente, está previsto que EOF se incluya en la próxima bifurcación dura. Si bien siempre es posible eliminarlo en el último minuto (se han eliminado funciones temporalmente en bifurcaciones duras anteriores), hacerlo sería muy complicado. Eliminar EOF significa que cualquier actualización futura de EVM deberá realizarse sin EOF, lo que es posible, pero puede ser más difícil.

La principal desventaja de la EVM es la complejidad de L1 frente a la complejidad de la infraestructura. El EOF es una gran cantidad de código que debe agregarse a la implementación de la EVM, y la verificación estática del código es relativamente compleja. Sin embargo, a cambio, podemos simplificar el lenguaje de alto nivel, simplificar la implementación de la EVM y otros beneficios. Se puede decir que la hoja de ruta que prioriza la mejora continua de Ethereum L1 debe incluir y basarse en el EOF.

Un trabajo importante que debe realizarse es implementar algo como EVM-MAX más la funcionalidad SIMD y evaluar el consumo de gas de varias operaciones criptográficas.

¿Cómo interactúa con el resto de la hoja de ruta?

L1 ajusta su EVM para que L2 pueda ajustarse en consecuencia con mayor facilidad. Si los dos no se ajustan de manera sincronizada, puede causar incompatibilidad y efectos adversos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita la sustitución de más precompilaciones con código EVM que puede realizar las mismas tareas, posiblemente sin afectar en gran medida la eficiencia.

Abstracción de cuenta

¿Qué problema se resolvió?

Actualmente, las transacciones solo se pueden verificar de una manera: firmas ECDSA. Inicialmente, la abstracción de cuentas pretende ir más allá de esto, permitiendo que la lógica de verificación de una cuenta sea un código EVM arbitrario. Esto puede permitir una variedad de aplicaciones:

• Pasando a la criptografía resistente a la cuántica

• Rotar llaves antiguas (ampliamente Se considera una práctica de seguridad recomendada. )

• Carteras multi-firma y Carteras de recuperación social

• Utilice una clave para operaciones de bajo valor y otra clave (o conjunto de claves) para operaciones de alto valor

Permite que los protocolos de privacidad funcionen sin relés, lo que reduce significativamente su complejidad y elimina un punto central clave de dependencia.

Desde que se propuso la abstracción de cuentas en 2015, sus objetivos también se han ampliado para incluir una gran cantidad de objetivos de conveniencia, como una cuenta que no tiene ETH pero tiene algunos ERC 20 que puedan pagar gas con ERC 20. Aquí hay un cuadro resumen de estos objetivos:

MPC (Computación Multipartidaria) es un Tecnología de 40 años para dividir una clave en múltiples partes y almacenarlas en múltiples dispositivos, utilizando técnicas criptográficas para generar firmas sin combinar directamente esas 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 de la necesidad de proporcionar una abstracción de cuentas conveniente para beneficiar a todos los usuarios (incluidos los usuarios de EOA). Su objetivo es mejorar la experiencia de todos los usuarios a corto plazo y evitar la división en dos ecosistemas.

El trabajo comenzó con EIP-3074 y finalmente formó EIP-7702. EIP-7702 proporciona las características convenientes de abstracción de cuentas a todos los usuarios, incluidas las EOA actuales (cuentas de propiedad externa, es decir, cuentas controladas por firmas ECDSA).

Como se puede ver en el gráfico, si bien algunos desafíos (especialmente el desafío de la conveniencia) se pueden resolver mediante técnicas progresivas como la computación multipartita o EIP-7702, el objetivo de seguridad principal de la propuesta de abstracción de cuentas original solo se puede lograr retrocediendo y resolviendo el problema original: permitir que el código de contrato inteligente controle la verificación de transacciones. La razón por la que esto no se ha logrado hasta ahora es que es difícil implementarlo 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 surge de implementar esto de una manera que sea amigable para mantener una red descentralizada y protegerse contra ataques de denegación de servicio.

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

Si hay 1000 cuentas cuyas funciones de validación dependen todas de un único valor S, y el valor actual de S hace que todas las transacciones en el conjunto de memoria sean válidas, entonces una única transacción que invierta el valor de S puede invalidar todas las demás transacciones en el conjunto de memoria. Esto permite a los atacantes enviar transacciones basura al conjunto de memoria a un costo muy bajo, con lo que se saturan los recursos de los nodos de la red.

Después de años de arduo trabajo destinado a ampliar la funcionalidad y limitar los riesgos de denegación de servicio (DoS), finalmente se llegó a una solución para lograr una abstracción de cuenta ideal: ERC-4337.

ERC-4337 funciona dividiendo el procesamiento de las acciones del usuario en dos fases: verificación y ejecución. Todas las verificaciones se procesan primero y todas las ejecuciones se procesan después. En el grupo de memoria, las acciones del usuario se aceptan solo si la fase de verificación solo involucra su propia cuenta y no lee variables de entorno. Esto evita múltiples ataques de invalidación. Además, también se aplican límites estrictos 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 energía adicional para manejar otras funciones. Es por eso que ERC-4337 usa objetos llamados acciones de usuario en lugar de transacciones regulares. Sin embargo, recientemente nos dimos cuenta de que necesitamos escribir al menos algunos de ellos en el protocolo.

Las dos razones principales son las siguientes:

1. Ineficiencia inherente de EntryPoint como contrato: hay un gasto fijo de alrededor de 100.000 gases por paquete y miles de gases adicionales por operación de usuario.

2. Necesidad de garantizar las propiedades de Ethereum: Las garantías de inclusión creadas por las listas de inclusión deben transferirse a los usuarios de abstracción de cuentas.

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

• Paymasters: una función que permite que una cuenta pague comisiones en nombre de otra cuenta. Esto viola la regla de que solo se puede acceder a la cuenta del remitente durante la fase de verificación, por lo que se introduce un procesamiento especial para garantizar la seguridad del mecanismo de pago maestro.

• Agregadores: funciones que admiten la agregación de firmas, como la agregación BLS o la agregación basada en SNARK. Esto es necesario para lograr la máxima eficiencia de datos en Rollup.

Enlaces a investigaciones existentes

Una charla sobre la historia de la abstracción de cuentas: https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC-4337: https://eips.ethereum.org/EIPS/eip-4337

EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

Código BLSWallet (usando la función de agregación): https://github.com/getwax/bls-wallet

EIP-7562 (Abstracción de cuenta escrita en el protocolo): https://eips.ethereum.org/EIPS/eip-7562

EIP-7701 (abstracción de cuenta de protocolo de escritura basada en EOF): https://eips.ethereum.org/EIPS/eip-7701

Trabajo restante y compensaciones

La cuestión principal que se debe abordar es cómo introducir por completo la abstracción de cuentas en el protocolo. El EIP más popular para escribir la abstracción de cuentas del protocolo es EIP-7701 , que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para verificación. Si la cuenta establece esta sección de código, el código se ejecutará en el paso de verificación de las transacciones de la cuenta.

La belleza de este enfoque es que muestra claramente dos visiones equivalentes de la abstracción de cuentas locales:

1. Hacer que EIP-4337 sea parte del protocolo

2. Un nuevo tipo de EOA donde el algoritmo de firma es la ejecución de código EVM

Si comenzamos con límites estrictos en la complejidad del código que se puede ejecutar durante la verificación (no se permite el acceso al estado externo e incluso el límite de gas inicial se establece lo suficientemente bajo como para ser ineficaz para aplicaciones resistentes a la computación cuántica o que preservan la privacidad), entonces la seguridad de este enfoque es clara: simplemente reemplace la verificación ECDSA con la ejecución del código EVM que toma un tiempo similar.

Sin embargo, con el tiempo tendremos que relajar estos límites, ya que es muy importante permitir que las aplicaciones que preservan la privacidad funcionen sin relés y sin resistencia cuántica. Para ello, necesitamos encontrar formas de abordar de forma más flexible los riesgos de denegación de servicio (DoS) sin exigir que el paso de verificación sea extremadamente minimalista.

La principal disyuntiva parece ser escribir una solución rápidamente que satisfaga a menos personas en lugar de esperar más tiempo para encontrar una solución potencialmente más ideal, siendo el enfoque ideal probablemente algún tipo de híbrido. Un enfoque híbrido sería escribir algunos casos de uso más rápido y dejar más tiempo para explorar otros casos de uso. Otro enfoque sería implementar primero una versión más ambiciosa de la abstracción de cuentas en L2. Sin embargo, el desafío aquí es que los equipos de L2 deben estar seguros de que la propuesta de adopción funcionará antes de estar dispuestos a implementarla, especialmente para garantizar que L1 y/u otras L2 puedan adoptar soluciones compatibles en el futuro.

Otra aplicación que debemos considerar explícitamente es cuentas de almacenamiento de claves que almacenan el estado relacionado con la cuenta en L1 o en una L2 dedicada, pero se pueden usar en L1 y en cualquier L2 compatible. Para hacer esto de manera eficiente, es posible que L2 deba admitir códigos de operación como CARGA L1S o LLAMADA ESTÁTICA REMOTA , pero esto también requerirá la implementación de la abstracción de cuenta en L2 para soportar estas operaciones.

¿Cómo interactúa con el resto de la hoja de ruta?

Las listas de inclusión deben admitir transacciones de abstracción de cuentas y, en la práctica, los requisitos para las listas de inclusión son en realidad muy similares a los de los grupos de memoria descentralizados, aunque existe un poco más de flexibilidad para las listas de inclusión. Además, las implementaciones de abstracción de cuentas deben coordinarse entre L1 y L2 tanto como sea posible. 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 la 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 situación actual Implementación de EIP-1559 No es perfecto en varios aspectos:

1. La fórmula es ligeramente defectuosa: no apunta a 50% de bloques, sino a unos 50-53% de bloques completos, dependiendo de la varianza (esto tiene que ver con lo que los matemáticos llaman la “desigualdad de la media aritmético-geométrica”).

2. No adaptarse con la suficiente rapidez en situaciones extremas.

La fórmula posterior para los blobs (EIP-4844) está diseñada específicamente para abordar el primer problema y, en general, también es más clara. Sin embargo, ni la EIP-1559 en sí ni la EIP-4844 intentan abordar el segundo problema. Como resultado, el statu quo es un punto intermedio confuso que involucra dos mecanismos diferentes y existe el argumento de que ambos deberán mejorarse con el tiempo.

Además, existen otras debilidades en el precio de los recursos de Ethereum que no están relacionadas con EIP-1559, pero que se pueden solucionar con ajustes a EIP-1559. Uno de los principales problemas es la diferencia entre el escenario promedio y el peor de los casos: los precios de los recursos en Ethereum deben establecerse para manejar el peor de los casos, donde el consumo total de gas de un bloque ocupa un recurso, pero el uso promedio real es mucho menor que esto, lo que genera ineficiencias.

¿Qué es el Gas Multidimensional y cómo funciona?

La solución a estas ineficiencias es Gas multidimensional : diferentes precios y límites para diferentes recursos. Este concepto es técnicamente independiente de EIP-1559, pero la existencia de EIP-1559 hace que sea más fácil de implementar. Sin EIP-1559, empaquetar de manera óptima un bloque con múltiples restricciones de recursos es un Problema complejo y multidimensional de la mochila Con EIP-1559, la mayoría de los bloques no alcanzarán su capacidad máxima en ningún recurso, por lo que un algoritmo simple como aceptar cualquier transacción que pague suficientes tarifas es suficiente.

Actualmente contamos con gas multidimensional para ejecución y bloques de datos; en principio, podemos extender esto a más dimensiones: como datos de llamada (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 los datos de llamadas. También simplifica el mecanismo de gas multidimensional al unificar los tres tipos de gas en un único marco (estilo EIP-4844), solucionando así también las fallas matemáticas de EIP-1559. EIP-7623 es una solución más precisa al problema de los recursos en los casos promedio y peores, con un límite más estricto en los datos de llamada máximos sin introducir una dimensión completamente nueva.

Otra dirección de investigación es resolver el problema de la tasa de actualización y encontrar un algoritmo de cálculo de tarifa básica más rápido, preservando al mismo tiempo las invariantes clave introducidas por el mecanismo EIP-4844 (es decir: a largo plazo, el uso promedio está apenas cerca del valor objetivo).

Enlaces a investigaciones existentes

Preguntas frecuentes sobre EIP-1559: Preguntas frecuentes sobre la EIP-1559

Empírico Análisis de EIP-1559

Propuesto Mejoras para permitir ajustes rápidos:

Preguntas frecuentes sobre el mecanismo de tarifa básica del EIP-4844: Preguntas frecuentes sobre EIP-4844

EIP-7706: EIP-7706

EIP-7623: EIP-7623

Gas multidimensional: Gas multidimensional

¿Cuáles son las tareas pendientes y las compensaciones que hay que hacer?

Existen dos desventajas principales para el gas multidimensional:

1. Aumentar la complejidad del protocolo: la introducción de gas multidimensional hará que el protocolo sea más complejo.

2. Mayor complejidad del algoritmo óptimo necesario para llenar bloques: El algoritmo óptimo para llenar bloques hasta su capacidad también será más complejo.

La complejidad del protocolo es relativamente pequeña para los datos de llamadas, pero para aquellas dimensiones de gas que son internas al EVM (como las lecturas y escrituras de almacenamiento), la complejidad aumenta. El problema es que no solo los usuarios establecen límites de gas, sino que los contratos también establecen límites cuando llaman a otros contratos. Y actualmente, la única forma en que pueden establecer límites es en una sola dimensión.

Una solución sencilla es hacer que el gas multidimensional solo esté disponible dentro de EOF, porque EOF no permite que los contratos establezcan límites de gas al llamar a otros contratos. Los contratos que no son de EOF deben pagar por todos los tipos de gas cuando realizan operaciones de almacenamiento (por ejemplo, si SLOAD ocupa 0,031 TP9T del límite de gas de acceso al almacenamiento en bloque, entonces a los usuarios que no son de EOF también se les cobrará 0,031 TP9T de la tarifa de límite de gas de ejecución).

Más investigaciones sobre el gas multidimensional ayudarán a comprender estas compensaciones y encontrar el equilibrio ideal.

¿Cómo interactúa con el resto de la hoja de ruta?

La implementación exitosa de Gas multidimensional puede reducir significativamente el uso de recursos en el peor de los casos, lo que reduce la presión para optimizar el rendimiento para cumplir con requisitos como árboles binarios basados en hashes STARK. Establecer un objetivo claro para el crecimiento del tamaño del estado facilitará a los desarrolladores de clientes planificar y estimar los requisitos en el futuro.

Como se mencionó anteriormente, la existencia de EOF facilita la implementación de versiones más extremas de gas multidimensional debido a su naturaleza no observable.

Funciones de retardo verificables (VDF)

¿Qué problema resuelve?

Actualmente, Ethereum utiliza la aleatoriedad basada en RANDAO para seleccionar a los proponentes. La aleatoriedad de RANDAO funciona al exigir que cada proponente revele un secreto al que se comprometió con anticipación y mezclar cada secreto revelado con la aleatoriedad.

Cada proponente tiene, por tanto, un bit de poder: puede cambiar la aleatoriedad no presentándose (con un coste). Esto tiene sentido para encontrar proponentes, ya que es muy raro que se pierda una oportunidad para conseguir dos nuevos. Pero no es ideal para aplicaciones en cadena que necesitan aleatoriedad. Lo ideal sería encontrar una fuente de aleatoriedad más sólida.

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

Una función de retardo verificable es una función que solo se puede calcular de forma secuencial y no se puede acelerar mediante paralelización. Un ejemplo simple es el hash repetido: para i en el rango (10**9): x = hash(x). El resultado se demuestra correcto utilizando SNARK y se puede utilizar como un valor aleatorio.

La idea es que las entradas se eligen en función de la información disponible en el momento T, mientras que las salidas aún no se conocen en el momento T: las salidas solo están disponibles en algún momento después de T, una vez que alguien ha ejecutado completamente el cálculo. Como cualquiera puede ejecutar el cálculo, no hay posibilidad de ocultar los resultados y, por lo tanto, no hay capacidad para manipularlos.

El principal riesgo de las funciones de retardo verificables es la optimización accidental: alguien encuentra una forma de ejecutar la función más rápido de lo esperado, manipulando así la información que revela en el momento T.

La optimización accidental puede ocurrir de dos maneras:

1. Aceleración de hardware: Alguien crea un ASIC que ejecuta ciclos computacionales más rápido que el hardware existente.

2. Paralelización accidental: alguien encuentra una manera de ejecutar una función más rápido al paralelizarla, incluso si hacerlo requiere 100 veces más recursos.

La tarea de crear un VDF exitoso es evitar ambos problemas y, al mismo tiempo, mantener la eficiencia en la práctica (por ejemplo, un problema con los enfoques basados en hashes es que la conversión de hashes en tiempo real mediante SNARK requiere hardware pesado). La aceleración de hardware generalmente la aborda un actor de interés público que crea y distribuye por sí mismo un ASIC de VDF casi óptimo.

Enlaces a investigaciones existentes

Sitio web de investigación de VDF: vdfresearch.org

Pensamiento Sobre los ataques a VDF en Ethereum, 2018:

Ataques contra MinRoot

¿Cuáles son las tareas pendientes y las compensaciones que hay que hacer?

Actualmente, no existe una única construcción de VDF que satisfaga por completo todos los requisitos de los investigadores de Ethereum. Se necesita más trabajo para encontrar dicha función. Si se encuentra, la principal disyuntiva es si incluirla: un simple equilibrio entre la funcionalidad y la complejidad del protocolo y los riesgos de seguridad.

Si creemos que un VDF es seguro, pero resulta ser inseguro, entonces, dependiendo de cómo se implemente, la seguridad se degradará al supuesto RANDAO (1 bit de control por atacante) o ligeramente peor. Por lo tanto, incluso si el VDF falla, no romperá el protocolo, pero romperá las aplicaciones o cualquier característica nueva del protocolo que dependa fuertemente de él.

¿Cómo interactúa con el resto de la hoja de ruta?

Los VDF son un componente relativamente autónomo del protocolo Ethereum que, además de aumentar la seguridad de la selección de proponentes, tienen aplicaciones en (i) aplicaciones en cadena que dependen de la aleatoriedad y (ii) mempools criptográficos, aunque la creación de mempools criptográficos basados en VDF todavía depende de descubrimientos criptográficos adicionales que aún no han sucedido.

Un punto importante que hay que recordar es que, dada la incertidumbre en el hardware, habrá un cierto margen de maniobra entre el momento en que se produce la salida VDF y el momento en que se necesita. Esto significa que la información estará disponible varios bloques antes. Este puede ser un costo aceptable, pero se debe tener en cuenta en los diseños de selección de comités o de finalización de una sola ranura.

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 artículo de 1997 sobre el “Protocolo de Dios”. En este artículo, señaló que muchas aplicaciones multipartitas 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 requerir realmente la confianza en ningún participante en particular.

Hasta ahora, sólo hemos logrado parcialmente este ideal. Si todo lo que queremos es una computadora virtual transparente cuyos datos y cálculos no se puedan apagar, censurar o manipular, y la privacidad no es un objetivo, entonces la cadena de bloques puede lograr este objetivo, aunque con una escalabilidad limitada.

Si la privacidad es el objetivo, hasta hace poco sólo hemos podido desarrollar unos pocos protocolos específicos para aplicaciones específicas: firmas digitales para autenticación básica, firmas de anillo y firmas de anillo enlazables para anonimato puro, cifrado basado en identidad para un cifrado más conveniente bajo ciertas suposiciones sobre emisores confiables, firmas ciegas para dinero electrónico estilo Charm, etc. Este enfoque requiere mucho trabajo para cada nueva aplicación.

En la década de 2010, tuvimos el primer atisbo de un enfoque diferente y más potente, basado en la criptografía programable. En lugar de crear un nuevo protocolo para cada nueva aplicación, podemos utilizar nuevos protocolos potentes (en concreto, ZK-SNARK) para añadir garantías criptográficas a programas arbitrarios.

Los ZK-SNARK permiten a los usuarios probar afirmaciones arbitrarias sobre los datos que poseen, y las pruebas son (i) fácilmente verificables y (ii) no revelan ningún dato más allá de la propia afirmación. Este es un gran paso adelante tanto en privacidad como en escalabilidad, y lo comparo con el impacto de los transformadores en la IA. Miles de años-hombre de trabajo específico de la aplicación fueron reemplazados de repente por esta solución general que puede manejar una gama inesperadamente amplia de problemas.

Sin embargo, los ZK-SNARK son solo los primeros de tres primitivos generales extremadamente poderosos. Estos protocolos son tan poderosos que cuando pienso en ellos, me recuerdan a un conjunto de cartas extremadamente poderosas de Yu-Gi-Oh!, el juego de cartas y programa de televisión que jugué cuando era niño: las Cartas de los Dioses Egipcios.

Las cartas de los dioses egipcios son tres cartas extremadamente poderosas, la leyenda dice que el proceso de creación de estas cartas puede ser fatal, y su poder hace que su uso esté prohibido en los duelos. De manera similar, en criptografía, también tenemos este conjunto de tres protocolos de los dioses egipcios:

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

ZK-SNARKs es uno de los tres protocolos que ya tenemos, con un alto nivel de madurez. En los últimos cinco años, las mejoras espectaculares en la velocidad de los probadores y la facilidad de uso para los desarrolladores han hecho de ZK-SNARKs una piedra angular de la estrategia de escalabilidad y privacidad de Ethereum. Pero ZK-SNARKs tiene una limitación importante: es necesario conocer los datos para probarlos. Cada estado de una aplicación ZK-SNARK debe tener un propietario único que debe estar presente para aprobar la lectura o escritura de ese estado.

El segundo protocolo que no tiene esta limitación es el cifrado totalmente homomórfico (FHE), que permite realizar cualquier cálculo sobre datos cifrados sin necesidad de mirarlos. Esto permite realizar cálculos sobre los datos de los usuarios para su beneficio, manteniendo la privacidad de los datos y del algoritmo.

También permite escalar sistemas de votación como MACI para obtener garantías de seguridad y privacidad casi perfectas. Durante mucho tiempo se consideró que FHE era demasiado ineficiente para su uso práctico, pero ahora finalmente se está volviendo lo suficientemente eficiente como para comenzar a ver aplicaciones en el mundo real.

Cursive es una aplicación que aprovecha el cálculo de dos partes y el cifrado totalmente homomórfico (FHE) para el descubrimiento de intereses comunes preservando la privacidad.

Sin embargo, FHE también tiene sus limitaciones: cualquier tecnología basada en FHE aún requiere que alguien tenga la clave de descifrado. Puede ser una configuración distribuida de M-of-N e incluso se pueden usar entornos de ejecución confiables (TEE) para agregar una segunda capa de protección, pero sigue siendo una limitación.

A continuación viene el tercer protocolo, que es incluso más potente que los dos primeros juntos: la ofuscación de indistinguibilidad. Si bien esta tecnología aún está lejos de estar madura, a partir de 2020 contamos con protocolos teóricamente válidos basados en supuestos de seguridad estándar y recientemente comenzamos a implementarlos.

La ofuscación indistinguible permite crear un programa criptográfico que realiza cálculos arbitrarios mientras oculta todos los detalles internos del programa. Como ejemplo simple, puede colocar su clave privada en un programa ofuscado que solo le permita usarla para firmar números primos y distribuir este programa a otros. Pueden usar este programa para firmar cualquier número primo, pero no podrán extraer la clave. Sin embargo, sus capacidades van mucho más allá de esto: combinado con el hash, se puede usar para implementar cualquier otro primitivo criptográfico y más.

Lo único que un programa indistinguiblemente ofuscado no puede hacer es evitar que lo copien. Pero para eso hay una tecnología más poderosa esperando en el horizonte, aunque depende de que todos tengan un ordenador cuántico: las firmas cuánticas de un solo uso.

Al combinar la ofuscación y las firmas de un solo uso, podemos construir un sistema de terceros casi perfecto y sin necesidad de confiar en nadie. El único objetivo que no se puede lograr solo con la criptografía y que aún debe garantizar la cadena de bloques es la resistencia a la censura. Estas tecnologías no solo pueden hacer que Ethereum sea más seguro, sino que también pueden crear aplicaciones más potentes en él.

Para entender mejor cómo estos primitivos añaden capacidades adicionales, usemos la votación como un ejemplo clave. La votación es un problema interesante porque necesita satisfacer muchas propiedades de seguridad complejas, incluyendo una verificabilidad y privacidad muy sólidas. Si bien los protocolos de votación con fuertes propiedades de seguridad han existido durante décadas, podemos hacerlo más difícil para nosotros mismos al requerir diseños que puedan manejar protocolos de votación arbitrarios: votación cuadrática, financiación cuadrática restringida por pares, financiación cuadrática de emparejamiento de grupos, etc. En otras palabras, queremos que el paso de recuento de votos sea un programa arbitrario.

En primer lugar, supongamos que publicamos los resultados de la votación en la cadena de bloques. Esto nos da la posibilidad de verificar públicamente (cualquiera puede verificar que el resultado final es correcto, incluidas las reglas de recuento y elegibilidad) y resistencia a la censura (no se puede impedir que la gente vote). Pero no tenemos privacidad.

Luego agregamos ZK-SNARKs, y ahora tenemos privacidad: cada voto es anónimo, al tiempo que garantizamos que solo los votantes autorizados puedan votar, y cada votante solo puede votar una vez.

A continuación, presentamos el mecanismo MACI, en el que los votos se cifran en una clave de descifrado de un servidor central. El servidor central es responsable del proceso de recuento de votos, incluida la eliminación de votos duplicados y la publicación de una prueba ZK-SNARK del resultado. Esto conserva las garantías anteriores (¡incluso si el servidor hace trampas!), pero si el servidor es honesto, también añade una garantía de resistencia a la coerción: los usuarios no pueden demostrar cómo votaron, incluso si quisieran hacerlo. Esto se debe a que, si bien los usuarios pueden demostrar su voto, no pueden demostrar que no votaron para compensar ese voto. Esto evita el soborno y otros ataques.

Realizamos el recuento de votos en FHE y luego realizamos el cálculo de descifrado del umbral N/2 de N. Esto mejora la garantía anticoerción a N/2 de N en lugar de 1 de 1.

Ofuscamos el programa de recuento y lo diseñamos de modo que solo pueda mostrar resultados cuando se lo autorice, lo que puede ser una prueba de consenso de la cadena de bloques, algún tipo de prueba de trabajo o una combinación de ambas. Esto hace que la garantía anti-coerción sea casi perfecta: en el caso del consenso de la cadena de bloques, 51% de validadores deben coludirse para romperlo; en el caso de la prueba de trabajo, incluso si todos coludiesen, será extremadamente costoso volver a contar los votos con un subconjunto diferente de votantes para intentar extraer el comportamiento de un solo votante. Incluso podemos hacer que el programa realice pequeños ajustes aleatorios al recuento final para aumentar aún más la dificultad de extraer el comportamiento de un solo votante.

Hemos añadido firmas de un solo uso, un sistema primitivo que se basa en la computación cuántica y que permite utilizar una firma solo una vez para un determinado tipo de información. Esto hace que la garantía anticoerción sea realmente perfecta.

La ofuscación indistinguible también es compatible con otras aplicaciones potentes. Por ejemplo:

1. Organizaciones Autónomas Descentralizadas (DAO), subastas en cadena y otras aplicaciones con estados secretos internos arbitrarios.

2. Una configuración de confianza verdaderamente universal: alguien puede crear un programa ofuscado que contenga una clave, ejecutar cualquier programa y proporcionar la salida, colocando hash(clave, programa) como entrada en el programa. Dado un programa de este tipo, cualquiera puede colocar el programa 3 en sí mismo, combinando la clave previa del programa y su propia clave, extendiendo así la configuración. Esto se puede utilizar para generar una configuración de confianza 1 de N para cualquier protocolo.

3. La verificación de ZK-SNARK requiere solo una firma: Implementar esto es muy simple: configure un entorno confiable y haga que alguien cree un ofuscador que solo firme mensajes con la clave si hay un ZK-SNARK válido.

4. Grupo de memoria encriptada: es muy sencillo encriptar transacciones para que solo puedan desencriptarse si ocurre algún evento en la cadena en el futuro. Esto puede incluir incluso una función de demora verificable (VDF) ejecutada correctamente.

Con firmas de un solo uso, podemos hacer que las cadenas de bloques sean inmunes a los ataques 51% con reversión de la finalidad, aunque los ataques de censura aún son posibles. Las primitivas como las firmas de un solo uso hacen posible el dinero cuántico, resolviendo el problema del doble gasto sin una cadena de bloques, aunque muchas aplicaciones más complejas aún requieren una cadena.

Si se logra que estos elementos primitivos sean lo suficientemente eficientes, entonces la mayoría de las aplicaciones del mundo podrán descentralizarse. El principal obstáculo será verificar la corrección de la implementación.

A continuación se muestran algunos enlaces a investigaciones existentes:

1. Indistinguibilidad Ofuscación (2021):

2. Cómo la ofuscación puede ayudar a Ethereum

3. Primera construcción conocida de firmas de un solo uso

4. Intento de implementación de ofuscación (1)

5. Intento de implementación de ofuscación (2)

¿Qué trabajo queda por hacer y cuáles son los compromisos asumibles?

Aún queda mucho trabajo por hacer y la ofuscación indistinguible todavía es muy inmadura, con construcciones candidatas que se ejecutan tan lentamente (o más) de lo esperado, por lo que no se pueden usar en aplicaciones. La ofuscación indistinguible es famosa por ser teóricamente un tiempo polinómico, pero en la práctica su tiempo de ejecución puede ser más largo que la vida del universo. Los protocolos recientes han aliviado un poco este tiempo de ejecución, pero la sobrecarga sigue siendo demasiado alta para el uso rutinario: un implementador estima un tiempo de ejecución de un año.

Los ordenadores cuánticos ni siquiera existen todavía: todas las construcciones que se ven en Internet son o prototipos que no pueden hacer más que operaciones de 4 bits, o no son ordenadores cuánticos sustanciales en absoluto, y aunque pueden tener componentes cuánticos, no pueden ejecutar cálculos significativos como los algoritmos de Shor o Grover. Ha habido indicios recientes de que los ordenadores cuánticos reales no están muy lejos. Sin embargo, incluso si los ordenadores cuánticos reales aparecen pronto, pueden pasar décadas hasta que la gente común pueda utilizar ordenadores cuánticos en sus portátiles o teléfonos, hasta el día en que las instituciones poderosas puedan descifrar la criptografía de curva elíptica.

Para lograr una ofuscación indistinguible, un compromiso clave radica en las suposiciones de seguridad, y hay diseños más agresivos que utilizan suposiciones especiales. Estos diseños suelen tener tiempos de ejecución más realistas, pero a veces las suposiciones especiales pueden acabar rompiéndose. Con el tiempo, podemos entender mejor las redes y elaborar suposiciones que sean menos propensas a romperse. Sin embargo, este camino es más arriesgado. Un enfoque más conservador sería ceñirse a protocolos cuya seguridad se reduzca demostrablemente a las suposiciones estándar, pero esto puede significar que lleve más tiempo obtener un protocolo que se ejecute lo suficientemente rápido.

¿Cómo interactúa con el resto de la hoja de ruta?

Una criptografía extremadamente fuerte podría revolucionar el juego, por ejemplo:

1. Si logramos que los ZK-SNARK sean tan fáciles de verificar como la firma, entonces tal vez ya no necesitemos ningún protocolo de agregación; simplemente podremos hacer la verificación 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 pueden requerir únicamente una máquina virtual Ethereum (EVM) que preserve la privacidad para reemplazarlos.

4. El conjunto de memoria cifrada se vuelve más fácil de implementar.

Inicialmente, los beneficios surgirán en la capa de aplicación, ya que la capa 1 de Ethereum debe ser inherentemente conservadora en sus suposiciones de seguridad. Sin embargo, el uso solo en la capa de aplicación podría ser disruptivo, como sucedió con la llegada de los ZK-SNARK.

Enlace original

Este artículo proviene de Internet: Nuevo artículo de Vitaliks: El posible futuro de Ethereum, The Splurge

Relacionado: Grayscale selecciona cuidadosamente 35 tokens: FDV mínimo 300 millones de dólares estadounidenses, más adecuado para grandes inversores

Original | Odaily Planet Daily (@OdailyChina) Autor | Fu Howe (@vincent31515173) Como uno de los puentes que conectan la Web3 y las finanzas convencionales, las iniciativas de Grayscale en la industria de las criptomonedas han atraído mucha atención. Desde los productos fiduciarios iniciales de Bitcoin, Ethereum y muchos tokens conocidos hasta el lanzamiento del ETF spot de Bitcoin y el ETF spot de Ethereum este año, la contribución de Grayscale a la industria de las criptomonedas es obvia para todos. Recientemente, Grayscale enumeró 35 activos criptográficos que está considerando agregar a sus productos en el futuro. Con este fin, Odaily Planet Daily primero clasificó las 35 monedas por pista, y luego las ordenó por el valor de mercado de cada moneda, y compartió las tendencias de precios de los últimos dos años con los lectores a través de diagramas. Hay un total de…