## 3 Towards Autonomous SC with Tenderfone
### An Agent-Oriented Language for SC  
Tenderfone comes with a declarative language based on first-order logic (FOL). In particular, it adopts the Prolog syntax; hence, its interpreter is a Prolog engine--tuProlog [35; 36] is the chosen one. Despite the choice of a declarative and logic language for smart contract programming is not new [37], as it allows the design and implementation of SC at a higher-abstraction level, in Tenderfone  
Figure 4: General layered architecture of smart contract (SC)-enabled blockchain technology (BCT). we leverage logic programming as a means to endow smart contract with goal-oriented reasoning. Given this choice, a Tenderfone SC is actually a logic theory against which goals, expressed as Prolog terms, can be proven. Or, in other terms, it is a knowledge base describing the application state and enabling to check properties of such states (e.g., to verify that transactions respect some constraints). Such a KB is actually split in two parts: _(i)_ a static part stores the the logic program to be executed and is immutable (it is what gets deployed to the blockchain with a deployment transaction), while _(ii)_ a dynamic part tracks the mutable state of the smart contract. Let us provide an overview of how SC code is structured and expected to work in Tenderfone. A Tenderfone SC program consists of many callbacks (i.e., Prolog rules) to be implemented by smart contracts developers. Within the bodies of such callbacks, developers can leverage on a number of built-in predicates ready to use. Callbacks come either in the form \"init(+Args) : -Body\" (we rely on Prolog standard notation for input/output arguments: + is an input, - is an output,? can be both, whereas @ is a ground input) or in the form \"receive(+Msg, @Sender) :- Body\". There, the init callback is triggered (just once) right after a deployment transaction is published, and it is aimed at endowing the SC with its own flow of control, whereas the receive callback is executed whenever _(i)_ a user publishes an invocation transaction, or _(ii)_ the SC is the recipient of a message from a SC (there including itself), as depicted in Table 2. It is worth highlighting that messages sent through the send(+Msg,+Recipient) built-in are characterized by asynchronous semantics. This implies the receive callback is eventually triggered on the recipient SC if, and only if, execution of the sender's entry point (where send is called) terminates successfully. This implies that the recipient callback is always executed after the sender's one--even if sender and receiver coincide. Within callback bodies, Tenderfone SC can autonomously affect its own control flow in several ways, thanks to some built-in predicates that have been conceived to serve this specific purpose. For instance, the Tenderfone language endows smart contracts with the \"deploy(+Interval, +Message, -GeneratedID)\" built-in predicate, which allows the calling SC to postpone a computation of some relative Interval of time, by scheduling the execution of some receive callback for a later moment in time. Similarly, the \"periodic(+Period, +Message)\" built-in predicate provokes the periodic execution of some receive callback on the calling SC, thus allowing smart contracts to perform cyclic, time-related activities. Finally, off-chain users can interact with Tenderfone smart contracts by means of an API composed by three primitives, namely \"deploy(+Theory, +Args)\", \"invoke(+Message, +Receiver)\", or \"observe(+Query, +Receiver, -Answer)\", aimed at instantiating, triggering, or inspecting a smart contract, respectively. In particular, the deploy API primitive provokes a deployment transaction to be registered on the blockchain, whereas the invoke one provokes the registration of an invocation transaction. Conversely, as the observe primitive is aimed at letting users query the inspectable status of a particular SC in a read-only fashion, it does not provoke any transaction to be registered on the blockchain.