EIP-3074

Mejor, experiencia de usuario más segura

EIP-3074 permite a las EOAs delegar el control a contratos especificados, obteniendo así capacidades de ejecución avanzadas similares a las de los contratos. Antes de EIP-3074, una EOA solo podía realizar una operación por transacción, como aprobar un token ERC20 o hacer un intercambio en Uniswap. Después de EIP-3074, una EOA puede completar múltiples operaciones en una sola transacción, lo que permite casos de uso anteriormente inimaginables. En esencia, EIP-3074 mejora significativamente la experiencia del usuario y redefine los métodos de autorización familiares al tiempo que mejora la seguridad.

Además, con EIP-3074, las EOAs ya no necesitan enviar transacciones en cadena por sí mismas, eliminando así la necesidad de adquirir primero ETH para pagar las tarifas de transacción.

Contratos Invoker

Los contratos que pueden tomar el control de las EOAs se llaman contratos Invoker. No cualquier contrato puede tomar el control; la EOA debe firmar con su clave privada, especificando qué contrato Invoker y qué operaciones autoriza al Invoker a realizar.

El proceso generalmente implica:

Alice firma con su clave privada EOA, especificando el contrato Invoker y las operaciones autorizadas.

Alice envía el contenido firmado y la firma a un Relayer.

El Relayer envía la transacción en la cadena al contrato Invoker.

El Invocador verifica la firma y, tras la validación, ejecuta las operaciones como EOA de Alice, como aprobar USDC, intercambiar activos en Uniswap y usar algo de USDC para pagar al Remitente como tarifa.

Nota: El Relayer es opcional; Alice puede enviar el contenido firmado y la firma a la cadena por sí misma.

Evitando ataques de repetición

El Invocador ejecuta operaciones como si tuviera un control limitado de la EOA de Alice. Sin embargo, el nonce de la EOA no aumenta después de la ejecución, lo que significa que la misma firma podría potencialmente ser reutilizada siempre que el nonce de la EOA permanezca sin cambios. Por lo tanto, el Invocador debe implementar su mecanismo de nonce para prevenir ataques de repetición.

Saber más

Para obtener una introducción detallada al funcionamiento de EIP-3074, consulte:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Aplicaciones de EIP-3074

Llamada en lote

Batchcall permite a los usuarios combinar múltiples transacciones en una sola, ahorrando el proceso de múltiples firmas de autorización y algunos costos de gas. Tenga en cuenta que esto requiere que las DApps admitan la funcionalidad de Batchcall, como el EIP-5792 actualmente promocionado. Sin dicho soporte, las DApps solicitarán una transacción separada para cada operación, tratando al usuario como un EOA regular.

Para obtener más información sobre EIP-5792, consulte: EIP-5792.

Clave de sesión

Los usuarios pueden delegar operaciones a un tercero bajo condiciones específicas utilizando una clave de sesión. En el ejemplo a continuación, la clave de delegado representa al tercero autorizado, mientras que la política de acceso define las restricciones operativas, como limitar acciones a Uniswap, limitar transferencias a 1 ETH por día o establecer una fecha de vencimiento de autorización. Estas condiciones están diseñadas y verificadas dentro del contrato Invoker. Una vez que las verificaciones pasan, el tercero puede realizar operaciones como el EOA del usuario.

Por ejemplo, un Bot de Telegram podría recibir permisos específicos para ejecutar operaciones en nombre del EOA del usuario.

Permiso nativo de ETH

Si se cumplen las condiciones (es decir, la firma del permiso es válida), las operaciones pueden ejecutarse como el EOA autorizante, lo que permite la funcionalidad nativa de permisos ETH.

Orden con límite

Los usuarios pueden establecer condiciones de orden de límite, que, una vez cumplidas, permiten que las operaciones se ejecuten como el EOA del usuario. Esto incluye aprobar activos digitales relevantes para un DEX e intercambiar activos en el DEX. En comparación con la funcionalidad de orden de límite proporcionada por los propios DEX, los usuarios no necesitan aprobar previamente activos para el DEX.

