Autor: Vitalik, fundador de Ethereum Traducción: Golden Finance 0xjs;

Desde el comienzo del proyecto Ethereum, hubo una fuerte filosofía de tratar de mantener el núcleo de Ethereum lo más simple posible y hacer todo lo posible construyendo protocolos sobre él. En el espacio blockchain, a menudo se piensa que el debate entre “ejecutar en L1” versus “centrarse en L2” implica principalmente escalar, pero de hecho, existen problemas similares al atender muchos tipos de necesidades de los usuarios de Ethereum: Números Intercambio de activos, privacidad, nombres de usuario, criptografía avanzada, seguridad de cuentas, resistencia a la censura, protección frontal y más. Sin embargo, recientemente ha habido un creciente interés por parte de algunos en escribir de manera discreta y formal más de estas características en el protocolo central de Ethereum.

Este artículo explorará algunos de los razonamientos filosóficos detrás de las primeras ideas de minimizar el protocolo Ethereum, así como algunos de mis pensamientos más recientes sobre estas ideas. El objetivo es construir gradualmente un marco que identifique mejor los objetivos que pueden valer la pena considerar para formar ciertas características del protocolo.

Filosofía de minimización del acuerdo temprano

Al principio de la historia de "Ethereum 2.0" (como se llamaba en ese momento), había un fuerte deseo de crear un protocolo limpio, simple y hermoso que hiciera el menor trabajo posible por sí solo y dejara casi todo en manos del usuarios construir sobre él. Idealmente, el protocolo sería solo una máquina virtual y validar un bloque solo requeriría una llamada a la máquina virtual.

Una reconstrucción muy aproximada de un diagrama de pizarra que Gavin Wood y yo hicimos a principios de 2015 cuando discutimos cómo sería Ethereum 2.0.

La "función de transición de estado" (la función que maneja los bloques) será simplemente una llamada a la máquina virtual, y toda la demás lógica se implementará a través de contratos: algunos contratos a nivel de sistema, pero principalmente contratos proporcionados por el usuario. Una característica muy interesante de este modelo es que incluso una bifurcación dura completa puede describirse como una única transacción para el contrato de procesamiento de bloques, que se aprobará a través de la gobernanza dentro o fuera de la cadena y luego se ejecutará con permisos actualizados.

Estas discusiones de 2015 se aplican específicamente a dos áreas que nos interesan: abstracción de cuentas y escalamiento. En el caso del escalado, la idea es intentar crear una forma de escalado que sea lo más abstracta posible para que parezca una extensión natural del diagrama anterior. Un contrato puede llamar a ciertos datos que no son almacenados por la mayoría de los nodos de Ethereum, y el protocolo lo detectará y resolverá la llamada a través de alguna funcionalidad de cálculo de escala muy general. Desde la perspectiva de la máquina virtual, la llamada irá a algún subsistema separado y luego, mágicamente, regresará algún tiempo después con la respuesta correcta.

Esta forma de pensar se exploró brevemente, pero se abandonó rápidamente porque estábamos demasiado concentrados en verificar si era posible alguna forma de escalamiento de blockchain. Sin embargo, como veremos más adelante, la combinación de muestreo de disponibilidad de datos y ZK-EVM significa que un posible futuro para el escalamiento de Ethereum puede parecer sorprendentemente cercano a esta visión. Para la abstracción de cuentas, por otro lado, sabíamos desde el principio que algún tipo de implementación era posible e inmediatamente comenzamos a trabajar en cómo hacer que el punto de partida puro de "transacciones solo llamadas" se acerque lo más posible a la realidad.

Aquí, hay una gran cantidad de código que ocurre entre y después del código que maneja la transacción y realiza la llamada EVM subyacente a la dirección de envío. ¿Cómo reducimos este código lo más cerca posible de cero?

Una de las tareas principales en un fragmento de código es validar_transacción (estado, tx), que incluye verificar que el nonce y la firma de la transacción sean correctos. El objetivo real de la abstracción de cuentas desde el principio fue permitir a los usuarios reemplazar el incremento básico de nonce y la verificación ECDSA con su propia lógica de verificación, facilitando a los usuarios el uso de cosas como la recuperación social y las billeteras de firmas múltiples. Por lo tanto, remodelar apply_transaction para que sea una simple llamada EVM no se trata solo de una tarea de "limpiar el código", sino de mover la lógica al código de la cuenta del usuario para darles la flexibilidad que necesitan;

Sin embargo, la insistencia en que apply_transaction contenga la menor lógica formal posible finalmente introdujo una serie de desafíos. Para entender por qué, profundicemos en una de las primeras propuestas de abstracción de cuentas, EIP 86:

especificación

Si block.number >= METROPOLIS_FORK_BLKNUM, entonces: 1. Si la firma de la transacción es (0, 0, 0) (es decir, v = r = s = 0), entonces se considera válida y la dirección del remitente se establece en 2 ** 160 - 1. 2. Establezca la dirección de cualquier contrato creado mediante la creación de una transacción en sha3 (0 + código de inicialización) % 2 ** 160, donde + representa la conexión, reemplace la fórmula de dirección anterior sha3(rlp.encode([remitente, nonce])) 3. Cree un nuevo código de operación, 0xfb, CREATE_P2SH, este código de operación establecerá la dirección de creación en sha3(remitente + código de inicio )%2**160. Si ya existe un contrato en esa dirección, falla y devuelve 0, como si el código de inicialización se hubiera quedado sin gas.

