Pregunta del día: ¿Debería Ethereum aceptar incluir más cosas en el protocolo?

Autor: Vitalik Buterin

Compilado por: Nian Yin Si Tang, Planet Daily

Desde el comienzo del proyecto Ethereum, ha existido una fuerte filosofía de tratar de hacer que el núcleo de Ethereum sea lo más simple posible y lograrlo en la medida de lo posible mediante la construcción de protocolos sobre él. En el espacio blockchain, a menudo se piensa que el debate entre “construir en L1” versus “centrarse en L2” tiene que ver principalmente con el escalamiento, pero de hecho, existen problemas similares al satisfacer las necesidades de múltiples usuarios de Ethereum: intercambio de activos digitales, privacidad. , nombres de usuario, cifrado avanzado, seguridad de cuentas, resistencia a la censura, protección frontal y más. Sin embargo, recientemente ha habido algunos intentos cautelosos de incorporar más de estas características en el protocolo central de Ethereum.

Este artículo profundizará en algunos de los razonamientos filosóficos detrás de la filosofía original de la encapsulación mínima, así como en algunas formas recientes de pensar sobre estas ideas. El objetivo será comenzar a construir un marco para identificar mejor posibles objetivos en los que valga la pena considerar encapsular cierta funcionalidad.

Una filosofía temprana sobre el minimalismo protocolario.

En la historia temprana de lo que entonces se conocía como "Ethereum 2.0", había un fuerte deseo de crear un protocolo limpio, simple y hermoso que intentara construir lo menos posible sobre sí mismo y dejara casi todo ese trabajo a los usuarios. Idealmente, el protocolo es solo una máquina virtual y validar un bloque es solo una llamada a la máquina virtual.

Esta es una reconstrucción aproximada del diagrama de pizarra que yo y Gavin Gavin Wood dibujaron a principios de 2015 cuando hablaba sobre cómo sería Ethereum 2.0.

La "función de transición de estado" (la función que maneja el bloque) será solo una única llamada de VM, y toda la demás lógica ocurrirá a través de contratos: algunos contratos a nivel de sistema, pero en su mayoría 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 al contrato del procesador de bloques, que será aprobada por la gobernanza dentro o fuera de la cadena y luego se actualizará el permiso para ejecutarse.

Estas discusiones en 2015 se aplican específicamente a dos áreas que consideramos: abstracción de cuentas y escalamiento. En el caso del escalado, la idea es intentar crear una forma de escalamiento máximamente abstracta que parezca una extensión natural del diagrama anterior. Los contratos pueden llamar a datos que no están almacenados en la mayoría de los nodos de Ethereum, y el protocolo lo detectará y resolverá la llamada a través de alguna funcionalidad informática extendida muy general. Desde la perspectiva de la máquina virtual, la llamada irá a algún subsistema separado y luego, mágicamente, devolverá la respuesta correcta algún tiempo después.

Exploramos brevemente esta idea, pero la abandonamos rápidamente porque estábamos demasiado concentrados en demostrar que era posible cualquier tipo de escalamiento de blockchain. Aunque, 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 en realidad parece muy cercano a esta visión. Con la abstracción de cuentas, por otro lado, sabíamos desde el principio que algún tipo de implementación era posible, por lo que la investigación inmediatamente comenzó a tratar de hacer algo lo más cercano posible al punto de partida puro de "una transacción es solo una llamada".

Hay una gran cantidad de código repetitivo entre el procesamiento de la transacción y la realización de la llamada EVM subyacente real desde la dirección del remitente, y más código repetitivo después de eso. ¿Cómo reducimos este código lo más cerca posible de cero?

Uno de los códigos principales aquí es validar_transacción (estado, tx), que es responsable de verificar si el nonce y la firma de la transacción son correctos. El verdadero objetivo de la abstracción de cuentas desde el principio ha sido permitir a los usuarios reemplazar la verificación básica no incremental y la verificación ECDSA con su propia lógica de verificación, de modo que los usuarios puedan utilizar más fácilmente funciones como la recuperación social y las billeteras con múltiples firmas. Por lo tanto, encontrar una manera de rediseñar apply_transaction en una simple llamada EVM no es solo una tarea de "limpiar el código por limpiar el código", sino que se trata de mover la lógica al código de la cuenta del usuario, brindarles a los usuarios la flexibilidad que necesitan; necesidad.

