Interpretar el pasado y el futuro de la cuenta abstracta de la pista de carreras ETH desde 4337 hasta 7702

Introducción

Este artículo se divide en dos secciones principales:

En la primera mitad, partiendo de la primera propuesta de AA en 2015, se organizarán los principales contenidos de las propuestas de Eip hasta ahora, con la esperanza de explorar el proceso histórico de las propuestas de AA desde una perspectiva histórica y evaluar de manera integral las ventajas y desventajas de cada propuesta.

En la segunda mitad, se centra en comparar la respuesta del mercado a la depresión después de la presentación de EIP4337, y analiza más a fondo EIP7702, que está a punto de ser incluida en la próxima actualización de Ethereum. Una vez que se fusiona esta propuesta, cambiará completamente la forma de las aplicaciones on-chain.

EIP-7702 tiene un cambio revolucionario, escucha atentamente al señor Catorce.

1. Antecedentes de la abstracción de la cuenta

1.1 Significado y ubicación de la abstracción de la cuenta

El fundador de Ethereum, Vitalik, actualizó nuevamente la hoja de ruta de desarrollo de ETH a finales de 2023, pero no ha cambiado la configuración de la abstracción de cuentas. El modelo dominante actual es la transición de EIP-4337 a la siguiente etapa, la Conversión Voluntaria de EOA (cuenta de propietario externo)

Desde el lanzamiento de EIP4337 hace más de un año (anunciado oficialmente en WalletCon Denver el 1 de marzo de 2023, el contrato inteligente central ERC-4337 diseñado e implementado por los desarrolladores de la fundación ETH ha pasado la auditoría de OpenZeppelin y se considera que ha sido oficialmente lanzado Nodo).

Siempre ha sido ampliamente reconocido por los usuarios, pero no utilizado ampliamente. En este entorno de mercado contradictorio, el progreso de EIP-7702 se ha adelantado significativamente, e incluso se ha confirmado que se fusionará en la próxima actualización.

1.2 Estado actual del mercado de la abstracción de cuentas

Sin más preámbulos, veamos los datos.

Después de un año y medio de desarrollo, EIP4337 tiene solo un total de 12 millones de DIRECCIÓN bajo la cuenta de la cadena principal, y lo que sorprende más es que en la red principal de ETH, hay solo 6,764 DIRECCIÓN activas. Puede haber problemas con las estadísticas, pero al menos hay una gran diferencia en la cantidad de DIRECCIÓN entre EOA y CA. Tenga en cuenta que el número de DIRECCIÓN independientes en la red principal de ETH ha alcanzado los 270 millones (fuente de datos: ).

Se puede decir que en Mainnet, EIP4337 no ha tenido ningún desarrollo sustancial.

（Fuente de datos del gráfico: 01928374656574839201）

Sin embargo, esto no borra el valor fundamental de AA, ya que su diseño desde el principio con EIP4337 lo condena a no poder hacer frente a los graves problemas de compatibilidad hacia adelante en Mainnet, por lo que, junto con la incrustación generalizada de AA nativo en varias cadenas de capa L2, el número de direcciones de EIP4337 experimenta un aumento explosivo en L2, siendo los usuarios activos mensuales de base y polygon chain en julio 1 millón y 3 millones, respectivamente, lo cual es bastante impresionante.

Por lo tanto, no es que el diseño EIP4337 sea incorrecto, tiene muchas ventajas. Resumiremos sistemáticamente más tarde. La situación actual se debe a las diferencias entre Mainnet y L2, y necesitan soluciones adecuadas para cada uno.

2、¿Qué es la abstracción de cuenta?

abstracción de cuentas，suena confuso, pero en realidad resuelve el problema de la separación de la propiedad.

La arquitectura de la Máquina virtual de Ethereum (EVM) tiene dos tipos de cuentas, la cuenta externa (EOA) y la cuenta de contrato (Contract Account). La propiedad y el derecho de firma de la cuenta externa son en realidad poseídos por la misma entidad. La persona que posee la Llave privada no solo tiene la ‘propiedad’ de esta cuenta, sino también el derecho de ‘firmar y transferir todos los activos’.

