[SLP-4] - Discussion thread

[dmkozh]

This is a discussion thread for SLP-4. This SLP proposes to increase most of the per-ledger and per-transaction resource limits about 2x, and also reduces the non-refundable fees 4x (originally proposed here: https://github.com/orgs/stellar/discussions/1831#discussioncomment-15521811)

[orbitlens]

Do you also plan to increase txMaxDiskReadEntries? Having 200 txMaxWriteLedgerEntries with only 100 txMaxDiskReadEntries (current value) doesn't make too much sense. Would be nice to have 400 txMaxDiskReadEntries (or at least 300). Otherwise it narrows the potential applications range for usage of those 200 writes per tx to a few very specific scenarios (inserting new data without reading previous values), while most of Soroban transactions update the entries.

[dmkozh]

Yeah, that's probably reasonable to set it to 200 for the sake of consistency. Just to be clear, since p23 only classic entry reads and Soroban entry restorations are counted towards 'disk' reads. There is no explicit limit for the number of Soroban entries accessed, though it is capped by the maximum overall transaction footprint size (200 entries with this SLP).

Otherwise it narrows the potential applications range for usage of those 200 writes per tx to a few very specific scenarios (inserting new data without reading previous values),

So for this example it is possible to update 200 Soroban entries (read and write them) even with the settings as proposed, as Soroban reads are normally not disk reads. But again, we'll increase the disc reads to 200 as well, so that you could update up to 200 classic entries at once as well.

Going to 300/400 with the footprint size could be nice, but that's more than 2x increase and there can be some subtle long-term performance impact (since the total size of all the footprints is only bounded by the number of transactions in the ledger), so additional research and benchmarking would be required - I can't say for sure if it's going to cut it for this SLP.

[orbitlens]

Probably the majority of Soroban calls in that way or another involve transferring funds to/from account trustlines, which are classic entries. 200 reads per tx might be enough, not sure. Do you have any stats on read/write ratio for an average transaction? We never tried to gather such statistics.

[dmkozh]

Do you have any stats on read/write ratio for an average transaction?

I don't have a disk read entry count number handy, but I can see that usually we have just ~20KB of disk reads per ledger, which is <200 Classic entries total per ledger. So I would say 200 entries per transaction should be enough for the time being.

[AlphaDZ47]

Good job 👍 Thanks 💜

[Clawue884]

Bagaimana perubahan limit footprint & disk reads ini mempengaruhi desain Oracle (off-chain feeder → on-chain commit) yang update banyak entri per transaksi

Apakah ada rencana jangka panjang untuk menyamakan treatment antara Soroban entry reads dan Classic entry disk reads, agar developer tidak perlu mikir dua model biaya/limit yang berbeda