An Optimized Encryption Storage Scheme for Blockchain Data Based on Cold and Hot Blocks and Threshold Secret Sharing
Abstract
:1. Introduction
- Collaborative Storage: This aims to form a whole by integrating multiple storage nodes with limited capacity so as to complete the functions of a full node in a blockchain system. Literature [2] provides a detailed introduction to a distributed storage load balancing scheme based on distributed hash table technology that effectively utilizes a subset of nodes in the Bitcoin network to construct a distributed hash table cluster. In this cluster, each node can play the role of a full node, and it verifies new transactions by referencing other nodes, thus significantly reducing the need to store the entire blockchain. Literature [3] then proposes an innovative concept called a consensus unit to address the problem of limited storage scalability in blockchain systems. By constructing consensus units, the scheme significantly reduces the storage space required by each node. Furthermore, literature [4] demonstrates the storage engine BFT-Store, which significantly enhances storage scalability by combining the Reed–Solomon coding technique with the Byzantine fault-tolerance (BFT) consensus protocol. In BFT-Store, nodes only need to store the encoded fragments of each data block rather than the complete ledger, thereby achieving a significant reduction in the storage consumption of each data block and achieving O(1) storage efficiency.
- Lightweight node model: As a different existence form from full nodes, its distinctive feature is that it does not need to store a complete copy of the ledger. Compared with full nodes that need to synchronize all block data, lightweight nodes adopt a more efficient strategy. Among them, the simple payment verification (SPV) protocol, as the first lightweight node protocol proposed, provides a simplified method for resource-constrained nodes by only storing the block headers of all blocks to achieve transaction verification. However, as the blockchain block height continues to grow, the SPV lightweight node, although it only needs to store the block headers, will also face the challenge of saturation of its storage space. At the same time, the SPV lightweight node still needs to rely on the data support provided by full nodes during the transaction verification process. In view of this situation, the academic community has conducted in-depth exploration, and a new public chain protocol was proposed in literature [5] that is particularly suitable for devices with limited storage resources. The protocol innovatively requires resource-constrained nodes to only store fixed-length data that are unrelated to the block height, thus abandoning the traditional practice of storing the block headers of each block. This further improves the efficiency and feasibility of lightweight nodes.
- IPFS-based off-chain storage mechanism: InterPlanetary File System (IPFS) is a peer-to-peer network primarily used for data storage and access. It abandons the traditional addressing method based on server location and instead assigns unique encrypted hashes to dissimilar storage files, achieving a content-based addressing mechanism [6]. Literature [7] introduces a distributed architecture based on blockchain, aiming to securely share event information between roadside units without relying on trusted third-party cloud servers. Literature [8] proposes an electronic health record secure storage system that combines IPFS and blockchain, aiming to ensure the confidentiality of patient records while maintaining their integrity. Additionally, the system implements a role-based access control mechanism to reduce the risk of malicious intrusion. Literature [9] designs an online review system based on the Ethereum blockchain and IPFS. The system stores reviews using IPFS hash addresses on connected computer nodes, enhancing trust between reviewers and service providers while improving the performance of the review system.
- Cloud-based off-chain storage: Literature [10] provides a detailed description of a lightweight decentralized encryption cloud storage architecture named Yugula. The architecture utilizes convergent encryption technology to encrypt files and innovatively stores the hash value of the file on the blockchain, thus achieving the decoupling of label and encrypted file association. This innovative design allows all users to effectively query the encrypted data in the cloud environment. Literature [11] then proposes a solution to optimize the node storage burden, allowing each node to store the old blocks created earlier and with a lower query probability in the cloud, which significantly reduces the storage pressure on nodes and effectively avoids the potential risks of block overflow. Furthermore, literature [12] introduces the concept of transparent integrity auditing and builds a blockchain-based mechanism for the secure transparent elimination of duplicate data. The solution not only supports the deduplication of encrypted data but also grants users the ability to verify duplicate data on the cloud server, thus ensuring that the data content is not interfered with by non-owners.
- We have proposed an optimized blockchain data storage architecture that combines cloud storage with cold and hot block strategies. A hot block refers to blocks that are frequently accessed and will be stored on the blockchain node while a cold block refers to blocks that are hardly accessed and are stored in cloud storage. By integrating on-chain and off-chain storage optimization methods, we have introduced a block heat assessment algorithm to evaluate the heat of block data, thereby reducing the storage burden on blockchain nodes.
- We have proposed an encryption storage scheme based on threshold secret sharing that utilizes symmetric encryption algorithms to encrypt blockchain data. The scheme divides the encryption key into multiple fragments using threshold secret sharing technology and stores them in various nodes within the network. Furthermore, the fragmented key undergoes secondary encryption using the public key of an asymmetric encryption algorithm before being stored. This approach effectively increases the cost for attackers attempting to access blockchain data and mitigates issues such as weak password attacks.
2. Related Work
2.1. Cloud Storage
2.2. Threshold Secret Sharing
- The Shamir threshold secret sharing scheme [24]: By constructing a t − 1 degree polynomial and setting the secret as the constant term of the polynomial, the secret is divided into n parts and distributed to n participants.
- Blakley’s threshold secret sharing scheme [25]: This utilizes points in a multi-dimensional space to establish a threshold scheme, where the shared secret is represented as a point in a t-dimensional space and each sub-secret corresponds to the equation of a (t − 1)-dimensional hyperplane containing this point.
2.3. Decentralized Identifiers
3. Optimized Storage Architecture
- The parameters to be tracked within the n round of block generation in the blockchain system include the number of proposals contained in each block, the content of each proposal within a block, and the historical query records associated with each proposal within a block.
- According to the block parameters, the block feature values are extracted, and the actual size, intrinsic value, historical heat, and hidden heat of each block are calculated based on the block parameters statistically obtained in Step 1. The definitions and calculation methods of the four feature values are described in Section 2.
- Determine the heat level of the block, set a heat threshold value, select an appropriate set of feature weight coefficients based on the needs of the actual application scenario, calculate the comprehensive heat level of the block based on the evaluation algorithm, and make a heat judgment. Blocks with heat levels exceeding the heat threshold are considered hot blocks, while those below the threshold are considered cold blocks.
- After the block heat judgement is completed, the judgement results are fed back to the blockchain system, and the blocks with combined heat exceeding the heat threshold are considered hot blocks; otherwise, they are cold blocks.
- Data are encrypted using a symmetric encryption algorithm, and the symmetric encryption key is distributed for storage using a threshold secret sharing scheme.
- Blocks that are judged by the decider to be cold are offloaded to the cloud storage system and only the block header and the hash value of the encrypted data are stored in the blockchain node. The storage location of the cold block is determined by the consistent hash algorithm based on the hash value of the block so that the client can easily query the cold block data.
- The client sends a query request to retrieve data within a block, but since there may be Byzantine nodes in the blockchain system, the query request needs to be broadcast to all the blockchain replica nodes. Let us assume that there are n nodes in the blockchain system, and f of them are Byzantine nodes, where f < n/3. The client can consider that it has received the correct data once it receives f + 1 identical feedback results.
- Each node in the blockchain system receives a query request from the client and performs a judgment. If the query content is within the hot block, it jumps to step 11 and returns the query result. If the query content is within the cold block, it calculates the location where the cold block is stored using the consistency hash algorithm to obtain the encrypted data of the cold block.
- When a cloud storage receives a request from a blockchain replica node to retrieve cold block encrypted data, it returns the cold block encrypted data.
- In the blockchain system, the integrity of cold block encrypted data is verified internally, and only after the data integrity verification is completed can the data be returned to the client.
- In a blockchain system, each replica node uses a symmetric encryption key to decrypt the data and then feeds the decrypted data back to the client. The client can consider that it has received the correct data once it receives f + 1 identical feedback results.
4. Block Heat Evaluation Algorithm
- –
- Block size (BS);
- –
- Block value (BV);
- –
- Block historical heat (BHH);
- –
- Block correlation heat (BCH).
4.1. Block Size
4.2. Block Value
4.3. Block Historical Heat
4.4. Block Correlation Heat
Algorithm 1: Block Heat Evaluation Algorithm |
Input: BLOCK = {B1, B2, …, Bn}, BW = (a1, a2, a3, a4), RU, DTV |
Output: BH = {BH1, BH2, …, BHn} |
1: initialization BS, BV, BHH, BCH, TS, TR |
2: for each Bi in BLOCK do |
3: Record the block size BSi |
4: Record the query time tqi |
5: TQ ← {tq1, tq2, …, tqn} |
6: Tnow ← time now |
7: for each Tj in Bi do |
8: Record the trade value TVj |
9: Record the trade sender TSj |
10: Record the trade receiver TRj |
11: end for |
12: TSi ← {TS1, TS2, …, TSj} |
13: TRi ← {TR1, TR2, …, TRj} |
14: |
15: |
16: end for |
17: for each Bm in BLOCK do |
18: for each Bj in BLOCK do |
19: if m! = j then |
20: |
21: end if |
22: end for |
23: |
24: end for |
25: F S ← [BS, BV, BHH, BCH] |
26: BH ← FS · BWT |
27: for i = 1 to n do |
28: if BHHi >= DT V then |
29: BLOCKi is a hot block |
30: else |
31: BLOCKi is a cold block |
32: end if |
33: end for |
5. An Encryption Storage Scheme Based on Threshold Secret Sharing
5.1. Scheme Design
Algorithm 2: Encryption Algorithm based on Secret Sharing |
Input: s, t, n, E, k, G, H |
Output: C |
1: initialization ai = {a0, a1, …, at−1}, uj = {u1, u2, …, un} |
2: uj = random(), j = 1, 2, …, n |
3: Construction t−1 polynomial f(x) = s + |
4: , j = 1, 2, …, n |
5: Pj ← (uj, pj) |
6: Mj = Encode(Pj) |
7: Q = k · G |
8: r = random(0, H) |
9: C1j = Mj + r · Q |
10: C2j = r · G |
11: C = {(C11, C21), (C12, C22), …, (C1n, C2n)} |
Algorithm 3: Encryption Algorithm based on Secret Sharing |
Input: C = {(C11, C21), (C12, C22), …, (C1n, C2n)}, k |
Output: s |
1: After collecting t secret key fragments |
2: Mj = C1j − k · C2j, j = 1, 2, …, t |
3: Pj = Decode(Mj) |
4: (uj, pj) ← Pj |
5: pj = a0 |
6: |
7: Solving matrix A = {a0, a1, … at−1} |
8: s = a0 |
5.2. The Process of Encrypting and Storing Blockchain Data
- The client submits a proposal, and the information that the client needs to submit includes transaction information, the DID identifier of the user, a list of DID identifiers that allow for access to the transaction data, and a list of public keys, where the transaction information is the data that the client needs to store on the blockchain for the nodes to reach consensus and store, the DID identifier of the user will be assigned to the creator DID field in the block header data, which represents the ownership of the data, the list of DID identifiers that allow access to the transaction data will be assigned to the DID list field in the block header data, which represents the DID identity authentication information of the other users who are allowed to access the data, the list of public keys includes the public key of the user submitting the transaction and the public key of the other users who are allowed to access the transaction data, and the user submitting the transaction can update the DID identifier list and the list of public keys data. Because there may be Byzantine nodes in the blockchain system, in order to ensure the effectiveness of the on-chain operation, the client needs to broadcast this information to all blockchain nodes.
- The blockchain nodes achieve consensus on the information submitted by clients using consensus protocols such as PBFT and Hotstuff or QuickBFT [36]. Upon reaching consensus, the data are stored using the proposed encrypted storage scheme in this study, and the key is fragmented for distributed storage.
- After the consensus and storage of blockchain nodes are completed, the results are fed back to the client. When the client receives more than f + 1 successful feedback, it is considered that the client’s proposal has been successfully recorded on the blockchain. The number of nodes in the blockchain is n = 3f + 1.
5.3. The Process of Obtaining Encrypted Data on a Blockchain
- Users submit data query requests, which require the following data to be submitted: data index information, user DID identifier, and the encrypted DID identifier using the user’s private key. The data index information is used to locate the block, including the query block height, block hash value, and the creator’s DID information. Due to the possible Byzantine nodes in the blockchain system, to ensure the effectiveness of data query operations, users need to broadcast data query requests to all blockchain nodes.
- When a blockchain node receives a data query request from a user, it locates the specific block position based on the data indexing information, searches for the user’s DID identifier in the DID list in the block header, and skips to step 5 if it is not found. If it exists, it searches for the corresponding public key of the user in the DID list and decrypts the DID identifier encrypted by the user’s private key using the user’s public key. Then, it searches for the identifier in the DID document and verifies its authenticity. The DID document is stored in a distributed manner in a location that everyone can control, making it easy to find.
- The DID document returns the search results, and if the user’s DID identifier does not exist, it jumps to step 5.
- Blockchain nodes broadcast key fragments of the queried block, and nodes aggregate the key fragments and decrypt the block data based on the decryption scheme based on the threshold secret sharing described in this study.
- If the DID identifier is not found in the DID list or the DID document does not contain the user’s DID identifier, the result will be a query failure. Otherwise, the block data to be queried will be returned.
6. Experimental Analysis
6.1. Storage Performance Analysis
6.1.1. Storage Load Test
6.1.2. Analysis of Block Query Efficiency
6.1.3. Analysis of Encryption Storage Efficiency
6.2. System Security Analysis
6.2.1. Data Security Analysis
6.2.2. Analysis of Resistance to Weak Password Attacks
6.2.3. Analysis of Resistance to Collusion Attacks
7. Conclusions
Author Contributions
Funding
Data Availability Statement
Conflicts of Interest
References
- Yin, B.; Li, J.; She, Y.; Wei, X. Reducing Storage Requirement in Blockchain via Node-Oriented Block Placement. IEEE Trans. Netw. Sci. Eng. 2024, 11, 64–76. [Google Scholar] [CrossRef]
- Abe, R.; Suzuki, S.; Murai, J. Mitigating Bitcoin Node Storage Size By DHT. In Proceedings of the Asian Internet Engineering Conference, AINTEC 2018, Bangkok, Thailand, 12–14 November 2018; pp. 17–23. [Google Scholar]
- Xu, Z.; Han, S.; Chen, L. CUB, a Consensus Unit-Based Storage Scheme for Blockchain System. In Proceedings of the 34th IEEE International Conference on Data Engineering, ICDE 2018, Paris, France, 16–19 April 2018; pp. 173–184. [Google Scholar]
- Qi, X.; Zhang, Z.; Jin, C.; Zhou, A. A Reliable Storage Partition for Permissioned Blockchain. IEEE Trans. Knowl. Data Eng. 2021, 33, 14–27. [Google Scholar] [CrossRef]
- Khor, J.H.; Sidorov, M.; Zulqarnain, S.A.B. Scalable Lightweight Protocol for Interoperable Public Blockchain-Based Supply Chain Ownership Management. Sensors 2023, 23, 3433. [Google Scholar] [CrossRef]
- Kang, P.; Yang, W.; Zheng, J. Blockchain Private File Storage-Sharing Method Based on IPFS. Sensors 2022, 22, 5100. [Google Scholar] [CrossRef] [PubMed]
- Dwivedi, S.K.; Amin, R.; Vollala, S. Blockchain-Based Secured IPFS-Enable Event Storage Technique With Authentication Protocol in VANET. IEEE CAA J. Autom. Sin. 2021, 8, 1913–1922. [Google Scholar] [CrossRef]
- Pilares, I.C.A.; Azam, S.; Akbulut, S.; Jonkman, M.; Shanmugam, B. Addressing the Challenges of Electronic Health Records Using Blockchain and IPFS. Sensors 2022, 22, 4032. [Google Scholar] [CrossRef]
- Onwubiko, A.; Singh, R.; Awan, S.; Pervez, Z.; Ramzan, N. Enabling Trust and Security in Digital Twin Management: A Blockchain-Based Approach with Ethereum and IPFS. Sensors 2023, 23, 6641. [Google Scholar] [CrossRef]
- Gochhayat, S.P.; Bandara, E.; Shetty, S.; Foytik, P. Yugala: Blockchain Based Encrypted Cloud Storage for IoT Data. In Proceedings of the IEEE International Conference on Blockchain, Blockchain 2019, Atlanta, GA, USA, 14–17 July 2019; pp. 483–489. [Google Scholar]
- Xu, M.; Feng, G.; Ren, Y.; Zhang, X. On Cloud Storage Optimization of Blockchain With a Clustering-Based Genetic Algorithm. IEEE Internet Things J. 2020, 7, 8547–8558. [Google Scholar] [CrossRef]
- Li, S.; Xu, C.; Zhang, Y.; Du, Y.; Chen, K. Blockchain-Based Transparent Integrity Auditing and Encrypted Deduplication for Cloud Storage. IEEE Trans. Serv. Comput. 2023, 16, 134–146. [Google Scholar] [CrossRef]
- Saleem, T.; Ismaeel, M.; Janjua, M.U.; Ali, A.; Aqib, A.; Ahmed, A.; Hassan, S.U. Predicting functional roles of Ethereum blockchain addresses. Peer Peer Netw. Appl. 2023, 16, 2985–3002. [Google Scholar] [CrossRef]
- Ruan, P.; Kanza, Y.; Ooi, B.C.; Srivastava, D. LedgerView: Access-Control Views on Hyperledger Fabric. In Proceedings of the SIGMOD ‘22: International Conference on Management of Data, Philadelphia, PA, USA, 12–17 June 2022; pp. 2218–2231. [Google Scholar]
- Wu, Y.; Tie, G.; Yu, Y.; Li, J.; Song, J. EBSS: A secure blockchain-based sharing scheme for real estate financial credentials. World Wide Web 2023, 26, 1599–1624. [Google Scholar] [CrossRef]
- Wang, L.; Liu, X.; Shao, W.; Guan, C.; Huang, Q.; Xu, S.; Zhang, S. A Blockchain-Based Privacy-Preserving Healthcare Data Sharing Scheme for Incremental Updates. Symmetry 2024, 16, 89. [Google Scholar] [CrossRef]
- Elisa, N.; Yang, L.; Chao, F.; Cao, Y. A framework of blockchain-based secure and privacy-preserving E-government system. Wirel. Netw. 2023, 29, 1005–1015. [Google Scholar] [CrossRef]
- Zhang, K.; Zhang, Y.; Li, Y.; Liu, X.; Lu, L. A Blockchain-Based Anonymous Attribute-Based Searchable Encryption Scheme for Data Sharing. IEEE Internet Things J. 2024, 11, 1685–1697. [Google Scholar] [CrossRef]
- Pei, H.; Yang, P.; Li, W.; Du, M.; Hu, Z. Proxy Re-Encryption for Secure Data Sharing with Blockchain in Internet of Medical Things. Comput. Netw. 2024, 245, 110373. [Google Scholar] [CrossRef]
- Vanin, F.N.D.S.; Policarpo, L.M.; Righi, R.D.R.; Heck, S.M.; da Silva, V.F.; Goldim, J.; da Costa, C.A. A Blockchain-Based End-to-End Data Protection Model for Personal Health Records Sharing: A Fully Homomorphic Encryption Approach. Sensors 2023, 23, 14. [Google Scholar] [CrossRef] [PubMed]
- Ofori, A.Y.; Sadat, S.K.; Darvishi, I. Blockchain Security Encryption to Preserve Data Privacy and Integrity in Cloud Environment. In Proceedings of the 10th International Conference on Future Internet of Things and Cloud, FiCloud 2023, Marrakesh, Morocco, 14–16 August 2023; pp. 344–351. [Google Scholar]
- Li, L.; Li, Z. An Efficient Quantum Secret Sharing Scheme Based on Restricted Threshold Access Structure. Entropy 2023, 25, 265. [Google Scholar] [CrossRef]
- Chen, F.; Li, Z.; Jiang, C.; Xiang, T.; Yang, Y. Cloud Object Storage Synchronization: Design, Analysis, and Implementation. IEEE Trans. Parallel Distrib. Syst. 2022, 33, 4295–4310. [Google Scholar] [CrossRef]
- Hakeem, S.A.A.; Kim, H. Centralized Threshold Key Generation Protocol Based on Shamir Secret Sharing and HMAC Authentication. Sensors 2022, 22, 331. [Google Scholar] [CrossRef]
- Shamsoshoara, A. Overview of Blakley’s Secret Sharing Scheme. arXiv 2019, arXiv:1901.02802. [Google Scholar]
- Fotiou, N.; Thomas, Y.; Siris, V.A.; Xylomenos, G.; Polyzos, G.C. Self-verifiable content using decentralized identifiers. Comput. Netw. 2023, 230, 109799. [Google Scholar] [CrossRef]
- Jang, I. The Pareto principle and resource egalitarianism. Math. Soc. Sci. 2017, 85, 23–29. [Google Scholar] [CrossRef]
- Kılıç, B.; Özturan, C.; Sen, A. Parallel analysis of Ethereum blockchain transaction data using cluster computing. Clust. Comput. 2022, 25, 1885–1898. [Google Scholar] [CrossRef]
- Suresh, K.; Anand, K.; Nagappan, G.; Pugalenthi, R. A Blockchain-Based Cloud File Storage System Using Fuzzy-Based Hybrid-Flash Butterfly Optimization Approach for Storage Weight Reduction. Int. J. Fuzzy Syst. 2024, 26, 978–991. [Google Scholar] [CrossRef]
- Sharma, P.; Namasudra, S.; Lorenz, P. Blockchain-Based Cloud Storage System with Enhanced Optimization and Integrity Preservation. In Proceedings of the ICC 2023—IEEE International Conference on Communications, Rome, Italy, 28 May–1 June 2023; pp. 3744–3749. [Google Scholar]
- Wang, F.; Zhou, J.T. Blockchain-Based Multi-Cloud Data Storage System Disaster Recovery. In Proceedings of the 2023 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Honolulu, HI, USA,, 1–4 October 2023; pp. 2379–2384. [Google Scholar]
- Liu, J.; Chen, J.; Wu, J.; Wu, Z.; Fang, J.; Zheng, Z. Fishing for Fraudsters: Uncovering Ethereum Phishing Gangs With Blockchain Data. IEEE Trans. Inf. Forensics Secur. 2024, 19, 3038–3050. [Google Scholar] [CrossRef]
- Hussien, F.T.A.; Khairi, T.W.A. Performance Evaluation of AES, ECC and Logistic Chaotic Map Algorithms in Image Encryption. Int. J. Interact. Mob. Technol. 2023, 17, 193–211. [Google Scholar] [CrossRef]
- Xie, B.; Li, Q.; Qian, H. Weak Password Scanning System for Penetration Testing. In Proceedings of the Cyberspace Safety and Security—13th International Symposium, CSS 2021, Virtual Event, 9–11 November 2021; Proceedings. Lecture Notes in Computer Science. pp. 120–130. [Google Scholar]
- Weng, C.; Yang, C. Reversible Data Hiding in Encrypted Image Using Multiple Data-Hiders Sharing Algorithm. Entropy 2023, 25, 209. [Google Scholar] [CrossRef] [PubMed]
- Yang, D.; Tsai, W.-T. Linear Consensus Protocol Based on Vague Sets and Multi-Attribute Decision-Making Methods. Electronics 2024, 13, 2461. [Google Scholar] [CrossRef]
- Jia, D.; Xin, J.; Wang, Z.; Guo, W.; Wang, G. ElasticChain: Support Very Large Blockchain by Reducing Data Redundancy. In Proceedings of the Web and Big Data—Second International Joint Conference, APWeb-WAIM 2018, Macau, China, 23–25 July 2018; Proceedings, Part II. Lecture Notes in Computer Science. pp. 440–454. [Google Scholar]
- Wang, X.; Ning, Z.; Wang, W.; Yang, Y. Anti-conspiracy attack threshold signature model and protocol. Int. J. Wirel. Mob. Comput. 2019, 17, 300–306. [Google Scholar] [CrossRef]
Parameter Name | Parameter Value |
---|---|
Number of nodes | N = 16 |
Block height | BH = 50,000 |
Block size | BS = 10 KB |
Weight coefficient | BW = (0.25, 0.25, 0.25, 0.25) |
Judgment threshold | DT = 0.5 |
Parameter Name | Parameter Value |
---|---|
Number of nodes | N = 16 |
Block height | BH = 5000 |
Block size | BS = 10 KB |
Weight coefficient | BW = (0.25, 0.25, 0.25, 0.25) |
Judgment threshold | DT = 0.5 |
Query times | QN = 50,000 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2024 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
Yang, D.; Tsai, W.-T. An Optimized Encryption Storage Scheme for Blockchain Data Based on Cold and Hot Blocks and Threshold Secret Sharing. Entropy 2024, 26, 690. https://doi.org/10.3390/e26080690
Yang D, Tsai W-T. An Optimized Encryption Storage Scheme for Blockchain Data Based on Cold and Hot Blocks and Threshold Secret Sharing. Entropy. 2024; 26(8):690. https://doi.org/10.3390/e26080690
Chicago/Turabian StyleYang, Dong, and Wei-Tek Tsai. 2024. "An Optimized Encryption Storage Scheme for Blockchain Data Based on Cold and Hot Blocks and Threshold Secret Sharing" Entropy 26, no. 8: 690. https://doi.org/10.3390/e26080690