A blockchain-based log storage model with e cient query

A blockchain-based log storage model with e�cientqueryGang Xu  ( [email protected] )

North China University of Science and TechnologyFan Yun 

North China University of TechnologyYiying Yu 

North China University of TechnologyShiyuan Xu 

North China University of TechnologyXiu-Bo Chen 

Beijing University of Posts and TelecommunicationsMianxiong Dong 

Muroran Institution of Technology

Research Article

Keywords: blockchain, log storge, IPFS, Merkle tee

Posted Date: June 2nd, 2022

DOI: https://doi.org/10.21203/rs.3.rs-1331640/v1

License: This work is licensed under a Creative Commons Attribution 4.0 International License.  Read Full License

Springer Nature 2021 LATEX template

A blockchain-based log storage model with efficient query

Gang Xu1, Fan Yun1, Yiying Yu1, Shiyuan Xu1, Xiu-Bo Chen2* and Mianxiong

Dong3

1School of Information Science and Technology, North China University of Technology,Street, Beijing, 100144, State, China.

2Information Security Center, State Key Laboratory of Networking and SwitchingTechnology, Beijing University of Posts and Telecommunications, Street, Beijing, 100876,

State, China.3Muroran Institute of Technology, Organization, Street, Muroran, 050-8585, State, Japan.

*Corresponding author(s). E-mail(s): [email protected];Contributing authors: gangxu [email protected]; [email protected]; [email protected];

[email protected]; [email protected];

Abstract

The server logs play an essential role in website maintenance. When the Internet server is run-ning, the service maintained may encounter various problems, and the logs generated by the serverare the key data to locate the problems. However, the existing log storage systems are prone toa single point of failure, which may cause logs to be lost, and the problem cannot be rectified.Meanwhile, external attackers can tamper with logs to evade tracking, and the person in charge ofan accident may also tamper with the log to evade responsibility. The advantages of blockchain,such as immutability, decentralization, and security, can effectively overcome these shortcomings.In this paper, we proposed a log data storage scheme based on blockchain and InterplanetaryFile System (IPFS). The lack of scalability of blockchain for storing large files is addressed bystoring the log data stored in IPFS. Firstly, our model uses IPFS to store extensive file logdata and combines blockchain technology to realize log data storage decentralization and diffi-culty to tamper. Secondly, to improve the query efficiency of log data, we propose two improvedMerkle tree methods to provide fast queries of log data with a timestamp as query keywords.Finally, the experimental results show that the two methods have better log retrieval efficiency.

Keywords: blockchain, log storge, IPFS, Merkle tee

1 Introduction

Log data can help administrators discover vul-nerabilities in the system (Sur, 2019). The serverdowntime or malicious invasion of the server willcause the log data to be lost, and it is difficult toanalyze the reasons or investigate the responsibil-ity after the problem occurs. Sending log data to

trusted third-party management or a distributedlog system to aggregate these files is now the main-stream log storage method (He et al, 2010; Sonet al, 2017). However, these servers are vulnerableto accidental data damage or malicious attacks,not guarantee log data security. On the one hand,the management of the log database is usually per-formed by users with permissions, and semi-honest

1

Springer Nature 2021 LATEX template

users with permissions can tamper with the logdata in the log database, which cannot guaranteethe security of the log data. On the other hand,external attackers can illegally manipulate the sys-tem, and log data may be tampered with, causingeconomic losses (Faradzhullaev, 2008).

The emergence of blockchain technology pro-vides a new idea for log data storage security(Kumar et al, 2018; Nakamoto, 2008). Blockchaintechnology is now applied to various fields, such aselectronic health record Uddin et al (2021), foodtraceability Jiuliang Liu (2020), etc. The decen-tralized distributed architecture of blockchaintechnology makes it possible to establish a logstorage system independent of trusted third par-ties. However, if the log data is directly storedin the blockchain, it may limit its large-scaleapplication since the traditional blockchain haslimitations in capacity and scalability (Yue et al,2020). Recently, (Shekhtman and Waisbard, 2021)considered the storage capacity of one blockchain,uploading ample file storage to the cloud, only sav-ing the hash value of the file to the blockchain,ensuring the integrity of the file. However, theydid not guarantee the authenticity of files whenthey were compromised or maliciously tamperedwith within a cloud server. Fortunately, Interplan-etary File System (IPFS) provides a new solutionfor storing large file log data (Benet, 2014), whichprovides storage scalability and high availabilitythrough replication through generating a uniquehash value for each file. Users can obtain the file’scontent through the hash value, and the uploadeddata are almost impossible to modify and delete.

