Decentralized Incident Reporting: Mobilizing Urban Communities with Blockchain

Highlights

What are the main findings?

• Development of a decentralized incident reporting system leveraging blockchain and IPFS for urban emergency settings.
• Empirical validation demonstrates the system’s feasibility and performance in terms of throughput, latency, and cost.
• The proposed system ensures real-time notification and accurate incident management through blockchain’s immutable records.
• An incentive model using blockchain-based tokens enhances user participation and system sustainability.

What is the implication of the main finding?

• Enhanced transparency and accountability in urban incident reporting.
• Improved effectiveness and sustainability of urban management through active user engagement.

Abstract

This paper introduces an innovative response to the pressing challenge of rapid and effective incident detection and management in urban settings. The proposed solution is a decentralized incident reporting system (IRS) harnessing blockchain technology and decentralized data storage systems. By empowering residents to report incidents, the proposed IRS enables seamless real-time monitoring and intervention by relevant departments. Built on a blockchain foundation, the proposed solution ensures immutability, transparency, security, and auditability, enhancing data resilience and comprehensive applicability. The proposed system leverages the InterPlanetary File System (IPFS) for the storage of incident proofs to manage the blockchain size effectively. Through the proposed IRS, transparency is upheld, enabling complete auditability of incident details and required interventions by citizens, societal bodies, and governmental bodies. Moreover, an incentive model is introduced to encourage active participation in incident reporting, thereby enhancing the system’s overall effectiveness and long-term sustainability. The proposed IRS integrates mobile technology to facilitate user engagement and data submission, essential for urban emergency management. Empirical validation using the Quorum–Raft blockchain demonstrates the feasibility of the proposed approach in terms of system throughput, incident reporting delay, blockchain size, and deployment cost. Specifically, the system maintains a latency of under 15 s even at high transaction rates, can handle up to 200 incidents per second, and is cost-effective, with deployment estimates for 16 organizations over five years being under 1.99 million USD. The method involves extensive testing with simulated incidents and user interactions to ensure robustness and scalability, showcasing the system’s potential for effective emergency management in urban environments.

1. Introduction

The rapid growth of urban areas and the increasing frequency of disasters have created a need for strong urban emergency management (UEM) systems [1]. Cities now face various challenges, including natural disasters, technological hazards, and public safety threats [2]. As urban populations expand and infrastructure becomes more complex, efficiently managing and responding to emergencies becomes more crucial than ever.

Effective UEM involves planning, coordinating, and implementing measures to prevent, mitigate, respond to, and recover from emergencies and disasters [3]. This field manages natural disasters, technological hazards, and human-caused incidents to protect lives, property, and the environment. It requires collaboration among government agencies, non-governmental organizations (NGOs), private sector entities, and the public [4]. Key components include risk assessment, disaster preparedness, emergency response, and recovery efforts [5]. The goal is to minimize the impact of emergencies through proactive planning, efficient resource allocation, and timely response actions.

Given UEM’s critical role, swift and efficient detection and response to emergencies are more important than ever in our urbanized and interconnected world [6]. These incidents include damage to public property, natural disasters, and public safety issues. The rapid identification and management of incidents are now essential elements of modern governance and public safety [7].

Advanced technologies, such as mobile technology, geographic information systems (GIS), early warning systems, and real-time communication tools, present a transformative opportunity to enhance UEM capabilities. By integrating these technologies and fostering a culture of preparedness, UEM aims to build resilient communities capable of withstanding and recovering from adverse events. Specifically, these technologies empower citizens to become vigilant observers, actively contributing to real-time incident reporting [8]. This potential forms the foundation of a decentralized IRS [9], representing a paradigm shift from traditional centralized reporting frameworks.

Centralized reporting frameworks face several challenges that limit their effectiveness. Reports must pass through multiple bureaucratic layers before reaching decision-makers, causing delays in information flow and slower response times [10]. These systems often lack transparency and accountability, making it difficult to track response actions. They are also vulnerable to single points of failure; a compromised central server can render the entire system inoperative [11]. Furthermore, centralized systems struggle with scalability, often becoming overwhelmed by high report volumes during major incidents, leading to bottlenecks and delays. These limitations highlight the need for decentralized systems that use modern technology to improve speed, transparency, and community engagement.

The proposed decentralized IRS aims to significantly improve the speed and efficiency of response mechanisms [12]. It overcomes the limitations of traditional incident reporting by adopting a wider perspective. This approach includes adaptability to various situations and fosters a cooperative relationship between the community and the governance structure. It serves as a platform that enables citizens to actively contribute to the well-being of their urban environment [13].

The vision for this decentralized system goes beyond just reporting incidents. It aims to create a versatile platform that can adapt to a variety of scenarios. The goal is to encourage community engagement and promote proactive civic participation [14]. The system’s core strength lies not only in its ability to quickly detect and respond to incidents but also in its potential to serve as a dynamic and inclusive platform for citizens’ involvement in urban governance [15].

The effective tracking of actions and interventions by local authorities and government offices within the decentralized IRS is crucial. This feature supports a robust and transparent governance process, ensuring prompt responses to reported incidents and being thoroughly documented [16]. By maintaining a comprehensive record of interventions, the platform establishes a transparent trail, allowing citizens to evaluate how effectively their local authorities address incidents. This tracking mechanism is vital for accountable governance, enabling citizens and administrators to assess the responsiveness of public services in incident management [17]. Furthermore, recorded interventions provide valuable data for policymakers and urban planners. These records offer insights into incident response patterns, help identify trends, and pinpoint areas needing strategic improvements. The ability to monitor and analyze the actions of governmental entities fosters public trust. It supports evidence-based decision-making, enhancing urban safety and security through effective incident reporting [18].

However, achieving this vision is challenging. Implementing such a decentralized system requires addressing complexities related to data security, the authenticity of incident reports, ensuring users’ (i.e., residents’) privacy, and seamlessly integrating with existing emergency response infrastructures [19]. These challenges are significant, but incorporating cutting-edge technologies, particularly blockchain, offers a viable solution to overcome them [10].

Owing to its features, blockchain is a promising technology for enabling a seamless incident reporting system (IRS) [20]. Blockchain introduces transparency, accountability, automation, and efficiency into the incident-reporting ecosystem. Its inherent characteristics, including immutability and decentralization, address concerns about the authenticity of reports and residents’ privacy. This integration promises a robust foundation for creating a transparent, accountable incident-reporting platform.

Blockchain is essential for decentralizing the incident reporting process in urban areas [21]. Unlike traditional centralized systems, which often fail to capture the dynamism and immediacy required for effective incident management, blockchain technology provides a decentralized architecture that empowers citizens to participate actively in the reporting ecosystem. Acting as a distributed ledger, it ensures that incident data are accessible and verifiable by a network of participants rather than confined to a central authority.

The immutability of blockchain records guarantees that once incident reports are validated and recorded, they remain secure and unmodifiable [22]. This feature contributes to the credibility of the reported incidents and fortifies the system’s integrity. Moreover, the decentralized network structure of blockchain enhances the platform’s resilience against potential disruptions, ensuring continued functionality even in the face of node failures or network issues.

Real-time incident reporting and monitoring are imperatives in navigating the challenges of the urban environment [23]. The blockchain-based platform is crucial for achieving this real-time responsiveness. By leveraging the capabilities of distributed ledger technology, incidents can be reported, validated, and acted upon swiftly. The platform transcends the constraints of traditional reporting mechanisms, providing a dynamic and adaptive system capable of addressing the diverse and evolving nature of incidents in urban areas.

Ensuring the authenticity and security of incident messages is critical, given the nature of the information being transmitted [24]. With its cryptographic foundations and decentralized structure, the blockchain establishes an immutable record of incident reports. This not only safeguards the integrity of the information but also mitigates the risks associated with unauthorized alterations or malicious tampering [25]. The platform, therefore, becomes a secure and auditable repository for incident-related data.

Tracking and monitoring interventions by various stakeholders involved in the incident reporting process necessitate a comprehensive and transparent system [20]. The blockchain’s transparency and immutability are pivotal in creating a traceable record of actions taken by emergency services, government agencies, and other entities. This feature enhances accountability, offering insights into the effectiveness and timeliness of responses and contributing to an environment of responsive and responsible governance.

Introducing an incentive mechanism facilitated by tokens stored and managed on the blockchain is crucial for encouraging stakeholder participation [26]. The platform’s integration of blockchain-based tokens provides a transparent and tamper-proof method for rewarding positive behaviors and contributions. This motivational tool fosters a collaborative ecosystem where stakeholders are actively engaged in the incident reporting and resolution processes.

Beyond its technological functionalities, the platform is a catalyst for promoting civic engagement [27]. By decentralizing incident reporting and response mechanisms, the blockchain-based system transforms citizens into active contributors to the well-being of their urban environment. It encourages a sense of shared responsibility and empowers individuals to play a direct role in shaping the safety and functionality of the community.

This research, therefore, embarks on a journey to redefine the dynamics of incident reporting in our urbanized world. It is a call to harness the potential of mobile technology, decentralization, and blockchain to create a resilient, community-driven reporting system.

1.1. Contributions

The main contributions of the proposed work can be summarized as follows:

• This work introduces a decentralized system for incident reporting in urban areas, leveraging blockchain technology and the InterPlanetary File System (IPFS).
• The proposed system ensures transparency and accountability in incident management through the immutable nature of blockchain, which permanently records all incident reports and subsequent actions.
• The proposed system ensures real-time notification of relevant departments and offers an evidence-based framework, enabling a higher level of accuracy for making effective decisions.
• The paper presents an incentive model using blockchain-based tokens to reward residents for accurate and timely incident reporting, enhancing residents’ participation and the system’s sustainability.
• The feasibility of the proposed system is demonstrated through empirical validation using the Raft consensus protocol, highlighting its performance in terms of throughput, latency, and cost.

