Saltar al contenido
Financial Context Wiki

Cómo recuperar un hueco de nonce en una billetera

Encuentra el primer nonce ausente de una cuenta EVM, decide si sustituirlo o cancelarlo y evita transacciones en cola entre billeteras o dispositivos.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

En una cadena compatible con EVM, las transacciones de una cuenta de propiedad externa (EOA) se ejecutan por orden de nonce. Si el siguiente nonce ejecutable está ausente o atascado, las transacciones con nonces superiores pueden seguir en cola aunque paguen comisiones altas. Recupera primero el nonce sin resolver más bajo: confirma la cadena y el remitente, compara los datos confirmados y pendientes, y después sustituye la transacción prevista o compite con ella mediante una cancelación con el mismo nonce.

Cancelar no es deshacer a nivel del protocolo. Suele consistir en una transferencia de 0 ETH de la cuenta a sí misma que compite por el mismo nonce. Gana la transacción válida incluida primero; una transacción confirmada no puede cancelarse así.

Este procedimiento es para transacciones EOA normales en EVM. Las cuentas inteligentes o las operaciones de abstracción de cuentas pueden usar esquemas de nonce definidos por contratos; las redes UTXO emplean otro modelo.

Por qué un hueco de nonce bloquea la cola

El nonce de una EOA es un contador secuencial. Solo puede ejecutarse una transacción por nonce y la cuenta no puede ejecutar el nonce 26 antes del nonce 25. Por eso los nodos separan las transacciones ejecutables de las de nonce superior reservadas para el futuro.

La cola no es un mempool global y autoritativo. Cada nodo RPC ve y conserva un subconjunto distinto de transacciones pendientes. Una transacción puede figurar en la billetera pero no en el explorador, o verse en un RPC y no en otro. Puede no haberse difundido, haber sido descartada del pool de un nodo o no haberse propagado al servicio consultado.

eth_getTransactionCount con latest devuelve el recuento en el último estado de bloque; para una EOA, se interpreta como el siguiente nonce tras las transacciones confirmadas. Con pending se consulta la vista pendiente de un nodo. Una diferencia sugiere que ese nodo conoce transacciones pendientes, pero no demuestra que todos los nodos públicos las conozcan.

Diagnóstico antes de firmar

  1. Detén los envíos desde la dirección afectada en todos los dispositivos y aplicaciones. Anota red, chain ID, dirección remitente, hashes, nonces, destinatarios, importes, calldata, gas limits y campos de comisión.
  2. Verifica que billetera, explorador y RPC se refieran a la misma cadena y remitente. El nonce pertenece a una cuenta en una cadena, no a una instalación de la billetera.
  3. Consulta eth_getTransactionCount con latest y pending, preferiblemente en dos proveedores RPC independientes. Considera las discrepancias como vistas distintas del mempool, no como prueba de incoherencia on-chain.
  4. Inspecciona por nonce las transacciones del remitente. Si está disponible, la API del pool del nodo distingue entradas ejecutables pending de entradas futuras queued. Los RPC públicos suelen desactivar esta API no estándar.
  5. Desde el valor latest, busca el primer nonce sin transacción confirmada. Determina si una transacción conocida sigue visible, fue descartada o solo se creó localmente.

No actúes basándote solo en la etiqueta de la billetera. El nonce confirmado, el recibo y la inclusión en un bloque de la cadena correcta son la evidencia decisiva.

Sustituir o cancelar el primer nonce sin resolver

Para conservar la acción original: usa la función de aceleración o vuelve a difundir una transacción con el mismo remitente, nonce, destinatario, importe y calldata, pero con comisiones competitivas. Revisa cada campo antes de firmar; cambiar el payload crea otra acción.

Para abandonar la acción original: mientras siga sin confirmar, envía 0 ETH desde la dirección a sí misma con el mismo nonce y comisiones competitivas. Solo se intenta que gane la autotransferencia. La original aún puede confirmarse primero; no des por hecha la cancelación hasta que la sustituta tenga recibo y la original siga sin confirmar.

La admisión de sustituciones es política del nodo, no un porcentaje universal. En una transacción EIP-1559 quizá deban subir maxPriorityFeePerGas y maxFeePerGas, y maxFeePerGas debe seguir siendo utilizable con la base fee actual. Las estimaciones y reglas varían; replacement transaction underpriced indica que el nodo receptor no aceptó la sustitución con su política vigente.

Cuando se confirme el nonce más bajo, revisa de nuevo recibo, latest, saldos y cada transacción con nonce superior. Las transacciones en cola pueden volverse ejecutables de inmediato; las descartadas por todos los nodos relevantes quizá deban redifundirse de forma deliberada. No las reenvíes a ciegas: confirma antes que no se incluyó una copia anterior.

Ejemplo

Una dirección tiene transacciones confirmadas hasta el nonce 24, así que latest es 25. Un RPC informa pending como 25 y la billetera muestra el nonce 26 y el nonce 27 en cola. Ningún proveedor encuentra una transacción difundida con nonce 25.

El propietario verifica primero cadena, remitente y payloads registrados. Si había una acción deseada en el nonce 25, la reconstruye y difunde con nonce 25 y comisiones actuales. Si no la había, puede enviar una autotransferencia de 0 ETH con nonce 25. Aumentar solo la comisión del nonce 27 no cierra el hueco.

Incluido el nonce 25, revisa su recibo antes de tocar el nonce 26 o el nonce 27. Examina ambos por separado: pueden haberse descartado o ejecutarse rápidamente tras cerrar el hueco.

Riesgos y condiciones para detenerse

  • La sustituta puede competir con la original. Hasta tener evidencia on-chain, presupón que el destinatario, importe y llamada originales aún pueden ejecutarse.
  • Confirma dirección completa del remitente, chain ID, nonce y calldata en una pantalla fiable. El malware o un sitio de “recuperación” no fiable puede sustituir una transferencia o aprobación.
  • Conserva moneda nativa suficiente para la comisión. Se cobra gas por la transacción incluida aunque una llamada al contrato luego revierta.
  • No reveles frase semilla ni clave privada para recuperar un hueco. Ningún RPC, explorador o agente de soporte legítimo las necesita.
  • Si la dirección está comprometida, las sustituciones públicas repetidas pueden convertirse en una carrera de comisiones con el atacante. Deja de usar el dispositivo comprometido y sigue un plan de respuesta a incidentes.
  • Si los RPC discrepan, se desconoce el destinatario original, no puede reconstruirse el payload o está en juego una gran interacción contractual, detente y busca ayuda experta antes de firmar.

Para el uso repetido entre dispositivos o firmantes automáticos, evita recurrencias con un asignador de nonce por cuenta y cadena, firma serializada, registros duraderos de nonces y hashes reservados y conciliación con el estado confirmado y el pool pendiente del emisor. Restablecer el historial local de la billetera no cambia el estado on-chain ni los mempools de otros nodos.

Errores comunes

  • “Una comisión mayor en el nonce 27 permite saltarse el nonce 25.” Solo puede mejorar la prioridad cuando los nonces anteriores sean ejecutables; no repara el hueco.
  • “No encontrada significa cancelada.” Un nodo puede descartarla mientras otro nodo, builder o contraparte aún la conserva. Una transacción firmada puede redifundirse.
  • “Una autotransferencia de 0 ETH revierte la original.” Solo compite por el mismo nonce y no tiene efecto tras confirmarse la original.
  • “pending es la respuesta final de la red.” Es la vista pendiente del nodo consultado y puede variar entre proveedores.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...