A blockchain multi-modal data management system based on Gin framework

Abstract

The application discloses a kind of blockchain multi-modal data management systems based on Gin framework, it is related to blockchain technology field, can be stored and managed multi-modal data simultaneously, realize on-chain and off-chain data collaborative management, reduce the storage pressure of blockchain.The present system is mainly divided into three layers, respectively for data processing intermediate layer and off-chain data layer, on-chain data layer, the three-layer multi-modal data management system is deployed in server, client sends transaction request, the transaction request is an http class request, server receives and parses transaction request, the data type of the data operated by parsing transaction, corresponding database is operated off-chain, and transaction is sent on-chain simultaneously, off-chain data layer includes IPFS database, MongoDB database, MySQL database and PostgreSqL database, accepts the data management operation of message distribution module.The advantages of Tendermint, IPFS and Gin framework are integrated into a unified multi-modal data management system, and a comprehensive solution that is safe, efficient and easy to use is provided.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically to a blockchain multimodal data management system based on the Gin framework. Background Technology

[0002] The Tendermint blockchain system is a distributed ledger platform based on a consensus algorithm, designed to provide secure, scalable, and high-performance blockchain solutions. This blockchain system employs a mechanism called the Byzantine Fault Tolerant (BFT) consensus algorithm, which enables consensus among nodes even if some nodes malfunction or engage in malicious behavior. This ensures that transactions and state transitions in the Tendermint network are correctly verified and confirmed. Furthermore, this consensus algorithm features high throughput and fast confirmation, capable of handling large volumes of transactions and achieving near real-time finality.

[0003] This blockchain system manages and maintains the network using a set of validators. These validators are responsible for proposing and confirming blocks, ensuring that all nodes reach consensus during the consensus process. Within the system, applications run independently, interacting with the Tendermint core engine through the ABCI (Application Blockchain Interface). A transaction is a user-defined sequence of operations and the basic unit of data within a block; transactions are executed with atomicity, consistency, isolation, and durability within the ABCI.

[0004] Tendermint also provides a secure P2P network layer for communication and data transmission between nodes. This network layer supports encrypted connections and mechanisms to prevent Byzantine faults, ensuring the confidentiality and integrity of data.

[0005] Overall, the Tendermint blockchain system, with its powerful consensus algorithm, high-performance transaction processing capabilities, and flexible application programming interface (API), provides developers and enterprises with a solution for building secure and scalable distributed applications. It has broad application prospects in fields such as finance, supply chain, and digital assets.

[0006] Existing blockchain database systems are limited to simple transactions, only supporting basic transaction data. This does not meet the diverse needs of data management and cannot support operations such as direct on-chain data management, making simple CRUD operations cumbersome.

[0007] Traditional data management systems often rely on centralized databases, making it difficult to guarantee data immutability and auditability. Once data is tampered with or incorrectly modified, it is difficult to trace and verify. Tendermint provides a high-performance blockchain underlying framework that can ensure data immutability and network-wide consensus, but it does not directly provide high-level application logic for data management.

[0008] In multimodal data management, the efficiency of data access and distribution is crucial. Traditional centralized storage solutions can lead to data access bottlenecks and single points of failure. The InterPlanetary File System (IPFS) provides a distributed storage solution that optimizes data storage and retrieval efficiency, but it lacks deep integration with blockchain technology to ensure data integrity and security.

[0009] Traditional systems may lack flexibility and scalability, making it difficult to meet the needs of different users. Gin is a high-performance Go web framework that can easily build RESTful APIs and improve development efficiency, but it does not directly provide integration solutions for blockchain or distributed storage.

[0010] Therefore, how to combine blockchain technology, IPFS technology, and database theory to build a multimodal data management system that can support complex transaction data, meet the diversity of data management, support the collaborative management of on-chain and off-chain data, and reduce the storage pressure on the blockchain is an urgent problem to be solved. Summary of the Invention

[0011] In view of this, the present invention provides a blockchain multimodal data management system based on the Gin framework, which can realize on-chain and off-chain data collaborative management while storing and managing multimodal data, thereby reducing the storage pressure on the blockchain.

[0012] To achieve the above objectives, the technical solution of the present invention is as follows: a blockchain multimodal data management system based on the Gin framework, comprising a three-layer structure of a data processing middleware layer, an off-chain data layer, and an on-chain data layer, wherein the three-layer multimodal data management system is deployed on the server side; the client sends a transaction request, which is received by the server side.

[0013] The data processing middleware layer includes an interaction interface, an access authentication module, a unified modeling module for JSON data processing, and a message distribution module.

[0014] The interaction interface is used for data interaction between the client and the server, including: receiving transaction requests and returning data processing responses; and sending transaction requests to the unified modeling module for JSON data processing.

[0015] The access authentication module is used for user identity management.

[0016] The unified modeling module for JSON data processing is used to parse transaction requests, parse the data types operated on by the transaction, and map the parsed data to the defined model. The mapped data is then sent to the message distribution module. The data types operated on by the transaction include file data, user data, and database data.

