MASM pattern for polymorphic procedure calls

[Keinberger]

Description

Opening this issue to spark a discussion around polymorphism/interface pattern requirement in MASM.

Use Case

The Zoro team (and potentially other developers) want to implement a pattern where an account shares a common receive_asset procedure root without having to depend on the underlying MAST root of the validate_and_update_state.

Current Behavior

Original Implementation (Doesn't Work):

export.receive_asset
    procref.validate_and_update_state mem_storew_be.ADDR dropw push.ADDR
    dynexec

    exec.native_account::add_asset
    dropw
end

Note: Since procref is resolved at compile time, each account implementation with a different validate_and_update_state logic will produce a different receive_asset procedure hash. This breaks the architecture because the team needs a consistent procedure hash to identify and call the function across different account types.

Current Workaround

export.receive_asset
    push.VALIDATE_AND_UPDATE_STATE_HASH_ADDR exec.active_account::get_item 
    push.ADDR mem_storew_be dropw push.ADDR
    dynexec

    exec.native_account::add_asset
    dropw
end

Problems with this approach:

1. Requires storing the validation procedure hash in account storage. We do not have support for immutables, so the only approach would be to store it as constants or in normal storage.
2. Since account storage is mutable, this opens up potential security vulnerabilities.

Questions

1. Is there a recommended pattern for this use case that we have and should document? What is the current solution to this problem?
2. Should we consider language-level support for interface/trait-like patterns?

[bobbinth]

The described workaround is probably how I would have done it too. To answer the problem points:

Requires storing the validation procedure hash in account storage. We do not have support for immutables, so the only approach would be to store it as constants or in normal storage.

If we need this level of "dynamism", putting procedure root into storage is not bad in and of itself. We actually considered something similar in #2143.

Since account storage is mutable, this opens up potential security vulnerabilities.

If the user fully controls the code deployed in the account, they should be able to ensure that no code writes to this storage slot (unless we do want to update the validation procedure). It does feel a bit less safe, but if the validation procedure can be defined dynamically, I assume that the users need to examine the code in the account anyway.

---

Other potential approaches:

1. If the number of versions of validate_and_update_state is small (e.g., 5 or fewer), we could build a tree of if-else statements to select the correct one based on some parameter.
2. Depending on the complexity of validate_and_update_state, it may be possible to rewrite it such that a single procedure handles all possible scenarios.

It may be possible to come up with some built-in mechanism to handle this at the VM level (e.g., have some kind of a native support for vtables), but that will probably require making some fundamental changes, and the overall benefits are probably not going to be that great over the storing procedure roots in storage approach.

We could also address this at the transaction kernel level - e.g., allow procedure invocation by index. It could look something like:

export.receive_asset
    # execute procedure in the account interface located at index 1
    push.1
    exec.account::execute_procedure_by_index

    exec.native_account::add_asset
    dropw
end

This could work pretty well, but we'd need to somehow guarantee the ordering or procedures at account instantiation time.

[PhilippGackstatter]

The procedure hash in storage approach seems best to me and I agree that this shouldn't open security vulnerabilities, since account storage can only be written by procedures in the account's interface, which are controlled by the creator.

If the number of versions of validate_and_update_state is small (e.g., 5 or fewer), we could build a tree of if-else statements to select the correct one based on some parameter.

I think one variant of this is putting all potential MAST roots of validate_and_update_state implementations into memory and then selecting one based on index, which should work well with dynexec which already takes a pointer.

I find the execute-account-procedure-by-index approach interesting, but the index needs to be stable across the entire lifetime of the account, which means account procedures cannot be removed (addition would be okay, if it is appended), as these would potentially shift procedure indices.
Related to this, I think to support account code upgrades, we'll need to require that account procedures are sorted by MAST root (in order to efficiently compute a diff, see also #2183), which means both removing and adding procedures could affect any procedure index.

So I think the approach with the least assumptions is the one already suggested, i.e. keeping the MAST root in an account storage slot.