Running WASM in WASM

[ilblackdragon]

Context

Given async nature of NEAR Native contracts, some types of permission-less innovation are hard to build. We are seeing more and more people learning how to build them, but aiding developer in easier development is always goal of NEAR Protocol.

Examples span from splitting a complex system into a number of contracts or reusing existing contract code - right now usually would mean to build it into a single WASM contract. Similarly if there is a complex interaction between contracts, it will require a complex handling of edge cases.

Allowing to build subsets of contracts in an environment that is synchronous would make a drastic improvement to Native developer experience. This can be done by grouping a number of logical contracts into a NEAR contract.

Logically each NEAR contract is a shard. They then get grouped into physical shards. Meaning each NEAR contract potentially can run up to single shard of capacity.

The most prominent example is Aurora - an EVM contract that runs a separate shard. Inside it contains a number of other executable contracts and sub-states that this contract knows how to interpret.

The con of this idea, is that these subsets would be limited to performance of a single shard. Also this would add an extra trade off that developers need to decide on -- deploy inside an existing container, new container or direct contract. Potentially some containers will have their own ecosystem like Aurora does.

WASM in WASM proposal

The proposal is to allow to create WASM containers similar to EVM container that Aurora is doing. These containers would provide synchronous execution between contracts that are deployed inside it.

There can be different implementations of the containers designed for different use cases.

Here are few examples:

• Container that just allows to componentize the deployment of a single app instead of using a single WASM.
• Container that is designed to extend a specific use case, for example, exchange where new types of AMM pools are added via governance by uploading new kinds as new WASM modules.
• Fully generic container that anyone can use, allowing for fully synchronous execution between apps created by different developers - creating pretty much a WASM sub-chain on NEAR.

Given variety of potential use case, proposal is to create very limited change to the runtime and SDK and allow developers of a container to decide on the specific implementation.

Extra benefit, that such container can implement relayer model, similar to one that Aurora using, allowing users to interact with container and pay no fees or pay fees in other currencies.

Potential implementation

The way it can be implemented is by adding next host function:

/// Runs WASM code found in the `code_register_id` function `method` defined by len and ptr, with serialized arguments in `arg_register_id` and returns result into `result_register_id`.
fn run_wasm(code_register_id: u64, method_key: u64, method_ptr: u64, arg_register_id: u64, result_register_id: u64);

There are two options how to permission / configure this:

• Each wasm file uploaded into single account is stored in predictable place and can be reference by hash. Each contract has also it's prefixed storage. This allows to pretty much have a full contract system inside a single contract.
• Instead allow to scope data access to some prefix in the storage. This way downstream contracts can't read/write to upstream contracts and need to have a call_parent method to access data from caller's contract (pretty much making the native contract as a "host" of subsequent contracts). This allows to implement on demand the previous version.

[bowenwang1996]

I don't quite understand the rationale behind this. If you want to call another wasm contract, why couldn't you deploy the wasm to another account and use a regular cross contract call? If you want to simply execute some function, you can just write it as part of the contract? Did I miss something here?

[ilblackdragon]

Executing another contract in cross contract call are: - async, meaning you have no guarantee when they will execute - failure will not rollback - there is no guarantee / control on the caller what will happen to callee The idea to allow permissionless innovation. For example https://github.com/ref-finance allows to customize pools. But every time will require to commit into the same codebase and deploy via upgrade the contract. This is not going to be permissoinless at all.

…

On Fri, Mar 12, 2021 at 9:22 AM Bowen Wang ***@***.***> wrote: I don't quite understand the rationale behind this. If you want to call another wasm contract, why couldn't you deploy the wasm to another account and use a regular cross contract call? If you want to simply execute some function, you can just write it as part of the contract? Did I miss something here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABK27RRXVFFMLXM5BBMPH3TDI5TZANCNFSM4ZB2H7HQ> .

-- Best regards, Illia Polosukhin

