OffchainLabs / arbitrum-classic

Powers fast, private, decentralized applications
https://offchainlabs.com/
Apache License 2.0
1.98k stars 1.39k forks source link

Provide interface to deliver message from VMs to standard Eth contracts #55

Closed hkalodner closed 3 years ago

hkalodner commented 5 years ago

Arbitrum uses an asynchronous messaging system for cross contract communication. This is general incompatible the the synchronous call system which standard Ethereum contracts use. This prevents full contract interoperability between Arbitrum contracts and Ethereum contracts.

Despite this, a weaker setup of asynchronous communication is possible. In the current version of Arbitrum, Ethereum contracts can send data to Arbitrum VMs which arrives after a delay with its sender properly authenticated. However the opposite is currently impossible and so there is no way to return data from Arbitrum VMs to Ethereum contracts.

External calls out of Arbitrum VMs show up in the system as messages. Currently messages that go to other VMs are delivered into their inboxes. Messages to other destinations (user addresses or Ethereum contracts) lead to currency being delivered into an EthBridge controlled wallet that can then be withdrawn from by its owner. This avoids the need to make calls directly into untrusted contracts. It would be fundamentally unsound to require that assertions involve making synchronous calls into untrusted contracts since they could be malicious.

There are number of solutions to this issue:

  1. Have a set of whitelisted contracts that are honest which synchronous calls are made to automatically when an assertion is accepted.
  2. Make message calls from a VM be optional and allow any validator independently make them on the VMs behalf after an assertion has been accepted.
  3. Other VM specific solutions

Due to there being a wide array techniques to handle this issue, including the fact that there could be optimized per VM solutions, providing an abstract and pluggable interface to solve this issue would be great. We can then provide a large space of options for people to choose within.

This versatility can be accomplished through the use of the owner interface. An owner is a special contract linked to a VM and trusted by its validators. This contract has a number of management features that affect and are linked to the functionality of the VM.

I propose the addition of the following function to the owners interface which will be called whenever a message is sent from the VM.

function didSendMessage(
    bytes32 _destination,
    bytes21 _tokenType,
    uint256 _amount,
    bytes calldata _data
)

This interface would admit any of the discussed implementation options on a per VM basis.

An additional possible expansion of this interface would be to provide the option to cancel the actual transfer if the owner returns false.

function didSendMessage(
    bytes32 _destination,
    bytes21 _tokenType,
    uint256 _amount,
    bytes calldata _data
) returns (bool)
hkalodner commented 3 years ago

Very interesting to see the thinking in this issue. The generic message bridge we ended up embracing was basically the second option listed here