Aurora Cross Contract Calls

[mfornet]

The idea of this document is fully describe how a cross contract call on NEAR can be initiated by an Aurora address.

The following considerations were taking into account while making this design:

• No changes to aurora-engine
• Users from Aurora, that only have an Aurora address/wallet should be able to use them. In particular even users that don't have a NEAR wallet or NEAR tokens.
• It should be compatible with future developments, when they are introduced.

High level description

A new contract,async.aurora, is created and it is used to initiate transactions from NEAR to Aurora and schedule promises "created" inside aurora EVM.

The workflow is as follow:

Off-chain

1. [user] Alice signs a tx T and sends it to the RPC. She pays the gas using ETH.
2. [aurora-rpc] RPC calls async.aurora.submit(T). This is a NEAR tx so RPC should pay NEAR Gas.

On-chain

3. [async_aurora] async.aurora schedules a call to aurora evm contract: aurora.submit(T) and attaches a callback to itself to wait for the result.
4. [evm] aurora contract is executed, and the result is passed back to async.aurora
5. [async_aurora] result is parsed into Vec<Promises>, and all these promises are created.

Notes:

• On 2) We must prevent side effects from a malicious relayer sending the tx directly to aurora instead of to async.aurora. The consecuences would be that the tx would have an impact on aurora, but promises will not be scheduled.
• On 3) This must work with multiple silos.

1) User sign a transaction

Alice signs a regular tx using their wallet of their preference.

2) Aurora RPC

If the tx is expecting any promises to be triggered after its execution it should be invoked through async.aurora. Aurora RPC needs a mechanism to tell those txs apart:

The proposed solution is to have a contract deployed on aurora that will have an interface to route txs and returns promises. Aurora RPC will send all txs that target this contract through async.aurora.

Notice: In practice nothing prevents the relayer from sending any tx through aurora or async.aurora, so it is responsibility of each aurora contract to verify if the predecessor account id is the one they expect. This is possible after #462.

Implementation details of async.aurora

# Rust contract on NEAR
class AsyncAurora:
    def call(self, args: AuroraCallArguments):
        # Value will be always 0
        assert(args.value == 0)
        
        # See Engine `CallArgs`
        ext_aurora.submit(
            payload = args,
            # Target Aurora ID
            target = args.silo_account_id,
        ).then(ext_self.call_back)
    
    
    def call_back(self, promises: Vec<Promise>):
        assert_self()
        
        promises = [None] * len(promises)
        
        for ix, promise_desc in enumerate(promises):
            promise = create_promise(
                target=promise_desc.target,
                gas=promise_desc.gas,
                value=0,
                payload=promise_desc.payload,
            )
            
            if promise_desc.combinator is None:
                promises[ix] = promise
                
            elif promise_desc.combinator.combinator_type == And:
                promises[ix] = promises[
                    promise_desc.combinator.promise_index
                ].and(promise)
                
            elif promise_desc.combinator.combinator_type == Then:
                promises[ix] = promises[
                    promise_desc.combinator.promise_index
                ].then(promise)
            

Aurora Engine CallArgs definition.

enum CombinatorType {
    And,
    Then,
}

struct Combinator {
    combinator_type: CombinatorType,
    promise_index: u8,
}

struct Promise {
    target: AccountId,
    gas: Option<u256>,
    payload: Vec<u8>
    /// Combinators are used to concatenate promises conviniently
    combinator: Option<CombinatorDescription>
}

Implementation details of Aurora router contract

The main goal of this contract is to provide a signal to the RPC that this tx should be routed through async.aurora, only tx sent from async.aurora will be accepted.

# Solidity contract on Aurora
class AuroraRouter:
    def __init__(self, expected_predecessor: AccountId):
        self.expected_predecessor = expected_predecessor

    def run(self, address: H160, payload: [u8], attach_msg_sender: bool):
        assert(self.expected_predecessor == env::predecessor_account_id())

        if attach_msg_sender:
            payload = concat(payload, msg.sender)

        ret = call(address, value, payload)
        return ret

Relevant notes

• Initiating a NEAR Cross Contract Call todays costs less than 1Tgas
• This proposal will be followed up with a full example about how it should be used. Native Aurora ERC20 connector to NEAR.

Changelog

• Use regular transactions instead of meta transactions, proposed by @birchmd on Aurora Cross Contract Calls #461 (comment)

[birchmd]

I wonder if we could avoid meta-transactions here if we make it so that there is not a special pathway needed for the relayer to handle the case of transactions which could trigger promises on NEAR.

Currently, the flow for sending transactions to the chain is:

1. [user] uses tool (eg metamask, truffle, hardhat) to create signed transaction and pass it to Aurora RPC via eth_sendRawTransaction
2. [RPC] creates a NEAR transaction from relay.aurora to aurora calling method submit
3. [Engine] processes the input, returns SubmitResult
4. [RPC] parses result from NEAR transaction, passes back to user as web3 JSON response