In this paper, we propose a blockchain-basedlog storage scheme, which uses IPFS to storelog data and utilizes an improved Merkle tree toimprove log query efficiency. In full generality, weoutline our contributions as follows:

Firstly, we propose a decentralized log storagescheme, which eliminates the traditional central-ized log storage scheme. This scheme utilizes IPFSto address the need to store a large number oflogs. By storing log data into the IPFS server, thestorage pressure of blockchain alleviates.

Secondly, we improve the traditional Merkletree and propose two enhanced schemes: the base-line and the enhanced method. Both of themsupport finding data by log timestamp on theblockchain.

Thirdly, we finished the simulation of theproposed two methods in the implementation.

The main structure is as follows: In section 2,we discuss work related to log storage. We design alog storage scheme based on blockchain and IPFSin section 3. Further, in section 4, we describe twomethods of the Merkle tree. Then, we comparethe query performance of the two schemes throughcomprehensive simulation in section 5. Finally, insection 6, we summarize the full text.

2 Related Works

In order to avoid the problem that centralizedlog storage is vulnerable to attack, researchershave proposed some blockchain-based log stor-age schemes. The security of log data can beprotected by using the immutability property ofblockchain (Ahmad et al, 2018; Putz et al, 2019;Xu et al, 2022). (Gursoy et al, 2020) realized thestorage and query scheme of genomic access logfiles based on the blockchain using a multi-chainplatform. In their scheme, inquirers need to down-load all data from the chain and save them inlocal memory for fast queries. To solve this prob-lem, they designed another ‘bigmem’ solution,which uses index instead of local storage for fastqueries. (Shekhtman and Waisbard, 2021) addedan additional encryption layer to the blockchain,encrypting data before data transmission to theblockchain and protecting the privacy and securityof data between authorized parties. (Pourmajidiand Miranskyy, 2018) designed a super blockchainwith two layers of hierarchical structure. Logdata is stored in a circled blockchain, includinga genesis block and a terminal block where eachsuperblock contains a circled blockchain. Obvi-ously, most existing blockchain-based log datastorage solutions mainly solve the shortage of cen-tralized log storage. In this article, we will focuson the scalability of blockchain storage and query.

Merkle tree is a data structure, which can real-ize fast data verification. Changing the value ofany leaf node causes the root to change (Buch-mann et al, 2008). Merkle tree is the main compo-nent of the blockchain and is used to store and ver-ify transactions, ensuring that the blocks are con-sistent at each node. Most mainstream blockchainframeworks have improved the Merkle tree. Bit-coin uses the traditional Merkle tree (Nakamoto,2008); Ethereum improved Bitcoin and proposed

Springer Nature 2021 LATEX template

Title 3

Merkle Patricia tree based on the characteristics ofefficient retrieval of Patricia tree (Bonneau, 2016);to reduce the cost of adding data, the Hyper-ledger combines Merkle trees and hash buckets(Androulaki et al, 2018). (Xu et al, 2017) proposedan educational certificate blockchain based on theMerkle Patricia tree, which not only can you pro-vide efficient queries but also support historicaltransaction queries. (He et al, 2020) proposeda blockchain-based verification scheme for large-scale cloud data and designed a T-tree structure,which supports binary search on the blockchain.(Yue et al, 2018) proposed a general data integrityverification framework for blockchain-based P2Pcloud storage. Some multi-branch Merkle treesbased on data shards are constructed, and theirperformance is compared.

3 System Design

3.1 System model

In the model proposed in this paper, log data arestored in IPFS, and the hash tags corresponding toeach log data are stored in the chain, which solvesthe shortage of blockchain in storing extensive filelog data. Based on this model, combined with theimproved Merkle tree, the log data with times-tamp query keywords can be quickly retrieved.The concrete implementation of the improvedMerkle tree is in section 4.

Our blockchain-based log storage systemmodel elaborates in Figure 1. The model containsthree different entities: client, IPFS server, andblockchain nodes. The clients have many log datathat need to be stored in the system safely and cansend query requests to blockchain nodes to obtainthe query results. IPFS servers store log filesreceived from the clients and generate a uniquehash for each log file. Clients and other users cansend download requests to servers or nodes accord-ing to unique hash tags to get the contents of thelog files. Blockchain stores hash values generatedby the IPFS server for data integrity verification.

