A decentralised solver architecture for executing intents on EVM blockchain

[ankurdubey521]

This is really interesting, I had a few questions:

1. Which entity is responsible for converting the User Intents to ATOs? What happens if this entity is malicious and generates invalid ATOs.
2. While calculating the DoE, it looks like all fields are currently given equal weightage. If this is correct, than this would assume that all fields are normalised, which might not hold in practice. Also, some fields may be more important than others - for example the user may care about the reputation of the bridge used, but not as much as the slippage.
3. How does the system account for the possibility of multiple pathways to resolve an intent? Say for a cross chain swap depending on the liquidity distribution, bridging->swapping could be more optimal than swapping->bridging. These two pathways would have their ATOs swapped, in this case how would the DoE^{ATO_i} calculate behave?

[nlok5923]

Hi @sk1122,

In the very initial iteration, we planned to proceed with the driver approach, as it’s a proven method used by few of the protocols for managing order flows. Essentially, the Driver would function as a DAO-governed entity for off-chain management of ATOs, Additionally, serving as the trusted entity for verifying and validating solutions.

Now, onto the second query. I completely agree that an auction-based mechanism for task completions would be beneficial. We drew inspiration from SUAVE’s preference management mechanism, where executors bid to complete user preferences. This concept will likely be incorporated in future iterations. However, for this very first iteration, our goal is to abstract away the complexities of the mechanism from the solver’s end, keeping it as simple as possible to lower barriers to participation in the network.

[chiragagrawal9200]

This is a very good research! The topics covered here are very good and explained in a very simple way.

[rishotics]

can be taken care by the client. One possible approach we experimented at ETH Paris was using LLMs which can be fine tuned for a set of N actions. Additionally you can attach a Snark proof to the ATO generation.

2. Weight will only be given to the fields which are being expressed by the user. So a rough expression might be:

DoE_{operation}= \sum w_{positiveQuality}. fieldValues_{positiveQuality} - w_{negativeQuality}. fieldValues_{negativeQuality} + default

where \;\;w\in\{0,1\}

The exact expression for DoE calculation will be highly dependent upon the operation.

3. Some thoughts have been mentioned some thoughts above: link. The global maximum for a particular Intent is dependant on the feedback the ATO generation receives from solvers for a particular intent. Currently these components are not connected and independent so might not get the maximum DoE but will get a local maxima.

[ankurdubey521]

Thanks for the explanation! Do you think representing the ATOs as a DAG with edge weights \propto \dfrac{1}{DoE_i} then applying a shortest path algo could be a potential solution?

[jacobdcastro]

This seems super promising! Thanks for all the thought you’ve put into this, and accelerating the EVM intent space. I have a few questions:

1. The driver seems a bit opinionated and centralized. What exactly is it? Can anyone build a driver implementation with different ordering algos?
2. How does the driver’s role differ from SUAVE’s MEVM smart contract mechanisms?
3. How do solvers guarantee block inclusion for the client? Will txns be routed through MEV-boost, or through private order flow?
4. How do you plan on deciding which solver reward mechanic to use? Is there a way to implement many reward solutions here, and/or allow solvers to create/enforce their own reward mechanisms depending on order type specialty?

[paul0x741]

Thanks for publishing this research! I have a couple questions:

1. One thing I’m thinking about is how expressive an intent can be on conditional criteria for example can they express preferences on mempool data? Would the driver need to wait for that data to be finalized? How would that affect the DOE calculation?
2. If a solver has access to private orderflow and can get better execution how would the driver verify that?
3. You say that this yields enhanced availability of solvers but what about the driver?
4. How does the Intent Execution Module work, does the user need to manually verify the solution for onchain execution?

[rishotics]

Thats an interesting anology! If I get it then each node will be a state s_{k} starting from s_{i} till final state s_{f} where an ATO_{k} can lead a state change from s_{k} \rightarrow s_{k+1}.

One issue might be the discovery of the entire state graph for optimising, as a particular state can lead to multiple states. But if the state graph is known then we can choose the shortest path for a potential solution.

[nlok5923]

Thanks for contributing @jacobdcastro

1. The driver seems a bit opinionated and centralized. What exactly is it? Can anyone build a driver implementation with different ordering algos?

