Vitalik: El posible futuro del protocolo Ethereum: el derroche

Autor: Vitalik, fundador de Ethereum;

Nota: Este artículo es la sexta parte de la serie de artículos publicados recientemente por Vitalik, fundador de Ethereum,Posibles futuros del Protocolo Ethereum, Parte 6: El derroche«, Ver la quinta parte»Vitalik: El posible futuro del protocolo Ethereum: la purga«, Ver la cuarta parte»Vitalik: El posible futuro de Ethereum el borde«. Ver «Vitalik: Objetivos clave del Ethereum the Scourge Fase«, Vea la segunda parte»Vitalik: ¿Cómo debería desarrollarse el protocolo Ethereum en la etapa de sobretensión?«, Vea la primera parte»¿Qué más se puede mejorar en Ethereum POS?«.

---

Un agradecimiento especial a Justin Drake y Tim Beiko por sus comentarios y comentarios.

Algunas cosas son difíciles de caer en una categoría.Hay muchas «pequeñas cosas» en el diseño del protocolo Ethereum que son muy valiosos para el éxito de Ethereum, pero no son adecuados para ser clasificados en una subcategoría más grande.De hecho, aproximadamente la mitad de estos terminan asociados con varias mejoras EVM, mientras que el resto consiste en varios temas de nicho.Para esto es «el derroche».

Derrojo, Hoja de ruta 2023

El derroche: objetivos principales

• Traiga EVM a un «estado final» estable de alto rendimiento y estable

• Introducir la abstracción de la cuenta en protocolos para que todos los usuarios puedan beneficiarse de cuentas más seguras y convenientes

• Optimizar la economía de las tarifas de transacción, mejorar la escalabilidad y reducir los riesgos

• Explore las tecnologías avanzadas de cifrado que pueden mejorar a Ethereum a largo plazo

Mejoras de EVM

¿Qué problemas resuelve?

Los EVM de hoy son difíciles de realizar un análisis estático, lo que dificulta crear implementaciones eficientes, código de verificación formal y una mayor escala con el tiempo.Además, es muy ineficiente, lo que dificulta implementar múltiples formas de cifrado avanzado a menos que sean compatibles explícitamente por la precompilación.

¿Qué es y cómo funciona?

El primer paso en la hoja de ruta de mejora EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura.EOF es una serie de EIP utilizados para especificar nuevas versiones del código EVM con muchas características únicas, especialmente:

• Separación entre código (ejecutable, pero no leído de EVM) y datos (legible, pero no ejecutable).

• 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 gas.

• Se agregó un nuevo mecanismo de subrutina explícita.

Estructura del código EOF

Los contratos de estilo antiguo continuarán existiendo y se pueden crear, aunque los contratos de estilo antiguo pueden eventualmente estar en desorden (y tal vez incluso obligarlos a convertir a Código EOF).Los nuevos contratos se beneficiarán de las ganancias de eficiencia provocadas por EOF-Primero, con funciones de subrutina, el bytecode será ligeramente menor, y luego se reducirán nuevas funciones específicas de EOF, o costos de gas específicos de EOF.

Con la introducción de EOF, se hizo más fácil introducir más actualizaciones.La más completa en la actualidad es la extensión aritmética modular EVM (EVM-Max).EVM-Max crea un conjunto de nuevas operaciones diseñadas para la aritmética modular y las coloca en un nuevo espacio de memoria al que no se puede acceder a través de otros códigos de operación.Esto permite el uso de optimizaciones, como la multiplicación de Montgomery.

Una idea más nueva es combinar las capacidades de EVM-Max con una sola instrucción múltiple (SIMD).Simd ha sido una idea para Ethereum desde el EIP-616 de Greg Colvin.SIMD se puede utilizar para acelerar una variedad de formas de cifrado, incluidas las funciones hash, el Stark de 32 bits y el cifrado basado en la matriz de puntos.EVM-Max y Simd juntos forman un par de extensiones orientadas al rendimiento de EVM.

El diseño aproximado del EIP combinado comienza con EIP-6690, y luego:

• Permite (i) cualquier número impar o (ii) cualquier potencia de 2 (hasta 2^768) como módulo

• Para cada código de operación EVMMAX (agregar, sub, mul), agregar una versión. .En el código Python, estos códigos de operación realizarán operaciones equivalentes a lo siguiente:

A menos que en la implementación real, se procesará en paralelo.

• Si es posible, agregue XOR, y, o, no, y cambie (bucle y acíclico) a al menos 2 módulos de potencia.También agregó ISZERO (empujando la salida a la pila principal EVM).

Esto sería lo suficientemente poderoso como para implementar la criptografía de la curva elíptica, la criptografía de dominio pequeño (por ejemplo, Poseidon, Circular Stark), funciones de hash tradicionales (por ejemplo, SHA256, Keccak, Blake) y criptografía basada en matriz Dot.

