Billeteras calientes vs frías: la diferencia que realmente importa para la custodia de claves

Respuesta directa y alcance

Una billetera caliente es una billetera cuyas claves privadas se guardan en software en un dispositivo conectado a Internet, por lo que la firma puede ocurrir en el mismo entorno que se comunica con la red. Una billetera fría es una billetera cuyas claves privadas se guardan en un entorno fuera de línea en el momento de la firma, por lo que una transacción debe transportarse a ese entorno, firmarse y transportarse de vuelta. La distinción se refiere a la exposición de la clave durante la firma, no a nombres de marcas, tiendas de aplicaciones ni a si un dispositivo parece una unidad USB.

Este artículo cubre el mecanismo, un procedimiento de verificación reproducible y las compensaciones operativas. No recomienda un proveedor de hardware específico ni un endpoint específico. Cuando necesite un endpoint RPC concreto o la elección de un proveedor para transmitir transacciones firmadas, utilice el Asistente RPC de OnFinality en lugar de tratar esta página como una lista de proveedores.

• Billetera caliente: claves en software en red; la firma y la transmisión pueden ocurrir en un solo proceso.
• Billetera fría: claves fuera de línea durante la firma; la carga firmada cruza un límite antes de la transmisión.
• Configuraciones tibias o híbridas: las claves pueden estar en línea pero detrás de políticas, MPC o controles de aprobación; clasifíquelas por la exposición real de la clave, no por etiquetas de marketing.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que usted controla una billetera en una red compatible con EVM y puede ejecutar herramientas de línea de comandos. Necesita una cuenta de prueba financiada en una testnet, un endpoint JSON-RPC que esté autorizado a usar y la capacidad de instalar curl y Node.js o Python. Nunca ejecute estas comprobaciones con claves de mainnet o frases semilla de producción.

También debe saber qué dirección está probando y si su software de billetera expone la firma en bruto o solo funciones de envío de alto nivel. Si su billetera no expone un límite de firma, aún puede clasificarla observando si el material de la clave se carga en un proceso que tiene acceso de red saliente.

El modelo mental: claves, firma y transmisión son pasos separados

Una billetera no almacena monedas. Almacena o deriva claves privadas que autorizan cambios de estado en una cadena de bloques. Una transacción se construye a partir de datos de la cadena, como nonce, parámetros de gas, destinatario y valor; luego se firma con la clave privada; luego los bytes firmados se transmiten a un nodo. La cuestión de caliente versus fría se refiere completamente al paso dos: ¿dónde existe la clave privada mientras firma?

En una billetera caliente, el mismo proceso que obtiene el nonce y el precio del gas también mantiene la clave y produce la firma. En una billetera fría, la transacción sin firmar se exporta, se mueve a un firmante fuera de línea, se firma allí y la transacción firmada se devuelve a un transmisor en línea. Ese límite es la propiedad de seguridad. También explica por qué un dispositivo hardware que está permanentemente conectado a una computadora en línea y aprueba automáticamente las transacciones es funcionalmente más cercano a una billetera caliente que a un firmante verdaderamente aislado (air-gapped).

• Construir: en línea, necesita el estado de la cadena, como nonce y tarifas.
• Firmar: el único paso que necesita la clave privada.
• Transmitir: en línea, solo necesita la carga firmada.

Comprobación ejecutable: inspeccionar el nonce y el estado de la cadena antes de firmar

Antes de comparar tipos de billeteras, confirme que su endpoint devuelve el estado de la cadena que usará su firmante. Esta llamada curl lee el número de transacciones de una dirección. Reemplace RPC_URL y ADDRESS con sus propios valores. Una discrepancia entre el nonce que usa su firmante y el nonce que espera la red es una causa común de transacciones fallidas o atascadas, y es independiente de si la billetera es caliente o fría.

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

Comprobación ejecutable: verificar una firma sin exponer la clave

Un flujo de firma en frío debería permitirle verificar que una carga firmada se recupera a la dirección esperada antes de la transmisión. El ejemplo de JavaScript a continuación usa ethers para recuperar el firmante de la firma de un mensaje. Ejecútelo en un entorno aislado o fuera de línea si la firma provino de un firmante en frío. El objetivo es confirmar que el límite funciona: la clave permaneció fuera de línea, pero la firma resultante aún se puede verificar en línea.

Esta comprobación no prueba que su clave nunca estuvo expuesta. Prueba que la firma corresponde a la dirección que espera. Combínela con una auditoría del proceso de dónde se cargó el material de la clave.

const { ethers } = require('ethers');

