Update gas limit for Jakarta

[novalis]

• Analysis: I noticed that on my test net, which is running proto alpha, that payment operations were running out of gas.

Looking at the tezos/tezos git logs, I see that [gas was upated for J] https://gitlab.com/tezos/tezos/-/merge_requests/4840

Now more gas is required for (at least) distribution to tz1 addresses. Per the logs: /trd/logs/app.log:2022-04-29 18:25:11,950 - consumer0 - DEBUG - Payment to tz1eawTP2ueRCqsYZq3DebwW9PkthdCqcZa8 requires 1,451 gas * 0.10 mutez-per-gas + 0 mutez burn fee

• Solution: Update the gas limit.

• Implementation: A one-liner. It would be nice to have this configurable per-network, but given that the difference here is 30 gas (which is ~0.003 tez, or less than a penny at current prices), it hardly seems worth worrying about. In the long run, if gas gets expensive, then bakers will move to TORU for payouts.

• Performed tests: Tested on a private chain at protocol Alpha.

Work effort: 1 hour (finding, changing, testing)

[nicolasochem]

Thanks @novalis , will this break payouts on proto I? Also, when there are a lot of accounts to pay out, we normally divide them into batches, and increasing this value for one payout may make batches too big and go over some proto limit. To address this, we would have to make smaller bundles.

Ideally we would find a way to make this work on I and J together and merge now, so when migration to J comes, more bakers will have upgraded their TRD and won't run into this problem.

[nicolasochem]

Thanks @novalis , will this break payouts on proto I? Also, when there are a lot of accounts to pay out, we normally divide them into batches, and increasing this value for one payout may make batches too big and go over some proto limit. To address this, we would have to make smaller bundles.

Ideally we would find a way to make this work on I and J together and merge now, so when migration to J comes, more bakers will have upgraded their TRD and won't run into this problem.

[novalis]

I don't expect that this will break payouts. The hard operation size limit is stored in HARD_GAS_LIMIT_PER_OPERATION, so it should split things into the right number of operations already. And I expect that this will work for both I and J -- it'll just overpay by less than a penny per destination (or per something anyway) on I.

[jdsika]

I think this can work but I will check the limits again