Operator Set v1

⚠️ Archived. This page describes an early design phase that predates the actual DCNR implementation in compute-all and has been superseded by it. It is kept for historical context. See the Architecture Overview and Project Status for the current state.

This document defines Operator Set v1, the minimal set of computational primitives supported by the DCNR Virtual Nodes (VNodes).

The operator set is a security boundary, not just an API. It determines:

  • What VNodes are allowed to execute
  • What can be validated and recomposed
  • What kinds of distributed algorithms are feasible

Operator Set v1 prioritizes simplicity, determinism, and verifiability over expressiveness.

See also

Design Goals

Operator Set v1 is designed to:

  • Be small and auditable
  • Enable useful linear-algebra workloads
  • Avoid Turing-completeness
  • Allow result validation and redundancy
  • Run within bounded memory and time

It explicitly avoids:

  • Arbitrary code execution
  • User-defined control flow
  • Dynamic memory allocation beyond declared bounds
  • File system or network access (handled by the PNode/Storage layer)

Execution Model

An operator invocation is defined by:

  • Operator name
  • Input tensors (or references)
  • Output shape
  • Resource bounds (memory, time)

All operators are:

  • Pure (no side effects)
  • Deterministic
  • Stateless

Given the same inputs, an operator must always produce the same outputs.

Data Model

Tensors

All data is represented as tensors with:

  • Fixed shape
  • Fixed data type
  • Explicit memory footprint

Supported data types (v1):

  • float32
  • float16
  • int32

Tensors are immutable during execution.

Data References

VNodes MAY accept inputs and produce outputs as data references (URIs/handles) instead of embedded tensors when sizes are large. PNodes should:

  • Resolve only the slices required for computation/validation
  • Prefer sampled fetching for validation (e.g., rows/cols for matmul, indices for ewise_*, slices for reduce_*)
  • Respect immutability for the lifetime of a job

See: Data Sources & Data Service

Core Operators

1. Matrix Multiplication (matmul)

Performs matrix multiplication:

C = A × B

Constraints:

  • 2D tensors only
  • Compatible shapes
  • Output shape known in advance

Use cases:

  • Linear layers
  • Attention projections

Validation (cheap):

  • Shape checks: verify A.shape == (m,k), B.shape == (k,n), C.shape == (m,n).
  • Freivalds’ algorithm: pick random vector r ∈ {0,1}^n, check A·(B·r) == C·r within tolerance. Cost: O(mk + kn + mn) per check.
  • Spot rows/cols: sample a few indices i or j and recompute C[i,*] or C[* ,j] directly.
  • Checksums: compare sum(C) with sum(A)·mean(B) only as a loose heuristic.

2. Element-wise Operations (ewise_*)

Supported operations:

  • add
  • sub
  • mul
  • div
  • max
  • min

Constraints:

  • Identical input shapes

Use cases:

  • Residual connections
  • Element-wise transformations

Validation (cheap):

  • Index sampling: sample K random indices and recompute locally; expect exact match.
  • Invariants by op:
    • add/mul: commutativity check on samples (x ⊕ y == y ⊕ x).
    • div: spot-check b != 0 and a == (a/b)*b within tolerance.
    • max/min: sampled outputs must equal max(a,b)/min(a,b).
  • Range/tensor shape checks: output shape == input shape; dtype rules preserved.

3. Reduction Operations (reduce_*)

Supported reductions:

  • sum
  • mean
  • max

Constraints:

  • Reduction axis must be explicit
  • Output shape deterministic

Use cases:

  • Loss computation
  • Aggregations

Validation (cheap):

  • Partial recompute: for sampled slices along the reduced axis, recompute the reduction and compare.
  • Invariants by reduction:
    • sum: total sum of partitions equals reported sum (recompute on a few random partitions).
    • mean: mean == sum/count; verify consistency on samples.
    • max: check that no sampled input exceeds the reported max and at least one element equals it in sampled blocks.
  • Shape check: verify output shape matches input with reduced axis removed or set to 1 per spec.

4. Unary Functions (unary_*)

Supported functions:

  • relu
  • tanh
  • sigmoid
  • exp
  • log

Constraints:

  • Element-wise only
  • No dynamic branching

Validation (cheap):

  • Index sampling: recompute function on K random positions.
  • Function-specific invariants:
    • relu(x) ≥ 0 and relu(x) == x when x ≥ 0.
    • tanh(x) ∈ [-1,1], odd function: tanh(-x) == -tanh(x) on samples.
    • sigmoid(x) ∈ (0,1), monotonic increasing.
    • exp(x) > 0, monotonic increasing; guard overflow/inf.
    • log(x) domain: inputs must be > 0; output monotonic; check exp(log(x)) ≈ x on samples.

5. Transpose (transpose)

Reorders tensor axes.

Constraints:

  • Axis permutation must be explicit
  • Resulting shape known in advance

Validation (cheap):

  • Shape and permutation checks: confirm output shape equals input shape permuted by provided axes.
  • Index mapping spot-checks: sample a few indices and verify out[idx_perm] == in[idx].
  • Invariants: transpose(transpose(X, p), inverse(p)) == X on a small sampled subset.

Explicitly Excluded Operations

The following are intentionally not supported in Operator Set v1:

  • Control flow (if, while, for)
  • Recursion
  • Dynamic shape creation
  • Random number generation
  • File I/O
  • Network I/O
  • Custom kernels

These exclusions are deliberate and foundational.

Validation & Redundancy

Because operators are pure and deterministic:

  • VNode tasks can be executed redundantly
  • Results can be compared byte-for-byte
  • Discrepancies can be detected and penalized

This enables:

  • Probabilistic Byzantine fault tolerance
  • Reputation-based trust mechanisms

Numeric tolerance and determinism:

  • Unless otherwise specified, comparisons for floating-point tensors use an absolute/relative tolerance suitable to the tensor dtype (e.g., float32: atol≈1e-5, rtol≈1e-4).
  • Deterministic kernels should be preferred; validation should rely on tolerant comparisons or algebraic checks (e.g., Freivalds for matmul).

Redundancy strategies (cheap first):

  • Spot-checks on random indices or slices.
  • Algebraic randomized checks (e.g., Freivalds’ algorithm for matmul).
  • Cross-PNode redundant execution on a fraction of tasks.

Relationship to Training & Inference

Operator Set v1 supports:

  • Forward passes of simple models
  • Portions of backpropagation
  • Distributed linear-algebra workloads

It does not fully support:

  • End-to-end backpropagation without orchestration/DCNR logic.
  • Dynamic computation graphs.

Training algorithms must be expressed as graphs of VNode invocations managed by the orchestrator.

Evolution Strategy

Future versions may introduce:

  • Batched operators
  • Sparse tensor support
  • Quantized operations
  • Cryptographic commitments to results

Backward compatibility is a strict requirement.

Summary

Operator Set v1 defines a minimal, safe, and verifiable execution surface.

Its constraints are intentional and foundational, enabling:

  • Decentralization
  • Fault tolerance
  • Trust minimization

This is not a limitation — it is the system’s core strength.

Built in the open. Owned by the community.