Cross contract calls

[mfornet]

Proposal to make cross contract calls from Aurora to any NEAR contract

tl;dr: Enable the same API that is currently available on NEAR blockchain, giving exactly the same guarantees (spoiler alert: async model).

Enable NEAR blockchain API

For each host function available on NEAR create a pre-compile with the same interface that allows calling the host function from the solidity code / EVM. This will allow the possibility of accessing the NEAR ecosystem from contracts deployed on Aurora.

Guarantees

NEAR uses an async model, while Aurora strive to have a sync environment. Because of this reason, the result (either success or failures) of this pre-compiles won't necessarily affect the result of the underlying Aurora transaction that initiated this call. This means that even if the cross contract call fails the transaction that executed this pre-compile might not fail.

Whenever possible, if the result of a host function call is perceived immediately after it was invoked (in a synchronous way), this can be handled in the Aurora Runtime. If the effect or result is only perceived in a separate block the result won't affect the execution of the underlying aurora transaction.

Security implications

Each host function needs to be analysed independently, since allowing access to some of the host functions may create some security vulnerabilities for aurora contract or are not required at all. One example of this is promise_batch_action_create_account which can create sub-accounts for the caller account.

All pre-compiles are available at:

nearcore/runtime/near-vm-logic/src/logic.rs

Motivation

Having this available on Aurora will allow better integration between contracts that lives inside Aurora, and native NEAR contracts. Having this features, will remove the need of hard coding some integrations between Aurora and NEAR. Some are already implemented, like moving tokens from Aurora to NEAR ecosystem.

Main motivation for this features is to have cross-contract call available as a pre-compile.

Notice any use of these methods may break the sync nature of EVM contracts on Aurora, and this should be explicitly stated for users and developers making use of this feature.

promise_create

In the case of promise_create it is required to attach some gas, and in some cases some NEAR balance. These are concepts not available in the context of EVM contracts, however, it is responsibility of the developer that will make use of this feature to attach enough resources for making the contract call.

The same way Aurora provides an interface to pay the NEAR gas fees paying with ETH, a similar interface should be used to attach some NEAR tokens to the call. A promise_create that attaches a positive amount of NEAR tokens, will be using it from the attached deposit of the NEAR call and not from Aurora balance.

Async model from sync model

For promises that are scheduled from Aurora transactions, they are only scheduled after the end of the transaction, and in case they were not reverted first from inside the EVM runtime. See more about how withdrawing ERC20 from Aurora to NEAR is implemented.

NEAR API in Aurora

The API for host functions is very low level. Instead we can provide a higher level API, similar to the API existing in near-sdk-rs. I see two potential paths:

• Create pre-compiles with low level API. Offer a higher level API from a solidity library that can be imported.
• Create pre-compiles with high level API.

Priorities

While the proposal encourages to enable all (or several) host functions from aurora runtime, they don't need to be implemented at once. We can implement them on demand, encourage and mentor open source community members to contribute, and give bounties for some of them.

[birchmd]

For each host function available on NEAR create a pre-compile with the same interface that allows calling the host function from the solidity code / EVM

Surely we don't need all the host functions to just have cross contract calls? promise_batch_action_create_account is a good example; I don't think it is a necessary feature to be able to create NEAR accounts from Aurora.

As a side note, from a minimality perspective, implementing cross-contract calls is sufficient to have all host functions because any host functions not required for cross-contract calls could then be contracts on NEAR that could be called from Aurora.

[mfornet]

Agree. While thinking about cross contract calls, I thought about having some "view functions" like predecessor account id, Signer, attached gas/balance, which can be useful to have, as well as the cross contracts API. But for sure we don't need all host functions.

[joshuajbouw]

Just out of pure curiosity, are there any contracts out there right now that are async on NEAR that you are aware of?

[birchmd]

All cross-contract calls on NEAR are async. This is what enables the dynamic re-sharding model (it is assumed at the runtime level that all contracts are in different shards to avoid any incentive for users to "game" what shard their contract ends up in, and allowing the actual distribution of state into shards to change at any time).

[birchmd]

I'd like to add some more details to this proposal. I believe the following API (presented as Rust functions for clarity, but implemented as precompiles in the Engine) is sufficient to have Aurora -> Near interaction. It is based on the corresponding NEAR API, but slightly modified for our use case.

