Skip to content

Latest commit

 

History

History
91 lines (62 loc) · 6.97 KB

slp-0001.md

File metadata and controls

91 lines (62 loc) · 6.97 KB

Preamble

SLP: 0001
Title: Increase Events and Read/Write Ledger Entry Limits for Soroban 
Authors:  Tim Baker <@silence48>, Attiss Ngo (Interop Labs), Mootz12 (Blend Protocol), Siddharth Suresh <@sisuresh>
Consulted: Soroswap, Hoops Finance, Yieldblox, Blend Protocol, Interop Labs, Squid Router
Status: Final
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.

Goals Alignment

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

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.

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.

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.

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 8198 16384

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.

Evaluation

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

Long-term protocol impact

  • 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

Evaluation Outcome

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 change can be considered acceptable and safe for the network health.

References