También se pueden implementar otras actualizaciones EVM, pero hasta ahora han recibido menos atención.

¿Qué investigación están disponibles?

EOF:https://evmobjectformat.org/

EVM-Max:https://eips.ethereum.org/eips/eip-6690

Simd:https://eips.ethereum.org/eips/eip-616

¿Cuáles son las cosas restantes que hacer y qué compensaciones hay?

Actualmente, el plan EOF está incluido en la próxima bifurcación dura.Si bien siempre es posible eliminarlo, la característica en la horquilla dura anterior se eliminó en el último minuto, sería una batalla cuesta arriba hacerlo.Eliminar EOF significa que EOF no se utilizará en ninguna actualización futura para EVM, lo que se puede hacer, pero puede ser más difícil.

Las principales compensaciones para EVM son la complejidad L1 y la complejidad de la infraestructura.EOF es un montón de código agregado a la implementación EVM, y la inspección del código estático es muy compleja.Sin embargo, a cambio, obtenemos simplificación del lenguaje de alto nivel, la simplificación de la implementación de EVM y otros beneficios.Se puede decir que la hoja de ruta para priorizar mejoras continuas al Ethereum L1 se incluirá y se construirá en EOF.

Un trabajo importante es implementar algo como EVM-Max Plus SIMD y Benchmark cuánto gas se requiere para varias operaciones de cifrado.

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

L1 ajusta su EVM para hacer que el L2 sea más fácil de hacer los mismos ajustes.Un ajuste y el otro ajuste causarán cierta incompatibilidad, que tiene sus propias desventajas.Además, EVM-Max Plus SIMD puede reducir los costos de gas para muchos sistemas de prueba, lo que resulta en un L2 más eficiente.También hace que sea más fácil eliminar más precompilaciones reemplazándolas con el código EVM que puede realizar las mismas tareas sin tener que tener un gran impacto en la eficiencia.

Abstracción de la cuenta

¿Qué problemas resuelve?

Actualmente, las transacciones solo se pueden verificar de una manera: firmas ECDSA.Inicialmente, la abstracción de la cuenta fue diseñada para ir más allá de esto y permitió que la lógica de verificación de la cuenta fuera un código EVM arbitrario.Esto puede lograr una gama de aplicaciones:

• Cambiar a tecnología de cifrado resistente a la cantidad cuántica;

• Cayas viejas giratorias (ampliamente considerada una práctica de seguridad recomendada);

• Billetera multisignatura y billetera de recuperación social;

• Firmar operaciones de bajo valor con una clave y operaciones de alto valor con otra clave (o un conjunto de claves);

• Permitir que los protocolos de privacidad funcionen sin repetidores reduce en gran medida su complejidad y elimina las dependencias centrales críticas.

Desde que comenzó la abstracción de la cuenta en 2015, el objetivo se ha expandido para incluir una gran cantidad de «objetivos de conveniencia» como no ETH, pero algunas cuentas ERC20 pueden pagar gas con ese ERC20.El resumen de estos objetivos se muestra en la siguiente tabla:

Aquí MPC es la computación multipartidista: una tecnología de 40 años que divide la clave en múltiples partes, la almacena en múltiples dispositivos y genera firmas utilizando el cifrado sin combinar directamente las partes individuales de la clave.

EIP-7702 es un EIP planeado para introducirse en la próxima horquilla dura.EIP-7702 es el resultado del aumento del reconocimiento de la necesidad de proporcionar abstracción de cuentas a todos los usuarios, incluidos los usuarios de EOA, para mejorar la experiencia de usuario de todos a corto plazo y evitar dividirse en dos ecosistemas.Este trabajo comenzó con EIP-3074 y finalmente alcanzó su punto máximo en EIP-7702.EIP-7702 «Función de conveniencia» que hace que el resumen de la cuenta esté disponible para todos los usuarios, incluida la EOA (cuentas de propiedad externamente, es decir, cuentas controladas por la firma ECDSA).

Desde el cuadro podemos ver que, si bien algunos desafíos (especialmente el desafío de «conveniencia») pueden resolverse mediante computación multipartidista o tecnologías progresivas como EIP-7702, la mayoría de los objetivos de seguridad de la propuesta inicial de cuentas abstractas solo pueden ser Volvió para resolver el problema inicial: permita que el código de contrato inteligente controle la verificación de la transacción.La razón por la cual esto no se ha hecho hasta ahora es que implementarlo de manera segura es un desafío.

¿qué es?¿Cómo funciona?

En esencia, la abstracción de la cuenta es simple: permitir que las transacciones se inicien a través de contratos inteligentes (no solo EOA).Toda la complejidad proviene de hacer esto de una manera que facilite el mantenimiento de redes descentralizadas y evite la negación de los ataques de servicio.

Un ejemplo ilustrativo de un desafío clave es el problema de invalidación múltiple:

Si hay 1000 funciones de validación de cuentas, todas dependen de un solo valor S y hay transacciones válidas de acuerdo con el valor actual de S en el grupo de memoria, una transacción que voltea el valor S puede invalidar todas las demás transacciones en el grupo de memoria.Esto permite a un atacante enviar spam al grupo de memoria a un costo muy bajo, bloqueando los recursos del nodo de red.

A lo largo de los años, los esfuerzos para expandir las capacidades al tiempo que limitan los riesgos de DOS han llevado a un acuerdo sobre soluciones para lograr la «abstracción de cuenta ideal»: ERC-4337.

La forma en que funciona ERC-4337 es dividir el procesamiento de las operaciones del usuario en dos etapas: verificación y ejecución.Todas las validaciones se procesan primero y luego se procesan todas las ejecuciones.En el grupo de memoria, las operaciones del usuario se aceptan solo cuando la fase de verificación de la operación del usuario solo toca su propia cuenta y no lee las variables de entorno.Esto evita múltiples ataques inválidos.El paso de verificación también aplica restricciones estrictas de gas.

ERC-4337 fue diseñado como un estándar fuera del protocolo (ERC) porque los desarrolladores de clientes de Ethereum se centraron en fusionarse en ese momento y no tenían capacidad adicional para manejar otras funciones.Es por eso que ERC-4337 usa sus propios objetos (llamados operaciones de usuario) en lugar de transacciones regulares.Sin embargo, recientemente nos hemos dado cuenta de la necesidad de incluir al menos parte de esto en el acuerdo.Dos razones principales son:

• EntryPoint es inherentemente ineficiente como contrato: fijo ~ 100k gastos generales de gas por paquete y miles de cargos adicionales por operación del usuario;

• Es necesario garantizar que las propiedades de Ethereum (como las garantías de inclusión creadas por las listas de inclusión) continúen al usuario abstracto de la cuenta.

Además, ERC-4337 también extiende dos funciones:

• Payer: la característica que permite que una cuenta pague tarifas en nombre de otra cuenta.Esto viola la regla que solo accede a la cuenta del remitente durante la fase de verificación, por lo que se introduce un procesamiento especial para permitir el mecanismo del pagador y garantizar que esté seguro.

• Agregador: admite características de agregación de firma como la agregación BLS o la agregación basada en Snark.Esto es necesario para lograr la mayor eficiencia de datos en el resumen.

¿Qué investigación están disponibles?

Introducción al historial de resúmenes de la cuenta: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 (resumen de la cuenta de incrustación):https://eips.ethereum.org/eips/eip-7562

EIP-7701 (incrustación aa basada en EOF):https://eips.ethereum.org/eips/eip-7701

¿Cuáles son las cosas restantes que hacer y qué compensaciones hay?

La principal pregunta restante es cómo incorporar completamente la abstracción de la cuenta en el acuerdo.El EIP de abstracción de cuenta más popular es EIP-7701, que implementa la abstracción de la cuenta sobre el EOF.Una cuenta puede tener una sección de código separada para la verificación, y si la cuenta ha establecido la sección del Código, el código se ejecutará en el paso de verificación de la transacción de la cuenta.

Estructura de código EOF para la cuenta EIP-7701

Lo fascinante de este enfoque es que muestra claramente dos formas equivalentes de ver abstracciones de cuentas nativas:

• EIP-4337, pero como parte del protocolo

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

Si primero limitamos estrictamente la complejidad del ejecutable del código durante la verificación, sin permitir el acceso al estado externo, o incluso establecer el límite de gas demasiado bajo al principio para ser utilizado para aplicaciones resistentes a la cantidad cuántica o protegida por la privacidad, entonces esta es la seguridad del El método es muy obvio: simplemente reemplaza la verificación ECDSA con la ejecución del código EVM que requiere un tiempo similar.Sin embargo, con el tiempo, necesitamos relajar estas restricciones, ya que permite que las aplicaciones de protección de la privacidad funcionen sin repetidores y se resistan a Quantum.Para hacer esto, realmente necesitamos encontrar formas de resolver los riesgos de DOS de una manera más flexible sin la necesidad de pasos de verificación extremadamente simples.

La principal compensación parece ser «tomar algo con lo que menos personas están satisfechas lo antes posible» en lugar de «esperar más y tal vez obtener una solución más ideal».El enfoque ideal podría ser algún tipo de enfoque mixto.Un enfoque híbrido es tomar algunos casos de uso como guía más rápido y dejar más tiempo para abordar otros.Otro enfoque es implementar primero una versión abstracta más ambiciosa de la cuenta en L2.Sin embargo, esto tiene el desafío de que para un equipo de L2 dispuesto a trabajar duro para adoptar la propuesta, deben asegurarse de que L1 y/u otros L2 adoptarán algo compatible más adelante.

