Non-tampering database system based on block chain and data processing method

Abstract

The invention relates to the technical field of data processing, in particular to a non-tampering database system based on a block chain and a data processing method.The system comprises a unified access control layer driven by an intelligent contract and used for verifying all user requests and mapping the user requests into on-chain credible operation; the hierarchical verifiable storage engine comprises a block chain evidence storage layer which is used for recording event logs on a chain in a tampering-free manner and regularly generating consistent anchor point transactions containing decentralized storage network data snapshot hash; the dynamic popularity perception storage layer is used for dynamically storing and migrating data among a high-speed cache, a local database and a decentralized storage network in a layered manner on the basis of a data access popularity prediction model; the integrity of the data migrated to the decentralized storage network is verified by comparing recalculation snapshot hash with on-chain anchor point transaction hash. On the premise of ensuring that the data cannot be tampered, flexible data access and management functions are provided, and the requirements of different application scenes are met.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a blockchain-based immutable database system and data processing method. Background Technology

[0002] Traditional database systems are typically based on a centralized architecture, which inherently suffers from vulnerabilities to malicious data tampering, high single-point-of-failure risks, and insufficient data trustworthiness in multi-party scenarios. While blockchain technology offers a new approach to trusted data storage with its decentralized and immutable characteristics, it still faces significant challenges when integrated with database systems: If all data is stored on the blockchain, it will be limited by the low throughput and high cost of the blockchain, which will not meet the high-frequency operation requirements of practical applications. If only the data hash is stored on the blockchain for evidence, there will be a problem that the on-chain evidence and the full off-chain data status are difficult to verify in real time and conveniently, and the trust chain is incomplete.

[0003] Existing blockchain-based evidence storage solutions mostly focus on storing fixed data, lacking the ability to perform complex data operations (such as adding, deleting, modifying, and querying), fine-grained dynamic access control, and deep integration with traditional business logic, making them unsuitable as a general-purpose data management infrastructure.

[0004] The immutability of blockchain smart contracts contradicts the need for rapid business iteration. Furthermore, the fixed roles of existing blockchain nodes prevent dynamic scheduling of computing, storage, and network resources based on real-time load, resulting in system rigidity and low resource utilization efficiency.

[0005] Therefore, there is an urgent need for an innovative solution that can achieve high-performance, intelligent management, and flexible evolution of database systems while ensuring data immutability and operational reliability. Summary of the Invention

[0006] To achieve distributed storage and management of data, improve the fault tolerance and reliability of the system, and reduce the risk of single points of failure, this invention provides a blockchain-based immutable database system and data processing method.

[0007] In a first aspect, the technical solution of the present invention provides a blockchain-based immutable database system, including a unified access control layer driven by smart contracts and a layered verifiable storage engine. The unified access control layer integrates a set of data operation rules and dynamic permission management strategies defined and automatically executed by blockchain smart contracts. All user requests must be verified by the unified access control layer and mapped to trusted on-chain operations. The tiered verifiable storage engine includes: The blockchain evidence storage layer is used to immutably record on-chain event logs triggered by data operations in the form of a hash chain, and periodically generate consistent anchor transactions containing cryptographic hashes of data snapshots in the decentralized storage network. A dynamic heat-aware storage layer forms a verifiable anchoring relationship with the blockchain evidence storage layer. Based on a data access heat prediction model, the dynamic heat-aware storage layer dynamically stores and migrates data in layers between a cache, a local database, and a decentralized storage network. For data migrated to the decentralized storage network, its integrity is verified by comparing the hash value obtained by recalculating the corresponding data snapshot with the hash value in the corresponding consistency anchor transaction recorded in the blockchain evidence storage layer.

[0008] The unified access control layer driven by smart contracts ensures that all data operations are trustworthy, auditable, and tamper-proof. At the same time, the dynamic heat-aware storage layer realizes intelligent optimization of data storage, which greatly improves the system's data processing efficiency and response speed while ensuring blockchain-level trustworthiness.

[0009] By combining the blockchain evidence storage layer with the dynamic heat perception storage layer and realizing closed-loop verification of cross-layer data integrity through consistent anchor transaction technology, a solution that is both efficient and verifiable is provided for the entire lifecycle of data from generation, storage, migration to archiving.

[0010] The division between a unified access control layer and a layered, verifiable storage engine decouples the system's permission management, business logic, data storage, and performance optimization, reducing system complexity and improving module maintainability and scalability.

[0011] As a preferred embodiment of the technical solution of the present invention, the unified access control layer provides a standardized data operation interface to the outside world. The data operation interface includes an operation interface for changing data status, an operation interface for managing data access permissions, and a data query interface. The operation interfaces for changing data status include a data insertion interface, a data update interface, and a data deletion interface; the operation interfaces for managing data access permissions include a permission granting interface and a permission revocation interface. When an operation is performed through the data insertion interface, data update interface, or data deletion interface, the blockchain evidence storage layer is triggered to generate an on-chain event log containing the operation type, data identifier, user signature, and timestamp. When performing operations through the data query interface, data can be obtained from the hierarchical verifiable storage engine, and Merkle proofs from the blockchain evidence storage layer can be obtained to verify the integrity of the data. The operation performed through the data deletion interface is a logical deletion operation; the smart contract marks the data as deleted, but retains the data hash value on the blockchain; the system is also configured with a background cleanup mechanism, which performs physical cleanup on the logically deleted data after the preset compliance retention period expires.