Esto está determinado por la estructura de transacción de la cuenta ETH.

Desde la estructura en la siguiente imagen, podemos ver que las transacciones estándar de Ethereum no tienen una dirección ‘From’. Entonces, cuando hago una transferencia de fondos, ¿cuál es el fondo específico que se utiliza en la dirección ‘DIRECCIÓN’? En realidad, se obtiene la dirección ‘From’ a través de los parámetros VRS (es decir, la firma del usuario) que se descomprimen.

Aquí involucra conceptos como ECDSA y encriptación asimétrica, funciones de umbral unidireccionales, etc. No vamos a entrar en detalles, en resumen, la seguridad aquí está garantizada por la criptografía, lo que, por supuesto, ha llevado a la difícil situación actual de la consolidación de la propiedad en la dirección EOA.

Y el efecto central de EIP4337 es agregar el campo de Dirección del Remitente en el campo de transacción, lo que permite separar la Llave privada de la DIRECCIÓN operada.

Entonces, ¿por qué es tan importante la separación de la propiedad?

Porque el diseño de la cuenta externa (EOA) plantea más problemas:

1. La llave privada es difícil de proteger: perder la llave privada (ya sea por pérdida, ataque de hackers o por ser descifrada criptográficamente) significa perder todos los activos.
2. El protocolo nativo solo puede usar la firma y verificación ECDSA en la validación de transacciones.
3. Alta autorización de firma: no hay múltiples firmas nativas (la colaboración solo se puede lograr mediante Contratos inteligentes), una sola firma puede ejecutar cualquier operación.
4. Las tarifas de transacción solo se pueden pagar con ETH y no admiten transacciones en lotes.
5. Divulgación de la privacidad de la transacción: Las transacciones uno a uno son susceptibles de análisis de la información privada del titular de la cuenta.

Las restricciones de apelación hacen que sea difícil para los usuarios comunes utilizar Ethereum (ETH)

Primero, cualquier usuario que utilice cualquier aplicación en la red de Ethereum debe poseer ETH (y asumir el riesgo de Fluctuación del precio de ETH).

En segundo lugar, los usuarios necesitan manejar una lógica de tarifas compleja, conceptos como precio del gas, límite de gas y bloqueo de transacciones (orden de nonce) son demasiado complejos para los usuarios.

Finalmente, aunque muchos Bloquear链 Billetera o aplicaciones intentan mejorar la experiencia del usuario a través de la optimización del producto, su efecto real es mínimo.

Por lo tanto, la clave para romper la situación está en lograr la abstracción de cuentas, desacoplar la propiedad (Owner) y los derechos de firma (Signer), a fin de resolver cada uno de los problemas mencionados.

En realidad, hay muchas propuestas históricas, y finalmente todas convergerán en dos tipos de enfoques.

3. Historia de las propuestas de AA

Aunque hay muchas propuestas de EIP que parecen ser soluciones al problema, en última instancia, se reducen a dos enfoques principales. Por lo tanto, cada EIP que no se ha adoptado hasta ahora ha contribuido a la forma en que se ha resuelto el problema en el plan actual.

3.1 La primera ruta es transformar EOA DIRECCIÓN en CA  DIRECCIÓN

Ya en noviembre 15 de 2015, en torno a EIP-101, Vitalik propuso una nueva estructura utilizando contratos como la DIRECCIÓN de la cuenta. Cambió la DIRECCIÓN para que solo tuviera código y espacio de almacenamiento, cambió el soporte de tarifas para que fuera pagado con ERC20, y a través de contratos precompilados convirtió el Token nativo en un tipo de ERC20 para almacenar el saldo (puede tener funciones de autorización de retención, entre otras), y simplificó los campos de transacción para que solo tuviera destinatario, gas inicial, datos y código.

Ahora parece ser una transformación de salto adelante, que cambiará significativamente el diseño subyacente y permitirá que cada DIRECCIÓN de cuenta tenga su propia lógica de “código” (de hecho, es el efecto que EIP-7702 está tratando de lograr en este momento).

También puede dar lugar a otras funciones, como