Our proposed scheme includes two stages: thestorage stage and the query stage.

Storage Stage: (1) The client encrypts the logdata using symmetric encryption and signs them,and uploads the processed log data to the IPFSserver. (2) The IPFS server verifies the processedlog data to ensure the integrity of log data. The

Fig. 1 Blockchain-based log storage system model

log data is then stored, and the generated hashtags are returned to the client. (3) The client ver-ifies the correctness of hash tags with other IPFSservers. (4) The client signs the hash tags andsends the data to the blockchain node. (5) Theblockchain node sends a comparison tags verifica-tion request to the IPFS node to verify whetherthe sender of tags is the same as the log dataholder in IPFS.

Query Stage: (6) The client sends log queryrequests to a blockchain node. (7) The blockchainnode query the corresponding log hash tag accord-ing to the request, then return the data proofand query results to the client. (8) The client ver-ifies the correctness of the data proof to otherblockchain nodes. If the data proof proves that thehash tag is intact, the client downloads data fromthe IPFS server node using the hash tag; other-wise, it indicates that the data tag is incompleteand may be tampered with.

In data transmission, a cryptography algo-rithm is used to ensure the authenticity, reliabilityand integrity of information transmission. Thesender of the data has to sign the hash valueof the data. If the data is tampered with dur-ing transmission, the verification signature willnot pass, and the data will not be trusted. Inthe storage stage, the Practical Byzantine FaultTolerance (PBFT) algorithm is used to completethe consensus process of data blocks (Castro andLiskov, 2002). Suppose there are blockchain nodesto compose a consensus system, the PBFT algo-rithm provides the fault-tolerant capability of f =(n − 1)/3 , that is, the number of failed or mali-cious nodes cannot exceed 1/3 of all nodes. IPFSguarantees the integrity of log data.

Springer Nature 2021 LATEX template

3.2 The Improved Blockchain

Storage Structure

In our scheme, hash tags generated from log dataare packaged into blocks by blockchain nodes. Inorder to adapt to the application scenario wherelog data needs to be queried by timestamp, thispaper extends the block structure, as shown inFigure 2.

Fig. 2 The improved blockchain architecture

Each block is composed of a block head and ablock body (Nofer et al, 2017). The block headercontains the hash value of the previous block, thetimestamp when generating the block, the Merkleroot, block height, and the log start and end timeof the transaction list in the block. The data in thetransaction list is sorted by log generation time,all of which are stored in the k-v database.

We added the start time and end time ofthe transaction in the transaction list of theblockchain to the original block header data toimprove the search efficiency of the timestampkeyword on the chain. Due to network delay andupload speed, the start time of logs in the currentblock may be shorter than the end time of theprevious block. Given a timestamp, the block con-taining the timestamp is determined by scanningall the block headers on the blockchain.

4 The Improved Merkle Tree

The transaction data for each block in theblockchain is stored as a Merkle tree. One featureof the Merkle tree is that given a Merkle path, itcan quickly verify whether a transaction is in the

transaction list. However, when a client wants toquery a transaction by keyword, the blockchainnode needs to traverse all the transaction datastored in the Merkle tree. As the transaction datain the block increases, the time it takes to query atransaction record on the blockchain increases dra-matically. In order to reduce memory and improvequery efficiency, the nodes of the Merkle tree areimproved in our method. Our method containsthe Merkle tree validation features (the client canverify that a transaction is included in the trans-action list without downloading all transactions inall blocks) but also improve the timestamp key-word query efficiency on the blockchain and themethods support the timestamp range query. Inthis section, we describe in detail the structure ofthe two improved Merkle trees and give the times-tamp point query algorithm and timestamp rangequery algorithm.

4.1 The Baseline Method

The baseline method combines the characteristicsof binary search and Merkle tree, and its nodestructure is shown in Figure 3. There are twotypes of nodes in this method: branch nodes andleaf nodes. A branch node Bnode of the baselinemethod consists of the minimum log timestampvalue Min, maximum log timestamp value Max,the hash values of the left subtrees LeftChild andright subtrees RightChild. A leaf node Lnode con-tains the transaction value TX and the generationtimestamp LogT ime of the log data in the trans-action. In this method, all nodes are stored in thek − v database, where v is all data connectionsof nodes and k is obtained by the hash algorithmHash(v).

