Summary
The purpose of this feature is to generate lookup constraints for function calls. This is similar to what was done in zkASM, but with some key differences (outlined below).
Differences
There are two key differences from the proposed approach, compared with how it worked in zkASM:
- (No
io.Bus). In zkASM, an io.Bus was created for each function called. This is not necessary in ZkC, since function calls already accept only registers as arguments and returns. Therefore, a lookup should be created for each distinct function call which operates directly on the argument/return registers in the call instruction.
- (OLI Enable Line) In zkASM, one-line functions did not have an enable line and, instead, supported padding with a valid instance of the function. In many cases, the tool could not determine a valid instance itself and, hence, it relied on the use to provide hints. Since this caused problems from a user-interface perspective, the plan for ZkC is to use an enable line
$ret for OLI functions.
Approach
The are a few suggested steps:
- (OLI Enable) The first step is to insert a
$ret line into OLI functions. Whilst this is not a constant register, it is always 1 in the non-padding region (and 0 in the padding region). This requires updating the Framing[F] to insert the $ret line (but no $pc line is required), with the FullObserver being updated accordingly.
- (Always On) The initial prototype should insert a lookup for each function call, with the
$ret line being set using a constant register.
- (Enable/Disable). The goal here is to now use a conditional lookup at the call site which is keyed on a binary (
u1) register. This register could be a control register, if a suitable one is available. Otherwise, we introduce a new control register to capture the execution path where the function call is active.
Summary
The purpose of this feature is to generate lookup constraints for function calls. This is similar to what was done in zkASM, but with some key differences (outlined below).
Differences
There are two key differences from the proposed approach, compared with how it worked in zkASM:
io.Bus). In zkASM, anio.Buswas created for each function called. This is not necessary in ZkC, since function calls already accept only registers as arguments and returns. Therefore, a lookup should be created for each distinct function call which operates directly on the argument/return registers in the call instruction.$retfor OLI functions.Approach
The are a few suggested steps:
$retline into OLI functions. Whilst this is not a constant register, it is always1in the non-padding region (and0in the padding region). This requires updating theFraming[F]to insert the$retline (but no$pcline is required), with theFullObserverbeing updated accordingly.$retline being set using a constant register.u1) register. This register could be a control register, if a suitable one is available. Otherwise, we introduce a new control register to capture the execution path where the function call is active.