Engineering

Abstracting the Mesh: How we built the EVE SDK

Jul 24, 2026

Abstracting the Mesh: How we built the EVE SDK

Decentralized networks are notoriously difficult to build for. Traditional peer-to-peer programming requires developers to manage peer discovery, state conflict resolution, network partitions, NAT traversal, and complex socket programming. When we set out to build EVE, we knew that if we wanted developers to build on decentralized networks, we had to offer a developer experience that felt just as simple as building on centralized backends like Firebase or Supabase.

Here is how we wrapped complex CRDTs (Conflict-free Replicated Data Types) and cryptographic routing into the EVE SDK.

The Problem with Traditional P2P

In a centralized model, the server is the single source of truth. If two users edit a document simultaneously, the server decides which edit wins. In a decentralized network, there is no central server. Every user's device (or EVE Box node) holds a copy of the state. If multiple nodes make concurrent edits, they must converge to the same state without a coordinator.

"The hardest problem in distributed systems isn't moving data, it's agreeing on what the data means after it's moved."

Normally, this requires writing complex merging logic and resolving synchronization issues manually. This is where CRDTs come in.

Conflict-Free Replicated Data Types

Under the hood, the EVE SDK uses state-based and operation-based CRDTs to represent data structures like maps, sets, and text fields. When you call db.collection('docs').doc('id').update({ text: 'Hello' }) in the EVE SDK, the library does not just send a raw update. It constructs a cryptographically signed delta containing operation metadata and logical timestamps.

These deltas are propagated across the mesh of EVE Box nodes. When a node receives a delta, it applies it using mathematical merge operations that are guaranteed to produce identical states across all nodes, regardless of the order in which the updates arrive.

Cryptographic Routing

Every EVE Box node has a cryptographic public key that acts as its network address. The EVE SDK uses a decentralized hash table (DHT) and cryptographic routing protocols to locate nodes and route requests securely.

  • End-to-End Encryption: Data is encrypted using AES-256-GCM keys derived from user authentication.
  • Zero-Knowledge Relays: EVE Box relays route encrypted blobs; they have no ability to inspect or modify the payloads.
  • Tamper-Proof Enclaves: Keys are generated inside the ARM TrustZone hardware enclave and can never be extracted.

The Firebase-like Experience

To make this accessible, we hid all the complexity behind a clean API:

// Initialize the mesh network interface const db = eve.database();

// Subscribe to a decentralized collection db.collection('messages') .onSnapshot((snapshot) => { console.log('Real-time mesh updates:', snapshot.docs); });

// Push an update to the mesh await db.collection('messages').add({ text: 'Hello from the edge!', timestamp: eve.serverTimestamp() });

With just a few lines of code, developers get fully decentralized, encrypted, real-time collaboration that runs entirely on local hardware nodes without any cloud server dependencies.