Guía de línea de comandos de claves

Crear Claves

Bursa permite derivar claves individuales a partir de una mnemónica y generar material BLS de Dijkstra para el registro de stake pools.

Tipos de claves:
Clave raíz	Clave de Cuenta	Clave de Pago
Clave de Stake	Clave fría de pool	Clave de política
Clave Calidus	Claves VRF	Par de Claves KES
Clave DRep	Clave fría del Comité Constitucional	Clave caliente del Comité Constitucional
Clave BLS de Dijkstra para registro de stake pool

Guía de línea de comandos de Bursa para derivar claves individuales a partir de una mnemónica y para generar material BLS de Dijkstra para el registro de stake pools.

La mnemónica se puede proporcionar mediante:

Bandera —mnemonic
Variable de entorno MNEMONIC
Bandera —mnemonic-file
Archivo por defecto “seed.txt”

Bursa genera las claves derivadas a partir de una mnemónica según los estándares CIP de Cardano y en formato bech32 adecuado para usar con cardano-cli y otras herramientas.

Rutas de derivación por tipo de clave:

CIP-1852: root, account, payment, stake (m/1852’/1815’/…)

CIP-1853: pool-cold (m/1853’/1815’/…)

CIP-1855: policy (m/1855’/1815’/…)

CIP-0105: drep, committee-cold, committee-hot (m/1852’/1815’/account’/role/…)

CIP-88/151: calidus (m/1852’/1815’/account’/0/index, autenticación SPO)

Dijkstra: bls (material BLS12-381 MinSig aleatorio para el registro de Leios y Peras)

Formato de archivo de clave de firma

Cuando Bursa exporta una clave de firma que sigue una ruta HD, escribe un sobre extendido Ed25519-BIP32. Los archivos de firma de las claves raíz, cuenta, pago, stake, gobernanza, política, multifirma y Calidus usan tipos de sobre como *_ExtendedSigningKeyShelley_ed25519_bip32 y CBOR de 128 bytes que comienza con 5880. Los archivos antiguos no extendidos usan CBOR de 32 bytes que comienza con 5820.

Las nuevas exportaciones de pool-cold usan un sobre Ed25519 estándar no extendido con el tipo StakePoolSigningKey_ed25519. El sobre de verificación correspondiente usa StakePoolVerificationKey_ed25519. Al cargar archivos, Bursa acepta los tipos heredados StakePoolSigningKeyShelley_ed25519 y StakePoolVerificationKeyShelley_ed25519, pero no los reescribe automáticamente. La clave de verificación exportada de pool-cold es la identidad Ed25519 estándar que usan los certificados operativos. La representación extendida opcional de pool-cold conserva la misma identidad del pool.

Bursa solo acepta archivos de clave secreta (.skey) con acceso exclusivo del propietario. En Unix, rechaza cualquier bit de permisos para el grupo u otros usuarios; en Windows, requiere una DACL restrictiva limitada al propietario. Bursa rechaza los archivos de clave secreta inseguros con ErrInsecureFileMode. Si un directorio contiene únicamente archivos .skey rechazados por esta comprobación, Bursa informa el error de permisos. Los artefactos públicos, como los archivos .vkey y los certificados operativos, siguen la ruta de carga de claves públicas y no están sujetos a esta comprobación de permisos de claves secretas. Al cargar una clave desde un archivo, Bursa rechaza cualquier entrada que no sea un archivo regular. En Unix, rechaza las entradas que usan enlaces simbólicos; en Windows, rechaza los puntos de reanálisis. Bursa limita el tamaño de entrada al máximo que admite la implementación y rechaza los archivos que superan ese máximo antes de procesarlos. La ruta de clave pública permite seguir leyendo los archivos públicos. Bursa aplica la comprobación de permisos de propietario únicamente cuando carga material secreto. No intente reparar un archivo de firma HD antiguo cambiando únicamente el campo type. Regenere conjuntamente los archivos de firma y verificación a partir de la mnemónica original y compare la dirección o el hash de clave resultantes con la dirección, el hash de clave o la identidad que ya están en uso antes de firmar.

Clave raíz

La clave raíz es la clave maestra a partir de la cual se derivan todas las demás claves. La salida es en formato bech32 (prefijo root_xsk) a menos que se especifique —signing-key-file.

./bursa key root --mnemonic "word1 word2 ..."

Ejemplo de clave raíz con archivo de clave de firma:

Por favor ajusta la ruta a continuación.

./bursa key root --signing-key-file /path/root.skey

Clave de Cuenta

La clave de cuenta sigue la ruta CIP-1852: m/1852’/1815’/account’ La salida es en formato bech32 (prefijo acct_xsk) a menos que se especifique —signing-key-file.