Básicamente, si configura la firma en (0, 0, 0), entonces la transacción efectivamente se convierte en "solo una llamada". La cuenta misma será responsable de tener el código para analizar transacciones, extraer y verificar firmas y nonces, y pagar tarifas. Haga clic aquí para ver una versión anterior de este código. Haga clic aquí para ver el código de validación_transacción que reemplazará este código de cuenta. En un momento, apply_transaction simplemente se redujo a Es solo un proceso llamado por EVM. En otras palabras, el protocolo de Ethereum realiza la verificación de transacciones, dejando la lógica de transacción específica al propio código de cuenta de los usuarios para brindar flexibilidad.

Sin embargo, tratar de hacer que apply_transaction contenga la menor lógica formal posible terminó presentando una serie de desafíos. Para entender por qué, veamos en detalle una de las primeras propuestas de abstracción de cuentas, EIP 86.

Tenga en cuenta que los mineros necesitan desarrollar una estrategia para aceptar estas transacciones. Esta estrategia debe ser muy selectiva, de lo contrario pueden aceptar transacciones que no pagan nada (por el código de validación_transacción que será reemplazado por el código previo a la cuenta), o incluso transacciones que no tienen ningún efecto (por ejemplo, porque la transacción ya está incluida). , Por lo que el nonce ya no es válido). Una forma sencilla de hacer esto es incluir en la lista blanca el código hash de los códigos de cuenta a los que aceptan transacciones para enviar. Los códigos aprobados incluirán la lógica para pagar las tarifas de transacción de los mineros. Sin embargo, esto puede ser demasiado restrictivo; una estrategia más relajada pero aún efectiva es aceptar cualquier código que se ajuste al mismo formato general descrito anteriormente, consumir solo una cantidad limitada de gas para realizar comprobaciones de firmas y nonce, y garantizar que las tarifas de transacción se mantengan. pagarse a los mineros. Otra estrategia es, además de otros métodos, intentar procesar cualquier transacción que solicite menos de 250.000 gas y solo incluirla si el saldo del minero aumenta adecuadamente después de ejecutar la transacción.

Si EIP-86 se incorporara tal cual, reduciría la complejidad del EVM pero, a un gran costo, aumentaría la complejidad de otras partes de la pila de Ethereum, lo que requeriría esencialmente escribir exactamente el mismo código en otro lugar e introducir posibilidades completamente nuevas y extrañas. por ejemplo, la misma transacción con el mismo hash podría aparecer varias veces en la cadena, sin mencionar el problema de invalidación múltiple.

Múltiples problemas de vencimiento en la abstracción de cuentas. Una transacción incluida en la cadena podría invalidar miles de otras transacciones en el mempool, dejando al mempool vulnerable a una inundación barata.

La abstracción de cuentas evolucionó gradualmente a partir de ahí. EIP-86 se convirtió en EIP-208, que luego se convirtió en esta publicación en ethresear.ch sobre "Compensaciones en propuestas de abstracción de cuentas", y luego, medio año después, en esta publicación en ethresear.ch. Al final, todo esto resultó en EIP-2938, que en realidad es bastante factible.

Sin embargo, EIP-2938 no es mínimo. El PEI incluye:

  • un nuevo tipo de transacción

  • Tres nuevas variables globales de alcance de transacción

  • Dos nuevos códigos de operación, incluido el muy torpe código de operación PAYGAS, manejan las verificaciones del precio y el límite del gas, actúan como puntos de interrupción de ejecución de EVM y también almacenan temporalmente ETH para pagos de tarifas.

  • Un conjunto complejo de estrategias de minería y reproducción, incluida una serie de códigos de operación prohibidos durante la fase de verificación de las transacciones.

Para impulsar la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum que estaban ocupados optimizando el cliente Ethereum e implementando fusiones, EIP-2938 finalmente se rediseñó en un ERC-4337 completamente fuera de protocolo.

ERC-4337. ¡Se basa completamente en llamadas EVM para hacer todo!

Debido a que es un ERC, no requiere un hard fork y técnicamente está "fuera del protocolo Ethereum". Entonces… ¿problema resuelto? Bueno, resulta que aún no está del todo resuelto. La hoja de ruta actual a mediano plazo para ERC-4337 en realidad implica eventualmente la transición de gran parte de ERC-4337 a una serie de características de protocolo, lo cual es un ejemplo útil de por qué se está considerando esta ruta.

Solidificación de capa de protocolo ERC-4337

