Introducción

EIP-7702 permite que las billeteras simples de Ethereum (EOAs) se actualicen a billeteras de contratos inteligentes, que ofrecen mayor seguridad, funcionalidad avanzada, la oportunidad de patrocinio de gas y otros beneficios. Históricamente, las billeteras inteligentes han tenido que ser creadas desde cero, pero con la introducción de EIP-7702, las billeteras tradicionales, con todos sus activos e historial en cadena, pueden actualizarse y mantener la misma dirección de billetera. Es como cambiar de un teléfono fijo a un teléfono inteligente sin tener que obtener un nuevo número.

Las EOAs se actualizan al establecer una "designación de delegación", un puntero a un contrato inteligente deleGate, cuya lógica luego gobierna la EOA. Por lo tanto, las EOAs actualizadas pueden tener funciones, establecer almacenamiento, emitir eventos y hacer todo lo que puede hacer un contrato inteligente. Las EOAs pueden cambiar o eliminar esta delegación en cualquier momento con una nueva autorización EIP-7702 firmada. Si bien esto desbloquea muchas nuevas posibilidades, esta poderosa función también introduce nuevos desafíos de seguridad que requieren una cuidadosa consideración y soluciones innovadoras.

Para permitir que las EOA actúen como billeteras de contratos inteligentes, desarrollamos el EIP7702Proxy, un ligeroproxy ERC-1967 contrato diseñado para servir como el deleGate EIP-7702 para un EOA. Además de la reenvío lógico básico realizado por un proxy, el EIP7702Proxy contiene características adicionales y elecciones de diseño que resuelven varios desafíos únicos para cuentas delegadas por EIP-7702. Un objetivo en el diseño del EIP7702Proxy fue permitir la paridad más cercana posible entre las Billeteras Inteligentes Coinbase "desplegadas-estándar" y las Billeteras Inteligentes Coinbase delegadas por EIP-7702, lo que significaba abstraer la complejidad adicional demandada por la mecánica de EIP-7702 en el proxy dedicado y continuar confiando en la implementación original de la CoinbaseSmartWallet. La solución a este desafío puede aplicarse de manera útil a cualquier lógica de implementación, no solo a la implementación de CoinbaseSmartWallet, mientras ayuda a los EOAs a mantenerse seguros en un entorno habilitado para 7702.

A continuación, describimos los desafíos específicos y las soluciones de diseño correspondientes que nos permiten adaptar de manera segura cualquier implementación existente de billetera de contrato inteligente para ser utilizada en las actualizaciones de EIP-7702.

Reto #1: Hacer cumplir una inicialización segura

El primer gran obstáculo en la implementación de EIP-7702 proviene de sus restricciones de inicialización. Las billeteras de contratos inteligentes tradicionales, incluida la CoinbaseSmartWallet, generalmente manejan la inicialización segura (el establecimiento de la propiedad de la cuenta) de manera atómica durante su implementación a través de un contrato de fábrica separado. Esta atomicidad significa que muchas de estas implementaciones tienen funciones de inicialización no protegidas que pueden ser llamadas exactamente una vez. Sin embargo, el diseño de EIP-7702 no permite la ejecución de calldata de inicialización durante el proceso de delegación de código (el paso comparable a "implementación") y, por lo tanto, esto no se puede hacer de manera atómica.

Esta separación de pasos crea una ventana de vulnerabilidad crítica. Cuando un contrato de implementación es “desplegado” a un EOA a través de EIP-7702, no hay garantía de que esta actualización 7702 y la transacción EVM estándar que inicializa la billetera se ejecuten de manera atómica. El código que establece la autorización podría aplicarse técnicamente de manera independiente de la transacción de inicialización, incluso si se envían simultáneamente, y esto podría permitir que un atacante adelante la transacción de inicialización con su propia carga útil y reclame la propiedad de la cuenta inteligente.

Solución: Requerir la firma de EOA para establecer de manera atómica la implementación e inicializar