1.2. Paper Organization

Table 1. List of abbreviations.

Abbreviation	Description
IRS	Incident Reporting System
UEM	Urban Emergency Management
IPFS	Interplanetary File System
DApp	Decentralized Application
ISP	Identity Service Provider
BIM	Blockchain Incident Management
RISC	Record Incident Smart Contract
CID	Content Identifier
RAFT	Reliable, Replicated, Redundant, And Fault-Tolerant
IoT	Internet of Things
GIS	Geographic Information Systems
GPS	Global Positioning System
API	Application Programming Interface

presents the notations used in the entire paper. The remainder of this paper is organized as follows: Section 2 reviews existing works, requirements, and main stages of building an IRS. Section 3 details the proposed framework. Section 4 presents the architecture of the proposed IRS and the protocol workflow, showcasing the complete life cycle of an incident in the proposed scheme. Section 5 discusses the experimentation and analysis conducted to demonstrate the system’s feasibility. Section 6 compares the proposed IRS with existing traditional systems. Finally, Section 7 concludes the paper and discusses future work.

2. Literature Review

2.1. Existing Incident Reporting Systems (IRSs)

In the evolving landscape of incident reporting and management, many new solutions have emerged to meet the diverse needs of various industries.

The Safety-Reports Incident Reporting App prioritizes real-time recording and investigation of workplace incidents, including injury and illness reports [28]. It aims to reduce documentation time through mobile devices, ensuring due diligence via a simple investigation method and enabling data analysis for preventive action planning.

The Trackforce Valiant Security Incident Reporting Software [29] provides a comprehensive solution for security personnel to report incidents. It leverages technology to enhance traditional reporting mechanisms, including time-stamped video, photo, audio, and GPS location data alongside textual evidence. This approach streamlines the reporting process and ensures the creation of credible reports that can withstand legal scrutiny. The system is designed to adapt to the specific needs of various security operations, offering features like digital tracking of incidents, simplification of guard reporting, and production of litigation-resistant reports.

The Risk Assessor’s free Incident Reporting Software [30] streamlines the process of reporting workplace incidents. It enables users to efficiently complete Near Miss, Incident, and Ill Health Reports, integrating features such as PDF report generation, which can be downloaded or emailed. This solution emphasizes ease of use and accessibility, offering online and mobile app options for report creation and management. It also features analytics to leverage incident data for safety improvements, allowing for live safety statistics and insights into incident types and trends.

In [31,32], the authors focus on the Critical Incident Reporting System (CIRS) within healthcare to enhance patient safety. They evaluate CIRS’s effectiveness in identifying risks and improving clinical risk management. They emphasize the importance of a supportive error-reporting culture and management commitment to patient safety. The core idea of CIRS is reporting observed safety-related events so that they can be systematically analyzed and serve the reporting person and others in the healthcare system.

For more examples, refer to the article [33] that comprehensively surveys some incident reporting and management systems. It highlights the evolution of these systems with the advent of smartphones and web-based platforms, allowing citizens to report incidents such as accidents, domestic violence, and burglaries through various means.

2.2. Blockchain-Based Approaches

Blockchain technology, first conceptualized in 2008, revolutionized digital transactions by introducing the concept of a decentralized ledger [34]. This technology has evolved significantly, extending its applications beyond cryptocurrency [35]. The main properties of blockchain include its decentralized nature, immutability, transparency, and enhanced security [36]. These attributes make blockchain an ideal solution for various sectors seeking robust data integrity and trust mechanisms without centralized control [37].

The expanded use of blockchain across diverse sectors such as finance, supply chain management, healthcare, and governance exemplifies its ability to adapt and innovate within various operational frameworks [38]. As blockchain continues to evolve, its application in specialized systems, particularly in incident reporting, showcases its adaptability and the expansive range of its utility.

In [39,40], the authors propose a system that addresses the current limitations of traditional incident reporting systems by ensuring data integrity, enhanced transparency, and guaranteed traceability of reports. The importance of blockchain in this context lies in its ability to create a decentralized, immutable ledger for incident reports, which ensures security and privacy and facilitates real-time information sharing among stakeholders. This approach incentivizes reporting through rewards and significantly enhances patient safety and healthcare quality by enabling a more reliable and effective incident reporting and learning ecosystem. While the authors presented theoretical concepts in their work, it was notably limited to health data, and it lacked experimental validation. This omission makes it challenging to assess the feasibility of their approach in practical settings.

The approach in [41] is the proposal of a blockchain-based framework for aviation incident reporting to enhance safety. Its decentralized and immutable nature suggests blockchain can significantly improve the efficiency and security of incident reporting in the aviation industry by ensuring that data remain unaltered and transparently accessible to all stakeholders. This approach aims to foster a safety culture and continuous improvement within the aviation sector. Despite the importance of the use case, this tailored framework for the aviation sector lacks comprehensive details regarding user privacy, data confidentiality, scalability, and blockchain data storage issues. Moreover, the absence of experiments makes it difficult to assess its practical feasibility.

In [16], the authors present a system called BISCUIT for reporting blockchain security incidents, emphasizing the importance of human observations in detecting security issues. BISCUIT uses blockchain to make the reporting process transparent, verifiable, and resistant to tampering. Unlike the healthcare and aviation incident reporting systems previously discussed, BISCUIT focuses on enhancing the security of blockchain networks by structuring and securing the incident reporting mechanism itself. This approach ensures the integrity of security incident data, leveraging blockchain’s decentralized and immutable features to address the challenges in centralized systems. Although the study was centered on the potential of human observations to aid in detecting blockchain security incidents, it failed to address incentive mechanisms or provide performance details. Furthermore, the security of data and the architecture of smart contracts were not analyzed, leaving significant gaps in evaluating their approach.

2.3. IRS Requirements

Our study of existing Incident Reporting Systems, alongside exploring barriers and challenges to effective implementation, has enabled us to establish a comprehensive list of requirements that an ideal reporting system should meet.

• Usability emerges as a pivotal aspect, encompassing a user-friendly interface and an experience devoid of issues [33]. Users in [42] expressed concerns about the usability of incident reporting systems, noting that the process is perceived as overly time-consuming, with reporting training efforts deemed futile.
• The efficiency of an IRS is contingent upon its ability to facilitate quick report submission and response, thereby necessitating a seamless performance [33].
• Transparency fosters trust and accountability. Transparent mechanisms engender confidence in the system and afford stakeholders insights into incident management processes [31,33].
• Anonymity is critical, particularly in contexts where fear of punitive measures or legal repercussions stifles reporting. Systems should afford users the option of anonymity to mitigate apprehensions and encourage candid reporting [33,42]. For instance, refs. [39,43] note that within the medical sector, additional challenges of the effectiveness of the IRS include the fear of punitive measures and legal and financial repercussions. Another study [44] on road accidents in India highlighted that approximately 74% of witnesses are reluctant to report incidents or assist victims due to the fear of legal complications and police harassment.
• Clarity refers to the imperative to delineate what constitutes reportable incidents, underscoring the importance of clear reporting guidelines. The authors in [45] discuss the need to know what to report in the context of incident reporting systems in healthcare. This work critiques the initial simplistic ambitions of incident reporting in healthcare, comparing the ideal scenario to the aviation industry’s “orange wire” concept [46], which symbolizes system-wide learning and rapid action. It reflects on the failure of the healthcare sector to develop a similar effective social infrastructure for investigating, understanding, and improving based on incident reports. It addresses misconceptions like “Report it all”, “More is better”, and “Incidents measure safety”, among others. It points to a fundamental misunderstanding or misapplication of incident reporting principles, such as overemphasizing data quantity over quality, misusing reporting as a performance measurement tool, and lacking effective feedback and learning mechanisms. Another example is from [47], where in the aviation industry, safety investigators express concerns regarding the issue of excessive reporting, which may drown out critical safety signals amid a flood of irrelevant information.
• Incentivization is essential for robust reporting. Financial incentives, coupled with a culture that valorizes reporting, can promote users’ engagement [31,48]. Authors in [48] added that incident reporting is of little value and wastes time, and they advised that financial incentives for generated reports might be a greater motivation for reporting.
• Feedback mechanisms assume significance in fortifying the reporting loop. Effective feedback acknowledges the contributions of reporters [41] and instills confidence by demonstrating responsiveness to reported incidents [39]. Furthermore, the lack of feedback mechanisms exacerbates usability challenges within incident reporting systems. For instance, in [49], over 50% of providers expressed uncertainty regarding their reports’ acknowledgment and impact. Establishing mechanisms for post-reporting follow-up could potentially incentivize greater engagement in reporting practices, thereby fostering a culture of accountability and continuous improvement.
• The security and confidentiality of data are non-negotiable imperatives in IRS design [39,40]. Robust security measures are imperative to safeguard sensitive information, thereby assuring users of data integrity and privacy [33,39].
• Scalability emerges as a critical consideration in designing and implementing an IRS. As noted by [39], achieving scalability presents a significant hurdle, particularly in expanding IRSs to encompass a broader network of healthcare facilities. The scalability challenge extends beyond mere technical limitations; it encompasses the capacity of IRSs to accommodate increasing volumes of incident reports while maintaining system performance and reliability.
• The cost effectiveness of an IRS warrants careful consideration. While reporting systems offer immense potential for enhancing incident management, their deployment entails significant financial outlays [42].