/// Data required to make a call to a smart contract on NEAR
struct CallNearArgs {
  account_id: String,
  method: String,
  /// It is up to the caller to know the ABI of the contract (e.g. borsh, json)
  args: Bytes,
  /// It is an open question as to where this NEAR should come from. I think the best thing
  /// would be if we could use bridged wrapped NEAR.
  near_amount: u128,
  /// This is the amount of NEAR gas to attach to the promise.
  gas_limit: u64,
}

/// Make an async call to a NEAR contract. As with the current exit
/// precompiles, the promise is actually scheduled after the EVM
/// transaction is completed, so the return value is a "dummy" value
/// used for internal bookkeeping (for referencing in callbacks/compositions).
/// The cost of this call in terms of EVM gas should depend on `call_data.gas_limit`
/// to prevent abusing this to run expensive NEAR computations for free via the relayer.
/// This is effectively "send and forget" communication with NEAR since the
/// outcome of the call has no impact on Aurora. See `callback_aurora` to see
/// how to make use of the return value of the call.
call_near(call_data: CallNearArgs) -> PromiseId

/// Chain together multiple NEAR calls. Note this is semantically different from
/// `call_near + callback_aurora + call_near` even though these might look
/// equivalent. The reason they are different is because `callback_aurora` creates
/// a dependency of the EVM transaction on the outcome of the NEAR contract
/// call, while `callback_near` does not.
callback_near(base: PromiseId, call_data: CallNearArgs) -> PromiseId

/// This is what is needed for the error handling of exit precompiles. This function allows
/// handling the result of a NEAR call from within the EVM (by making a contract call). More details below.
/// The `gas_limit` here is denominated in EVM gas; the cost of this call in terms of EVM
/// gas can be equal to this parameter (effectively you consume the gas now to have it
/// available to spend in the callback later).
callback_aurora(base: PromiseId, contract: Address, args: Bytes, eth_amount: U256, gas_limit: u64) -> PromiseId

/// Compose multiple promises into a single promise. This allows consuming
/// results from multiple async calls in a single callback. Example:
/// `let a = call_near(A); let b = call_near(B); let ab = promise_and(&[a, b]); callback_aurora(ab, ...);`
promise_and(ids: &[PromiseId]) -> PromiseId

/// Returns the number of results available from previous promises.
/// 0 in the case the execution is not in a callback; 1 if it is a callback from
/// a simple `call_near`; or more if it is a callback from a promise created by `promise_and`.
promise_results_count() -> usize

/// Get the ith promise result. Returns an error if the call failed, or if the index
/// is out of range.
promise_result(result_idx: usize) -> Result<Bytes, Error>

The most semantically complex function is callback_aurora, so I'll spend some time describing this in detail here. EVM transactions are supposed to be atomic, and callback_aurora aims to preserve this property as much as possible. In particular, if revert is called in the callback execution then the EVM state changes which happened before the NEAR call will also be reverted. This does not make the transaction fully atomic because we cannot take back the call to NEAR, so any state changes that call caused will remain, but the EVM portion of the transaction will be atomic. This atomicity is exactly what is needed for the exit precompiles (per #269).

To enable the atomicity we will need to make changes to the way the Engine consumes transactions. If we do not make any change, then it would be possible for another transaction to change the state out from under another transaction waiting for a response from NEAR. To prevent this, I propose that a transaction which invokes callback_aurora takes a sort of "lock" on the Engine contract so that until the callback resolves other transactions will not be executed.

There is a question here about what the user experience should be like when the contract is in this locked state. One option is that the contract simply returns an Unavailable response and the front-end and/or relayer will need to handle the retry logic. Another option is that the transaction is saved into a sort of queue and a Pending result will be returned. The queue will need to be emptied out via future transactions (I think both ending a new transaction and checking the status of transactions could trigger processing of the queue; remember the NEAR gas spent is not important when transactions pay for themselves via ETH). This increases complexity and perhaps without much value. I'd be interested in know what others think about this. cc @mfornet @joshuajbouw @sept-en

We must also enforce the condition that a transaction can only call callback_aurora at most one time. If it is called multiple times then we cannot tie the atomicity of all the calls together. This restriction should not limit any functionality because of promise_and enabling consuming the results from multiple NEAR calls in a single callback.

It would be allowed to chain together multiple aync calls and atomic callbacks (i.e. the callback makes a new call_near promise and attaches a new callback_aurora). This does not create the possibility for infinitely long executions because everything is still limited by the initial gas limit (from the originating transaction).