[0017] The message distribution module receives the mapped data, calculates the hash value of the data, stores it in the carrier Tx, and broadcasts the carrier Tx to the blockchain. If the blockchain returns a successful broadcast response to the message distribution module, it means that the blockchain has successfully received the transaction. After receiving the successful broadcast response, the message distribution module distributes the transaction to the off-chain data management layer to manage the data in the database corresponding to the transaction.

[0018] The on-chain data layer includes a user permission management module, an on-chain data retrieval module, and an on-chain data storage module.

[0019] The user permission management module is used to manage user permissions.

[0020] The on-chain data storage module establishes a state database on the Tendermint chain for storing file-type data, user-type data, and database-type data.

[0021] The on-chain data storage module is used to retrieve data using the state database.

[0022] The off-chain data layer includes IPFS, MongoDB, MySQL, and PostgreSQL databases, which accept data management operations from the message distribution module.

[0023] Furthermore, the access authentication module is used for user identity management, specifically as follows: When a user logs in and enters their information, the first step is to access the authentication module to query the user information from the blockchain. If an error occurs during the query process, a JSON response indicating an input error is returned, and further processing is terminated.

[0024] The second step is to check whether the user has been revoked.

[0025] The third step is to verify whether the signature in the request is valid. If the signature verification fails, an error message indicating that the user's signature is invalid is returned, and further processing is terminated.

[0026] The fourth step is to parse and verify the certificate content and check the certificate's validity period. If the current time is later than the certificate's expiration time, the certificate has expired, the corresponding error message is returned, and further processing is terminated.

[0027] If all verifications pass, a success response is returned, including the user role, user ID, username, registration ID, registration time, revocation status, and a randomly generated verification code. Each response's verification code is random and unique. The system also provides functions for deleting users and updating user information. All user data is recorded on the blockchain, allowing for the storage, updating, and deletion of user information.

[0028] Furthermore, the unified modeling module for JSON data processing specifically includes: The Model is defined to represent and process database-related data structures and operations. It includes three types of Models, which correspond to the data types operated on by the transaction, namely file data, user data, and database data.

[0029] The model corresponding to the file data contains seven fields: FileType, Cid, Feature, Uuid, Name, Uploader, and Time. The FileType field represents the file type; the Cid field represents the file-specific content identifier; the Feature field represents the file's characteristic data; the Uuid field represents the file's unique identifier; the Name field represents the file's name; the Uploader field represents the uploader's identifier; and the Time field represents the file upload timestamp.

[0030] The Model corresponding to database-type data consists of seven fields: TxId, Txtype, TxOp, Txtable, TxAttr, TxValue, and Time. The TxId field is a unique identifier for each record; the Txtype field is the database type of the transaction; the TxOp field is the operation type; the Txtable field is the database table name of the operation; the TxAttr field is the column name of the operation; the TxValue field is the content of the specific operation; and the Time field is the timestamp of the operation.

[0031] The model corresponding to user data is as follows: it includes UserRole, UserId, Name, PubKey, CertContent, Register, Time, and IsRevoked; where UserRole is the user's role; UserId is the user ID; Name is the username; PubKey is the public key; CertContent is the certificate content; Register is the user's registration information; Time is the timestamp of the operation; and IsRevoked is a flag indicating whether the operation has been revoked.

[0032] Furthermore, in the message distribution module, the carrier Tx specifically includes the following four fields: Type, Objects, Operation, and Data. The Type field is the data type; the Objects field is the database table name to be operated on; the Operation field is the type of operation; and the Data field is the specific operation content.

[0033] Furthermore, the on-chain data storage module establishes three state databases on the Tendermint chain. The first key-value database, db1, stores the key data type and the specific location of the value data operation. The second key-value database, db2, stores the specific location of the key data operation and the value of the specific data operation. The third key-value database, db3, stores the specific location of the key data operation and the operation type of the value data.

[0034] The on-chain storage operation for file-type data (`file`) is as follows: When uploading file-type data, the file controller middleware connected to off-chain storage maps the received file-type data to the carrier `Tx`. Feature extraction is performed on the file to obtain its characteristics and attributes. The `Data` field of `Tx` stores the specific information of the file. The on-chain data storage module generates the file's UUID. First, the on-chain data storage module decodes the transaction data, using the Amino codec library to decode the data in the transaction into a `file` structure. The on-chain data storage module stores the file information in the database according to the carrier `Tx`, with the file type and UUID as the key in `db1` and `Cid` as the value. The file ID and specific data are stored in database db2, while the Cid and operation data are stored in database db3. Simultaneously, the on-chain data storage module updates the UUIDS record. First, it checks if a corresponding UUIDS record exists in database db1. If it does, the new file.Uuid is appended, and the updated Cid list is stored back in database db2. If it doesn't exist, the UUIDS record is created directly in database db1, and the corresponding Cid is stored. Then, the on-chain data storage module constructs a new event, recording the file UUID and Cid so that the client is notified. Similarly, user file downloads and file queries are also recorded on the chain.