[0012] Standardized data operation interfaces are defined, enabling upper-layer applications to interact with the complex underlying blockchain storage system in a unified and convenient manner, reducing integration and development difficulties. All write operations trigger the generation of on-chain event logs containing complete context, providing an immutable chain of evidence for data auditing; query operations support obtaining Merkle proofs, allowing light clients or third parties to independently verify data authenticity, enhancing the system's transparency and credibility.

[0013] By employing a logical deletion mechanism, the requirement that blockchain data cannot be deleted for evidence preservation is met, while also enabling data deletion at the business level. Furthermore, the background cleanup mechanism satisfies the regulations regarding the complete deletion of data after the expiration of the data retention period, thus resolving a key obstacle to the compliant application of blockchain technology.

[0014] As a preferred embodiment of the technical solution of the present invention, the data operation rule set at least stipulates that: all data write operations must be accompanied by a valid requester signature; the dynamic permission management strategy adopts a role-based access control model and is extended with dynamic authorization rules based on data attributes, and the binding relationship between roles and permissions is updated through the management interface of smart contracts.

[0015] The system requires data to be written with a valid signature. Leveraging the immutability of blockchain, this allows for precise traceability of the data writer, preventing unauthorized data alteration or subsequent repudiation, and ensuring the authenticity and legality of data writing from the source. Building upon the RBAC model, it extends dynamic authorization rules based on data attributes, enabling fine-grained permission control according to data sensitivity levels and business attributes. Furthermore, permission binding relationships are updated via smart contract interfaces without modifying the underlying system, allowing for flexible iteration of permission policies to meet the permission management needs of different business scenarios.

[0016] As a preferred embodiment of the technical solution of the present invention, the processing of user requests for writing classes or permission change classes by the unified access control layer includes: By invoking the blockchain smart contract, the digital signature attached to the request is verified; the dynamic permission management policy maintained within the smart contract is queried to determine whether the requester is authorized to execute the operation; if the authorization is successful, the smart contract automatically constructs a blockchain transaction, converting the user request into an on-chain operation instruction; the blockchain transaction is submitted to the blockchain network, executed after consensus, and its execution result serves as a certificate of trusted on-chain operation. When the smart contract performs a data update or deletion operation, it requires the requester to provide an on-chain credential of the last valid operation. After verifying that the credential has not been used, the contract marks it as spent and records the details of this operation together with the hash of the old credential in an immutable event log.

[0017] By requiring data update and deletion operations to provide on-chain credentials of the previous valid operation, attackers are prevented from intercepting and repeatedly submitting old operation requests to illegally tamper with data.

[0018] Each operation is recorded together with the hash of the old voucher, forming an unforgeable and unbreakable chain of operation vouchers. This allows the complete change history of any data item to be clearly and reliably traced, improving the system's security audit capabilities.

[0019] As a preferred embodiment of the technical solution of the present invention, the blockchain notarization layer periodically generates consistent anchor transactions, and the process by which the system provides data integrity verification based on these transactions includes: When a preset period is reached, a data snapshot of the current data state in the decentralized storage network is obtained, and the cryptographic hash value of the data snapshot is calculated; the cryptographic hash value, the unique identifier of the data snapshot, and the signature of the generating node are packaged to construct a consistency anchor transaction; the consistency anchor transaction is submitted to the blockchain network for consensus verification and recorded in the blockchain evidence storage layer; The system provides a public verification interface for verifiers to query the hash value in the consistency anchor transaction and compare it with the hash value recalculated from the data snapshot obtained from the decentralized storage network based on the unique identifier, in order to verify the integrity of the off-chain data.

[0020] By migrating infrequently accessed cold data to a low-cost decentralized storage network and periodically anchoring the hashes of data snapshots to the blockchain, the integrity and immutability of this off-chain data are ensured, achieving an optimal balance between storage costs and data credibility. Through public verification interfaces and standardized comparison processes, any third party that does not trust the system operator can independently and cost-effectively verify the integrity and tamper-proof nature of data stored in the decentralized network, enhancing the system's credibility in multi-party collaborative scenarios.

[0021] As a preferred embodiment of the technical solution of the present invention, the process of dynamic layered storage and migration of the dynamic heat sensing storage layer includes: The data access popularity prediction model continuously monitors and analyzes the historical data operation logs recorded in the blockchain notarization layer, extracts the access frequency, recent access time, and associated query patterns of each data item, and predicts the access popularity value in future periods. The predicted access popularity value is compared with a preset threshold, and based on the comparison result, the data items are dynamically assigned to the corresponding storage layer. If the predicted access popularity value of a data item is higher than the first preset threshold, it will be allocated to the cache. If the predicted access popularity value of a data item is between the first preset threshold and the second preset threshold, it will be assigned to the local database. If the predicted access popularity value of a data item is lower than the second preset threshold, it is marked as to be migrated to the decentralized storage network. Based on the partitioning results, data migration tasks between different storage tiers will be automatically triggered; For data migrated to a decentralized storage network, after the migration is completed, the dynamic heat perception storage layer triggers the blockchain evidence storage layer to generate associated consistent anchor transactions.

