Revisiting approach to multi-operation transactions

[gaunt sparrow]

We've recently added an ability to run multiple soroban operations per transaction. Every operation is 'standalone' and uses its own ledger footprint.
Now that we're adding more resource accounting (such as CPU instructions and IO), I wanted to revisit this.
On a high level I see two options:

• keep operations standalone, i.e. add the resource consumption data to the operations similar to footprints. it makes it easy to batch operations together. it is a bit more expensive though, as the transaction size would be larger. there also will be some double-counting (e.g. if you write an entry and then read it in the next operation, you'd need to pay both for read and for write). the transaction itself will be a bit larger as well (though the difference is marginal)
• move everything (including footprints) to the transaction level. this could make multi-operation transactions cheaper if we eliminate double-counting. another benefit is that resources are carried over between the operations, which is a bit better for operations with volatile cost. however, this might be trickier implementation-wise - e.g. I'm not sure if we can get rid of IO double-counting while also emitting the sane per-operation ledger change meta. so it seems to me that this approach would work better if we came back to the idea of only allowing a single operation, but allow it to invoke multiple host fns. this way we'll get all the cost-related benefits 'for free'.

I've also considered in-between options (like do per-operation footprint, but tx-level instructions), but I don't like them because of inconsistency.

any thoughts?

cc @distant harbor @carmine vigil @fading tulip @digital oar @vague bear

[half raft]

This is great news, I did not know it's been implemented.

[gaunt sparrow]

yeah, somehow almost no-one knew and hence it's not properly supported in preflight yet (so you'd need to do 2 preflight calls)

[half raft]

I knew we talked about it but didn't think it was possible yet. Maybe it will make more things possible 😄 how would i do 2 preflights won't that give me two simulations and then i would need to concatenate those? Sorry You guys improve faster than i can learn 😆 not complaining

[gaunt sparrow]

yeah, you'd need to concatenate these for now (hopefully should be fixed next release)

[digital oar]

What does the "resource consumption data" in "add the resource consumption data to the operations similar to footprints" mean? Is it the declared resource limits by each operation?
Overall I think the budget-sharing approach (#2) makes sense.

[half raft]

do you happen to have an example of how to do the concat? Is it literally just like adding them together somehow?

I need to look at how the footprint validation works

[gaunt sparrow]

just push the operations into the operations vector

[gaunt sparrow]

add fields like 'instructions' to the operation xdr. this will declare the resource limit for that operation only (similar to how the footprint is applied to that operation only)

[half raft]

okay i must have been doing it wrong I will go back through my code on it. I wish i could get soroban-client to work in runkit btw

[carmine vigil]

I think this would make it difficult for systems to associate things like fees and other things with operations. It sounds like we've discovered that having separate operations has an inefficiency. Instead of altering the behavior of operations, we could also remove multi-op for soroban, and allow multi-invocation inside a single op which preserves existing operation semantics.

[gaunt sparrow]

yeah, this seems like a simple option while also being cheaper overall

[vague bear]

I think that resources, fees, footprints should be expressed per transaction (so I am in violent agreement here): while they're computed per operation, at the core layer we can only reason at the transaction layer when deciding to include a transaction in a ledger (same with limits). Also, footprints can represent a significant overhead in terms of transaction size, so the less duplication, the better.

As far as using what we call operations today or moving to something more Soroban specific that allows some level of batching, I don't think it matters much -- are there implications wrt operation source accounts (in particular right now we allow mismatch between the various source accounts)?

[digital oar]

One thing to consider is we currently do not allow mixture of classic and SC operations in a transaction. I couldn't find it stated in the CAPs but is currently implemented, I wonder if this has been discussed before.
If we ever consider mixing classic and SC ops in the same transaction, then I think the "one invocation per operation + tx level footprint & limits" makes more sense as it allows leveraging the operation framework for batching and validity checking.

[vague bear]

we will not mix: this breaks parallelism

[half raft]

oh darn that's why i couldn't make it work

i was trying to add an invoke after a create account op

this morning i wasted an hour on that

[gaunt sparrow]

If we ever consider mixing classic and SC ops in the same transaction
we don't - soroban and classic will be in different phases (otherwise we won't ever be able to run soroban in parallel)

something more Soroban specific that allows some level of batching, I don't think it matters much

