¿Qué es el Delegation Toolkit y qué puedes construir con él?

El control de cuentas en Ethereum ha sido tradicionalmente rígido. Las cuentas de propiedad externa (EOAs) son simples y ampliamente utilizadas, pero tienen capacidades limitadas. Las cuentas de contrato inteligente (SCAs) ofrecen mucha más flexibilidad, pero hasta hace poco no podían operar de forma independiente. Aún se necesitaba una EOA para iniciar y pagar cada transacción.

Eso cambió con ERC-4337, ya que las SCAs ahora pueden admitir de forma nativa funciones como el patrocinio de gas, el agrupamiento de transacciones (combinar múltiples transacciones en una sola), las claves de sesión y la abstracción de cadena, lo que se traduce en mayor seguridad, flexibilidad y control para el usuario.

Sin embargo, las EOAs no han desaparecido. Y con razón: no todos los usuarios necesitan una cuenta que admita lógica de verificación arbitraria. ¿Qué sentido tiene migrar a una SCA en este momento?

Pero entonces, ¿cómo garantizamos que cuando estén listos para hacer el cambio —o incluso para aprovechar temporalmente una o más funciones de las cuentas ERC-4337— no se vean obligados a crear un nuevo tipo de cuenta desde cero? ¿Cómo permitimos que las EOAs accedan a las funciones de una SCA para transacciones específicas sin renunciar a su configuración habitual?

Aquí es donde entra en juego EIP-7702 (Set-EOA-account-code).

Como parte de la próxima actualización Pectra, EIP-7702 permitirá que las EOAs se comporten temporalmente como SCAs al delegar el control a código de contrato inteligente que se ejecuta directamente desde sus direcciones. Esto significa que los usuarios no tendrán que migrar a nuevas cuentas para disfrutar de estas funciones avanzadas. Garantiza la compatibilidad con versiones anteriores mientras impulsa el avance de Ethereum.

A pesar de estas mejoras, todavía hay un aspecto clave de la experiencia de usuario que debe desbloquearse para lograr plenamente una experiencia similar a la de web2: permisos detallados y flexibles que permitan al usuario compartir fácilmente la capacidad de realizar una acción específica en su nombre con otro usuario. Esto se hace de forma controlada, con límites estrictos y la posibilidad de revocar permisos cuando sea necesario.

Este es el desafío para el que se creó el Delegation Toolkit. Pero antes de profundizar en qué es y cómo funciona, analicemos más de cerca los dos ERCs que impulsan esta próxima fase de la experiencia de usuario de cuentas en Ethereum.

ERC 7710: Delegación de contratos inteligentes

ERC-7710 es una propuesta para estandarizar la forma en que las cuentas de contrato inteligente delegan permisos específicos a otras cuentas de Ethereum. Introduce una interfaz común para que los delegadores otorguen autoridad a los delegados con reglas claras y aplicables.

Con ERC-7710, los desarrolladores pueden crear sistemas donde una cuenta permite de forma segura que otra actúe en su nombre bajo ciertas condiciones, como límites de gasto, restricciones de tiempo o permisos específicos para determinadas tareas. Todo esto se gestiona a través de un flujo de delegación seguro y predecible.

Entonces, ¿qué significa "delegación" en este contexto?

En términos generales, se trata de separar la propiedad de la cuenta de su ejecución. Un delegador sigue siendo dueño de los activos o la lógica, pero puede transferir poderes específicos a otra persona de forma temporal o permanente sin ceder el control total.

Desde la perspectiva de la red, ERC-7710 aporta claridad y componibilidad a la forma en que se transfieren permisos entre cuentas. En lugar de que cada aplicación implemente su propia lógica de delegación, ahora existe una base común sobre la que los contratos y las herramientas pueden construir.

ERC 7715: Conceder permisos desde wallets

ERC-7715 es una propuesta para simplificar la forma en que las dapps solicitan permisos a las wallets de los usuarios. Introduce un modelo de permisos que permite a las dapps solicitar acceso previamente aprobado y con alcance definido a la cuenta de un usuario, sin necesidad de confirmaciones repetidas en cada interacción.

Hoy en día, el flujo de interacción típico es torpe: una dapp solicita enviar una transacción o interactuar con un contrato, y la wallet pide la aprobación del usuario cada vez. No hay forma de especificar límites, duraciones ni acotar el alcance de lo que una dapp puede hacer, y no existe un método estándar para que los usuarios vean o revoquen estas aprobaciones posteriormente.

