diff --git a/meetings/2023-01-12.mdx b/meetings/2023-01-12.mdx new file mode 100644 index 000000000..f56344e1e --- /dev/null +++ b/meetings/2023-01-12.mdx @@ -0,0 +1,31 @@ +--- +title: "2023-01-12" +description: A detailed review of the Soroban Auth Next proposal, examining account abstraction, standardized authorization payloads, and their impact on wallets, fees, and contract composability. +authors: john +tags: [developer, soroban] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This follow-up session revisits Soroban Auth Next with a deeper technical review and open Q&A. The group focused on validating the proposal’s core ideas against real developer and wallet concerns, especially around complexity, performance, replay protection, and preserving simple signing flows for common use cases. + +Discussion emphasized how moving authentication into the protocol can reduce fragmentation while still supporting advanced scenarios like multi-step contract execution, delegated authorization, and programmable accounts. Much of the review centered on how standardized authorization trees, preflight recording, and host-managed nonces interact in practice. + +### Key Topics + +- Review of current auth fragmentation (`invoker`, `soroban-auth`, custom schemes) and why it scales poorly. +- Account abstraction model where contracts interact with generic accounts, not cryptographic primitives. +- Standardized authorization payloads that describe authorized call subtrees (not full call stacks). +- Preflight “recording” to deterministically build payloads wallets can sign once per account. +- How authorization forests allow selective signing of nested contract calls. +- Gas, performance, and depth concerns for large call graphs. +- Security considerations around partial authorization, front-running, and contract design pitfalls. +- Preserving simple invoker-style UX for common cases via built-in account implementations. +- Replay protection, nonce consumption, and the need for expiration or ledger-bound signatures. + +### Resources + +- [Soroban Auth Next proposal document](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI/view) +- [Soroban protocol and CAP discussions](https://github.com/stellar/stellar-protocol) diff --git a/meetings/2023-02-23.mdx b/meetings/2023-02-23.mdx new file mode 100644 index 000000000..ba6a0b1f5 --- /dev/null +++ b/meetings/2023-02-23.mdx @@ -0,0 +1,35 @@ +--- +title: "2023-02-23" +description: Discussion of Soroban state rent, archival storage, and configuration upgrades, covering rent mechanics, security tradeoffs, and approaches to managing large network configuration data. +authors: john +tags: [soroban, CAP-46, CAP-46-9] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This session combined two major threads: how Soroban network configuration should scale beyond ledger-header limits, and how state rent and archival storage can bound ledger growth without breaking contract safety. The discussion emphasized that Soroban parameters (like metering and fees) are too large and flexible to live in the ledger header long term, motivating new upgrade mechanisms tied to dedicated ledger entries. + +The second half focused on state rent and archival mechanics. To prevent unbounded ledger growth, Soroban introduces rent-backed contract data that expires and moves to an archive. This enables pruning unused state while preserving recoverability, but introduces subtle security challenges around replay protection, versioning, and key collisions that must be addressed at the storage-model level. + +### Key Topics + +- Limitations of storing Soroban configuration (metering, fees, limits) directly in the ledger header. +- Three approaches to scalable configuration upgrades, with strong interest in using Soroban ledger entries as upgrade inputs. +- Validators voting on hashes of configuration sets, not raw data, to avoid SCP bloat. +- Using Soroban and ledger entries to make configuration proposals on-chain and auditable. +- Motivation for state rent: bounding ledger growth and incentivizing cleanup of unused data. +- Archival storage model using Merkle proofs, with validators storing only archive roots. +- Security risks from archival state, including nonce replay and restoring outdated data. +- Three Soroban storage classes: + - **Unique storage** for data that must never have multiple versions (e.g. nonces). + - **Recreatable storage** for mergeable or replaceable data (e.g. balances). + - **Temporary storage** for short-lived, non-recoverable data. +- Contract-level responsibility for resolving key collisions when restoring recreatable data. +- Role of preflight and RPC nodes in fetching archive proofs and preparing transactions. + +### Resources + +- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md) +- [CAP-46-9: Network Configuration Ledger Entries](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-09.md) diff --git a/meetings/2023-03-02.mdx b/meetings/2023-03-02.mdx new file mode 100644 index 000000000..55880be17 --- /dev/null +++ b/meetings/2023-03-02.mdx @@ -0,0 +1,36 @@ +--- +title: "2023-03-02" +description: "Discussion of the Auth Next proposal plus related protocol work: Soroban fee-model considerations, ledger-state archiving design, and rent-bumping mechanics for on-chain storage." +authors: john +tags: [soroban, CAP-46-7] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This session reviews the Auth Next direction (account-abstraction style authorization with standardized payloads) alongside adjacent protocol concerns that impact developer UX and network sustainability. + +Conversation also digs into Soroban economics and storage lifecycle: fee-market design across multiple resource types, a tiered storage/archival interface for managing ledger growth, and practical ways to keep frequently-read state from expiring without forcing every read to become a write. + +This thread covers a design review of unified authorization for Soroban, focusing on the implications for the host environment and SDKs, alongside updates on fee-schedule work and how different resource markets shape the contract developer experience. It also includes a follow-up deep dive into state archiving, storage classes, incentives for proof serving, and emerging patterns for rent maintenance. + +### Key Topics + +- Auth Next overview: moving toward a single authorization model so contracts can delegate signature/policy verification and focus on business logic +- Fee model refresh: revisiting a draft “fee CAP” and aligning it with newer realities like preflight; framing fees across compute, ledger, bandwidth, and externalized ecosystem costs (indexers/streams/archives) +- Storage interface proposal (three classes): + - Unique storage: single authoritative version (never both live + archived); intended for “must-not-be-reinitialized” state like admin/control entries; higher creation cost due to exclusion guarantees + - Recreatable storage: cheaper creation by allowing archived key collisions (multiple historical versions can exist); discussed mainly as a scalability/UX trade-off for common patterns like token balances + - Temporary storage: short-lived entries that delete on expiry (no archive), favored for scoped approvals and time-bounded auth-related artifacts +- Staging plan: ship the interface + rent charging early, with archiving behaviors/proofs phased in as infrastructure lands (including discussion of a “null root hash” style bootstrap for exclusion proofs) +- Bloom filter debate: whether probabilistic “key exists” hints could reduce proof overhead, balanced against false positives, adversarial key targeting, resizing/migration, and consensus constraints +- Archive proof delivery models: + - Direct archiver endpoints (Horizon-like) vs. on-chain proof requests with reward-driven “archive miners” + - Key concern: proof theft / front-running when proofs are disclosed publicly, and what commit/reveal or other anti-stealing mechanisms might be required +- Rent bumping problem: how to extend rent for heavily-read state without rewriting immutable bucket-list entries; explored host-level bump operations, contract-managed thresholds, and who should bear the cost when state is “public goods” + +### Resources + +- [Auth Next design proposal (guiding document)](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI) +- [CAP-46-7: Fee model in smart contracts](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-07.md) diff --git a/meetings/2023-03-09.mdx b/meetings/2023-03-09.mdx new file mode 100644 index 000000000..a1a5d19b9 --- /dev/null +++ b/meetings/2023-03-09.mdx @@ -0,0 +1,46 @@ +--- +title: "2023-03-09" +description: Overview of proposed updates to the Fees CAP, focusing on deterministic resource pricing and a separate inclusion fee model to improve transaction prioritization, predictability, and user understanding in Soroban. +authors: john +tags: [soroban] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This meeting walked through recent revisions to the Fees CAP, focusing on how to price Soroban’s various resources (compute, bandwidth, ledger I/O, storage impacts) without forcing users and clients to reason about a complex, multi-dimensional bidding system. It outlines a direction for unifying Soroban authorization by replacing `invoker`, `soroban-auth`, and ad hoc schemes with a single account-abstraction model and standardized authorization payloads so contracts stay focused on business logic. + +A central theme was separating deterministic, protocol-derived resource charges from a distinct inclusion mechanism that handles congestion and ordering. The goal is a model that’s easier to understand, more predictable for users, and less prone to unfair prioritization when workloads mix different resource profiles. + +### Key Topics + +- Motivation: Soroban resource accounting is inherently multi-dimensional (compute, bandwidth, reads/writes, bytes, events), and fee design needs to deter spam while keeping execution affordable. +- Dynamic per-resource pricing + prioritization was seen as too complex for both the protocol and clients to bid correctly. +- “Synthetic resource” (gas-like aggregation) exploration highlighted prioritization pathologies: + - weighting different resources can unfairly penalize mixed workloads + - small usage of a scarce dimension can dominate total price even when other capacity is plentiful +- Updated direction: deterministic resource fees derived from network parameters, so costs can be computed from a transaction largely independent of other transactions. +- Transaction ordering under contention shifts to a separate **inclusion fee**: + - prioritization reflects user urgency / willingness to pay (the “social value” of a transaction) + - decouples priority from internal resource dimensions +- User experience emphasis: users should be able to understand “what I pay to run” vs “what I pay to get in sooner,” similar in spirit to familiar fee markets but with clearer separation. +- Refund policy discussion: + - conservative stance against refunds for highly contended resources to prevent gaming and idle capacity + - framing: you pay for reserved/declared capacity (what you _asked_ for), not necessarily what you _ended up using_ +- Edge cases called out for analysis/simulation: + - preflight overestimation vs runtime path changes + - “unused writes” / test-and-set patterns where a write is declared but doesn’t occur + - arbitrage-style scenarios where state changes invalidate a preflighted execution path + - whether limited refunds make sense when there is no contention + +### Outcomes + +- By generalizing authorization through account abstraction, contracts can treat classic accounts and programmable wallets uniformly, delegating signature verification, nonce handling, and policy enforcement to account contracts that expose a single `check_auth` entry point. +- Contract invocations are authorized via structured payloads that capture the full call stack. Preflight recording determines what will execute so wallets can construct correct payloads, while the host tracks nonces per account-root pair. +- The proposal includes a built-in account contract for classic accounts, recommends temporary or scoped storage (such as short-lived approvals) instead of long-lived allowances, and presents proof-of-concept patterns like timelocks, atomic swaps, and token approvals, along with notes on SDK and host implications. +- This approach introduces added complexity in preflight, larger transaction footprints, and new host responsibilities. The intent is to reduce ecosystem fragmentation, simplify wallet integration, and focus authorization logic within a consistent framework. + +### Resources + +- [Fees CAP – Updated Auth Next Proposal and Design Discussion](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI) diff --git a/meetings/2023-03-16.mdx b/meetings/2023-03-16.mdx new file mode 100644 index 000000000..dcc974277 --- /dev/null +++ b/meetings/2023-03-16.mdx @@ -0,0 +1,63 @@ +--- +title: "2023-03-16" +description: "This session outlines Soroban’s state expiration rollout plan: shipping rent + temporary storage at pubnet launch, finalizing SDK interfaces for unique/recreatable storage, and enabling expiration later once the backend is ready." +authors: john +tags: [soroban, CAP-46] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +Soroban is a smart contracts platform designed with purpose and built to perform. + +This discussion focuses on the roadmap and implementation sequencing for state expiration: what must be ready at Soroban pubnet launch versus what can be completed and activated afterward. A key theme is prioritizing a stable developer-facing interface early, even if the full storage backend and expiration mechanism is enabled later. + +The group also digs into how rent should work in practice—especially who pays it, how contracts decide when to top up, and how fee variability interacts with developer expectations around predictable lifetimes and deletion behavior. + +### Key Topics + +- Rollout plan split into two stages + - At pubnet launch: implement rent + temporary storage fully, and finalize/expose SDK interfaces for unique and recreatable storage + - After launch: enable state expiration (actual expiring/archiving) once the storage backend is ready + - Rationale: lock the interface early so contracts deployed from day one can be compatible when expiration is later activated +- Terminology update + - Naming pivots from “archival system” to **state expiration** to avoid confusion with history archives +- Rent model fundamentals + - Each Soroban ledger entry carries a rent balance (XLM tied to that entry) + - Rent is charged over time for remaining “live” in ledger storage + - Rent fee rate is designed to vary with storage pressure (bucket list size), aiming for a system equilibrium that discourages unbounded state growth +- Who pays rent is contract-dependent (no universal default) + - Token-like balances: the user “owns” their balance entry, so user-funded rent feels appropriate + - Shared AMM state (e.g., pools/pairs): a shared resource used by many, so it may be better funded by a shared mechanism rather than whichever user happens to touch it next +- Proposed rent payment primitives for contracts + - Expose two primitives: `rent bump` and `rent bump from` (modeled after `transfer` / `transfer from`) + - Enables explicit control over who funds rent + - Allows allowance-style patterns so a contract (or maintainer) can fund rent on someone’s behalf without requiring that party to sign each time +- Expected developer pattern for keeping entries alive + - Contracts likely add checks inside common getter/setter helpers: + - inspect current rent balance + - if below a threshold, bump rent (and choose the payer logic) + - This keeps policy flexible while making frequent-use entries self-sustaining +- Abuse/spam concerns and mitigation thinking + - Concern: shared pools could be drained by junk entries + - Suggested approach: bump rent only on meaningful access; junk entries that aren’t used don’t get topped up + - Also noted: contracts can add economic friction (e.g., charge to create entries) +- “Don’t store the data, only store proofs” idea + - Not treated as a protocol-special case + - Suggested approach: store hashes/checksums on-chain and keep sensitive payloads off-chain, using the contract to verify integrity via cryptographic hashes +- Predictability vs variable pricing + - Developers want to reason about “how long does this last” in ledger time, but fees vary with storage pressure + - Temporary entries were discussed as needing strict, ledger-count TTL semantics (especially for security-sensitive uses) + - Unique/recreatable entries are less sensitive since they can be restored, but UX predictability still matters +- Bucket-merge granularity realities + - Expiration/cleanup aligns with bucket merge events, which implies coarse-grained practical effects (e.g., week/month-ish behavior for long-lived entries) + - Discussion notes conservative charging/expiration behavior can lead to entries living longer than their nominal target in some scenarios +- Open design tension: time-based guarantees vs dynamic rent rate + - Proposal floated: lock an entry’s rate for a period after a bump (a “subscription-like” behavior) to improve predictability + - Tradeoff concerns: incentives for gaming/“rent control,” fairness between older and newer entries, and potential impacts as the system approaches storage bounds + - Outcome: recognized as an open question to resolve in follow-on design work + +### Resources + +- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md) diff --git a/meetings/2023-03-30.mdx b/meetings/2023-03-30.mdx new file mode 100644 index 000000000..3acdf3c85 --- /dev/null +++ b/meetings/2023-03-30.mdx @@ -0,0 +1,62 @@ +--- +title: "2023-03-30" +description: This discussion explores how Soroban should expose contract metadata for off-chain consumers, evaluates whether metadata needs protocol-level support, and reviews proposed changes to the token interface, including transfers, allowances, and authorization patterns. +authors: john +tags: [soroban] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +Soroban is a smart contracts platform designed with purpose and built to perform. + +This session focuses on two related design areas: how contract metadata should be represented and accessed, and a set of proposed refinements to the Soroban token interface. Much of the discussion centers on balancing protocol simplicity against developer ergonomics and downstream consumer needs. + +Participants weigh whether metadata should remain an ecosystem-level convention rather than a protocol feature, and whether token interfaces should stay minimal—even if that means pushing more complex patterns (like subscriptions or flexible transfers) into higher-level abstractions. + +### Key Topics + +- Contract metadata goals and scope + - Metadata defined as static, read-only information intended mainly for off-chain consumers + - Two categories discussed: + - Code metadata (embedded in WASM custom sections, e.g. build info, supported interfaces) + - Instance metadata (associated with a deployed contract instance) +- Where metadata should live + - Preference toward ecosystem standards using normal contract data entries rather than new protocol primitives + - SDK tooling can standardize how and where metadata is stored and retrieved + - Avoid introducing new protocol mechanics that must be supported indefinitely +- Cross-contract metadata access + - Considered a niche use case (e.g. reading token decimals for valuation logic) + - Most metadata consumers are expected to be off-chain systems (wallets, explorers, indexers) + - Cross-contract calls via existing interfaces are seen as sufficient for on-chain needs +- Security and mutability concerns + - Metadata that can change at runtime introduces risk and ambiguity for consumers + - Strong preference for metadata being effectively immutable or very strictly controlled + - Contract upgrades complicate guarantees if metadata is treated as authoritative state +- Rent and metadata + - Metadata entries are unlikely to be accessed on-chain, so they won’t get automatic rent bumps + - Manual rent bumping is considered acceptable since metadata is non-critical and recoverable + - No special protocol-level coupling between contract usage and metadata rent was adopted +- Token interface cleanups + - Admin functions no longer need admin addresses passed explicitly (fetched from storage) + - Strong support for renaming abbreviated functions to clearer, longer names (e.g. `transfer`) +- “Transfer max” / flexible transfer semantics + - Proposal to allow signing a maximum amount while letting contracts decide actual spend + - Aimed at improving composability for trades and refunds + - Ultimately deferred to keep the core token interface simple + - Current strict-send semantics deemed sufficient for now +- Allowances: persistent vs temporary + - Persistent allowances recognized as risky but widely used and familiar + - Temporary (transaction-scoped) allowances seen as safer but less generally useful + - Consensus leans toward keeping persistent allowances with strong guidance and warnings +- Account abstraction as a long-term alternative + - Subscriptions and recurring payments better modeled via account logic, not token allowances + - Concepts discussed: + - Signature-less authorization via on-ledger rules + - Extensible or modular account contracts + - Acknowledged as architecturally cleaner but higher complexity and adoption cost +- General design philosophy + - Favor minimal, stable protocol interfaces + - Push experimentation and specialization into contracts, SDKs, and ecosystem standards + - Document risks clearly rather than overfitting the protocol to edge cases diff --git a/meetings/2023-04-06.mdx b/meetings/2023-04-06.mdx new file mode 100644 index 000000000..d43422fcc --- /dev/null +++ b/meetings/2023-04-06.mdx @@ -0,0 +1,36 @@ +--- +title: "2023-04-06" +description: Design discussion covering a proposed transient (ephemeral) storage feature and a v1 contract upgrade mechanism, weighing developer UX complexity vs. benefits, and outlining a protocol-level approach to make upgrades observable and secure-by-convention. +authors: john +tags: [soroban, CAP-46-2] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This session focuses on two contract-platform capabilities: a lightweight transient storage concept for “only-needed-during-execution” state, and a v1-ready upgrade path for deployed contracts. The group explores where each feature helps, what it costs in complexity, and how developers and tooling would reason about it. + +The discussion leans toward minimalism and clear observability: avoiding extra storage modes unless they unlock compelling real-world use cases, while prioritizing a protocol-level upgrade mechanism so contracts shipped in v1 aren’t permanently frozen without an upgrade path. + +### Key Topics + +- Transient storage proposal: ephemeral state that avoids ledger writes and footprint inclusion, aimed at lowering transaction cost/size and ledger growth +- Primary motivating example: temporary allowances/approvals during multi-step cross-contract flows (e.g., distribute funds across receivers) without persisting allowance state +- Concern: limited concrete use cases today, and adding another storage mechanic may confuse developers (especially alongside state expiration and other storage behaviors) +- Token interface impact: desire to avoid “multiple allowance types” and extra surface area if persistent approvals remain the standard +- Related ecosystem context: similar ideas in Ethereum (transient storage opcodes) and its relevance there for re-entrancy patterns; noted as less motivating here given current execution model +- Conclusion on transient storage: consensus to remove/de-scope due to narrow benefit vs added conceptual overhead, unless strong use cases emerge +- Upgradeability motivation: without a built-in mechanism in v1, contracts deployed in v1 that don’t include self-upgrade hooks could remain unupgradeable forever +- Upgrade approaches compared: + - Storage delegation/proxy-style patterns (powerful but more manual machinery and tricky ergonomics/performance in a VM-heavy environment) + - Protocol-level “update contract executable” approach (contract updates its associated WASM hash via a host function; auth logic stays with the contract) + - Optional extension: allow executable indirection to another contract (cheap proxy-style “shared implementation” pattern for fleets of instances) +- Observability argument: protocol-level upgrades are easier for explorers/tooling to detect than bespoke proxy patterns, making behavior changes more auditable and less “hidden” +- UX/security tradeoff: discussion of including the WASM hash in signed payloads to invalidate old signatures after upgrades (extra safety vs potential user friction) +- Practical note: footprint/preflight behavior already makes some “stale view” failures likely, reducing the incremental benefit of hash-in-signature in many cases + +### Resources + +- [EIP-1153: Transient Storage Opcodes](https://eips.ethereum.org/EIPS/eip-1153) +- [CAP-46-2: Smart Contract Lifecycle](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-02.md) diff --git a/meetings/2023-04-13.mdx b/meetings/2023-04-13.mdx new file mode 100644 index 000000000..797eda53f --- /dev/null +++ b/meetings/2023-04-13.mdx @@ -0,0 +1,70 @@ +--- +title: "2023-04-13" +description: Design discussion and workshop covering Soroban state expiration, rent mechanics, automatic and manual rent bumps, temporary entries, and hands-on demos for writing and testing stateful smart contracts with Soroban tooling. +authors: john +tags: [soroban, tutorial, CAP-46] +--- + +import YouTube from "@site/src/components/YouTube"; + +## Rent Bumps and Temporary Entries {#part-1} + + + +This session explores how Soroban manages contract state over time through rent, expiration, and temporary entries. The discussion focuses on reducing ledger bloat while preserving developer ergonomics, walking through how rent is charged, how entries are kept alive, and how developers and users interact with these mechanisms. + +Participants also dig into open design questions around rent bumping: what should happen automatically, what should be explicit, and where responsibility should sit between protocol, contract developers, wallets, and transaction builders. The goal is a system that is safe by default, flexible for advanced use cases, and understandable for developers and users. + +### Key Topics + +- Overview of state expiration and rent: entries must maintain a non-zero rent balance to remain usable +- Automatic rent bumps applied on access to contract data, contract instances, and WASM code +- Motivation: frequently used entries stay alive without manual intervention; rarely used entries naturally expire +- Manual rent bumps for infrequently accessed but latency-sensitive data (e.g. long-term token balances) +- Design tradeoffs: + - Manual rent bump operations that specify ledger keys directly + - Exposing a rent-bump host function to contracts to abstract key management +- UX and safety concerns with contract-controlled rent bumps (griefing, accidental overspending of refundable fees) +- Debate over responsibility: + - Contracts know which keys belong to a user + - Users or wallets should decide _how much_ rent to pay +- Emerging middle-ground ideas: + - User-supplied “auxiliary rent bump” values combined with contract-selected keys + - Leveraging transaction footprints to bound and make rent behavior observable +- Default rent for newly created entries: + - Minimum required to survive initial bucket levels + - Optional immediate bumping via transaction metadata rather than contract logic +- Deletion semantics: + - Outstanding rent balances are burned on deletion to avoid refund gaming + - Rationale compared to other chains’ storage refund models +- Emphasis that rent affects performance and availability, not correctness or security of unique/temporary state + +### Resources + +- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md) + +## Write Your First `Hello World` to Ledger Storage {#part-2} + + + +This workshop segment walks through writing and testing Soroban smart contracts using Rust and the Soroban SDK, with a strong focus on developer experience. Live demos show how to compile, invoke, and iterate on contracts entirely in a browser-based environment. + +The session progresses from a basic “Hello World” contract to stateful contracts that store and retrieve data from ledger storage, demonstrating how Soroban abstracts serialization, storage access, and testing while remaining explicit about execution and state. + +### Key Topics + +- Writing minimal Soroban contracts in Rust using `#![no_std]` and the Soroban SDK +- Contract functions, return values, and logging via the host environment +- Using `Symbol` for efficient on-chain data representation +- Interactive contract invocation via a browser-based playground +- Ledger storage basics: + - `env.storage().set()` and `env.storage().get()` + - Handling optional values and type safety +- Storing state keyed by addresses instead of global keys +- Testing and iterating on stateful contracts without deploying to a live network +- Soroban’s “batteries included” philosophy for developer productivity + +### Resources + +- [Soroban Rust SDK](https://github.com/stellar/rs-soroban-sdk) +- [Rust documentation](https://docs.rs/soroban-sdk) diff --git a/meetings/2023-04-20.mdx b/meetings/2023-04-20.mdx new file mode 100644 index 000000000..8a6c5c332 --- /dev/null +++ b/meetings/2023-04-20.mdx @@ -0,0 +1,50 @@ +--- +title: "2023-04-20" +description: Design discussion on Soroban state expiration economics, examining rent burning, archival incentives, and temporary storage pricing, with a focus on minimizing complexity while keeping ledger and archive growth under control. +authors: john +tags: [soroban, CAP-46] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This discussion continues the exploration of Soroban’s state expiration and rent model, focusing on what happens when entries expire, are deleted, or move into archival storage. The group revisits earlier decisions around burning outstanding rent balances and evaluates whether additional incentives are needed to encourage deletion of unused ledger entries. + +A major theme is simplicity versus precision: whether to introduce a new “archival fee” to motivate cleanup, or instead rely on pricing differentials—especially making temporary entries meaningfully cheaper—to guide developer behavior while avoiding extra fee types and conceptual overhead. + +### Key Topics + +- Burning outstanding rent balances on deletion: + - Prevents refund-based attack vectors where malicious contracts reclaim rent paid by many users + - Avoids unfair redistribution where one actor benefits from rent funded by others +- Archival storage characteristics: + - Archived entries must be stored indefinitely, even if later restored + - Deletion is strictly better for entries that will never be used again +- Archival fee proposal: + - Flat, refundable-at-deletion fee paid on entry creation + - Burned if the entry reaches the archive + - Intended to incentivize deletion before archival + - Downsides: new fee type, added complexity, and larger entry size +- Temporary vs. restorable entries: + - Temporary entries have fixed lifetimes and never enter the archive + - Restorable entries persist, accrue rent, and may be archived +- Pricing and incentives: + - Current cost gap between temporary and restorable entries is relatively small + - Proposal to widen the gap by discounting temporary entries instead of adding archival fees + - Discounted temporary entries encourage correct usage without extra mechanisms +- Developer ergonomics and complexity concerns: + - Reluctance to add another fee type purely for edge-case deletion incentives + - Preference for fewer storage types and clearer mental models +- TTL (time-to-live) behavior for temporary entries: + - Current model enforces strict expiration for security-sensitive use cases + - Debate over allowing TTL extension (“bumping”) versus keeping lifetimes immutable + - Concern that extensible TTLs could undermine security assumptions or allow rent gaming +- Consensus direction: + - Favor simpler pricing adjustments (temporary entry discounts) + - Avoid archival fee refunds and additional protocol complexity + - Preserve strict TTL semantics for temporary entries as the common, safe default + +### Resources + +- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md) diff --git a/meetings/2023-04-27.mdx b/meetings/2023-04-27.mdx new file mode 100644 index 000000000..038447f00 --- /dev/null +++ b/meetings/2023-04-27.mdx @@ -0,0 +1,55 @@ +--- +title: "2023-04-27" +description: "Design discussion on unifying Soroban state-expiration storage: rent-based lifetimes for temporary and restorable entries, automatic and manual rent bumps, incentives to prefer self-deleting data, and how (or whether) to hash event outputs for replay integrity." +authors: john +tags: [soroban] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This discussion focused on evolving state expiration toward a single, rent-based storage interface that supports both temporary (self-deleting) and restorable (recoverable via a separate network role) entries. The group explored how to offer predictable minimum lifetimes without requiring exact ledger-specific TTLs that would harm downstream performance. + +The conversation also covered how rent is paid and extended (automatic bumps on access vs manual bump operations), how to incentivize use of temporary entries, and a final thread on whether emitted events/results should be hashed into ledger-visible structures to preserve historical replay fidelity. + +### Key Topics + +- Unifying temporary and restorable storage under one rent-based model + - Both entry types start with an initial lifetime selection (e.g., short/medium/long) expressed via SDK-friendly flags + - Exact, arbitrary ledger TTLs were discouraged due to performance and overfitting to narrow security use cases + - Contracts that truly need exact expiry should implement it explicitly (e.g., store an expiration ledger and enforce in contract logic) +- Minimum lifetime guarantees vs “fuzzy” expiration + - The system aims to guarantee a strict lower bound (entry lives at least as long as purchased) + - The upper bound can extend beyond the minimum depending on access patterns and rent mechanics +- Automatic rent bumps on access + - Proposal: every read/write access triggers a small, incremental rent bump (a small number of ledgers) + - Includes a ceiling/max so frequently accessed entries don’t accumulate effectively “infinite” lifetime +- Manual rent bumps + - Users can explicitly extend an entry’s lifetime via an operation that targets specific keys + - Deleting and recreating an entry burns the existing rent balance (no refund), discouraging “reset” patterns +- Differentiated pricing to incentivize self-deleting data + - Temporary entries should have a lower rent rate than restorable entries to steer developers toward self-deleting storage when possible + - Restorable storage is positioned as something to reserve for data that cannot be recreated (or is otherwise critical) +- Product/UX concerns about bumping temporary entries + - Tension: some temporary data (e.g., oracle-like short-lived values) becomes useless past a semantic expiry even if storage persists + - Potential mitigations discussed: + - contracts enforce semantic expiry (delete/ignore stale values) + - special-casing very short lifetimes to avoid automatic bumps + - General agreement that a unified interface simplifies developer decision-making (main question becomes “does this need to be restorable or not?”) +- “Witness node” concept for restorable data + - Restorable entries would be removed from validators when expired and stored by a separate role (described as a witness node / deep state store) + - Restoration involves bidding/fees, rewarding nodes that serve requested historical state +- Whether smart contracts should be able to trigger rent bumps + - Concerns raised: + - conditional bumps can damage parallelism by creating extra write-dependencies + - contract-driven bumps can enable griefing/bugs (e.g., unexpectedly forcing large rent payments) + - ambiguity about who should pay when the invoker isn’t the owner of the state being accessed + - An “auxiliary rent bump” idea was described: + - contract can mark which keys should be bumped (`aux_rent_bump(key)`) + - caller supplies the bump amount (including zero) in the transaction footprint + - viewed as niche/complex; leaning toward wallet-managed manual bump operations instead +- Event/result hashing and replay integrity + - Initial thought: hash event outputs into ledger-visible data for cryptographic inclusion proofs + - Shifted focus toward replay-fidelity checks: include a hash of emitted events/return values so historical replay mismatches are detectable + - Preferred direction discussed: keep full events in transaction meta for consumers, but include their hashes in operation results (avoiding larger structural changes) diff --git a/meetings/2023-05-04.mdx b/meetings/2023-05-04.mdx new file mode 100644 index 000000000..ebd1da1b8 --- /dev/null +++ b/meetings/2023-05-04.mdx @@ -0,0 +1,73 @@ +--- +title: "2023-05-04" +description: Design discussion comparing rent balances and expiration ledgers for Soroban state expiration, focusing on user experience, downstream system complexity, eviction pressure, and safeguards against rent-fee exploits. +authors: john +tags: [soroban] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +This session examined a major shift in Soroban’s state-expiration design: replacing variable rent balances with fixed expiration ledgers. The discussion compared the two approaches from first principles, weighing predictability and simplicity against dynamic eviction pressure and resistance to economic exploits. + +Participants explored how expiration ledgers could dramatically improve developer experience and downstream tooling (Horizon and RPC), while also identifying new risks—such as locking in cheap storage early or enabling storage “middlemen”—and discussed mitigations like maximum lifetimes and bounded auto-bump behavior. + +### Key Topics + +- Rent balances (legacy approach) + - Entries hold an XLM rent balance that is decremented each ledger by a variable rent fee + - Rent fee adjusts with bucket list size to create automatic eviction pressure + - Pros: + - Strong resistance to economic exploits + - Natural eviction as network usage increases + - Cons: + - Poor UX (lifetimes are estimates, not guarantees) + - Difficult or impractical for downstream systems to track without re-implementing bucket list logic +- Expiration ledgers (proposed direction) + - Each entry stores a single expiration ledger + - Entry is valid before that ledger and expired after + - Expiration info is emitted in transaction meta on creation or bump + - Pros: + - Predictable, ledger-based lifetimes + - Much simpler for Horizon and RPC to index and reason about + - Cons: + - Rent price is “locked in” at creation or bump time + - Loses dynamic eviction pressure inherent in rent balances +- Network health and exploit concerns + - “Storage middleman” contracts could pre-purchase long-lived storage at low fees and resell later + - Early spam could lock in cheap storage and crowd out later legitimate usage + - Proposed mitigation: + - Enforce a protocol-level maximum lifetime (e.g., 6–12 months) + - Make this maximum adjustable via network vote +- Entry resizing under expiration ledgers + - Rent is charged per byte + - If an entry grows in size, additional rent must be paid + - Expiration ledger should never decrease on resize + - Updates would require paying the delta cost to preserve the same expiration +- Auto-bumps vs manual bumps + - Auto-bumps: + - Extend expiration slightly on every read or write + - Intended to fairly distribute cost for shared resources (e.g., contract WASM, instances) + - Implemented efficiently via small “shim” entries rather than rewriting large state + - Manual bumps: + - Explicit operation to extend expiration to a target ledger + - Open design question: + - additive model (pay only for extension) + - or reset model (burn prior payment and re-buy full lifetime at market rate) +- Temporary entries and security semantics + - Expiration ledgers make exact TTLs possible in theory + - However, because any user can bump entries, expiration is not absolute + - Security-sensitive TTLs must still be enforced in contract logic + - Discussion around: + - whether auto-bumps should be configurable + - whether “non-bumpable” temporary entries are worth the added complexity +- Auto-bump configurability + - Strong consensus that auto-bumps are essential for shared state (contract code, instances) + - More debate for contract data and user-specific state (balances, LP positions) + - Trade-off: + - configurability vs simplicity + - risk of over-bumping short-lived data (e.g., oracle values) + - Leaning toward: + - fewer flags in v1 + - possible future extensions if clear patterns emerge diff --git a/meetings/authors.yml b/meetings/authors.yml index 9d92d724b..8f808c704 100644 --- a/meetings/authors.yml +++ b/meetings/authors.yml @@ -56,3 +56,11 @@ kaankacar: image_url: https://github.com/kaankacar.png socials: github: kaankacar +john: + name: John Wooten + url: https://wooten.link + image_url: https://github.com/JFWooten4.png + socials: + github: jfwooten4 + x: jfwooten4 + linkedin: jfwooten4 diff --git a/routes.txt b/routes.txt index 9f0304cc0..d6e9c4b7e 100644 --- a/routes.txt +++ b/routes.txt @@ -837,6 +837,17 @@ /docs/validators/admin-guide/soroban-settings /docs/validators/tier-1-orgs /meetings +/meetings/2023/01/12 +/meetings/2023/02/23 +/meetings/2023/03/02 +/meetings/2023/03/09 +/meetings/2023/03/16 +/meetings/2023/03/30 +/meetings/2023/04/06 +/meetings/2023/04/13 +/meetings/2023/04/20 +/meetings/2023/04/27 +/meetings/2023/05/04 /meetings/2024/01/18 /meetings/2024/01/26 /meetings/2024/02/01 @@ -925,7 +936,12 @@ /meetings/page/5 /meetings/page/6 /meetings/page/7 +/meetings/page/8 /meetings/tags +/meetings/tags/cap-46 +/meetings/tags/cap-46-2 +/meetings/tags/cap-46-7 +/meetings/tags/cap-46-9 /meetings/tags/developer /meetings/tags/developer/page/2 /meetings/tags/developer/page/3 @@ -933,4 +949,6 @@ /meetings/tags/developer/page/5 /meetings/tags/developer/page/6 /meetings/tags/protocol +/meetings/tags/soroban +/meetings/tags/tutorial /search