GB/T 47701-2026Blockchain and distributed ledger technology — Infrastructure — Technical requirements for system storage (English PDF)

5.1 Overview

The stored objects are the data of the blockchain system itself, including ledger data, extended data, and system operation auxiliary data.

a) Ledger data consists of records of messages sent by users to the blockchain, specifically including transaction data and block data.

1) Transaction data consists of messages sent by users to the blockchain that atomically modify the ledger data; it is part of the ledger data. Minimum storage unit;

2) Block data is a data packet that carries transaction data. Consensus protocols are used to reach an agreement on the transaction execution results in the data packet.

b) Extended data is data derived from or extended by providing evidentiary information in the ledger data, specifically including status... State data and custom data.

1) State data is data derived from transaction execution, including smart contract code, smart contract account status, and transaction or... Data derived from smart contract execution can be used to reconstruct state data based on ledger data;

2) Custom data is additional data that provides supporting information to the ledger layer.

c) System operation auxiliary data refers to data that is not directly stored or recorded in transactions or blocks, and cannot be derived from transaction and block data.

According to [the data source], but other data that helps the blockchain system operate or provide services, such as end-user keys, system operation logs, and transactions. Logs and configuration parameters, etc.

5.2 Ledger Data

d) The block body of a non-genesis block should contain the block's transaction sequence;

e) It is advisable to limit the size of a single block of data or the number of transactions contained in a single block;

f) It is advisable to record the source information of cross-chain blocks to achieve traceability of cross-chain data sources and enhance the relevance of block data.

5.2.1 Transaction Data

The technical requirements for transaction data are as follows.

a) It should contain a unique ID for the transaction data;

b) Should include the transaction initiator's ID;

c) It should include the digital signature of the transaction initiator on the transaction content to ensure the non-repudiation of transaction data;

d) It should include the transaction details, specifically indicating the activities initiated by the transaction initiator, such as smart contract call transactions. The called method, parameters, etc.;

e) A timestamp should be included to prevent replay attacks;

f) It is advisable to include transaction types, such as transfer transactions or contract call transactions;

g) It is advisable to limit the size of a single transaction data entry within a certain range.

5.2.2 Block Data

The technical requirements for block data are as follows.

a) The block data structure should include at least two parts. a block header and a block body;

b) Each block should have a unique ID that can be verified as not having been tampered with;

c) The block header of a non-genesis block should at least include the block ID, the block producer ID, proof of the block's validity by the consensus algorithm, and the block name.

Block metadata such as the preceding block ID and the timestamp of the block's creation;

5.3 Extended Data

5.3.1 Status Data

State data consists of data representing the following. smart contract code, smart contract account status, and transactions or smart contract execution.

Derivative data, etc. The technical requirements for status data are as follows.

a) Transactions should be used as the basis for changing status data;

b) It should be able to define read and write rules for state data through smart contracts or other means, and verify them during transaction execution;

c) Data organization methods with data integrity and consistency verification should be adopted, such as Merkle trees, MPT, etc.

d) Consensus should be reached on changes to state data through a consensus protocol;

e) It should have the function of reconstructing data based on ledger data;

f) It is advisable to implement read/write permission settings for status data;

g) It should be stored consistently across multiple blockchain nodes;

h) It is advisable to have a cross-chain state synchronization mechanism to enable timely updates of relevant state data between different chains and maintain system collaboration.

5.3.2 Custom Data

The technical requirements for custom data are as follows.

a) Should have a unique ID;

b) Data content should be verified for integrity and validity before storage;

c) It is advisable to store the supporting information in the ledger data and enable verification within a certain period;

d) It is advisable to declare metadata information such as storage method, storage location, data type, data producer or data source in the ledger;

e) It is advisable to provide cross-chain custom data indexes to facilitate quick location and reference of the data in cross-chain scenarios.

5.4 System Operation Auxiliary Data

System operation auxiliary data consists of data representing the following. keys, logs (run logs, transaction logs), configuration parameters, and their... It requires data for the system to operate. The technical requirements for auxiliary data for system operation are as follows.

