Billetera digital no custodial: control de claves, dependencias RPC y flujos de verificación

Alcance y definición central

Una billetera digital no custodial es una billetera en la que las claves privadas que controlan una dirección se generan y almacenan en infraestructura que el usuario controla, y las firmas de transacciones se producen localmente. La aplicación de billetera puede ser una extensión de navegador, una aplicación móvil, un dispositivo hardware o una herramienta de línea de comandos. En todos los casos, la propiedad definitoria es que ningún servicio posee una clave capaz de mover los activos del usuario.

Este artículo se centra en el lado operativo y de integración: qué hace la billetera localmente, qué delega a la infraestructura remota y cómo verificar el límite. No recomienda un producto de billetera específico. Cuando se necesita una decisión concreta de endpoint o proveedor, los recursos complementarios de RPC Assistant enlazados a continuación cubren esa selección.

• Claves y firma: locales al dispositivo del usuario o módulo hardware.
• Lecturas de estado de cadena y difusión de transacciones: delegadas a un endpoint RPC.
• Recuperación: depende de una frase semilla o copia de seguridad en poder del usuario, no de un servicio de soporte.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que tiene una billetera capaz de exportar una dirección pública (nunca una clave privada) y una red de prueba donde puede mover activos sin valor. Necesita Node.js 18 o posterior para los ejemplos de JavaScript, y curl para las comprobaciones RPC. Trate cada clave que genere para pruebas como desechable.

También debe tener una cuenta de prueba con fondos en una testnet pública. Si está eligiendo un endpoint para una integración de billetera en producción, revise la guía de endpoints multicadena en /en/learn/multi-chain-rpc-endpoints-guide antes de ejecutar las comprobaciones, porque los límites de velocidad y los requisitos de archivo varían según la red.

• Una billetera de prueba con una frase semilla conocida almacenada fuera de línea.
• Un RPC_URL de testnet que controle o con cuota disponible.
• Node.js 18+, curl y una terminal.
• Ninguna clave privada de producción en ningún script o historial de shell.

Cómo interactúan el control de claves y el límite de confianza RPC

El componente local de la billetera deriva un par de claves a partir de entropía, típicamente una frase semilla BIP-39, y calcula la dirección. Firmar una transacción es una operación criptográfica local sobre una carga útil que incluye el ID de cadena, nonce, destinatario, valor, parámetros de gas y datos. La transacción firmada se envía luego a un nodo RPC, que la valida y la propaga a la red peer-to-peer.

Por lo tanto, el proveedor RPC ve sus transacciones firmadas y sus consultas de lectura, pero nunca ve su clave privada. Ese es el límite de confianza: un endpoint RPC malicioso o comprometido puede censurar, retrasar, devolver estado obsoleto o informar mal los saldos, pero no puede falsificar una firma para su dirección. Por eso la seguridad de la billetera y la fiabilidad RPC son problemas separados que requieren verificación separada.

• Local: generación de entropía, derivación de claves, cálculo de dirección, construcción de carga útil, firma.
• Remoto: lecturas de saldo y nonce, estimación de gas, simulación eth_call, difusión de transacciones, sondeo de recibos.
• Nunca remoto: material de clave privada, frase semilla u operación de firma.

Verificar que la firma permanece local con una comprobación ejecutable

El siguiente script de Node.js deriva una dirección a partir de un mnemónico de prueba, firma localmente una carga útil de transacción e imprime la dirección recuperada. Si la dirección recuperada coincide con la dirección derivada, la firma se produjo localmente y la carga útil es internamente consistente. No se realiza ninguna llamada de red en este paso.

Ejecútelo solo con un mnemónico de prueba desechable. El script usa ethers v6; instálelo con npm install ethers.

const { Wallet, Transaction, getAddress } = require('ethers');

async function main() {
  const mnemonic = process.env.TEST_MNEMONIC; // disposable test phrase only
  const wallet = Wallet.fromPhrase(mnemonic);
  console.log('derived address:', wallet.address);

  const tx = Transaction.from({
    to: '0x000000000000000000000000000000000000dEaD',
    value: 1n,
    nonce: 0,
    gasLimit: 21000n,
    maxFeePerGas: 1000000000n,
    maxPriorityFeePerGas: 1000000000n,
    chainId: 11155111,
    type: 2
  });

  const signed = await wallet.signTransaction(tx);
  const parsed = Transaction.from(signed);
  console.log('recovered address:', getAddress(parsed.from));
  console.log('match:', getAddress(parsed.from) === getAddress(wallet.address));
}

main().catch((e) => { console.error(e); process.exit(1); });

Resultado esperado de la verificación y qué significa una discrepancia

Una ejecución correcta imprime la misma dirección para derivada y recuperada, con match: true. Eso confirma que la ruta de firma local es coherente. Una discrepancia generalmente significa que los campos de la transacción se modificaron después de firmar, que el ID de cadena es incorrecto para la red de destino o que la versión de la biblioteca de firma difiere de la que produjo la carga útil.

Esta comprobación no prueba que la interfaz de la billetera sea honesta. Para probarlo, compare la dirección mostrada en la interfaz de la billetera con la dirección derivada por el script a partir de la misma frase semilla. Si difieren, deténgase e investigue antes de financiar la cuenta.