[0035] The on-chain storage operation for user data is as follows: When processing user data, different data processing strategies are adopted depending on the operation type. First, the User object is obtained by deserializing the content in tx.Data. If an error occurs in any step, the corresponding error code and log information are returned. For the "add" operation, the user type and user ID are first used as keys in db1, and the username and user ID are stored as values. Then, the username and user ID are used as keys in db2, and the user data is saved as values. Finally, the operation type is associated with the username and user ID and saved in db3. If the key "user.Name:user.UserId" already exists in db2, the new username and user ID are added to the list and updated. This operation is "update". If it does not exist, the key is created and a new record is set. For the "update" operation, the existing user data is first deleted from db2, and then the new user data is saved in db2. Next, the operation type is associated with the user ID and saved in db3. If the user does not exist, the operation is "add".

[0036] The on-chain storage operation for database data is as follows: When processing database-related operations, the system distinguishes between different operations based on the value of tx.Operation. First, the "INSERT" operation, i.e., the data insertion operation, is handled as follows: First, the data in tx.Data is deserialized into a Member structure to obtain detailed operation information. The database type plus identifier and table name + column name from the Member structure are stored as key-value pairs in database db1. The table name + column name and tx.Data are stored as key-value pairs in database db2 to store the actual data content. The operation type is recorded in database db3, i.e., the table name + column name and operation type are stored as key-value pairs. If the key (table name + column name) already exists in database db2, it indicates that a data update is required. The on-chain data storage module then stores the data and operation type in databases db2 and db3 respectively, this time with the operation type being "UPDATE". The operation event is recorded, including the creator and other relevant attributes, for subsequent data tracking and auditing. Finally, a successful operation response is returned, including operation event information, indicating that the data has been successfully processed and recorded on the chain.

[0037] Furthermore, the on-chain data retrieval module uses the following specific data retrieval methods: First, clarify the data type of the target query; for the information the user wants to query, perform the following steps: Step 1: First, use "[data type]:[identifier]" as the key to query the first key-value database; then use the value returned by the first key-value database as the key to query the second and third key-value databases to find the specific location of the data operation and the value of the data being operated on.

[0038] Step 2: In the second key-value database, use the specific location key obtained from the first step to query the corresponding specific operation data value (Data).

[0039] Step 3: In the third key-value database, using the specific location key, query the operation type of the data to understand how the data is processed.

[0040] Step 4: Combine the query results obtained in Step 2 and Step 3 to obtain complete data information, including data content and data operation type; for cases that reference off-chain storage, query the corresponding off-chain storage system based on the reference in on-chain storage to obtain the actual data content.

[0041] Beneficial effects: 1. This invention provides a blockchain multimodal data management system based on the Gin framework, suitable for on-chain and off-chain storage in blockchains. It reduces the storage pressure on on-chain systems through on-chain and off-chain collaboration. Simultaneously, leveraging the Tendermint transaction programming language, the diversity of state databases, and the decoupling of applications and consensus engines, a blockchain application based on a relational database is developed. SQL functions are encapsulated in the access interface, maintaining on-chain state data in the form of relational tables to meet users' complex query needs. By combining Tendermint blockchain technology, this invention provides a multimodal data management system that ensures data immutability and easy traceability. This not only enhances data security but also improves the transparency of data management. Utilizing IPFS distributed storage technology, this invention significantly improves data access and distribution efficiency, solving the data access bottlenecks and single points of failure problems existing in traditional centralized storage solutions. Through the RESTful API built using the Gin framework, this invention provides a set of efficient and flexible user interaction APIs, enabling users to easily manage and access multimodal data. The core contribution of this invention lies in integrating the advantages of Tendermint, IPFS, and the Gin framework into a unified multimodal data management system, providing a comprehensive solution that is secure, efficient, and easy to use. Attached Figure Description

[0042] Figure 1 This is a framework diagram of the multimodal data management system used in this system; Figure 2A flowchart for uploading file-type data; Figure 3 Flowchart for downloading files; Figure 4 A flowchart illustrating the storage and query process of a database; Figure 5 This is a flowchart illustrating the collaborative process between on-chain and off-chain data. Detailed Implementation

[0043] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0044] This invention provides a blockchain multimodal data management system based on the Gin framework, the framework of which is as follows: Figure 1 As shown, the system comprises a three-layer architecture: a data processing middleware layer, an off-chain data layer, and an on-chain data layer. This three-layer multimodal data management system is deployed on the server side. Clients issue transaction requests, which are received by the server. The server receives and parses the transaction request through an interactive interface, determining the data type of the transaction, performing the corresponding off-chain database operations, and simultaneously sending the transaction on-chain. The on-chain data layer is responsible for verifying the legality of blocks and broadcasting the proof of block validity to other nodes. In each round of consensus, the validating nodes take turns acting as the leader node, responsible for packaging transactions into blocks.

[0045] In this embodiment of the invention, the data processing middleware layer includes an interaction interface, an access authentication module, a unified modeling module for JSON data processing, and a message distribution module.

[0046] The interaction interface is used for data interaction between the client and the server, including: receiving transaction requests and returning data processing responses; and sending transaction requests to the unified modeling module for JSON data processing.

