## 1 Introduction
The first approach is the signature-based or misuse-based approach, where the main idea is to recognise the patterns of well-known attacks and then monitor the target system's activities to detect such attacks based on their patterns. This approach has high performance but is inefficient at detecting zero-day attacks or any unknown attack strategies. The second approach is the anomaly-based or behaviour-based approach, where the main idea is to create target system profiles representing supposed \"right behaviours\", where behaviour means a set of related events, with each event representing an interactive action that occurs in the system either internally or externally, and the ordered events collectively represent the system behaviour, then monitor the target system's behaviour to detect attacks based on anomalies that may occur in conflict with the profiles' details. This approach is more effective than the previous approach but assumes that the source codes for the target system will not be accessible when creating the profile. Therefore, profiles will be created based on several techniques, including some AI techniques, but these gained profiles do not provide all behaviours of the target system, including their correct but unusual behaviours. Consequently, high false-positive detection occurs by considering \"correct but unusual\" behaviour as an attack, which weakens the reliability of this approach. The third approach is the specification-based approach, which is considered in some studies as a sub-approach of the behaviour-based approach [14]. The main idea of this approach is to operate analysis techniques on the source codes of the target system in order to extract all trusted behaviours for the target system. Then, during the runtime, just as in the previous approach, the technique will monitor the target system's behaviour to detect the attacks based on any anomalies that may occur in conflict with the extracted behaviours. The main distinction between the second and third approaches is the reliability aspect, as the last approach should achieve high reliability due to the absence of false-positive detection,i.e., all truth behaviours are provided, so no false-positive detections are expected this not like the second approach [12]. Table 1 shows the difference between the three detection approaches. These detection systems, especially standalone-style systems where no direct communication between the detection systems takes place, are commonly used in various cybersecurity products. Our solution, as explained in the evaluation section with different scenarios, will detect any attacks to software in a distributed system that affects behaviour. These attacks can occur on any part of the distributed system software and not limited to the blockchain itself, given that the use of blockchain in the proposal architecture was based on the immutability feature provided in this technology. Examples of attacks that change normal behaviour include malicious code attacks and Denial-of-Service (DoS) attacks. However, some attacks do not affect the behaviour of the software directly; therefore, they remain undetected, such as shoulder surfing attacks and social engineering attacks. However, behaviour-based attack detection techniques are facing challenges that affect their role to preserve distributed software systems against attacks. One of these challenges is ensuring the immutability of the data used for detecting the attacks. This data including both of the predefined trusted behaviours and the observed behaviours during runtime, are supposed to be unchangeable. In fact, such behavioural-based attack detection techniques have strict mechanisms in place that require high accuracy for any data and/or behaviours dealt with. Without these mechanisms the results obtained by these detection techniques will be wrong and thus unreliable. However, the potential vulnerability of stored and exchanged data in distributed systems, especially in terms of integrity, is that storage and extraction behaviours can alter during runtime.