Tuven Chain: Nueva solución para el problema del pago de Gas y análisis de riesgos de seguridad relacionados

Casi todos los que han utilizado una billetera en la cadena han encontrado este problema: tener un montón de tokens en la cuenta, querer hacer una transferencia o interactuar con un contrato inteligente, pero la transacción falla debido a la falta de Gas. En las principales cadenas públicas compatibles con EVM, se exige que las tarifas de Gas se paguen con el token nativo de la cadena, lo que significa que los nuevos usuarios deben obtener tokens nativos adicionales para iniciar interacciones. Además, las tarifas de Gas fluctúan dinámicamente según el nivel de congestión de la red blockchain, lo que impide que los usuarios prevean con precisión el costo real de las tarifas antes de que se confirme la transacción. Este es uno de los principales obstáculos para la adopción masiva de Web3.

Este artículo analizará las soluciones actuales de tarifas de Gas en la industria de Web3 y desglosará la nueva solución de la cadena pública RWA, Tuven Chain, desde dimensiones como la lógica de implementación técnica, los puntos de innovación arquitectónica y los riesgos potenciales, proporcionando referencias para los desarrolladores de cadenas públicas y auditores de seguridad.

1. Soluciones principales de tarifas de Gas

1.1 Mecanismo de pago de Paymaster de ERC-4337 (abstracción de cuentas)

Paymaster es un contrato especial definido en el marco de ERC-4337 que permite pagar las tarifas de Gas en nombre del usuario durante la ejecución de UserOperation. De esta manera, los usuarios no necesitan poseer monedas nativas de la cadena al enviar transacciones, lo que reduce la barrera de entrada para nuevos usuarios. El flujo de trabajo central del pago de Gas es:

(1) El usuario inicia la operación: el usuario firma y envía una operación de usuario (UserOperation) en su billetera inteligente.

(2) Empaquetado y verificación: el Bundler (empaquetador) recopila múltiples operaciones y las envía al contrato de pago y al contrato de entrada (Entrypoint).

(3) Intervención de Paymaster: el contrato de Paymaster verifica si acepta pagar el Gas para esa operación.

(4) Liquidación de tarifas: se ejecuta la transacción en la cadena, y el Entrypoint deduce el token nativo (como ETH) de la cuenta de depósito de Paymaster como tarifa de Gas.

(5) Compensación posterior: los modelos comunes de pago de Gas incluyen el patrocinio total, donde el proyecto cubre completamente las tarifas de Gas para nuevos usuarios o actividades específicas; el pago con tokens, donde el usuario no tiene tokens nativos de la red principal (como ETH) pero puede usar USDT o USDC en su billetera para pagar el Gas, que Paymaster convierte automáticamente en segundo plano; y el pago condicional, donde el proyecto establece reglas que solo permiten el pago para usuarios que poseen un NFT específico, completan tareas específicas o utilizan tokens específicos dentro de la aplicación.

La limitación de esta solución es que las cuentas externas ordinarias (EOA) no pueden usarla directamente; los usuarios deben cambiar o actualizar a una billetera de abstracción de cuentas.

1.2 Modelo de transacciones meta y relés

Esta es otra solución en blockchain para reducir la barrera de entrada para los usuarios y lograr "sin tarifas de Gas" o el pago de tarifas de minería. Las transacciones meta se refieren a que los usuarios no envían directamente la transacción a la blockchain, sino que firman un mensaje de "metadatos" que contiene la intención de la operación y los datos fuera de la cadena con su clave privada. El relé se encarga de recopilar las firmas fuera de la cadena de los usuarios, actuando como el iniciador real de la transacción en la cadena y pagando las tarifas de Gas, transmitiendo la transacción a la blockchain. Su flujo de trabajo central es el siguiente:

(1) Firma del usuario: el usuario firma localmente la intención (como transferencias, llamadas a contratos) sin consumir Gas en la cadena.

(2) Envío a servicios fuera de la cadena: el usuario envía la firma y los datos al relé (que puede ser el servidor oficial de DApp o un servicio de terceros).

(3) Empaquetado del relé: el relé encapsula la firma en una transacción real en la cadena, firma con su cuenta de billetera y paga las tarifas de Gas.

(4) Verificación del contrato inteligente: el contrato inteligente objetivo recibe la transacción, analiza y verifica la firma original del usuario, y ejecuta la lógica correspondiente si es correcta.