Sin embargo, insistir en que apply_transaction contenga la menor lógica fija posible terminó creando muchos desafíos. Podemos mirar una de las primeras propuestas de abstracción de cuentas, EIP-86.

Si EIP-86 se incluyera tal cual, reduciría la complejidad del EVM a costa de aumentar enormemente la complejidad de otras partes de la pila de Ethereum, lo que requeriría esencialmente escribir el mismo código en otro lugar, además de introducir un Nueva clase de rareza. Por ejemplo, la misma transacción con el mismo valor hash puede aparecer varias veces en la cadena, sin mencionar el problema de invalidación múltiple.

Múltiples problemas de invalidación en la abstracción de cuentas. Una transacción incluida en la cadena podría invalidar miles de otras transacciones en el mempool, lo que facilitaría que el mempool se llenara de forma económica.

Desde entonces, la abstracción de cuentas ha evolucionado por etapas. EIP-86 luego se convirtió en EIP-208 y finalmente en el práctico EIP-2938.

Sin embargo, EIP-2938 es todo menos minimalista. Su contenido incluye:

  • 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 para manejar las verificaciones del precio y el límite del gas, como puntos de interrupción de ejecución de EVM y para almacenar temporalmente ETH para el pago único de tarifas.

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

En un esfuerzo por lograr la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum (que se centraban en optimizar los clientes de Ethereum e implementar fusiones), EIP-2938 finalmente se rediseñó como ERC-4337, que estaba completamente fuera de protocolo.

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

Debido a que se trata de un ERC, no requiere una bifurcación dura y técnicamente existe "fuera del protocolo Ethereum". Entonces… ¿problema resuelto? Resulta que no es el caso. La actual hoja de ruta a mediano plazo de ERC-4337 en realidad implica eventualmente la transición de grandes partes de ERC-4337 a una serie de características de protocolo, lo cual es un ejemplo útil de orientación sobre por qué se debe considerar esta ruta.

Paquete ERC-4337

Se discuten varias razones clave para volver a incluir 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 funciones que consumen mucho gas, como las ranuras de almacenamiento. Actualmente, estas ineficiencias adicionales suman al menos 20.000 gas, si no más. Incluir 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" ERC-4337 tiene un error suficientemente terrible, todas las billeteras compatibles con ERC-4337 podrían ver todos sus fondos agotados. Reemplazar los contratos con funcionalidad dentro del protocolo crea una obligación implícita de corregir errores de código mediante bifurcaciones duras, eliminando así el riesgo de que los usuarios se queden sin fondos.

Admite códigos de operación EVM como txt.origin. El propio ERC-4337 hace que txt.origin devuelva la dirección de un "paquete" que empaqueta un conjunto de acciones del usuario en una transacción. La abstracción de cuenta nativa resuelve este problema al hacer que txt.origin apunte a la cuenta real que envía la transacción, lo que hace que se comporte igual que EOA.

Resistencia a la censura: Uno de los desafíos de la separación entre proponente y constructor es que resulta más fácil revisar transacciones individuales. En un mundo donde el protocolo Ethereum puede identificar transacciones individuales, este problema puede aliviarse en gran medida mediante listas de inclusión, que permiten a los proponentes especificar una lista de transacciones que deben incluirse en los dos espacios siguientes en casi todos los casos. Sin embargo, ERC-4337 fuera del protocolo encapsula las "operaciones del usuario" en una sola transacción, lo que hace que las operaciones del usuario sean opacas para el protocolo Ethereum, por lo tanto, la lista de inclusión proporcionada por el protocolo Ethereum no podrá brindar resistencia a la censura al usuario de ERC-4337; operaciones. Envolver ERC-4337 y hacer que la acción del usuario sea un tipo de transacción "adecuada" resolvería este problema.

Vale la pena mencionar que 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.

