A method and system for on-chain data storage of double-ended interactions

Abstract

The application provides a kind of double-end interactive on-chain data storage method and system, comprising responding to the on-chain storage request initiated by user through system interface, obtaining the certificate issued by alliance organization and distributing private key;Certificate and private key are verified, and the user is confirmed to have the right to operate alliance chain after verification;According to the on-chain mode selected by user, through server on-chain mode or client on-chain mode, the data to be stored to alliance chain is stored.The application realizes strict permission control and data privacy protection through alliance chain, meets different scene needs through double-end on-chain mode, avoids user waiting through asynchronous on-chain and on-chain log, improves business processing efficiency and controllability of data on-chain.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and data storage technology, specifically to a dual-terminal interactive on-chain data storage method and system, which is particularly suitable for on-chain data storage in blockchain product traceability scenarios. Background Technology

[0002] Blockchain technology, with its decentralized, immutable, and traceable characteristics, has been widely applied in areas such as product traceability, supply chain management, and food safety. In a blockchain-based product traceability system, data such as product information, invoice information, order information, and transaction information need to be stored on the blockchain to achieve trusted data storage and full-process traceability.

[0003] However, existing blockchain data storage solutions have the following shortcomings: First, the on-chain process is opaque to users: In existing traceability systems, the on-chain storage of data is a complete black box for users. After initiating an on-chain request, users cannot intuitively confirm whether the data content to be stored on the blockchain is correct, nor can they verify or check the data before storage. This black-box operation mode reduces users' sense of control and trust in the on-chain data.

[0004] Second, public blockchain storage cannot meet the requirement for selective data transparency: data on a public blockchain is public to all nodes, and any user can view all data stored on the chain. However, in real-world product traceability scenarios, different participants (such as suppliers, logistics providers, retailers, and consumers) have different data visibility needs. Some data (such as product circulation details) may only be publicly available within the consortium members, while remaining confidential to other organizations or users without authorization. The fully public model of public blockchains cannot meet these differentiated privacy protection needs.

[0005] Third, the lag and latency of on-chain data storage affect user experience: Writing data to a blockchain requires multiple steps, including transaction construction, endorsement, sorting, consensus, and block creation, which takes a considerable amount of time. In the synchronous on-chain mode, users must wait for the storage result to be returned on the chain before they can perform subsequent operations. This long wait severely impacts the continuity of business processing and user experience.

[0006] To address the aforementioned issues, some existing technologies attempt to alleviate user waiting problems by introducing on-chain logs or caching mechanisms. However, these solutions still have shortcomings in ensuring log reliability and data consistency, and fail to address users' needs for data visibility control and data confirmation before being uploaded to the blockchain.

[0007] Furthermore, in consortium blockchain scenarios, existing technologies have not provided satisfactory solutions to problems such as how to achieve fine-grained access control, how to ensure the consistency of state order of multi-state data in asynchronous on-chain scenarios, and how to efficiently perform on-chain state tracking under massive on-chain requests. Summary of the Invention

[0008] To address the problems existing in the prior art, the present invention aims to provide a method and system for on-chain data storage with dual-end interaction. The technical problems to be solved by the present invention include: How can the on-chain process be made visible and controllable to users, so that users can confirm the data before it is uploaded to the blockchain? How to achieve strict access control in a consortium blockchain environment to meet users' needs for selective and transparent data; How to avoid user waiting and improve business processing efficiency through asynchronous blockchain uploading, while ensuring data consistency and traceability in asynchronous blockchain scenarios; How to support consistency verification of the state order of multi-state data in asynchronous on-chain scenarios; How to efficiently track the on-chain state and update the logs for massive asynchronous on-chain requests.

[0009] The present invention achieves the above objectives through the following technical solutions: A method for on-chain data storage with dual-end interaction, comprising: In response to on-chain storage requests initiated by users through the system interface, obtain certificates issued by the consortium and allocate private keys; The certificate and private key are verified, and once the verification is successful, the user is confirmed to have the authority to operate the consortium blockchain. Depending on the user's chosen method of on-chain storage, the data to be stored on the blockchain is stored in the consortium blockchain via either server-side or client-side on-chain storage. Among them, the server-side on-chain method adopts synchronous on-chain. After the server assembles the initial data into on-chain data, it calls the chaincode service to store the data on the chain and directly returns the on-chain result to the on-chain user. The client-side on-chain method adopts asynchronous on-chain. The server assembles the initial data into on-chain data and displays it on the system interface. After user confirmation, the on-chain operation is recorded in the on-chain log and marked as pending on-chain status. The system interface quickly responds with a success message, and then asynchronously calls the client-side on-chain service to execute the actual on-chain operation.

[0010] According to the on-chain data storage method for dual-end interaction provided by the present invention, when verifying the certificate and private key, the X.509 certificate and private key issued by the consortium organization submitted by the user are obtained; The X.509 certificate is validated. The validation includes: verifying whether the X.509 certificate has a verifiable certificate path from the consortium root certificate or intermediate certificate to the X.509 certificate; and verifying whether the X.509 certificate is on the certificate revocation list. After the certificate validity verification is successful, the user's digital signature is verified using the private key to confirm that the user is the legitimate holder of the X.509 certificate; After the signature verification is successful, the user is mapped to the corresponding alliance organization and the role under that alliance organization based on the organization unit field in the X.509 certificate; Based on the alliance organization and role obtained from the mapping, obtain the operation permission information corresponding to the user, and determine whether the user has the operation permission to initiate the current on-chain storage request; When certificate validity verification, signature verification, and operation permission judgment all pass, the user is confirmed to have the permission to operate the consortium blockchain.

