What if txs that alter more than rewards and UTxO were restricted to direct inclusion in a Ranking Block?

[nfrisby]

We've been discussing conflicting txs for a while, and one of the persistent asterisks within our discussions has been that we know there are other ways txs could conflict besides consuming the same UTxO or withdrawing the same rewards, but still we've only been discussing conflicts in terms of UTxO and/or rewards.

Just a brainstormed idea: maybe any tx that does more than consume UTxO, withdraw rewards, and create new UTxO might be prohibited from Input Blocks. Instead, they'd be circulated separately and could only be included directly within Ranking Blocks? The formal property might be something like

A tx X must not be included in an IB if there exists some other tx Y such that X and Y do not share any inputs or withdrawals but also X and Y do not commute. This tx would instead need to be directly included in the Ranking Block (since certificates are smaller than today's maximum Praos block size.)

I haven't thought through it more than that.

[nfrisby]

@WhatisRT maybe I'm obviously overlooking some problem with this sort of thing that you (or someone else) could demonstrate in a paragraph-sized reply?

[Quantumplation]

This was brought up at the edi workshop, and I think it's a good idea. I think the main concern at the time is that Duncan really wanted the property, after a transition period, that txs only occurred in input blocks.

If you have that property, then you don't need to have finished reconstructing the ledger state to produce a ranking block, since you can rely on "a majority of the stake has endorsed the EB, so if I produce a ranking block referencing it, it's not likely to be invalid, and I'm not gonna get reorged out and lose my block rewards".

This would also mean we can make Praos blocks more frequent, etc.

I don't think it'd be the end of the world to lose that property.

But also, what would the behavior be with respect to utxo conflicts?

Say you have some transaction that deregisters a stake address or donates to the treasury, two of the things that @WhatisRT said could conflict that aren't utxo or account based things.

But, it spends a script utxo, and you also build a transaction that spends the same script utxo.

One goes into an input block and the other goes into a ranking block while the input block is propagating.

Now your ranking block invalidates the work done to produce the input block. So in theory you could scale that up: one RB tx that invalidates 400 IB txs.

[nfrisby]

Thanks for the reply.

But also, what would the behavior be with respect to utxo conflicts?

That's the open question that still remains, even among the txs in the IBs. My goal with this idea is simply that our discussions of utxo-based conflicts no longer need to have a disclaimer/asterisk on them about the fact that there are other ways txs can conflict.

[ch1bo]

I like the idea if this constraint gives us freedom in other places of the design!

In particular one thought occurred to me:

If IBs would only be grouping transactions that evolve the UTxO ledger state, the whole IB could be reapplied very cheaply to the overall ledger state. That is, the whole IB would have a set of inputs consumed and outputs produced. If all inputs are present, the resulting UTxO' = UTxO \\ inputs <> outputs.

That being said, there is at least the example of de-registering stake addresses and transactions that withdraw from stake address to be conflicting. So maybe the constraint is even further.. only non-reward interacting txs may go procssed by leios / in parallel / go into IBs? (i.e. all non-account-based things?)

[WhatisRT]

I honestly don't see non UTxO conflicts as a big deal anymore. I don't think they need any special treatment other than a bit of logic to check for the actual conflict (which we also need in the UTxO case) - and if we prevented them from being included in IBs we'd have to implement logic that touches the same places except that it doesn't look at the state. That's easier, but I'm not sure it's that big of a reduction in complexity.

My preferred notion of conflict is this: a transaction that cannot be applied to the current ledger state but is otherwise valid. I don't think it matters much whether it could have been valid with a different transaction order or not. Maybe we can provide some sanity checking for preventing accidents when you submit a transaction so that in practice conflicts are typically caused by reordering, but I think it's totally fine to call a transaction that deregisters a non-existant stake credential a conflict, no matter if there is a transaction around that registerst that credential or not.