[bowenwang1996]

I see. But if you want to allow it to be done permissionlessly, that seems quite dangerous -- what prevents someone calling this function and change the underlying contract? Or is there some limit as to what this injected wasm code can do?

[ilblackdragon]

As described in the proposal above, there are two different permissions models that can be done.

…

On Mon, Mar 15, 2021 at 8:38 AM Bowen Wang ***@***.***> wrote: I see. But if you want to allow it to be done permissionlessly, that seems quite dangerous -- what prevents someone calling this function and change the underlying contract? Or is there some limit as to what this injected wasm code can do? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABK27VAF64AQF2FZ2SOVA3TDYSVRANCNFSM4ZB2H7HQ> .

-- Best regards, Illia Polosukhin

[bowenwang1996]

I think this is an interesting idea overall. Some questions/comments:

• Does this mean we need a separate host function to deploy wasm contracts into the chain contract? It seems to me that this has to be another host function primarily because we want to compile the contracts at deployment time to reduce the cost when they are invoked. This is similar to what we do inside runtime.
• We need to handle how contracts communicate within a chain contract and between chain contracts. For example you have code_register_id here in the proposal, but I imagine that we need some way to convert higher level object (such as names) to register id. This shouldn't be hard to do as we can create name to contract mapping within the contract. For cross chain communication, you need to build some route of routing table (chain1, contract1) -> (chain2, contract2) and convert them when the chain contracts receive receipts. This will incur some additional overhead.
• This makes it more difficult to implement parallel execution within a shard since many executions can happen within one (chain) contract.

[bowenwang1996]

Naming is interesting point. One option that I've been thinking is that . gets routed into if it has internal sub-system. That was idea for private shard, this can be same for multi chain world as well. We would need somehow to decide that vs when prefix itself is an account.