[0011] According to a dual-end interactive on-chain data storage method provided by the present invention, the server assembles initialization data into on-chain data, including: The server receives initialization data, which includes at least one business identifier field and data type. Based on the type of data to be uploaded to the chain, the target data structure definition that matches the initial data is queried from the data structure mapping table pre-stored on the server. The data structure mapping table records the correspondence between different data types and the data structures defined in the chaincode. Based on the target data structure definition obtained from the query, each field in the initial data is mapped to the corresponding field in the data structure required by the chaincode, generating on-chain data that conforms to the on-chain format; Based on the data type, the target chaincode identifier and target chaincode method corresponding to the data type are queried from the chaincode mapping table pre-stored on the server. The chaincode mapping table records the correspondence between different data types and the chaincode and chaincode methods deployed on the consortium blockchain. Based on the target chaincode identifier and target chaincode method found in the query, construct a chaincode invocation request. The chaincode invocation request carries the on-chain data and the method parameters required by the target chaincode method. Send the chaincode invocation request to the endorsing node of the consortium blockchain to request that the on-chain data be stored in the consortium blockchain according to the target chaincode method.

[0012] According to the on-chain data storage method with dual-end interaction provided by the present invention, in the client-side on-chain mode, the server returns the assembled on-chain data and its corresponding data hash value to the system interface for display. The data hash value is used by the user to verify whether the on-chain data has been tampered with during transmission. In response to the user's data confirmation operation on the system interface, the system interface obtains the organization information in the current user's certificate, and queries the channel configuration of the consortium blockchain based on the organization information to find one or more available channels that the user can access, as well as one or more available contracts that the user has the right to call under each available channel. The system interface displays one or more available channels and their corresponding available contracts in a visual list for users to select from. Receive the target channel identifier selected by the user from the available channels and the target contract identifier selected from the available contracts; Based on the organization unit and role fields in the user's certificate, and in conjunction with the access control list of the target channel, verify whether the user has the permission to invoke the target contract on the target channel; Once the user has permission to invoke the target contract, the system verifies whether the target contract has deployed a target chaincode method corresponding to the data type, based on the data type to be uploaded to the chain. After the target contract is successfully matched and verified, the system receives the final confirmation instruction from the user. The final confirmation instruction carries the signature data generated by the user digitally signing the hash value of the on-chain data using their private key. The server uses the user's certificate to verify the signature data. Once the verification is successful, it confirms that the data uploaded to the blockchain has not been tampered with after the user's confirmation, and records the blockchain upload operation in the blockchain log.

[0013] According to the on-chain data storage method for dual-end interaction provided by the present invention, before recording the on-chain operation in the on-chain log, it further includes performing pre-on-chain verification on the on-chain data: Extract the unique business identifier and current status identifier from the initialization data; Based on the unique business identifier, query the on-chain logs to see if there is a set of historical log records corresponding to the unique business identifier. If the historical log record set is empty, the current on-chain operation is determined to be the first on-chain operation of the data corresponding to the unique business identifier. The on-chain pre-verification is passed, and it is allowed to write the current on-chain operation to the on-chain log. If the historical log record set is not empty, the corresponding predefined state transition path is obtained according to the data type of the initialization data. The state transition path is a directed acyclic graph structure, which is used to define the legal transition order between states under the same business unique identifier. Based on the current state identifier and the state transition path, determine the set of predecessor states of the current state.

[0014] According to a dual-end interactive on-chain data storage method provided by the present invention, a query is performed in the historical log record set to check whether there is a predecessor log record corresponding to any predecessor state in the predecessor state set; If there is no predecessor log record corresponding to any predecessor state in the predecessor state set, it is determined that the predecessor state data of the current on-chain operation has not yet initiated an on-chain request, the current on-chain request is rejected and an error message is returned. If there is a predecessor log record corresponding to any predecessor state in the predecessor state set, then read the on-chain state field in the predecessor log record and determine whether the data corresponding to the predecessor state has been marked as on-chain. If the data corresponding to the predecessor state is not marked as being on the chain, the current on-chain request is rejected and a failure message containing information that the predecessor state is not on the chain is returned. If the data corresponding to the predecessor state has been marked as being on the chain, then acquire a distributed lock with the business unique identifier as the key name; After successfully acquiring the distributed lock, query the predecessor log in the on-chain log again to see the current on-chain status. If the current on-chain status has changed and is no longer on-chain, release the distributed lock and reject the current on-chain request. If the current on-chain status is still on-chain, write the current on-chain operation to the on-chain log, mark it as pending on-chain status, and release the distributed lock after successful writing.

[0015] According to the on-chain data storage method for dual-end interaction provided by the present invention, after asynchronously calling the client's on-chain service to perform the actual on-chain operation, it further includes: The server periodically scans the consortium blockchain and updates the on-chain logs based on the scan results. For data that has already been stored on the consortium blockchain, the corresponding record in the on-chain log will be marked as having been on-chain. For data that has not been stored on the consortium blockchain, the corresponding record in the on-chain log will be kept in a pending on-chain state so that users can manually re-initiate the on-chain process through the log interface.

[0016] According to the on-chain data storage method with dual-end interaction provided by the present invention, in the client-side on-chain mode, when the data to be on-chain is state change data with multiple states, the on-chain operation of the current state needs to be executed after the on-chain operation of the previous state is completed. Specifically, obtain the unique business identifier and current status identifier corresponding to the data to be uploaded to the blockchain; Based on the unique business identifier and the current state identifier, the set of predecessor states of the current state is queried from the predefined state dependency graph model. The state dependency graph model is a directed acyclic graph structure, which is used to define the sequential dependency relationship between states under the same unique business identifier. Each state is a node, and the directed edges between states represent the execution order dependency of the on-chain operations. If the predecessor state set is empty, the current state is determined to be the initial state, and the current on-chain request is allowed to continue. If the predecessor state set is not empty, then acquire the distributed lock with the business unique identifier as the key name.