a) Confidential data such as keys should be encrypted;

b) Log data should not expose detailed information about ledger data and extended data;

c) It should have backup and recovery capabilities for critical data.

6.1 Overview

Based on the purpose of the data, stored data can be divided into persistent storage data and temporary storage data.

Persistent data storage refers to data that cannot be modified or deleted. In full nodes, it is used to achieve historical traceability and data security in the blockchain.

The data is immutable. In light nodes, it is used to enable clients to verify the trustworthiness of business data returned by blockchain nodes.

Temporary storage data refers to data that can be modified or deleted after a certain period of time. In a full node, it is used to implement the current business logic of the blockchain. Service functions.

6.2 Persistent Data Storage

c) Compressed storage methods are recommended.

6.2.1 Storing Data Objects

6.2.1.1 Persistent storage objects for full nodes

The persistent storage objects of a full node include block data, extended data, and system operation auxiliary data.

6.2.1.2 Lightweight Node Persistent Storage Objects

The persistent storage objects for light nodes are as follows.

a) At most, all block header data, i.e., the sequence of block headers throughout the entire blockchain lifecycle (5.2.2c).

b) At least block ID data, i.e., the sequence of block IDs in the block header throughout the entire lifecycle of the blockchain in 5.2.2c).

6.2.2 Technical Requirements

6.2.2.1 Persistent storage of data across all nodes

The technical requirements for persistent data storage across all nodes are as follows. a) Integrity.

1) A blockchain should be a complete sequence of blocks throughout the entire lifecycle of the system, with no missing blocks;

2) The block structure is complete, and there should be no missing transactions within a block;

3) It should be able to pass the integrity check of the block hash value. b) Consistency.

1) The state data of the snapshot should be consistent with the state data generated from tracing back from the genesis block to the block corresponding to that snapshot;

2) The cryptographic data, such as keys, in the system operation auxiliary data of the snapshot should be able to verify the digital signature in the block;

3) Blocks with the same sequence number in blockchains of different nodes should be consistent. c) Extensibility.

1) The storage solution should have elastic scaling capabilities to accommodate all data throughout the entire lifecycle of the blockchain;

2) A multi-tiered storage system should be established, so that as blockchain data gradually increases over time, earlier data can be moved from main storage to secondary storage.

Storage is transferred layer by layer to other levels of the storage system;

3) It should be compatible with different blockchain storage formats and data structures, and have efficient cross-chain data transmission, storage and interaction capabilities.

d) Ledger data, extended data, and system auxiliary operation data should be protected using necessary technical means to prevent data loss and ensure data availability. Available.

e) Persistently stored data should be queryable and traceable.

f) Data snapshots of multiple states should be included to improve the efficiency of block tracing.

g) It is advisable to have tiered cold and hot storage or offline storage.

6.2.2.2 Lightweight nodes persistently store data

The technical requirements for persistent data storage in lightweight nodes are as follows.

a) Completeness. It should include all block headers in the ledger data and should not have any missing blocks. b) Consistency.

1) Fields in the headers of blocks with the same sequence number in the block header chains of different light nodes should be consistent;

2) The block header in the blockchain header of a light node should be consistent with the field of the system sequence number block header in the blockchain of a full node.

6.3 Temporary Data Storage

6.3.1 Storing Data Objects

The purpose of temporary data storage is to enable the business functions of the blockchain. Only full nodes have temporary storage; light nodes do not perform business transactions.

Easy, no temporary storage is needed. Temporary storage objects should include.

a) The latest block in the ledger data and newly received transactions that have not yet been included in a block;

b) The latest extended data and system operation auxiliary data.

6.3.2 Technical Requirements

The technical requirements for temporary data storage are as follows.

a) The integrity of the latest activity logs and status data should be ensured;

b) Data consistency with other normal nodes in the blockchain network should be achieved;

c) Transaction data and block data should be periodically transferred to persistent storage;

d) It is advisable to periodically migrate snapshots of temporary extended and auxiliary data to persistent storage;

