Introducción

En nuestro anterior post 15, presentamos el modelo ERC-4337. Este modelo describe la estructura del mercado de tarifas para los agrupadores y detalla la función de costo relacionada con el costo de publicación en la cadena y los costos de agregación fuera de la cadena de un paquete.

También introdujimos el concepto del "Juego del Agrupador". Este juego será el foco principal de la segunda parte. Dado un conjunto de transacciones, un agrupador puede elegir qué transacciones incluir en su paquete. Esto crea una asimetría de información entre los agrupadores y el usuario, ya que el usuario no sabe cuántas transacciones se incluirán en el paquete. Esto lleva a un juego de suma cero donde el usuario está en clara desventaja.

Esta investigación tiene como objetivo explorar métodos para mejorar la UX asegurando que los usuarios no tengan que pagar de más por la inclusión en el próximo paquete. En su lugar, los usuarios deberían poder pagar una tarifa basada en la demanda de mercado real para la inclusión.

Estado actual de ERC-4337

En el mercado actual, la mempool P2P no está en vivo en la mainnet y se está probando en la testnet de Sepolia. Las empresas que trabajan en ERC-4337 están operando actualmente en modo privado, los usuarios se conectan a través de un RPC a un paqueteador privado que luego trabajará con un constructor para publicar en la cadena su operación de usuario.Aplicación Bundle Bear 3, desarrollado por Kofi, proporciona algunas estadísticas intrigantes sobre el estado actual de ERC-4337.

En el Paquetes Semanales de Multi-UsuarioOp 1En métricas, observamos el porcentaje de bundlers que crean paquetes que incluyen múltiples operaciones de usuario. Desde principios de 2024 hasta junio de 2024, este porcentaje no ha superado el 6.6%. Estos datos resultan aún más interesantes al considerar que muchos bundlers ejecutan sus propios paymasters, entidades que patrocinan transacciones en nombre de los usuarios. Es notable que los dos bundlers más grandes que también operan como paymaster, en términos de operaciones de usuario publicadas,patrocinado 97% 1de las operaciones del usuario utilizando sus servicios. El pagador paga por algunas partes de la operación del usuario y el resto es pagado por los dapps u otros.entidad 1.

La pregunta que surge es por qué los pagadores, las dApps, etc., están pagando por las operaciones de los usuarios. ¿El usuario les devolverá el dinero en el futuro? No podemos estar seguros de lo que sucederá, pero mi suposición personal es que actualmente, las dApps están cubriendo las tarifas para aumentar el uso y la adopción de sus aplicaciones. Una vez que la adopción sea alta, es probable que los usuarios tengan que pagar las transacciones ellos mismos. Vale la pena mencionar que para el usuario pagar por una operación de usuario con el modelo actual no es la mejor opción, ya que una operación básica ERC-4337 cuesta ~ 42,000 gas, mientras que una transacción normal cuesta ~ 21,000 gas.

Variaciones en ERC-4337

Resumen de ERC-4337

El mempool todavía está en fase de prueba en Sepolia y no está activo en la red principal. Sin el mempool, los usuarios tienen opciones limitadas para utilizar la abstracción de cuentas. Los usuarios interactúan con un RPC, que puede ser ofrecido por un agrupador que agrupa las operaciones de usuario, o con un servicio RPC que no agrupa, similar a servicios como Alchemy o Infura, que reciben y propagan transacciones a otros agrupadores.

Una vez que la mempool esté activa, el flujo de transacciones se parecerá al diagrama a continuación, que es similar al flujo de transacciones actual. Una mempool mejora la resistencia a la censura para los usuarios porque, a diferencia del modelo RPC, reduce las posibilidades de que una transacción sea excluida. Sin embargo, incluso con una mempool, todavía existe el riesgo de que un proveedor de RPC no reenvíe la transacción, pero el modelo de mempool es particularmente beneficioso para los usuarios que prefieren ejecutar sus propios nodos, ya que mitiga este riesgo.

Si bien los agrupadores tienen el potencial de actuar como constructores, preferimos mantener los roles separados debido al panorama competitivo. Los agrupadores enfrentarían una competencia significativa de constructores sofisticados existentes, lo que haría que la construcción fuera menos atractiva y potencialmente menos rentable. Como resultado, los agrupadores tienen más incentivos para colaborar con constructores establecidos en lugar de construir de forma independiente y arriesgarse a pérdidas.

La combinación de los roles de agrupador y constructor en una sola entidad implica cambios significativos en el sistema actual. Los agrupadores tendrían que competir con los existentes constructores sofisticadosO, alternativamente, los constructores actuales deberán integrarse horizontalmente y asumir también el papel de agente de agrupación. El último escenario, aunque más plausible, plantea preocupaciones sobre la concentración del mercado y el posible impacto negativo en la resistencia a la censura.

