the streaming two-phase consensus section of newton's whitepaper solves a problem that isnt immediately obvious unless you think through how BLS aggregation actually works.
BLS aggregation requires all participating operators to sign the same message. identical bytes. if two operators sign different messages - even because they fetched slightly different oracle prices a millisecond apart - their signatures cant be aggregated. the math breaks.
the problem is that operators are supposed to fetch external data independently. thats the decentralization guarantee. sanctions feeds, oracle prices, risk scores – no single entity controls those inputs. but independent fetching over real networks produces variance. two operators hitting the same API endpoint a second apart might see different prices during a volatile period.
the prepare phase exists to resolve this before it becomes a signature problem. every operator in the active validator set independently executes the same WASM data provider plugin through its own network path and streams back its observed values alongside an ECDSA attestation over what it saw. no synchronization barrier - responses arrive as they come. the gateway then computes median-based consensus across numeric fields in those responses and publishes one canonical dataset.
only after that canonical dataset exists does the evaluate phase begin. every operator fetches the same Rego policy by content hash from IPFS, evaluates it against the same canonical dataset, and produces identical output. identical output means identical digest. identical digest means BLS aggregation works. the aggregator exits as soon as the configured quorum threshold is met rather than waiting for all operators to respond.
whats notable about the median step is what it tolerates. a single operator with a stale feed or a temporarily misconfigured data source doesnt corrupt the canonical dataset – it just loses the median. the design is explicitly built to handle noisy real-world data without trusting any single data source.
what the whitepaper doesnt address is systematic splits rather than random variance. if half the operators are fetching from one version of a data source and half from another during a feed migration, the median might produce a value neither cohort actually observed. whether that scenario is caught, flagged, or just silently absorbed into the consensus output isnt specified.