./bursa key account --mnemonic "word1 word2 ..." --index 0

Clave de Pago

La clave de pago sigue la ruta CIP-1852: m/1852’/1815’/account’/0/index La salida es en formato bech32 (prefijo addr_xsk) a menos que se especifiquen archivos de clave.

./bursa key payment --mnemonic "word1 word2 ..." --account-index 0 --index 0

Clave de Stake

La clave de stake sigue la ruta CIP-1852: m/1852’/1815’/account’/2/index La salida es en formato bech32 (prefijo stake_xsk) a menos que se especifiquen archivos de clave.

./bursa key stake --mnemonic "word1 word2 ..." --account-index 0 --index 0

Clave fría de pool

La clave fría de pool sigue la ruta CIP-1853: m/1853’/1815’/0’/index’ Estas claves se usan como las claves de identidad a largo plazo para los operadores de stake pool. La salida es en formato bech32 (prefijo pool_xsk) a menos que se especifiquen archivos de clave.

./bursa key pool-cold --mnemonic "word1 word2 ..." --index 0

Clave de política

La clave de política sigue la ruta CIP-1855: m/1855’/1815’/policy_ix’ Estas claves se usan para políticas de acuñación/quema de activos nativos. La salida es en formato bech32 (prefijo policy_xsk) a menos que se especifiquen archivos de clave.

./bursa key policy --mnemonic "word1 word2 ..." --index 0

Clave Calidus

La clave Calidus es la clave caliente de autenticación on-chain de SPO definida por CIP-88/CIP-151. Usa la misma ruta de derivación que la clave de pago: m/1852’/1815’/account’/0/index

La clave es funcionalmente idéntica a la clave de pago, pero usa diferentes prefijos bech32 (calidus_xsk/calidus_xvk) y diferentes tipos de sobre de texto de cardano-cli para propósitos de identidad SPO.

La salida es en formato bech32 (prefijo calidus_xsk) a menos que se especifiquen archivos de clave.

./bursa key calidus --mnemonic "word1 word2 ..." --account-index 0 --index 0

Ejemplo de Clave Calidus con Archivos de Clave

Por favor ajusta la ruta a continuación.

./bursa key calidus --signing-key-file /path/calidus.skey --verification-key-file /path/calidus.vkey

Par de claves VRF (función aleatoria verificable)

Las claves VRF son usadas por los operadores de stake pool para la elección de líder en el protocolo de consenso Praos. La semilla se deriva determinísticamente de la mnemónica, lo que permite la recuperación de la clave.

La salida incluye tanto la clave de firma (vrf_sk) como la clave de verificación (vrf_vk) en formato bech32, a menos que se especifiquen archivos de clave.

Antes de exportar o cargar material de VRF, Bursa valida las longitudes requeridas. La clave de verificación vrf_vk debe tener la longitud esperada. La clave de firma vrf_sk debe usar un formato de semilla aceptado: una semilla sola o una semilla seguida de su clave pública. En el segundo formato, Bursa comprueba que la clave pública incluida coincide con la identidad derivada de la semilla. Si el material tiene una longitud incorrecta o esa identidad no coincide, Bursa rechaza la entrada y no genera un sobre.

./bursa key vrf --mnemonic "word1 word2 ..." --index 0

Ejemplo de VRF con Archivos de Clave

Por favor ajusta la ruta a continuación.

./bursa key vrf --signing-key-file /path/vrf.skey --verification-key-file /path/vrf.vkey

Par de Claves KES

Las claves KES son usadas por los operadores de stake pool para firma de bloques en el protocolo de consenso Praos. KES proporciona firmas con seguridad hacia adelante donde comprometer la clave actual no compromete las firmas anteriores.

Esta implementación usa la profundidad 6 de Cardano, proporcionando 64 períodos de tiempo. La semilla se deriva determinísticamente de la mnemónica, lo que permite la recuperación de la clave.

La salida incluye tanto la clave de firma (kes_sk, 608 bytes) como la clave de verificación (kes_vk, 32 bytes) en formato bech32, a menos que se especifiquen archivos de clave.

Antes de exportar o cargar material de KES, Bursa valida las longitudes requeridas. La clave de verificación kes_vk debe tener la longitud esperada. La clave de firma kes_sk debe usar la profundidad de Cardano KES y el tamaño de clave secreta esperados. Bursa rechaza el material con longitudes malformadas, una profundidad KES inválida o un tamaño de clave secreta inválido, y no genera un sobre.

./bursa key kes --mnemonic "word1 word2 ..." --index 0

Ejemplo de Clave KES con Archivos de Clave

Por favor ajusta la ruta a continuación.