Fig. 3 Basic baseline method data types

In tree constructions, leaf nodes are first con-structed according to the transaction list andsaved in the database. Then, starting at the bot-tom of the tree, a new branch node is constructedlayer by layer by two nodes of the tree, and if thereis an odd number of branch nodes in a layer, thelast branch node is copied until the last is the root

Springer Nature 2021 LATEX template

Title 5

node. In a branch node, if its child node is a branchnode, Min is the left child’s Min, and Max is theright child’s Max; if its child node is the leaf node,and its Min and Max are the LogT ime of the leafnode.

In the query stage of the blockchain-based logstorage model, when a client requests a times-tamp single point query of a blockchain node,the blockchain node invokes the query algorithmto search for transaction data. The client sendsa timestamp T to the blockchain node. If T isnot within the time range of the blockchain, thealgorithm returns a null value. Otherwise, findthe blocks where T is located by the start andend times in the block header. Then, based onthe hash value of the root of the Merkle tree inthe block header, the search algorithm is calledto obtain TX. In the search process, the tra-versed nodes are Merkle path, and the blockchainnodes return Merkle path and search results to theclient. The Merkle path allows the client to deter-mine whether the transaction is on the blockchainquickly. The timestamp point query algorithm forthe baseline method is as follows:

Algorithm 1 Timestamp Point Query Algorithm

Require: timestamp T , Merkle root Root1: nodes=stack()2: nodes.append(GetNode(Root))3: while nodes is not empty do

4: Plist.append(nodes[-1])5: node= nodes.pop()6: if node is leaf node and node.Min==T

then

7: Hlist.Add(GetValue(node.leftChild))8: else if T ≥

GetNode(node.leftChild).Max then

9: nodes.append(GetNode(node.rightChild))10: else if T ≤

GetNode(node.rightChild).Min then

11: nodes.append(GetNode(node.leftChild))12: end if

13: end while

14: return Hlist, Plist

According to the timestamp keyword queryfeature of log data, when the client sends thestart and ends time of the log to the blockchain

node, the blockchain node returns the correspond-ing query results. Gives a start timestamp T sand an end timestamp Te, timestamp range queryalgorithm returns the hash tag list within thattimestamp range. Assuming that the timestampranges of each block have no intersection, theblocks containing T s and Te are found from theblockchain. From these blocks, we can call thequery algorithm to get hash tag list, according tothe following conditions:

Case1: Ts and Te are in the same block, callquery algorithm.

Case2: Ts and Te are in different blocks. Theblock transaction list in the middle of the twoblocks is added to the hash tag list. The queryalgorithm is then called on both blocks.

The following query algorithm is given tosearch for transactions within a given timestamprange in a block:

Algorithm 2 Timestamp Range Query Algo-rithmRequire: start timestamp Ts, end timestamp

Te, Merkle root Root1: nodes=queue()2: nodes.append(Root)3: while nodes is not empty do

4: node = nodes.get()5: if node is leaf node then

6: Hlist.Add(GetValue(node.leftChild))7: Plist.append(nodes[-1])8: else

9: leftChild = GetNode(node.leftChild)10: rightChild =

GetNode(node.rightChild)11: if Ts or Te ≤ leftChild.Max then

12: nodes.append(GetNode(node.leftChild))13: Plist.append(nodes[-1])14: end if

15: if Ts or Te ≥ leftChild.Max then