Se han discutido algunas razones clave para la eventual introducción de ERC-4337 en el protocolo:

  • Eficiencia del gas: cualquier operación realizada dentro del EVM genera cierto grado de sobrecarga de la máquina virtual, incluidas ineficiencias cuando se utilizan costosas funciones de gas, como ranuras de almacenamiento. Actualmente, estas ineficiencias adicionales suman al menos ~20.000 gases y, a menudo, más. Insertar estos componentes en el protocolo es la forma más sencilla de eliminar estos problemas.

  • Riesgo de error de código: si el "contrato de punto de entrada" de ERC-4337 tiene suficientes errores, es posible que se eliminen todos los fondos de todas las billeteras compatibles con ERC-4337. Al reemplazar los contratos con funciones de protocolo, se crea una responsabilidad implícita de corregir errores de código y eliminar el riesgo para los fondos de los usuarios.

  • Admite códigos de operación EVM como tx.origin. El propio ERC-4337 hace que tx.origin devuelva la dirección enviada por un "paquete" que empaqueta un conjunto de acciones del usuario en una transacción. La abstracción de cuenta nativa puede resolver este problema haciendo que tx.origin apunte a la cuenta que realmente envía la transacción, haciendo que funcione de la misma manera que EOA.

  • Resistencia a la censura: En el caso de PBS, un desafío es facilitar la censura de transacciones individuales. En un mundo donde cada transacción es visible para el protocolo Ethereum, este problema se mitiga en gran medida con las listas de inclusión, que permiten al proponente especificar en casi todos los casos qué debe incluirse en los dos siguientes espacios de la lista de transacciones. Sin embargo, el ERC-4337 fuera de protocolo envuelve las "operaciones del usuario" dentro de una sola transacción, haciendo que las operaciones del usuario sean invisibles para el protocolo Ethereum, por lo tanto, la lista de inclusión proporcionada por el protocolo Ethereum no proporcionará resistencia a la censura para las operaciones del usuario ERC-4337. Formalizar ERC-4337 y convertir las operaciones de los usuarios en un tipo de transacción "oficial" resolvería este problema.

Vale la pena estudiar más a fondo la cuestión de la eficiencia del gas. En su forma actual, ERC-4337 es significativamente más caro que las transacciones "básicas" de Ethereum: una transacción cuesta 21.000 gas, mientras que ERC-4337 cuesta alrededor de 42.000 gas. La documentación enumera algunas de estas razones:

  • Hay que pagar una serie de costos de lectura/escritura de almacenamiento separados, que para EOA se agrupan en un pago único de 21,000 gas:

  • Editar ranura de almacenamiento que contiene pubkey+nonce (~5000)

  • Costo de datos de llamadas de operación de usuario (~4500, reducido a ~2500 con compresión)

  • RECUPERACIÓN ECRE (~3000)

  • Calienta la billetera (~2600)

  • Calentar cuentas de destinatarios (~2600)

  • Transferir ETH a la cuenta del destinatario (~9000)

  • Editar almacenamiento para cubrir tarifas (~5000)

  • Acceda a la ranura de almacenamiento que contiene el agente (~2100), luego al propio agente (~2600)

  • Además de los costos de lectura/escritura de almacenamiento mencionados anteriormente, el contrato debe realizar "lógica de negocios" (desempaquetar la operación de usuario, aplicar hash, mezclar variables, etc.), mientras que las transacciones EOA son manejadas "gratis" por el protocolo Ethereum.

  • Se requiere gas para pagar los registros (EOA no emite registros)

  • Costo único de creación de contrato (costo base ~32 000, el código en el proxy agrega 200 gas por byte, más 20 000 gas para configurar la dirección del proxy)

En teoría, debería ser posible manipular el sistema de costos de gas EVM para que el costo dentro del protocolo y el costo extra del protocolo del acceso al almacenamiento coincidan. No hay ninguna razón por la cual la transferencia de ETH cueste 9000 gas cuando otras operaciones de edición de almacenamiento son mucho más baratas; . De hecho, dos EIP relacionados con la próxima transición del árbol Verkle intentan hacer precisamente eso. Pero incluso si hacemos eso, hay una gran razón por la cual las características del protocolo formal serán inevitablemente mucho más baratas que el código EVM, sin importar cuán eficiente se vuelva el EVM: el código formalizado no necesita pagar gasolina por la precarga.

Una billetera ERC-4337 completamente funcional es enorme. Esta implementación, compilada y colocada en cadena, ocupa aproximadamente 12800 bytes. Por supuesto, podría implementar ese código masivo una vez y usar DELEGATECALL para permitir que cada billetera individual lo llame, pero el código aún tendría que ser accesible en cada bloque que lo use. Según el próximo EIP de costo de gas del árbol Verkle, 12800 bytes ocuparán 413 fragmentos, y para acceder a estos fragmentos será necesario pagar 2x WITNESS_BRANCH_COST (3800 gas en total) y 413x WITNESS_CHUNK_COST (82600 gas en total). Eso sin mencionar el punto de entrada ERC-4337 en sí, que tiene 23689 bytes en cadena en la versión 0.6.0 (la carga requiere ~158700 gas según las reglas EIP del árbol Verkle).