as I've mentioned, keeping the operations is trickier implementation-wise. if we want to preserve the operation semantics, then we need to emit the proper meta for every operation to track what are the entries created/deleted. so on one hand we need to compute the effects of every operation, but on the other hand for the sake of deduplication we need to keep track of the modified ledger entries at the transaction level. basically this breaks the current design approach where the only way the state is shared between the operations is via ledger; we'd need to do a bunch of stuff at transaction level. there is also overhead of passing the footprint and other data back and forth for every operation.

[vale phoenix]

A multi-invoke operation seems to be the path of least resistance. Any strong opposition to that?

[gaunt sparrow]

just to clarify the operation source account concern - it indeed won't be possible to change the source account between the invocations, but that's not a huge issue as the signatures can be passed as a part of the auth payload (that's a bit more work for the wallets, but I'd hope they support the auth next payloads in general, besides allowing to signing the transactions/operations only)

also in most of the cases invoker auth still can be used (e.g. when an account uploads and deploys a bunch of contracts, which is one the main use cases for multiple operations in general)

[distant harbor]

Yeah moving to multi-invocation makes sense. The initial reason for going multi-op was due to the ease of implementation, but that's irrelevant if it makes the rest of the implementation more complex. One very minor thing to note is that we won't be able to split up InvokeHostFunctionOp into multiple operations. I think we briefly discussed this a while ago.

[delicate sparrow]

There are two questions I have that I hope are relevant. If we do a batch payment to 100 people (tokens or XLM) does that work better in one model vs another? If we eventually add parallel processing where separate cores process separate transactions, would they parallel process better under one model vs another? Parallel processing and batch transactions are both common innovations.

[gaunt sparrow]

my hunch would be that the classic route will be cheaper

in terms of the parallel execution my hunch is that simple operations like payments are IO bounded, hence it shouldn't really matter as to whether they're executed in parallel or not

also batching currently has an inherent issue of failing the whole tx due to one operation failure. with soroban you can build a batching contract that gracefully handles the failures.

[gilded geyser]

Given that the classic and soroban execution paths are completed separate, there is no functional deficiency here in moving multiple invocations into a single operation. I think that only practical downside is that it looks awkward.

[carmine vigil]

There is one functional deficiency: inability to use different invoker auth (source account auth) for each invocation. But it is minimal.

[half raft]

is there a reason that if you have multiple invocations in one op that you can't have multi-ops with different invocations to use different auth for each one?

[gaunt sparrow]

yeah, but since you need a signature either way, there is no impact in terms of cost

can't have multi-ops with different invocations to use different auth for each one?
every host fn invocation will have it's own ContractAuth vector, so you can do arbitrary batching. the only thing not supported is reusing the operation signature for invoker, which can be achieved via signing contract auth directly instead

[flat wave]

If we only allow a given transaction to be either Soroban or classic, how is this distributed within a given ledger? Is it fixed based on the metering config (that presumably allocates a set number of Soroban vs classic txns)? Are there sequencing requirements for a set of Soroban transactions within a given ledger (and is every Soroban operation atomic or can it have invocations that span across multiple operations within a given transaction)? Just trying to wrap my head around this.

[gaunt sparrow]

this is still WIP to some degree. we'd like to utilize the ledger space as much as possible and likely will be biased towards classic txns. so roughly speaking the ledger would contain up to X instructions worth of soroban txns plus, say, up to 1000 classic ops, with the number of ops reduced depending on soroban utilization

the transactions do preserve the transaction semantics (i.e. they're atomic)

soroban will probably be executed after classic at apply time

[half raft]

that topic has me a bit confused about how the orders will be chosen

[gaunt sparrow]

orders have nothing to do with soroban

so no changes there

[half raft]

not dex orders but order of operations of how transactions are processed ea. say there are 500 pending tx and 200 are soroban invocations and 300 are filled with classic ops.

[gaunt sparrow]

ah, sorry

no significant changes here as well - the apply order will be deterministcally randomized (using the hash of the whole tx set). but the overall order will be all classic txs, then all soroban txs

[half raft]

thanks so is that what is preventing having a classic operation and a soroban invoke operation in the same transaction, is there any chance that will ever be possible?

[gaunt sparrow]

in theory if we migrate all the classic ops to soroban fee and execution model (which I'm not sure if ever happens in practice)

[sullen wagon]

@gaunt sparrow Hello! Going back to this thread 😅

Is it possible to add multiple operations in one transaction in soroban? or will be possible at some point?

I'm trying to add a transaction without having to wrap a smart contract into another contract or modify/upgrade the contract to add the functionality