Tenga en cuenta que las billeteras inteligentes de Coinbase existentes están desplegadas detrás de un proxy ERC-1967 con un UUPSUpgradeable implementación (la lógica real de CoinbaseSmartWallet). El código en la dirección de cuenta real es un proxy, y el proxy utiliza una ubicación de almacenamiento convencional definida por ERC-1967 para mantener un puntero a su lógica de implementación. Nuestra solución a la vulnerabilidad de inicialización en un contexto 7702 implica reconocer que cualquier lógica de implementación solo se activa (y por lo tanto se vuelve peligrosa) cuando el proxy establece realmente una conexión con ella. Por lo tanto, si no podemos hacer cumplir el despliegue atómico con la inicialización, en su lugar podemos hacer cumplir la configuración atómica de la implementación con la inicialización.

Arquitectura del contrato CoinbaseSmartWallet EIP-7702 y flujo de delegación lógica

En el contexto de EIP-7702, el EOA en sí es la autoridad inicial sobre cualquier cambio en su cuenta y debe proporcionar una firma para autorizar la inicialización y establecer a los propietarios de la nueva cuenta inteligente. Nuestro contrato EIP7702Proxy implementa una función setImplementation que puede establecer de manera atómica la nueva implementación lógica e inicializar la cuenta. La función setImplementation:

1. Valida una firma del EOA a través de datos clave como la dirección del nuevo contrato de implementación, los datos iniciales de llamada, la dirección de un contrato de validador que evaluará la seguridad del estado de cuenta resultante, y protecciones básicas contra la repetición de firmas como un nonce y una fecha de caducidad.
2. Establece el valor del puntero ERC-1967 a la nueva implementación y ejecuta los datos de llamada proporcionados contra la nueva implementación lógica
3. Realiza una llamada a la función validateAccountState que debe ser implementada por el validador incluido en la firma.

El validador es un contrato específico de la implementación que contiene la lógica para evaluar si considera que el estado de la cuenta resultante es seguro. Por ejemplo, en el caso de la CoinbaseSmartWallet, el CoinbaseSmartWalletValidator verificará si el estado de propiedad de la cuenta no está vacío y, por lo tanto, ya no es susceptible a la inicialización arbitraria.

Reto #2: Almacenamiento compartido entre los delegados de EIP-7702

Quizás el desafío más intrincado de EIP-7702 esté relacionado con la gestión del almacenamiento. El EOA puede volver a delegar libremente su lógica a diferentes contratos, o eliminar completamente la delegación en cualquier momento. Todos los delegados comparten el mismo espacio de almacenamiento en la dirección del EOA. Varios contratos que comparten acceso al mismo almacenamiento a lo largo del tiempo pueden dar lugar a un problema de "colisión de almacenamiento". Las colisiones de almacenamiento ocurren cuando dos contratos realizan diferentes cambios o tienen diferentes suposiciones sobre la misma ubicación de almacenamiento, lo que puede llevar a errores impredecibles.

La gestión de las colisiones de almacenamiento ya es un problema familiar en el espacio de diseño de proxies, donde se utiliza lógica de implementación mutable para gobernar el almacenamiento compartido. A pesar de que los proxies actualizables pueden cambiar las implementaciones, el código del proxy en sí (para direcciones no 7702) no puede cambiar. Esto aporta certeza y garantías al proceso de actualización. La re-delegación 7702 introduce otra capa de mutabilidad total a la lógica potencial que puede gobernar este almacenamiento compartido. Esto elimina esencialmente cualquier garantía sobre el efecto que un deleGate arbitrario puede tener en el almacenamiento. Por ejemplo, si un EOA delega de deleGate A a B y vuelve a A, el deleGate de retorno no puede hacer suposiciones sobre el estado de su almacenamiento, que puede haber sido borrado o manipulado por el deleGate B en un estado que habría sido imposible de lograr solo a través de la lógica del deleGate A. Esto es cierto para cualquier deleGate 7702, independientemente del patrón de delegación, ya que un deleGate anterior puede haber almacenado o eliminado cualquier cosa en cualquier ubicación de almacenamiento.

Ejemplo de un estado inválido para DeleGate A inducido por el patrón de delegación A → B → A

Solución: Externalización de valores de almacenamiento críticos para la seguridad

