Cartera hardware no custodial: arquitectura, flujos de firma y verificación

Respuesta directa y alcance

Una cartera hardware no custodial es un dispositivo físico que genera y almacena claves privadas en un elemento seguro o microcontrolador aislado, sin exponer nunca la frase semilla al sistema operativo anfitrión. El anfitrión (aplicación de escritorio, extensión de navegador o aplicación móvil) construye una transacción sin firmar, la envía al dispositivo para su revisión y recibe de vuelta una carga firmada. Luego, el anfitrión difunde esa carga firmada a un nodo de blockchain a través de un endpoint RPC.

Este artículo cubre la arquitectura, el flujo de firma, cómo verificar que la firma se realizó en el dispositivo, cómo el software anfitrión del dispositivo se comunica con la infraestructura RPC y cómo solucionar fallos comunes. No recomienda un proveedor de hardware ni un proveedor RPC específico; para elecciones concretas de endpoints, utiliza el Asistente RPC.

• Se asume que ya posees o estás evaluando una cartera hardware compatible con la cadena que te interesa.
• Se asume familiaridad básica con pares de claves públicas/privadas y la difusión de transacciones.
• Todo el código utiliza marcadores como RPC_URL y PRIVATE_KEY; nunca pegues una frase semilla real en ningún script.

Requisitos previos y supuestos

Antes de ejecutar cualquier procedimiento de verificación, confirma que el firmware de tu dispositivo esté actualizado, que la aplicación complementaria del proveedor esté instalada desde una fuente oficial y que tengas una cuenta de prueba financiada en una testnet o una cuenta de mainnet con poco valor. También necesitas un endpoint RPC funcional para la cadena objetivo; puedes revisar las redes compatibles en la página de redes de OnFinality y comparar opciones de endpoints a través del servicio API RPC.

Los procedimientos a continuación asumen que la máquina anfitriona tiene Python 3.10+ o Node.js 18+ y que puedes instalar paquetes. No asumen ningún modelo de hardware específico, porque la interfaz de firma varía según el proveedor. Cuando se requiere un paso específico del proveedor, el procedimiento describe qué buscar en lugar de un comando codificado.

Modelo de aislamiento de claves: qué protege realmente el dispositivo

El valor de seguridad de una cartera hardware no custodial proviene de separar el material de claves del ordenador de propósito general. El dispositivo genera entropía internamente, deriva una frase semilla y la almacena en memoria protegida. El anfitrión nunca ve la frase semilla durante el funcionamiento normal. Cuando se debe firmar una transacción, el anfitrión envía la transacción sin firmar y la ruta de derivación al dispositivo; el dispositivo muestra el destino, el importe y la comisión en su propia pantalla, y el usuario confirma físicamente.

Este modelo protege contra malware en el anfitrión que intente exfiltrar claves, pero no protege contra un usuario que apruebe una transacción maliciosa. Tampoco protege contra ataques a la cadena de suministro en el propio dispositivo, por lo que la verificación del firmware y la compra en canales oficiales son importantes. El dispositivo es una frontera de firma, no un sistema de seguridad completo.

• Las claves privadas permanecen dentro del elemento seguro o MCU aislado.
• El anfitrión solo recibe firmas y claves públicas.
• La confirmación física vincula la carga firmada con lo que el usuario vio en la pantalla del dispositivo.
• La copia de seguridad de la semilla sigue siendo responsabilidad del usuario y es el único punto de recuperación.

Flujo de firma y difusión de principio a fin

Un flujo típico tiene seis etapas. Primero, la aplicación anfitriona consulta un endpoint RPC para obtener el nonce de la cuenta, el saldo y los parámetros de gas actuales. Segundo, el anfitrión construye un objeto de transacción sin firmar. Tercero, el anfitrión serializa ese objeto y lo envía a la cartera hardware por USB, Bluetooth o un canal QR. Cuarto, el dispositivo muestra la transacción decodificada y espera la aprobación física. Quinto, el dispositivo devuelve una firma. Sexto, el anfitrión adjunta la firma y difunde la transacción firmada en bruto a través del endpoint RPC.