To accommodate the possibility of transactions which trigger further operations on NEAR, I think we only need to change step 2 as follows:

2. [RPC] creates a NEAR transaction from async.aurora to itself calling method submit

Now instead of a relayer account calling the engine, this new async account calls itself (and will have internal logic to call the Engine). This should not be much more expensive in terms of NEAR gas than the current flow because the first receipt is "local". async.aurora will still pass the transaction on to the Engine, but now additionally could look for promises to schedule. If there are none then it simply returns the result (preserving the same flow as today), but if there are some then it will schedule them before returning the Engine result to the RPC.

I think this is nicer because the change is entirely internal; users will not suddenly be prompted to sign arbitrary messages instead of submitting a normal transaction if a dapp decides to start using the functionality. I also like that the relayer doesn't need to do any special dispatch depending on the type of input it receives. (To make this work with silos some dispatching may still be needed, but at least the type of the input will always be the same.)

Regarding the question of guaranteeing that transactions which cause the Engine to return promises to be scheduled will always have those promises created; I think that it could be a feature, as opposed to a bug, if those promises could actually cross NEAR transaction boundaries. The reason is because we may already be tight on NEAR gas with just the Aurora execution, so the created promises may run out of gas. In this situation I think it would be good if the first transaction called the Engine directly (instead of async.aurora), parsed the response to see what call to make next, and then make that call as a separate transaction. Notably this flexibility means the downstream NEAR contracts may need to check the Engine state instead of trusting the sender of the call because not all calls will come from async.aurora.

[mfornet]

In this situation I think it would be good if the first transaction called the Engine directly (instead of async.aurora), parsed the response to see what call to make next, and then make that call as a separate transaction.

This is possible today without doing nothing on our end. But this proposal aims to solve the use case of users that only have an aurora wallet & no NEAR wallet.

---

I like this approach more than the one using meta-transactions. It is definitely simpler (which is desirable). The main drawback I see is that we need to prevent a malicious RPC from sending the content of the tx directly to aurora skipping async.aurora. This is also a problem on the initial proposal, but can be prevented inside the contract logic by checking the field msg.signer, which will be pointing to evm_implict_address("async.aurora").

The other variant we discussed was to expose predecessor_account_id as a precompile in the EVM. That would allow both using submit mechanism and only triggering some special behaviour in case the contract was called from async.aurora. I initially didn't like the idea because the execution of the EVM will depend on this value, however, as you pointed out, this is not a major drawback. @birchmd @joshuajbouw WDYT

[birchmd]

I do not think adding predecessor_account_id as a precompile in the EVM is much of a drawback. The work required to implement it is minimal, and the interface of a precompile which takes no arguments is simple to communicate to developers that need it.

[mfornet]

Got it, I'll update the description of the proposal accordingly!

[birchmd]

I created a PR to add the relevant precompiles! #462

[joshuajbouw]

As @birchmd, he nailed it. I'm seeing this post the changes, and don't have much more to add to it. Makes sense. See my note below however.

[karim-en]

@mfornet
some questions:
1- def call_back(self, promises: Vec<Promise>): where the Vec come from? as I see the submit doesn't return Vec of promises.
2- how the result of ext_aurora.submit will be handled, so I mean which part of infrastructure will process that?
3- I know that the "Native Aurora ERC20 connector to NEAR" example is a separate part, but could you please write a couple of words about how it will work with this concept?

[mfornet]

1. fn submit returns EngineResult<SubmitResult>. In the case the transaction is successful the status of the transaction will contain the encoded result as a byte sequence.

In the call_back this sequence should be deserialised as Vec<Promise>.

2. async.aurora will handle that part. On NEAR the result of the previous promise is passed into the next promise, so if you call.
   A.then(B.call()).then(A.callback()). The result of B.call() will be passed into A.callback()

3. Yes. I plan to write a similar discussion for it to have in depth discussion. In the mean time: Roughly there are two contracts, minter-factory on NEAR side, and Locker in Aurora side. To send tokens from Aurora to NEAR the on chain workflow would be roughly:

send lock token transaction to async.aurora
  send this transaction to aurora.submit
    aurora_router receives the tx and sends it to locker
      locker make sure the tokens are locked, create an in storage event and returns encode([promise(mint_token)]).
  async.aurora receives the list of promises, and sends the promise to token.factory.near to be minted
    token.factory.near calls aurora about the event stored by the locker
      locker checks predecessor account id to be token.factory.near burn the event and returns true
    token.factory.near mints the tokens in favor of the user.

[joshuajbouw]

We must have versioned calls. If others have the possibility of using a different version of a call in the future, we need to be able to handle this for compatibility in case something changes.

We could also have the enum parser trick which will simply try to parse each input to match the correct structure, not exactly requiring a version # at all. So if input latest structure fails, downgrade and try the next.