Por ejemplo, cuando Alice completa una orden límite, la aprobación se ejecuta simultáneamente, eliminando la necesidad de aprobación previa.

Al diseñar las condiciones de forma más general, se puede crear un contrato de Intención: siempre que se cumplan las condiciones especificadas, cualquier persona puede ejecutar la intención en nombre de la EOA del usuario.

Recuperación social

Si un usuario pierde su clave privada de EOA, puede usar la autorización previamente firmada EIP-3074, junto con las firmas de las partes autorizadas (por ejemplo, Esposo y Agente de Confianza), para transferir todos los activos del EOA. Esto recupera los activos (transferibles), no el control de la cuenta. Una vez que se pierde la clave privada del EOA, el EOA no se puede volver a utilizar.

Mejorando los Métodos de Autorización de Activos

EIP-3074 tiene el potencial de mejorar o incluso reemplazar los métodos actuales de aprobación/permiso. Las DApps actualmente operan bajo la suposición de que los usuarios son EOAs: los usuarios deben preaprobar una cantidad lo suficientemente grande de activos al contrato de DApp para evitar permanecer en línea constantemente y aprobar repetidamente transacciones. Esto mejora significativamente la experiencia del usuario.

Por ejemplo, aplicaciones condicionales como órdenes límite o DCA requieren que los usuarios preautoricen una gran cantidad de activos para que la DApp pueda ejecutar operaciones cuando se cumplan las condiciones, potencialmente varias veces.

Sin embargo, esto requiere que los usuarios confíen en la DApp o eviten aprobar DApps falsas, y deben poder eliminar aprobaciones en tiempo real.

Modelos de permisos recientes como EIP-2612 o el Permit2 no nativo tienen como objetivo mejorar la experiencia del usuario y la seguridad del modelo de aprobación. Los usuarios no necesitan aprobar grandes cantidades de activos para cada contrato de DApp; en su lugar, pueden autorizar a las DApps a retirar una cantidad especificada de activos dentro de un tiempo determinado firmando una vez. Esto reduce considerablemente la superficie de ataque y mejora la experiencia del usuario.

△ Los usuarios solo necesitan firmar fuera de la cadena, y pueden especificar la cantidad de activos y el período de validez, lo que proporciona una mejor experiencia de usuario y seguridad que aprobar.

Sin embargo, en realidad, no solo aprobar, el modo de permiso todavía se explota con frecuencia como un método de estafa. Las víctimas firman erróneamente permisos que creen que son para el uso de DApp pero en realidad están dando autorización a los atacantes.

△ Cuando los usuarios firman un permiso, solo pueden ver a quién están autorizando pero no saben qué operaciones se realizarán en conjunto con él.

Nota:El diseño actual del permiso es incompatible con las DApps que requieren operaciones repetitivas, como DCA u otras aplicaciones de pagos periódicos. Esto se debe a que el permiso tiene un mecanismo contra repeticiones, por lo que una vez que se completa una transacción, el mismo permiso no puede ser utilizado nuevamente. Básicamente, los usuarios necesitan pre-firmar permisos para cada operación repetitiva futura.

Más información:

Para comprender más sobre los incidentes en los que el modo de permiso ha sido explotado como un método de estafa, por favor copie los siguientes enlaces en su navegador para obtener más información:

• Enlace 1

• Enlace 2

• Link 3

Sin embargo, EIP-3074 trae una oportunidad de cambio: cuando los desarrolladores de DApp se dan cuenta de que EOA puede realizar diversas operaciones complejas a través de Invoker, el diseño de las interacciones de DApp ya no necesitará sacrificar la seguridad por una mejor experiencia de usuario, como "los usuarios aprueban una gran cantidad de activos por adelantado" o "los usuarios firman un mensaje de autorización para autorizar retiros".