[0047] The access authentication module is used for user identity management. For user identity management, this invention designs middleware to control user login and registration behaviors, managing user permissions, identity, passwords, etc. When a user logs in, the server first queries the blockchain for user information. If an error occurs during the query (e.g., the user does not exist), a JSON response indicating an input error is returned, and further processing is terminated. The second step checks if the user has been revoked. The third step verifies the validity of the signature in the request. If signature verification fails, an error message indicating an invalid signature is returned, and further processing is terminated. The fourth step parses and verifies the certificate content and checks the certificate's validity period. If the current time is later than the certificate's expiration time, the certificate has expired, a corresponding error message is returned, and further processing is terminated. If all verifications pass, a success response is returned, including the user's role, user ID, username, registration ID, registration time, revocation status, and a randomly generated verification code. Each response's verification code is random and unique. This system also provides functions such as deleting users and updating user information. All user data is stored on the blockchain, including user information and updates.

[0048] A unified modeling module for JSON data processing is used to parse transaction requests, analyze the data types operated on by the transactions, and map the parsed data to a defined model. The mapped data is then sent to the message distribution module. The data types operated on by the transactions include file data, user data, and database data. In this embodiment of the invention, a multimodal data model is defined in the Gin framework. The defined model is typically used to represent and process database-related data structures and operations, and is the part of the application used to process application data logic. The model defines the data structure, usually using structs to represent tables in the database. Each field in the model corresponds to a column in the database table, allowing for type-safe data manipulation in the code. The model also encapsulates database operations such as querying, inserting, updating, and deleting (CRUD operations). These operations can be implemented using an ORM (Object-Relational Mapping) library, such as GORM, or through custom data access logic. This invention designs corresponding models for "file", "user", "sql", and "nosql" data types.

[0049] In this embodiment of the invention, the unified modeling module for JSON data processing specifically includes: The Model is defined to represent and process database-related data structures and operations. It includes three types of Models, which correspond to the data types operated on by the transaction, namely file data, user data, and database data.

[0050] The model corresponding to the file data contains seven fields: FileType, Cid, Feature, Uuid, Name, Uploader, and Time. The FileType field represents the file type; the Cid field represents a file-specific identifier; the Feature field represents the file's characteristic data; the Uuid field represents the file's unique identifier; the Name field represents the file's name; the Uploader field represents the uploader's identifier; and the Time field represents the file upload timestamp. See Table 1 for details. Table 1

[0051] The model corresponding to database-type data consists of seven fields: TxId, Txtype, TxOp, Txtable, TxAttr, TxValue, and Time. The TxId field is a unique identifier for each record; the Txtype field indicates the database type of the transaction; the TxOp field indicates the operation type; the Txtable field is the database table name; the TxAttr field is the column name; the TxValue field is the content of the specific operation; and the Time field is the timestamp of the operation. The specific field structure is shown in Table 2. Table 2

[0052] The model corresponding to user-type data is as follows: it includes UserRole, UserId, Name, PubKey, CertContent, Register, Time, and IsRevoked; where UserRole is the user's role; UserId is the user ID; Name is the username; PubKey is the public key; CertContent is the certificate content; Register is the user's registration information; Time is the timestamp of the operation; and IsRevoked is a flag indicating whether the operation has been revoked. See Table 3 for details. Table 3

[0053] The message distribution module receives the mapped data, calculates the hash value of the data, stores it in the carrier Tx, and broadcasts the carrier Tx to the blockchain. If the blockchain returns a successful broadcast response to the message distribution module, it means that the blockchain has successfully received the transaction. After receiving the successful broadcast response, the message distribution module distributes the transaction to the off-chain data management layer for data management of the database corresponding to the transaction. In this embodiment of the invention, the carrier Tx in the message distribution module specifically includes the following four fields: Type, Objects, Operation, and Data. The Type field is the data type; the Objects field is the database table name of the operation; the Operation field is the type of operation; and the Data field is the specific operation content, as shown in Table 4. Table 4

[0054] The on-chain data layer includes a user permission management module, an on-chain data retrieval module, and an on-chain data storage module.

[0055] The user permission management module is used for user permission management. In this embodiment of the invention, to ensure the security of operations, all user operations require permission verification at the on-chain data layer. We use digital signatures based on the ECDSA algorithm to verify user permissions. This process includes the following key steps: First, the signature is parsed, converting the signature string into a byte sequence to prepare for hash processing and signature verification. Then, the ECDSA public key is parsed from the PEM format public key string. If parsing fails or the public key type does not match, an error will be returned or an exception will be thrown. The parsed ECDSA public key, the message byte sequence, and the signature byte sequence are input for signature verification. The message is hashed using the SHA-256 algorithm, and then the hash value and signature are verified, returning a boolean value indicating whether the signature is valid. Meanwhile, different roles have different operation permissions. After verifying the user's permissions, the user can perform related operations such as registration, login, query, update, and revocation to manage user information.

