34. Becoming a Validator

Validators are the consensus authorities of the Kortana blockchain. They run isolated cryptographic signers, propose new blocks, and sign HotStuff Quorum Certificates.

34.1 Key Generation

A validator requires two distinct cryptographic key pairs: a BLS12-381 Key for consensus voting and an Operator Key (secp256k1 or Ed25519) for paying staking transaction gas fees:

# Generate BLS12-381 consensus key pair
kortana-cli keygen --type bls > consensus.key

# Generate operator wallet for staking management
kortana-cli wallet new > operator.key

Private keys must be backed up securely in air-gapped storage.

34.2 Node Configuration

In config.toml, configure the validator's public identity and specify the local IPC socket path used to communicate with the kortana-validator signing process:

[validator]
enabled = true
identity = "Validator-Node-01"
bls_public_key = "0x8f1234..."
signer_socket = "/var/run/kortana/validator.sock"

34.3 Validator Address Configuration

Load the generated BLS12-381 private key into the kortana-validator process. The signing process runs as an isolated system user with read-only access to the encrypted key file, communicating with kortanad over a permissioned Unix domain socket.

34.4 The --check Flag

Before launching a validator into live consensus, execute the diagnostic verification command:

kortanad --check config.toml

The --check routine validates configuration file syntax, verifies that RocksDB column families are uncorrupted, tests P2P port reachability, and confirms that the BLS signer socket is responsive.

34.5 Launching the Validator Process

Launch the validator by starting both systemd service units:

sudo systemctl start kortana-validator
sudo systemctl start kortanad

Once the daemon synchronizes with the network head, broadcast a native Stake transaction (Type 0x30) with the minimum required DNR self-stake (e.g., 100,000 DNR). The validator will be included in the active set at the next epoch boundary.

34.6 Responsibilities & Slashing Risks

Validators must maintain 99.9% server availability and ensure reliable network connectivity.

[!CAUTION] Slashing Prevention: NEVER run two active node instances with the same BLS12-381 consensus key simultaneously (e.g., in active-active failover setups). Doing so will cause double-signing equivocation, resulting in 100% stake slashing and permanent jailing.

---