3

I would like to understand how Ethereum "messages" (originated from a smart contract) can transfer Ether to another account without a blockchain confirmation.

I have spent several hours reading the yellow paper, the white paper, various links, and three SO questions on the subject, but the subject remains unclear to me.

From the following SO answer I gathered that there are "formal" and "practical" definitions for "messages" and "transactions":

Formal definitions:

Message: Data (bytes) and Value (Ether) passed between two Accounts (either through the deterministic operation of a smart contract or the secure signature of a Transaction).

Transaction: Data sent from an EOA specifically. It represents either a Message or a new smart contract. Transactions are recorded into the blockchain.

In practice:

Message: Data sent from a smart contract. Not delayed by mining because are part of the transaction execution

Transaction: Data sent from an EOA. It's always a transaction that gets things started, but multiple messages may be fired off to complete the action.

That indicates that messages are "not delayed by mining because they are part of the transaction execution".

This SO answer repeats that in different words: "The act of passing a message from one Account to another. If the destination account is associated with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation"

This SO answer indicates "message calls are not published on the blockchain" because they are part of an initial transaction that starts a domino process. (unquoted wording mine)

So lets assume transaction X transfers Y Ether from EOAccount1 to SmartContract1. That transaction gets confirmed on the blockchain in 20 minutes. The EVM code of SmartContract1 triggers, and following the code's instructions in 30 days SmartContract1 sends a message to SmartContract2 with Z Ether. How can the latter Ether transfer be part of the initial transaction? How can it not be confirmed in the blockchain? Thank you.

Improve this question
0

1 Answer 1

Reset to default
8

The distinction between a 'transaction' and a 'message call' is one that people have been trying to clarify for a long time. Message calls used to be called 'internal transactions' and it used to make a little bit more sense. I won't get into a discussion of the merits of trying to change the terminology, but I will answer it this way.

A transaction is from an external account to either another external account or a smart contract. It has to have been 'signed' by either someone or some process outside of the blockchain (that's why its called an external account.)

A message call (or internal transaction) is always the result of a previously initiated external transaction (or, in these terms, just a transaction). Message calls are initiated only from smart contracts, and always from one of the operations of a smart contract that allows it to call into other smart contracts or to any account to send ether.

So an external transaction gets initiated by an external account and it simply sends ether to another account: zero message calls.

An external account initiates a transaction to a smart contract and that smart contract does not call any other smart contracts: no message calls.

An external account initiates a transaction into a smart contract and that smart contract sends some ether to a regular, non-smart contract account: the account gets the ether and a message call happened between the smart contract and the recipient address.

Note that smart contracts can call number of other smart contracts, and that these "chains" of message calls can be arbitrarily deep (dependant on the max gas limit). You'll sometimes see these 'chains' called a transaction's trace. (Or at least the calls into other smart contract appear in the trace.)

The example you mention above can't happen. The first transaction happens and then is over. It may set some bit in the contract's state that later 'permits' or 'allows' the 30-days-later transaction, but that 30-days-later transaction would have to be initiated by another external transaction 30 days later. There is no 'timer' in the EVM.

Hope this helps. Keep reading the Yellow Paper. It's the best source of deep knowledge. It's hard, but it's all in there.

Improve this answer
3
  • Thanks Thomas. So given that ether transfers carried out by messages triggered by a transaction are confirmed in a new block at the same time as the transactiom, then a transaction that ininitiates a chain of messages triggering heavy computational operations could theoretically very well take days to confirm rather than minutes/seconds. Is that correct?
    – Krug
    Aug 10, 2017 at 1:04
  • 1
    @krug Good news. A transaction is an atomic event that's allowed by the protocol. It must complete entirely. The mining delay applies to the signed transaction. The messages can be thought of instantaneous because they must complete entirely to determine the post-transaction state.
    – Rob Hitchens
    Aug 10, 2017 at 2:37
  • 1
    Also, in terms of a pattern, although you can't schedule a future transaction, you can program such an agreement by inverting control. Have the beneficiary claim the receipt and have the contract check if the request is permissible. It's one way to satisfy the requirement of an outside actor starting the transaction when it should run.
    – Rob Hitchens
    Aug 10, 2017 at 2:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.