# Week6 Update

## TL;DR
1. Test `QuicTransport` using a simple `discard` protocol. The draft [PR](https://github.com/zen-eth/zig-libp2p/pull/30).
2. Investigate the `Illegal instruction at address 0x179cde0` [issue](https://github.com/zen-eth/zig-libp2p/actions/runs/16514919547/job/46703830565#step:8:9).
3. Investigate the handshake could not promoted issue.

## Zig and C compiler difference
`Illegal instruction at address 0x179cde0` [issue](https://github.com/zen-eth/zig-libp2p/actions/runs/16514919547/job/46703830565#step:8:9) mainly stems from compiler differences
### Zig Build Modes

Zig provides **four build modes** with a focus on the "optimization vs safety" tradeoff:

1. **Debug** (default) - Fastest compile times, no optimizations
2. **ReleaseSafe** - Optimized but retains safety checks (overflow, bounds checking)
3. **ReleaseFast** - Maximum performance optimizations, safety checks disabled
4. **ReleaseSmall** - Optimized for binary size

#### Zig Build System Usage:
- With `zig build`: `-Doptimize=ReleaseFast` or `-Doptimize=ReleaseSafe`
- With direct commands: `zig build-exe -OReleaseFast` or `zig run -O ReleaseSafe`

### C Compiler Release Flags

Traditional C compilers use optimization level flags:
- **-O0** - No optimization (debug)
- **-O1** - Basic optimizations
- **-O2** - Standard release optimizations
- **-O3** - Aggressive optimizations
- **-Os** - Optimize for size

### Key Differences

1. **Safety Philosophy**: Zig's `ReleaseSafe` maintains runtime safety checks (overflow detection, bounds checking) even in optimized builds, while C's `-O2/-O3` typically disable such checks entirely.

2. **Default Behavior**: When using Zig as a C compiler (`zig cc`), it enables `-fsanitize=undefined` by default, providing additional safety that standard C compilers don't include.

3. **Granular Control**: Zig offers a more explicit choice between safety and performance with `ReleaseSafe` vs `ReleaseFast`, while C optimization levels primarily focus on performance vs compile time.

4. **Recommended Practice**: Zig recommends using `ReleaseSafe` for production releases to maintain safety guarantees, whereas C developers typically use `-O2` or `-O3` without additional safety measures.

The fundamental difference is that Zig treats release builds as a spectrum between safety and performance, while C treats them primarily as optimization levels.

## ALPN

### libp2p QUIC ALPN Overview

**QUIC in libp2p** uses ALPN (Application Layer Protocol Negotiation) as part of its transport protocol implementation, but with some key differences from traditional TLS-based ALPN usage.

### QUIC Transport in libp2p

#### Implementation Details
- **Version Support**: libp2p's QUIC implementation initially supported draft-ietf-quic-transport-29 (draft-29) and later added support for RFC 9000
- **Dual Version Support**: go-libp2p supports both draft-29 and RFC 9000 QUIC versions
- **Transport Role**: QUIC serves as a fundamental transport mechanism for non-browser libp2p nodes

### ALPN in QUIC Context

#### Protocol Negotiation
- **Built-in Security**: Unlike TCP connections that require separate TLS negotiation, QUIC has built-in encryption and can perform ALPN directly
- **Application Protocol Selection**: ALPN in QUIC allows negotiation of the application-layer protocol during the initial handshake
- **Stream Multiplexing**: QUIC inherently supports stream multiplexing, so ALPN focuses on application protocol selection rather than multiplexer negotiation

#### Key Differences from TLS ALPN
1. **Integrated Approach**: QUIC combines transport, security, and ALPN in a single handshake
2. **No Separate Multiplexer Negotiation**: Since QUIC has native multiplexing, ALPN primarily handles application protocol selection
3. **Reduced Round Trips**: The integrated nature of QUIC further reduces connection establishment time

## Next
Try to fix the blocking issue and make the `QuicTransport` test work.