Allow transactions to use larger notes, args, programs.

[jannotti]

Status

Today, notes are limited to 1k. Args are limited to 2k. Programs are limited to sum to 8k.

Expected

Several different improvements might be made. We might pool that space, as we often do, so you can use 11k across all three things. But the reality is that using these fields consumes a lot of space compared to normal transactions, and perhaps we should charge appropriately, even for modest usage. People sometimes get the idea to use huge transactions to store data, thinking - wow it's nice that archival nodes and indexers are paid for by someone else!

We should charge for this space, but probably should not change the cost for transactions that are legal today. There's no existing model for charging for block (not ledger) space, so we need one. Here's a proposal.

If a transaction exceeds any of the the above limits, its entire group enters "pay by the byte territory". Let's call such transactions Modern. We add up those three things and there is an extra fee per byte. So if you use a 2k note, and a 10k program, you will be paying some factor times 12k.

How much? I don't know, but for future compatibility with a changing MinFee, I would propose it is described as "X MinFees per Y Bytes". And I would start with "1 MinFee per 10,000 bytes" (which reduces to 1uA per 10 bytes.

The txn above would pay about 1200uA extra. That means it pays about double what a simple pay costs. That feels ok to me, but should be discussed.

Modernity infects inner groups. If your parent is modern, so are you.

There will need to be some limits, regardless of how much a txn is willing to pay. Very large transactions make block packing harder.

Solution

Dependencies

Urgency

[joe-p]

The proposed mechanism makes sense to me. I think it makes sense to start with a relatively small fee but over time we'd probably want to increase it. The main challenge for the ecosystem will be adopting to any new fee model. Once we get over the main hurdle of making fees more dynamic we'll have much more flexibility for increasing the amount down the road. Essentially it's probably best to separate the technical and economic considerations as much as possible.

I would also propose that we consider charging for other "modern" features beyond transaction size, such as new AVM versions, new txn fields, etc., but that's probably a separate discussion.

Modernity infects inner groups. If your parent is modern, so are you.

One challenge is that the inners that will be executed is not deterministic. You can simulate and estimate the size of transactions but it may actually be different during the real block eval. Although I suppose that's the same kind of problem we have now with non-deterministic execution so maybe that doesn't change much... but it is another potential foot-gun unless apps advertise their max fee and callers always pay that fee. Refund mechanism would be quite useful for this as well.

[jannotti]

I agree that refund mechanics should happen soon, but I also agree that this change doesn't move the needle much on that need.

In order to have refund mechanics, we first need to fix the two places where fees are "ambiguous".

1. Congestion charges are not part of the protocol. So a naive refund plan would refund them! I think we need to bring congestion on-chain.

2. Opt-in for incentive eligibility. It's not explicit. If you pay 2A in a keyreg, we assume it's for that. But it could be because you were talking to a congested node. Or, in the future contemplated by this issue, maybe your group is expensive, and you just happen to put the big fee in the keyreg. The point is that we don't know whether to refund it or not because there is no explicit field that says you're opting in.

Those are reasonably easy fixes. After that, we have to decide who to refund. There are many senders in a group. Refund pro-rata?

We also ought to offer a way to explicitly donate. Reti charges a high fee on purpose. It would be funny if the protocol gave it back! Maybe they should change to a pay directly to fee sink. @pbennett

[pbennett]

I would also propose that we consider charging for other "modern" features beyond transaction size, such as new AVM versions, new txn fields, etc., but that's probably a separate discussion.

@joe-p I definitely don't like what you're proposing here. IMO, the AVM should charge based on use and on collective cost to the network (of all node types). The resource usage (and future extra costs that we already have to pay through dummy transactions - but just turning into comparable extra reference entries in a single call) and opcode usage (w/ opups presumably going away as well -but we still have to pay for them) should already cover the 'costs'. More complex opcodes just have higher opcode cost. Saying, oh you want to use something 'new', even if its actual cpu/io cost is cheap(?) - I definitely don't agree with that.

We also ought to offer a way to explicitly donate. Reti charges a high fee on purpose. It would be funny if the protocol gave it back! Maybe they should change to a pay directly to fee sink. @pbennett