La delegación de EOA puede afectar arbitrariamente el estado de la cuenta. Si un EOA delega a un contrato malicioso o destructivo, ningún delegado incumbente puede proteger contra esto. Al igual que firmar una transacción de drenaje, autorizar delegados maliciosos 7702 podría ser ruinoso, y protegerse contra estos resultados está fuera del alcance de nuestro diseño.

Diseñamos el EIP7702Proxy para ser autodefensivo contra problemas previsibles en un ecosistema multi-billetera habilitado para 7702 de actores bien intencionados pero potencialmente caóticos. No puede proteger a los EOAs que autorizan a deleGates realmente maliciosos o con errores.

Un problema previsible involucra las firmas para las llamadas setImplementation y los riesgos introducidos por el estado mutable de la cuenta. El EIP7702Proxy depende de las firmas EOA para establecer la lógica de implementación e inicializar a un estado seguro. Estas firmas podrían convertirse en responsabilidades si alguna vez fueran reproducibles. Por ejemplo, si una firma autoriza a un propietario inicial que luego se compromete y es removido, una firma reproducible podría restablecer al propietario comprometido o forzar una degradación de la implementación.

La protección común contra la repetición de firmas utiliza nonces en mensajes firmados, marcados como consumidos cuando son verificados. El riesgo para las cuentas 7702: otros deleGates podrían comprometer este almacenamiento de seguimiento de nonces. Si el almacenamiento que rastrea el uso de nonces se borra, la firma setImplementation del EOA (disponible públicamente en el mempool) podría reaplicarse al delegar de nuevo al EIP7702Proxy.

Para garantizar la no repetibilidad de las firmas, implementamos un singleton NonceTracker separado que mantiene el estado de los nonces en una ubicación de contrato inmutable fuera del almacenamiento de la cuenta. Solo el EOA puede afectar sus nonces (solo de manera incremental), evitando que otros deleGates manipulen estos valores críticos de seguridad. El NonceTracker asegura que cada firma setImplementation funcione solo una vez, independientemente de los cambios en el almacenamiento de la cuenta.

Reto #3: Mayor riesgo de ubicaciones de almacenamiento convencionales compartidas

Slots de almacenamiento estandarizados como los definidos por ERC-1967son particularmente vulnerables a posibles colisiones de almacenamiento debido a que son ubicaciones convencionales que probablemente serán utilizadas por múltiples implementaciones de deleGate. El slot de implementación ERC-1967 es la única ubicación de almacenamiento estándar utilizada en el EIP7702Proxy y contiene la dirección de la implementación lógica a la que apunta el proxy. Nuestro diseño garantiza que, independientemente del valor en esta ubicación de almacenamiento (que determina gran parte de la lógica disponible en la cuenta), el EIP7702Proxy siempre podrá establecer con éxito su lógica de implementación a un contrato deseado por el EOA.

Para ilustrar más claramente el problema que se está resolviendo, note que cuando una cuenta transiciona entre diferentes deleGates (A→B→A) donde ambos deleGates implementan patrones de proxy ERC-1967, el deleGate B usará naturalmente la misma ranura de almacenamiento que el deleGate A estaba usando para almacenar su dirección de implementación. Durante su mandato, el deleGate B podría modificar o sobreescribir esta ranura, ya sea intencionadamente o como parte normal de sus propias operaciones de proxy. En un patrón de proxy UUPSUpgradeable, la lógica para actualizar una implementación se define en el propio contrato de implementación. Si la implementación establecida en esta ubicación de puntero por el deleGate B no contiene la interfaz upgradeToAndCall esperada en una implementación, entonces, al regresar al deleGate A, el mismo mecanismo para cambiar su implementación podría no existir en la lógica actualmente disponible.

Ejemplo de sobrescribir la ubicación de almacenamiento convencional compartido por un nuevo deleGate

Solución: Mecanismo de actualización disponible en el EIP7702Proxy

Nuestro EIP7702Proxy aborda esto a través de su función setImplementation, que proporciona un mecanismo de actualización independiente de la implementación directamente en el proxy mismo. Esto garantiza que incluso si un deleGate intermedio ha apuntado la implementación ERC-1967 a una implementación no válida (o la ha eliminado por completo), el EOA original, después de delegar de vuelta a un EIP7702Proxy, mantiene la capacidad de reconfigurar el puntero ERC-1967 del proxy a su implementación lógica elegida.

