JAM Protocol: Technical Updates and Network Architecture

Since the release of the initial JAM Protocol Graypaper, significant refinements have been made to the protocol, particularly in its networking layer (JAMNP-S). In this article we do a comprehensive overview of the key architectural changes to provide updates to those who read the paper on its 0.1 version.

Network Protocol Foundation: QUIC and TLS 1.3

The JAM network protocol builds on modern networking foundations:

QUIC Protocol Base

All connections in JAMNP-S are based on QUIC, chosen for its performance and security advantages. This provides a solid foundation for the protocol’s stream-based architecture.

Advanced Security with TLS 1.3

The protocol implements robust security through TLS 1.3 with specific requirements:

• Mandatory peer authentication through X.509 certificates
• Ed25519 signature algorithm requirement
• Certificates must use the peer’s Ed25519 key (which must be published on-chain for validators)
• Specific DNS name format: 53-character name starting with “e” followed by base-32 encoded Ed25519 public key
  • f.g. eanxzefp2q4l6pyhuczm3rw8kjgvt5fdyxqn2c7hs5rakmjzcf7ay

Network Architecture

IPv6-First Design

JAMNP-S makes a forward-looking architectural choice by requiring IPv6 for all validator endpoints. Validator endpoints are specified through IPv6/port combinations, with addressing information stored in the first 18 bytes of validator metadata (16 bytes for IPv6 address, 2 bytes for port in little-endian format).

Validator Connectivity Requirements

The protocol implements a sophisticated connectivity model:

• Validators must maintain connections with all validators from previous, current, and next epochs
• Connection initiation is determined by a deterministic “Preferred Initiator” algorithm based on Ed25519 public keys
• Reserved slots (approximately 20) are maintained for work-package builders
• Epoch transitions include a 2-minute buffer period plus finalization of the first block before applying connectivity changes

Stream-Based Communication

All network communication occurs over QUIC streams, categorized into two types:

1. Unique Persistent (UP) Streams:

   • Single stream per connection
   • Typically long-lived
   • Opened by connection initiator
   • Used for ongoing communication like block announcements

2. Common Ephemeral (CE) Streams:

   • Multiple concurrent streams allowed
   • Short-lived for specific operations
   • Used for queries and data submission
   • Clear protocol for stream closure and error handling

Protocol Features

Block Distribution and State Access

• Efficient block announcement system using a grid structure for validator organization
• State request protocol allowing range-based state queries with size limits
• Work-report distribution system with guaranteed delivery confirmation

Work Package Processing

• Dedicated protocols for work-package submission from builders to guarantors
• Work-package sharing between guarantors on the same core assignment
• Built-in verification steps before package sharing
• Support for bundle distribution and shard management

Availability System

• Sophisticated shard distribution protocol for assurers
• Audit shard request system for auditors
• Segment shard request protocols with optional verification
• Support for both immediate and delayed verification strategies

Consensus and Validation

• Safrole ticket distribution system with proxy-based architecture
• Two-phase ticket distribution process with timing controls
• Comprehensive availability assurance system
• Audit announcement and judgment publication protocols

Protocol Identification

JAMNP-S uses ALPN (Application Layer Protocol Negotiation) for protocol identification:

• Format: jamnp-s/V/H or jamnp-s/V/H/builder
• V: Protocol version (currently 0)
• H: First 8 nibbles of chain’s genesis header hash
• Special builder suffix for work-package builder connections

Message Format Standardization

All stream protocols use a consistent message format:

• Size prefix: 32-bit little-endian unsigned integer
• Content follows size specification
• Clear protocol for message boundaries and stream termination

This refined architecture demonstrates significant evolution from the original Graypaper, with particular attention to network security, efficiency, and scalability. The protocol provides a robust foundation for JAM’s distributed consensus and computation systems.

References:

• Gav’s HackMD (JAMSNP)
• jamchain docs
• zdave-parity’s jamp-np repo
• Graypaper changelog

Comments