El sistema de gobernanza de Ethereum es el modelo VVRC, cualquier propuesta que se incluya debe cumplir primero con los valores de Ethereum (Value).
Escrito por: shew
Resumen
En la actualización de Pectra, surgió el problema de disputa de gobernanza más complejo. Cuando el EIP3074 fue incluido en la actualización de Pectra, causó una gran controversia, especialmente por parte del equipo de ERC4337.
EIP3074 se ha visto atrapado en un dilema, el proceso de gobernanza no puede continuar. Hasta que Vitalik propuso EIP7702, lo que puso fin a las dudas del equipo de ERC4337 sobre EIP3074.
GCC Research ha encontrado que hay pocas discusiones sobre los problemas de gobernanza de EIP3074 y ERC7702 en la actualización de Pectra en el mundo chino. Pero este problema de gobernanza también refleja un problema profundo de la gobernanza de Ethereum, es decir, bajo el principio de code is law, 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 dentro de Ethereum.
La conclusión final de este artículo se basa en un comentario publicado por ZeroDev, que señala que el sistema de gobernanza de Ethereum es el modelo VVRC. Cualquier propuesta que se incluya debe cumplir primero con los valores de Ethereum (Value), luego la propuesta debe reflejar la visión diseñada por Vitalik (Vision), y finalmente, la propuesta debe reflejarse en la hoja de ruta (Roadmap). Después de la discusión de los desarrolladores principales, se incorporará a la implementación del cliente (Client).
GCC Research en el artículo anterior presentó que el EIP2537 solo tuvo problemas de implementación en el nivel del 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 presentar el proceso de gobernanza específico, primero necesitamos hacer una breve introducción sobre el contenido específico relacionado con EIP3074, EIP7702 y ERC4337.
EIP3074 es una propuesta de capa de ejecución cuya ejecución requiere una actualización del software del nodo. El objetivo principal de EIP3074 es permitir el patrocinio de gas y el comercio a granel. El llamado patrocinio de gas significa que los usuarios pueden pagar las tarifas de gas con cualquier token, o los usuarios pueden pagar las tarifas de gas fuera de línea. Sin embargo, hay que tener en cuenta que EIP3074 no permite a los usuarios utilizar ningún algoritmo de firma que no sea secp256k1, en comparación con otras propuestas de abstracción de cuentas que permiten cambios en el algoritmo de verificación de firma. En otras palabras, EIP3074 no es una propuesta que satisfaga todas las abstracciones del relato. Este es también un punto por el que EIP3074 ha sido criticado.
Para alcanzar los objetivos esperados, 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 cuando la verificación de la firma es exitosa, este código configurará la dirección authorized en el contexto actual de EVM a la dirección del firmante. Una vez configurada la dirección authorized en el contexto, AUTHCALL puede utilizar la dirección authorized como msg.sender para iniciar la transacción. En cierto sentido, el usuario puede delegar su cuenta a un contrato inteligente para su uso en una transacción a través de la firma. 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 problema de seguridad es el campo de confirmación. El campo de confirmación se utiliza para garantizar ciertas operaciones, y los usuarios pueden ajustar el control de sus permisos de firma en la confirmación, como escribir algún contenido en la confirmación para evitar que el contenido de su firma se utilice para transferencias de ETH. En el documento EIP3074, el proponente proporciona una serie de ejemplos del uso del campo de confirmación. Pero el problema es que el papel de commit depende completamente de la definición del contrato inteligente, y es esencialmente un contenido opcional. Diferentes contratos inteligentes pueden analizar el contenido de la confirmación de manera completamente inconsistente, y algunos contratos pueden incluso no leer el contenido de la confirmación en absoluto. Si quieres utilizar EIP3074 de forma segura, simplemente tienes que revisar el contrato inteligente tú mismo.
Finalmente, presentamos el impacto de EIP3074 en el pool de memoria de transacciones actual de Ethereum. Con la introducción de EIP3074, puede surgir un método de ataque al pool de memoria, donde los hackers pueden iniciar transacciones utilizando una gran cantidad de cuentas, y luego, cuando las transacciones están a punto de ser empaquetadas, usar EIP3074 para vaciar de una sola vez los ETH en estas cuentas, lo que provocará que todas las transacciones iniciadas anteriormente fallen. Este tipo de ataque tendrá un impacto considerable en los nodos de la capa de ejecución, siendo esencialmente un ataque DoS. Sin embargo, es importante señalar que EIP7702, que se propuso como alternativa a EIP3074, también presenta este problema, aunque EIP7702 introdujo algunas restricciones para evitar que este problema ocurra, lo que discutiremos más adelante.
Además de los problemas que tiene EIP3074 mencionados anteriormente, el autor de ERC4337, Yova, presentó más objeciones en su artículo Implications of EIP-3074 inclusion. En términos sencillos, estas objeciones incluyen principalmente:
Riesgo de centralización. Debido a las propiedades 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 actualmente con protocolos de abstracción de cuentas como ERC4337 es completamente incompatible con EIP3074.
La seguridad del usuario. Como se mencionó anteriormente, EIP3074 no tiene un método de control de permisos de diseño unificado, y el diseño de nonce de firma también presenta riesgos de seguridad, lo que podría dar lugar a problemas de seguridad graves.
Funcionalidad de abstracción de cuentas incompleta. En comparación con otras propuestas de abstracción de cuentas, EIP3074 no es completa y no puede implementar funciones como cambiar el algoritmo de firma del usuario, entre otras.
Existen problemas en la experiencia del usuario. Cuando un usuario necesita delegar su cuenta a un contrato inteligente, debe realizar una firma AUTH y luego publicar la llamada que incluye la firma AUTH en la cadena. El usuario necesita realizar dos firmas.
EIP7702 es una propuesta de Vitalik para reemplazar a EIP3074. En lugar de introducir un nuevo código de operación de EVM, la propuesta introduce un nuevo tipo de transacción, que se denomina SET_CODE_TX_TYPE. Una vez que un usuario inicia un EIP7702 tipo de transacción, el usuario puede agregar la funcionalidad del contrato inteligente a su EOA mientras conserva la funcionalidad básica del EOA. En pocas palabras, los usuarios pueden continuar iniciando transacciones utilizando billeteras como MetaMask, u otros usuarios pueden llamar a direcciones EOA en forma de contratos inteligentes.
Presentamos la funcionalidad de EIP7702 con un ejemplo simple de transacción en lote. Los usuarios pueden utilizar EIP7702 para delegar su dirección EOA a un contrato inteligente que pueda ejecutar llamadas en lote, y luego los usuarios pueden invocar directamente su dirección EOA para iniciar transacciones en lote de forma contractual.
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 la ERC4337, lo que significa que EIP7702 puede aprovechar toda la exploración actual en el campo de la abstracción de cuentas y reutilizar la infraestructura existente, como EIP7702 puede utilizar directamente la infraestructura de ERC4337. Actualmente, ERC4337 ha lanzado EntryPoint v0.8 que admite llamadas a EIP7702. Desde la perspectiva de reutilizar la infraestructura existente, EIP7702 tiene un grado de descentralización equivalente al de ERC4337.
Por supuesto, EIP7702 en realidad tampoco ha solucionado completamente los problemas que surgieron en EIP3074. La mayoría de los problemas que existían en EIP3074 siguen existiendo. EIP7702 requiere que los contratos de cuenta tengan una implementación segura, mientras que el protocolo en sí no garantiza ninguna seguridad. En las primeras propuestas de EIP7702, algunos desarrolladores sugirieron estandarizar el nonce de la firma para evitar posibles ataques de repetición, pero EIP7702 finalmente no aceptó estas sugerencias. Así que si los usuarios desean utilizar EIP7702 de forma segura, deberán revisar la seguridad del contrato por sí mismos.
Al mismo tiempo, EIP7702 también crea una serie de problemas para la capa ejecutiva. Anteriormente, describimos una posible forma de explotar EIP3074 para realizar ataques DoS en grupos de memoria de capa de ejecución. Este método también es eficaz en EIP7702. Por lo tanto, EIP7702 recomienda que todas las direcciones EOA que usan EIP7702 solo tengan una transacción pendiente en el mempool para evitar ataques DoS a gran escala.
En resumen, el mayor problema de EIP3074 es que EIP3074 no ha implementado la funcionalidad completa de abstracción de cuentas, mientras que EIP7702 ha logrado implementar la funcionalidad completa de abstracción de cuentas. Y la definición de qué incluye "abstracción de cuentas completa" es precisamente lo que los autores de ERC4337 han establecido. Al llegar a este punto, el lector debería entender por qué el equipo de ERC4337 se opuso a EIP3074, que finalmente fue sustituido por EIP7702. En los siguientes párrafos, presentaremos todo el proceso de gobernanza y discusión.
Proceso de gobernanza de EIP3074 y EIP7702
EIP3074 se mencionó muy temprano en la reunión de desarrolladores centrales de Ethereum. En la reunión #109 del 2 de abril de 2021, los desarrolladores centrales de Ethereum discutieron brevemente sobre EIP3074. El resultado de la discusión fue muy simple:
Alexey planteó que el contenido de la firma de EIP3074 presenta riesgos de seguridad, lo que podría causar graves pérdidas de seguridad a los usuarios. Sugirió que EIP3074 normalice aún más el contenido específico de la firma AUTH, y esta propuesta recibió 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 gastado 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 desarrolladores de billeteras. El autor de EIP3074 ha indicado que ya ha llevado a cabo una serie de intercambios con desarrolladores de aplicaciones.
Es interesante que Vitalik, en esta conferencia, considere que de cualquier manera, 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 necesitan avanzar sobre la base de EIP3074.
Aparentemente, 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 se necesita 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 si algunas contrataciones utilizan msg.sender == tx.origin para determinar si la dirección de llamada es EOA. Cuando se introduzca EIP3074, estas determinaciones se volverán inválidas, pero la conclusión es que la invalidación de estas determinaciones no generará problemas de seguridad graves. En resumen, esta reunión se centró principalmente en que el proponente de EIP3074 presentó a los desarrolladores centrales los resultados de la auditoría de seguridad de 3074. La conclusión final de la reunión es que 3074 aún necesita considerar el problema del contrato invoker y se sugiere no incluirlo en la bifurcación dura de Londres.
En la reunión #116 del 25 de junio de 2021, Yova, el autor principal de ERC4337, presentó el material "A case for a simpler alternative to EIP 3074", que señala que EIP3074 presenta numerosos problemas de seguridad. Se sugiere modificar algunos de sus contenidos, como limitar el contenido del campo commit en la firma, exigiendo que el campo commit tenga la forma {nonce,to,gas,calldata,value,chainid}. Con este modo de firma, EIP3074 solo se puede utilizar 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 incluir la dirección del contrato invoker en las especificaciones de EIP, y luego que los desarrolladores centrales de Ethereum escriban un contrato invoker seguro para evitar problemas de seguridad.
Sobre el contenido de 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 necesita ser estandarizado en el EIP.
Vitalik presentó los siguientes tres puntos en esta conferencia:
EIP3074 aún utiliza el esquema de firma tradicional secp256k1 que no puede lograr características resistentes a la computación cuántica.
EIP3074 no tiene compatibilidad futura, y usar EIP3074 no puede hacer que un EOA evolucione a una cuenta de contrato inteligente.
EIP3074 tiene una vida útil limitada. 3074 introduce dos códigos de precompilación, 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 precompilación de EIP3074 serán desechados 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 incluido en el ámbito de discusión, pero los desarrolladores solo sincronizaron brevemente 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, el cual no contenía 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 estándar que permite a los EOA invocar contratos externos utilizando la llamada deleGate.io 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 el hard fork debido a posibles problemas de seguridad, y EIP5806 es una propuesta aún 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 cuenta debe tener las siguientes tres funciones:
Rotación de claves
Descarte de claves
Compatible con firmas resistentes a la computación cuántica
Vitalik señaló que EIP5806 podría ser una mejor opción que EIP3074. Andrew considera que EIP3074 es más general en comparación con EIP5806 y sugiere usar EIP3074. Vitalik refutó a Andrew, argumentando que en el futuro todas las billeteras podrían ser billeteras de contratos inteligentes, y una vez que eso ocurra, los códigos de operación precompilados introducidos por EIP3074 se volverían obsoletos. Yoav, como autor de ERC4337, hizo una presentación bastante extensa en esta reunión, cuyo contenido principal incluía:
EIP3074 podría llevar a un ataque DoS en el memory pool de Ethereum, mientras que el ERC4337 ha realizado una gran cantidad de investigación sobre esta parte y ha proporcionado 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 relé centralizado
Yova tiende más a utilizar EIP5806 como solución de abstracción de cuentas.
En la reunión #183 del 14 de marzo de 2024, los desarrolladores principales invitaron a Dan Finlay, de MetaMask, para discutir lo que piensa la billetera sobre EIP3074. Dan está a favor de EIP3074, señalando que MetaMask también apoyará las pruebas de EIP3074. MetaMask cree que EIP3074 puede permitir funcionalmente que EOA disfrute de la funcionalidad completa de la abstracción de cuentas. En términos de seguridad, EIP3074 proporciona una solución para los proveedores de servicios de billetera, es decir, separación de claves calientes y frías. El proveedor de servicios de billetera puede mantener la firma EIP3074 de EOA para iniciar una transacción, y los usuarios pueden usar la clave privada activa en transacciones normales, pero la clave privada fría se puede mantener en la billetera de hardware del usuario y, cuando se encuentra una emergencia, el usuario puede usar la clave privada fría en la billetera fría para iniciar una transacción para revocar la firma del EIP3074. Esta solución de separación de claves privadas en caliente y en frío brinda flexibilidad a los proveedores de billeteras.
Vitalik señala que dentro del EIP3074, los diseñadores de billeteras deben diseñar una lógica de autorización estricta para evitar el uso indebido de las firmas de EIP3074 de los usuarios. Curiosamente, al discutir la capacidad de MetaMask para agregar EIP3074 funcionalidad, Vitalik señaló que L2 podría usarse como una solución de transición, es decir, cualquier nuevo cambio en la capa de ejecución debe implementarse primero dentro de L2, ya que L2 tiene fondos limitados y puede causar graves pérdidas incluso si algo sale mal.
Dror Tiros señaló en la discusión que la mejor manera de asegurar la seguridad de EIP3074 es que Ethereum proporcione directamente el contrato invoker. Sin embargo, Dan Finlay se opuso a la idea de que la oficialidad proporcionara el contrato, 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 debería corresponder a una única transacción por firma; los proveedores de servicios de billetera no deberían reutilizar las firmas de los usuarios para iniciar transacciones, pero Dan Finlay también expresó su desacuerdo. Dan Finlay cree que EIP3074 debería ser firmado por una billetera fría, y luego los proveedores de servicios de billetera podrían reutilizar esa firma para iniciar transacciones directamente en nombre de los usuarios. Si se exige a los usuarios que firmen de nuevo cada vez, podría llevar a que la clave privada fría se utilice múltiples veces. Esto va en contra de la idea de separación de claves frías y calientes.
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 se comprometan a incluirse directamente en el siguiente bloque. Sin embargo, los desarrolladores principales señalaron que EIP3074 es contradictoria con la lista de inclusión.
En la reunión #185 del 11 de abril de 2024, la mayoría de las implementaciones de los clientes acordaron unirse EIP3074 la bifurcación dura de Pectra, pero Geth se opuso con el argumento de que EIP3074 podría causar problemas con el árbol Verkle. Danno todavía está en contra, ya que EIP3074 se puede reutilizar para firmas. Yoav también se opuso, sugiriendo una forma de atacar el mempool usando transacciones de EIP3074 y blobs. En términos sencillos, un atacante puede iniciar un gran número de transacciones de blobs que contienen una gran cantidad de datos y, a continuación, usar EIP3074 para invalidarlas todas.
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 la cuestión de que EIP7702 sustituya a EIP3074. Y EIP7702 fue completado 90 minutos antes del inicio de la reunión de desarrolladores principales de Vitalik. En la reunión, los desarrolladores principales reconocieron que EIP7702 es un estándar superior a EIP3074. No hubo voces en contra de EIP7702 en esta reunión, solo algunos investigadores consideraron que EIP7702 también presenta una propiedad de irreversibilidad similar a la de EIP3074, lo que podría causar problemas de seguridad de fondos.
En la reunión #188 del 23 de mayo de 2024, los desarrolladores centrales discutieron la posibilidad de reemplazar EIP3074 por EIP7702. La conclusión final de esta reunión fue usar EIP7702 en lugar de EIP3074 como el estándar de abstracción de cuentas en el hard fork de Pectra. Vitalik señaló que EIP7702 también tiene algunas propiedades de irreversibilidad consistentes con EIP3074, las cuales ya se habían discutido extensamente al tratar EIP3074. Resulta interesante que hubo una gran participación de representantes de ERC4337 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 de desarrolladores principales, y el resultado de esa discusión fue que 3074 sería reemplazado, por lo que no hubo mucha controversia en la reunión de desarrolladores principales.
Hoja de ruta y juicio
La infraestructura central de la abstracción de cuentas, Zerodev, publicó un artículo interesante tras enterarse de que EIP3074 sería reemplazado. El título del artículo es "Reflections on Ethereum Governance Following the 3074 Saga" y la conclusión del 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 óptimo, por razones que incluyen:
EIP3074 ha pasado por un largo proceso de discusión, en el texto anterior ya hemos presentado las múltiples discusiones sobre EIP3074 en la reunión de desarrolladores principales.
EIP3074 fue objeto de una gran oposición por parte de la comunidad ERC4337 tras ser confirmado su inclusión en la actualización 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 durante el largo proceso de discusión entre los desarrolladores centrales de EIP3074, la comunidad de ERC4337 debería participar ampliamente y expresar su opinión.
Los desarrolladores de EIP3074 creen que ERC4337 debería ser responsable de los fallos 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 ERC4337, por otro lado, cree que EIP3074 es el principal responsable de los fracasos de gobernanza. ERC4337 miembros de la comunidad creen que Yova, como desarrollador principal del ERC4337, ha expresado su oposición a EIP3074 en varias reuniones de desarrolladores principales, pero el desarrollador principal no parece estar escuchando. La mayoría de los miembros de la comunidad en el ERC4337 no prestan atención a la dinámica de gobernanza de EIP3074, y la mayoría de los miembros están de acuerdo en que EIP3074 es un estándar muerto. La comunidad ERC4337 también sintió que los desarrolladores principales no se estaban comunicando activamente con la comunidad 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, esta razón más profunda es en realidad la hoja de ruta de Ethereum. La hoja de ruta de Ethereum tiene más autoridad que la reunión principal de desarrolladores. La hoja de ruta para la abstracción de cuentas está centrada en ERC4337. EIP7702 es totalmente compatible con el estándar ERC4337, pero EIP3074 no es totalmente compatible con el estándar ERC4337. Entonces, desde la perspectiva de la hoja de ruta de Ethereum, es probable que ocurra EIP3074 reemplazo.
Por supuesto, la hoja de ruta de Ethereum es una exhibición de la visión futura de Ethereum que Vitalik tiene de manera personal. Si surge una controversia seria en el proceso de gobernanza de Ethereum, Vitalik, como definidor de la hoja de ruta, tiene la última palabra. Y fue precisamente la decisión de Vitalik la que hizo que EIP3074 fuera reemplazada.
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 descentralización, resistencia a la censura, etc.
vision, en realidad, es el pensamiento personal de Vitalik sobre el futuro de Ethereum.
roadmaps hoja de ruta, los investigadores proporcionan algunas consideraciones técnicas basadas en la visión para presentar un mapa de implementación más completo.
implementación del cliente, los desarrolladores principales del cliente utilizan herramientas como reuniones de desarrolladores principales para discutir la hoja de ruta y llevar a cabo los requisitos de la hoja de ruta.
El proceso mencionado es el verdadero proceso de gobernanza de Ethereum. Podemos ver que la visión personal de Vitalik se encuentra en la parte inferior del modelo de gobernanza de Ethereum, por lo que una vez que surjan serias disputas en la implementación del cliente, la opinión personal de Vitalik será el juicio final.
Referencia
Introducción a ZeroDev
null
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: EIP3074, ERC4337 y EIP7702 | Investigación GCC
Escrito por: shew
Resumen
En la actualización de Pectra, surgió el problema de disputa de gobernanza más complejo. Cuando el EIP3074 fue incluido en la actualización de Pectra, causó una gran controversia, especialmente por parte del equipo de ERC4337.
EIP3074 se ha visto atrapado en un dilema, el proceso de gobernanza no puede continuar. Hasta que Vitalik propuso EIP7702, lo que puso fin a las dudas del equipo de ERC4337 sobre EIP3074.
GCC Research ha encontrado que hay pocas discusiones sobre los problemas de gobernanza de EIP3074 y ERC7702 en la actualización de Pectra en el mundo chino. Pero este problema de gobernanza también refleja un problema profundo de la gobernanza de Ethereum, es decir, bajo el principio de code is law, 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 dentro de Ethereum.
La conclusión final de este artículo se basa en un comentario publicado por ZeroDev, que señala que el sistema de gobernanza de Ethereum es el modelo VVRC. Cualquier propuesta que se incluya debe cumplir primero con los valores de Ethereum (Value), luego la propuesta debe reflejar la visión diseñada por Vitalik (Vision), y finalmente, la propuesta debe reflejarse en la hoja de ruta (Roadmap). Después de la discusión de los desarrolladores principales, se incorporará a la implementación del cliente (Client).
GCC Research en el artículo anterior presentó que el EIP2537 solo tuvo problemas de implementación en el nivel del 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 presentar el proceso de gobernanza específico, primero necesitamos hacer una breve introducción sobre el contenido específico relacionado con EIP3074, EIP7702 y ERC4337.
EIP3074 es una propuesta de capa de ejecución cuya ejecución requiere una actualización del software del nodo. El objetivo principal de EIP3074 es permitir el patrocinio de gas y el comercio a granel. El llamado patrocinio de gas significa que los usuarios pueden pagar las tarifas de gas con cualquier token, o los usuarios pueden pagar las tarifas de gas fuera de línea. Sin embargo, hay que tener en cuenta que EIP3074 no permite a los usuarios utilizar ningún algoritmo de firma que no sea secp256k1, en comparación con otras propuestas de abstracción de cuentas que permiten cambios en el algoritmo de verificación de firma. En otras palabras, EIP3074 no es una propuesta que satisfaga todas las abstracciones del relato. Este es también un punto por el que EIP3074 ha sido criticado.
Para alcanzar los objetivos esperados, 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 cuando la verificación de la firma es exitosa, este código configurará la dirección authorized en el contexto actual de EVM a la dirección del firmante. Una vez configurada la dirección authorized en el contexto, AUTHCALL puede utilizar la dirección authorized como msg.sender para iniciar la transacción. En cierto sentido, el usuario puede delegar su cuenta a un contrato inteligente para su uso en una transacción a través de la firma. 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 problema de seguridad es el campo de confirmación. El campo de confirmación se utiliza para garantizar ciertas operaciones, y los usuarios pueden ajustar el control de sus permisos de firma en la confirmación, como escribir algún contenido en la confirmación para evitar que el contenido de su firma se utilice para transferencias de ETH. En el documento EIP3074, el proponente proporciona una serie de ejemplos del uso del campo de confirmación. Pero el problema es que el papel de commit depende completamente de la definición del contrato inteligente, y es esencialmente un contenido opcional. Diferentes contratos inteligentes pueden analizar el contenido de la confirmación de manera completamente inconsistente, y algunos contratos pueden incluso no leer el contenido de la confirmación en absoluto. Si quieres utilizar EIP3074 de forma segura, simplemente tienes que revisar el contrato inteligente tú mismo.
Finalmente, presentamos el impacto de EIP3074 en el pool de memoria de transacciones actual de Ethereum. Con la introducción de EIP3074, puede surgir un método de ataque al pool de memoria, donde los hackers pueden iniciar transacciones utilizando una gran cantidad de cuentas, y luego, cuando las transacciones están a punto de ser empaquetadas, usar EIP3074 para vaciar de una sola vez los ETH en estas cuentas, lo que provocará que todas las transacciones iniciadas anteriormente fallen. Este tipo de ataque tendrá un impacto considerable en los nodos de la capa de ejecución, siendo esencialmente un ataque DoS. Sin embargo, es importante señalar que EIP7702, que se propuso como alternativa a EIP3074, también presenta este problema, aunque EIP7702 introdujo algunas restricciones para evitar que este problema ocurra, lo que discutiremos más adelante.
Además de los problemas que tiene EIP3074 mencionados anteriormente, el autor de ERC4337, Yova, presentó más objeciones en su artículo Implications of EIP-3074 inclusion. En términos sencillos, estas objeciones incluyen principalmente:
EIP7702 es una propuesta de Vitalik para reemplazar a EIP3074. En lugar de introducir un nuevo código de operación de EVM, la propuesta introduce un nuevo tipo de transacción, que se denomina SET_CODE_TX_TYPE. Una vez que un usuario inicia un EIP7702 tipo de transacción, el usuario puede agregar la funcionalidad del contrato inteligente a su EOA mientras conserva la funcionalidad básica del EOA. En pocas palabras, los usuarios pueden continuar iniciando transacciones utilizando billeteras como MetaMask, u otros usuarios pueden llamar a direcciones EOA en forma de contratos inteligentes.
Presentamos la funcionalidad de EIP7702 con un ejemplo simple de transacción en lote. Los usuarios pueden utilizar EIP7702 para delegar su dirección EOA a un contrato inteligente que pueda ejecutar llamadas en lote, y luego los usuarios pueden invocar directamente su dirección EOA para iniciar transacciones en lote de forma contractual.
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 la ERC4337, lo que significa que EIP7702 puede aprovechar toda la exploración actual en el campo de la abstracción de cuentas y reutilizar la infraestructura existente, como EIP7702 puede utilizar directamente la infraestructura de ERC4337. Actualmente, ERC4337 ha lanzado EntryPoint v0.8 que admite llamadas a EIP7702. Desde la perspectiva de reutilizar la infraestructura existente, EIP7702 tiene un grado de descentralización equivalente al de ERC4337.
Por supuesto, EIP7702 en realidad tampoco ha solucionado completamente los problemas que surgieron en EIP3074. La mayoría de los problemas que existían en EIP3074 siguen existiendo. EIP7702 requiere que los contratos de cuenta tengan una implementación segura, mientras que el protocolo en sí no garantiza ninguna seguridad. En las primeras propuestas de EIP7702, algunos desarrolladores sugirieron estandarizar el nonce de la firma para evitar posibles ataques de repetición, pero EIP7702 finalmente no aceptó estas sugerencias. Así que si los usuarios desean utilizar EIP7702 de forma segura, deberán revisar la seguridad del contrato por sí mismos.
Al mismo tiempo, EIP7702 también crea una serie de problemas para la capa ejecutiva. Anteriormente, describimos una posible forma de explotar EIP3074 para realizar ataques DoS en grupos de memoria de capa de ejecución. Este método también es eficaz en EIP7702. Por lo tanto, EIP7702 recomienda que todas las direcciones EOA que usan EIP7702 solo tengan una transacción pendiente en el mempool para evitar ataques DoS a gran escala.
En resumen, el mayor problema de EIP3074 es que EIP3074 no ha implementado la funcionalidad completa de abstracción de cuentas, mientras que EIP7702 ha logrado implementar la funcionalidad completa de abstracción de cuentas. Y la definición de qué incluye "abstracción de cuentas completa" es precisamente lo que los autores de ERC4337 han establecido. Al llegar a este punto, el lector debería entender por qué el equipo de ERC4337 se opuso a EIP3074, que finalmente fue sustituido por EIP7702. En los siguientes párrafos, presentaremos todo el proceso de gobernanza y discusión.
Proceso de gobernanza de EIP3074 y EIP7702
EIP3074 se mencionó muy temprano en la reunión de desarrolladores centrales de Ethereum. En la reunión #109 del 2 de abril de 2021, los desarrolladores centrales de Ethereum discutieron brevemente sobre EIP3074. El resultado de la discusión fue muy simple:
Es interesante que Vitalik, en esta conferencia, considere que de cualquier manera, 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 necesitan avanzar sobre la base de EIP3074.
Aparentemente, 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 se necesita 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 si algunas contrataciones utilizan msg.sender == tx.origin para determinar si la dirección de llamada es EOA. Cuando se introduzca EIP3074, estas determinaciones se volverán inválidas, pero la conclusión es que la invalidación de estas determinaciones no generará problemas de seguridad graves. En resumen, esta reunión se centró principalmente en que el proponente de EIP3074 presentó a los desarrolladores centrales los resultados de la auditoría de seguridad de 3074. La conclusión final de la reunión es que 3074 aún necesita considerar el problema del contrato invoker y se sugiere no incluirlo en la bifurcación dura de Londres.
En la reunión #116 del 25 de junio de 2021, Yova, el autor principal de ERC4337, presentó el material "A case for a simpler alternative to EIP 3074", que señala que EIP3074 presenta numerosos problemas de seguridad. Se sugiere modificar algunos de sus contenidos, como limitar el contenido del campo commit en la firma, exigiendo que el campo commit tenga la forma {nonce,to,gas,calldata,value,chainid}. Con este modo de firma, EIP3074 solo se puede utilizar 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 conferencia:
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 incluido en el ámbito de discusión, pero los desarrolladores solo sincronizaron brevemente 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, el cual no contenía 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 estándar que permite a los EOA invocar contratos externos utilizando la llamada deleGate.io 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 el hard fork debido a posibles problemas de seguridad, y EIP5806 es una propuesta aún 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 cuenta debe tener las siguientes tres funciones:
Vitalik señaló que EIP5806 podría ser una mejor opción que EIP3074. Andrew considera que EIP3074 es más general en comparación con EIP5806 y sugiere usar EIP3074. Vitalik refutó a Andrew, argumentando que en el futuro todas las billeteras podrían ser billeteras de contratos inteligentes, y una vez que eso ocurra, los códigos de operación precompilados introducidos por EIP3074 se volverían obsoletos. Yoav, como autor de ERC4337, hizo una presentación bastante extensa en esta reunión, cuyo contenido principal incluía:
Yova tiende más a utilizar EIP5806 como solución de abstracción de cuentas.
En la reunión #183 del 14 de marzo de 2024, los desarrolladores principales invitaron a Dan Finlay, de MetaMask, para discutir lo que piensa la billetera sobre EIP3074. Dan está a favor de EIP3074, señalando que MetaMask también apoyará las pruebas de EIP3074. MetaMask cree que EIP3074 puede permitir funcionalmente que EOA disfrute de la funcionalidad completa de la abstracción de cuentas. En términos de seguridad, EIP3074 proporciona una solución para los proveedores de servicios de billetera, es decir, separación de claves calientes y frías. El proveedor de servicios de billetera puede mantener la firma EIP3074 de EOA para iniciar una transacción, y los usuarios pueden usar la clave privada activa en transacciones normales, pero la clave privada fría se puede mantener en la billetera de hardware del usuario y, cuando se encuentra una emergencia, el usuario puede usar la clave privada fría en la billetera fría para iniciar una transacción para revocar la firma del EIP3074. Esta solución de separación de claves privadas en caliente y en frío brinda flexibilidad a los proveedores de billeteras.
Vitalik señala que dentro del EIP3074, los diseñadores de billeteras deben diseñar una lógica de autorización estricta para evitar el uso indebido de las firmas de EIP3074 de los usuarios. Curiosamente, al discutir la capacidad de MetaMask para agregar EIP3074 funcionalidad, Vitalik señaló que L2 podría usarse como una solución de transición, es decir, cualquier nuevo cambio en la capa de ejecución debe implementarse primero dentro de L2, ya que L2 tiene fondos limitados y puede causar graves pérdidas incluso si algo sale mal.
Dror Tiros señaló en la discusión que la mejor manera de asegurar la seguridad de EIP3074 es que Ethereum proporcione directamente el contrato invoker. Sin embargo, Dan Finlay se opuso a la idea de que la oficialidad proporcionara el contrato, 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 debería corresponder a una única transacción por firma; los proveedores de servicios de billetera no deberían reutilizar las firmas de los usuarios para iniciar transacciones, pero Dan Finlay también expresó su desacuerdo. Dan Finlay cree que EIP3074 debería ser firmado por una billetera fría, y luego los proveedores de servicios de billetera podrían reutilizar esa firma para iniciar transacciones directamente en nombre de los usuarios. Si se exige a los usuarios que firmen de nuevo cada vez, podría llevar a que la clave privada fría se utilice múltiples veces. Esto va en contra de la idea de separación de claves frías y calientes.
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 se comprometan a incluirse directamente en el siguiente bloque. Sin embargo, los desarrolladores principales señalaron que EIP3074 es contradictoria con la lista de inclusión.
En la reunión #185 del 11 de abril de 2024, la mayoría de las implementaciones de los clientes acordaron unirse EIP3074 la bifurcación dura de Pectra, pero Geth se opuso con el argumento de que EIP3074 podría causar problemas con el árbol Verkle. Danno todavía está en contra, ya que EIP3074 se puede reutilizar para firmas. Yoav también se opuso, sugiriendo una forma de atacar el mempool usando transacciones de EIP3074 y blobs. En términos sencillos, un atacante puede iniciar un gran número de transacciones de blobs que contienen una gran cantidad de datos y, a continuación, usar EIP3074 para invalidarlas todas.
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 la cuestión de que EIP7702 sustituya a EIP3074. Y EIP7702 fue completado 90 minutos antes del inicio de la reunión de desarrolladores principales de Vitalik. En la reunión, los desarrolladores principales reconocieron que EIP7702 es un estándar superior a EIP3074. No hubo voces en contra de EIP7702 en esta reunión, solo algunos investigadores consideraron que EIP7702 también presenta una propiedad de irreversibilidad similar a la de EIP3074, lo que podría causar problemas de seguridad de fondos.
En la reunión #188 del 23 de mayo de 2024, los desarrolladores centrales discutieron la posibilidad de reemplazar EIP3074 por EIP7702. La conclusión final de esta reunión fue usar EIP7702 en lugar de EIP3074 como el estándar de abstracción de cuentas en el hard fork de Pectra. Vitalik señaló que EIP7702 también tiene algunas propiedades de irreversibilidad consistentes con EIP3074, las cuales ya se habían discutido extensamente al tratar EIP3074. Resulta interesante que hubo una gran participación de representantes de ERC4337 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 de desarrolladores principales, y el resultado de esa discusión fue que 3074 sería reemplazado, por lo que no hubo mucha controversia en la reunión de desarrolladores principales.
Hoja de ruta y juicio
La infraestructura central de la abstracción de cuentas, Zerodev, publicó un artículo interesante tras enterarse de que EIP3074 sería reemplazado. El título del artículo es "Reflections on Ethereum Governance Following the 3074 Saga" y la conclusión del 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 óptimo, por razones que incluyen:
Zerodev considera que el mejor camino de gobernanza debería ser que durante el largo proceso de discusión entre los desarrolladores centrales de EIP3074, la comunidad de ERC4337 debería participar ampliamente y expresar su opinión.
Los desarrolladores de EIP3074 creen que ERC4337 debería ser responsable de los fallos 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 ERC4337, por otro lado, cree que EIP3074 es el principal responsable de los fracasos de gobernanza. ERC4337 miembros de la comunidad creen que Yova, como desarrollador principal del ERC4337, ha expresado su oposición a EIP3074 en varias reuniones de desarrolladores principales, pero el desarrollador principal no parece estar escuchando. La mayoría de los miembros de la comunidad en el ERC4337 no prestan atención a la dinámica de gobernanza de EIP3074, y la mayoría de los miembros están de acuerdo en que EIP3074 es un estándar muerto. La comunidad ERC4337 también sintió que los desarrolladores principales no se estaban comunicando activamente con la comunidad 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, esta razón más profunda es en realidad la hoja de ruta de Ethereum. La hoja de ruta de Ethereum tiene más autoridad que la reunión principal de desarrolladores. La hoja de ruta para la abstracción de cuentas está centrada en ERC4337. EIP7702 es totalmente compatible con el estándar ERC4337, pero EIP3074 no es totalmente compatible con el estándar ERC4337. Entonces, desde la perspectiva de la hoja de ruta de Ethereum, es probable que ocurra EIP3074 reemplazo.
Por supuesto, la hoja de ruta de Ethereum es una exhibición de la visión futura de Ethereum que Vitalik tiene de manera personal. Si surge una controversia seria en el proceso de gobernanza de Ethereum, Vitalik, como definidor de la hoja de ruta, tiene la última palabra. Y fue precisamente la decisión de Vitalik la que hizo que EIP3074 fuera reemplazada.
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 mencionado es el verdadero proceso de gobernanza de Ethereum. Podemos ver que la visión personal de Vitalik se encuentra en la parte inferior del modelo de gobernanza de Ethereum, por lo que una vez que surjan serias disputas en la implementación del cliente, la opinión personal de Vitalik será el juicio final.