En teoría, debería ser posible ajustar el sistema de costos de gas EVM hasta que el costo dentro del protocolo y el costo de acceder al almacenamiento fuera del protocolo coincidan; no hay razón para necesitar gastar 9000 gas para transferir ETH cuando se editan otros tipos de almacenamiento; Las operaciones son más baratas. De hecho, dos EIP relacionados con la próxima transformación del árbol Verkle intentan hacer precisamente eso. Pero incluso si hacemos esto, hay una razón obvia por la que no importa cuán eficiente sea el EVM, las funciones del protocolo encapsulado serán inevitablemente mucho más baratas que el código EVM: el código encapsulado no necesita pagar gasolina por la precarga.

Una billetera ERC-4337 completamente funcional es grande, y esta implementación compilada y puesta en cadena ocupa alrededor de 12,800 bytes. Por supuesto, puede implementar este código una vez y usar DELEGATECALL para permitir que cada billetera individual lo llame, pero aún necesitará acceder al código en cada bloque donde se use. Según el EIP de costo de gas del árbol de Verkle, 12,800 bytes formarán 413 fragmentos, y para acceder a estos fragmentos será necesario pagar 2 veces el costo de la rama testigo (un total de 3,800 gas) y 413 veces el costo del fragmento testigo (un total de 82,600 gas). Esto ni siquiera comienza a mencionar el punto de entrada ERC-4337 en sí, que en la versión 0.6.0 tiene 23,689 bytes en la cadena (aproximadamente 158,700 gases para cargar según las reglas EIP del árbol Verkle).

Esto genera un problema: el costo del gas para acceder realmente a estos códigos debe amortizarse entre transacciones de alguna manera. El enfoque actual utilizado por ERC-4337 no es muy bueno: la primera transacción del paquete consume un costo único de almacenamiento/lectura de código, lo que la hace mucho más costosa que otras transacciones. La encapsulación dentro del protocolo permitirá que estas bibliotecas públicas compartidas formen parte del protocolo y sean de libre acceso para todos.

¿Qué podemos aprender de este ejemplo y cuándo debería practicarse la encapsulación de manera más general?

En este ejemplo vemos algunas razones diferentes para encapsular abstracciones de cuentas en protocolos.

Los enfoques basados ​​en el mercado que “llevan la complejidad al límite” tienen más probabilidades de fracasar cuando los costos fijos son altos. De hecho, la hoja de ruta de abstracción de cuentas a largo plazo parece tener muchos costos fijos por bloque. 244,100 gas para cargar el código de billetera estandarizado es una cosa; pero la agregación puede agregar cientos de miles de gas para la verificación ZK-SNARK, así como el costo en cadena de la verificación de prueba. No hay forma de cobrar a los usuarios por estos costos sin introducir ineficiencias masivas en el mercado, y convertir algunas de estas características en características de protocolo que sean de libre acceso para todos resolvería muy bien este problema.

Respuesta de toda la comunidad a errores de código. Si todos los usuarios, o una gama muy amplia de usuarios, utilizan algún fragmento de código, a menudo tiene más sentido que la comunidad blockchain asuma la responsabilidad de un hard fork para corregir cualquier error que surja. ERC-4337 introduce una gran cantidad de código compartido globalmente. A largo plazo, sin duda es más razonable corregir errores en el código mediante un hard fork que hacer que los usuarios pierdan una gran cantidad de ETH.

A veces, se puede implementar una forma más sólida del protocolo aprovechando directamente su funcionalidad. El ejemplo clave aquí son las características resistentes a la censura dentro del protocolo, como las listas de inclusión: las listas de inclusión dentro del protocolo pueden garantizar la resistencia a la censura mejor que los métodos fuera del protocolo para que las operaciones a nivel de usuario realmente se beneficien del protocolo. incluir listas, usuarios individuales Las operaciones de nivel requieren "legibilidad" del protocolo. Otro ejemplo menos conocido es que el diseño de prueba de participación de Ethereum de la era de 2017 tenía una abstracción de cuenta de las claves de participación, que se abandonó en favor de BLS encapsulado porque BLS admitía un mecanismo de "agregación" que tenía que implementarse en el protocolo y niveles de red, esto puede hacer que el procesamiento de un gran número de firmas sea más eficiente.