• match: true — la ruta de firma local es consistente.
• match: false — inspeccione el ID de cadena, el orden de los campos y la versión de la biblioteca.
• Discrepancia de dirección con la interfaz de la billetera — trátela como un incidente de seguridad hasta que se explique.

Comprobar el comportamiento RPC para difusión y lecturas de estado

Una vez verificada la firma, pruebe el lado remoto. Los siguientes comandos curl comprueban el ID de cadena, el nonce actual y una llamada simulada contra su RPC_URL. Reemplace RPC_URL con su endpoint y ADDRESS con su dirección de prueba. Estas son llamadas de solo lectura y no cuestan gas.

Registre las salidas en una tabla de resultados para poder comparar endpoints o ventanas de tiempo. No invente valores; capture lo que devuelve su endpoint y anote la marca de tiempo.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionCount","params":["ADDRESS","pending"]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"eth_call","params":[{"to":"ADDRESS","data":"0x"},"latest"]}'

Procedimiento de tabla de resultados para comparar endpoints

Ejecute las tres llamadas anteriores contra cada endpoint candidato en el mismo momento y complete una tabla con estas columnas: etiqueta del endpoint, resultado de eth_chainId, nonce pendiente, número de bloque más reciente, tiempo de respuesta en milisegundos y código de error si lo hay. Repita tres veces por endpoint y conserve la mediana. Esto le da una comparación reproducible sin depender de las afirmaciones del proveedor.

Si el nonce pendiente difiere entre endpoints, un nodo está retrasado en el mempool. Eso importa para billeteras que prefirman transacciones. Para integraciones en producción, compare opciones de nodo dedicado en /en/dedicated-node y revise el comportamiento de cuotas en /en/pricing/rpc antes de comprometerse.

Solución de problemas comunes de billeteras no custodiales

La mayoría de los fallos de billetera se agrupan en tres categorías: pérdida de claves, inconsistencia de estado y rechazo de difusión. La pérdida de claves es irrecuperable por diseño; la inconsistencia de estado y el rechazo de difusión son diagnosticables.

Para la inconsistencia de estado, compare el nonce devuelto por dos endpoints independientes. Para el rechazo de difusión, inspeccione el código y el mensaje de error JSON-RPC; replacement underpriced y nonce too low son los más comunes. Si una transacción está atascada, una transacción de reemplazo con el mismo nonce y una tarifa más alta es el remedio estándar, pero solo fírmela después de confirmar que la original no ha sido minada ya.

• Frase semilla perdida y dispositivo perdido — los fondos son irrecuperables; no existe una vía de soporte.
• nonce too low — la transacción ya fue minada o reemplazada; vuelva a leer el nonce.
• replacement transaction underpriced — aumente la tarifa por encima de la transacción pendiente.
• Saldo obsoleto — el endpoint está retrasado; consulte un segundo endpoint o un explorador de bloques.
• Discrepancia de ID de cadena — la billetera apunta a la red incorrecta; consulte /en/networks.

Limitaciones y compensaciones de la autocustodia

Las billeteras no custodiales eliminan el riesgo de contraparte pero concentran el riesgo operativo en el usuario. No hay restablecimiento de contraseña, ni contracargo, ni servicio de recuperación. La firma con hardware reduce la exposición de la clave pero añade una dependencia del dispositivo. Las billeteras basadas en MPC dividen el material de clave entre las partes pero introducen complejidad de coordinación y nuevos modos de fallo.

La dependencia RPC es la otra compensación. Una billetera que lee de un único endpoint hereda la disponibilidad y corrección de ese endpoint. La conmutación por error multi-endpoint mejora la resiliencia pero complica la gestión de nonces, porque diferentes nodos pueden informar estados pendientes diferentes. Para equipos que construyen infraestructura de billetera, la guía de integración en /en/api-service y la descripción general de alojamiento de nodos en /en/learn/blockchain-node-hosting-guide son los puntos de partida relevantes.

• Autocustodia: control total, responsabilidad total.
• Firma con hardware: mayor aislamiento de claves, carga del ciclo de vida del dispositivo.
• MPC: sin punto único de fallo de clave, sobrecarga de coordinación añadida.
• RPC único: simple, pero un punto único de fallo de estado y disponibilidad.

Próximos pasos para constructores y operadores de billeteras

Si está integrando una billetera no custodial en una aplicación, comience verificando la ruta de firma local con el script anterior, luego evalúe al menos dos endpoints RPC usando el procedimiento de tabla de resultados. Documente los ID de cadena y el comportamiento de nonce de los que depende su integración, y pruebe la recuperación desde una frase semilla en un dispositivo limpio antes de mantener valor real.

Para la selección de endpoints entre redes, use las guías de RPC Assistant en lugar de codificar un proveedor. La descripción general de la API de Ethereum en /en/learn/best-ethereum-rpc-api y la guía más amplia de endpoints en /en/learn/rpc-endpoints-guide cubren las compensaciones entre infraestructura compartida y dedicada. Mantenga su ruta de firma local, su ruta RPC redundante y su ruta de recuperación probada.