1. Permitir que más transacciones utilicen Algoritmo de cifrado, que puede ser especificado por el código interno de cada DIRECCIÓN para verificar el método de autenticación
2. Tiene características de resistencia al ataque cuántico porque el código tiene características de actualización.
3. Hacer que Ethereum tenga las mismas características funcionales que el contrato ERC20, con el efecto central de la autorización de retención, evitando así la pérdida de la moneda nativa.
4. Mejorar el espacio personalizado de la cuenta, compatible con la recuperación social, el soporte sbt, la recuperación de la Llave secreta, etc.

La razón por la que no se ha seguido adelante es muy simple, obviamente es un paso demasiado grande, y el problema de conflicto de hash en la transacción actual, la consideración insuficiente de los riesgos de seguridad, ha estado en espera todo el tiempo, pero el concepto de cada ventaja se ha convertido en una de las funciones centrales de los posteriores EIP4337 y EIP7702.

Más tarde, hubo una serie de intentos de EIP para mejorar esta lógica

EIP-859: Abstracto de cuenta de cadena principal–2018-01-30

Intentando resolver el problema de implementación de Code, su función principal es que si el contrato del lado opuesto no está desplegado, se utilizará el parámetro code adjunto a la transacción para ejecutar la implementación de la Billetera del contrato. Además, también se propone un nuevo código de operación PAYGAS, que, además de pagar el gas, también sirve como separador entre la parte de validación y la parte de ejecución de una transacción.

Aunque murió sin enfermedad en ese momento, también se convirtió en una de las lógicas centrales de EIP7702 en la actualidad. Cada transacción de EIP7702 combina una estructura de transacción especial que puede llevar cierto código, lo que permite que la EOA DIRECCIÓN tenga capacidades de contrato en esta transacción.

EIP-7702: Configuración del código de cuenta EOA 2024-05-07

Este también es el núcleo del mecanismo de discusión posterior de este artículo EIP, que fue presentado por Vitalik como una alternativa a EIP-3074 (2024-05-07). Por lo tanto, EIP-3074 se ha descartado y EIP-7702 se ha confirmado para su inclusión en la próxima bifurcación dura ETH Prague/Electra (Pectra), vamos a profundizar en los detalles en el siguiente texto.

3.2 La segunda ruta es hacer que EOA DIRECCIÓN conduzca a CA DIRECCIÓN

**EIP-3074: Agregar los códigos de operación AUTH y AUTHCALL - 2020-10-15

Agregar dos nuevos OpCodes, AUTH y AUTHCALL, a EVM para permitir que EOA autorice a los contratos a llamar a otros contratos en lugar de la identidad de EOA.

En resumen, con referencia a la imagen a continuación, un EOA puede enviar un mensaje (transacción) firmado a un contrato de confianza propio (llamado Invoker), y este contrato Invoker puede utilizar los códigos de operación AUTH y AUTHCALL para enviar esta transacción en lugar del EOA.

EIP-4337: Implementación de la abstracción de cuenta mediante la memory pool de transacciones - 2021-09-29

En resumen, se inspiró en MEV para su diseño, cuyo valor central es evitar por completo los cambios en el protocolo de consenso.

eip4337 propone un nuevo objeto de transacción UserOperation, que los usuarios envían a la memoria pool, donde los bundlers los empaquetan en lotes desde la perspectiva del Minero para ejecutar transacciones de contrato, esencialmente llevando la ejecución de transacciones y operaciones de cuentas del nivel base al nivel de contrato.

EIP-5189: Operar cuenta abstracta a través de endosantes-2022-06-29

Esto es una optimización de la lógica de EIP4337, que se enfrenta a Bundlers maliciosos a través del establecimiento de un mecanismo de endoso de multas financieras para prevenir ataques de bloqueo Dos.

3.3 Otras propuestas para apoyar AA

EIP-2718: Envoltura de sobre para nuevos tipos de transacciones–2020-06-13

Esta es una propuesta que ya está finalizada, define un nuevo tipo de transacción como un sobre para los tipos de transacciones que se agregarán en el futuro.