[0022] The system can automatically identify and predict data access patterns, placing hot data in a high-speed cache to support high-concurrency queries, placing warm data in a local database to ensure stable access, and archiving cold data to low-cost storage, thereby achieving adaptive optimization of storage performance and resource costs.

[0023] By automating computationally intensive heat prediction and data migration tasks, and combining them with an anchor transaction triggering mechanism, intelligent linkage between storage strategies and blockchain notarization is achieved, reducing manual intervention and enabling the system to dynamically adapt to ever-changing data access loads.

[0024] As a preferred embodiment of the technical solution of the present invention, the smart contracts integrated in the unified access control layer are deployed in an upgradeable proxy mode, which includes beacon contracts and upgradeable logic contracts. The beacon contract is used to store the address of the latest logic contract, and the upgradeable logic contract contains specific business logic and permission rules. The upgrade operation of the smart contract is controlled by a multi-signature governance contract and requires a preset time lock delay period before execution.

[0025] By adopting a proxy model that separates beacon contracts from upgradeable logic contracts, the business logic and permission rules of smart contracts can be securely upgraded without interrupting services or migrating historical data. This solves the rigidity problem of traditional blockchain contracts being unmodifiable once deployed, and ensures the long-term evolvability of the system.

[0026] The upgrade operation is controlled by a multi-signature governance contract and introduces a time-lock delay to prevent malicious upgrades by a single privileged party. This provides the community with a buffer period to deal with potential risk upgrades and reflects the security concept of decentralized governance.

[0027] As a preferred embodiment of the technical solution of the present invention, the system further includes a decentralized consensus and state synchronization network composed of multiple nodes; The nodes in the network are configured to dynamically switch between three roles: verification node, storage node, and routing relay node, based on real-time load metrics. The real-time load metrics include at least the node's own computing resource utilization, network bandwidth utilization, and the length of the service request queue from other nodes.

[0028] Nodes can dynamically switch between roles such as authentication, storage, and routing based on real-time load (CPU, bandwidth, queue length), enabling the network to automatically respond to traffic peaks, localized failures, and other anomalies, achieving load balancing and avoiding performance bottlenecks. Through dynamic role allocation, each node's hardware resources are utilized most effectively according to the network's overall needs, avoiding resource idleness or over-congestion, thus supporting higher system performance with lower hardware costs.

[0029] Secondly, the present invention also provides a blockchain-based data processing method, applied to the immutable database system described in the first aspect, the method comprising: Through a unified access control layer, user data operation requests are received and verified. Verified requests are mapped to trusted on-chain operations executed by blockchain smart contracts, and the blockchain evidence storage layer is triggered to record the corresponding on-chain event logs. Through the dynamic heat perception storage layer, based on the data operation history obtained from the blockchain storage layer, the heat value of each data item is determined by the data access heat prediction model, and the data is dynamically scheduled between the cache, local database and decentralized storage network according to the heat value and the dynamic scheduling rules. For data stored in a decentralized storage network, a consensus anchor transaction containing the cryptographic hash of its data snapshot is generated and recorded by the blockchain notarization layer; based on the consensus anchor transaction, the integrity of the data in the decentralized storage network is independently verified.

[0030] As a preferred embodiment of the technical solution of the present invention, the rules for dynamic scheduling include: If the popularity value of a data item is higher than the first threshold, it will be placed in or retained in the cache. If the popularity value of a data item is between the first threshold and the second threshold, then place it in or migrate it to the local database; If the popularity value of a data item is lower than the second threshold, it will be migrated to a decentralized storage network.

[0031] As can be seen from the above technical solutions, this application has the following advantages: relying on blockchain smart contracts to uniformly manage data operation rules and permission policies, all user requests must be verified by the contract and transformed into trusted on-chain operations, realizing the transparency, automation and non-repudiation of data operations, and greatly improving the credibility of data operations in multi-participant collaborative scenarios.

[0032] The layered verifiable storage engine solidifies operation logs and data snapshot hashes through a blockchain notarization layer, ensuring the traceability of data operations and the integrity of off-chain data. Meanwhile, the dynamic heat perception storage layer enables intelligent migration of data between different storage media based on access frequency, ensures the read and write efficiency of frequently accessed data through high-speed caching and local databases, and achieves low-cost, high-reliability storage of low-frequency data using a decentralized storage network.

[0033] By binding off-chain data snapshots to the blockchain storage layer through consistency anchor transactions, data integrity verification is completed by comparing hash values. This eliminates the need to rely on centralized institutions, solves the problem of insufficient data credibility in traditional databases, and strengthens the credibility of data throughout its entire lifecycle. Attached Figure Description

[0034] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A block diagram of a system provided in an embodiment of the present invention.