ERC-7715 cambia eso. Introduce un nuevo método, wallet_grantPermissions, que permite a una dapp solicitar capacidades específicas con antelación. Por ejemplo, podría solicitar permiso para gastar hasta 10 USDC durante la próxima hora o interactuar con un único contrato inteligente durante las próximas sesiones. El usuario revisa esto de antemano y lo aprueba o rechaza con total claridad.

Desde la perspectiva de una dapp, esto facilita el proceso de incorporación y permite experiencias basadas en sesiones o automatizadas que no interrumpen constantemente al usuario. Para las wallets, introduce una estructura limpia y auditable para gestionar permisos y controlar lo que se ha concedido. Para los usuarios, ofrece mayor visibilidad, más control y menos ventanas emergentes molestas, todo sin sacrificar la seguridad.

Entonces, ¿qué pueden crear los desarrolladores con estos estándares?

Estas son algunas funciones que se pueden habilitar combinando ERC-7710 y ERC-7715:

• Establecer límites de gasto diarios desde una wallet segura usando ERC-7710 para delegar una asignación fija a una wallet de uso más frecuente, manteniendo la mayor parte de los fondos de forma segura sin conexión.

• Simplificar la incorporación permitiendo a los usuarios realizar acciones como acuñar tokens o reclamar recompensas sin configuración previa de la wallet ni aprobaciones de transacciones, mediante delegaciones preconfiguradas que otorgan permisos limitados automáticamente.

• Permitir que agentes de IA operen en tu nombre asignando permisos de ejecución limitados a través de ERC-7710, con ERC-7715 facilitando la aprobación de esos permisos desde tu wallet.

• Permitir que una dapp cubra las comisiones de gas de los usuarios asignando derechos de patrocinio a una SCA que aproveche la delegación de ERC-7710, permitiendo que transacciones específicas se procesen sin que el usuario necesite ETH.

• Revocar aprobaciones de tokens de forma segura delegando el permiso a un contrato auxiliar que llame a approve(0) en tu nombre, usando ERC-7710 para delimitar estrictamente lo que puede hacer y garantizar la compatibilidad con cualquier token ERC-20 estándar.

Y mucho más.

Definiendo el Delegation Toolkit

La forma más sencilla de describir el Delegation Toolkit es como un conjunto de herramientas que incluye dos paquetes principales:

1. El Delegation Core SDK – Un paquete que permite a los desarrolladores crear cuentas de contrato inteligente compatibles con ERC-4337 (cuentas delegadoras) que se benefician de todas las funciones introducidas por la abstracción de cuentas ERC-4337.

2. El Delegation Framework – Un sistema que permite a las cuentas de contrato inteligente delegar permisos a otras cuentas de Ethereum a través del estándar ERC-7710, y permite que sitios web, dapps o, eventualmente, cualquier entidad solicite permisos a tu cuenta a través de ERC-7715 (próximamente).

En términos simples, el Delegation Toolkit hace posible crear dapps que admitan cuentas de contrato inteligente (SCAs) compatibles con ERC-4337, deleguen permisos a otras SCAs o EOAs, y permitan a las dapps solicitar esos permisos, ya sea desde cuentas inteligentes o, tras la actualización Pectra, incluso desde EOAs.

Si estás familiarizado con cómo funcionan las cuentas de contrato inteligente, ya sabes qué esperar del paquete Delegation Core VIEM. Si no es así, puedes consultar la documentación oficial para profundizar más. En el resto de este artículo, nos centraremos en el Delegation Framework en sí y destacaremos algunos de los principios clave que lo hacen tan poderoso.

Delegación off-chain

Las delegaciones no necesitan estar en la cadena para ser válidas. Una vez que la Cuenta A firma una delegación para la Cuenta B, puede almacenarse en cualquier lugar: IPFS, caché del navegador, almacenamiento en la nube o incluso descargarse localmente, ya que es criptográficamente segura y solo puede ser utilizada por el delegado previsto. Esto hace que todo el sistema sea más escalable y flexible.

Por ejemplo, B puede obtener la delegación firmada cuando la necesite y usarla en una transacción sin requerir almacenamiento en cadena ni costos de gas anticipados.

Permisos revocables

