As a first step, we start with the presentation of a basic calculus–see, e.g., Fokkink, (2007)—for the description of the isolated behavior of sequential processes.

Let Act be the set of actions, ranged over by a, b, … , including also the special internal action τ. The set L of process terms of the basic calculus for sequential processes is generated through the following syntax: P ⩴ 0 ̲ ∣ a . P ∣ P + P ∣ B where we have the constant 0 ̲ for the inactive process, the classical algebraic operators for prefix and nondeterministic choice, and a constant based mechanism for expressing recursive processes, such that a set of constants defining equations of the form B = d e f P is assumed. As standard, we consider only guarded and closed process terms. The semantics of process terms is expressed in terms of labeled transition systems.

Definition 1. A labeled transition system (LTS) is a tuple (Q, q ₀, L, R), where Q is a finite set of states (with q ₀ the initial one), L is a finite set of labels, and R ⊆ Q × L × Q is a finitely-branching transition relation.

As a shorthand, (q, a, q′) ∈ R is denoted by q → a q ′ . Then, the behavior of process term P is defined by the smallest LTS ( L , P , A c t , R ) , where the transitions in R are obtained through the application of the operational semantics rules of Table 1. The prefix rule is at the base of the sequential behavior of processes, stating that a. P executes a and then behaves as P. The two choice rules express the nondeterministic choice between P ₁ and P ₂. The winning process proceeds with its execution, thus disabling once and for all the other one. The recursion rule establishes that the process term named B and defined as P, behaves as P itself; naming enables the definition of recursive behaviors.

Example 1.

As a first running example, we consider a social network in which various agents contribute to the spreading of (possibly fake) news. A detailed version of this system is modeled and analyzed in Aldini, (2022), by using a formal framework that turns out to be an instance of that proposed in this work. Here, we start considering a simple, process term: F = d e f n b r . r e - e v a l u a t e . F + f o r g e t . 0 ̲ which models the behavior of a fact checker in such a network. Action nbr denotes the gathering of shared news from the neighbourhood, action forget expresses that any shared news is forgotten once and for all, and action re-evaluate denotes that the process of news evaluation is repeated again.

As another running example, we will consider a trustworthy network of communities, where agents exchange services and the interactions among agents are enabled/disabled by trust/distrust relations. A detailed version of this system is modeled and analyzed in Aldini, (2018) through an alternative framework that, similarly as above, is generalized by the current proposal. Here, we start considering a simple, process term: T = d e f s n d _ req . r e c _ acc . T + r e c _ ref . T + l e a v e _ com . 0 ̲ describing the behavior of a trustor, which may ask for services from the unique provider operating in the community to which the trustor belongs. Action snd_req denotes a service request sent to such a provider, which in fact represents the trustee subject of trust evaluation by the trustor; the request can be either accepted (action rec_acc) or refused (action rec_ref). Alternatively, the trustor may decide to abandon the community (action leave_com).

In the following, an agent is any instance of a given process term P, which is referred to as the behavioral type (or pattern) of the agent. In other words, an agent represents an element exhibiting the behavior associated with a process term. Agents are associated with a unique identity, which in the following we denote with a natural number for the sake of simplicity. Moreover, each agent is equipped with a local data repository, used to store local parameters as well as data retrieved from sensors or received from the neighborhood. Such a repository is represented as a set of local atomic predicates. By assuming a standard first-order logic interpretation, predicates are of the form v = d, with v ∈ VNames a local variable and d a value of the corresponding domain.

Formally, an agent is described by a triple of elements ⟨id, P, V⟩, where:

• i d ∈ N is the identity of the agent;

Given the triple ⟨id, P, V⟩, as a shorthand we sometimes use the classical dot notation id. P to denote the local behavior of agent id, id. a to denote an action a enabled by the local behavior P of agent id, and id. v to denote the value V(v) of the local variable v in the local data repository of agent id.

Example 2. A fact checker named id of behavioral type F is described by the triple ⟨id, F, V⟩. The local variables are: type , which expresses the level of susceptibility of the agent to accept shared news; accept , which is a Boolean modeling whether the news is accepted and in turn shared by the agent; threshold , which expresses the minimum number of neighbours that must share the same news in order to consider the news for acceptance.

