Explicación detallada del impacto de EIP-3074 en Billetera y DApp.

Autor: Nic @ imToken Labs

EIP-3074

Mejor y más seguro experiencia de uso

EIP-3074 permite que un EOA transfiera el control a un contrato específico, obteniendo así la capacidad de ejecución similar a la del contrato.

Antes de EIP-3074, una EOA solo podía realizar una operación cada vez, como aprobar ERC20 o hacer un intercambio en Uniswap. Después de EIP-3074, una EOA puede realizar varias operaciones a la vez o incluso tener usos antes inimaginables.

En pocas palabras, EIP-3074 mejora significativamente la experiencia de uso y redefine los métodos de autorización que conocemos actualmente, todo esto sin comprometer la seguridad.

Y a través de EIP-3074, EOA no tiene más largo que enviar transacciones a la cadena por sí mismo, y no hay necesidad de preocuparse por recaudar ETH para pagar primero las tarifas de transacción.

Contrato Invoker

Poder obtener el control EOA de un contrato se conoce como contrato Invoker. Por supuesto, no todos los contratos pueden obtener el control EOA: EOA debe firmar con una llave privada, el contenido de la firma especificará claramente qué contrato Invoker y qué operaciones se permiten ejecutar al Invoker.

El contenido de la firma EOA especificará claramente qué contrato Invoker (dirección del invocador) y qué operación autoriza al contrato Invoker (compromiso).

El proceso de ejecución real se verá así:

• Alice firma con su clave privada de EOA y luego entrega el contenido firmado y la firma al Relayer.
• El Relayer envía la cadena al contrato Invoker para su ejecución.
• Invoker verifica y firma, una vez verificado puede operar como EOA, por ejemplo, aprobar USDC y luego intercambiar activos en Uniswap, finalmente, utilizar algo de USDC como comisión para el Relayer.

Nota 1: El repetidor no es necesario, Alice también puede traer su contenido de firma y firma a la cadena.

Invoker después de verificar y firmar, ejecuta la operación como Alice EOA, como si obtuviera el control limitado de EOA.

Sin embargo, tenga en cuenta que ejecutarlo no aumentará el valor de nonce de esta EOA, por lo que la misma firma puede ser utilizada repetidamente (siempre que el nonce de la EOA no cambie). Por lo tanto, el Invoker debe implementar su propia trampa nonce para evitar la reproducción.

Si el contrato Invoker no tiene protección contra repeticiones, una misma autorización puede ser ejecutada continuamente.

Conoce más sobre la introducción al mecanismo de funcionamiento real de EIP-3074 en:

Aplicación

Batchcall

Permite a los usuarios combinar múltiples transacciones que normalmente se dividirían en varias en una sola transacción, ahorrando así el proceso de autorización y firma repetitiva, así como algunos costos de Gas.

Nota: Esto requerirá que la DApp también admita la función Batchcall, como el EIP-5792 que la comunidad está promoviendo actualmente. De lo contrario, la DApp tratará al usuario como una cuenta EOA normal y solo solicitará la firma del usuario para cada operación en una transacción separada.

Comprenda EIP-5792, por favor copie el enlace y consulte en el navegador.

Clave de sesión

Los usuarios también pueden permitir que terceros realicen operaciones en su nombre bajo ciertas condiciones restringidas. Por ejemplo, la clave de delegación en la imagen a continuación es un tercero autorizado; y la política de acceso establece las condiciones limitantes, como la restricción de operar solo en Uniswap, transferir un máximo de 1 ETH al día, establecer un límite de tiempo para la autorización, entre otras.

Estas condiciones están diseñadas y verificadas dentro del contrato Invoker, siempre y cuando la verificación sea exitosa, un tercero puede realizar operaciones en nombre del usuario EOA.

El bot de Telegram puede recibir permisos específicos para realizar operaciones en nombre del usuario EOA.

Permiso nativo ETH