e) It is advisable to back up critical data in auxiliary data when significant changes occur in the node and system operating status;

f) A multi-tiered, differentiated storage system should be established based on the amount of temporary data, its activity level, and read/write activity to achieve optimal results. performance.

7.1 Overview

Different storage objects will employ different storage methods based on their characteristics. Ledger data can be stored in a database, while extended data and system data can be stored in a database.

System operation auxiliary data can be stored in a database, object, or file.

Database storage is a storage method that organizes data into a data set according to a predetermined structure.

Object storage is a storage method that uses objects as the storage unit and provides object-level access interfaces.

File storage is a hierarchical storage method that stores data in the form of files on a computer system or other storage devices.

Database storage and object storage are more suitable for temporary storage data that requires frequent access, while file storage is more suitable for data that requires... Persistent storage data that is stored for a long period of time.

7.2 General Requirements

The general technical requirements for database storage, object storage, and file storage are as follows.

a) It shall comply with the safety requirements in GB/T 42571-2023, 6.5.1.2c), d), f) and 6.5.2.1;

b) It is advisable to implement quick data retrieval using identifiers such as block height, block timestamp, and transaction hash value;

c) It should have flexible expansion capabilities.

7.3 Database Storage

The database storage technology requirements are as follows.

a) Data should be stored as key-value pairs;

b) It is advisable to have data sharding technology to distribute key-value data into different shards to improve parallel processing capabilities;

c) It is advisable to have state channels or sidechain technology to allow frequently updated key-value data to be off-chain stored;

d) A read-write separation mechanism should be implemented to optimize database query performance;

e) Technologies such as data replication, master-slave architecture, or distributed databases should be adopted to achieve high availability of database services;

f) Data backup and recovery mechanisms should be provided, and the database should have fault tolerance mechanisms;

g) It should have key-value data replication and synchronization based on a consensus mechanism to achieve data consistency in the network;

h) High-performance, high-reliability storage media, such as enterprise-grade solid-state drives or all-solid-state storage arrays, should be used;

i) Different RAID levels should be selected according to actual needs, such as RAID10 or RAID5.

7.4 Object Storage

The technical requirements for object storage are as follows.

a) Decentralized content-addressable storage technology should be adopted, such as using data hashes as identifiers to quickly locate and access stored objects;

b) It should have object version control, allowing for the tracking and recovery of historical versions of objects;

c) It should have an expandable namespace and be able to dynamically expand storage capacity;

d) Efficient indexing and retrieval of object metadata should be implemented to cope with the management of massive objects;

e) Multiple copies of objects should be stored and automatically synchronized to ensure data availability;

f) It should have fault tolerance mechanisms and self-repair capabilities, automatically recovering from copies to ensure data integrity.

7.5 File Storage

The technical requirements for file storage are as follows.

a) It is advisable to implement distributed file storage in a blockchain network, allowing large files to be stored across multiple nodes;

b) It should have a flexible storage strategy for both full and light nodes in the blockchain, allowing light nodes to store only the block header and their own related data;

c) It should have a flexible directory structure, such as a tree-like directory or a flat directory;

d) File version control should be implemented to retain historical versions of data;

e) It is advisable to have immutable file storage, such as an append-only file system, so that data written to the file system cannot be modified;

f) It should be compatible with commonly used file-level protocols, such as FTP, SMB, CIFS, NFS, etc.

g) It should have file sharing capabilities, allowing computers with appropriate permissions on the network to access the network-attached storage (NAS) device. The file on;

h) File storage disaster recovery should be implemented.

8.1 Overview

The blockchain storage process refers to the data configuration, data preprocessing, construction of custom data, custom data verification, and data synchronization on the blockchain. […]

8.2 Running Auxiliary Data Configuration

Before data storage, auxiliary data supporting system operation needs to be configured, including but not limited to.

a) Load the system's configuration files;

b) The key of the person initiating the storage activity should be entrusted to an agent or the person should be prompted to keep it safe.

8.3 Data Preprocessing

