Generación de billeteras Solana: claves ed25519 y direcciones

Solana es una de las blockchains más utilizadas tanto para DeFi como para aplicaciones de consumo, pero su proceso de generación de billeteras difiere significativamente de Bitcoin y Ethereum. Curva elíptica diferente, rutas de derivación diferentes, codificación de dirección diferente y supuestos diferentes sobre la gestión de claves. Si vienes del mundo Bitcoin o Ethereum, estas diferencias importan — y malinterpretarlas puede llevar a la pérdida de fondos o seguridad comprometida.

Esta guía cubre el proceso completo de generación de billeteras Solana: la curva elíptica ed25519, las rutas de derivación específicas de Solana, la codificación de direcciones Base58 y las consideraciones de seguridad únicas del ecosistema Solana.

Cómo Solana difiere de Bitcoin y Ethereum¶

A nivel más alto, la diferencia es la curva elíptica. Bitcoin y Ethereum usan secp256k1, una curva del Standards for Efficient Cryptography Group (SECG). Solana usa ed25519, una curva de forma Edwards diseñada por Daniel J. Bernstein y colegas. La elección de curva se propaga por cada capa del stack.

Las decisiones de diseño de Solana reflejan sus prioridades: alto throughput y verificación rápida de firmas. Las firmas Ed25519 son aproximadamente el doble de rápidas de verificar que las firmas ECDSA en secp256k1, lo cual importa cuando procesas miles de transacciones por segundo. Para una comparación técnica más profunda de las dos curvas, consulta secp256k1 vs ed25519.

La curva ed25519¶

Ed25519 es una instancia específica del Algoritmo de Firma Digital de Curva Edwards (EdDSA), operando en Curve25519. La curva está definida sobre el campo primo 2^255 - 19 (de ahí el nombre) y usa una forma de Edwards retorcida:

-x^2 + y^2 = 1 + d*x^2*y^2

donde d es una constante específica. El nivel de seguridad es aproximadamente 128 bits — comparable a secp256k1 — pero las características de implementación difieren significativamente.

Generación de claves¶

Una clave privada de Solana comienza como un escalar aleatorio de 32 bytes, a menudo llamado "semilla" en la terminología ed25519 (no confundir con una frase semilla BIP39). Este valor de 32 bytes se hashea con SHA-512 para producir una clave expandida de 64 bytes. Los 32 bytes inferiores (después del clamping de bits) se convierten en el escalar usado para firmar. Los 32 bytes superiores se usan como aleatoriedad adicional en el proceso de firma.

La clave pública se deriva multiplicando el punto base B de la curva por el escalar clamped. El resultado es un punto de 32 bytes en forma comprimida de Edwards. Esta clave pública de 32 bytes es también la dirección de Solana — no hay un paso adicional de hashing como el Keccak-256 de Ethereum.

32 bytes aleatorios → SHA-512 → 64 bytes de clave expandida
    → 32 bytes inferiores (clamped) × Punto base B → 32 bytes clave pública = dirección Solana

Firmas determinísticas¶

Una ventaja de ed25519 sobre ECDSA es que las firmas son determinísticas. ECDSA requiere un nonce aleatorio para cada firma, y un generador de números aleatorios defectuoso puede filtrar catastróficamente la clave privada (esto ha sucedido múltiples veces en la historia de Bitcoin y Ethereum). Ed25519 deriva el nonce del mensaje y la clave privada, eliminando toda esta clase de vulnerabilidad.

Rendimiento¶

La verificación de firmas Ed25519 es rápida — aproximadamente 70,000 verificaciones por segundo en un solo núcleo de CPU moderno. Esto es aproximadamente el doble de la velocidad de verificación ECDSA en secp256k1. Para la arquitectura de Solana, que apunta a tiempos de bloque de 400 milisegundos y alto throughput de transacciones, esta ventaja de velocidad es significativa.

Rutas de derivación de Solana¶

Como Bitcoin y Ethereum, las billeteras Solana usan derivación de billeteras HD para generar múltiples claves desde una sola frase semilla. El estándar sigue siendo BIP39 para la generación de mnemónicos y BIP32 para la derivación jerárquica, pero con rutas específicas de Solana.

La ruta estándar: m/44'/501'/0'/0'¶

La ruta de derivación canónica de Solana es:

m/44'/501'/0'/0'

Desglosándola según BIP44:

• 44' — Propósito: jerarquía multi-cuenta BIP44.
• 501' — Tipo de moneda: 501 es el índice registrado SLIP44 para Solana.
• 0' — Cuenta: primera cuenta.
• 0' — El nivel de "cambio", pero en la convención de Solana este es el índice de dirección.

