Skip to main content

​
ForkNode-VEST Protocol System Requirements Specification

:::info Executive Summary ForkNode-VEST is the ultimate synthesis protocol combining:
  • ForkNode: Homomorphic CRDTs enabling server-side conflict resolution without decryption
  • VEST: Cryptographic audit trails with tamper-evident operation chains
The Promise: “Your documents are encrypted end-to-end. We can’t read them. Yet we can merge your edits in real-time AND provide court-admissible proof of every change.” Strategic Position: ForkNode-VEST positions Materi as the only platform achieving the “impossible trinity” of real-time collaboration: Privacy + Performance + Proof Comparison to AEGIS:
  • AEGIS: Zero-knowledge access control (who accessed what, when) - SERVER NEVER SEES CONTENT
  • ForkNode-VEST: Homomorphic editing (collaborative document editing) - SERVER MERGES WITHOUT SEEING CONTENT
  • Use Together: AEGIS for access control, ForkNode-VEST for document operations = COMPLETE SOLUTION :::
:::note sdd
CategoryDetailsNotes
ClassificationL3-TechnicalAdvanced protocol architecture
AuthorityProtocol Architecture Team + Security Engineering + CTOStrategic protocol
ImpactStrategicMarket leadership, ultimate security positioning
TargetsPrivacy: E2E encryption maintained<br/>Performance: <50ms P95 collaborative editing<br/>Proof: Cryptographic audit trail<br/>Scalability: 100K+ ops/secExcellence targets
DependenciesVEST Protocol, ForkNode Protocol, Relay, Shield, Redis, FolioProtocol synthesis
ImplementsHomomorphic CRDTs, verifiable audit, E2E collaborationCore capabilities
Verification MethodCryptographic verification, performance benchmarking, collaborative testingProtocol validation
Approval GatesSecurity review, Performance validation, Cryptography auditProtocol approval
:::

​
1. The ForkNode-VEST Vision: Solving the “Impossible Trinity”

​
1.1 The Collaboration Trilemma

Traditional Belief: “You can have any two, but not all three” Why This Seemed Impossible:
  1. Privacy requires encryption → Server can’t see content
  2. Real-time collaboration requires server to merge edits → Server must see content
  3. Audit trails require server to log operations → Server must see what was done
These requirements appear contradictory. ForkNode-VEST breaks this trilemma. Rationale: No existing system achieves all three properties simultaneously. ForkNode-VEST’s ability to do so creates an unassailable competitive moat. [REQ-CS-001]

​
1.2 How ForkNode-VEST Achieves the Impossible

The Two-Layer Architecture: Key Innovation #1: Homomorphic CRDT Operations 
/// ForkNode: Operations that can be merged while encrypted
pub struct HomomorphicOperation {
    /// Encrypted operation payload
    encrypted_payload: EncryptedPayload,

    /// Homomorphic metadata (mergeable without decryption)
    causal_metadata: CausalMetadata,

    /// Operation type (visible, but content encrypted)
    operation_type: OperationType,  // INSERT, DELETE, etc.

    /// Position information (encrypted but comparable)
    position: EncryptedPosition,
}

impl HomomorphicOperation {
    /// Server merges two concurrent operations WITHOUT decrypting
    pub fn merge_encrypted(
        op1: &HomomorphicOperation,
        op2: &HomomorphicOperation
    ) -> Vec<HomomorphicOperation> {
        // Compare causal metadata (not encrypted)
        if op1.happens_before(op2) {
            return vec![op1.clone(), op2.clone()];
        }

        // Resolve conflict using CRDT rules on ENCRYPTED data
        match (op1.operation_type, op2.operation_type) {
            (OperationType::Insert, OperationType::Insert) => {
                // Both inserting - use encrypted position comparison
                if op1.position.encrypted_lt(&op2.position) {
                    vec![op1.clone(), op2.clone()]
                } else {
                    vec![op2.clone(), op1.clone()]
                }
            },
            (OperationType::Delete, OperationType::Insert) => {
                // Delete wins (CRDT rule)
                vec![op1.clone()]
            },
            // ... other CRDT merge rules
        }
    }
}

/// Key technique: Position comparisons work on encrypted values
pub struct EncryptedPosition {
    /// Order-preserving encryption (OPE)
    /// Allows comparison without decryption
    ope_encrypted_index: u64,

