FVM Actors and Getters (view functions)

[Schwartz10]

Context

Smart contracts on other blockchain networks like Ethereum (and other EVM chains) frequently make use of "getters" or "view functions" - contract calls that cost no gas to invoke that return some data about the state of a smart contract. "Getters" are important because they reduce friction for creating composable chains of smart contracts (without forcing end users to pay gas to read data). Getters also make it easier for off-chain applications to make sense of an actor's internal state.

Current solutions

1. Use the lotus jsonrpc method StateReadState, passing the Head CID to ChainReadObj, and then deserializing the params of state one by one.
2. Create methods on the actor itself for returning data (as mentioned here)
3. Something I'm missing?

Downsides to current solution

1. There are primarily 2 downsides to using StateReadState to extract state data from an actor. First, it's overly complex to compute state that depends on the states of multiple underlying actors. Second, this strategy does not work for other FVM actors, so it's incomplete.
2. The downside to using methods on the actor itself to return state data is that invoking methods costs gas. This would require client applications to pay for reading data off chain, which seems problematic and unfamiliar to other similar ecosystems.

This discussion is meant to propose various solutions for how to enable getters in the FVM. @raulk had already mentioned a few ideas on our last FVM early builders call.

[jennijuju]

cc @ZenGround0 @arajasek for 👀 this convo.

[Kubuxu]

The downside to using methods on the actor itself to return state data is that invoking methods costs gas. This would require client applications to pay for reading data off chain, which seems problematic and unfamiliar to other similar ecosystems.

Client applications don't need to pay gas to execute methods on actors locally. You only need to pay when you want a message included and executed by everyone, but nothing is preventing you from executing messages on your own node/hosted node.

[anorth]

I understand the motivation for accessing state off-chain. I do not understand the following:

"Getters" are important because they reduce friction for creating composable chains of smart contracts (without forcing end users to pay gas to read data).

Could you explain this more for me? As far as I understand, in all ecosystems, if a contract wants to get data from another contract's state it is going to need to pay gas, either for a method invocation or perhaps for some method of direct access. But loading the state is computation that must be paid for. I think there might be some confusion over the "view functions are free" meme – they're not free when called by other contracts as part of a transaction.

[Schwartz10]

Hey thanks for clarifying @anorth - after getting a better understanding of the "getter" landscape, i was definitely confused. Have a better understanding now, and agree why that statement above isn't sensible.

[anorth]

Thanks @Schwartz10 this is a great question, which pre-dates the FVM too.

In my opinion, actors should implement methods to expose their state to other contracts and local callers. These methods should generally attempt to abstract over the concrete representation of that state so that the actor can upgrade/migrate without friction of being locked in to an overly transparent API. There'll sometimes be a cost-vs-abstraction trade-off there.

The built-in actors do not set a good example here. We cheated because the Go code defining their state and its interpretation could be directly executed by Go node implementations. Going forward, they will need to implement new read-only methods in order for any other contract to get any information (I have a plan for defining them).

User-programmed actors must expose such methods. The FVM will not expose one actor's state to another actor (there is no StateReadState equivalent), so exporting some API will be necessary for composability. Nodes like Lotus will also generally not understand the schema of user actor state, so they won't be able to interpret it for display. They'll instead have a mechanism to invoke the same view functions for user display, browser apps, etc.

We don't need any special VM support here. Any actor methods can be invoked locally, via the VM, without paying a gas fee to the chain. In on-chain transactions, they can be invoked normally (e.g. following a calling convention like #382). This will involve the necessary gas cost of loading the state, plus the cost of an internal message invocation. This latter cost could be avoided if we allowed actors direct access to each other's state, but I don't think anyone's a big advocate of that.

[anorth]

One idea that @Kubuxu and I have discussed is the possibility of an annotation for explicit view-only methods that can only be invoked locally, and cannot be invoked during a transaction. The goal would be to separate an actor's transaction API (callable by other contracts) from introspection methods for UIs, block explorers, etc. These methods might use the same calling convention for simplicity, but would not be reachable within an on-chain transaction context. This would require some support from the VM, with some environmental parameter indicating whether the call was in a transaction.

We didn't pursue it too much. The main reason is that both kinds of APIs are still exposed to third parties who might reasonably expect that API not to change. Changing the code for a view-only method would still change the actor's WASM code, require an on-chain upgrade etc. And changing the API would break off-chain composability, like with third-party UIs, explorers etc. Maybe that's not quite as bad as breaking on-chain compatibility, but still undesirable. So we concluded that since the methods are a strong commitment in either case, we may as well have only one way to do it and have those methods invocable on-chain too.

These compatibility concerns all lead towards very careful thought required about actor APIs to be exposed. FYI @raulk in case this is interesting.

[Schwartz10]

Hey @anorth, an interesting approach to consider! Some questions:

• Can "composable getters" be created with this implementation? I.e. - could the getter in a "higher level" (i.e. entry point) actor also view information from an underlying actor? Assuming yes, as long as the getter in the higher level actor is not invoking a transaction?
• If a higher level actor needs to read state from an underlying actor when it invokes a transaction, my assumption is the read function would require method dispatch (and cost gas)?
• If the answer to the above is yes (invoking a transaction that requires getting state info from an underlying actor requires gas), do we have a sense of how expensive these calls would be to make? Are we worried about the gas implications from the method invoker's perspective? Since I believe this would be a common pattern, how does this affect the cost of miner's submitting proofs on chain?
• From an education / onboarding pov, how does this effect the devex and learning curve? If folks are unfamiliar with this pattern, how much of a hurdle will it be to get new devs into the ecosystem to build actors? what dev tools would need to be made to make this process at least feel more familiar? (some type of codegen?)

[anorth]

I'm not sure whether you're referring to the approach of explicit view-only methods, or, as we returned to, the simpler approach of just one type of method.

I don't think explicit view-only methods is a good idea. But (1) yes, (2) calling view method in a txn would be illegal, (3) doesn't make sense and (4) good point, another reason it's not a good idea.

For the normal approach (described in previous comment, (1) yes, (2) yes, (3/4) this is how it works today in both Filecoin and Ethereum, so no change. "Getters are free" is a lie.

[raulk]

@anorth I think solving this in an elegant, future-proof manner is on the critical path of M2 (rather: making M2 useful).

A few thoughts:

• I propose a potential goal post that can guide the solution and can serve as a litmus test of whether we're doing things right: convert all existing Lotus JSON-RPCs that access actor state to eth_call equivalents, calling (and composing) public accessors on actor code. Making this an explicit goal has several advantages:
  • Piggybacks on the knowledge accumulated by the Lotus team of what users need to have visibility into, to feed into our own identification of accessors that are worth exposing.
  • Removes the direct state reads from Lotus code, which are an anti-pattern that was just comfortable to implement back then (as you suggested).
  • Forces us to implement data model abstractions for future-proofing inside actors. We have kind of implemented them outside actors in the shims under chain/actors/builtin package.
• IMO the main difficulty is in designing the future-proof data model. The Filecoin chain is unique in the sense that core functionality that most user-deployed actors will depend on can change from under them through network upgrades.
  • We would break general blockchain guarantees and expectations if we end up shipping actors upgrades that break existing user-deployed actors.
  • Ideally we would identify which parts of the protocol are absolutely unmovable in the future first. Those parts could serve as the basis to build our abstractions. However, I suspect that the only answer folks will be happy with is: everything is movable. So that's a non-starter.
  • Maybe we can move the system of shims inside the actors themselves, and have callers identify either (a) the version of the data model they expect (and have the actor apply the right shim), or (b) the CID of the schema of the data structure they expect (more IPLD-ish, but does not account for cases where functionality changes while preserving the schema).
  • We need tons of tests for the shims, these will become uber critical.

[anorth]

I think the built-in actors present a slightly different case. I interpreted the OP as asking about facilities primarily for user-programmed actors. Since these will all be built from scratch, they can and should work to carefully define interfaces to read those parts of their state they chose to expose. And my general response is that the FVM needn't do anything special here – actors will just expose methods as usual (and when invoked locally, they won't cost anything).

For the built-in actors, I am much more conservative. For local access (Lotus RPCs), direct state access works today and I don't see an urgent need to change that despite the anti-pattern nature if the approach was used more widely. Filecoin enjoys an interpretable state representation and we're exploiting it. Local access can blow right past any abstraction an actor developer might intend, and we don't have much choice but to take the good and bad of that. We can't force the use of abstractions.

