Feature Request: Seperate general policy logic from block builder policy logic to improve usability for other TEE projects

[fnerdman]

Currently the only policy available is the BlockBuilderPolicy. This policy combines both general policy logic applicable to any TEE system as well as BlockBuilder specific logic. To improve flashtestations usabilty for other projects I'd recommend to separate general logic into a BasePolicy.sol

[fnerdman]

@Melvillian do you approve? would you accept a PR?

[Melvillian]

@fnerdman This sounds good to me... what roughly were you thinking of putting in BasePolicy.sol?

addWorkloadToPolicy and removeWorkloadFromPolicy are good functions to abstract. _cachedIsAllowedPolicy and isAllowedPolicy, with some small tweaks, could go in as well, I think.

What should be the function interface to external callers? For instance, how would BasePolicy hook into the user's implementation of what is now workloadIdForTDRegistration?

[fnerdman]

I agree with moving addWorkloadToPolicy, removeWorkloadFromPolicy, getWorkloadMetadata, isAllowedPolicy, and the cached variant into BasePolicy.sol, along with common storage (approvedWorkloads, registry) and events/errors.

On the derivation side: workloadIdForTDRegistration isn’t block-builder–specific; it’s TDX-platform–specific. I see two ways to structure it:

A) TDX-only Base (simplest now):

• Move the TDX derivation into BasePolicy as the default virtual implementation (_workloadIdForRegistration).
• Tradeoff: Base becomes TDX-specific.

B) Composition via deriver (max flexibility):

• BasePolicy delegates to an injected IWorkloadDeriver.
• Provide TDXWorkloadDeriver with today’s logic.
• Slight extra call cost; easiest to swap derivations later.

So in fact, BlockBuilderPolicy would only add the block-builder EIP-712 layer.

[spencer-ritual]

One nit I would add here is workloadIdForReportBody(TD10ReportBody memory body) public pure would be a better UI than function workloadIdForTDRegistration(IFlashtestationRegistry.RegisteredTEE memory registration). registration.parsedReportBody is the only field from registration used in the function, so doing workloadIdForReportBody makes it easier to calculate workloadIDs prior to registration, e.g. for governance to approve it before something actually registers. workloadIdForTDRegistration can also wrap workloadIdForReportBody by only sending in the relevant part of the registration.

[fnerdman]

@Melvillian ping

[Melvillian]

@fnerdman +1 to your approach, as well as @spencer-ritual 's suggestion to make it a pure function using just TD10ReportBody. We should have done that for version 1.

I like Option B above because of the max flexibility. But if you go that approach can you make sure the final version of whatever PRs you merge ends up with:

1. a BasePolicy that exposes Option B
2. A BlockBuilderPolicy that uses BasePolicy in the same way the current BlockBuilderPolicy does
3. Can you create your PR's off of this v2.0.0 branch? I want to keep main that latest version, and work on the v2.0.0 branch at least until we're after launch and people won't be confused by thinking main is what's running in production
4. An examples/ top level directory with one other implementation of BasePolicy that differs from BlockBuilderPolicy, so people can see different approaches to implementing the workload derivation?
5. tests of course.

Also importantly: feel free to break backwards compatibility with regards to the functions interface, but your changes must keep backwards compatibility with the BlockBuilderPolicy's storage format. We are going to upgrade the contract when it comes time to release this and other v2 updates we have planned, and it will be much easier if the storage format stays the same. If you have a good reason to break backwards compatibility (much improved UX, or much improved gas savings), then let's talk about it.

Thank you for contributing and I look forward to reviewing your PRs.