Do you mean in terms of users possibly 'overpaying' on transactions and instead of refunding just accept it to fee sink? I agree with that - it simplifies things anyway. If they pay X fees, it goes to the fee sink - period. Introducing a refund mechanism in an app call feels like it would break a lot of code that tracks algo movement and for what gain?
I've always kind of enjoyed seeing 'large block payouts' simply because someone added a new reti validator. Something kind of poetic about it. 😀

[joe-p]

IMO, the AVM should charge based on use and on collective cost to the network (of all node types)

I agree. I also think it's not controversial to say that if we want to incentivize node runners with block rewards we NEED to increase fees eventually. If we just bumped min fee, however, a LOT of stuff would break. Increasing the cost of new features is a way to increase net fee "income" while keeping all the existing apps running. We'd probably need to increase min fee eventually, but starting with new features is a way to gradually roll out higher fees

We also ought to offer a way to explicitly donate

Isn't that just sending a pay to the fee sink? I think trying to come up with a mechanism to conditionally send extra ALGO from the fee to the fee sink would add a lot of complexity.

If we are bringing fees in consensus I think we should do something similar to EIP1559. A base fee that is in consensus and set based on chain activity (increases as blocks get more full) and then a tip that goes 100% to the block producer. If we really wanted more to go to the fee sink we could split the tip between the block producer and fee sink like we do with fees now, but that leaves the door open to side contracts which seems less desirable in the long term.

[jannotti]

We also ought to offer a way to explicitly donate

Isn't that just sending a pay to the fee sink? I think trying to come up with a mechanism to conditionally send extra ALGO from the fee to the fee sink would add a lot of complexity.

Maybe. But right now, @pbennett (and others?) force a large fee when they want to "donate", not a pay to feesink. And, in fact, they have different outcomes. A large fee is split with the proposer immediately. A pay to the feesink is just a pay to the fee sink. I suppose a pay to the fee sink eventually gets paid to a proposer though.

I strongly believe a refund mechanism is necessary to have a reasonable programming model. For all @pbennett's complaints about developer ugliness, I can't believe he really mean this:

Introducing a refund mechanism in an app call feels like it would break a lot of code that tracks algo movement and for what gain? (emphasis mine)

The gain is tremendous simplicity for dynamic transactions. You can't help but be a little unsure exactly how expensive your group will be when it hits chain (b/c of congestions changes, or simply changes in behavior because of state changes that hit before your group does). So you add extra fee, knowing it will come back if not used. This is especially true if we get a "pay as you go" model for opcodes. @pbennett complains often about dummy transactions for opup. Well, what's the alternative? Surely it's "I paid some fee, I can just draw it down as I execute". But we can't expect perfect knowledge of the number of ticks your code will execute under changing block chain state.

Although I hate wasting block space to write down what has happened, any refund would surely end up in a new field of ApplyData, so that it can be easily tracked. And yes, surely some off-chain tracker will break, just as some must have for incentives. But any tracker using StateDeltas will just keep working.

But we are perhaps getting ahead of ourselves, I don't think it would be crazy to add this extra fee even without a refund mechanism. These things are quite predictable (at the top-level, they must be known - they are right there in the transaction).

Finally, I agree we should only be charging for things that cost time / space for execution. However, it is sometimes reasonable to say "If you use new feature X (which could be an AVM version), then I know you are recent enough to understand some new change, you can be processed under a new set of rules, which might cost more".

[pbennett]

My dismissal over pay +refund mechanisms were mostly out of concern of 'too large of a change + new behaviors' and how that has often caused things to never actually change. Changing of existing expectations is always raised as a kind of hard uncrossable line and what you pay in fees not being what is removed from your account seems like a big change to me. If it's literally all on the table and seen as doable on a reasonable timeline, I'm certainly game to discuss it. 😀

Right now I don't currently mind paying 'extra' if the calculations on opcode requirements aren't correct - and if its extra - I see it as a going to the proposers and thus health of the system (with boosted rewards feeling like they're quite rapidly diminishing...). If we can be more exact about it and allow overpayment and refund based on what's 'actually' used I'd be fine with that too. 😀