Siempre que se cumplan las condiciones (es decir, si la firma del permiso es válida), se puede realizar una transferencia de ETH en nombre del autorizador como EOA, logrando así el efecto del permiso nativo de ETH.

Orden con límite

El usuario completa las condiciones de la orden de límite y puede ejecutarla cuando se cumplan las condiciones, incluyendo la aprobación de activos digitales relacionados para DEX y realizando intercambios en DEX, entre otras operaciones. En comparación con la orden de límite proporcionada por DEX, el usuario no necesita enviar previamente la transacción de aprobación a DEX.

Cuando Alice llene un orden, ejecutará la aplicación por cierto, y no es necesario que más largo tenga una aprobación previa.

Si se diseña la condición de manera más genérica, se convertirá en un contrato de intención: siempre que se cumplan las condiciones especificadas por el usuario, cualquier persona podrá ejecutar la intención completada en su identidad de EOA.

Tan larga como se cumpla la condición de intención, cualquiera puede iniciar una ejecución en nombre del EOA del usuario.

Recuperación social

Llave privada

Cuando un usuario pierde la llave privada de EOA, otras personas autorizadas previamente pueden firmar y transferir los activos de EOA.

Impacto de EIP-3074

¿Mejorar la forma de autorización de activos, incluso reemplazar a approve/permit?

DApp actualmente se diseñan bajo la suposición de que los usuarios son EOA: los usuarios deben “aprobar de antemano” y “aprobar una cantidad suficientemente grande de activos” para el contrato de DApp, de esta manera los usuarios no necesitan estar en línea todo el tiempo, esperando la ejecución de DApp y no necesitan aprobar repetidamente, lo cual mejora en gran medida la experiencia de uso.

Por ejemplo, las aplicaciones activadas por condiciones, como las órdenes limitadas o DCA, es posible que los usuarios no estén en línea cuando se cumplan las condiciones. Por lo tanto, deben aprobar de antemano una cantidad suficientemente grande de activos para que el contrato DApp los ejecute, y es posible que se ejecute repetidamente.

El usuario debe aprobar previamente una cantidad suficientemente grande de activos en DApp para poder permitir que DApp utilice su dinero para operar.

Pero también debemos confiar en DApp o evitar aprobar a DApp falsos, así como poder eliminar la aprobación en tiempo real.

O simplemente, el modo de permiso que apareció más tarde, como EIP-2612 o el no nativo Permit2, se crearon para mejorar la experiencia de uso y la seguridad del modo de aprobación: los usuarios ya no necesitan aprobar grandes cantidades de activos para cada contrato de DApp (y aprobar cada activo una vez), sino que solo necesitan “firmar” una vez para autorizar al contrato de DApp a “extraer una cantidad especificada de activos” durante un “tiempo especificado”, lo que no solo reduce en gran medida la superficie de ataque, sino que también mejora considerablemente la experiencia de uso.

Para obtener más información sobre EIP-2612, por favor copia el enlace a continuación en tu navegador para consultar:

Permit2 详情，请复制下方链接到浏览器查询：

El usuario solo necesita firmar fuera de la cadena y puede especificar la cantidad de activos y el período de validez, lo que proporciona una mejor experiencia de uso y seguridad que la aprobación.

Pero de hecho, no solo el modo de “approve” y “permit” se utilizan como medios de ataque para estafas, los casos siguen siendo frecuentes: las víctimas firman por error un “permit” que creen que es para ser utilizado por una DApp, pero en realidad se lo están dando al atacante.

Cuando los usuarios firman un permiso, solo pueden ver a quién se le otorga la autorización, pero no saben qué operación se ejecutará junto con ella.

Nota: Además, el diseño actual del permiso no es compatible con DApp de operaciones repetitivas, como DCA u otras aplicaciones de pago periódico. Esto se debe a que el permiso tiene un mecanismo de prevención de reproducción, por lo que una vez que se ha transferido, no se puede utilizar el mismo permiso nuevamente. Esto significa que el usuario debe firmar previamente un permiso para cada operación repetitiva en el futuro.