    /// Fully encrypted exact position
    fully_encrypted_position: EncryptedData,
}

impl EncryptedPosition {
    /// Compare positions without decrypting
    pub fn encrypted_lt(&self, other: &EncryptedPosition) -> bool {
        // Order-preserving encryption enables comparison
        self.ope_encrypted_index < other.ope_encrypted_index
    }
}
Key Innovation #2: VEST Chain Over Encrypted Operations 
/// VEST: Cryptographic audit of encrypted operations
pub struct ForkNodeVESTOperation {
    // ForkNode component
    homomorphic_operation: HomomorphicOperation,

    // VEST component
    operation_id: Hash,
    parent_hashes: Vec<Hash>,
    user_signature: Signature,
    server_signature: Option<Signature>,
    timestamp_proof: RoughtimeProof,
    merkle_proof: Option<MerkleProof>,
}

impl ForkNodeVESTOperation {
    /// Create auditable encrypted operation
    pub fn create(
        document_id: DocumentId,
        user_private_key: &PrivateKey,
        document_key: &DocumentKey,  // For encryption
        operation_content: &OperationContent,
        parent_ops: &[Hash]
    ) -> Result<Self, ForkNodeVESTError> {
        // ForkNode: Encrypt operation content
        let encrypted_payload = document_key.encrypt(operation_content);

        // ForkNode: Create homomorphic operation
        let homomorphic_op = HomomorphicOperation {
            encrypted_payload,
            causal_metadata: CausalMetadata::from_parents(parent_ops),
            operation_type: operation_content.operation_type,
            position: EncryptedPosition::new(
                operation_content.position,
                document_key
            ),
        };

        // VEST: Create operation ID (includes encrypted content)
        let operation_id = Hash::blake3(&homomorphic_op);

        // VEST: Sign operation
        let user_signature = user_private_key.sign(&operation_id);

        // VEST: Get timestamp proof
        let timestamp_proof = RoughtimeClient::get_proof().await?;

        Ok(Self {
            homomorphic_operation: homomorphic_op,
            operation_id,
            parent_hashes: parent_ops.to_vec(),
            user_signature,
            server_signature: None,
            timestamp_proof,
            merkle_proof: None,
        })
    }

    /// Server merges AND witnesses without decrypting
    pub async fn server_merge_and_witness(
        relay: &Relay,
        ops: Vec<ForkNodeVESTOperation>
    ) -> Result<Vec<ForkNodeVESTOperation>, ForkNodeVESTError> {
        // ForkNode: Merge encrypted operations
        let mut merged_ops = Vec::new();
        for op in ops {
            // Verify VEST properties first
            op.verify_VEST_properties()?;

            // Merge with existing operations (homomorphically)
            let merged = relay.merge_homomorphic(&op).await?;

            // VEST: Add server witness
            let witnessed = relay.witness_operation(merged).await?;

            merged_ops.push(witnessed);
        }

        Ok(merged_ops)
    }
}
What This Achieves: The Magic:
  1. Server merges conflicts (using homomorphic CRDT rules on encrypted data)
  2. Server never sees content (operations stay encrypted end-to-end)
  3. Server creates audit trail (VEST chain records all operations)
  4. Auditors verify integrity (VEST proofs validate without content access)
This was considered impossible before ForkNode-VEST. Rationale: Homomorphic CRDTs enable the first true end-to-end encrypted collaborative editing system with server-side conflict resolution and cryptographic audit trails. [REQ-CS-002]

​
1.3 Market Positioning: Beyond AEGIS

ForkNode-VEST vs AEGIS - When to Use Each: Customer Scenarios:
ScenarioAEGISForkNode-VESTResult
Law firm contract negotiation✅ Proves who read contract✅ Encrypts collaborative editingComplete solution
Healthcare patient records✅ HIPAA access logs✅ E2E encrypted medical notesHIPAA compliant E2E
Intelligence classified docs✅ Zero-knowledge access✅ Encrypted collaborationTS/SCI compliant
Financial audit documents✅ SOX audit trails✅ Encrypted financial dataFull compliance
Pricing Strategy:
TierFeaturesPrice/User/MonthTarget
BasicNeither$15SMB
ProfessionalVEST only$45Mid-market
EnterpriseVEST + AEGIS$150Large orgs
Maximum SecurityVEST + AEGIS + ForkNode$500Gov/IC/Legal/Healthcare
Total Addressable Market (TAM):
  • Maximum Security Tier: 100K potential users globally
  • Average price: $500/user/month
  • TAM: $600M ARR from premium tier alone
