Infrastructure

Overview

SentiChain is a purpose-built blockchain designed for storing and verifying sentiment analysis data. Unlike general-purpose blockchains, SentiChain is optimized for a specific data model: 768-dimensional embedding vectors derived from social media posts using the MPNet encoder.

The blockchain ensures data integrity through cryptographic signatures at multiple levels: individual transaction signatures, embedding vector signatures, and Merkle tree-based consensus roots that summarize all transactions in a block.

Proof of Verification

SentiChain uses a Proof of Verification (PoV) consensus mechanism specifically designed for sentiment data integrity. Unlike Proof of Work or traditional Proof of Stake, PoV validators are responsible for verifying the cryptographic validity of sentiment data before including it in blocks.

Validation Process

When a transaction is submitted, validators perform the following checks:

1. Schema Validation - Verify all required fields are present and correctly formatted
2. Signature Verification - Validate the RSA signature against the sender's public key
3. Matrix Signature Check - Verify the embedding vector's signature to ensure authenticity
4. Deduplication - Check that the embedding matrix hasn't been submitted before
5. Timestamp Validation - Ensure transaction timestamps are within acceptable bounds

Validator Selection

Validators are selected using a stake-weighted random selection algorithm. Higher-stake validators have proportionally higher chances of being selected to propose the next block, but all validators participate in verification.

# Simplified validator selection
def select_validator(validators, stakes):
    total_stake = sum(stakes.values())
    selection_point = random.uniform(0, total_stake)
    
    cumulative = 0
    for validator in validators:
        cumulative += stakes[validator]
        if cumulative >= selection_point:
            return validator

Merkle Consensus Root

Each block in SentiChain contains a Consensus Root: the root hash of a Merkle tree constructed from all transactions in the block. This enables efficient verification of transaction inclusion without downloading the entire block.

Verification Benefits

• Efficient Proofs - O(log n) proof size for transaction inclusion
• Tamper Detection - Any modification to a transaction invalidates the root
• Light Clients - Clients can verify data with only the consensus root

Block Structure

SentiChain links blocks through hashes and commits to their transactions. Public API reads return a restricted view of a block while preserving the stored chain. This public view is not the complete original signed record.

Block responses use a block wrapper. Read network statistics without a charge; a block query costs 1 credit. The API reference explains authentication and purchase headers.

Transaction Model

Public transaction entries contain complete numeric embedding matrices. Matrix rows remain in order and retain their full values. Source records are excluded for all accounts, including administrators.

Collection and canonical transaction signing remain separate from the public read view. Verification must use the fields and proofs actually returned, rather than assuming the restricted public response contains the complete signed transaction.

Validator Staking

The validator network secures SentiChain through stake-based participation. Validators stake tokens to participate in block proposal and earn rewards for honest verification.

Staking Mechanics

• Minimum Stake - Validators must meet a minimum stake threshold
• Proportional Selection - Higher stakes increase block proposal probability
• Slashing - Malicious behavior results in stake reduction
• Rewards - Validators earn rewards proportional to their stake

Becoming a Validator

To become a validator, you must register with the network, provide a minimum stake, and maintain uptime requirements. Contact us for validator onboarding information.

Storage Layer

SentiChain uses PostgreSQL as its primary storage backend. The database interface is abstracted through a DBInterface class, allowing alternative implementations.

Database Schema

The storage layer maintains the following primary tables:

• blocks - Block headers and metadata
• transactions - Transaction data with foreign key to blocks
• stakes - Validator stake amounts and addresses
• transaction_pool - Pending unconfirmed transactions

Pluggable Architecture

The DBInterface abstraction allows swapping storage backends. To implement a custom backend, extend the interface class and implement all required methods.