The driver in this architecture is managed and governed by the solver DAO. We retained the driver for the initial iteration of this architecture to place a stronger emphasis on the solvers’ end of the structure. Certainly, our roadmap includes plans to make it increasingly permissionless and decentralized. We are indeed considering the possibility that, in the future, anyone could code their own logic for ATO distribution among solvers. Since an intent comprises multiple ATOs, the routing and distribution of these ATOs also present an optimization challenge. Better approaches from the community could enable quicker resolution of the ATOs.

How does the driver’s role differ from SUAVE’s MEVM smart contract mechanisms?

In SUAVE’s MEVM, smart contracts are primarily used to construct builders, relays, and searchers. These entities mainly deal with building blocks and identifying MEV opportunities from the order flow, which, in the case of SUAVE, are user preferences. In the context of SUAVE, the driver functions more as a mempool management entity where user preferences are received. Executors (as solvers here) can then listen to these preferences and solve them.

How do solvers guarantee block inclusion for the client? Will txns be routed through MEV-boost, or through private order flow?

Solvers operate at a layer above the order flow layer of the EVM. Their primary task is to determine the best route for the user’s optimizable ATO. Once the path is identified, it is sent and executed from the user’s wallet as a UserOperation.

How do you plan on deciding which solver reward mechanic to use? Is there a way to implement many reward solutions here, and/or allow solvers to create/enforce their own reward mechanisms depending on order type specialty?

For now, the reward mechanism we are considering is largely based on the type of ATO a solver addresses. However, we are definitely open to discussions and suggestions regarding the implementation of a flexible solver oriented rewards mechanism.

[nlok5923]

Thanks @paul0x741 for the contribution

Here are the answers to your recent queries.

One thing I’m thinking about is how expressive an intent can be on conditional criteria for example can they express preferences on mempool data? Would the driver need to wait for that data to be finalized? How would that affect the DOE calculation?

For sure, in the future, we might have intentions that prioritize preferences based on mempool. We could perhaps draw inspiration from SUAVE MEVM contracts in this regard. However, these preferences are more logical when managed by developers on behalf of the users. In our current architecture, we are focusing more on user-oriented preferences, ones that could potentially offer greater value around specific operations. For instance, if a user wants to execute a swap operation, they could specify preferences such as low slippage, faster execution, and interaction with trusted contracts, encompassing both on-chain and off-chain preferences.

Regarding the second part, we mentioned in the ATO ordering section that the driver would propagate ATO bundles in phases. Once a solution for a specific phase is determined, the updated state information will be included with the next set of ATO bundles, allowing solvers to work with the refreshed state…

If a solver has access to private orderflow and can get better execution how would the driver verify that?

The primary value proposition of solvers collaborating is to achieve the most optimized solution possible and to support the resolution of multiple different types of operations, as an intent might encompass several operations. Thus, users will benefit the most from this infrastructure when the driver manages the order flow.

You say that this yields enhanced availability of solvers but what about the driver?

In the initial iteration, the driver will be governed by the DAO. However, we eventually plan to decentralize the driver. In the future, we aim to release an extension for the solvers that will handle the validation, verification, and management of ATOs. This can be likened to running a ethereum client, as a client operates both the consensus and execution clients.

How does the Intent Execution Module work, does the user need to manually verify the solution for onchain execution?

The Intent Execution Module will serve as an extension to the user’s smart contract wallet, enabling support for intent execution. Its primary function is to facilitate fee payments and execute calldata received for a specific intent. The solution will be verified by the driver entity, and we are planning introduce an API (via driver) through which dApps can display the execution steps for the user’s resolved intent.

[Bbasche]

Hey guys, thanks for this, super interesting area of investigation and great questions raised - particularly around solver incentivization and proving optimality.

Two questions I had

1. Can you ELI5 why the driver needs to be enshrined with a particular DAO? I understand the idea of progressively decentralizing it etc but I want to understand why ATOs necessitate a DAO for this system role in this design whereas the userOps they are somewhat analogous to (and definitely adjacent to as you described) do not as far as I can tell? Why not a design explicitly around multiple drivers, or a network of drivers with reputations that could be managed by arbitrary actors like DAOs or other designs as we have in AA-land ? You did allude to this down road in the post but why not from start is what first comes to mind for me.
2. I forgot the second question by the end of that so I’ll come back later if I remember it