Para obtener más información sobre los incidentes en los que se ha utilizado el modo de “permiso” como método de ataque fraudulento, por favor copie el enlace a continuación y péguelo en su navegador para realizar la consulta.

No obstante, EIP-3074 ha presentado una oportunidad de cambio: cuando los desarrolladores de DApp se dan cuenta de que pueden realizar diversas operaciones complejas a través de Invoker, el diseño de la interacción de DApp ya no necesita comprometer la seguridad en aras de mejorar la experiencia de uso, por ejemplo, “aprobar previamente grandes cantidades de activos por parte del usuario” o “autorizar el retiro mediante un mensaje de permiso firmado por el usuario”.

En su lugar, los usuarios pueden combinar la operación de DApp con la aprobación, y realizar una ejecución atómica a través del Invoker: o bien la aprobación y la operación de DApp se ejecutan con éxito juntas, o ambas fallan juntas. No es posible que la aprobación se realice con éxito de forma independiente, por lo que los usuarios pueden estar seguros de que esta aprobación es para esta operación.

Además, los usuarios utilizan la autorización de firma fuera de la cadena, por lo que la experiencia de uso 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 podrán bloquear o examinar de manera más estricta las solicitudes de firma de permisos, sin tener que preocuparse por si los usuarios podrán o no utilizar ciertas DApps (pero que puedan ser utilizadas para estafas).

El usuario ya no solo autoriza una dirección en particular, sino también qué acciones realizar, e incluso puede ver el resultado de ejecuciones simuladas.

Este no significa que se pueda prevenir completamente el fraude. Los usuarios todavía pueden ser engañados para ingresar a sitios web de estafas, y estos sitios web pueden realizar operaciones de aprobación o transferencia y hacer que los usuarios firmen. Sin embargo, en este caso, al menos los usuarios pueden ver para qué se está realizando la firma, e incluso las billeteras pueden mostrar los resultados de la ejecución a través de la simulación y presentarlos a los usuarios, para que los usuarios sepan claramente quién perderá cuánto dinero y quién ganará cuánto dinero. En comparación con los permisos que no permiten saber qué operaciones se están realizando o incluso los resultados de la ejecución, los usuarios tienen más información para decidir si autorizar o no. Aunque no es una prevención perfecta, sigue siendo una mejora significativa en la situación actual.

¿Cómo maneja la billetera el nonce de EOA?

El diseño actual de EIP-3074 incluye el valor de nonce de EOA en el contenido de la firma, por lo que si un EOA envía una transacción que se ejecuta en la cadena y cambia el valor de nonce, la autorización original de EIP-3074 se invalidará por completo.

Si el usuario autoriza a otra persona para que actúe en nombre de su cuenta EOA, como se mencionó anteriormente, ya sea mediante una clave de sesión o mediante el método de recuperación social, el nonce de la cuenta EOA debe evitarse que sea modificado. De lo contrario, se debe volver a firmar todas las autorizaciones y entregarlas nuevamente al fiduciario, lo cual afecta significativamente tanto la experiencia de uso como la robustez del mecanismo.

Si el usuario está operando bajo su propia autorización, no es necesario evitar especialmente que el nonce de EOA se modifique, ya que la firma EIP-3074 todavía se espera que se ejecute antes de cierto plazo, al igual que la transacción. Solo el monedero debe gestionar más transacciones EIP-3074 de este EOA: si hay una firma EIP-3074 esperando ser confirmada en la cadena, las transacciones del EOA deben esperar.

Nota: el contrato Invoker deberá (y debería) mantener su propia trampa de nonce, por lo que después de usar una firma, deberá firmar nuevamente, independientemente de si ha cambiado el nonce de la cuenta externa (EOA).