2.4. IRS Main Steps

Effective incident reporting systems encompass a structured approach with distinct yet interconnected steps. We can distinguish between four main steps in this process: report submission, validation and verification, incident processing, and evaluation and learning. Each stage is crucial in ensuring incidents are accurately reported, thoroughly investigated, and appropriately addressed to enhance organizational safety and mitigate risks.

1.

Report Submission: In the initial phase of the incident reporting process, individuals or stakeholders directly involved in or witnesses to an incident submit detailed reports outlining the event.

2.

Validation and Verification: Following report submission, the validation and verification stage involves assessing the accuracy, credibility, and completeness of the reported information by relevant departments.

3.

Incident Processing: Once reports are validated and verified, they enter the processing stage, where they are systematically reviewed, categorized, and prioritized based on their severity and potential impact. This stage also includes resolving the reported problem or accident, where appropriate actions are taken to address the incident and prevent its recurrence.

4.

Evaluation and Learning: The final stage in incident reporting involves evaluating the outcomes of incident management efforts and capturing lessons learned to enhance future incident response protocols. Additionally, this stage includes the evaluation of the reporter’s contribution to the incident resolution process. This may involve providing ratings or feedback to the reporter, such as assigning star grades or tokens, to acknowledge their efforts and facilitate continuous improvement in incident reporting practices.

Notably, none of the existing approaches cover all four steps simultaneously. Our approach addresses this gap by providing a comprehensive framework that integrates all four essential steps into a cohesive incident reporting and management system.

2.5. IRS and Smart Cities

The concept of smart cities revolves around leveraging advanced technologies to create more efficient, sustainable, and livable urban areas [50]. Smart cities utilize various technologies, including the Internet of Things (IoT), big data analytics, and artificial intelligence. These technologies enhance urban living, from transportation and energy management to public safety and citizen engagement.

A decentralized IRS aligns perfectly with the goals of smart cities [51]. By enabling real-time, citizen-driven incident reporting, the IRS enhances public safety and empowers residents to actively participate in the governance and maintenance of their urban environment. This participatory approach not only improves the responsiveness and efficiency of emergency management but also fosters a sense of community and shared responsibility among citizens.

Moreover, integrating the IRS with other smart city technologies can lead to even greater benefits. For example, data collected through the IRS platform can be combined with IoT sensors and GIS data to provide a comprehensive view of urban incidents, enabling more effective and timely interventions [52]. Additionally, the transparency and accountability ensured by our blockchain-based system can help build public trust and promote a more open and collaborative relationship between citizens and city authorities.

By addressing the critical need for efficient incident management in urban areas, the IRS contributes to the broader objectives of smart cities, making them safer, more resilient, and more inclusive.

3. Proposed Framework

The proposed system revolutionizes how incidents are reported in cities. It leverages cutting-edge digital tools, including blockchain and IPFS storage, to facilitate secure and transparent reporting. Combining these advanced technologies enhances security, fosters trust, reduces vulnerabilities, and ensures resilient storage. This represents a significant advancement in creating reliable and efficient incident reporting systems (IRS) for urban areas. In this section, we delve into the key components of the proposed system, providing an in-depth exploration of the stakeholders involved, the decentralized infrastructure utilized, and the crucial communication channels that link all system components.

3.1. System Actors

Several actors are integral to the functionality and success of the proposed system. These actors, ranging from users to departments, each have unique roles and responsibilities that contribute to the overall effectiveness of the IRS. Figure 1 outlines the use cases for the main actors in our system, the user, and the department, which are then elaborated upon.

3.1.1. User

The first actor in our system is the user. A user is a physical person who interacts with the system primarily through a dedicated mobile application. This mobile application serves as the main interface for accessing all features and functionalities related to incident reporting and management. The application contains the user interface and necessary APIs to communicate with the system.

Users can perform various actions, such as account management, reporting incidents, tracking incident status, confirming incidents, providing feedback, receiving rewards, accessing incidents, and receiving notifications. These actions are seamlessly facilitated through the user-friendly interface offered by a mobile application. In the following text, we detail these actions to provide a comprehensive overview of how they are carried out.

Account Management: Users commence their interaction by creating an account through the mobile application. Upon registration, they gain the ability to manage, update, and enhance their profile information directly within the application interface. This feature empowers users to modify personal details or add supplementary information, ensuring the accuracy and currency of their profiles.

Reporting Incidents: After completing their profile, users can initiate incident reporting via a dedicated and user-friendly interface after completing their profile. Through the mobile application, users can report various incidents, encompassing fires, road accidents, thefts, robberies, damages, and health emergencies, by furnishing comprehensive details alongside evidence and proofs. They can augment their reports with descriptive text and multimedia evidence, such as photos, videos, or pertinent documents, to support their claims effectively.

Moreover, users can engage in the “witness” mode during event creation, converting the application into a smart witness. In this mode, the mobile application leverages specific phone sensors, including GPS location and humidity sensors, combined with AI-driven environmental metrics or other sensor data to gather additional evidence. Additionally, users can use in-app features for smart proof collection, which facilitates capturing environmental metrics or photos tailored to the nature of the reported incident.

These measures strengthen the accuracy and comprehensiveness of reported incidents, thereby assisting decision-makers and involved parties in evaluating incident quality and enhancing the responsiveness and reliability of the decision-making process.

Confirming Incidents: Upon initiating the creation of an incident, the user’s input details undergo thorough cross-verification with existing active incidents stored in the system. This verification process aims to prevent the duplication of incidents within the system. If a match between the user’s input and an existing active incident is found, the user is promptly notified and allowed to validate the matched event instead of creating a new one.

The validation process involves the user reviewing the details of the matched event and confirming its accuracy. This is facilitated through a dedicated validation report incident form, which closely resembles the incident creation form. Users can provide additional details, multimedia evidence, and sensor data to corroborate the validity of the matched event. By leveraging this validation process, the system ensures the accuracy and integrity of incident data while avoiding redundancy.

Tracking Incident Status: Furthermore, as the incident event lifecycle progresses, involved actors can track its status and evolution over time, enabling efficient management and resolution of reported incidents. This validation mechanism enhances the efficiency and reliability of the IRS, fostering trust and accountability among users and stakeholders.

For instance, upon detecting a new incident on the blockchain, involved departments can signify acknowledgment by adding a “received” flag to the incident record. Departments can then designate the incident as “under investigation”, “confirmed”, “resolved”, “invalid”, or other statuses to indicate its current stage in the resolution process.

The progress and actions of departments involved in incident resolution are subject to scrutiny by other entities and stakeholders in the system. Notably, any claims, status changes, or actions undertaken by departments are open to validation by the broader stakeholder community, reinforcing accountability and transparency throughout the resolution process.

Providing Feedback: Users can also provide feedback or comments specifically related to the resolution process or the outcomes of reported incidents. This feedback is tailored to the specifics of each incident and its handling. Examples of feedback may encompass various aspects, including the following:

• Delays: Users can highlight instances where delays in the resolution process impacted the timeframe for handling the incident.
• Inappropriate Handling: Users can flag instances where the event may have been mishandled or not appropriately addressed.
• Resource Insufficiency: Feedback may address cases where insufficient resources were allocated or utilized in addressing the reported incident.
• Output Quality: Users can comment on the quality or adequacy of the resolution’s end result, ensuring that the outcome meets expected standards.

This feedback mechanism empowers users to contribute to continuously improving incident resolution processes. By providing insights into areas of improvement or commendation, users play an active role in enhancing the effectiveness and efficiency of incident handling within the system.

Receiving Rewards: Upon a user’s creation of an incident and subsequent confirmation by a trusted official entity (e.g., fire department), rewards are distributed to various stakeholders involved in the incident reporting and confirmation processes. The distribution of rewards follows a predefined formula tailored to each stakeholder’s role.

Creators and validators of incidents receive distinct allocations of rewards, reflecting their respective contributions. Early validators are incentivized with higher rewards to encourage prompt and accurate validation of incidents. Similarly, users providing accurate information or precise incident reports are rewarded at a higher rate to ensure that valuable contributions are duly recognized and incentivized.

Accessing Incidents Details: The proposed system enables users to request access to all incidents stored within it and selectively validate specific events, potentially earning rewards. This selective validation mechanism transforms each user into a potential witness, enhancing the reliability of stored information while incentivizing active engagement.

Users can view and access incident history and records, filtering incidents based on criteria such as timeframes, locations, or specific attributes. This streamlines the retrieval process according to user preferences. Additionally, users can perform queries for validation or statistical insights, examining details like incident frequency, types, and geographical distribution. These statistics provide valuable insights into patterns, trends, and concentrations over time and across locations. This feature allows users to monitor the progress and outcomes of incidents they have reported or engaged with.

Receiving Notifications: Users can receive notifications or alerts concerning updates on reported incidents, their resolutions, and the distribution of rewards. This feature ensures that users are kept informed about the progress and outcomes of incidents they are associated with. Additionally, users can opt to receive notifications or alerts prompting them to validate specific events. They can accept or decline these validation requests, streamlining the validation process by allowing users to prioritize their participation based on their availability and interest. Furthermore, users can receive real-time alerts tailored to incidents occurring within specified geographic areas, enabling prompt notification of incidents happening in locations of particular interest to them.

3.1.2. Department

The department stakeholder represents official entities responsible for executing specific tasks or providing services within a designated geographic area. These departments can be affiliated with governmental bodies or operate as standalone organizations. Examples include the Fire Department, Police Department, Identity Verification Department, Emergency Medical Services, City Government, Environmental Protection Agency, Public Health Department, Emergency Relief Organizations, Employment Verification Department, and Utility Companies.

