Proxy contract on main account to JSVM

[encody]

I've noticed a few discussions around difficulties integrating JSVM smart contracts with the larger NEAR ecosystem, e.g. cross-contract calls, standards integration, access keys etc.

I think many of these issues could be solved almost completely transparently by generating a proxy WASM contract to deploy to the main account. This contract would merely forward native method calls to the correct call_js_contract call on the JSVM contract, remapping arguments as necessary. However, this would solve the function-call access key issue, the standards integration issue, and the cross-contract calls in one fell swoop.

Is this a viable solution?

[thisisjoshford]

Interesting... 🤔

So you propose that a user would deploy two contracts? One standard wasm file that would have the same methods but they actually perform a cross-contract call to the second contract deployed in the JSVM?

[encody]

Yes. It wouldn't work for view methods, since view calls can't perform cross-contract calls, but it would probably improve ux otherwise.

[ailisp]

Proxy contract is an innovative idea and will solve some problem, but developer need to write their proxy contract, in Rust (Or in standalone JS sdk, but that storage cost drawback comes). The proxy contract cannot be auto generated from their JS contract, the reason is explained in the following common use case:

The goal is to call from a js contract to a rust contract. Rust contract checks the predecessor_account_id to control access permission and we don't want it to be "jsvm.testneat". So developer add the proxy contract, now user calls the proxy contract. The proxy contract forward argument to JS contract. The proxy contract also invokes the Rust contract, to get predecessor_account_id right.

Therefore, the proxy contract invokes both JS and Rust contract. If user want process the return value of the Rust contract, they cannot do that in the JS contract. They need to write in the proxy contract in Rust. The proxy contract will look like:

// call some js contract
// call some rust contract
// callback(value returned from js, value returned from rust)
// fn callback() {
//     call some other js contract(value returned from js, value returned from rust)
//     or some rust code to do with (value returned from js, value returned from rust)
// }

[encody]

You're absolutely right, this would also mess with the predecessor account. There would have to be some sort of handler built into the proxy contract that would forward the "original" predecessor account ID, and then some sort of exception in the JS contract that substitutes in the "original" predecessor account ID where it originally was the proxy's.

I do think it would be possible to auto-generate the proxy contract; I don't think it would be strictly necessary for the JS contract authors to manually write them, especially since that would add so much to the workload to make it unreasonable.

As for when the JS contract wishes to send a cross-contract call (and doesn't want the predecessor ID to be that of the JSVM), the proxy could solve that issue as well if the JS contract reroutes cross-contract calls through the proxy contract. Yeah, it's another layer of indirection, and therefore complexity (and inefficiency), but it's more friendly to the existing ecosystem if the JSVM contracts are 100% compatible with native ones (or at least, as close as possible).

[volovyks]

The Aurora team has a vision that is similar to the ideas described here, but structured: https://github.com/aurora-is-near/AIPs/pull/2/files
It is using two more contracts inside of the enclave (if I git it right).
The discussion is here: https://forum.aurora.dev/t/cross-contract-calls/304/2
It can affect our decision on Enclaved vs Standalone.
cc @ailisp @AustinBaggio