EIP-3074 Experiencia de

uso mejor y más segura

EIP-3074 permite que EOA (cuentas de propiedad externa) transfiera el control a un contrato específico, obteniendo así las mismas capacidades de ejecución enriquecidas que el contrato. Antes de EIP-3074, un EOA solo podía realizar una operación por transacción, como aprobar ERC20 o intercambiar en Uniswap. Después de EIP-3074, un EOA puede realizar múltiples operaciones a la vez, o incluso realizar tareas previamente inimaginables. En pocas palabras, EIP-3074 mejora en gran medida la experiencia del usuario, y el método familiar de autorización de token se remodelará, aumentando la seguridad sin cambiar la experiencia del usuario.

Además, a través de EIP-3074, EOA no necesita enviar transacciones más largas a la cadena por sí misma, eliminando el problema de tener que recaudar ETH para pagar las tarifas de transacción.

Contrato de invocador

El contrato que puede obtener el control de EOA se denomina contrato de invocador. Por supuesto, no cualquier contrato puede obtener el control de la EOA: la EOA debe firmar con una clave privada, y el contenido de la firma especificará claramente qué contrato de Invoker es y qué operaciones puede realizar el Invoker.

El contenido de la firma EOA especificará claramente qué contrato de Invoker (dirección de invocador) y autorizará las operaciones de ese contrato de Invoker (confirmación)

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

1. Alice firma con su clave privada EOA y, a continuación, proporciona el contenido de la firma y la firma al repetidor
2. El repetidor lleva la cadena a la ejecución del contrato
del
3. invocador El invocador verifica la firma. Después de pasar la verificación, puede realizar operaciones como EOA, como aprobar USDC, luego ir a Uniswap para intercambiar y, finalmente, transferir algo de USDC al Relayer como tarifa de manejo.

Nota 1: El repetidor no es necesario. Alice también puede aportar su propio contenido y sello a la cadena.

Después de que el invocador verifique la firma y comience a ejecutar la operación, se ejecutará como Alice EOA, que es como obtener el control (limitado) de la EOA.

Sin embargo, debe tenerse en cuenta que el valor nonce del EOA no aumentará después de la ejecución, por lo que se puede reutilizar la misma firma (tan larga como el nonce EOA permanezca sin cambios), por lo que el invocador debe implementar su propio mecanismo nonce para evitar la reproducción.

Si el contrato de Invoker no es a prueba de reproducción, se puede ejecutar la misma autorización todo el tiempo.

Para obtener una introducción al mecanismo operativo real de EIP-3074, consulte: Introducción a EIP3074

Application

Permite a los usuarios fusionar la ejecución de varias transacciones en una sola, ahorrando el proceso de múltiples firmas autorizadas y algunos costos de Gas.

Nota: Esto requerirá que la dApp también soporte la función Batchcall, como EIP-5792, que actualmente está siendo impulsada por la comunidad. De lo contrario, la dApp solo solicitará al usuario que firme una vez para cada operación si trata al usuario como un EOA normal.

Clave de sesión

Los usuarios también pueden permitir que un tercero actúe en su nombre bajo ciertas condiciones. La clave delegada en el diagrama siguiente es el tercero autorizado; la política de acceso es la restricción de ejecución, como limitarla a operar solo Uniswap, transferir un máximo de 1 ETH por día, período de validez de autorización, etc. Estas condiciones están diseñadas y verificadas dentro del contrato de Invoker. Tan larga como se supere la comprobación, el tercero puede ejecutar operaciones como EOA de un usuario.

Telegram Bot puede recibir permisos específicos para realizar operaciones en nombre del EOA del usuario

Native ETH Permit

En largo se cumplan las condiciones (es decir, la firma del Permiso sea legal), la transferencia de ETH se puede realizar como EOA autorizador, logrando el efecto del Permiso ETH nativo.

Orden límite

El usuario rellena el límite orden las condiciones, y cuando se cumplen las condiciones, se puede ejecutar como EOA del usuario, incluida la aprobación de tokens para DEX, ir a DEX para su canje, etc. En comparación con los Orden límite proporcionados por DEX en sí, los usuarios no necesitan enviar transacciones a DEX para su aprobación por adelantado.

Cuando Alice completa una orden, ejecutará una aprobación al mismo tiempo, eliminando la necesidad de aprobación previa.

Si la condición está diseñada para ser más general, se convertirá en un contrato de intención: tan largas como se cumplan las condiciones especificadas por el usuario, cualquiera puede ejecutar la intención en nombre de su EOA.

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

Social Recovery

Cuando el usuario pierde la clave privada de EOA, él (Alice) puede usar la autorización EIP-3074 que firmó, junto con las firmas de su persona autorizada (esposo y agente fiduciario) para transferir todos los activos de EOA. En realidad, lo que se recupera son los activos (transferibles), no el control de la cuenta. Después de perder la clave privada EOA, la EOA no se puede utilizar más larga.

Cuando el usuario pierde la clave privada de EOA, otras personas autorizadas pueden firmar y autorizar la transferencia de activos de EOA.

Impacto de EIP-3074