Empacadores y constructores como dos entidades diferentes

Con los usuarios conectándose directamente a un RPC, todo se ejecuta en un entorno más privado, lo cual no ayuda con la competencia en el mercado. En un futuro cercano, el mempool estará en la mainnet aumentando la competencia.

Utilizar un mempool, en el que los userops son públicos para diferentes bundlers, aumenta la competencia, en el caso de la abstracción de cuenta no nativa es necesario tener una separación entre el bundler y el builder, en el caso de la abstracción de cuenta nativa es posible que no sea necesaria la separación ya que el builder puede interpretar los userops como transacciones normales.

Esto podría llevar al siguiente resultado: en un entorno competitivo, los agrupadores reducirán sus precios para ser seleccionados por los usuarios, quienes buscarán el precio más bajo para la inclusión de su operación de usuario en un paquete. Esta competencia creará un sistema donde el agrupador que ofrece el mejor precio será seleccionado con más frecuencia que el agrupador que solo intenta maximizar sus ganancias mediante la creación de paquetes más pequeños. La separación de las funciones del agrupador y el constructor también puede mejorar la resistencia a la censura. Un agrupador puede crear un paquete de operaciones de usuario agregadas y enviarlo a diferentes constructores. Si el paquete incluye operaciones que podrían ser censuradas, un constructor que no censura puede aceptarlo y proceder con la construcción. Sin embargo, vale la pena señalar que desde la perspectiva de un usuario, esta configuración podría aumentar los costos, ya que la introducción de un agrupador agrega una parte adicional, lo que lleva a gastos más altos.

RIP-7560

La abstracción de cuenta nativa no es un concepto novedoso; se ha estado investigando durante años. Si bien ERC-4337 está ganando impulso, su implementación fuera del protocolo ofrece ventajas distintas junto con compensaciones. Es importante destacar que las cuentas EOAs existentes no pueden realizar transiciones sin problemas a las SCWs y es más difícil utilizar varios tipos de listas resistentes a la censura. Como se mencionó anteriormente, los costos adicionales de gas de una operación de usuario aumentan significativamente en comparación con una transacción normal.RIP-7560 2no resolverá inherentemente el problema continuo relacionado con los costos fuera de la cadena, pero reducirá sustancialmente los gastos de transacción. Desde aproximadamente ~42000 gas, es posible reducir el costo en~20000 gas.

Abstracción de cuenta Layer2s

La abstracción de cuenta se puede utilizar en soluciones de Capa 2 (L2). Algunos L2 ya lo implementan de forma nativa, mientras que otros siguen el enfoque L1 y esperan una nueva propuesta similar a RIP-7560. En L2, L1 se utiliza para la disponibilidad de datos para heredar seguridad, mientras que la mayoría de la computación ocurre fuera de cadena en L2, lo que proporciona transacciones más baratas y escalabilidad.

En escenarios en los que la computación en L2 es significativamente más barata que el costo de calldata para la disponibilidad de datos (DA) en la cadena principal, el uso de la agregación de firmas resulta altamente beneficioso. Por ejemplo, el emparejamiento para BLS en la red principal es facilitado por Gate.0x08 1precompilar desde el EVM, lo cual cuesta aproximadamente ~45000k gas. En consecuencia, usar BLS en L1 es más costoso que las transacciones tradicionales.

Ya se están utilizando técnicas de compresión en L2, como la compresión de 0 bytes, que reduce el costo de ~188 bytes a ~154 bytes para una transferencia ERC20. Con la agregación de firmas, la eficiencia de compresión se puede mejorar aún más mediante el uso de una sola firma, reduciendo el tamaño a ~128 bytes.

En las capas 2, la agregación de firmas es una innovación crucial que mejora tanto la eficiencia de las transacciones como la rentabilidad. Al combinar múltiples firmas en una sola, la carga de datos general se reduce significativamente, lo que disminuye los costos asociados con la disponibilidad de datos en la Capa 1. Este avance no solo mejora la escalabilidad, sino que también reduce los costos de transacción para los usuarios, lo que hace que el sistema sea más económico y eficiente.

Economía de agregación de firmas en Layer2s

Al utilizar un servicio L2, el usuario incurre en varios costos, incluyendo una tarifa para el operador L2, un costo basado en la congestión de la red y el costo de la disponibilidad de datos en L1.

De una investigación anterior sobre ”Comprender la economía de rollup desde los principios fundamentalesPodemos resumir los costos que enfrenta un usuario al utilizar los servicios de L2 de la siguiente manera:

Cuando un usuario interactúa con una capa 2, tiene algunos costos que podemos definir de la siguiente manera:

• Tarifa del usuario = Tarifa de publicación de datos de L1 + Tarifa del operador de L2 + Tarifa de congestión de L2
• Coste del operador = Coste del operador de L2 + Coste de publicación de datos de L1
• Ingresos del operador = Tarifas del usuario + MEV
• Beneficio del operador = Ingresos del operador - Costo del operador = Tarifa de congestión L2 + MEV

