## 3 Towards Autonomous SC with Tenderfone
### An Agent-Oriented Language for SC
#### 3.1.2 Asynchronous Interaction  
Tenderfone smart contracts interact through asynchronous message passing, as follows.  
* receive(+Message, @SenderID) is a callback that specifies what a smart contract should do every time it is triggered by an invocation transaction carrying a Message, and coming from either an end user (through invoke/2) or another smart contract (through send/2) identified by SenderID. The execution of each receive/2 callback, on any smart contract, is atomic and must terminate like in any other SC-enabled blockchain technology. However, differently from other BCT, smart contracts in Tenderfone can trigger their own receive/2 callbacks, autonomously, by means of some mechanisms described below. For instance, a smart contract may simply decide to store the message but process it later on, through the time-aware constructs described in next subsection, so as to preserve its autonomy without hindering the blockchain semantics.
* send(+Message, @ReceiverID) is a built-in predicate aimed at letting smart contracts send messages to each other. It works by simply adding Message to the outbox of the current smart contract, in order to let it be eventually dispatched to ReceiverID. However, the actual dispatching of Message does not occur immediately. Accordingly, we say that the send/2 built-in predicate just \"outboxes\" a Message. As any other built-in predicate, the send/2 one can only be used within the body of some callback. According to Tenderfone asynchronous semantics, the actual dispatching of the (possibly many) messages outboxed by the (possibly multiple) invocations of the send/2 predicate within a given callback is conditioned by the successful execution of such callback. If (and only if) the execution of the wrapping callback terminates successfully, then the messages in the outbox are actually dispatched to their recipients. This implies that the receive/2 callback is then triggered on the receiver smart contracts (i.e., the ones identified by ReceiverID) by means of an invocation transaction, which is generated by the Tenderfone Interpreter whenever some callback successfully terminates.
* answer(+Message, @SenderID, -Result) is a callback that specifies how the smart contract should answer (with which Result) every time it is triggered through observe/3 API primitive (last paragraph) by an end user whose identifier is SenderID. Any side effect possibly produced by the callback during its execution is simply dropped as soon as the callback terminates. In other words, the answer/3 callback is aimed at serving users' queries in a read-only fashion. In fact,this callback is intended to promote encapsulation: by defining many answer/3, the developer chooses which parts of the SC status to make observable.  
It is worth to be noted that any invocation transaction issued by entity \(E\) towards \(SC\) to transmit a message \(M\) is valid only if the goal \"receive(Message, SenderID)\"--subject to Message\(=M\) and SenderID\(=id(E)\)--can be proven against the current KB of \(SC\). In case of success, the current state of \(SC\)'s dynamic KB is committed to the blockchain and, therefore, updated. In case of failure, any change to \(SC\)'s dynamic KB, and possibly any outgoing message queued by send/2, is dropped.