Overall approach
Chaintable first builds an offchain runtime matching onchain state and execution semantics, then addresses large-scale processing, consistency constraints, and low-latency online services on that foundation.
Design principles
Row-level computations within a task are independent
Rows within a task compute independently of each other’s execution order or intermediate results. They can share ready state but cannot affect each other through mutable state. This lets the engine fully parallelize execution for greater efficiency without changing results.
Computations across tasks are independent
Once upstream dependencies are ready, tasks for the same target table compute independently from their required world state, excluding the target table itself. With upstream data and business logic fixed, tasks depend on neither the target’s existing results nor its processing progress. Execution order, parallelism, and backfill strategy should not change final results.
The compute engine itself remains stateless
Client logic in Notebooks manages orchestration; BlockDB maintains data state. The engine focuses on high-performance task execution, leaving state management to those components.
Only block-driven computation is supported
Platform pipelines use block-ready events from Block Tables—both Event and State tables. Individual row changes in arbitrary tables cannot trigger computation independently.
Functions are first-class citizens
Functions are independent platform modules expressing the smallest units of business logic. Their definitions and identities stand alone; they interact with execution, orchestration, or service modules only in specific runtime scenarios.
Functions drive developer productivity and computational efficiency. Chaintable streamlines writing, debugging, composing, and reusing Functions, and optimizes execution and state access—making the same business logic more efficient to develop, run, and use.
A table’s computation logic is reusable
A table’s computation logic—input tables, upstream dependencies, business Functions, and output definitions—serves both historical backfills and real-time computation. Different execution granularities and scheduling strategies support large-scale processing and low-latency updates without changing computation semantics.
