Blockchain – Zixt Secure Messaging

What is blockchain, isn’t that just that bitcoin thing?

NO! Far from it! You could say that bitcoin was the first well-known use of a blockchain ledger. Blockchain ledger exists outside of just a narrow concept of “bitcoin,” it in-fact, is the protocol or underpinning of not just bitcoin, but virtually any “cryptocurrency.”

Who invented blockchain?

That is the subject of lore, actually. What we know from history is that in 2008, a whitepaper titled, “Bitcoin: A Peer-to-Peer Electronic Cash System” was published by Satoshi Nakamoto, a pseudonym of the creator of bitcoin. Some may also argue that the concept of blockchain was first posed by Wei Dai in the late 1990’s in cryptography forums as athought exercise.

The whitepaper was published on a cryptography mailing list hosted by metzdowd.com. It was posted to the listserv under the subject “Bitcoin P2P e-cash paper” and is archived at http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html. The original PDF was also hosted on bitcoin.org, a domain registered by Nakamoto (http://www.bitcoin.org/bitcoin.pdf). To date, no one has positively identified who Satoshi Nakamoto actually is.

In the whitepaper, blockchain ledger technology wasn’t intended to be the “invention,” but rather was the protocol described that allowed a decentralized currency called bitcoin to exist. Since then, the core “blockchain ledger” concept has been adapted to all sorts of use-cases and applications where secure, immutable decentralized control is used, including Zixt Chat!!

How does Zixt Chat use blockchain

Zixt Chat leverages blockchain technology to ensure secure, decentralized, and tamper-resistant messaging and user authentication.

Core Blockchain Functionality
Zixt employs a custom blockchain to store critical application data, such as user identities (cryptographic pseudonyms) and message metadata, ensuring immutability and transparency. The blockchain is a distributed ledger where each block contains a set of transactions (e.g., user registrations, message sends, or authentication events) and is cryptographically linked to the previous block.

Block Structure:

Each block includes a unique block ID

A timestamp
A list of transactions (e.g., user registration events or message metadata)
A reference to the previous block’s hash, ensuring chain integrity
A SPHINCS+ signature for post-quantum security, verifying the block’s authenticity

Transaction Types:

User Registration: Stores a user’s cryptographic pseudonym and public key, signed with SPHINCS+ to ensure quantum-resistant authentication.

Message Metadata: Records details like sender, recipient, timestamp, and a hash of the message content (actual message content is stored off-chain for efficiency).

Authentication Events: Logs login attempts or key updates, ensuring traceability.

Lets Get Technical

SPHINCS+ for Quantum-Resistant Authentication
Zixt integrates SPHINCS+, a stateless hash-based signature scheme, to provide post-quantum cryptographic security. This is critical for protecting user identities and blockchain integrity against future quantum computing threats.

User Authentication: When a user registers or logs in, their cryptographic pseudonym is tied to a SPHINCS+ key pair. The private key signs transactions (e.g., sending a message), and the public key, stored on the blockchain, allows others to verify the signature.
Block Signing: Each block is signed with a SPHINCS+ signature by the node that proposes it, ensuring that only authorized nodes can add blocks and that the block’s contents are tamper-proof.
Why SPHINCS+?: Its stateless nature simplifies key management in a distributed system, and its hash-based design is resistant to quantum attacks, unlike traditional algorithms like RSA or ECDSA.

Multi-Node Blockchain for Decentralization
To address your earlier concern about state loss on server restarts, Zixt uses a multi-node setup with peer-to-peer (P2P) communication and a leader-based consensus mechanism. This ensures the blockchain state is preserved across nodes and restarts.

Node Architecture:

Multiple nodes run the Zixt application, each maintaining a full copy of the blockchain.
Nodes communicate via a P2P network to propagate transactions and blocks.
A leader node, elected periodically, proposes new blocks, while other nodes validate and sync.

Consensus Mechanism:

The leader-based consensus ensures efficient block creation. The leader collects transactions, forms a block, signs it with SPHINCS+, and broadcasts it.
Other nodes verify the block’s signature and contents against their local blockchain copy. If valid, they append it and sync with peers.
If a node restarts, it syncs with peers to rebuild its blockchain state, ensuring no data loss (unlike the single-node setup where in-memory state was lost).

Fault Tolerance:

The multi-node setup tolerates node failures as long as a majority of nodes remain online, maintaining blockchain availability.

Persistence and Caching
To improve performance and address your question about caching, Zixt implements a file-system-based cache and database integration:

Database Integration: Transaction data (e.g., user registrations, message metadata) is stored in a database (e.g., SQLite or PostgreSQL) alongside the blockchain. On node restart, the system trusts the database to rebuild the blockchain state, skipping invalid or missing blocks, as we adjusted in the script.
File-System Cache: Frequently accessed blockchain data, such as recent blocks or user public keys, is cached on the file system. This reduces the need to traverse the entire blockchain for common operations, improving performance as the chain grows.

Messaging Workflow on the Blockchain
When a user sends a message in Zixt, the blockchain ensures secure and verifiable communication:

Transaction Creation: The sender’s client creates a transaction containing the message metadata (e.g., sender pseudonym, recipient pseudonym, timestamp, and message hash). The transaction is signed with the sender’s SPHINCS+ private key.
Broadcast: The transaction is sent to the Zixt node network, where it’s added to a transaction pool.
Block Inclusion: The leader node includes the transaction in the next block, which is signed and broadcast to all nodes.
Verification: Recipient nodes verify the transaction’s signature and the block’s integrity before processing the message.
Off-Chain Storage: The actual message content is stored off-chain (e.g., in a secure database or encrypted file storage) to keep the blockchain lightweight, with the blockchain storing only the hash for verification.

Security and Privacy Features

Immutability: The blockchain’s cryptographic linking (via previous block hashes) ensures that once a transaction is added, it cannot be altered without breaking the chain.
Privacy: User identities are pseudonymous, tied to SPHINCS+ public keys, and message contents are stored off-chain, reducing exposure.
Tamper Resistance: SPHINCS+ signatures and the consensus mechanism prevent unauthorized modifications to the blockchain.
Decentralization: The multi-node setup eliminates a single point of failure, making the system resilient to attacks or server outages.

Integration with Zixt’s Features
The blockchain underpins several key features of Zixt, as outlined in the README we developed:

Secure Login: The blockchain stores user public keys and authentication events, enabling secure, quantum-resistant logins via SPHINCS+.
Message Integrity: Message metadata on the blockchain allows recipients to verify the authenticity and integrity of received messages.
Auditability: All actions (registrations, messages, logins) are logged on the blockchain, providing a transparent audit trail for debugging or compliance.
Scalability: The multi-node setup and caching ensure Zixt can handle growing numbers of users and messages without performance degradation.