Sin embargo, esta solución presenta riesgos de centralización y ataques de repetición: si el relé falla o se niega intencionalmente a atender ciertas solicitudes de usuarios, estos no podrán enviar transacciones; además, el relé puede ver la intención de las transacciones de los usuarios y podría utilizar esta información para realizar transacciones anticipadas. Si la firma del usuario es obtenida por un atacante y el contrato carece de verificación de Nonce y ChainID, podría dar lugar a un ataque de repetición.

Las soluciones mencionadas no han modificado directamente la lógica de facturación en la capa de ejecución de consenso de la cadena. Tuven Chain intenta modificar la lógica de ejecución subyacente para permitir el pago de tarifas de Gas fijas con tokens personalizados, sin cambiar las billeteras ordinarias ni modificar las aplicaciones, es decir, completar el reemplazo de la moneda de tarifas y el bloqueo de precios.

2. Lógica central de implementación de Tuven Chain

Tuven Chain se bifurca de la cadena Arc de Circle, heredando la capacidad básica de pago de Gas con monedas estables de Arc. La innovación central radica en la reutilización inversa del mecanismo de verificación de listas negras existente. Se construye un registro de SponsorRegistry, combinando credenciales de identidad SBT para completar el control de acceso de usuarios, así como la lógica de deducción de tarifas y acceso a transacciones.

2.1 Componentes centrales SponsorRegistry.sol / sponsor_registry.rs

SponsorRegistry es el contrato central predesplegado, actuando como una "tabla de paquetes de tarifas de Gas" global, que almacena múltiples configuraciones de tarifas de Gas. La disposición del almacenamiento de datos está estrictamente fijada, y el código Rust de la capa de ejecución lee datos directamente a través de los slots de almacenamiento.

// SponsorRegistry.sol — La disposición está "congelada", el manejador lee directamente por slot, el orden no puede cambiar
struct GasPlan { address token; uint256 feePerTx; address feeBeneficiary; }
address public multisig;                        // slot 0
mapping(uint256 => GasPlan) public plans;       // slot 1: planId → paquete
mapping(address => uint256) public sourcePlan;  // slot 2: SBT → planId otorgable
mapping(address => uint256) public userPlan;    // slot 3: titular → planId (0=fuera del paquete)
// Punto de escritura único: SBT autorizado para agregar/eliminar a una dirección
function setSponsored(address who, bool on) external {
    uint256 plan = sourcePlan[msg.sender];      // El llamador debe ser un SBT autorizado
    if (plan == 0) revert NotAuthorizedSource();
    userPlan[who] = on ? plan : 0;              // on=agregar a la lista; off=limpiar 0
}
// Rust: sponsor_registry.rs — La capa de ejecución lee con la misma disposición, ambas partes se prueban cruzadamente
const PLANS_MAPPING_SLOT=1;
const USER_PLAN_MAPPING_SLOT=3; // Dirección: keccak256(key . slot)

Donde plans[planId] = { token: qué moneda usar, feePerTx: cuánto cobrar por transacción, feeBeneficiary: quién recibe}. Al liquidar, Tuven Chain primero verifica a qué paquete pertenece el usuario; si no está en el paquete (userPlan[tu]==0), se paga normalmente con la moneda estable nativa USDX; si está en el paquete, se paga con el token especificado por el paquete. Es importante notar que USDX es un contrato de moneda estable de Circle, pero la autoridad de acuñación/congelación/pausa está en manos de la operación, aislada de la verdadera USDC. Su "estabilidad" proviene de la estrategia de la operación, no del respaldo de reservas.

2.2 Modificación de la lógica de deducción de tarifas en la capa de ejecución subyacente