[0036] Figure 2 A flowchart of a method provided in an embodiment of the present invention. Detailed Implementation

[0037] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this application and in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0039] like Figure 1 As shown, this embodiment of the invention provides a blockchain-based immutable database system, including a smart contract-driven unified access control layer and a layered verifiable storage engine. The unified access control layer integrates a set of data operation rules and dynamic permission management strategies defined and automatically executed by blockchain smart contracts. All user requests must be verified by the unified access control layer and mapped to trusted on-chain operations. In this embodiment of the invention, the unified access control layer serves as the system's business entry point and rule execution hub. Essentially, it is a collection of smart contracts deployed on the blockchain. These contracts explicitly define a set of data operation rules, such as requiring all data writes to be signed and dynamic permission management strategies. When a user initiates a request via API, this layer intercepts the request and invokes the corresponding smart contract for verification. Upon successful verification, the smart contract automatically transforms and executes the request into one or more standard blockchain transactions, thereby mapping the user's intent into non-repudiable and tamper-proof trusted on-chain operations.

[0040] The tiered verifiable storage engine includes: The blockchain evidence storage layer is used to immutably record on-chain event logs triggered by data operations in the form of a hash chain, and periodically generate consistent anchor transactions containing cryptographic hashes of data snapshots in the decentralized storage network. In this embodiment of the invention, the blockchain evidence storage layer utilizes the underlying blockchain itself as the evidence storage medium. All trusted on-chain operations executed through the unified access control layer are permanently recorded as a structured on-chain event log in the blockchain blocks, forming a hash chain to ensure the immutability of the operation history. Furthermore, this layer periodically generates consistency anchor transactions. For example, the system can be configured so that every 1000 blocks, a specific node generates a complete data snapshot of all externally stored cold data, calculates its Merkle root hash, and then packages this hash into a special transaction and uploads it to the blockchain. This transaction is the consistency anchor transaction.

[0041] A dynamic heat-aware storage layer forms a verifiable anchoring relationship with the blockchain evidence storage layer. Based on a data access heat prediction model, the dynamic heat-aware storage layer dynamically stores and migrates data in layers between a cache, a local database, and a decentralized storage network. For data migrated to the decentralized storage network, its integrity is verified by comparing the hash value obtained by recalculating the corresponding data snapshot with the hash value in the corresponding consistency anchor transaction recorded in the blockchain evidence storage layer.

[0042] The dynamic heat-aware storage layer incorporates a data access heat prediction model. This model continuously analyzes the operation logs recorded in the blockchain notarization layer to predict which data is hot (frequently accessed), which is lukewarm (occasional access), and which is cold (rarely accessed). Based on the prediction results, the layer automatically executes a data migration strategy: loading the predicted hot data into a high-speed cache for millisecond-level response; storing lukewarm data in a local database; and migrating cold data to a lower-cost decentralized storage network. The dynamic heat-aware storage layer and the blockchain notarization layer form a verifiable anchor relationship: when a batch of data is migrated to IPFS, the dynamic heat-aware storage layer notifies the blockchain notarization layer, triggering it to generate a consistency anchor transaction for this batch of data. Anyone who suspects that data on IPFS has been tampered with can obtain the hash value of the anchor transaction from the blockchain, recalculate the hash of the corresponding data on IPFS, and compare it, thereby independently completing integrity verification.

[0043] In some embodiments, the unified access control layer provides standardized data operation interfaces to the outside world. The data operation interfaces include operation interfaces for changing data status, operation interfaces for managing data access permissions, and data query interfaces. The operation interfaces for changing data status include a data insertion interface, a data update interface, and a data deletion interface; the operation interfaces for managing data access permissions include a permission granting interface and a permission revocation interface. When an operation is performed through the data insertion interface, data update interface, or data deletion interface, the blockchain evidence storage layer is triggered to generate an on-chain event log containing the operation type, data identifier, user signature, and timestamp. When performing operations through the data query interface, data can be obtained from the hierarchical verifiable storage engine, and Merkle proofs from the blockchain evidence storage layer can be obtained to verify the integrity of the data. The operation performed through the data deletion interface is a logical deletion operation; the smart contract marks the data as deleted, but retains the data hash value on the blockchain; the system is also configured with a background cleanup mechanism, which performs physical cleanup on the logically deleted data after the preset compliance retention period expires.

[0044] The data operation rule set stipulates at least that: all data write operations must be accompanied by a valid requester signature; the dynamic permission management strategy adopts a role-based access control model, and is extended with dynamic authorization rules based on data attributes, and the binding relationship between roles and permissions is updated through the management interface of smart contracts.

[0045] The smart contract provides a data existence proof interface; in response to a query request, the data existence proof interface returns the Merkle path proof of the specified data item at a specific block height and the corresponding block Merkle root, which can be independently verified by light nodes or third parties.

