Proposal for gas payment in the resource machine

Resource Machine Stuff
1

Spawned by a discussion with @isheff and others in the state architecture ART review call, I propose that we specify a mechanism for gas payment (or, more specifically, payment for transaction function execution) as part of the resource machine specs, which would work as follows:

  1. We introduce a new datatype TransactionFunctionWithPayment, which consists of three elements:
    a. A transaction function (as currently in the RM specs).
    b. A transaction object (the “payment transaction”), which includes in a special application data field the hash of the transaction function and the gas limit.
    c. A gas limit (natural number).
  2. When executing a TransactionFunctionWithPayment, the executor takes the following steps:
    a. Checks that the payment transaction is “simple”. What exactly this means can be executor-specific, but roughly “simple” means “inexpensive to verify”. A basic (very restrictive) check could be that the payment transaction has exactly one consumed resource and nothing else.
    b. Decide whether this gas payment is sufficient. This decision can be controller-specific (maybe there are certain assets and certain prices accepted for gas).
    c. Alter the payment transaction, adding new resources assigned to the executor (or whoever is supposed to receive the gas payments) as necessary to make the payment transaction balanced.
    d. Check that the payment transaction is fully valid and balanced (normal transaction rules), including in a special application data field the hash of the transaction function and the gas limit.
    e. Execute the payment transaction (apply the state changes).
    f. Compute the transaction function, limited by the specified gas limit.
    g. If the transaction function computation finishes within the gas limit (returning a transaction object), check that the transaction object is valid and balanced, and if so apply it to state (as previously in the RM).

I like this approach for a few reasons:

  1. It does the basic thing we want (a simple transaction pays for the potentially costly execution of the transaction function).
  2. It’s pretty simple and uses mostly data structures and logic which we already have.
  3. It’s quite general, doesn’t fix a particular token which must be used to pay for gas, and even allows for solving as part of the gas payment (e.g. controller accepts token X, user wants to pay for gas in token Y, a solver can match this with another X → Y intent and produce a valid payment transaction).

I’m looking for quick feedback from @isheff @vveiln and @degregat. If this looks good, we can add it to the specs next week (in full detail). Otherwise, raise any questions or concerns here.

1 Like
2

Some thoughts on

and

The authorization mechanism of the token would need to allow “adding new resources assigned to the executor (…) as necessary to make the payment transaction balanced”.
The current Kudos token authorization mechanism requires a signature over a message including the mustBeCreated commitments and mustBeConsumed nullifiers from the owner. The logic then checks that mustBeCreated commitments and mustBeConsumed nullifiers are subsets of the action commitments and nullifiers.

Similar to a swap, we could require an ephemeral intent resource in the mustBeConsumed set in which further constraints are expressed.
This gas payment intent resource could also be the right place to specify the gas limit (and maybe other things, such as an expiration time).
TransactionFunctionWithPayment could have an app data field pointing to the intent resource commitment. Maybe we don’t even need a special transaction function type at all if the intent resource is transparent and has a standardized kind.

2 Likes
3

Why? The owner of the token would just be authorizing “I am happy to consume a resource with X units of token Y if the transaction function with hash A is executed with gas limit B”. The executor would add e.g. a created resource of X units of token Y to a different action, which would not be visible to the first action (but would make the payment transaction as a whole balanced).

1 Like
4

Where is the logic located making sure that this constraint is met? I’m argueing that this constraint is not located on the token (because tokens should have a more general logic and not a specific one) but rather on an intent resource that the token requires to be present (like we do it in the case of a swap).

1 Like
5

Ah I see - an intent resource should not really be necessary, the user should sign over an authorization which binds to particular public inputs (in this case, the information about the transaction function execution being paid for), where the proof is valid only if those public inputs are as expected.

6

the user should sign over an authorization which binds to particular public inputs (in this case, the information about the transaction function execution being paid for), where the proof is valid only if those public inputs are as expected.

Can you help me to see where the signed message over the public inputs gets checked if this doesn’t happen on an (intent) resource?

1 Like
7

The token resource should allow for a kind of authorization where an external identity signs over a commitment to a predicate, and where the predicate must return true in order for the resource logic to accept. In this case, the predicate should check that the appropriate data is present in the application data, specifically the hash of the transaction function and the gas limit. Does that make sense? We need intent resources to carry constraints across actions, but we shouldn’t need them just for this kind of authorization in a single action.

8

How it relates to transaction with metadata? What is the hierarchy there?

What is a transaction object? Is it what is called just a transaction in the spec?

Does it only work for finalised transactions that won’t be composed anymore?

Ah, so this gas payment transaction initially is not balanced? Is it proven? What is this resource contained in the transaction, what is the logic of it?

Is it always the case that the transaction function hash is sufficient to bind the gas payment transaction to the future transaction resulting from the transaction function? I can imagine the transaction function won’t be unique, do we care about uniqueness there? What stops the executor node to apply the state changes from the gas payment transaction, then discard the transaction function associated with it or replace the computed transaction with some other transaction?

1 Like
9

Good question. I would probably say that we can just make the payment field part of TransactionWithMetadata for now (instead of having a separate TransactionFunctionWithPayment structure), they’ll always be sent together (and the payment can always be empty).

Yes.

Yes, this payment applies specifically to paying a controller to execute a transaction function and attempt to apply the resulting transaction, which would happen after any solving, composition, etc.

