Capa 2 Tokens nativos como pago de tarifas de transacción: Análisis técnico

Este artículo técnico examina las ventajas y desventajas de permitir que los usuarios paguen tarifas de transacción con tokens nativos de Capa 2, analizando tanto los mecanismos técnicos como las implicaciones en el mercado.

Requisitos previos

Se recomienda comprender los mecanismos de operación de Rollup y los mecanismos de Inclusión Forzada para una comprensión completa de este análisis.

Introducción

La mayoría de las redes de Capa 2 emiten sus propios tokens, aunque muchos se utilizan principalmente para fines de gobernanza ( como Arbitrum y Optimism ). Algunos protocolos de L2 han implementado mecanismos de staking para sus tokens nativos, incluidos Mantle y Manta. Estos tokens apostados sirven para diversas funciones, como determinar la autoridad de secuenciación de transacciones, el poder de generación de pruebas de conocimiento cero o garantizar que se cumplan los requisitos de publicación de datos. Para detalles técnicos, consulte la documentación de StarkNet, zkSync, Mantle y Manta.

Nota técnica: La verificación objetiva de la "publicación de datos correcta" presenta desafíos significativos, lo que dificulta la implementación de mecanismos de castigo efectivos. Esto plantea preguntas sobre la eficacia de los diseños que dependen de "apostar tokens L2 para la funcionalidad de publicación de datos."

Pago de Comisiones en Token Nativo: Análisis Técnico y de Mercado

Ventajas Técnicas

La implementación de tokens nativos de Capa 2 como mecanismos de pago de tarifas expande significativamente la utilidad del token más allá de las funciones básicas de gobernanza. Este enfoque puede mejorarse implementando mecanismos EIP-1559 para quemar una parte de los tokens recaudados como tarifas, lo que potencialmente crea presión deflacionaria que contribuye a la acumulación de valor dentro del ecosistema.

Limitaciones Técnicas

Desafío de Denominación de Costo de Datos

El problema fundamental sigue siendo que los Secuenciadores de Rollup deben pagar los costos de disponibilidad de datos en la moneda nativa de L1 (ETH) cuando suben datos de transacción a Ethereum. Esto crea un riesgo inherente de tipo de cambio entre el momento en que el Secuenciador recibe tokens de Capa 2 como pago y cuando debe convertir estos tokens a ETH para los costos de disponibilidad de datos. Esta exposición al riesgo agrega complejidad operativa para los operadores de Secuenciadores.

Nota técnica: Este problema se extiende más allá de los Rollups basados en Ethereum. Las redes de Capa 2 que utilizan capas de disponibilidad de datos alternativas ( como Mantle o Manta) enfrentan desafíos idénticos con el token nativo de la respectiva capa de DA.

Impacto en la Experiencia del Usuario

Los modelos de tarifas de un solo token pueden crear una fricción significativa en el proceso de incorporación de usuarios. Cuando los usuarios solo pueden pagar tarifas con el token nativo de la Capa 2, se encuentran con un problema de dependencia circular: necesitan el token para realizar transacciones, pero adquirir el token a menudo requiere ejecutar una transacción primero.

Por ejemplo, los usuarios que depositan ETH en Polygon PoS por primera vez descubren que no pueden usar ese ETH para pagar tarifas de transacción. Sin tokens MATIC ya disponibles en su billetera, no pueden ejecutar la transacción necesaria para intercambiar ETH por MATIC. Esto obliga a los usuarios a adquirir primero MATIC en L1 y luego trasladarlo al entorno L2.

Nota técnica: Aunque Polygon PoS es técnicamente una cadena lateral en lugar de una verdadera Capa 2, este ejemplo ilustra efectivamente el desafío de la experiencia del usuario.

Esta fricción se multiplica en todo el ecosistema, con N diferentes redes de Capa 2 que requieren N diferentes tokens para operaciones básicas.

Barreras de Interoperabilidad entre Capas 2