¿Mejorar los métodos de autorización de tokens y potencialmente reemplazar aprobar/permitir?

Actualmente, las dApps se diseñan bajo el supuesto de que el usuario es un EOA: el usuario debe "preaprobar" y "aprobar una cantidad suficiente de dinero" para el contrato de dApp. Esto significa que los usuarios no necesitan permanecer en línea todo el tiempo, esperar a que se ejecute la dApp o volver a aprobarla constantemente, lo que mejora en gran medida la experiencia del usuario. Para aplicaciones activadas por condiciones, como órdenes limitadas o DCA, es posible que los usuarios no estén en línea cuando se cumplan las condiciones, por lo que deben aprobar previamente una cantidad de dinero lo suficientemente grande como para que se ejecute el contrato de dApp, y puede ser un proceso repetitivo.

El usuario debe aprobar una cantidad lo suficientemente grande para la dApp por adelantado para que la dApp pueda operar con su dinero.

Pero también es necesario confiar en la dApp o evitar la aprobación de la dApp falsa, y poder eliminar la aprobación inmediatamente

Los modos de permiso que aparecieron más tarde, como el token nativo EIP-2612 o el Permit2 no nativo, son todos para mejorar la experiencia de uso y la seguridad del modo de aprobación: los usuarios no necesitan aprobar una gran cantidad de dinero más largo para cada contrato de dApp (y cada token debe aprobarse una vez). En cambio, el usuario solo necesita "firmar un nombre" para autorizar el contrato de dApp a "retirar la cantidad especificada" dentro del "tiempo especificado". Esto no solo reduce en gran medida la superficie de ataque, sino que también mejora en gran medida la experiencia del usuario.

Los usuarios solo necesitan firmar off-chain, y pueden especificar la cantidad y el período de validez, proporcionando una mejor experiencia de usuario y seguridad que aprobar.

Pero, de hecho, no solo aprueba, sino que el modo de permiso se ha utilizado como método de ataque de estafa con frecuencia (1,2,3): las víctimas firmaron por error lo que pensaban que era un permiso para una dApp, pero en realidad se le dio al atacante.

Cuando los usuarios firman un permiso, solo pueden ver a quién autorizar, pero no saben qué operaciones se emparejarán con él para ejecutarlo.

Nota: El diseño actual del permiso no es compatible con dApps de operación repetitiva, como DCA u otras aplicaciones de pago regulares. Esto se debe a que el permiso tiene un mecanismo de protección de repetición, por lo que una vez que se completa una transferencia, no se puede volver a usar el mismo permiso, lo que significa que los usuarios deben firmar un permiso por adelantado para cada operación repetitiva futura.

Sin embargo, EIP-3074 brinda una oportunidad para el cambio: cuando los desarrolladores de dApp saben que EOA puede realizar varias operaciones complejas a través de Invoker, el diseño de la interacción de dApp no necesita sacrificar más la seguridad en los órdenes para mejorar la experiencia del usuario, como "los usuarios preaprueban una gran cantidad de dinero" y "los usuarios firman un mensaje de permiso para autorizar el retiro". En su lugar, los usuarios vinculan las operaciones de dApp para aprobar y realizar la ejecución atómica a través de Invoker: las operaciones de aprobación y dApp se ejecutan correctamente juntas o fallan juntas. No hay posibilidad de éxito solo para la aprobación, por lo que los usuarios pueden estar seguros de que esta aprobación es para esta operación. Y los usuarios están utilizando la autorización de firma off-chain, por lo que la experiencia del usuario es la misma que la permitida. ¡Esto significa que dApp no necesitará más largo el modo de permiso! En el futuro, las billeteras pueden prohibir directamente o realizar revisiones más estrictas de las solicitudes de firma de permisos, sin tener que preocuparse por si hará que los usuarios no usen algunas dApps (pero a su vez se usarán para estafar).

Los usuarios no más largos simplemente autorizan una determinada dirección, sino que autorizan una determinada dirección y qué hacer, e incluso ven el resultado de la ejecución simulada.

Nota: ¡Esto no significa que las estafas puedan bloquearse por completo! Los usuarios aún pueden ser engañados en sitios web fraudulentos, y los sitios web fraudulentos aún pueden organizar operaciones de aprobación o transferencia para que los usuarios las firmen, pero en este momento los usuarios pueden al menos ver lo que va a hacer esta firma, y las billeteras pueden incluso simular mostrar los resultados de la ejecución y presentarlos a los usuarios, para que los usuarios puedan saber claramente quién perderá cuánto dinero y quién ganará cuánto dinero. En comparación con los permisos que no saben qué resultado de la operación o incluso de la ejecución, los usuarios tienen más información para decidir si autorizan o no. Aunque no es una cura perfecta, seguirá siendo una mejora sustancial de la situación actual.

Cómo maneja el Billetera los nonces de EOA

El diseño actual de EIP-3074 incluirá el valor de nonce EOA en el contenido de la firma, largo como EOA envía una transacción a la cadena para su ejecución y cambia el valor nonce, se invalidarán todas las autorizaciones originales de EIP-3074.