Las delegaciones no son permanentes. El delegador original, digamos la Cuenta A, puede revocar cualquier delegación activa que haya emitido, incluso si esa delegación ya ha sido transferida a través de delegación transitiva (ver la sección sobre delegación transitiva o encadenada más adelante). Una vez revocada, el gestor de delegaciones rechazará cualquier intento de utilizarla, incluidas las subdelegaciones que dependan de ella. Esto es fundamental para la seguridad.

Si la Cuenta A sospecha que ha sido comprometida o desea actualizar los permisos, puede cortar el acceso de inmediato, invalidando toda la cadena de confianza. Es como poder desconectar todo en cualquier momento sin necesidad de rastrear a todos los involucrados.

Delegaciones con alcance definido

Con el Delegation Toolkit, las delegaciones generalmente están vinculadas a un delegado específico. Esto significa que si la Cuenta A firma una delegación para la Cuenta B, solo B puede utilizarla. Incluso si alguien más obtiene la delegación firmada, no le sirve de nada, ya que está vinculada criptográficamente a B.

Sin embargo, también existe soporte para delegaciones abiertas. Estas son delegaciones que no especifican un delegado de antemano y pueden ser utilizadas por cualquier cuenta. Las delegaciones abiertas son útiles cuando aún no se sabe quién será el delegado, pero deben usarse con precaución para evitar un uso indebido. Puedes crear una estableciendo el campo delegate en la constante especial ANY_BENEFICIARY (0x0000000000000000000000000000000000000a11).

Si la Cuenta B posteriormente desea transferir un permiso con alcance definido a la Cuenta C, debe crear explícitamente una nueva delegación de B a C. Esto garantiza que los límites de los permisos permanezcan claros e intencionales, incluso cuando se utilizan flujos abiertos o transitivos.

Caveats

Los caveats son las reglas que definen cómo puede utilizarse una delegación. Piensa en ellos como condiciones personalizadas que el delegador puede adjuntar a una delegación. Por ejemplo, si la Cuenta A delega en la Cuenta B, podría incluir un caveat que indique que B solo puede transferir hasta 1 ETH o interactuar únicamente con un contrato específico dentro de las próximas 24 horas.

Los caveats se aplican en tiempo de ejecución mediante contratos especiales de aplicación de caveats, que verifican que se cumplan las reglas antes de ejecutar cualquier acción. Así, aunque B tenga derecho a actuar, sigue operando dentro de los límites establecidos por A. Consulta aquí la lista completa de caveats admitidos o aprende a crear tu propio caveat personalizado.

Delegación transitiva o encadenada

Una de las funciones más poderosas del Delegation Framework es que la delegación no tiene que detenerse en una sola transferencia. Con la delegación transitiva, una cuenta que recibe un permiso —digamos la Cuenta B— puede a su vez delegar toda o parte de esa autoridad a otra cuenta, formando una cadena de delegaciones que se origina en una sola cuenta.

Cada eslabón de la cadena está firmado criptográficamente y delimitado con sus propios caveats, lo que significa que los permisos pueden reducirse o redefinirse en cada nivel. En otras palabras, estas subdelegaciones pueden ser un subconjunto del original, con restricciones más estrictas o capacidades limitadas.

Es importante destacar que el delegador original mantiene el control total y puede revocar la delegación inicial en cualquier momento, lo que invalida automáticamente todas las delegaciones posteriores en la cadena, creando una cadena de confianza flexible pero segura, ideal para configuraciones de permisos complejas como DAOs y wallets compartidas.

¿Qué sigue?

El Delegation Toolkit te proporciona las herramientas para incorporar sistemas de permisos más seguros, inteligentes y flexibles a tus dapps. Ya sea que busques habilitar gastos delegados, patrocinios de gas, flujos de trabajo automatizados o una incorporación fluida, todo es posible ahora sin tener que reinventar la rueda.

En las próximas publicaciones, nos pondremos manos a la obra, comenzando con un tutorial sobre cómo crear una función de "Invitar a un amigo", un ejemplo práctico de la delegación en acción. Mantente atento al resto de la serie, donde cubriremos más funciones que puedes implementar hoy mismo.

Si te entusiasma explorar estas ideas más a fondo, estate atento al próximo Gator Hackathon de abril, donde tendrás la oportunidad de crear con el Delegation Toolkit junto a otros desarrolladores.