Observa que los cuatro niveles usan derivación endurecida (indicada por el apóstrofe). Esto difiere del m/44'/60'/0'/0/0 de Ethereum, que usa derivación no endurecida para los dos últimos niveles. La elección de Solana de rutas totalmente endurecidas proporciona un aislamiento más fuerte entre las claves derivadas: comprometer una clave derivada no puede llevar al compromiso de claves hermanas.

Múltiples cuentas¶

Para cuentas adicionales, incrementa el índice de cuenta:

• Primera cuenta: m/44'/501'/0'/0'
• Segunda cuenta: m/44'/501'/1'/0'
• Tercera cuenta: m/44'/501'/2'/0'

Algunas billeteras (como Phantom) también pueden soportar incrementar el índice final:

• m/44'/501'/0'/0'
• m/44'/501'/0'/1'
• m/44'/501'/0'/2'

Consideraciones de compatibilidad¶

No todas las billeteras Solana usan exactamente la misma ruta de derivación. Históricamente, el CLI de Solana usaba m/44'/501' (solo dos niveles), mientras que la mayoría de las billeteras GUI usan m/44'/501'/0'/0'. Esta discrepancia significa que la misma frase semilla puede producir direcciones diferentes en diferentes billeteras. Al recuperar una billetera, siempre confirma qué ruta de derivación espera la billetera.

El Generador de frases semilla Solana de SafeSeed muestra la ruta de derivación exacta utilizada, para que sepas precisamente qué ruta corresponde a qué dirección.

Generación de billetera paso a paso¶

Aquí está el proceso completo para generar una billetera Solana desde una frase semilla BIP39, desglosado en pasos discretos.

Paso 1: Generar entropía¶

Usa un generador de números aleatorios criptográficamente seguro para producir 128 bits (para una frase de 12 palabras) o 256 bits (para una de 24 palabras) de entropía. En SafeSeed, esto usa la Web Crypto API del navegador a través de crypto.getRandomValues().

Paso 2: Crear el mnemónico¶

Añade los bits de checksum SHA-256 a la entropía, divide en segmentos de 11 bits, y mapea cada segmento a una palabra en la lista de palabras BIP39. El resultado son 12 o 24 palabras en inglés. Este proceso es idéntico a Bitcoin y Ethereum — BIP39 es agnóstico de blockchain. Para un desglose completo, consulta BIP39 explicado.

Paso 3: Derivar la semilla maestra¶

Aplica PBKDF2-HMAC-SHA512 con 2,048 iteraciones a la cadena del mnemónico (con sal de frase de contraseña opcional), produciendo una semilla maestra de 512 bits.

Paso 4: Derivar la clave Solana¶

Recorre la ruta de derivación m/44'/501'/0'/0', realizando derivación de clave hijo HMAC-SHA512 en cada nivel. Debido a que Solana usa ed25519 en lugar de secp256k1, la derivación de clave hijo usa el estándar SLIP-0010 (no BIP32 directamente), que especifica cómo derivar claves ed25519 jerárquicamente.

La salida al final de la ruta es una semilla ed25519 de 32 bytes.

Paso 5: Generar el par de claves¶

Alimenta la semilla de 32 bytes en la generación de claves ed25519:

1. Calcula SHA-512 de la semilla para obtener 64 bytes.
2. Aplica clamping de bits a los 32 bytes inferiores (limpia los 3 bits más bajos, limpia el bit más alto, establece el segundo bit más alto).
3. Multiplica el punto base B por el escalar clamped para obtener la clave pública de 32 bytes.

El par de claves consiste en la clave privada expandida de 64 bytes (semilla + clave pública) y la clave pública de 32 bytes.

Paso 6: Codificar la dirección¶

La clave pública de 32 bytes se codifica usando Base58 para producir la dirección Solana legible por humanos. Sin hashing adicional, sin byte de prefijo — solo codificación Base58 cruda de los bytes de la clave pública.

Puedes generar e inspeccionar todo este flujo usando el Generador de claves privadas Solana de SafeSeed, que muestra la frase semilla, ruta de derivación, clave privada, clave pública y dirección final.

Formato de dirección Base58¶

Las direcciones Solana usan codificación Base58 — el mismo alfabeto Base58 usado por las direcciones legado de Bitcoin, que excluye caracteres visualmente confusos: 0 (cero), O (O mayúscula), I (I mayúscula) y l (l minúscula).

Una dirección Solana típica se ve así:

7EcDhSYGxXyscszYEp35KHN8vvw3svAuLKTzXwCFLtV

Propiedades¶