A trustor named id of behavioral type T is described by the triple ⟨id, T, V⟩. The local variables are: α and β , reporting the number of accepted (respectively, refused) requests, and θ , which represents the trust threshold employed by the trustor for the trust-based evaluation of the trustee.

While it is easy to see that the agent local semantics is given by the semantics of its behavioral type, it is less obvious to determine the agent’s behavior in the context of the environment. Such a context affects also the updates applied by the agent to its local repository. Therefore, we need to define formally the interaction semantics for a network of communicating agents.

A network is a set of agents, which are grouped to form (possibly dynamic) communities. Basically, direct interactions among agents are possible only within the same community. However, each agent, in general, may belong to several different communities at the same time. Similarly as in the case of single agents, each community is associated with a global data repository, storing data that can be shared by all the community participants. Such a repository is modeled as a set of global atomic predicates of the form w = d, with w ∈ WNames ² a global variable and d a value of the corresponding domain.

Formally, a network is a triple of elements ⟨ S , G , W ⟩ , where:

• S is the finite set ⋃ i = 1 n ⟨ i d i , P i , V i ⟩ of n agents in the network, such that id _j ≠ id _k for every pair of indexes j, k;

The semantics of a network and, in particular, the way in which the constituting agents cooperate and evolve, depend on requirements of the specific scenario under consideration. Hence, (almost all) the rules we are going to introduce are actually schemes of rules including customizable elements. The first, fundamental modeling choice is related to the mode of execution, for which we distinguish two classical, alternative cases: asynchronous mode, where every agent may execute an autonomous action while all the others remain idle, and synchronous mode, where all the agents involved simultaneously execute one of their enabled actions.

The general semantic rule scheme for the asynchronous mode is as follows: ( a s y n c ) P → a P ′ ∧ c o n d 〈 〈 i d , P , V 〉 ∪ S , G , W 〉 → a 〈 〈 i d , P ′ , V ′ 〉 ∪ S , G , W ′ 〉 where the side condition c o n d stands for a Boolean formula composed of logical predicates over any combination of identities, communities, local variables, and global variables taken from the current network triple ⟨ { ⟨ i d , P , V ⟩ } ∪ S , G , W ⟩ , and stating whether the action a offered by the local behavior P of agent id is enabled in the network environment. Hence, the side condition is actually of the form c o n d ( a , i d , V , S , G , W , V ′ , W ′ ) . The additional terms V′ and W ′ depend on V and W , respectively, and represent their updated versions by virtue of the execution of the action a. More details about these terms and the definition of the side condition will be provided through examples. Notice that, for the sake of readability, in the rule scheme above and in the following ones, the side condition c o n d is reported without making the list of arguments explicit.

Example 3. We present three typical formats for the atomic predicates that can be combined through logical connectives to define the side condition c o n d in the rule scheme async :

1. id. v⋈k , with ⋈ any arithmetic comparison operator and k a scalar value belonging to the domain of the local variable v : such a condition is purely local as it does not depend on the context in which agent ⟨id, P, V⟩ operates;

Analogous patterns can be envisioned by defining conditions over id rather than over id. v .

Later on we will show some exemplifying conditions specifically adapted to the application domains of interest. As stated above, the rule scheme async expresses also potential side effects of the execution of the action a over the local variables of the agent id and/or over the global variables of the network. Formally, the terms V′ and W ′ represent the updated versions of the terms V and W , respectively. On one hand, they may be equal to V and W , respectively, to express that no change occurs. On the other hand, they may be defined in terms of updates occurring in V and W . To this aim, in the following examples we will use the standard notation s′ = s[x↦d] to express a mapping s′ equal to s in every point but x, where s′(x) = d.

Summarizing, the rule format states that if the agent of the network defined as ⟨id, P, V⟩ enables locally a move, and such a move is permitted by the environmental conditions, then the agent is allowed to evolve and change accordingly the variables under its control.

