Files
72ce8bb3e9 docs: sync why-zap scrub + fix landing cards; unfreeze MDX collections (#2)
- why-zap: same rewrite as zap-proto/dev — gRPC+protobuf replacement
  story, ZAP-only-in-production case (zero gRPC, four-function zap2pb
  boundary), unmeasured tables scrubbed. Links to pages not in this
  site%27s subset (tools, zip, benchmarks, capabilities) point at
  zap-proto.dev.
- index: Next Steps cards pointed at /docs/schema, /docs/codegen,
  /docs/rpc — pages this site does not carry. Now: Quick Start,
  Protocol, Why ZAP, and full docs on zap-proto.dev.
- build: alias MDX collections at the regenerated docs/ instead of
  the frozen .docs/ snapshot (same latent bug as zap-proto/dev —
  new content files would silently never render).

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-07 17:58:45 -07:00

149 lines
5.2 KiB
Plaintext

---
title: Introduction
description: ZAP — Infinitely faster. Zero-copy Application Protocol for the age of AI & crypto.
---
# ZAP
**ZAP** (Zero-copy Application Protocol) is an insanely fast data interchange format and capability-based RPC system built for the age of AI & crypto.
Think JSON, except binary. Think Protocol Buffers, except faster. In fact, in benchmarks, ZAP is **∞ TIMES** faster than Protocol Buffers.
## Why Infinitely Faster?
This benchmark is, of course, unfair. It only measures the time to encode and decode a message in memory. ZAP gets a perfect score because **there is no encoding/decoding step**.
The ZAP encoding is appropriate both as a data interchange format AND an in-memory representation. Once your structure is built, you can simply write the bytes straight out to disk!
## Platform Independent
The encoding is defined byte-for-byte independent of any platform. However, it is designed to be efficiently manipulated on common modern CPUs:
- **Struct-like layout** — fixed widths, fixed offsets, proper alignment
- **Pointer-based** — variable-sized elements embedded as offset pointers
- **Position independent** — pointers are relative, not absolute
- **Little-endian** — most CPUs are little-endian; big-endian CPUs have conversion instructions
## Backwards Compatible
New fields are always added to the end of a struct (or replace padding space), so existing field positions are unchanged. The recipient simply does a bounds check when reading each field.
Fields are numbered in the order they were added, so ZAP always knows how to arrange them for compatibility.
## Smart Compression
Fixed-width integers, unset optional fields, and padding do add zeros on the wire. However, ZAP applies an extremely fast packing scheme to remove them:
- Achieves similar (often better) message sizes than protobuf
- Still faster than protobuf encoding
- For bandwidth-critical paths, apply general compression (zlib, LZ4) on top
## Security
ZAP does NOT just cast a buffer pointer to a struct pointer. That would be dangerous.
ZAP generates classes with accessor methods that validate pointers before following them. Invalid pointers (out-of-bounds, etc.) throw exceptions or return defaults — your choice.
ZAP powers **Hanzo AI**'s distributed inference infrastructure and **Lux Network**'s consensus layer — environments where both security and microsecond-level performance are paramount. ZAP has undergone fuzzing and expert security review.
## Superpowers
### Incremental Reads
Start processing a ZAP message before receiving all of it. Outer objects appear entirely before inner objects.
### Random Access
Read just one field without parsing the whole message. Jump directly to the data you need.
### Memory Mapping
Read large ZAP files via `mmap`. The OS won't even read the parts you don't access.
### Inter-Language Communication
Java, Python, C++, Rust — all operate on the same in-memory structure. No slow serialization between languages.
### Shared Memory IPC
Multiple processes share ZAP messages via shared memory. No kernel pipes. Calling another process is as fast as calling another thread.
### Arena Allocation
All objects allocated in arenas. Faster than protobuf's scattered allocations. Better cache locality.
### Tiny Generated Code
Just inline accessor methods. Order of magnitude smaller than protobuf's parsing/serialization code.
### Tiny Runtime
Simple format = tiny library. Less code to ship, audit, and maintain.
### Time-Travel RPC
ZAP's RPC system implements promise pipelining — call results return to clients **before** requests arrive at the server!
## Quick Example
Define your schema:
<SchemaTabs
zap={`struct Person
name Text
birthdate Date # Field numbers = addition order
email Text # for backwards compatibility
phones List(PhoneNumber)
interface AddressBook
lookup (id UInt64) -> (person Person)
search (query Text) -> stream (person Person)`}
capnp={`@0xa1b2c3d4e5f6a7b8; # file ID required
struct Person {
name @0 :Text;
birthdate @3 :Date; # Field numbers = addition order
email @1 :Text; # for backwards compatibility
phones @2 :List(PhoneNumber);
}
interface AddressBook {
lookup @0 (id :UInt64) -> (person :Person);
search @1 (query :Text) -> stream (person :Person);
}`}
/>
Generate and implement your server (Go):
```go
type addressBookServer struct{}
func (s *addressBookServer) Lookup(ctx context.Context, id uint64) (*Person, error) {
return db.FindPerson(id)
}
func main() {
server := zap.NewServer()
server.Register(&addressBookServer{})
server.ListenAndServe(":9000")
}
```
Use the generated client:
```go
client, _ := zap.Dial("localhost:9000")
defer client.Close()
person, _ := client.AddressBook().Lookup(ctx, 12345)
fmt.Println(person.Name()) // Zero-copy access!
```
## Next Steps
<Cards>
<Card title="Quick Start" href="/docs/quick-start">
Get up and running in 5 minutes
</Card>
<Card title="Protocol" href="/docs/protocol">
The wire format and schema language
</Card>
<Card title="Why ZAP?" href="/docs/why-zap">
What ZAP replaces, and the stack that proves it
</Card>
<Card title="Full Documentation" href="https://zap-proto.dev/docs">
SDKs, protocols, tools, and benchmarks on zap-proto.dev
</Card>
</Cards>