I have a few questions about Anoma’s handling / thinking around data dependencies for intents. I’m still not 100% sure how they would fit into your current architecture.
Let’s start with an example of an intent with a data dependency presented in natural language: “Swap ETH to receive at least 200 USDC and send to Apriori.eth if he was able to successfully buy the NFT conference ticket for both of us”.
Would data dependencies just be part of a Predicate, as the resource can’t be consumed until the specified condition is satisfied?
Based on the whitepaper and the “temperature in Berlin” example, it sounds like solvers are expected to provide data. How would solvers submit additional data, for example a required proof of computation or a proof of satisfied conditionals that are fulfilled with private data?
This might be necessary in some cases, as view of state is subjective and solvers might have a significantly diverging view, e.g. through private order flow or access to off-chain liquidity. Not all conditionals are purely end state related, as they can be totally independent from the desired end state + constraints.
Does the Path Authentication design also allow someone to just solve for the data dependency, i.e. a “data solver”? For the sake of simplicity, let’s just assume the existence of one trusted data solver only; no consensus / proof generation on the data side or solver auction for now. The data solver could solve for the conditional (“was Apriori able to successfully buy the NFT conference ticket for the both of us?”) and then hand it over to “execution” solvers (“swap ETH to receive at least 200 USDC”). The “how” relates back to the second question.
We believe that the assumption of solvers providing various types of data is overly optimistic. Competing on the execution side is already hard enough, and will only get harder.
The solver market needs to be accessible and sufficiently competitive. While solvers CAN build up additional data infrastructure to gain a competitive advantage, we can’t solely rely on it and need to find a balance between allowing for a solver’s capitalization on this competitive advantage and reliable resolution of data dependencies. That’s exactly what we are looking into right now.
I would like to hear everyone’s thoughts on whether this line of thinking makes sense in general and understand more about how it could fit into Anoma’s architecture. Lastly, is this something you are working on yourself or is it out of scope for you?
It would be interesting to hear more about how Anoma is thinking about these data dependencies and if any other folks have thoughts on possible solutions. Anyone have any initial thoughts?
I’ve been thinking of a structure to have intents based on oracle data. We are launching a cosmos chain that’s used as oracle infrastructure, it does arbitrary data fetching and computation. Would love to come up with a design that would make certain intents dependent on oracle state.
In the general case, any data inputs that are supposed to be used with Intents or (Partial) Transactions and which are not Resources on the protocol level already would need to be modeled via oracles.
This could be done in a number of (non-exhaustive) ways:
An oracle could create resources for data points or series, then Predicates would refer to the Resource Type the oracle creates and take into account the Value field of the Resource, containing the data.
An oracle could promise to add a signature to Intents or (Partial) Transactions, which are presented to it, given that data conditions specified in the Predicates contained therein are fulfilled. The Predicate would include a check for a valid oracle signature to deem the Intent satisfied or the Transaction valid.
Both of these present different tradeoffs. For example, in the “Oracles encode outside data as Resources” we get the possibility to record the data history independently of other interactions, in the “sign interactions under certain data conditions” we can potentially implement interactive schemes on the side of the Oracle.
In both cases, different Oracles could also run consensus (or even compute something like an average or median in case of e.g. Temperature) over outside data.
There’s an important distinction here between data which is referenced as part of verifiable history and data about the external world which comes from oracles:
“if he was able to successfully buy the NFT conference ticket for both of us” - this is (presumably) part of verifiable history.
“current temperature in Berlin” - this is an oracle question.
Data which is part of verifiable history can be described directly in a resource logic and checked as part of execution, such that the intent will only be executed (and constituent actions e.g. “Swap ETH” taken) if the property is satisfied - as you mention @robin in (1).
Data which is not part of verifiable history can be requested in an intent. In order to do this the involved parties (oracle and data requester) will need to agree in advance on some standard language to describe the oracle queries - for example, I imagine that temperature queries could be specified by (latitude, longitude) coordinates and a timestamp. Similarly, the intent will not be executed unless this data is provided, signed by the specified oracle, and satisfying any specified conditions (e.g. “if the temperature is > 25C”). There is no guarantee that the oracle will actually respond to the request, but assuming reliable network conditions and perhaps multiple acceptable oracles the reliability from a user’s perspective should be high. This oracle could be the solver, but they could also just provide their signature and the data to another solver which does the actual computational work - so to answer your (3), yes.