Abstracción de cuentas parte 4: firmas agregadas

Firmas agregadas

Nuestra implementación actual valida cada user op del bundle por separado. Es una forma muy directa de pensar la validación, pero potencialmente ineficiente. Verificar firmas puede terminar siendo costoso en términos de gas porque requiere bastante aritmética criptográfica.

¿No sería bueno poder validar muchas ops al mismo tiempo con una sola firma en lugar de muchas?

Hacerlo depende de un concepto de la criptografía: las firmas agregadas.

Un esquema de firmas que soporta agregación provee una forma, dados múltiples mensajes firmados con distintas claves, de generar una única firma combinada tal que verificar la firma combinada implica que todas las firmas que la componen también son válidas.

Un ejemplo común de un esquema de firmas que soporta agregación es BLS.

Esta optimización es particularmente útil para implementar rollups, ya que el objetivo principal de un rollup es la compresión de datos, y la agregación de firmas nos permite comprimir la parte correspondiente a las firmas.

Para más información sobre el ahorro de espacio que produce la agregación de firmas, ver el tweet de Vitalik sobre el tema.

Presentando los aggregators

De inmediato, vemos que no todas las user ops de un bundle pueden tener sus firmas agregadas entre sí. Recordemos que una wallet tiene permitido usar la lógica arbitraria que quiera para validar la firma que recibe, por lo que puede haber varios esquemas de firma presentes en el mismo bundle.

Como probablemente no podamos agregar firmas de distintos esquemas, nuestro bundle terminará con grupos de ops, cada grupo usando un esquema de agregación distinto o ningún esquema de agregación.

Como necesitamos tener varios esquemas de agregación representados on chain, cada uno con su propia lógica, haremos que cada esquema de agregación esté representado por un contrato que llamaremos aggregator.

Un esquema de agregación se define por cómo combina múltiples firmas en una y por cómo valida la firma combinada, así que un aggregator expone estas dos funciones como métodos:

Como cada wallet define su propio esquema de firma, depende de cada wallet decidir con qué aggregator es compatible, si es que lo es con alguno.

Si una wallet quiere participar en la agregación, expone un método para elegir su aggregator:

Usando este nuevo método getAggregator, el bundler puede agrupar las ops que tienen el mismo aggregator y usar el método aggregateSignatures de ese aggregator para calcular una firma combinada para ellas.

Un grupo podría verse así:

A continuación, necesitamos actualizar el contrato entry point para que haga uso de los nuevos aggregators.

Recordemos que el entry point tiene un método handleOps que recibe una lista de ops.

Le daremos un nuevo método, handleAggregatedOps, que hace lo mismo pero recibe las ops agrupadas por aggregator:

El nuevo método, handleAggregatedOps, funciona en gran medida igual que handleOps. La única diferencia está en su paso de validación.

Mientras que handleOps realiza la validación llamando al método validateOp de cada wallet, handleAggregatedOps en cambio llamará al método validateSignatures del aggregator sobre la firma combinada de cada grupo, usando el aggregator de ese grupo.

¡Ya casi terminamos!

Pero hay un problema aquí que ya nos resulta bastante familiar.

El bundler quiere simular la validación y comprobar que el aggregator validará un grupo de ops antes de incluirlas en el bundle, porque si la validación falla, el bundler se ve obligado a pagar el gas. Pero un aggregator con lógica arbitraria puede fácilmente tener éxito durante la simulación y fallar durante la ejecución.

Resolveremos esto exactamente de la misma forma en que lo hicimos para los paymasters y las factories: restringimos qué storage puede acceder el aggregator y qué opcodes puede usar, y exigimos que haga stake de ETH en el entry point a menos que no acceda a storage.

¡Y eso es todo respecto a las firmas agregadas!

Cierre

Lo que hemos creado aquí es, más o menos, la arquitectura completa de ERC-4337. Hay algunas diferencias en los detalles, como los nombres y argumentos de algunos de los métodos, pero no queda nada que yo consideraría una diferencia arquitectónica. Si hice bien mi trabajo, ahora deberías poder leer el ERC-4337 real y entender qué está pasando.

Si llegaste hasta acá, ¡muchas gracias por leer esta explicación! Espero que te haya ayudado tanto como a mí me ayudó escribirla.

Apéndice: diferencias con ERC-4337

Si bien ya tenemos clara la arquitectura general de la abstracción de cuentas, las personas inteligentes detrás de ERC-4337 pensaron en algunas cosas que son ligeramente distintas de lo que describimos arriba.

¡Repasemos algunas de ellas!

1. Rangos de tiempo de validación

Arriba fui bastante vago respecto al tipo de retorno del validateOp de la wallet y del validatePaymasterOp del paymaster. ERC-4337 encuentra una buena manera de aprovechar esto.

Algo que a una wallet le gustaría mucho hacer es permitir que una user op sea válida solo durante cierto período de tiempo. De lo contrario, un bundler malicioso podría quedarse con esa operación durante mucho tiempo y luego incluirla en un bundle mucho después, en un momento que le resulte ventajoso al bundler.

La wallet podría querer defenderse de esto verificando el TIMESTAMP durante la validación para asegurarse de que no esté demasiado lejos en el futuro, pero no puede, porque hemos prohibido TIMESTAMP durante la validación para evitar que las simulaciones sean inexactas. Esto significa que la wallet necesita otra forma de indicar en qué momentos la operación es válida.

Por eso, ERC-4337 le da a validateOp un valor de retorno que la wallet puede usar para elegir un rango de tiempo:

Este valor de retorno representa el rango de tiempo en el que la operación es válida como dos enteros de 8 bytes, uno después del otro.

Otra nota de ERC-4337: las wallets deberían devolver un valor centinela desde validateOp en lugar de revertir en caso de fallo de validación, lo cual ayuda con la estimación de gas, porque eth_estimateGas no indica cuánto gas se usó en una transacción que revierte.

2. Call data arbitrario para wallets y factories

Dijimos que la interfaz de nuestra wallet era:

En ERC-4337, las wallets en realidad no tienen un método llamado executeOp.

En cambio, la user operation tiene un campo callData:

Esto se pasa a la wallet como call data.

Para un contrato inteligente típico, los primeros cuatro bytes de estos datos se interpretarán como un selector de función y el resto como argumentos de la función.

Esto significa que, aparte del método requerido validateOp, las wallets pueden definir su propia interfaz, y las user operations pueden usarse para llamar a métodos arbitrarios de la wallet.

De manera similar, en ERC-4337 los contratos factory tampoco tienen realmente un método deployContract. Ellos también reciben call data arbitrario, en este caso desde el campo initCode de la op.

3. Datos compactos para paymasters y factories

Arriba dijimos que la user operation contenía campos para especificar un paymaster, así como qué datos pasarle:

En ERC-4337, estos se combinan en un solo campo como optimización, donde los primeros 20 bytes del campo son la dirección del paymaster y el resto son los datos:

Lo mismo ocurre con las factories y los datos que se les envían: mientras que nosotros usamos dos campos, factory y factoryData, ERC-4337 los combina en un solo campo, initCode.

Bueno, ¡lo lograste!

Esperamos que hayas aprendido mucho sobre la Abstracción de Cuentas.

Podrías haber inventado la abstracción de cuentas

¿Te perdiste el comienzo de esta serie de 4 partes? ¡Vuelve atrás y léela desde el principio!

1. Abstracción de Cuentas Parte 1: Protejamos Nuestros Activos
2. Abstracción de Cuentas Parte 2: Patrocinando Transacciones con Paymasters
3. Abstracción de Cuentas Parte 3: Creación de Wallets