Thanks!

[nlok5923]

Thanks for the contribution @Bbasche

1. Can you ELI5 why the driver needs to be enshrined with a particular DAO? I understand the idea of progressively decentralizing it etc but I want to understand why ATOs necessitate a DAO for this system role in this design whereas the userOps they are somewhat analogous to (and definitely adjacent to as you described) do not as far as I can tell? Why not a design explicitly around multiple drivers, or a network of drivers with reputations that could be managed by arbitrary actors like DAOs or other designs as we have in AA-land ? You did allude to this down road in the post but why not from start is what first comes to mind for me.

For the very first iteration of this network we are more focused on building a robust network of solvers that could help facilitate optimized and faster resolving of intents into optimized executable paths. Having a network of drivers does helps in delegating loads and maintaining consensus in validation and verification stage of solutions. But we wanted to work on it phase by phase so for the first phase building a network of solvers and enabling a communication layer between driver and solver network is what we are thinking to focus on. Once the architecture is functional We could move to the next phase of development which could surely involve building a network of drivers.

Considering AA, The phases of development are quite similar. As for the first phase of functional AA we had separate teams providing their own bundlers and other services and with the next sets of development phases we are seeing development towards an alternate mempool for UserOps where all bundler would listen and fetch userOp to bundle and broadcast.

Please do let us know your feedbacks we are open to discussion.

[nlok5923]

Firstly, we want to extend our gratitude to the community for the insightful feedback and challenging questions. Below, we address the major points raised:

1. The Role of the Driver:

• The driver currently works in harmony with DAO in our architecture, acting as a coordinator and aggregator of ATOs. However, we should note that while its operation looks centralize, it doesn’t centralize control or introduce a single point of failure. We’re actively exploring ways to decentralize this piece, including introducing multiple driver implementations with varying ordering algorithms. In a gist, anyone should be able to build and propose a driver implementation, promoting decentralization and reducing potential biases.

• The driver’s role in our design differs from SUAVE’s MEVM primarily in its ATO ordering and managment. Whereas SUAVE MEVM offering a totally different approach of enabling user to build their own searches, relayer, builders. Our infrastructure would lie one layer above SUAVE infrastructure

2. Solver Network and Incentivization:

• Our approach does lean on solvers being competitive and incentivized correctly. We’re still iterating on incentive model to attract more people to build solvers for this network.

• The Degree of Expectation (DoE) was indeed designed to be a representation of solver’s solution. We’re in the process of introducing some weighted parameters to ensure that it can be tuned to users’ specific preferences.

3. Expressiveness of Intents:

• Intents are designed to be as expressive as possible. While our current focus is on optimizing the DoE for immediate user intents, we acknowledge that more dynamic and conditional intents (like those based on mempool data) can introduce complexity. We are iterating on ATO design to enable it to capture as much preferences as possible for a particular operation.

4. Execution and Verification:

• Although we would be having certain validity checks at Driver end to verify the solution authenticity before providing it to the user. Apart from Driver check we a devising a model in which user would be able to see the execution steps before actually executing the intent.

5. Availability and Redundancy:

• Multiple solvers working as a part of network would enable max uptime and expand avenues for solving multiple different types of intents.

6. Decentralization and DAO Involvement:

• DAO involvement provides a layer of community governance over critical system components (in context of our architecture Driver). However, we understand the concerns about starting the infra with a DAO-centric approach. Our vision is to evolve towards a network of drivers managed by various entities, not limited to DAOs. Starting with DAO involvement ensures community participation from the outset, but we’re flexible in adapting our approach based on practical implications and feedback.

To conclude, we’re at a nascent stage, and there’s much to refine. The intent-driven approach is UX friendly, but its success hinges on the collaboration of the community, users, and developers. We welcome continuous feedback and collaboration as we iterate on this architecture.

Once again, Really appreciate valuable insights, and we look forward to further discussions and collaborations.

[0xTaker]

Thought I’d chime in and reply here after having a good read of this - for one, really enjoyed it! There’s a couple things I think that still are up in the air for me.

The ATO Schema:

It’s good that ATOs are more loose than that of UserOps, Transaction Objects etc.