16: nodes.append(GetNode(node.rightChild)

17: Plist.append(nodes[-1])18: end if

19: end if

20: end while

21: return Hlist, Plist

Springer Nature 2021 LATEX template

4.2 The Enhanced Method

In the enhanced method, we combine the prefixtree and the Merkle tree to improve the baselinescheme. In this method, we take the log gener-ation time to build a prefix tree. The maximumheight of the improved tree is the length of theUnix timestamp under decimal. The basic nodes ofthe enhanced method are composed of two nodes:branch node, leaf node as shown in Figure 4. Abranch node Bnode is a node with a child setchildi, i ∈ [0, 9] and a prefix value Prefix. A leafnode Lnode consists of a prefix value and a trans-action list TXj , j ∈ [0,m], transactions in eachleaf node have the same log generation time.

Fig. 4 Basic enhanced method data types

Similar to the baseline, the input of the treeconstructions algorithm is a list, and the output isthe hash value of the root node, except that the listelement UT is A Unix timestamp. Transactionswith the same log timestamp are stored in thesame leaf node, which greatly reduces the numberof nodes that need to be traversed based on thetimestamp keyword.

Algorithm 3 Timestamp Point Query Algorithm

Require: timestamp UT , Merkle root Root1: node=GetNode(Root)2: while node is not leaf node do

3: if UT[len(node.prefix)] in node.childrenthen

4: Plist.append(node)5: node= node.getChild(UT [len(node.prefix)])6: else

7: return null8: end if

9: end while

10: if node.prefix==UT then

11: for tx in node.txes do

12: Hlist.append (tx)13: end for

14: end if

15: return Hlist, Plist

In the timestamp range query algorithm,whether the prefix of the node is within thegiven time range is determined. The algorithm isdescribed in detail as follows:

Algorithm 4 Timestamp Range Query Algo-rithmRequire: start timestamp Ts, end timestamp

Te, the Merkle root Root1: nodes=queue()2: nodes.append(Root)3: while nodes is not empty do

4: for temp in range(nodes.size())) do5: node = nodes.popleft()6: for childNode in node.childrenNode

do

7: if Ts [:len(prefix)] ≤ childNode.prefix ≤ Te[:len(prefix)] then

8: if childNode is leaf node then

9: for tx in childNode.txes do10: Hlist.append(tx)11: end for

12: else

13: nodes.append(childNode)14: end if

15: Plist.append(childNode)16: end if

17: end for

18: end for

19: end while

20: return Hlist, Plist

5 Experiments

The experiment was performed on Windows 10.The main hardware configuration is as follows:CPU: Intel(R) Core (TM) i7-4720HQ 2.60GHz;RAM:16GB. This paper mainly studies how toimprove the blockchain structure and Merkle treeto improve the search efficiency on the blockchain.Consequently, we have not conducted experimentson clusters.

In this paper, we implemented the twoimproved methods using the python language andcompared them with the Merkle tree of Yue’sscheme [22]. Yue’s scheme [22] constructs somemulti-branched Merkle trees based on data shards,each tree needs to download all the transactions in

Springer Nature 2021 LATEX template

Title 7

the block to be queried, so we only design a com-prehensive comparison experiment between theBinary Branching tree (BBT) and our methods.We compare the storage structures of blockchainin terms of tree construction complexity, times-tamp point query, and range query overhead. Werandomly generated one hundred thousand logdata, uploaded it to the IPFS server in the privatenetwork, and uploaded the hash tags of these logsto blockchain for an experiment. Each block con-tains the Merkle root of BBT, the baseline, andthe enhanced method.

Firstly, we compare the tree generation effi-ciency versus the number of the size of the trans-action list. Assuming that the block’s transactionlist is from 256 to 8192 (256, 512, 1024, 2048, 4096,8192). From Figure 5, we can see that the twoimproved methods’ tree construction efficiency islower than BBT. Due to the two methods, weproposed storing all nodes in the database dur-ing the construction process. Furthermore, in theenhanced method, the prefix value of log gener-ation time for all transactions is different in theworst case, resulting in a much larger number ofnodes than the other methods.

Fig. 5 The comparison of methods and BBT build cost

Secondly, we compare the query efficiency.Considering that timestamps are often used askeywords when searching for logs, we compare thetime consumption of point query and range query.We experimented on the blockchain generatedby the tree construction experiment, randomlyquerying 10,000 times and recording the averagequery time. As shown in Figure 6, the baselineand enhanced methods do not require all transac-tions to be read in, so timestamp point query timesare much lower than BBT. As shown in Figure7, two methods also have higher query efficiency

in timestamp range queries. Fewer tree nodes aregenerated in the enhanced approach, so it takesless time to query than the baseline method.Therefore, it can be observed that both methodshave better query performance than BBT.

Fig. 6 The comparison of methods and BBT point querycost

Fig. 7 The comparison of methods and BBT range querycost

In our methods, we build a tree with the times-tamp as the keyword and store each node in thedatabase, so the build time of the tree is more pro-tracted than BBT. However, the query overheadis lower than BBT because we have added fieldsto each node to enable efficient searching.

6 Conclusions

This paper proposes a log data storage schemebased on blockchain and IPFS. This scheme effec-tively solves the problem of insufficient scalabilityof blockchain by storing log data in IPFS andhash tags in the blockchain. The structure of themodel is introduced and analyzed. Aiming at the