En el caso de la abstracción de cuenta no nativa, una entidad adicional, el agrupador, puede introducir una tarifa por crear paquetes de userops.

Teniendo en cuenta el agrupador, los costos y beneficios se extienden de la siguiente manera:

• Tarifa del usuario = tarifa de publicación de datos de L1 + tarifa de operador de L2 + tarifa de congestión de L2 + tarifa del agrupador
• Costo del agrupador = Cotizado (tarifa de publicación de datos L1 + tarifa del operador L2 + tarifa de congestión L2)
• Ingresos de paquetes = Tarifa del usuario
• Beneficio del agrupador = Ingresos del agrupador - Costo del agrupador = Diferencia entre los costos de L1 y L2 y los precios cotizados del agrupador + Tarifa del agrupador
• Costo del operador = tarifa de publicación de datos L1 + tarifa del operador L2
• Beneficio del operador = Ingresos del operador - Costo del operador = Tarifa de congestión L2 + MEV

El agrupador cobra su tarifa al usuario por sus servicios, mientras que el resto del pago del usuario cubre los costos del operador L2. Si el usuario desconoce el tamaño del paquete, estimar el costo real de enviar las operaciones del usuario se vuelve difícil, lo que podría llevar al agrupador a cobrar tarifas más altas de las necesarias para cubrir el costo del operador.

Alineación de incentivos en L2

La interacción entre el agrupador y L2 ayuda a abordar este problema, ya que los L2 están incentivados a mantener bajos los costos para los usuarios debido a la competencia. Cobrar de más a los usuarios puede llevarlos a cambiar a otros L2 que ofrecen precios más justos.

Redefinamos nuestro modelo introduciendo el operador. El usuario realiza una oferta al agrupador para ser incluido en el siguiente bloque L2 al ofrecer un valor V. El usuario tiene como objetivo minimizar la tarifa de publicación de datos, mientras que el agrupador busca maximizar su tarifa o obtener un excedente de los costos de interacción L2 y las tarifas del usuario.

Los costos asociados con la creación de un paquete y su publicación en la cadena se pueden dividir en dos partes:

Función de costo en cadena: Un agrupador que emite el paquete B cuando la tarifa base es r incurre en un costo:

Función de costo agregada: El empaquetador tiene una función de costo para agregar n transacciones en un solo paquete B con una tarifa base de r:

con S′F, que contiene la publicación y verificación de la única firma agregada en cadena.

Si el usuario puede obtener una estimación confiable para n, puede calcular su costo utilizando la función estimateGas, disponible en la mayoría de las soluciones L2. Tener una buena estimación puede permitir al usuario hacer una oferta adecuada sin tener que sobreestimar su oferta para su inclusión. Esta función determina el costo necesario para garantizar la inclusión. Tener una buena estimación para n y la función estimateGas puede evitar que el usuario pague un preVerificationGas más alto. En la próxima sección, exploraremos diversos mecanismos para garantizar una estimación confiable de n.

Layer2s operan un oráculo

El papel del oráculo es monitorear el mempool y estimar el número de transacciones presentes. El proceso funciona de la siguiente manera: la Capa 2 implementa un oráculo para verificar el mempool y luego informa al usuario sobre el número de transacciones en el mempool. Esto permite al usuario estimar su oferta para ser incluido en un paquete. La Capa 2 puede solicitar al empaquetador que incluya al menos un número especificado de transacciones (n) en un paquete, de lo contrario, el paquete será rechazado. Una vez que el empaquetador reúne suficientes transacciones para formar un paquete, envía el paquete a la Capa 2, que luego lo reenvía a la mainnet como datos de llamada para la disponibilidad de datos.

Propuesta de vigilancia691×642 47.4 KB

Layer2s con secuenciador compartido

Un enfoque interesante es tener múltiples redes de Capa 2 (L2) que ejecuten un secuenciador compartido. Esta configuración puede proporcionar una estimación más precisa del mempool, ya que el secuenciador llega a un acuerdo a través del consenso facilitado por el secuenciador compartido.

En esta configuración, diferentes redes L2 operan de forma independiente pero comparten un secuenciador común. A intervalos regulares, estas redes verifican el número de operaciones de usuario (userops) en el mempool compartido. El secuenciador compartido ayuda a sincronizar y aggreGate datos de estas redes. Una vez que llegan a un acuerdo, la información se comunica al usuario, lo que le permite ofertar en función del número de userops presentes.

Este enfoque ofrece varias ventajas. En primer lugar, proporciona un método descentralizado para determinar el número de userops en el mempool, mejorando la resistencia a la colusión. En segundo lugar, elimina el único punto de falla que podría ocurrir si solo un sistema estuviera gestionando la comunicación entre el usuario y el mempool. En tercer lugar, el secuenciador compartido garantiza la consistencia y reduce las discrepancias entre las diferentes soluciones de L2.

