Pallas

The pallas-crypto crate provides the following cryptographic primitives required for the Cardano protocol:

• hash: Provides Hash<N> and Hasher<N> implementations using Blake2b. The generic N is the digest size in bits.
• key::ed25519: Supports regular and extended Ed25519 key pairs, including signing and verification.
• kes: Implements Key Evolving Signature (KES) primitives used by block producers.
• nonce: Provides helpers for epoch and chain-nonce evolution.
• memsec: Provides secure-memory utilities to ensure key material is wiped from memory.

The pallas-configs crate provides era-specific modules and shared cost model views:

• Era Modules: byron, shelley, alonzo, and conway. Each module exposes a GenesisFile struct (or equivalent) and a from_file function for loading configuration files.
• Cost Models: The cost_models module provides typed views over Plutus cost-model tables, which are shared across different eras.

The pallas-hardano crate provides interoperability with Haskell Cardano node artifacts through two main modules:

storage::immutable

Provides readers over the node's chunk, primary, and secondary index files. Key entry points include:

• read_blocks: Iterates through blocks in the immutable directory.
• read_blocks_from_point: Reads blocks starting from a specific point.
• get_tip: Retrieves the current tip of the chain.

display

Provides pretty-printing helpers for the structures returned by the storage modules.

The pallas-codec crate provides the encoding foundation for the Pallas workspace. It primarily consists of a re-exported version of minicbor for CBOR operations and a Rust port of the Plutus Core flat format.

While most users will interact with these encoding capabilities transitively through higher-level crates like pallas-primitives, pallas-traverse, or pallas-txbuilder, you can use pallas-codec directly for custom CBOR serialization or Plutus Core script handling.

use pallas_codec::minicbor;

#[derive(minicbor::Encode, minicbor::Decode)]
struct Pair(#[n(0)] u64, #[n(1)] String);

let bytes = minicbor::to_vec(Pair(1, "hi".into()))?;
let back: Pair = minicbor::decode(&bytes)?;

The TxSubmission miniprotocol allows a client holding transactions to announce them to a server interested in those transactions. This is primarily used for propagating transactions across node mempools in a peer-to-peer fashion until they reach a node ready to mint a block.

Unlike traditional download protocols, TxSubmission is designed for two-way congestion control:

1. A node with transactions is not forced to initiate connections to everyone.
2. A node interested in transactions can selectively choose what to download.

The protocol operates as a state machine where the client initiates the connection and moves the protocol from an Init state to an Idle state. Once in Idle, the server can request transaction IDs or full transaction bodies.

For compatibility with the Cardano blockchain, this library provides two implementations of Sum6Kes:

1. Sum6Kes: The standard implementation used by Cardano.
2. SumCompact6Kes: An optimized implementation that provides an asymptotic halving of the signature size compared to the standard version.

Interoperability is maintained via test vectors generated using Cardano's code, located in the ./data directory of the repository.

The pallas_addresses crate organizes address data into a hierarchy of types:

• Address (Enum): The top-level container that dispatches to one of three variants: Byron, Shelley, or Stake.
• Specific Address Types:
  • ByronAddress
  • ShelleyAddress
  • StakeAddress
• Structural Components (Shelley/Stake):
  • ShelleyPaymentPart and ShelleyDelegationPart: The constituent parts of a Shelley address.
  • StakePayload and Pointer: Components used in stake address construction.
• Network: An enum representing the network context (Mainnet, Testnet, or Other(u8)) extracted from the address header.
• Submodules:
  • byron: Contains Byron-specific structures and CBOR helpers.
  • varuint: Provides the variable-length integer codec used by stake pointers.

Pallas Traverse provides two main discriminators to understand the context of the data you are traversing:

1. Era: Used to determine exactly which era a piece of data belongs to.
2. Feature: Used to check if a specific era supports certain capabilities, such as multi-assets, smart contracts, or CIP-1694.

The transaction construction lifecycle in Pallas TxBuilder follows a two-stage pattern:

1. StagingTransaction: This is the mutable, in-progress state of your transaction. It serves as the primary entry point for configuration. You use it to collect inputs, outputs, minting requirements, scripts, datums, redeemers, fees, network IDs, and validity intervals.
2. BuiltTransaction: Once configuration is complete, you call a finalization method (like build_conway_raw()) which consumes or transforms the staging state into a BuiltTransaction. This object represents the finalized, encoded transaction body. It provides the .sign(&signer) method to apply signatures and exposes the raw CBOR bytes via the .tx_bytes field.