It would increase gas slightly for the 2nd option if others are using an older call, but it's ideal IMO.

In general, even if Aurora handles the ecosystem entirely, anything cross contract should require some form of handling of possible new structs down the line.

So, two options.

[sept-en]

If you are talking about versioning of "promises message" that will be used as a return value from the Solidity locker - then I agree with you. Or were you referring to something else?

[sept-en]

Btw, we can use a typed data structure for the payload, something similar to EIP-712.

[alexauroradev]

Some comments from my side...

1. In the initial post there are async.near and async.aurora. Are these different?
2. A bit saparate, but still influencing the matter... There's a long-discussed idea of removing relayer.aurora account and instead add function keys to aurora that will be disposed to relayer. Thus we would be saving time on Aurora txs execution (2s -> 1s), since no NEAR cross-contract call is initiated. This might influence some of the things that @birchmd have been suggesting.

Now, a bit of the philosophy. The above discussion is centred around how to implement the functionality. I would like to put on the table a bit of what is expected. Ethereum ecosystem is a thing-in-itself. Even though functionality to call NEAR contracts interacts with something external to Aurora, the interface for this functionality should live inside Aurora. Simply, just to allow all the complicated interaction with this piece created by 3rd party contracts (imagine: getting a loan, putting a part of the tokens to a farm, sending another part to NEAR farm, saving some tokens on interim account to allow for potential losses because of closing the opportunity because of the async execution on NEAR). Moreover, mainly, user would like to get the result of the interaction back, since just scheduling some call doesn't make sense. And such results must be delivered in the familiar form -- as results of the transaction execution.

From my point of view, for the Aurora developer the simplest construct would be the following.

1. Inside Aurora there is a new contract (probably a precompile) that can schedule promises outside Aurora. Such contract should return the hash of the promise.
2. As a separate function, a developer should be able to get the result of the execution of the promise inside Aurora and use it further. For this another function should be available, which returns the result of the promise execution.

Separation of the execution. The actual call outside Aurora may be executed inside an initial Aurora tx or completely separate, opening a market for those who want to pay for such calls. Obviously, Aurora msg.sender, should be depositing some ETH for the execution of the call in the precompile.

Sender identifier. Now, an important thing that should be solved is how to correctly pass through the promise its' creator. This can be done at least through a new NIP, which would specify the interface for the meta-txs on NEAR (maybe there's already one?). Alternatively, Aurora contract can spawn abcdef12345...0.aurora accounts through which it would proxy the calls (similarly to how RB ERC-20 connector factory does it). Such accounts may be a representation of the user accounts inside Aurora and be used for various other reasons. Independently to the chosen approach of the implementation, this problem should be solved one way or another.

Storage considerations. Additional tricky point in this approach is the storage of the execution results. From one hand, if you want to separate the execution and the usage of the results into multiple NEAR transactions (and I believe this is what should be done), you either should store the execution results OR use NEAR light client to prove the results of the execution on the go. Second option from my point of view is an overhead for this use case and it complicates the usage of the functionality too much. From the other hand, if you need to store the data, then you face the problem of bloating the state. And this would be particularly an issue in the case of massive communications with NEAR contracts. So a piece that manages the lifetime of keeping the results on-chain is necessary. If can be as simple as 1) one needs to pay for the allocation of the storage for the result of the promise during scheduling it (and pay for it's execution), 2) a creator of the promise may delete the execution result through ordinary Ethereum means, which will result in returning the gas costs. This logic may become more complicated with some automation in the future.

The above approach is from my point of view is that is the simplest schema and thus can can be comprehended by Ethereum developers much faster than the NEAR runtime. This approach can be extended to message passing interfaces (specifically, MPI) that are the most scalable approach for cross-program interactions in supercomputers (i.e. environments with parallel execution). The details of the implementation of this scheme is out of the scope of this post, but for sure need to be dived deep into.

[mfornet]

FYI here is a discussion with the first use case for this tool: Native Aurora ERC20 To NEAR.

[joshuajbouw]

As a follow up with the call, @mfornet had mentioned that we should have a sort of solidity SDK that others can use to make it more friendly for them. It makes sense to add it to the design.

[alexauroradev]

Using the approach, the developer can even call a function and attach a callback to react directly on the effect of its transaction in the same way it works on NEAR today.

@mfornet, sure, this can be done, but the pull approach would be OK in the beginning too.

[mfornet]

The precompile will only call the schedule method, and there will need to be some kind of external service (provided by us or others) that runs the execute method.

@birchmd do we actually need a precompile for this? can we just use a regular contract with the same effect? The downside I see, is that accessing msg.sender will be challenging; and it would be easier on a precompile. It can be addressed though!

The good sides: It is way easier to iterate on that code (upgrade in case of new formats, combinators, etc...) and no changes to the engine.

[birchmd]

That's a good point. If the promise data was persisted in aurora itself then a regular contract would suffice and it would be more maintainable for sure.