Departments have a variety of responsibilities within the system, including incident management and response, updating incident status, asking for user confirmation, issuing alerts, providing feedback and continuous improvement, reward distribution, addressing user feedback, and accessing incident details. These functions are integral to ensuring the efficient and reliable operation of the IRS. In the following text, we detail these responsibilities to give an overview of their execution comprehensively.

Incident Management and Response: Departments oversee the operation and management of incidents within their jurisdiction. This includes monitoring and addressing various incidents such as fires, road accidents, thefts, robberies, damages, and health emergencies. Each department uses data from reported incidents to construct and execute its incident response strategies. For instance, the fire department uses these data to maintain a comprehensive overview of incident activity, ensuring timely response efforts.

Update Incident Status: Departments report and track real-time status updates and the progress of incidents, ensuring transparency and facilitating user audits. This provides stakeholders with up-to-date information on incident status, actions taken, and progress made, fostering accountability and trust within the IRS.

Ask for User Confirmation: Departments can request user confirmation for specific incidents to ensure the accuracy and validity of reported events. When a department identifies an incident that requires additional verification, it can prompt users who have reported or are located near the incident area to confirm its details. This process involves sending a notification to the relevant users, asking them to review the incident information and provide confirmation or additional evidence if needed. Users can respond through the mobile application to corroborate the incident’s details, add multimedia evidence, or suggest corrections. This user confirmation mechanism helps departments verify the authenticity of incidents, reducing false reports and enhancing the reliability of the incident management system. By involving users in the confirmation process, departments also foster a sense of community participation and accountability.

User Engagement and Profile Building: Certain departments assist users in building their profiles within the system. For example, The Identity Verification Department verifies users’ real identities and generates verifiable credentials. Other departments, such as the Employment Verification Department, provide credentials related to users’ employment status and job titles. This support helps users develop the necessary skill sets and experiences for effective incident intervention. Some of these organizations play a crucial role in assisting users with building their profiles within the proposed system. For instance, the identity verification department aids in verifying users’ real identities and generating verifiable credentials that may be pertinent in certain scenarios, such as proving residency within a specific area. Additionally, other departments are instrumental in helping users acquire verifiable credentials to streamline their involvement in specific incident circumstances. For example, the employment verification department may be tasked with providing users with verifiable credentials related to their employment status, job title, and the nature of their work. Furthermore, various departments may intervene at this stage to assist users in developing their skill sets and experiences, which are essential elements for effective intervention when necessary.

Issuing Alerts: A department can issue validation alerts within a designated area. For instance, the police department may send targeted alerts for specific incidents requiring validation, which is a relevant mechanism to mitigate false alerts and reduce intervention costs. This targeted approach ensures that validation efforts are focused on incidents requiring attention, optimizing resource allocation, and enhancing the efficiency of incident management processes.

Feedback and Continuous Improvement: Departments receive and address user feedback regarding reported incidents’ resolution process and outcomes. This feedback mechanism allows users to highlight delays, inappropriate handling, resource insufficiency, and output quality. By incorporating user feedback, departments can continuously improve their incident resolution processes, ensuring effective and efficient handling of incidents.

Reward Distribution: Departments establish and manage reward mechanisms for incident reporting and validation stakeholders. Each department implements its system, including engagement tokens that can be exchanged for real money or used within the system for discounts and services. These reward systems are tailored to each department’s specific needs and contexts, influenced by factors such as the nature of the incident, the availability of validators, and the geographical context. The transparency of these mechanisms enhances trust and credibility within the system, ensuring that stakeholders can track the distribution process. Additionally, departments can update their reward mechanisms based on user feedback and the behavior of validators, allowing for a dynamic and responsive approach to incentivizing participation and maintaining system integrity.

Similar to users, departments have wallets and can access incidents, manage profiles, and receive notifications. This allows them to filter, monitor, and analyze incidents for efficient response and strategic planning.

3.2. System Architecture

Integrating advanced technologies into the system architecture enhances its capabilities and functionalities, ensuring efficient incident reporting and management processes. This section delves into how various components work together seamlessly to achieve these goals. From the DApp acting as the central interface to using Smart Contracts and IPFS for secure and transparent transactions and data storage, each element is vital in fostering transparency, efficiency, and accountability within the ecosystem. Furthermore, the section explores the role of external tools, such as Decision Making Tools, Statistical Tools, and AI Tools, which augment the system’s capabilities, empowering stakeholders with enhanced insights and functionalities. This comprehensive approach ensures that the system remains adaptable, responsive, and equipped to effectively address the evolving needs of incident resolution. Figure 2 illustrates the key components involved in the proposed reporting system.

3.2.1. Decentralized Application (DApp)

DApp [53] acts as the system architecture’s central interface for users and departments. It provides access to various features and functionalities related to incident reporting and management, catering to all stakeholders’ needs.

The DApp offers users a user-friendly interface accessible through various platforms, including mobile devices and web browsers. It facilitates seamless user onboarding and identity verification processes, ensuring authenticity through verification by the Identity Service Provider (ISP). Additionally, users can communicate in real-time with other system actors, such as official departments and stakeholders, receive alerts, and participate in feedback and improvement processes. Prioritizing user experience and accessibility, the DApp empowers users to contribute effectively to incident reporting and management.

In contrast, for departments, the DApp provides essential tools and functionalities for efficient incident management, accessible through web-based interfaces or dedicated departmental systems. Departmental users can access features tailored to their roles, such as incident review, status updates, and reward distribution mechanisms. They can interact with incident reports, validate incidents, and coordinate response efforts seamlessly within the application. Moreover, the DApp enables departments to communicate with other stakeholders, receive alerts, and engage in feedback and improvement processes, fostering collaboration and enhancing the overall effectiveness of incident resolution.

3.2.2. Identity Service Provider (ISP)

The ISP plays a pivotal role in the system architecture, albeit external to it, by facilitating secure identity verification processes for users [54]. Entering personal details, which an official ISP verifies, initiates the user interaction with the system. To maintain user privacy, this sensitive information is not stored on the blockchain ledger. Instead, users engage with an official ISP (e.g., the state) through the dedicated mobile application to verify their information and link it to their digital identity within our system. This process ensures the privacy-preserving management of user information as identity details are transformed into verifiable credentials. Furthermore, official departments such as municipal offices or identity verification agencies can corroborate the user’s information and issue verifiable credentials based on the user’s provided data. These credentials are securely stored either locally on the user’s device or in their personal cloud. Additionally, users can obtain verifiable credentials related to their profession or expertise by communicating with other official entities within the system. These credentials, too, are stored securely and utilized during incident reporting or intervention processes. Trusted official entities retain the authority to disclose user identity information if necessary, but only after confirming the user’s misconduct. This dual mechanism ensures user information remains private and under their control while allowing official entities the capacity to disclose identity information or revoke verifiable credentials as needed, thus maintaining a balance between privacy and accountability.

For secure user authentication, a decentralized identity management system is essential. This approach should ensure robust authentication while also allowing users to report incidents confidentially. Currently, there is significant interest in proposing self-sovereign identities within blockchain technology to ensure user privacy and minimize proof disclosure [55,56]. For the proposed Incident Reporting System (IRS), we refer to the use of a self-sovereign identity scheme based on Schnorr Zero-Knowledge Proof (ZKP) to ensure user privacy as discussed in [57]. According to this protocol, a user can generate proof of being a citizen of a region and having the right to disseminate incidents without revealing their identity. The proof issuer, in this case, would be the state, which legally has the authority to verify citizen identities.

3.2.3. Digital Wallet

The Digital Wallet serves as a cornerstone of the user experience within the system, providing a secure and versatile platform for managing rewards and engaging with system features [58]. Each user account is seamlessly linked to a public wallet residing on the blockchain, facilitating the receipt of rewards as tokens. Users earn tokens for contributing valid incident reports or actively participating within the system. These tokens are securely stored within the user’s wallet, serving as an incentive mechanism for sustained engagement and valuable contributions.

Similarly, departments within the system manage their reward mechanisms and have their own digital wallets tailored to their specific needs and contexts. Departments establish and manage reward systems for stakeholders involved in incident reporting and validation, implementing systems that may include engagement tokens exchangeable for real money or used within the system for discounts and services. These reward mechanisms are influenced by factors such as the nature of the incident, the availability of validators, and geographical context.

Moreover, the user’s wallet boasts additional features to enhance user engagement and incentivization. These may include reputation metrics, reflecting the user’s reliability and trustworthiness based on their contributions and interactions within the system. Community ranks, gamification-related indicators, and badges are also integrated into the wallet, giving users tangible recognition for their contributions and encouraging further engagement.

This hybrid storage approach ensures the security and privacy of user data. Verifiable credentials, such as identity information and user-generated data, are securely stored in the user’s digital wallet on their device. These credentials are shared only upon explicit user consent. Public information indicating the user’s behavior within the system is stored on the blockchain, fostering transparency and accountability while safeguarding user privacy. This combination of local and public storage mechanisms contributes to a more trustworthy and secure system architecture, enhancing user confidence in their interactions with the platform.

3.2.4. Blockchain

The blockchain is the backbone of the IRS system architecture, facilitating transparent and secure record-keeping of all actions and interactions within the ecosystem. One of its primary functions is hosting the departments’ and users’ wallets and associated public data.

