Foundation
Stellar protocol upgrades are network-wide changes to consensus and core functionality. Validators must update their software to stay in sync. Upgrades may add new features, improve transaction performance, or strengthen network security.
The Latest
Allows the network to evict persistent entries from the live state BucketList to a separate BucketList containing archival state
Defines a new structure for transaction sets that allows for applying Smart Contract transactions with multiple threads while maintaining bounded application time
Maintain a fully-populated cache of all live WASM modules -- parsed, validated and translated -- at all times, across all ledgers, eliminating parsing and validation costs from the WASM VM instantiation process
New resource type for Soroban reads, distinguishing between in-memory and disk reads and automatic restoration for archived entries via InvokeHostFunction0p
Emit transfer, mint, burnt, clawback, fee, and set_authorized events in Classic in the same format as Soroban so that the movement of assets and trustline updates can be tracked using a single stream of data
Soroban host function for getting the executable corresponding to an Address
Soroban host functions for conversion between String and Bytes types
Ledger configuration settings allowing the Stellar network to dynamically adjust ledger close times, nomination timeouts, and ballot timeouts to facilitate controlled, incremental improvements to block time performance
CAP-0062
This proposal separates archived state and live state into two separate DBs. While these DBs are still both persisted on disk by validators, optimizing live state access is significantly easier. In particular, live state can be entirely cached in memory, removing disk reads from the Soroban transaction execution path, greatly increasing read limits and throughput.
CAP-0063
Utilizing the idle cores for applying the transactions provides a straightforward way of increasing the number of transactions that may be included into a single ledger block without compromising the time for closing that ledger. This CAP aims to solve this issue and allow for parallelization that has a guaranteed upper bound for the execution time of transaction sets (given at least the minimum specified number of physical threads supported).