Generic cross chain smart contract communication

[ilblackdragon]

Currently the connectors are specialized for asset transfers. There is big value in that to reduce gas and number of cross contract calls on NEAR side.

But actually this is not really required, next design describes generic connector that allows to communicate for any contracts between each other, where asset transfers would just be special case.

GenericConnector on both EVM and NEAR
   send(receiver: EvmAddress / AccoutId, method_name: string, bytes: Bytes)
      This records event in the form of `(receiver, method_name, bytes)` on EVM or Receipt on NEAR
  receive(proof)
      This gets called with the proof from the other blockchain
      Proof recovers `(receiver, method_name, bytes)` and dynamically executes receiver.method_name(bytes)

Note, that in case of calling Ethereum, method name should be method_name(uint256,...), e.g. containing the method specification so that bytes4(sha3(method_name)) can be done. Bytes should be RLP encoded.

For example, Token Locker like communication can then be implemented by creating a EvmTokenLocker contract that receives tokens and then calls GenericConnector.send(near_token_locker_account_id, "deposit", BorshEncode(receiver,amount)).

In NearTokenLocker deposit method will check that it was called from GenericConnector on NEAR side to allow to execute this operation (e.g. GenericConnector already done all the bridge checks to indeed allow to call this method).

Similar operation on calling withdraw, which would in turn call send(eth_locker_address, "unlock(address,uint256)", RLP(receiver,amount)) to unlock given amount from the ETH locker and transfer it to receiver's address.

This also means that a contract on NEAR can call some special contract on Ethereum, that would for example do set of actions and then call back to this NEAR contract. To keep track of the context for the callback, might need some additional identification system to verify that callback came from the same transaction on the other chain, e.g. some additional Prover logic that would track that this transaction was issuing specific request.

Thoughts?

[abacabadabacaba]

1. Instead of passing method name, one can directly pass the call data (which includes method selector). Solidity provides methods to generate it (abi.encodeWithSelector and abi.encodeWithSignature).
2. In Ethereum, call arguments are not RLP encoded. Solidity ABI encoding is used instead.
3. There should probably be a mechanism to send the result of the call back.