Consensus & Validator System

Registration: 0x1a2b...3c4d → IK_Alice (Ed25519 public key)

Without consensus:
- Node A sees: 0x1a2b...3c4d → IK_Alice
- Node B sees: 0x1a2b...3c4d → IK_Mallory (attacker)
- Different users get different "Alice" keys → MITM possible

With consensus:
- All nodes agree: 0x1a2b...3c4d → IK_Alice
- Mallory's conflicting registration is rejected
- Single source of truth prevents identity confusion

Alice publishes OPK_1, OPK_2, OPK_3...

Without consensus:
- Bob fetches OPK_1, sends message to Alice
- Carol also fetches OPK_1 (race condition)
- Both messages encrypted with same ephemeral secret
- Forward secrecy violated

With consensus:
- OPK_1 marked as "consumed" in atomic transaction
- Carol's request returns OPK_2 instead
- Each conversation gets unique ephemeral key material

ValidatorRegistration {
    operator_address: 0x...,
    consensus_pubkey: Ed25519PublicKey,
    stake_amount: 100000 CHAIN,
    commission_rate: 5%,        // Portion of delegator rewards
    metadata: {
        name: "MyValidator",
        website: "https://...",
        contact: "security@..."
    }
}

Base yield: ~8% APY on staked amount
With delegations: +commission on delegator rewards
With uptime bonus: +10% on base rewards

Example (100,000 CHAIN stake, 500,000 CHAIN delegated):
- Base rewards: 8,000 CHAIN/year
- Commission (5% of delegator yield): 2,000 CHAIN/year
- Uptime bonus: 800 CHAIN/year
- Total: ~10,800 CHAIN/year (~10.8% effective APY)

Validator voting power = Own stake + Delegated stake

Example:
- Validator A: 100,000 (own) + 400,000 (delegated) = 500,000 voting power
- Validator B: 100,000 (own) + 200,000 (delegated) = 300,000 voting power
- Validator A has 62.5% voting power in consensus

1. VRF Selection:
   vrf_output = VRF(slot_number, validator_private_key)

2. Leader Determination:
   leader = validator with lowest vrf_output
   (weighted by stake - higher stake = more winning VRF values)

3. Block Proposal:
   Block {
       slot: 12345,
       parent_hash: 0x...,
       state_root: 0x...,
       transactions: [...],
       proposer_signature: Ed25519Signature
   }

Phase 1: PRE-PREPARE (Leader → All)
┌─────────────────────────────────────────────────┐
│ Leader broadcasts proposed block                │
│ Validators verify: valid transactions,          │
│ correct state transitions, proper signature     │
└─────────────────────────────────────────────────┘
                      ↓
Phase 2: PREPARE (All → All)
┌─────────────────────────────────────────────────┐
│ Each validator broadcasts PREPARE vote          │
│ Wait for 2f+1 PREPARE messages                  │
│ (f = max Byzantine validators tolerated)        │
└─────────────────────────────────────────────────┘
                      ↓
Phase 3: COMMIT (All → All)
┌─────────────────────────────────────────────────┐
│ Each validator broadcasts COMMIT vote           │
│ Wait for 2f+1 COMMIT messages                   │
│ Block is finalized - no reversion possible      │
└─────────────────────────────────────────────────┘

IdentityRegistry {
    // Primary mapping: address → identity
    identities: Map<Address, Identity>,

    // Reverse lookup: identity_key → address
    key_to_address: Map<Ed25519PublicKey, Address>,

    // Prekey tracking
    prekeys: Map<Address, PrekeyBundle>,
    consumed_otpks: Set<X25519PublicKey>
}

Identity {
    owner: Address,
    identity_key: Ed25519PublicKey,
    kyber_public_key: KyberPublicKey,  // Post-quantum
    registration_slot: u64,
    last_rotation: u64
}

IdentityRegistrationTx {
    // Transaction metadata
    tx_type: IDENTITY_REGISTER,
    sender: Address,
    nonce: u64,
    fee: u64,

    // Identity data
    identity_key: Ed25519PublicKey,
    kyber_public_key: KyberPublicKey,

    // Proof of ownership
    signature: Ed25519Signature,  // Signs (sender || identity_key || nonce)

    // Optional: initial prekey bundle
    initial_prekeys: Option<PrekeyBundle>
}

1. Signature Verification:
   verify(signature, sender || identity_key || nonce, identity_key)

2. Uniqueness Check:
   assert(identities[sender] == null)  // Address not registered
   assert(key_to_address[identity_key] == null)  // Key not in use

3. Fee Verification:
   assert(balance[sender] >= fee)
   assert(fee >= MIN_REGISTRATION_FEE)