@mfornet @joshuajbouw @sept-en please review this and let me know what you think. This introduces a lot of complexity into the engine, but I think this proposal is minimal to meet the requirements of #269 while enabling generic NEAR calls from aurora. Once we approve a high level design then we can schedule implementation work.

[mfornet]

Thanks for writing down the details!

/// It is an open question as to where this NEAR should come from. I think the best thing
/// would be if we could use bridged wrapped NEAR.
near_amount: u128,

In practice this NEAR tokens needs to be attached to the call while used, and this will probably be done by the proxy most of the time. Using wNEAR in Aurora is a cool idea, but notice that if submitter is the same as the aurora caller, it requires to have amount of NEAR duplicated, i.e X native NEAR to attach to the call, and X wNEAR in Aurora to receive. I propose we don’t enforce any particular policy at this step, and instead we leave NEAR refunding to the contract level in Aurora. For example, we can have an EVM contract deployed in Aurora that works as a proxy for every call; it first makes the refund for the submitter, and immediately schedules the real call. Notice how Aurora engine doesn’t need to be aware about this.

[mfornet]

I propose that a transaction which invokes callback_aurora takes a sort of "lock" on the Engine contract so that until the callback resolves other transactions will not be executed.

I think we should avoid any type of locks. There is no good protection against delay tx, since if such tx is added as the first one in a block, all further tx in that block submitted for aurora will fail, and it can be easily/cheaply exploited. Also, right now having a receipt wandering around doesn't consume any gas (that should change, though the new design is not clear), this means that it is possible some of the receipts to be delayed long time. Moreover it will limit ourselves regarding future scaling optimisations, when sharding is available.

Most importantly IMO, is that while we want to provide this interfaces for easy integrations, we are only providing an async model, and not provide any guarantee about synchronicity. It'll be like running tx using same model as NEAR is using today. In this regard, I propose to get rid of callback_aurora altogether, and for this regard use callback_near targeting aurora.call().

[mfornet]

Also we should consider adding support to other read-only host functions like:

• Context API
• Economics API
• Math API (maybe we don't need this one, since it should be already exposed anyway)
• log_utf8

[birchmd]

it requires to have amount of NEAR duplicated

I was thinking the cross-contract calling mechanism under the hood would handle moving the wNEAR around appropriately so that no duplication is needed. E.g. the ERC-20 version could be transferrer right away to the precompile address, and there could be some way for Aurora admin to exit the ERC-20 version of wNEAR into the NEP-141 version.

I don't understand your counter proposal. What do you mean by "contract level in Aurora"?

we are only providing an async model, and not provide any guarantee about synchronicity

I agree that locking is dangerous and potentially exploitable. But I also feel that not providing any kind of atomicity will make this feature difficult to use for devs with previous experience on the EVM. The use-case we have in mind is our exit precompiles and we need atomicity there, so I imagine there are other use cases which will have similar requirements. If we cannot support this because it is too risky then we need to go back to the drawing board for fixing #269.

we should consider adding support to other read-only host functions

Sure, we can do this. But it feels like a separate issue to me because they are not strictly required for the cross-contract calls feature. I prefer if we get the minimal design put together and then we can add nice-to-haves later.

[mfornet]

There is a vulnerability if we allow arbitrary cross-contract calls. It will allow everyone to make cross contract call where predecessor_id is aurora, and some trivial problem with this, is that people can steal FT tokens associated with aurora.

One potential solution for this particular problem, is going through a proxy contract (like async.aurora) before doing the final contract call.

The only automatic cross-contract call are made directly to async.aurora with a special format. We can decide if we will only allow async.aurora to be called from aurora contract. The only job of async.aurora is to proxy all promises to the target, and returns results back. There should be no special permissions for async.aurora given that arbitrary cross-contract calls can be done on its behalf.

Some fundamental issues with this approach are:

• we can't rely only in this API to transfer assets owned by Aurora to other contracts, so still it needs to be "hardcoded" into the engine.
• Cross contract calls will be more expensive since an extra step is required, and it is known that each cross-contract call step is expensive.

[birchmd]

Good catch here! So I guess we are back to the drawing board for trying to fix #269 ?

[mfornet]

we can't rely only in this API to transfer assets owned by Aurora to other contracts, so still it needs to be "hardcoded" into the engine.

I was recently thinking about the quoted issue, and it can be solved, without hardcoding anything in the engine. We create yet another contract on NEAR that will lock the token for the users inside Aurora ecosystem. Then having cross-contract precompiles only will be enough to build all the locking/unlocking mechanics without depending on the engine.