Billetera solo necesita centrarse en el escenario de “autorización de operaciones por parte del usuario” y tratar la firma de EIP-3074 como una transacción, para evitar preocuparse por enviar transacciones desde una cuenta de contrato externo (EOA) o cambiar el nonce de EOA. Es muy probable que Session Key y Social Recovery solo puedan ser ampliamente adoptados después de que EIP-3074 modifique las reglas y elimine el nonce de EOA del contenido de la firma.

Pero ten en cuenta que si el usuario desea llevar su propio contenido de firma EIP-3074 a la cadena, habrá dos inconvenientes:

1. El usuario debe firmar dos veces: una vez con la firma EIP-3074 y otra vez con la firma de la transacción en la cadena.
2. Debido a que las transacciones en la cadena se incrementan en 1 antes de que se ejecute la transacción, el nonce EOA firmado con EIP-3074 por el usuario debe incrementarse en 1 de antemano para que coincida con el nonce EOA +1 causado por la transacción en la cadena.

Debido a que el nonce de EOA se incrementa antes de que se registre en la cadena, la verificación del sello EIP-3074 fallará debido a una discrepancia en el nonce de EOA.

Antes de que el usuario se ancle en la cadena, es necesario que aumente en 1 el nonce de EOA en la firma de EIP-3074 para pasar la verificación sin problemas.

Resumen y puntos clave

• EIP-3074 permite a las EOA tener la misma capacidad de ejecución que los contratos inteligentes, lo que abre muchas nuevas posibilidades de aplicación.
• Esto no solo mejorará en gran medida la experiencia de uso, sino que también cambiará el método de autorización actual, haciéndolo más seguro sin alterar la experiencia de uso.
• Además, EIP-3074 es una firma simple, los usuarios no necesariamente tienen que ejecutar la firma en la cadena ellos mismos, por lo que no necesitan preocuparse por tener que reunir ETH primero para pagar las tarifas.
• El propósito de EIP-3074 incluye Llamada en Lote, Clave de Sesión, Permiso ETH Nativo, Orden Límite, Recuperación Social. Muchos de estos eran originalmente imposibles de hacer para una dirección de Ethereum (EOA) y algunos, como la Orden Límite, requerían métodos menos seguros como la autorización previa.
• EIP-3074 también cambiará la forma actual de autorización. aprobar autoriza directamente a la dirección especificada a tener derecho a retirar activos digitales indefinidamente, y requiere que el usuario EOA envíe una transacción para ejecutar la aprobación, por lo que la experiencia del usuario y la seguridad no son buenas; El permiso solo necesita ser firmado por el usuario, y cada firma especificará la cantidad de activos y el período de validez, lo cual es mucho mejor que aprobar en términos de experiencia de usuario y seguridad.
• Sin embargo, el permiso todavía se usa con frecuencia para el fraude, y el usuario solo puede saber qué dirección autorizar, más o menos activos y período de validez al firmar, pero no sabrá para qué se “usa” la autorización. El “qué hacer” será otra firma (o transacción), y una DApp normal le pedirá al usuario que firme el permiso y “para qué usarlo”, pero seguirán siendo dos firmas diferentes, por lo que cuando se solicite la firma del permiso, ni el usuario ni la billetera sabrán para qué se “usará” el permiso.
• Con EIP-3074, los usuarios (1) no necesitan aprobar una gran cantidad de activos a la DApp por adelantado, sino que solo aprueban cuando hay una operación y el efecto es el mismo que el permiso; (2) Simplemente firme y no tenga que preocuparse por compensar ETH para pagar la tarifa de manejo, lo mismo que el permiso; (3) Cada aprobación está vinculada a la operación especificada y firmada junta, de modo que el usuario pueda saber claramente para qué se “usa” la aprobación, ¡lo que será más seguro que el permiso!
• Se espera que EIP-3074 reemplace con éxito el modo actual de aprobación y permiso y proporcione a los usuarios un método de autorización más seguro.