Rationale: ForkNode-VEST + AEGIS together create a complete security solution that justifies enterprise premium pricing and captures the highest-value market segment. [REQ-CS-003]

​
2. Functional Requirements

​
2.1 Homomorphic CRDT Operations

​
FR-CS-001: Order-Preserving Encryption for Positions

Requirement: ForkNode-VEST SHALL use order-preserving encryption for document positions, enabling server-side comparison and merging without decryption. Specification: 
/// Order-preserving encryption for positions
pub struct OPEPosition {
    /// OPE-encrypted index (comparable without decryption)
    ope_value: u64,

    /// Fully encrypted exact position (for client decryption)
    exact_position: EncryptedData,

    /// Encryption parameters
    ope_params: OPEParameters,
}

impl OPEPosition {
    /// Encrypt position using OPE
    pub fn encrypt(
        position: usize,
        document_key: &DocumentKey
    ) -> Result<Self, ForkNodeError> {
        // Generate OPE parameters from document key
        let ope_params = OPEParameters::derive_from(document_key);

        // OPE encryption (preserves order)
        let ope_value = ope_params.encrypt(position as u64)?;

        // Full encryption (for exact recovery)
        let exact_position = document_key.encrypt(&position.to_le_bytes());

        Ok(Self {
            ope_value,
            exact_position,
            ope_params,
        })
    }

    /// Decrypt to exact position (client only)
    pub fn decrypt(
        &self,
        document_key: &DocumentKey
    ) -> Result<usize, ForkNodeError> {
        let bytes = document_key.decrypt(&self.exact_position)?;
        let position = usize::from_le_bytes(bytes.try_into()?);
        Ok(position)
    }

    /// Compare positions WITHOUT decrypting (server can do this)
    pub fn compare_encrypted(&self, other: &OPEPosition) -> Ordering {
        self.ope_value.cmp(&other.ope_value)
    }
}

/// Server-side conflict resolution using OPE
pub fn resolve_insert_conflict_encrypted(
    op1: &ForkNodeVESTOperation,
    op2: &ForkNodeVESTOperation
) -> Ordering {
    // Server compares encrypted positions directly
    let pos1 = &op1.homomorphic_operation.position;
    let pos2 = &op2.homomorphic_operation.position;

    // OPE enables comparison without decryption!
    pos1.compare_encrypted(pos2)
}
OPE Security Considerations: What OPE Reveals to Server:
  • ✅ Relative ordering of positions (position A < position B)
  • ❌ Exact position values (is it character 42 or 43? Unknown)
  • ❌ Document content (what’s at that position? Unknown)
  • ❌ User identity (who made the edit? Hidden by VEST witnessing)
What OPE Enables:
  • ✅ Server can determine which edit comes first
  • ✅ Server can merge concurrent inserts at different positions
  • ✅ Server can apply CRDT rules without seeing content
Rationale: OPE provides the minimum information leakage necessary to enable server-side conflict resolution while maintaining end-to-end encryption of document content. [REQ-CS-FR-001] Verification: OPE tests SHALL verify correct ordering is preserved and exact values cannot be recovered without the document key. [TEST-CS-FR-001]

​
FR-CS-002: Homomorphic CRDT Merge Rules

Requirement: ForkNode-VEST SHALL implement CRDT merge rules that operate on encrypted operations, enabling server-side conflict resolution without decryption. Specification: 
/// CRDT merge rules for encrypted operations
pub struct HomomorphicCRDT {
    /// Operation type determines merge behavior
    merge_strategy: MergeStrategy,
}

