There are several modularity issues with the WP1 Air trait organization, mostly defined in core::air::builder.
-
the convenience trait SP1AirBuilder is used in bound position very often, whereas a more sparse trait would suffice. This isn't a problem for the SP1 code base since this convenience trait is auto-implemented, but muddles that the implementations often have simpler requirement. For instance:
https://github.com/wormhole-foundation/wp1/blob/ef5133d62b2575a8e75fd35b0d6a1bf83d7cd823/core/src/alu/add_sub/mod.rs#L140-L142
probably only requires an AluAirBuilder.
-
We would like to reuse the existing definitions of generate_trace for gadgets. Those are defined in the MachineAir trait, which requires a generate_trace that's a bit inflexible: in the form of a single instantiation of a Self::Record: MachineRecord type:
a. the Self::Record type is bound once and for all at the implementation of the MachineAir trait. We anticipate that a generic generate_trace which takes on a parameter MR: AdvancedMachineRecord with AdvancedMachineRecord a suitable bound would be more flexible,
b. the generate_trace implementations are specialized to work on the ExecutionRecord, a concrete, SP1-specific-type and would probably be more reusable if they worked against a trait that abstracts the "common denominator" fields required of this (the above AdvancedMachineRecord) + some specific traits that would encode the capability of storing gadget-specific events (e.g. events for point decompression specific to a gadget accomplishing that on a specific curve).
There are several modularity issues with the WP1 Air trait organization, mostly defined in core::air::builder.
the convenience trait
SP1AirBuilderis used in bound position very often, whereas a more sparse trait would suffice. This isn't a problem for the SP1 code base since this convenience trait is auto-implemented, but muddles that the implementations often have simpler requirement. For instance:https://github.com/wormhole-foundation/wp1/blob/ef5133d62b2575a8e75fd35b0d6a1bf83d7cd823/core/src/alu/add_sub/mod.rs#L140-L142
probably only requires an
AluAirBuilder.We would like to reuse the existing definitions of
generate_tracefor gadgets. Those are defined in theMachineAirtrait, which requires agenerate_tracethat's a bit inflexible: in the form of a single instantiation of aSelf::Record: MachineRecordtype:a. the
Self::Recordtype is bound once and for all at the implementation of theMachineAirtrait. We anticipate that a genericgenerate_tracewhich takes on a parameterMR: AdvancedMachineRecordwithAdvancedMachineRecorda suitable bound would be more flexible,b. the
generate_traceimplementations are specialized to work on theExecutionRecord, a concrete, SP1-specific-type and would probably be more reusable if they worked against a trait that abstracts the "common denominator" fields required of this (the aboveAdvancedMachineRecord) + some specific traits that would encode the capability of storing gadget-specific events (e.g. events for point decompression specific to a gadget accomplishing that on a specific curve).