Pero es importante recordar que incluso encapsular abstracciones de cuentas dentro de protocolos sigue siendo una enorme “desencapsulación” en comparación con el status quo. Hoy en día, las transacciones de Ethereum de nivel superior solo pueden iniciarse desde cuentas de propiedad externa (EOA), que se verifican mediante una única firma de curva elíptica secp256k1. La abstracción de cuenta elimina esto y deja que el usuario las defina las condiciones de validación. Por lo tanto, en esta historia sobre la abstracción de cuentas, también vemos la principal razón en contra de la encapsulación: la flexibilidad para satisfacer las necesidades de diferentes usuarios.

Profundicemos más en la historia observando algunos otros ejemplos de características que recientemente se han considerado para su encapsulación. Prestaremos especial atención a: ZK-EVM, separación entre proponente y constructor, grupos de memoria privados, participación de liquidez y nueva precompilación.

PaqueteZK-EVM

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

Una controversia reciente en el campo EVM ZK-rollup se relaciona con cómo lidiar con los errores que pueden aparecer en el código ZK. Actualmente, todos estos sistemas en ejecución tienen algún tipo de mecanismo de "consejo de seguridad" que controla el sistema de certificación en caso de un error. El año pasado, traté de crear un marco estandarizado que alentaría a los proyectos a aclarar cuánto confían en el sistema de certificación y cuánto confían en el Consejo de Seguridad, y reducir gradualmente su autoridad sobre esa organización con el tiempo.

En el mediano plazo, la consolidación puede depender de múltiples sistemas de certificación, y el Consejo de Seguridad sólo tendrá poder en casos extremos en los que dos sistemas de certificación diferentes diverjan.

Sin embargo, existe la sensación de que parte de este trabajo parece redundante. Ya tenemos una capa base de Ethereum, tiene un EVM y ya tenemos un mecanismo de trabajo para manejar errores en la implementación: si hay un error, el cliente se actualizará para solucionarlo y la cadena seguirá funcionando. Desde la perspectiva del cliente con errores, parece que los bloques que se han finalizado ya no se confirmarán, pero al menos no veremos a los usuarios perder fondos. Del mismo modo, si los rollups solo quieren mantener la función equivalente de EVM, entonces necesitan implementar su propia gobernanza para cambiar constantemente sus reglas internas ZK-EVM para que coincidan con las actualizaciones de la capa base de Ethereum, lo cual parece incorrecto porque, en última instancia, están construidos sobre la base. de la propia capa base de Ethereum, sabe cuándo actualizar y según qué nuevas reglas.

Dado que estos ZK-EVM L2 básicamente usan exactamente el mismo EVM que Ethereum, ¿podemos de alguna manera incorporar "verificar la ejecución de EVM en ZK" en la funcionalidad del protocolo y manejar excepciones aplicando el consenso social de Ethereum, como errores y actualizaciones, como ya lo hacemos para el ¿La propia ejecución de EVM de la capa base?

Este es un tema importante y desafiante.

Un posible tema de debate sobre la disponibilidad de datos en ZK-EVM nativo es el estado. Los ZK-EVM serían mucho más eficientes en cuanto a datos si no necesitaran transportar datos "testigos". Es decir, si un dato en particular ha sido leído o escrito en algún bloque anterior, podemos simplemente asumir que el proveedor tiene acceso a él y no tiene que volver a ponerlo a disposición. No se trata solo de no recargar el almacenamiento y el código; está demostrado que si un paquete acumulativo comprime los datos correctamente, la compresión con estado puede 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 este paquete acumulativo de ZK precompilado es mucho más costoso que usar un paquete acumulativo de código personalizado.

2. La precompilación permite que los punteros apunten a datos utilizados o generados por ejecuciones anteriores. Esto hace que el resumen de ZK sea casi óptimo, pero es más complejo e introduce un nuevo estado que debe ser almacenado por el probador.