Before data is stored on the blockchain, it undergoes preprocessing, which includes, but is not limited to.

a) The data format should be checked to ensure it meets the requirements for on-chain processing;

b) Data integrity verification should be performed on the relevant information of the data;

c) The content of the data should be protected against privacy concerns;

d) It is advisable to check the compliance of the data.

8.4 Issuance of Transaction

After data preprocessing, transactions that are signed onto the blockchain are broadcast to the network as pending transactions. The content involved includes, but is not limited to, these transactions. Limited to.

a) Transactions uploaded to the blockchain should be digitally signed using a legally authorized private key;

b) For temporary data, the retention period should be specified;

c) The algorithm used for transaction signing should be compatible with mainstream international or domestic commercial cryptographic algorithms;

d) The storage type of transaction data should be clearly defined.

8.5 Constructing Custom Data

After data preprocessing, custom types of on-chain data are constructed according to business needs, including but not limited to.

a) Custom data uploaded to the blockchain should be digitally signed using a legally authorized private key;

b) For temporary data, the retention period should be specified;

c) The algorithm used when signing custom data should be compatible with mainstream international or domestic commercial cryptographic algorithms;

d) The storage type should be clearly defined in custom data.

8.6 Transaction Data Verification and Packaging

After receiving a request to package a transaction, the block-producing node verifies and packages the transaction, which includes, but is not limited to.

a) The integrity of the transaction details and the legitimacy of the digital signature should be verified;

b) After accumulating the required number of valid transactions, when constructing a new block, a validly authorized private key should be used to access all information within the block. Sign the information;

c) New blocks should be broadcast to the blockchain network;

d) It is advisable to verify whether the storage size of transaction data meets the storage requirements of blockchain nodes.

8.7 Custom Data Validation

Custom data is validated before being written to disk, and this includes, but is not limited to.

a) The integrity of the custom data content and the legitimacy of the digital signature should be verified;

b) It is advisable to verify whether the storage size of custom data meets the storage requirements of blockchain nodes.

8.8 Data Synchronization

In addition to being generated and stored through its own nodes, ledger data and extended data can also be synchronized through a blockchain node network. The content involved includes, but is not limited to.

a) The data synchronization process should avoid relying on centralized servers or nodes, and instead achieve data distribution and updates through a peer-to-peer network;

b) Blockchain nodes can choose to be full nodes (synchronizing all block data) or light nodes (synchronizing block header data), etc., according to their actual needs.

Different synchronization modes are used to reduce storage burden and improve data synchronization speed;

c) Blockchain nodes should choose to synchronize only a specific version of the state data set, based on actual needs, to reduce synchronization, storage, and block execution.

Reduce the burden on the line and improve the speed of data synchronization.

8.9 Data Storage in Ledgers

The data synchronization process involves the following. the storage of ledger data on disk.

a) Upon receiving a new block, a node should verify the legality of the block signature and transaction information;

b) When traversing each transaction within a block, it is advisable to classify and store the data according to the storage type of the on-chain data;

c) Different types of storage methods should be selected based on the data type of the data uploaded to the blockchain.

8.10 Extended Data Persistence

Extended data persistence to disk includes, but is not limited to.

a) For extended data with persistent storage type, a database should be used as its storage method;

b) For extended data with temporary storage type, file storage or object storage should be used as the storage method.

8.11 Running auxiliary data to disk

The content involved in running auxiliary data to disk storage includes, but is not limited to.

a) Log data should preferably be stored in files;

b) When log data is written to disk, encryption should be set for access control.

8.12 Post-event data management

The post-event data management function includes, but is not limited to.

a) It should have security auditing capabilities;

b) Data management should have the capability for redundant backup and storage expansion;

c) Blockchain nodes should periodically scan the temporarily stored data and promptly delete expired data;

d) Blockchain nodes should periodically compress and solidify persistently stored data according to different storage methods, and perform data migration, etc. Perform storage optimization;

e) Blockchain nodes should be able to periodically and in batches prune status data, promptly clear and reclaim space, and reduce management costs.