Explore the cryptography, consensus, execution, data, and application interfaces in the Dytallix reference architecture.
A wallet or client signs the transaction with the configured signature algorithm.
The client submits through an RPC interface. Peers exchange messages and validators agree on transaction order.
Application rules and contract execution determine state changes. The node stores the committed state.
Applications query results. Records and state proofs support independent checks.
Post-quantum cryptography separates two tasks: establishing shared secrets and verifying signatures. The National Institute of Standards and Technology (NIST) defines these algorithms in Federal Information Processing Standards (FIPS).
Shared-secret establishment
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) establishes a shared secret over a public channel. Symmetric encryption then uses keys derived from that secret to protect the data carried by the session.
Transaction and record signatures
Module-Lattice-Based Digital Signature Algorithm (ML-DSA) authenticates signed data and detects changes. The architecture applies signatures to transaction authorization, validator messages, governance votes, and signed external records.
The browser wallet uses ML-DSA-87. The deployed node build enables the FIPS 204 verifier and maps its legacy dilithium5 identifier to ML-DSA-87. This describes the inspected wallet and testnet build, not every Dytallix product.
Read FIPS 204Hash-based signature standard
Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) provides a signature family based on hash functions. It offers a different mathematical basis from the lattice-based ML-DSA family.
This is a standards reference. The current browser wallet uses ML-DSA, and this page does not list SLH-DSA as a supported testnet signing option.
Read FIPS 205Consensus establishes an agreed order for transactions. Networking carries messages between peers. Client interfaces connect applications to the node.
Validator agreement and block commitment
The reference stack uses CometBFT to coordinate validators and commit blocks. Its Application Blockchain Interface (ABCI++) separates the consensus engine from application processing. Post-quantum vote extensions carry signed validator attestations.
Peer discovery and message transport
libp2p provides peer discovery, connection management, and message propagation. The reference design combines its transport stack with ML-KEM key establishment. Relays and hole punching help peers connect across network address translation (NAT).
Application interfaces
Remote procedure call (RPC) interfaces let applications submit transactions and query state. The reference stack provides gRPC for service integrations and JSON-RPC for browser and developer tools.
Contracts define application logic. The runtime executes that logic under resource limits and must produce the same state changes on each validating node.
Contract execution format
WebAssembly (WASM) provides the execution format for compiled contracts. Memory limits and instruction metering bound the resources a contract can consume. Gas records execution cost.
Contract and tooling development
Rust is the primary language described for contract development. Its ownership and borrowing rules help prevent memory errors in safe Rust. Contracts compile to WebAssembly and can be tested before network deployment.
WebAssembly interpreter
The reference stack selects Wasmi for on-chain interpretation. Validators need consistent execution results across supported systems. Instruction metering and call-depth limits bound contract execution.
Artificial intelligence (AI) services run outside consensus. Oracle adapters deliver signed results to contracts. A valid signature identifies the source; it does not establish that a model result is correct.
Off-chain risk analysis
The reference design describes Aegis and other analysis services consuming transaction data, extracting features, and producing risk scores. Containerized services separate model computation from validator execution.
Model development and inference
Machine-learning models produce risk scores, anomaly flags, and behavioral signals. The reference stack separates training from inference so model versions and serving environments can be managed independently.
Signed delivery to contracts
Adapters submit external results with an operator signature. Contracts check the signature, permitted source, and data freshness before using the result. This keeps external computation separate from the rules that accept its output.
Node databases retain application state. Content-addressed storage holds larger payloads. Cryptographic proofs connect stored values to an agreed state without putting every underlying file on-chain.
Persistent node state
The reference stack uses RocksDB as an embedded key-value database for account balances, contract storage, and governance parameters. Its log-structured merge-tree organizes writes and compaction on local storage.
Storage for large payloads
The InterPlanetary File System (IPFS) identifies payloads by content identifier (CID). A retrieved object can be checked against its CID. Retention depends on pinning and storage arrangements; confidential content requires encryption.
Versioned state proofs
A Merkle tree commits to data through a root hash. The IAVL+ structure described in the stack keeps versioned state so a client can check an individual value against a state root without downloading the full database.
Command-line tools, a software development kit (SDK), and browser tools support development from local testing through transaction inspection.
Keys, transactions, and node operations
The reference command-line interface, dytx, covers key generation, transaction signing, contract deployment, chain queries, and node management. Its command set and supported algorithms depend on the installed release.
Contract development interfaces
The dytallix-sdk reference describes contract entry points, typed storage, cross-contract calls, event emission, and signature verification helpers. A mock runtime supports local tests before deployment to a development network.
Testnet access and inspection
The browser wallet creates session keys and signs testnet transfers. The Explorer shows network activity. The Faucet supplies test assets for development. Wallet keys stay in browser memory and are lost when the page reloads.
