Separate general policy logic from block builder policy logic to improve usability for other TEE projects #55
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor: extract BasePolicy + deriver architecture; keep BlockBuilderPolicy upgrade-safe
Summary
This PR refactors
BlockBuilderPolicyby extracting reusable policy logic into a new abstractBasePolicy, and introduces a pluggable workload-derivation layer (IWorkloadDeriver) so workload ID derivation can evolve without rewriting policy code. The refactor is designed to preserve upgradeability by maintainingBlockBuilderPolicy’s storage layout.Previous Discussion
Discussion occurred in #45 (comment)
What changed
src/BasePolicy.solwith common policy logic (addWorkloadToPolicy,removeWorkloadFromPolicy,getWorkloadMetadata,isAllowedPolicy,_cachedIsAllowedPolicy) and hooks for auth/deriver/cachesrc/interfaces/IPolicyCommon.solfor sharedWorkloadIdtype,WorkloadMetadata, and common events/errorssrc/interfaces/IBasePolicy.solfor the shared policy interfacesrc/interfaces/IWorkloadDeriver.solfor injected workload derivation (workloadIdForQuote(bytes))src/derivers/TDXWorkloadDeriver.solcontaining the current TDX derivation logic behindIWorkloadDeriverBlockBuilderPolicyBlockBuilderPolicynow inheritsBasePolicyand keeps block-builder-specific logic (EIP-712 domain, proof verification, permit nonce handling)workloadDeriverand wired it throughinitialize(...)andsetWorkloadDeriver(...)isAllowedPolicyto derive fromregistration.parsedReportBodyto avoid re-parsing raw quotes on cache misses_setWorkloadDeriverto ensure the configured deriver supports the report-body derivation method assumed by the overrideexamples/DualDeriverPolicy.sol(UNAUDITED EXAMPLE) demonstrating a migration approach that tries an “old” and “new” deriverexamples/TDXTD15WorkloadDeriver.solshowing how a hypothetical future report-body format could be supported by swapping deriverstest/UpgradeRegression.t.solto upgrade a proxy from a legacy policy implementation to the refactoredBlockBuilderPolicyand assert state + behavior preservationtest/Examples.t.sol) and updated existing tests/scripts for the new initializer/deriver wiringWhy
BlockBuilderPolicystorage layout compatibleStorage / upgradeability notes
BasePolicyonly introduces shared storage in the original order (approvedWorkloads,registry) and uses hooks so derived contracts can own additional stateBlockBuilderPolicykeeps its existing slots and introducesworkloadDeriverin reserved space; the upgrade regression test validates this end-to-endTest plan
forge test