// (handler.rs) // Simulando "listas negras": se hace un "SLOAD" no medido en la tabla de paquetes, decidiendo por transacción qué moneda usar
fn charge_sponsored_gas(&self, evm, caller) -> Result<bool> {
    journal.load_account(SPONSOR_REGISTRY_ADDRESS)?;  // Precalentamiento, de lo contrario, una lectura fría SLOAD fallará
    let plan_id = sload(REG, compute_user_plan_slot(caller))?;
    if plan_id.is_zero() { return Ok(false); }  // No está en el paquete → se paga normalmente con USDX
    let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?;
    if token.is_zero() { return Err(GAS_PLAN_UNCONFIGURED); }  // Paquete no configurado → rechazo, sin respaldo
    let fee = sload(REG, compute_plan_slot(plan_id, PLAN_FEE_OFFSET))?;
    let bal = sload(token, compute_erc20_balance_slot(caller))?;
    if bal < fee { return Err(INSUFFICIENT_GAS_TOKEN); }  // Saldo insuficiente → rechazo
    sstore(token, caller_slot, bal - fee)?;  // Deducción de tarifa fija: el miembro paga
    sstore(token, benef_slot, benef_bal + fee)?;  // Registro para feeBeneficiary (sin relación con el gas)
    Ok(true)  // true = pagado con moneda de miembro, USDX completamente exento
}
// pre_execution compone un USDX prepagado para que la verificación nativa pase; reward_beneficiary se deduce nuevamente,
// y no se registra USDX para el beneficiario — de lo contrario, sería como imprimir dinero de la nada.

Aquí, el usuario deduce una cantidad fija de un token específico por cada transacción, sin relación con la cantidad real de cálculo consumido. Esta configuración eleva la tarifa base de toda la cadena, donde el aumento de las tarifas de Gas es asumido por los usuarios de USDX (no del paquete), trasladando el costo a estos usuarios.

2.3 Insignia de identidad SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol — Insignia de identidad "no transferible" (ERC-5192)
function issue(address to, uint256 id, string uri) external onlyIssuer {
    _safeMint(to, id);
    registry.setSponsored(to, true);  // Al emitir, se agrega a la lista del paquete
}
function revoke(uint256 id) external onlyIssuer {
    address owner = ownerOf(id);
    _burn(id);
    registry.setSponsored(owner, false);  // Al revocar, se elimina de la lista
}
// Solo se permite mint(from=0)/burn(to=0), cualquier otra transferencia se bloquea → no se puede mover, no se puede vender
function _update(...) internal override returns (address) {
    if (from != address(0) && to != address(0)) revert Soulbound(); ...
}
// DeployUserland.s.sol — Despliega y entrega el control a un multisig (1-de-2 es redundancia de clave privada, no equilibrio)
registry.setSourcePlan(address(sbt), PLAN_ID);  // Autoriza SBT a vincular el paquete 1
registry.setMultisig(address(multisig));  // admin entregado a la gestión multisig
// Riesgo: feeSigner no configurado explícitamente por defecto = firmante admin (cofre y gestión con la misma clave privada)

Tuven Chain reutilizó el mecanismo de lista negra existente de Arc, combinándolo con credenciales de identidad SBT para completar el control de acceso de usuarios. Las características de su solución se pueden resumir como:

(1) Capacidad nativa de pago de Gas con múltiples tokens: a diferencia de las soluciones de pago de contratos superiores, la lógica de facturación se ha trasladado a la capa de ejecución de consenso, soportando múltiples paquetes en paralelo, permitiendo que diferentes usuarios con diferentes identidades utilicen diferentes tokens personalizados para pagar tarifas.

(2) Modelo de tarifa fija por transacción: desvinculándose del modelo de facturación tradicional "tarifa de Gas × consumo de cálculo", se logra que las tarifas de transacción sean predecibles.

(3) Alta compatibilidad con la infraestructura existente: no se requieren cuentas inteligentes ni modificaciones de DApp, las billeteras EOA ordinarias como MetaMask pueden interactuar directamente.

(4) Reutilización de mecanismos: reutiliza la ruta de ejecución de lectura de almacenamiento de listas negras existente, transformándola de control de acceso inverso a control de acceso de identidad, maximizando la reutilización del marco de código subyacente existente.

Sin embargo, esta conveniencia se basa en muchas suposiciones de confianza adicionales, y los cambios en el núcleo subyacente, el diseño de permisos, el modelo económico y los componentes de cadena cruzada pueden presentar riesgos. La semántica de la lista negra original ha sido modificada, y la lógica de interceptación que originalmente solo se aplicaba a las transferencias se ha ampliado para cubrir las llamadas a contratos ordinarios, lo que ha cambiado los límites lógicos. La deducción de tarifas con tokens de paquete es una nueva lógica de negocio que necesita una auditoría de seguridad independiente para garantizar que no haya vulnerabilidades en la lectura y escritura de almacenamiento y en el cálculo de saldos, evitando consecuencias graves como excepciones de transacción, bifurcaciones de consenso de cadena o deducciones anómalas de activos.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.