Read-only Invocations

[leighmcculloch]

I think there would be some value for safety to make it possible to add several features that support functions being guaranteed to execute as read-only.

The motivation being that contract developers often know that areas of their code shouldn't have side-effects, and marking that area of code as read-only ensures that no side-effects are ever introduced, either by code in that area of the contract the developer is writing, or in code that the contract is calling.

We explored ideas for this previously in, and some folks (@kalepail @earrietadev @mootz12) have commented there already:

• Support View/Read-Only Functions rs-soroban-sdk#971

Through a combination of a few features read-only safe areas could be implemented:

• 1️⃣ Soroban Contract Spec's are expanded to include an indicator on functions about whether a function is read-only or not, so that clients can infer that without executing the contract. An attribute is added for contractimpl for marking functions as read only.
• 2️⃣ Soroban SDK uses &mut Env / &Env to separate read-only from read-write operations. So it becomes impossible for a dev to accidentally cause side-effects in read-only functions. This change sounds simple, but may be challenging to implement in Rust's type system.
• 3️⃣ Soroban Contract Client's are generated so there is a read-only variant, via the use of &self vs &mut self.
• 4️⃣ Soroban Env supports being placed into a "read-only" mode, where once a new host fn, enable_read_only_mode is called, the current invocation will error on any attempt to write to the footprint, write an event, or change anything about the environment. That change applies to all sub-invocations too, but not parent invocations.

These ideas were already shared in the SDK issue above, but the first three don't really make sense and may actually be unsafe without 4️⃣, and 4️⃣ is a protocol change.

The protocol change idea is:

• Add new host function enable_read_only_mode that after calling causes the host to trap on any attempt to cause a side-effect, i.e. write to storage, bump TTLs, write any ledger entry, write a system event, write a contract event. The exception being diagnostic events, which would be allowed.

Note that this feature doesn't really help contract top-level invokers, because they can already invoke a contract in a read-only fashion with a read-only footprint.

---

Would this feature improve the safety of your contracts?

Would this feature make it safer to use untrusted dependency contracts that you call?

Thoughts?

[jayz22]

4️⃣ Soroban Env supports being placed into a "read-only" mode, where once a new host fn, enable_read_only_mode is called, the current invocation will error on any attempt to write to the footprint, write an event, or change anything about the environment. That change applies to all sub-invocations too, but not parent invocations.

I see challenges regarding this one.
The state of the environment (the Host) includes, but is not limited, to the budget and host object array.
I think you did not meant to make the budget immutable, since any "read only" operation is still metered and affects the budget.
I think you did mean to include host object array as being immutable in read-only mode.

The host has its own assumption regarding immutability that is different from a contract. Namely a host object is immutable, and mutable operations on a host object creates new host objects (thus mutating the host object array). And the host has numerous small value optimizations baked in with such assumption.

For example,

• The host functions get_current_contract_id and get_ledger_network_id appear to be immutable but both creates an host object. (We could get around it by creating those objects eagerly or caching them, but that requires work, see Cache contract id (and other frequent objects) in host rs-soroban-env#681)
• The arithmetic involving potentially large numbers (i64, i128, i256) could be immutable or mutable, depending on the value involved. A contract may perform some local arithmetic, based on the result interact with its storage in immutable way, but that could still be mutating the host.
• Subcontract calling, involves Symbol which may or may not create a new object based on the callee's function name length.

It'll require a lot of work to level out differences in assumptions between the host and the contract. And I don't think we should expose/change the assumptions and the baked-in optimization of the host too much.

[leighmcculloch]

I was meaning that no ledger entry would be written, and no event would be written. No observable side-effect would exist to a watching contract or a watching downstream system.

It would be fine for the budge to be mutated, and for fees to be charged, and for host objects to be created, moved around, etc.

[jayz22]

Ah got it! I guess I was confused by "change anything about the environment".
If it's just storage and events, the surface area is much more limited. Instead of a global state (mutable or immutable) in the host, I would prefer something more limited-scope. We could potentially set a flag in the VM (read-only) at the instantiation time, which if set, does not allow it to invoke certain host functions (to modify storage, emit event), essentially "blacklisting" certain host functions for read-only contracts.

[leighmcculloch]

A problem to consider with the ideas in this discussion is that if a function is implicitly read-only today, someone writing a read-only may depend on it being read-only when it's read-only capability is only happenstance and not part of any guarantee the contract provides. Preventing those types of accidental dependencies is possible by having every function declare it's read-only-or-read-write intent to both the spec and the host. The spec signals to external tooling. Informing the host ensures that regardless of whether the contract writes today, if it is marked as intending to write, or not intending to be read-only, it can't be called by a read-only fn.

[tupui]

Just seeing this. I have a use case, a bit tangential.

To make some commitments for a ZK proof, I have some helper functions. Calling them must not write anything onchain as this would reveal the elements. So I make simulations only. It is helpful to have these functions in the contract as to have a verified and static version of the code.

If there was some ways to prevent a function to be called at all, this would solve that security issue. (Besides using some form of hack to ensure all calls fail if not in a simulation.)

TLDR, having more tools to control the function execution and what is happening to the env would be powerful additions.

[leighmcculloch]

It seems risky to solve that security problem at a layer, the protocol, that is outside the machine with the secrets.

In the example described the sensitive information is those commitments. The security protecting those commitments from leaving the machine should exist at that machine, not on chain.

Using the simulation endpoint of RPC is guaranteed to only simulate and not submit, which is good. If using tooling like the CLI which does both, usually there's an option like in the CLI --send=no, to make sure it never sends even if it is a write.

Using a remote hosted RPC may not be a good idea in this situation so potentially you'd need to use a local RPC to keep all the sensitive information on the machine.