[0017] According to the on-chain data storage method for two-way interaction provided by the present invention, after successfully acquiring the distributed lock, the following serialized verification steps are performed: Query all historical log records corresponding to the unique business identifier from the on-chain logs; For each predecessor state in the predecessor state set, query the historical log records to see if there is a predecessor log record corresponding to the predecessor state. If any predecessor state in the predecessor state set has no corresponding predecessor log record in the historical log record, it is determined that the predecessor state has not yet initiated the on-chain process, the distributed lock is released, and the current on-chain request failure and missing state information are returned. If each predecessor state in the predecessor state set has a corresponding predecessor log record, then the on-chain state field in each predecessor log record is further read to confirm whether each predecessor state has been marked as on-chain. If any predecessor state in the predecessor state set is not marked as being on the chain, the distributed lock is released, and a failure message containing the information of the incomplete predecessor state is returned. If each predecessor state in the predecessor state set has been marked as being on the chain, then write the log record corresponding to the current state into the on-chain log, mark it as a state to be on the chain, and release the distributed lock after successful writing. In the case where the set of predecessor states contains multiple predecessor states, there is a parallel dependency relationship between the multiple predecessor states. That is, the current state's on-chain operation can only be allowed to be executed after all the predecessor states have been on-chained.

[0018] A dual-end interactive on-chain data storage system, comprising: Consortium blockchains are used to store on-chain data; The server is used to receive users' on-chain requests, verify users' certificates and private keys, assemble initial data into on-chain data, and provide on-chain service interfaces for both the server and client. The client communicates with the server and is used to perform asynchronous on-chain operations; The on-chain log module is used to record on-chain operations and on-chain status under the client's on-chain mode; The system is configured to execute the methods described above.

[0019] Therefore, compared with the prior art, the on-chain data storage method and system with dual-end interaction proposed in this invention has the following beneficial effects: 1. This invention provides a dual-end on-chain mode for users, including client-side and server-side on-chain storage. This on-chain storage process requires user confirmation; users store the data only after verifying its accuracy. To avoid user waiting issues during on-chain storage, this invention provides an asynchronous on-chain method and an on-chain log management module. User on-chain requests are queued in the log for processing, allowing users to complete other operations during this period and then view the on-chain processing results through the log.

[0020] 2. In the client-side on-chain method of this invention, the server returns the assembled on-chain data and its hash value to the system interface for display. Users can confirm and verify the data before it is uploaded to the blockchain. After confirming the data to be uploaded, the user must also digitally sign the data hash using their private key. Only after the server verifies the signature can it be written to the log. This invention constructs a complete secure chain of generation-display-confirmation-submission, ensuring that the data confirmed by the user is strictly consistent with the actual data uploaded to the blockchain, thus solving the pain point of users' black-box operation of on-chain data in existing technologies.

[0021] 3. This invention uses a consortium blockchain for data storage and implements multi-level progressive authentication through X.509 certificates and private keys. The four-layer authentication architecture—certificate validity verification, signature verification, organization role mapping based on OU fields, and operation permission judgment—is organically linked. Only users with the corresponding certificate and private key can operate the consortium blockchain through chaincode, ensuring selective and transparent data access. Users can view data within a certain scope according to their permissions, while unauthorized organizations or users cannot access it.

[0022] 4. This invention provides an asynchronous on-chain method for clients. After a user initiates an on-chain request, the on-chain operation is first recorded in the on-chain log and a success message is quickly returned. The user can then continue with other operations without waiting for on-chain consensus to complete. The on-chain result can be queried through the on-chain log, transforming the user's blocking wait into an asynchronous query, significantly improving business processing efficiency.

[0023] 5. This invention achieves dynamic querying and field mapping of data structures through a data structure mapping table and a chaincode mapping table. When adding a new data type, only the mapping table configuration needs to be updated, without modifying the business code, significantly improving the system's scalability and maintainability. Simultaneously, the chaincode mapping table enables automatic routing to the corresponding chaincode and chaincode method based on the data type, decoupling the on-chain request from the specific chaincode implementation.

[0024] 6. This invention abstracts the dependencies between states of state-changing data into a directed acyclic graph model, supporting the existence of multiple predecessor states for the same data entity and cross-level state dependency verification. Through serialized verification protected by distributed locks and recursive multi-level dependency chain verification, it effectively prevents the problem of state order disorder caused by concurrency in asynchronous on-chain scenarios, and ensures the consistency of state order of multi-state data in asynchronous on-chain scenarios.

[0025] 7. This invention employs a distributed scan lock to ensure that only one scan task instance executes at any given time; it adaptively adjusts the number of scans per batch through a dynamic batching mechanism, achieving a dynamic balance between scan real-time performance and system load; and it combines a unique business identifier and data hash value for dual verification, effectively capturing abnormal scenarios such as on-chain data tampering or inconsistent data formats. For records that have been in a pending on-chain state for a long time, automatic marking and proactive acceleration of retries are achieved through a failure accumulation and dynamic priority promotion mechanism.

[0026] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0027] Figure 1 This is a flowchart of an embodiment of a dual-end interactive on-chain data storage method according to the present invention.

[0028] Figure 2 This is a flowchart illustrating the on-chain data storage process in an embodiment of a dual-end interactive on-chain data storage method of the present invention.

[0029] Figure 3 This is a schematic diagram of the dual-end on-chain data storage method based on a blockchain product traceability system, as described in an embodiment of the present invention.

[0030] Figure 4 This is a schematic diagram illustrating asynchronous on-chain storage processing on the client side in an embodiment of a dual-end interactive on-chain data storage method of the present invention.

[0031] Figure 5 This is a schematic diagram illustrating the architecture of an embodiment of a dual-end interactive on-chain data storage system according to the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0033] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0034] An embodiment of an on-chain data storage method with dual-end interaction See Figures 1 to 4 This embodiment provides an on-chain data storage method for dual-end interaction, including: Step S1: In response to the on-chain storage request initiated by the user through the system interface, obtain the certificate issued by the consortium and allocate the private key; Step S2: Verify the certificate and private key. Once the verification is successful, confirm that the user has the authority to operate the consortium blockchain. Step S3: Based on the on-chain method selected by the user, store the data to be on-chain to the consortium blockchain through either the server-side on-chain method or the client-side on-chain method, i.e., execute step S4 or step S5. Among them, the server-side on-chain method adopts synchronous on-chain. After the server assembles the initial data into on-chain data, it calls the chaincode service to store the data on the chain and directly returns the on-chain result to the on-chain user. The client-side on-chain method adopts asynchronous on-chain. The server assembles the initial data into on-chain data and displays it on the system interface. After user confirmation, the on-chain operation is recorded in the on-chain log and marked as pending on-chain status. The system interface quickly responds with a success message, and then asynchronously calls the client-side on-chain service to execute the actual on-chain operation.