Otra aplicación que debemos considerar explícitamente es la cuenta del almacén de claves, que almacena el estado asociado con la cuenta en L1 o L2 dedicado, pero puede usarse en L1 y cualquier L2 compatible.Hacer esto de manera efectiva puede requerir que L2 admite códigos de operación como L1SLoad o RemotestaticCall, aunque también requiere una implementación de abstracto de cuenta en L2 para admitirlo.

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

Las listas incluidas requieren soporte para las transacciones abstractas de la cuenta.De hecho, los requisitos para incluir listas son en última instancia muy similares a los de los grupos de memoria descentralizados, aunque la flexibilidad de incluir listas es ligeramente mayor.Además, idealmente, las implementaciones de resumen de la cuenta deben coordinarse en L1 y L2 tanto como sea posible.Si en el futuro esperamos que la mayoría de los usuarios usen el resumen del almacén de claves, entonces el diseño de abstracción de la cuenta debe tener esto en cuenta.

Mejoras EIP-1559

¿Qué problemas resuelve?

EIP-1559 se lanzó en Ethereum en 2021 y mejoró significativamente el tiempo de inclusión promedio de bloqueo.

Sin embargo, la implementación actual de EIP-1559 no es perfecta de varias maneras:

• La fórmula es ligeramente defectuosa: en lugar de apuntar al 50% de los bloques, se dirige a ~ 50-53% de los bloques completos en función de la varianza (esto está relacionado con lo que los matemáticos llaman la «desigualdad de AM-GM»);

• No se ajusta lo suficientemente rápido en condiciones extremas.

La fórmula utilizada más tarde para blobs (EIP-4844) fue claramente diseñada para resolver el primer problema y, en general, fue más conciso.Ni EIP-1559 ni EIP-4844 intentaron resolver el segundo problema.Por lo tanto, el status quo es un estado confuso de abandono a mitad de camino que involucra dos mecanismos diferentes, e incluso uno es que ambos necesitan una mejora con el tiempo.

Además, el precio de recursos de Ethereum tiene otras debilidades que no están relacionadas con EIP-1559, pero pueden resolverse ajustando EIP-1559.Un problema importante es la diferencia entre el escenario promedio y el peor de los casos: el precio de los recursos en Ethereum debe establecerse para poder manejar el peor de los casos, es decir, todo el gas de un bloque consume un recurso, pero el uso promedio es mucho más bajo de esta manera, la ineficiencia es causada.

¿qué es?¿Cómo funciona?

La solución a estos problemas de ineficiencia es el gas multidimensional: establecer diferentes precios y restricciones en diferentes recursos.Este concepto es técnicamente independiente de EIP-1559, pero EIP-1559 lo hace más fácil: sin EIP-1559, el embalaje óptimo de bloques con múltiples restricciones de recursos es un complejo problema de mochilero multidimensional.Con EIP-1559, la mayoría de los bloques no están completamente cargados en ningún recurso, por lo que un algoritmo simple de «aceptar cualquier cosa que paga lo suficiente» es suficiente.

Tenemos gas multidimensional para la ejecución y blobs hoy;

EIP-7706 introduce una nueva dimensión de gas a los datos de llamadas.Al mismo tiempo, también resuelve los defectos matemáticos de EIP-1559 al simplificar el mecanismo de gas multidimensional al hacer que los tres tipos de gases pertenezcan a un marco (estilo EIP-4844).

EIP-7623 es una solución más precisa para los problemas de recursos promedio y peor de los casos, que limita más estrictamente los datos de llamadas máximas sin introducir dimensiones completamente nuevas.

Otra dirección es resolver el problema de la tasa de actualización y encontrar un algoritmo de cálculo de tarifas básicas más rápidas mientras se conserva los invariantes clave introducidos por el mecanismo EIP-4844 (es decir, el uso promedio está completamente cerca del objetivo a largo plazo).

¿Qué investigación están disponibles?

EIP-1559 Preguntas frecuentes:https://notes.ethereum.org/@vbuterin/eip-1559-faq

Análisis empírico EIP-1559:>https://dl.acm.org/doi/10.1145/3548606.3559341

Mejoras recomendadas para permitir ajustes rápidos:https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/transaction_fees_on_a_honeymoon_ethereums_eip_1559_one_month_later.pdf

EIP-4844 Preguntas frecuentes, sección sobre el mecanismo de tarifa básica:https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#how-does-the-exponential-eip-1559-blob-fee-adjustmentism-work

EIP-7706:https://eips.ethereum.org/eips/eip-7706

EIP-7623:https://eips.ethereum.org/eips/eip-7623

Gas multidimensional:https://vitalik.eth.limo/general/2024/05/09/multidim.html

¿Cuáles son las cosas restantes que hacer y qué compensaciones hay?

Hay dos compensaciones principales para gas multidimensional:

• Aumenta la complejidad del protocolo