impl HomomorphicCRDT {
    /// Merge two encrypted operations
    pub fn merge_encrypted(
        &self,
        op1: &ForkNodeVESTOperation,
        op2: &ForkNodeVESTOperation
    ) -> MergeResult {
        // Determine causal relationship (from VEST metadata)
        match (op1.happens_before(op2), op2.happens_before(op1)) {
            (true, false) => {
                // op1 → op2 (sequential)
                MergeResult::Sequential(vec![op1.clone(), op2.clone()])
            },
            (false, true) => {
                // op2 → op1 (sequential)
                MergeResult::Sequential(vec![op2.clone(), op1.clone()])
            },
            (false, false) => {
                // Concurrent operations - apply CRDT rules
                self.resolve_concurrent_encrypted(op1, op2)
            },
            (true, true) => {
                // Cycle in causality (should never happen)
                MergeResult::Error(CRDTError::CausalCycle)
            }
        }
    }

    /// Resolve concurrent operations using encrypted data
    fn resolve_concurrent_encrypted(
        &self,
        op1: &ForkNodeVESTOperation,
        op2: &ForkNodeVESTOperation
    ) -> MergeResult {
        use OperationType::*;

        match (op1.homomorphic_operation.operation_type,
               op2.homomorphic_operation.operation_type) {

            // Both inserting
            (Insert, Insert) => {
                // Compare encrypted positions (OPE enables this)
                match op1.position().compare_encrypted(op2.position()) {
                    Ordering::Less => {
                        MergeResult::Concurrent(vec![op1.clone(), op2.clone()])
                    },
                    Ordering::Greater => {
                        MergeResult::Concurrent(vec![op2.clone(), op1.clone()])
                    },
                    Ordering::Equal => {
                        // Same position - use tie-breaker (user ID hash)
                        if op1.user_id_hash() < op2.user_id_hash() {
                            MergeResult::Concurrent(vec![op1.clone(), op2.clone()])
                        } else {
                            MergeResult::Concurrent(vec![op2.clone(), op1.clone()])
                        }
                    }
                }
            },

            // Insert vs Delete
            (Insert, Delete) | (Delete, Insert) => {
                // Delete wins (standard CRDT rule)
                let delete_op = if matches!(op1.operation_type(), Delete) {
                    op1
                } else {
                    op2
                };
                MergeResult::Concurrent(vec![delete_op.clone()])
            },

            // Both deleting same position
            (Delete, Delete) => {
                // Both deletes succeed (idempotent)
                MergeResult::Concurrent(vec![op1.clone()])
            },

            // Format changes
            (Format, Format) => {
                // Last writer wins (based on Lamport clock)
                if op1.lamport_clock > op2.lamport_clock {
                    MergeResult::Concurrent(vec![op1.clone()])
                } else {
                    MergeResult::Concurrent(vec![op2.clone()])
                }
            },

            // Mixed operation types
            _ => {
                // Apply in order determined by Lamport clocks
                if op1.lamport_clock < op2.lamport_clock {
                    MergeResult::Concurrent(vec![op1.clone(), op2.clone()])
                } else {
                    MergeResult::Concurrent(vec![op2.clone(), op1.clone()])
                }
            }
        }
    }
}
CRDT Merge Example: Rationale: Homomorphic CRDT rules enable deterministic conflict resolution on encrypted data, ensuring all clients converge to the same state without the server seeing plaintext. [REQ-CS-FR-002] Verification: CRDT merge tests SHALL verify convergence of encrypted operations and that server-side merges produce correct results when decrypted. [TEST-CS-FR-002]

​
2.2 VEST Integration

​
FR-CS-010: Dual-Layer Operation Structure

Requirement: Every ForkNode-VEST operation SHALL contain both ForkNode (encrypted CRDT) and VEST (audit chain) components in a unified structure. Specification: 
/// Complete ForkNode-VEST operation
#[derive(Clone, Serialize, Deserialize)]
pub struct ForkNodeVESTOperation {
    // ===== ForkNode LAYER =====
    /// Encrypted operation content
    pub encrypted_content: EncryptedOperationContent,

    /// Homomorphic metadata for server-side merging
    pub homomorphic_metadata: HomomorphicMetadata,

    /// Document key fingerprint (not the key itself)
    pub document_key_fingerprint: KeyFingerprint,

    // ===== VEST LAYER =====
    /// Unique operation identifier
    pub operation_id: Hash,

    /// Parent operation(s) in causal chain
    pub parent_hashes: Vec<Hash>,

    /// Lamport logical clock
    pub lamport_clock: u64,

    /// User's digital signature
    pub user_signature: Signature,