Esto genera un problema: el costo del gas para acceder realmente a este código debe distribuirse entre las transacciones de alguna manera. El enfoque utilizado actualmente por ERC-4337 no es muy bueno: la primera transacción del paquete absorbe el costo único de almacenamiento/lectura de código, lo que la hace significativamente más costosa que el resto de las transacciones. Hacer que estas bibliotecas compartidas de uso común formen parte del protocolo, accesibles para todos sin pagar una tarifa, es una solución a este problema.

¿Qué podemos aprender de este ejemplo sobre cuándo solidificarnos en protocolos de manera más general?

En este ejemplo, podemos aprender algunas lecciones sobre los principios más generales sobre cuándo resumir las cosas.

  • Es una buena idea trasladar la complejidad a los límites, especialmente cuando los costos de curado son altos. Esto se hace evidente en la hoja de ruta de "Abstracción de cuentas descentralizadas", ya que cargar el código de billetera estandarizado requiere 244,100 gas, mientras que la agregación (consulte mi charla de este verano para obtener más detalles) puede requerir cientos de miles de gas para la verificación de ZK-SNARK, más el Costo de verificación de prueba en cadena. Imponer estos costos a los usuarios es casi imposible, ya que esto introduciría muchas ineficiencias en el mercado, que pueden resolverse claramente haciendo que ciertas funciones sean accesibles a todos los usuarios sin costo como funciones de protocolo.

  • La respuesta colectiva de la comunidad a los errores de codificación. Si todos los usuarios o una amplia clase de usuarios utilizan un conjunto de fragmentos de código, a menudo es más razonable que la comunidad blockchain asuma la responsabilidad de corregir posibles errores a través de una bifurcación dura. ERC-4337 introduce una gran cantidad de código compartido globalmente y, a largo plazo, es mejor corregir errores en este código a través de una bifurcación dura en lugar de hacer que los usuarios pierdan grandes cantidades de ETH.

  • A veces, se pueden lograr formas de funcionalidad más poderosas aprovechando directamente el poder de un protocolo. Por ejemplo, la censura dentro del protocolo puede garantizar mejor la resistencia a la censura, pero para que las operaciones a nivel de usuario realmente se beneficien del protocolo, las operaciones individuales a nivel de usuario deben ser "legibles" para el protocolo. Otro ejemplo menos conocido es el diseño de prueba de participación de Ethereum de 2017 con abstracción autorizada, y esto se abandonó a favor de BLS para resumir, porque BLS admite mecanismos de "agregación" que deben implementarse en los niveles de protocolo y red, que can Hace que el procesamiento de una gran cantidad de firmas sea más eficiente.

Pero es importante recordar que incluso la abstracción de cuentas establecida en el protocolo sigue siendo un enorme "contrasistema" en relación con el status quo. Hoy en día, las transacciones de nivel superior de Ethereum solo pueden iniciarse mediante cuentas de propiedad externa (EOA), que se verifican mediante una única firma de curva elíptica secp256k1. La abstracción de la cuenta refleja esto y brinda a los usuarios la posibilidad de definir condiciones de validación. Entonces, en esta historia sobre la abstracción de cuentas, también vemos el mayor argumento en contra de la suspensión de actividades: la flexibilidad para satisfacer las diferentes necesidades de los usuarios.

Intentemos refinar aún más esta historia observando algunas de las características que recientemente se han considerado para su establecimiento. Prestaremos especial atención a: ZK-EVM, separación entre proponente y constructor, mempools privados, participaciones de liquidez y nueva precompilación.

Curado de ZK-EVM

Dirijamos nuestra atención a otro posible objetivo establecido en el protocolo Ethereum: los ZK-EVM. Actualmente, tenemos una gran cantidad de paquetes acumulativos de ZK que tienen que escribir código bastante similar para verificar bloques similares a Ethereum en la ejecución de ZK-SNARK. Existe un ecosistema bastante diverso de implementaciones independientes: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth y muchas más.

Una de las controversias recientes en el campo del EVM ZK-rollup tiene que ver con cómo lidiar con la posibilidad de errores en el código ZK. Actualmente, todos los sistemas en ejecución tienen algún tipo de mecanismo de "consejo de seguridad" que anula el sistema de certificación en caso de error. En un artículo del año pasado, intenté crear un marco estandarizado que alentaría a los proyectos a aclarar su nivel de confianza entre los sistemas de certificación y el Consejo de Seguridad, y avanzar hacia una reducción de la autoridad sobre el Consejo de Seguridad con el tiempo.

A mediano plazo, los rollups pueden depender de múltiples sistemas de certificación, y el Consejo de Seguridad sólo tendrá poder en el caso extremo en el que dos sistemas de certificación diferentes no estén de acuerdo entre sí.