[0035] In step S2 above, when verifying the certificate and private key, the X.509 certificate and private key issued by the consortium organization and submitted by the user are obtained. The X.509 certificate is validated. The validation includes: verifying whether the X.509 certificate has a verifiable certificate path from the consortium root certificate or intermediate certificate to the X.509 certificate; and verifying whether the X.509 certificate is on the certificate revocation list. After the certificate validity verification is successful, the user's digital signature is verified using the private key to confirm that the user is the legitimate holder of the X.509 certificate; After the signature verification is successful, the user is mapped to the corresponding alliance organization and the role under that alliance organization based on the organization unit field in the X.509 certificate; Based on the alliance organization and role obtained from the mapping, obtain the operation permission information corresponding to the user, and determine whether the user has the operation permission to initiate the current on-chain storage request; When certificate validity verification, signature verification, and operation permission judgment all pass, the user is confirmed to have the permission to operate the consortium blockchain.

[0036] In the server-side on-chain method, the server assembles the initial data into on-chain data, including: The server receives initialization data, which includes at least one business identifier field and data type. Based on the type of data to be uploaded to the chain, the target data structure definition that matches the initial data is queried from the data structure mapping table pre-stored on the server. The data structure mapping table records the correspondence between different data types and the data structures defined in the chaincode. Based on the target data structure definition obtained from the query, each field in the initial data is mapped to the corresponding field in the data structure required by the chaincode, generating on-chain data that conforms to the on-chain format; Based on the data type, the target chaincode identifier and target chaincode method corresponding to the data type are queried from the chaincode mapping table pre-stored on the server. The chaincode mapping table records the correspondence between different data types and the chaincode and chaincode methods deployed on the consortium blockchain. Based on the target chaincode identifier and target chaincode method found in the query, construct a chaincode invocation request. The chaincode invocation request carries the on-chain data and the method parameters required by the target chaincode method. Send the chaincode invocation request to the endorsing node of the consortium blockchain to request that the on-chain data be stored in the consortium blockchain according to the target chaincode method.

[0037] In the client-side on-chain method, after confirming the data to be uploaded to the blockchain, the user selects the corresponding on-chain channel and contract, and confirms that the data will be uploaded to the blockchain.

[0038] Specifically, the server returns the assembled on-chain data and its corresponding data hash value to the system interface for display. The data hash value is used by the user to verify whether the on-chain data has been tampered with during transmission. In response to the user's data confirmation operation on the system interface, the system interface obtains the organization information in the current user's certificate, and queries the channel configuration of the consortium blockchain based on the organization information to find one or more available channels that the user can access, as well as one or more available contracts that the user has the right to call under each available channel. The system interface displays one or more available channels and their corresponding available contracts in a visual list for users to select from. Receive the target channel identifier selected by the user from the available channels and the target contract identifier selected from the available contracts; Based on the organization unit and role fields in the user's certificate, and in conjunction with the access control list of the target channel, verify whether the user has the permission to invoke the target contract on the target channel; Once the user has permission to invoke the target contract, the system verifies whether the target contract has deployed a target chaincode method corresponding to the data type, based on the data type to be uploaded to the chain. After the target contract is successfully matched and verified, the system receives the final confirmation instruction from the user. The final confirmation instruction carries the signature data generated by the user digitally signing the hash value of the on-chain data using their private key. The server uses the user's certificate to verify the signature data. Once the verification is successful, it confirms that the data uploaded to the blockchain has not been tampered with after the user's confirmation, and records the blockchain upload operation in the blockchain log. In this embodiment, before recording the on-chain operation in the on-chain log, it also includes performing pre-on-chain verification on the on-chain data to confirm that there is no previous state record in the on-chain log that has not yet been completed under the same initialization data.

[0039] The on-chain pre-verification includes: Extract the unique business identifier and current status identifier from the initialization data; Based on the unique business identifier, query the on-chain logs to see if there is a set of historical log records corresponding to the unique business identifier. If the historical log record set is empty, the current on-chain operation is determined to be the first on-chain operation of the data corresponding to the unique business identifier. The on-chain pre-verification is passed, and it is allowed to write the current on-chain operation to the on-chain log. If the historical log record set is not empty, the corresponding predefined state transition path is obtained according to the data type of the initialization data. The state transition path is a directed acyclic graph structure, which is used to define the legal transition order between states under the same business unique identifier. Based on the current state identifier and the state transition path, determine the set of predecessor states of the current state; Search the historical log record set to see if there is a predecessor log record corresponding to any predecessor state in the predecessor state set; If there is no predecessor log record corresponding to any predecessor state in the predecessor state set, it is determined that the predecessor state data of the current on-chain operation has not yet initiated an on-chain request, the current on-chain request is rejected and an error message is returned. If there is a predecessor log record corresponding to any predecessor state in the predecessor state set, then read the on-chain state field in the predecessor log record and determine whether the data corresponding to the predecessor state has been marked as on-chain. If the data corresponding to the predecessor state is not marked as being on the chain, the current on-chain request is rejected and a failure message containing information that the predecessor state is not on the chain is returned. If the data corresponding to the predecessor state has been marked as being on the chain, then acquire a distributed lock with the business unique identifier as the key name; After successfully acquiring the distributed lock, query the predecessor log in the on-chain log again to see the current on-chain status. If the current on-chain status has changed and is no longer on-chain, release the distributed lock and reject the current on-chain request. If the current on-chain status is still on-chain, write the current on-chain operation to the on-chain log, mark it as pending on-chain status, and release the distributed lock after successful writing.

