Saltar al contenido
Financial Context Wiki

Espacios de nombres de nonce en cripto

Guía práctica sobre nonces de cuenta Ethereum, nonces de aplicación contra replay, carriles key-sequence de ERC-4337 y nonces de búsqueda en cabeceras Proof of Work.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Un nonce es un valor cuyo significado procede de un espacio de nombres específico del protocolo. No siempre es un número aleatorio ni un valor universal «usado una sola vez». En Ethereum, el nonce de estado de una cuenta de propiedad externa ordena y valida las transacciones de ese remitente. Un contrato puede mantener nonces de aplicación independientes en storage para permisos o intenciones firmadas. Las smart accounts ERC-4337 pueden usar un nonce estructurado de UserOperation con carriles paralelos de clave y secuencia. En el Proof of Work de Bitcoin, el nonce de la cabecera es un campo de búsqueda acotado para probar hashes candidatos.

Estos valores no son intercambiables. El nonce de una cuenta Ethereum no protege una firma arbitraria de datos tipados si la aplicación no valida su propio dominio y campo anti-replay. Un nonce de cabecera PoW no ordena transacciones de cuentas. El mismo número usado por distintos remitentes, contratos, cadenas o carriles describe estados diferentes.

Cómo funciona

  1. Identifique el espacio de nombres antes de leer el número: transacción EOA, estado de cuenta contractual, storage de aplicación, UserOperation ERC-4337 o cabecera PoW concreta. Fije cadena, fork y versión, cuenta u owner, contrato verificador y dominio, EntryPoint o formato de cabecera según corresponda.
  2. Lea el estado autoritativo con un block tag explícito. Separe el nonce canónico de la EOA del recuento pending del proveedor, el valor nonces(owner) de la aplicación, la clave y secuencia ERC-4337 y el contador local de búsqueda del minero. La coincidencia entre RPC no sustituye verificar recibo y estado canónicos.
  3. Construya el linaje firmado. Registre remitente u owner, cadena y dominio, nonce, payload, deadline, contrato verificador, hash de transacción o mensaje y cada sustitución. En transacciones Ethereum, reglas de dominio como EIP-155 complementan el nonce; este por sí solo no evita por completo replay entre cadenas.
  4. Asigne dentro del carril correcto. Coordine firmantes EOA concurrentes para asignar una vez cada secuencia canónica; conserve gaps y linaje de sustituciones con el mismo nonce. En aplicaciones o smart accounts, siga las reglas atómicas de comprobación e incremento y de carriles del contrato, no un supuesto contador global.
  5. Envíe según las reglas de admisión correctas. Las políticas pending y de sustitución del execution client son locales; los bundlers ERC-4337 validan objetos UserOperation según EntryPoint y la cuenta; una firma EIP-712 o permit puede viajar dentro de la transacción de otro. Ninguna aceptación local prueba inclusión canónica.
  6. Siga todo el resultado. Distinga rechazado, pending, queued, sustituido, incluido con éxito, incluido con status = 0, retirado por reorganización y finalizado. Una transacción Ethereum incluida incrementa el nonce del remitente aunque la EVM revierta; el nonce de aplicación actualizado dentro de esa llamada revierte con ella.
  7. Concilie antes de reintentar. Verifique recibo canónico, hash de bloque, nonce del remitente, storage de aplicación, evento o recibo ERC-4337 y finalidad. En PoW, verifique cabecera completa y target, no solo nonce; al agotar el campo finito, los mineros modifican otros datos que afectan a la cabecera para crear otro espacio de búsqueda.

Ejemplos desarrollados

  • Un revert incluido consume el nonce EOA. El nonce canónico del remitente es 12. Una transacción con nonce 12 se incluye con status = 0, usa 50,000 gas a 30 gwei y cuesta 50,000 * 30 gwei = 0.0015 ETH. Los cambios del contrato revierten, pero el nonce canónico pasa a 13. Si una reorganización retira el bloque, puede volver a 12; la cartera debe revisar todo el linaje.
  • Los nonces de aplicación y relayer son independientes. Un owner tiene nonce EOA 18; un token ERC-2612 informa nonces(owner) = 7; el nonce EOA del relayer es 42. Un permit correcto consume el nonce de aplicación 7, que pasa a 8; la inclusión lleva el nonce del relayer a 43 y deja el del owner en 18. Si toda la llamada revierte, el relayer sigue pasando a 43, pero el storage del token vuelve a 7.
  • Carriles ERC-4337. Con la expresión didáctica nonce = (key << 64) | sequence, la clave 5 y secuencia 9 dan 5 * 2^64 + 9 = 92,233,720,368,547,758,089; la secuencia 10 da 92,233,720,368,547,758,090. La clave independiente 6, secuencia 0, da 110,680,464,442,257,309,696. El paralelismo aún depende de la validación de la smart account y es independiente del nonce EOA del bundler.
  • Nonce de búsqueda PoW. El nonce de cabecera Bitcoin tiene 32 bits, es decir, 2^32 = 4,294,967,296 candidatos numéricos. A unos hipotéticos 100 TH/s, recorrerlos requiere 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. Los mineros cambian extraNonce de coinbase, tiempo o conjunto de transacciones para alterar la raíz de Merkle y obtener nuevas cabeceras; este campo no es estado anti-replay de cuentas.

Riesgos

  • Confundir espacios EOA, contrato, aplicación, ERC-4337 y PoW.
  • Leer el nonce de cadena, fork, contrato o EntryPoint incorrectos.
  • Usar una respuesta RPC obsoleta, incoherente o maliciosa.
  • Que firmantes concurrentes asignen el mismo nonce EOA.
  • Que un gap de nonce bloquee candidatos locales posteriores.
  • Tratar el nonce pending de un proveedor como estado canónico.
  • Olvidar que un revert incluido consume nonce EOA y gas.
  • No restaurar nonce y linaje tras una reorganización.
  • Que una sustitución no satisfaga la política de comisión del nodo.
  • Suponer que la sustitución borró globalmente la transacción antigua.
  • Correlacionar números iguales de remitentes o dominios distintos.
  • Omitir chain ID u otro separador de dominio requerido.
  • No comprobar e incrementar atómicamente un nonce de aplicación.
  • Owner, deadline, domain separator o token ERC-2612 incorrectos.
  • Replay de firma entre cadena, contrato o versión.
  • Interpretar el nonce de una cuenta contractual como contador genérico de llamadas.
  • Empaquetar mal clave o ancho de secuencia ERC-4337.
  • Mezclar nonce EOA del bundler y nonce UserOperation de la smart account.
  • Que un upgrade de proxy o colisión de storage cambie el nonce de aplicación.
  • Tratar un nonce PoW finito como autorización, estado anti-replay o prueba aislada.

Conceptos erróneos habituales

  • Todo campo llamado nonce significa lo mismo y se usa globalmente una vez.
  • Un nonce mayor hace una transacción más segura, rápida o final.
  • Una transacción Ethereum que revierte no consume el nonce del remitente.
  • Un nonce por sí solo impide cualquier replay entre cadenas, contratos y mensajes tipados.
  • Toda smart account ERC-4337 tiene un contador lineal idéntico al nonce EOA.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...