Acerca de Permit2
Uniswap acaba de lanzar un nuevo estándar de aprobación de tokens, Permit2, que difiere de los tradicionales ERC20 y EIP-2612. Permit2 permite a los usuarios evitar la necesidad de una operación de “aprobación” a nivel de cadena antes de interactuar con diferentes DApps, permitiendo que el protocolo DApp adquiera primero la aprobación de su token. Según la descripción, el nuevo protocolo Permit2 tiene las ventajas de ahorrar gas, permitir operaciones por lotes de aprobación/transferencias y ser más flexible que la aprobación ERC20 tradicional, además de admitir la gestión de aprobación en un único punto.
Uniswap concibió inicialmente Permit2 y Universal Router para mejorar su propio producto, optimizar los costes de gas, simplificar el proceso de transacción del usuario y mejorar la seguridad. Durante el proceso conceptual, Uniswap consideró que otras aplicaciones podrían beneficiarse enormemente de la integración de estos contratos. La propia Uniswap se dedica a construir infraestructuras públicas, por lo que diseñó estos contratos para que pudieran ser utilizados por todo el ecosistema de desarrolladores, incluyendo una amplia documentación y Soft Developer Kit (SDK).
Un SDK es un paquete de herramientas de software integrado que ayuda a los programadores a desarrollar soluciones blockchain. Ideal para acelerar el desarrollo de blockchain. Muchos SDK incluyen una o más API criptográficas.
Para ilustrar lo revolucionario que es Permit2, repasemos las soluciones anteriores tomando el ejemplo de un contrato que necesita mover tokens en posesión de Alice.
Modelo tradicional de aprobación
La forma tradicional de ejecución se muestra en el siguiente diagrama.
- Alice llama a la función approve() en el ERC20 para conceder al contrato un límite de control.
- Alice llama a una función de interacción en el contrato, que a su vez llama a transferFrom() en el contrato de tokens ERC20 para mover sus tokens. Es evidente que este modelo es factible (ya que es ampliamente existente) y en última instancia puede ser muy flexible, debido a que el protocolo puede acceder continuamente a los tokens del usuario durante un período prolongado de tiempo.
El contrato de aprobación recibe por defecto la aprobación para controlar la cantidad máxima de tokens, sin limitaciones temporales. Cada DApp requiere una aprobación única para la primera ejecución, lo que plantea riesgos significativos.
Pero se enfrenta a dos problemas bien conocidos en el mundo real:
- Mala experiencia de usuario: Los usuarios deben conceder la aprobación para cada nuevo protocolo que pretendan utilizar en cada token, lo que casi siempre supone una transacción independiente (por ejemplo, ejecutar una aprobación de token en Uniswap, pero tener que volver a aprobarla si se utiliza Transit).
- Poca seguridad: Los contratos suelen requerir un límite de aprobación ilimitado, y la aprobación debe ejecutarse cada vez que se utiliza un swap u otro contrato. Esto significa que si se explota el protocolo, todos los usuarios que lo hayan aprobado para consumir sus tokens podrían ver transferidos todos sus tokens aprobados. (Por ejemplo, a menudo nos encontramos con la aprobación del uso de tokens, como la aprobación para operar DeFi, la aprobación para intercambiar, y la aprobación para el uso por primera vez de diferentes DApps)
Modo Permiso (EIP-2612)
EIP-2612 itera sobre la aprobación de tokens. Los usuarios pueden interactuar con el contrato de la aplicación adjuntando una firma de aprobación (Permiso) o lo que es igual a una información en su transacción, sin la necesidad de pre-aprobar.
Echemos un vistazo a los métodos habilitados por la extensión EIP-2612 de ERC20, que suele ser así:
- Alice firma un mensaje de “permiso” fuera de la cadena, indicando que desea conceder a un contrato el derecho a utilizar un token (EIP-2612).
- Alice envía el mensaje firmado como parte de su interacción con dicho contrato.
- El contrato llama al método “permiso()” del token, que utiliza la información de aprobación de la firma y la firma para conceder el permiso al contrato.
- El contrato ahora tiene permiso, por lo que puede llamar a transferFrom() sobre el token, transfiriendo los tokens en posesión de Alice.
Debido al requisito del EIP-2612 (Permiso) de tener los métodos relacionados escritos dentro del contrato de token ERC20, los contratos ERC20 desplegados existentes no pueden ser soportados.
Esto resuelve dos problemas del típico método de aprobación del ERC20:
- El usuario no necesita enviar una transacción approve() adicional en la cadena.
- Dado que se omite una operación en la cadena, se puede elegir una cantidad de aprobación normalmente más razonable en lugar de ilimitada y, lo que es más importante, se puede establecer un tiempo de caducidad al firmar el mensaje de aprobación.
Aunque el EIP-2612 hace que la aprobación de tokens sea más segura, los tokens lanzados antes del EIP-2612 carecen de la aprobación de firmas y sólo algunos tokens de reciente emisión han adoptado esta función. Por lo tanto, el protocolo no está muy extendido.
Permiso2 Modelo de aprobación
Permit2 combina ambos modelos, ampliando la experiencia de usuario y las ventajas de seguridad de EIP-2612 para cubrir también los tokens ERC20 estándar。
- Alice llama a approve() en un ERC20, de forma típica, dando al contrato Permit2 aprobación ilimitada.
- Alice firma un mensaje Permit2 fuera de la cadena, indicando que el contrato del protocolo está autorizado a transferir tokens en su nombre.
- Alice llama a una función de interacción en el contrato de protocolo, pasando el mensaje Permit2 firmado como argumento.
- El contrato de protocolo llama a permitTransferFrom() en el contrato Permit2, y el contrato Permit2 utiliza su aprobación (concedida en 1) para llamar a “transferFrom()” en el contrato ERC20, transfiriendo los tokens en posesión de Alice.
Al conceder la aprobación a Permit2, las DApps que utilizan el protocolo Permit2 solo necesitan realizar una firma local 712 una vez, lo que elimina la necesidad de una aprobación adicional a nivel de cadena y reduce las tasas de Gas, al tiempo que aumenta la usabilidad y la seguridad. La aprobación está limitada en el tiempo, por ejemplo, si se concede por un mes, después de que expire el mes, sólo se requiere una firma 712 para ser utilizada de nuevo.
El protocolo no llamará directamente a transferFrom() en el token ERC20 para ejecutar la transferencia, sino que llamará a permitTransferFrom() del contrato estándar Permit2. Permit2 se sitúa entre el protocolo y el token ERC20, rastreando y validando el mensaje permit2 y, en última instancia, utilizando su aprobación para ejecutar directamente la llamada transferFrom() en el ERC20. Este carácter indirecto permite a Permit2 ampliar las ventajas similares a las del EIP-2612 a todos los tokens ERC20 existentes.
Ventajas del protocolo Permit2:
- Gestión unificada de tokens
- Tiempo de aprobación controlable
- No es necesario enviar cada vez una transacción para su aprobación
Posibles riesgos del permiso2
Permit2 se deriva de EIP 2612 y es una extensión del protocolo EIP 20, por lo que, en última instancia, Permit2 es sólo un complemento de ERC20, no un sustituto. Después de todo, Permit2 no hereda todos los datos existentes de ERC20, y la llamada gestión de ventanilla única sigue requiriendo llamar a la función de aprobación del contrato ERC20 para completar algunas operaciones iniciales.
El proceso completo del Permiso2 debe ser:
- El usuario concede la aprobación máxima de tokens ERC20 al contrato Permit2.
- El usuario gestiona aprobaciones específicas a través de la función de permiso en el contrato Permit2.
- Los protocolos de terceros y los usuarios pueden transferir tokens a través del contrato Permit2 como intermediario basándose en la información de aprobación ya disponible en Permit2.
Posibles riesgos del protocolo Permit2:
- Aunque afirma resolver el problema de la aprobación infinita, sólo transfiere el objeto de aprobación de la DApp interactuante al contrato Permit2, y la seguridad del contrato Permit2 requiere normas más estrictas para la gestión centralizada de las aprobaciones.
- Aunque la aprobación del token tiene un tiempo de expiración, este tiempo puede ser ilimitado, y las Dapps necesitan establecer tiempos de expiración razonables.
- Dado que el proceso de llamada a la función de permiso puede realizarse sin enviar una transacción, limitándose a proporcionar una firma a un tercero para su reenvío, puede quedar más oculto si se utiliza para suplantación de identidad. El coste de comprobar el mensaje de firma aumenta, y algunos monederos de terceros pueden no descodificar y mostrar la información de la firma, lo que aumenta el riesgo de ataque al usuario.
Existen ventajas y riesgos al mismo tiempo, lo que nos exige cierta capacidad de discernimiento. Específicamente, el monedero también necesita tener prevención previa para el posible soporte a gran escala de Permit2 en el futuro (TokenPocket todavía no soporta el parseo de Permit2, pero lo hará pronto). Por ejemplo, las actuales ventanas emergentes de advertencia de riesgo de aprobación de TokenPocket pueden mostrar bien el contenido de riesgo, evitando así riesgos como el phishing o la aprobación maliciosa por parte de terceros.
No abra sitios web desconocidos ni los ejecute imprudentemente. Asegúrese de utilizar DApps regulares y controlar la cantidad de tokens concedidos a los contratos tanto como sea posible. Utilice regularmente herramientas de comprobación de autorizaciones para inspeccionar.
Sígueme en mis redes sociales