Sin embargo, existe la sensación de que parte del trabajo es redundante. Ya tenemos la capa base de Ethereum, que tiene un EVM, y ya tenemos un mecanismo de trabajo para manejar errores en la implementación: si hay un error, el cliente con el error se actualizará para corregir el error y la cadena continuará. . Desde la perspectiva del cliente con el error, desde la perspectiva de las múltiples implementaciones de la comunidad Ethereum y el consenso social fuera de la cadena, el bloqueo parece estar finalizado, pero al menos no veremos a los usuarios perder fondos. Del mismo modo, si un paquete acumulativo solo quiere convertirse y seguir siendo equivalente a EVM, entonces cuando sus reglas internas ZK-EVM necesiten coincidir con la actualización de la capa base de Ethereum, no deberían implementar su propia gobernanza, sino que deberían construirse directamente sobre Ethereum. capa base Además de eso, esta capa base sabe cuándo actualizar y a qué nuevas reglas actualizar.

Dado que estos ZK-EVM L2 básicamente usan el mismo EVM que Ethereum, ¿no podemos de alguna manera convertir "verificar la ejecución de EVM en ZK" en una función de protocolo? En el caso de errores y actualizaciones, ¿podemos manejar esto aplicando el consenso social de Ethereum, lo mismo que ya hacemos para la ejecución de EVM de la capa base?

Este es un tema importante y desafiante. Hay algunas sutilezas:

1. Esperamos seguir siendo compatibles con la filosofía multicliente de Ethereum. Esto significa que queremos permitir que diferentes clientes utilicen diferentes sistemas de prueba. Esto, a su vez, significa que para cualquier ejecución de EVM que utilice un sistema ZK-SNARK para pruebas, queremos asegurarnos de que los datos subyacentes estén disponibles para que se puedan generar pruebas para otros sistemas ZK-SNARK.

2. Aunque la tecnología aún no está madura, es posible que deseemos realizar una auditoría. En la práctica, esto significa exactamente lo mismo: si se prueba alguna ejecución, queremos que los datos subyacentes estén disponibles para que los usuarios y desarrolladores puedan inspeccionarlos si algo sale mal.

3. Necesitamos tiempos de prueba más rápidos para que si se genera un tipo de prueba, se puedan generar otros tipos de pruebas rápidamente para que otros clientes puedan verificarlas. Este problema podría resolverse creando una precompilación que tenga una respuesta asincrónica después de un cierto período de tiempo (por ejemplo, 3 horas), pero esto agrega complejidad.

4. Esperamos admitir no sólo copias de EVM, sino también "casi-EVM". Innovar a nivel de ejecución y extender EVM es parte del atractivo de L2. Si la VM para una L2 determinada es solo ligeramente diferente de la EVM, sería bueno si la VM de L2 usara el protocolo nativo ZK-EVM para las mismas partes que la EVM, y solo confiara en su propio código para manejar las diferentes partes de . Esto se puede lograr diseñando la precompilación ZK-EVM de modo que permita a la persona que llama especificar un conjunto de códigos de operación o campos de bits o listas de direcciones que son manejadas por una tabla proporcionada externamente, en lugar del propio EVM. También podemos personalizar el coste del gas hasta cierto punto.

Un posible tema de discordia con la disponibilidad de datos cuando se utiliza ZK-EVM nativo es el estado. Los ZK-EVM serán más eficientes en cuanto a datos si no necesitan transportar datos "testigos". Es decir, si se han leído o escrito datos específicos en algún bloque anterior, simplemente podemos asumir que el probador tiene acceso a ellos y no tenemos que volver a revelarlos. Esto va más allá de no recargar el almacenamiento y el código; resulta que si un paquete acumulativo comprime los datos correctamente para que la compresión tenga estado, esto ahorrará hasta 3 veces más datos en comparación con la compresión sin estado.

Esto significa que para la precompilación ZK-EVM tenemos dos opciones:

1. La precompilación requiere que todos los datos estén disponibles en el mismo bloque. Esto significa que el probador puede ser sin estado, pero también significa que usar un paquete acumulativo de ZK precompilado es más costoso que usar un paquete acumulativo de código personalizado.

2. La precompilación permite punteros a datos utilizados o generados en ejecuciones anteriores. Esto permite que el resumen de ZK sea casi óptimo, pero es más complejo e introduce nuevos tipos de estados que el probador debe almacenar.

¿Qué lecciones podemos sacar de esto? Existe un argumento bastante bueno de que la verificación ZK-EVM podría establecerse de alguna manera: el rollup ya está creando su propia versión personalizada, y lo que parece incorrecto es la voluntad de Ethereum de poner el peso de sus múltiples implementaciones y el consenso social fuera de la cadena después del EVM. Se ejecuta L1, L2, que hace exactamente el mismo trabajo, tiene que implementar un dispositivo complejo que involucra al consejo de seguridad. Pero, por otro lado, hay un gran inconveniente en los detalles: existen diferentes versiones del ZK-EVM establecido, con diferentes costos y beneficios. Con estado versus sin estado es solo la punta del iceberg; intentar admitir "casi-EVM" con código personalizado probado por otros sistemas puede revelar un espacio de diseño más grande. Por lo tanto, establecer ZK-EVM tiene tanto promesas como desafíos.

Separación solidificada entre proponente y constructor (ePBS)