Al aprovechar el secuenciador compartido, este método garantiza un sistema sólido y confiable para estimar y comunicar el estado del mempool a los usuarios, mejorando así la eficiencia y seguridad general del proceso.

Shared Sequencer764×785 66.3 KB

En los dos enfoques explicados utilizando un oráculo, hay un vector de ataque potencial donde un adversario podría generar múltiples operaciones de usuario en el mempool, sabiendo que se revertirán si se agregan juntas. Como resultado, el oráculo ve que hay

n

transacciones y requiere un paquete grande, pero el empaquetador no puede crear el paquete. Este problema podría detener la red durante muchos bloques.

Layer2s operan su propio bundler

En esta propuesta, la Capa 2 misma asume el papel del agrupador, mientras que otra entidad maneja la agregación de firmas (esto podría ser servicios de agrupación actuales). El proceso funciona de la siguiente manera: la Capa 2 opera su propio agrupador, y los usuarios envían sus operaciones (userops) al mempool. La Capa 2 selecciona algunas de estas userops del mempool y las envía 'en bruto' al agregador, compensando al agregador por la agregación de las firmas. Una vez que el agregador produce el paquete, lo envía al agrupador, que luego lo reenvía a la mainnet como calldata para la disponibilidad de datos.

La idea principal es que la Capa 2 se encarga de la recopilación de userops y luego subcontrata la agregación a otra entidad. La Capa 2 paga por la agregación y cobra al usuario una tarifa por el servicio.

Hay dos opciones diferentes:

1. Modelo de tarifa plana: El agrupador (Secuenciador) selecciona algunas transacciones y cobra al usuario una tarifa plana. Esta tarifa plana se calcula de manera similar a las transacciones de la Capa 2 actuales, prediciendo el costo futuro de la publicación de datos de L1. Alternativamente, la Capa 2 podría cobrar al usuario una tarifa plana basada en el costo de agrupar n.
2. aggreGated userops, la capa 2 aún tiene que predecir cuántas transacciones estarán presentes en el paquete que construirá para cotizar correctamente al usuario, esto se puede hacer de la misma manera que se hace ahora donde el l2 cobra el mejor precio competitivo al usuario, es de interés de la Capa 2 mantener los precios lo más competitivos posible para el usuario.
   
3. Flat Fee671×702 22.1 KB
4. Solicitar reembolsos: Si la Capa 2 desea mejorar su credibilidad, podría habilitar reembolsos automáticos. Esto implicaría un mecanismo que verifica cuántas operaciones de usuario se publican en un solo bloque y si las transacciones podrían haber sido agregadas. Si una operación de usuario que podría haber sido agregada no lo fue y no se emitió un reembolso automático, el usuario puede solicitar un reembolso. En este escenario, la Capa 2 podría apostar algunos activos y, si no se proporciona el reembolso, el usuario podría hacer valer el reembolso, garantizando la equidad y la responsabilidad.
   
5. Solicitar reembolso671×702 22.8 KB

Conclusión

En estas dos publicaciones diferentes, describimos las dificultades que los usuarios experimentan al hacer una oferta para ser incluidos en el próximo paquete. En la primera parte, presentamos el modelo ERC-4337, explicando los costos que incurre un agrupador al publicar un paquete en la cadena y los costos externos asociados. También describimos los mercados de tarifas para los agrupadores y comenzamos a discutir el problema de dar formato al agrupador. Los usuarios experimentan dificultades al hacer ofertas debido a la falta de conocimiento sobre el número de transacciones presentes en el mempool en el momento del agrupamiento.

En la segunda parte, explicamos ERC-4337 y RIP-7560. Luego discutimos por qué la agregación de firmas es más probable que ocurra en soluciones de Capa 2 en lugar de directamente en la Capa 1. Demostramos cómo las soluciones de Capa 2 podrían abordar el conocimiento asimétrico que los usuarios experimentan de diferentes maneras. La primera es usar oráculos para señalar al usuario cuántas transacciones están presentes en el mempool, con este enfoque el usuario sabe cuánto debería ofertar y puede obligar al agrupador a hacer paquetes más grandes. El tercer enfoque, que es el más simple, es que la L2 actúa como un agrupador y subcontrata la agregación a un tercero y permite a los usuarios pagar una tarifa por ello.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [ethresear], Avance del título original 'Embedded fee markets and ERC-4337 (parte 2)', Todos los derechos de autor pertenecen al autor original [ DavideRezzoli & Barnabé Monnot]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learn equipo, y lo manejarán con prontitud.

2. Responsabilidad de descargo de responsabilidad: Las opiniones y puntos de vista 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.