Minor updates for SLP-1. (#1581)

I've added a section on the anticipated long-term impact of the change and moved the text/sections around a bit.

limits/slp-0001.md

@@ -14,20 +14,22 @@ This proposal suggests increasing the per-transaction and ledger-wide limits for
 
 This proposal also suggests increasing the Soroban event size limit to accommodate events containing message payloads of > 8KB for use with the Axelar Interchain Amplifier protocol.
 
-## Rationale
+## Goals Alignment
 
-### Identify Resources in Demand
+Increasing the events and read/write ledger entry limits is a necessary step to support existing protocols and enable future innovation on Soroban. This adjustment aligns with Stellar's goals of facilitating efficient and scalable financial services, providing tangible benefits to developers and users without compromising network integrity.
+
+## Limit Change Rationale
 
-#### Read/Write limits
-Developers are encountering limitations with current read/write ledger entry limits when building advanced protocols on Soroban. Specific use cases include:
+### Ledger read/write entries per transaction
+Developers are encountering limitations with current per-transaction read/write ledger entry limits when building advanced protocols on Soroban. Specific use cases include:
 
 - **Hoops Finance**: Account contracts managing liquidity across multiple Automated Market Maker (AMM) pool contracts require calling multiple contracts resulting in many reads during auth and gathering data. Current limits force inefficient workarounds and data bloating.
 - **Soroswap**: Swap aggregator contracts performing path calculations need to read from multiple contracts simultaneously. Existing limits restrict the number of hops, limiting the effectiveness of swap routes.
 - **Yieldblox and Blend Protocol**: Lending platforms aim to support additional collateral assets face constraints due to ledger entry limits, hindering the expansion of collateral options.
 
 Increasing these limits will directly benefit these protocols by allowing more efficient and natural implementations without resorting to complex or inefficient solutions.
 
-#### Events limit
+### Event size per transaction
 
 Squid Router is reporting occasional message payloads of 7KB for their cross-chain swaps. This indicates that a significantly complex swap could be untenable on Stellar due to the event size limit.
 
@@ -36,32 +38,32 @@ Although the Gateway itself only stores a hash of the message payload, it needs
 - It adds a new data availability assumption: that some Relayer has stored the message payload off-chain.
 - It negatively affects UX, as individual apps will have to compute and post the payload to be sent to some relayer API.
 
-### Desired Limits
+## Proposed Limits
 To meet the demand, we propose the following increases:
 | Resource       | Current Per-tx | Proposed Per-tx | Current Ledger | Proposed Ledger | Ratio (Ledger/Tx) |
 |----------------|----------------|-----------------|----------------|-----------------|-------------------|
 | Read Entries   | 40             | 100              | 200            | 500             | 5                 |
 | Write Entries  | 25             | 50              | 125            | 250             | 5                 |
 | Events Size    | 8096           | 16192           |                |                 |                   |
 
-By raising the per-transaction read entries from 40 to 100, contracts can perform more extensive operations within a single transaction. Ledger-wide limits are adjusted accordingly to maintain the crucial ledger/transaction ratio of 5x, ensuring network performance remains stable.
+By raising the per-transaction read entries from 40 to 100, contracts can perform more extensive operations within a single transaction. Ledger-wide limits are adjusted accordingly to maintain the ledger/transaction limit ratio of 5x defined by the SLP process in order to ensure fair ledger resource distribution among multiple transactions.
 
 
-### Evaluate Proposed Numbers
+## Evaluation
 
-#### Benchmarking
+### Benchmarking
 
 - The benchmarking was done using the apply-load command in stellar-core. The version we're using is currently in a branch as we make improvements to it (PR and branch with changes on top of that PR).
 - The benchmark populates the bucket list with 9 levels of data, applies 100 ledgers with Soroban transactions that use as much of the resources available as possible, write meta to a file, and then output performance related data. The tool outputs a lot of information, but we only show max, min and mean ledger close times in this doc.
 - The benchmarking was done on an AWS c5d.2xlarge instance using docker so we could limit the iops for a given run using the --device-write-iops DEVICE_NAME:10000 --device-read-iops DEVICE_NAME:10000 docker options. We limited the runs to 10k iops.
 
-##### Evaluation of current limits
+#### Evaluation of current limits
 - Benchmark transactions configured with 100M instructions, 25 RO entries, 15 RO entries, 500 bytes per entry, 100 80-byte events. 5 TPL.
 1. Max ledger close: 197 milliseconds  
 2. Min ledger close: 181 milliseconds  
 3. Mean ledger close: 187 milliseconds
 
-##### Evaluation of proposed limits
+#### Evaluation of proposed limits
 - Benchmark increase to the entry limits. Transactions configured with 100M instructions, 50 RO entries, 50 RW entries, 240 bytes per entry, 100 80-byte events. 5 TPL.
 1. Max ledger close: 215 milliseconds  
 2. Min ledger close: 199 milliseconds  
@@ -72,17 +74,18 @@ By raising the per-transaction read entries from 40 to 100, contracts can perfor
 2. Min ledger close: 176 milliseconds
 3. Mean ledger close:  181 milliseconds
 
+### Long-term protocol impact
 
-### Nominate the Proposal
+- The increase amount of entries read/written per transaction doesn't have any significant long term impact given the moderate absolute number in this proposal. The overall number of reads and writes only has impact at the ledger level and the per-ledger limit may be decreased in case of performance degradation in the future.
+- 2 times per-transaction event size growth in theory leads to proportional (2x) growth of the maximum event size per ledger, which will affect all the future protocol versions that might also come with organic increase of the transaction volume per ledger.
+    - However, in practice not every transaction will emit 2 times more event data and thanks to the event fee there is an incentive to not emit unnecessary events.
+    - Thus the expectation is that the change will mostly affect certain protocol (like bridges) and likely won't affect the overall volume of events significantly
 
-We would like to first make the settings increase to testnet so the proposers can test their scenarios. After successful testing and validation, we'll nominate this proposal for a vote by the validators, providing detailed evaluation results to support informed decision-making.
 
-## Conclusion
+## Evaluation Outcome
 
-The entry limit increase (187 milliseconds to 205 milliseconds) is acceptable, but close to the 250ms limit to applying soroban transactions.
+The overall impact of the proposed changes on the ledger close time (187 milliseconds to 205 milliseconds) is acceptable given that we increase the ledger I/O limits more than 2x. The time is still below the boundary of 250ms dedicated to Soroban transaction processing currently. There is also no significant long-term impact.
 
-The event size increase has a negligible impact on stellar-core. This makes sense because core just writes events to meta. The impact on downstream meta consumers is more important to measure.
-
-Increasing the events and read/write ledger entry limits is a necessary step to support existing protocols and enable future innovation on Soroban. This adjustment aligns with Stellar's goals of facilitating efficient and scalable financial services, providing tangible benefits to developers and users without compromising network integrity.
+The change can be considered acceptable and safe for the network health.
 
 ## References