## 5 Consensus Mechanism
### Smart Contract
If the path-message has not reached its maximum length, then the agent has to find out who the next node is, as defined in Equations (15) and (16). It adds the next corresponding agent to the list and forwards the path-message to it. If the path-message has reached its maximum length then the agent has to submit it to the contract through the **path_message_submission0*
* function. In this case, the contract checks the length of the path message, the validity of the last \(k\) state transitions and if no inconsistencies are found, then the path message is added to the pool of path messages that reached maximum length at the specific time interval. These are then combined as described in Section 4, to produce alarms regarding DDoS attacks. * If an issue is observed at a specific transition, then the agent has to report that to the smart contract, through the smart contract **path_message_validation0*
* function. The agent has to report the whole path message to the contract along with the index of the first (chronologically) invalid transition. The contract can automatically validate the claim of the agent and if it stands, then it is going to mark the agent that is responsible for the invalid state transition and all subsequent agents (apart from the one reporting it) as malicious. These nodes are then temporarily (or even permanently) added to a black list of inactive nodes and are not included in subsequent path-messages' paths. The core functionality of the consensus mechanism is depicted in the activity diagram of Figure 2.  
In order to further reduce the malicious behaviors that are possible, the node that conveys the path-message waits for a signed acknowledgment response from the node that receives that. If the response is never sent, then the node chooses another node to convey the path-message to. This feature is protecting the protocol from malicious nodes that will try to stop the transmission of path-messages at some point of the path. If the node receives a response from the subsequent node, then the responsibility of monitoring the future of the path-message is transferred from the former to the latter. Each node can compute the time steps remaining for a path-message to reach the end of its life-cycle and therefore to be submitted to the smart contract. When this happens the smart contract emits an event that is accessible for all agents. If the path-message never reaches the smart contract, then the node that sent an acknowledgment response and never forwarded the massage is assumed to be a malicious one and the dispute resolving protocol is initiated in order to find out who this node is. All nodes that have sent a path-message and received a response wait for the corresponding event that the path-message has reached the smart contract in a specific time slot. If that never happens then they can initiate a procedure in which all subsequent nodes are candidates for being the malicious nodes that stopped the path message forwarding. Each one of these can prove that they behaved according to the protocol by submitting the signed acknowledgment response they received when they actually forwarded the path-message. The agent that has not forwarded the path-message will not be able to make such a claim, so it will be added to the agents' blacklist. As analyzed, the path-message states correspond to aggregated outbound traffic rates to specific hosts for each installation. That means that agents are able to inspect states of previous (in the path) agents and conclude on the hosts to which IoT devices of corresponding installations connect to. IoT devices usually connect to predefined hosts, the identity of which can be easily inferred (e.g., an IP camera connects to the manufacturer's storage service), thus the privacy implications are rather limited. Nevertheless, in order to further minimize privacy implications, the identity (IP address) of hosts can be replaced by a salted hash of it.