We point out that, as a special case, ad-hoc actions can be envisioned to model movements to or from communities, which is typical of dynamic scenarios–see, e.g., Aldini, (2022) for a possible semantic characterization. Just notice that such a kind of actions would affect the structure G of the tuple describing the network configuration. As an example, the general semantic rule scheme describing the action of leaving a group is as follows: ( l e a v e ) P → l e a v e _ com P ′ ∧ c o n d 〈 〈 i d , P , V 〉 ∪ S , G , W 〉 → a 〈 〈 i d , P ′ , V ′ 〉 ∪ S , G ′ , W ′ 〉 where leave_com is the name of such an action, the side condition c o n d specifies the enabling situation and the identification of the community G ∈ CNames that the agent id is leaving, V′ and W ′ express possible updates to the local/global repositories V and W due to such a move, and G ′ = G ( G ) \ { i d } represents the update of the involved community. We can reason analogously for a corresponding action join_com modeling the entry into a community G, in which case we have G ′ = G ( G ) ∪ { i d } .

From the cooperation model standpoint, the rule scheme async enables forms of knowledge-based communication. Indeed, if the local repository modification (and/or the side condition c o n d ) depends on some content deriving from the environment, then a data-driven communication from the environment to such an agent is actually modeled. Analogously, writing to the global repository, to which any other agent may have access, represents a form of community-based multicast communication. Sometimes, these forms of (asynchronous) communication are not enough as two (or more) agents have to synchronize over a certain event. To model such a kind of interaction, the following general semantic rule scheme is needed: ( s y n c ) P → a P ′ Q → b Q ′ ∃ G ∈ C N a m e s . i d 1 , i d 2 ∈ G G ∧ c o n d 〈 〈 i d 1 , P , V 1 〉 , 〈 i d 2 , Q , V 2 〉 ∪ S , G , W 〉 → a × b 〈 〈 i d 1 , P ′ , V 1 ′ 〉 , 〈 i d 2 , Q ′ , V 2 ′ 〉 ∪ S , G , W ′ 〉 where the action a × b expresses the simultaneous execution of the actions a and b, so that the two involved agents evolve synchronously. The form of the side conditions is as discussed above, with the additional constraint that the two agents involved in the (synchronous) communication must be members of the same community, which is formally expressed by the predicate ∃ G ∈ C N a m e s . i d 1 , i d 2 ∈ G ( G ) . As a special case, it is possible to define an ad-hoc semantic rule scheme modeling a multicast synchronous communication from an agent of a community to the other agents of the same community–see, e.g., Aldini, (2018) for a possible characterization.

We now discuss the case of a purely synchronous mode of execution, which requires a slightly different approach relying on a two-steps semantics. In the first step, the local actions of the agents that are enabled by the environment according to the given side conditions are determined. In the second step, one action per agent is sampled nondeterministically and the system performs a move by simultaneously executing all the sampled actions. By assuming that the network of agents S includes the agent ⟨id, P, V⟩, the general semantic rule scheme implementing the first step is as follows: ( g l o b a l ) P → a P ′ ∧ c o n d 〈 i d , P , V 〉 〈 S , G , W 〉 → a 〈 i d , P ′ , V ′ 〉 〈 S \ 〈 i d , P , V 〉 ∪ 〈 i d , P ′ , V ′ 〉 , G , W ′ 〉 Notice that in the conclusion of the rule scheme, the triple of elements describing the agent is decorated with the subscripted context expressing the environment with respect to which the side condition must be evaluated. More precisely, the rule scheme global expresses whether the network ⟨ S , G , W ⟩ enables the execution of the action a offered in isolation by the agent represented by ⟨id, P, V⟩. This is done through the verification of the side condition c o n d , parameterized by the elements of the triple ⟨ S , G , W ⟩ representing the environment of ⟨id, P, V⟩. The rule scheme expresses also what would be the effect of such an execution upon the agent and upon the network. Thus, the same considerations related to the asynchronous case apply as well, the unique difference being that the global semantics defines what actions can be potentially performed by the agents in the network. Since every agent is expected to enable at least one action to not block the synchronous evolution of the network, we assume also the following rule: ( i d l e ) 〈 i d , P , V 〉 〈 S , G , W 〉 → 〈 i d , P , V 〉 〈 S , G , W 〉 → τ 〈 i d , P , V 〉 〈 S , G , W 〉 the effect of which is to allow the agent to stay idle without blocking the network.