[0056] The on-chain data storage module establishes a state database on the Tendermint chain for storing file-type data, user-type data, and database-type data. The on-chain data structure includes, but is not limited to, transaction data, account status, smart contract status, and logs. Tendermint provides the ABCI (Application Blockchain Interface), which allows applications to interact with the Tendermint core. This means that custom data storage logic can be defined within ABCI applications. A common practice is to use a key-value store (such as LevelDB) to persist on-chain data, where the key is typically a transaction hash or account address, and the value is the corresponding data itself. The system provides a query interface, allowing external systems to retrieve on-chain data using indexes such as transaction hashes and account addresses. In Tendermint, the Query method can be implemented to support querying on-chain data. Furthermore, an event system can be designed to obtain real-time on-chain data updates by subscribing to specific events. The design also needs to consider how to associate on-chain data with off-chain data (such as files on IPFS or records in a database). A common practice is to store index information of off-chain data (such as file hashes in IPFS or unique identifiers for database records) on-chain so that off-chain data can be quickly retrieved when needed.

[0057] In this embodiment of the invention, the on-chain data storage module establishes three state databases on the Tendermint chain. On-chain data is primarily stored in key-value pairs, where the key is typically a unique identifier for the data, and the value is the actual data content or a reference to off-chain storage. Tendermint on-chain storage can be divided into three modules based on data type: file-type, user-type, and database-type data storage. Therefore, in this invention, the first key-value database db1 stores the key data type and the specific location of the value data operation; the second key-value database db2 stores the specific location of the key data operation and the value of the specific data operation; and the third key-value database db3 stores the specific location of the key data operation and the operation type of the value data.

[0058] The on-chain storage operation for file-type data (`file`) is as follows: When uploading file-type data, the file controller middleware connected to off-chain storage maps the received file-type data to the carrier `Tx`. Feature extraction is performed on the file to obtain its characteristics and attributes. The `Data` field of `Tx` stores the specific information of the file. The server (on-chain data storage module) generates the file's UUID. First, the system decodes the transaction data using the Amino codec library to decode the data in the transaction into a `file` structure. The system stores the file information in the database according to the carrier `Tx`. The file type and UUID are used as the key in `db1`, and the Cid is used as the value. The file's Cid and specific data are stored in database `db2`, and the Cid and operation (upload, download, etc.) are stored in database `db3`. Simultaneously, the system updates the UUIDS record. First, it checks if a corresponding UUIDS record exists in database `db1`. If it exists, the new `file.Uuid` is appended to it, and the updated Cid list is stored back in database `db2`. If it does not exist, a UUIDS record is created directly in database `db1`, and the corresponding Cid is stored. The system then constructs new events, recording the file's UUID and CID so that clients can be notified. Similarly, user file downloads and file queries are also recorded on the blockchain.

[0059] The on-chain storage operation for user data is as follows: When processing user data, different data processing strategies are adopted depending on the operation type (e.g., "add" represents adding a user, and "update" represents updating user information). First, the User object is obtained by deserializing the content in tx.Data. If an error occurs at any step, the corresponding error code and log information will be returned. For the "add" operation, the user type (tx.Type) and user ID (user.UserId) are first used as keys in db1, and the username (Name) and user ID are stored as values. Then, the username (Name) and user ID are used as keys in db2, and the user data (Data) is saved as values. Finally, the operation type ("add") is associated with the username (Name) and user ID and stored in db3. If the key "user.Name:user.UserId" already exists in db2, the new username and user ID are added to the list and updated; this operation is "update". If it does not exist, the key is created and a new record is set. For the "update" operation, the existing user data is first deleted from db2, and then the new user data (tx.Data) is saved in db2. Next, the operation type ("update") is associated with the user ID and saved in db3. If the user does not exist, the operation is "add".

[0060] On-chain storage operations for database data are as follows: When handling database-related operations (such as MySQL, MongoDB, PostgreSQL), the system differentiates processing based on the value of `tx.Operation`. First, let's introduce the "INSERT" operation, i.e., the processing of data insertion. First, the data in `tx.Data` is deserialized into a `Member` structure to obtain detailed operation information. The database type (`Txtype`) plus identifier (`TxId`) and table name + column name (`Txtable` + `TxAttr`) from the `Member` structure are stored as key-value pairs in database `db1`. The table name + column name (`Txtable` + `TxAttr`) and `tx.Data` are stored as key-value pairs in database `db2` to store the actual data content. The operation type is recorded in database `db3`, i.e., the table name + column name (`Txtable` + `TxAttr`) and operation type (`TxOp`) are stored as key-value pairs. This helps track what the last operation was for each data item. If the key (i.e., table name + column name) already exists in database `db2`, it indicates that a data update is required. The system will then store the data and operation type again in the db2 and db3 databases, respectively, this time with the operation type set to "UPDATE". The operation event is recorded, including the creator and other relevant attributes, which aids in subsequent data tracking and auditing. Finally, a successful operation response is returned, including the operation's event information. This indicates that the data has been successfully processed and recorded on the blockchain.

[0061] The on-chain data retrieval module is used to retrieve data using a state database. In this embodiment of the invention, the specific data retrieval method of the on-chain data retrieval module is as follows: First, clarify the data type of the target query; for the information the user wants to query, perform the following steps: Step 1: First, use "[data type]:[identifier]" as the key to query the first key-value database; then use the value returned by the first key-value database (such as Cid, Name:UserId, Txtable:Txattr) as the key to query the second and third key-value databases to find the specific location of the data operation and the value of the data being operated on.

[0062] Step 2: In the second key-value database, use the specific location key obtained from the first step to query the corresponding specific operation data value (Data).