Springer Nature 2021 LATEX template

requirement that logs need to be queried by times-tamp, we design two improved methods basedon the Merkle tree to improve the query rate oflogs by timestamp. Experiments show that thetwo improved methods proposed in this paper caneffectively improve the search performance of thequery log according to the timestamp.

Author Contributions Conceptualization,Methodology, Validation, Investigation, Writ-ing, Funding acquisition, Formal analysis by G.Xu and F. Yun. Collected data, Data analysis,Review by Y.Y. Yu and S.Y. Xu. Funding acqui-sition, Visualization, Writing -Review & Editing,Supervision by X. B. Chen and M. X. Dong. Allauthors read and approved the final manuscript.

Funding This work was supported by the OpenFund of Advanced Cryptography and SystemSecurity Key Laboratory of Sichuan Province(Grant No. SKLACSS-202101), NSFC (GrantNos. 62176273, 61962009, U1936216), the Fun-damental Research Funds for Beijing MunicipalCommission of Education, Beijing Urban Gov-ernance Research Base of North China Univer-sity of Technology, the Natural Science Founda-tion of Inner Mongolia (2021MS06006), BaotouKundulun District Science and technology planproject (YF2020013), and Inner Mongolia disci-pline inspection and supervision big data labora-tory open project fund (IMDBD2020020).

Declarations

Conflict of interest All authors declare thatthey have no conflict of interest.

Ethical approval This article does not containany studies with human participants or animalsperformed by any of the authors.

Informed consent Informed consent wasobtained from all individual participants includedin the study.

References

Ahmad A, Saad M, Bassiouni MA, et al (2018)Towards blockchain-driven, secure and trans-parent audit logs. In: Schulzrinne H, Li P (eds)

Proceedings of the 15th EAI International Con-ference on Mobile and Ubiquitous Systems:Computing, Networking and Services, MobiQui-tous 2018, 5-7 November 2018, New York City,NY, USA. ACM, pp 443–448, https://doi.org/10.1145/3286978.3286985

Androulaki E, Barger A, Bortnikov V, et al(2018) Hyperledger fabric: a distributed oper-ating system for permissioned blockchains. In:Oliveira R, Felber P, Hu YC (eds) Proceed-ings of the Thirteenth EuroSys Conference,EuroSys 2018, Porto, Portugal, April 23-26,2018. ACM, pp 30:1–30:15, https://doi.org/10.1145/3190508.3190538

Benet J (2014) IPFS - content addressed, ver-sioned, P2P file system. CoRR abs/1407.3561

Bonneau J (2016) Ethiks: Using ethereum to audita CONIKS key transparency log. In: Clark J,Meiklejohn S, Ryan PYA, et al (eds) Finan-cial Cryptography and Data Security - FC 2016International Workshops, BITCOIN, VOTING,and WAHC, Christ Church, Barbados, Febru-ary 26, 2016, Revised Selected Papers, Lec-ture Notes in Computer Science, vol 9604.Springer, pp 95–105, https://doi.org/10.1007/978-3-662-53357-4 7

Buchmann J, Dahmen E, Schneider M (2008)Merkle tree traversal revisited. In: Buchmann J,Ding J (eds) Post-Quantum Cryptography, Sec-ond International Workshop, PQCrypto 2008,Cincinnati, OH, USA, October 17-19, 2008,Proceedings, Lecture Notes in Computer Sci-ence, vol 5299. Springer, pp 63–78, https://doi.org/10.1007/978-3-540-88403-3 5

Castro M, Liskov B (2002) Practical byzantinefault tolerance and proactive recovery. ACMTrans Comput Syst 20(4):398–461. https://doi.org/10.1145/571637.571640

Faradzhullaev R (2008) Analysis of web server logfiles and attack detection. Autom Control Com-put Sci 42(1):50–54. https://doi.org/10.1007/s11950-008-1008-y

Gursoy G, Bjornson R, Green ME, et al (2020)Using blockchain to log genome dataset access:efficient storage and query. BMC Medical

Springer Nature 2021 LATEX template

Title 9

Genomics 13(Suppl 7)

He K, Shi J, Huang C, et al (2020) Blockchainbased data integrity verification for cloud stor-age with t-merkle tree. In: Qiu M (ed) Algo-rithms and Architectures for Parallel Processing- 20th International Conference, ICA3PP 2020,New York City, NY, USA, October 2-4, 2020,Proceedings, Part III, Lecture Notes in Com-puter Science, vol 12454. Springer, pp 65–80,https://doi.org/10.1007/978-3-030-60248-2 5