Additionally, the blockchain orchestrates the lifecycle of reported incidents and their progression, along with all related actions [59]. Actors within the system interact with the blockchain ledger to write, read, or update incident details, ensuring transparency and accountability throughout the incident management process. Furthermore, the blockchain manages the lifecycle of tokens within the user’s wallet, ensuring seamless token management and secure transactions. Smart contracts facilitate and secure transactions, such as when a department transfers tokens to reward a user for their engagement.

To optimize efficiency and scalability, heavy incident information such as photos or videos is not directly stored on the blockchain. Instead, a decentralized file management system is employed, with unique identifiers for each resource stored on the blockchain. This approach ensures efficient incident management while preserving the integrity and scalability of the blockchain infrastructure.

The proposed system uses Raft [60] as a consensus mechanism to orchestrate the transaction lifecycle within a collaborative and distributed environment. This is reputable for its efficiency, reliability, and simplicity. Raft’s leader election and log replication model ensure quick and consistent updates across the network, which is vital for maintaining the integrity of the system’s data as it evolves through the project lifecycle.

Furthermore, Raft’s ability to handle node failures gracefully ensures that the system’s data remain available and consistent, even in the face of network or hardware failures (up to ($(N-1)/2$) failures, where N is the total number of participants in the consensus). This supports the high availability requirements of Blockchain Incident Management (BIM) applications. The immediate finality of data transactions under Raft, without the possibility of forks, guarantees that once a change is made to the BIM model, it is accepted and propagated throughout the network, ensuring all stakeholders are working from the same version.

This coherence is essential for avoiding costly misunderstandings and rework. In essence, Raft provides a robust, efficient, and straightforward consensus framework that aligns perfectly with the needs of BIM orchestration, fostering collaboration, enhancing data integrity, and supporting the real-time decision-making processes that are pivotal in modern construction and infrastructure development projects.

3.2.5. Smart Contracts

Smart contracts constitute another cornerstone of the system, residing on the blockchain to automate and enforce transactional agreements and workflows [61]. These self-executing contracts are programmable and transparent, ensuring the trustless execution of various processes within the ecosystem. Through smart contracts, users and departments can engage in secure and transparent transactions, with predefined rules and conditions enforced autonomously.

Moreover, smart contracts govern the lifecycle of incidents within the system, from creation to resolution, automating key stages of incident management. They enable the seamless progression of incidents through predefined workflows, ensuring adherence to established protocols and guidelines. Additionally, smart contracts can integrate external data sources and oracles, enabling the system to access real-world information and trigger actions based on predefined criteria, enhancing responsiveness and effectiveness.

3.2.6. InterPlanetary File System (IPFS)

To alleviate the increasing size of the blockchain ledger and improve storage efficiency, our system leverages the IPFS [62] for managing and storing incident evidence. IPFS is a decentralized file storage and sharing network that allows for efficient, secure, and resilient data management by distributing it across multiple nodes. Unlike traditional centralized systems, IPFS addresses content by its unique hash (Content Identifier, or CID), ensuring data integrity and immutability.

Storing evidence on IPFS facilitates immediate access for emergency responses and serves as a permanent, auditable record of the incident and its associated evidence. This can be crucial for post-incident analyses, legal proceedings, and improving future emergency response strategies. Furthermore, the privacy and security of the evidence can be controlled using encryption. Files can be encrypted before being uploaded to IPFS, with decryption keys shared only with authorized parties. This ensures that the evidence remains secure and private while it is readily available for authorized users. The following steps showcase how evidence is stored in IPFS.

1.

Uploading Evidence: Detailed evidence supporting the incident (such as photos, videos, documents, or sensor data) is uploaded to IPFS. Each file uploaded to IPFS is content-addressed, which means it receives a unique hash based on its content (CID).

2.

Immutable Records: Once uploaded, the evidence cannot be altered without changing the file’s hash. This immutability ensures the integrity of the evidence, providing a tamper-proof record of the incident and the associated response.

3.

Efficient Access: The hash of the uploaded evidence is included in the PubSub notification, allowing for emergency services to access and retrieve the evidence directly from the IPFS network. IPFS’s distributed nature ensures that files can be accessed quickly without relying on a central server.

3.2.7. Blockchain Node

Within the system architecture, users and departments can maintain their blockchain nodes, which is crucial for the operation and integrity of the decentralized network.

For departments, hosting a blockchain node is integral to their responsibilities within the system. These entities oversee the operation of the blockchain network, hosting and maintaining a full blockchain node, executing the consensus protocol, and defining the governance and rules of the system in collaboration with users. This collaborative effort involves reaching a consensus on transactions, writing them to the ledger, and disseminating blockchain blocks across the network. Additionally, they are responsible for deploying necessary smart contracts to facilitate various functionalities within our system. Given their greater resources and vested interest in decentralizing the IRS, these organizations are well-equipped to handle the technical responsibilities of maintaining blockchain nodes. Discussions may be held and subsequent implementations made regarding node revocation procedures, actions to be taken in case of revocation, protocols for addressing malicious behavior by blockchain actors, procedures for admitting new nodes into the system, and methodologies for updating smart contracts, among other considerations. This governance framework ensures the orderly functioning and evolution of the system, fostering transparency, accountability, and user participation in decision-making processes.

On the other hand, while users can maintain a full blockchain node, it may not be the most cost-effective choice. Therefore, we propose that the technical responsibility of hosting blockchain nodes be primarily entrusted to departments or organizations. Users can opt to interact with the blockchain network indirectly through the DApp, which abstracts away the complexities of directly managing a node. This approach allows users to focus on contributing to the IRS without the burden of maintaining infrastructure. At the same time, departments or organizations ensure the robustness and reliability of the underlying blockchain network.

3.2.8. IPFS Storage Node

Users and departments can operate their IPFS nodes, which serve as decentralized storage solutions, facilitating storing and retrieving multimedia content associated with reported incidents.

Operating an IPFS node for departments can enhance their access and control over data management. These entities may choose to host their own IPFS nodes to ensure the availability and integrity of incident-related multimedia content. By maintaining their IPFS storage infrastructure, departments or organizations can efficiently manage large volumes of data while adhering to decentralized principles.

Similarly, users also have the option to operate their own IPFS storage nodes, providing them with greater control over the storage and sharing of multimedia content associated with their reported incidents. However, operating an IPFS node may entail technical complexities and resource requirements that not all users may be willing or able to manage.

To effectively deploy a decentralized file storage system, we propose that local authorities or trusted organizations manage the deployment of IPFS nodes, ensuring a stable and scalable infrastructure for users to connect to without needing to run their own nodes. User-friendly mobile and web applications will facilitate seamless interaction with the IPFS network, simplifying the processes of uploading, retrieving, and managing incident-related multimedia content. For advanced users and developers, secure APIs can be provided to enable integration with third-party applications, fostering an ecosystem of tools that enhance the incident reporting process.

Therefore, while both users and departments or organizations can operate IPFS storage nodes, it is important to note that this choice is optional and may not be suitable for all stakeholders. Users and departments can leverage other entities’ existing IPFS infrastructure or integrate alternative storage solutions into the system architecture. Ultimately, the decision to operate an IPFS storage node should be based on technical expertise, resource availability, and data management requirements.

3.2.9. External Tools

The system architecture allows for seamless integration with external tools, enabling enhanced functionality and capabilities for decision-making, analysis, and automation. External tools such as Decision Making, Statistical, and AI tools can be interfaced with the system to augment its capabilities and provide additional insights and functionalities.

• Decision-Making Tools: External decision-making tools can be integrated into the system’s components (i.e., IPFS and Blockchain) to facilitate informed decision-making processes [63]. These tools may include decision support systems, expert systems, or simulation tools that assist users and departments in assessing and evaluating incident data, identifying trends, and making strategic decisions to improve incident resolution outcomes.
• Statistical Tools: Statistical analysis tools can be integrated to enable comprehensive data analysis and visualization. These tools empower users and departments to perform advanced statistical analyses, generate reports, and derive insights from incident data. By leveraging statistical tools, stakeholders can identify patterns, correlations, and anomalies in incident reports, leading to more informed decision-making and proactive incident management strategies [64].
• AI Tools: Artificial intelligence (AI) tools can enhance the system’s capabilities by automating repetitive tasks, predicting incident trends, and identifying potential risks or opportunities. AI algorithms can analyze large volumes of incident data, detect patterns, and make recommendations for optimizing incident resolution processes. Additionally, AI-powered chatbots or virtual assistants can provide real-time support and assistance to users, improving the overall user experience and the system’s efficiency.

By interfacing with external tools, the proposed system harnesses the power of advanced technologies to streamline incident reporting and management processes, enhance data analysis and decision-making capabilities, and ultimately improve the effectiveness and efficiency of the incident resolution ecosystem.

4. Protocol

This section outlines the interactions among various components for secure and efficient incident reporting and management. Figure 3 illustrates the interactions among components using a fire incident use case. As depicted, when a resident (i.e., user) identifies a fire incident, they collect evidence using their mobile phone and submit it to the blockchain to initiate an incident report. The incident report evolves over time on the blockchain as additional evidence is gathered by other users, who update the report’s status on-chain. The details of the incident evidence are stored on IPFS and linked to the blockchain ledger. Local authorities, connected to the blockchain in real time, analyze both the blockchain and IPFS data to facilitate decision-making. Figure 4 further depicts the system’s workflow using a sequence diagram. The main steps of the proposed IRS are divided as follows:

4.1. Report Incident

Initially, users can seamlessly report an incident through a user-friendly application interface, equivalent to contacting the relevant emergency departments in the current system. Upon activation, the incident is formalized as a blockchain transaction, encapsulating the essential details required for incident reporting and management:

$$tx=(t,l,pk,d,m),$$