[0046] For user requests that require writing to a class or permission change class, the unified access control layer's processing includes: By invoking the blockchain smart contract, the digital signature attached to the request is verified; the dynamic permission management policy maintained within the smart contract is queried to determine whether the requester is authorized to execute the operation; if the authorization is successful, the smart contract automatically constructs a blockchain transaction, converting the user request into an on-chain operation instruction; the blockchain transaction is submitted to the blockchain network, executed after consensus, and its execution result serves as a certificate of trusted on-chain operation. When the smart contract performs a data update or deletion operation, it requires the requester to provide an on-chain credential of the last valid operation. After verifying that the credential has not been used, the contract marks it as spent and records the details of this operation together with the hash of the old credential in an immutable event log.

[0047] The unified access control layer exposes a complete set of standardized interfaces through smart contracts. In specific implementations, these interfaces can be encapsulated as gRPC or RESTful APIs. The core interfaces are divided into three categories: Data status change interfaces: insert(rowKey, data, signature), update(rowKey,newData, signature, oldCredential), delete(rowKey, signature, oldCredential).

[0048] Access control interfaces: grant(user, role, resource), revoke(user, role, resource).

[0049] Data query interface: select(rowKey).

[0050] When a user calls the insert, update, or delete interface, the smart contract triggers a LogEntry event after executing its business logic. This event records the operation type (opType), target data identifier (rowKey), operator address (caller), block height (blockHeight), and a user signature hash (sigHash) for this operation. This event is permanently recorded in the blockchain's notarization layer, forming an audit trail chain.

[0051] When a user calls the `select` query interface, the request is not directly recorded on the blockchain. The system retrieves the data from the corresponding storage medium in the dynamic heat-aware storage layer and returns it. Meanwhile, to prove that the returned data has not been tampered with, the smart contract provides a `proveSelect` function. Calling this function obtains the Merkle path proof of the specified data at a specific historical block height and the Merkle root of that block, allowing users to perform offline verification.

[0052] Specifically, the delete operation uses logical deletion. When the contract executes, it doesn't erase the data; instead, it sets the status field of the data record to 0xFF (representing deletion). The data content and its hash remain in the on-chain record to meet compliance audit requirements. A separate cleanup service runs in the background, monitoring the deletion timestamp of each logically deleted data entry. When the retention period for a piece of data expires, this service generates a zero-knowledge proof through a secure multi-party computation process, proving that the retention period has ended. It then triggers the on-chain cleanup contract, ultimately securely removing the actual content of the data and completing the physical cleanup.

[0053] Access control employs a model combining RBAC and attribute-based policies. The smart contract maintains a user-role mapping table and a policy table. Policies not only include roles and actions but can also include conditions and expiration times based on data attributes. Administrators can dynamically adjust these binding relationships through the grant / revoke interface.

[0054] To prevent man-in-the-middle replay attacks, the update and delete interfaces require callers to provide on-chain credentials returned by the last successful operation. The smart contract checks a set of spent credentials named spentSet to ensure that the credentials have not been reused. Only after successful verification will the new operation be executed, the old credentials be marked as spent, and the hash of the old credentials be recorded in a newly generated LogEntry event, forming a tamper-proof credential chain.

[0055] In some embodiments, the blockchain notarization layer periodically generates consistency anchor transactions, and the process by which the system provides data integrity verification based on these transactions includes: When a preset period is reached, a data snapshot of the current data state in the decentralized storage network is obtained, and the cryptographic hash value of the data snapshot is calculated; the cryptographic hash value, the unique identifier of the data snapshot, and the signature of the generating node are packaged to construct a consistency anchor transaction; the consistency anchor transaction is submitted to the blockchain network for consensus verification and recorded in the blockchain evidence storage layer; The system provides a public verification interface for verifiers to query the hash value in the consistency anchor transaction and compare it with the hash value recalculated from the data snapshot obtained from the decentralized storage network based on the unique identifier, in order to verify the integrity of the off-chain data.

[0056] The generation of the consistency anchor transaction is an automated, periodic process. The system can be set with two trigger modes: Time / block driven: For example, the system automatically starts the anchor point generation process every 1024 new blocks generated.

[0057] Event-driven: Triggered by a signal emitted by the dynamic heat-aware storage layer after a large-scale data archiving to IPFS is completed.

[0058] The process for generating consistent anchor transactions is as follows: The node responsible for generating the data accesses the decentralized storage network to obtain a list of all currently managed data and proof of storage.

[0059] Based on this list, the nodes recalculate the Merkle tree root hash for the entire dataset.

[0060] A node constructs a special transaction whose data field contains: anchor type identifier, calculated Merkle root hash, reference identifier of data snapshot, and timestamp.

[0061] The node signs the transaction using its private key and broadcasts it to the blockchain network. After consensus is reached, the transaction is written into a new block, becoming an immutable consensus anchor.

[0062] The system also provides a public verification interface. Any validator only needs to enter a unique identifier for a data snapshot, and the interface will return the corresponding consistency anchor transaction information on the blockchain. Validators can then download the complete data snapshot from the IPFS network, recalculate its hash locally, and compare it with the hash recorded on the chain. If they match, it proves that the off-chain data is complete; if they do not match, it proves that the data has been tampered with.