• Aumenta la complejidad del mejor algoritmo requerido para llenar los bloques a la capacidad

La complejidad del protocolo es un problema relativamente pequeño para CallData, pero un problema mayor para las dimensiones de gas «dentro del EVM» (como la lectura y la escritura de almacenamiento).El problema es que no es solo el usuario que establece límites de gas: los contratos también establecen restricciones al llamar a otros contratos.Y ahora, la única forma en que establecen restricciones es unidimensional.

Una manera fácil de eliminar este problema es hacer que el gas multidimensional esté disponible solo 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 EOF deben pagar todo tipo de tarifas de gas al realizar operaciones de almacenamiento (por ejemplo, si Sload gasta el 0.03% del límite de gas de acceso de almacenamiento de bloques, los usuarios no se cobrarán al 0.03% del límite de gas para la ejecución)

Hacer más investigaciones sobre gas multidimensional ayudará a comprender las 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 en gran medida el uso de algunos recursos de «peor de los casos», reduciendo así la presión para optimizar el rendimiento para admitir árboles binarios basados ​​en el hash rígido, por ejemplo.Establecer un objetivo difícil para el crecimiento del tamaño del estado facilitará que los desarrolladores de clientes planifiquen y estimen sus necesidades futuras.

Como se mencionó anteriormente, debido a que el EOF es de gas no observable, las versiones multidimensionales más extremas del gas son más fáciles de implementar.

Función de retraso verificada (VDF)

¿Qué problemas resuelve?

Hoy, Ethereum utiliza aleatoriedad basada en Randao para seleccionar propuestas.El principio de funcionamiento de la aleatoriedad basada en Randao es exigir a cada propositor que revele los secretos que prometieron de antemano y mezclar cada secreto revelado en la aleatoriedad.Por lo tanto, cada proponente tiene un «derecho de manipulación de 1 bits»: pueden cambiar la aleatoriedad al no aparecer (a un precio).Esto es razonable para el proponente, ya que pocas personas pueden darse dos nuevas oportunidades de propuestas al renunciar a una.Pero para aplicaciones en cadena que requieren aleatoriedad, esto no es posible.Idealmente, encontraríamos una fuente más fuerte de aleatoriedad.

¿qué es?¿Cómo funciona?

Una función de retraso verificable es una función que solo se puede calcular en orden y no puede acelerarse por paralelización.Un ejemplo simple es repetir hash: calcular i: x = hash (x) en el rango (10 ** 9).La salida se demuestra por corrección de gruñidos y puede usarse como un valor aleatorio.La idea es que la entrada se seleccione en función de la información disponible en el tiempo T, mientras que la salida no está clara en el tiempo T: solo estará disponible en algún momento después de T después de que alguien haya ejecutado completamente el cálculo.Debido a que cualquiera puede ejecutar el cálculo, es imposible ocultar los resultados y, por lo tanto, no tiene capacidad para manipular los resultados.

El riesgo principal de la función de retraso verificable es la optimización inesperada: alguien descubrió cómo ejecutar la función a un ritmo mucho más rápido de lo esperado, lo que les permite manipular la información que revelan en el momento T en función de la producción futura.La optimización inesperada puede ocurrir de dos maneras:

• Aceleración de hardware: alguien ha hecho un ASIC cuyo bucle computacional se ejecuta mucho más rápido que el hardware existente.

• Paralelización inesperada: alguien ha encontrado una manera de ejecutar la función más rápido a través de la paralelización, incluso si lleva más de 100 veces el recurso.

La tarea de crear un VDF exitoso es evitar ambos problemas mientras sigue siendo eficiente y práctico (por ejemplo, un problema con los enfoques basados ​​en hash es que Snark en tiempo real demuestra estar requerido por hardware).La aceleración de hardware a menudo se resuelve al permitir que los actores de interés público creen y distribuyan razonablemente cerca de los ASIC óptimos para los VDF.

¿Qué investigación están disponibles?

vdfresearch.org:https://vdfresearch.org/

Pensamientos sobre los ataques a los VDF utilizados en Ethereum en 2018:https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365

Ataque a Minroot (un VDF propuesto): «https://inria.hal.science/hal-04320126/file/minrootanálisis2023.pdf

¿Cuáles son las cosas restantes que hacer y qué compensaciones hay?

En la actualidad, no hay una estructura VDF que satisfaga completamente todas las necesidades de los investigadores de Ethereum.Se necesita más trabajo para encontrar tales características.Si lo tenemos, la compensación principal es si se incluye: una simple compensación entre la funcionalidad y la complejidad del protocolo y los riesgos de seguridad.Si creemos que VDF es seguro, pero en última instancia insegura, la seguridad se degradará a la hipótesis de Randao (manipulación de 1 bit por atacante) o peor, de acuerdo con cómo se implementa.Entonces, incluso si VDF está roto, romperá el protocolo, pero romperá la aplicación o cualquier característica nueva del protocolo que se basa en gran medida en él.

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

