SLP-0001 (#1577)

limits/slp-0001.md

@@ -0,0 +1,88 @@
+## Preamble
+
+```
+SLP: 0001
+Title: Increase Events and Read/Write Ledger Entry Limits for Soroban 
+Authors:  Tim Baker, Attiss Ngo (Interop Labs), Mootz12 (Blend Protocol), Siddharth Suresh <@sisuresh>
+Consulted: Soroswap, Hoops Finance, Yieldblox, Blend Protocol
+Status: Draft
+Created: 2024-12-04
+```
+
+## Summary
+This proposal suggests increasing the per-transaction and ledger-wide limits for read and write ledger entries in Soroban smart contracts. The adjustment aims to support more complex protocols, enhance cross-contract interactions, and enable existing protocols to operate at their full potential on the Stellar network.
+
+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
+
+### Identify Resources in Demand
+
+#### Read/Write limits
+Developers are encountering limitations with current 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
+
+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.
+
+Although the Gateway itself only stores a hash of the message payload, it needs to emit an event containing the full payload for Relayers to discover and forward to the Axelar Network. Failing to make the full message payload available on-chain has the following consequences:
+
+- 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
+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.
+
+
+### Evaluate Proposed Numbers
+
+#### 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
+- 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
+- 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  
+3. Mean ledger close: 205 milliseconds  
+
+- Benchmark the increase to the event limit. Transactions configured with 100M instructions, 25 RO entries, 15 RW entries, 500 bytes per entry, 800 80-byte events. 5 TPL.
+1. Max ledger close: 195 milliseconds
+2. Min ledger close: 176 milliseconds
+3. Mean ledger close:  181 milliseconds
+
+
+### Nominate the Proposal
+
+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
+
+The entry limit increase (187 milliseconds to 205 milliseconds) is acceptable, but close to the 250ms limit to applying soroban transactions.
+
+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.
+
+## References