Exposing equivalent information to all on-chain actors is a non-goal to me. Everything we expose is basically locked in forever, lest we break compatibility for some user actors in the future. This means I am very conservative about what we should expose. All Lotus RPCs is certainly way beyond what I think would be wise. You're probably aware that I'm pursuing several proposals (#313, #298) for significant changes to how storage mining and markets work, and I don't want to expose any APIs that will impede such changes right away.

Yes, not exposing all of miner state to user contracts will limit what they can do. That's part of a deal we're taking by prioritising the release of the FVM ahead of cleaning up the tightly-coupled built-in architecture. There will still be lots of things that user contracts can usefully do immediately, and once we decouple the built-in market they'll be able to interact with miners as markets and brokers of deals, and then all of the aggregations and derivatives that then become possible.

I do have a proposal coming for the incremental exposure of APIs for the built-in actors.

[anorth]

@raulk @Schwartz10 I have written up my proposal for presenting a good API from the built-in actors in #401. Please take a look.

[Schwartz10]

Thanks @anorth! Sorry for the radio silence on my end these last few weeks, will review this and continue the discussion over there

[oberstet]

FWIW, I just ran into this (filed here) and skimmed over above discussion. Not sure, it seems there might be some confusion in what the EVM provides.

This whole thing runs under the name "state mutability" in the EVM, and under "function modifiers" in Solidity.
https://docs.soliditylang.org/en/latest/contracts.html#state-mutability

There are 2 modifiers for functions:

• view: can read (contract) on-chain state, but not write
• pure: can neither read nor write (contract) on-chain state

Apps calling into Web3 gateways to EVM nodes can do so without paying any gas, and without on-chain signed transactions.

A Web3 gateway may of course control even read-access (eg Infura or Alchemy, two popular gateway/node providers allow only a certain volume of free requests. "free" for the app vendor that is)

A contract function that does modify (contract) on-chain state must be fully signed, submitted on-chain and paid for execution in gas.

Such an "external transaction" (the outermost call to a contract function submitted as a user signed transaction) can call other contract functions. Any gas needed is aggregated along the call stack. BUT: if the outermost transaction is "read only", it can also itself only call other contracts read-only functions, and hence the whole call is free and can run without an on-chain transaction.

Web3 applications regularily call read-only functions (via a Web3 gateway), might call graph indexes, on-chain oracles etc all without the user having to sign anything.

Long story short: not supporting view/pure modifiers for actor functions in some way would be a huge IMO ..

---

Thinking about options, here are a couple of ideas:

1. allow to declare state mutability from create_actor/install_actor (on a per-actor-function basis) - this is in a way most similar to solidity/evm
2. allow to specify state mutability in the external actor call (from client/gateway) - and revert when a state modification is tried at run-time
3. just monitor actual state mutations - and then require a fully signed external call transaction only when state is indeed modified

[Stebalien]

This is a solidity thing, not an EVM thing.

[Stebalien]

Apps calling into Web3 gateways to EVM nodes can do so without paying any gas, and without on-chain signed transactions.

By calling EthCall, which is already supported. As far as I know, Ethereum clients don't care (really, the have no way of knowing) about the distinction between a pure/view/etc. function. They just do what the user tells them to do.

Tools, on the other hand, do care. But said tools usually lookup this information locally.

That's not to say that we shouldn't have some way to describe methods on-chain on the FVM, but I think you're over-estimating what Ethereum provides out of the box here.

[oberstet]

mmmh, not sure I get that. there is an EVM opcode STATICCALL

If the compiler’s EVM target is Byzantium or newer (default) the opcode STATICCALL is used when view functions are called, which enforces the state to stay unmodified as part of the EVM execution.

and Sputnik seems to set gas = 0 for that

https://github.com/rust-blockchain/evm/blob/775c477dfc5d2c9772b94a776f6d5205c5b08954/runtime/src/context.rs#L26
https://github.com/rust-blockchain/evm/blob/775c477dfc5d2c9772b94a776f6d5205c5b08954/runtime/src/eval/system.rs#L345

but then again I'm new to FVM and I don't even know the level of compat the FEVM aims to provide .. can I call into "view" functions in FEVM contracts without gas? Or is this a thing of Lotus?

[Stebalien]

That's for EVM -> EVM calls on-chain (although I guess it can be used off-chain as well).

but then again I'm new to FVM and I don't even know the level of compat the FEVM aims to provide .. can I call into "view" functions in FEVM contracts without gas? Or is this a thing of Lotus?

Yes? You can run any transaction you want without paying gas by locally invoking EthCall. Any changes you make just won't be reflected on-chain.

This is the only method that I know of provided by the Ethereum JSON-RPC API: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call (and it doesn't distinguish between static and non-static calls).

[oberstet]

thanks for your reply! ok, I see.

That's for EVM -> EVM calls on-chain (although I guess it can be used off-chain as well). ... This is the only method that I know of provided by the Ethereum JSON-RPC API

yes, fwiw, I dug out the two web3 entry points used by apps

• eth_call: "Executes a new message call immediately without creating a transaction on the block chain." ("CallContract executes a message call transaction, which is directly executed in the VM of the node, but never mined into the blockchain.")
• eth_sendRawTransaction: "Submits a raw transaction." ("SendTransaction injects a signed transaction into the pending pool for execution.")

comments are from web3 spec and from geth sources:

https://github.com/ethereum/execution-apis
https://github.com/ethereum/go-ethereum/blob/master/ethclient/ethclient.go

---

You can run any transaction you want without paying gas by locally invoking EthCall. Any changes you make just won't be reflected on-chain.

ok, so it is still running, but state changes done by the call are on a per-call state copy thrown away?

there might be a small difference still in semantics: "not reflected on-chain", but also returning an error to the invoker? when I call a state modifying (non-view/non-pure) function via eth_call, this results in a error on eth ..

I'm trying to understand the FVM code base, maybe you could give me some more hints?

Calls are ultimately run in a container via the call manager

https://github.com/filecoin-project/ref-fvm/blob/master/fvm/src/call_manager/default.rs#L197

which interestingly has a read_only flag. the call manager is called from the executor

https://github.com/filecoin-project/ref-fvm/blob/master/fvm/src/executor/default.rs#L117

which hard-codes the flag to false? the executor is called from the kernel

https://github.com/filecoin-project/ref-fvm/blob/master/fvm/src/kernel/default.rs#L349

which forwards SendFlags.read_only (which is always overridden by false above).

and the kernel SendOps is the only entry point for Lotus to inject any messages (transactions with or without state changes).

Is above about right?