[0063] In this embodiment of the invention, a fixed-length access history queue based on a time-sliding window is maintained for each data item in the system. This queue records, in chronological order, the timestamp and access type (read / write) of each access to the data item within a recent period (e.g., T=7 days). Based on this queue, the dynamic heat-aware storage layer calculates three core features in real time: Normalized access frequency : Count the total number of times the data item is accessed within the sliding window T. To eliminate the difference in the absolute number of accesses of different data items, count is normalized, for example by using Min-Max scaling or dividing by the maximum number of accesses of all data items in the window, so that the value of F falls within the interval [0,1].

[0064] Exponential decay factor based on recent access time This factor reflects the popularity of a more recent visit. Let the current time be... The last access time of the data item is Window duration is Then the attenuation factor It can be calculated using the following formula:

[0065] in, The attenuation constant (e.g.) =1), This indicates the percentage of time elapsed since the last visit within the entire window. Results The value is between (0,1]. The closer , The closer it is to 1.

[0066] Cumulative access popularity of related data items The system analyzes historical query logs to maintain a set of frequently queried related data items for each data item. For the current data item... Its related popularity Calculate all its associated data items Estimated access popularity within the current sliding window Weighted sum:

[0067] in, It is a data item and The association weight (which can be calculated from historical co-occurrence frequencies). It is a data item The real-time popularity value (which may use values ​​from the previous iteration or the initial value during calculation). This calculation reflects the data associated with the hot data, and may itself become part of the spread of the hot data.

[0068] Data Items Current access popularity value Synthesized via a configurable linear weighted model:

[0069] in, For data items Normalized access frequency within a sliding window For data items Exponential decay factor based on recent access time, To be related to data items The cumulative access popularity of other related data items within the window. These are adjustable weighting coefficients, representing the contributions of historical visit frequency, time decay effect, and association propagation effect to the final popularity prediction. .

[0070] In some embodiments, the process of dynamic hierarchical storage and migration of the dynamic heat-sensing storage layer includes: The data access popularity prediction model continuously monitors and analyzes the historical data operation logs recorded in the blockchain notarization layer, extracts the access frequency, recent access time, and associated query patterns of each data item, and predicts the access popularity value in future periods. The predicted access popularity value is compared with a preset threshold, and based on the comparison result, the data items are dynamically assigned to the corresponding storage layer. The system presets two decision thresholds: threshold_Hot and threshold_Cold, and periodically calculates the latest popularity value for each data item. Storage decisions are made based on the following rules: like Threshold_Hot: Marks a data point as a hotspot and ensures that its data is in the cache.

[0071] If the threshold _Cold <= <= threshold_Hot: Marked as warm data and stored in the local database.

[0072] like <Threshold_Cold: Marked as cold data, scheduled for migration to a decentralized storage network.

[0073] After the migration task is executed, the corresponding consistency anchor transaction generation process is triggered.

[0074] In some embodiments, the smart contracts integrated by the unified access control layer are deployed using an upgradeable proxy pattern, which includes beacon contracts and upgradeable logic contracts. The beacon contract is used to store the address of the latest logic contract, and the upgradeable logic contract contains specific business logic and permission rules. The upgrade operation of the smart contract is controlled by a multi-signature governance contract and requires a preset time lock delay period before execution.

[0075] It should be noted that, in order to achieve secure upgrades of smart contracts, this system adopts a hybrid model of BeaconProxy + Upgradeable Logic Contract (UUPS).

[0076] In some embodiments, the system further includes a decentralized consensus and state synchronization network consisting of multiple nodes; The nodes in the network are configured to dynamically switch between three roles: verification node, storage node, and routing relay node, based on real-time load metrics. The real-time load metrics include at least the node's own computing resource utilization, network bandwidth utilization, and the length of the service request queue from other nodes.

[0077] The system's underlying layer is a decentralized consensus and state synchronization network, composed of multiple physical or cloud-based server nodes. Each node runs the same core software, but can dynamically assume different responsibilities based on system instructions and its own load. Validator nodes: Participate in the blockchain consensus algorithm, package transactions, and generate new blocks. They consume significant CPU resources.

[0078] Storage nodes: Store complete copies of the blockchain data and full temperature data in the local database. They consume significant amounts of disk I / O and storage space.

[0079] Routing relay nodes: Primarily responsible for network communication, efficiently forwarding transaction and block data, and maintaining the P2P network topology. They consume a significant amount of network bandwidth.

[0080] Each node has a built-in load monitor that continuously collects local metrics: CPU utilization, network inbound and outbound bandwidth, and the length of the pending transaction queue. These metrics are reported to a centralized coordinator or shared among nodes via a decentralized heartbeat protocol. The system presets load thresholds for each role. For example: When a storage node's pending transaction queue length remains excessively high, indicating slow response and low network inbound / outbound bandwidth, the coordinator can instruct it to switch to a routing relay node to alleviate network pressure.

[0081] When a validator node's CPU utilization remains below 50% for an extended period, while other nodes in the network are overloaded, the coordinator can instruct it to switch to a storage node for a portion of the time to help store data.

[0082] Through this dynamic role scheduling based on real-time metrics, the entire network can achieve load balancing, respond flexibly to traffic fluctuations, maximize resource utilization, and avoid single-point performance bottlenecks.

