CIP-0164 | Re-introduce additive per tx Plutus limits

[ch1bo]

This is a request by @Quantumplation, which has the potential of increasing utility of Cardano through Leios, but at the cost of lower adversarial stake tolerance (of dApps that rely on it).

Still WIP as more places would need updating, but wanted to record the request and start the discussion.

[ch1bo]

PR that removed them originally: cardano-scaling#28

[Quantumplation]

Here's my justification, in case @colll78 wants to have a discussion;

Transaction chaining can be used to work around tx limits, this can be damaging to UX / capital efficiency. Losing atomicity means something can happen in between your steps, changing whether the second half is even viable.

There are plenty of cases where I'd be happy to pay a higher per-unit rate to go above my tx limits so I could fit more into one transaction, such as splitting a single large trade across many potential routes to ensure it executes atomically and gives the user the best price.

We can't raise tx limits above the size of the praos block limits generally, because then dApps might be built that depend on those limits, and can be denied service when Leios throughput doesn't materialize. By default we want to ensure that txs can always fit into praos blocks.

But, I think an opt in ability, along with good education for new dApps, solves this; If there is an explicit tx field, either a boolean that indicates "yes, I'm confirming that my tx is too big to fit in a praos block and Leios blocks may not always bee available", or an integer field that explicitly confirms the extra fees your paying for the extra space, would allow dApps to opt in to this extra capacity, and also teach them (at the time of building the transaction, and at the time of audit), that relying on this is unsafe.

Thoughts?

[rphair]

Marking Triage just so all editors know it's here @ next meeting (https://hackmd.io/@cip-editors/137) & likely agree to simply observe discussion until @Quantumplation @colll78 @ch1bo (+ any others) confirm it's concluded. cc (co-authors) @will-break-it @bwbush @pagio (please tag more who may be interested)

[rphair]

Confirmed as a valid update at CIP meeting today & that editors will simply monitor discussion to see when it stabilises on something to merge.

[fallen-icarus]

At a high level, I like this idea. I always prefer giving users choice as long as the risks are clear. It is effectively optimistic tx capacity.

Not really relevant to this discussion, but it makes me wonder if there are dApps/L2 designs where it is safe to only be possible with the optimistic capacity. Not all dApps need to be considered mission critical so what is wrong with these non-critical dApps being disabled in the pessimistic state? Maybe that is actually desired behavior.

[ch1bo]

But, I think an opt in ability, along with good education for new dApps, solves this; If there is an explicit tx field, either a boolean that indicates "yes, I'm confirming that my tx is too big to fit in a praos block and Leios blocks may not always bee available", or an integer field that explicitly confirms the extra fees your paying for the extra space, would allow dApps to opt in to this extra capacity, and also teach them (at the time of building the transaction, and at the time of audit), that relying on this is unsafe.

@Quantumplation Does this imply that we would need to have this field before we can safely have a higher limit on EBs? I'm asking because then, speculatively adding the protocol parameter witout the tx body change is moot.

[lehins]

"yes, I'm confirming that my tx is too big to fit in a praos block and Leios blocks may not always bee available"

This suggestion has similar issues as tiered pricing does: such transactions would interfere with Praos block production simply be sitting in the mempool at the head of the queue. So this would need to be solved in some way, like parallel mempools one for Leios and another for Praos blocks, etc. Tiered pricing for Cardano mempool is still, as far as I know, not a solved problem.

Another issue is that even if a Tx is only optionally destined for Leios, such a feature could compromise safety of Praos: in case there is any sort of issue that could affect Leios and production of EBs an adversary would be able to fill up the whole mempool with transactions that can't go into an RB, thus locking up the whole of Cardano until Leios is back and operational.

I strongly believe we need to have exact same limits on per transaction basis, regardless which block type they got into. There might be a future where this is no longer going to be the case, but as far as the timeline for the current implementation plan for Leios goes, IMHO, this definitely out of realm of being possible.

[Quantumplation]

The mempools are being completely redesigned for Leios regardless, and this seems like a relatively easy thing to do in a number of ways. Of course the devil is in the details, but that shouldn't deter us from shooting for building the highest utility chain we can.

I am totally fine if these larger txs are "second class" citizens, in the sense that they are deprioritized relative to normal sized txs; in separate mempools; dropped relatively quickly, costed superlinearly above the limit, etc.

Users always have the option to avoid this, and right-size their transactions (breaking them up into smaller txs) if they need to avoid such second-classery; dApps are sufficiently warned not to rely on this behavior; etc.

And ultimately, the "RB vs EB" split isn't what's important to me (it just seemed like a convenient way to unlock larger txs); if they have to be the same across block types, but we can enable larger txs by adding a superlinear opt-in; or a collateral opt-in; any of these are acceptable solutions from my perspective.