where t is the timestamp, l is the location, $pk$ is the public key of the user, d is the description of the incident, and m includes any attached media that offers additional proof or context for the incident.

This structure captures the fundamental details necessary for effective incident management.

4.2. Record Incident

When an incident report is verified and validated, the relevant departments are notified simultaneously when initiating IPFS storage. This parallel process helps save valuable seconds by alerting the departments about the incident, even if there is a delay in storing the transaction on the blockchain. Consequently, this ensures real-time notification of the incident to the relevant departments, even though it may take a few extra seconds for them to access the proof. This approach enhances the efficiency and effectiveness of emergency response efforts by ensuring timely alerts and prompt action. It is assumed that the emergency departments have dedicated infrastructure to monitor any updates on the blockchain, allowing them to instantly update the status of the incidents for which they are responsible.

The Record Incident Smart Contract (RISC) in Algorithm 1 illustrates the incident record logic. RISC incorporates transaction validation. If the reported incident includes media files, they are stored off-chain using IPFS. The IPFS storage is an asynchronous process. Once the media files are successfully stored on IPFS, the CID (Content Identifier) is included in the transaction metadata and recorded in the Blockchain for Incident Management (BIM). This ensures the link between the off-chain data and the on-chain transaction is secure and verifiable.

This approach preserves the integrity of the evidence by leveraging the strengths of both the blockchain and IPFS. When an incident is reported, any associated media files (such as photos or videos) are first uploaded to IPFS. IPFS, being a decentralized storage system, generates a unique Content Identifier (CID) for each file. This CID is then included in the incident report logged on the blockchain.

Recording the CID on the blockchain establishes a permanent and immutable link between the on-chain incident record and the off-chain media evidence stored on IPFS. This means the evidence uploaded to IPFS can be directly and securely linked to the immutable blockchain record. Including the CID in the blockchain ensures that any attempt to alter the media files on IPFS will result in a different CID, thereby breaking the link to the original incident record. This cryptographic linkage guarantees that the evidence cannot be tampered with without detection, thus maintaining the integrity and trustworthiness of the incident report.

Furthermore, storing large files directly on the blockchain is impractical and costly due to size limitations and high transaction fees. By using the blockchain to record incident details and IPFS to store the actual files, we optimize both storage efficiency and cost. The incident is recorded on the blockchain, including the hashes (CIDs) of the evidence stored on IPFS. This setup streamlines the retrieval process: stakeholders can quickly access the blockchain record, obtain the IPFS hashes, and retrieve the evidence from IPFS. This separation of responsibilities ensures the blockchain maintains a secure and immutable record, while IPFS provides efficient and scalable storage for large files.

Incidents must be recorded on the blockchain as soon as they are created. Given that an incident may be time-critical, the proposed system must ensure their real-time propagation to concerned services for immediate action, without extensive verification at this stage. Instead, the proposed protocol will rely on a post-validation model to penalize intentional false advertising or malicious behavior.

Algorithm 1: Record Incident Smart Contract (RISC)
1:	Data Structure Incident (tx)
2:	t: timestamp
3:	l: location
4:	$pk$: issuer
5:	d: description
6:	m: $c_{id}$	▹ IPFS Content Identifier
7:	h: $hash$(tx) || $c_{id}$
8:
9:	procedure RecordIncident($l,d,c_{id}$)
10:	validate($pk$)	▹ Ensure issuer is authenticated
11:	store($l,d,c_{id}$)	▹ Store incident details
12:	end procedure
13:
14:	functionvalidate(issuer)
15:	if issuer is not registered or authenticated then
16:	return False
17:	else
18:	return True
19:	end if
20:	end function
21:
22:	function store($l,d,c_{id}$)
23:	Create new tx with provided details
24:	Include h in tx metadata for off-chain evidence
25:	Save tx to blockchain
26:	end function

Due to the need for real-time updates in managing advertising incidents and the legal implications of accessing such incidents, it is crucial to address the legal status of various organizations involved in incident management. Consequently, RAFT was chosen as a consensus mechanism for orchestrating BIM. Both governmental and non-governmental entities will maintain the blockchain. The latter can be entities that enforce transparency in incident reporting, representing the interests of users against errors or defiance by governmental organizations. This aspect highlights a compelling argument for using blockchain technology to enhance transparency, fairness, and automation in incident reporting. This added layer of transparency holds emergency centers accountable for any subpar service. Furthermore, the proposed architecture will encourage different emergency centers to strive for excellence in client service.

By initially recording the event on the blockchain, you create an immutable timestamped record of the incident. This step ensures that the event’s occurrence is securely logged in a tamper-proof and verifiable way.

4.3. Take Actions

Once their format is validated, the relevant emergency center is notified about its respective incidents. This enables the handling of time-critical situations promptly. At this stage, the emergency center must act upon the reported incident. For example, in the case of a fire report, the fire department should proceed to the specified location to assess the situation. Subsequently, it must report the integrity of the event to the blockchain. Whether the incident is relevant or not, the emergency service will issue a transaction to the blockchain to confirm that an action has been taken, including available media evidence. The action taken is formalized as follows:

$$ti=(h_{\mathrm{tx}},pk,t,s,f,m),$$

$ti$ includes a reference to the original event ($h_{\mathrm{tx}}$), the intervention agent identity ($pk$), the intervention timestamp (t), the incident state after verification (s), which can be true or false, the monetary penalty if applicable (f), and finally, media files (m) may be included to support the claim for greater transparency. As detailed previously, the media evidence is stored on IPFS for auditability in case of inspection.

At the beginning of the intervention, such as the arrival of the first car or agent, a transaction ($ti$) is issued as proof that the emergency department has taken action. Additional ($ti$) are recorded on the BIM throughout the incident lifecycle to update its status, as shown in Figure 4.

4.4. Close the Incident

After the respective emergency department has taken action and it is assumed that no further updates regarding a particular incident are needed, a $ti$ type transaction will be issued to close the incident. This transaction includes a complete report about the incident, which will be attached. The transaction will also include any penalties or rewards.

Indeed, to encourage user participation in the proposed IRS, an incentive system is implemented. This system rewards positive behavior and penalizes malicious actions. The reputation model is embedded within the Reputation Manager Smart Contract (RMSC), as shown in Algorithm 2.

RMSC retrieves each transaction along with the reporting user’s current reputation, adjusting this reputation based on the relevance of the reported incident. It calculates a bonus using an exponential decay formula for relevant reports, incentivizing prompt submissions. The algorithm imposes fines for irrelevant or false reports, deducting a penalty from the user’s reputation.

The updated reputation is then recorded within BIM. By incorporating a bonus system that exponentially decreases reporting delays and enforcing penalties for false reports, the incentive model maintains system integrity and motivates users to report responsibly.

Algorithm 2: Reputation Manager Smart Contract (RMSC)
1:	Inputs:
2:	$ti=(h_{\mathrm{tx}},id,t,s,f,m)$
3:	MAX_B: Maximum possible bonus
4:	$\alpha$: Decay rate for the bonus
5:	p: Fixed penalty on the user reputation
6:
7:	Output: updated user reputation
8:
9:	procedure UpdateReputationAndFine($ti$)
10:	$tx\leftarrow \mathrm{getTx}(h_{tx})$
11:	$r\leftarrow \mathrm{getCurrentReputation}(tx.pk)$
12:	if v is true then	▹ Incident is relevant
13:	$r\leftarrow$CalculateBonus($tx.t,ti.t$)
14:	else
15:	$r\leftarrow r-p$
16:	imposeFineOnUser($tx.px,ti.f$)
17:	end if
18:	updateReputationOnBIM($tx,r$)
19:	end procedure
20:
21:	function CalculateBonus($t_b,t_e$)
22:	$\Delta t\leftarrow t_e-t_b$	▹ Time difference in seconds
23:	$bonus\leftarrow \mathrm{MAX\_B}·e^{-\alpha ·\Delta t}$
24:	return $bonus$
25:	end function

Such a model encourages a more vigilant and responsive community, where citizens are more likely to contribute valuable information for the collective benefit. This collaborative effort between the system and its users improves incident management efficiency. It fosters a culture of responsibility and accountability among citizens. By integrating this incentive mechanism, the RMSC effectively leverages the collective power of the community to enhance security and safety, making it a pivotal tool in the broader context of public emergency management and response systems.

5. Experimental Analysis

This section focuses on evaluating the feasibility of the proposed Incident Reporting System (IRS). It starts with the definition of the assessment metrics before diving into the simulation and presentation of the results.

5.1. Assessed Metrics

Below, we outline the assessed metrics to demonstrate the efficiency of the proposed IRS. These metrics encompass various aspects of system functionality and efficiency, including incident report/notify delay, the end-to-end delay from incident creation to treatment (i.e., concerned emergency services have taken action to confirm the incident veracity), blockchain size, cost-effectiveness, and scalability.

A

Incident Notification Delay: An incident undergoes various processes throughout its lifecycle, with one pivotal stage being the notification of the relevant emergency. This delay is denoted as $t_{\mathrm{notify}}$, where

$$t_{\mathrm{notify}}=t_{\mathrm{pub}}+t_{\mathrm{ipfs}}+t_B$$

(1)

where:

• $t_{\mathrm{pub}}$ represents the delay between a user clicking “submit incident” and the incident being received on the blockchain network.
• $t_{\mathrm{ipfs}}$ is the delay in writing and reading the incident-supported proofs to the IPFS.
• $t_B$ is the time required to record the incident on the blockchain; this time includes the transaction format validation.

B