It is proven, but not necessarily balanced (as the creator of the payment transaction might not necessarily know exactly who will be receiving the payment). The executor might just add a new token owned by themselves.

Nothing stops the executor from doing arbitrary things - there’s just an implicit contract (implemented in the actual execution code) that checks this payment transaction, only executes the authorized transaction function, and only applies the transaction which results from computing it. Eventually, we can make this contract explicit with service commitments, but even before that, it will be obvious if this contract is broken (it would be a fork - compare e.g. if an Ethereum validator took your transaction and replaced some of the EVM opcodes with different ones).

1 Like
10

Reviving this as we need gas implementation soon:

So do I understand correctly that the initial flow can be something like like:

  1. User submits {tx_function, TX_gas} where tx_function evaluates to transaction TX and TX_gas is just a transaction.

Here are some basic limitations I would set on this: there are at most 4 resources.

In the good case there are two: the user consumed their N XAN as a single resource and creates N XAN in the controller.

The bad case is when the user has N+M XAN as one resource and needs only N for gas. Then they need to spend N+M XAN and create M XAN for them and N XAN for us.

Moreover, looking at TX_gas we should be able to decode the plaintexts to make sure that we actually receive the resources.

So either should have an RM version with transparent Compliance proving or a way for the controller to decipher the transaction using its key.

Hence here we assume the controller knows that the user is spending N XAN.

  1. We execute tx_function. If its gas surpasses N we fail.

  2. Otherwise, run TX and TX_gas verification in parallel. If both succeed (with global checks s well), do appropriate state change

Does this sound correct? From what I understand we cannot just compose here because balanced transaction composition is tricky.

1 Like
11

Note that a basic specification for the data structures involved in gas payment can be found here, and if we want to make substantial changes or additions to this design, we should alter the specs (which are owned by @vveiln).

This seems fine to me (this corresponds to the line “Checks that paymentTransaction is “simple”” in the specs page, this is a particular kind of “simple”).

The gas payment must be checked first (otherwise we might perform computation which the user didn’t pay for, if the paymentTransaction doesn’t verify). See the specs page (linked above) for the intended execution flow (feedback welcome if unclear / you see any problems).

2 Likes
12

The gas payment must be checked first
Yes, that makes sense, you are absolutely correct

Some notes from the specs:

It is unbalanced, contains consumed resources (gas payment sent) but not created (the receiver is not specified)

I do not think that’s what we want. If this is visible over the wire in the transparent case anybody can take this and balance out themselves. While if the payment is shielded, creating proofs on-chain will take too much computational time. The user should instead create a transaction that sends stuff to us (specified Heliax acc) directly, signing over the entire action, so that nobody would be able to balance the transaction on their own.

The problem is: how to make sure that the controller does not just spend it without executing the appropriate tx.

but not created (the receiver is not specified)

That cannot be the case as we may need to split our resources - as I mentioned - may need to be split. Moreover, yeah, I think we should forward it to our specified identity directly.

  1. Execute paymentTransaction (apply the state changes).

At which timestamp should that happen? Seems to me that we should bundle up both transaction and transaction with payment at one timestamp if both succeed. i.e. we should only do the state change after checking the transaction function.

If succeeded, we commit/nullify whatever is in the tx and tx_with_payment

Otherwise, just commit/nullify whatever is in tx_with_payment

re gaslimit field

Do we need it? Shouldn’t it be availiable from the payment transaction itself? Whatever the user is willing to spend, that’s the gas, assuming we have a unified token to pay for it or some uniform way of conversion of any resource from payment to gas

re shielded payment

How do we figure out that a user actually is willing to spend the specified ammount of tokens to pay? Ciphertexts?

1 Like
13

There are ways to prevent this but they depend on how exactly the system is organised. For example, specifying a whitelist of executors.

Shielded payments wouldn’t work this way anyway. You can’t encrypt a payment if you don’t know who the receiver of the payment is.

This could work in the context of RP, but it doesn’t scale well. However it might be a good idea to design a payment application that serves this role.

If that happens, is it publicly verifiable? Can we tell if a transaction wasn’t executed because the controller didn’t want to? If yes, it might be good enough.

We can explicitly specify this example in the specs.

tx_with_payment already contains both the state change tx and the payment tx, so there are no transactions to bundle up

14

Does this actually help? You submit a payment over the wire for a transaction as {tx, payment}. The controller (even if whitelisted) knows that this payment will be for him and will most probably suceed. Why cannot it just update state transferring the payment but never executing the transaction? Is this like a trust assumption: you assume that whoever you sending it to will not spend it without executing your tx alongside it?

I guess you answer this in the other section, I address it below.

Well, depends on what you mean by publically verifiable. The user can scower the longs and at some point see that his token was consumed as its own tx and not as payment.

I guess we can sorta agree that gas costs should be negligible to the point that the user should be happy with a trust guarantee that if we steal something from him at least he will know about it? :slight_smile:

Sounds funny

I see, true.

Does this have to do with resource plasma? I mean, sending things to Heliax specifically yes, that is for a centralized anoma controller. At the same time maybe we can decide on gas to be a burning measure where we do want a centralized account to be used for burning. Here it seems to be a policy decision, I dunno.

But could you elaborate what you mean by the payment application? What do you imagine it to work like?

Typo. I meant if tx_with_payment = {tx, payment} we put the nullifiers/commitments of both tx and payment at the same timestamp. Otherwise, we only commit state in the payment

1 Like