[0083] like Figure 2 As shown, this embodiment of the invention also provides a blockchain-based data processing method applied to the immutable database system described in the above embodiments. The method includes: S1. Through the unified access control layer, receive and verify the user's data operation request, map the verified request to the on-chain trusted operation executed by the blockchain smart contract, and trigger the blockchain evidence storage layer to record the corresponding on-chain event log. A user application initiates a data insertion request, carrying data and a digital signature. The request arrives at the API gateway of the unified access control layer. The gateway invokes the corresponding smart contract. The contract first uses the user's public key to recover the signature and verify their identity. Then, it queries the RBAC policy within the contract to confirm that the user has the writer role. After successful verification, the contract executes the insertion logic, generates a new on-chain record, and triggers a LogEntry event containing details of the operation. This event is recorded in the blockchain's notarization layer. Thus, the user request is successfully mapped and recorded as a trusted on-chain operation.

[0084] S2. Through the dynamic heat perception storage layer, based on the data operation history obtained from the blockchain evidence storage layer, the heat value of each data item is determined by the data access heat prediction model, and the data is dynamically scheduled between the cache, local database and decentralized storage network according to the heat value and the dynamic scheduling rules. The monitoring service of the dynamic popularity-aware storage layer captures new LogEntry events and updates the popularity characteristics of the corresponding data items. The popularity prediction model periodically recalculates the predicted popularity values ​​for all data items. The scheduler makes decisions based on preset rules: for example, if it finds that a newly inserted data item's predicted popularity quickly rises to 0.85 due to its correlation, it issues an instruction to synchronize a copy of the data from the local database to the cache. At the same time, the scheduler finds that the popularity value of another batch of historical data has dropped to 0.15, so it initiates a migration task to package and upload this data to the decentralized storage network.

[0085] S3. For data stored in a decentralized storage network, the blockchain notarization layer generates and records a consistency anchor transaction containing the cryptographic hash of its data snapshot; based on the consistency anchor transaction, the integrity of the data in the decentralized storage network is independently verified.

[0086] After the aforementioned cold data migration task is completed, the migration service notifies the blockchain evidence storage layer. The anchor service in the blockchain evidence storage layer is then triggered, reading the CID of this new data from IPFS, calculating its Merkle root hash, and generating a consistent anchor transaction to be uploaded to the blockchain. When it is necessary to verify this batch of data archived on IPFS, the validator can call the system's public verification interface, inputting the CID of the data. The interface returns the corresponding anchor transaction and hash value on the blockchain. The validator downloads the data from IPFS, calculates the hash locally, and compares it with the on-chain value to complete an independent and objective integrity verification.

[0087] The triggering conditions for generating a consistent anchor transaction are: reaching a preset time or block cycle, or the dynamic heat sensing storage layer issuing a trigger signal after completing a batch of data migration.

[0088] In some embodiments, the method further includes a network node adaptive optimization step: monitoring the real-time load of nodes in the consensus network and dynamically adjusting the allocation of responsibilities among the verification, storage and routing roles of each node in response to changes in network state.

[0089] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain-based immutable database system, characterized in that, This includes a unified access control layer driven by smart contracts and a layered, verifiable storage engine; The unified access control layer integrates a set of data operation rules and dynamic permission management strategies defined and automatically executed by blockchain smart contracts. All user requests must be verified by the unified access control layer and mapped to trusted on-chain operations. The tiered verifiable storage engine includes: The blockchain evidence storage layer is used to immutably record on-chain event logs triggered by data operations in the form of a hash chain, and periodically generate consistent anchor transactions containing cryptographic hashes of data snapshots in the decentralized storage network. A dynamic heat-aware storage layer forms a verifiable anchoring relationship with the blockchain evidence storage layer. Based on a data access heat prediction model, the dynamic heat-aware storage layer dynamically stores and migrates data in layers between a cache, a local database, and a decentralized storage network. For data migrated to the decentralized storage network, its integrity is verified by comparing the hash value obtained by recalculating the corresponding data snapshot with the hash value in the corresponding consistency anchor transaction recorded in the blockchain evidence storage layer.

2. The blockchain-based immutable database system according to claim 1, characterized in that, The unified access control layer provides standardized data operation interfaces to the outside world. The data operation interfaces include operation interfaces for changing data status, operation interfaces for managing data access permissions, and data query interfaces. The operation interfaces for changing data status include a data insertion interface, a data update interface, and a data deletion interface; the operation interfaces for managing data access permissions include a permission granting interface and a permission revocation interface. When an operation is performed through the data insertion interface, data update interface, or data deletion interface, the blockchain evidence storage layer is triggered to generate an on-chain event log containing the operation type, data identifier, user signature, and timestamp. When performing operations through the data query interface, data can be obtained from the hierarchical verifiable storage engine, and Merkle proofs from the blockchain evidence storage layer can be obtained to verify the integrity of the data. The operation performed through the data deletion interface is a logical deletion operation; the smart contract marks the data as deleted, but retains the data hash value on the blockchain; the system is also configured with a background cleanup mechanism, which performs physical cleanup on the logically deleted data after the preset compliance retention period expires.