El auge de MEV ha convertido la producción de bloques en un ejercicio de economía de escala, con jugadores inteligentes capaces de generar bloques que generan más ingresos que los algoritmos predeterminados que simplemente monitorean las transacciones en el mempool y las incluyen. Hasta ahora, la comunidad Ethereum ha intentado abordar este problema utilizando un esquema de separación entre proponente y constructor fuera de protocolo como MEV-Boost, que permite a los validadores regulares ("proponentes") subcontratar la construcción de bloques a actores dedicados ("Constructor").

Sin embargo, MEV-Boost impone supuestos de confianza a una nueva clase de participantes, llamados relevos. En los últimos dos años, ha habido muchas propuestas para crear un "PBS solidificado". ¿Cuáles son los beneficios de hacer esto? En este caso, la respuesta es muy simple: un PBS construido usando directamente los poderes del protocolo es más fuerte en términos de supuestos de confianza (en el sentido de que los supuestos de confianza son más débiles) que un PBS construido sin ellos. Esto es similar al caso de establecer un oráculo de precios en un protocolo, aunque en ese caso hay un poderoso contraargumento.

Establecer un grupo de memoria privado

Cuando un usuario envía una transacción, la transacción inmediatamente se vuelve pública y visible para todos, incluso antes de ser incluida en la cadena. Esto deja a los usuarios de muchas aplicaciones vulnerables a ataques económicos como el front-running: si un usuario realiza una transacción grande en Uniswap, un atacante podría colocar una transacción delante de él, aumentando el precio de su compra y recolectando las ganancias del arbitraje.

Recientemente, ha habido una serie de proyectos dedicados a la creación de "mempools privados" (o "criptomempools") que permiten que las transacciones de los usuarios permanezcan cifradas hasta que sean aceptadas irreversiblemente en un bloque.

Sin embargo, este esquema requiere un tipo específico de cifrado: para evitar que los usuarios inunden el sistema y ejecuten el proceso de descifrado antes de que la transacción se acepte de manera irreversible, el cifrado debe estar habilitado para descifrar automáticamente cuando la transacción se acepte de manera irreversible. .

Para implementar esta forma de cifrado, existen varias técnicas diferentes, con diferentes compensaciones, bien descritas por Jon Charbonneau en un artículo (y en este vídeo y presentación de diapositivas):

  • Cifre a un operador centralizado como Flashbots Protect.

  • Cifrado con bloqueo de tiempo, una forma de cifrado que cualquier persona puede descifrar después de una cierta cantidad de pasos computacionales secuenciales, que no se pueden paralelizar.

  • Cifrado de umbral, confía en un comité mayoritario para descifrar los datos. Consulte el concepto de cadena de balizas con contraventanas para ver una propuesta concreta.

  • Hardware confiable como SGX.

Desafortunadamente, todos estos tienen varias debilidades. Por razones obvias, el operador del centro no acepta incluir esto en el acuerdo. El cifrado de bloqueo de tiempo tradicional es demasiado costoso para ejecutar miles de transacciones en un grupo de memoria público. Una primitiva más poderosa llamada cifrado retardado permite descifrar eficientemente una cierta cantidad de mensajes, pero es difícil de implementar en la práctica y, en ocasiones, todavía se descubren ataques a compilaciones existentes. Al igual que con las funciones hash, es posible que necesitemos muchos más años de investigación y análisis antes de que el cifrado retrasado esté lo suficientemente maduro. La criptografía de umbral requiere confiar en que un comité mayoritario no coludirá, lo cual es inaceptable en un entorno donde la colusión puede ser indetectable (a diferencia de un ataque del 51% en el que se sabe inmediatamente quién participó). SGX introduce una dependencia para un único fabricante de confianza.

Si bien para cada solución hay un subconjunto de usuarios dispuestos a confiar en ella, actualmente ninguna solución es lo suficientemente confiable como para ser aceptada en el Nivel 1. Por lo tanto, hasta que al menos o a menos que mejore el cifrado retardado o se produzcan otros avances tecnológicos, incorporar el front-running al Nivel 1 parece una propuesta difícil, incluso si es una característica muy valiosa para la que han surgido muchas soluciones de aplicaciones.

Hipoteca Líquida Solidificada

Una necesidad común entre los usuarios de Ethereum DeFi es poder utilizar su ETH tanto para apostar como como garantía en otras aplicaciones. Otra solicitud común es simplemente por conveniencia: los usuarios quieren poder realizar apuestas sin la complejidad de ejecutar un nodo y estar siempre en línea (además de proteger sus claves de apuestas que ahora están en línea).

Con diferencia, la "interfaz" de participación más simple que satisface ambas necesidades es un token ERC20: convierta su ETH en "ETH de participación", manténgalo y luego conviértalo nuevamente. De hecho, han surgido proveedores de apuestas de liquidez como Lido y Rocketpool para hacer precisamente eso. Sin embargo, hay algunos mecanismos de centralización naturales en juego con la apuesta de liquidez: las personas naturalmente apuestan por la versión más grande de ETH porque es la más familiar y líquida (y mejor respaldada por aplicaciones, y aplicaciones que a su vez la favorecen porque es más familiar). ya que es del que la mayoría de usuarios han oído hablar).

