Structured Resource Profiles #
This file defines a compositional resource profile for open computations.
A ResourceProfile ω κ separates two kinds of cost:
intrinsic : ω, the concrete runtime cost of the code itself;usage : κ →₀ ℕ, a symbolic count of how often the code invokes each external capability.
This split is useful for reduction proofs. We can first analyze an open reduction body in terms of its intrinsic overhead and interface usage, and only later instantiate those interface calls with the cost profiles of the adversaries or subroutines that implement them.
Pure intrinsic cost with no external capability usage.
Instances For
Pure external usage with zero intrinsic cost.
Instances For
A single capability use counted n times, with zero intrinsic cost.
Instances For
Instances For
Evaluate a structured resource profile against concrete per-capability costs.
Instances For
Instantiate the symbolic capability usage in c with open implementations impl.
Instances For
Additive monoid hom extracting the intrinsic component of a resource profile.
Instances For
Additive monoid hom extracting the symbolic capability-usage component of a resource profile.
Instances For
Additive monoid hom evaluating a structured resource profile against concrete per-capability weights.
Instances For
Additive monoid hom instantiating the symbolic capabilities in a resource profile with open implementations.
Instances For
Instantiating symbolic capabilities is associative.
Substituting impl₁ into a profile c, and then substituting impl₂ into the resulting
profile, is the same as substituting the composite implementation
fun k ↦ (impl₁ k).instantiate impl₂ into c directly.
Evaluating a purely intrinsic profile after instantiation leaves the intrinsic cost unchanged.
Evaluating a purely symbolic usage profile after instantiation amounts to evaluating each capability implementation and summing the resulting scalar costs.
Evaluating a resource profile after instantiating its symbolic capabilities is the same as evaluating the outer profile against the scalar costs induced by the implementations.