## 3 Towards Autonomous SC with Tenderfone
### The Tenderfone Interpreter  
The API described so far requires the underlying interpreter to support asynchronous communication and computation for smart contracts. In particular, such an interpreter should let SC react to both user- and SC-generated messages. This is usually not the case in mainstream BCT implementations, where SC can only react to user-generated messages carried by transactions, as transactions can only be issued by off-chain users. To overcome the aforementioned limitations, we designed the Tenderfone interpreter, which essentially lets SC issue transactions autonomously, and also route messages directed towards other SC with the purpose of triggering them. To do so, Tenderfone relies on a modular design which is inspired to the Tendermint SMR technology. Accordingly, as depicted in Figure 5, Tenderfone assumes the underlying BCT system to be composed by several distributed validator processes, aimed at enacting a consensus protocol to keep track of the many transactions issued by the end-users. Periodically, validators agree on the ordering of the last \(N\) transactions. Then, they pack these transactions into a time-stamped block and forward it to a local interpreter process, which is in charge of executing transactions according to the Tenderfone semantics described in Section 3.1. Validators and interpreters are assumed to exist in equal quantities, and to be deployed on different nodes of the network, in such a way that each validator-interpreter couple runs on a different node. To support the Tenderfone semantics, whenever a new block of transactions is ready, validators and interpreters enact the request-response protocol, defined in [16] and depicted in Figure 6, which aims at executing the transactions therein contained orderly, thus letting smart contracts execution progress. As a by-product of this protocol, a number of transactions may be spontaneously generated by interpreters, for instance to schedule time-reactive computations or to support asynchronous message passing. We call these transactions spontaneous, and they are the core mechanism enabling smart contract's autonomy in Tenderfone. More precisely, the Tenderfone block execution protocol works as follows:  
1. via consensus, validators agree on the content of the \(i\)th (i.e., transactions \(t_{i,j}:j\in\{1,\ldots,N\}\)) block and on its time-stamp \(\tau\);
2. each validator then notifies the beginning of the protocol to its local interpreter, informing it that the management of block \(i\) begins at time \(\tau\);
3. the local interpreter joins the protocol by returning a list of spontaneous transactions, one for each computation which has been previously postponed, delayed, or scheduled to an instant not later than \(\tau\);
4. then, the protocol makes each validator forward each transaction \(t_{i,j}\) to the local interpreter, which in turn * executes \(t_{i,j}\), possibly updating the current state of the system (e.g., by creating, destroying, or altering the internal state of some smart contract), * appends all the outgoing messages possibly sent by any smart contract triggered during the previous step into a temporary outbox queue;
5. once all transactions have been processed, validators notify the commitment of the block to their local interpreter;
6. each interpreter should then conclude the protocol by returning another list of spontaneous transactions, one for each outgoing message accumulated into the aforementioned outbox queue--which is finally emptied. Figure 5: Representation of a Tenderfone system at run-time: a number of validator–interpreter couples are deployed on different nodes of the network and kept consistent via the Tendermint SMR engine. Off-chain entities (e.g., clients) and interpreters may issue transactions, which are ordered validators and executed by interpreters, in a replicated way. Spontaneous transactions generated during the block execution process are accumulated by validators as if they where ordinary transactions issued by end users.