Los requisitos de tarifas del token nativo crean barreras técnicas significativas para la interoperabilidad fluida de Capa 2. Por ejemplo, una transferencia básica entre Capa 2 no se puede completar solo con ETH si la Capa 2 de destino requiere su token nativo para las tarifas de transacción.

Esto obliga a los usuarios a gestionar múltiples tenencias de tokens y a navegar por complejos desafíos de liquidez. Con N diferentes Capa 2, la liquidez se fragmenta a través de N-1 pares de tokens, lo que requiere que los usuarios realicen N intercambios distintos antes de operar en múltiples entornos de Capa 2. Las operaciones cruzadas más complejas entre Capa 2, como el préstamo, la apertura de posiciones y las liquidaciones, enfrentan una fricción acumulada debido a estos requisitos de tokens de tarifas.

La visión de la Supercadena de Optimism para la interoperabilidad ilustra perfectamente este desafío: si cada Rollup dentro del ecosistema de la Supercadena requiriera diferentes tokens para el pago de tarifas, socavaría directamente los objetivos fundamentales de interoperabilidad.

Sin embargo, estas limitaciones de experiencia e interoperabilidad solo se aplican a modelos de tarifas de tokens nativos exclusivos. Los enfoques híbridos que admiten tanto pagos de tarifas en ETH como en tokens nativos pueden mitigar estos problemas al permitir que los usuarios elijan ETH para operaciones entre cadenas mientras utilizan tokens L2 para operaciones nativas cuando lo deseen. StarkNet está siendo pionero en este enfoque híbrido al implementar soporte tanto para pagos de tarifas en ETH como en STRK.

Implementación Técnica: STRK como Tarifa de Transacción

StarkNet recientemente anunció el soporte para pagos de tarifas con tokens STRK junto con ETH. Este modelo de tarifas de doble moneda permite a los usuarios elegir su método de pago preferido, mientras que el Secuenciador ( llamado "Operador" en la terminología de StarkNet ) asume el riesgo de tipo de cambio entre ETH y STRK. Esto plantea importantes preguntas técnicas sobre la determinación de tarifas para las transacciones.

Análisis técnico de la autoridad del secuenciador

A través de las redes L1 y L2, las transacciones suelen especificar una tarifa máxima que el usuario está dispuesto a pagar. En las cadenas compatibles con EIP-1559 (Ethereum, Arbitrum, Optimism), los usuarios especifican un valor maxFeePerGas, que multiplicado por gasLimit define la tarifa máxima de la transacción. Las cadenas no compatibles con EIP-1559 utilizan modelos de tarifas fijas.

Nota técnica: StarkNet, aunque aún no implementa EIP-1559, requiere que los usuarios especifiquen un parámetro maxFee.

Los secuenciadores de transacciones (mineros, validadores o secuenciadores de Capa 2 ) mantienen la autoridad para incluir o excluir transacciones específicas. Sin embargo, una vez incluidas, las transacciones solo pueden ser cobradas hasta la tarifa máxima especificada por el usuario.

Análisis de Implementación de Oracle

STRK para la conversión de tarifas. Sin embargo, este enfoque pasa por alto la dinámica fundamental de autoridad del secuenciador: los secuenciadores pueden elegir qué transacciones incluir en función de sus propios incentivos económicos.

El factor crítico sigue siendo la tarifa máxima que un usuario especifica (en ETH o STRK), después de lo cual debe esperar su inclusión. Un oráculo de tipo de cambio público no alteraría fundamentalmente esta relación, ya que los secuenciadores mantienen la capacidad de cobrar hasta la tarifa máxima especificada.

Arquitectura de Oracle Off-chain para StarkNet

STRK específicamente para las operaciones del secuenciador. Esto plantea importantes preguntas de gobernanza técnica: ¿cómo puede la comunidad verificar que los secuenciadores calculan las tarifas de STRK de acuerdo con estas cotizaciones del oráculo?