[0040] In this embodiment, after asynchronously calling the client's on-chain service to perform the actual on-chain operation, the process further includes: The server periodically scans the consortium blockchain and updates the on-chain logs based on the scan results. For data that has already been stored on the consortium blockchain, the corresponding record in the on-chain log will be marked as having been on-chain. For data that has not been stored on the consortium blockchain, the corresponding record in the on-chain log will be kept in a pending on-chain state so that users can manually re-initiate the on-chain process through the log interface. Specifically, the timed scanning and on-chain log update process in this embodiment includes: S31. The server triggers a scanning task at a preset scanning cycle. When the scanning task starts, it acquires a system-level distributed scanning lock to ensure that only one scanning task instance is executing at any given time. S32. Obtain all log records marked as pending on-chain status in the current on-chain log, generate a list of records to be scanned, and sort the list of records to be scanned according to the on-chain request timestamp of the pending on-chain data in the records. S33. Based on the number of records in the list of records to be scanned, dynamically determine the target scanning quantity N of the current scanning batch, and divide the list of records to be scanned into batches according to the target scanning quantity N to generate at least one scanning batch. S34. For each log record to be scanned in the current scan batch, perform the following on-chain evidence verification sub-step: S341. Read the unique business identifier and target chaincode identifier corresponding to the data to be uploaded to the chain from the log records to be scanned; S342. Based on the unique business identifier and the target chaincode identifier, construct a certificate of evidence query request for the consortium chain. The certificate of evidence query request includes the unique business identifier and the data hash value of the data to be uploaded to the chain. S343. Send the evidence storage query request to the endorsement node of the consortium blockchain and obtain the query result returned by the consortium blockchain. The query result includes the actual storage status and actual storage hash value of the data to be uploaded to the blockchain. S344. Perform a consistency comparison between the actual storage hash value in the query results and the data hash value stored in the log record to be scanned, and comprehensively determine the verification result of this scan based on the actual storage status and the consistency comparison result: if the actual storage status is "stored" and the consistency comparison passes, the verification is deemed successful; if the actual storage status is "stored" but the consistency comparison fails, the data is deemed abnormal; if the actual storage status is "not stored", the verification is deemed unsuccessful. S35. Update the status of the log record to be scanned according to the verification results: If the verification is successful, update the on-chain status of the log record to be scanned from pending on-chain to already on-chain, and record the on-chain confirmation time and block height; if the data is abnormal, mark the log record to be scanned as abnormal and trigger an alarm; if the verification fails, keep the log record to be scanned in the pending on-chain status and accumulate the number of failed scans of the log record to be scanned. S36. For log records to be scanned that fail verification within a consecutive preset number of scans and whose number of scan failures exceeds a preset threshold, change their on-chain status from pending on-chain to pending retry status, and increase the scanning priority of the log records to be scanned. S37. After verifying and updating the status of all log records to be scanned in the current scan batch, determine whether there are any unscanned records in the list of records to be scanned. If so, repeat steps S34 to S36 for the next scan batch until all records to be scanned have been scanned. S38. Release the system-level distributed scan lock and wait for the next scan cycle to be triggered.

[0041] In this embodiment, the user manually re-initiates the on-chain process through the log interface, including: Users can select log records marked as pending on-chain status in the on-chain log interface; The corresponding data of the log record is re-requested to be stored on the chain in a synchronous manner.

[0042] In the client-side on-chain method, when the data to be on-chain is state change data with multiple states, the on-chain operation for the current state must be executed after the on-chain operation for the previous state is completed. If the on-chain log record of the previous state has not yet been marked as on-chain, the on-chain request of the current state is rejected and a failure message is returned.

[0043] Specifically, obtain the unique business identifier and current status identifier corresponding to the data to be uploaded to the blockchain; Based on the unique business identifier and the current state identifier, the set of predecessor states of the current state is queried from the predefined state dependency graph model. The state dependency graph model is a directed acyclic graph structure, which is used to define the sequential dependency relationship between states under the same unique business identifier. Each state is a node, and the directed edges between states represent the execution order dependency of the on-chain operations. If the predecessor state set is empty, the current state is determined to be the initial state, and the current on-chain request is allowed to continue. If the predecessor state set is not empty, then acquire the distributed lock with the business unique identifier as the key name; After successfully acquiring the distributed lock, perform the following serialized verification steps: Query all historical log records corresponding to the unique business identifier from the on-chain logs; For each predecessor state in the predecessor state set, query the historical log records to see if there is a predecessor log record corresponding to the predecessor state. If any predecessor state in the predecessor state set has no corresponding predecessor log record in the historical log record, it is determined that the predecessor state has not yet initiated the on-chain process, the distributed lock is released, and the current on-chain request failure and missing state information are returned. If each predecessor state in the predecessor state set has a corresponding predecessor log record, then the on-chain state field in each predecessor log record is further read to confirm whether each predecessor state has been marked as on-chain. If any predecessor state in the predecessor state set is not marked as being on the chain, the distributed lock is released, and the current on-chain request fails and a failure message containing the information of the incomplete predecessor state is returned. The failure message also includes the log location information of the incomplete predecessor state in the on-chain log, so that the user can locate it through the on-chain log interface and manually re-initiate the on-chain operation of the corresponding predecessor state. If each predecessor state in the predecessor state set has been marked as being on the chain, then write the log record corresponding to the current state into the on-chain log, mark it as a state to be on the chain, and release the distributed lock after successful writing. In the case where the set of predecessor states contains multiple predecessor states, there is a parallel dependency relationship between the multiple predecessor states. That is, the current state's on-chain operation can only be allowed to be executed after all the predecessor states have been on-chained. In cases where the current state has multiple levels of predecessor dependencies, the predecessor states of each predecessor state in the predecessor state set are recursively queried through the state dependency graph model. Dependency verification is completed layer by layer until the predecessor state set is empty or every predecessor state at all dependency levels is confirmed to have been marked as being on the chain.

[0044] In this embodiment, the status change data includes product data and order data. The status of product data includes "listed" and "unlisted". The status of order data includes at least two of the following: "not delivered", "in transit", "delivered", and "signed for".