Then, in the second step, the network semantics must express the simultaneous execution of one action per agent. By assuming S = ⋃ i = 1 n ⟨ i d i , P i , V i ⟩ , the semantic rule for the second step is as follows: ( n e t w o r k ) ⋀ i = 1 n 〈 i d i , P i , V i 〉 〈 S , G , W 〉 → a i 〈 i d i , P i ′ , V i ′ 〉 〈 S i , G , W i 〉 〈 ⋃ i = 1 n 〈 i d i , P i , V i 〉 , G , W 〉 → τ 〈 ⋃ i = 1 n 〈 i d i , P i ′ , V i ′ 〉 , G , ∏ W i 〉

In practice, in the premise of the rule each agent (indexed by i) offers a transition labeled with a _i that derives from the application of the rule scheme global or idle. Then, the conclusion establishes that all these moves are performed synchronously, as modeled by the τ action. ³ The proposed scheme is intentionally general. More sophisticated variants of the network semantic rule are however possible. For instance, only specific agents (e.g., of selected communities) could be engaged in the synchronization and perform a move. Alternatively, each a _i in the premise may be replaced by a unique action a, expressing that the involved agents must synchronize on the specific action. Such a condition may be too strong, as some agents may be not available to execute the action a, thus blocking all the others. However, similarly as discussed above, it is sufficient to use an ad-hoc version of the idle semantic rule that adds the action information as a negative premise on a and decorates the τ action with a subscripted a. Then, the network semantic rule may enable the synchronization of the involved agents that offer either a or τ _a . These variants emphasize the flexibility and the expressiveness of the approach, which make it adequate to deal with even very specific requirements of various application domains.

In any case, independently from the chosen mode of execution, the semantics of a system ⟨ S , G , W ⟩ will be given by the smallest LTS with initial state ⟨ S , G , W ⟩ and transitions deriving from the application of the SOS rules at hand. We observe that the proposed rule schemes express a general format that may potentially guide the definition of a library of several, alternative rules. Such rules can be customized to deal with a comprehensive set of behavioral models and application domains. Obviously, a tradeoff exists between such an expressive power and the efficiency issues that may arise when checking complex side conditions in order to build the underlying LTS.

Example 4.

Assume a social network ⟨ S , G , W ⟩ of agents adopting the synchronous mode of execution and including the agent ⟨id, F, V⟩ of the previous example. One specific instance of the global rule scheme, which is related to the execution of action a = nbr , may establish that cautious agents (identified by type 2) accept the news whenever the number of neighbours accepting the news is greater than the agent’s threshold. This rule can be formalized easily, first of all by setting the following side conditions: i d . t y p e = 2 ∧ i d . t h r e s h o l d < ∣ i d ′ ∣ i d ′ ≠ i d ∧ i d ′ . a c c e p t = t r u e ∧ ∃ G . i d ′ , i d ∈ G G ∣

Notice that the neighbours of the agent id are those agents, different from id , belonging to communities of which id is a member. Then, as a side effect, we would also need to update V with the mapping accept = true , i.e., V′ = V[accept↦true].

