Implement native-fungible natively.

[MathieuDutSik]

Motivation

Issue #4416 that is being considered here is about authentication. We have one authentication going on in native-fungible contract code:

                self.runtime
                    .check_account_permission(owner)
                    .expect("Permission for Transfer operation");

This one is done with the authenticated_caller_id being equal to the contract that was calling it.

This is followed in the function fn transfer of linera-execution/src/system.rs by the following:

            ensure!(
                authenticated_owner == Some(source)
                    || authenticated_application_id.map(AccountOwner::from) == Some(source),
                ExecutionError::UnauthenticatedTransferOwner
            );

It looks the same, but it is not: The authenticated caller ID in question is this time the one of the native-fungible contract.

This means that we cannot expect the native-fungible to behave in a way identical to the fungible contract, despite them having the same API. As a practical example, we cannot use crowd-funding with native-fungible.

In the killed PR #5649, it was proposed to expose the stack to the caller who would then be able to select the level of authentication. The problem with this approach is that it exposes us to all kind of possible scenario and complexifies the work of the programmer.

Fixes #4416

Proposal

Implement the native-fungible as an application native to linera. So, now we have applications that are Wasm, applications that are Evm, and native ones.

This is simply a continuation of existing software trends:

• The native-fungible is anyway having its state in the entries balances and allowances of the ChainStateView.
• There is a trend to make such applications (see hyperliquid as an example)

Note that we are still forced to expose some of the stack. But this is done in linera-execution and the functionality are not exposed to the linera-sdk.

Test Plan

CI and add a few tests.

Release Plan

It cannot be backported to testnet_conway.

Links

None

[ma2bd]

I was hoping we wouldn't have to do that given that we already have the VM enum.

[MathieuDutSik]

Three points:

• From a logical standpoint I think this is the right design since Native applications are qualitatively different from Wasm/Revm based ones.

• But yes of course, if we want compatibility with testnet_conway this is a problem.

• I think we can support all Wasm/Evm/Native at the same level. After all there is little that cannot be solved by some programming.

[MathieuDutSik]

See #6269 that demonstrates the concept.

Though more care would be needed to make it work. Also, there are some issues of web compatibility that would have to be carefully considered.