Enhance Simulation to proactively record ReadWrite access for near-expiry Persistent entries

[EFCCWEB3]

Description:

Is your feature request related to a problem? Please describe. Currently, a "Footprint-Restoration Deadlock" can occur when a Persistent ledger entry expires in the brief window between transaction simulation (Recording Mode) and execution (Enforcing Mode).

During simulation, if an entry is live, the host records AccessType::ReadOnly. However, if that entry expires before the transaction is processed, the host’s internal logic in handle_maybe_expired_entry attempts to auto-restore the entry. This requires ReadWrite access. Since the signed footprint only contains ReadOnly, the transaction fails with ScErrorCode::ExceededLimit. While this is a rare edge case, it creates non-deterministic execution failures for valid transactions.

Describe the solution you'd like I suggest modifying the simulation logic (Recording Mode) to include a "buffer zone" check for Persistent entries.

If a Persistent entry is accessed and its live_until sequence is within a certain threshold (e.g., the next 100–500 ledgers) of the current ledger sequence, the simulation should automatically record the access as ReadWrite instead of ReadOnly.

Describe alternatives you've considered

Manual Developer Intervention: Expecting developers to manually mark entries as ReadWrite defensively. This is inefficient and increases costs unnecessarily for the majority of the entry's lifespan.

Host-level Bypass: Allowing the Host to bypass the ExceededLimit check specifically for internal TTL restoration. However, this might complicate the security invariants of the Footprint system.

This improvement would align simulation more closely with the realities of network latency and submission delays, ensuring that a "successful" simulation is more robust and predictable upon execution. It reduces the likelihood of users paying non-refundable fees for transactions that fail due to unavoidable internal maintenance logic (Rent/TTL).

[leighmcculloch]

I'd like to propose an alternative: that we consider allowing read entries to be restored.

I'm not aware of all of the ways that might impact things, so I acknowledge that this may be a bad idea and extraordinarily naive. But here's why I'm thinking about this:

The fact that restoration requires an entry in the footprint to be read-write is a leaky abstraction and has some downsides. When an item is being restored, it makes it look like this transaction is intending the contracts being invoked to write to the entry, when that isn't the case.

Some sensitive clients may red flag that hey for some reason this invocation when simulated wrote to the entry, when it wasn't expected to.

Some applications and tooling, like the Stellar CLI, use the footprint and other simulation data as signal to identify if an invocation will write data to the network or not, or be read-only. The fact that restoration has simulation say an entry is read-write when the contract doesn't write it, provides incorrect signal about the effect of a transaction.

While I understand the practicality that yes, a restored item is being written back into the ledger, semantically, it also seems accurate and much more useful from the developers perspective to say that nothing in the contract invocations are in fact writing to the entry, so the externally viewable footprint is read-only. The entry is being moved from one storage to another.

[EFCCWEB3]

The core issue with allowing a "Read-to-Restore" bypass is that restoration is not merely a "move" of data; it is a metered state-change operation.
• Fee Computation Logic: There is a state that the host must charge for every entry written to the ledger. If an entry is restored, the compute_rent_fee logic identifies it as an entry where old_live_until_ledger < new_live_until_ledger.
• Resource Tracking: This triggers the addition of a fee_per_write_entry and write bytes for the TtlEntry.
• The Contradiction: If the host allowed a ReadOnly footprint to trigger a restoration, the Transaction Resources would report 0 write_entries to the user, yet the network would process and charge for a write. This creates a mathematical inconsistency in the resource accounting: the user would pay a write fee for an entry that is explicitly flagged as not being written to.

2. The "Leaky Abstraction" vs. Security Invariants
   You are correct that it is a "leaky abstraction" for the CLI to show a write when the contract code didn't call put. However, the Footprint system is designed as a Security Boundary, not just a developer hint.
   • Access Enforcement: The current code flow in Footprint::enforce_access is binary: an operation is either ReadOnly or ReadWrite.
   • Deterministic Safety: If the host allowed "internal" writes on ReadOnly keys, it would break the invariant that the signed footprint is an exhaustive list of all ledger keys that can be modified during execution. Allowing a "stealth write" for restoration could potentially be exploited if a vulnerability in the TTL logic allowed unauthorized state changes under the guise of "maintenance."

[EFCCWEB3]

Instead of allowing ReadOnly entries to be restored (which breaks the security and fee model), the "real" architectural fix involves Metadata Differentiation.
The Recommended Code Flow Evolution:

1. Simulation Layer: The host identifies a near-expired Persistent entry.
2. Recording Mode: Instead of simply upgrading the key to ReadWrite, the host should flag the access with a new internal metadata tag: AccessType::ReadOnlyWithRestoration.
3. Footprint Serialization: The signed transaction still includes ReadWrite (to satisfy the ledger safety requirement), but the Simulation Result returned to the CLI/SDK includes a breakdown:
   ◦ Contract Writes: 0 (The contract logic is pure).
   ◦ Maintenance Writes: 1 (The host must restore this entry).
4. Enforcement Mode: The host uses the ReadWrite permission to perform the restoration, but diagnostic events clarify that this write was a system-level event.
5. Mathematical Stimulation of the Conflict
   If we follow your proposal to allow restoration on a ReadOnly entry dont you think:
   • User Expectation: write_entries = 0.
   • Host Logic: compute_rent_fee sees an extension.
   • Calculation: fee = fee.saturating_add(fee_config.fee_per_write_entry * 1).
   • Result: The transaction is rejected or fails because the non_refundable_fee calculated by the host will be higher than the fee the user signed for (based on 0 writes).
   I think the real fix is to ensure simulation is predictive. The "Buffer Zone" check ensures the user signs for the permissions and fees they will inevitably need once the transaction hits the ledger.

[EFCCWEB3]

Lets see how it goes though, thanks for your feedback.