En la actualización de Pectra, surgió el problema de disputa de gobernanza más complejo. Cuando EIP3074 fue incluido en la actualización de Pectra, causó una gran controversia, especialmente por parte del equipo de ERC4337.
EIP3074 se ha estancado, el proceso de gobernanza no puede continuar. Hasta que Vitalik propuso EIP7702 que puso fin a las dudas del equipo de ERC4337 sobre EIP3074.
GCC Research descubrió que hay poca discusión en el mundo chino sobre los problemas de gobernanza de EIP3074 y ERC7702 en la actualización de Pectra. Pero este problema de gobernanza también refleja un problema profundo de gobernanza en Ethereum, es decir, bajo el principio de "el código es la ley", ¿quién puede controlar el contenido específico del código? Los problemas de gobernanza de EIP3074 y ERC7702 pueden brindarnos una buena perspectiva para observar el verdadero proceso de gobernanza interno de Ethereum.
La conclusión final de este artículo es una paráfrasis de un artículo de opinión publicado por ZeroDev, que afirma que el sistema de gobernanza de Ethereum es un modelo VVRC, y que la inclusión de cualquier propuesta debe alinearse primero con los valores de Ethereum (Value), y luego la propuesta debe reflejar la visión diseñada por Vitalik (Vision), la propuesta final debe reflejarse en la hoja de ruta (Roadmap), y finalmente ser discutida por los desarrolladores principales e incorporada al cliente (Client) Implementación.
GCC Research en el artículo anterior presentó que el EIP2537 solo tuvo problemas de implementación a nivel de cliente, lo que llevó a un retraso en su inclusión en el hard fork, mientras que el EIP3074 no fue incluido en el hard fork debido a problemas de visión y hoja de ruta, y los desarrolladores centrales de Ethereum eligieron directamente el EIP7702 escrito por Vitalik como la propuesta final de abstracción de cuentas.
Resumen del contenido de la propuesta
Antes de introducir los procesos de gobernanza específicos, primero necesitamos presentar brevemente el contenido específico relacionado con EIP3074, EIP7702 y ERC4337.
EIP3074 es una propuesta de capa de ejecución que requiere una actualización del software de los nodos para su implementación. El objetivo principal de EIP3074 es lograr la funcionalidad de patrocinio de gas y transacciones en lote. El llamado patrocinio de gas significa que los usuarios pueden pagar las tarifas de gas utilizando cualquier token, o que los usuarios pueden pagar las tarifas de gas fuera de línea. Sin embargo, es importante tener en cuenta que, a diferencia de otras propuestas de abstracción de cuentas que permiten cambiar el algoritmo de verificación de firmas, EIP3074 no permite a los usuarios utilizar ningún algoritmo de firma distinto a secp256k1. En otras palabras, EIP3074 no es una propuesta que satisfaga todas las funciones de abstracción de cuentas. Este es también un punto por el cual EIP3074 ha sido objeto de críticas.
Para lograr el objetivo esperado, EIP3074 introduce dos códigos de operación, que son AUTH y AUTHCALL. El código de operación AUTH puede verificar la firma, y una vez que la verificación de la firma se completa, este código de operación configurará el campo authorized en el contexto actual de EVM con la dirección del firmante. Una vez que se configura el campo authorized en el contexto, AUTHCALL puede usar la dirección authorized como msg.sender para iniciar una transacción. En cierto sentido, el usuario puede delegar su cuenta a un contrato inteligente a través de una firma en una transacción. Generalmente llamamos a este contrato inteligente delegado por el usuario como contrato invoker.
¿Cuál es el contenido específico de la firma del usuario? El usuario necesita firmar el siguiente contenido:
La dirección del invocador en el contenido anterior se refiere a la dirección del contrato invocador que el usuario desea delegar. EVM verificará si el contenido de la firma del usuario coincide con el contrato que realmente verifica la firma, evitando que el contenido de la firma AUTH del usuario sea utilizado por otros contratos.
Un nonce, por otro lado, es un identificador que impide que se reproduzcan las transacciones. Sin embargo, debe tenerse en cuenta que el código de operación AUTH verificará si el nonce de la firma es coherente con el nonce del EOA firmado actualmente y, en teoría, siempre que el usuario no utilice la cuenta EOA para iniciar una transacción para aumentar el valor del nonce, el contrato del invocador siempre podrá utilizar la firma AUTH emitida por el usuario. Esta es una gran vulnerabilidad de seguridad y significa que los usuarios que usan EIP3074 deben confiar en el proveedor de servicios de retransmisión que obtiene la firma. Si el proveedor de servicios de retransmisión que obtiene la firma del usuario es malintencionado, el proveedor de servicios puede reproducir la firma AUTH del usuario en algún momento para robar los activos del usuario.
Otro que presenta problemas de seguridad es el campo commit. El campo commit se utiliza para garantizar ciertas operaciones, los usuarios pueden controlar de manera más detallada sus derechos de firma dentro del commit, por ejemplo, escribiendo algún contenido en el commit para evitar que su contenido de firma se utilice para transferencias de ETH. En el documento EIP3074, el proponente presenta una serie de ejemplos de cómo utilizar el campo commit. Sin embargo, el problema es que la función del commit depende completamente de la definición del contrato inteligente, siendo esencialmente un contenido opcional. Diferentes contratos inteligentes pueden interpretar el contenido del commit de manera completamente inconsistente, e incluso algunos contratos pueden no leer en absoluto el contenido del commit. Si un usuario desea utilizar EIP3074 de manera segura, debe revisar brevemente el contrato inteligente por sí mismo.
Por último, echemos un vistazo al impacto de un EIP3074 en el mempool de transacciones actual de Ethereum. Con la introducción de EIP3074, un pirata informático puede usar una gran cantidad de cuentas para iniciar transacciones y luego usar EIP3074 transacciones para drenar el ETH en esas cuentas a la vez cuando la transacción está a punto de empaquetarse, lo que hará que todas las transacciones iniciadas anteriormente fallen. Este tipo de ataque puede tener un impacto considerable en los nodos de la capa de ejecución y es esencialmente un ataque DoS. Cabe señalar, sin embargo, que el EIP7702 utilizado para reemplazar EIP3074 también tiene este problema, pero EIP7702 introduce algunas limitaciones para evitar este problema, de las que hablaremos más adelante.
Además de los problemas que presenta el propio EIP3074 mencionado anteriormente, el autor de ERC4337, Yova, presentó más objeciones en su artículo Implications of EIP-3074 inclusion. En términos simples, estas objeciones incluyen principalmente:
Riesgo de centralización. Debido a las características especiales de la firma AUTH, los usuarios deben confiar completamente en los proveedores de servicios de retransmisión de EIP3074 y en la infraestructura subyacente. Al mismo tiempo, la infraestructura construida por protocolos de abstracción de cuentas como ERC4337 es completamente incompatible con EIP3074.
Seguridad del usuario. Como se mencionó anteriormente, el EIP3074 no tiene un método de control de acceso diseñado de manera uniforme, y el diseño del nonce de firma también presenta riesgos de seguridad, lo que podría dar lugar a problemas de seguridad graves.
Abstracción incompleta de la cuenta. En comparación con otras propuestas de abstracción de cuentas, EIP3074 está incompleta y no puede implementar funciones como cambiar los algoritmos de firma del usuario
Existe un problema con la experiencia del usuario. Cuando los usuarios necesitan delegar su cuenta a un contrato inteligente, deben realizar una firma AUTH una vez y luego publicar la llamada que contiene la firma AUTH en la cadena. Los usuarios deben realizar dos firmas.
EIP7702 es una propuesta presentada por Vitalik para reemplazar EIP3074. Esta propuesta no introduce nuevos códigos de operación EVM, sino que introduce un nuevo tipo de transacción, que se denomina SET_CODE_TX_TYPE. Una vez que el usuario inicia una transacción del tipo EIP7702, puede aumentar las funciones del contrato inteligente de su EOA mientras mantiene las funciones básicas del EOA. En resumen, el usuario puede continuar utilizando billeteras como MetaMask para iniciar transacciones, o puede ser llamado por otros usuarios en forma de contrato inteligente a la dirección EOA.
Presentamos la funcionalidad de EIP7702 con un simple ejemplo de transacciones en lote. Los usuarios pueden delegar su dirección EOA a un contrato inteligente que puede ejecutar llamadas en lote utilizando EIP7702, y luego los usuarios pueden invocar directamente su dirección EOA para iniciar transacciones en lote de manera similar a un contrato inteligente.
En términos de implementación técnica, en comparación con las transacciones tradicionales, EIP7702 introduce una lista de autorización_list de tipos de transacciones, que es [[chain_id, address, nonce, y_parity, r, s], ...]. donde address es la dirección del contrato inteligente que el usuario desea delegar, y nonce es el valor nonce actual del usuario. Los y_parity, r y s restantes son el resultado de la firma del usuario. En el proceso de ejecución específico, primero iteraremos a través de cada elemento en authorization_list para su procesamiento, y el método de procesamiento es restaurar la dirección EOA a través de parámetros de firma como y_parity y, a continuación, apuntar la dirección EOA al contrato inteligente con la dirección de dirección. Después de eso, la dirección EOA puede aceptar la llamada para reproducir la función del contrato.
Las ventajas de EIP7702 son muy evidentes, siendo la más fundamental que EIP7702 permite esencialmente que las EOA tengan la funcionalidad de contratos inteligentes. Esto es consistente con las reglas básicas de la abstracción de cuentas, como ERC4337, lo que significa que EIP7702 puede aprovechar toda la exploración actual en el ámbito de la abstracción de cuentas y reutilizar la infraestructura existente, por ejemplo, EIP7702 puede usar directamente la infraestructura de ERC4337. Actualmente, ERC4337 ya ha lanzado EntryPoint v0.8 que soporta llamadas de EIP7702. Desde la perspectiva de reutilizar la infraestructura existente, EIP7702 tiene el mismo grado de descentralización que ERC4337.
Por supuesto, EIP7702 en realidad tampoco ha solucionado completamente los problemas que surgieron en EIP3074. La mayoría de los problemas presentes en EIP3074 siguen existiendo. EIP7702 requiere que los contratos de cuentas tengan una implementación segura, pero el propio protocolo no garantiza ninguna seguridad. En las primeras etapas de la propuesta de EIP7702, algunos desarrolladores sugirieron estandarizar el nonce de firma para evitar posibles ataques de repetición, pero EIP7702 finalmente no aceptó estas sugerencias. Así que si los usuarios desean utilizar EIP7702 de manera segura, necesitarán revisar la seguridad del contrato por sí mismos.
Al mismo tiempo, EIP7702 también traerá una serie de problemas a la capa de ejecución. En el texto anterior, presentamos un posible método para llevar a cabo un ataque DoS en el grupo de memoria de la capa de ejecución utilizando EIP3074. Este método también es efectivo en EIP7702. Por lo tanto, EIP7702 sugiere que todas las direcciones EOA que utilizan EIP7702 solo pueden tener una transacción pendiente en el grupo de memoria, para evitar la aparición de ataques DoS a gran escala.
En resumen, el mayor problema de EIP3074 es que no ha implementado la funcionalidad completa de abstracción de cuentas, mientras que EIP7702 sí ha implementado la funcionalidad completa de abstracción de cuentas. La definición de lo que incluye una "abstracción de cuentas completa" es proporcionada por el autor de ERC4337. Al llegar a este punto, los lectores deberían poder entender por qué el equipo de ERC4337 se opuso a EIP3074, que finalmente fue reemplazado por EIP7702. En los siguientes párrafos, presentaremos todo el proceso de gobernanza y discusión.
El proceso de gobernanza de EIP3074 y EIP7702
EIP3074 se mencionó muy temprano en la reunión de desarrolladores principales de Ethereum. En la reunión #109 del 2 de abril de 2021, los desarrolladores principales de Ethereum discutieron brevemente sobre EIP3074. El resultado de la discusión fue muy simple:
Alexey planteó que el contenido de la firma EIP3074 presenta riesgos de seguridad, lo que podría causar graves pérdidas de seguridad a los usuarios, y sugiere que EIP3074 debe normalizar más el contenido específico de la firma AUTH, propuesta que cuenta con el apoyo de Martin.
James planteó que EIP3074 podría traer vulnerabilidades potenciales en la capa de ejecución, como ataques DoS, y sugirió que EIP3074 proporcionara un análisis de amenazas por escrito.
Alexey y Martin se quejan de que la calidad de la documentación de EIP3074 es regular, y han pasado mucho tiempo leyendo y entendiendo.
Martin considera que el núcleo de EIP3074 es la colaboración y la implementación con aplicaciones, especialmente con los desarrolladores de billeteras. El autor de EIP3074 ha indicado que ya ha tenido una serie de intercambios con los desarrolladores de aplicaciones.
Lo interesante es que Vitalik considera en esta conferencia que, de todos modos, Ethereum necesita una solución técnica que genere múltiples llamadas a partir de una transacción diseñada para EOA. Aunque EIP3074 presenta posibles problemas de seguridad, EIP3074 ofrece una posible solución técnica, y los desarrolladores deben avanzar sobre la base de EIP3074.
Claramente, debido a los problemas de seguridad de EIP3074, esta reunión no incluyó EIP3074 en la actualización de Londres.
En la reunión #115 del 11 de junio de 2021, los desarrolladores de EIP3074 presentaron un informe sobre auditoría de seguridad, y la reunión se centró principalmente en los problemas de seguridad de EIP3074. Una conclusión simple es que el contrato invocador de EIP3074 es muy importante dentro del sistema, por lo que la cuestión de si es necesario gestionar el contrato invocador es un problema. Los desarrolladores de EIP3074 desean realizar una prueba formal del contrato invocador para aumentar la seguridad.
Por supuesto, también hubo parte de la discusión sobre algunos contratos que utilizan msg.sender == tx.origin para determinar si la dirección de llamada es EOA. Cuando se introduzca EIP3074, estas verificaciones se volverán obsoletas, pero la conclusión es que la pérdida de estas verificaciones no generará problemas de seguridad graves. En resumen, esta reunión se centró principalmente en que el proponente de EIP3074 presentara los resultados de la auditoría de seguridad de 3074 a los desarrolladores principales. La conclusión final de la reunión es que 3074 aún necesita considerar el problema de los contratos invocadores, y se recomienda no incluirlo en la bifurcación dura de Londres.
En la reunión #116 del 25 de junio de 2021, Yova, uno de los autores principales de ERC4337, presentó materiales sobre un caso para una alternativa más simple al EIP 3074. Este material señala que EIP3074 presenta varios problemas de seguridad y sugiere modificar algunos de sus contenidos, como restringir el contenido del campo commit en la firma, exigiendo que el campo commit tenga la forma {nonce,to,gas,calldata,value,chainid}. Con este patrón de firma, EIP3074 solo puede utilizarse para ejecutar ciertas transacciones específicas para garantizar la seguridad de las transacciones.
En esta reunión, el autor de EIP3074 respondió al material presentado por Yova:
Se espera que la dirección del contrato invoker se incluya en las normas de EIP, y luego los desarrolladores principales de Ethereum escribirán un contrato invoker seguro para evitar problemas de seguridad.
En cuanto al contenido del commit en la firma, los desarrolladores de EIP3074 creen que esto es completamente un problema del usuario y del software de la billetera, y no es necesario estandarizarlo dentro del EIP.
Vitalik presentó los siguientes tres puntos en esta reunión:
EIP3074 aún utiliza el tradicional esquema de firma secp256k1 que no puede lograr características resistentes a la computación cuántica.
EIP3074 no tiene compatibilidad futura, y usar EIP3074 tampoco puede hacer que un EOA evolucione a una cuenta de contrato inteligente.
EIP3074 tiene un ciclo de vida limitado. 3074 introduce dos códigos de preensamblador, AUTH y AUTHCALL, pero según la hoja de ruta de la abstracción de cuentas, en el futuro, todas las billeteras en Ethereum podrían ser billeteras de contratos inteligentes, y los códigos de preensamblador de EIP3074 serán obsoletos en el futuro.
En la reunión #131 del 4 de febrero de 2022, los desarrolladores discutieron los tipos de EIP que deberían incluirse en la actualización de ShangHai. EIP3074 fue parte de la discusión, pero los desarrolladores simplemente sincronizaron el estado de desarrollo de EIP3074. Cabe destacar que, antes de que comenzara la reunión, Nethermind escribió el artículo "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", en el que no se incluyeron objeciones a EIP3074.
En la reunión #167 del 3 de agosto de 2023, los desarrolladores principales mencionaron EIP3074 al discutir otro EIP5806. EIP5806 es un mecanismo que permite a un EOA invocar contratos externos mediante el uso de deleGate.io call durante el proceso de transacción. Esta propuesta es, en cierto modo, similar a EIP7702. Sin embargo, los desarrolladores principales también expresaron dudas sobre la seguridad de esta propuesta; Ansgar señaló que EIP3074 no pudo ser incluido en la bifurcación dura debido a posibles problemas de seguridad, mientras que EIP5806 es una propuesta más radical.
En la reunión #182 del 29 de febrero de 2024, los desarrolladores discutieron en detalle si el EIP3074 debería ser incluido en la actualización de Pectra. Vitalik propuso que cualquier estándar de abstracción de cuentas debe tener las siguientes tres funciones:
Rotación de claves
Desactivación de claves
Compatible con firmas resistentes a la computación cuántica
Los comentarios de Vitalik sobre EIP5806 pueden ser una mejor opción que EIP3074. Andrew cree que EIP3074 es más versátil que EIP5806 y recomienda usar EIP3074. Vitalik responde a Andrew, argumentando que todas las billeteras en el futuro pueden ser billeteras de contratos inteligentes, y que si eso sucede, el código de operación preensamblado introducido por EIP3074 será invalidado. Yoav, el autor del ERC4337, hizo una larga presentación en la conferencia, que abarcó los siguientes temas:
EIP3074 podría provocar ataques DoS en el pool de memoria de Ethereum, mientras que ERC4337 ha realizado una gran cantidad de investigaciones sobre esta parte y ha propuesto algunas reglas para evitar ataques.
EIP3074 requiere que el usuario firme dos veces al iniciar transacciones en lote, lo cual es irracional.
EIP3074 requiere el uso de un releyente centralizado
Yova tiende a utilizar EIP5806 como solución de abstracción de cuentas.
En la reunión interna Meeting #183 del 14 de marzo de 2024, los desarrolladores principales invitaron a Dan Finlay de MetaMask para discutir la opinión sobre EIP3074 respecto a las billeteras. Dan tiene una actitud favorable hacia EIP3074 y señala que MetaMask también brindará apoyo para las pruebas de EIP3074. MetaMask considera que EIP3074 permite que las EOA disfruten de todas las funciones de la abstracción de cuentas. En términos de seguridad, EIP3074 ofrece a los proveedores de billeteras una solución de separación de claves frías y calientes. Los proveedores de billeteras pueden poseer la firma EIP3074 de la EOA para iniciar transacciones, los usuarios pueden usar claves privadas calientes en transacciones normales, pero las claves privadas frías pueden guardarse en la billetera de hardware del usuario. Cuando se detecta una situación de emergencia, el usuario puede iniciar una transacción para revocar la firma EIP3074 utilizando la clave privada fría en la billetera fría. Esta solución de separación de claves frías y calientes brinda flexibilidad a los proveedores de billeteras.
Vitalik señala que en EIP3074, los diseñadores de billeteras deben crear una lógica de autorización estricta para evitar que las firmas de EIP3074 de los usuarios sean mal utilizadas. Curiosamente, al discutir la adición de soporte para EIP3074 en MetaMask, Vitalik mencionó que se podría utilizar L2 como una solución de transición, es decir, cualquier modificación en la nueva capa de ejecución debería practicarse primero en L2, ya que el volumen de fondos en L2 es limitado, y aunque ocurriera un problema grave, las pérdidas serían significativas.
Dror Tiros señaló en la discusión que la mejor manera de garantizar la seguridad de EIP3074 es que el equipo oficial de Ethereum proporcione directamente el contrato invoker. Sin embargo, Dan Finlay se opuso a la idea de que el contrato sea proporcionado oficialmente, argumentando que el contrato invoker debería ser decidido completamente por los usuarios, y que el mercado finalmente elegiría el contrato invoker más seguro.
Ansgar sigue insistiendo en que EIP3074 una firma debe corresponder a una sola transacción, y que los proveedores de servicios de billetera no deben reutilizar las firmas de los usuarios para iniciar transacciones, pero Dan Finlay también se opuso. Dan Finlay cree que EIP3074 debe estar firmada por una billetera fría, y luego el proveedor de servicios de billetera puede reutilizar la firma para iniciar transacciones directamente para el usuario, y si se requiere que el usuario vuelva a firmar cada vez, la clave privada fría se puede usar varias veces. Esto es inconsistente con la idea de separar las claves privadas calientes y frías.
En esta reunión, los desarrolladores principales discutieron otro tema importante: la lista de inclusión. La lista de inclusión es un medio para aumentar las propiedades de resistencia a la censura de Ethereum. En términos simples, la lista de inclusión permite que algunas transacciones sean comprometidas para ser incluidas directamente en el siguiente bloque. Sin embargo, los desarrolladores principales señalaron que EIP3074 es incompatible con la lista de inclusión.
En la reunión #185 del 11 de abril de 2024, la mayoría de las implementaciones del cliente dentro de la reunión acordaron que EIP3074 se incluya en la bifurcación dura de Pectra, pero Geth se opuso, argumentando que EIP3074 podría causar problemas con los árboles Verkle. Danno también se opuso, ya que EIP3074 podría llevar a la reutilización de firmas. Yoav también manifestó su oposición, proponiendo un esquema para atacar el pool de memoria usando EIP3074 y transacciones Blob. En términos simples, un atacante podría lanzar una gran cantidad de transacciones Blob, que contienen una gran cantidad de datos, y luego utilizar EIP3074 para invalidar todas estas transacciones Blob.
En resumen, en esta reunión, todos los desarrolladores de clientes acordaron que EIP3074 se incluyera en la actualización final.
En la reunión #187 del 9 de mayo de 2024, los desarrolladores principales discutieron por primera vez el tema de EIP7702 como reemplazo de EIP3074. EIP7702 se completó 90 minutos antes de que comenzara la reunión de desarrolladores principales de Vitalik. Durante la reunión, los desarrolladores principales aceptaron que EIP7702 es un estándar superior a EIP3074. No hubo voces en contra de EIP7702 en esta reunión, aunque algunos investigadores señalaron que EIP7702 también presenta propiedades de irreversibilidad similares a EIP3074, lo que podría llevar a problemas de seguridad de fondos.
En la reunión #188 del 23 de mayo de 2024, los desarrolladores principales discutieron la posibilidad de reemplazar EIP7702 por EIP3074. La conclusión final de esta reunión fue utilizar EIP7702 en lugar de EIP3074 como estándar de abstracción de cuentas en la bifurcación dura de Pectra. Vitalik señaló que EIP7702 también tiene algunas propiedades de irreversibilidad que son consistentes con EIP3074, y estas propiedades ya se habían discutido en gran medida al hablar sobre EIP3074. Es bastante interesante que hubo una gran cantidad de representantes de ERC4337 participando en la discusión durante la reunión.
De hecho, la discusión sobre el reemplazo de EIP3074 por EIP7702 ya se había debatido ampliamente antes de 188 reuniones del desarrollador principal, y el resultado de esa discusión fue que 3074 sería reemplazado, por lo que no hubo mucha controversia en la reunión del desarrollador principal.
hoja de ruta y resolución
La infraestructura básica central de la abstracción de cuentas, Zerodev, publicó un artículo interesante tras enterarse de que EIP3074 sería reemplazada. El título del artículo es "Reflections on Ethereum Governance Following the 3074 Saga" y la conclusión de este artículo es que EIP7702 es una buena propuesta que puede beneficiar a todos los usuarios. Sin embargo, el proceso de gobernanza de EIP7702 para reemplazar EIP3074 no es el mejor, por las siguientes razones:
EIP3074 ha pasado por un largo proceso de discusión, en el texto anterior ya hemos introducido las múltiples discusiones sobre EIP3074 en la reunión de desarrolladores principales.
EIP3074 recibió una gran oposición de la comunidad ERC4337 después de ser confirmado para ser incluido en la actualización de Pectra. Por supuesto, en el texto anterior, ya hemos señalado que el desarrollador principal de ERC4337, yova, ha expresado en varias ocasiones su oposición a EIP3074 en las reuniones de desarrolladores principales.
Zerodev considera que el mejor camino de gobernanza debería ser que la comunidad de ERC4337 participe ampliamente y exprese sus opiniones durante el largo proceso de discusión de desarrolladores principales de EIP3074.
Los desarrolladores de EIP3074 creen que ERC4337 debería ser responsable de los fracasos de gobernanza. Esto se debe a que EIP3074 ha participado activamente en la gobernanza durante los últimos años y ha tenido múltiples intercambios con el desarrollador principal de ERC4337, yova.
La comunidad de ERC4337 considera que EIP3074 debería ser responsable principalmente del fracaso en la gobernanza. Los miembros de la comunidad de ERC4337 creen que Yova, como desarrollador principal de ERC4337, expresó su oposición a EIP3074 en varias reuniones de desarrolladores principales, pero parece que los desarrolladores principales no escucharon las opiniones. La mayoría de los miembros de la comunidad de ERC4337 no prestaron atención a la dinámica de gobernanza de EIP3074, y la mayoría de los miembros creen que EIP3074 es un estándar muerto. La comunidad de ERC4337 también cree que los desarrolladores principales no han comunicado activamente con la comunidad de ERC4337.
EIP3074 y ERC4337 ambos creen que han realizado un trabajo de gobernanza correcto, y que la otra parte debería ser la principal responsable del fracaso en la gobernanza. Es evidente que hay una razón más profunda que está en juego en este proceso de gobernanza.
En pocas palabras, la razón más profunda es en realidad la hoja de ruta de Ethereum. La hoja de ruta de Ethereum tiene más poder que las reuniones de los desarrolladores centrales. La hoja de ruta de la abstracción de cuentas se centra en el ERC4337. El EIP7702 es completamente compatible con el estándar ERC4337, pero el EIP3074 no es plenamente compatible con el estándar ERC4337. Por lo tanto, desde la perspectiva de la hoja de ruta de Ethereum, el reemplazo del EIP3074 es algo que definitivamente sucederá.
Por supuesto, la hoja de ruta de Ethereum es una representación personal de Vitalik sobre la visión futura de Ethereum. Si surge una disputa grave durante el proceso de gobernanza, Vitalik, como el definidor de la hoja de ruta, tiene la última palabra. Y fue precisamente el juicio de Vitalik lo que llevó a la sustitución de EIP3074.
El modelo de gobernanza de Ethereum es el modelo values ⇒ vision ⇒ roadmaps ⇒ clients, o simplemente el modelo VVRC. Su proceso de gobernanza es el siguiente:
valores, especialmente los valores de la comunidad, los valores de la comunidad de Ethereum incluyen la descentralización, la resistencia a la censura, etc.
visión, en realidad es el pensamiento personal de Vitalik sobre el futuro de Ethereum.
roadmaps, el investigador proporciona algunas consideraciones técnicas basadas en la visión, presentando un mapa de ruta de implementación más completo.
implementación del cliente, los desarrolladores principales del cliente discuten la hoja de ruta utilizando herramientas como reuniones de desarrolladores principales, y realizan las demandas dentro de la hoja de ruta.
El proceso anterior es el verdadero proceso de gobernanza de Ethereum. Podemos ver que la visión personal de Vitalik se encuentra en la parte subyacente del modelo de gobernanza de Ethereum, por lo que en caso de un debate serio dentro de la implementación del cliente, la opinión personal de Vitalik será definitiva.
Material de referencia
Introducción a ZeroDev
nulo
Introducción a ZeroDev
null
Notas sobre la hoja de ruta de la abstracción de cuentas - HackMD
Notas sobre la hoja de ruta de la Abstracción de Cuentas *Agradecimientos especiales a Vitalik y al equipo de AA por sus comentarios
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Guerra de gobernanza de Ethereum: EIP3074, ERC4337 y EIP7702
Autor: shew
Resumen
En la actualización de Pectra, surgió el problema de disputa de gobernanza más complejo. Cuando EIP3074 fue incluido en la actualización de Pectra, causó una gran controversia, especialmente por parte del equipo de ERC4337.
EIP3074 se ha estancado, el proceso de gobernanza no puede continuar. Hasta que Vitalik propuso EIP7702 que puso fin a las dudas del equipo de ERC4337 sobre EIP3074.
GCC Research descubrió que hay poca discusión en el mundo chino sobre los problemas de gobernanza de EIP3074 y ERC7702 en la actualización de Pectra. Pero este problema de gobernanza también refleja un problema profundo de gobernanza en Ethereum, es decir, bajo el principio de "el código es la ley", ¿quién puede controlar el contenido específico del código? Los problemas de gobernanza de EIP3074 y ERC7702 pueden brindarnos una buena perspectiva para observar el verdadero proceso de gobernanza interno de Ethereum.
La conclusión final de este artículo es una paráfrasis de un artículo de opinión publicado por ZeroDev, que afirma que el sistema de gobernanza de Ethereum es un modelo VVRC, y que la inclusión de cualquier propuesta debe alinearse primero con los valores de Ethereum (Value), y luego la propuesta debe reflejar la visión diseñada por Vitalik (Vision), la propuesta final debe reflejarse en la hoja de ruta (Roadmap), y finalmente ser discutida por los desarrolladores principales e incorporada al cliente (Client) Implementación.
GCC Research en el artículo anterior presentó que el EIP2537 solo tuvo problemas de implementación a nivel de cliente, lo que llevó a un retraso en su inclusión en el hard fork, mientras que el EIP3074 no fue incluido en el hard fork debido a problemas de visión y hoja de ruta, y los desarrolladores centrales de Ethereum eligieron directamente el EIP7702 escrito por Vitalik como la propuesta final de abstracción de cuentas.
Resumen del contenido de la propuesta
Antes de introducir los procesos de gobernanza específicos, primero necesitamos presentar brevemente el contenido específico relacionado con EIP3074, EIP7702 y ERC4337.
EIP3074 es una propuesta de capa de ejecución que requiere una actualización del software de los nodos para su implementación. El objetivo principal de EIP3074 es lograr la funcionalidad de patrocinio de gas y transacciones en lote. El llamado patrocinio de gas significa que los usuarios pueden pagar las tarifas de gas utilizando cualquier token, o que los usuarios pueden pagar las tarifas de gas fuera de línea. Sin embargo, es importante tener en cuenta que, a diferencia de otras propuestas de abstracción de cuentas que permiten cambiar el algoritmo de verificación de firmas, EIP3074 no permite a los usuarios utilizar ningún algoritmo de firma distinto a secp256k1. En otras palabras, EIP3074 no es una propuesta que satisfaga todas las funciones de abstracción de cuentas. Este es también un punto por el cual EIP3074 ha sido objeto de críticas.
Para lograr el objetivo esperado, EIP3074 introduce dos códigos de operación, que son AUTH y AUTHCALL. El código de operación AUTH puede verificar la firma, y una vez que la verificación de la firma se completa, este código de operación configurará el campo authorized en el contexto actual de EVM con la dirección del firmante. Una vez que se configura el campo authorized en el contexto, AUTHCALL puede usar la dirección authorized como msg.sender para iniciar una transacción. En cierto sentido, el usuario puede delegar su cuenta a un contrato inteligente a través de una firma en una transacción. Generalmente llamamos a este contrato inteligente delegado por el usuario como contrato invoker.
¿Cuál es el contenido específico de la firma del usuario? El usuario necesita firmar el siguiente contenido:
La dirección del invocador en el contenido anterior se refiere a la dirección del contrato invocador que el usuario desea delegar. EVM verificará si el contenido de la firma del usuario coincide con el contrato que realmente verifica la firma, evitando que el contenido de la firma AUTH del usuario sea utilizado por otros contratos.
Un nonce, por otro lado, es un identificador que impide que se reproduzcan las transacciones. Sin embargo, debe tenerse en cuenta que el código de operación AUTH verificará si el nonce de la firma es coherente con el nonce del EOA firmado actualmente y, en teoría, siempre que el usuario no utilice la cuenta EOA para iniciar una transacción para aumentar el valor del nonce, el contrato del invocador siempre podrá utilizar la firma AUTH emitida por el usuario. Esta es una gran vulnerabilidad de seguridad y significa que los usuarios que usan EIP3074 deben confiar en el proveedor de servicios de retransmisión que obtiene la firma. Si el proveedor de servicios de retransmisión que obtiene la firma del usuario es malintencionado, el proveedor de servicios puede reproducir la firma AUTH del usuario en algún momento para robar los activos del usuario.
Otro que presenta problemas de seguridad es el campo commit. El campo commit se utiliza para garantizar ciertas operaciones, los usuarios pueden controlar de manera más detallada sus derechos de firma dentro del commit, por ejemplo, escribiendo algún contenido en el commit para evitar que su contenido de firma se utilice para transferencias de ETH. En el documento EIP3074, el proponente presenta una serie de ejemplos de cómo utilizar el campo commit. Sin embargo, el problema es que la función del commit depende completamente de la definición del contrato inteligente, siendo esencialmente un contenido opcional. Diferentes contratos inteligentes pueden interpretar el contenido del commit de manera completamente inconsistente, e incluso algunos contratos pueden no leer en absoluto el contenido del commit. Si un usuario desea utilizar EIP3074 de manera segura, debe revisar brevemente el contrato inteligente por sí mismo.
Por último, echemos un vistazo al impacto de un EIP3074 en el mempool de transacciones actual de Ethereum. Con la introducción de EIP3074, un pirata informático puede usar una gran cantidad de cuentas para iniciar transacciones y luego usar EIP3074 transacciones para drenar el ETH en esas cuentas a la vez cuando la transacción está a punto de empaquetarse, lo que hará que todas las transacciones iniciadas anteriormente fallen. Este tipo de ataque puede tener un impacto considerable en los nodos de la capa de ejecución y es esencialmente un ataque DoS. Cabe señalar, sin embargo, que el EIP7702 utilizado para reemplazar EIP3074 también tiene este problema, pero EIP7702 introduce algunas limitaciones para evitar este problema, de las que hablaremos más adelante.
Además de los problemas que presenta el propio EIP3074 mencionado anteriormente, el autor de ERC4337, Yova, presentó más objeciones en su artículo Implications of EIP-3074 inclusion. En términos simples, estas objeciones incluyen principalmente:
EIP7702 es una propuesta presentada por Vitalik para reemplazar EIP3074. Esta propuesta no introduce nuevos códigos de operación EVM, sino que introduce un nuevo tipo de transacción, que se denomina SET_CODE_TX_TYPE. Una vez que el usuario inicia una transacción del tipo EIP7702, puede aumentar las funciones del contrato inteligente de su EOA mientras mantiene las funciones básicas del EOA. En resumen, el usuario puede continuar utilizando billeteras como MetaMask para iniciar transacciones, o puede ser llamado por otros usuarios en forma de contrato inteligente a la dirección EOA.
Presentamos la funcionalidad de EIP7702 con un simple ejemplo de transacciones en lote. Los usuarios pueden delegar su dirección EOA a un contrato inteligente que puede ejecutar llamadas en lote utilizando EIP7702, y luego los usuarios pueden invocar directamente su dirección EOA para iniciar transacciones en lote de manera similar a un contrato inteligente.
En términos de implementación técnica, en comparación con las transacciones tradicionales, EIP7702 introduce una lista de autorización_list de tipos de transacciones, que es [[chain_id, address, nonce, y_parity, r, s], ...]. donde address es la dirección del contrato inteligente que el usuario desea delegar, y nonce es el valor nonce actual del usuario. Los y_parity, r y s restantes son el resultado de la firma del usuario. En el proceso de ejecución específico, primero iteraremos a través de cada elemento en authorization_list para su procesamiento, y el método de procesamiento es restaurar la dirección EOA a través de parámetros de firma como y_parity y, a continuación, apuntar la dirección EOA al contrato inteligente con la dirección de dirección. Después de eso, la dirección EOA puede aceptar la llamada para reproducir la función del contrato.
Las ventajas de EIP7702 son muy evidentes, siendo la más fundamental que EIP7702 permite esencialmente que las EOA tengan la funcionalidad de contratos inteligentes. Esto es consistente con las reglas básicas de la abstracción de cuentas, como ERC4337, lo que significa que EIP7702 puede aprovechar toda la exploración actual en el ámbito de la abstracción de cuentas y reutilizar la infraestructura existente, por ejemplo, EIP7702 puede usar directamente la infraestructura de ERC4337. Actualmente, ERC4337 ya ha lanzado EntryPoint v0.8 que soporta llamadas de EIP7702. Desde la perspectiva de reutilizar la infraestructura existente, EIP7702 tiene el mismo grado de descentralización que ERC4337.
Por supuesto, EIP7702 en realidad tampoco ha solucionado completamente los problemas que surgieron en EIP3074. La mayoría de los problemas presentes en EIP3074 siguen existiendo. EIP7702 requiere que los contratos de cuentas tengan una implementación segura, pero el propio protocolo no garantiza ninguna seguridad. En las primeras etapas de la propuesta de EIP7702, algunos desarrolladores sugirieron estandarizar el nonce de firma para evitar posibles ataques de repetición, pero EIP7702 finalmente no aceptó estas sugerencias. Así que si los usuarios desean utilizar EIP7702 de manera segura, necesitarán revisar la seguridad del contrato por sí mismos.
Al mismo tiempo, EIP7702 también traerá una serie de problemas a la capa de ejecución. En el texto anterior, presentamos un posible método para llevar a cabo un ataque DoS en el grupo de memoria de la capa de ejecución utilizando EIP3074. Este método también es efectivo en EIP7702. Por lo tanto, EIP7702 sugiere que todas las direcciones EOA que utilizan EIP7702 solo pueden tener una transacción pendiente en el grupo de memoria, para evitar la aparición de ataques DoS a gran escala.
En resumen, el mayor problema de EIP3074 es que no ha implementado la funcionalidad completa de abstracción de cuentas, mientras que EIP7702 sí ha implementado la funcionalidad completa de abstracción de cuentas. La definición de lo que incluye una "abstracción de cuentas completa" es proporcionada por el autor de ERC4337. Al llegar a este punto, los lectores deberían poder entender por qué el equipo de ERC4337 se opuso a EIP3074, que finalmente fue reemplazado por EIP7702. En los siguientes párrafos, presentaremos todo el proceso de gobernanza y discusión.
El proceso de gobernanza de EIP3074 y EIP7702
EIP3074 se mencionó muy temprano en la reunión de desarrolladores principales de Ethereum. En la reunión #109 del 2 de abril de 2021, los desarrolladores principales de Ethereum discutieron brevemente sobre EIP3074. El resultado de la discusión fue muy simple:
Lo interesante es que Vitalik considera en esta conferencia que, de todos modos, Ethereum necesita una solución técnica que genere múltiples llamadas a partir de una transacción diseñada para EOA. Aunque EIP3074 presenta posibles problemas de seguridad, EIP3074 ofrece una posible solución técnica, y los desarrolladores deben avanzar sobre la base de EIP3074.
Claramente, debido a los problemas de seguridad de EIP3074, esta reunión no incluyó EIP3074 en la actualización de Londres.
En la reunión #115 del 11 de junio de 2021, los desarrolladores de EIP3074 presentaron un informe sobre auditoría de seguridad, y la reunión se centró principalmente en los problemas de seguridad de EIP3074. Una conclusión simple es que el contrato invocador de EIP3074 es muy importante dentro del sistema, por lo que la cuestión de si es necesario gestionar el contrato invocador es un problema. Los desarrolladores de EIP3074 desean realizar una prueba formal del contrato invocador para aumentar la seguridad.
Por supuesto, también hubo parte de la discusión sobre algunos contratos que utilizan msg.sender == tx.origin para determinar si la dirección de llamada es EOA. Cuando se introduzca EIP3074, estas verificaciones se volverán obsoletas, pero la conclusión es que la pérdida de estas verificaciones no generará problemas de seguridad graves. En resumen, esta reunión se centró principalmente en que el proponente de EIP3074 presentara los resultados de la auditoría de seguridad de 3074 a los desarrolladores principales. La conclusión final de la reunión es que 3074 aún necesita considerar el problema de los contratos invocadores, y se recomienda no incluirlo en la bifurcación dura de Londres.
En la reunión #116 del 25 de junio de 2021, Yova, uno de los autores principales de ERC4337, presentó materiales sobre un caso para una alternativa más simple al EIP 3074. Este material señala que EIP3074 presenta varios problemas de seguridad y sugiere modificar algunos de sus contenidos, como restringir el contenido del campo commit en la firma, exigiendo que el campo commit tenga la forma {nonce,to,gas,calldata,value,chainid}. Con este patrón de firma, EIP3074 solo puede utilizarse para ejecutar ciertas transacciones específicas para garantizar la seguridad de las transacciones.
En esta reunión, el autor de EIP3074 respondió al material presentado por Yova:
Vitalik presentó los siguientes tres puntos en esta reunión:
En la reunión #131 del 4 de febrero de 2022, los desarrolladores discutieron los tipos de EIP que deberían incluirse en la actualización de ShangHai. EIP3074 fue parte de la discusión, pero los desarrolladores simplemente sincronizaron el estado de desarrollo de EIP3074. Cabe destacar que, antes de que comenzara la reunión, Nethermind escribió el artículo "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", en el que no se incluyeron objeciones a EIP3074.
En la reunión #167 del 3 de agosto de 2023, los desarrolladores principales mencionaron EIP3074 al discutir otro EIP5806. EIP5806 es un mecanismo que permite a un EOA invocar contratos externos mediante el uso de deleGate.io call durante el proceso de transacción. Esta propuesta es, en cierto modo, similar a EIP7702. Sin embargo, los desarrolladores principales también expresaron dudas sobre la seguridad de esta propuesta; Ansgar señaló que EIP3074 no pudo ser incluido en la bifurcación dura debido a posibles problemas de seguridad, mientras que EIP5806 es una propuesta más radical.
En la reunión #182 del 29 de febrero de 2024, los desarrolladores discutieron en detalle si el EIP3074 debería ser incluido en la actualización de Pectra. Vitalik propuso que cualquier estándar de abstracción de cuentas debe tener las siguientes tres funciones:
Los comentarios de Vitalik sobre EIP5806 pueden ser una mejor opción que EIP3074. Andrew cree que EIP3074 es más versátil que EIP5806 y recomienda usar EIP3074. Vitalik responde a Andrew, argumentando que todas las billeteras en el futuro pueden ser billeteras de contratos inteligentes, y que si eso sucede, el código de operación preensamblado introducido por EIP3074 será invalidado. Yoav, el autor del ERC4337, hizo una larga presentación en la conferencia, que abarcó los siguientes temas:
Yova tiende a utilizar EIP5806 como solución de abstracción de cuentas.
En la reunión interna Meeting #183 del 14 de marzo de 2024, los desarrolladores principales invitaron a Dan Finlay de MetaMask para discutir la opinión sobre EIP3074 respecto a las billeteras. Dan tiene una actitud favorable hacia EIP3074 y señala que MetaMask también brindará apoyo para las pruebas de EIP3074. MetaMask considera que EIP3074 permite que las EOA disfruten de todas las funciones de la abstracción de cuentas. En términos de seguridad, EIP3074 ofrece a los proveedores de billeteras una solución de separación de claves frías y calientes. Los proveedores de billeteras pueden poseer la firma EIP3074 de la EOA para iniciar transacciones, los usuarios pueden usar claves privadas calientes en transacciones normales, pero las claves privadas frías pueden guardarse en la billetera de hardware del usuario. Cuando se detecta una situación de emergencia, el usuario puede iniciar una transacción para revocar la firma EIP3074 utilizando la clave privada fría en la billetera fría. Esta solución de separación de claves frías y calientes brinda flexibilidad a los proveedores de billeteras.
Vitalik señala que en EIP3074, los diseñadores de billeteras deben crear una lógica de autorización estricta para evitar que las firmas de EIP3074 de los usuarios sean mal utilizadas. Curiosamente, al discutir la adición de soporte para EIP3074 en MetaMask, Vitalik mencionó que se podría utilizar L2 como una solución de transición, es decir, cualquier modificación en la nueva capa de ejecución debería practicarse primero en L2, ya que el volumen de fondos en L2 es limitado, y aunque ocurriera un problema grave, las pérdidas serían significativas.
Dror Tiros señaló en la discusión que la mejor manera de garantizar la seguridad de EIP3074 es que el equipo oficial de Ethereum proporcione directamente el contrato invoker. Sin embargo, Dan Finlay se opuso a la idea de que el contrato sea proporcionado oficialmente, argumentando que el contrato invoker debería ser decidido completamente por los usuarios, y que el mercado finalmente elegiría el contrato invoker más seguro.
Ansgar sigue insistiendo en que EIP3074 una firma debe corresponder a una sola transacción, y que los proveedores de servicios de billetera no deben reutilizar las firmas de los usuarios para iniciar transacciones, pero Dan Finlay también se opuso. Dan Finlay cree que EIP3074 debe estar firmada por una billetera fría, y luego el proveedor de servicios de billetera puede reutilizar la firma para iniciar transacciones directamente para el usuario, y si se requiere que el usuario vuelva a firmar cada vez, la clave privada fría se puede usar varias veces. Esto es inconsistente con la idea de separar las claves privadas calientes y frías.
En esta reunión, los desarrolladores principales discutieron otro tema importante: la lista de inclusión. La lista de inclusión es un medio para aumentar las propiedades de resistencia a la censura de Ethereum. En términos simples, la lista de inclusión permite que algunas transacciones sean comprometidas para ser incluidas directamente en el siguiente bloque. Sin embargo, los desarrolladores principales señalaron que EIP3074 es incompatible con la lista de inclusión.
En la reunión #185 del 11 de abril de 2024, la mayoría de las implementaciones del cliente dentro de la reunión acordaron que EIP3074 se incluya en la bifurcación dura de Pectra, pero Geth se opuso, argumentando que EIP3074 podría causar problemas con los árboles Verkle. Danno también se opuso, ya que EIP3074 podría llevar a la reutilización de firmas. Yoav también manifestó su oposición, proponiendo un esquema para atacar el pool de memoria usando EIP3074 y transacciones Blob. En términos simples, un atacante podría lanzar una gran cantidad de transacciones Blob, que contienen una gran cantidad de datos, y luego utilizar EIP3074 para invalidar todas estas transacciones Blob.
En resumen, en esta reunión, todos los desarrolladores de clientes acordaron que EIP3074 se incluyera en la actualización final.
En la reunión #187 del 9 de mayo de 2024, los desarrolladores principales discutieron por primera vez el tema de EIP7702 como reemplazo de EIP3074. EIP7702 se completó 90 minutos antes de que comenzara la reunión de desarrolladores principales de Vitalik. Durante la reunión, los desarrolladores principales aceptaron que EIP7702 es un estándar superior a EIP3074. No hubo voces en contra de EIP7702 en esta reunión, aunque algunos investigadores señalaron que EIP7702 también presenta propiedades de irreversibilidad similares a EIP3074, lo que podría llevar a problemas de seguridad de fondos.
En la reunión #188 del 23 de mayo de 2024, los desarrolladores principales discutieron la posibilidad de reemplazar EIP7702 por EIP3074. La conclusión final de esta reunión fue utilizar EIP7702 en lugar de EIP3074 como estándar de abstracción de cuentas en la bifurcación dura de Pectra. Vitalik señaló que EIP7702 también tiene algunas propiedades de irreversibilidad que son consistentes con EIP3074, y estas propiedades ya se habían discutido en gran medida al hablar sobre EIP3074. Es bastante interesante que hubo una gran cantidad de representantes de ERC4337 participando en la discusión durante la reunión.
De hecho, la discusión sobre el reemplazo de EIP3074 por EIP7702 ya se había debatido ampliamente antes de 188 reuniones del desarrollador principal, y el resultado de esa discusión fue que 3074 sería reemplazado, por lo que no hubo mucha controversia en la reunión del desarrollador principal.
hoja de ruta y resolución
La infraestructura básica central de la abstracción de cuentas, Zerodev, publicó un artículo interesante tras enterarse de que EIP3074 sería reemplazada. El título del artículo es "Reflections on Ethereum Governance Following the 3074 Saga" y la conclusión de este artículo es que EIP7702 es una buena propuesta que puede beneficiar a todos los usuarios. Sin embargo, el proceso de gobernanza de EIP7702 para reemplazar EIP3074 no es el mejor, por las siguientes razones:
Zerodev considera que el mejor camino de gobernanza debería ser que la comunidad de ERC4337 participe ampliamente y exprese sus opiniones durante el largo proceso de discusión de desarrolladores principales de EIP3074.
Los desarrolladores de EIP3074 creen que ERC4337 debería ser responsable de los fracasos de gobernanza. Esto se debe a que EIP3074 ha participado activamente en la gobernanza durante los últimos años y ha tenido múltiples intercambios con el desarrollador principal de ERC4337, yova.
La comunidad de ERC4337 considera que EIP3074 debería ser responsable principalmente del fracaso en la gobernanza. Los miembros de la comunidad de ERC4337 creen que Yova, como desarrollador principal de ERC4337, expresó su oposición a EIP3074 en varias reuniones de desarrolladores principales, pero parece que los desarrolladores principales no escucharon las opiniones. La mayoría de los miembros de la comunidad de ERC4337 no prestaron atención a la dinámica de gobernanza de EIP3074, y la mayoría de los miembros creen que EIP3074 es un estándar muerto. La comunidad de ERC4337 también cree que los desarrolladores principales no han comunicado activamente con la comunidad de ERC4337.
EIP3074 y ERC4337 ambos creen que han realizado un trabajo de gobernanza correcto, y que la otra parte debería ser la principal responsable del fracaso en la gobernanza. Es evidente que hay una razón más profunda que está en juego en este proceso de gobernanza.
En pocas palabras, la razón más profunda es en realidad la hoja de ruta de Ethereum. La hoja de ruta de Ethereum tiene más poder que las reuniones de los desarrolladores centrales. La hoja de ruta de la abstracción de cuentas se centra en el ERC4337. El EIP7702 es completamente compatible con el estándar ERC4337, pero el EIP3074 no es plenamente compatible con el estándar ERC4337. Por lo tanto, desde la perspectiva de la hoja de ruta de Ethereum, el reemplazo del EIP3074 es algo que definitivamente sucederá.
Por supuesto, la hoja de ruta de Ethereum es una representación personal de Vitalik sobre la visión futura de Ethereum. Si surge una disputa grave durante el proceso de gobernanza, Vitalik, como el definidor de la hoja de ruta, tiene la última palabra. Y fue precisamente el juicio de Vitalik lo que llevó a la sustitución de EIP3074.
El modelo de gobernanza de Ethereum es el modelo values ⇒ vision ⇒ roadmaps ⇒ clients, o simplemente el modelo VVRC. Su proceso de gobernanza es el siguiente:
El proceso anterior es el verdadero proceso de gobernanza de Ethereum. Podemos ver que la visión personal de Vitalik se encuentra en la parte subyacente del modelo de gobernanza de Ethereum, por lo que en caso de un debate serio dentro de la implementación del cliente, la opinión personal de Vitalik será definitiva.