La propiedad crítica es que el endpoint RPC solo ve la transacción firmada. No ve la clave privada ni la frase semilla. Esto significa que la confianza en el proveedor RPC se limita a la disponibilidad y a los datos correctos de la cadena, no a la custodia de los fondos. Esa distinción es la razón por la que las carteras hardware de autocustodia pueden combinarse con infraestructura RPC de terceros sin renunciar al control de las claves.

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

Construcción de una transacción sin firmar para revisión en el dispositivo

El anfitrión debe construir una transacción que el dispositivo pueda decodificar y mostrar sin ambigüedad. Utiliza campos explícitos en lugar de valores predeterminados y verifica que el ID de cadena coincida con la red que pretendes usar. El ejemplo siguiente utiliza un RPC_URL y una dirección de marcador de posición; solo lee datos de la cadena y no firma nada.

Cuando la transacción esté lista, pásala a la biblioteca de firma o CLI de tu proveedor. La llamada exacta varía según el proveedor, pero la entrada siempre es la misma: un objeto de transacción sin firmar más una ruta de derivación. La salida es una firma o una transacción en bruto firmada. Nunca registres la frase semilla ni la clave privada durante este paso.

import json, urllib.request

RPC_URL = "RPC_URL"
ADDRESS = "0xYOUR_ADDRESS"

def rpc(method, params):
    payload = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).encode()
    req = urllib.request.Request(RPC_URL, data=payload, headers={"Content-Type":"application/json"})
    with urllib.request.urlopen(req, timeout=15) as resp:
        return json.loads(resp.read())["result"]

nonce = rpc("eth_getTransactionCount", [ADDRESS, "pending"])
chain_id = rpc("eth_chainId", [])
gas_price = rpc("eth_gasPrice", [])
print({"nonce": nonce, "chain_id": chain_id, "gas_price": gas_price})

Verificación de que la firma se realizó en el dispositivo

La verificación es un procedimiento de medición, no un ejercicio de confianza. El objetivo es confirmar tres cosas: que la firma fue producida por el dispositivo, que la carga firmada coincide con lo que mostró el dispositivo y que la difusión fue aceptada por la red. Puedes verificar las dos primeras sin difundir, recuperando la dirección del firmante a partir de la firma y comparándola con la dirección pública del dispositivo.

Ejecuta el procedimiento a continuación con una transacción de testnet. Registra la dirección recuperada, la dirección mostrada por el dispositivo y el hash de la transacción difundida. Una configuración correcta produce una dirección recuperada que coincide exactamente con la dirección del dispositivo y un hash de transacción que aparece en un explorador de bloques para la cadena correcta.

• La dirección del firmante recuperada es igual a la dirección pública del dispositivo.
• La pantalla del dispositivo muestra el mismo destino, importe y comisión que la transacción del anfitrión.
• La difusión devuelve un hash de transacción, no un error.
• El hash es visible en el explorador de la cadena correcta después de la inclusión.

Tabla de resultados para tu propia ejecución de verificación

Utiliza la siguiente tabla para registrar tus propias mediciones. No rellenes valores de este artículo; la tabla es una plantilla. Cada fila debe completarse a partir de tu propia ejecución en testnet o en mainnet con poco valor, y los criterios de aprobación se indican para que puedas juzgar el resultado sin referencias externas.

Cómo se comunica el software anfitrión con la infraestructura RPC

La cartera hardware en sí no suele realizar solicitudes de red. Lo hace la aplicación complementaria o la extensión del navegador. Eso significa que la fiabilidad del RPC, los límites de velocidad y la corrección de la cadena son propiedades de la configuración del software anfitrión, no del dispositivo. Si tu aplicación de cartera permite una URL RPC personalizada, puedes apuntarla a un endpoint dedicado para obtener una mayor consistencia; consulta las opciones de nodo dedicado y la página de precios de RPC para la planificación de capacidad.