En cambio, los usuarios vincularán la operación de la DApp con la acción de aprobación, ejecutándolas atómicamente a través de Invoker: o ambas, la aprobación y la operación de DApp, tienen éxito juntas o fallan juntas. No hay posibilidad de que la acción de aprobación tenga éxito por sí sola, por lo que los usuarios pueden estar seguros de que esta acción de aprobación es específicamente para la operación actual.

Además, los usuarios autorizan utilizando firmas fuera de la cadena, ¡por lo que la experiencia del usuario es la misma que con el permiso! ¡Esto significa que las DApps ya no necesitarán el modo de permiso! En el futuro, las billeteras pueden bloquear directamente o escrutar de manera más estricta las solicitudes de firma de permiso sin preocuparse por evitar que los usuarios accedan a ciertas DApps (sino más bien ser explotados por estafas).

△ Los usuarios ya no solo autorizarán una dirección específica, sino que también especificarán qué acciones se pueden tomar, e incluso podrán ver los resultados de la ejecución simulada.

Nota:¡Esto no significa que las estafas puedan ser completamente prevenidas! ¡Los usuarios aún pueden ser engañados por sitios web fraudulentos, y los sitios web fraudulentos aún pueden elaborar operaciones de aprobación o transferencia para que los usuarios firmen. Sin embargo, en este punto, los usuarios al menos pueden ver qué operaciones está autorizando la firma. Las billeteras incluso pueden simular y mostrar los resultados de la ejecución, mostrando claramente a los usuarios quién perderá dinero y quién ganará dinero. En comparación con los permisos donde los usuarios no pueden conocer las operaciones o los resultados de la ejecución, ahora los usuarios tienen más información para decidir si autorizar. Si bien no es una solución perfecta, sigue siendo una mejora significativa sobre la situación actual.

Cómo las Billeteras Manejan el Número de Secuencia EOA

Actualmente, el diseño de EIP-3074 incluye el valor de nonce de EOA en el contenido de la firma. Por lo tanto, tan pronto como EOA envíe una transacción en cadena que altere el valor de nonce, todas las autorizaciones existentes de EIP-3074 se vuelven inválidas.

Si un usuario autoriza a otros a operar su EOA en su nombre, como a través de la Clave de Sesión o los métodos de Recuperación Social mencionados anteriormente, el nonce del EOA debe permanecer sin cambios. De lo contrario, todas las autorizaciones deben volver a firmarse y entregarse al fiduciario, lo que afecta significativamente tanto la experiencia del usuario como la solidez del mecanismo.

Si el usuario se está autorizando a sí mismo para operar, entonces no es necesario evitar cambiar el nonce de EOA. Las firmas EIP-3074, al igual que las transacciones, deben ejecutarse dentro de un cierto período. Sin embargo, las billeteras deben gestionar las transacciones EIP-3074 para el EOA: si hay una firma EIP-3074 esperando ser en cadena, cualquier transacción EOA debe esperar.

Nota:El contrato Invoker en sí mismo debe mantener un mecanismo de nonce separado, por lo que cada firma debe ser renovada independientemente de los cambios en el nonce de EOA.

La Clave de Sesión y la Recuperación Social probablemente serán ampliamente adoptadas solo después de que EIP-3074 modifique las reglas para eliminar el nonce de EOA del contenido de la firma. Por lo tanto, las billeteras deben centrarse en el escenario donde los usuarios se autoricen a operar y tratar las firmas de EIP-3074 como lo harían con transacciones, evitando preocupaciones sobre transacciones de EOA que alteren el nonce.

Sin embargo, si los usuarios desean enviar su firma EIP-3074 en cadena por sí mismos, hay dos inconvenientes:

1. Los usuarios necesitan firmar dos veces: una vez para la firma EIP-3074 y otra vez para la firma de transacción en cadena.