• Longitud: 32-44 caracteres (más comúnmente 43-44). La longitud varía porque la codificación Base58 no es de ancho fijo; los bytes cero iniciales producen caracteres 1 iniciales.
• Conjunto de caracteres: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
• Sin prefijo: A diferencia de Bitcoin (empieza con 1, 3 o bc1) o Ethereum (empieza con 0x), las direcciones Solana no tienen prefijo fijo. Esto hace más difícil la identificación visual pero mantiene las direcciones cortas.
• Sin checksum embebido: A diferencia de Base58Check (usado por direcciones legado de Bitcoin), la codificación Base58 de Solana no incluye un checksum. Un error de transcripción podría producir una dirección que parece válida pero pertenece a alguien más o a nadie.

La falta de checksum hace que el manejo cuidadoso sea esencial. Siempre usa copiar y pegar en lugar de transcripción manual. Cuando sea posible, usa códigos QR. Y valida el formato de la dirección usando el Validador de direcciones Solana antes de enviar fondos. Para una comparación más amplia de formatos de direcciones entre blockchains, consulta Formatos de direcciones cripto explicados.

Consideraciones de seguridad para Solana¶

Los principios generales de seguridad de claves se aplican a Solana igual que a cualquier blockchain, pero varios factores específicos de Solana merecen atención.

La generación offline es crítica¶

Debido a que las direcciones Solana no tienen checksum embebido, los errores durante la generación son más difíciles de detectar. Generar tu billetera offline — en una máquina sin conexión de red — elimina el riesgo de exfiltración y te da un entorno controlado para verificar cuidadosamente la salida. Las herramientas de SafeSeed están diseñadas para esto: carga la página, desconecta, genera y registra. Para principios generales de generación offline, consulta ¿Son seguros los generadores de frases semilla online?.

Archivos de par de claves¶

El CLI de Solana almacena claves privadas como arrays JSON de 64 bytes (el par de claves ed25519) en archivos típicamente llamados id.json. Si exportas tu billetera desde una GUI e importas en el CLI (o viceversa), puedes encontrar este formato. Protege los archivos de par de claves con el mismo rigor que las frases semilla: cifrados, almacenados en medios aislados y nunca en máquinas conectadas a la red.

Cuentas de tokens¶

A diferencia de Ethereum, donde los tokens ERC-20 se mantienen en la misma dirección que ETH, Solana usa cuentas de tokens asociadas (ATAs) — cuentas separadas en cadena para cada tipo de token. Esto es un detalle de implementación, no una preocupación de seguridad de claves, pero significa que tu dirección Solana por sí sola no cuenta toda la historia de tus holdings. Todos los ATAs derivados de una dirección de billetera dada están controlados por la misma clave privada, así que tu respaldo de frase semilla sigue siendo suficiente.

Direcciones Derivadas por Programa (PDAs)¶

El modelo de programación de Solana usa Direcciones Derivadas por Programa — direcciones que se generan determinísticamente a partir de un ID de programa y un conjunto de semillas, y que intencionalmente no tienen una clave privada correspondiente. Los PDAs son usados por contratos inteligentes (programas) para gestionar el estado en cadena. No necesitas generar ni respaldar PDAs; no son billeteras controladas por usuarios.

Nonces duraderos y firma de transacciones¶

Las transacciones de Solana incluyen un blockhash reciente para protección contra replay, lo que significa que las transacciones expiran después de aproximadamente 60-90 segundos. Esto es relevante para flujos de trabajo de firma offline: necesitas obtener un blockhash reciente (o usar un nonce duradero) en una máquina online, transferirlo a la máquina offline para firmar, y luego transmitir la transacción firmada antes de que expire el blockhash. Las billeteras hardware manejan esto automáticamente, pero si estás construyendo un pipeline personalizado de firma offline, la restricción de tiempo es una consideración de diseño importante.

Mejores prácticas de seguridad de claves privadas¶

Los fundamentos siguen siendo los mismos independientemente de la cadena: nunca compartas tu frase semilla, nunca la almacenes digitalmente en un dispositivo conectado a la red, y usa almacenamiento frío para cualquier holding significativo. Para un tratamiento completo, consulta Mejores prácticas de seguridad de claves privadas.

El proceso de generación de billeteras Solana es conceptualmente similar a Bitcoin y Ethereum — la entropía se convierte en una frase semilla, la frase semilla se convierte en una clave maestra, y las rutas de derivación producen cuentas individuales. Pero la curva subyacente (ed25519), el estándar de derivación (SLIP-0010) y el formato de dirección (Base58 crudo sin checksum) crean un conjunto distinto de detalles de implementación que importan para la interoperabilidad, la recuperación y la seguridad. Entender estas diferencias no es académico; es la base para proteger tus holdings de Solana.