Network Consensus Validation

The Consensus Model

Distributed Validation

Why This Works

Deterministic Verification:

• Same transaction → Same verification result
• Every honest node reaches the same conclusion
• No coordination required between nodes
• Mathematical certainty, not voting

Transaction Lifecycle

Phase 1: Submission

Phase 2: Full Verification

Each node performs complete verification.

The core verification logic lives in cryptography/crypto/proof_verify.go in the Verify() function. Each node independently runs through the same sequence:

1. Overflow check -- Reject if fees + extra_value overflows (proof_verify.go:108-110)
2. Parity check -- Verify the secret parity is well-formed (proof_verify.go:136-141)
3. Polynomial recovery -- Verify B^w × A recovery (proof_verify.go:177-179)
4. Challenge hash -- Recompute and compare challenge c from all six sigma proof components (proof_verify.go:410-425)
5. Inner product -- Final cryptographic consistency check (proof_verify.go:457-459)

If any step fails, Verify() returns false and the transaction is rejected.

Phase 3: Propagation

Key Principle: Nodes only propagate transactions they've independently verified as valid.

Phase 4: Block Inclusion

What Gets Verified

Transaction-Level Checks

Block-Level Checks

Byzantine Fault Tolerance

The Byzantine Generals Problem

DERO's solution:

Why Malicious Nodes Can't Win

The math is deterministic:

Transaction TX with proofs P

For every honest node N:
  Verify(TX, P) → Same result

If TX is valid:
  ALL honest nodes accept
  Malicious nodes saying "invalid" are simply ignored

If TX is invalid:
  ALL honest nodes reject
  Malicious nodes cannot force acceptance

Key insight: Nodes don't "vote" on validity. They independently compute the same mathematical result. A malicious node lying about the result is just ignored.

The Verification Timeline

Single Transaction

When a transaction is submitted, it passes through these stages in order:

1. Basic format check -- Structural validation (field counts, size limits, parity)
2. Full proof verification -- All sigma proofs and inner product proof verified mathematically
3. Mempool admission -- If valid, added to the node's mempool
4. Peer propagation -- Forwarded to connected peers, who independently verify

Note: No official benchmarks exist for per-step verification times. Actual performance depends on hardware, network conditions, and ring size. The codebase does not include benchmark tests for proof verification.

Block Confirmation

Block time: 18 seconds (from config/config.go)

Time 0:      TX in mempool
Time 18s:    Included in block
Time 36s:    1 confirmation
Time 54s:    2 confirmations
Time ~5 min: ~17 confirmations (very secure)

Source verification:

// config/config.go:34
const BLOCK_TIME = uint64(18)
const BLOCK_TIME_MILLISECS = BLOCK_TIME * 1000

Network Topology

P2P Architecture

Properties:

• No central coordinator
• Multiple paths between nodes
• Failure of one node doesn't affect others
• Geographic distribution

TLS Encryption

All node communication is encrypted:

// From p2p/controller.go
 
// Outgoing connections wrap in TLS
conntls := tls.Client(conn, &tls.Config{InsecureSkipVerify: true})
 
// Server generates random TLS certificate
tlsconfig := &tls.Config{Certificates: []tls.Certificate{generate_random_tls_cert()}}

Benefits:

• Prevents eavesdropping on transaction data
• Encrypts all peer-to-peer traffic

Honest limitations:

• Uses InsecureSkipVerify: true -- peers are not authenticated via certificate validation
• TLS provides transport encryption, not peer identity verification
• Peer identity is established through the DERO handshake protocol, not TLS certificates

Finality

When is a Transaction "Final"?

Block Reorganization

Reorg protection: Deeper transactions are safer because reorganizing the chain becomes exponentially harder.

Security Guarantees

What Consensus Provides

What It Doesn't Provide

Key Takeaways

The Consensus Guarantee

Valid transaction + Network propagation = Guaranteed acceptance

Because:
  1. All honest nodes compute same result
  2. Honest nodes only propagate valid TXs
  3. Invalid TXs die at first node they reach
  4. Majority honest nodes = valid state

Defense in Depth

Multiple layers:

• Wallet creates valid proofs (or TX can't be created)
• Each node verifies (or TX is dropped)
• Miners include only valid TXs (or block is rejected)
• Network verifies blocks (or block is orphaned)

Related Pages

Security Suite:

• Transaction Proofs - What nodes verify
• Proof Verification Flow - Detailed verification steps

Technical Reference:

• Running a Node - Participate in consensus
• Daemon RPC API - Submit transactions