Response Time: This refers to the duration between initiating an incident and arriving at the first responding unit, such as a police car. This timeframe includes the notification and the time the concerned dedicated services take to take action. Therefore, the comprehensive response time for an incident can be quantified as follows:

$$t_{\mathrm{response}}=t_{\mathrm{notify}}+t_{\mathrm{action}}+t_B$$

(2)

Here, $t_{\mathrm{action}}$ is the delay incurred by emergency services in responding to and acting upon the incident. This measure is crucial for evaluating the efficiency and effectiveness of the emergency response protocol. Here, $t_B$ is the time delay for storing a $ti$ transaction on the blockchain.

C

The throughput: The throughput measures the number of incidents a system can process within a given time frame. It is expressed in incident per second (incident/s). The throughput is defined as

$$Th={\displaystyle \frac{N_{tx}}{t_B}}$$

(3)

where $N_{tx}$ is the number of pending incidents and $t_B$ is the delay in writing to the Blockchain (BIM).

D

Blockchain Size: In the proposed IRS, each reported incident initiates a sequence of blockchain storage operations to update the incident state. The first storage operation involves recording the incident’s initial report on the blockchain before notifying the relevant emergency services. Subsequently, additional transactions $ti$ are logged to record the response time and actions taken by the emergency services and the closing report. During the period between the initial response and the closing report, multiple updates may be necessary to accurately reflect the state of the incident. Let $\omega$ denote the average number of updates required to maintain this accuracy. Consequently, the total size of the blockchain ($S_B$) can be expressed by the equation

$$S_B=S_{tx}+(S_{ti}\times \omega ),$$

(4)

where $S_{tx}$ represents the size of the transaction that logs the incident, and $S_{ti}$ denotes the size of the transaction recording the action taken. $\omega \ge 1$ is the average number of updates needed to adjust the incident state.

E

Scalability: The proposed system capability to accommodate an increasing volume of incident reports and a high arrival rate, as well as the growing number of involved organizations, is crucial. Scalability ensures that the system remains efficient and responsive as demand grows over time, allowing it to adapt to evolving requirements and maintain optimal functionality even under high usage and activity levels. Therefore, the evaluation considers different blockchain network participants (8 and 16 validators, i.e., the blockchain maintainers) and increasing incident arrival rates from 1 to 400 incidents per second.

F

Deployment Cost: A dedicated consortium maintains BIM, so transaction fees are not directly applicable. The primary operational costs arise from maintaining and writing to the blockchain. Each organization must invest in a server capable of running a Quorum–Raft node. As the consensus is established through message exchanges, it does not require heavy computation or particular software, as in the case of Proof of Work (PoW). Additionally, costs may be associated with promoting the adoption of the proposed IRS scheme. For simplicity, we estimate only the costs of implementing the proposed framework. Therefore, we express the global cost as follows:

$$C_{\mathrm{total}}=C_{\mathrm{server}}\times N$$

(5)

where

• $C_{\mathrm{server}}$ represents the cost of acquiring and maintaining a server capable of running a Quorum–Raft node.
• N is the number of nodes in the network.

5.2. Results

The objective of this section is to demonstrate the feasibility of the proposed protocol rather than to present a complete implementation. Therefore, some findings from existing studies have been relied upon instead of conducting the implementation independently while showcasing the unique features of the proposed solution.

Table 2. Summary of variables setting.

Variable	Description	Value Setting
N	Number of validators responsible for maintaining the blockchain network, executing the consensus, and managing smart contracts. Validators host full blockchain nodes and ensure the security and transparency of transactions by verifying and recording them on the blockchain ledger.	8, 16
$t_{\mathrm{ipfs}}$	Delay taken to write and read the incident supported media proofs on IPFS	6.573 s for 64 MB [66]
$t_{\mathrm{pub}}$	The delay between a user clicking “submit incident” and the incident being received by the blockchain network	5.12 s for 64 MB and 100 Mbps bandwidth
$t_B$	Time required to record the incident on the blockchain.	Quorum–Raft performance evaluation [68]
$t_{\mathrm{Action}}$	Delay incurred by emergency services in responding to the incident.	16 min 49 s (average total intervention time in France for Firefighters) [67]
$S_{tx}$	Incident transaction size.	1071 Bytes
$S_{ti}$	Action feedback/update state transaction size.	264 Bytes

summarizes various crucial variables within the system. Specific values are derived directly from their definitions, such as transaction size

Table 3. Sizes of variables.

Variable	Representation	Size (bytes)
h	SHA-256 hash	32
t	Unix timestamp (int)	4
l	Coordinates (float)	16
$pk$	ECC public key	64
d	String	800 (upper bound)
m	IPFS CID	59
f	Amount	8
s	Boolean (true/false)	1
$\sigma$	ECDSA Signature	64
Size of $tx:(t,l,pk,d,m)$		$32+4+16+64+800+59+32+64=1071\mathrm{bytes}$
Size of $ti:(h_{\mathrm{tx}},pk,t,s,f,m),$		$32+64+4+1+8+59+32+64=264\mathrm{bytes}$

Note: An additional 32+64 bytes for the transaction hash (h) and its signature ($sigma$) is included in each transaction’s total size calculation, as each transaction must contain its hash and signature ($\sigma$).

. In contrast, others are sourced from established benchmark studies, such as Quorum performance [65] and IPFS performance [66]. Furthermore, real-world data are utilized to ascertain the average time required for intervention. Specifically, statistics from the 2023 France Firefighters report delay and intervention delay serve as our reference [67].

Assuming a bandwidth of 100 Mbps, the transmission time for 1 MB of incident data is approximately 0.08 s. This brief communication delay is minimal due to the high-speed capabilities of modern internet infrastructure. Thus, for an average incident size (including media files) of 64 MB, $t_{\mathrm{pub}}=0.08\times 64=5.12$ s.

5.2.1. Incident Notification Delay

The IRS significantly enhances the traditional emergency response process by reducing latency and increasing efficiency. The current system in France, with an average response time of 2 min 28 s for $6.3$ incidents per second [67], involves multiple steps prone to delays and errors. In contrast, the proposed scheme maintains a latency of under 15 s, as shown in Figure 5, even at high transaction rates, enabling near-instantaneous processing of notifications. Using a smartphone application, citizens can report incidents directly, automatically providing crucial information such as location, incident type, and user credentials. This streamlines the response process, minimizes human error, and eliminates potential biases during verbal communication with emergency operators.

For example, in a car accident, a user can quickly send a notification with photos and precise GPS coordinates, ensuring that responders have accurate information immediately. This can save valuable time compared to describing the location and incident details over a phone call. Additionally, recording incidents transparently on the blockchain ensures full accountability and reduces the risk of discrimination.

Furthermore, the system supports governmental procedures by providing a reliable and tamper-proof record of all incidents. This transparency helps audit and analyze emergency responses, leading to better resource allocation and policy-making. While the integration of machine learning for automated incident assessment is a future perspective, the current advantages of the blockchain-based system in terms of speed, accuracy, and transparency make it a compelling alternative to the traditional emergency response approach.

5.2.2. Response Time

Figure 6 illustrates the required delay in response time, which is the time from incident issuance to the intervention of the concerned emergency services. The results show that the proposed IRS can reduce this delay compared to existing systems by more than 1 min (77 s). This improvement is primarily due to the reduction in the incident notification delay.

The results also indicate that as the number of organizations maintaining the blockchain increases, the delay also increases. This is because of the increase in $t_B$, the time required to write on the blockchain.

Response time is an important metric for the IRS as it showcases the efficiency of the emergency services. Storing this information transparently on the blockchain helps to avoid complaints and makes the system more accountable.

5.2.3. Throughput

Figure 7 shows the number of incidents the BIM can validate and write on the blockchain against the incident arrival rate. The results indicate that at an incident arrival frequency of 200 incidents per second, approximately 50% of the transactions are instantly written on the blockchain, which is considered high.

To put this result in context, in France, on average, 6.3 incidents were reported every second to the firefighters in 2023 [67]. Such a load can be handled without any bottleneck by the proposed IRS.

However, to anticipate the wider adoption of the proposed solution, considering different types of incidents beyond those concerning firefighters, we assess incident frequencies ranging from 100 to 400 incidents per second. This assessment ensures the IRS’s scalability and efficiency in various real-world scenarios.

The results also demonstrate that the number of organizations involved impacts the throughput, adding further latency to the consensus process.

5.2.4. Blockchain Size

The proposed IRS enables comprehensive tracking of an incident lifecycle. This includes multiple updates to the status of incidents before they are finally closed. To objectively assess the size of the blockchain, Figure 8 plots the blockchain size with varying numbers of updates $\omega =[1,2,3,4]$.

The results show that despite numerous updates to the blockchain ($\omega =4$) to reflect the status of incidents, the blockchain size remains less than 200 GB with ${10}^8$ incidents reported. This demonstrates the efficiency of the proposed IRS in maintaining a manageable blockchain size even with frequent status updates, owing to the off-chain storage using IPFS for media files supporting incidents.

To further elaborate, each incident can go through several stages, requiring updates to its status on the blockchain. These stages might include incident report, validation, response initiation, ongoing response updates, and incident closure. Even with multiple updates per incident, the proposed IRS ensures that the blockchain remains scalable and efficient in terms of storage.

Such a design is crucial for practical implementation, as it ensures that the blockchain does not become excessively large and unwieldy, which could compromise performance and accessibility. The ability to maintain a blockchain size under 200 GB with a large number of incidents highlights the robustness and scalability of the proposed IRS.

5.2.5. Deployment Cost