Si el usuario autoriza a otra persona a operar el EOA, como la clave de sesión o el método de recuperación social mencionado anteriormente, se debe evitar que cambie el nonce del EOA. De lo contrario, es necesario volver a firmar todas las autorizaciones y entregárselas al fiduciario, lo que tiene un impacto considerable en la experiencia del usuario y la robustez del mecanismo.

Si el usuario está autorizado a operar por sí mismo, no hay necesidad de impedir específicamente que se cambie el nonce EOA, porque aún se espera que la firma EIP-3074 se ejecute antes de un plazo determinado, como la transacción. Es solo que la billetera necesita administrar más transacciones EIP-3074 del EOA: si hay firmas EIP-3074 esperando ser cargadas en la cadena, entonces las transacciones del propio EOA tendrán que esperar.

Nota: El contrato de Invoker en sí mantendrá (y debería) mantener un conjunto de mecanismos de nonce, por lo que después de usar la firma, aún debe firmarse nuevamente, independientemente de si cambia el nonce de EOA.

Lo más probable es que Session Key y Social Recovery tengan que esperar hasta que EIP-3074 cambie las reglas para eliminar el nonce EOA del contenido de la firma antes de que puedan adoptarse a gran escala. Por lo tanto, la billetera solo necesita centrarse en el caso de uso de "operaciones autorizadas por el usuario" y tratar la firma EIP-3074 como una transacción. No hay necesidad de preocuparse por evitar transacciones de envío de EOA o cambiar el nonce de EOA.

Sin embargo, hay que tener en cuenta que si el usuario quiere traer su propio contenido de firma EIP-3074 a la cadena, habrá dos desventajas:

1. El usuario debe firmar dos veces: una para la firma EIP-3074 y otra para la firma de transacción on-chain.
2. Debido a que la transacción on-chain agregará 1 al nonce EOA antes de que la transacción comience a ejecutarse, el nonce EOA en la firma EIP-3074 del usuario debe agregarse previamente 1 para que coincida con el nonce EOA +1 causado por la propia cadena.

Debido a que la cadena agregará 1 al nonce EOA primero, la verificación de la firma EIP-3074 fallará debido a la falta de coincidencia del nonce EOA.

Si los usuarios agregan 1 al nonce EOA en la firma EIP-3074 antes de incorporarlo a la cadena ellos mismos, la verificación puede continuar sin problemas.

Resumen y resaltados

• EIP-3074 permite a EOA obtener las mismas capacidades de ejecución ricas que los contratos, abriendo muchos nuevos escenarios de aplicación.
• Esto no solo mejorará en gran medida la experiencia del usuario, sino que también cambiará el método actual de autorización de tokens, haciéndolo más seguro mientras se mantiene la misma experiencia de usuario.
• Además, EIP-3074 es una firma simple, y los usuarios no necesariamente tienen que llevar la firma a la cadena para su ejecución, por lo que no hay necesidad de preocuparse por reunir ETH para pagar las tarifas de transacción.
• Los usos de EIP-3074 incluyen llamada por lotes, clave de sesión, permiso ETH nativo, orden límite y recuperación social. Muchos de estos eran previamente imposibles de lograr para las EOA, y algunos, como el orden límite, requerían métodos de autorización previa inseguros para ser utilizados.
• EIP-3074 también cambiará el método actual de autorización de tokens. El método de aprobación autoriza directamente a una dirección específica a tener el poder de retirar tokens indefinidamente, y requiere que el EOA del usuario envíe una transacción para ejecutar la aprobación, por lo que la experiencia del usuario y la seguridad no son buenas; El método de permiso solo requiere que el usuario firme, y cada firma especificará la cantidad y el período de validez, lo que mejora en gran medida la experiencia del usuario y la seguridad en comparación con la aprobación.
• Sin embargo, el permiso todavía se usa con frecuencia en estafas. Al firmar, los usuarios solo pueden saber a quién autorizar, cuánto y el período de validez, pero no saben para qué es esta autorización. "Para qué sirve" será otra firma (o transacción). Las dApps normales permitirán a los usuarios firmar el permiso y "para qué sirve", pero seguirán siendo dos firmas diferentes, por lo que cuando se les solicite que firmen el permiso, ni el usuario ni la billetera pueden saber para qué se usará este permiso.
• Con EIP-3074, los usuarios (1) no necesitan aprobar una gran cantidad de dinero a dApp por adelantado, sino que solo necesitan aprobar cuando hay una operación, que tiene el mismo efecto que el permiso; (2) es solo una firma simple y no necesita preocuparse por reunir ETH para pagar la tarifa de transacción, que es la misma que el permiso; (3) Cada aprobación está vinculada a una operación específica y firmada junta, por lo que los usuarios pueden saber claramente para qué es esta aprobación, ¡que será más segura que el permiso!
• Se espera que EIP-3074 pueda reemplazar con éxito los modos actuales de aprobación y permiso y proporcionar a los usuarios un método de autorización más seguro.

Disclaimer:

1. Este artículo es una reimpresión de [imToken Labs]. Todos los derechos de autor pertenecen al autor original [Nada]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones 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.