MASM pattern for polymorphic procedure calls
- Linguagem predominante
- Rust
- Estrelas
- 132
- Forks
- 167
- Merge médio
- 1d 23h
- PRs com merge (30d)
- 110
Descrição
## 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):**
```masm
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
```masm
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?
Guia de contribuição
Avaliação
Esta issue ainda não foi avaliada.