We can introduce a protocol change to allow predecessor_id in receipts to contain characters that are otherwise not allowed in account ids (e.g, #) and use this to route function calls.

[MaksymZavershynskyi]

We can introduce a protocol change to allow predecessor_id in receipts to contain characters that are otherwise not allowed in account ids (e.g, #) and use this to route function calls.

It would be better if we update AccountId structure from pure string to versioned Rust structure. CC @EgorKulikov @Longarithm

[ilblackdragon]

@nearmax how is versioned struct of AccountId helps in cases of frontends and other tools?

[EgorKulikov]

@nearmax can you elaborate, what you want from such a structure?

[MaksymZavershynskyi]

how is versioned struct of AccountId helps in cases of frontends and other tools?

It helps with protocol development, since we don't need to hack around the account name with special characters.

can you elaborate, what you want from such a structure?

@bowenwang1996 suggested to essentially emulate a Rust enum through using special characters in AccountId. Instead I suggested to convert AccountId to a Rust enum explicitly. However, in general, I am against this whole proposal.

[MaksymZavershynskyi]

This a nice trick with many caveats:

• We won't be able to optimize Wasm in Wasm execution. E.g. current experiments of @olonho and @matklad show 3-4x speedup which won't be applicable to this architecture;
• As contract is entering deeper levels of Wasm nesting using run_wasm there will be suspended Wasm VMs hanging which will make it hard to architect in non-abusable way. Especially as @bowenwang1996 pointed out, in multi-sharded setting;
• This might make our fee computation much harder. And it is already pretty difficult to maintain.
• This might make resharding useless. We won't be able to put the state of the top-level contract into different shards.

Given limited development resources, I would rather prefer us to focus on developing good async DevX, and then circle back to this idea once we have async DevX figured out.

[ilblackdragon]

There might be some missing context, because this proposal doesn't interact with sharding in any way.

Same as EVM is fully enclosed in one account, so as this.This also can leverage most of the optimizations around WASM if done in the way #1 (vs #2 is more generic but indeed limits how much optimizations can be done).We have discussed about various options with @evgenykuzyakov before but this makes it way less invasive than other options.

I'm not sure what are the overhead of running more VMs. Also what are security isolation between different modules in WASM. If we can have single VM with security isolation between modules and dynamic loading of such modules - that probably provide the best performance.

There are some extra security measures, similar to ones that EVM needs to have around re-entrancy and other things required.

Alternative is to keep Promise interface between running these modules but allow to revert the whole Action in case of failure in any of the executions. Though, I think this will be confusing for devs and should be avoided.

[olonho]

Seems like @ilblackdragon suggests adding dynamic codegeneration facility to the blockchain. It looks really tempting, however has its own caveats. Most important ones as performance consideration, especially if we'll implement full contract compilation on deployment, and security, as an innocently looking contract can exploit potential WASM vulnerability.
In light of that, what about adding some other dynamic linking mechanism, i.e. API for calling other contracts "in place",
i.e.

fn call_inplace(contract_id: u64, method_key: u64, method_ptr: u64, arg_register_id: u64, result_register_id: u64);

[bowenwang1996]

API for calling other contracts "in place",

That doesn't seem too different from what @ilblackdragon proposed. In his proposal Illia actually assumes that the contract you call is already deployed. See #173 (comment)

[mattlockyer]

Why not focus on deploying L2 solution like rollups for EVM or NEAR runtime? Optimistic or ZK? Then you get the off-chain computation boost and lower the fees. Within these rollup chains calls would be sync no?

[MaksymZavershynskyi]

We are developer-friendly blockchain and so we want to have the lowest possible barrier for entry for casual developers. With rollups developers would need to learn not only the L1 tech stack, but also the L2 tech stack, increasing the barrier. And this is also not the kind of thing that you can abstract away through dev tools.

[mattlockyer]

I agree deploying your own L2 stack increases the barrier. I'm not advocating we ask each developer to deploy their own rollup contract and run their own network of operators. I was proposing a shared network.

I thought we were discussing is a single contract where multiple contracts can be deployed. Any contract to contract calls in would be sync. This is not unlike Arbitrum for example offering an alternate network where developers simply "deploy contracts", which doesn't seem that complicated:
https://developer.offchainlabs.com/docs/contract_deployment

Products like NEAR Wallet could "switch networks" like MetaMask, transacting with the contracts deployed on a single Rollup chain.

[MaksymZavershynskyi]

Any L2 adds extra complexity for developers and maintainers of devtools. We probably want all our dashboards, libraries, SDKs, frameworks, CLIs to work both with L1 and L2, which means we would need to special-case this L2 in every single devtool, and developers would need to not only know how to point and configure their tools to work with L2, but also understand subtle differences, e.g. that they can run sync dApp on L2, but if they attempt to redeploy their dApp on L1 it would not work; or that explorer/indexer/wallet now need to extract cross-contract call info in a different way and they would mean different things. All that adds extra work for DevPlatform team which we don't have capacity for right now, and having two environments with subtle but critical differences is just as bad as having two completely different environments.

[ilblackdragon]

I agree with @nearmax that Rollups is complexity that neither developers nor users want. They just currently forced into it on Ehterum.

NEAR's way of L2s are these: Aurora and WASM containers.

They provide the customized experience while being fully "realistic" (instead of "optimistic" and need to be proven) and immediately composable with other apps.

This means in the future wallets could actually handle value and apps across all these environments in a transparent to the user way. E.g. it doesn't matter if funds are in Aurora, Ref Finance, on your NEAR account or inside XYZ container - wallet will pull them inside one transaction and deposit into place you want. You can not really do this with what commonly called rollups.

[mattlockyer]

How is UX impacted by solutions like Octopus Network? Isn't this similar?

I understand my comment may be off topic, but why does Octopus get a pass? Is there some magic UX I missed?

[MaksymZavershynskyi]

It looks like we are talking about two problems:

1. Working with async contracts is fundamentally difficult for DeFi, since it inherits complexities of concurrent programming;
2. Contract developers are forced to operate with a contract in a monolithic way -- they cannot update parts of it and they don't have different levels of access control for different parts of the code or contract state;

The first one is a fundamental problem -- developers cannot avoid dealing with synchronization primitives like Mutex/Lock if they want to benefit from parallel processing, even outside the blockchain world. And unfortunately, we cannot abstract it away with the runtime since dealing with deadlocks, livelocks, and race conditions is done on a business-logic level.

The second problem does not necessarily require a Wasm-in-Wasm solution. If we are talking about a simple example when an exchange contract wants to have a code of the pool deployed separately with a limited access to the storage, then it can be done through a cross-contract call mechanism with pool living in a separate code. We can provide a convenience macros/wrapper for it that deals with the Mutex. It is very similar to https://github.com/OpenZeppelin/openzeppelin-contracts -- developers are saved from common contract development mistakes by having some convenience classes written for them. For more complex scenarios, we cannot avoid needing to educate engineers on elements of safe concurrent programming. Most of the DeFi developers have their code interact with the contracts that they cannot escape dealing with async code anyway, and have to educate themselves on concurrency.

There are also issues with the specific proposed solution, as I said before this will make optimization more complex (we cannot do IO pipelining, we now don't know how much RAM to allocate per shard because of varying number of Wasmer instances executing simultaneously, etc). This is also add new scheme for communicating between the contracts, which will make both runtime and all dev-tools more complex.

I suggest the following solution instead:

• A write convenience helpers for simple common cases (e.g. exchange with pools) as part of our Standards library or the SDK. They are simple enough that we can hide away the Mutex/Lock from the contract developers. This is in-line with https://github.com/OpenZeppelin/openzeppelin-contracts approach;
• We start educating contract developers on the proper way of building concurrent contracts, so that they are aware of deadlocks, livelocks, etc.

[ilblackdragon]

I've updated with more context and separated proposal from the implementation details to discuss them separately.

[bowenwang1996]

Container that just allows to componentize the deployment of a single app instead of using a single WASM.

@ilblackdragon this is very interesting. I agree that this gives app developers more flexibility when it comes to deploying their applications. At the same time, I worry that now there are more ways for the deployment/management of the smart contract to go wrong. Do we actually see demand/good use cases for this feature?

[ilblackdragon]

Yes, for example ref finance right now need to update the whole contract even if just want to add a new kind of a pool. There are more complex contracts which require many separate contracts which would be useful to separate both for development, testing and upgradability, also allowing to customize with other versions. But currently it will be required to deploy it as one contract as the synchronicity required between these contracts.

…

On Tue, Dec 14, 2021 at 4:52 AM Bowen Wang ***@***.***> wrote: Container that just allows to componentize the deployment of a single app instead of using a single WASM. @ilblackdragon <https://github.com/ilblackdragon> this is very interesting. I agree that this gives app developers more flexibility when it comes to deploying their applications. At the same time, I worry that now there are more ways for the deployment/management of the smart contract to go wrong. Do we actually see demand/good use cases for this feature? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABK27RKZDKDDHMFXSNTLMLUQ2WNVANCNFSM4ZB2H7HQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Best regards, Illia Polosukhin

[mfornet]

Another example, Aurora can provide a way to deploy WASM contracts rather than EVM contracts inside its container, and have them running synchronously. This could provide ~1500x speed up on computation (without I/O). We are researching the possibility of having an EVM 2 WASM bytecode "compiler" service, so developers can keep using EVM, but not forced to.

However, this makes more sense if we were able to run the dynamic code synchronously (no cross contract calls).

[nujabes403]

@ilblackdragon @bowenwang1996
Is it possible to put a contract deployed by me and a contract deployed by someone else in a container? Or can I only containerize the contracts I deployed?

For example, can I containerize the contract I deployed and the ref finance contract so that they are processed internally synchronously?