    /// Server's witnessing signature
    pub server_signature: Option<Signature>,

    /// Distributed timestamp proof
    pub timestamp_proof: RoughtimeProof,

    /// Merkle tree inclusion proof
    pub merkle_proof: Option<MerkleProof>,

    // ===== METADATA =====
    /// Operation metadata
    pub metadata: OperationMetadata,
}

impl ForkNodeVESTOperation {
    /// Verify ForkNode properties (encryption integrity)
    pub fn verify_ForkNode_properties(&self) -> Result<(), ForkNodeError> {
        // Verify encrypted content is well-formed
        self.encrypted_content.verify_structure()?;

        // Verify homomorphic metadata consistency
        self.homomorphic_metadata.verify_consistency(
            &self.encrypted_content
        )?;

        // Verify document key fingerprint matches
        if !self.document_key_fingerprint.matches(&self.encrypted_content)? {
            return Err(ForkNodeError::KeyMismatch);
        }

        Ok(())
    }

    /// Verify VEST properties (audit integrity)
    pub fn verify_VEST_properties(&self) -> Result<(), VESTError> {
        // Verify operation ID is correct hash
        if self.operation_id != self.compute_operation_hash() {
            return Err(VESTError::HashMismatch);
        }

        // Verify user signature
        self.user_signature.verify()?;

        // Verify server signature if present
        if let Some(ref sig) = self.server_signature {
            sig.verify()?;
        }

        // Verify timestamp proof
        self.timestamp_proof.verify()?;

        // Verify Merkle proof if present
        if let Some(ref proof) = self.merkle_proof {
            proof.verify()?;
        }

        Ok(())
    }

    /// Verify BOTH ForkNode and VEST properties
    pub fn verify_complete(&self) -> Result<(), ForkNodeVESTError> {
        self.verify_ForkNode_properties()?;
        self.verify_VEST_properties()?;
        Ok(())
    }
}
Layered Verification: Rationale: Unified operation structure ensures ForkNode and VEST properties are jointly verified, providing both privacy and auditability guarantees simultaneously. [REQ-CS-FR-010] Verification: Dual-layer verification tests SHALL confirm that both ForkNode and VEST properties are independently and jointly verifiable. [TEST-CS-FR-010]

​
3. Non-Functional Requirements

​
3.1 Performance Requirements

​
NFR-CS-001: End-to-End Latency

Requirement: ForkNode-VEST SHALL maintain P95 end-to-end latency below 60ms for collaborative editing operations. Latency Budget: Component Latency:
StageP50P95P99Optimization
Client encrypt2ms3ms6msAES-NI hardware acceleration
Client sign1ms2ms4msEd25519 optimized
Network upload5ms8ms20msGeographic CDN distribution
Server verify (VEST)3ms5ms10msBatched verification
Server merge (ForkNode)2ms4ms8msOPE comparison (fast)
Server witness2ms3ms6msAsync timestamp service
Redis persist2ms3ms8msPipelined writes
Network download5ms8ms20msPush via WebSocket
TOTAL22ms36ms82msTarget: <60ms P95
Performance Optimization: 
/// High-performance ForkNode-VEST pipeline
pub struct ForkNodeVESTPipeline {
    /// Hardware-accelerated encryption
    ForkNode_engine: AESNIEngine,

    /// Batched signature verification
    signature_verifier: BatchVerifier,

    /// Parallel OPE comparisons
    ope_comparator: ParallelComparator,

    /// Async timestamp service (non-blocking)
    timestamp_service: AsyncTimestampService,
}

impl ForkNodeVESTPipeline {
    /// Process operation with optimal parallelization
    pub async fn process_operation(
        &self,
        operation: ForkNodeVESTOperation
    ) -> Result<ForkNodeVESTOperation, ForkNodeVESTError> {
        // Verify ForkNode and VEST in parallel
        let (ForkNode_result, VEST_result) = tokio::join!(
            tokio::spawn(async move {
                operation.verify_ForkNode_properties()
            }),
            tokio::spawn(async move {
                operation.verify_VEST_properties()
            })
        );

        ForkNode_result??;
        VEST_result??;

        // Merge operation (uses OPE - fast)
        let merged = self.merge_with_existing(&operation).await?;

        // Witness operation (async timestamp)
        let witnessed = self.witness_operation(merged).await?;

        Ok(witnessed)
    }
}
Rationale: 60ms P95 latency provides acceptable real-time collaboration experience while accommodating the additional overhead of encryption and cryptographic verification. [REQ-CS-NFR-001] Verification: Performance tests SHALL measure end-to-end latency under production load and verify P95 < 60ms with 1000 concurrent editors. [TEST-CS-NFR-001]

