A Blockchain-Based Audit Trail Mechanism: Design and Implementation
Abstract
:1. Introduction
2. Background and Motivation
2.1. Blockchain Technology
2.2. Current Blockchain Based Audit Solutions
2.3. Motivation
3. Audit Trail Mechanism Architecture
- Integrity: The information recorded in Blockchain cannot be manipulated. As the information is distributed across multiple nodes, it cannot be modified at all. In this way, fraud prevention and detection are almost unnecessary.
- Authenticity: Blockchain provides an unalterable assurance of origin; thus, nonrepudiation is guaranteed.
- Long-term maintenance of audit information: Once information has been entered into the Blockchain, it can never be deleted; consequently, the audit trail will always be traceable.
- Blockchain network: A permissioned Blockchain network should be considered as the backbone. All information provided to the audit trail will be recorded in all the nodes of the Blockchain, ensuring its integrity, authenticity, and long-term maintenance. This means that both the auditing system functionality and the information registered in the system cannot be modified at all, making them totally reliable.
- Smart contracts: The audit trail functionalities are implemented through smart contracts deployed on the Blockchain network. Like information, smart contracts are registered on all the nodes of the Blockchain, ensuring their integrity and secure execution. Auditing functionalities include the registration of necessary data to be audited on the Blockchain, as well as the consumption of this previously registered data for integrity validation. In addition, Blockchain-based events will be generated to feed the Blockchain monitor.
- Blockchain client: Each component using the auditing functionalities backboned by Blockchain needs a Blockchain client to be able to interact with the Blockchain. This Blockchain client will be deployed as a docker image for usability and interoperability reasons. This Blockchain client exposes a REST API to be able to interact with it.
- Blockchain monitor: It listens for Blockchain events from the audit trail mechanism smart contract and normalizes and categorizes the details for correct consumption from the Blockchain monitor client. The Blockchain monitor allows isolating external users from the need to have a Blockchain client (or, at least, a Blockchain account) to consume the information recorded on the Blockchain.
- Blockchain monitor client: This client consumes the normalized and categorized information from the Blockchain monitor.
4. Audit Trail Mechanism Description
4.1. Blockchain Network
- Without cryptocurrency. There are several applications, such as audit trails, that do not require cryptocurrencies. In these cases, there is no need to complicate the operation of the network with cryptocurrency support; the revenue model, if necessary, should be outside the network.
- New consensus algorithms. Quorum leverages RAFT [41] for collision fault tolerance and IBFT consensus [42] for Byzantine fault tolerance, increasing speed and not requiring large processing capacity at the nodes as in, for example, public networks with proof-of-work consensus algorithms [43]. Consequently, performance increases.
- Increased scalability, in terms of both participants and activities. Quorum is a permissioned network in which only authorized nodes can participate. These new participating nodes must have permission to be part of the Blockchain and be able to verify transactions, execute smart contracts, and maintain the state of the ledger. Figure 2 shows the architecture of a Quorum node.
- Transaction manager: It manages private transactions by allowing access and sending and receiving encrypted payloads to other transaction managers on other Quorum nodes. It uses Enclave to perform cryptographic operations.
- Enclave: It performs all necessary encryption and decryption operations.
4.2. Smart Contracts for Audit Trail
4.2.1. User Management
- Administrators: These entities are those who can authorize or deny users to use the audit trail mechanism. Administrators can also define or delete other new administrators. The first administrators in the system are the participants of the Blockchain network.
- Authorized users: These users are authorized by an administrator to use the audit trail mechanism. The audit trail data associated with each user can only be updated or retrieved by its owner (the user who registered it). Therefore, although multiple users may register audit trail information on the same Blockchain network, each user will only have access to the information associated with themself.
4.2.2. Administrator Functionalities
- Define new administrators (the new administrator ID is needed).
- Remove an existing administrator (the administrator ID is needed).
- Check if a specific user ID is an administrator in the system (the administrator ID is needed).
- Obtain the number of administrators in the system.
- Authorize a new user (the new authorized user ID is needed).
- Deauthorize an existing authorized user (the authorized user ID is needed).
- Check if a specific user ID is an authorized user (the authorized user ID is needed).
- Obtain the number of authorized users in the system.
4.2.3. Authorized User Functionalities
- ID: This is an internal ID to identify the audit trail record in the Blockchain. It is automatically generated by the smart contract.
- Owner: This refers to the authorized user ID (authorized user Blockchain address) who has registered the audit trail. The owner is the only one with permission to update or retrieve this information. It is automatically detected by the smart contract.
- Data: This refers to the audit trail registered in the system for auditing purposes. The data could be provided by the authorized user as a name-value, to allow the registration of different types of information and provide a general-purpose solution (not limited to a specific application or domain). The value can be encrypted if necessary.
- creationTimestamp: This refers to the timestamp of the audit trail data registering process in seconds since the epoch. It is automatically generated by the smart contract.
- updatedTimestamp: This refers to the timestamp of the audit trail data last updating process in seconds since the epoch. It is automatically updated by the smart contract.
- Register a new audit trail (data information is needed).
- Update an existing audit trail (ID of the audit trail and new data are needed).
- Obtain an existing audit trail (ID of the audit trail is needed).
- A new administrator is added.
- An existing administrator is removed.
- A new user is authorized.
- An existing user is deauthorized.
- A new audit record is registered.
- An existing audit record is updated.
4.3. Blockchain Client
4.3.1. Blockchain Account Management
- Create a new account. A new address and an associated private key are generated.
- Obtain the address associated with a private key (the private key obtained when creating a new account is needed).
- Add the account to the wallet (the private key is needed).
- Obtain the address added to the account. The address previously added to the wallet is obtained.
4.3.2. Blockchain Transactions Generation
4.3.3. REST API for External Interaction
4.4. Blockchain Monitor
- Eventeum [46]: This is a middleware that serves as a bridge between the smart contracts deployed on the Blockchain network and the application layer of the Blockchain monitor. It is in charge of listening to all the Blockchain events from the Blockchain-based audit trail mechanism and transmitting them to Logstash using Kafka.
- To listen to the events, it is necessary to be subscribed to the events of the specific smart contract addresses (each smart contract has a Blockchain address, which identifies itself in the Blockchain). In addition, it is also necessary to indicate to Eventeum the specific format of the events (event ID, order of the event parameters, type of the event parameters).
- Apache Kafka [47]: This is the intermediary platform used to distribute and process message flows between Eventeum and Logstash. It allows data to be communicated very quickly, categorizing them in different topics if necessary.
- Logstash [48]: This is a log management tool whose function is to collect all the events it receives from Eventeum, through Kafka, and normalize them before routing them to the Elasticsearch service for processing.
- Elasticsearch [49]: This is a distributed search and analysis engine, which allows storing, indexing, and processing information. It receives data from the Logstash service and categorizes the information into different categories: users and data. The information stored in Elasticsearch can be recreated from scratch at any time in case of a security incident, resulting in a fully reliable source of information. Elasticsearch exposes an REST API to access the information.
4.5. Blockchain Monitor Client
- The general dashboard, where the current audit trail information is displayed (latest updates). Figure 4 shows a general dashboard from the KYKLOS 4.0 project, as an example, showing information about registered users, registered components, and registered features of the different components.
- The history report, where all updates associated to an audit trail since its creation can be consulted, being able to detect all changes occurred and when they took place. It is not necessary to add details about who has updated the component information because only the owner of the audit trail can update its associated audit trail. The history report on its audit trail is accessed from the general dashboard by accessing each specific audit trail ID (shown as blue links in Figure 4). Figure 5 shows an example of the history for a component registered in the KYKLOS 4.0 project.
5. Audit Trail Mechanism Operation
- Administrators: people, automated systems, etc. who manage the system and authorize users to use it.
- Authorized users: people, automated systems, etc. who provide data to be registered in the Blockchain-based auditing mechanism and consume it as required. Authorized users always need the Blockchain client to interact with the Blockchain.
- External data consumers: people who consume the data registered in the Blockchain-based audit trail mechanism. They do not need any Blockchain client as they do not access the Blockchain directly, but they access the Blockchain monitor, which has a copy of all-important events occurring on the Blockchain by means of the subscribed Blockchain-based events. They cannot register or modify audit trails on the Blockchain. They only need to access the Blockchain monitor client by means of a web browser.
- An administrator must authorize a user to use the audit trail mechanism.
- The authorized user can register a new audit trail (new data will be registered in the Blockchain)
- The authorized user can update an existing audit trail (data recorded in the Blockchain will be updated).
- The authorized user can obtain the current version of an existing audit trail.
- An external data consumer can obtain the information recorded on the Blockchain (main dashboard or history report) by means of the web-based Blockchain monitor client (authentication is required).
6. Validation Experiment
- Blockchain network: Three Quorum Blockchain nodes were locally deployed as docker images for validation purposes (kyklos_network_node1_1, kyklos_network_node2_1 and kyklos_network_node3_1 in Figure 7); however, in real deployments, additional nodes managed by different owners are recommended to improve decentralization and governance of the Blockchain network. The implemented smart contracts with the functionalities described in Section 4 were registered (deployed) on the Blockchain network.
- Blockchain monitor and Blockchain monitor client: One instance of each of the required services for the Blockchain monitor and Blockchain monitor client were locally deployed as docker images for validation purposes; in real deployments, at least the Blockchain monitor client must be publicly accessible.
- Logstash, Elasticsearch, and Kibana, as part of the Elastic Stack, were deployed through the Logstash, Elasticsearch, and Kibana docker images in Figure 7, respectively.
- Blockchain client: One Blockchain client instance was locally deployed as a Node.js application for validation purposes by means of the PM2 process manager [53] (KYKLOS_HTTP_SERVER in Figure 8); however, in real deployment, any component that is likely to provide audit information should deploy its own instance of Blockchain client.
7. Conclusions
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
References
- Costin, A.; Zaddach, J. Iot Malware: Comprehensive Survey, Analysis Framework and Case Studies. Available online: https://i.blackhat.com/us-18/Thu-August-9/us-18-Costin-Zaddach-IoT-Malware-Comprehensive-Survey-Analysis-Framework-and-Case-Studies-wp.pdf (accessed on 21 October 2021).
- Zhang, Z.K.; Cho, M.C.Y.; Wang, C.W.; Hsu, C.W.; Chen, C.K.; Shieh, S. IoT security: Ongoing challenges and research opportunities. In Proceedings of the 2014 IEEE 7th International Conference on Service-Oriented Computing and Applications, Matsue, Japan, 17–19 November 2014. [Google Scholar]
- Ahmad, R.; Alsmadi, I. Machine learning approaches to IoT security: A systematic literature review. IEEE Internet Things 2021, 14, 100365. [Google Scholar]
- Valaboju, Y. A Comprehensive Study on Iot Architectures and Iot Security. Parishodh J. 2019, VIII, 57–66. [Google Scholar]
- Mohanta, B.K.; Jena, D.; Satapathy, U.; Patnaik, S. Survey on IoT security: Challenges and solution using machine learn-ing, artificial intelligence and blockchain technology. IEEE Internet Things 2020, 11, 100227. [Google Scholar]
- Nadir, I.; Ahmad, Z.; Mahmood, H.; Shah, G.A.; Shahzad, F.; Umair, M.; Gulzar, U. An Auditing Framework for Vul-nerability Analysis of IoT System. In Proceedings of the 2019 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Stockholm, Sweden, 17–19 June 2019. [Google Scholar]
- Wolf, Z.R. Exploring the audit trail for qualitative investigations. Nurse Educ. 2003, 28, 175–178. [Google Scholar] [CrossRef] [PubMed]
- Kennedy, G.E.; Judd, T.S. Making sense of audit trail data. Australas. J. Educ. Technol. 2004, 20, 18–32. [Google Scholar] [CrossRef] [Green Version]
- Duncan, R.A.K.; Whittington, M. Enhancing cloud security and privacy: The power and the weakness of the audit trail. Available online: https://aura.abdn.ac.uk/bitstream/handle/2164/8061/cloud_computing_2016_6_20_20063.pdf?sequence=1 (accessed on 21 October 2021).
- Khanuja, H.K.; Adane, D.S. S. Database security threats and challenges in database forensic: A survey. In Proceedings of 2011 International Conference on Advancements in Information Technology (AIT 2011), Chennai, India, 17–18 December 2011.
- Nikolaou, C.N.; Marazakis, M.; Georgiannakis, G. Transaction routing for distributed OLTP systems: Survey and recent results. Inf. Sci. 1997, 97, 45–82. [Google Scholar] [CrossRef]
- Lee, K.H.; Zhang, X.; Xu, D. LogGC: Garbage collecting audit log. In Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, Berlin, Germany, 4–8 November 2013; pp. 1005–1016. [Google Scholar]
- Zheng, Z.; Xie, S.; Dai, H.N.; Chen, X.; Wang, H. Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. 2018, 14, 352–375. [Google Scholar] [CrossRef]
- Ljunggren, N. Improving the Usability of Secure Information Storing within Blockchain Applications. Master’s Thesis, Lund University, Lund, Sweden, 2019. [Google Scholar]
- Clincy, V.; Shahriar, H. Blockchain development platform comparison. In Proceedings of the 2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC), Milwaukee, WI, USA, 15–19 July 2019; IEEE: Piscataway, NJ, USA, 2019; Volume 1, pp. 922–923. [Google Scholar]
- Bodkhe, U.; Tanwar, S.; Parekh, K.; Khanpara, P.; Tyagi, S.; Kumar, N.; Alazab, M. Blockchain for industry 4.0: A comprehensive review. IEEE Access 2020, 8, 79764–79800. [Google Scholar] [CrossRef]
- Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 21 October 2021).
- Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap. 2014, 151, 1–32. [Google Scholar]
- Cong, L.W.; He, Z. Blockchain disruption and smart contracts. Rev. Financ. Stud. 2019, 32, 1754–1797. [Google Scholar] [CrossRef]
- Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, Porto, Portugal, 23–26 April 2018; pp. 1–15. [Google Scholar]
- Morgan, J.P. Quorum Whitepaper. Technical Report. 2016. Available online: https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf (accessed on 11 November 2021).
- Consensys Quorum. Available online: https://consensys.net/quorum/ (accessed on 11 November 2021).
- Lombardi, R.; de Villiers, C.; Moscariello, N.; Pizzo, M. The disruption of blockchain in auditing—A systematic literature review and an agenda for future research. Available online: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3834838 (accessed on 21 October 2021).
- Tiron-Tudor, A.; Deliu, D.; Farcane, N.; Dontu, A. Managing change with and through blockchain in accountancy organizations: A systematic literature review. Available online: https://www.emerald.com/insight/content/doi/10.1108/JOCM-10-2020-0302/full/html (accessed on 21 October 2021).
- Pimentel, E.; Boulianne, E.; Eskandari, S.; Clark, J. Systemizing the challenges of auditing blockchain-based assets. J. Inf. Syst. 2021, 35, 61–75. [Google Scholar] [CrossRef]
- Psaila, S. Blockchain: A Game Changer for Audit Processes. Available online: https://www2.deloitte.com/mt/en/pages/audit/articles/mt-blockchain-a-game-changer-for-audit.html (accessed on 11 November 2021).
- Chartered Professional Accountants of Canada (CPA Canada) and the American Institute of CPAs (AICPA). Available online: https://us.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/blockchain-technology-and-its-potential-impact-on-the-audit-and-assurance-profession.pdf (accessed on 11 November 2021).
- Dai, J. Three Essays on Audit Technology: Audit 4.0, Blockchain, and Audit App. Ph.D. Thesis, Rutgers University-Graduate School-Newark, New Brunswick, NJ, USA, 2017. [Google Scholar]
- Fanning, K.; Centers, D.P. Blockchain and Its Coming Impact on Financial Services. J. Corp. Account. Financ. 2016, 27, 53–57. [Google Scholar] [CrossRef]
- Kiviat, T.I. Beyond Bitcoin: Issues in Regulating Blockchain Transactions. Duke Law J. 2015, 65, 569. [Google Scholar]
- Ahmad, A.; Saad, M.; Bassiouni, M.; Mohaisen, A. 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, New York, NY, USA, 5–7 November 2018; pp. 443–448. [Google Scholar]
- Peters, G.W.; Panayi, E. Understanding Modern Banking Ledgers through Blockchain Technologies: Future of Transaction Processing and Smart Contracts on the Internet of Money. In Banking Beyond Banks and Money; Working paper; Cornell University: Ithaca, NY, USA, 2015. [Google Scholar]
- Sutton, A.; Samavi, R. Blockchain Enabled Privacy Audit Logs. In Proceedings of the International Semantic Web Conference ISWC, Vienna, Austria, 21–25 October 2017; pp. 645–660. [Google Scholar] [CrossRef]
- VishwaVidyapeetham, A. A blockchain and ipfs based framework for secure research record keeping. Int. J. Pure Appl. Math. 2018, 119, 1437–1442. [Google Scholar]
- Li, J.; Wu, J.; Jiang, G.; Srikanthan, T. Blockchain-based public auditing for big data in cloud storage. Inf. Process. Manag. 2020, 57, 102382. [Google Scholar]
- Cucurull, J.; Puiggalí, J. Distributed Immutabilization of Secure Logs. In Security and Trust Management. STM 2016; Lecture Notes in Computer, Science; Barthe, G., Markatos, E., Samarati, P., Eds.; Springer: Cham, Switzerland, 2016; Volume 9871. [Google Scholar] [CrossRef]
- Wang, Y.; Li, J.; Yan, Y.; Chen, X.; Yu, F.; Zhao, S.; Yu, T.; Feng, K. A semi-centralized blockchain system with multi-chain for auditing communications of Wide Area Protection System. PLoS ONE 2021, 16, e0245560. [Google Scholar] [CrossRef] [PubMed]
- Ali, A.; Khan, A.; Ahmed, M.; Jeon, G. BCALS: Blockchain-based secure log management system for cloud computing. Available online: https://onlinelibrary.wiley.com/doi/abs/10.1002/ett.4272 (accessed on 21 October 2021).
- Dannen, C. Introducing Ethereum and Solidity; Apress: Berkeley, CA, USA, 2017; Volume 318, Available online: https://link.springer.com/content/pdf/bfm%253A978-1-4842-2535-6%252F1.pdf (accessed on 21 October 2021).
- Van Leeuwen, J.; Wiedermann, J. The Turing machine paradigm in contemporary computing. In Mathematics Unlimited—2001 and Beyond; Springer: Berlin/Heidelberg, Germany, 2001; pp. 1139–1155. [Google Scholar]
- Raft Consensus Protocol. Available online: https://docs.goquorum.consensys.net/en/stable/Concepts/Consensus/Raft/ (accessed on 11 November 2021).
- Istanbul BFT. Available online: https://github.com/ethereum/EIPs/issues/650 (accessed on 11 November 2021).
- Kiayias, A.; Zindros, D. Proof-of-work sidechains. In Proceedings of the International Conference on Financial Cryptography and Data Security, Frigate Bay, Saint Kitts and Nevis, 18–22 February 2019; pp. 21–34. [Google Scholar]
- Baliga, A.; Subhod, I.; Kamat, P.; Chatterjee, S. Performance evaluation of the quorum blockchain platform. arXiv 2018, arXiv:1809.03421. [Google Scholar]
- web3.js—Ethereum JavaScript API. Available online: https://web3js.readthedocs.io/en/v1.4.0/ (accessed on 11 November 2021).
- Eventeum Source Code. Available online: https://github.com/eventeum/eventeum (accessed on 11 November 2021).
- Apache Kafka. Available online: https://kafka.apache.org/ (accessed on 11 November 2021).
- Logstash. Available online: https://www.elastic.co/es/logstash/ (accessed on 11 November 2021).
- Elasticsearch. Available online: https://www.elastic.co/es/what-is/elasticsearch (accessed on 11 November 2021).
- Kibana. Available online: https://www.elastic.co/es/kibana/ (accessed on 11 November 2021).
- Mongo DB. Available online: https://www.mongodb.com/ (accessed on 11 November 2021).
- Zookeeper. Available online: https://zookeeper.apache.org/ (accessed on 11 November 2021).
- PM2: Advanced, Production Process Manager for Node.js. Available online: https://pm2.keymetrics.io/ (accessed on 11 November 2021).
Study | Main Contribution | Main Limitations |
---|---|---|
[31] | Upgrade of an existing traditional auditing system to improve its security using Blockchain. | Lack of technical aspects specific to the Blockchain technology. |
[32] | Detailed description of how to use Blockchain for bank accountability. | Limited to banking context (broader applicability limited). Usability is not considered. |
[33,34,35,36] | Auditing mechanisms based on data recorded in traditional database/InterPlanetary File System (IPFS) systems/secure log systems + tamperproof in Blockchain. | Availability is at risk (traditional databases). Two systems are required; complexity increases (synchronization is required). |
[37] | Detailed description of how to use Blockchain for wide area protection systems | Limited application. Usability is not considered. |
[38] | Detailed description of how to use Bitcoin for secure log management. | Auditing functionality is not secure enough (Blockchain only saves data but does not execute auditing functions; an additional log server is needed). Usability is not considered. |
Requirement Name | Description |
---|---|
Inalterability (integrity) | The audit trail mechanism should provide inalterable evidence of information needed for audit purposes. |
Long-term maintenance | The audit trail mechanism must retain evidence of past information (history records). |
Assurance of origin | The origin of all data recorded in the audit system should be securely identifiable. |
Simultaneity | The audit trail mechanism should be able to support simultaneous input/output interaction from different stakeholders. |
Availability | The audit trail mechanism must have a very high availability (close to 99%). |
Confidentiality | All incoming and outgoing communications must be encrypted. |
Access control | Data recorded in the audit trail mechanism should only be provided and/or consumed by authorized users. |
Usability | The audit trail mechanism must provide a graphical and user-friendly interface. |
Multidomain | The audit trail mechanism should be used in any kind of use-case, without limiting it to a particular environment. |
Abstraction of the Blockchain | The audit trail mechanism must provide the possibility of accessing the recorded data and abstracting the Blockchain technology, thus enabling its mass adoption. |
REST API | The audit trail mechanism must provide an REST API to facilitate the input/output interaction of information sources. |
Requirement Name | How It Was Addressed |
---|---|
Inalterability (integrity) | Blockchain owns inherent characteristic of integrity (the information recorded on the Blockchain cannot be modified/altered at all). |
Long-term maintenance | Blockchain owns the inherent characteristic of long-term maintenance (the information recorded on the Blockchain cannot be erased). |
Assurance of origin | Blockchain has the inherent feature of guarantee of origin (the information recorded on the Blockchain is always associated with a specific account on the Blockchain). |
Simultaneity | Each stakeholder providing or consuming information has its own Blockchain client instance, while the Blockchain transaction supports simultaneous write and read operations. |
Availability | Blockchain networks are distributed by design; thus, high availability is guaranteed. |
Confidentiality | SSL is used in all communications. |
Access control | The auditing system is designed in such a way that only the data source can update or retrieve its own data through the DApp, while access through the Blockchain monitor client is authenticated; hence, a proper account is required to access the graphical information. Thus, data access control is guaranteed. |
Usability | Graphical information (tables) is provided in the Blockchain monitor client. |
Multidomain | The Blockchain monitor allows the recording of any kind of information thanks to the name-value pair in the data model (multisector, multidomain). |
Abstraction of the Blockchain | A Blockchain monitor is included in the audit trail system to allow users without any Blockchain account to access the Blockchain-based audit trail data. |
REST API | An REST API is implemented in the Blockchain client to facilitate the deployment, integration, and use of the auditing system by any stakeholder. |
Study | Main Limitation | Improvement |
---|---|---|
[31] | Lack of technical aspects specific to the Blockchain technology. | Detailed technical description is provided. |
[32] | Limited to banking context (broader applicability limited). Usability is not considered. | The proposed auditing system is multidomain and multisector. Usability is provided by means of the Blockchain monitor and Blockchain monitor client. |
[33,34,35,36] | Availability is at risk (traditional databases). Two systems are required; complexity increases (synchronization is required). | The auditing functionality and the registered data are only recorded on a distributed Blockchain; thus, high availability is guaranteed, and complexity is limited to the Blockchain technology. |
[37] | Limited application. Usability is not considered. | The proposed auditing system is multidomain and multisector. Usability is provided by means of the Blockchain monitor and Blockchain monitor client. |
[38] | Auditing functionality is not secure enough (Blockchain only saves data but does not execute auditing functions; an additional log server is needed). Usability is not considered. | The auditing functionality is provided through smart contracts directly registered on the Blockchain; thus, it is secure and tamper-resistant. Usability is provided by means of the Blockchain monitor and Blockchain monitor client. |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Regueiro, C.; Seco, I.; Gutiérrez-Agüero, I.; Urquizu, B.; Mansell, J. A Blockchain-Based Audit Trail Mechanism: Design and Implementation. Algorithms 2021, 14, 341. https://doi.org/10.3390/a14120341
Regueiro C, Seco I, Gutiérrez-Agüero I, Urquizu B, Mansell J. A Blockchain-Based Audit Trail Mechanism: Design and Implementation. Algorithms. 2021; 14(12):341. https://doi.org/10.3390/a14120341
Chicago/Turabian StyleRegueiro, Cristina, Iñaki Seco, Iván Gutiérrez-Agüero, Borja Urquizu, and Jason Mansell. 2021. "A Blockchain-Based Audit Trail Mechanism: Design and Implementation" Algorithms 14, no. 12: 341. https://doi.org/10.3390/a14120341