¿Qué podemos aprender de esto? Hay una buena razón para encapsular la verificación ZK-EVM de alguna manera: el paquete acumulativo ya está creando su propia versión personalizada y Ethereum está dispuesto a implementar EVM en L1 con el peso de sus múltiples implementaciones y consenso social fuera de la cadena, esto se siente mal. , pero L2 haciendo exactamente el mismo trabajo tendría que implementar un dispositivo complejo que involucrara al Consejo de Seguridad. Pero, por otro lado, hay un gran problema en los detalles: existen diferentes versiones de ZK-EVM y tienen diferentes costos y beneficios. La distinción entre con estado y sin estado sólo toca la superficie; los intentos de admitir código personalizado "casi EVM" que ha sido probado por otros sistemas pueden exponer un espacio de diseño más grande. Por lo tanto, empaquetar ZK-EVM trae esperanzas y desafíos.

Separación de proponente y constructor de encapsulación (ePBS)

El auge de MEV hace que la producción de bloques sea una actividad económica a gran escala, con actores sofisticados capaces de producir bloques que generan más ingresos que el algoritmo predeterminado, que simplemente observa un mempool de transacciones y las contiene. Hasta ahora, la comunidad Ethereum ha intentado mejorar la experiencia de las herramientas existentes aumentando su funcionalidad y haciéndolas más robustas. BOOST es el token de utilidad nativo que se utiliza para desbloquear funciones premium y actualizables, votaciones futuras en eventos de gobernanza y procesamiento de pagos para funciones futuras del producto. Los próximos productos BOOST incluyen BoostSWAP, BoostFARM y BoostNFT. Estos productos innovadores mejorarán la infraestructura DeFi existente y ayudarán a expandir la comunidad de Internet descentralizada. BOOST Coin se lanzó el 9 de agosto de 2021 con mil millones de tokens en circulación. Actualmente, Boost se puede comercializar en Uniswap y pronto estará disponible en BoostSwap. Vea más soluciones a este problema, como la separación entre el proponente y el constructor fuera de protocolo, que permite a los validadores regulares ("proponentes") subcontratar la construcción de bloques a actores dedicados ("constructores") ").

Sin embargo, MEV-Boost hace suposiciones de confianza en una nueva clase de actores llamados retransmisiones. En los últimos dos años, ha habido muchas propuestas para crear un "PBS empaquetado". ¿Cuáles son los beneficios de hacer esto? En este caso, la respuesta es muy simple: un PBS construido utilizando directamente las características del protocolo es más poderoso (en el sentido de tener supuestos de confianza más débiles) que un PBS construido sin usarlas. Esto es similar al caso de encapsular oráculos de precios dentro de un protocolo, aunque en este caso existen fuertes objeciones.

Encapsular grupo de memoria privado

Cuando un usuario envía una transacción, ésta es inmediatamente pública y visible para todos, incluso antes de que se incluya en la cadena. Esto deja a los usuarios de muchas aplicaciones vulnerables a ataques económicos, como el front-running.

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

El problema, sin embargo, es que tal esquema requiere un tipo especial de cifrado: para evitar que los usuarios inunden el sistema y lo descifren primero, el cifrado debe descifrarse automáticamente después de que la transacción haya sido aceptada de manera irreversible.

Existen varias técnicas con diferentes compensaciones para implementar esta forma de cifrado. Jon Charbonneau lo describió bien una vez:

Cifrado para operadores centralizados como Flashbots Flashbots Flashbots es una empresa de investigación y desarrollo centrada en Miner Extractable Value (MEV), con el objetivo de mitigar las externalidades negativas y los riesgos existenciales que MEV aporta a las cadenas de bloques de contratos inteligentes. Ver más Proteger.

Cifrado de bloqueo de tiempo: cualquier persona puede descifrar esta forma de cifrado después de ciertos pasos de cálculo secuenciales y no se puede paralelizar;

El cifrado de umbral confía en un comité mayoritario honesto para descifrar los datos. Consulte el concepto de cadenas de balizas cerradas para obtener sugerencias específicas.

Hardware confiable como SGX.

Desafortunadamente, cada método de cifrado tiene diferentes debilidades. Si bien para cada solución hay un segmento de usuarios dispuestos a confiar en ella, ninguna solución es lo suficientemente confiable como para ser aceptada por la Capa 1. Por lo tanto, al menos hasta que se perfeccione el cifrado retardado o se logre algún otro avance tecnológico, encapsular la funcionalidad anti-comercio anticipado en la Capa 1 parece ser una propuesta difícil, incluso si es una característica lo suficientemente valiosa como para que hayan surgido muchas soluciones de aplicación.

