I wanted to come back to the problem of action context separation and composition of unbalanced transactions, that I’ve described in our internal team chat in the context of the rock-paper-scissors game.
I was now thinking if this is a more general problem, for example, in the context of oracle services.
Let’s say there is an oracle service for weather forecasts. The oracle service provides and proves the weather forecast resource and requests some compensation in return via an intent. This is an unbalanced txn. Apps with weather dependent logic would create unbalanced txns to be composed with the weather forecast service intent.
However, after composition of the unbalanced txns, the weather forecast resource and the weather dependent resources end up in different action contexts, so that the weather-dependent logic cannot depend on the weather resource.
Do we have a solution for this problem @vveiln and @cwgoes?
Sending the weather resource (which is required for the weather-dependent logic proof) out-of-band together with a signature by the oracle service is insufficient because the weather-dependent app could just extract the oracle information and put it in some other place without compensating the service provider.
Thinking more about it, extraction of oracle information can also happen if unbalanced txns are used, unless the oracle service provider creates the logic proof for the weather dependent logic of the customer, which sounds hacky to me too. Maybe I am missing something here. It would be good to have a simple pattern for these use cases.
First of all, we need to think of the oracle’s model. How can the oracle give the information to the receivers? I can see a few ways:
Subscription. An application that depends on the weather subscribes to the oracle’s services, paying a montly/weekly/whatever-they-agree-on-ly fee to the oracle. In response, the oracle sends the weather information to the subscribers each time they perform a measurement (or, again, whatever rate they agree on) encrypted under the subscriber’s key.
Requests. The weather oracle doesn’t place intents, but rather solves intents of the applications requesting the weather information. An action contains: a consumed fee resource and a created intent resource. The weather application, upon receiving the intent, creates their own action, including the weather resource (encrypted under the receiver’s key), consumes the intent resource, and creates the fee resource for themselves. They also can help of a third-party solver.
Offers. The oracle can offer measurements to whoever wants to buy them, but this method is tricky because the oracle doesn’t know the receiver’s key and therefore have to encrypt the measurement under some other key and somehow communicate the key to the receiver. This definitely implies more communication rounds.
Here I assume that in all three cases the measurements are encrypted even in the transparent case because otherwise whoever wants to get a measurement, can just see it in the gossip network. For example, a fake oracle can be just stealing measurements from a genuine oracle and therefore provide their services to weather-dependent-apps and getting a share of the genuine oracle’s fees. For the apps themselves the stolen measurements might be less useful if their logics requires a presence of an oracle resource. In the request model case, if the weather application solves the intents itself, the encryption might not be needed - it won’t get to the gossip network, and the full transaction is already encrypted. Note that this is application-level encryption independent from RM-level verifiable encryption
Next I will only consider the first two formats because the key issue in the third one makes everything complicated.
So, how would a weather-dependent app include the oracle measurements in the transaction?
Subscription. In this case, the oracle can send consumable weather resources directly to the application independently of when the application wants to use it. When the application needs it, they consume the weather resource (provided a time range check - the weather is still relevant). The subscription contract is independent from the weather information provisioning. Because of that, the weather information can be sent out of band, on request or on a regular basis - knowledge of the weather information won’t make the application stop paying the fees because the fees were paid in advance.
Request model. The application creates the action with the resources that do whatever the application wants them to do and includes an intent resource that requires certain weather conditions to be satisfied. The action is proven. It requests the weather measurement from the weather app, the weather app includes the measurement and consumes the intent resource if the intent is satisfied. To make sure the weather oracle is paid for services, and not for the weather, the weather-dependent app includes an alternative action with an intent that gets satisfied in case the weather is not what it needs. In that case the action only contains the fee for the oracle. In both cases the oracle only sees the condition on which the intent is satisfied and not the content of the other action
Thank you, this was very instructive! An example implementation for the different models you’ve listed and their pros and cons would probably make up a good tutorial on how to design a (service) app.
I’ll skip what @vveiln already covered and note that – in general – I do not think that the RM “as existent” alone is sufficient to really make “payment-for-information” work. In order to enforce atomic payment-for-information, you need either:
A party acting as solver who is trusted to reveal the information (and create associated proofs) iff. conditions are matched. In @vveiln’s “request model”, this party is the weather oracle, which makes the incentive-compatibility argument easy. This party could also be a third party (neither the user nor the oracle), who at least the oracle would then need to trust to keep the information secret, only using it to make the appropriate transactions and proofs when conditions are met. This party could also be a quorum of a set of parties, e.g. a quorum of validators running a DKG such as Ferveo, where the oracle encrypts data to the threshold key, and a quorum of validators decrypts it (perhaps re-encrypting to appropriate parties) only when specified conditions are met.
Full witness encryption, where data would be witness-encrypted to a proof of a successful payment transaction (roughly speaking). For now this is not practical (and it probably won’t be super soon, although I think it’s a research area of future potential promise).
That said, I’m also not convinced that you need atomic payment-for-information for this kind of oracle – it might well be overly complicated. A simpler option could be to simply have the weather oracle provide the data for free, and for either users to tip the oracle a very small amount whenever they use the data, or for some relevant institution concerned with the public good of “freely available weather data” to help fund it (this institution could be e.g. the Public Signal app, where a bunch of users crowdfund a weather oracle). Given that the actual underlying physical costs have no relation to the number of times the oracle data is used, and relate purely to some underlying physical costs of collecting it, this also makes more sense to me from a fundamental economics perspective.