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 estéticamente agradable que intentara construirse por sí mismo con lo menos posible y dejara casi todo ese tipo de trabajo a los usuarios. Idealmente, el protocolo es solo una máquina virtual y la validación de un fragmento es solo una llamada a una máquina virtual.
La "función de transición de estado" (la función que procesa el fragmento) será una sola llamada a la máquina virtual, y el resto de la lógica se producirá a través del contrato: algunos contratos de nivel de sistema, pero sobre todo contratos proporcionados por el usuario. Una característica muy buena de este modelo es que incluso una bifurcación dura completa puede describirse como una sola transacción para un contrato de procesador de bloques que será aprobada por la gobernanza fuera de la cadena o dentro de la cadena y luego se ejecutará con privilegios elevados.
Estas discusiones en 2015 se aplican en particular a dos áreas que consideramos: la abstracción de cuentas y el escalado. En el caso del escalado, la idea es tratar de crear una forma de escalado de máxima abstracción que se sienta como una extensión natural del gráfico anterior. Los contratos pueden llamar a datos que no están almacenados por la mayoría de los nodos de Ethereum, y el protocolo detectará esto y resolverá la llamada con algún tipo de función informática extendida muy general. Desde la perspectiva de la máquina virtual, la llamada entra en un subsistema independiente y devuelve mágicamente la respuesta correcta después de un tiempo.
Exploramos brevemente esta línea de pensamiento, pero rápidamente nos dimos por vencidos porque estábamos demasiado centrados en verificar que cualquier tipo de escalado de blockchain es posible. Aunque lo veremos más adelante, la combinación del muestreo de disponibilidad de datos y ZK-EVM significa que un posible futuro para el escalado de Ethereum en realidad se parece mucho a esta visión. Por otro lado, para la abstracción de cuentas, sabíamos desde el principio que era posible algún tipo de implementación, por lo que inmediatamente la investigación comenzó a tratar de acercar lo más posible al punto de partida puro de "el trading es solo una llamada" a la realidad.
Entre el procesamiento de la transacción y la realización de la llamada EVM subyacente real desde la dirección del remitente, hay una gran cantidad de código reutilizable y más código reutilizable 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 validate_transaction(state, tx), que se encarga de comprobar que la transacción tiene el nonce y la firma correctos. Desde el principio, el objetivo práctico de la abstracción de cuentas fue permitir a los usuarios reemplazar la verificación básica no incremental y ECDSA con su propia lógica de verificación, de modo que los usuarios pudieran usar más fácilmente funciones como la recuperación social y las billeteras de múltiples firmas. Por lo tanto, encontrar una manera de rediseñar la aplicación _transaction como una simple llamada a EVM no es solo una tarea de "código limpio por el simple hecho de limpiar el código"; En su lugar, se trata de trasladar la lógica al código de cuenta del usuario, lo que le da al usuario la flexibilidad que necesita.
Sin embargo, insistir en que la aplicación _transaction contenga la menor lógica fija posible termina creando muchos desafíos. Podemos echar un vistazo a una de las primeras propuestas de abstracción de cuentas, EIP-86 .
Si EIP-86 se incluye tal cual, reducirá la complejidad de la EVM a costa de aumentar masivamente la complejidad de otras partes de la pila de Ethereum, lo que requerirá que se escriba un código esencialmente idéntico en otro lugar, excepto por la introducción de categorías extrañas completamente nuevas, como que la misma transacción con el mismo número de hash puede aparecer varias veces en la cadena, sin mencionar el problema de la invalidación múltiple.
Múltiples problemas de invalidación en la abstracción de cuentas. Una transacción incluida en la cadena puede invalidar miles de otras transacciones en el mempool, lo que hace que el mempool sea fácil de inundar a bajo precio.
Desde entonces, la abstracción del relato ha evolucionado por etapas. Más tarde, el EIP-86 se convirtió en el EIP-208 y, finalmente, en el práctico EIP-2938.
Sin embargo, EIP-2938 es cualquier cosa menos minimalista. Su contenido incluye:
· Nuevos tipos de transacciones
· Variables globales para tres nuevos ámbitos de negociación
· Dos nuevos códigos de operación, incluido el código de operación PAYgas muy torpe para manejar el precio del gas y las comprobaciones del límite del gas, realizar puntos de interrupción como EVM y almacenar temporalmente ETH por una tarifa única
· Un complejo conjunto 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 la transacción.
Con el fin de implementar la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum (que se centran en optimizar los clientes de Ethereum e implementar la fusión), EIP-2938 finalmente se rediseñó a ERC-4337 completamente fuera de protocolo.
Debido a que se trata de un ERC, no requiere una bifurcación dura y técnicamente existe "fuera del protocolo Ethereum". Así que...... ¿Está resuelto el problema? Resulta que este no es el caso. La hoja de ruta actual a medio plazo de ERC-4337 en realidad implica convertir gran parte de ERC-4337 en un conjunto de características de protocolo, lo cual es un ejemplo guía útil de por qué se debe considerar este camino.
Paquete ERC-4337
Hay varias razones clave discutidas para eventualmente traer ERC-4337 de vuelta al protocolo:
Eficiencia del gas: cualquier operación realizada dentro de la EVM da como resultado cierto nivel de sobrecarga de la máquina virtual, incluidas las ineficiencias cuando se utilizan funciones que consumen mucho gas, como las ranuras de almacenamiento. Actualmente, estas ineficiencias adicionales suman al menos 20.000 gases, o más. Poner estos componentes en un protocolo es la forma más fácil de eliminar estos problemas.
Riesgo de error de código: Si el "contrato de punto de entrada" ERC-4337 tiene un error lo suficientemente aterrador, todas las billeteras compatibles con ERC-4337 pueden ver cómo se agotan todos sus fondos. La sustitución de los contratos por la funcionalidad dentro del protocolo crea una obligación implícita de corregir los errores de código a través de bifurcaciones duras, eliminando así el riesgo de que los fondos de los usuarios se agoten.
Compatibilidad con códigos de operación EVM como txt.origin. ERC-4337 en sí mismo hace que txt.origin devuelva la dirección de un "empaquetador" que empaqueta un conjunto de acciones de usuario en una transacción. La abstracción de cuentas nativas resuelve este problema haciendo que txt.origin apunte a la cuenta real que envía la transacción, lo que hace que funcione de la misma manera que EOA.
Resistente a la censura: Uno de los desafíos de la separación entre el proponente y el constructor es que resulta más fácil revisar las transacciones individuales. Este problema puede aliviarse en gran medida en un mundo en el que el protocolo Ethereum puede reconocer una sola transacción, lo que permite al proponente especificar una lista de transacciones que deben incluirse en las dos ranuras siguientes en casi todos los casos. Sin embargo, ERC-4337 fuera del protocolo encapsula las "operaciones de usuario" en una sola transacción, lo que hace que las operaciones de usuario sean opacas para el protocolo Ethereum; Por lo tanto, la lista de inclusión proporcionada por el protocolo Ethereum no podrá proporcionar resistencia a la censura a las operaciones de usuario ERC-4337. Encapsular ERC-4337 y hacer que la acción del usuario sea un tipo de transacción "apropiado" resolverá este problema.
Vale la pena mencionar que en su forma actual, ERC-4337 es mucho más caro que una transacción "básica" de Ethereum: el costo de transacción es de 21,000 gas, mientras que ERC-4337 cuesta alrededor de 42,000 gas.
Teóricamente, debería ser posible ajustar el sistema de costos de gas EVM hasta que coincidan el costo dentro del acuerdo y el costo del acceso fuera del protocolo al almacenamiento; Cuando otros tipos de operaciones de edición de almacenamiento son más baratas, no hay razón para transferir ETH a 9000 gas. De hecho, dos EIP relacionados con la próxima conversión del árbol Verkle intentan hacer precisamente eso. Pero incluso si lo hacemos, hay una razón obvia por la que la funcionalidad del protocolo encapsulado será inevitablemente mucho más barata que el código EVM, sin importar cuán eficiente sea la EVM: el código encapsulado no necesita pagar gasolina por la precarga.
La billetera ERC-4337 completamente funcional es grande, y la implementación que la compila y la pone 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 debe acceder al código en cada bloque que lo use. Según el EIP del costo de gas del árbol Verkle, 12.800 bytes constituirían 413 fragmentos, y el acceso a estos fragmentos requeriría pagar 2 veces la rama testigo_cost (3.800 gas en total) y 413 veces el fragmento testigo_cost (82.600 gas en total). Y eso sin mencionar el punto de entrada ERC-4337 en sí, que en la versión 0.6.0 tiene 23.689 bytes en la cadena (alrededor de 158.700 de gas para cargar según las reglas EIP del árbol Verkle).
Esto lleva al problema: el costo de gas para acceder a estos códigos debe amortizarse de alguna manera a lo largo de la transacción. 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 será más común el envasado? **
En este ejemplo, vemos algunas razones diferentes para encapsular el aspecto de abstracción de cuentas en el protocolo.
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 que cada bloque tiene muchos costos fijos. 244, 100 gas para cargar códigos de billetera estandarizados es una cosa; Pero la agregación podría agregar cientos de miles de gas a la validación ZK-SNARK, así como el costo en cadena de la validación de prueba de cadena. No hay forma de cobrar a los usuarios por estos costos sin introducir muchas ineficiencias en el mercado, y traducir algunas de estas características en características de protocolo a las que todos puedan acceder de forma gratuita resuelve bien este problema.
Respuestas de toda la comunidad a errores de código. Si algunos fragmentos de código son utilizados por todos los usuarios o por una amplia gama de usuarios, suele tener más sentido que la comunidad blockchain asuma la responsabilidad de una bifurcación dura para corregir cualquier error que surja. ERC-4337 introduce una gran cantidad de código compartido globalmente, y corregir errores en el código a través de una bifurcación dura es, sin duda, más razonable a largo plazo que hacer que los usuarios pierdan una gran cantidad de ETH.
A veces, se puede lograr una forma más fuerte aprovechando directamente la funcionalidad del protocolo. El ejemplo clave aquí es la función anticensura dentro del protocolo, como la lista de inclusión: la lista de inclusión dentro del protocolo puede garantizar la resistencia a la censura mejor que el método fuera del protocolo, y para que las operaciones a nivel de usuario se beneficien realmente de la lista de inclusión dentro del protocolo, una sola operación a nivel de usuario debe ser "legible" para el protocolo. Otro ejemplo menos conocido es el diseño de prueba de participación de Ethereum de la era de 2017 que abstrajo la cuenta clave de participación, que se abandonó en favor de encapsular BLS, ya que BLS admite un mecanismo de "agregación" que debe implementarse a nivel de protocolo y red, lo que puede hacer que el manejo de grandes cantidades de firmas sea más eficiente.
Pero es importante recordar que incluso encapsular la abstracción de la cuenta en el protocolo sigue siendo una gran "desencapsulación" en comparación con la situación actual. Hoy en día, las transacciones de Ethereum de primer nivel solo se pueden iniciar desde cuentas de propiedad externa (EOA) que se verifican con una sola firma de curva elíptica secp 256k1. La abstracción de cuentas elimina esto y deja que el usuario defina los criterios de validación. Entonces, en esta historia sobre la abstracción de cuentas, también vemos el mayor argumento en contra de la encapsulación: la flexibilidad para satisfacer las necesidades de diferentes usuarios.
Desarrollemos esta historia aún más viendo varios otros ejemplos de características que recientemente se han considerado encapsuladas. Prestaremos especial atención a: ZK-EVM, separación proponente-constructor, mempools privados, staking de liquidez y nueva precompilación.
Paquete ZK-EVM
Vamos a centrar nuestra atención en otro posible objetivo de encapsulación del protocolo Ethereum: ZK-EVM. Actualmente, tenemos una gran cantidad de ZK-rollups, todos los cuales tienen que escribir un código bastante similar para verificar la ejecución de bloques similares de Ethereum 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 espacio EVM ZK-rollup tiene que ver con cómo manejar posibles errores 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 atestación en caso de errores. El año pasado, traté de crear un marco estandarizado para alentar a los proyectos a aclarar su nivel de confianza en el sistema de certificación, así como en el Consejo de Seguridad, y reducir gradualmente su autoridad sobre la organización con el tiempo.
A mediano plazo, los rollups pueden basarse en múltiples sistemas de certificación, y el Consejo de Seguridad sólo tendrá la facultad en casos extremos en que diverjan dos sistemas de certificación diferentes.
Sin embargo, existe la sensación de que parte del trabajo se siente redundante. Ya tenemos la capa base de Ethereum, tiene una EVM, y ya tenemos un mecanismo de trabajo para manejar errores en la implementación: si hay un error, el cliente actualizará para solucionarlo, y luego 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 dinero. Del mismo modo, si los rollups solo quieren mantener su función equivalente a EVM, entonces necesitan implementar su propia gobernanza para cambiar constantemente sus reglas internas de ZK-EVM para que coincidan con las actualizaciones con la capa base de Ethereum, lo que se siente mal porque, en última instancia, se construyen sobre la propia capa base de Ethereum, que sabe cuándo actualizar y de acuerdo con qué nuevas reglas.
Dado que estas EVM ZK L2 utilizan básicamente exactamente las mismas EVM que Ethereum, ¿podemos incorporar de alguna manera la "verificación de la ejecución de la EVM en ZK" en la función del protocolo y manejar excepciones como errores y actualizaciones aplicando el consenso social de Ethereum, como ya hacemos con la propia implementación de EVM de capa base?
Este es un tema importante y desafiante.
Un posible tema de debate sobre la disponibilidad de datos en ZK-EVM nativo es la estadidad. Si las ZK-EVM no necesitaran transportar datos "testigos", la eficiencia de sus datos sería mucho mayor. Es decir, si un dato en particular ya ha sido leído o escrito en algún bloque anterior, simplemente podemos asumir que el probador tiene acceso a él y no tiene que volver a ponerlo a disposición. No se trata solo de no volver a cargar el almacenamiento y el código; Resulta que la compresión con estado puede ahorrar hasta 3 veces los datos en comparación con la compresión sin estado si un paquete acumulativo comprime los datos correctamente.
Esto significa que para la precompilación de ZK-EVM, tenemos dos opciones:
La precompilación requiere que todos los datos estén disponibles en el mismo fragmento. Esto significa que el probador puede no tener estado, pero también significa que el uso de este paquete acumulativo de valor aproximado precompilado es mucho más costoso que el uso del paquete acumulativo con código personalizado.
La precompilación permite que el puntero apunte a datos ejecutados, utilizados o generados anteriormente. Esto hace que ZK-rollup sea casi óptimo, pero es más complejo e introduce un nuevo estado que debe ser almacenado por prover.
¿Qué podemos aprender de esto? Hay una buena razón para encapsular de alguna manera la verificación de ZK-EVM: rollup ya está construyendo su propia versión personalizada, y Ethereum está dispuesto a sopesar sus múltiples implementaciones y el consenso social fuera de la cadena en L1 para ejecutar EVM, lo que se siente mal, pero L2 haciendo exactamente el mismo trabajo debe implementar dispositivos complejos que involucran al Consejo de Seguridad. Pero, por otro lado, hay un gran problema en los detalles: hay diferentes versiones del ZK-EVM, que difieren en costo y beneficio. La distinción entre apátridas y apátridas sólo araña la superficie; Tratar de admitir "casi-EVM", códigos personalizados que han sido probados por otros sistemas, puede exponer más espacio de diseño. Por lo tanto, encapsular el ZK-EVM presenta tanto promesas como desafíos.
Separación de envoltorios y constructores (ePBS)
El auge de MEV ha convertido la producción de bloques en una actividad económica a gran escala, con participantes complejos capaces de producir bloques que generan más ingresos que el algoritmo predeterminado, que simplemente observa el mempool de transacciones y las contiene. Hasta ahora, la comunidad de Ethereum ha tratado de resolver este problema mediante el uso de un esquema de separación de proponentes-constructores fuera de protocolo como MEV-Boost, que permite a los validadores regulares ("proponentes") subcontratar la construcción de bloques a participantes especializados ("constructores").
Sin embargo, MEV-Boost hace suposiciones de confianza en una nueva clase de participantes llamados relés. En los últimos dos años, ha habido muchas propuestas para crear un "SBP encapsulado". ¿Cuáles son los beneficios de esto? En este caso, la respuesta es simple: los PBS construidos directamente con características de protocolo son más poderosos (en el sentido de tener supuestos de confianza más débiles) que los PBS construidos sin ellas. Esto es similar al caso de los oráculos de precios dentro del protocolo de encapsulación, aunque en este caso, también hay una fuerte oposición.
Encapsulación de un grupo de memoria privada
Cuando un usuario envía una transacción, 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 las transacciones preventivas.
Recientemente, ha habido una serie de proyectos dedicados a crear "mempools privados" (o "mempools encriptados") que cifran las transacciones de los usuarios hasta que son aceptadas irreversiblemente en un bloque.
El problema, sin embargo, es que tales esquemas requieren 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 irreversiblemente.
Para lograr esta forma de cifrado, existen varias técnicas de compensación. Jon Charbonneau lo expresó una vez:
Cifre operadores centralizados, como Flashbots Protect.
cifrado de bloqueo de tiempo, que puede ser descifrado por cualquier persona después de un determinado paso de cálculo secuencial y no se puede paralelizar;
Cifrado de umbral, confiando en un comité de mayoría honesta para descifrar los datos. Para obtener recomendaciones específicas, consulte Concepto de cadena de balizas cerrada.
Hardware de confianza, como SGX.
Desafortunadamente, cada cifrado tiene diferentes debilidades. Si bien para cada solución, hay un subconjunto de usuarios dispuestos a confiar en ella, ninguna de las soluciones es lo suficientemente confiable como para que la capa 1 la acepte realmente. Por lo tanto, al menos hasta que se perfeccione el cifrado de latencia o algún otro avance tecnológico, encapsular la funcionalidad de trading anti-avance en la Capa 1 parece una propuesta difícil, incluso si es una característica lo suficientemente valiosa como para que hayan surgido muchas soluciones de aplicación.
Staking de liquidez encapsulado
Una necesidad común para los usuarios de Ethereum DeFi es la capacidad de usar su ETH simultáneamente para hacer staking y como garantía en otras aplicaciones. Otra necesidad común es simplemente por comodidad: los usuarios quieren poder hacer staking (y proteger las claves de staking online) sin la complejidad de ejecutar un nodo y mantenerlo siempre en línea.
Hasta ahora, la "interfaz" de staking más simple que satisface ambas necesidades es solo un token ERC 20: convierta su ETH en "staking ETH", manténgalo y conviértalo de nuevo. De hecho, los proveedores de staking de liquidez como Lido y Rocket Pool ya han comenzado a hacerlo. Sin embargo, el staking de liquidez tiene algunos mecanismos naturales de centralización en funcionamiento: la gente entra naturalmente en la versión más grande del staking de ETH porque es la más familiar y líquida.
Cada versión de staking de ETH requiere algún mecanismo para determinar quién puede ser el operador del nodo subyacente. No puede ser ilimitado, ya que entonces los atacantes se unirán y amplificarán el ataque con los fondos del usuario. Actualmente, los dos primeros son Lido, que tiene un operador de nodos de lista blanca de DAO, y Rocket Pool, que permite a cualquiera ejecutar un nodo con 8 ETH depositados. Los dos métodos tienen diferentes riesgos: el enfoque de Rocket Pool permite a los atacantes llevar a cabo ataques del 51% en la red y obliga a los usuarios a pagar la mayor parte del costo; En cuanto al enfoque DAO, si domina un determinado token de staking, da como resultado un único dispositivo de gobernanza potencialmente atacable que controla una parte significativa de todos los validadores de Ethereum. Sin duda, protocolos como Lido ya tienen precauciones, pero una capa de defensa puede no ser suficiente.
A corto plazo, una opción es animar a los participantes del ecosistema a utilizar una amplia gama de proveedores de staking de liquidez para reducir la probabilidad de riesgo sistémico de una sola empresa. A largo plazo, sin embargo, se trata de un equilibrio precario, y es peligroso confiar demasiado en la presión moral para resolver los problemas. Surge una pregunta natural: ¿tiene sentido encapsular algún tipo de funcionalidad en el protocolo para que el staking de liquidez sea menos centralizado?
La pregunta clave aquí es: ¿qué tipo de funcionalidad en el protocolo? El problema de simplemente crear un token fungible de "staking ETH" en el protocolo es que, o bien tiene que tener una gobernanza encapsulada en todo Ethereum para elegir quién ejecuta los nodos, o bien es abierto, pero esto lo convierte en una herramienta para los atacantes.
Una idea interesante es el artículo de Dankrad Feist sobre la maximización del staking de liquidez. Primero, mordamos la bala y si Ethereum es atacado por el 51%, solo el 5% del ETH de ataque puede ser confiscado. Esta es una compensación razonable; Con más de 26 millones de ETH actualmente en staking, un tercio de eso (alrededor de 8 millones de ETH) del costo del ataque es excesivo, especialmente considerando cuántos ataques "fuera de modelo" se pueden realizar a un costo menor. De hecho, se han explorado compensaciones similares en la propuesta de la Supercomisión para implementar la finalidad de un solo espacio.
Si aceptamos que solo se confisca el 5% de los ETH de ataque, entonces más del 90% de los ETH apostados no se verán afectados por la confiscación, por lo que pueden usarse como tokens de staking de liquidez fungible dentro del protocolo y luego ser utilizados por otras aplicaciones.
El camino es interesante. Pero aún queda la pregunta: ¿qué es exactamente lo que está encapsulado? El Rocket Pool funciona de manera muy similar: cada operador de nodo proporciona algunos fondos y los stakers de liquidez proporcionan el resto. Simplemente podemos ajustar algunas constantes para limitar la penalización máxima a 2 ETH y el rETH existente del Rocket Pool estará libre de riesgo.
Con simples ajustes de protocolo, también podemos hacer otras cosas inteligentes. Por ejemplo, supongamos que queremos un sistema con dos "capas" de staking: operadores de nodos (altos requisitos de garantía) y depositantes (sin requisitos mínimos de garantía y pueden unirse y salir en cualquier momento), pero aún queremos evitar la centralización de los operadores de nodos al facultar a un comité de depositantes muestreado aleatoriamente, como sugerir una lista de transacciones que deben incluirse (por razones resistentes a la censura), controlar la selección de bifurcaciones durante fugas inactivas o requerir la firma de bloques. Esto se puede lograr de una manera que esencialmente se separe del protocolo ajustando el protocolo para requerir que cada validador proporcione (i) una clave de participación regular y (ii) una dirección ETH a la que se pueda llamar a través de cada ranura para generar una clave de participación secundaria. El protocolo dará energía a ambas claves, pero el mecanismo para elegir la segunda clave en cada ranura se puede dejar en manos del protocolo del grupo de participación. Puede que aún sea mejor encapsular algunas características directamente, pero vale la pena señalar que este espacio de diseño de "incluir algunas cosas y dejar todo lo demás al usuario" existe.
Encapsular más precompilaciones
Los contratos precompilados (o "contratos precompilados") son contratos de Ethereum que implementan operaciones criptográficas complejas, cuya lógica se implementa de forma nativa en el código del cliente, en lugar del código del contrato inteligente EVM. La precodificación fue un compromiso adoptado al comienzo del desarrollo de Ethereum: dado que la sobrecarga de una máquina virtual era demasiado grande para un código muy complejo y altamente especializado, podíamos implementar algunas operaciones clave en el código local que eran valiosas para aplicaciones importantes para hacerlo más rápido. Hoy en día, esto incluye básicamente algunas funciones hash específicas y operaciones de curva elíptica.
Actualmente hay un impulso para agregar la precompilación para secp 256 R1, una curva elíptica ligeramente diferente a la secp 256 K1 para cuentas básicas de Ethereum, ya que está bien respaldada por módulos de hardware confiables, por lo que su uso generalizado puede mejorar la seguridad de la billetera. En los últimos años, la comunidad también ha presionado para que se agreguen precompilaciones para BLS-12-377, BW 6-761, emparejamiento generalizado y otras características.
El contraargumento a estas solicitudes de más archivos precompilados es que muchas de las precompilaciones agregadas anteriormente (por ejemplo, RIPEMD y BLAKE) terminan usando mucho menos de lo esperado, y deberíamos aprender de ellas. 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 propuestas SIMD inactivas pero siempre recuperables, lo que permitirá que las implementaciones de EVM ejecuten una amplia gama de clases de código a un costo menor. Tal vez incluso la precompilación existente, que rara vez se usa, podría eliminarse y reemplazarse con una implementación (inevitablemente menos eficiente) del código EVM de la misma función. 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; Deriva de la tradición filosófica de Unix de crear software minimalista que se pueda adaptar fácilmente a las diferentes necesidades de los usuarios y evitar la maldición de la hinchazón del software. Sin embargo, blockchain no es un sistema operativo de computación personal, sino un sistema social. Esto significa que tiene sentido encapsular cierta funcionalidad en el protocolo.
En muchos casos, estos otros ejemplos son similares a lo que vemos en la abstracción de cuentas. Pero también aprendimos algunas lecciones nuevas:
La encapsulación puede ayudar a evitar el riesgo de centralización en otra parte de la pila:
A menudo, mantener el protocolo básico mínimo y simple empuja la complejidad más allá de algunos de los protocolos del ecosistema. Desde un punto de vista filosófico de Unix, esto es bueno. Sin embargo, a veces existe el riesgo de que los ecosistemas fuera del protocolo se centralicen, generalmente (pero no solo) debido a los altos costos fijos. A veces, la encapsulación puede reducir la centralización de facto.
Encapsular demasiado contenido puede expandir en exceso la carga de confianza y gobernanza en el protocolo:
Este es el tema de un artículo anterior sobre "No sobrecargues el consenso de Ethereum": si encapsular una función en particular debilita el modelo de confianza y hace que Ethereum en su conjunto sea más "subjetivo", debilita la neutralidad de confianza de Ethereum. En estos casos, es mejor presentar una característica específica como un mecanismo sobre Ethereum que tratar de introducirla en el propio Ethereum. Aquí, los grupos de memoria cifrados son el mejor ejemplo, y puede ser un poco difícil de encapsular, al menos hasta que mejore el cifrado de latencia.
Encapsular demasiado puede complicar demasiado el protocolo:
La complejidad del protocolo es un riesgo sistémico que puede aumentarse si se agregan demasiadas funciones al protocolo. La precompilación es el mejor ejemplo.
A largo plazo, la funcionalidad de encapsulación puede ser contraproducente porque las necesidades del usuario son impredecibles:
Una característica que muchas personas consideran importante y que será utilizada por muchos usuarios probablemente no se use regularmente en la práctica.
Además, el staking de liquidez, ZK-EVM y los casos precompilados muestran la posibilidad de una vía intermedia: la consagración mínima viable. No es necesario que los protocolos encapsulen toda la función, sino que pueden contener partes específicas que aborden desafíos clave, lo que hace que la función sea fácil de implementar sin ser demasiado paranoica o demasiado estrecha. Ejemplos de esto incluyen:
En lugar de encapsular un sistema completo de pignoración de liquidez, es mejor cambiar las reglas de penalización de staking para que sea más factible la pignoración de liquidez sin confianza;
En lugar de encapsular más precompiladores, encapsule EVM-MAX y/o SIMD para facilitar la implementación eficiente para una gama más amplia de categorías operativas;
La verificación de EVM se puede encapsular simplemente en lugar de encapsular todo el concepto de rollup.
Podemos ampliar el gráfico anterior de la siguiente manera:
A veces tiene sentido envolver algo, y la eliminación de la precompilación que rara vez se usa es un ejemplo. 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 puede ser sorprendentemente similar al que desencapsula los precompilados: una de las propuestas es EIP-5003, que permitiría a EOA convertir sus cuentas en contratos con la misma (o mejor) funcionalidad.
Qué características deben introducirse en el protocolo y cuáles deben dejarse a otras capas del ecosistema es una disyuntiva compleja. 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 las ideas disponibles y los conjuntos de tecnología 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.
Vitalik Buterin: ¿Debería Ethereum encapsular más características?
Primeras filosofías del 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 estéticamente agradable que intentara construirse por sí mismo con lo menos posible y dejara casi todo ese tipo de trabajo a los usuarios. Idealmente, el protocolo es solo una máquina virtual y la validación de un fragmento es solo una llamada a una máquina virtual.
La "función de transición de estado" (la función que procesa el fragmento) será una sola llamada a la máquina virtual, y el resto de la lógica se producirá a través del contrato: algunos contratos de nivel de sistema, pero sobre todo contratos proporcionados por el usuario. Una característica muy buena de este modelo es que incluso una bifurcación dura completa puede describirse como una sola transacción para un contrato de procesador de bloques que será aprobada por la gobernanza fuera de la cadena o dentro de la cadena y luego se ejecutará con privilegios elevados.
Estas discusiones en 2015 se aplican en particular a dos áreas que consideramos: la abstracción de cuentas y el escalado. En el caso del escalado, la idea es tratar de crear una forma de escalado de máxima abstracción que se sienta como una extensión natural del gráfico anterior. Los contratos pueden llamar a datos que no están almacenados por la mayoría de los nodos de Ethereum, y el protocolo detectará esto y resolverá la llamada con algún tipo de función informática extendida muy general. Desde la perspectiva de la máquina virtual, la llamada entra en un subsistema independiente y devuelve mágicamente la respuesta correcta después de un tiempo.
Exploramos brevemente esta línea de pensamiento, pero rápidamente nos dimos por vencidos porque estábamos demasiado centrados en verificar que cualquier tipo de escalado de blockchain es posible. Aunque lo veremos más adelante, la combinación del muestreo de disponibilidad de datos y ZK-EVM significa que un posible futuro para el escalado de Ethereum en realidad se parece mucho a esta visión. Por otro lado, para la abstracción de cuentas, sabíamos desde el principio que era posible algún tipo de implementación, por lo que inmediatamente la investigación comenzó a tratar de acercar lo más posible al punto de partida puro de "el trading es solo una llamada" a la realidad.
Entre el procesamiento de la transacción y la realización de la llamada EVM subyacente real desde la dirección del remitente, hay una gran cantidad de código reutilizable y más código reutilizable 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 validate_transaction(state, tx), que se encarga de comprobar que la transacción tiene el nonce y la firma correctos. Desde el principio, el objetivo práctico de la abstracción de cuentas fue permitir a los usuarios reemplazar la verificación básica no incremental y ECDSA con su propia lógica de verificación, de modo que los usuarios pudieran usar más fácilmente funciones como la recuperación social y las billeteras de múltiples firmas. Por lo tanto, encontrar una manera de rediseñar la aplicación _transaction como una simple llamada a EVM no es solo una tarea de "código limpio por el simple hecho de limpiar el código"; En su lugar, se trata de trasladar la lógica al código de cuenta del usuario, lo que le da al usuario la flexibilidad que necesita.
Sin embargo, insistir en que la aplicación _transaction contenga la menor lógica fija posible termina creando muchos desafíos. Podemos echar un vistazo a una de las primeras propuestas de abstracción de cuentas, EIP-86 .
Si EIP-86 se incluye tal cual, reducirá la complejidad de la EVM a costa de aumentar masivamente la complejidad de otras partes de la pila de Ethereum, lo que requerirá que se escriba un código esencialmente idéntico en otro lugar, excepto por la introducción de categorías extrañas completamente nuevas, como que la misma transacción con el mismo número de hash puede aparecer varias veces en la cadena, sin mencionar el problema de la invalidación múltiple.
Múltiples problemas de invalidación en la abstracción de cuentas. Una transacción incluida en la cadena puede invalidar miles de otras transacciones en el mempool, lo que hace que el mempool sea fácil de inundar a bajo precio.
Desde entonces, la abstracción del relato ha evolucionado por etapas. Más tarde, el EIP-86 se convirtió en el EIP-208 y, finalmente, en el práctico EIP-2938.
Sin embargo, EIP-2938 es cualquier cosa menos minimalista. Su contenido incluye:
· Nuevos tipos de transacciones
· Variables globales para tres nuevos ámbitos de negociación
· Dos nuevos códigos de operación, incluido el código de operación PAYgas muy torpe para manejar el precio del gas y las comprobaciones del límite del gas, realizar puntos de interrupción como EVM y almacenar temporalmente ETH por una tarifa única
· Un complejo conjunto 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 la transacción.
Con el fin de implementar la abstracción de cuentas sin involucrar a los desarrolladores principales de Ethereum (que se centran en optimizar los clientes de Ethereum e implementar la fusión), EIP-2938 finalmente se rediseñó a ERC-4337 completamente fuera de protocolo.
Debido a que se trata de un ERC, no requiere una bifurcación dura y técnicamente existe "fuera del protocolo Ethereum". Así que...... ¿Está resuelto el problema? Resulta que este no es el caso. La hoja de ruta actual a medio plazo de ERC-4337 en realidad implica convertir gran parte de ERC-4337 en un conjunto de características de protocolo, lo cual es un ejemplo guía útil de por qué se debe considerar este camino.
Paquete ERC-4337
Hay varias razones clave discutidas para eventualmente traer ERC-4337 de vuelta al protocolo:
Eficiencia del gas: cualquier operación realizada dentro de la EVM da como resultado cierto nivel de sobrecarga de la máquina virtual, incluidas las ineficiencias cuando se utilizan funciones que consumen mucho gas, como las ranuras de almacenamiento. Actualmente, estas ineficiencias adicionales suman al menos 20.000 gases, o más. Poner estos componentes en un protocolo es la forma más fácil de eliminar estos problemas.
Riesgo de error de código: Si el "contrato de punto de entrada" ERC-4337 tiene un error lo suficientemente aterrador, todas las billeteras compatibles con ERC-4337 pueden ver cómo se agotan todos sus fondos. La sustitución de los contratos por la funcionalidad dentro del protocolo crea una obligación implícita de corregir los errores de código a través de bifurcaciones duras, eliminando así el riesgo de que los fondos de los usuarios se agoten.
Compatibilidad con códigos de operación EVM como txt.origin. ERC-4337 en sí mismo hace que txt.origin devuelva la dirección de un "empaquetador" que empaqueta un conjunto de acciones de usuario en una transacción. La abstracción de cuentas nativas resuelve este problema haciendo que txt.origin apunte a la cuenta real que envía la transacción, lo que hace que funcione de la misma manera que EOA.
Resistente a la censura: Uno de los desafíos de la separación entre el proponente y el constructor es que resulta más fácil revisar las transacciones individuales. Este problema puede aliviarse en gran medida en un mundo en el que el protocolo Ethereum puede reconocer una sola transacción, lo que permite al proponente especificar una lista de transacciones que deben incluirse en las dos ranuras siguientes en casi todos los casos. Sin embargo, ERC-4337 fuera del protocolo encapsula las "operaciones de usuario" en una sola transacción, lo que hace que las operaciones de usuario sean opacas para el protocolo Ethereum; Por lo tanto, la lista de inclusión proporcionada por el protocolo Ethereum no podrá proporcionar resistencia a la censura a las operaciones de usuario ERC-4337. Encapsular ERC-4337 y hacer que la acción del usuario sea un tipo de transacción "apropiado" resolverá este problema.
Vale la pena mencionar que en su forma actual, ERC-4337 es mucho más caro que una transacción "básica" de Ethereum: el costo de transacción es de 21,000 gas, mientras que ERC-4337 cuesta alrededor de 42,000 gas.
Teóricamente, debería ser posible ajustar el sistema de costos de gas EVM hasta que coincidan el costo dentro del acuerdo y el costo del acceso fuera del protocolo al almacenamiento; Cuando otros tipos de operaciones de edición de almacenamiento son más baratas, no hay razón para transferir ETH a 9000 gas. De hecho, dos EIP relacionados con la próxima conversión del árbol Verkle intentan hacer precisamente eso. Pero incluso si lo hacemos, hay una razón obvia por la que la funcionalidad del protocolo encapsulado será inevitablemente mucho más barata que el código EVM, sin importar cuán eficiente sea la EVM: el código encapsulado no necesita pagar gasolina por la precarga.
La billetera ERC-4337 completamente funcional es grande, y la implementación que la compila y la pone 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 debe acceder al código en cada bloque que lo use. Según el EIP del costo de gas del árbol Verkle, 12.800 bytes constituirían 413 fragmentos, y el acceso a estos fragmentos requeriría pagar 2 veces la rama testigo_cost (3.800 gas en total) y 413 veces el fragmento testigo_cost (82.600 gas en total). Y eso sin mencionar el punto de entrada ERC-4337 en sí, que en la versión 0.6.0 tiene 23.689 bytes en la cadena (alrededor de 158.700 de gas para cargar según las reglas EIP del árbol Verkle).
Esto lleva al problema: el costo de gas para acceder a estos códigos debe amortizarse de alguna manera a lo largo de la transacción. 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 será más común el envasado? **
En este ejemplo, vemos algunas razones diferentes para encapsular el aspecto de abstracción de cuentas en el protocolo.
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 que cada bloque tiene muchos costos fijos. 244, 100 gas para cargar códigos de billetera estandarizados es una cosa; Pero la agregación podría agregar cientos de miles de gas a la validación ZK-SNARK, así como el costo en cadena de la validación de prueba de cadena. No hay forma de cobrar a los usuarios por estos costos sin introducir muchas ineficiencias en el mercado, y traducir algunas de estas características en características de protocolo a las que todos puedan acceder de forma gratuita resuelve bien este problema.
Respuestas de toda la comunidad a errores de código. Si algunos fragmentos de código son utilizados por todos los usuarios o por una amplia gama de usuarios, suele tener más sentido que la comunidad blockchain asuma la responsabilidad de una bifurcación dura para corregir cualquier error que surja. ERC-4337 introduce una gran cantidad de código compartido globalmente, y corregir errores en el código a través de una bifurcación dura es, sin duda, más razonable a largo plazo que hacer que los usuarios pierdan una gran cantidad de ETH.
A veces, se puede lograr una forma más fuerte aprovechando directamente la funcionalidad del protocolo. El ejemplo clave aquí es la función anticensura dentro del protocolo, como la lista de inclusión: la lista de inclusión dentro del protocolo puede garantizar la resistencia a la censura mejor que el método fuera del protocolo, y para que las operaciones a nivel de usuario se beneficien realmente de la lista de inclusión dentro del protocolo, una sola operación a nivel de usuario debe ser "legible" para el protocolo. Otro ejemplo menos conocido es el diseño de prueba de participación de Ethereum de la era de 2017 que abstrajo la cuenta clave de participación, que se abandonó en favor de encapsular BLS, ya que BLS admite un mecanismo de "agregación" que debe implementarse a nivel de protocolo y red, lo que puede hacer que el manejo de grandes cantidades de firmas sea más eficiente.
Pero es importante recordar que incluso encapsular la abstracción de la cuenta en el protocolo sigue siendo una gran "desencapsulación" en comparación con la situación actual. Hoy en día, las transacciones de Ethereum de primer nivel solo se pueden iniciar desde cuentas de propiedad externa (EOA) que se verifican con una sola firma de curva elíptica secp 256k1. La abstracción de cuentas elimina esto y deja que el usuario defina los criterios de validación. Entonces, en esta historia sobre la abstracción de cuentas, también vemos el mayor argumento en contra de la encapsulación: la flexibilidad para satisfacer las necesidades de diferentes usuarios.
Desarrollemos esta historia aún más viendo varios otros ejemplos de características que recientemente se han considerado encapsuladas. Prestaremos especial atención a: ZK-EVM, separación proponente-constructor, mempools privados, staking de liquidez y nueva precompilación.
Paquete ZK-EVM
Vamos a centrar nuestra atención en otro posible objetivo de encapsulación del protocolo Ethereum: ZK-EVM. Actualmente, tenemos una gran cantidad de ZK-rollups, todos los cuales tienen que escribir un código bastante similar para verificar la ejecución de bloques similares de Ethereum 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 espacio EVM ZK-rollup tiene que ver con cómo manejar posibles errores 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 atestación en caso de errores. El año pasado, traté de crear un marco estandarizado para alentar a los proyectos a aclarar su nivel de confianza en el sistema de certificación, así como en el Consejo de Seguridad, y reducir gradualmente su autoridad sobre la organización con el tiempo.
A mediano plazo, los rollups pueden basarse en múltiples sistemas de certificación, y el Consejo de Seguridad sólo tendrá la facultad en casos extremos en que diverjan dos sistemas de certificación diferentes.
Sin embargo, existe la sensación de que parte del trabajo se siente redundante. Ya tenemos la capa base de Ethereum, tiene una EVM, y ya tenemos un mecanismo de trabajo para manejar errores en la implementación: si hay un error, el cliente actualizará para solucionarlo, y luego 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 dinero. Del mismo modo, si los rollups solo quieren mantener su función equivalente a EVM, entonces necesitan implementar su propia gobernanza para cambiar constantemente sus reglas internas de ZK-EVM para que coincidan con las actualizaciones con la capa base de Ethereum, lo que se siente mal porque, en última instancia, se construyen sobre la propia capa base de Ethereum, que sabe cuándo actualizar y de acuerdo con qué nuevas reglas.
Dado que estas EVM ZK L2 utilizan básicamente exactamente las mismas EVM que Ethereum, ¿podemos incorporar de alguna manera la "verificación de la ejecución de la EVM en ZK" en la función del protocolo y manejar excepciones como errores y actualizaciones aplicando el consenso social de Ethereum, como ya hacemos con la propia implementación de EVM de capa base?
Este es un tema importante y desafiante.
Un posible tema de debate sobre la disponibilidad de datos en ZK-EVM nativo es la estadidad. Si las ZK-EVM no necesitaran transportar datos "testigos", la eficiencia de sus datos sería mucho mayor. Es decir, si un dato en particular ya ha sido leído o escrito en algún bloque anterior, simplemente podemos asumir que el probador tiene acceso a él y no tiene que volver a ponerlo a disposición. No se trata solo de no volver a cargar el almacenamiento y el código; Resulta que la compresión con estado puede ahorrar hasta 3 veces los datos en comparación con la compresión sin estado si un paquete acumulativo comprime los datos correctamente.
Esto significa que para la precompilación de ZK-EVM, tenemos dos opciones:
La precompilación requiere que todos los datos estén disponibles en el mismo fragmento. Esto significa que el probador puede no tener estado, pero también significa que el uso de este paquete acumulativo de valor aproximado precompilado es mucho más costoso que el uso del paquete acumulativo con código personalizado.
La precompilación permite que el puntero apunte a datos ejecutados, utilizados o generados anteriormente. Esto hace que ZK-rollup sea casi óptimo, pero es más complejo e introduce un nuevo estado que debe ser almacenado por prover.
¿Qué podemos aprender de esto? Hay una buena razón para encapsular de alguna manera la verificación de ZK-EVM: rollup ya está construyendo su propia versión personalizada, y Ethereum está dispuesto a sopesar sus múltiples implementaciones y el consenso social fuera de la cadena en L1 para ejecutar EVM, lo que se siente mal, pero L2 haciendo exactamente el mismo trabajo debe implementar dispositivos complejos que involucran al Consejo de Seguridad. Pero, por otro lado, hay un gran problema en los detalles: hay diferentes versiones del ZK-EVM, que difieren en costo y beneficio. La distinción entre apátridas y apátridas sólo araña la superficie; Tratar de admitir "casi-EVM", códigos personalizados que han sido probados por otros sistemas, puede exponer más espacio de diseño. Por lo tanto, encapsular el ZK-EVM presenta tanto promesas como desafíos.
Separación de envoltorios y constructores (ePBS)
El auge de MEV ha convertido la producción de bloques en una actividad económica a gran escala, con participantes complejos capaces de producir bloques que generan más ingresos que el algoritmo predeterminado, que simplemente observa el mempool de transacciones y las contiene. Hasta ahora, la comunidad de Ethereum ha tratado de resolver este problema mediante el uso de un esquema de separación de proponentes-constructores fuera de protocolo como MEV-Boost, que permite a los validadores regulares ("proponentes") subcontratar la construcción de bloques a participantes especializados ("constructores").
Sin embargo, MEV-Boost hace suposiciones de confianza en una nueva clase de participantes llamados relés. En los últimos dos años, ha habido muchas propuestas para crear un "SBP encapsulado". ¿Cuáles son los beneficios de esto? En este caso, la respuesta es simple: los PBS construidos directamente con características de protocolo son más poderosos (en el sentido de tener supuestos de confianza más débiles) que los PBS construidos sin ellas. Esto es similar al caso de los oráculos de precios dentro del protocolo de encapsulación, aunque en este caso, también hay una fuerte oposición.
Encapsulación de un grupo de memoria privada
Cuando un usuario envía una transacción, 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 las transacciones preventivas.
Recientemente, ha habido una serie de proyectos dedicados a crear "mempools privados" (o "mempools encriptados") que cifran las transacciones de los usuarios hasta que son aceptadas irreversiblemente en un bloque.
El problema, sin embargo, es que tales esquemas requieren 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 irreversiblemente.
Para lograr esta forma de cifrado, existen varias técnicas de compensación. Jon Charbonneau lo expresó una vez:
Cifre operadores centralizados, como Flashbots Protect.
cifrado de bloqueo de tiempo, que puede ser descifrado por cualquier persona después de un determinado paso de cálculo secuencial y no se puede paralelizar;
Cifrado de umbral, confiando en un comité de mayoría honesta para descifrar los datos. Para obtener recomendaciones específicas, consulte Concepto de cadena de balizas cerrada.
Hardware de confianza, como SGX.
Desafortunadamente, cada cifrado tiene diferentes debilidades. Si bien para cada solución, hay un subconjunto de usuarios dispuestos a confiar en ella, ninguna de las soluciones es lo suficientemente confiable como para que la capa 1 la acepte realmente. Por lo tanto, al menos hasta que se perfeccione el cifrado de latencia o algún otro avance tecnológico, encapsular la funcionalidad de trading anti-avance en la Capa 1 parece una propuesta difícil, incluso si es una característica lo suficientemente valiosa como para que hayan surgido muchas soluciones de aplicación.
Staking de liquidez encapsulado
Una necesidad común para los usuarios de Ethereum DeFi es la capacidad de usar su ETH simultáneamente para hacer staking y como garantía en otras aplicaciones. Otra necesidad común es simplemente por comodidad: los usuarios quieren poder hacer staking (y proteger las claves de staking online) sin la complejidad de ejecutar un nodo y mantenerlo siempre en línea.
Hasta ahora, la "interfaz" de staking más simple que satisface ambas necesidades es solo un token ERC 20: convierta su ETH en "staking ETH", manténgalo y conviértalo de nuevo. De hecho, los proveedores de staking de liquidez como Lido y Rocket Pool ya han comenzado a hacerlo. Sin embargo, el staking de liquidez tiene algunos mecanismos naturales de centralización en funcionamiento: la gente entra naturalmente en la versión más grande del staking de ETH porque es la más familiar y líquida.
Cada versión de staking de ETH requiere algún mecanismo para determinar quién puede ser el operador del nodo subyacente. No puede ser ilimitado, ya que entonces los atacantes se unirán y amplificarán el ataque con los fondos del usuario. Actualmente, los dos primeros son Lido, que tiene un operador de nodos de lista blanca de DAO, y Rocket Pool, que permite a cualquiera ejecutar un nodo con 8 ETH depositados. Los dos métodos tienen diferentes riesgos: el enfoque de Rocket Pool permite a los atacantes llevar a cabo ataques del 51% en la red y obliga a los usuarios a pagar la mayor parte del costo; En cuanto al enfoque DAO, si domina un determinado token de staking, da como resultado un único dispositivo de gobernanza potencialmente atacable que controla una parte significativa de todos los validadores de Ethereum. Sin duda, protocolos como Lido ya tienen precauciones, pero una capa de defensa puede no ser suficiente.
A corto plazo, una opción es animar a los participantes del ecosistema a utilizar una amplia gama de proveedores de staking de liquidez para reducir la probabilidad de riesgo sistémico de una sola empresa. A largo plazo, sin embargo, se trata de un equilibrio precario, y es peligroso confiar demasiado en la presión moral para resolver los problemas. Surge una pregunta natural: ¿tiene sentido encapsular algún tipo de funcionalidad en el protocolo para que el staking de liquidez sea menos centralizado?
La pregunta clave aquí es: ¿qué tipo de funcionalidad en el protocolo? El problema de simplemente crear un token fungible de "staking ETH" en el protocolo es que, o bien tiene que tener una gobernanza encapsulada en todo Ethereum para elegir quién ejecuta los nodos, o bien es abierto, pero esto lo convierte en una herramienta para los atacantes.
Una idea interesante es el artículo de Dankrad Feist sobre la maximización del staking de liquidez. Primero, mordamos la bala y si Ethereum es atacado por el 51%, solo el 5% del ETH de ataque puede ser confiscado. Esta es una compensación razonable; Con más de 26 millones de ETH actualmente en staking, un tercio de eso (alrededor de 8 millones de ETH) del costo del ataque es excesivo, especialmente considerando cuántos ataques "fuera de modelo" se pueden realizar a un costo menor. De hecho, se han explorado compensaciones similares en la propuesta de la Supercomisión para implementar la finalidad de un solo espacio.
Si aceptamos que solo se confisca el 5% de los ETH de ataque, entonces más del 90% de los ETH apostados no se verán afectados por la confiscación, por lo que pueden usarse como tokens de staking de liquidez fungible dentro del protocolo y luego ser utilizados por otras aplicaciones.
El camino es interesante. Pero aún queda la pregunta: ¿qué es exactamente lo que está encapsulado? El Rocket Pool funciona de manera muy similar: cada operador de nodo proporciona algunos fondos y los stakers de liquidez proporcionan el resto. Simplemente podemos ajustar algunas constantes para limitar la penalización máxima a 2 ETH y el rETH existente del Rocket Pool estará libre de riesgo.
Con simples ajustes de protocolo, también podemos hacer otras cosas inteligentes. Por ejemplo, supongamos que queremos un sistema con dos "capas" de staking: operadores de nodos (altos requisitos de garantía) y depositantes (sin requisitos mínimos de garantía y pueden unirse y salir en cualquier momento), pero aún queremos evitar la centralización de los operadores de nodos al facultar a un comité de depositantes muestreado aleatoriamente, como sugerir una lista de transacciones que deben incluirse (por razones resistentes a la censura), controlar la selección de bifurcaciones durante fugas inactivas o requerir la firma de bloques. Esto se puede lograr de una manera que esencialmente se separe del protocolo ajustando el protocolo para requerir que cada validador proporcione (i) una clave de participación regular y (ii) una dirección ETH a la que se pueda llamar a través de cada ranura para generar una clave de participación secundaria. El protocolo dará energía a ambas claves, pero el mecanismo para elegir la segunda clave en cada ranura se puede dejar en manos del protocolo del grupo de participación. Puede que aún sea mejor encapsular algunas características directamente, pero vale la pena señalar que este espacio de diseño de "incluir algunas cosas y dejar todo lo demás al usuario" existe.
Encapsular más precompilaciones
Los contratos precompilados (o "contratos precompilados") son contratos de Ethereum que implementan operaciones criptográficas complejas, cuya lógica se implementa de forma nativa en el código del cliente, en lugar del código del contrato inteligente EVM. La precodificación fue un compromiso adoptado al comienzo del desarrollo de Ethereum: dado que la sobrecarga de una máquina virtual era demasiado grande para un código muy complejo y altamente especializado, podíamos implementar algunas operaciones clave en el código local que eran valiosas para aplicaciones importantes para hacerlo más rápido. Hoy en día, esto incluye básicamente algunas funciones hash específicas y operaciones de curva elíptica.
Actualmente hay un impulso para agregar la precompilación para secp 256 R1, una curva elíptica ligeramente diferente a la secp 256 K1 para cuentas básicas de Ethereum, ya que está bien respaldada por módulos de hardware confiables, por lo que su uso generalizado puede mejorar la seguridad de la billetera. En los últimos años, la comunidad también ha presionado para que se agreguen precompilaciones para BLS-12-377, BW 6-761, emparejamiento generalizado y otras características.
El contraargumento a estas solicitudes de más archivos precompilados es que muchas de las precompilaciones agregadas anteriormente (por ejemplo, RIPEMD y BLAKE) terminan usando mucho menos de lo esperado, y deberíamos aprender de ellas. 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 propuestas SIMD inactivas pero siempre recuperables, lo que permitirá que las implementaciones de EVM ejecuten una amplia gama de clases de código a un costo menor. Tal vez incluso la precompilación existente, que rara vez se usa, podría eliminarse y reemplazarse con una implementación (inevitablemente menos eficiente) del código EVM de la misma función. 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; Deriva de la tradición filosófica de Unix de crear software minimalista que se pueda adaptar fácilmente a las diferentes necesidades de los usuarios y evitar la maldición de la hinchazón del software. Sin embargo, blockchain no es un sistema operativo de computación personal, sino un sistema social. Esto significa que tiene sentido encapsular cierta funcionalidad en el protocolo.
En muchos casos, estos otros ejemplos son similares a lo que vemos en la abstracción de cuentas. Pero también aprendimos algunas lecciones nuevas:
La encapsulación puede ayudar a evitar el riesgo de centralización en otra parte de la pila:
A menudo, mantener el protocolo básico mínimo y simple empuja la complejidad más allá de algunos de los protocolos del ecosistema. Desde un punto de vista filosófico de Unix, esto es bueno. Sin embargo, a veces existe el riesgo de que los ecosistemas fuera del protocolo se centralicen, generalmente (pero no solo) debido a los altos costos fijos. A veces, la encapsulación puede reducir la centralización de facto.
Encapsular demasiado contenido puede expandir en exceso la carga de confianza y gobernanza en el protocolo:
Este es el tema de un artículo anterior sobre "No sobrecargues el consenso de Ethereum": si encapsular una función en particular debilita el modelo de confianza y hace que Ethereum en su conjunto sea más "subjetivo", debilita la neutralidad de confianza de Ethereum. En estos casos, es mejor presentar una característica específica como un mecanismo sobre Ethereum que tratar de introducirla en el propio Ethereum. Aquí, los grupos de memoria cifrados son el mejor ejemplo, y puede ser un poco difícil de encapsular, al menos hasta que mejore el cifrado de latencia.
Encapsular demasiado puede complicar demasiado el protocolo:
La complejidad del protocolo es un riesgo sistémico que puede aumentarse si se agregan demasiadas funciones al protocolo. La precompilación es el mejor ejemplo.
A largo plazo, la funcionalidad de encapsulación puede ser contraproducente porque las necesidades del usuario son impredecibles:
Una característica que muchas personas consideran importante y que será utilizada por muchos usuarios probablemente no se use regularmente en la práctica.
Además, el staking de liquidez, ZK-EVM y los casos precompilados muestran la posibilidad de una vía intermedia: la consagración mínima viable. No es necesario que los protocolos encapsulen toda la función, sino que pueden contener partes específicas que aborden desafíos clave, lo que hace que la función sea fácil de implementar sin ser demasiado paranoica o demasiado estrecha. Ejemplos de esto incluyen:
En lugar de encapsular un sistema completo de pignoración de liquidez, es mejor cambiar las reglas de penalización de staking para que sea más factible la pignoración de liquidez sin confianza;
En lugar de encapsular más precompiladores, encapsule EVM-MAX y/o SIMD para facilitar la implementación eficiente para una gama más amplia de categorías operativas;
La verificación de EVM se puede encapsular simplemente en lugar de encapsular todo el concepto de rollup.
Podemos ampliar el gráfico anterior de la siguiente manera:
A veces tiene sentido envolver algo, y la eliminación de la precompilación que rara vez se usa es un ejemplo. 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 puede ser sorprendentemente similar al que desencapsula los precompilados: una de las propuestas es EIP-5003, que permitiría a EOA convertir sus cuentas en contratos con la misma (o mejor) funcionalidad.
Qué características deben introducirse en el protocolo y cuáles deben dejarse a otras capas del ecosistema es una disyuntiva compleja. 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 las ideas disponibles y los conjuntos de tecnología continúen mejorando.