VDF es un componente relativamente independiente del Protocolo Ethereum, pero además de mejorar la seguridad de la elección del propuesta, también se puede utilizar para (i) aplicaciones en cadena que dependen de la aleatoriedad, así como potencialmente (ii) de memoria cifrada Pools.

Una cosa para recordar es que, dada la incertidumbre del hardware, habrá alguna «brecha» entre generar salida VDF y requerir salida.Esto significa que la información estará disponible antes de varios bloques.Esto puede ser un costo aceptable, pero debe considerarse en el diseño de la selección de comité o finalidad de la ranura única, etc.

Confusión y firma única: el futuro de la criptografía

¿Qué problemas resuelve?

Una de las publicaciones más famosas de Nick Saab fue un artículo de 1997 sobre «Acuerdo de Dios».En este artículo, señala que las aplicaciones de varias partes a menudo dependen de «terceros de confianza» para administrar las interacciones.En su opinión, el papel de la criptografía es crear un tercero de confianza simulado para hacer el mismo trabajo sin requerir confianza en un participante en particular.

«Protocolo matemáticamente de confianza», cuadro dibujado por Nick Szabo

Hasta ahora, solo podemos abordar parcialmente este ideal.Si todo lo que necesitamos es una computadora virtual transparente donde los datos y la computación no se pueden apagar, censurar o manipular, pero la privacidad no es el objetivo, entonces Blockchain puede hacerlo, aunque con una escalabilidad limitada.Si la privacidad es un objetivo, hasta hace poco solo podíamos desarrollar algunos protocolos específicos para aplicaciones específicas: firmas digitales para la autenticación básica, firmas de anillo para formularios anónimos originales y firmas de anillo vinculables, cifrado basado en la identidad (implementar un cifrado más conveniente bajo supuestos específicos emisores), firmas ciegas para efectivo electrónico de Chaumian, etc.Este enfoque requiere mucho trabajo para hacer para cada nueva aplicación.

En la década de 2010, vimos por primera vez un enfoque diferente y más poderoso basado en el cifrado programable.En lugar de crear un nuevo protocolo para cada nueva aplicación, podemos agregar garantías de cifrado a cualquier programa utilizando nuevos protocolos poderosos (especialmente ZK-Snark).ZK-Snark permite a los usuarios probar cualquier declaración de los datos que poseen: probar (i) fácil de verificar, y (ii) no se revela datos que no sean más que la declaración en sí.Este es un gran avance para la privacidad y la escalabilidad, y lo comparo con el efecto del transformador en la inteligencia artificial.Miles de personas tienen un año de trabajo de aplicación específico reemplazado repentinamente por una solución universal que puede resolver una gama sorprendentemente amplia de problemas con solo enchufar.

Pero ZK-Snark es solo el primero de tres primitivas universales igualmente extremadamente poderosas.Estos protocolos son tan poderosos que cuando pienso en ellos me recuerdan a un conjunto de cartas extremadamente poderoso en Yu-Gi-Oh, un juego de cartas y un programa de televisión que jugué de manera a menudo y veo: la carta de Dios Egipcio.Las tarjetas de Dios egipcio son tres cartas extremadamente poderosas, y según la leyenda, hacerlas puede ser fatal y tan poderosa que no se les permite usarse en duelos.Del mismo modo, en la criptografía, tenemos tres protocolos de Dios egipcio:

¿qué es?¿Cómo funciona?

ZK-Snark es uno de los tres protocolos que ya tenemos y ha alcanzado un alto nivel de madurez.En los últimos cinco años, ZK-Snark ha hecho un gran progreso en la prueba de la velocidad y la amistad del desarrollador y se ha convertido en la piedra angular de las políticas de escalabilidad y privacidad de Ethereum.Pero ZK-Snark tiene una limitación importante: debe conocer los datos para probarlo.Cada estado en la aplicación ZK-Snark debe tener un «propietario» que debe estar presente para aprobar cualquier lectura o escritura.

El segundo protocolo no tiene esta limitación, a saber, el cifrado totalmente homomórfico (FHE).FHE le permite realizar cualquier cálculo sobre datos cifrados sin verlo.Esto le permite realizar cálculos de los datos del usuario para beneficiar a los usuarios mientras mantiene los datos y los algoritmos privados.También le permite expandir sistemas de votación como Maci para garantías de seguridad y privacidad casi perfectas.Durante mucho tiempo se ha considerado demasiado ineficiente para ser práctico, pero ahora finalmente se ha vuelto lo suficientemente eficiente como para que estamos comenzando a ver aplicaciones.

Cursive es una aplicación que utiliza tanto la computación como la FHE para el descubrimiento de privacidad.

