Draft Status: Very
We (@cwgoes and I) thought a bit more about how to (de)compose Intent Machines and which roles exist within them. Here’s a draft on that.
Composition
An Intent Machine (IM) is composed of a Selector, a Solver and a Picker. IMs can be composed of IMs, in which case the individual roles need to be composed.
Parties implementing these roles can announce that they are forming an Intent Machine explicitly, or users can request collaboration of different parties to spin up and ad-hoc IM.
IM can state policies they implement, and users can request them but IMs can always choose to accept or not.
Each Role is governed by an Identity, which can be trivial or composed.
Roles
Selector
The Selector decides which Intents go into one solving batch. These Intents construct and constrain (maybe span is a better term?) the solving space. Users submit their Intents to Selectors.
Selectors can be composed in parallel by just accepting the union of submissions within batch bounds, or sequentially, via consensus.
Note: This seems to have similar structure and issues to a mempool.
Solver
A solver only uses computation to produce matchings between intents. These could be deterministic algorithms for PTIME instances, or heuristics for NP-HARD/NP-COMPLETE ones.
For deterministic algorithms (at least), receipts can be provided via ZK proofs.
Solvers behave like a single process to the outside, but could be built on top of e.g. privacy preserving MPC schemes running across multiple machines.
Picker
In case of non-unique solutions, the Picker picks one solution according to some metric.
Policies
An Intent can always request to only be included in batches fulfilling certain IM Policies, but some policies, called Intent Policies can be heterogenous within a batch. These can always be extended to the whole batch, but not the other way around.
IM Policies
Example policy features which need to be decided at the IM level:
Solving batches being bounded
Submission of Intents to solve batches and the solving of them could be bounded by wall-clock time via an oracle, logical time in respect to some consensus provider, or compute cycles (verifiable via receipts/proofs)
Batches could be unbounded
Once started, solve time could be unbounded, e.g. for NP-Hard Intents and contingent on continued payment for solving.
TODO: Can we have dynamic solving alogrithms, that can incorporate new intents while running?
Retention of Unmatched Intents across batches
E.g. dependent on continued payment.
Privacy
Do the solvers do plaintext solving, or e.g. using a batched MPC scheme.
Intent Policies
This includes most things that are not purely Resource based, e.g.:
Solving rewards
- A priori, e.g. payment for inclusion and compute attempts
- A posteriori, e.g. outcome dependent
Matching Constraints
- Restrictions on counterparty properties
Incentives and Economics
We assume that most of the MEV-like (SUAVE?) opportunities will lie in the Selector and Picker role (in cases where Solving is verifiably correct).
In adversarial settings, composition between Selectors and Pickers needs to be well structured to not implement unwanted equilibria.
MEV Mitigations
- Ferveo, Commit/Reveal Schemes can help bound MEV opportunity.
Questions
- How to incentivize revelation of
Intentsto composition components? - Can we use trust/entanglement metrics to mitigate some of the incentive problems?
Open Problems
- Characterization of IM/IM composition (SUAVE-ish setting)