# SASLedger: A Secured, Accelerated Scalable Storage Solution for Distributed Ledger Systems
## 7 Conclusions  
In this paper, a secured and accelerated scalable storage solution for blockchain systems is proposed. Our solution relieves the storage burden of blockchain nodes by adding an off-chain remote DB server for each CU in blockchain network to store the blocks while ensuring data integrity. Our solution also improves the performance compared to our previous work by separating the data-deduction operation from the transaction-processing phase. Experiments show that our solution can reduce the size of block files for peers by 93.3% compared to the original HLF blockchain system and that our solution enhances the TPS by 9.6% compared to xFabLedger.  
Our solution can be applied in blockchain systems constructed with HLF to enhance its storage scalability by simply replacing the vanilla HLF peers with the modified SASLedger peers and deploying the remote DB server. For conventional HLF blockchain systems, if the storage spaces of peers are insufficient, additional hard disks need to be installed to each peer; however, in a SASLedger blockchain system, new hard disks only need to be installed in the remote DB server, which reduces the budget.  
There are several limitations left in our solution:  
* Retrieving blocks or transactions from the remote DB server is slower than retrieving them from the local file system of a peer, thus our solution leads to a decrease of the query performance.
* The data-reduction phase of our solution depends on the snapshot operation of HLF, since the commitment of transactions are stopped when taking the snapshot, the performance is decreased due to the snapshot operation.  
In the future, we would like to study the mechanism of the local databases of HLF peers to solve the read-write conflict problem when exporting the contents of the local  
Figure 9: Query latency comparison: HLF, xFabLedger, and SASLedger. When using SASLedger, for a block stored in the local file system of a peer, the time to query it and the transactions therein is similar to the time cost when using HLF, while for a block that has been transmitted to the remote DB server, the query latency is similar to that when using xFabLedger.  
databases. This may accelerate the current snapshot generation process by keeping the commitment of transactions unstopped when a snapshot is taken.  
Conceptualization, B.P., J.S. and H.S.; methodology, H.S. and B.P.; software, H.S.; validation, H.S. and B.P.; formal analysis, B.P.; investigation, H.S. and B.P.; resources, H.S. and B.P.; data curation, B.P.; writing--original draft preparation, H.S.; writing--review and editing, B.P., J.S., T.M. and M.M.; visualization, H.S.; supervision, J.S.; project administration, B.P. All authors have read and agreed to the published version of the manuscript.  
This research received no external funding.  
Not Applicable, the study does not report any data.  
The authors declare no conflict of interest.  
The following abbreviations are used in this manuscript:  
\begin{tabular}{l l} DB & Database \\ HLF & Hyperledger Fabric \\ Org & Organization \\ OSN & Ordering Service Nodes \\ BlkNum & Block Number \\ BlkHash & Block Hash \\ Tx & Transaction \\ PBFT & Practical Byzantine Fault Tolerant \\ VC & Vector Commitment \\ CU & Consensus Unit \\ BAO & Blocks Assignment Optimization \\ TPS & Transactions Per Second \\ OS & Operating System \\ CPU & Central Processing Unit \\ SSD & Solid-State Driver \\ GB & Gigabytes \\ MB & Megabytes \\ \end{tabular}