LogStamping: A blockchain-based log auditing approach for large-scale systems

LogStamping: A blockchain-based log auditing approach for large-scale systems | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article LogStamping: A blockchain-based log auditing approach for large-scale systems Md Shariful Islam, Mohammad Saifur Rahman, M. Sohel Rahman This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-8076476/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 6 You are reading this latest preprint version Abstract Log management is crucial for ensuring the security, integrity, and compliance of modern information systems. Traditional log management solutions face challenges in achieving tamper-proofing, scalability, and real-time processing in distributed environments. This paper presents a blockchain-based log management framework that addresses these limitations by leveraging blockchain’s decentralized, immutable, and transparent features. The framework integrates a hybrid on-chain and off-chain storage model, combining blockchain’s integrity guarantees with the scalability of distributed storage solutions like IPFS. Smart contracts automate log validation and access control, while cryptographic techniques ensure privacy and confidentiality. With a focus on real-time log processing, the framework is designed to handle the high-volume log generation typical in large-scale systems, such as data centers and network infrastructure. Performance evaluations demonstrate the framework’s scalability, low latency, and ability to manage millions of log entries while maintaining strong security guarantees. Additionally, the paper discusses challenges like blockchain storage overhead and energy consumption, offering insights for enhancing future systems. Blockchain Log Management Scalability Privacy Real-Time Systems Distributed Environments Tamper-Proof Large-Scale Systems Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 1. Introduction Log management is crucial for IT operations, providing critical insights for monitoring, troubleshooting, and ensuring compliance. Various IT infrastructure components, including but not limited to servers, firewalls, routers, switches, and individual PCs, typically create log recordings (popularly referred to as ‘logging’), particularly when they carry out crucial operations and transactions. Such logs are crucial for determining the trail of illicit actions carried out in such contexts [32, 33, 34]. Thus, these log files are often utilized to audit the computing environment, and they present us with crucial evidence for locating and resolving various incorrect or malicious behaviours that are interfering with the system under consideration and the infrastructure thereof. Even though log data can be useful in many ways, it can also be manipulated [37] to conceal harmful activities or impede the discovery of system vulnerabilities. Therefore, creating a secure and immutable system to store the vast amount of log data is essential to guarantee the integrity and safety of the computing environment. Blockchain [35] is a shared, distributed, immutable ledger that facilitates the process of recording transactions and tracking assets, where an asset may refer to anything of value, both tangible and intangible. For its immutable and other desirable properties, blockchain has been utilized [38, 39, 40] in this context to create tamper-proof log record storage. Unfortunately, the continuously expanding huge log data cannot be handled efficiently by the current blockchain-based solutions [17, 19], which results in massive storage overhead [42, 43, 44, 45, 46] on the participating blockchain nodes, which in turn affects performance severely, sometimes compromising the original goal of integrity as well. While some works use separate off-chain storage to solve the storage scalability problem [15, 17], these works are unable to ensure the confidentiality of log data, thereby compromising a crucial issue [15, 23]. The adoption of blockchain for log auditing in large-scale systems is hindered by limitations in scalability, performance, and compliance. Traditional blockchain architectures suffer from low throughput and high storage overhead—storing S GB of logs across N nodes results in GB of total storage, making it impractical for terabyte-scale, high-frequency environments. Additionally, consensus mechanisms introduce latency, impacting the feasibility of real-time log recording. Current solutions inadequately handle the dynamic and incremental nature of log generation. Many assume that log files are secured at the source when generated, but it fails to address scenarios where logs are continuously appended, altered during transmission, or modified before ingestion. This oversight creates vulnerabilities in log integrity and auditability. Furthermore, waiting time during log generation—a critical factor in real systems—is often ignored, leading to unaddressed latency and potential data gaps. Some methods restructure logs for query efficiency at the cost of provenance, original format, and timestamp accuracy, which undermines forensic and compliance objectives. Energy-intensive mechanisms, such as PoW exacerbate inefficiency, and the immutability of blockchain leads to data redundancy and storage overhead, worsening scalability issues. With this backdrop, this paper proposes a blockchain-based framework for log management that ensures tamper-proof logging, supports real-time processing, and maintains scalability in large-scale distributed environments. By leveraging smart contracts, cryptographic techniques, and a layered architectural design, the framework also prioritizes privacy and efficient recovery mechanisms. 2. Related Works The advancement of log management systems, coupled with their integration into blockchain technology, has marked significant milestones and yielded valuable research contributions. Various blockchain-based approaches have been developed to address similar challenges, with some solutions excelling in storing limited-size critical data [18, 21]. Other blockchain-based systems primarily focus on the storage and querying of logs directly from the blockchain [15, 41]. While each approach is well-suited to its specific use case, none effectively addresses the demands of large-scale systems with massive volumes of log data. Tamper-resistant log files are essential in various domains and are mandated by numerous regulatory frameworks and standards, including HIPAA [47], and GDPR [48]. The integrity issue of these files is critical with varying degrees from one domain to another. For example, medical records must be reliable due to their potential life-or-death implications, financial data requires accuracy to maintain trust, and IT security logs are indispensable for detecting security incidents and conducting forensic investigations. A shared characteristic of these use cases is that log files are typically append-only, with new entries continuously added over time as individuals undergo more medical procedures, perform additional financial transactions, or generate further security events. Beyond ensuring integrity, these logs must also ensure high availability to allow users to review and access records as and when needed. They serve crucial roles in fault analysis [1], anomaly detection [2, 3], forensic investigations [36], audits, and other critical processes [4, 10, 11, 12]. During a security breach, attackers often attempt to erase event logs on compromised systems to conceal their activities, underscoring the importance of secure and immutable log storage to preserve critical information and enhance system resilience. Olaf and Esmiralda [4] proposed a centralized log server that can collect and store log records securely. However, this approach is vulnerable due to a single point of failure and lacks efficient query mechanisms. Indrajit et al. [5] introduced a cloud-based log storage system, but issues of trust and data consistency remained, as cloud servers are susceptible to unauthorized access and manipulation. A blockchain-based solution for immutable log storage was proposed in [6] that incorporated hierarchical ledgers to address scalability issues. While promising, the system, LogChain, lacks implementation details, and its API is underdeveloped for production-level deployments. Kumar et al. proposed a high-level design for secure log storage leveraging blockchain and cloud infrastructure [7]. However, the solution lacks details regarding its operational framework, performance evaluation, and query mechanisms. Blockchain has also been explored in the domain of cloud forensics. Liang et al. [8] introduced ProvChain, a blockchain-based architecture for validating cloud data provenance, while Park et al. [9] proposed a data logging and integrity verification system for cloud environments. Both systems focused on cloud data integrity but failed to ensure log data integrity. Moreover, they did not provide a real-time performance analysis. Schneier and Kelsey pioneered cryptographic support for secure logs, emphasizing tamper detection in untrusted machines, laying the groundwork for tamper-proof logging [10]. However, this work lacked scalability, which is essential for large-scale distributed systems. Holt introduced Logcrypt, which enhanced log integrity through forward security and public verification, addressing critical gaps in audit log systems [11]. The major limitation was its dependency on centralized systems, which made it prone to single points of failure. Ahmad et al. presented BlockAudit, leveraging blockchain’s immutability for secure and transparent audit logs, showcasing improved security and fault tolerance [12]. A drawback of this approach was its reliance on high storage overhead on-chain, which limited its scalability. Notably, IBM highlighted blockchain’s storage challenges, advocating for efficient on-chain and off-chain strategies to handle growing data volumes [13]. Rakib et al. proposed [14] a MultiChain-based system for storing, querying, and auditing network logs. Their work achieves immutability, confidentiality, and scalability but focuses primarily on timestamp-based queries and does not emphasize real-time applicability to large-scale environments. Ali et al. introduced BCALS [15], a blockchain-based secure log management system tailored for cloud computing, ensuring audit log immutability and trust enhancement. The system’s scalability was limited in handling diverse and high-frequency log sources. Furthermore, it transforms the logs before storing them into the blockchain, which creates a crucial concern with regards to the originality of the log. Shekhtman and Waisbard developed EngraveChain [16, 17], which leverages Hyperledger Fabric [27] to provide tamper-proof log storage with encryption for data privacy. However, it lacks efficient query mechanisms and comprehensive performance evaluations, particularly in large-scale systems. Rakib et al. further refined blockchain-enabled scalable network log systems, leveraging IPFS [49] for efficient data management and a robust query mechanism [19]. While it improves scalability as off-chain storage helps reduce on-chain data, the blockchain still maintains transaction metadata, which can lead to scalability concerns as the number of log transactions grows over time. Collectively, these works underscore the potential of blockchain technology to address critical challenges in log management systems, including tamper-proofing, scalability, and privacy. However, challenges related to log confidentiality, real-time processing, and handling large log files remain as research gaps motivating further research and development. 3. Background 3.1 Blockchain A blockchain is a decentralized and distributed ledger technology that securely records transactions across a network of computers. Transactions are grouped into blocks, each cryptographically linked to its predecessor, forming an immutable chain. This structure ensures transparency, security, and tamper-proof storage, making blockchain ideal for applications such as cryptocurrency, supply chain management, and smart contracts. Blockchain's core features include decentralization, immutability, transparency, and cryptographic security [59], enabling efficient, trustless operations across various industries. Blockchain platforms provide the infrastructure for building, deploying, and managing decentralized systems and applications. They enable recording, validating, and securing data in an immutable, distributed ledger. Several blockchain platforms are popular at the industry scale due to their unique capabilities and applications. For instance, Ethereum [26] is well-suited for private and consortium blockchains in enterprises, leveraging the Proof of Authority [52] consensus for fast block creation without mining. It supports smart contracts and decentralized applications (dApps) [55] within Ethereum’s robust ecosystem. Hyperledger Fabric [27], another notable platform, is widely used in supply chain, finance, and healthcare industries. Its modular, permissioned architecture with private channels allows high customization for specific business workflows. Similarly, Corda [54] is designed for financial services and trade finance, featuring a peer-to-peer transaction model that ensures privacy and compliance with regulatory requirements. Quorum [56], a blockchain platform forked from Ethereum, is tailored for banking and asset management, offering enhanced privacy and compatibility with Ethereum smart contracts. MultiChain [57], on the other hand, is designed for private networks and secure data sharing, providing fast deployment and built-in permissions management, making it ideal for controlled enterprise environments. Lastly, Ripple (XRP Ledger) [58] focuses on cross-border payments, delivering near-instant transactions and scalable performance for financial institutions. These platforms collectively address diverse enterprise needs, offering strong privacy, scalability, and customizability to support a wide range of business applications, from secure data sharing to financial services and decentralized asset management. 3.2 Smart contract A smart contract is a self-executing program stored on a blockchain, with the terms and logic encoded directly into its code. The contract automatically executes when predefined conditions are met, ensuring tamper-proof, transparent, and trustless operations without intermediaries. Key features include automation, immutability, cryptographic security, and decentralized execution. Smart contracts are extensively used in financial transactions, supply chain management, and decentralized applications (dApps), transforming how agreements are enforced securely and efficiently. 3.3 Consensus algorithms A consensus algorithm is a fundamental mechanism in blockchain networks that ensures all participants (nodes) agree on the validity of transactions and the current state of the ledger. It resolves trust issues in decentralized systems by providing a unified agreement among distributed nodes. Table 1 compares three widely used consensus algorithms—PoW, PoA, and BFT—highlighting their trade-offs in terms of security, scalability, decentralization, and efficiency. Table 1 : Comparison of PoW, PoA, and BFT consensus mechanisms based on key features like security, scalability, energy efficiency, and use cases Feature Proof of Work (PoW) Proof of Authority (PoA) Byzantine Fault Tolerance (BFT) Security High Medium High Energy Efficiency Low High Medium Scalability Low High Medium Decentralization High Medium Medium Fault Tolerance Medium Low High Use Cases Bitcoin, Litecoin VeChain, Rinkeby Hyperledger, Tendermint 3.4 InterPlanetary File System (IPFS) The InterPlanetary File System (IPFS) [49] is a decentralized, peer-to-peer file storage and sharing protocol designed to create a more open and resilient web. Unlike traditional centralized systems, IPFS uses content-addressing to identify files by their unique cryptographic hash rather than their location. This ensures data integrity and allows files to be distributed across multiple nodes globally, enhancing reliability and resistance to censorship. IPFS is commonly used for storing and sharing large datasets, decentralized applications (dApps), and blockchain-related data, providing an efficient, secure, and scalable alternative to traditional file storage systems 3.5 Elasticsearch Elasticsearch [60] is a distributed, open-source search and analytics engine built on Apache Lucene. It provides fast and scalable full-text search, data indexing, and real-time data exploration, making it ideal for applications like log analysis, business intelligence, and security monitoring. Its ability to handle large datasets efficiently makes it a popular choice for enterprise solutions. 4. Methods In this section, we describe our research and experimental design in detail, discussing the rationale behind our design choices. We use the following technologies in our research: Ethereum (Proof of Authority) Solidity for smart contracts IPFS for off-chain storage Elasticsearch for search and analytics 4.1 Ethereum as our Blockchain Platform Ethereum is one of the most widely used and versatile blockchain platforms, making it an excellent choice for developing secure, scalable, and decentralized applications. Its robust ecosystem offers extensive developer tools, active community support, and compatibility with smart contracts via the Ethereum Virtual Machine (EVM). These attributes make Ethereum particularly suited for enterprise-grade solutions and research applications. 4.2 Smart contracts with Ethereum (PoA) The performance of a blockchain platform mostly depends on the consensus algorithm employed therein. The combination of Ethereum's versatile blockchain capabilities and PoA's high efficiency creates an optimized environment for scalable and secure applications. This configuration ensures rapid transaction processing, reduced operational costs, and robust smart contract execution, making it a preferred choice for enterprise and research-focused projects. We use Solidity with Ethereum (PoA) for its native EVM compatibility, enabling efficient, secure, and low-latency execution of smart contracts in a permissioned environment. 4.3 IPFS for Off-Chain Storage Once a log file is verified using our tool and no longer changes, it is stored in the InterPlanetary File System (IPFS) to make it tamper-proof and persistently available. IPFS uses a unique hash to identify each file, ensuring its integrity. We then record that hash on the blockchain, creating a lightweight and verifiable audit trail. A similar approach was adopted by Rakib et al. [13], showcasing the use of IPFS for securely storing finalized logs in blockchain-based systems. However, their solution is confined to offline or pre-generated logs and does not address the challenges of real-time log generation, ingestion, or on-the-fly verification—key requirements for dynamic and continuously operating environments. 4.4 Elasticsearch for Search and Analytics Querying logs directly from the blockchain is slow and not suitable for large-scale systems. To solve this, we use Elasticsearch for fast and efficient access to logs after they are verified and stored in IPFS. Finalized logs are indexed, making it easy to search, filter, and analyze them quickly. This setup keeps integrity checks handled by the blockchain and IPFS, while Elasticsearch ensures fast performance for tasks like audits, anomaly detection, and compliance. 4.5 Data Model In this study, we focus on plain-text logs, where each log entry follows a standardized format to ensure uniformity and compatibility. A typical log entry includes: Timestamp : Precise date and time with nanosecond granularity to maintain accuracy. Log Level : Indicates the severity or priority of the log (e.g., INFO, DEBUG, ERROR). Machine/Service Name : Specifies the source of the log for identification. Log Details : Provides a description or message for the logged event. This standardized structure enables efficient parsing, storage, and analysis of log data, crucial for large-scale systems. 4.6 Data Collection To comprehensively test the system's performance, both offline and real-time, we utilize three distinct sources of log data as follows. Online Archives : We have collected datasets from LogPai [13], which contain diverse log samples from large-scale systems and data centers. These datasets allow us to evaluate the system's offline behavior with substantial volumes of data. Synthetic Log Generators : We have used tools like Fake-Apache-Log-Generator [14] to generate human-readable, randomized logs. These enable us to simulate diverse scenarios and test the system's real-time data handling capabilities. Custom Log Generator : A tailored log generation tool has been developed to create logs with specific patterns, formats, or parameters. This process ensures flexibility for testing system behaviors under customized conditions. By combining these datasets, we aim to rigorously evaluate the system's robustness, scalability, and real-time processing capabilities across a range of scenarios and data volumes. 5. Main Approach of LogStamping We developed our system with three major components, they are: Ingestion Tool, Blockchain Platform, and Integrity Verification Tool. In what follows, we briefly describe these components. 5.1 The Ingestion Tool The Python-based log ingestion tool is designed to provide a scalable and secure solution for managing log data in large-scale systems. By integrating blockchain technology, the tool ensures the immutability, traceability, and auditability of log entries. It continuously monitors log files for new entries, generates cryptographic hashes (using SHA256 [50] ) for individual or a group of n log lines, where n is any predefined number of log lines, and records these hashes on the blockchain. This approach ensures that log data remains tamper-proof and can be reliably audited for compliance and forensic purposes if and when required. The tool is particularly suited for high-volume environments, such as data centers and distributed systems, where traditional log management systems often struggle to maintain security and scalability. The following components make up the modular architecture of the log ingestion tool: Log Collector : Gathers logs from various sources. Parser and Formatter : Standardizes log formats. Blockchain Interface : Interacts with the blockchain to store logs immutably. Error Handling Module : Manages exceptions and logging failures. Algorithm 1 : MonitorAndIngestLogs Input : logFile, groupSize, timeout Output : Hashes stored in blockchain for log file integrity 1. Initialize logGroup ← ∅ 2. Initialize startTime ← CURRENT_TIME() 3. while True do 4. Wait for new log entry in logFile 5. if NEW _ENTRY_ EXISTS(logFile) then 6. Append log entry to logGroup 7. end if 8. if |logGroup| ≥ groupSize or (CURRENT_TIME() − startTime) ≥ timeout then 9. hashValue ← GenerateSHA256Hash(logGroup) 10. WriteToBlockchain(hashValue) 11. logGroup ← ∅ 12. startTime ← CURRENT_TIME() 13. end if 14. end while Algorithm 2: GenerateSHA256Hash Input : logGroup Output : Hash value of log group 1. Concatenate all log entries in logGroup into a single string 2. return SHA256 _HASH_ OF_STRING(string) Algorithm 3: WriteToBlockchain Input : hashValue Output : hashValue stored in blockchain 1. Connect to blockchain 2. Store hashValue in blockchain 3. return SUCCESS The tool works by executing the following steps. Figure 1 illustrates the described log ingestion process. Monitoring Log Entries : The log ingestion tool continuously monitors the target log file for new entries, processing them line by line. Grouping Log Lines : Instead of sending each log line individually, the tool groups multiple log lines to form a chunk based on pre-configured parameters (e.g., number of lines ( n) , time intervals (t) ). Here, Algorithm 1 explains the complete process. Timeout Handling : If the chunk is incomplete (e.g., insufficient new log entries), the tool waits for a pre-configured timeout (t) period. After the timeout, the hash of the partial group is computed and written to the blockchain to secure any unrecorded entries. Dynamic Group Capacity : The size of the groups is variable, dynamically adjusting based on the frequency of log entries in the target log file. Hash Generation : Once a group is formed, the tool computes SHA256 hash for the grouped log lines, creating a unique digital fingerprint (Algorithm 2). Writing to Blockchain : The computed hash is immediately written into the blockchain, ensuring the immutability and integrity of the grouped logs (Algorithm 3). 5.2 The Blockchain Platform We deployed Ethereum [26] as the private blockchain platform for its ease of setup, maintenance, and scalability. To improve efficiency as per Figure 1, we adopted the Proof of Authority (PoA) consensus algorithm [52], which enables rapid block creation without the need for mining. Custom smart contracts were developed in Solidity [51], supported by additional tools, such as Blockchain Explorer [53], for enhanced functionality. The smart contract's functionalities are in Algorithm 4. Algorithm 4: LogStorage Smart Contract Purpose : To store and retrieve log hashes securely on the blockchain. Input : logHash (string) - The cryptographic hash of a log group. Output : Immutable storage and retrieval of log hashes. State Variables: 1. logHashes: A mapping (integer → string) to store log hashes indexed by their count. 2. logCount: An unsigned integer representing the total number of stored log hashes. Functions: 1. Function: storeLogHash Input: logHash (string) - The hash to be stored. Output: Updates logHashes and increments logCount. Procedure: 1. logHashes[logCount] ← logHash 2. logCount ← logCount + 1 2. Function: getLogHash Input: index (unsigned integer) - The index of the log hash to retrieve. Output: The log hash stored at the specified index. Procedure: 1. return logHashes[index] The Integrity Verification Tool Verification tools ensure the integrity and authenticity of log files by detecting tampering or modifications. Their process logs by grouping entries based on predefined parameters, computing cryptographic hashes using SHA256, and verifying these hashes against blockchain records. Using timestamps from log entries, they align verification with real-world events. Optionally, verified logs can be archived in IPFS for immutability or indexed in ElasticSearch for efficient querying. These tools are vital for audits, forensic investigations, and maintaining trust in system logs. Algorithm 5: VerifyLogIntegrityWithTimestamps Input : logFile, groupParameters (maxLines, maxWaitTime), blockchain, ipfs (optional), elasticSearch (optional) Output : Verification status of log integrity 1. Initialize logGroup ← ∅ 2. Initialize allHashesValid ← TRUE 3. Initialize groupStartTime ← NULL 4. Initialize groupEndTime ← NULL 5. Open logFile for reading 6. while not EOF(logFile) do 7. Read logLine from logFile 8. Append logLine to logGroup 9. Extract timestamp from logLine 10. if groupStartTime = NULL then 11. groupStartTime ← timestamp 12. end if 13. groupEndTime ← timestamp 14. if |logGroup| ≥ groupParameters.maxLines or (groupEndTime − groupStartTime) ≥ groupParameters.maxWaitTime then 15. hashValue ← ComputeHash(logGroup) 16. isValid ← QueryBlockchain(hashValue, blockchain) 17. if isValid = FALSE then 18. allHashesValid ← FALSE 19. Print "Tampered group detected:" 20. end if 21. logGroup ← ∅ 22. groupStartTime ← NULL 23. groupEndTime ← NULL 24. end if 25. end while 26. if logGroup ≠ ∅ then 27. hashValue ← ComputeHash(logGroup) 28. isValid ← QueryBlockchain(hashValue, blockchain) 29. if isValid = FALSE then 30. allHashesValid ← FALSE 31. Print "Tampered group detected:", logGroup 32. end if 33. end if 34. if allHashesValid = TRUE then 35. Print "Log file is intact" 36. if ipfs ≠ NULL then 37. ArchiveToIPFS(logFile) 38. end if 39. if elasticSearch ≠ NULL then 40. StoreInElasticSearch(logFile) 41. end if 42. else 43. Print "Log file has been modified" 44. end if The tool works based on Algorithm 5 by executing the following steps. Figure 2 illustrates the log verification process. Log Grouping Based on Time and Size: The algorithm reads an existing log file and groups entries based on two conditions: a maximum number of lines ( maxLines ) or a maximum time window ( maxWaitTime ). Each entry is added to the current group, and timestamps are used to determine the time span (Line 14). Conditional Group Finalization: When either condition is met, the current group is finalized for integrity verification (Lines 14-20). This approach ensures consistent and adaptive log grouping without requiring real-time monitoring. Hash Computation and Blockchain Verification: For every completed group - A SHA-256 hash is computed from the grouped entries ( Line 15, 27 ) . The hash is checked against blockchain records ( Lines 34-44 ) . Match found: Group is confirmed intact. No match: Group is flagged as tampered. Handling Remaining Entries: After processing all log lines, any incomplete group is also hashed and verified to ensure no entries are skipped (Lines 26-33). Optional Steps: IPFS Archival: Verified log files can be archived in IPFS to ensure long-term immutability. Elasticsearch Indexing: Logs can be indexed in Elasticsearch for fast retrieval and advanced search capabilities. 5.3 Handling log files in large scale systems Efficient log management in large-scale systems relies on robust strategies for categorization, traceability, and organization. A widely adopted approach is the use of structured naming patterns for log files, incorporating base names dynamically configured with details, such as timestamps, system identifiers, or unique indices. This method ensures better organization, simplified retrieval, and improved log file management. Common log generation methods include time-based, size-based, index-based, event-based, chunk-based, hybrid (time + size), and distributed approaches. These methods segment logs by criteria, such as time, size, events, indices, or sources, creating unique file names that often include timestamp fields for each entry. Our system employs a hybrid approach (i.e., a combination of chunk-based and time-based approaches) to process real-time logs into the blockchain, leveraging standardized log generation patterns. The chunk-based approach groups logs by a fixed number of entries, ideal for high-volume systems to optimize performance and reduce processing overhead. On the other hand, the time-based approach groups logs by fixed time intervals, ensuring timely processing and enhanced security in systems with irregular log generation. Hybrid approach, as the name indicates, combines both chunk size and time interval conditions, finalizing log groups when either threshold is met for balanced efficiency and flexibility. This methodology ensures scalable, flexible, and reliable management practices optimized for real-time operations in large-scale systems. To elaborate, in this approach, logs are grouped based on two criteria: a predefined maximum chunk size (number of entries) and a predefined time interval (e.g., seconds or minutes). A log group is finalized and processed as soon as either of these conditions are met, ensuring timeliness and scalability. This dual criterion prevents excessive waiting for logs to fill a chunk while avoiding overloading the system during high activity periods. Once a group is complete, a cryptographic hash is computed and stored on the blockchain, ensuring the integrity and traceability of the logs. The hybrid approach also allows dynamic adjustment of chunk size and time intervals, enabling the system to adapt to changes in log generation rates and workloads. By combining the strengths of both methods, the hybrid approach reduces tampering risks, optimizes resource usage, and ensures timely log processing, making it ideal for large-scale, high-frequency systems. 5.4 Log Archiving Using Off-Chain In this approach, logs are periodically archived off-chain after the ingestion process for a specific log file is complete and no additional entries are expected. Once a log file is marked as complete, the verification tool continuously monitors it to ensure there are no alterations or tampering. If the verification tool confirms the file’s integrity, the entire log file is encrypted using a symmetric key to enhance security and then archived in IPFS (InterPlanetary File System). This ensures that the archived file is both immutable and secure. The archiving process is designed to adapt to the log generation strategy. For instance, if the strategy is time-based, the system will trigger the archiving process at regular time intervals, ensuring an encrypted and immutable copy of the original log file is maintained. This approach is beneficial for log recovery and for pinpointing specific lines where modifications might have occurred. Alternatively, strategies such as size-based or index-based log generation are also supported. Regardless of the strategy, the archiving process remains consistent, ensuring securely stored logs that are readily available for verification and recovery. By encrypting the original file before storing it in IPFS, this off-chain archiving approach maintains log integrity and enhances confidentiality. This method provides a robust mechanism for safeguarding logs, supporting flexible log generation strategies, and ensuring immutable, tamper-proof, and secure records. 5.5 Leveraging Elasticsearch for Efficient Log Search and Audit Searching data directly on a blockchain is not optimal, particularly for large-scale log files. Large data storage in a distributed manner requires a significant amount of storage capacity. Blockchain’s inherent design prioritizes immutability and security but lacks the performance capabilities required for efficient data retrieval, especially for unstructured data. To address this limitation, industry-standard tools like Elasticsearch [60] are a better fit for full-text search and analysis. Elasticsearch is known for its high performance and scalability, making it ideal for handling large datasets and conducting fast, precise searches. In our system, we utilized Elasticsearch for storing and querying logs after their integrity was verified by the verification tool. Logs are stored in chunks, with each chunk containing the following items. Calculated Hash : Ensuring that data integrity is maintained and verifiable. Raw Log Data : Providing unstructured log content for search and analysis. Chunk Metadata : Including the hash of the chunk and its associated log data for additional traceability. For logs originating from IPFS (InterPlanetary File System), Elasticsearch acts as a complementary storage solution. IPFS ensures the integrity, availability, and immutability of the log files, while Elasticsearch facilitates efficient full-text search and audit processes. This dual approach enhances both data security and retrieval performance. The primary purpose of Elasticsearch in this system is to support forensic and auditing operations. By enabling fast and accurate searches across large datasets, Elasticsearch simplifies the task of finding specific log entries, even within unstructured data. This approach combines the security of blockchain and IPFS with the performance capabilities of Elasticsearch, creating a robust solution for log management in large-scale systems. 6. Experimental setup 6.1 Hardware Requirements For the implementation of our system, we configured three identical nodes with the following hardware specifications: Processor : 4 vCPUs Memory (RAM) : 8 GB Storage : 200 GB Operating System: Ubuntu 22.04 LTS These nodes are uniformly configured to ensure consistent performance across the blockchain network. This identical setup minimizes variations in processing and storage. 6.2 Datasets For the evaluation of our system, we utilized two distinct datasets to assess performance under varying log volumes: Small Dataset : Size : 10,000 log lines Purpose : Used to evaluate the correctness of our proposed model. Datasource : LogPai [13] Large Dataset : Size : 14 million log lines (~1.3 GB) Purpose : Used to test the system's scalability and robustness in handling large-scale log data efficiently. DataSource : Fake-Apache-Log-Generator [14] and our custom log generator These datasets provided comprehensive insights into the system’s performance across both small-scale and large-scale use cases, ensuring its suitability for diverse operational requirements. 6.3 Tools We use the following tools in our experiments: Python: Core language for implementing log processing, verification logic, and system integration. web3.py: Python library for interacting with Ethereum-compatible blockchains, handling smart contract interactions and transactions. web3.js: JavaScript library for blockchain communication from web or Node.js applications. Geth: Go Ethereum client used to run a full Ethereum node and interface with the blockchain. IPFS CLI / API: Tools for decentralized storage and retrieval of verified log files. Elasticsearch: Engine for indexing and querying verified logs efficiently. 6.4 Analysis Security : The proposed model incorporates robust security measures to ensure data integrity and protection. By leveraging the Proof of Authority (PoA) consensus algorithm, it ensures that only trusted, pre-authorized nodes are responsible for block creation, minimizing the risk of unauthorized activity. Furthermore, the ingestion tool operates within a secure, private network, restricting access exclusively to verified entities. These combined mechanisms create a highly secure and reliable framework for log management. Scalability : The proposed system enhances the scalability of blockchain networks by significantly reducing the number of network calls through the implementation of chunk-based processing. This approach minimizes the frequency of transactions, making the system more efficient and suitable for integration with other services or applications. Additionally, the reduced storage requirements decrease the input/output (I/O) overhead on blockchain servers, thereby improving processing efficiency and overall system performance. Privacy : We have implemented robust privacy measures in our proposed model to ensure the highest level of data security. Notably, no raw log data is stored directly on the blockchain, and it is impossible to reconstruct raw data from the information stored in the blockchain. Furthermore, the data stored in the InterPlanetary File System (IPFS) is encrypted before being transmitted, adding an additional layer of security. This comprehensive approach ensures that privacy is maintained at an optimal level, adhering to best practices for secure and private data management. 6.5 Evaluation We have evaluated the proposed system under various scenarios to analyze its behavior in terms of storage usage and performance. These scenarios were designed to assess the system’s capabilities for both small and large log datasets. The experiments were conducted with different configurations, focusing on the time required for processing and storage consumption. Table 2 reports the datasets and chunk parameters used in different experiments. Table 2: Experimental setup for evaluating log ingestion and storage efficiency, showing different dataset sizes, chunk configurations, log formats (raw and hashed), number of nodes, and the performance metrics (time and storage) used for analysis. Dataset (log entries) Chunk Size (N) Ingestion Date Type Nodes Metrics 10,000 1, 5, 10, 20 Raw 3 Time & Storage Hashed 14 million 1, 5, 10, 20 Hashed 3 Time & Storage The storage required to store raw data on the blockchain is consistently high, regardless of the chunk size. Therefore, we excluded raw data from the analysis for large datasets, focusing instead on the results for different chunk sizes with hashed data. 7. Result Analysis & Discussions 7.1 Result Analysis 7.1.1 Ingestion Anlysis We initially conducted experiments on a small dataset (10k log entries) to analyze storage usage for raw data and hashed data for each log line. From the results depicted in Figure 3 , it is evident that for a chunk size of N=1 , the storage required for hashed data is reduced by half compared to raw data. This reduction corresponds to a 50% storage gain, highlighting the efficiency of hashed data storage in minimizing storage overhead while preserving data integrity and auditability. The storage required for hashed data significantly decreases as the chunk size increases. For N=5 , the storage usage is approximately five times less compared to N=1 . This substantial reduction is due to the minimized metadata overhead and fewer chunks being generated, demonstrating the efficiency of larger chunk sizes in optimizing storage. From Figure 4 , the storage required is 14 GB where N=1 and the data is hashed. It also shows that increasing the chunk size to N=5, 10, 20 for hashed data significantly reduces storage requirements. For each increase in chunk size, the storage requirement becomes approximately half of the same for the preceding chunk size. This reduction occurs due to fewer chunks being created, which minimizes metadata overhead and optimizes storage usage. Larger chunk sizes are thus highly effective in reducing storage demands while maintaining data integrity. Similarly, Figure 5 presents a quantitative analysis of processing time for 14 million hashed log entries under varying chunk sizes. When each log entry is processed individually (chunk size of 1), the total processing time reaches approximately 172 hours , indicating a substantial computational overhead. However, when logs are grouped into batches of 5 entries, the processing time drops dramatically to about 16 hours , reflecting a nearly 90% reduction . Increasing the chunk size further results in additional gains—processing time decreases to roughly 7.5 hours with a chunk size of 10 and stabilizes around 7.3 hours at chunk size 20. This trend clearly demonstrates that batching log entries into larger groups significantly improves processing efficiency. Fewer hash computations and reduced storage interactions contribute to the time savings. These findings emphasize the value of selecting an appropriate chunking strategy to ensure scalability and high performance in large-scale log processing systems. Figure 4 and Figure 5 collectively offer details about the scalability and performance of the system, emphasizing its ability to handle large-scale datasets efficiently in terms of both storage and time. Finally, Figure 6 presents a combined analysis of storage usage and processing time for 14 million log entries using various chunk sizes. This figure demonstrates how increasing the chunk size significantly reduces both storage overhead and processing time during log data processing. When the chunk size is set to 1, the system requires approximately 14,062 MB of additional storage and takes around 172.6 hours to process, highlighting the inefficiency of handling logs individually. As the chunk size increases to 5, both metrics improve drastically, with storage dropping to 2,664 MB and processing time reducing to 15.8 hours . This trend continues with chunk size 10, where storage falls to 1,151 MB and time to 7.3 hours . At chunk size 20, the gains begin to plateau, with storage at 1,083 MB and processing time at 7.3 hours , indicating diminishing returns beyond this point. Overall, Figure 6 demonstrates that batching logs into larger chunks significantly enhances system efficiency, with the most notable improvements occurring between chunk sizes 1 and 10. These results clearly demonstrate that increasing the chunk size drastically reduces both storage requirements and processing time. The greatest gains occur between chunk sizes 1 and 5, emphasizing the inefficiency of handling logs individually. The trend highlights the effectiveness of chunking for optimizing both system performance and resource utilization in large-scale log management. 7.1.2 Verification Analysis The verification time analysis presented in Figure 7 highlights the significant impact of chunk size (N) on the efficiency of log verification. When the chunk size is set to 1, the system takes approximately 1,020 minutes (or 17 hours) to verify the logs, indicating a high computational burden when each entry is processed individually. However, as the chunk size increases to 5, the verification time drops sharply to 200 minutes , representing nearly an 80% reduction . At chunk size 10, the time further decreases to around 145 minutes , and at chunk size 20, it reaches just 50 minutes . Overall, moving from a chunk size of 1 to 20 results in a 95% reduction in verification time. This trend highlights the efficiency benefits of processing logs in larger chunks, especially in large-scale or real-time verification systems. These results highlight the importance of optimizing chunk sizes for efficient log verification. Larger chunk sizes reduce processing overhead and enhance the scalability of the system, particularly in high-volume log datasets. By balancing chunk size with processing capabilities, this approach ensures a more efficient and scalable solution for log verification in large-scale systems. 7.2 Comparative Analysis Summary This section compares LogStamping against four notable blockchain-based log or provenance systems: LogChain [6] , BCALS [15] , EngraveChain [16] , Rakib et al. [19] , and ProvChain[8] . The analysis evaluates key system aspects including storage, verification speed, real-time capability, query performance, and tamper detection. Table 3 shows a comparative analysis summary among those systems. Table 3 : Comparison of Blockchain-Based Log Management Systems Feature LogChain BCALS EngraveChain Rakib et al. ProvChain LogStamping(Proposed) Storage Efficiency Unknown: No backend specified Moderate: On-chain; no compression High: Encrypted chunks, no IPFS High: IPFS + hash mapping Low: Fully on-chain; high cost ✅ Very High: IPFS + chunking (92% reduction) Verification Time Unreported: No results Moderate: On-chain transforms slow audits Moderate: Limited benchmarking Moderate: No numbers reported Moderate: No latency data ✅ Very High: 95% faster audit (1,020 → 50 mins) Real-Time Support ❌ Not implemented; underdeveloped API ❌ Limited ❌ Limited ❌ Pre-computed logs only ❌ Not emphasized; post-event focus ✅ High Query Efficiency Unknown: Query system not defined Moderate: Uses Elasticsearch, not optimized Moderate: Slow chain traversal High: Timestamped Merkle tree Low: No retrieval optimization ✅ Very High: Indexed search via IPFS + Elasticsearch Tamper Detection Theoretical: Not validated High: Blockchain integrity High: AES/RSA, no detection rate given High: IPFS-backed hash proofs High: Immutable, but no tested attack detection ✅ Very High: 100% detection of fake log injections 7.3 Discussion on Storage Gain Perspective The analysis of storage requirements for different chunk sizes reveals significant storage optimization as the chunk size increases. For N=1 , the storage demand is the highest due to the large number of small chunks, each requiring its own metadata and hash computations. This additional overhead contributes to inflated storage usage. In contrast, larger chunk sizes ( N=5, 10, 20 ) dramatically reduce storage needs by consolidating more log entries into fewer chunks, thereby minimizing metadata overhead. For instance, Figure 4 shows that when N=5 , the storage requirement is approximately five times less than that for N=1, demonstrating a substantial storage gain. Similarly, as the chunk size increases to N=10 and N=20, the storage demands continue to decrease, albeit with diminishing returns. This trend underscores the efficiency of larger chunk sizes in reducing overall storage requirements while maintaining data integrity. From a storage optimization perspective, the results indicate that larger chunk sizes reduce the total storage footprint and make the system more scalable for large datasets. However, there is a trade-off between storage efficiency and potential delays in log ingestion, as larger chunks require more time to fill. Balancing chunk size based on system requirements and log generation rates is essential for achieving optimal storage usage and system performance. This approach highlights the importance of chunk size configuration as a critical parameter for scalable and efficient blockchain-based log management. 7.4 Discussion on Performance Gain Perspective The performance of blockchain systems in processing large-scale log files is influenced by several critical factors, including the selection of the blockchain platform, the choice of an efficient consensus algorithm, and the underlying hardware capabilities, such as CPU performance and host machine specifications. After a thorough evaluation, we identified and implemented the most suitable platform combined with a high-performance consensus algorithm to optimize processing efficiency. Our findings highlight the time required to process large log files, demonstrating that our approach leverages these optimizations to achieve enhanced performance and scalability. As previously discussed, Figure 5 highlights substantial performance gains achieved by increasing chunk size. Recall that processing time drops from 172.6 hours at N=1 to 15.8 hours at N=5 (a ~91% improvement), and further to 7.3 hours at N=10 (a ~54% gain over N=5). These results confirm that the majority of performance gains occur between N=1 and N=10. Moreover, this approach enables near real-time processing when chunk sizes are dynamically adjusted based on application-specific log generation rates. Overall, our experiments highlight that while increasing chunk size dramatically boosts performance at first, especially from N=1 to N=10 , the marginal benefits taper off beyond that. Selecting a moderate chunk size, such as N=10, offers a balanced trade-off between performance and resource usage in large-scale log processing. Importantly, this figure also illustrates that when log generation occurs in real time, this chunk-based strategy allows the system to process logs almost in real time. By dynamically adjusting chunk sizes based on the log generation rate of different applications, the system can maintain efficiency and responsiveness without introducing significant processing delays. 7.5 Discussion on Temper detection The proposed tamper detection mechanism leverages a timestamp-aware log grouping strategy to ensure data integrity. Using configurable thresholds ( maxLines , maxWaitTime ), log entries are grouped and hashed incrementally, with each hash verified against the blockchain. This enables localized detection of modifications without reprocessing the entire log file. The algorithm supports real-time log integrity checks, efficiently identifying altered segments based on their temporal boundaries. If tampering is detected, the affected group is flagged, while intact logs are optionally archived to IPFS and indexed in Elasticsearch. Experimental results show a 100% detection accuracy for any synthetic tampering, confirming the system’s effectiveness for scalable, fine-grained integrity verification in dynamic environments. 8. Conclusion and Future Works The proposed LogStamping framework addresses key limitations in existing blockchain-based log management systems by introducing an efficient, scalable, and tamper-resilient solution. Through dynamic chunking, off-chain storage via IPFS, and real-time indexing with Elasticsearch, the system enables high-throughput log ingestion and efficient auditability. Empirical evaluations confirm significant gains in storage efficiency, performance, and tamper detection accuracy. Furthermore, the system guarantees integrity through cryptographic hashing and blockchain anchoring, ensuring trustworthy and verifiable log records. The name LogStamping reflects its foundational design—mirroring timestamping practices in PKI systems , where data integrity, authenticity, and temporal validity are enforced via secure digital signatures. Similarly, LogStamping secures logs by embedding them into timestamped hash groups, offering strong guarantees of chronological accuracy, traceability, and audit readiness. This work lays a robust foundation for future advancements in decentralized and verifiable system log management. However, a key limitation lies in the system’s inability to recover logs during ingestion . Since only hashes are stored on-chain and raw logs are not retained until explicitly archived, any loss or deletion before ingestion completes will result in irreversible data loss. Although this enhances privacy and reduces storage burden, it limits real-time recoverability. Once logs are ingested and verified, however, they become tamper-proof and immutable, providing reliable records for audit and compliance. Future work will focus on extending the system’s log recoverability , fault-tolerant ingestion pipelines , and fine-grained access control for multi-tenant environments. Integrating anomaly detection, dynamic chunk reconfiguration, and decentralized identity for audit attribution will further enhance LogStamping’s applicability in critical infrastructure and cloud-native systems. Declarations Funding The authors did not receive support from any organization for the submitted work. No funds, grants, or other support were received. Competing Interests The authors have no relevant financial or non-financial interests to disclose. Author Contributions Md Shariful Islam led the study conception, design, implementation, and served as the primary writer of the manuscript. Mohammad Saifur Rahman and M. Sohel Rahman provided continuous supervision, research guidance, and intellectual feedback throughout the project. Material preparation, data collection, and analysis were conducted by Md Shariful Islam with supervisory support from the co-authors. All authors reviewed, commented on, and approved the final manuscript. Data Availability The data that support the findings of this study are available from the corresponding author upon reasonable request. Ethics Approval Not applicable. This study did not involve human participants, animals, or any materials requiring ethics approval. References Liang, Y.; Zhang, Y.; Sivasubramaniam, A.; Jette, M.; Sahoo, R. Bluegene/l failure analysis and prediction models. In Proceedings of the International Conference on Dependable Systems and Networks, Philadelphia, PA, USA, 25–28 June 2006; p. 425. Frei, A.; Rennhard, M. Histogram Matrix: Log File Visualization for Anomaly Detection. In Proceedings of the 2008 Third International Conference on Availability, Reliability and Security, Barcelona, Spain, 4–7 March 2008; pp. 610–617. Goldstein, M.; Raz, D.; Segall, I. Experience Report: Log-Based Behavioral Differencing. In Proceedings of the 2017 IEEE 28th International Symposium on Software Reliability Engineering (ISSRE), Toulouse, France, 23–26 October 2017; pp. 282–293. O. Soderstrom and E. Moradian, “Secure audit log management,” ¨ Procedia Comput. Sci., vol. 22, pp. 1249–1258, 2013 I. Ray, K. Belyaev, M. Strizhov, D. Mulamba, and M. Rajaram, “Secure logging as a service-delegating log management to the cloud,” IEEE Syst. Journal, vol. 7, no. 2, pp. 323–334, 2013. W. Pourmajidi and A. Miranskyy, “Logchain: Blockchain-assisted log storage,” in Proc. 11th IEEE Int. Conf. Cloud Comput. (CLOUD), 2018, pp. 978–982. M. Kumar, A. K. Singh, and T. V. S. Kumar, “Secure log storage using blockchain and cloud infrastructure,” in Proc. 9th IEEE Int. Conf. Comput., Commun. and Netw. Technol. (ICCCNT), 2018, pp. 1–4 X. Liang, S. Shetty, D. Tosh, C. Kamhoua, K. Kwiat, and L. Njilla, “Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability,” in Proc. 17th IEEE/ACM Int. Symp. Cluster, Cloud and Grid Comput. (CCGrid’17), 2017, pp. 468–477 J. H. Park, J. Y. Park, and E. N. Huh, “Block chain based data logging and integrity management system for cloud forensics ,” Comput. Sci. & Inf. Technol., vol. 149, 2017 Schneier, B., & Kelsey, J. (1999). Cryptographic Support for Secure Logs on Untrusted Machines. Holt, J. E. (2006). Logcrypt: Forward Security and Public Verification for Secure Audit Logs. AISW-NetSec 2006. Ahmad, A., Saad, M., Bassiouni, M., & Mohaisen, A. (2018). Towards Blockchain-Driven, Secure and Transparent Audit Logs. MobiQuitous, 3286978-3286985. Rakib, M. H., Hossain, S., Jahan, M., & Kabir, U. (2020). Towards Blockchain-Driven Network Log Management System. IEEE iSCI IBM (2018). Storage Needs for Blockchain Technology: Point of View. IBM Corporation. Ali, A., Khan, A., Ahmed, M., & Jeon, G. (2021). BCALS: Blockchain-Based Secure Log Management System for Cloud Computing. Transactions on Emerging Telecommunications Technologies, e4272. L. M. Shekhtman and E. Waisbard, "Securing log files through blockchain technology," in Proceedings of the 11th ACM International Systems and Storage Conference, Article No. 3, 2018. doi: 10.1145/3211890.3211893. Shekhtman, L., & Waisbard, E. (2021). EngraveChain: A Blockchain-Based Tamper-Proof Distributed Log System. Future Internet, 13(6), 143. P. V. Kakarlapudi and Q. H. Mahmoud, "Design and Development of a Blockchain-Based System for Private Data Management," Electronics, vol. 10, no. 24, p. 3131, 2021. doi: 10.3390/electronics10243131. Rakib, M. H., Hossain, S., Jahan, M., & Kabir, U. (2022). A Blockchain-Enabled Scalable Network Log Management System. Journal of Computer Science, 18(6), 496-508. Y. Zhao, X. Liu, and L. Wang, "A Complete Log Files Security Solution Using Anomaly Detection and Blockchain Technology," Proceedings of the IEEE International Conference on Big Data (Big Data 2023), pp. X-X, 2023. DOI: 10.1109/BigData.2023.10100200. Kanhere, S. S., & Conti, M. (2024). Blockchain for Health Data Management. In Blockchains: A Handbook on Fundamentals, Platforms and Applications (pp. 321-346). Springer. https://doi.org/10.1007/978-3-031-32146-7_18 Khan, S., Alam, M., & Khan, S. U. (2023). Blockchain-Based Secure Logging Mechanism for Cloud Forensics. Computers & Security, 125, 102976. https://doi.org/10.1016/j.cose.2023.102976 Singh, A., Zhou, Y., Mehrotra, S., Sadoghi, M., Sharma, S., & Nawab, F. (2023). WedgeBlock: An off-chain secure logging platform for blockchain applications. In Proceedings of the 26th International Conference on Extending Database Technology (EDBT) (pp. 684–696). https://doi.org/10.48786/edbt.2023.43 Zhang, P., & Wang, J. (2019). Blockchain Based Data Integrity Verification for Large-Scale IoT Data. IEEE Access, 7, 164401-164411. https://doi.org/10.1109/ACCESS.2019.2952847 Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. Retrieved from https://bitcoin.org/bitcoin.pdf Buterin, V. (2013). A next-generation smart contract and decentralized application platform. Ethereum Whitepaper. Available at https://ethereum.org/en/whitepaper/ Hyperledger Fabric Documentation. (2024). Hyperledger Fabric documentation. Retrieved from https://hyperledger-fabric.readthedocs.io/ A Large Collection of System Log Datasets for AI-Driven Log Analytics, https://github.com/logpai/loghub,[Last Access on 12 Jan 2024] Generate a Boatload of Fake Apache Log Files Very Quickly, https://github.com/kiritbasu/Fake-Apache-Log-Generator, [Last Access on 12 Jan 2024]. Yoshida, H., & Biryukov, A. (2005). Analysis of a SHA-256 variant. In Advances in Cryptology – EUROCRYPT 2005 (pp. 245–260). Springer. https://doi.org/10.1007/11693383_17 Satoshi, Nakamoto . Bitcoin: A peer-to-peer electronic cash system, https://bitcoin.org/bitcoin.pdf, [Last Access on 12 Jan 2024]. Chuvakin, A., Schmidt, K., & Phillips, C. (2013). Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management. Syngress. Kent, K., & Souppaya, M. (2006). Guide to Computer Security Log Management (NIST Special Publication 800-92). National Institute of Standards and Technology (NIST). Barisani, A., & Oldani, D. (2007). Offensive Computing: Understanding Windows, Linux, and UNIX Security. Syngress. Yaga, D., Mell, P., Roby, N., & Scarfone, K. (2018). Blockchain technology overview. National Institute of Standards and Technology (NIST). [https://doi.org/10.6028/NIST.IR.8202](https://doi.org/ J. Dykstra and A. T. Sherman, “Understanding issues in cloud forensics: two hypothetical case studies,” in Proceedings of the Conference on Digital Forensics, Security and Law, 2011, p. 45. Aptive, "Log Injection Attack: Understanding and Mitigating the Risks." [Online]. Available: https://www.aptive.co.uk/blog/log-injection-attack/. [Accessed: Jan. 12, 2024]. Ma, D., & Tsudik, G. (2009). A new approach to secure logging. ACM Transactions on Storage, 5(1), 2:1–2:21. https://doi.org/10.1145/1502777.1502779 Rajebhosale, S. S., & Nikam, M. C. (2019). Development of secured log management system over blockchain technology. International Journal of Cyber Research and Education, 1(1), 38–42. IGI Global. https://doi.org/10.4018/IJCRE.2019010104 Ahmad, A., Saad, M., Bassiouni, M., & Mohaisen, A. (2018). Towards blockchain-driven, secure and transparent audit logs. In Proceedings of the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (pp. 443–448). ACM. https://doi.org/10.1145/3286978.3286985 Xu, G., Yun, F., Xu, S., Yu, Y., Chen, X.-B., & Dong, M. (2023). A blockchain-based log storage model with efficient query. Soft Computing, 27 , 13779–13787. https://doi.org/10.1007/s00500-023-08975-3 Khan, D., Jung, L. T., & Hashmani, M. A. (2020). Scalability in blockchain: Challenges and solutions. In Blockchain Technology: Applications and Challenges (pp. 315–332). Elsevier. https://doi.org/10.1016/B978-0-12-819816-2.00015-0 Shafin, K. M., & Reno, S. (2024). Breaking the blockchain trilemma: A comprehensive consensus mechanism for ensuring security, scalability, and decentralization. IET Software, 2024(1). https://doi.org/10.1049/2024/6874055 Abbas, Z., & Myeong, S. (2024). A comprehensive study of blockchain technology and its role in promoting sustainability and circularity across large-scale industry. Sustainability, 16(10), 4232. https://doi.org/10.3390/su16104232 Sanka, A. I., & Cheung, R. C. C. (2021). A systematic review of blockchain scalability: Issues, solutions, analysis and future research. Journal of Network and Computer Applications, 195, 103232. https://doi.org/10.1016/j.jnca.2021.103232 Alghamdi, T. A., Khalid, R., & Javaid, N. (2024). A survey of blockchain based systems: Scalability issues and solutions, applications and future challenges. IEEE Access, 12, 79626–79651. https://doi.org/10.1109/ACCESS.2024.3408868 U.S. Department of Health & Human Services. (1996). Health Insurance Portability and Accountability Act (HIPAA). Retrieved from https://www.hhs.gov/hipaa/index.html, [Last Accessed on 24 May 2024]. European Union. (2016). General Data Protection Regulation (GDPR). Retrieved from https://eur-lex.europa.eu/eli/reg/2016/679/oj, [Last Accessed on 24 May 2024]. Benet, J. (2014). IPFS - Content Addressed, Versioned, P2P File System. arXiv:1407.3561. DOI: 10.48550/arXiv.1407.3561. National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)," Federal Information Processing Standards Publication 180-4 (FIPS PUB 180-4), 2015. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.180-4. Ethereum Foundation, Solidity: High-Level Language for Smart Contracts , 2024. [Online]. Available: https://soliditylang.org. V. Buterin, "Proof of Authority Chains," Ethereum Foundation, 2017. [Online]. Available: https://github.com/ethereum/EIPs/issues/225. "Blockchain explorer," Wikipedia, The Free Encyclopedia , Apr. 2024. [Online]. Available: https://en.wikipedia.org/wiki/Blockchain_explorer. Brown, R. G., Carlyle, J., Grigg, I., & Hearn, M. (2016). Corda: An introductory whitepaper. R3 Consortium. Retrieved May 24, 2024, from https://docs.r3.com/en/pdf/corda-introductory-whitepaper.pdf Ethereum Foundation. (n.d.). Introduction to dapps. Retrieved May 24, 2024, from https://ethereum.org/en/developers/docs/dapps/ J.P. Morgan. (n.d.). Quorum blockchain platform. Retrieved May 24, 2024, from https://consensys.net/quorum/ MultiChain . (n.d.). MultiChain: Open platform for building blockchains. Retrieved May 24, 2024, from https://www.multichain.com/ Ripple Labs Inc. (n.d.). Ripple: Real-time gross settlement system, currency exchange and remittance network. Retrieved May 24, 2024, from https://ripple.com/ Zheng, Z., Xie, S., Dai, H., Chen, X., & Wang, H. (2017, June). An overview of blockchain technology: Architecture, consensus, and future trends. In 2017 IEEE International Congress on Big Data (BigData Congress) (pp. 557–564). IEEE. https://doi.org/10.1109/BigDataCongress.2017.85 Elastic. (n.d.). Elasticsearch: Distributed, RESTful search and analytics engine. Retrieved May 24, 2024, from https://www.elastic.co/elasticsearch/ Additional Declarations No competing interests reported. Cite Share Download PDF Status: Under Review Version 1 posted Reviews received at journal 05 Jan, 2026 Reviewers agreed at journal 26 Dec, 2025 Reviewers invited by journal 25 Dec, 2025 Editor assigned by journal 25 Dec, 2025 Submission checks completed at journal 13 Nov, 2025 First submitted to journal 10 Nov, 2025 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-8076476","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":566168365,"identity":"7bf6535f-a48f-46d2-8263-9d25f3da3465","order_by":0,"name":"Md Shariful Islam","email":"","orcid":"","institution":"Bangladesh University of Engineering and Technology","correspondingAuthor":false,"prefix":"","firstName":"Md","middleName":"Shariful","lastName":"Islam","suffix":""},{"id":566168366,"identity":"83cb30bb-8367-47a2-b872-1102c0f26af8","order_by":1,"name":"Mohammad Saifur Rahman","email":"","orcid":"","institution":"Bangladesh University of Engineering and Technology","correspondingAuthor":false,"prefix":"","firstName":"Mohammad","middleName":"Saifur","lastName":"Rahman","suffix":""},{"id":566168372,"identity":"de8e6fc2-ba15-403b-839e-3759118858a3","order_by":2,"name":"M. Sohel Rahman","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA50lEQVRIiWNgGAWjYJACZhDBDyIYG6BCjA3MhLVINkC18BCtxeAAsVp0+88+/FyYY5dnfPz4wweMOw7L2TMwP/zAuMMapxazG+nG0jO3JRebnckxNmA8c9iYh4HNWILxTDoeLWwM0rzbmBO33eBhk2BsO5zYAxRkADJwazl/jPk377b6xM0z2J//AKqs72Fg/4Zfy4E0NqAthxM3SEAMT+Bh4CFgy400NmvebccTZwD9IpF4Jt2w5zBPMYiB12G3ebdVJ/a3H3/44eMOa3n29vaNIAZOLaggAUQwwxijYBSMglEwCsgGAACfUNEDyFBEAAAAAElFTkSuQmCC","orcid":"","institution":"Bangladesh University of Engineering and Technology","correspondingAuthor":true,"prefix":"","firstName":"M.","middleName":"Sohel","lastName":"Rahman","suffix":""}],"badges":[],"createdAt":"2025-11-10 11:38:07","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-8076476/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-8076476/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":99136867,"identity":"74ebb5f9-b708-4a4a-8f2a-e6b0947d9106","added_by":"auto","created_at":"2025-12-29 06:49:34","extension":"docx","order_by":0,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":724816,"visible":true,"origin":"","legend":"","description":"","filename":"LogStampingv1.docx","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/989f3d1ea62dba712085ed70.docx"},{"id":99315417,"identity":"f78d02ec-b33d-4388-8248-3eef6e6d90e9","added_by":"auto","created_at":"2025-12-31 16:26:55","extension":"json","order_by":1,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":5039,"visible":true,"origin":"","legend":"","description":"","filename":"42d394d770b5407a94d08f87d35e1b3d.json","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/02ed2876b62e3a27791aeb76.json"},{"id":99315717,"identity":"70dc06ca-976d-4308-90f2-a7462db0d429","added_by":"auto","created_at":"2025-12-31 16:27:17","extension":"xml","order_by":2,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":150676,"visible":true,"origin":"","legend":"","description":"","filename":"42d394d770b5407a94d08f87d35e1b3d1enriched.xml","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/8c647c25610b341bf86a5406.xml"},{"id":99314770,"identity":"28c2f416-ffe2-4dc4-888f-806ca244b6fe","added_by":"auto","created_at":"2025-12-31 16:23:04","extension":"png","order_by":3,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":44834,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/cf5886f67d39a8e4f768cf6f.png"},{"id":99136878,"identity":"c5abac55-0a01-4f19-abe4-af991970a2f0","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":4,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":198836,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/983c84fc1908c25d1132367c.png"},{"id":99136880,"identity":"aa24e0c9-2917-41f6-a073-9815dbb88077","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":5,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":70720,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage3.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/3609ad875bcbc9c1fda81f58.png"},{"id":99315314,"identity":"e1153275-59b3-4e71-ae60-f9107202a3f9","added_by":"auto","created_at":"2025-12-31 16:26:47","extension":"png","order_by":6,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":94050,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/99ae911a770f62c144932495.png"},{"id":99136885,"identity":"11b8871e-34ec-404a-adbb-bb69126d8d16","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":7,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":78077,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/f3c99b6c29897ce48c1993cd.png"},{"id":99136883,"identity":"58ec74e9-2507-4bf7-a730-65dc48436ea2","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":8,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":140122,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage6.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/6d674fd819b1c62f49254668.png"},{"id":99136881,"identity":"ab231676-d7c8-4a4a-a1af-8dd50506fba3","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":9,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":28135,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage7.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/4c745f67e65371dde5212db8.png"},{"id":99315327,"identity":"c6afc07c-3f4f-49c2-a48c-f50f03df034b","added_by":"auto","created_at":"2025-12-31 16:26:48","extension":"png","order_by":10,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":10282,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/47f8d368fde19959da15da99.png"},{"id":99136875,"identity":"46a5dae1-6867-46a6-aefa-4a80263b25d8","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":11,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":53267,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/ebc59affd55c5901a48b8d3f.png"},{"id":99315692,"identity":"1671651a-fd3c-429c-ad52-81cd9ee22de6","added_by":"auto","created_at":"2025-12-31 16:27:15","extension":"png","order_by":12,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":19014,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage3.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/87cc592a7d300dbeed47bbc1.png"},{"id":99136889,"identity":"801cbd7d-9ae6-4760-8e60-dd5ac09fc7dc","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":13,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":31879,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/769d5cf1e2dda558f88d8bca.png"},{"id":99316872,"identity":"90b5c51b-b455-4f46-a23c-6dab96d27a19","added_by":"auto","created_at":"2025-12-31 16:29:22","extension":"png","order_by":14,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":27023,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/d8b119ad35208ebc577f9e77.png"},{"id":99315440,"identity":"e73f122a-35b8-4736-ab80-eccc6f361563","added_by":"auto","created_at":"2025-12-31 16:26:56","extension":"png","order_by":15,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":49643,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage6.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/370daf13ab086109136fe592.png"},{"id":99136886,"identity":"20f5b3fb-81ac-4ec8-8c52-7424017ca9b4","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":16,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":8177,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage7.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/6a39adc92ac549e6aaad37f7.png"},{"id":99136888,"identity":"9d846d28-cc49-4c89-82f2-d94fcdcafe3f","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"xml","order_by":17,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":149381,"visible":true,"origin":"","legend":"","description":"","filename":"42d394d770b5407a94d08f87d35e1b3d1structuring.xml","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/a6cd55ef65942ea57b3712a2.xml"},{"id":99136887,"identity":"b2ce547d-856a-493e-a257-bde549fb2755","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"html","order_by":18,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":171008,"visible":true,"origin":"","legend":"","description":"","filename":"earlyproof.html","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/2d7089df0c905ef798545f6a.html"},{"id":99136864,"identity":"f385a3f7-5616-4d83-b8e1-1688faf5bb4c","added_by":"auto","created_at":"2025-12-29 06:49:34","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":44834,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eLog ingestion workflow for secure blockchain logging using SHA-256 and group-based entry hashing.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/daa85117cb2742b0281bc14b.png"},{"id":99315093,"identity":"97064039-0556-44fe-b7ba-ea0efbb5f198","added_by":"auto","created_at":"2025-12-31 16:26:19","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":191691,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eVerification workflow that ensures log integrity by grouping original log entries and validating them against trusted records stored on the blockchain to identify any unauthorized modifications.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/b0d45d684af53125b8be7a0f.png"},{"id":99136865,"identity":"0d800cb6-4819-4bcc-8c17-4fb2caf4fb79","added_by":"auto","created_at":"2025-12-29 06:49:34","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":70720,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eEffect of Chunk Size on Storage Efficiency - Comparing Raw vs. Hashed Storage Overhead for 10,000 Log Entries\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage3.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/e839288c624211e6ba2cb0ba.png"},{"id":99136869,"identity":"675804fa-7308-46e1-a1fd-43f51ededae6","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":94050,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eImpact of Chunk Size on Storage Usage for 14 million Log Entries\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/ffa396a6d6bba1b5a7936e44.png"},{"id":99315079,"identity":"ee56cdb7-27a6-46ec-b5aa-9ff1a83d4c09","added_by":"auto","created_at":"2025-12-31 16:26:18","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":78077,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eProcessing Time for Hashed Log Data Decreases Significantly as Chunk Size Increases, Highlighting the Efficiency Gains in Batch-Based Log Handling\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/e2d8b38d29691af1cab22856.png"},{"id":99136872,"identity":"98d1d4a7-9a2c-4b4d-9379-dde835c011f5","added_by":"auto","created_at":"2025-12-29 06:49:35","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":140122,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eImpact of Chunk Size on Storage and Processing; larger chunks significantly reduce both storage overhead and processing duration during log data handling. (14 million Entries)\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage6.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/00bc54c3a0c6eb3453024728.png"},{"id":99315241,"identity":"8461d7fd-7473-4a88-afa0-008362535612","added_by":"auto","created_at":"2025-12-31 16:26:40","extension":"png","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":28135,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eVerification time decreases sharply with larger chunk sizes, dropping from 1,020 minutes at size 1 to just 50 minutes at size 20—demonstrating up to 95% efficiency gain in log verification.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"floatimage7.png","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/f103824e3a4eda8a33bd9cb8.png"},{"id":99323680,"identity":"488d6d1e-d28b-468a-b3ff-c14aa82323f4","added_by":"auto","created_at":"2025-12-31 16:45:52","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":2480544,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-8076476/v1/4c591632-af17-40e5-ab87-bfc6a6956f20.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"LogStamping: A blockchain-based log auditing approach for large-scale systems","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eLog management is crucial for IT operations, providing critical insights for monitoring, troubleshooting, and ensuring compliance. Various IT infrastructure components, including but not limited to servers, firewalls, routers, switches, and individual PCs, typically create log recordings (popularly referred to as \u0026lsquo;logging\u0026rsquo;), particularly when they carry out crucial operations and transactions. Such logs are crucial for determining the trail of illicit actions carried out in such contexts [32, 33, 34]. Thus, these log files are often utilized to audit the computing environment, and they present us with crucial evidence for locating and resolving various incorrect or malicious behaviours that are interfering with the system under consideration and the infrastructure thereof. Even though log data can be useful in many ways, it can also be manipulated [37] to conceal harmful activities or impede the discovery of system vulnerabilities. Therefore, creating a secure and immutable system to store the vast amount of log data is essential to guarantee the integrity and safety of the computing environment.\u003c/p\u003e\n\u003cp\u003eBlockchain [35] is a shared, distributed, immutable ledger that facilitates the process of recording transactions and tracking assets, where an asset may refer to anything of value, both tangible and intangible. For its immutable and other desirable properties, blockchain has been utilized [38, 39, 40] in this context to create tamper-proof log record storage. Unfortunately, the continuously expanding huge log data cannot be handled efficiently by the current blockchain-based solutions [17, 19], which results in massive storage overhead [42, 43, 44, 45, 46] on the participating blockchain nodes, which in turn affects performance severely, sometimes compromising the original goal of integrity as well. While some works use separate off-chain storage to solve the storage scalability problem [15, 17], these works are unable to ensure the confidentiality of log data, thereby compromising a crucial issue [15, 23].\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe adoption of blockchain for log auditing in large-scale systems is hindered by limitations in scalability, performance, and compliance. Traditional blockchain architectures suffer from low throughput and high storage overhead\u0026mdash;storing \u003cem\u003eS\u0026nbsp;\u003c/em\u003eGB of logs across \u003cem\u003eN\u003c/em\u003e nodes results in\u0026nbsp;\u003cimg width=\"36\" height=\"21\" src=\"https://myfiles.space/user_files/58895_8739fc6c57c1c19a/58895_custom_files/img1766989535.gif\" alt=\"image\"\u003e\u0026nbsp;GB of total storage, making it impractical for terabyte-scale, high-frequency environments. Additionally, consensus mechanisms introduce latency, impacting the feasibility of real-time log recording. Current solutions inadequately handle the dynamic and incremental nature of log generation. Many assume that log files are secured at the source when generated, but it fails to address scenarios where logs are continuously appended, altered during transmission, or modified before ingestion. This oversight creates vulnerabilities in log integrity and auditability. Furthermore, waiting time during log generation\u0026mdash;a critical factor in real systems\u0026mdash;is often ignored, leading to unaddressed latency and potential data gaps. Some methods restructure logs for query efficiency at the cost of provenance, original format, and timestamp accuracy, which undermines forensic and compliance objectives. Energy-intensive mechanisms, such as PoW exacerbate inefficiency, and the immutability of blockchain leads to data redundancy and storage overhead, worsening scalability issues.\u003c/p\u003e\n\u003cp\u003eWith this backdrop, this paper proposes a blockchain-based framework for log management that ensures tamper-proof logging, supports real-time processing, and maintains scalability in large-scale distributed environments. By leveraging smart contracts, cryptographic techniques, and a layered architectural design, the framework also prioritizes privacy and efficient recovery mechanisms.\u003c/p\u003e"},{"header":"2. Related Works","content":"\u003cp\u003eThe advancement of log management systems, coupled with their integration into blockchain technology, has marked significant milestones and yielded valuable research contributions. Various blockchain-based approaches have been developed to address similar challenges, with some solutions excelling in storing limited-size critical data [18, 21]. Other blockchain-based systems primarily focus on the storage and querying of logs directly from the blockchain [15, 41]. While each approach is well-suited to its specific use case, none effectively addresses the demands of large-scale systems with massive volumes of log data.\u003c/p\u003e\n\u003cp\u003eTamper-resistant log files are essential in various domains and are mandated by numerous regulatory frameworks and standards, including HIPAA [47], and GDPR [48]. The integrity issue of these files is critical with varying degrees from one domain to another. For example, medical records must be reliable due to their potential life-or-death implications, financial data requires accuracy to maintain trust, and IT security logs are indispensable for detecting security incidents and conducting forensic investigations. A shared characteristic of these use cases is that log files are typically append-only, with new entries continuously added over time as individuals undergo more medical procedures, perform additional financial transactions, or generate further security events.\u003c/p\u003e\n\u003cp\u003eBeyond ensuring integrity, these logs must also ensure high availability to allow users to review and access records as and when needed. They serve crucial roles in fault analysis [1], anomaly detection [2, 3], forensic investigations [36], audits, and other critical processes \u0026nbsp;[4, 10, 11, 12]. During a security breach, attackers often attempt to erase event logs on compromised systems to conceal their activities, underscoring the importance of secure and immutable log storage to preserve critical information and enhance system resilience.\u003c/p\u003e\n\u003cp\u003eOlaf and Esmiralda [4] proposed a centralized log server that can collect and store log records securely. However, this approach is vulnerable due to a single point of failure and lacks efficient query mechanisms. Indrajit et al. [5] introduced a cloud-based log storage system, but issues of trust and data consistency remained, as cloud servers are susceptible to unauthorized access and manipulation. A blockchain-based solution for immutable log storage was proposed in [6] that incorporated hierarchical ledgers to address scalability issues. While promising, the system, LogChain, lacks implementation details, and its API is underdeveloped for production-level deployments. Kumar et al. proposed a high-level design for secure log storage leveraging blockchain and cloud infrastructure [7]. However, the solution lacks details regarding its operational framework, performance evaluation, and query mechanisms.\u003c/p\u003e\n\u003cp\u003eBlockchain has also been explored in the domain of cloud forensics. Liang et al. [8] introduced ProvChain, a blockchain-based architecture for validating cloud data provenance, while Park et al. [9] proposed a data logging and integrity verification system for cloud environments. Both systems focused on cloud data integrity but failed to \u0026nbsp;ensure log data integrity. Moreover, they did not provide a real-time performance analysis. Schneier and Kelsey pioneered cryptographic support for secure logs, emphasizing tamper detection in untrusted machines, laying the groundwork for tamper-proof logging [10]. However, this work lacked scalability, which is \u0026nbsp; essential for large-scale distributed systems.\u003c/p\u003e\n\u003cp\u003eHolt introduced Logcrypt, which enhanced log integrity through forward security and public verification, addressing critical gaps in audit log systems [11]. The major limitation was its dependency on centralized systems, which made it prone to single points of failure. Ahmad et al. presented BlockAudit, leveraging blockchain\u0026rsquo;s immutability for secure and transparent audit logs, showcasing improved security and fault tolerance [12]. A drawback of this approach was its reliance on high storage overhead on-chain, which limited its scalability. Notably, IBM highlighted blockchain\u0026rsquo;s storage challenges, advocating for efficient on-chain and off-chain strategies to handle growing data volumes [13].\u003c/p\u003e\n\u003cp\u003eRakib et al. proposed [14] a MultiChain-based system for storing, querying, and auditing network logs. Their work achieves immutability, confidentiality, and scalability but focuses primarily on timestamp-based queries and does not emphasize real-time applicability to large-scale environments. Ali et al. introduced BCALS [15], a blockchain-based secure log management system tailored for cloud computing, ensuring audit log immutability and trust enhancement. The system\u0026rsquo;s scalability was limited in handling diverse and high-frequency log sources. Furthermore, it transforms the logs before storing them into the blockchain, which creates a crucial concern with regards to the originality of the log. Shekhtman and Waisbard developed EngraveChain [16, 17], which leverages Hyperledger Fabric [27] to provide tamper-proof log storage with encryption for data privacy. However, it lacks efficient query mechanisms and comprehensive performance evaluations, particularly in large-scale systems. Rakib et al. further refined blockchain-enabled scalable network log systems, leveraging IPFS [49] for efficient data management and a robust query mechanism [19]. While it improves scalability as off-chain storage helps reduce on-chain data, the blockchain still maintains transaction metadata, which can lead to scalability concerns as the number of log transactions grows over time.\u003c/p\u003e\n\u003cp\u003eCollectively, these works underscore the potential of blockchain technology to address critical challenges in log management systems, including tamper-proofing, scalability, and privacy. However, challenges related to log confidentiality, real-time processing, and handling large log files remain as research gaps motivating further research and development.\u003c/p\u003e"},{"header":"3. Background","content":"\u003ch2\u003e3.1 Blockchain\u003c/h2\u003e\n\u003cp\u003eA blockchain is a decentralized and distributed ledger technology that securely records transactions across a network of computers. Transactions are grouped into blocks, each cryptographically linked to its predecessor, forming an immutable chain. This structure ensures transparency, security, and tamper-proof storage, making blockchain ideal for applications such as cryptocurrency, supply chain management, and smart contracts. Blockchain\u0026apos;s core features include decentralization, immutability, transparency, and cryptographic security [59], enabling efficient, trustless operations across various industries. \u0026nbsp;Blockchain platforms provide the infrastructure for building, deploying, and managing decentralized systems and applications. They enable recording, validating, and securing data in an immutable, distributed ledger.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eSeveral blockchain platforms are popular at the industry scale due to their unique capabilities and applications. For instance, Ethereum [26]\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003eis well-suited for private and consortium blockchains in enterprises, leveraging the Proof of Authority [52] consensus for fast block creation without mining. It supports smart contracts and decentralized applications (dApps) [55] within Ethereum\u0026rsquo;s robust ecosystem. Hyperledger Fabric\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e[27], another notable platform, is widely used in supply chain, finance, and healthcare industries. Its modular, permissioned architecture with private channels allows high customization for specific business workflows. Similarly, Corda [54] is designed for financial services and trade finance, featuring a peer-to-peer transaction model that ensures privacy and compliance with regulatory requirements.\u003c/p\u003e\n\u003cp\u003eQuorum [56], a blockchain platform forked from Ethereum, is tailored for banking and asset management, offering enhanced privacy and compatibility with Ethereum smart contracts. MultiChain [57], on the other hand, is designed for private networks and secure data sharing, providing fast deployment and built-in permissions management, making it ideal for controlled enterprise environments. Lastly, Ripple (XRP Ledger) [58] focuses on cross-border payments, delivering near-instant transactions and scalable performance for financial institutions. These platforms collectively address diverse enterprise needs, offering strong privacy, scalability, and customizability to support a wide range of business applications, from secure data sharing to financial services and decentralized asset management.\u003c/p\u003e\n\u003ch2\u003e3.2 Smart contract\u003c/h2\u003e\n\u003cp\u003eA smart contract is a self-executing program stored on a blockchain, with the terms and logic encoded directly into its code. The contract automatically executes when predefined conditions are met, ensuring tamper-proof, transparent, and trustless operations without intermediaries. Key features include automation, immutability, cryptographic security, and decentralized execution. Smart contracts are extensively used in financial transactions, supply chain management, and decentralized applications (dApps), transforming how agreements are enforced securely and efficiently.\u003c/p\u003e\n\u003ch2\u003e3.3 Consensus algorithms\u003c/h2\u003e\n\u003cp\u003eA consensus algorithm is a fundamental mechanism in blockchain networks that ensures all participants (nodes) agree on the validity of transactions and the current state of the ledger. It resolves trust issues in decentralized systems by providing a unified agreement among distributed nodes. \u003cstrong\u003eTable 1\u003c/strong\u003e compares three widely used consensus algorithms\u0026mdash;PoW, PoA, and BFT\u0026mdash;highlighting their trade-offs in terms of security, scalability, decentralization, and efficiency.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cem\u003eTable 1\u003c/em\u003e\u003c/strong\u003e\u003cem\u003e\u0026nbsp;: Comparison of PoW, PoA, and BFT consensus mechanisms based on key features like security, scalability, energy efficiency, and use cases\u003c/em\u003e\u003c/p\u003e\n\u003cdiv align=\"\"\u003e\n \u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"638\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eFeature\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eProof of Work (PoW)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eProof of Authority (PoA)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eByzantine Fault Tolerance (BFT)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eSecurity\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eEnergy Efficiency\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eLow\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eScalability\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eLow\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDecentralization\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eFault Tolerance\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eMedium\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eLow\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eHigh\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eUse Cases\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 145px;\"\u003e\n \u003cp\u003eBitcoin, Litecoin\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 147px;\"\u003e\n \u003cp\u003eVeChain, Rinkeby\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 193px;\"\u003e\n \u003cp\u003eHyperledger, Tendermint\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003ch2\u003e3.4 InterPlanetary File System (IPFS)\u003c/h2\u003e\n\u003cp\u003eThe InterPlanetary File System (IPFS) [49] is a decentralized, peer-to-peer file storage and sharing protocol designed to create a more open and resilient web. Unlike traditional centralized systems, IPFS uses content-addressing to identify files by their unique cryptographic hash rather than their location. This ensures data integrity and allows files to be distributed across multiple nodes globally, enhancing reliability and resistance to censorship. IPFS is commonly used for storing and sharing large datasets, decentralized applications (dApps), and blockchain-related data, providing an efficient, secure, and scalable alternative to traditional file storage systems\u003c/p\u003e\n\u003ch2\u003e3.5 Elasticsearch\u0026nbsp;\u003c/h2\u003e\n\u003cp\u003eElasticsearch [60] is a distributed, open-source search and analytics engine built on Apache Lucene. It provides fast and scalable full-text search, data indexing, and real-time data exploration, making it ideal for applications like log analysis, business intelligence, and security monitoring. Its ability to handle large datasets efficiently makes it a popular choice for enterprise solutions.\u003c/p\u003e"},{"header":"4. Methods","content":"\u003cp\u003eIn this section, we describe our research and experimental design in detail, discussing the rationale behind our design choices. We use the following technologies in our research:\u003c/p\u003e\n\u003col start=\"1\" type=\"a\"\u003e\n \u003cli\u003eEthereum (Proof of Authority)\u003c/li\u003e\n \u003cli\u003eSolidity for smart contracts\u003c/li\u003e\n \u003cli\u003eIPFS for off-chain storage\u003c/li\u003e\n \u003cli\u003eElasticsearch for search and analytics\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e4.1 Ethereum as our Blockchain Platform\u003c/h2\u003e\n\u003cp\u003eEthereum is one of the most widely used and versatile blockchain platforms, making it an excellent choice for developing secure, scalable, and decentralized applications. Its robust ecosystem offers extensive developer tools, active community support, and compatibility with smart contracts via the Ethereum Virtual Machine (EVM). These attributes make Ethereum particularly suited for enterprise-grade solutions and research applications.\u003c/p\u003e\n\u003ch2\u003e4.2 Smart contracts with Ethereum (PoA)\u003c/h2\u003e\n\u003cp\u003eThe performance of a blockchain platform mostly depends on the consensus algorithm employed therein. The combination of Ethereum\u0026apos;s versatile blockchain capabilities and PoA\u0026apos;s high efficiency creates an optimized environment for scalable and secure applications. This configuration ensures rapid transaction processing, reduced operational costs, and robust smart contract execution, making it a preferred choice for enterprise and research-focused projects. We use Solidity with Ethereum (PoA) for its native EVM compatibility, enabling efficient, secure, and low-latency execution of smart contracts in a permissioned environment.\u003c/p\u003e\n\u003ch2\u003e4.3 IPFS for Off-Chain Storage\u003c/h2\u003e\n\u003cp\u003eOnce a log file is verified using our tool and no longer changes, it is stored in the InterPlanetary File System (IPFS) to make it tamper-proof and persistently available. IPFS uses a unique hash to identify each file, ensuring its integrity. We then record that hash on the blockchain, creating a lightweight and verifiable audit trail. A similar approach was adopted by Rakib et al. [13], showcasing the use of IPFS for securely storing finalized logs in blockchain-based systems. However, their solution is confined to offline or pre-generated logs and does not address the challenges of real-time log generation, ingestion, or on-the-fly verification\u0026mdash;key requirements for dynamic and continuously operating environments.\u003c/p\u003e\n\u003ch2\u003e4.4 Elasticsearch for Search and Analytics\u003c/h2\u003e\n\u003cp\u003eQuerying logs directly from the blockchain is slow and not suitable for large-scale systems. To solve this, we use Elasticsearch for fast and efficient access to logs after they are verified and stored in IPFS. Finalized logs are indexed, making it easy to search, filter, and analyze them quickly. This setup keeps integrity checks handled by the blockchain and IPFS, while Elasticsearch ensures fast performance for tasks like audits, anomaly detection, and compliance.\u003c/p\u003e\n\u003ch2\u003e4.5 Data Model\u003c/h2\u003e\n\u003cp\u003eIn this study, we focus on plain-text logs, where each log entry follows a standardized format to ensure uniformity and compatibility. A typical log entry includes:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eTimestamp\u003c/strong\u003e: Precise date and time with nanosecond granularity to maintain accuracy.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eLog Level\u003c/strong\u003e: Indicates the severity or priority of the log (e.g., INFO, DEBUG, ERROR).\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eMachine/Service Name\u003c/strong\u003e: Specifies the source of the log for identification.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eLog Details\u003c/strong\u003e: Provides a description or message for the logged event.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis standardized structure enables efficient parsing, storage, and analysis of log data, crucial for large-scale systems.\u003c/p\u003e\n\u003ch2\u003e4.6 Data Collection\u003c/h2\u003e\n\u003cp\u003eTo comprehensively test the system\u0026apos;s performance, both offline and real-time, we utilize three distinct sources of log data as follows.\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003e\u003cstrong\u003eOnline Archives\u003c/strong\u003e: We have collected datasets from LogPai [13], which contain diverse log samples from large-scale systems and data centers. These datasets allow us to evaluate the system\u0026apos;s offline behavior with substantial volumes of data.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eSynthetic Log Generators\u003c/strong\u003e: We have used tools like Fake-Apache-Log-Generator [14] to generate human-readable, randomized logs. These enable us to simulate diverse scenarios and test the system\u0026apos;s real-time data handling capabilities.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eCustom Log Generator\u003c/strong\u003e: A tailored log generation tool has been developed to create logs with specific patterns, formats, or parameters. This process ensures flexibility for testing system behaviors under customized conditions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eBy combining these datasets, we aim to rigorously evaluate the system\u0026apos;s robustness, scalability, and real-time processing capabilities across a range of scenarios and data volumes.\u003c/p\u003e"},{"header":"5. Main Approach of LogStamping","content":"\u003cp\u003eWe developed our system with three major components, they are:\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003eIngestion Tool,\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eBlockchain Platform,\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eand Integrity Verification Tool.\u0026nbsp;\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIn what follows, we briefly describe these components.\u003c/p\u003e\n\u003ch2\u003e5.1 The Ingestion Tool\u003c/h2\u003e\n\u003cp\u003eThe Python-based log ingestion tool is designed to provide a scalable and secure solution for managing log data in large-scale systems. By integrating blockchain technology, the tool ensures the immutability, traceability, and auditability of log entries. It continuously monitors log files for new entries, generates cryptographic hashes (using \u003cstrong\u003eSHA256 [50]\u003c/strong\u003e) for individual or a group of \u003cem\u003en\u003c/em\u003e log lines, where \u003cem\u003en\u003c/em\u003e is any predefined number of log lines, and records these hashes on the blockchain. This approach ensures that log data remains tamper-proof and can be reliably audited for compliance and forensic purposes if and when required. The tool is particularly suited for high-volume environments, such as data centers and distributed systems, where traditional log management systems often struggle to maintain security and scalability. The following components make up the modular architecture of the log ingestion tool:\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eLog Collector\u003c/strong\u003e: Gathers logs from various sources.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eParser and Formatter\u003c/strong\u003e: Standardizes log formats.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eBlockchain Interface\u003c/strong\u003e: Interacts with the blockchain to store logs immutably.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eError Handling Module\u003c/strong\u003e: Manages exceptions and logging failures.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 624px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAlgorithm 1\u003c/strong\u003e:\u003cstrong\u003e\u0026nbsp;MonitorAndIngestLogs\u003c/strong\u003e\u003cbr\u003e\u003cstrong\u003eInput\u003c/strong\u003e: logFile, groupSize, timeout\u003cbr\u003e\u003cstrong\u003eOutput\u003c/strong\u003e: Hashes stored in blockchain for log file integrity\u003cbr\u003e\u0026nbsp;\u003cbr\u003e1. Initialize logGroup \u0026larr;\u0026nbsp;\u0026empty;\u003cbr\u003e2. Initialize startTime \u0026larr; CURRENT_TIME()\u003cbr\u003e\u0026nbsp;\u003cbr\u003e3. while True do\u003cbr\u003e4. Wait for new log entry in logFile\u003cbr\u003e5. if NEW\u003cem\u003e_ENTRY_\u003c/em\u003eEXISTS(logFile) then\u003cbr\u003e6. Append log entry to logGroup\u003cbr\u003e7. end if\u003cbr\u003e\u0026nbsp;\u003cbr\u003e8. if |logGroup| \u0026ge; groupSize or (CURRENT_TIME() \u0026minus; startTime) \u0026ge; timeout then\u003cbr\u003e9. hashValue \u0026larr; GenerateSHA256Hash(logGroup)\u003cbr\u003e10. WriteToBlockchain(hashValue)\u003cbr\u003e11. logGroup \u0026larr;\u0026nbsp;\u0026empty;\u003cbr\u003e12. startTime \u0026larr; CURRENT_TIME()\u003cbr\u003e13. end if\u003cbr\u003e14. end while\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 624px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAlgorithm 2: GenerateSHA256Hash\u003c/strong\u003e\u003cbr\u003e\u003cstrong\u003eInput\u003c/strong\u003e: logGroup\u003cbr\u003e\u003cstrong\u003eOutput\u003c/strong\u003e: Hash value of log group\u003cbr\u003e\u0026nbsp;\u003cbr\u003e1. Concatenate all log entries in logGroup into a single string\u003cbr\u003e2. return SHA256\u003cem\u003e_HASH_\u003c/em\u003eOF_STRING(string)\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 624px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAlgorithm 3: WriteToBlockchain\u003c/strong\u003e\u003cbr\u003e\u003cstrong\u003eInput\u003c/strong\u003e: hashValue\u003cbr\u003e\u003cstrong\u003eOutput\u003c/strong\u003e: hashValue stored in blockchain\u003cbr\u003e\u0026nbsp;\u003cbr\u003e\u0026nbsp;1. Connect to blockchain\u003cbr\u003e\u0026nbsp;2. Store hashValue in blockchain\u003cbr\u003e\u0026nbsp;3. return SUCCESS\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eThe tool works by executing the following steps. \u003cstrong\u003eFigure 1\u003c/strong\u003e illustrates the described log ingestion process.\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003e\u003cstrong\u003eMonitoring Log Entries\u003c/strong\u003e: The log ingestion tool continuously monitors the target log file for new entries, processing them line by line.\u003c/li\u003e\n\u003c/ol\u003e\n\u003col start=\"2\"\u003e\n \u003cli\u003e\u003cstrong\u003eGrouping Log Lines\u003c/strong\u003e: Instead of sending each log line individually, the tool groups multiple log lines to form a chunk based on pre-configured parameters (e.g., number of lines (\u003cem\u003en)\u003c/em\u003e, time intervals \u003cem\u003e(t)\u003c/em\u003e). Here, Algorithm 1 explains the complete process.\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eTimeout Handling\u003c/strong\u003e:\u003col style=\"list-style-type: lower-roman;\"\u003e\n \u003cli\u003eIf the chunk is incomplete (e.g., insufficient new log entries), the tool waits for a pre-configured timeout \u003cem\u003e(t)\u003c/em\u003e period.\u003c/li\u003e\n \u003cli\u003eAfter the timeout, the hash of the partial group is computed and written to the blockchain to secure any unrecorded entries.\u003c/li\u003e\n \u003c/ol\u003e\n \u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eDynamic Group Capacity\u003c/strong\u003e:\u003col style=\"list-style-type: lower-roman;\"\u003e\n \u003cli\u003eThe size of the groups is variable, dynamically adjusting based on the frequency of log entries in the target log file.\u003c/li\u003e\n \u003c/ol\u003e\n \u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n\u003c/ol\u003e\n\u003col start=\"3\" type=\"1\"\u003e\n \u003cli\u003e\u003cstrong\u003eHash Generation\u003c/strong\u003e: Once a group is formed, the tool computes SHA256\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003ehash for the grouped log lines, creating a unique digital fingerprint (Algorithm 2).\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eWriting to Blockchain\u003c/strong\u003e: The computed hash is immediately written into the blockchain, ensuring the immutability and integrity of the grouped logs (Algorithm 3).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e5.2 The Blockchain Platform\u003c/h2\u003e\n\u003cp\u003eWe deployed Ethereum [26] as the private blockchain platform for its ease of setup, maintenance, and scalability. To improve efficiency as per Figure 1, we adopted the Proof of Authority (PoA) consensus algorithm [52], which enables rapid block creation without the need for mining. Custom smart contracts were developed in Solidity [51], supported by additional tools, such as Blockchain Explorer [53], for enhanced functionality. The smart contract\u0026apos;s functionalities are in Algorithm 4.\u0026nbsp;\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 624px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eAlgorithm 4: LogStorage Smart Contract\u003c/strong\u003e\u003cbr\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e: To store and retrieve log hashes securely on the blockchain.\u003cbr\u003e\u003cstrong\u003eInput\u003c/strong\u003e: logHash (string) - The cryptographic hash of a log group.\u003cbr\u003e\u003cstrong\u003eOutput\u003c/strong\u003e: Immutable storage and retrieval of log hashes.\u003cbr\u003e\u0026nbsp;\u003cbr\u003e\u003cstrong\u003eState Variables:\u003c/strong\u003e\u003cbr\u003e1. logHashes: A mapping (integer \u0026rarr; string) to store log hashes indexed by their count.\u003cbr\u003e2. logCount: An unsigned integer representing the total number of stored log hashes.\u003cbr\u003e\u0026nbsp;\u003cbr\u003e\u003cstrong\u003eFunctions:\u003cbr\u003e\u0026nbsp;\u003c/strong\u003e\u003cbr\u003e1. Function: storeLogHash\u003cbr\u003e\u0026nbsp; \u0026nbsp; Input: logHash (string) - The hash to be stored.\u003cbr\u003e\u0026nbsp; \u0026nbsp; Output: Updates logHashes and increments logCount.\u003cbr\u003e\u0026nbsp;\u003cbr\u003e\u0026nbsp; \u0026nbsp; Procedure:\u003cbr\u003e\u0026nbsp; \u0026nbsp; 1. logHashes[logCount] \u0026larr; logHash\u003cbr\u003e\u0026nbsp; \u0026nbsp; 2. logCount \u0026larr; logCount + 1\u003cbr\u003e\u0026nbsp;\u003cbr\u003e2. Function: getLogHash\u003cbr\u003e\u0026nbsp; \u0026nbsp; Input: index (unsigned integer) - The index of the log hash to retrieve.\u003cbr\u003e\u0026nbsp; \u0026nbsp; Output: The log hash stored at the specified index.\u003cbr\u003e\u0026nbsp;\u003cbr\u003e\u0026nbsp; \u0026nbsp; Procedure:\u003cbr\u003e\u0026nbsp; \u0026nbsp; 1. return logHashes[index]\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eThe Integrity Verification Tool\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eVerification tools ensure the integrity and authenticity of log files by detecting tampering or modifications. Their process logs by grouping entries based on predefined parameters, computing cryptographic hashes using SHA256, and verifying these hashes against blockchain records. Using timestamps from log entries, they align verification with real-world events. Optionally, verified logs can be archived in IPFS for immutability or indexed in ElasticSearch for efficient querying. These tools are vital for audits, forensic investigations, and maintaining trust in system logs.\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\"\u003e\n \u003cp\u003e\u003cstrong\u003eAlgorithm 5: VerifyLogIntegrityWithTimestamps\u003c/strong\u003e\u003c/p\u003e\n \u003cp\u003e\u003cstrong\u003eInput\u003c/strong\u003e: logFile, groupParameters (maxLines, maxWaitTime), blockchain, ipfs (optional), elasticSearch (optional)\u003cbr\u003e\u003cstrong\u003eOutput\u003c/strong\u003e: Verification status of log integrity\u003cbr\u003e\u0026nbsp;\u003cbr\u003e1. Initialize logGroup \u0026larr;\u0026nbsp;\u0026empty;\u003cbr\u003e2. Initialize allHashesValid \u0026larr; TRUE\u003cbr\u003e3. Initialize groupStartTime \u0026larr; NULL\u003cbr\u003e4. Initialize groupEndTime \u0026larr; NULL\u003cbr\u003e\u0026nbsp;\u003cbr\u003e5.\u0026nbsp;\u003cstrong\u003eOpen\u003c/strong\u003e logFile for reading\u003cbr\u003e6.\u0026nbsp;\u003cstrong\u003ewhile\u003c/strong\u003e not EOF(logFile) do\u003cbr\u003e7. Read logLine from logFile\u003cbr\u003e8. Append logLine to logGroup\u003cbr\u003e9. Extract timestamp from logLine\u003cbr\u003e\u0026nbsp;\u003cbr\u003e10. if groupStartTime = NULL then\u003cbr\u003e11. groupStartTime \u0026larr; timestamp\u003cbr\u003e12. end if\u003cbr\u003e13. groupEndTime \u0026larr; timestamp\u003cbr\u003e\u0026nbsp;\u003cbr\u003e14. if |logGroup| \u0026ge; groupParameters.maxLines or (groupEndTime \u0026minus; groupStartTime) \u0026ge; groupParameters.maxWaitTime then\u003cbr\u003e15. hashValue \u0026larr; ComputeHash(logGroup)\u003cbr\u003e16. isValid \u0026larr; QueryBlockchain(hashValue, blockchain)\u003cbr\u003e\u0026nbsp;\u003cbr\u003e17. if isValid = FALSE then\u003cbr\u003e18. allHashesValid \u0026larr; FALSE\u003cbr\u003e19. Print \u0026quot;Tampered group detected:\u0026quot;\u003cbr\u003e20. end if\u003cbr\u003e\u0026nbsp;\u003cbr\u003e21. logGroup \u0026larr;\u0026nbsp;\u0026empty;\u003cbr\u003e22. groupStartTime \u0026larr; NULL\u003cbr\u003e23. groupEndTime \u0026larr; NULL\u003cbr\u003e24. end if\u003cbr\u003e25. \u003cstrong\u003eend while\u003c/strong\u003e\u003cbr\u003e\u0026nbsp;\u003cbr\u003e26. if logGroup \u0026ne;\u0026nbsp;\u0026empty;\u0026nbsp;then\u003cbr\u003e27. hashValue \u0026larr; ComputeHash(logGroup)\u003cbr\u003e28. isValid \u0026larr; QueryBlockchain(hashValue, blockchain)\u003cbr\u003e\u0026nbsp;\u003cbr\u003e29. if isValid = FALSE then\u003cbr\u003e30. allHashesValid \u0026larr; FALSE\u003cbr\u003e31. Print \u0026quot;Tampered group detected:\u0026quot;, logGroup\u003cbr\u003e32. end if\u003cbr\u003e33. end if\u003cbr\u003e\u0026nbsp;\u003cbr\u003e34. if allHashesValid = TRUE then\u003cbr\u003e35. Print \u0026quot;Log file is intact\u0026quot;\u003cbr\u003e36. if ipfs \u0026ne; NULL then\u003cbr\u003e37. ArchiveToIPFS(logFile)\u003cbr\u003e38. end if\u003cbr\u003e39. if elasticSearch \u0026ne; NULL then\u003cbr\u003e40. StoreInElasticSearch(logFile)\u003cbr\u003e41. end if\u003cbr\u003e42. else\u003cbr\u003e43. Print \u0026quot;Log file has been modified\u0026quot;\u003cbr\u003e44. end if\u003c/p\u003e\n \u003cp\u003e\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e\u0026nbsp;\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eThe tool works based on Algorithm 5 by executing the following steps. \u003cstrong\u003eFigure 2\u003c/strong\u003e illustrates the log verification process.\u003c/p\u003e\n\u003col start=\"1\" type=\"1\"\u003e\n \u003cli\u003e\u003cstrong\u003eLog Grouping Based on Time and Size:\u0026nbsp;\u003c/strong\u003eThe algorithm reads an existing log file and groups entries based on two conditions: a maximum number of lines (\u003cstrong\u003emaxLines\u003c/strong\u003e) or a maximum time window (\u003cstrong\u003emaxWaitTime\u003c/strong\u003e). Each entry is added to the current group, and timestamps are used to determine the time span (Line 14).\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eConditional Group Finalization:\u003c/strong\u003e When either condition is met, the current group is finalized for integrity verification (Lines 14-20). This approach ensures consistent and adaptive log grouping without requiring real-time monitoring.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eHash Computation and Blockchain Verification:\u0026nbsp;\u003c/strong\u003eFor every completed group - \u0026nbsp;\u003c/li\u003e\n\u003c/ol\u003e\n\u003cul\u003e\n \u003cli\u003eA SHA-256 hash is computed from the grouped entries \u0026nbsp;\u003cstrong\u003e(\u003c/strong\u003eLine 15, 27\u003cstrong\u003e)\u003c/strong\u003e.\u003c/li\u003e\n \u003cli\u003eThe hash is checked against blockchain records \u003cstrong\u003e(\u003c/strong\u003eLines 34-44\u003cstrong\u003e)\u003c/strong\u003e.\u003cul\u003e\n \u003cli\u003e\u003cstrong\u003eMatch found:\u003c/strong\u003e Group is confirmed intact.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eNo match:\u003c/strong\u003e Group is flagged as tampered.\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n\u003c/ul\u003e\n\u003col start=\"4\" type=\"1\"\u003e\n \u003cli\u003e\u003cstrong\u003eHandling Remaining Entries:\u0026nbsp;\u003c/strong\u003eAfter processing all log lines, any incomplete group is also hashed and verified to ensure no entries are skipped (Lines 26-33).\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eOptional Steps:\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cul class=\"decimal_type\"\u003e\n \u003cli\u003e\u003cstrong\u003eIPFS Archival:\u003c/strong\u003e Verified log files can be archived in IPFS to ensure long-term immutability.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eElasticsearch Indexing:\u003c/strong\u003e Logs can be indexed in Elasticsearch for fast retrieval and advanced search capabilities.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e5.3 Handling log files in large scale systems\u003c/h2\u003e\n\u003cp\u003eEfficient log management in large-scale systems relies on robust strategies for categorization, traceability, and organization. A widely adopted approach is the use of structured naming patterns for log files, incorporating base names dynamically configured with details, such as timestamps, system identifiers, or unique indices. This method ensures better organization, simplified retrieval, and improved log file management.\u003c/p\u003e\n\u003cp\u003eCommon log generation methods include time-based, size-based, index-based, event-based, chunk-based, hybrid (time + size), and distributed approaches. These methods segment logs by criteria, such as time, size, events, indices, or sources, creating unique file names that often include timestamp fields for each entry.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eOur system employs a hybrid approach (i.e., a combination of chunk-based and time-based approaches) to process real-time logs into the blockchain, leveraging standardized log generation patterns. The chunk-based approach groups logs by a fixed number of entries, ideal for high-volume systems to optimize performance and reduce processing overhead. On the other hand, the time-based approach groups logs by fixed time intervals, ensuring timely processing and enhanced security in systems with irregular log generation. Hybrid approach, as the name indicates, combines both chunk size and time interval conditions, finalizing log groups when either threshold is met for balanced efficiency and flexibility. This methodology ensures scalable, flexible, and reliable management practices optimized for real-time operations in large-scale systems.\u003c/p\u003e\n\u003cp\u003eTo elaborate, in this approach, logs are grouped based on two criteria: a predefined maximum chunk size (number of entries) and a predefined time interval (e.g., seconds or minutes). A log group is finalized and processed as soon as either of these conditions are met, ensuring timeliness and scalability. This dual criterion prevents excessive waiting for logs to fill a chunk while avoiding overloading the system during high activity periods. Once a group is complete, a cryptographic hash is computed and stored on the blockchain, ensuring the integrity and traceability of the logs. The hybrid approach also allows dynamic adjustment of chunk size and time intervals, enabling the system to adapt to changes in log generation rates and workloads. By combining the strengths of both methods, the hybrid approach reduces tampering risks, optimizes resource usage, and ensures timely log processing, making it ideal for large-scale, high-frequency systems.\u003c/p\u003e\n\u003ch2\u003e5.4 Log Archiving Using Off-Chain\u003c/h2\u003e\n\u003cp\u003eIn this approach, logs are periodically archived off-chain after the ingestion process for a specific log file is complete and no additional entries are expected. Once a log file is marked as complete, the verification tool continuously monitors it to ensure there are no alterations or tampering. If the verification tool confirms the file\u0026rsquo;s integrity, the entire log file is encrypted using a symmetric key to enhance security and then archived in IPFS (InterPlanetary File System). This ensures that the archived file is both immutable and secure.\u003c/p\u003e\n\u003cp\u003eThe archiving process is designed to adapt to the log generation strategy. For instance, if the strategy is time-based, the system will trigger the archiving process at regular time intervals, ensuring an encrypted and immutable copy of the original log file is maintained. This approach is beneficial for log recovery and for pinpointing specific lines where modifications might have occurred. Alternatively, strategies such as size-based or index-based log generation are also supported. Regardless of the strategy, the archiving process remains consistent, ensuring securely stored logs that are readily available for verification and recovery.\u003c/p\u003e\n\u003cp\u003eBy encrypting the original file before storing it in IPFS, this off-chain archiving approach maintains log integrity and enhances confidentiality. This method provides a robust mechanism for safeguarding logs, supporting flexible log generation strategies, and ensuring immutable, tamper-proof, and secure records.\u003c/p\u003e\n\u003ch2\u003e5.5 Leveraging Elasticsearch for Efficient Log Search and Audit\u0026nbsp;\u003c/h2\u003e\n\u003cp\u003eSearching data directly on a blockchain is not optimal, particularly for large-scale log files. Large data storage in a distributed manner requires a significant amount of storage capacity. Blockchain\u0026rsquo;s inherent design prioritizes immutability and security but lacks the performance capabilities required for efficient data retrieval, especially for unstructured data. To address this limitation, industry-standard tools like Elasticsearch [60] are a better fit for full-text search and analysis. Elasticsearch is known for its high performance and scalability, making it ideal for handling large datasets and conducting fast, precise searches.\u003c/p\u003e\n\u003cp\u003eIn our system, we utilized Elasticsearch for storing and querying logs after their integrity was verified by the verification tool. Logs are stored in chunks, with each chunk containing the following items.\u003c/p\u003e\n\u003col start=\"1\" type=\"1\"\u003e\n \u003cli\u003e\u003cstrong\u003eCalculated Hash\u003c/strong\u003e: Ensuring that data integrity is maintained and verifiable.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eRaw Log Data\u003c/strong\u003e: Providing unstructured log content for search and analysis.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eChunk Metadata\u003c/strong\u003e: Including the hash of the chunk and its associated log data for additional traceability.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFor logs originating from IPFS (InterPlanetary File System), Elasticsearch acts as a complementary storage solution. IPFS ensures the integrity, availability, and immutability of the log files, while Elasticsearch facilitates efficient full-text search and audit processes. This dual approach enhances both data security and retrieval performance.\u003c/p\u003e\n\u003cp\u003eThe primary purpose of Elasticsearch in this system is to support forensic and auditing operations. By enabling fast and accurate searches across large datasets, Elasticsearch simplifies the task of finding specific log entries, even within unstructured data. This approach combines the security of blockchain and IPFS with the performance capabilities of Elasticsearch, creating a robust solution for log management in large-scale systems.\u003c/p\u003e"},{"header":"6. Experimental setup","content":"\u003ch2\u003e6.1 Hardware Requirements\u003c/h2\u003e\n\u003cp\u003eFor the implementation of our system, we configured three identical nodes with the following hardware specifications:\u003c/p\u003e\n\u003cul class=\"decimal_type\"\u003e\n \u003cli\u003e\u003cstrong\u003eProcessor\u003c/strong\u003e: 4 vCPUs\u0026nbsp;\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eMemory (RAM)\u003c/strong\u003e: 8 GB\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eStorage\u003c/strong\u003e: 200 GB\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eOperating System: Ubuntu\u003c/strong\u003e 22.04 LTS\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese nodes are uniformly configured to ensure consistent performance across the blockchain network. This identical setup minimizes variations in processing and storage.\u003c/p\u003e\n\u003ch2\u003e6.2 Datasets\u003c/h2\u003e\n\u003cp\u003eFor the evaluation of our system, we utilized two distinct datasets to assess performance under varying log volumes:\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003e\u003cstrong\u003eSmall Dataset\u003c/strong\u003e:\u003col style=\"list-style-type: lower-alpha;\"\u003e\n \u003cli\u003e\u003cstrong\u003eSize\u003c/strong\u003e: 10,000 log lines\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e: Used to evaluate the correctness of our proposed model.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eDatasource\u003c/strong\u003e: LogPai [13]\u003c/li\u003e\n \u003c/ol\u003e\n \u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eLarge Dataset\u003c/strong\u003e:\u003col style=\"list-style-type: lower-alpha;\"\u003e\n \u003cli\u003e\u003cstrong\u003eSize\u003c/strong\u003e: 14 million log lines (~1.3 GB)\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e: Used to test the system\u0026apos;s scalability and robustness in handling large-scale log data efficiently.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eDataSource\u003c/strong\u003e: \u0026nbsp;Fake-Apache-Log-Generator [14] and our custom log generator\u003c/li\u003e\n \u003c/ol\u003e\n \u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThese datasets provided comprehensive insights into the system\u0026rsquo;s performance across both small-scale and large-scale use cases, ensuring its suitability for diverse operational requirements.\u003c/p\u003e\n\u003ch2\u003e6.3 Tools\u003c/h2\u003e\n\u003cp\u003eWe use the following tools in our experiments:\u003c/p\u003e\n\u003cul class=\"decimal_type\"\u003e\n \u003cli\u003e\u003cstrong\u003ePython:\u003c/strong\u003e Core language for implementing log processing, verification logic, and system integration.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eweb3.py:\u003c/strong\u003e Python library for interacting with Ethereum-compatible blockchains, handling smart contract interactions and transactions.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eweb3.js:\u003c/strong\u003e JavaScript library for blockchain communication from web or Node.js applications.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eGeth:\u003c/strong\u003e Go Ethereum client used to run a full Ethereum node and interface with the blockchain.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eIPFS CLI / API:\u003c/strong\u003e Tools for decentralized storage and retrieval of verified log files.\u003c/li\u003e\n \u003cli\u003e\u003cstrong\u003eElasticsearch:\u003c/strong\u003e Engine for indexing and querying verified logs efficiently.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e6.4 Analysis\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eSecurity\u003c/strong\u003e: The proposed model incorporates robust security measures to ensure data integrity and protection. By leveraging the Proof of Authority (PoA) consensus algorithm, it ensures that only trusted, pre-authorized nodes are responsible for block creation, minimizing the risk of unauthorized activity. Furthermore, the ingestion tool operates within a secure, private network, restricting access exclusively to verified entities. These combined mechanisms create a highly secure and reliable framework for log management.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eScalability\u003c/strong\u003e: The proposed system enhances the scalability of blockchain networks by significantly reducing the number of network calls through the implementation of chunk-based processing. This approach minimizes the frequency of transactions, making the system more efficient and suitable for integration with other services or applications. Additionally, the reduced storage requirements decrease the input/output (I/O) overhead on blockchain servers, thereby improving processing efficiency and overall system performance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePrivacy\u003c/strong\u003e: We have implemented robust privacy measures in our proposed model to ensure the highest level of data security. Notably, no raw log data is stored directly on the blockchain, and it is impossible to reconstruct raw data from the information stored in the blockchain. Furthermore, the data stored in the InterPlanetary File System (IPFS) is encrypted before being transmitted, adding an additional layer of security. This comprehensive approach ensures that privacy is maintained at an optimal level, adhering to best practices for secure and private data management.\u003c/p\u003e\n\u003ch2\u003e6.5 Evaluation\u003c/h2\u003e\n\u003cp\u003eWe have evaluated the proposed system under various scenarios to analyze its behavior in terms of storage usage and performance. These scenarios were designed to assess the system\u0026rsquo;s capabilities for both small and large log datasets. The experiments were conducted with different configurations, focusing on the time required for processing and storage consumption. \u003cstrong\u003eTable 2\u003c/strong\u003e reports the datasets and chunk parameters used in different experiments.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eTable 2: Experimental setup for evaluating log ingestion and storage efficiency, showing different dataset sizes, chunk configurations, log formats (raw and hashed), number of nodes, and the performance metrics (time and storage) used for analysis.\u003c/em\u003e\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" align=\"\" width=\"642\" class=\"fr-table-selection-hover\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eDataset (log entries)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 128px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eChunk Size (N)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 168px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eIngestion Date Type\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 72px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eNodes\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 120px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eMetrics\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd rowspan=\"2\" valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e10,000\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd rowspan=\"2\" valign=\"top\" style=\"width: 128px;\"\u003e\n \u003cp\u003e1, 5, 10, 20\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 168px;\"\u003e\n \u003cp\u003eRaw\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd rowspan=\"2\" valign=\"top\" style=\"width: 72px;\"\u003e\n \u003cp\u003e3\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd rowspan=\"2\" valign=\"top\" style=\"width: 120px;\"\u003e\n \u003cp\u003eTime \u0026amp; Storage\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 168px;\"\u003e\n \u003cp\u003eHashed\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 153px;\"\u003e\n \u003cp\u003e14 million\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 128px;\"\u003e\n \u003cp\u003e1, 5, 10, 20\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 168px;\"\u003e\n \u003cp\u003eHashed\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 72px;\"\u003e\n \u003cp\u003e3\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 120px;\"\u003e\n \u003cp\u003eTime \u0026amp; Storage\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eThe storage required to store raw data on the blockchain is consistently high, regardless of the chunk size. Therefore, we excluded raw data from the analysis for large datasets, focusing instead on the results for different chunk sizes with hashed data.\u003c/p\u003e"},{"header":"7. Result Analysis \u0026 Discussions","content":"\u003ch2\u003e7.1 Result Analysis\u003c/h2\u003e\n\u003ch3\u003e7.1.1 Ingestion Anlysis\u003c/h3\u003e\n\u003cp\u003eWe initially conducted experiments on a small dataset (10k log entries) to analyze storage usage for raw data and hashed data for each log line.\u003c/p\u003e\n\u003cp\u003eFrom the results depicted in \u003cstrong\u003eFigure 3\u003c/strong\u003e, it is evident that for a chunk size of \u003cem\u003eN=1\u003c/em\u003e, the storage required for hashed data is reduced by half compared to raw data. This reduction corresponds to a \u003cstrong\u003e50%\u0026nbsp;\u003c/strong\u003estorage gain, highlighting the efficiency of hashed data storage in minimizing storage overhead while preserving data integrity and auditability.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe storage required for hashed data significantly decreases as the chunk size increases. For\u003cem\u003e\u0026nbsp;N=5\u003c/em\u003e, the storage usage is approximately \u003cstrong\u003efive times less\u003c/strong\u003e compared to\u003cem\u003e\u0026nbsp;N=1\u003c/em\u003e. This substantial reduction is due to the minimized metadata overhead and fewer chunks being \u0026nbsp;generated, demonstrating the efficiency of larger chunk sizes in optimizing storage.\u003c/p\u003e\n\u003cp\u003eFrom \u003cstrong\u003eFigure 4\u003c/strong\u003e, the storage required is \u003cem\u003e14 GB\u003c/em\u003e where\u003cem\u003e\u0026nbsp;N=1\u003c/em\u003e and the data is hashed. It also shows that increasing the chunk size to \u003cem\u003eN=5, 10, 20\u003c/em\u003e for hashed data significantly reduces storage requirements. For each increase in chunk size, the storage requirement becomes approximately half of the same for the preceding chunk size. This reduction occurs due to fewer chunks being created, which minimizes metadata overhead and optimizes storage usage. Larger chunk sizes are thus highly effective in reducing storage demands while maintaining data integrity.\u003c/p\u003e\n\u003cp\u003eSimilarly, Figure 5 presents a quantitative analysis of processing time for 14 million hashed log entries under varying chunk sizes. When each log entry is processed individually (chunk size of 1), the total processing time reaches approximately \u003cstrong\u003e172 hours\u003c/strong\u003e, indicating a substantial computational overhead. However, when logs are grouped into batches of 5 entries, the processing time drops dramatically to about \u003cstrong\u003e16 hours\u003c/strong\u003e, reflecting a nearly \u003cstrong\u003e90% reduction\u003c/strong\u003e. Increasing the chunk size further results in additional gains\u0026mdash;processing time decreases to roughly \u003cstrong\u003e7.5 hours\u003c/strong\u003e with a chunk size of 10 and stabilizes around \u003cstrong\u003e7.3 hours\u003c/strong\u003e at chunk size 20.\u003c/p\u003e\n\u003cp\u003eThis trend clearly demonstrates that batching log entries into larger groups significantly improves processing efficiency. Fewer hash computations and reduced storage interactions contribute to the time savings. These findings emphasize the value of selecting an appropriate chunking strategy to ensure scalability and high performance in large-scale log processing systems. \u003cstrong\u003eFigure 4 and Figure 5\u003c/strong\u003e collectively offer details about the scalability and performance of the system, emphasizing its ability to handle large-scale datasets efficiently in terms of both storage and time.\u003c/p\u003e\n\u003cp\u003eFinally, \u003cstrong\u003eFigure 6\u003c/strong\u003e presents a combined analysis of storage usage and processing time for 14 million log entries using various chunk sizes. This figure demonstrates how increasing the chunk size significantly reduces both storage overhead and processing time during log data processing. When the chunk size is set to 1, the system requires approximately \u003cstrong\u003e14,062 MB\u003c/strong\u003e of additional storage and takes around \u003cstrong\u003e172.6 hours\u003c/strong\u003e to process, highlighting the inefficiency of handling logs individually. As the chunk size increases to 5, both metrics improve drastically, with storage dropping to \u003cstrong\u003e2,664 MB\u003c/strong\u003e and processing time reducing to \u003cstrong\u003e15.8 hours\u003c/strong\u003e. This trend continues with chunk size 10, where storage falls to \u003cstrong\u003e1,151 MB\u003c/strong\u003e and time to \u003cstrong\u003e7.3 hours\u003c/strong\u003e. At chunk size 20, the gains begin to plateau, with storage at \u003cstrong\u003e1,083 MB\u003c/strong\u003e and processing time at \u003cstrong\u003e7.3 hours\u003c/strong\u003e, indicating diminishing returns beyond this point. Overall, Figure 6 demonstrates that batching logs into larger chunks significantly enhances system efficiency, with the most notable improvements occurring between chunk sizes 1 and 10.\u003c/p\u003e\n\u003cp\u003eThese results clearly demonstrate that increasing the chunk size drastically reduces both storage requirements and processing time. The greatest gains occur between chunk sizes 1 and 5, emphasizing the inefficiency of handling logs individually. The trend highlights the effectiveness of chunking for optimizing both system performance and resource utilization in large-scale log management.\u003c/p\u003e\n\u003ch3\u003e7.1.2 Verification Analysis\u003c/h3\u003e\n\u003cp\u003eThe verification time analysis presented in \u003cstrong\u003eFigure 7\u003c/strong\u003e highlights the significant impact of chunk size (N) on the efficiency of log verification. When the chunk size is set to 1, the system takes approximately \u003cstrong\u003e1,020 minutes\u003c/strong\u003e (or 17 hours) to verify the logs, indicating a high computational burden when each entry is processed individually.\u003c/p\u003e\n\u003cp\u003eHowever, as the chunk size increases to 5, the verification time drops sharply to \u003cstrong\u003e200 minutes\u003c/strong\u003e, representing nearly an \u003cstrong\u003e80% reduction\u003c/strong\u003e. At chunk size 10, the time further decreases to around \u003cstrong\u003e145 minutes\u003c/strong\u003e, and at chunk size 20, it reaches just \u003cstrong\u003e50 minutes\u003c/strong\u003e. Overall, moving from a chunk size of 1 to 20 results in a \u003cstrong\u003e95% reduction\u003c/strong\u003e in verification time. This trend highlights the efficiency benefits of processing logs in larger chunks, especially in large-scale or real-time verification systems.\u003c/p\u003e\n\u003cp\u003eThese results highlight the importance of optimizing chunk sizes for efficient log verification. Larger chunk sizes reduce processing overhead and enhance the scalability of the system, particularly in high-volume log datasets. By balancing chunk size with processing capabilities, this approach ensures a more efficient and scalable solution for log verification in large-scale systems.\u003c/p\u003e\n\u003ch2\u003e7.2 Comparative Analysis Summary\u0026nbsp;\u003c/h2\u003e\n\u003cp\u003eThis section compares \u003cstrong\u003eLogStamping\u003c/strong\u003e against four notable blockchain-based log or provenance systems: \u003cstrong\u003eLogChain [6]\u003c/strong\u003e, \u003cstrong\u003eBCALS [15]\u003c/strong\u003e, \u003cstrong\u003eEngraveChain [16]\u003c/strong\u003e, \u003cstrong\u003eRakib et al. [19]\u003c/strong\u003e, and \u003cstrong\u003eProvChain[8]\u003c/strong\u003e. The analysis evaluates key system aspects including storage, verification speed, real-time capability, query performance, and tamper detection. \u003cstrong\u003eTable 3\u003c/strong\u003e shows a comparative analysis summary among those systems.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cem\u003eTable 3\u003c/em\u003e\u003c/strong\u003e\u003cem\u003e: Comparison of Blockchain-Based Log Management Systems\u003c/em\u003e\u003c/p\u003e\n\u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"628\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eFeature\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eLogChain\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eBCALS\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eEngraveChain\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eRakib et al.\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eProvChain\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eLogStamping(Proposed)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eStorage Efficiency\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003eUnknown: No backend specified\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003eModerate: On-chain; no compression\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003eHigh: Encrypted chunks, no IPFS\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eHigh: IPFS + hash mapping\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eLow: Fully on-chain; high cost\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e✅\u0026nbsp;Very High: IPFS + chunking (92% reduction)\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eVerification Time\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003eUnreported: No results\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003eModerate: On-chain transforms slow audits\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003eModerate: Limited benchmarking\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eModerate: No numbers reported\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eModerate: No latency data\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e✅\u0026nbsp;Very High: 95% faster audit (1,020 \u0026rarr; 50 mins)\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eReal-Time Support\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e❌\u0026nbsp;Not implemented; underdeveloped API\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003e❌\u0026nbsp;Limited\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003e❌\u0026nbsp;Limited\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003e❌\u0026nbsp;Pre-computed logs only\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003e❌\u0026nbsp;Not emphasized; post-event focus\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e✅\u0026nbsp;High\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eQuery Efficiency\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003eUnknown: Query system not defined\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003eModerate: Uses Elasticsearch, not optimized\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003eModerate: Slow chain traversal\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eHigh: Timestamped Merkle tree\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eLow: No retrieval optimization\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e✅\u0026nbsp;Very High: Indexed search via IPFS + Elasticsearch\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003e\u003cstrong\u003eTamper Detection\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 84px;\"\u003e\n \u003cp\u003eTheoretical: Not validated\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 90px;\"\u003e\n \u003cp\u003eHigh: Blockchain integrity\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 108px;\"\u003e\n \u003cp\u003eHigh: AES/RSA, no detection rate given\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eHigh: IPFS-backed hash proofs\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 78px;\"\u003e\n \u003cp\u003eHigh: Immutable, but no tested attack detection\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd valign=\"top\" style=\"width: 106px;\"\u003e\n \u003cp\u003e✅\u0026nbsp;Very High: 100% detection of fake log injections\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u003c/p\u003e\n\u003ch2\u003e7.3 Discussion on Storage Gain Perspective\u003c/h2\u003e\n\u003cp\u003eThe analysis of storage requirements for different chunk sizes reveals significant storage optimization as the chunk size increases. For \u003cem\u003eN=1\u003c/em\u003e, the storage demand is the highest due to the large number of small chunks, each requiring its own metadata and hash computations. This additional overhead contributes to inflated storage usage. In contrast, larger chunk sizes (\u003cem\u003eN=5, 10, 20\u003c/em\u003e) dramatically reduce storage needs by consolidating more log entries into fewer chunks, thereby minimizing metadata overhead.\u003c/p\u003e\n\u003cp\u003eFor instance, Figure 4 shows that when \u003cem\u003eN=5\u003c/em\u003e, the storage requirement is approximately \u003cstrong\u003efive times less\u003c/strong\u003e than that for \u003cem\u003eN=1,\u003c/em\u003e demonstrating a substantial storage gain. Similarly, as the chunk size increases to \u003cem\u003eN=10 and N=20,\u003c/em\u003e the storage demands continue to decrease, albeit with diminishing returns. This trend underscores the efficiency of larger chunk sizes in reducing overall storage requirements while maintaining data integrity.\u003c/p\u003e\n\u003cp\u003eFrom a storage optimization perspective, the results indicate that larger chunk sizes reduce the total storage footprint and make the system more scalable for large datasets. However, there is a trade-off between storage efficiency and potential delays in log ingestion, as larger chunks require more time to fill. Balancing chunk size based on system requirements and log generation rates is essential for achieving optimal storage usage and system performance. This approach highlights the importance of chunk size configuration as a critical parameter for scalable and efficient blockchain-based log management.\u003c/p\u003e\n\u003ch2\u003e7.4 Discussion on Performance Gain Perspective\u003c/h2\u003e\n\u003cp\u003eThe performance of blockchain systems in processing large-scale log files is influenced by several critical factors, including the selection of the blockchain platform, the choice of an efficient consensus algorithm, and the underlying hardware capabilities, such as CPU performance and host machine specifications. After a thorough evaluation, we identified and implemented the most suitable platform combined with a high-performance consensus algorithm to optimize processing efficiency. Our findings highlight the time required to process large log files, demonstrating that our approach leverages these optimizations to achieve enhanced performance and scalability.\u003c/p\u003e\n\u003cp\u003eAs previously discussed, Figure 5 highlights substantial performance gains achieved by increasing chunk size. Recall that processing time drops from \u003cstrong\u003e172.6 hours at N=1\u003c/strong\u003e to \u003cstrong\u003e15.8 hours at N=5\u003c/strong\u003e (a ~91% improvement), and further to \u003cstrong\u003e7.3 hours at N=10\u003c/strong\u003e (a ~54% gain over N=5). These results confirm that the majority of performance gains occur between N=1 and N=10. Moreover, this approach enables near real-time processing when chunk sizes are dynamically adjusted based on application-specific log generation rates.\u003c/p\u003e\n\u003cp\u003eOverall, our experiments highlight that while increasing chunk size dramatically boosts performance at first, especially from \u003cem\u003eN=1 to N=10\u003c/em\u003e, the marginal benefits taper off beyond that. Selecting a moderate chunk size, such as N=10, offers a balanced trade-off between performance and resource usage in large-scale log processing. Importantly, this figure also illustrates that when log generation occurs in real time, this chunk-based strategy allows the system to process logs almost in real time. By dynamically adjusting chunk sizes based on the log generation rate of different applications, the system can maintain efficiency and responsiveness without introducing significant processing delays.\u003c/p\u003e\n\u003ch2\u003e7.5 Discussion on Temper detection\u003c/h2\u003e\n\u003cp\u003eThe proposed tamper detection mechanism leverages a timestamp-aware log grouping strategy to ensure data integrity. Using configurable thresholds (\u003cstrong\u003emaxLines\u003c/strong\u003e, \u003cstrong\u003emaxWaitTime\u003c/strong\u003e), log entries are grouped and hashed incrementally, with each hash verified against the blockchain. This enables localized detection of modifications without reprocessing the entire log file. The algorithm supports real-time log integrity checks, efficiently identifying altered segments based on their temporal boundaries. If tampering is detected, the affected group is flagged, while intact logs are optionally archived to IPFS and indexed in Elasticsearch. Experimental results show a 100% detection accuracy for any synthetic tampering, confirming the system\u0026rsquo;s effectiveness for scalable, fine-grained integrity verification in dynamic environments.\u003c/p\u003e"},{"header":"8. Conclusion and Future Works","content":"\u003cp\u003eThe proposed \u003cb\u003eLogStamping\u003c/b\u003e framework addresses key limitations in existing blockchain-based log management systems by introducing an efficient, scalable, and tamper-resilient solution. Through dynamic chunking, off-chain storage via IPFS, and real-time indexing with Elasticsearch, the system enables high-throughput log ingestion and efficient auditability. Empirical evaluations confirm significant gains in storage efficiency, performance, and tamper detection accuracy. Furthermore, the system guarantees integrity through cryptographic hashing and blockchain anchoring, ensuring trustworthy and verifiable log records. The name \u003cb\u003eLogStamping\u003c/b\u003e reflects its foundational design\u0026mdash;mirroring \u003cb\u003etimestamping practices in PKI systems\u003c/b\u003e, where data integrity, authenticity, and temporal validity are enforced via secure digital signatures. Similarly, LogStamping secures logs by embedding them into timestamped hash groups, offering strong guarantees of chronological accuracy, traceability, and audit readiness. This work lays a robust foundation for future advancements in decentralized and verifiable system log management.\u003c/p\u003e \u003cp\u003eHowever, a key limitation lies in the system\u0026rsquo;s \u003cb\u003einability to recover logs during ingestion\u003c/b\u003e. Since only hashes are stored on-chain and raw logs are not retained until explicitly archived, any loss or deletion before ingestion completes will result in irreversible data loss. Although this enhances privacy and reduces storage burden, it limits real-time recoverability. Once logs are ingested and verified, however, they become tamper-proof and immutable, providing reliable records for audit and compliance.\u003c/p\u003e \u003cp\u003eFuture work will focus on extending the system\u0026rsquo;s \u003cb\u003elog recoverability\u003c/b\u003e, \u003cb\u003efault-tolerant ingestion pipelines\u003c/b\u003e, and \u003cb\u003efine-grained access control\u003c/b\u003e for multi-tenant environments. Integrating anomaly detection, dynamic chunk reconfiguration, and decentralized identity for audit attribution will further enhance LogStamping\u0026rsquo;s applicability in critical infrastructure and cloud-native systems.\u003c/p\u003e"},{"header":"Declarations","content":"\u003ch2\u003eFunding\u003c/h2\u003e\n\u003cp\u003eThe authors did not receive support from any organization for the submitted work. No funds, grants, or other support were received.\u003c/p\u003e\n\u003ch2\u003eCompeting Interests\u003c/h2\u003e\n\u003cp\u003eThe authors have no relevant financial or non-financial interests to disclose.\u003c/p\u003e\n\u003ch2\u003eAuthor Contributions\u003c/h2\u003e\n\u003cp\u003eMd Shariful Islam led the study conception, design, implementation, and served as the primary writer of the manuscript. Mohammad Saifur Rahman and M. Sohel Rahman provided continuous supervision, research guidance, and intellectual feedback throughout the project. Material preparation, data collection, and analysis were conducted by Md Shariful Islam with supervisory support from the co-authors. All authors reviewed, commented on, and approved the final manuscript.\u003c/p\u003e\n\u003ch2\u003eData Availability\u003c/h2\u003e\n\u003cp\u003eThe data that support the findings of this study are available from the corresponding author upon reasonable request.\u003c/p\u003e\n\u003ch2\u003eEthics Approval\u003c/h2\u003e\n\u003cp\u003eNot applicable. This study did not involve human participants, animals, or any materials requiring ethics approval.\u003c/p\u003e"},{"header":"References","content":"\u003col start=\"1\" type=\"1\"\u003e\n\u003cli\u003eLiang, Y.; Zhang, Y.; Sivasubramaniam, A.; Jette, M.; Sahoo, R. Bluegene/l failure analysis and prediction models. In Proceedings of the International Conference on Dependable Systems and Networks, Philadelphia, PA, USA, 25\u0026ndash;28 June 2006; p. 425.\u003c/li\u003e\n\u003cli\u003eFrei, A.; Rennhard, M. Histogram Matrix: Log File Visualization for Anomaly Detection. In Proceedings of the 2008 Third International Conference on Availability, Reliability and Security, Barcelona, Spain, 4\u0026ndash;7 March 2008; pp. 610\u0026ndash;617.\u003c/li\u003e\n\u003cli\u003eGoldstein, M.; Raz, D.; Segall, I. Experience Report: Log-Based Behavioral Differencing. In Proceedings of the 2017 IEEE 28th International Symposium on Software Reliability Engineering (ISSRE), Toulouse, France, 23\u0026ndash;26 October 2017; pp. 282\u0026ndash;293.\u003c/li\u003e\n\u003cli\u003eO. Soderstrom and E. Moradian, \u0026ldquo;Secure audit log management,\u0026rdquo; \u0026uml; Procedia Comput. Sci., vol. 22, pp. 1249\u0026ndash;1258, 2013\u003c/li\u003e\n\u003cli\u003eI. Ray, K. Belyaev, M. Strizhov, D. Mulamba, and M. Rajaram, \u0026ldquo;Secure logging as a service-delegating log management to the cloud,\u0026rdquo; IEEE Syst. Journal, vol. 7, no. 2, pp. 323\u0026ndash;334, 2013. \u003c/li\u003e\n\u003cli\u003eW. Pourmajidi and A. Miranskyy, \u0026ldquo;Logchain: Blockchain-assisted log storage,\u0026rdquo; in Proc. 11th IEEE Int. Conf. Cloud Comput. (CLOUD), 2018, pp. 978\u0026ndash;982.\u003c/li\u003e\n\u003cli\u003eM. Kumar, A. K. Singh, and T. V. S. Kumar, \u0026ldquo;Secure log storage using blockchain and cloud infrastructure,\u0026rdquo; in Proc. 9th IEEE Int. Conf. Comput., Commun. and Netw. Technol. (ICCCNT), 2018, pp. 1\u0026ndash;4\u003c/li\u003e\n\u003cli\u003eX. Liang, S. Shetty, D. Tosh, C. Kamhoua, K. Kwiat, and L. Njilla, \u0026ldquo;Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability,\u0026rdquo; in Proc. 17th IEEE/ACM Int. Symp. Cluster, Cloud and Grid Comput. (CCGrid\u0026rsquo;17), 2017, pp. 468\u0026ndash;477\u003c/li\u003e\n\u003cli\u003eJ. H. Park, J. Y. Park, and E. N. Huh, \u0026ldquo;Block chain based data logging and integrity management system for cloud \u003cstrong\u003eforensics\u003c/strong\u003e,\u0026rdquo; Comput. Sci. \u0026amp; Inf. Technol., vol. 149, 2017\u003c/li\u003e\n\u003cli\u003eSchneier, B., \u0026amp; Kelsey, J. (1999). Cryptographic Support for Secure Logs on Untrusted Machines.\u003c/li\u003e\n\u003cli\u003eHolt, J. E. (2006). Logcrypt: Forward Security and Public Verification for Secure Audit Logs. AISW-NetSec 2006.\u003c/li\u003e\n\u003cli\u003eAhmad, A., Saad, M., Bassiouni, M., \u0026amp; Mohaisen, A. (2018). Towards Blockchain-Driven, Secure and Transparent Audit Logs. MobiQuitous, 3286978-3286985.\u003c/li\u003e\n\u003cli\u003eRakib, M. H., Hossain, S., Jahan, M., \u0026amp; Kabir, U. (2020). Towards Blockchain-Driven Network Log Management System. IEEE iSCI\u003c/li\u003e\n\u003cli\u003eIBM (2018). Storage Needs for Blockchain Technology: Point of View. IBM Corporation.\u003c/li\u003e\n\u003cli\u003eAli, A., Khan, A., Ahmed, M., \u0026amp; Jeon, G. (2021). BCALS: Blockchain-Based Secure Log Management System for Cloud Computing. Transactions on Emerging Telecommunications Technologies, e4272.\u003c/li\u003e\n\u003cli\u003eL. M. Shekhtman and E. Waisbard, \u0026quot;Securing log files through blockchain technology,\u0026quot; in Proceedings of the 11th ACM International Systems and Storage Conference, Article No. 3, 2018. doi: 10.1145/3211890.3211893.\u003c/li\u003e\n\u003cli\u003eShekhtman, L., \u0026amp; Waisbard, E. (2021). EngraveChain: A Blockchain-Based Tamper-Proof Distributed Log System. Future Internet, 13(6), 143.\u003c/li\u003e\n\u003cli\u003eP. V. Kakarlapudi and Q. H. Mahmoud, \u0026quot;Design and Development of a Blockchain-Based System for Private Data Management,\u0026quot; Electronics, vol. 10, no. 24, p. 3131, 2021. doi: 10.3390/electronics10243131.\u003c/li\u003e\n\u003cli\u003eRakib, M. H., Hossain, S., Jahan, M., \u0026amp; Kabir, U. (2022). A Blockchain-Enabled Scalable Network Log Management System. Journal of Computer Science, 18(6), 496-508.\u003c/li\u003e\n\u003cli\u003eY. Zhao, X. Liu, and L. Wang, \u0026quot;A Complete Log Files Security Solution Using Anomaly Detection and Blockchain Technology,\u0026quot; Proceedings of the IEEE International Conference on Big Data (Big Data 2023), pp. X-X, 2023. DOI: 10.1109/BigData.2023.10100200.\u003c/li\u003e\n\u003cli\u003eKanhere, S. S., \u0026amp; Conti, M. (2024). Blockchain for Health Data Management. In Blockchains: A Handbook on Fundamentals, Platforms and Applications (pp. 321-346). Springer. https://doi.org/10.1007/978-3-031-32146-7_18\u003c/li\u003e\n\u003cli\u003eKhan, S., Alam, M., \u0026amp; Khan, S. U. (2023). Blockchain-Based Secure Logging Mechanism for Cloud Forensics. Computers \u0026amp; Security, 125, 102976. https://doi.org/10.1016/j.cose.2023.102976\u003c/li\u003e\n\u003cli\u003eSingh, A., Zhou, Y., Mehrotra, S., Sadoghi, M., Sharma, S., \u0026amp; Nawab, F. (2023). WedgeBlock: An off-chain secure logging platform for blockchain applications. In Proceedings of the 26th International Conference on Extending Database Technology (EDBT) (pp. 684\u0026ndash;696). https://doi.org/10.48786/edbt.2023.43\u003c/li\u003e\n\u003cli\u003eZhang, P., \u0026amp; Wang, J. (2019). Blockchain Based Data Integrity Verification for Large-Scale IoT Data. IEEE Access, 7, 164401-164411. https://doi.org/10.1109/ACCESS.2019.2952847\u003c/li\u003e\n\u003cli\u003eNakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. Retrieved from https://bitcoin.org/bitcoin.pdf\u003c/li\u003e\n\u003cli\u003eButerin, V. (2013). A next-generation smart contract and decentralized application platform. Ethereum Whitepaper. Available at https://ethereum.org/en/whitepaper/\u003c/li\u003e\n\u003cli\u003eHyperledger Fabric Documentation. (2024). Hyperledger Fabric documentation. Retrieved from https://hyperledger-fabric.readthedocs.io/\u003c/li\u003e\n\u003cli\u003eA Large Collection of System Log Datasets for AI-Driven Log Analytics, https://github.com/logpai/loghub,[Last Access on 12 Jan 2024] Generate a Boatload of Fake Apache Log Files Very Quickly,\u003c/li\u003e\n\u003cli\u003ehttps://github.com/kiritbasu/Fake-Apache-Log-Generator, [Last Access on 12 Jan 2024].\u003c/li\u003e\n\u003cli\u003eYoshida, H., \u0026amp; Biryukov, A. (2005). Analysis of a SHA-256 variant. In Advances in Cryptology \u0026ndash; EUROCRYPT 2005 (pp. 245\u0026ndash;260). Springer. https://doi.org/10.1007/11693383_17\u003c/li\u003e\n\u003cli\u003eSatoshi, Nakamoto . Bitcoin: A peer-to-peer electronic cash system, https://bitcoin.org/bitcoin.pdf, [Last Access on 12 Jan 2024].\u003c/li\u003e\n\u003cli\u003eChuvakin, A., Schmidt, K., \u0026amp; Phillips, C. (2013). \u003cem\u003eLogging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management.\u003c/em\u003e Syngress.\u003c/li\u003e\n\u003cli\u003eKent, K., \u0026amp; Souppaya, M. (2006). \u003cem\u003eGuide to Computer Security Log Management (NIST Special Publication 800-92).\u003c/em\u003e National Institute of Standards and Technology (NIST).\u003c/li\u003e\n\u003cli\u003eBarisani, A., \u0026amp; Oldani, D. (2007). \u003cem\u003eOffensive Computing: Understanding Windows, Linux, and UNIX Security.\u003c/em\u003e Syngress.\u003c/li\u003e\n\u003cli\u003eYaga, D., Mell, P., Roby, N., \u0026amp; Scarfone, K. (2018). Blockchain technology overview. National Institute of Standards and Technology (NIST). [https://doi.org/10.6028/NIST.IR.8202](https://doi.org/\u003c/li\u003e\n\u003cli\u003eJ. Dykstra and A. T. Sherman, \u0026ldquo;Understanding issues in cloud forensics: two hypothetical case studies,\u0026rdquo; in Proceedings of the Conference on Digital Forensics, Security and Law, 2011, p. 45.\u003c/li\u003e\n\u003cli\u003eAptive, \u0026quot;Log Injection Attack: Understanding and Mitigating the Risks.\u0026quot; [Online]. Available: https://www.aptive.co.uk/blog/log-injection-attack/. [Accessed: Jan. 12, 2024].\u003c/li\u003e\n\u003cli\u003eMa, D., \u0026amp; Tsudik, G. (2009). A new approach to secure logging. ACM Transactions on Storage, 5(1), 2:1\u0026ndash;2:21. https://doi.org/10.1145/1502777.1502779\u003c/li\u003e\n\u003cli\u003eRajebhosale, S. S., \u0026amp; Nikam, M. C. (2019). Development of secured log management system over blockchain technology. International Journal of Cyber Research and Education, 1(1), 38\u0026ndash;42. IGI Global. https://doi.org/10.4018/IJCRE.2019010104\u003c/li\u003e\n\u003cli\u003eAhmad, A., Saad, M., Bassiouni, M., \u0026amp; Mohaisen, A. (2018). Towards blockchain-driven, secure and transparent audit logs. In Proceedings of the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (pp. 443\u0026ndash;448). ACM. https://doi.org/10.1145/3286978.3286985\u003c/li\u003e\n\u003cli\u003eXu, G., Yun, F., Xu, S., Yu, Y., Chen, X.-B., \u0026amp; Dong, M. (2023). \u003cem\u003eA blockchain-based log storage model with efficient query.\u003c/em\u003e \u003cstrong\u003eSoft Computing, 27\u003c/strong\u003e, 13779\u0026ndash;13787. https://doi.org/10.1007/s00500-023-08975-3\u003c/li\u003e\n\u003cli\u003eKhan, D., Jung, L. T., \u0026amp; Hashmani, M. A. (2020). Scalability in blockchain: Challenges and solutions. In Blockchain Technology: Applications and Challenges (pp. 315\u0026ndash;332). Elsevier. https://doi.org/10.1016/B978-0-12-819816-2.00015-0\u003c/li\u003e\n\u003cli\u003eShafin, K. M., \u0026amp; Reno, S. (2024). Breaking the blockchain trilemma: A comprehensive consensus mechanism for ensuring security, scalability, and decentralization. IET Software, 2024(1). https://doi.org/10.1049/2024/6874055\u003c/li\u003e\n\u003cli\u003eAbbas, Z., \u0026amp; Myeong, S. (2024). A comprehensive study of blockchain technology and its role in promoting sustainability and circularity across large-scale industry. Sustainability, 16(10), 4232. https://doi.org/10.3390/su16104232\u003c/li\u003e\n\u003cli\u003eSanka, A. I., \u0026amp; Cheung, R. C. C. (2021). A systematic review of blockchain scalability: Issues, solutions, analysis and future research. Journal of Network and Computer Applications, 195, 103232. https://doi.org/10.1016/j.jnca.2021.103232\u003c/li\u003e\n\u003cli\u003eAlghamdi, T. A., Khalid, R., \u0026amp; Javaid, N. (2024). A survey of blockchain based systems: Scalability issues and solutions, applications and future challenges. IEEE Access, 12, 79626\u0026ndash;79651. https://doi.org/10.1109/ACCESS.2024.3408868\u003c/li\u003e\n\u003cli\u003eU.S. Department of Health \u0026amp; Human Services. (1996). Health Insurance Portability and Accountability Act (HIPAA). Retrieved from https://www.hhs.gov/hipaa/index.html, [Last Accessed on 24 May 2024].\u003c/li\u003e\n\u003cli\u003eEuropean Union. (2016). General Data Protection Regulation (GDPR). Retrieved from https://eur-lex.europa.eu/eli/reg/2016/679/oj, [Last Accessed on 24 May 2024].\u003c/li\u003e\n\u003cli\u003eBenet, J. (2014). \u003cem\u003eIPFS - Content Addressed, Versioned, P2P File System.\u003c/em\u003e arXiv:1407.3561. DOI: 10.48550/arXiv.1407.3561.\u003c/li\u003e\n\u003cli\u003eNational Institute of Standards and Technology (NIST), \u0026quot;Secure Hash Standard (SHS),\u0026quot; Federal Information Processing Standards Publication 180-4 (FIPS PUB 180-4), 2015. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.180-4.\u003c/li\u003e\n\u003cli\u003eEthereum Foundation, \u003cem\u003eSolidity: High-Level Language for Smart Contracts\u003c/em\u003e, 2024. [Online]. Available: https://soliditylang.org.\u003c/li\u003e\n\u003cli\u003eV. Buterin, \u0026quot;Proof of Authority Chains,\u0026quot; Ethereum Foundation, 2017. [Online]. Available: https://github.com/ethereum/EIPs/issues/225.\u003c/li\u003e\n\u003cli\u003e\u0026quot;Blockchain explorer,\u0026quot; \u003cem\u003eWikipedia, The Free Encyclopedia\u003c/em\u003e, Apr. 2024. [Online]. Available: https://en.wikipedia.org/wiki/Blockchain_explorer.\u003c/li\u003e\n\u003cli\u003eBrown, R. G., Carlyle, J., Grigg, I., \u0026amp; Hearn, M. (2016). Corda: An introductory whitepaper. R3 Consortium. Retrieved May 24, 2024, from https://docs.r3.com/en/pdf/corda-introductory-whitepaper.pdf\u003c/li\u003e\n\u003cli\u003eEthereum Foundation. (n.d.). \u003cem\u003eIntroduction to dapps.\u003c/em\u003e Retrieved May 24, 2024, from https://ethereum.org/en/developers/docs/dapps/\u003c/li\u003e\n\u003cli\u003eJ.P. Morgan. (n.d.). \u003cem\u003eQuorum blockchain platform.\u003c/em\u003e Retrieved May 24, 2024, from https://consensys.net/quorum/\u003c/li\u003e\n\u003cli\u003eMultiChain\u003cstrong\u003e.\u003c/strong\u003e (n.d.). \u003cem\u003eMultiChain: Open platform for building blockchains.\u003c/em\u003e Retrieved May 24, 2024, from https://www.multichain.com/\u003c/li\u003e\n\u003cli\u003eRipple Labs Inc. (n.d.). \u003cem\u003eRipple: Real-time gross settlement system, currency exchange and remittance network.\u003c/em\u003e Retrieved May 24, 2024, from https://ripple.com/\u003c/li\u003e\n\u003cli\u003eZheng, Z., Xie, S., Dai, H., Chen, X., \u0026amp; Wang, H. (2017, June). \u003cem\u003eAn overview of blockchain technology: Architecture, consensus, and future trends.\u003c/em\u003e In 2017 IEEE International Congress on Big Data (BigData Congress) (pp. 557\u0026ndash;564). IEEE. https://doi.org/10.1109/BigDataCongress.2017.85\u003c/li\u003e\n\u003cli\u003eElastic. (n.d.). \u003cem\u003eElasticsearch: Distributed, RESTful search and analytics engine.\u003c/em\u003e Retrieved May 24, 2024, from https://www.elastic.co/elasticsearch/\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"cluster-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"","sideBox":"Learn more about [Cluster Computing](https://www.springer.com/journal/10586)","snPcode":"10586","submissionUrl":"https://submission.nature.com/new-submission/10586/3","title":"Cluster Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false},"keywords":"Blockchain, Log Management, Scalability, Privacy, Real-Time Systems, Distributed Environments, Tamper-Proof, Large-Scale Systems","lastPublishedDoi":"10.21203/rs.3.rs-8076476/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-8076476/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eLog management is crucial for ensuring the security, integrity, and compliance of modern information systems. Traditional log management solutions face challenges in achieving tamper-proofing, scalability, and real-time processing in distributed environments. This paper presents a blockchain-based log management framework that addresses these limitations by leveraging blockchain\u0026rsquo;s decentralized, immutable, and transparent features. The framework integrates a hybrid on-chain and off-chain storage model, combining blockchain\u0026rsquo;s integrity guarantees with the scalability of distributed storage solutions like IPFS. Smart contracts automate log validation and access control, while cryptographic techniques ensure privacy and confidentiality. With a focus on real-time log processing, the framework is designed to handle the high-volume log generation typical in large-scale systems, such as data centers and network infrastructure. Performance evaluations demonstrate the framework\u0026rsquo;s scalability, low latency, and ability to manage millions of log entries while maintaining strong security guarantees. Additionally, the paper discusses challenges like blockchain storage overhead and energy consumption, offering insights for enhancing future systems.\u003c/p\u003e","manuscriptTitle":"LogStamping: A blockchain-based log auditing approach for large-scale systems","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-12-29 06:49:28","doi":"10.21203/rs.3.rs-8076476/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"editorInvitedReview","content":"","date":"2026-01-05T23:20:03+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"991977555136682827228246362738896674","date":"2025-12-26T05:07:12+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2025-12-25T10:24:36+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2025-12-25T10:23:21+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2025-11-14T01:43:22+00:00","index":"","fulltext":""},{"type":"submitted","content":"Cluster Computing","date":"2025-11-10T11:22:22+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"cluster-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"","sideBox":"Learn more about [Cluster Computing](https://www.springer.com/journal/10586)","snPcode":"10586","submissionUrl":"https://submission.nature.com/new-submission/10586/3","title":"Cluster Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false}}],"origin":"","ownerIdentity":"40173411-4dca-48ee-accf-20ca04595ee7","owner":[],"postedDate":"December 29th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"under-review","subjectAreas":[],"tags":[],"updatedAt":"2025-12-29T06:49:28+00:00","versionOfRecord":[],"versionCreatedAt":"2025-12-29 06:49:28","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-8076476","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-8076476","identity":"rs-8076476","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}