He S, Liu G, He Z, et al (2010) Design andimplementation of log management modulein three-dimensional spatial database man-agement system. In: The 18th InternationalConference on Geoinformatics: GIScience inChange, Geoinformatics 2010, Peking Uni-versity, Beijing, China, June, 18-20, 2010.IEEE, pp 1–5, https://doi.org/10.1109/GEOINFORMATICS.2010.5567648

Jiuliang Liu KSXingming Sun (2020) A foodtraceability framework based on permissionedblockchain. Journal of Cyber Security 2(2):107–113. https://doi.org/10.32604/jcs.2020.011222

Kumar M, Singh AK, Kumar TVS (2018) Securelog storage using blockchain and cloud infras-tructure. In: 9th International Conference onComputing, Communication and NetworkingTechnologies, ICCCNT 2018, Bengaluru, India,July 10-12, 2018. IEEE, pp 1–4, https://doi.org/10.1109/ICCCNT.2018.8494085

Nakamoto S (2008) Bitcoin: A peer-to-peer elec-tronic cash system. consulted

Nofer M, Gomber P, Hinz O, et al (2017)Blockchain. Bus Inf Syst Eng 59(3):183–187.https://doi.org/10.1007/s12599-017-0467-3

Pourmajidi W, Miranskyy AV (2018) Logchain:Blockchain-assisted log storage. In: 11th IEEEInternational Conference on Cloud Computing,CLOUD 2018, San Francisco, CA, USA, July 2-7, 2018. IEEE Computer Society, pp 978–982,https://doi.org/10.1109/CLOUD.2018.00150

Putz B, Menges F, Pernul G (2019) A secureand auditable logging infrastructure based ona permissioned blockchain. Comput Secur 87.

https://doi.org/10.1016/j.cose.2019.101602

Shekhtman LM, Waisbard E (2021) Engravechain:A blockchain-based tamper-proof distributedlog system. Future Internet 13(6):143. https://doi.org/10.3390/fi13060143

Son S, Gil M, Moon Y (2017) Anomaly detec-tion for big log data using a hadoop ecosys-tem. In: 2017 IEEE International Conferenceon Big Data and Smart Computing, BigComp2017, Jeju Island, South Korea, February 13-16, 2017. IEEE, pp 377–380, https://doi.org/10.1109/BIGCOMP.2017.7881697

Sur C (2019) Deepseq: learning browsing log databased personalized security vulnerabilities andcounter intelligent measures. J Ambient IntellHumaniz Comput 10(9):3573–3602. https://doi.org/10.1007/s12652-018-1084-9

Uddin M, Memon MS, Memon I, et al(2021) Hyperledger fabric blockchain: Secureand efficient solution for electronic healthrecords. Computers, Materials and Continua68(2):2377–2397

Xu G, Cao Y, Xu S, et al (2022) A novelpost-quantum blind signature for log systemin blockchain. Computer Systems Science andEngineering 41(3):945–958. https://doi.org/10.32604/csse.2022.022100

Xu Y, Zhao S, Kong L, et al (2017) ECBC: A highperformance educational certificate blockchainwith efficient query. In: Hung DV, KapurD (eds) Theoretical Aspects of Computing -ICTAC 2017 - 14th International Colloquium,Hanoi, Vietnam, October 23-27, 2017, Proceed-ings, Lecture Notes in Computer Science, vol10580. Springer, pp 288–304, https://doi.org/10.1007/978-3-319-67729-3 17

Yue C, Xie Z, Zhang M, et al (2020) Analysisof indexing structures for immutable data. In:Maier D, Pottinger R, Doan A, et al (eds) Pro-ceedings of the 2020 International Conferenceon Management of Data, SIGMOD Conference2020, online conference [Portland, OR, USA],June 14-19, 2020. ACM, pp 925–935, https://doi.org/10.1145/3318464.3389773

Springer Nature 2021 LATEX template

Yue D, Li R, Zhang Y, et al (2018) Blockchainbased data integrity verification in P2P cloudstorage. In: 24th IEEE International Conferenceon Parallel and Distributed Systems, ICPADS2018, Singapore, December 11-13, 2018. IEEE,pp 561–568, https://doi.org/10.1109/PADSW.2018.8644863