Desafío #4: Compatibilidad hacia atrás con el comportamiento estándar de EOA

Un objetivo de diseño del EIP7702Proxy era mantener la compatibilidad hacia atrás con la funcionalidad EOA de la cuenta, además de la nueva funcionalidad de contrato inteligente. La presencia o ausencia de código en una dirección puede afectar el flujo de ejecución de los protocolos que interactúan con la dirección, ya que fundamentan esta calidad para diferenciar entre EOAs y contratos inteligentes. Esto requirió considerar dos comportamientos principales: verificación de firmas y comportamiento de recepción de tokens.

Verificación de firma

Los contratos inteligentes tienen un estándar diferente para la validación de firmas que las EOAs estándar. Los contratos inteligentes implementan la interfaz isValidSignature definida por ERC-1271y son libres de definir lógica arbitraria que determina si el contrato considera una firma válida. Para las EOAs estándar, una firma se valida con un chequeo ecrecover estándar que asegura que el firmante se recupere a la dirección EOA esperada.

Para garantizar que las firmas EOA existentes o futuras continúen siendo reconocidas en la EOA después de una actualización 7702, el EIP7702Proxy implementa una versión de isValidSignature que primero delega la validación de la firma a la función isValidSignature que debe definirse en la implementación lógica, pero sigue a una validación fallida con una verificación final de ecrecover. Si esto pasa, la firma se considera válida. De esta manera, las EOAs que utilizan el EIP7702Proxy pueden garantizar que las firmas EOA simples siempre serán reconocidas en su dirección, independientemente de la implementación de isValidSignature de su billetera de contrato inteligente.

Recibo de token

Algunos estándares de token (específicamente ERC-1155 y ERC-721) intento de proteger contra tokens que se quedan atascados en contratos inteligentes que pueden no tener la capacidad de gestionarlos. Estos tokens requieren que cualquier contrato inteligente que reciba dichos tokens declare esta capacidad implementando interfaces estándar de receptor de tokens que son llamadas por el contrato de tokens durante un envío de tokens. También es esencial que la lógica en la EOA mejorada contenga una función de recepción estándar o un fallback pagable para poder recibir tokens nativos. Una cuenta nunca debe estar en un estado que la deje incapaz de recibir ETH u otros tokens, aunque sea brevemente.

Dado que nuestro proxy carece de una implementación inicial, incluimos una implementación inmutable de DefaultReceiver como la lógica predeterminada para el EIP7702Proxy en ausencia de un puntero ERC-1967. Este receptor implementa una función de recepción y los ganchos de receptor para estos estándares de token comunes, asegurando que la cuenta pueda aceptar transferencias de tokens antes de establecer explícitamente una nueva implementación.

Conclusión

El diseño de EIP7702Proxy nos permite mantener una estrecha paridad con las Billeteras CoinbaseSmartWallet estándar y continuar utilizando la implementación existente de CoinbaseSmartWallet mientras resolvemos los desafíos de seguridad únicos que surgen en el contexto de EIP-7702. Al considerar cuidadosamente la seguridad de inicialización, las implicaciones de la impermanencia y la interferencia del almacenamiento, la necesidad de un manejo ininterrumpido de tokens y la compatibilidad hacia atrás con la verificación de firmas EOA estándar, hemos creado un proxy para delegar y gestionar de manera segura las billeteras de contratos inteligentes EIP-7702. Aunque el EIP7702Proxy fue diseñado teniendo en cuenta la implementación de CoinbaseSmartWallet V1, este proxy es en última instancia agnóstico a la implementación. Animamos a los desarrolladores a evaluar esta solución para la adaptación de prueba 7702 de otras implementaciones de billeteras de contratos inteligentes.

Descargo de responsabilidad:

1. Este artículo es reproducido de [Blog de Ingeniería Base]. Todos los derechos de autor pertenecen al autor original [Amie Corso]. Si hay objeciones a esta reimpresión, por favor contacte a el Gate Learn equipo, y ellos se encargarán de ello de inmediato.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, copiar, distribuir o plagiar los artículos traducidos está prohibido.