[0045] The on-chain operations recorded in the on-chain log include the initial data identifier of the data to be on-chain, the content of the on-chain data, the on-chain time, the on-chain status, and the corresponding chaincode information.

[0046] In practical applications, Figure 2 This describes the internal processing flow when a user requests to store data on the blockchain. When requesting to store data on the blockchain, the user needs to submit a certificate issued by the consortium organization and a private key to the blockchain-uploading end (server or client). After verifying the certificate and private key, user authentication is successful; if successful, the user has the necessary permissions; otherwise, the operation is rejected. Upon receiving the request, the blockchain-uploading end stores the data on the blockchain using chaincode. Chaincode is the interface between the blockchain and external business operations. Operations on the blockchain are achieved by calling chaincode services. The chaincode itself is also stored on the blockchain and provides various methods. These methods need to be customized according to business requirements before being deployed on the blockchain. For example, when a user registers a product, the product registration chaincode is called to store the product data on the blockchain. In this case, the chaincode defines a series of product-related data structures. External data must install these data structures to assemble the data before it can be stored on the blockchain, ultimately existing as key-value pairs. The writing of the chaincode and the definition of the data structures must be completed according to business requirements.

[0047] The dual-end on-chain method is embedded into the blockchain product traceability system. The specific processing flow of dual-end on-chain is as follows: Figure 3 As shown.

[0048] (1) Server-side data uploading This embodiment provides a server-side on-chain method. When the system interface requests the server to upload data to the chain, the server receives the initial data (such as product information, order information, order information, transaction information, etc.), assembles the data into the format and content required for on-chain, requests the on-chain interface (chaincode), and uploads the data that can be uploaded to the chain (when uploading data to the chain, the corresponding default chaincode is used for different types of on-chain data, such as product data, order data, etc.).

[0049] The server-side on-chain process uses a synchronous on-chain method, which requires a certain amount of time before the data can be uploaded to the chain. Success or failure of the on-chain upload will be returned directly and a notification will be sent to the user.

[0050] (2) Client data uplink This embodiment provides a client-side blockchain uploading method. When the system interface requests the client to upload the blockchain data, the server assembles the data and displays it on the system interface. After the user confirms the accuracy of the data and selects the corresponding chaincode, they directly access the service interface of the blockchain client to perform the blockchain uploading operation. This uploading operation is recorded in the blockchain log, and the user can query the uploading result in the log. For data that fails to upload, the user can re-request the client to upload the data.

[0051] The client-side blockchain upload process uses an asynchronous approach. The blockchain upload operation is first recorded in the blockchain upload log and quickly responded to the system interface, which uniformly indicates that the operation was successful. Then, the client-side blockchain upload service is requested asynchronously, and the blockchain upload result needs to be viewed in the blockchain upload log.

[0052] In this embodiment, the server-side on-chain process is synchronous. After assembling the data, the server requests the on-chain connection interface provided by the client. The client-side on-chain process is asynchronous. After the server assembles the data, the user needs to select the chaincode to be on-chain and write the on-chain operation to the on-chain log. With the former, the user needs to wait for the on-chain process to complete before performing other operations, and can directly obtain the on-chain result (success / failure). With the latter, there is no waiting, but the user needs to view the data on-chain result in the on-chain log and can manually handle on-chain failure logs (re-on-chain). The client-side on-chain process is more complex, and the specific process is as follows: Figure 4 The following is an explanation of the implementation process based on a product traceability platform: Users request to upload data to the blockchain through the system interface (requesting products, invoices, orders, or transactions). The server processes the initial data (product details, invoices, orders, and transactions), assembling it into on-chain data according to the required format (product details, invoices, orders, and transactions). The assembled data is then returned to the system interface. Users confirm the on-chain data and select the corresponding on-chain channel and contract to confirm the data upload. Upon receiving the request, the server first adds it to the on-chain log. During this process, the on-chain data is verified to ensure that no unuploaded content based on the initial data exists in the log.

[0053] Initialization data, such as product details and order data, exists in multiple states, and each state change requires on-chain recording. For example, after a product is listed, it needs to be on-chain; after a product is delisted, it needs to be on-chain again. Orders have multiple states, such as not delivered, in transit, delivered, and signed for; each order state change requires a separate on-chain recording operation. Because the client uses asynchronous on-chain recording, when recording data for the next state (product, order, etc.) on-chain, it must be ensured that the previous state for the same data has been recorded on-chain. For example, when a product is delisted, an on-chain request is required, but it must be ensured that the on-chain recording operation for the product's listing has been completed. Only after the data has been recorded on-chain will the delisting request return a success return. When an order changes from not delivered to in transit, the in transit order data needs to be on-chain. At this time, it will first enter the on-chain log, which will scan whether the previous state of the order has been recorded on-chain. If it has, the current request is allowed to continue; otherwise, it will return a failure, prompting that the data in the previous state that was not recorded on-chain needs to be re-recorded on-chain in the on-chain log interface.

[0054] After the log update is successful, the initial data state will be modified (for example, the on-chain status of the listed products will be changed from not on-chain to on-chain), and then the client will be asynchronously requested to perform the on-chain operation.

[0055] Because asynchronous execution involves a time lag, the server periodically scans the blockchain to update the blockchain log. Data that has actually been added to the blockchain is marked as "on-chain" in the log, while data that has not been added (failed to be added) is marked as "pending addition," waiting for the user to manually click to add the data to the blockchain again. To better understand this process, let's take order on-chaining as an example: A supplier creates an order A containing product a and product b, described below as A(a, b, not delivered). After successful creation, order A is in an undelivered state and not yet on the blockchain. Now, the supplier clicks "OnChain 2" (client-side on-chain method). The system interface transmits some basic information related to A(a, b, not delivered) (such as the order's sender, shipping address, recipient, and product traceability code, SN code, etc.) to the server. After receiving the data, the server assembles it into on-chain data according to the number of orders to be on-chain, described below as onChainA(a, b, not delivered). This is then returned to the system interface. The supplier confirms the order's on-chain data, selects the on-chain channel and contract, and transmits it to the server. After receiving the data, the server stores onChainA(a, b, not delivered) in the on-chain log and marks it as pending on-chain in the log. After successful storage in the log, the server changes the on-chain status of order A in the database from not on-chain to on-chain. Finally, the system interface simultaneously requests the blockchain client to perform the actual asynchronous blockchain upload operation for order A. During the asynchronous blockchain upload, the server updates the logs periodically (a timed update operation set by the server, for example, automatically executed once every 20 seconds). By scanning the blockchain, it confirms whether order A in the logs has indeed been uploaded to the blockchain. If it has, it marks order A as uploaded to the blockchain in the logs.