• Does additional validation occur for each operation type? For example, to make sure that I’ve staked ETH with the Lido contract to get stETH as opposed to having swapped for it on a DEX?
• With an external constraint system and the ATO schema, it would be possible to forge ATOs. What protections would be in place to protect against DoS on the solvers?
• Am I correct in that an unsolved ATO is one where payload and payloadSchema is unset / set to their default values and a solved ATO is one where they are set?
• How would constraints / validity conditions / counterfactuals be encoded? Would this be using a very large negative weighting?

The Driver:

From reading, it seems like the driver holds a number of responsibilities for this system to function:

• Receiving the client’s ATO
• Bundling of ATOs
• Sending of ATOs to a designated solver or designed solvers
• Sending of solved ATOs back to the client

I do have some questions regarding this related to censorship:

• How is censorship by the driver managed? How does the driver ensure itself try to prevent censoring a client’s ATO or solver’s solved ATO back to the client? Is this from alignment with the DAO’s intentions that it ultimately leads to more ATO uptake?
• In the scenario that a collective of solvers behind a driver does choose to censor a specific segment of ATOs or clients, what would you envision the switching cost be to another driver? Is a solver network specific to a single driver and thus a switch to another driver potentially worsen solution quality?

[nlok5923]

Thanks for the contribution @0xTaker

Does additional validation occur for each operation type? For example, to make sure that I’ve staked ETH with the Lido contract to get stETH as opposed to having swapped for it on a DEX?

The validation totally depends on the operation type and the operation type would always be fixed for a particular ATO. For your example, the operation type for the ATO could always be STAKE or SWAP.

With an external constraint system and the ATO schema, it would be possible to forge ATOs. What protections would be in place to protect against DoS on the solvers?

Yes, for sure it is possible to forge ATO’s with external constraint system but the DoS won’t be beneficial. As before the solver starts working on the ATO the user would have to pay the fees upfront for solving those ATOs. So even if the user starts forging ATO’s just to DoS the solvers. The attack vector would be very expensive for them.

Am I correct in that an unsolved ATO is one where payload and payloadSchema is unset / set to their default values and a solved ATO is one where they are set?

Yes, exactly

How would constraints / validity conditions / counterfactuals be encoded? Would this be using a very large negative weighting?

We are planning to enforce constraints / validity condition / counterfactuals on ATO via trusted Driver for the very first iteration.

(if I understood correctly) yes it would apply very large negative weighting to the solutions which fails constraints / validity conditions / counterfactuals.

The Driver:

From reading, it seems like the driver holds a number of responsibilities for this system to function:

• Receiving the client’s ATO
• Bundling of ATOs
• Sending of ATOs to a designated solver or designed solvers
• Sending of solved ATOs back to the client

Yes we gave it a thought after hearing some feedbacks and for the next iteration we are working on delegating several responsibilities out of driver to smart contract to make system more permissionless and transparent.

I do have some questions regarding this related to censorship:

How is censorship by the driver managed? How does the driver ensure itself try to prevent censoring a client’s ATO or solver’s solved ATO back to the client? Is this from alignment with the DAO’s intentions that it ultimately leads to more ATO uptake?

Yes, we planned DAO would lead the charge towards Driver but for sure your query is totally valid we are working on delegating out the pieces which could lead to censorship to work with harmony in user and DAO.

In the scenario that a collective of solvers behind a driver does choose to censor a specific segment of ATOs or clients, what would you envision the switching cost be to another driver? Is a solver network specific to a single driver and thus a switch to another driver potentially worsen solution quality?

I think the above answer answers the first few parts of this question. For the other parts, The solver network won’t be specific to Driver it just a routing entity that is responsible for routing the ATO’s to the solver network. We want Driver should be composable such that any party could spin up their Driver with their own custom routing logic for ATO’s and integrate it with the system. Also, we do forsee having driver’s custody owned to users could lead to potential censorship issues.

Thanks for the amazing feedback this was definitely helpful and would help us to make this system far more robust and secure.

[nlok5923]

Thanks for the contribution @xmrjun absolutely we are working towards the community feedback and certain points of centralization in our current iteration of infrastructure.

We would be updating the post with potential solutions soon.

[nlok5923]

Hi everyone,

Thank you for your valuable feedback.

Upon analyzing the feedback, we noticed that a recurring concern was the centralization of the Driver in our infrastructure, which could lead to potential centralization issues.