[0063] Step 3: In the third key-value database, using the specific location key, query the operation type of the data to understand how the data is processed.

[0064] Step 4: Combine the query results obtained in Step 2 and Step 3 to obtain complete data information, including data content and data operation type; for cases that reference off-chain storage, query the corresponding off-chain storage system based on the reference in on-chain storage to obtain the actual data content.

[0065] Figure 4 This describes the storage and query process for the database.

[0066] The off-chain data layer includes IPFS, MongoDB, MySQL, and PostgreSQL databases, which accept data management operations from the message distribution module.

[0067] For file-type data, this invention uses IPFS as the off-chain storage for raw data. IPFS is a distributed file system designed to connect all computing devices and store files through content addressing. Each file and all blocks have a unique fingerprint called a hash value. This makes IPFS ideal as a platform for storing large amounts of raw file-type data, providing an efficient, reliable, and decentralized data storage solution. First, IPFS nodes are deployed by installing the IPFS package on a server, making it a node in the network. Each node stores a portion of a file and can request other nodes in the network to provide portions they do not have. When a user uploads a file, the system stores the file in the IPFS network. IPFS generates a unique hash value (CID) for each file, representing the file's content. In this way, even if a file is stored on different nodes in the network, anyone can retrieve the file using the hash value. Although the file's metadata is stored in IPFS, this invention still requires storing crucial indexing information (e.g., the IPFS hash value) on the blockchain. This allows the system to leverage the immutability of the blockchain to ensure data integrity and traceability. When a user needs to access a specific file, the system first retrieves the corresponding IPFS hash value from the blockchain, and then retrieves and downloads the file through the IPFS network. This design stores key metadata information (such as hash values ​​pointing to data in IPFS) on the Tendermint blockchain, while storing more detailed data content in IPFS.

[0068] In this embodiment of the invention, the file-type data storage process is as follows: (IPFS off-chain and Tendermint on-chain) Figure 3 As shown: Clients can send POST requests. The routing group provides "file upload ( / file / upload)," "file query ( / file / query)," and "file download ( / file / download)." Client input mainly consists of two parts: the HTTP request method and the payload. Specifically, each API endpoint (route) expects clients to submit requests according to a predefined format and data structure. After receiving the instructions, the system parses them and performs the corresponding operations.

[0069] First, let's introduce off-chain data management: Figure 2 This design provides a file upload function, which will be introduced below: (1) Receiving Files: The client retrieves the files uploaded by the client. If an error occurs during the process, such as the file not being received, an error response is returned.

[0070] (2) Saving to the server: The client then extracts information from the uploaded file (using a feature extraction algorithm), creates a `requestFile` structure instance, and prepares for subsequent operations. The received file is saved to the server's temporary directory. If saving the file fails, an error response is returned.

[0071] (3) Save to IPFS: The server saves the file to IPFS and obtains the file's unique identifier (CID) in IPFS. If the save fails, an error message is returned and the operation is terminated.

[0072] (4) Prepare data for on-chain upload: Create a SHA-256 hash object using sha256.New(), and calculate the hash value using the file's CID as input. Serialize the requestFile object (containing file information and CID) into JSON format data, ready for on-chain upload.

[0073] (5) Construct and broadcast the transaction: Construct a transaction tx containing file information and broadcast the transaction to the blockchain network. This step means storing the file's metadata (such as CID) on the blockchain to achieve data immutability and persistence.

[0074] (6) Processing the on-chain result: Check the return result ret of the on-chain operation. If the operation fails (e.g., ret is empty, or either CheckTx.Code or DeliverTx.Code is not 0), execute the error handling logic, such as deleting the file uploaded to IPFS and returning an error message to the client. If the on-chain operation is successful, delete the temporary file on the server and return a success message to the client, including the file's CID and the calculated hash value.

[0075] Figure 3 This design provides a file download function. (1) Get UUID: Get the field value named "uuid" from the client's POST form. This value is the file's unique identifier.

[0076] (2) Query file information by UUID: Use GetHttp().ABCIQuery to send a query request to Tendermint to query the file information corresponding to the provided UUID.

[0077] (3) Process query results: Check the query response code. If the code is not 0, it means that the corresponding file was not found, return the error message "UUID does not exist" to the client, and terminate the processing. If the query is successful, parse the file information in the response.

[0078] (4) Retrieve file from IPFS: Try retrieving file information again, possibly to ensure the accuracy of the file information or for processing logic needs. Retrieve file information from IPFS based on the UUID.

[0079] (5) Download file: Determine the local storage path of the file to be downloaded, and download the file from IPFS to the specified path.

[0080] (6) Provide the file to the client: Open the downloaded file stored locally, ready to send it to the client. Set the HTTP response headers, including content type, content transfer encoding, cache control, and content handling, the latter instructing the browser how to handle the response content (download as an attachment or display inline). Send the file as a response to the client, allowing the client to download or preview the file.

[0081] Figure 5 This refers to the collaborative process between on-chain and off-chain data.