[0056] Then, the logistics provider receives the undelivered order A, assigns it a delivery agency, delivery person, transit address, and other information. After confirmation, the status of order A in the database changes from undelivered to in transit. At this point, A(a, b, in transit) needs to be added to the blockchain, which is also assembled into blockchain data and transmitted to the server after confirmation. After receiving the data, the server first adds it to the log. However, there are restrictions on adding it to the log. The previous state of order A stored in the log, onChainA(a, b, undelivered), must have been marked as blockchain-added. If there is a log entry for order A marked as unblocked, the operation will fail. If all entries are marked as blockchain-added, the process of adding to the log, modifying the database blockchain status, and asynchronously adding the data to the blockchain can continue.

[0057] For log data that is still marked as not on the chain after scanning the chain, users can manually add it to the chain in the log interface. This chain-adding process is synchronous and may require waiting.

[0058] An embodiment of a dual-end interactive on-chain data storage system like Figure 5 As shown in the figure, this embodiment provides a dual-end interactive on-chain data storage system, including: Consortium blockchains are used to store on-chain data; The server is used to receive users' on-chain requests, verify users' certificates and private keys, assemble initial data into on-chain data, and provide on-chain service interfaces for both the server and client. The client communicates with the server and is used to perform asynchronous on-chain operations; The on-chain log module is used to record on-chain operations and on-chain status under the client's on-chain mode; The system is configured to perform the method as claimed in any one of claims 1 to 9.

[0059] The server includes: The data assembly module is used to assemble the initial data into on-chain data that matches the chaincode data structure, based on the type of data to be uploaded to the chain. The chaincode invocation module is used to invoke the chaincode service deployed on the consortium blockchain to perform data storage operations; The authorization verification module is used to verify the validity of user certificates and private keys; The log management module is used to manage the writing, updating, and querying of on-chain logs.

[0060] The on-chain log module records the on-chain status, including the pending on-chain status and the already on-chain status. The system also includes a timed scanning module, which is used to periodically scan the consortium blockchain and update the on-chain status in the on-chain log module.

[0061] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0062] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for on-chain data storage with dual-end interaction, characterized in that, include: In response to on-chain storage requests initiated by users through the system interface, obtain certificates issued by the consortium and allocate private keys; The certificate and private key are verified, and once the verification is successful, it is confirmed that the user has the authority to operate the consortium blockchain. Depending on the user's chosen method of on-chain storage, the data to be stored on the blockchain is stored in the consortium blockchain via either server-side or client-side on-chain storage. Among them, the server-side on-chain method adopts synchronous on-chain. After the server assembles the initial data into on-chain data, it calls the chaincode service to store the data on the chain and directly returns the on-chain result to the on-chain user. The client-side on-chain method adopts asynchronous on-chain. The server assembles the initial data into on-chain data and displays it on the system interface. After user confirmation, the on-chain operation is recorded in the on-chain log and marked as pending on-chain status. The system interface quickly responds with a success message, and then asynchronously calls the client-side on-chain service to execute the actual on-chain operation.

2. The method according to claim 1, characterized in that: When verifying certificates and private keys, obtain the X.509 certificate and private key issued by the consortium organization submitted by the user; The X.509 certificate is validated. The validation includes: verifying whether the X.509 certificate has a verifiable certificate path from the consortium root certificate or intermediate certificate to the X.509 certificate; and verifying whether the X.509 certificate is on the certificate revocation list. After the certificate validity verification is successful, the user's digital signature is verified using the private key to confirm that the user is the legitimate holder of the X.509 certificate; After the signature verification is successful, the user is mapped to the corresponding alliance organization and the role under that alliance organization based on the organization unit field in the X.509 certificate; Based on the alliance organization and role obtained from the mapping, obtain the operation permission information corresponding to the user, and determine whether the user has the operation permission to initiate the current on-chain storage request; When certificate validity verification, signature verification, and operation permission judgment all pass, the user is confirmed to have the permission to operate the consortium blockchain.

3. The method according to claim 1, characterized in that, The server will assemble the initial data into on-chain data, including: The server receives initialization data, which includes at least one business identifier field and data type. Based on the type of data to be uploaded to the chain, the target data structure definition that matches the initial data is queried from the data structure mapping table pre-stored on the server. The data structure mapping table records the correspondence between different data types and the data structures defined in the chaincode. Based on the target data structure definition obtained from the query, each field in the initial data is mapped to the corresponding field in the data structure required by the chaincode, generating on-chain data that conforms to the on-chain format; Based on the data type, the target chaincode identifier and target chaincode method corresponding to the data type are queried from the chaincode mapping table pre-stored on the server. The chaincode mapping table records the correspondence between different data types and the chaincode and chaincode methods deployed on the consortium blockchain. Based on the target chaincode identifier and target chaincode method found in the query, construct a chaincode invocation request. The chaincode invocation request carries the on-chain data and the method parameters required by the target chaincode method. Send the chaincode invocation request to the endorsing node of the consortium blockchain to request that the on-chain data be stored in the consortium blockchain according to the target chaincode method.