El resultado final es que, al introducir un nuevo tipo de transacción, se distingue mediante una codificación específica, lo que permite que solo sea compatible hacia atrás, sin necesidad de compatibilidad hacia adelante. El ejemplo más común es EIP1559, que diferencia las tarifas de transacción, utiliza una nueva codificación de tipo de transacción y no afecta al tipo de transacción heredado original.

EIP-3607: Impedir que las EOA DIRECCIÓN puedan implementar contratos - 2021-06-10

Este es un plan complementario en la ruta AA para evitar conflictos entre la dirección de contrato DIRECCIÓN y la dirección EOA DIRECCIÓN. Controlará el método de generación de contratos para evitar que el sistema permita el despliegue de código en una dirección DIRECCIÓN que ya es una dirección EOA. Este riesgo es bastante bajo, después de todo, la dirección de Ethereum tiene una longitud de 160 bits. Aunque existe un método para colisionar Llave privada y obtener una dirección de contrato especificada DIRECCIÓN, se necesitaría un año de poder de cómputo de BTC para lograrlo.

**3.4 ¿Cómo entender el desarrollo abstracto de la cuenta?

Primero, es necesario entender el valor después de la conversión a CA.

Básicamente, es el efecto real de EIP-4337, que puede lograrlo.

Sin embargo, la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.

Parece que ha mejorado, pero ha caído en un ciclo de desarrollo de mercado en el que muchas Dapp no son compatibles, por lo que los usuarios no están dispuestos a usar direcciones de CA, e incluso el uso de CA tiene un Costo de la transacción más alto (en escenarios de transferencia normales, el blanqueo de capitales también se duplicará), lo que demuestra una dependencia excesiva en la compatibilidad de la propia Dapp.

Por lo tanto, no ha sido popularizado en la red principal de Ether hasta ahora.

El costo es el estándar más importante para que los usuarios lo midan, debe Soltar el costo.

Sin embargo, para soltar GAS de verdad, es necesario hacer un soft fork en Ethereum, modificando el cálculo del GAS o el consumo de GAS de los módulos de código de operación. Sin embargo, si vamos a hacer un soft fork, ¿por qué no considerar directamente EIP-7702?

4、全面解析EIP-7702

¿Qué es EIP-7702?

Se diferencia por nuevos tipos de transacciones que permiten que un EOA tenga temporalmente las funciones de un contrato inteligente en una única transacción, lo que permite realizar transacciones en lotes, transacciones sin Gas y gestión personalizada de permisos en el negocio, sin necesidad de introducir nuevos opCodes de EVM (que afecten a la compatibilidad hacia atrás).

Él puede permitir a los usuarios obtener la mayoría de las capacidades de AA sin implementar contratos inteligentes, incluso puede proporcionar la capacidad de que un tercero inicie transacciones en nombre de los usuarios, sin necesidad de que los usuarios proporcionen la llave privada, solo la información de autorización firmada.

4.2 Estructura de datos

Él definió un nuevo tipo de transacción 0x04, cuya TransactionPayload es el resultado de la serialización RLP del siguiente contenido

Lo importante es que se ha agregado un objeto authorization_list que almacena el código que los firmantes desean ejecutar en su EOA. Los usuarios firman la transacción y también firman el código del contrato que se ejecutará. Está representado como una lista bidimensional, lo que indica que se pueden almacenar múltiples operaciones en lotes y ejecutarlas en lotes.

4.3 Ciclo de vida comercial

4.3.1 Fase de validación

En la etapa inicial de la ejecución de la transacción, para cada tupla [chain_id, address, nonce, y_parity, r, s] en cada authorization_list:

1. De los firmas r y s, recuperar la DIRECCIÓN del firmante utilizando ecrecover (ten en cuenta que este es el mecanismo interno de Ethereum, por lo que esta EIP no cambia el Algoritmo de firma). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (similar a la recuperación de DIRECCIÓN anteriormente, aquí se obtiene la DIRECCIÓN parcial de esta lista).
2. Verificar el ID de la cadena (proteger contra la reproducción de la cadena bifurcada).
3. Verifique si el código del firmante de la autoridad está vacío o ha sido delegado (verifique si la transacción es una transacción 7702 válida y luego utilice el mecanismo de delegación para ejecutar la transacción).
4. Verificar el nonce del firmante de la autoridad (para evitar la repetición de firmas de la autoridad).
5. Establezca el código del firmante de autoridad en 0xef0100 || dirección (utilizado para evitar la política de prevención de colisiones EIP3607).
6. Aumentar el nonce del firmante de la autoridad (para evitar la reutilización de firmas parciales).
7. Agregar el firmante de autorización cuenta a la lista de DIRECCIÓN ya accedida (transferir a la DIRECCIÓN caliente, Soltar consultar las tarifas de gas almacenadas)