./bursa key kes --signing-key-file /path/kes.skey --verification-key-file /path/kes.vkey

Clave DRep

La clave DRep sigue la ruta CIP-0105: m/1852’/1815’/account’/3/index Estas claves se usan para participación en gobernanza como Representante Delegado. La salida es en formato bech32 (prefijo drep_xsk) a menos que se especifiquen archivos de clave.

./bursa key drep --mnemonic "word1 word2 ..." --account-index 0 --index 0

Ejemplo de Clave DRep con Archivos de Clave

Por favor ajusta la ruta a continuación.

./bursa key drep --signing-key-file /path/drep.skey --verification-key-file /path/drep.vkey

Clave fría del Comité Constitucional

La clave fría del comité sigue la ruta CIP-0105: m/1852’/1815’/account’/4/index Estas claves se usan para la membresía en el Comité Constitucional (identidad a largo plazo). La salida es en formato bech32 (prefijo cc_cold_xsk) a menos que se especifiquen archivos de clave.

./bursa key committee-cold --mnemonic "word1 word2 ..." --account-index 0 --index 0

Ejemplo de clave fría del Comité Constitucional con archivos de clave

Por favor ajusta la ruta a continuación.

./bursa key committee-cold --signing-key-file /path/committee-cold.skey --verification-key-file /path/committee-cold.vkey

Clave caliente del Comité Constitucional

La clave caliente del comité sigue la ruta CIP-0105: m/1852’/1815’/account’/5/index Estas claves se usan para votación del Comité Constitucional (clave operacional). La salida es en formato bech32 (prefijo cc_hot_xsk) a menos que se especifiquen archivos de clave.

./bursa key committee-hot --mnemonic "word1 word2 ..." --account-index 0 --index 0

Ejemplo de clave caliente del Comité Constitucional con archivos de clave

Por favor ajusta la ruta a continuación.

./bursa key committee-hot --signing-key-file /path/committee-hot.skey --verification-key-file /path/committee-hot.vkey

Clave BLS de Dijkstra para registro de stake pool

El comando bursa key bls genera material BLS12-381 MinSig criptográficamente aleatorio para el registro de stake pools de la era Dijkstra en Leios y Peras. El comando no consume una mnemónica ni las fuentes --mnemonic, MNEMONIC, --mnemonic-file o seed.txt de los demás comandos.

./bursa key bls --signing-key-file bls.skey --verification-key-file bls.vkey --output-file bls-registration.json

Para ejecutar el comando, la bandera --signing-key-file <ruta> es obligatoria. Las banderas --verification-key-file y --output-file son opcionales:

--signing-key-file guarda la clave de firma en un sobre compatible con cardano-cli de tipo BlsSigningKey_bls12-381-BLS-Signature-Minimal-Signature-Size. Bursa nunca imprime el secreto de firma; el comando solo lo guarda cuando recibe esta bandera.
--verification-key-file guarda la clave de verificación en un sobre compatible con cardano-cli de tipo BlsVerificationKey_bls12-381-BLS-Signature-Minimal-Signature-Size.
--output-file guarda el material de registro en formato JSON. Cuando el comando omite esta bandera, Bursa escribe el JSON en la salida estándar.

El JSON contiene los campos publicKey y possessionProof. publicKey contiene la clave pública de 96 bytes y possessionProof contiene la prueba de posesión de 48 bytes; ambos valores usan cadenas hexadecimales en minúsculas. Bursa verifica la prueba generada antes de producir la salida.

Bursa crea los archivos de destino con permisos solo para el propietario (0600). La clave de firma constituye material de credenciales del pool y requiere protección y una copia de respaldo segura.

Bursa exige que --signing-key-file, --verification-key-file y --output-file no apunten al mismo destino. Bursa convierte las rutas a una forma canónica y rechaza las colisiones entre ellas, incluidos los alias que usan enlaces simbólicos.

Explora otros comandos de Bursa

Categorías de comandos de Bursa

wallet - Comandos para generar billetera y los archivos necesarios para administrar una billetera de Cardano

api    - Comandos para ejecutar la API

kes-agent - Comando para ejecutar el agente KES para un productor de bloques de Cardano

cert - Comandos para generar varios certificados de Cardano

hash     - Comandos para generar hashes criptográficos usados en Cardano

script    - Comandos para operaciones multifirma

address - Comandos para trabajar con direcciones de Cardano

key    - Comandos para derivar claves individuales a partir de una mnemónica y generar material BLS de Dijkstra

Docs authored by Doc Holiday

Editar página

Última actualización: 22 oct 2026

Anterior
Guía de línea de comandos de direcciones Siguiente
Referencia de configuración de Bursa