4. The method according to claim 1, characterized in that: In the client-side on-chain method, the server returns the assembled on-chain data and its corresponding data hash value to the system interface for display. The data hash value is used by the user to verify whether the on-chain data has been tampered with during transmission. In response to the user's data confirmation operation on the system interface, the system interface obtains the organization information in the current user's certificate, and queries the channel configuration of the consortium blockchain based on the organization information to find one or more available channels that the user can access, as well as one or more available contracts that the user has the right to call under each available channel. The system interface displays one or more available channels and their corresponding available contracts in a visual list for users to select from. Receive the target channel identifier selected by the user from the available channels and the target contract identifier selected from the available contracts; Based on the organization unit and role fields in the user's certificate, and in conjunction with the access control list of the target channel, verify whether the user has the permission to invoke the target contract on the target channel; Once the user has permission to invoke the target contract, the system verifies whether the target contract has deployed a target chaincode method corresponding to the data type, based on the data type to be uploaded to the chain. After the target contract is successfully matched and verified, the system receives the final confirmation instruction from the user. The final confirmation instruction carries the signature data generated by the user digitally signing the hash value of the on-chain data using their private key. The server uses the user's certificate to verify the signature data. Once the verification is successful, it confirms that the data uploaded to the blockchain has not been tampered with after the user's confirmation, and records the blockchain upload operation in the blockchain log.

5. The method according to claim 1, characterized in that, Before recording on-chain operations in the on-chain log, it also includes pre-on-chain verification of the on-chain data: Extract the unique business identifier and current status identifier from the initialization data; Based on the unique business identifier, query the on-chain logs to see if there is a set of historical log records corresponding to the unique business identifier. If the historical log record set is empty, the current on-chain operation is determined to be the first on-chain operation of the data corresponding to the unique business identifier. The on-chain pre-verification is passed, and it is allowed to write the current on-chain operation to the on-chain log. If the historical log record set is not empty, the corresponding predefined state transition path is obtained according to the data type of the initialization data. The state transition path is a directed acyclic graph structure, which is used to define the legal transition order between states under the same business unique identifier. Based on the current state identifier and the state transition path, determine the set of predecessor states of the current state.

6. The method according to claim 5, characterized in that: Search the historical log record set to see if there is a predecessor log record corresponding to any predecessor state in the predecessor state set; If there is no predecessor log record corresponding to any predecessor state in the predecessor state set, it is determined that the predecessor state data of the current on-chain operation has not yet initiated an on-chain request, the current on-chain request is rejected and an error message is returned. If there is a predecessor log record corresponding to any predecessor state in the predecessor state set, then read the on-chain state field in the predecessor log record and determine whether the data corresponding to the predecessor state has been marked as on-chain. If the data corresponding to the predecessor state is not marked as being on the chain, the current on-chain request is rejected and a failure message containing information that the predecessor state is not on the chain is returned. If the data corresponding to the predecessor state has been marked as being on the chain, then acquire a distributed lock with the business unique identifier as the key name; After successfully acquiring the distributed lock, query the predecessor log in the on-chain log again to see the current on-chain status. If the current on-chain status has changed and is no longer on-chain, release the distributed lock and reject the current on-chain request. If the current on-chain status is still on-chain, write the current on-chain operation to the on-chain log, mark it as pending on-chain status, and release the distributed lock after successful writing.

7. The method according to claim 1, characterized in that, After asynchronously calling the client's on-chain service to perform the actual on-chain operation, it also includes: The server periodically scans the consortium blockchain and updates the on-chain logs based on the scan results. For data that has already been stored on the consortium blockchain, the corresponding record in the on-chain log will be marked as having been on-chain. For data that has not been stored on the consortium blockchain, the corresponding record in the on-chain log will be kept in a pending on-chain state so that users can manually re-initiate the on-chain process through the log interface.

8. The method according to claim 1, characterized in that: In the client-side on-chain method, when the data to be on-chain is state change data with multiple states, the on-chain operation for the current state must be executed after the on-chain operation for the previous state is completed. Specifically, obtain the unique business identifier and current status identifier corresponding to the data to be uploaded to the blockchain; Based on the unique business identifier and the current state identifier, the set of predecessor states of the current state is queried from the predefined state dependency graph model. The state dependency graph model is a directed acyclic graph structure, which is used to define the sequential dependency relationship between states under the same unique business identifier. Each state is a node, and the directed edges between states represent the execution order dependency of the on-chain operations. If the predecessor state set is empty, the current state is determined to be the initial state, and the current on-chain request is allowed to continue. If the predecessor state set is not empty, then acquire the distributed lock with the business unique identifier as the key name.

9. The method according to claim 8, characterized in that, After successfully acquiring the distributed lock, perform the following serialized verification steps: Query all historical log records corresponding to the unique business identifier from the on-chain logs; For each predecessor state in the predecessor state set, query the historical log records to see if there is a predecessor log record corresponding to the predecessor state. If any predecessor state in the predecessor state set has no corresponding predecessor log record in the historical log record, it is determined that the predecessor state has not yet initiated the on-chain process, the distributed lock is released, and the current on-chain request failure and missing state information are returned. If each predecessor state in the predecessor state set has a corresponding predecessor log record, then the on-chain state field in each predecessor log record is further read to confirm whether each predecessor state has been marked as on-chain. If any predecessor state in the predecessor state set is not marked as being on the chain, the distributed lock is released, and a failure message containing the information of the incomplete predecessor state is returned. If each predecessor state in the predecessor state set has been marked as being on the chain, then write the log record corresponding to the current state into the on-chain log, mark it as a state to be on the chain, and release the distributed lock after successful writing. In the case where the set of predecessor states contains multiple predecessor states, there is a parallel dependency relationship between the multiple predecessor states. That is, the current state's on-chain operation can only be allowed to be executed after all the predecessor states have been on-chained.

10. A dual-end interactive on-chain data storage system, characterized in that, include: Consortium blockchains are used to store on-chain data; The server is used to receive users' on-chain requests, verify users' certificates and private keys, assemble initial data into on-chain data, and provide on-chain service interfaces for both the server and client. The client communicates with the server and is used to perform asynchronous on-chain operations; The on-chain log module is used to record on-chain operations and on-chain status under the client's on-chain mode; The system is configured to perform the method as described in any one of claims 1 to 9.

Images