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.
Intent Machine (IM) is composed of 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.
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
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.
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.
In case of non-unique solutions, the
Picker picks one solution according to some metric.
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.
Example policy features which need to be decided at the IM level:
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)
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?
E.g. dependent on continued payment.
Do the solvers do plaintext solving, or e.g. using a batched MPC scheme.
This includes most things that are not purely
Resource based, e.g.:
- A priori, e.g. payment for inclusion and compute attempts
- A posteriori, e.g. outcome dependent
- Restrictions on counterparty properties
We assume that most of the MEV-like (SUAVE?) opportunities will lie in the
Picker role (in cases where
Solving is verifiably correct).
In adversarial settings, composition between
Pickers needs to be well structured to not implement unwanted equilibria.
- Ferveo, Commit/Reveal Schemes can help bound MEV opportunity.
- How to incentivize revelation of
Intentsto composition components?
- Can we use trust/entanglement metrics to mitigate some of the incentive problems?
- Characterization of IM/IM composition (SUAVE-ish setting)