Cada versión de ETH apostada debe tener un mecanismo para determinar quién puede convertirse en el operador del nodo base. No puede ser ilimitado porque los atacantes se unirán y utilizarán los fondos de los usuarios para amplificar sus ataques. Actualmente, los dos primeros son Lido, que tiene un operador de nodo DAO incluido en la lista blanca, y Rocket Pool, que permite a cualquiera ejecutar un nodo depositando 8 ETH (es decir, 1/4 del capital) como depósito. Ambos métodos conllevan riesgos diferentes: el método Rocket Pool permite a un atacante lanzar un ataque del 51% en la red y obligar a los usuarios a pagar la mayor parte del coste. Con el enfoque DAO, si un único token apostado se volviera dominante, eso daría como resultado un único dispositivo de gobernanza potencialmente atacable que controlaría una gran parte de todos los validadores de Ethereum. Para protocolos como Lido, han implementado salvaguardias, pero una capa de defensa puede no ser suficiente.

A corto plazo, una opción es alentar socialmente a los participantes del ecosistema a utilizar un conjunto diverso de proveedores de garantías líquidas para reducir la posibilidad de que cualquiera de ellos se vuelva demasiado grande como para convertirse en un riesgo sistémico. Sin embargo, a largo plazo, este es un equilibrio precario y existen peligros al depender demasiado de la presión moral para resolver los problemas. Surge una pregunta natural: ¿tiene sentido solidificar alguna funcionalidad en el protocolo para reducir la concentración de garantía líquida?

Aquí la pregunta clave es: ¿Qué función de protocolo se solidifica? El problema de simplemente crear un token fungible "ETH colateralizado" dentro de un protocolo es que tiene que haber solidificado la gobernanza global de Ethereum para elegir quién ejecuta los nodos, o es abierto, convirtiéndolo en una herramienta para los atacantes.

Una idea interesante es el artículo de Dankrad Feist sobre el extremismo de la garantía de liquidez. En primer lugar, tenemos que aceptar el hecho de que si Ethereum es atacado por el 51%, sólo el 5% del ETH atacante puede ser castigado. Esta es una compensación razonable; con más de 26 millones de ETH ahora apostados, 1/3 del costo de un ataque (~8 millones de ETH) es completamente excesivo, especialmente considerando cuántos ataques "fuera de modelo" hay que pueden realizarse. implementado con mucho menos costo. De hecho, ya se han explorado compensaciones similares en la propuesta del "Súper Comité" para implementar la finalidad de un solo turno.

Si aceptamos que solo se reducirá el 5 % del ETH de ataque, entonces más del 90 % del ETH apostado estará exento de corte, por lo que el 90 % del ETH apostado se puede colocar en un token de stake líquido fungible en el protocolo. que luego puede ser utilizado por otras aplicaciones.

Este camino es interesante. Pero aún queda una pregunta: ¿qué será exactamente lo que se solidificará? Rocket Pool funciona de manera muy similar: cada operador de nodo aporta algo de capital y los participantes líquidos aportan el resto. Simplemente podemos ajustar algunas constantes para limitar la penalización máxima a 2 ETH, y el rETH existente de Rocket Pool quedará libre de riesgos.

Con simples ajustes de protocolo podemos hacer algunas cosas inteligentes. Por ejemplo, imaginemos que queremos un sistema en el que haya dos "niveles" de participación: operadores de nodos (altos requisitos de garantía) y depositantes (sin requisitos mínimos, pueden unirse y salir en cualquier momento), pero aún queremos dar depósitos por A Un comité de personas muestreado al azar otorga poderes tales como recomendar una lista de transacciones que deben incluirse (por razones anticensura), controlar la selección de bifurcaciones durante fugas de inactividad o exigir bloques firmados. Esto se puede lograr adaptando el mecanismo en el protocolo mediante el cual cada validador debe proporcionar (i) una clave de participación regular y (ii) una dirección ETH a la que cada ranura puede llamar para generar la clave de participación secundaria. El protocolo otorgará poder a ambas claves, pero el mecanismo para seleccionar la segunda clave en cada ranura puede dejarse en manos del protocolo del grupo de participación. Puede que aún sea mejor solidificar algo directamente, pero vale la pena señalar que existe este espacio de diseño de "solidificar algunas cosas y dejar otras al usuario".

Solidificar más precompilación

Los contratos precompilados (o "contratos precompilados") son contratos de Ethereum que implementan operaciones criptográficas complejas de forma nativa en el código del cliente, en lugar de en el código de contrato inteligente de EVM. La precompilación es un compromiso adoptado en los primeros días de Ethereum: dado que la sobrecarga de la VM es demasiado grande para ciertos tipos de código muy complejo y altamente especializado, podemos implementar en código nativo algunas características que son útiles para tipos importantes de aplicaciones. operaciones clave para hacerlas más rápidas. Hoy en día, esto incluye básicamente algunas funciones hash específicas y operaciones de curva elíptica.

