External query bounds from the machine clock #
Each instruction makes at most one external request and writes at most one symbol per query
buffer. Starting from empty channels, a run of fuel instructions therefore makes at most
fuel external calls, each with a request length at most fuel. Private coins are sampled
independently and do not count as external requests. The bound permits arbitrarily long replies
and arbitrary state shared by the external handlers.
Moreover, because each channel's answer head starts at position 0 on query reception and moves by
at most one cell per instruction, a fuel-step run from initialConfig never inspects reply
indices at or beyond fuel. Replacing every reply by reply.take fuel in finiteRunFrom
therefore yields the exact same OracleComp program as machine.run.
Main results #
Turing.MultiTapePTM.query_bounds_runFrom: bounds from a partial run and its initial buffers.Turing.MultiTapePTM.query_bounds_runOracle: the clock bounds calls and request lengths.Turing.MultiTapePTM.finiteRunFrom_take_init: truncating replies to the clock preserves the exact typed program.
References #
Adapted from Computability/Machines/Turing/MultiTape/Oracle/QueryBounds.lean on the cslib
crypto branch at 5ff69ca93402e7c947208dc56396d6d86203ccd8, using the common machine.
A partial run adds at most one external call per instruction. Requests fit within the initial buffer bound plus elapsed time, regardless of the oracle's reply sizes.
From blank channels, the same clock bounds external calls and every request length.
Agreement with a native configuration up to truncating each channel's reply to limit
symbols.
- tapes : finite.tapes.Represents cfg.tapes
Ordinary configurations correspond.
Pending requests agree.
- answers (op : Operation) : (finite.channels op).2.Represents (fun (position : ℤ) => if 0 ≤ position then (List.take limit (cfg.channels op).answer)[position.toNat]? else none) (cfg.channels op).answerPos
Answer tapes agree with the
limit-prefix of each channel's reply.
Instances For
Initial finite storage represents the native initial configuration at any reply truncation limit.
When every answer head lies strictly before limit, the truncated finite configuration sees
the exact same answer symbols as the native configuration.
An ordinary transition preserves truncated representation.
Installing a truncated reply in finite storage represents installing the full reply in native storage.
Truncating every reply to limit symbols in finiteRunFrom produces the exact same typed
program as runFrom whenever the remaining fuel keeps every answer head below limit.
Over fuel steps from blank initial storage, truncating every oracle reply to fuel symbols
preserves the exact typed OracleComp program.
Specializing finiteRunFrom_take_init to runOracle: truncating every external reply to
fuel symbols preserves the exact ProbOracleComp program.