Skip to main content
The verify tile performs cryptographic signature verification and deduplication on incoming transactions before they proceed to the dedup and pack tiles.

Overview

The verify tile:
  • Verifies Ed25519 signatures on transactions
  • Performs high-availability (HA) deduplication
  • Validates transaction parsing
  • Filters gossip votes
  • Handles bundle transaction flows
  • Publishes verified transactions to downstream tiles

Input Sources

The verify tile accepts transactions from multiple sources:
Each input source has different processing characteristics and routing rules.

Architecture

Tile Structure

Round-Robin Load Balancing

Multiple verify tiles share load via round-robin:
Transactions are distributed based on:
  • Sequence number for QUIC and gossip packets
  • Tile 0 only for bundles (prevents interleaving)

Transaction Processing Pipeline

1. Before Fragment (Filtering)

The before_frag callback determines if this tile should process the transaction:
Bundle transactions must go through verify:0 to prevent interleaving of bundle streams, which would break atomicity guarantees.

2. During Fragment (Copy)

The during_frag callback copies transaction data:

3. After Fragment (Verify)

The after_frag callback performs the core verification:

Bundle Handling

Bundles require special handling for atomicity:

Bundle State Machine

  • Each bundle has a unique ID
  • Track current bundle ID and failure state
  • If any transaction in bundle fails, mark entire bundle as failed

Bundle Deduplication

Bundle transactions are exempt from normal HA dedup checks. This allows users to send the same transaction both as part of a bundle (with a tip) and via the normal path (without a tip). The one with the tip will be packed. The dedup tile still performs full-bundle dedup to drop identical bundles.

Gossip Vote Handling

Gossip votes have a special code path:
Gossip votes are:
  • Extracted from gossip update messages
  • Marked with FD_TXN_M_TPU_SOURCE_GOSSIP
  • Processed through normal verification pipeline

Signature Verification

SHA-512 Context Pool

Each verify tile maintains SHA-512 contexts for signature verification:
  • Pre-allocated SHA-512 contexts for each possible signature
  • Avoids allocation overhead during verification
  • Maximum of FD_TXN_ACTUAL_SIG_MAX signatures per transaction

Transaction Cache (tcache)

The verify tile uses a transaction cache for deduplication:
The tcache stores recent transaction signatures to detect duplicates.

Memory Management

Input Memory

Each input link has associated memory regions:

Output Memory

Verified transactions are copied to output workspace:

Metrics

The verify tile tracks verification results:

Result Counters

  • V_SUCCESS_IDX - Successfully verified transactions
  • V_PARSE_FAILURE_IDX - Transaction parsing failures
  • V_VERIFY_FAILURE_IDX - Signature verification failures
  • V_DEDUP_FAILURE_IDX - Duplicate transactions detected
  • V_BUNDLE_PEER_FAILURE_IDX - Bundle failed due to peer transaction
  • GOSSIPED_VOTES_RECEIVED - Votes received via gossip

Security

Seccomp Filtering

The verify tile uses seccomp to restrict system calls:

File Descriptor Restrictions

Limited file descriptors allowed:
Only stderr and the log file are accessible.

Initialization

Privileged Init

Generates secure random seed for hashmap:

Unprivileged Init

Sets up data structures:
  • Transaction cache (tcache)
  • SHA-512 contexts
  • Round-robin configuration
  • Input/output memory regions
  • Bundle state tracking

Performance Characteristics

Burst Size

Processes one transaction at a time for:
  • Simpler error handling
  • More predictable latency
  • Easier bundle state tracking

Memory Footprint

Footprint includes:
  • Context structure
  • Transaction cache
  • SHA-512 contexts for signature verification