Investigate separation between internal and external account component procedures

[bobbinth]

Up until this point, we've assumed that all public procedures of an account component would be invoked via the call instruction, and all such procedures get included into the account code commitment. But, as we've started to build components that depend on other components, this may need to be reevaluated.

To give a specific example: in #2712 we've implemented role-based access control component (RBAC) which depends on the Ownable2Step component. Specifically, the assert_sender_is_owner_or_role_admin procedure needs to check whether the sender of the note that is being executed is the owner of the account. And for this, it needs to rely on the functionality of Ownable2Step. The way this is currently implemented is by invoking ownable2step::is_sender_owner_internal via the exec instruction.

A similar pattern is also present in the Pausable component (being implemented in #2793). There, 2 out of 3 procedures (pause and unpause) are meant to invoked "internally" - i.e., from within another component. And in fact, these procedures shouldn't be accessible externally (e.g., from a note script).

The main implication is that we may need to create two types of component procedures (this was first described in #2793 (comment)):

1. "External" procedures - these are meant to be invoked via the call instruction and would be accessible to the note/tx scripts and via FPI calls.
2. "Internal" procedures - these are meant to be invoked via the exec instruction from within other components deployed in the same account.

To support this, we would need to switch over to using attributes to identify "external" procedures. There are a couple of ways to do it:

Option 1: we can create some specialized attribute(s) for this. For example:

# This procedure forms a part of the public interface of the component and should be 
# invoked via the `call` instruction.
@external
pub proc foo
    ...
end

# This procedure is available to be invoked from other components installed in the account
# but is not accessible from external code. It should be invoked via the `exec` instruction.
pub proc bar
    ...
end

The exact naming of the attribute is TBD - i.e., we should probably use something less generic than @external.

Option 2: we can try to rely on the built-in calling convention attributes. It could look something like this:

# This procedure forms a part of the public interface of the component and should be 
# invoked via the `call` instruction.
@component_model
pub proc foo
    ...
end

# This procedure is available to be invoked from other components installed in the account
# but is not accessible from external code. It should be invoked via the `exec` instruction.
@fast
pub proc bar
    ...
end

This mostly works - but there are a couple of issues:

1. The @fast calling convention semantics are not exactly the same as what we currently use. The main point of differences is that "internal" procedures can pass any number of arguments via the stack (not just 16 as is required by the @fast calling convention).
2. @fast and @component_model names are not super meaningful in this specific context and may cause some confusion.

(cc @bitwalker and @greenhat in case I'm saying anything incorrect about calling conventions)

We could probably fix this by introducing new calling conventions or maybe changing the semantics of the existing ones. It may be nice to be able to say something like:

@component_external    # same as current `@component_model`
pub proc foo
    ...
end

@component_internal    # like `@fast` but with 16-stack element limitation for args
pub proc bar
    ...
end

But other approaches could work too.

---

Regardless of the approach we take, there is one annoying thing that would be good to resolve:

Some procedures may may need to be accessible in both contexts. For example, in the Pausable component, the is_paused procedure should be a part of the public interface (so that we could invoke it via the FPI calls) and ideally, it'll be also accessible internally as it would be used by internal components.

I can think of two ways to handle it:

• Use different names for these procedures - e.g., is_paused and is_paused_internal.
• Only have the external is_paused procedure and invoke it via the call instruction even internally.

Neither of these is ideal: the first approach is probably going to create confusion and the second approach would incur meaningful overhead (i.e., using call when exec would do). Maybe there is something else we can come up with?

This is also somewhat related to @greenhat's question from 0xMiden/compiler#697 (comment).

[PhilippGackstatter]

Technically, the RBAC component can call the procedure of the Ownable component, right? If I understand correctly, the main motivation is not needing to call from the RBAC component into the Ownable component, when an exec would work just as well, so that the context switch overhead can be avoided, right?

Identifying account procedures

To support this, we would need to switch over to using attributes to identify "external" procedures

I think this would be a good idea. It enables account component code to become more versatile, and also contain:

• Convenient exec-wrappers around call-ed procedures - so MASM users don't need to pad and truncate the stack themselves which is error-prone. (To illustrate what I mean with this: move_asset_to_note procedure and an "exec-wrapper").
• Procedures for fetching the commitment to some data via a call to an account procedure and then pipe_preimage_to_memory (or similar) from the advice stack.

Attribute

For naming, I think the attribute for declaring the procedures of an account (the ones that are call-ed), that is most consistent with other attributes we have (@note_script and @auth_script) is @account_procedure.

Maybe this attribute is all we need: All procedures marked as @account_procedure are merged into the account's code. All others are assumed to just be regular procedures and have no attribute. I don't think we necessarily need to mark "internal account procedures" (like your bar example) in a special way.

Procedures from multiple contexts

If we'd also like to ship the exec-wrappers mentioned above, then we'd potentially have three procedures with the same name:

#! The procedure implementing the actual logic.
#! Invocation: exec
pub proc is_paused
    # ...
    exec.active_account::get_item
end

#! The procedure in the public interface of the account.
#! Invocation: call
pub proc is_paused_external
    exec.is_paused
end

#! The procedure that calls is_paused in the public interface of the account while taking care of
#! stack padding and truncation.
#! Invocation: exec
pub proc is_paused_adapter
    # pad stack
    call.is_paused_external
    # truncate stack
end

A slight twist on this procedure naming strategy is to put them in different modules, so that all can be named is_paused. To illustrate, the invocations of these methods could look like:

# Invokes the public interface procedure directly.
call.pausable::api::is_paused

# Invokes the logic procedure directly (e.g. from the account context).
exec.pausable::core::is_paused

# Invokes the exec-wrapper around the public interface procedure.
exec.pausable::adapter::is_paused

With this approach, we could technically even skip requiring the @account_procedure attribute since we could take all procedures from the api module as the public interface of the account.