We have taken this feedback and developed an approach to decentralize the Driver component within our infrastructure.

Decentralizing driver by making it a component of solver client. And we are calling that component as Router.

Thoughts on Driver Decentralisation

We are thinking of an approach where driver roles have been delegated to solver clients themselves. Basically, the solver client now would have two components.

• Router Component: The Router component would be performing all the duties of the Driver. which includes ATO’s routing, solution simulation, winner selection and solution aggregation
• Solver Component: The Solver component would be the component where solvers could embed their solving algorithms. The solver components would act as an interface for solvers where they just have to plug their own solver implementation (can be in the form of API integration, SDKs etc.). Through the interface itself, the solvers would be receiving ATO for solving.

ATO Routing

Clients can send their intents (ATO bundles) to any of the solver client RPCs. Once sent the ATOs would land into solver offchain mempool. From thier the Router component of the solver client would route the ATOs to other solvers. (for example sending swap ATOs to swap solvers, bridge ATOs to bridge solvers etc).

Winner Selection and Solution Aggregation

Once the ATOs are solved by different solver clients. The solved ATOs would be routed back to the origin solver which received those ATOs and the origin solver would now decide the winning solver based on the solution efficiency and at least it would aggregate the winning solution and return it back to the users.

Further, we are planning to operate the Router component inside a trusted execution environment so as to eliminate any inference from the solver component of the client. We don’t want the solver component to have access to the solutions the Router component would receive for a particular ATO so as to avoid solver cheating.

In Addition to that, we plan to employ winning solver deciding and ATO sharing capabilities in a trusted manner within the solver client. As it might be the case if the Router component is kept open within the Solver client the solvers might tweak it and make it not to share the ATO with another solver to solve or could modify it to always declare their own solver solution as the winning solution for a particular ATO.

Why this is better than our first approach ?

In our previous proposal Driver worked as a DAO-owned trusted entity. It’s the sole entity which was getting order flow (in the form of ATOs) from user, broadcasting ATOs to solver and for deciding the winning solver for a particular ATO. Which conveyed the fact that owning a Driver means owning the whole network. But in the current approach, we delegated the Driver task to the Router component of each solver client.

Task	DAO-owned Driver Approach	Router component in each solver client
Broadcasting ATOs to solve	The driver had the ownership of all the order flows (user intents) Driver would receive the orderflows first and then it would broadcast it to solvers for solving.	Any user can send his intent to any solver client. And the solver client would have to share the ATO’s with each other via trusted Router component.
Winning solver declaration	Driver had the sole control for deciding the winner solver for a particular ATO.	With Router component we are planning to employ a voting based mechanism to decide the winning solver for a particular ATO.
Availability bottleneck	Driver has to be up all the time in case the driver went down the whole solver network would stop working.	Solver network would remain avalaible till the last know solver client up for work.

How will the solver run the router?

Solver doesn’t have to worry about the complexities of the Router component. They just have to integrate their APIs, SDK etc. into the client solver component and that’s it. Once integration is done the solvers would just have to spin up the client.

Looking forward towards feedback on this revised approach.

Thanks!

[pixelcircuits]

I’m curious if you’ve thought about issues with solutions that only work at a specific block height, but quickly become invalid. Basically, how can you guarantee a solution valid at block n, will still be valid by the time the client submits their tx at block n+1?

[ankurdubey521]

we are planning to operate the Router component inside a trusted execution environment so as to eliminate any inference from the solver component of the client.

how do you guarantee that every node ensures that the solver component is unable to access information meant to the router component, given that all information is received over a network interface?

Additionally, what incentive does a node have to “not” try and intercept the solutions from other solvers? As a node runner in the network, I could simply choose to not run the router in an isolated component and claim the fee for the solutions myself.

I also had an unrelated question: In the original post, the first step is to send a raw intent to the “constraint system” which is responsible for breaking down the intent into ATOs that are then further processed by the driver/router. How does this constraint system work?

[Indigoozz]

Nice research, you mentioned, “These ATO’s can be presented in the form of a private manner where information is hidden and executed in such a way that the user doesn’t reveal any information to the public blockchain.”. I have a few questions:

1. Is this achieved by encrypting the ATO’s using cryptographic techniques?

2. How does the driver and the solver get through the ATO’s in ciphertext form and eventually generate solved ATO’s?