1. Introduction

2. Materials and Methods

2.6. Primitive Symbolic Actions

Interactions among objects, such as actors and agents, usually begin with actions. Typically, actions are invoked or selected from libraries using their labels or names. However, in ObTFL, there are predefined actions that perform basic tasks. For simplicity, these actions are identified by symbols in addition to or instead of their names. Some of these symbolic actions are summarized in Appendix A, while others are explained next. Since there are actions, they can be indexed and associated with conditions.

2.6.1. Stop (∅), Null ($\epsilon$), Repeat ($\circlearrowleft$), and Progress ($⊳$) actions.

To detect abnormal states, incomplete forms, and errors within a compartment, the stop action, symbolized by ∅, is utilized in various combinations. This action halts the progress of an activity before it is completed. An activity may consist of a series of actions enclosed in brackets or a fractional statement. Conversely, the null action, represented by ε, indicates doing nothing. It is commonly employed in junctions when no path is selected.

For instance, the activity A*∅* B specifies that action A is performed, but B will never be reached. However, A* ε* B denotes that A is executed, followed by B; this is equivalent to A*B. Additionally, in a compartment with A/B : a₁ →a₂ : ∅, actor a₂ receives communication from actor a₁ but ignores it. Conversely, A/B : a₁ →a₂ : ε indicates that actor a₂ did not receive the communication, as if the signal is lost or the communication has been hijacked. In both cases, a deadlock occurs if the interaction is synchronous, as a reply from a₂ will never be received by a₁ to be addressed by action B.

This action, represented by ↻, repeats the activity it belongs to, defined by enclosed brackets, a fractional statement, or the entire block, such as (! Send (msg) * ↻) or !Send(msg)/↻. This effectively repeats the action of sending a message indefinitely. If a condition is associated with the repeat action, ↻, as in ↻_{j[1≤j≤n],} it indicates repeating the action n times.