Actualmente hay un impulso para agregar la precompilación de secp256r1, una curva elíptica ligeramente diferente a la secp256k1 utilizada para cuentas básicas de Ethereum, ya que es ampliamente compatible con módulos de hardware confiables, por lo que su uso generalizado puede mejorar la seguridad de la billetera. En los últimos años, se han realizado esfuerzos para promover la precompilación de funciones como BLS-12-377, BW6-761 y el emparejamiento generalizado.

El contraargumento a estas solicitudes de agregar más precompiladores es que muchos de los precompiladores agregados previamente (por ejemplo, RIPEMD y BLAKE) terminaron usándose menos de lo previsto, y deberíamos aprender de esto. En lugar de agregar más precompilación para operaciones específicas, probablemente deberíamos centrarnos en un enfoque más suave basado en ideas como EVM-MAX y la propuesta SIMD de suspensión pero siempre activa, que permitiría que las implementaciones de EVM funcionen de manera más amplia y más económica. Incluso podría ser posible eliminar y reemplazar precompilaciones existentes, pero rara vez utilizadas, con implementaciones de código EVM de la misma funcionalidad. Dicho esto, es posible que todavía haya algunas operaciones criptográficas específicas que sea valioso acelerar, lo que justifica agregarlas como precompiladas.

¿Qué podemos aprender de todo esto?

El deseo de tener la menor solidificación posible es comprensible y bueno; surge de la tradición filosófica de Unix de crear software mínimo que pueda adaptarse fácilmente a las diferentes necesidades de sus usuarios, evitando la maldición del software excesivo. Sin embargo, las cadenas de bloques no son sistemas operativos de computación personal; son sistemas sociales. Esto significa que existen razones para incluir ciertas características en el protocolo que van más allá de las consideraciones puramente personales mencionadas anteriormente.

En muchos casos, estos otros ejemplos reintroducen lecciones similares observadas en la abstracción de cuentas. Pero también se han aprendido algunas lecciones nuevas:

  • Ayude a evitar riesgos de centralización en otras áreas de la pila. A menudo, mantener el protocolo base simple y simple lleva la complejidad al ecosistema fuera del protocolo. Desde la perspectiva de la filosofía Unix, esto está bien. A veces, sin embargo, el riesgo de un ecosistema fuera de un protocolo es que puede centralizarse, a menudo (pero no sólo) debido a los altos costos fijos. La solidificación a veces puede reducir la centralización real.

  • Demasiada solidificación aumentará excesivamente la carga de confianza y gobernanza del protocolo. Este es el tema de un artículo anterior sobre "No sobrecargues el consenso de Ethereum" (consulte el artículo de traducción anterior de Golden Finance): si se solidifica una característica específica, debilitará el modelo de confianza y hará que Ethereum en su conjunto sea más "subjetivo". , Esto debilita así la neutralidad confiable de Ethereum. En estos casos, es mejor mantener esa funcionalidad específica como mecanismo encima de Ethereum en lugar de intentar llevarla al propio Ethereum. En este caso, los grupos de memoria cifrada son el mejor ejemplo de algo que puede ser demasiado difícil de solidificar, al menos hasta que la tecnología de cifrado mejore.

  • Demasiado curado puede complicar demasiado el protocolo. La complejidad del protocolo es un riesgo sistémico y agregar demasiadas funciones a un protocolo aumenta ese riesgo. La precompilación es el mejor ejemplo de esto.

  • La solidificación puede ser contraproducente a largo plazo porque las necesidades de los usuarios son impredecibles. Una característica que mucha gente piensa que es importante y que será utilizada por muchos usuarios puede que en realidad no se utilice mucho en la práctica.

Además, la garantía de liquidez, ZK-EVM y los casos precompilados muestran una posibilidad intermedia: solidificación mínima viable. En lugar de solidificar una característica completa, solidifique partes específicas que aborden los desafíos clave de implementar esa característica sin ser demasiado subjetivo o estrecho de miras. Esto incluye:

  • En lugar de solidificar todo el sistema de apuestas de liquidez, las reglas de penalización deberían cambiarse para hacer más factibles las apuestas de liquidez sin confianza.

  • En lugar de reforzar más la precompilación, refuerce EVM-MAX y/o SIMD para simplificar la implementación eficiente de una clase más amplia de operaciones.

  • En lugar de solidificar todo el concepto de Rollups, podemos simplemente solidificar la verificación EVM.

Podemos ampliar el diagrama anterior en este artículo de la siguiente manera:

A veces incluso podría tener sentido eliminar la solidificación de algo. Un ejemplo es la eliminación de precompiladores que se utilizan con poca frecuencia. Como soporte compatible con versiones posteriores para usuarios existentes, este mecanismo puede ser sorprendentemente similar al que elimina la precompilación: uno de ellos es EIP-5003, que permitirá a los EOA convertir sus cuentas en el lugar para tener el mismo (o mejor). ) contrato de función.

Qué funciones deben incorporarse al protocolo y cuáles deben dejarse para otras capas del ecosistema es una solución de compromiso compleja que deberíamos esperar seguir mejorando a medida que comprendamos las necesidades de los usuarios y nuestro conjunto de ideas y tecnologías disponibles. evolucionar con el tiempo.