原文标题: ¿Ethereum debería estar de acuerdo con consagrar más cosas en el protocolo?
Autor original: Vitalik Buterin
Traductor de Odaily Planet Daily | Nian Yin Si Tang
*Un agradecimiento especial a Justin Drake, Tina Zhen y Yoav Weiss por sus comentarios y reseñas. *
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 determinadas funciones.
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 Gavin Wood y yo dibujamos 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 a la 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, con más código repetitivo a continuación. ¿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 reestructurar apply_transaction en una simple llamada EVM no es simplemente una tarea de "limpiar el código por el simple hecho de limpiar el código"; más bien, se trata de mover la lógica al código de cuenta del usuario, dándoles 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. Más tarde, EIP-86 se convirtió en EIP-208 y, finalmente, surgió el práctico EIP-2938.
Sin embargo, EIP-2938 es todo menos minimalista. Sus contenidos incluyen:
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 límite del gas, como puntos de interrupción de ejecución de EVM y para almacenar temporalmente ETH para un pago único.
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.
Para lograr la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum (centrados en optimizar los clientes de Ethereum e implementar fusiones), EIP-2938 finalmente se rediseñó en 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 hoja de ruta actual a mediano plazo para 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 la eventual reincorporación de ERC-4337 al protocolo:
eficiencia del gas: cualquier operación realizada dentro del EVM genera cierto nivel 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, o 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 ERC-4337. operaciones. Envolver ERC-4337 y convertir la acción del usuario en 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 otros tipos de edición 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 la 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. 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). Eso 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 gas 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 funciones en funciones de protocolo a las que todos puedan acceder de forma gratuita 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 algunos fragmentos 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 los 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 de 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 incluya listas. Las operaciones individuales a nivel de usuario deben ser "legibles" para el 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 la abstracción de cuentas dentro del protocolo de encapsulación 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 se pueden iniciar desde cuentas de propiedad externa (EOA), que se verifican mediante una única firma de curva elíptica secp 256k 1. 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: 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. En particular, veremos: ZK-EVM, separación entre proponente y constructor, grupos de memoria privados, participación de liquidez y nueva precompilación.
Paquete ZK-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 muchas más.
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 funcionamiento 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 alentara 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.
*A mediano plazo, es probable que la acumulación dependa de múltiples sistemas de certificación, y el Consejo de Seguridad tenga poder sólo 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 lidiar con 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 ya 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; resulta 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 el consenso social fuera de la cadena. 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 solo 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, empacar ZK-EVM trae esperanza y desafíos.
Separación de generador y proponente de encapsulación (ePBS)
El auge de MEV hace que la producción de bloques sea una actividad económica a 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 tratado de resolver este problema mediante el uso de esquemas de separación entre proponentes y constructores fuera de protocolo, como MEV-Boost, que permite a los validadores regulares ("proponentes") empujar bloques para que la construcción se subcontrate a actores especializados ("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 usarlos. 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 Protect**. **
Cifrado de bloqueo de tiempo. Cualquiera puede descifrar esta forma de cifrado después de ciertos pasos de cálculo secuenciales y no se puede paralelizar;
Cifrado de umbral, confíe 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 produzca 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 muchas aplicaciones la resuelvan. El plan ha surgido.
Encapsular la apuesta por la liquidez
Una necesidad común entre los usuarios de Ethereum DeFi es la capacidad de utilizar simultáneamente su ETH para apostar y 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 ERC 20: convierta su ETH en "ETH de participación", manténgalo y luego conviértalo nuevamente. De hecho, proveedores de apuestas de liquidez como Lido y Rocket Pool ya lo están haciendo. Sin embargo, existen algunos mecanismos naturales de centralización en juego 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, el primero tiene operadores de nodos incluidos en la lista blanca de DAO y el segundo permite que cualquiera ejecute un nodo con un depósito de 8 ETH. Estos 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, conducirá 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: **¿Tiene 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 un atacante. Herramientas.
Una idea interesante es el artículo de Dankrad Feist sobre la maximización de las apuestas de liquidez. Primero, hagamos de tripas corazón: si Ethereum está sujeto a un ataque del 51%, solo el 5% del ETH atacado puede ser cortado. 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. costo más bajo. 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 participantes de 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 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.
Encapsula más precompilación
Los contratos 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 código nativo y valorar las operaciones críticas 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 secp 256 r 1, una curva elíptica ligeramente diferente a la secp 256 k 1 utilizada para cuentas básicas de Ethereum, que se usa ampliamente ya que está bien respaldada por módulos de hardware confiables. Úselo para aumentar la seguridad de la billetera. En los últimos años, la comunidad también ha presionado para agregar precompilación para BLS-12-377, BW 6-761, emparejamiento generalizado y otras características.
El contraargumento a estos pedidos de más precompiladores es que muchos de los precompiladores agregados anteriormente (como 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, tal vez deberíamos centrarnos en un enfoque más suave basado en ideas como EVM-MAX y la propuesta SIMD Hibernate-But-Always-Resumable, que permitiría que las implementaciones de EVM se ejecuten a un costo menor. una amplia gama de clases de código. Quizás 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 de crear software minimalista que pueda adaptarse fácilmente a las diferentes necesidades de los usuarios y evitar la maldición del exceso de software. 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:
Las funciones encapsuladas pueden 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 contenido puede extender demasiado la carga de confianza y gobernanza del protocolo:
Este es el tema de un 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 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 contenido 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.
A largo plazo, encapsular la funcionalidad puede ser contraproducente 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 estrecha. 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 más viables las apuestas de liquidez sin confianza;
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;
Puede encapsular simplemente la verificación EVM en lugar de encapsular todo el concepto de resumen.
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) contrato funcional.
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.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
El último artículo extenso de Buterin: ¿Debería el protocolo Ethereum encapsular más funciones?
原文标题: ¿Ethereum debería estar de acuerdo con consagrar más cosas en el protocolo?
Autor original: Vitalik Buterin
Traductor de Odaily Planet Daily | Nian Yin Si Tang
*Un agradecimiento especial a Justin Drake, Tina Zhen y Yoav Weiss por sus comentarios y reseñas. *
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 determinadas funciones.
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 Gavin Wood y yo dibujamos 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 a la 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, con más código repetitivo a continuación. ¿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 reestructurar apply_transaction en una simple llamada EVM no es simplemente una tarea de "limpiar el código por el simple hecho de limpiar el código"; más bien, se trata de mover la lógica al código de cuenta del usuario, dándoles 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. Más tarde, EIP-86 se convirtió en EIP-208 y, finalmente, surgió el práctico EIP-2938.
Sin embargo, EIP-2938 es todo menos minimalista. Sus contenidos incluyen:
Para lograr la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum (centrados en optimizar los clientes de Ethereum e implementar fusiones), EIP-2938 finalmente se rediseñó en 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 hoja de ruta actual a mediano plazo para 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 la eventual reincorporación de ERC-4337 al protocolo:
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 otros tipos de edición 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 la 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. 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). Eso 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 gas 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.
Pero es importante recordar que incluso la abstracción de cuentas dentro del protocolo de encapsulación 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 se pueden iniciar desde cuentas de propiedad externa (EOA), que se verifican mediante una única firma de curva elíptica secp 256k 1. 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: 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. En particular, veremos: ZK-EVM, separación entre proponente y constructor, grupos de memoria privados, participación de liquidez y nueva precompilación.
Paquete ZK-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 muchas más.
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 funcionamiento 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 alentara 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.
*A mediano plazo, es probable que la acumulación dependa de múltiples sistemas de certificación, y el Consejo de Seguridad tenga poder sólo 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 lidiar con 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 ya 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; resulta 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 el consenso social fuera de la cadena. 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 solo 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, empacar ZK-EVM trae esperanza y desafíos.
Separación de generador y proponente de encapsulación (ePBS)
El auge de MEV hace que la producción de bloques sea una actividad económica a 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 tratado de resolver este problema mediante el uso de esquemas de separación entre proponentes y constructores fuera de protocolo, como MEV-Boost, que permite a los validadores regulares ("proponentes") empujar bloques para que la construcción se subcontrate a actores especializados ("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 usarlos. 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:
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 produzca 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 muchas aplicaciones la resuelvan. El plan ha surgido.
Encapsular la apuesta por la liquidez
Una necesidad común entre los usuarios de Ethereum DeFi es la capacidad de utilizar simultáneamente su ETH para apostar y 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 ERC 20: convierta su ETH en "ETH de participación", manténgalo y luego conviértalo nuevamente. De hecho, proveedores de apuestas de liquidez como Lido y Rocket Pool ya lo están haciendo. Sin embargo, existen algunos mecanismos naturales de centralización en juego 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, el primero tiene operadores de nodos incluidos en la lista blanca de DAO y el segundo permite que cualquiera ejecute un nodo con un depósito de 8 ETH. Estos 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, conducirá 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: **¿Tiene 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 un atacante. Herramientas.
Una idea interesante es el artículo de Dankrad Feist sobre la maximización de las apuestas de liquidez. Primero, hagamos de tripas corazón: si Ethereum está sujeto a un ataque del 51%, solo el 5% del ETH atacado puede ser cortado. 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. costo más bajo. 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 participantes de 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 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.
Encapsula más precompilación
Los contratos 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 código nativo y valorar las operaciones críticas 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 secp 256 r 1, una curva elíptica ligeramente diferente a la secp 256 k 1 utilizada para cuentas básicas de Ethereum, que se usa ampliamente ya que está bien respaldada por módulos de hardware confiables. Úselo para aumentar la seguridad de la billetera. En los últimos años, la comunidad también ha presionado para agregar precompilación para BLS-12-377, BW 6-761, emparejamiento generalizado y otras características.
El contraargumento a estos pedidos de más precompiladores es que muchos de los precompiladores agregados anteriormente (como 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, tal vez deberíamos centrarnos en un enfoque más suave basado en ideas como EVM-MAX y la propuesta SIMD Hibernate-But-Always-Resumable, que permitiría que las implementaciones de EVM se ejecuten a un costo menor. una amplia gama de clases de código. Quizás 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 de crear software minimalista que pueda adaptarse fácilmente a las diferentes necesidades de los usuarios y evitar la maldición del exceso de software. 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:
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.
Este es el tema de un 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 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.
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.
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 estrecha. Ejemplos incluyen:
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) contrato funcional.
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.