[0082] First, let's introduce the storage of database data. The server first extracts database information from the JSON data received from the client and maps it to the member carrier. If JSON parsing fails, the function returns a failure status code and error message, and then terminates. If parsing is successful, the server operates on the corresponding database according to the parsed instructions. If creation fails (e.g., due to data verification failure or database error), a status code and error message are returned. The server sends a transaction to Tendermint to perform the on-chain operation. The system creates a SHA-256 hash object to calculate the hash value of the newly generated TxId. This transaction is then broadcast to the blockchain. If the on-chain operation is successful, a response containing a success message, a hexadecimal string of the TxId, and a hexadecimal string of the TxId hash value is returned to the client. If any problems are encountered during the on-chain process (such as transaction verification failure or processing failure), the previously created member record is deleted, and an error message is returned to the client. If the on-chain operation is successful, in addition to printing the member ID (mainly for server-side logging or debugging), a JSON response containing a success message, TxId, and hash value is sent to the client via ctx.JSON.

[0083] The second part involves querying database data. This research designs a system that queries information based on the ID input by the client and processes the query results into a blockchain transaction. The server first determines the database to be operated on based on the client's request header, obtains the ID (id) from the request URL parameters, and then uses the provided ID to query information. If the relevant information is successfully found, pre-chain preparation work is performed, calculating the hash value of the member's TxId using the SHA256 algorithm. The hash value and TxId are converted into hexadecimal strings for transmission and display. A blockchain transaction object is constructed using the member information and serialized into JSON. Finally, the constructed transaction is submitted to the blockchain network, and the transaction submission result is checked. If the transaction submission fails (e.g., due to transaction verification failure), an attempt is made to delete the member record, and an error response is returned. If the transaction is successfully submitted and confirmed, a success response is returned, including the queried member information and the hash value of the member's TxId. In a successful case, the client response body contains the message "Data Query Successful," the member information, the hexadecimal string of the member's TxId, and the hexadecimal string of the TxId hash value.

[0084] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A blockchain multimodal data management system based on the Gin framework, characterized in that, The system comprises a three-layer architecture: a data processing middleware layer, an off-chain data layer, and an on-chain data layer. This three-layer multimodal data management system is deployed on the server side. Clients send transaction requests, which are received by the server. The data processing middleware layer includes an interaction interface, an access authentication module, a unified modeling module for JSON data processing, and a message distribution module. The interaction interface is used for data interaction between the client and the server, including: receiving transaction requests and returning data processing responses; The transaction request is sent to the unified modeling module for JSON data processing. The access authentication module is used for user identity management; The unified modeling module for JSON data processing is used to parse the transaction request, parse the data type operated by the transaction, and map the parsed data to the defined model. The mapped data is then sent to the message distribution module. The data types operated by the transaction include file data, user data, and database data. The message distribution module receives the mapped data, calculates the hash value of the data, stores it in the carrier Tx, and broadcasts the carrier Tx to the blockchain. If the blockchain returns a successful broadcast response to the message distribution module, that is, the blockchain has successfully received the transaction. After receiving the successful broadcast response, the message distribution module distributes the transaction to the off-chain data management layer to manage the data in the database corresponding to the transaction. The on-chain data layer includes a user permission management module, an on-chain data retrieval module, and an on-chain data storage module; The user permission management module is used to manage user permissions; The on-chain data storage module establishes a state database on the Tendermint chain for storing file-type data, user-type data, and database-type data. The on-chain data storage module is used to retrieve data using the state database; The off-chain data layer includes IPFS, MongoDB, MySQL, and PostgreSQL databases, and accepts data management operations from the message distribution module.

2. The blockchain multimodal data management system based on the Gin framework as described in claim 1, characterized in that, The access authentication module is used for user identity management, specifically as follows: When a user logs in and enters user information, the access authentication module first queries the user information from the blockchain. If an error occurs during the query process, it returns a JSON response indicating an input error and terminates further processing. The second step is to check whether the user has been revoked. The third step is to verify whether the signature in the request is valid. If the signature verification fails, an error message indicating that the user's signature is invalid is returned, and further processing is terminated. The fourth step is to parse and verify the certificate content and check the certificate's validity period. If the current time is later than the certificate's expiration time, the certificate has expired, the corresponding error message is returned, and further processing is terminated. If all verifications pass, a success response is returned, including the user role, user ID, username, registration ID, registration time, revocation status, and a randomly generated verification code. Each response's verification code is random and unique. The system also provides functions for deleting users and updating user information. All user data is recorded on the blockchain, allowing for the storage, updating, and deletion of user information.

3. A blockchain multimodal data management system based on the Gin framework as described in claim 1, characterized in that, The unified modeling module for JSON data processing specifically includes: Define a Model to represent and process database-related data structures and operations. There are three types of Models, which correspond to the data types of transactions, including file data, user data, and database data. The model corresponding to the file type data is as follows: it contains seven fields: FileType, Cid, Feature, Uuid, Name, Uploader, and Time. The FileType field represents the file type; the Cid field represents the file-specific content identifier; the Feature field represents the file's characteristic data; the Uuid field represents the file's unique identifier; and the Name field represents the file's name. The Uploader field represents the uploader's identifier; the Time field represents the timestamp of the file upload. The database data corresponds to a Model with seven fields: TxId, Txtype, TxOp, Txtable, TxAttr, TxValue, and Time. The TxId field is a unique identifier for each record; the Txtype field indicates the database type of the transaction; the TxOp field indicates the operation type; the Txtable field is the database table name of the operation; the TxAttr field is the column name of the operation; the TxValue field is the content of the specific operation; and the Time field is the timestamp of the operation. The model corresponding to the user class data is: containing UserRole, UserId, Name, PubKey, CertContent, Register, Time, and IsRevoked; where the UserRole field is the user's role; the UserId field is the user ID; the Name field is the username; the PubKey field is the public key; and the CertContent field is the certificate content. The Register field contains the user's registration information; the Time field contains the timestamp of the operation; and the IsRevoked field indicates whether the operation has been revoked.