To accurately assess the costs associated with managing the proposed IRS system, we utilize the cost model of Hyperledger Fabric blockchain nodes on Amazon Managed Blockchain (Amazon Web Services, Amazon Managed Blockchain Pricing, [Online]. Available online: https://aws.amazon.com/managed-blockchain/pricing/ (accessed on 18 May 2024)). This choice is justified by the fact that Hyperledger Fabric, when running under the Raft consensus algorithm, has similar costs to a Quorum–Raft configuration.

Table 4. Cost components for Hyperledger Fabric on Amazon Managed Blockchain.

Cost Component	Description	Value (USD)/Month
Peer Node Monthly Cost ($C_{\mathrm{peer}}$)	Monthly cost per peer node	2014.07
Ordering Service Monthly Cost ($C_{\mathrm{ordering}}$)	Monthly cost for ordering service instance	487.91
Storage Cost ($C_{\mathrm{storage}}$)	Cost per GB of storage per month	0.10/GB

breaks down the cost for Hyperledger Fabric on Amazon Managed Blockchain, and an estimation of $C_{\mathrm{server}}$, the cost of maintaining a Quorum–Raft node.

The total monthly cost $C_{\mathrm{total}}$ for managing N peer nodes, utilizing $S_B$ GB of storage, is given by:

$$C_{\mathrm{server}}=C_{\mathrm{peer}}\times N+C_{\mathrm{ordering}}+0.10\times S_B$$

$$C_{\mathrm{server}}=2014.07\times N+487.91+0.10\times S_B$$

Thus, from the Equation (5), we have:

$$C_{\mathrm{total}}=(2014.07\times N+487.91+0.10\times S_B)\times N$$

Fixing the blockchain size $S_B$ to 200 GB, Figure 9 plots the cost of maintaining 8 and 16 BIM nodes for varying numbers of years. The results show that over 5 years, it would cost less than 1.99 million USD to deploy the system with 16 organizations and 1 million USD for 8 organizations. This estimation provides a comprehensive evaluation of the cost of deploying the IRS.

While a significant budget would be needed to deploy the proposed IRS, the benefits include increased transparency, reduced errors, and enhanced collection of statistics, leading to better Quality of Service (QoS). Additionally, the potential integration of sophisticated AI for incident media analysis could further justify the deployment costs by significantly improving performance and efficiency.

6. Discussion

Comparing the proposed IRS with existing systems reveals several innovative enhancements that address key limitations in existing solutions.

Table 5. Comparison between traditional systems and the proposed Incident Report System.

Feature	Traditional Systems	Proposed IRS
Transparency	Limited, controlled by central authority	High, due to immutable blockchain records
Accountability	Low, difficult to track and audit	High, all actions are recorded and traceable
User Anonymity	Generally low, users often disclose identity	High, allows anonymous reporting
Data Integrity	Vulnerable to tampering and loss	Strong, secured by blockchain and IPFS
Incentive Model	Typically none	Blockchain-based tokens to reward participation
Scalability	Established infrastructure, scales with investment	Potentially high, but requires robust infrastructure
Cost	Lower initial setup costs	Higher initial setup costs, potential long-term savings
User Engagement	Moderate, dependent on trust in the system	High, incentivized participation

illustrates the benefits and limitations of the proposed approach compared to traditional and existing systems. The proposed decentralized IRS presents significant advancements over traditional centralized systems. By leveraging blockchain technology and IPFS, the system ensures that all incident reports are transparent, immutable, and efficiently stored. This not only enhances the reliability of the data but also fosters a higher level of trust among users and stakeholders. The incorporation of a blockchain-based incentive model further motivates users to participate actively, thereby improving the overall effectiveness and responsiveness of incident management.

Additionally, unlike existing IRSs that often focus on isolated aspects like report submission or incident processing, the proposed IRS integrates all four critical steps: Report Submission, Validation and Verification, Incident Processing, and Evaluation and Learning. This comprehensive approach ensures accurate and thorough incident reporting while enhancing continuous improvement and accountability through effective learning and feedback mechanisms.

Furthermore, the IRS we propose also emphasizes user-centric features such as enhanced usability, incentivization, and feedback mechanisms, which are crucial for encouraging active engagement and participation. By integrating these elements, our proposed system offers a robust and scalable solution that overcomes the challenges of existing IRSs, thereby contributing valuable advancements to the field of incident management and smart city governance.

7. Conclusions and Future Works

7.1. Conclusions

Integrating blockchain into urban incident reporting systems addresses critical requirements for effective incident management. These requirements include usability, efficiency, transparency, anonymity, incentivization, feedback mechanisms, data security, scalability, and cost-effectiveness. The proposed decentralized reporting system offers significant improvements over traditional centralized frameworks, meeting these requirements in several key ways.

Usability: The user-friendly mobile application enables citizens to easily report incidents, track their status, and receive updates. The system’s intuitive interface ensures that users can participate in the reporting process without facing technical barriers, thereby enhancing civic engagement.

Efficiency: By utilizing blockchain technology in conjunction with the IPFS, the system ensures rapid incident reporting and data retrieval. The empirical validation based on the Raft consensus protocol demonstrates the system’s capability to handle high throughput and low latency, crucial for timely incident management.

Transparency and Accountability: The immutable nature of blockchain ensures that all incident reports and subsequent actions are permanently recorded and verifiable. This transparency fosters users’ trust and allows citizens and government bodies to audit the incident management process comprehensively.

Anonymity: The system supports a level of anonymity by allowing users to report incidents without directly revealing their identities on the blockchain. However, verifiable credentials and identity verification through official entities ensure that user information can be corroborated if necessary. This balance addresses concerns about privacy while maintaining the integrity and trustworthiness of the system.

Incentivization: An integrated incentive model, facilitated by blockchain-based tokens, rewards users for accurate and timely incident reporting. This mechanism not only motivates active participation but also ensures the long-term sustainability of the system.

Feedback Mechanisms: The platform includes robust feedback loops where users can provide input on the resolution process. This continuous feedback helps improve the system and ensures that users feel their contributions are valued and impactful.

Data Security and Confidentiality: Blockchain’s cryptographic foundations and the use of decentralized storage via IPFS ensure that incident data is secure, unalterable, and accessible only to authorized parties. This level of security is critical for maintaining the integrity and privacy of the reported incidents.

Scalability: The decentralized architecture and the use of IPFS for storing large files ensure that the system can scale to accommodate increasing volumes of incident reports and expanding networks of users and organizations. This scalability is essential for urban areas with growing populations and incident reporting needs.

Cost-Effectiveness: The cost of the proposed system has been analyzed based on available data from online servers, indicating an expense of 1 million USD over 5 years for a blockchain comprising 8 organizations. This cost is distributed among the participants, effectively decentralizing the financial burden.

Additionally, the proposed system comprehensively covers the four steps of the Incident Reporting System lifecycle:

Report Submission: Users can submit detailed incident reports through the mobile application, including descriptions and multimedia evidence.

Validation and Verification: The system validates the authenticity of reports using blockchain’s immutable ledger and cross-verification with existing incidents.

Incident Processing: Once validated, incidents are processed and managed by relevant departments, ensuring timely and effective responses.

Evaluation and Learning: The system tracks and documents all interventions, allowing for continuous evaluation and improvement of incident management practices.

The proposed decentralized incident reporting system is designed to complement and enhance existing emergency response frameworks rather than replace them. One of the significant added values is the system’s capability to empower citizens to report incidents seamlessly using their smartphones. This feature streamlines the reporting process, allowing users to easily document incidents such as accidents on an autoroute without the burden of calling emergency services and explaining the situation. The system holds users accountable for their reports through a verification process, ensuring that only accurate and legitimate incidents are recorded. This accountability not only deters false reporting but also enhances the reliability of the data received by emergency responders. Furthermore, the system incentivizes user engagement by offering rewards for accurate and timely reports, encouraging active participation in maintaining public safety. By enabling direct user participation, verification, and incentives, the proposed system reduces response times, improves the efficiency of incident management, and fosters a proactive community culture, all while building public trust through a transparent and accountable reporting process.

In conclusion, the proposed blockchain-based incident reporting system effectively meets the highlighted requirements, providing a robust, transparent, and user-friendly platform for urban emergency management. By addressing the critical needs of usability, performance, transparency, anonymity, incentivization, feedback mechanisms, data security, scalability, and cost-effectiveness, and by covering all four steps of the IRS lifecycle, the system represents a significant advancement in mobilizing urban communities for proactive incident reporting and management.

7.2. Future Works

This work proposes a decentralized framework for effective incident reporting and management in urban areas. Despite the detailed description, the following tasks are planned for future work:

The proposed framework includes a reputation model to track the reputation of actors based on their actions within the system. However, experimenting with this model has not yet been done. We aim to study how this model can punish bad actions and encourage good behavior within the system.

We also plan to investigate the IRS privacy issues thoroughly. For instance, sharing the location of an incident might inadvertently reveal the reporter’s identity. To address this, we intend to integrate advanced cryptographic tools, enabling the sharing of sensitive information without compromising participant privacy. Another aspect of enhancing privacy is enabling data sharing between specific departments rather than placing all data on the blockchain, which is accessible to everyone. This can be achieved using the private channel features of the Quorum blockchain. Studying the feasibility and impact of this approach on system performance will be a valuable area of future research.

Another point involves automating more processes using AI techniques. For example, we aim to study how blockchain data can be used alongside AI tools to help departments predict the sensitivity of an incident based on a wide range of data and evidence.

Finally, implementing multiple reporting blockchains in neighboring cities is another consideration. Enabling these blockchains to interoperate and work together while respecting their own architecture and consensus mechanisms presents a significant challenge related to interoperability.