Pero el FHE también tiene sus limitaciones: cualquier tecnología basada en FHE todavía requiere que alguien mantenga la clave de descifrado.Esta puede ser una configuración distribuida M-OF-N, incluso puede agregar una defensa de la capa 2 usando Tee, pero eso sigue siendo una limitación.

Esto nos da un tercer protocolo, que es más poderoso que los otros dos protocolos combinados: confusión indistinguible.Si bien está lejos de ser maduro, a partir de 2020, hemos desarrollado protocolos teóricamente efectivos basados ​​en supuestos de seguridad estándar y recientemente comenzamos a implementar el trabajo.La ofuscación indistinguible le permite crear un «programa cifrado» que realice cálculos arbitrarios, de modo que todos los detalles internos del programa estén ocultos.Para dar un ejemplo simple, puede poner la clave privada en un programa ofuscado que solo le permite usarlo para firmar números primos y distribuir el programa a otros.Pueden usar el programa para firmar cualquier número primo, pero no pueden recuperar la clave.Pero hace mucho más que eso: se puede usar con hash, y se puede usar para implementar cualquier otro cifrado primitivo y aún más.

Lo único que un programa ofuscado no puede hacer es evitar ser copiado.Pero para esto, hay algo más poderoso a punto de venir, aunque depende de que todos tengan una computadora cuántica: una firma cuántica única.

Usando la ofuscación y las firmas únicas, podemos construir terceros casi perfectos y confiables.Lo único que no podemos hacer con la tecnología de cifrado es lo que aún necesitamos hacer blockchain, lo que es garantizar la resistencia a la censura.Estas tecnologías no solo nos permiten hacer que Ethereum sea más seguro, sino que también cree aplicaciones más poderosas además de Ethereum.

Para comprender cómo cada una de estas primitivas agrega funcionalidad adicional, veamos un ejemplo clave: la votación.La votación es una pregunta fascinante porque tiene muchos atributos de seguridad difíciles que deben cumplirse, incluida una verificabilidad y privacidad muy sólidas.Si bien los protocolos de votación con una fuerte seguridad han existido durante décadas, hagamos que el problema sea más difícil al decir que queremos un diseño que pueda manejar protocolos de votación arbitrarios: votación secundaria, financiamiento secundario limitado, emparejado, financiamiento secundario de clúster, etc.Es decir, queremos que el paso del «recuento de recuento» sea un procedimiento arbitrario.

• Primero, digamos que pusimos el voto públicamente en la cadena de bloques.Esto nos proporciona verificabilidad pública (cualquiera puede verificar que el resultado final sea correcto, incluidas las reglas de conteo de votos y las reglas de elegibilidad) y la resistencia a la censura (que no puede evitar que las personas voten).Pero no tenemos privacidad.

• Luego, agregamos Zk-Snark.Ahora, tenemos privacidad: cada voto es anónimo, al tiempo que garantiza que solo los votantes autorizados puedan votar, y que cada votante solo puede votar una vez.

• Ahora, agregamos el mecanismo MACI.La votación está encriptada a la clave de descifrado del servidor central.El servidor central debe ejecutar el proceso de conteo de votos, incluida la descarga de los votos duplicados y la publicación de ZK-Snark que demuestra la respuesta.Esto conserva la garantía anterior (¡incluso si el servidor hace trampa!), Pero si el servidor es honesto, agrega una garantía de resistencia obligatoria: el usuario no puede probar cómo votó, incluso si lo desean.Esto se debe a que, si bien los usuarios pueden probar qué voto votaron, no pueden probar que no hicieron otro voto para cancelar el voto.Esto evita el soborno y otros ataques.

• Ejecutamos el conteo internamente en FHE y luego lo desciframos realizando cálculos de descifrado de umbral N/2 de N.Esto hace que la resistencia obligatoria garantice que sea N/2 de N, no 1 de 1.

• Obsuscamos el proceso de conteo y diseñamos el proceso de ofuscación para que pueda dar la salida solo si está con licencia, ya sea comprobante de consenso de blockchain, o a través de una cierta cantidad de prueba de trabajo, o ambos.Esto hace que la resistencia obligatoria garantizada sea casi perfecta: en el caso del consenso de blockchain, necesita el 51% de los validadores para coludirla, mientras que en el caso de la prueba de trabajo, incluso si todos coluden, vuelva a ejecutar con un subconjunto diferente el conteo de votos de los votantes En un intento por extraer votantes individuales, también será muy costoso.Incluso podemos hacer que el programa ajuste el resultado final ligeramente al azar, lo que hace que sea más difícil extraer el comportamiento de los votantes individuales.

• Agregamos una firma única, una primitiva que se basa en la computación cuántica, permitiendo que las firmas se usen solo para firmar un mensaje de algún tipo a la vez.Esto hace que la verdadera perfección antidepresión garantizada.

La ofuscación indiscriminatoria también puede permitir otras aplicaciones poderosas.Por ejemplo:

• DAO, subastas en cadena y otras aplicaciones con cualquier estado secreto interno.

• Configuración de confianza que son verdaderamente universales: alguien puede crear un programa difuso con una clave, y puede ejecutar cualquier programa y proporcionar salida, poner hash (clave, programa) en el programa como entrada.Dado dicho programa, cualquiera puede poner el programa en sí mismo, combinar la clave existente del programa con la suya y extender la configuración en el proceso.Esto se puede utilizar para generar una configuración de 1 de N de confianza para cualquier protocolo.

• ZK-Snarks, su verificación es solo firma.Implementar esto es simple: hay una configuración confiable en la que alguien crea un programa difuso que solo firmará el mensaje con la clave si es una SNARK válida de ZK.

• Grupo de memoria cifrado.Las transacciones criptográficas se han vuelto tan fáciles que solo serán descifradas si se producen ciertos eventos en la cadena en el futuro.Esto incluso puede incluir una ejecución exitosa de VDF.

Con firmas únicas, podemos proteger la cadena de bloques de los ataques de inversión final del 51%, aunque aún pueden existir ataques de censura.Las primitivas similares a las firmas únicas pueden implementar monedas cuánticas y resolver el problema de pago dual sin blockchain, aunque muchas aplicaciones más complejas aún requieren blockchain.

Si estas primitivas son lo suficientemente eficientes, la mayoría de las aplicaciones en el mundo pueden descentralizarse.El principal cuello de botella radica en verificar la corrección de la implementación.

¿Qué investigación están disponibles?

El Acuerdo de Ofusión Indiscriminatoria de 2021:https://eprint.iacr.org/2021/1334.pdf

Confusión cómo ayudar a Ethereum:https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

La primera construcción de firma conocida de una sola vez:https://eprint.iacr.org/2020/107.pdf

Intentos ofuscados de implementar (1):https://mediatum.ub.tum.de/doc/1246288/1246288.pdf

Intentos ofuscados de implementar (2):https://github.com/sorasuegami/iomaker/tree/main

¿Cuáles son las cosas restantes que hacer y qué compensaciones hay?

Todavía hay muchas cosas que hacer.La confusión indiscriminatoria es muy inmadura, y las construcciones candidatas son millones de veces más lentas (o incluso más) que las aplicaciones.La confusión indiscriminatoria es conocida por el tiempo de ejecución del tiempo polinomial «en teoría», pero lleva más tiempo correr en la práctica que la vida útil del universo.Los protocolos más nuevos hacen que los tiempos de lanzamiento sean menos extremos, pero la sobrecarga sigue siendo demasiado alta para su uso regular: un implementador espera que el tiempo de ejecución sea un año.

Las computadoras cuánticas ni siquiera existen: todas las construcciones que puede leer en Internet hoy son prototipos que no pueden realizar ningún cálculo de más de 4 bits, o no son realmente computadoras cuánticas, y aunque pueden contener piezas cuánticas, No pueden ejecutar realmente el cálculo del significado, como el algoritmo Shor o el algoritmo de Grover.Recientemente, hay signos de que las computadoras cuánticas «reales» ya no están tan lejos.Sin embargo, incluso si las computadoras cuánticas «reales» salen pronto, los días en que las personas comunes tienen computadoras cuánticas en sus computadoras portátiles o teléfonos pueden ser décadas más tarde que las instituciones poderosas que obtienen computadoras cuánticas que pueden descifrar los códigos de curva elíptica.

Una compensación clave por la confusión indiscriminatoria es la suposición de seguridad.Hay más diseños radicales que utilizan suposiciones extrañas.Estos generalmente tienen tiempos de ejecución más realistas, pero a veces se rompen suposiciones extrañas.Con el tiempo, eventualmente podemos tener suficiente conocimiento del patio para hacer suposiciones que no se romperán.Sin embargo, este camino es más peligroso.Un enfoque más conservador es atenerse a los protocolos donde la seguridad puede probarse como suposiciones «estándar», pero esto puede significar que nos llevará más tiempo obtener un protocolo que funciona lo suficientemente rápido.

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

La tecnología de cifrado extremadamente poderosa podría cambiar el juego.Por ejemplo:

• Si obtenemos ZK-Snark, que es tan fácil de verificar como una firma, es posible que no necesitemos ningún protocolo de agregación;

• Las firmas únicas pueden significar una prueba más segura de acuerdo de participación.

• Muchos protocolos de privacidad complejos pueden ser reemplazados por «solo» EVM protegidos por la privacidad.

• Los grupos de memoria cifrados se vuelven más fáciles de implementar.

Primero, los beneficios ocurrirán en la capa de aplicación, porque Ethereum L1 esencialmente necesita ser conservador en los supuestos de seguridad.Sin embargo, incluso usar la capa de aplicación solo puede cambiar el juego, al igual que el advenimiento de ZK-Snark.