4. State Update:
   identities[sender] = Identity { ... }
   key_to_address[identity_key] = sender
   balance[sender] -= fee

IdentityRotationTx {
    tx_type: IDENTITY_ROTATE,
    sender: Address,
    nonce: u64,
    fee: u64,

    new_identity_key: Ed25519PublicKey,
    new_kyber_key: KyberPublicKey,

    // Must be signed by CURRENT identity key
    old_key_signature: Ed25519Signature,
    // Must be signed by NEW identity key (proves ownership)
    new_key_signature: Ed25519Signature,

    rotation_reason: enum { SCHEDULED, COMPROMISE, DEVICE_CHANGE }
}

1. Verify old_key_signature with current identity_key
2. Verify new_key_signature with new_identity_key
3. Check new key not already registered
4. Update identity registry
5. Broadcast key change notification to contacts

n = 3f + 1

Where:
- n = total validators
- f = maximum Byzantine validators tolerated

With n=100:
- f = 33 Byzantine validators tolerated
- 67 honest validators required for progress
- 34 honest validators required for safety

Scenario: 40 validators go offline (network has 60 remaining)

1. Detection:
   - Missed block proposals trigger timeout
   - View change protocol activates

2. Leader Rotation:
   - Skip offline leader
   - Next online validator proposes

3. Continued Operation:
   - 60 validators > 67 required for 2f+1
   - Network continues if 67+ remain online

4. Offline Validator Handling:
   - Accumulate downtime penalties
   - After 24 hours: ejected from active set
   - Must re-register and wait for next epoch

To run multiple validators, attacker must:

1. Stake 100,000 CHAIN per validator
2. Operate separate infrastructure (detected if shared)
3. Risk all stake on detection

Attack: Create 34 fake validators to break safety
Cost: 3,400,000 CHAIN stake
Risk: If detected, lose all 3,400,000 CHAIN
Detection: Infrastructure correlation, voting pattern analysis

Creating spam identities requires:
- 1 CHAIN per identity (registration fee)
- Unique wallet address per identity
- Gas fees for transactions

Attack: Create 1 million spam accounts
Cost: 1,000,000 CHAIN + gas fees
Mitigation: Rate limiting per IP, captcha for web registrations

Security budget = Total stake × Slashing risk

With 100 validators at 100,000 CHAIN each:
- Total stake: 10,000,000 CHAIN
- Attack cost: Acquire 34% = 3,400,000 CHAIN
- If attack detected: Lose 3,400,000 CHAIN
- Net attacker loss: 3,400,000 CHAIN (+ opportunity cost)

Rational attacker analysis:
- Expected profit from attack: P
- Cost of attack: 3,400,000 CHAIN
- Probability of detection: ~95%+
- Expected value: P - (0.95 × 3,400,000)

Attack only rational if P > 3,230,000 CHAIN

Monthly Economics (Example):

Revenue:
- Messages relayed: 10,000,000
- Average size: 2 KB
- Routing bounty: 10,000 CHAIN
- Bandwidth fees: 2,000 CHAIN
- Storage fees: 500 CHAIN
- Uptime bonus: 2,500 CHAIN
Total revenue: ~15,000 CHAIN/month

Costs:
- Server (8 core, 32GB): $200/month
- Bandwidth (10TB): $100/month
- Stake opportunity cost: ~$400/month
Total costs: ~$700/month

Net profit: 15,000 CHAIN - $700 ≈ $74,300/month
(Assuming CHAIN = $5, highly dependent on network usage)

Relay nodes commit to bandwidth tiers:

Tier 1 (Starter):
- Commitment: 100 Mbps
- Stake: 10,000 CHAIN
- Max reward multiplier: 1x

Tier 2 (Standard):
- Commitment: 500 Mbps
- Stake: 25,000 CHAIN
- Max reward multiplier: 2x

Tier 3 (Premium):
- Commitment: 1 Gbps
- Stake: 50,000 CHAIN
- Max reward multiplier: 3x

Under-delivery penalty:
- Actual < 80% committed: Warning
- Actual < 50% committed: 1% stake slash
- Actual < 25% committed: 5% stake slash + tier downgrade

1. Initiate Withdrawal:
   UnstakeTx { amount: 50000 CHAIN, type: PARTIAL }

2. Unbonding Period (7 days):
   - Stake still slashable
   - No longer earning rewards
   - Cannot re-stake

3. Completion:
   - After 7 days: funds available
   - If slashed during unbonding: reduced amount

4. Claim:
   ClaimTx { unbond_id: 123 }
   - Transfer to wallet