Participación de liquidez encapsulada

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 apostar (y proteger las claves de participación en línea) sin la complejidad de ejecutar un nodo y mantenerlo siempre en línea.

Con diferencia, la "interfaz" de participación más simple que satisface ambas necesidades es simplemente un token ERC20: convierta su ETH en "ETH de participación", manténgalo y luego conviértalo nuevamente. De hecho, Lido Lido Lido es una solución de participación en un fondo de liquidez. Lido permite a los usuarios apostar en la cadena pública de PoS con rendimientos compuestos mientras participan en actividades en la cadena (como préstamos, comercio) sin depósitos mínimos ni mantenimiento de infraestructura. Actualmente es compatible con ETH2.0, Terra y Solana, y puede ampliarse a otras cadenas públicas de POS en el futuro. Ver más y Rocket Rocket Rocket (ROCKET) es una criptomoneda lanzada en 2021 que se ejecuta en la plataforma BNB Smart Chain (BEP20). Ver más Pool Pool apoya a organizaciones que permiten a la gente común monetizar y compartir sus datos Ver más Proveedores de participación de liquidez como Ya han comenzado a hacer esto. Sin embargo, existen algunos mecanismos de centralización naturales que funcionan con las apuestas de liquidez: las personas naturalmente pasarán a apostar la versión más grande de ETH porque es la más familiar y líquida.

Cada versión de ETH apostada debe tener algún mecanismo para determinar quién puede convertirse en el operador del nodo subyacente. No puede ser ilimitado porque entonces los atacantes se unirán y utilizarán los fondos de los usuarios para expandir sus ataques. Actualmente, los dos primeros son Lido y Rocket Pool Rocket Pool RocketPool es un servicio de infraestructura Ethereum PoS. Todas las personas y organizaciones que quieran ganar intereses en Ethereum mediante apuestas regulares pueden participar en apuestas utilizando la red descentralizada y operada por nodos de RocketPool. Ver más, el primero tiene operadores de nodos en la lista blanca de DAO y el segundo permite que cualquiera ejecute un nodo con un depósito de 8 ETH. Los dos métodos tienen riesgos diferentes: el método Rocket Pool permite a un atacante realizar un ataque del 51% en la red y obliga a los usuarios a pagar la mayor parte de los costos. En cuanto al método DAO, si un determinado token apostado se vuelve dominante, liderará; En resumen, un dispositivo de gobernanza potencialmente comprometido controla una gran parte de todos los validadores de Ethereum. Hay que reconocer que protocolos como Lido han implementado salvaguardias, pero una capa de defensa puede no ser suficiente.

A corto plazo, una opción es alentar a los participantes del ecosistema a utilizar un conjunto diverso de proveedores de apuestas de liquidez para reducir la posibilidad de que un actor dominante plantee un riesgo sistémico. Sin embargo, a largo plazo, se trata de un equilibrio inestable y depender excesivamente de la presión moral para resolver los problemas es peligroso. Surge una pregunta natural: ¿tendría sentido encapsular alguna funcionalidad en el protocolo para hacer que las apuestas de liquidez sean menos centralizadas?

La pregunta clave aquí es: ¿qué tipo de funcionalidad dentro del protocolo? Un problema con la simple creación de un token fungible de "stake ETH" dentro del protocolo es que tendría que tener una gobernanza encapsulada para todo Ethereum para elegir quién puede ejecutar los nodos, o ser abierto, pero eso lo convertiría en Herramientas del atacante.