As another use case, assume that ⟨ S , G , W ⟩ is a trustworthy network including the trustor ⟨id, T, V⟩ of the previous example. In such a scenario, let us assume the asynchronous mode of execution. In particular, assume by hypothesis that the action snd_req of the trustor must synchronize with a corresponding action rcv_req of the trustee in the same community of the trustor. Therefore, we need one specific instance of the sync rule scheme with a = snd_req and b = rcv_req . Then, if the interaction must be enabled only if the trustor trusts the trustee, we would need a side condition as follows: i d 1 . θ ≤ f i d 1 . α , i d 1 . β where f is the specific trust function, like, e.g., the probability expectation of the Beta distribution, α α + β (Jøsang and Ismail, 2002). Another instance of such a rule scheme is related to the synchronization involving action rec_acc , the consequence of which would be the update α = α + 1 in the local repository of the trustor. We can argue analogously in the case of action rec_ref and the related update involving β . Finally, one instance of the rule scheme async would be associated to the execution of action leave_com . If the agent is expected to leave the community whenever the trustee is not trusted anymore, then a side condition of such a rule would be the predicate id θ > f(id.α, id. β). Moreover, two side effects would be given by the corresponding update of the community G ( G ) to which the agent belongs and, possibly, the updates α = β = 0.

In order to show the flexibility of our approach, here we discuss a case study requiring to deal with stochastically timed events. In such a way, our basic process calculus becomes a stochastic process calculus, in which actions are enriched with rates of exponentially distributed random variables that represent the action duration. Thus, such models give rise to stochastic processes in the form of (action-labeled) Continuous Time Markov chains (Clark et al., 2007). Technically, the operators of our basic calculus are still the same, with the trick of adopting the additional syntax and semantics of the stochastic process algebra PEPA (Hillston, 1996; Tribastone et al., 2009). In particular, actions are pairs of the form (a, λ), where a ∈ Act and λ ∈ R + is a positive rate representing the parameter of an exponential probability distribution governing the duration of the timed action. In this setting, the choice operator captures a notion of competition solved via the race policy: the action to execute is the one that samples the least duration. We refer to the citations above for all the details about the semantics of stochastic processes. In our use case, we assume the fully asynchronous mode of execution, so that in the following we have to specify the instances of the rule async tailored to the given use case.

The objective of the case study is to model a network of peers (P2P network) exchanging information about the blocks of a blockchain, which are generated by special agents called miners - see, e.g., Gamage et al. (2020) for a comprehensive overview of this distributed ledger technology. The blockchain model under consideration is permissionless and based on the proof-of-work mechanism (as in the case, e.g., of Bitcoin). Basically, any peer can mine a new block by solving a cryptographic puzzle called proof-of-work. To this aim, it is essential for the miner to learn information about the most recent block added to the blockchain and the data with which a new block is compiled, which depend on the specific application domain (e.g., virtual currency transactions in the case of Bitcoin). Here, we abstract away from the application domain and we concentrate on the blockchain management.

Peers acting as miners have the following behavioral pattern: M i n e r = d e f o b s _ block , p r o p _ rate . M i n e r + m i n e , m i n i n g _ rate . M i n e r ′ M i n e r ′ = d e f o b s _ block , r e s u m e _ rate . M i n e r + a d d _ block , p r o p _ rate . M i n e r

A mining node can notice that a new block was mined and propagated through the miner’s community (action obs_block) and, at the same time, tries to solve the proof-of-work that would allow him to mine the next block (action mine) to be added to the blockchain and propagated to the network (action add_block). The other ordinary peers advertise and relay to their reference communities any new block added to the blockchain. Hence, they simply act as forwarder nodes: P e e r = d e f o b s _ block , p r o p _ rate . P e e r + p r o p _ block , p r o p _ rate . P e e r A peer can notice that a new block was mined (action obs_block) and can propagate newly received blocks (action prop_block).

As far as the local repositories are concerned, every node shall maintain a local copy of the blockchain; for the sake of simplicity we limit each node to store the last block of the blockchain, which is abstractedly represented by a local counter block_id initially set to 0 for every node of the network. As far as the community-based global repositories are concerned, we use a global variable last_block_id storing the most recent block propagated in the community. With such additional information in view–used to define the local mapping V of each node and the global mappings W for the communities–we now define the several instances of the semantic rule scheme async. For each instance, we specify the action of interest, the enabling conditions, and the side effects:

1. case a = obs_block:

The first case, which refers to the observation of a new block by a node in one of its communities, requires the node to update its local copy of the blockchain. The second case, which refers to the propagation of a new block by a node to one of its communities, requires the node to update the global repository of that community. The third case, which refers to the upload of a new block to the blockchain, requires the miner to update its local copy and to propagate the block. Notice that, by the presence of several potential communities (see the existential quantifier over G ∈ CNames), such cases may enable several different outgoing transitions, one per involved community. Any other action, like action mine in our example, does not require side conditions and/or effects, i.e., the async rule scheme is applied with c o n d ≔ t r u e and no variation of the local/global repositories.

Essentially, the specification requires just to define the behavioral pattern of the node types (Miner and Peer) and the pre/post-conditions associated with the execution of the relevant actions. Analogously, we now show through a simple example how it is easy to model properties of interest.

Block propagation delays may potentially impair the correctness of the blockchain sharing process, because a miner could mine and propagate a block before learning of a newly mined block that has been added to the blockchain. Such a misalignment problem is known as blockchain fork. To solve the issue, the network abandons the blocks that are not in the longest chain. Hence, performance and correctness are tightly connected, as the speed at which peers learn of new blocks is related to the likelihood of forks in the blockchain. Recently, in Chandrasekaran et al. (2022) an empirical study of the information propagation delays between nodes in blockchain P2P networks was proposed that emphasizes how the likelihood of forks drastically diminished since 2013. In particular, block propagation delays are estimated in the top four blockchain-based applications, including Bitcoin.

Here, we propose a formal and automated verification of the analysis mentioned above, based on the use of the PRISM model checker ⁷ . For analysis purposes, we decided to instantiate the rates of the timed actions according to the Bitcoin related estimates of Chandrasekaran et al. (2022): the expected time to mine is about 10 min, while the mean (respectively, median) end-to-end propagation delay is about 4 s (respectively, about 0.4 s). Moreover, we modeled various configurations, represented by the topology shown in Figure 1, in which the P2P network radius - represented by the number of involved communities, depicted as clouds - is equal to 6. When a block is advertised in a community, all the members of the community react by experiencing the same delay, so that the overall end-to-end delay of the network depends on the network radius. Two miners are present in the network, while the other peers are either members of a single community or belonging to the intersection of many of them.

For the purpose of model checking, we consider a probabilistic reachability property of the form P ⋈ p ( π ) , where π is an until formula expressing the reachability of a state in which a peer mines a new block and uses it to extend an obsolete version of the blockchain, thus causing a fork. Formally, if we concentrate on the miner with id = 1, such a condition is a mixture of action and state based formulas defined as follows: 1 . a d d _ block ∧ c o u n t i d e | i d e = 1 ∧ b l o c k _ id < max l a s t _ block _ id | t r u e = 1 .

The first conjunct holds when the first miner is enabled to update the blockchain. The second conjunct holds when such an update is obsolete as a more recent block is circulating in the network. We can reason analogously for the other miner, and then join the result of the two properties.

In Figure 2, we show the results of such an analysis by considering the four combinations deriving from two different configuration choices. The first dimension is given by the topology specification: in scenarios A and B we have exactly the representative nodes depicted in Figure 1, while in scenarios C and D only the miners and the peers in the intersecting areas between the communities are modeled. Then, in the first two scenarios we measure the fork likelihood in a period of time equal to 100 min, while in the other two scenarios we refer to a 1 day interval. The second dimension is given by the propagation delay between each pair of peers, which is chosen to correspond to the mean end-to-end delay measured in Chandrasekaran et al. (2022) for scenarios A and C, and to the median end-to-end delay measured in Chandrasekaran et al. (2022) for scenarios B and D. Moreover, each figure presents the results obtained in three different cases: in case (1) both miners experience the same mining delay (10 min), in case (2) the second miner is slower (15 min), while in the third case the second miner is faster (5 min).

In general, case (1) emphasizes that the fork probability is negligible, especially in cases (b) and (d). These results confirm the performance shown in Chandrasekaran et al. (2022). In detail, cases (2) and (3) reveal that the monitoring of the proof-of-work expected time is critical to maintain the fork likelihood at the desired level. Summarizing, already this simple case study illustrates that our framework is flexible and easy-to-use both from the modeling and the verification standpoints, also in the quantitative setting.