4. A blockchain multimodal data management system based on the Gin framework as described in claim 3, characterized in that, The message distribution module's carrier Tx specifically includes the following four fields: Type, Objects, Operation, and Data. The Type field represents the data type; the Objects field represents the database table name being operated on; the Operation field represents the type of operation; and the Data field represents the specific operation content.

5. A blockchain multimodal data management system based on the Gin framework as described in claim 1, characterized in that, The on-chain data storage module establishes three state databases on the Tendermint chain. The first key-value database db1 is used to store the key data type and the specific location of the value data operation. The second key-value database db2 stores the specific location of the key data operation and the value of the specific data operation. The third key-value database db3 stores the specific location of the key data operation and the operation type of the value data. The on-chain storage operation for file-type data (`file`) is as follows: When file-type data is uploaded, the file controller middleware connected to off-chain storage maps the received file-type data to the carrier `Tx`. Feature extraction is performed to obtain the file's characteristics and attributes. The `Data` field of `Tx` stores the specific information of the file. The on-chain data storage module generates the file's UUID. First, the on-chain data storage module decodes the transaction data, using the Amino codec library to decode the data in the transaction into a `file` structure. Based on the carrier `Tx`, the on-chain data storage module stores the file information in the database. The file type and UUID are used as the key in `db1`, and the Cid is used as the value. The file's Cid and specific data are stored in database `db2`, and the Cid and operation are stored in database `db3`. Simultaneously, the on-chain data storage module updates the UUIDS record. First, it checks if a corresponding UUIDS record exists in database `db1`. If it exists, the new `file.Uuid` is appended to it. The updated Cid list is then stored back in database db2. If it does not exist, a UUIDS record is created directly in database db1 and the corresponding Cid is stored. Then, the on-chain data storage module constructs a new event, records the file UUID and Cid, so that the client can be notified. Similarly, user file download and file query operations are also recorded on the chain. The on-chain storage operation for user data is as follows: When processing user data, different data processing strategies are adopted depending on the operation type. First, the User object is obtained by deserializing the content in tx.Data. If an error occurs in any step, the corresponding error code and log information are returned. For the "add" operation, the user type and user ID are first used as keys in db1, and the username and user ID are stored as values. Then, the username and user ID are used as keys in db2, and the user data is saved as values. Finally, the operation type is associated with the username and user ID and stored in db3. If the key "user.Name:user.UserId" already exists in db2, add the new username and user ID to the list and update it; this operation is "update". If it does not exist, create the key and set a new record. For the "update" operation, first delete the existing user data from db2, then save the new user data in db2; next, associate the operation type with the user ID and save it in db3; if the user does not exist, this operation is "add". The on-chain storage operation for database data is as follows: When processing database-related operations, the system distinguishes between different operations based on the value of tx.Operation. First, the "INSERT" operation, i.e., the data insertion operation, is handled as follows: First, the data in tx.Data is deserialized into a Member structure to obtain detailed operation information. The database type plus identifier and table name + column name from the Member structure are stored as key-value pairs in database db1. The table name + column name and tx.Data are stored as key-value pairs in database db2 to store the actual data content. The operation type is recorded in database db3, i.e., the table name + column name and operation type are stored as key-value pairs. If the key (table name + column name) already exists in database db2, it indicates that a data update is required. The on-chain data storage module then stores the data and operation type in databases db2 and db3 respectively, this time with the operation type being "UPDATE". The operation event is recorded, including the creator and other relevant attributes, for subsequent data tracking and auditing. Finally, a successful operation response is returned, including operation event information, indicating that the data has been successfully processed and recorded on the chain.

6. A blockchain multimodal data management system based on the Gin framework as described in claim 1, characterized in that, The on-chain data retrieval module uses the following specific data retrieval method: First, clarify the data type of the target query; for the information the user wants to query, perform the following steps: Step 1: First, use "[data type]:[identifier]" as the key to query the first key-value database; then use the value returned by the first key-value database as the key to query the second and third key-value databases to find the specific location of the data operation and the value of the data being operated on. Step 2: In the second key-value database, use the specific location key obtained from the first step to query the corresponding specific operation data value (Data); Step 3: In the third key-value database, using the specific location key, query the operation type of the data to understand how the data is processed; Step 4: Combine the query results obtained in Step 2 and Step 3 to obtain complete data information, including data content and data operation type; for cases that reference off-chain storage, query the corresponding off-chain storage system based on the reference in on-chain storage to obtain the actual data content.

Images