Una idea interesante es el artículo de Dankrad Feist sobre cómo maximizar las apuestas de liquidez. En primer lugar, hagamos de tripas corazón y comprendamos que si Ethereum está sujeto a un ataque del 51%, solo se puede perder el 5% del ETH atacado. Esta es una compensación razonable; con más de 26 millones de ETH actualmente en juego, el costo de atacar un tercio de eso (~8 millones de ETH) es excesivo, especialmente considerando cuántos ataques "fuera de modelo" se pueden realizar a la vez. menor costo. De hecho, 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 recorta el 5% del ETH de ataque, entonces más del 90% del ETH apostado no se verá afectado por el corte, por lo que pueden usarse como tokens de stake líquidos fungibles dentro del protocolo y luego utilizados por otras aplicaciones.

Este camino es interesante. Pero aún queda una pregunta: ¿qué se encapsula exactamente? Rocket Pool funciona de manera muy similar: cada operador de nodo proporciona algunos fondos y los interesados ​​en liquidez proporcionan el resto. Simplemente podemos ajustar algunas constantes para limitar la penalización máxima de corte a 2 ETH, y el rETH existente de Rocket Pool quedará libre de riesgos.

Con simples ajustes de protocolo, también podemos hacer otras cosas inteligentes. Por ejemplo, digamos que queremos un sistema con dos "niveles" de participación: operadores de nodos (altos requisitos de garantía) y depositantes (sin requisitos mínimos de garantía, pueden unirse y salir en cualquier momento), pero aún así queremos dotar a un sistema con muestras aleatorias. poderes del comité de depositantes para evitar la centralización de los operadores de nodos, como recomendar una lista de transacciones que deben incluirse (por razones de resistencia a la censura), controlar la selección de bifurcaciones durante fugas de inactividad o exigir firmas en los bloques. Esto podría lograrse de una manera que esencialmente se salga del protocolo modificando el protocolo para requerir que cada validador proporcione (i) una clave de participación regular y (ii) se llame a una dirección ETH que se pueda usar en cada ranura para generar el clave de compromiso secundaria. El protocolo habilitaría ambas claves, pero el mecanismo para seleccionar la segunda clave en cada ranura podría dejarse en manos del protocolo del grupo de participación. Puede que aún sea mejor encapsular algunas funciones directamente, pero vale la pena señalar que este espacio de diseño de "incluir algunas cosas y dejar otras al usuario" existe.

Encapsular más precompilación

Los precompilados (o "contratos precompilados") son contratos de Ethereum que implementan operaciones criptográficas complejas, con una lógica implementada de forma nativa en el código del cliente en lugar del código de contrato inteligente EVM. La precodificación es un compromiso adoptado desde el comienzo del desarrollo de Ethereum: dado que la sobrecarga de una máquina virtual es demasiado grande para un código muy complejo y altamente especializado, podemos implementar algunas aplicaciones importantes en el código nativo 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 precompilación para secp256r1, una curva elíptica ligeramente diferente a la secp256k1 utilizada para cuentas básicas de Ethereum, ya que está bien respaldada por módulos de hardware confiables, por lo que su uso generalizado podría mejorar la seguridad de la billetera. En los últimos años, la comunidad también ha presionado para agregar precompilación para BLS-12-377, BW6-761, emparejamiento generalizado y otras características.

El contraargumento a estos pedidos de más precompiladores es que muchos de los precompiladores agregados anteriormente (por ejemplo, RIPEMD y BLAKE) terminaron usándose mucho menos de lo esperado, y deberíamos aprender de esto. En lugar de agregar más precompilación para operaciones específicas, quizás deberíamos centrarnos en un enfoque más modesto basado en EVM-MAX MAX MAX Token es un token de utilidad emitido por Max Asset Exchange (MAX). MAX Exchange se centra en apoyar a su comunidad comercial y proporcionar la plataforma comercial más segura. Los tokens MAX se recompensarán mediante la minería de transacciones y también se pueden utilizar para apostar en la plataforma para obtener recompensas. Ver más e ideas como la propuesta SIMD inactiva pero siempre reanudable, que permitiría a las implementaciones de EVM ejecutar una amplia gama de clases de código a un costo menor. Tal vez incluso la precompilación existente poco utilizada podría eliminarse y reemplazarse con una implementación de código EVM (inevitablemente menos eficiente) de las mismas funciones. Dicho esto, todavía es posible que haya operaciones criptográficas específicas que sean lo suficientemente valiosas como para acelerarlas, por lo que tiene sentido agregarlas como precompiladas.

