Currently, trait definitions do not enforce a read-only property on trait implementations. This is desirable because trait implementation consumers may want to be assured that a particular implementation cannot alter blockchain state. For example, the SIP-009 trait function get-last-token-id should not write new state.
Until the VM can be extended to support read-only enforcement for trait concretizations, the Clarity VM could instead record whether or not a function is truly read-only at analysis time. This analysis is something it already does as part of verifying that a function is properly defined. Once the VM does this, then we can add an RPC endpoint to allow users to query whether or not a trait concretization (or really, any defined function anywhere in the chain) is read-only. This way, users of popular trait concretizations like SIP-009 NFTs can ascertain whether or not functions that are expected to be read-only truly are.
Currently, trait definitions do not enforce a read-only property on trait implementations. This is desirable because trait implementation consumers may want to be assured that a particular implementation cannot alter blockchain state. For example, the SIP-009 trait function
get-last-token-idshould not write new state.Until the VM can be extended to support read-only enforcement for trait concretizations, the Clarity VM could instead record whether or not a function is truly read-only at analysis time. This analysis is something it already does as part of verifying that a function is properly defined. Once the VM does this, then we can add an RPC endpoint to allow users to query whether or not a trait concretization (or really, any defined function anywhere in the chain) is read-only. This way, users of popular trait concretizations like SIP-009 NFTs can ascertain whether or not functions that are expected to be read-only truly are.