2. Dado que la transacción en cadena incrementará el nonce de EOA antes de la ejecución, el nonce de EOA de la firma EIP-3074 debe ser pre-incrementado para que coincida con el cambio de nonce causado por la transacción en cadena.

△ Debido a que la transacción en cadena incrementa el nonce de EOA, la verificación de la firma EIP-3074 fallará si los nonces no coinciden.

△ Los usuarios necesitan preincrementar el nonce de EOA en la firma EIP-3074 para pasar la verificación con éxito.

Al comprender estas sutilezas, los proveedores de billeteras pueden gestionar mejor el manejo del número de secuencia de EOA, garantizando una experiencia de usuario más fluida y segura con las autorizaciones de EIP-3074.

Resumen y aspectos destacados

• EIP-3074 otorga a las EOAs (Cuentas de Propiedad Externa) las mismas capacidades de ejecución avanzadas que los contratos, desbloqueando numerosos nuevos escenarios de aplicación.
• Esto no solo mejora significativamente la experiencia del usuario, sino que también transforma los métodos de autorización actuales, haciéndolos más seguros sin comprometer la usabilidad.
• Además, EIP-3074 implica firmas simples, por lo que los usuarios no necesariamente tienen que ejecutar estas firmas en la cadena ellos mismos, eliminando la necesidad de reunir ETH para pagar las tarifas de transacción.
• Los usos de EIP-3074 incluyen Llamada de Lote, Clave de Sesión, Permiso ETH Nativo, Orden Límite y Recuperación Social. Muchos de estos son originalmente imposibles de lograr con EOA, y algunos, como la Orden Límite, requieren autorización previa y otros métodos menos seguros para ser utilizados.
• Esto antes era imposible para las EOAs. Por ejemplo, usar Orden de Límite requería métodos menos seguros como la preautorización.
• EIP-3074 también cambiará los métodos actuales de autorización. El método de aprobación autoriza directamente a una dirección especificada a retirar activos digitales ilimitados indefinidamente, lo que requiere que el EOA del usuario envíe una transacción para ejecutar la aprobación, lo que resulta en una mala experiencia del usuario y seguridad. El método de permiso solo requiere la firma del usuario, y cada firma especifica la cantidad de activos y el período de validez, mejorando en gran medida la experiencia del usuario y la seguridad en comparación con la aprobación.
• Sin embargo, el método de permiso sigue siendo frecuentemente explotado en estafas. Al firmar, los usuarios solo pueden ver la dirección, la cantidad de activos y el período de validez que están autorizando, pero no el propósito de la autorización. El propósito sería definido en otra firma (o transacción). Una DApp legítima requeriría que el usuario firme tanto el permiso como el propósito, pero estas son dos firmas separadas. Por lo tanto, cuando se solicita firmar un permiso, los usuarios y las billeteras no pueden determinar el uso previsto del permiso.
• Con EIP-3074, los usuarios (1) no necesitan aprobar una gran cantidad de activos para la DApp de antemano, sino solo aprobar cuando hay una operación, y el efecto es el mismo que el permiso; (2) solo firman y no necesitan preocuparse por recopilar ETH para pagar la tarifa del procedimiento. Es lo mismo que el permiso; (3) Cada aprobación está vinculada a la operación especificada y firmada juntas. El usuario puede saber claramente “para qué se usa la aprobación” esta vez. ¡Esto será más seguro que el permiso!
• Se espera que EIP-3074 reemplace con éxito los métodos actuales de aprobación y permiso, proporcionando a los usuarios un método de autorización más seguro.

Renuncia：

1. Este artículo es una reimpresión de [imToken Labs]. Todos los derechos de autor pertenecen al autor original [Nic]. Si hay objeciones a esta reimpresión, por favor contacte alAprender en Gateequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los 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, está prohibido copiar, distribuir o plagiar los artículos traducidos.