Para carteras multi-cadena, el anfitrión puede cambiar los endpoints RPC por cadena. Verifica que el endpoint de cada cadena devuelva el ID de cadena esperado antes de firmar. Un ID de cadena incorrecto es una de las causas más comunes de transacciones fallidas o mal dirigidas, y es detectable antes de firmar con una sola llamada RPC.

const RPC_URL = "RPC_URL";

async function checkChain(expectedChainId) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_chainId", params: [] })
  });
  const { result } = await res.json();
  const actual = parseInt(result, 16);
  if (actual !== expectedChainId) {
    throw new Error(`Chain mismatch: expected ${expectedChainId}, got ${actual}`);
  }
  return actual;
}

checkChain(1).then(console.log).catch(console.error);

Solución de problemas comunes

La mayoría de los fallos de carteras hardware se agrupan en cuatro categorías: conexión, discrepancia de cadena, problemas de nonce o comisión y discrepancia en la pantalla. Los fallos de conexión suelen significar que el dispositivo está bloqueado, que el cable o el emparejamiento Bluetooth está obsoleto o que la aplicación complementaria carece de permisos. La discrepancia de cadena significa que el endpoint RPC y la red esperada por el dispositivo no coinciden; verifica el ID de cadena antes de firmar. Los problemas de nonce producen transacciones de reemplazo o atascadas; consulta el nonce pendiente y compáralo con el último nonce confirmado. La discrepancia en la pantalla significa que la transacción del anfitrión y la pantalla del dispositivo no coinciden, lo cual es una condición de parada: rechaza la transacción e investiga.

Si una difusión falla después de firmar, la carga firmada sigue siendo válida. Puedes volver a difundirla a través de un endpoint diferente sin volver a firmar, siempre que el nonce no se haya consumido. Guarda la transacción firmada en bruto en un lugar seguro hasta que se confirme o se reemplace.

• Dispositivo no detectado: desbloquea el dispositivo, vuelve a abrir la aplicación complementaria y prueba con otro cable o puerto.
• Discrepancia de cadena: verifica eth_chainId con la red prevista antes de firmar.
• Transacción atascada: consulta el nonce pendiente y vuelve a difundir o reemplaza con una comisión más alta.
• Discrepancia en la pantalla: rechaza en el dispositivo e inspecciona la construcción de la transacción del anfitrión.

Limitaciones y compensaciones

Las carteras hardware no custodiales intercambian comodidad por aislamiento de claves. Cada transacción requiere confirmación física, lo que resulta lento para operaciones de alta frecuencia. La copia de seguridad de la semilla es un punto único de fallo: si pierdes la semilla y el dispositivo, los fondos son irrecuperables. La confianza en el firmware y la cadena de suministro siguen siendo riesgos residuales que ninguna fiabilidad del RPC puede eliminar.

En el lado de la infraestructura, el dispositivo no resuelve la disponibilidad del RPC. Una firma correcta difundida a un endpoint no disponible sigue sin llegar a la red. Combinar una cartera hardware con un proveedor RPC fiable aborda la disponibilidad, pero no cambia el modelo de custodia. Para equipos que gestionan muchos dispositivos de firma, considera documentar las rutas de derivación, los ID de cadena y las configuraciones de endpoints para que los procedimientos de recuperación y auditoría sean reproducibles.

Próximos pasos

Después de completar una ejecución de verificación, documenta la dirección del dispositivo, la ruta de derivación, el ID de cadena y el endpoint RPC de cada cuenta que gestiones. Prueba un flujo de recuperación en una testnet antes de depender de él para fondos en mainnet. Si necesitas elegir un endpoint para el software anfitrión, utiliza el Asistente RPC para obtener una recomendación concreta y revisa la guía de endpoints RPC multi-cadena para patrones de configuración. Para equipos que estandarizan en infraestructura gestionada, la guía de alojamiento de nodos blockchain cubre consideraciones operativas que complementan la firma de autocustodia.