Para mayor transparencia, las cotizaciones de los oráculos deberían estar disponibles públicamente, lo que permitiría la verificación por parte de la comunidad de los cálculos de tarifas de secuenciador. Si bien la integración de oráculos en la cadena proporcionaría garantías más sólidas, el enfoque actual representa un compromiso pragmático que intenta equilibrar la complejidad técnica con los requisitos de confianza de la comunidad.

Requisitos del Mecanismo de Inclusión Forzada

El mecanismo de Inclusión Forzada presenta un caso de uso más convincente para la integración de oráculos. Cuando los usuarios activan la Inclusión Forzada desde L1 ( para eludir a los secuenciadores L2 ), deben pagar tarifas de ejecución L2 a nivel L1. Por ejemplo, la función depositTransaction de Optimism quema gas de acuerdo con el límite de gas L2 especificado, cobrando efectivamente ETH en L1. De manera similar, requestL2Transaction de zkSync calcula los costos básicos de transacción L2 y requiere suficiente ETH en la transacción L1.

Si estos protocolos de Capa 2 implementan pagos de tarifas con tokens nativos, los mecanismos de Inclusión Forzada enfrentan un desafío técnico crítico: ¿cómo determinar de manera justa los cargos de ETH en L1 para transacciones que normalmente costarían tokens de Capa 2? Sin tasas de cambio precisas, esto podría penalizar injustamente a los usuarios de Inclusión Forzada a través de tarifas excesivas o permitir que los atacantes exploten tarifas artificialmente bajas.

Este escenario específico presenta un caso de uso convincente para la integración de oráculos, permitiendo que los contratos L1 calculen de manera justa las tarifas para las transacciones de Inclusión Forzada.

Alternativamente, los protocolos de Capa 2 podrían estandarizar sus tokens nativos para transacciones regulares y de Inclusión Forzada, eliminando la necesidad de conversión entre monedas. Sin embargo, los costos de disponibilidad de datos siguen denominados en ETH, creando un modelo de tarifas híbrido donde las transacciones de Inclusión Forzada requieren tanto ETH ( para datos) como tokens de Capa 2 ( para ejecución) - un desafío técnico que los desarrolladores de Capa 2 deben abordar al implementar modelos de tarifas con tokens nativos.

Síntesis Técnica

• Los tokens nativos de Capa 2 pueden cumplir múltiples funciones técnicas, siendo el pago de tarifas una expansión significativa de utilidad más allá de la gobernanza.

• La principal ventaja de los modelos de tarifas de tokens nativos es establecer una utilidad clara del token con posibles mecanismos deflacionarios a través de la implementación de EIP-1559.

• Las desventajas técnicas incluyen una mayor exposición al riesgo del secuenciador, fricción en la experiencia del usuario y barreras de interoperabilidad en todo el ecosistema de Capa 2.

• Modelos de tarifas híbridos que soportan tanto ETH como tokens nativos pueden preservar la experiencia del usuario y la interoperabilidad, al mismo tiempo que permiten la utilidad del token.

• StarkNet está pionero en un enfoque híbrido con soporte de tarifas del token STRK, implementando feeds de precios de oráculos fuera de la cadena para los secuenciadores.

• La autoridad del secuenciador sigue siendo una consideración técnica fundamental - los secuenciadores mantienen un poder significativo sobre la inclusión de transacciones y la determinación de tarifas, restringido solo por las tarifas máximas especificadas por el usuario.

• La integración de Oracle proporciona beneficios limitados para transacciones estándar, pero se vuelve críticamente importante para los mecanismos de Inclusión Forzada donde la conversión entre monedas afecta la seguridad y la equidad.

• Las implementaciones de inclusión forzada con tarifas de tokens nativos crean desafíos técnicos complejos, lo que puede requerir que los usuarios paguen tanto ETH ( por la disponibilidad de datos ) como tokens L2 ( por tarifas de ejecución ) en una única transacción.