But the target for these are dApps that can easily rebuild and resubmit them if they don't land in a block for some reason; they can make up for the transaction fees through the volume or quality of service they provide; etc.

It is very very very valuable, to all kinds of use cases on Cardano, to find a way to create the optionality for larger transactions, because the current limits are very constraining, and are a deterrent to the exact kinds of businesses and economic activity we need on the chain. It makes it harder to build L2s, because complex actions have to be split across multiple transactions, which in turn increases the surface area of attack; it makes it hard to build highly composed DeFi transactions (the kind of thing that actually differentiates blockchain from TradFi), etc.

[Quantumplation]

@Quantumplation Does this imply that we would need to have this field before we can safely have a higher limit on EBs? I'm asking because then, speculatively adding the protocol parameter witout the tx body change is moot.

I think yes; And I'd push for it in Dijkstra, even if Leios launches with the protocol parameter disabled at first while we evaluate the impact more thoroughly, so that it's in the new script context, dApps can be designed and built with it in mind (tentative availability and all), and it isn't another 3 years before we can hard fork, add it, and only then start adopting it in dApps.

[lehins]

@Quantumplation I am not arguing that something like this would not be useful.
I am telling you that this idea introduces a significant constraint on the mempool that might not be feasible to implement in the time constraints that we have, because you propose the problem, not the solution to the problem. My concern is not introducing second or third class citizens to the system, my concern is the system as a whole.

Point that I am trying to get across is that transactions in the mempool will often depend on same parts of the ledger state, i.e. they can be interdependent. So, let's say a potential solution we employ is to have two separate mempools: one for RBs another for EBs. That would mean as soon as an RB is minted, then the whole sequence of transactions in the mempool for EBs would have to be revalidated. Granted scripts would not need to be executed, but phase 1 validation and ledger state application would have to be performed all over again. EBs will be big, so this redundant computation would likely be prohibitively expensive. There might be more clever solutions, but at this point I personally haven't heard of any that would work without a massive amount of work. Please, if you or anybody else has one, I am all ears.

The mempools are being completely redesigned for Leios regardless,

Unless you can delay the deadline for Leios delivery, we need ideas on how to simplify this redesign, not complicate it even more.

[ch1bo]

The mempools are being completely redesigned for Leios regardless

This is not exactly true. We can have a few hundred TPS without major redesigns (a first attempt here); this is largely also due to its current simplicity. We had discussed DAG-based designs, which Dingo is also exploring, but nothing done and dusted. Keeping separate mempools with differing semantics would probably be the most sensible approach. Either way, these kinds of changes are objectively more work to get ready before the hard fork.

@Quantumplation could you attempt to specify the transaction body change you imagine? We would need that either way in Dijkstra, even if we ship this turned off (= the additive parameter set to 0)

---

@Quantumplation The obvious alternative is to raise the tx limits to the praos block limits, but I suppose that is not sufficient for you?

[Quantumplation]

No that would be perfectly acceptable to me, but whenever I've brought that up it's been shot down too.

In general, the way some people engage with this process is very much engineered around telling people building on the chain what's not possible and stopping there, making those with the pain points shoot in the dark until they happen on something acceptable; In my mind, a healthy process would instead focus on understanding the problem they're having and helping them find a solution for it. Every time I engage hoping it will be different but this attitude persists, so...

I tried to convey this in my previous responses but I'll be ultra ultra explicit: I and other builders want to submit transactions that use significantly more memory, cpu, and block size than is allowed today. The useful work we can do per transaction is very small compared to many other chains. Splitting and tx chaining is a painful workaround that hurts usability, safety, and capital rfficiency. I do not care what form it takes, and there is a very very rich design space to achieve that goal. I've proposed half a dozen or more:

• just raising the limits
• charging super-linearly for costs above the limit
• allowing bigger txs in EBs alone
• allowing that but with an opt in flag
• allowing multiple txs to be mutually dependent
• allowing some per-epoch budget of larger txs
• etc.

Some of these are not workable, are undesirable for one reason or another, or add extra complications. I am not advocating for any one of them in particular, nor am I advocating for anything that destabilizes the chain, obviously. I am trying to provide handholds that others can grab onto and help me find a solution that would be acceptable with the minimal amount of work and within the time constraints we have. The default answer should be "ok, I understand the pain, I respect it as real because it's coming from someone really trying to build a business on top of the chain, what is the best possible thing we can do to help alleviate that pain point and make their and other businesses successful."

This mindset and inability to recognize, understand, and help solve real world problems to make us competitive is killing Cardano, IMO.