¿Qué hemos aprendido de todo esto?

El deseo de encapsular lo menos posible es comprensible y bueno; surge de la tradición filosófica de Unix Unix Ver más de crear software minimalista que pueda adaptarse fácilmente a las diversas necesidades de los usuarios y evitar la maldición del software excesivo. Sin embargo, blockchain no es un sistema operativo de computación personal, sino un sistema social. Esto significa que tiene sentido encapsular determinadas funciones en el protocolo.

En muchos casos, estos otros ejemplos son similares a lo que vimos en la abstracción de la cuenta. Pero también aprendimos algunas lecciones nuevas:

  • La funcionalidad de encapsulación puede ayudar a evitar riesgos de centralización en otras áreas de la pila:

A menudo, mantener el protocolo base mínimo y simple lleva la complejidad a algún ecosistema fuera del protocolo. Desde la perspectiva de la filosofía Unix, esto está bien. Sin embargo, a veces existe el riesgo de que el ecosistema fuera de protocolo se centralice, generalmente (pero no sólo) debido a los altos costos fijos. La encapsulación a veces puede reducir la centralización de facto.

  • Encapsular demasiado puede extender demasiado la carga de confianza y gobernanza del protocolo:

Este es el tema del artículo anterior sobre "No sobrecargar el consenso de Ethereum": si encapsular una característica específica debilita el modelo de confianza y hace que Ethereum en su conjunto sea más "subjetivo", esto debilita la neutralidad creíble de Ethereum. En estos casos, es mejor tener la funcionalidad específica como un mecanismo además de Ethereum en lugar de intentar incorporarla al propio Ethereum. Los grupos de memoria cifrados son el mejor ejemplo aquí, que pueden ser un poco difíciles de encapsular, al menos hasta que mejore el cifrado de latencia.

  • Encapsular demasiado puede hacer que el protocolo sea demasiado complejo:

La complejidad del protocolo es un riesgo sistémico que aumenta al agregar demasiadas funciones a un protocolo. La precompilación es el mejor ejemplo.

  • Encapsular la funcionalidad puede resultar contraproducente a largo plazo porque las necesidades del usuario son impredecibles:

Una característica que mucha gente considera importante y que será utilizada por muchos usuarios probablemente no se utilice con mucha frecuencia en la práctica.

Además, las apuestas de liquidez, ZK-EVM y ejemplos precompilados muestran la posibilidad de un camino intermedio: una consagración mínima viable. No es necesario que el protocolo encapsule toda la funcionalidad, pero puede contener partes específicas que aborden desafíos clave, haciendo que la funcionalidad sea fácil de implementar sin ser demasiado paranoica o demasiado limitada. Los ejemplos incluyen:

  • En lugar de encapsular un sistema completo de apuestas de liquidez, es mejor cambiar las reglas de penalización de apuestas para hacer que las apuestas de liquidez sin confianza sean más factibles;

  • En lugar de encapsular más precompiladores, es mejor encapsular EVM-MAX y/o SIMD para hacer que una clase más amplia de operaciones sea más fácil de implementar de manera eficiente;

  • En lugar de encapsular todo el concepto de resumen, es posible simplemente encapsular la verificación EVM.

Podemos ampliar el diagrama anterior de la siguiente manera:

A veces tiene sentido encapsular algo y, por ejemplo, eliminar precompiladores que se utilizan con poca frecuencia. La abstracción de cuentas en su conjunto, como se mencionó anteriormente, también es una forma importante de desencapsulación. Si queremos admitir la compatibilidad con versiones anteriores para los usuarios existentes, el mecanismo podría ser sorprendentemente similar al que eliminó la precompilación: una de las propuestas es EIP-5003, que permitiría a los EOA convertir sus cuentas para que tengan la misma (o mejor) contratos funcionales.

Qué características deberían incluirse en el protocolo y cuáles deberían dejarse en manos de otras capas del ecosistema es un equilibrio complejo. Se espera que esta compensación continúe mejorando con el tiempo a medida que nuestra comprensión de las necesidades de los usuarios y el conjunto de ideas y tecnologías disponibles continúen mejorando.