3. The blockchain-based immutable database system according to claim 1, characterized in that, The data operation rule set stipulates at least that all data write operations must be accompanied by a valid requester signature. The dynamic permission management strategy adopts a role-based access control model and is extended with dynamic authorization rules based on data attributes. The binding relationship between roles and permissions is updated through the management interface of smart contracts.

4. The blockchain-based immutable database system according to claim 3, characterized in that, For user requests that require writing to a class or permission change class, the unified access control layer's processing includes: By invoking the blockchain smart contract, the digital signature attached to the request is verified; the dynamic permission management policy maintained within the smart contract is queried to determine whether the requester is authorized to execute the operation; if the authorization is successful, the smart contract automatically constructs a blockchain transaction, converting the user request into an on-chain operation instruction; the blockchain transaction is submitted to the blockchain network, executed after consensus, and its execution result serves as a certificate of trusted on-chain operation. When the smart contract performs a data update or deletion operation, it requires the requester to provide an on-chain credential of the last valid operation. After verifying that the credential has not been used, the contract marks it as spent and records the details of this operation together with the hash of the old credential in an immutable event log.

5. The blockchain-based immutable database system according to claim 1, characterized in that, The blockchain notarization layer periodically generates consistent anchor transactions, and the system provides data integrity verification based on these transactions, including the following process: When a preset period is reached, a data snapshot of the current data state in the decentralized storage network is obtained, and the cryptographic hash value of the data snapshot is calculated; the cryptographic hash value, the unique identifier of the data snapshot, and the signature of the generating node are packaged to construct a consistency anchor transaction; the consistency anchor transaction is submitted to the blockchain network for consensus verification and recorded in the blockchain evidence storage layer; The system provides a public verification interface for verifiers to query the hash value in the consistency anchor transaction and compare it with the hash value recalculated from the data snapshot obtained from the decentralized storage network based on the unique identifier, in order to verify the integrity of the off-chain data.

6. The blockchain-based immutable database system according to claim 1, characterized in that, The dynamic heat-sensing storage layer performs dynamic hierarchical storage and migration processes, including: The data access popularity prediction model continuously monitors and analyzes the historical data operation logs recorded in the blockchain notarization layer, extracts the access frequency, recent access time, and associated query patterns of each data item, and predicts the access popularity value in future periods. The predicted access popularity value is compared with a preset threshold, and the data items are dynamically assigned to the corresponding storage layer based on the comparison results. If the predicted access popularity value of a data item is higher than the first preset threshold, it will be allocated to the cache. If the predicted access popularity value of a data item is between the first preset threshold and the second preset threshold, it will be assigned to the local database. If the predicted access popularity value of a data item is lower than the second preset threshold, it is marked as to be migrated to the decentralized storage network. Based on the partitioning results, data migration tasks between different storage tiers will be automatically triggered; For data migrated to a decentralized storage network, after the migration is completed, the dynamic heat perception storage layer triggers the blockchain evidence storage layer to generate associated consistent anchor transactions.

7. The blockchain-based immutable database system according to claim 1 or 3, characterized in that, The smart contracts integrated in the unified access control layer are deployed using an upgradeable proxy pattern, which includes beacon contracts and upgradeable logic contracts. The beacon contract is used to store the address of the latest logic contract, and the upgradeable logic contract contains specific business logic and permission rules. The upgrade operation of the smart contract is controlled by a multi-signature governance contract and requires a preset time lock delay period before execution.

8. The blockchain-based immutable database system according to claim 1, characterized in that, The system also includes a decentralized consensus and state synchronization network consisting of multiple nodes; The nodes in the network are configured to dynamically switch between three roles: verification node, storage node, and routing relay node, based on real-time load metrics. The real-time load metrics include at least the node's own computing resource utilization, network bandwidth utilization, and the length of the service request queue from other nodes.

9. A data processing method based on blockchain, characterized in that, Applied to the immutable database system of any one of claims 1 to 8, the method comprises: Through a unified access control layer, user data operation requests are received and verified. Verified requests are mapped to trusted on-chain operations executed by blockchain smart contracts, and the blockchain evidence storage layer is triggered to record the corresponding on-chain event logs. Through the dynamic heat perception storage layer, based on the data operation history obtained from the blockchain evidence storage layer, the heat value of each data item is determined by the data access heat prediction model, and the data is dynamically scheduled between the cache, local database and decentralized storage network according to the heat value and the dynamic scheduling rules. For data stored in a decentralized storage network, a consensus anchor transaction containing the cryptographic hash of its data snapshot is generated and recorded by the blockchain notarization layer; based on the consensus anchor transaction, the integrity of the data in the decentralized storage network is independently verified.

10. The data processing method based on blockchain according to claim 9, characterized in that, The rules for dynamic scheduling include: If the popularity value of a data item is higher than the first threshold, it will be placed in or retained in the cache. If the popularity value of a data item is between the first threshold and the second threshold, then place it in or migrate it to the local database; If the popularity value of a data item is lower than the second threshold, it will be migrated to a decentralized storage network.

Images