Apertures: Coordinated Partial Evaluation for Distributed Computation

Apertures provide a lightweight coordination mechanism for distributed computation through partial evaluation with “holes” (denoted ?variable). Unlike cryptographic approaches, apertures make no security claims but instead offer practical coordination for scenarios where parties can share computation structure while controlling when and where data is introduced.

The Core Idea

An aperture represents an unknown expression—a hole in a computation. Programs with apertures can be:

• Partially evaluated by parties who don’t know the aperture values
• Optimized and transformed without seeing the data
• Resumed when apertures are eventually filled

Critical disclaimer: Apertures leak information through program structure, evaluation patterns, and algebraic relationships. They’re not for adversarial settings or high-security requirements.

The Local Computation Pattern

The most compelling use case:

;; Server optimizes without seeing data or results
(let ((plan (server-optimize ?query)))
  (client-execute plan ?local-data))
;; Results stay local
Copy

The server provides optimization expertise without seeing:

• Actual query parameters
• Local data being processed
• Query results

However, the server learns query structure and patterns.

How It Works

Core Language

Apertures extend a Lisp-like language with holes:

e ::= v | x | ?h | (e e*) | (λ (x*) e)
    | (let ((x e)*) e) | (if e e e)
Copy

Partial Evaluation

Evaluation proceeds until blocked by apertures:

E[(+ n1 n2)] → n1 + n2           (arithmetic)
E[(+ ?h n)]  →p (+ ?h n)         (partial - blocked)
E[?h]        →p E[?h]            (aperture blocks)
Copy

Algebraic Simplification

During partial evaluation, algebraic rules apply:

(* 0 ?x) →p 0
(+ 0 ?x) →p ?x
(* 1 ?x) →p ?x
Copy

These simplifications improve performance but also leak information!

Coordination Patterns

Progressive Refinement

Multiple parties incrementally fill apertures:

;; Initial query with holes
(select ?table
  (where (and (> ?col1 ?val1)
              (< ?col2 ?val2))))

;; Party A knows table structure
(fill query {table: "users", col1: "age", col2: "salary"})

;; Party B knows constraints
(fill query {val1: 18, val2: 100000})
Copy

Speculative Compilation

Servers compile multiple code paths without knowing which will be used:

(case ?config
  [(fast) (quick-process data)]
  [(accurate) (slow-process data)]
  [(balanced) (hybrid-process data)])
Copy

Performance

Overhead compared to direct evaluation: 2-5%

The minimal overhead comes from hole checking and maintaining partial evaluation state.

When NOT to Use Apertures

Adversarial Settings: An adversary can infer values from structure and exploit evaluation patterns.

High-Sensitivity Data: Medical records, financial data, personal information—apertures leak too much.

Regulatory Compliance: GDPR, HIPAA, financial regulations require stronger guarantees.

Information Leakage Example:

(if (> ?age 65)
    (discount 0.2)
    (if (< ?age 18)
        (discount 0.1)
        (no-discount)))
Copy

Even without seeing ?age, observers learn:

• Age-based discount tiers exist
• Exact discount amounts
• Business logic structure

When Apertures ARE Appropriate

• Computation structure is not sensitive
• Parties are honest-but-curious, not adversarial
• Performance matters more than perfect privacy
• Local computation can limit result leakage

Good use cases:

• Scientific computing with public algorithms
• Optimization of non-sensitive business logic
• Collaborative debugging and testing
• Educational systems

Implementation

Our C++ implementation provides:

• S-expression parser with aperture syntax
• Partial evaluator with algebraic simplification
• Hole tracking and filling mechanism
• Stack-based evaluation with continuation frames

Key Insight

Many real-world scenarios don’t require cryptographic privacy but do need coordination primitives. Apertures fill this gap with minimal overhead while acknowledging—rather than obscuring—their limitations.

Not every distributed computation needs cryptographic security, but all need clear understanding of their tradeoffs.

View the full workshop paper (PDF)

Related Work

• Partial Evaluation: Apertures extend partial evaluation with explicit holes for multi-party coordination
• Homomorphic Encryption: Provides strong privacy with 1000-10000× overhead
• Secure Multi-Party Computation: Cryptographic guarantees for adversarial settings
• Staged Computation: Multi-stage programming for performance optimization