async function verify() {
  const message = 'cold-signing-check';
  const signature = process.env.SIGNATURE; // produced by your offline signer
  const expected = process.env.EXPECTED_ADDRESS;
  const recovered = ethers.verifyMessage(message, signature);
  console.log('recovered:', recovered);
  console.log('matches expected:', recovered.toLowerCase() === expected.toLowerCase());
}

verify().catch(console.error);

Procedimiento de tabla de resultados para su propia comparación de custodia

No confíe en las afirmaciones de los proveedores sobre la postura de seguridad. Construya una tabla de resultados a partir de sus propias observaciones. Para cada billetera que opere, registre las siguientes columnas y complételas mediante inspección y ejecutando las comprobaciones anteriores. Deje las celdas en blanco en lugar de adivinar; una celda en blanco es una brecha de medición honesta.

La tabla solo es útil si la ejecuta con claves de prueba. Una billetera caliente que muestra un límite manual puede ser híbrida; una billetera fría cuya clave se importa a un proceso caliente en línea por conveniencia es caliente en la práctica. Clasifique por la exposición observada de la clave, no por la categoría del producto.

Resultado de verificación esperado

Para un flujo de firma en frío configurado correctamente, debería ver que la dirección recuperada coincide con la dirección esperada, y debería poder confirmar que la clave privada nunca estuvo presente en el proceso que transmitió la transacción. Para una billetera caliente, la dirección recuperada también debería coincidir, pero la clave se habrá cargado en el mismo proceso en red que construyó y envió la transacción.

Si la dirección recuperada no coincide, deténgase antes de transmitir. Una discrepancia generalmente significa la clave incorrecta, la codificación del mensaje incorrecta o una firma producida sobre bytes diferentes a los que verificó. Si el nonce de su endpoint difiere del nonce que usó su firmante, reconstruya la transacción en lugar de forzar una transmisión.

Solución de problemas de clasificaciones erróneas comunes

El error más común es llamar billetera fría a cualquier dispositivo hardware. Un dispositivo que permanece conectado y firma automáticamente es un firmante caliente respaldado por hardware. Otro error común es asumir que una aplicación móvil siempre es caliente; algunas aplicaciones admiten modo de solo observación o firmantes externos, lo que cambia la exposición de la clave aunque la aplicación esté en línea.

Si una transacción se rechaza con un error de nonce, verifique si otro proceso usó la misma clave simultáneamente. Las billeteras calientes son especialmente propensas a esto porque múltiples procesos en línea pueden compartir un archivo de clave. Si una firma se verifica pero la transacción falla en la cadena, el problema probablemente sea gas, ID de cadena o lógica del contrato, no el límite caliente versus frío.

• Conflictos de nonce: serialice la firma por clave o use un único servicio de firma.
• Discrepancia de ID de cadena: confirme que el firmante usa la misma red que el transmisor.
• Atajos de importación de claves: importar una semilla fría a una aplicación caliente colapsa el límite.

Compensaciones y limitaciones

El almacenamiento en frío reduce la exposición a compromisos remotos pero no elimina la pérdida por phishing, robo físico o error del usuario durante la firma. También agrega latencia y fricción operativa, lo que importa para operaciones de alta frecuencia. Las billeteras calientes son más rápidas y fáciles de automatizar, pero cada proceso en línea que pueda alcanzar la clave es parte de su superficie de ataque.

Una arquitectura práctica a menudo separa roles: una billetera caliente mantiene solo saldos de trabajo, mientras que un firmante frío o controlado por políticas mantiene reservas. El límite debe ser impuesto por el proceso, no solo por la etiqueta. Para equipos que ejecutan sus propios nodos o infraestructura dedicada, el lado del transmisor puede aislarse del lado del firmante; consulte la guía sobre nodos dedicados y precios de RPC para dimensionar esa separación adecuadamente.

Próximos pasos

Comience clasificando sus billeteras actuales con la tabla de resultados anterior usando claves de prueba. Luego decida si su operación necesita un aislamiento estricto, un firmante respaldado por hardware con aprobación manual o una billetera caliente con saldos limitados. Si necesita elegir un endpoint para transmitir transacciones firmadas, use el Asistente RPC para obtener una recomendación directa y revise las guías de red para detalles específicos de la cadena.

Para obtener un contexto más amplio sobre operaciones de nodos y confiabilidad de endpoints, lea la guía de alojamiento de nodos de blockchain y la guía de endpoints RPC multicadena. Estos recursos le ayudan a mantener la mitad en línea de una arquitectura caliente más fría observable y reproducible.

• Clasifique las billeteras por la exposición observada de la clave, no por la categoría del producto.
• Mantenga las claves de prueba separadas de las claves de producción en todo momento.
• Documente el límite de firma y vuelva a verificarlo después de cualquier actualización de herramienta.