4.3.2 Fase de ejecución de la operación

¿Dónde se encuentra el código del contrato a ejecutar y las instrucciones de operación?

La versión ‘新’ solo cambia el comportamiento de la implementación del código.

Ya no establece el código de cuenta como contract_code, sino que recupera el código de dirección del authorization_list y lo establece como el código de cuenta.

Por lo tanto, cuando se necesita ejecutar el código de autorización, se carga el código desde la DIRECCIÓN especificada en el campo de dirección de la lista de autorizaciones y se ejecuta en el contexto de la cuenta del firmante.

Esto significa que el código de contrato del usuario se almacena en realidad en una dirección específica en la cadena, en lugar de estar incluido directamente en la transacción.

Mientras que las instrucciones de operación y los parámetros relacionados se almacenan en el campo de datos de la carga útil de la transacción.

¿Cuál es el valor de EIP-7702?

Tendrá cambios en todo el proceso de Web3 Monedero, lo que cambiará enormemente la experiencia del usuario, ya que las transacciones normales iniciadas por EOA también pueden ejecutar múltiples lógicas similares a contratos, como transferencias en lotes. Esto afectará la identificación de transacciones en el escenario CeFi, así como las tarifas de retiro y recopilación.

Debido a su aparición, ha roto muchos prejuicios anteriores, como por ejemplo:

1. Rompió la invariante de que el saldo de la cuenta solo puede disminuir debido a las transacciones que provienen de esa cuenta.
2. Rompió la invariante de incremento de nonce EOA después de que la ejecución de la transacción comenzara (puede aumentar varios al mismo tiempo).
3. Rompió la lógica de protección de comparación entre tx.origin y msg.sender, lo que pone en riesgo muchos contratos anteriores.
4. Rompe la situación actual en la que EOA no puede emitir eventos, por lo que es posible que se deba prestar atención a la identificación y escucha de algunos eventos on-chain.
5. Rompió la DIRECCIÓN de EOA para aceptar activos ERC20, 721, 1155, etc. es inevitablemente exitoso (debido al mecanismo de retroceso, puede fallar)

4.5 Comparación entre EIP-7702 y EIP-4337

1. Ventajas de EIP-7702

gas más bajo, ya que no necesita pasar por el módulo de punto de entrada, reduciendo las operaciones on-chain.

El costo de migración del usuario es más bajo, no es necesario desplegar previamente contratos on-chain como entidad principal

En comparación con Eip4337, también habrá ejecución de código de delegación y también habrá dos formas:

Delegación completa (Full Delegation)

La delegación total se refiere a la delegación de todos los permisos de una operación a una DIRECCIÓN específica. Por ejemplo, un usuario puede delegar todos los permisos de gestión de tokens ERC-20 a una DIRECCIÓN de contrato inteligente, lo que permite que este contrato inteligente ejecute todas las operaciones relacionadas en nombre del usuario.

Delegación Protegida

La delegación protegida se refiere a la adición de ciertas restricciones y medidas de protección durante el proceso de delegación para garantizar la seguridad y controlabilidad de la operación de delegación.

Por ejemplo, los usuarios pueden delegar los permisos de gestión de algunos tokens ERC-20 a un contrato inteligente, o establecer algunas condiciones restrictivas (como gastar como máximo el 1% del saldo total al día).

2. Desventajas de EIP-7702

Su principal inconveniente es que pertenece a una actualización de bifurcación suave, que requiere consenso y tiene un gran impacto en la ecología en la cadena. Según nuestra evaluación inicial, enfrenta los siguientes desafíos, pero los desafíos también son oportunidades de mercado:

1. Muy flexible y difícil de auditar, los usuarios necesitan una Billetera confiable para garantizar la protección de la seguridad.
2. Los cambios en la arquitectura original son demasiado grandes, aunque se diferencian por tipos de transacciones diferentes, muchos aspectos fundamentales, especialmente los contratos no modificables en la cadena, no se pueden adaptar directamente.
3. Se proporciona la capacidad de contrato para la DIRECCIÓN EOA, pero no se puede conservar el espacio de almacenamiento correspondiente.
4. El costo de la transacción individual aumenta ligeramente, ya que se agregará una gran cantidad de la parte de Calldata, estimando un costo total de llamada de 16 (gas) * 15 (bytes) = 240 costo de calldata (gas), más el costo de EIP-3860 2 * 15 = 30, más un costo de tiempo de ejecución de aproximadamente 150. Por lo tanto, incluso solo preparando la cuenta sin hacer nada, se agregarán 500 de gas.
5. ‘Si el destinatario firma un código sin función de recepción, el remitente puede enfrentar un DoS al intentar enviar activos’. Ver caso. En realidad, este problema ocurre cuando EOA A firma algo que no debería firmar: un archivo reproducible con una implementación incorrecta (sin receive()).
6. La lógica de depósito y retiro on-chain puede ser inconsistente, por ejemplo, cuando se transfiere un token ERC-20, si la cuenta receptora tiene un código, entonces el contrato de token llamará a onERC20Received en la cuenta receptora. Si onERC20Received devuelve un valor incorrecto o de error, la transferencia de token se revertirá.
7. ¿Habrá algún problema si EOA puede emitir eventos? Algunas infraestructuras pueden requerir atención.

Estos son solo algunos de los puntos débiles identificados por los catorce miembros de la junta directiva sobre la base del contenido actual de la propuesta EIP7702 y un resumen de las discusiones en el foro oficial. Sin embargo, se requerirá un análisis completo basado en el código de implementación final para obtener una visión completa.

Consulte a continuación:

5. Resumen completo

Este artículo parece tener una gran extensión, pero en realidad solo tiene unas 6k palabras. Muchas de las interpretaciones anteriores de EIP mencionadas en el texto se pueden ampliar a través de enlaces, así que no entraré en más detalles al respecto.

Actualmente, la abstracción de cuentas solo puede colocarse en el sexto módulo, es decir, reparar todo, es decir, implementarlo por último. Ahora se ha acelerado significativamente el progreso de EIP7702, lo que trae principalmente desafíos a la seguridad del sistema. Se puede prever que finalmente se logrará, después de todo, eventos disruptivos como la fusión de ETH y la modificación del Algoritmo de Consenso pueden ocurrir. ¿Qué importancia tienen los nuevos tipos de transacciones?

Pero esta vez hay demasiado contenido disruptivo, rompiendo múltiples reglas no posibles en la cadena, también rompiendo la lógica de la mayoría de las aplicaciones Dapp, pero se aferra firmemente al punto central, que es que el costo para los usuarios es más bajo en comparación con el costo de transacción casi duplicado de EIP4337.

El usuario sigue siendo una DIRECCIÓN EOA, pero solo activa y utiliza la lógica de CA cuando es necesario, lo que reduce el costo de posesión. No es necesario convertir primero la identidad de CA en la cadena y luego realizar operaciones, lo que significa que los usuarios no necesitan registrarse.

Los usuarios pueden realizar múltiples transacciones de forma simultánea con EOA, como la autorización de retenciones y la ejecución de retenciones, lo que reduce el Costo de la transacción para los usuarios. Para Dapp, especialmente aquellos que requieren la gestión empresarial on-chain del equipo detrás del proyecto, como los intercambios, es una optimización disruptiva. Una vez que se implementa la capacidad de agrupar transacciones a nivel nativo, los costos del intercambio pueden reducirse en más de la mitad al instante, lo que finalmente beneficiará a los usuarios.

Por lo tanto, aunque ha habido muchos cambios, el costo de ocupación es un aspecto que todos los Dapp deberían investigar y adaptarse, porque esta vez, los usuarios definitivamente están del lado de EIP7702.