## 5 Consensus Mechanism
### The Fault-Tolerant Path-Message  
In a fault-free environment, as described in Section 4, the information added to a path-message, as this is exchanged between nodes, is merged with metrics of previous agents into a single sum value. In order to tackle an environment with higher probability of malicious behavior, the information structure of the path-message has been enhanced. Apart from the last state, a number of previous states of the path message are additionally stored. Based on that, it will be feasible to detect the event of a malicious node trying to falsify information of the path message, or even of a group of more than one malicious node trying to collaborate on succeeding that.  
The enhanced structure of the path-message contains the recent \(k\) states of it, by holding data about distinct states submitted by the \(k\) previous nodes. Hence, this structure provides a way of checking at least \(k\) previous steps and ensuring the data has not been falsified. Furthermore, each distinct data record of traffic information is signed by each node, securing the whole process in the case of nodes attempting to tamper with the information submitted by previous nodes. The actual value of \(k\) parameter needs to be set with respect to other parameters such as the length of the path message and the ratio of malicious collaborating agents. Related experiments are presented in Section 6.  
When an agent receives a path-message, it has to sum up the metrics of outbound traffic, observed locally with the ones already existing in the path-message. The accumulated traffic metrics are defined as the new state of the path message. Each agent practically updates the state of the path message and the transition between two states is coupled to the information the agent adds to the path message.  
Formally, let a path-message be denoted by \(\mathbf{P}\), then the path-message is defined as a set of the previous states committed by the last \(k\) nodes.  
\[\mathbf{P}\coloneqq\{\mathbf{H},\mathbf{T}_{0},\ldots,\mathbf{T}_{k-1}\} \tag{10}\]  
where \(\mathbf{H}\) is the list of the previous nodes, and \(\mathbf{T}_{i},\ \forall i\in[0,k-1]\) is the ordered list of state updates (regarding traffic information) committed by each one of the last \(k\) nodes.  
The additional building block required is a formally defined validation scheme, that enables all involved parties to check if a status update is valid or not. In that sense, the rules applied are:  
* An agent can only add outbound traffic during status update. No subtractions are allowed.
* An agent can add outbound traffic to more than one destination as long as the sum of this traffic is bounded by an upper limit that is relevant to the maximum upload bandwidth of the installation. For simplicity reasons, a global value is set for this limit for all agents. These rules are mathematically defined as follows: \[\mathbf{T}_{i+1}=\{\mathbf{t}_{i}^{j}+\mathbf{t}_{i+1}^{j}\mid\mathbf{t}_{i+ 1}^{j}\geq 0,\ \forall j\in I\},\] (11)where \(I\) is a set of IP addresses and  
\[\sum_{j\in I}\textbf{t}_{i+1}^{j}\leq M, \tag{12}\]  
where \(M\) is the maximum upload rate of each installation.