​
4. Implementation Roadmap

​
4.1 Phased Development

​
4.2 Resource Requirements

Team Composition:
RoleSkillsFTEDurationCost
Protocol ArchitectCryptography, distributed systems1.018 months$315K
Senior Backend EngineersRust, encryption, CRDTs3.018 months$945K
Cryptography SpecialistOPE, homomorphic systems1.012 months$240K
Security EngineersProtocol security, auditing2.018 months$630K
Frontend EngineersTypeScript, WASM, encryption2.012 months$420K
DevOps EngineersKubernetes, performance1.012 months$210K
QA EngineersSecurity testing, performance2.012 months$360K
Technical WriterProtocol documentation0.59 months$60K
Total Team: 12.5 FTE
Engineering Cost: $3.18M Additional Costs:
CategoryCostNotes
Security Audits$300KMultiple audits (NCC Group, Trail of Bits, academic review)
Infrastructure$100KTesting environments, performance benchmarking
Third-Party Services$50KRoughtime, code signing, compliance consulting
Contingency (25%)$912KHigh-risk cryptographic protocol development
TOTAL BUDGET$4.54M~$4.5M total investment

​
4.3 Risk-Adjusted ROI

Investment: $4.5M over 18 months Revenue Potential:
YearCustomer SegmentUsersARPU/monthARRNotes
Y1Beta customers500$500$3.0MEarly adopters, discounted
Y2Enterprise5,000$500$30MFull launch, market validation
Y3Scale20,000$400$96MGeographic expansion
Y4Mature50,000$350$210MMarket leader position
Break-even: Month 20 (8 months post-launch)
ROI by Year 3: 21x (4.5Minvestment→4.5M investment → 96M ARR) Competitive Moat Value:
  • Patent portfolio: 5-10 patents on novel homomorphic CRDT techniques
  • Technical lead: 3-5 years before competitors can replicate
  • Market position: First-mover in E2E encrypted real-time collaboration
  • Acquisition value: $500M-1B valuation based on unique technology

​
5. Why ForkNode-VEST is the Ultimate Protocol

​
5.1 Comparison Matrix

Feature Completeness:
CapabilityGoogle DocsVESTForkNodeAEGISForkNode-VEST
Real-time Collaboration✅✅⚠️✅✅
E2E Encryption❌❌✅✅✅
Server-side Merge✅✅❌⚠️✅
Cryptographic Audit❌✅❌✅✅
Zero-Knowledge Access❌❌❌✅⚠️
Tamper-Evident Chain❌✅❌✅✅
Court-Admissible Proofs❌✅❌✅✅
Performance <50ms✅✅❌✅⚠️
The Verdict:
  • VEST alone: Great audit, but no privacy
  • ForkNode alone: Great privacy, but slow and limited audit
  • AEGIS: Perfect for access control, but not content editing
  • ForkNode-VEST: Combines the best of all worlds

​
5.2 Strategic Recommendation

Build Priority:
  1. Phase 1: VEST (6 months, $1.3M)
    • Get to market fast with audit trails
    • Validate demand for cryptographic verification
    • Generate revenue while building more
  2. Phase 2: AEGIS (6 months, $1.8M)
    • Add zero-knowledge access control
    • Differentiate from all competitors
    • Capture enterprise premium pricing
  3. Phase 3: ForkNode integration (6 months, $1.4M)
    • Add E2E encryption to editing
    • Complete the “impossible trinity”
    • Achieve total market dominance
Total Investment: $4.5M over 18 months
Market Position: Unassailable for 3-5 years
Document Status: 🔄 Draft - Strategic Review Required
Version: 1.0
Authority: Protocol Architecture Team + Security Engineering Lead + CTO ForkNode-VEST represents the ultimate protocol synthesis - combining privacy, performance, and proof in a way no competitor can match. When combined with AEGIS for access control, Materi will own the highest-value segment of the collaboration market.