To illustrate the usage of the repeat action, let’s consider the scenario of a persistent man trying to arrange a date with a lady. He sends her an SMS invitation, !Send {sms}. The lady’s phone might be closed or not receiving, ∅, or she receives the SMS, ?{…}, and then she decides to ignore it, indicated by ∅, or reply with a yes or no $\left(!Reply{(}^{’}{T}^{’}\right)\times \left(’F^{’}\right)$. If she ignores him or her phone is closed, he repeats sending the SMS every 5 minutes, ${\int }_{d\left(5\right)}^{@\left(t\right)}$ for three times. If she refuses, by replaying with a false, ‘F’, he performs a stop action that terminates the activity, ∅.

$$\frac{!Send \left\{sms\right\}}{{{\left(\right(\int }_{d\left(5\right)}^{@\left(t\right)}\circlearrowleft )}_{\left[1\le j\le 3\right]}\times \varnothing )\times ?\left(\dots \right)\left({ ⊳}_{{[}^{’}{T}^{’}]}\times \varnothing \right)}$$

$$:man \leftrightarrow woman:\varnothing \times ?\left\{\dots \right\}\left(!Reply{(}^{’}{T}^{’}\right)\times \left(’F^{’}\right)\times \varnothing )$$

2.6.2. Timer or Delay Action ($\int$).

The syntax of the timer or delay action is as follows: ${\int }_{d\left(t_2\right)}^{@\left(t_1\right)}$. The delay process starts at time t₁ and lasts for a duration of t₂. The delay action is a versatile action that can be used alone to introduce a silent period for a specified duration or in conjunction with another action to defer its execution. In some simulation models, delays, such as service and arrival times, play a significant role in the modeling process.

For example, the statement of an action, ${\int }_{d\left(10\right)}^{@\left(t\right)}Delay*A,$ or ${\int }_{d\left(10\right)}^{@\left(t\right)}A$, delays the operation of an actor for a duration of 10-time units, starting from the current time t, before it executes the action A.

There are several variants to the notations of the timer. The notations ${\int }_{d\left(t2\right)}^{@}$, ${\int }_{d\left(t2\right)}^{@\left(t\right)}$ and ${\int }_{d\left(t2\right)}^{@\left(o\right)}$ indicate a duration of t2 starting from the current time. The difference between them lies in the recording of the current time: in the first notation, the current time is not recorded; in the second, it is recorded, in the variable t; and in the last, the current time (o) is an absolute value that remains constant across subsequent calls to the timer.

On the other hand, the notations ${\int }_{d\left(\infty \right)}^{@},{\int }_d^{@} ,{\int }_{d\left(t\right)}^{@} , {\int }_{d\left(0\right)}^{@} \mathrm{a}\mathrm{n}\mathrm{d} {\int }_{d\left(-t2\right)}^{@\left(o\right)}$ signify actions occurring at the current time for various durations: indefinitely, an unspecified but finite duration, specified by time t, starting immediately, and lasting until the present moment, respectively. The last notation is useful for recording events that occurred in the past.

The following statement of the timed action, schedules activities, by only giving the chance to one of the three sequential activities, A, B or C to complete after a duration of time, t2, if the action D cannot start immediately.

$$\left({\int }_{d\left(t2\right)}^{@}\left(A\times B\times C\right)\times {\int }_{d\left(0\right)}^{@\left(t2\right)}D\right)$$

With this statement, if one of the actions A, B and C performing concurrently, has not finished within a period, t2, one of the actions, $\circlearrowleft \times \mathrm{\varnothing }\times ⊳,$ associated with the timer executes. This mechanism can be used for transmission with a time out, like the TCP/IP protocol. In general, this statement has the same effect as, ${\int }_{d\left(t2\right)}^{@}\times \left|\right|A_{i\left[1\le i\le n\right]}$. Some actions of the n-parallel actions are interrupted after time, t2, if they did not complete.

$${\int }_{d\left(t2\right)}^{@}(\circlearrowleft \times \mathrm{\varnothing }\times ⊳)\times \left(A \left|\right|B \left|\right|C\right)$$

2.6.3. Input (?) and Output (!) Actions.

All interactions between actors are initiated by two special primitives: (!) and (?). The first action operator (!) injects a collection of items gathered in a container into the communication medium. This is usually associated with action names such as Send, Register, Transmit, Reply, Open, Login, Close, etc. The second action operator (?) extracts any container injected by the corresponding operator (!). The associated action names with the last operator are Receive, Get, Obtain, etc. While these names are not mandatory, they are occasionally used for readability purposes.

These operators solely exchange the payload of a message, while the communication protocol itself is abstracted in the layer of interaction. The underlying communication protocol is concealed, and interchangeably, we replace IP addresses with the names and identifiers of the requestors and receptors.

Both input and output action primitives can be synchronized with buffered or unbuffered communication, depending on the nature of the interaction between two objects. The primitive receives(?), regardless of the type of interaction, always implements a blocking receive scheme. In this example, the receptor blocks until a message is sent by the requestor. By default, the requestor and receptors are autonomous and perform concurrently unless they are synchronized to wait for replies from each other. In the example provided, !Send(msg): Requestor → Receptor: Action ?(…), the requestor waits for the message to arrive and then performs the action on it. The notation, ?(…), signifies receiving something in a container of type sequence.

2.6.4. Store (∇) and Retrieve (∆) Actions.

Similarly to the primitives send (!) and blocking receive (?), which are used for passing containers, the primitives store (∇) and retrieve (∆), along with the blocking retrieve (${\mathsf{\Delta }}^{\circ }$), are employed for container sharing. The blocking retrieve behaves similarly to the receive (?). These four primitives can be combined within the same model, providing various perspectives in terms of specification. To illustrate this concept, let’s consider a queuing system.

Figure 6. A single queuing system.

Figure 6. A single queuing system.

A generator acts as an actor or agent within a system, producing customers denoted as C at random intervals, typically every average time interval represented by t1. These customers then join a queue denoted as Q, which is implemented as a sequence and managed by a security agent denoted as S. Once the security agent deems a customer ready to be served, he passes him/her on to the teller denoted as T. This model finds applications in various real-world scenarios such as transportation, communication networks, and banking systems. In this specification, the generator continuously generates an infinite stream of clients, repeating the action Send as shown in the modified UML sequence diagram of Figure 7. The junctions are depicted by the symbol x. In the formal specification, shown below, once a customer is generated, the actor S places him/her at the back of the queue ⊣Q and either terminates or sends a notification to the teller if the teller is not active, identified by the condition of the queue being empty [Q=( )]. The teller retrieves customers from the front of the queue ⊢Q and spends a random time t3 to service them. It repeats the same process or terminates if the queue is empty.

2.6.5. Fail ($⇟$) and Recover ($⇞$) Actions.

The advancement of compartments can be disrupted by various events. Certain compartments may fail to achieve success and are forced to pause, necessitating corrective measures from external entities or, in cases involving intelligent agents, autonomously executing self-repair protocols. These events may arise internally, such as software or hardware failures, malware attacks, or internal interruptions, or externally, like attacks from malicious actors sending viruses or compromising communication infrastructure, or even natural disasters such as earthquakes, floods, and fires. The impact of events on interactions is symbolized by (↝). Figure 8 depicts the various steps to invoke external or internal repairs, where an external event with action, U1, or internal incident with action, U2, occurs and disrupts the actor that’s Fails ($⇟$) after performing the actions, A1. The actor, a2, resume the execution of action, A2, if it is repaired by an external actor, b, or it perform its own self-repair action, B.

3. Case Studies

3.2. Case 3: Blockchain for Cryptocurrency

In a blockchain protocol, such as that used in cryptocurrency transactions, the process begins with a sender node initiating a transaction. This transaction comprises various fields, including a transaction ID, input (representing unspent transaction outputs, or UTXOs, which must cover the specified amount), output (containing sender, recipient, and amount details), signature, and other pertinent information. The sender node signs the transaction data, encompassing sender, recipient, and amount, among other elements, using their private key (e.g., $K_A^{-})$thus generating a digital signature.

For simplicity, let’s define the transaction as a dictionary with specific keys. The signed transaction is then broadcasted to nodes registered within the blockchain network, such as miners, full nodes, and other network participants. Within this context, miners play a vital role in validating and subsequently incorporating the transaction into a block. These miners uphold copies of the blockchain ledger, composed of interconnected blocks. Each block, depending on its size, has the capacity to accommodate numerous transactions, typically ranging from 2000 to 4000 transactions per block. The block header contains essential information, including the hash value of the previous block header, a hash representation of the block’s transactions (such as the Merkle tree root hash or hashing of all block transactions), the block’s size, and the nonce value, often utilized for mining purposes. It’s worth noting that nonce values may or may not be included in all blockchain networks. The memory pool, known as MemPool, serves as a temporary repository for transactions that have been received but not yet validated and included in a block. During the mining process, new transactions continue to arrive and are queued in the MemPool. Transactions are typically stored in the memory pool in the order of their receipt. Some blockchain systems employ prioritization schemes to sequence transactions based on factors like fees and size. Due to the finite memory size of the MemPool, a memory management scheme is implemented, whereby unconfirmed transactions may be removed from the MemPool to make room for incoming transactions.

Figure 9. two blocks chained.

Figure 9. two blocks chained.

The Merk activity hashes the transactions in pairs until the root is reaches which contains the final hash. It is also possible to use a different algorithm where the list of all transactions is hashed all together. Miners send blocks when they finish solving the puzzle, B₃, these blocks although valid they are put in a pending list, A₂, until nodes independently verify and extend the longest valid chain by adding new blocks to it. The length of the blockchain is a proxy for cumulative proof of work.

4. Discussion

5. Conclusions

References

1. D. Serrano, D.; Iglesias, C. A. JSONbis: A Proposal to Extend JSON with Type Information. In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020), June 8-10, 2020, pp. 290-297.
2. Jacobs, S. Beginning XML with DOM and Ajax: from Novice to Professional. Published A press, 2020.
3. Kaye, R. The Mathematical Theory of Predicate Logic. Published by Cambridge University Press, 2020.
4. Stubblebine, T. Regular Expressions Pocket Reference. Published by O’Reilly Media, 2021.
5. S. B. Cooper, and M. Soskova, “Turing machines and Computational Theory,” Published by Spring, 2020.
6. Bernardo, M.; R. D. Nicola, R.D.; M. Loreti, M. Process Algebra and Probabilistic Models: Performance and Dependability Analysis. Published by Springer, 2020.
7. Whitney, J.; Gifford. C; Pantoja, M. Distributed execution of communicating sequential process-style concurrency: Golang case study. The Journal of Supercomputing, Springer, 2019.
8. Vrancken, L.M. The algebra of communicating processes with empty processes. Elsevier, Theoretical Computer Science, 15 May 1997, Volume 177, Issue 2, pp. 287-328.
9. Friedman, A. Communicating with Process Calculus. A Major Qualifying Project submitted to the Faculty of Worcester Polytechnic Institute, August 24, 2022 – May 3, 2023.
10. Nicollin, X.; Sifakis, J. An overview and synthesis on timed process algebras. Timed Specification and Verification. Conference paper, Computer Aided Verification, Springer. First Online: 01 January 2005, pp 376–398,.
11. Umer, M.; Ali, A. Automated Analysis of the Security of the IoT using Pi-calculus. Publish by Springer, 2021.
12. Awais, M.; Yasin, M.; Umar, A. I. Formal Verification of a Secure Message Protocol using the Applied Spi-Calculus. In the Journal of Computer Science and Technology, Springer, 2021.
13. Vasconcelos, V. T.; Kok, J. N. A Theory of Distributed Program Composition. Information and Computation, 2003.
14. Y Liao, Y.; Yeaser, A.; Yang, B.; Tung, J.; Hashemi, E. Unsupervised fault detection and recovery for intelligent robotic rollators. Elsevier, Robotics and Autonomous Systems, December 2021, Volume 146.
15. Al Fikri, M.; Ramli, K.; Sudiana, D. Formal Verification of the Authentication and Voice Communication Protocol Security on Device X Using Scyther Tool. IOP Conference Series: Materials Science and Engineering, The 5th International Conference on Information Technology and Digital Applications (ICITDA 2020) 13th-14th November 2020, Yogyakarta, Indonesia, Volume 1077.
16. Cortier, V.; Delaune, S.; Dreier, J.; Klein, E. Automatic generation of sources lemmas in Tamarin: Towards automatic proofs of security protocols. Computer Security – ESORICS 2020, Springer, pp. 3–22.
17. Blanchet. B.; Cheval, V.; Cortier, V. ProVerif with Lemmas, Induction, Fast Subsumption, and Much More. 2022 IEEE Symposium on Security and Privacy (SP).
18. Yogesh. P. R.; Devane Satish, D. Formal Verification of Secure Evidence Collection Protocol using BAN Logic and AVISPA. Elsevier, 2020, Volume 167, pp. 1334-1344.
19. Adda, M. ObTFL formal language for Spider Network. Internal Technical Report, University of Portsmouth, 2023.
20. Scheidt, N.; Adda, M. Internet of Things: Threats, Landscape, and Countermeasures. CRC Press Inc, 2021, pp. 137-166.
21. Initiative T.H.S., IPC-HERMES-9852: The global standard for machine-to-machine communication in SMT assenbly(v1.2), Technocal report, IPC 2019.
22. Aziz, B. Formal Analysis by Abstract Interpretation, case studies in modern protocols, Publish by Springer, 2022.