Archive handover method and device based on block chain, server and storage medium

Abstract

The invention provides an archive handover method and device based on a block chain, a server and a storage medium, and relates to the technical field of archive processing. The method comprises the following steps: in response to an archive handover request initiated by a handover party client, generating a dynamic handover code, and sending the dynamic handover code to the handover party client for display; the dynamic handover code comprises a bound receiver identity label and a to-be-handed-over file list. And receiving a verification request sent by the receiver client. And if it is determined that the dynamic handover code is in a correct state and the receiver identity of the receiver client is matched with the receiver identity identifier, pushing the to-be-handed-over file list to the receiver client for display. And if a receiving confirmation instruction sent by the receiver client is received, generating a handover event record based on the receiving confirmation instruction, and storing the hash value of the handover event record to the block chain. The method is used for achieving the effect of improving the safety of an existing archive handover method.

Description

Technical Field

[0001] This application relates to the field of archival processing technology, and more specifically, to a blockchain-based archival transfer method, apparatus, server, and storage medium. Background Technology

[0002] Currently, the handover of physical documents is a frequent and crucial daily activity in business dealings within corporate groups and with external partners (such as law firms and auditing firms). These documents may contain sensitive business contracts, financial documents, legal documents, personnel records, etc. The core of document handover is ensuring a clear transfer of responsibility; that is, at a specific point in time, the responsibility for the safekeeping of the documents clearly transfers from the sender to the receiver. This process needs to be accurately and reliably recorded for subsequent auditing and traceability.

[0003] In existing technology, the handover of archives usually involves signing a paper handover form. Specifically, both parties count the archives on a printed handover list and sign to confirm.

[0004] However, in the existing technology, the signing of paper handover forms is inefficient, paper documents are easy to lose or tamper with, and the authenticity of signatures is difficult to verify, resulting in insufficient security of existing file handover methods. Summary of the Invention

[0005] The purpose of this application is to provide a blockchain-based method, apparatus, server, and storage medium for transferring archives, thereby solving the aforementioned problems in the prior art and greatly improving the security of existing archive transfer methods.

[0006] Firstly, a blockchain-based method for transferring archives is provided, which may include: In response to a file handover request initiated by the receiving client, a dynamic handover code is generated and sent to the receiving client for display; wherein, the dynamic handover code includes a bound receiver identity identifier and a list of files to be handed over; Receive a verification request sent by the receiving client; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client; If the dynamic handover code is determined to be in a correct state, and the recipient's identity on the receiving client matches the recipient's identity identifier, then the list of files to be handed over is pushed to the receiving client for display. If a confirmation of receipt is received from the receiving client, a handover event record is generated based on the confirmation of receipt, and the hash value of the handover event record is stored in the blockchain.

[0007] Secondly, a blockchain-based document transfer device is provided, which may include: A generation module is used to respond to a file handover request initiated by the handover client, generate a dynamic handover code, and send the dynamic handover code to the handover client for display; wherein, the dynamic handover code includes a bound receiver identity identifier and a list of files to be handed over; A receiving module is used to receive a verification request sent by a receiving client; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client; The push module is used to push the list of files to be handed over to the receiving client for display if it is determined that the dynamic handover code is in a correct state and the receiving client's identity matches the receiving client's identity identifier. The storage module is used to generate a handover event record based on the confirmation of receipt instruction sent by the receiving client if it receives the confirmation of receipt instruction, and to store the hash value of the handover event record in the blockchain.

[0008] Thirdly, a server is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0009] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0010] This application provides a blockchain-based file transfer method, apparatus, server, and storage medium. In response to a file transfer request initiated by the transferring client, a dynamic transfer code is generated and sent to the transferring client for display. The dynamic transfer code includes a bound recipient identity identifier and a list of files to be transferred. A verification request is received from the receiving client, containing information obtained by scanning the dynamic transfer code displayed on the transferring client. If the dynamic transfer code is confirmed to be correct and the recipient's identity matches the recipient's identity identifier, the list of files to be transferred is pushed to the receiving client for display. If a confirmation of receipt is received from the receiving client, a transfer event record is generated based on the confirmation, and the hash value of the transfer event record is stored in the blockchain. In this solution, the tracking of entity file transfer responsibilities based on identity binding and a time-sensitive dynamic transfer code is mainly achieved through a dedicated App or mini-program running on both transferring clients (such as smartphones) in collaboration with a background server. By using a time-sensitive, dynamic QR code linked to identity and task, replacing all static handover credentials, document handover is executed, generating a handover event record. The hash value of this record is stored on the blockchain, providing the highest level of decentralized credibility for the handover process. Simultaneously, the four key elements—time, location, person, and event—are automatically captured and merged into an indivisible event record at the moment of handover completion. This solves the problems of strong binding, anti-forgery, and non-repudiation of the four crucial elements: "Who," "When," "Where," and "What was handed over." It addresses the core issues of insufficient security, susceptibility to impersonation, incomplete process information, and easy repudiation in existing document handover methods, significantly improving their security. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic flowchart illustrating a blockchain-based file transfer method provided in this application embodiment; Figure 2 A schematic flowchart illustrating a blockchain-based file transfer method provided in this application embodiment; Figure 3 A schematic diagram of a blockchain-based file transfer device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0014] Currently, the handover of physical documents is a frequent and crucial daily activity in business dealings within corporate groups and with external partners (such as law firms and auditing firms). These documents may contain sensitive business contracts, financial documents, legal documents, personnel records, etc. The core of document handover is ensuring a clear transfer of responsibility; that is, at a specific point in time, the responsibility for the safekeeping of the documents clearly transfers from the sender to the receiver. This process needs to be accurately and reliably recorded for subsequent auditing and traceability.

[0015] In one example, the handover of documents typically involves a signed paper handover form. Specifically, both parties check the documents on a printed handover list and sign to confirm receipt. Alternatively, the handover can be done via static barcode / QR code scanning. Specifically, a unique barcode or QR code is printed for each package or batch of documents. During the handover, the recipient scans the code with a barcode scanner or mobile phone and clicks "Confirm Receipt" in the system to complete the handover.

[0016] However, in existing technologies, signing paper handover forms is inefficient, paper documents are easily lost or altered, and the authenticity of signatures is difficult to verify, resulting in insufficient security for current document handover methods. While static barcode / QR code scanning achieves digitization, it also presents security risks: once a static code is printed, it can be copied, photographed, or leaked in advance. Unauthorized personnel may scan the copied code to impersonate the recipient, or one party may later deny the time and place of the scanning, further compromising the security of document handover.

[0017] For ease of understanding, the terms used in the embodiments of this application are explained below: The blockchain-based file transfer method provided in this application can be applied to a system architecture, which may include a server and a client. The client includes a transfer client and a receiving client. The transfer client and the receiving client can be the same mobile terminal or different mobile terminals, without limitation. When they are the same mobile terminal, the client initiating the file transfer request is the transfer client, and the client receiving the file is the receiving client. The interaction between the server and the client is not limited to enterprise backend and enterprise employees, but can also be between enterprises, etc., without limitation. The server can be a physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The terminal can be a user equipment (UE) such as a mobile phone, smartphone, laptop computer, digital broadcast receiver, personal digital assistant (PDA), tablet computer (PAD), handheld device, in-vehicle device, wearable device, computing device or other processing device connected to a wireless modem, mobile station (MS), mobile terminal, etc. The terminal and server can be connected directly or indirectly through wired or wireless communication methods, which is not limited herein.

[0018] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0019] Figure 1 This is a flowchart illustrating a blockchain-based file transfer method provided in an embodiment of this application. Figure 1As shown, the method may include: Step S101: In response to the file handover request initiated by the handover client, generate a dynamic handover code and send the dynamic handover code to the handover client for display; wherein, the dynamic handover code includes the bound receiver identity identifier and the list of files to be handed over.

[0020] For example, the handover client can be a dedicated mobile app, mini-program, or PC. The sender, on the mobile app, selects or creates a batch of files to be handed over (containing a list of files), and specifies the receiver's identity information (such as an employee ID). Then, the sender performs real-time biometric identification or enters a high-level password through the app to confirm their identity. After successful authentication, the app sends a file handover request to the backend server; this request is essentially a request to generate a handover code. The server receives the file handover request from the sender client and verifies it. Upon successful verification, the server performs the following operations: Generate a payload containing information such as the unique identifier (ID) of this file handover task, the handover party ID, the receiver ID, the current timestamp, and a nonce to prevent replay.

[0021] The payload is encrypted or signed using a dynamic key (which changes periodically) to generate a time-sensitive encrypted data string. This encrypted data string is then encoded into a graphic code, or "dynamic handover code," for example, a QR code.

[0022] The server sends a dynamic handover code to the app of the receiving party for display. This dynamic handover code is automatically refreshed every preset time period (e.g., 30 seconds), and the old dynamic handover code immediately becomes invalid. The dynamic handover code includes the bound identity identifier of the receiving party and a list of files to be handed over.

[0023] Step S102: Receive a verification request sent by the receiving client; wherein the verification request contains information obtained by scanning the dynamic handover code displayed by the handover client.

[0024] For example, the receiving client can be a dedicated mobile terminal app, mini-program, or PC. The transferring party, as the initiator of the file transfer task and the current custodian of the file, presents a transfer credential, i.e., a dynamic transfer code, to the correct receiving party. The receiving party opens its mobile terminal app, enters "scan code to receive," scans the dynamic transfer code displayed on the transferring party's mobile terminal app screen, parses the dynamic transfer code to obtain an encrypted data string, and generates a verification request based on the encrypted data string. This verification request is then sent to the server for decryption and verification. The server receives the verification request sent by the receiving party's client; the verification request contains the encrypted data string obtained by scanning the dynamic transfer code displayed on the transferring party's client.

[0025] Step S103: If the dynamic handover code is confirmed to be in the correct state and the recipient's identity matches the recipient's identity identifier, then the list of files to be handed over is pushed to the recipient's client for display.

[0026] For example, the server verifies the validity and timeliness of the dynamic handover code, and confirms whether the recipient's identity bound to the dynamic handover code matches the identity of the recipient currently logging into the App by scanning the code. After successful verification, the server pushes detailed information such as the list of files to be handed over to the recipient's App interface.

[0027] Step S104: If a confirmation of receipt instruction is received from the receiving client, a handover event record is generated based on the confirmation of receipt instruction, and the hash value of the handover event record is stored in the blockchain.

[0028] For example, after the recipient has checked the physical files according to the list of files to be handed over, they perform real-time biometric identification or enter a password on the App to generate their own "digital signature" and click the "Confirm Receipt" button. The recipient's client App generates a confirmation receipt instruction based on the digital signature and confirmation signal and sends the confirmation receipt instruction to the server. If the server receives the confirmation receipt instruction sent by the recipient's client, it immediately generates a complete and structured "handover event record" based on the confirmation receipt instruction. This record includes: handover task ID, handover file list, identity IDs of the handover party and the recipient, a handover completion timestamp accurate to the second, the geographical coordinates of the location at the time of the handover obtained through the mobile terminal's GPS or base station positioning, and the digital signature or biometric authentication credentials when the handover party initiates the handover and when the recipient confirms it.

[0029] Ultimately, the server records the hash value of this handover event as a transaction record on an immutable distributed ledger (such as a blockchain), forming a legally valid and undeniable evidence of the transfer of rights and responsibilities.

[0030] The method provided in this application embodiment, in response to a file handover request initiated by the handover client, generates a dynamic handover code and sends the dynamic handover code to the handover client for display; wherein, the dynamic handover code includes a bound receiver identity identifier and a list of files to be handed over. It receives a verification request sent by the receiver client; wherein, the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client. If it is determined that the dynamic handover code is in a correct state, and the receiver identity of the receiver client matches the receiver identity identifier, then the list of files to be handed over is pushed to the receiver client for display. If a confirmation of receipt instruction is received from the receiver client, a handover event record is generated based on the confirmation of receipt instruction, and the hash value of the handover event record is stored in the blockchain. In this solution, the tracking of entity file handover responsibilities based on identity binding and time-sensitive dynamic handover codes is mainly achieved through a dedicated App or Mini Program running on the clients of both handover parties (such as smartphones and other mobile terminals), working in conjunction with a background server. By using a time-sensitive, dynamic QR code linked to identity and task, replacing all static handover credentials, document handover is executed, generating a handover event record. The hash value of this record is stored on the blockchain, providing the highest level of decentralized credibility for the handover process. Simultaneously, the four key elements—time, location, person, and event—are automatically captured and merged into an indivisible event record at the moment of handover completion. This solves the problems of strong binding, anti-forgery, and non-repudiation of the four crucial elements: "Who," "When," "Where," and "What was handed over." It addresses the core issues of insufficient security, susceptibility to impersonation, incomplete process information, and easy repudiation in existing document handover methods, significantly improving their security.

[0031] Figure 2 A flowchart illustrating a blockchain-based document transfer method provided for this application is shown below. Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the method is described in detail below, and the method includes: Step S201: In response to the file handover request initiated by the client of the handover party, generate a dynamic handover code.

[0032] In one example, S201 includes: responding to a file handover request initiated by the handover client, obtaining payload data; wherein the payload data includes a handover task identifier corresponding to the file handover request, a handover party identifier, a receiver identifier, a timestamp, and a replay-protected random number; obtaining the dynamic key at the current moment, encrypting or digitally signing the payload data according to the dynamic key to generate encrypted data; and encoding the encrypted data into a graphic code as a dynamic handover code.

[0033] In one example, the dynamic handover code has an expiration period, which is implemented in at least one of the following ways: the timestamp associated with the dynamic handover code has a time limit constraint; and / or, the dynamic handover code is refreshed periodically according to a preset duration.

[0034] For example, the sender creates a "handover task" in the file management system on a PC or mobile app. Specifically, a batch of files to be handed over (each file has a unique radio frequency identification (RFID) or barcode) can be added to a virtual "handover basket" by checking boxes or scanning. The server generates a unique batch ID for this basket.

[0035] Secondly, initiate the handover. At the handover site, the parties involved open their mobile app, locate the handover task, and click the "Initiate Handover" button. Thirdly, perform identity authentication for the parties involved. Specifically, the client app of the parties involved will trigger a high-security identity authentication process, which can be configured to include one or more of the following: Face ID / Fingerprint recognition: calls the biometric API at the bottom layer of the mobile operating system; One-time password (OTP): requires the input of a dynamic password received via SMS or authentication app (such as Google Authenticator); Knowledge password: requires the input of a preset transaction password that is different from the login password.

[0036] After successful identity verification, the client app of the handover party will generate a temporary security token representing the successful verification.

[0037] Finally, the client app requests a dynamic handover code from the server. Specifically, the client app sends the batch ID and security token to the server's default interface via an encrypted file handover request (e.g., an HTTPS POST request).

[0038] The server receives the file transfer request initiated by the client and performs a series of strict checks: Verify the validity of the security token to confirm that the legitimate person performing the handover is operating the system; query the batch ID to confirm that the task exists and is in the "pending handover" state.

[0039] After the server verification is successful, the dynamic code generation logic is initiated. Construct the payload: Create a JSON object, payload = { "batchId": "B001", "senderId": "U123", "receiverId": "U456", "timestamp": 1666888888, "nonce": "random_string"}. Retrieve the payload data from the JSON object; the payload data includes the batchId (assigned task identifier), senderId, receiverId, timestamp, and nonce (a random number to prevent replay attacks) corresponding to the file handover request.

[0040] Then, the server performs dynamic key processing and encryption. Specifically, the server maintains a dynamic key K_dynamic, which can be generated based on a preset time period (e.g., changing every minute) or a predetermined algorithm. The server obtains the dynamic key at the current moment and, based on it, encrypts or signs the string form of the payload using a symmetric encryption algorithm (such as AES-GCM) or an asymmetric encryption signature algorithm (such as ECDSA), obtaining a ciphertext. Among these, AES-GCM mode provides both encryption and authentication simultaneously and is the preferred algorithm.

[0041] Finally, the server uses the ciphertext (usually Base64 encoded) as data and calls a QR code generation library (such as QR-Code-generator) to generate a QR code image, which can be a dynamic handover code.

[0042] Furthermore, the server returns the dynamic handover code to the client app. Simultaneously, the client app starts a timer (e.g., every 30 seconds). Whenever the timer triggers, the client app automatically sends a "refresh handover code" request to the server (carrying the original security token). The server then re-encrypts and generates a new dynamic handover code using the latest dynamic key, overwriting the old one. This ensures that the code displayed on the screen is always "fresh."

[0043] Step S202: Send the dynamic handover code to the handover party's client for display; wherein, the dynamic handover code includes the bound receiver's identity identifier and the list of files to be handed over.

[0044] For example, this step is described in step S102, and will not be repeated here.

[0045] Step S203: Receive a verification request sent by the receiving client; wherein the verification request contains information obtained by scanning the dynamic handover code displayed by the handover client.

[0046] For example, the receiver opens its own receiver client app, and its login status itself constitutes a layer of identity verification. Clicking the "Scan" button scans the dynamic code on the handover device's phone. The receiver's client app sends the parsed ciphertext to a predefined interface on the server, for example, the / api / handovers / verify interface. The server then receives the verification request sent by the receiver client; this verification request includes the ciphertext obtained by scanning the dynamic handover code displayed on the handover client.

[0047] Step S204: Check the timeliness, identity matching, and uniqueness of the dynamic handover code.

[0048] For example, after receiving the ciphertext, the server decrypts it using the current (or one of the most recent valid) dynamic key K_dynamic. If decryption fails, indicating that the code has expired or been forged, an error is returned directly. If decryption succeeds, a payload JSON object is obtained, and the following checks are performed: Timeliness check: Check whether the timestamp in the payload is within the preset error range (e.g., 45 seconds) compared to the current server time; if it times out, the payload will be rejected.

[0049] Identity matching check: Check if the receiverId in the payload matches the recipient ID of the person initiating the verify request. If they do not match, it indicates that "someone else scanned the QR code," and the request is rejected.

[0050] Uniqueness check: Check if the nonce (a one-time anti-replay random number) in the payload already exists in the cache (has been used) to prevent replay attacks. Store the nonce in the cache immediately after use and set a short expiration time.

[0051] Therefore, by using multiple security verification logics on the server, a backend security gateway was built that includes multiple verifications such as timeliness, identity matching, and one-time random number (anti-replay), ensuring the rigor of the dynamic code verification process and improving the accuracy of file handover.

[0052] Step S205: If the dynamic handover code is confirmed to be in the correct state and the recipient's identity matches the recipient's identity identifier, then the list of files to be handed over is pushed to the recipient's client for display.

[0053] For example, if all the above verifications pass, the dynamic handover code is confirmed to be correct, and the recipient's identity matches the recipient's identifier. The server then queries the database for a detailed list of files to be handed over corresponding to the batchId and pushes this list to the recipient's app. After seeing a clear list of files to be handed over on the app interface, the recipient verifies it against the physical files. If the verification is successful, the recipient clicks the "Confirm Receipt" button, triggering another high-security authentication (face / fingerprint, etc.). This authentication operation generates a "digital signature" locally that can be verified by the backend.

[0054] Step S206: If a confirmation of receipt instruction is received from the receiving client, a handover event record is generated based on the confirmation of receipt instruction, and the hash value of the handover event record is stored in the blockchain.

[0055] In one example, S206 includes: if a confirmation of receipt instruction sent by the receiving client is received through a preset interface, a handover event record is generated in the current archive database based on the confirmation of receipt instruction; wherein, the confirmation of receipt instruction includes the receiving client's confirmation of receipt signal, the receiving client's digital signature, and the current latitude and longitude coordinates; the handover event record is serialized and hashed to generate a hash value, and the hash value is stored in the blockchain.

[0056] In one example, the file handover request from the handover client and / or the confirmation of receipt instruction from the receiving client are both issued after identity authentication is completed through biometric identification or dynamic password.

[0057] In one example, the handover event log includes any one or more of the following: handover task ID, handover file list, identity IDs of the handover party and the receiving party, handover completion timestamp, geographical coordinates of the time the handover occurred, and digital signature credentials of the handover party and the receiving party.

[0058] For example, firstly, the receiving app sends a "confirm receipt" signal, along with the recipient's own digital signature and the current latitude and longitude coordinates obtained through the phone's location services (GPS / Wi-Fi / base station), to a pre-defined interface on the server. For example, the pre-defined interface could be the / api / handovers / complete interface.

[0059] Secondly, a Handover Event Record is generated. Upon receiving the confirmation instruction (e.g., a complete request) and verifying the validity of the digital signature, the server immediately updates the status of the handover task to "completed" in the database and generates a detailed, structured handover event record. This record is a JSON object or database row containing all key elements, permanently storing all dimensions of information related to this handover. The handover event record includes any one or more of the following: handover task ID, handover file list, identity IDs of the handover party and the receiving party, handover completion timestamp, geographical coordinates of the time the handover occurred, and digital signature credentials of the handover party and the receiving party.

[0060] Secondly, blockchain evidence is stored. To achieve the highest level of immutability and trustworthiness, the server performs the following operations: The generated JSON object of the "handover event record" is serialized and hashed to obtain a unique hash value H_event. The blockchain node client on the server constructs a new transaction, using H_event as the main content (payload) and including index information such as the task ID. Finally, the transaction is broadcast to the consortium blockchain network for record management.

[0061] Once a transaction is packaged and uploaded to the blockchain by consensus nodes, it forms a permanent, tamper-proof record of the handover that cannot be altered by any single party. The original detailed handover event record can be stored in a centralized database or distributed file system, while the blockchain only stores its "fingerprint" (hash value), achieving a balance between efficiency and trustworthiness.

[0062] Optionally, the file handover request from the sending client and / or the confirmation instruction from the receiving client are both issued after identity authentication is completed through biometric recognition or dynamic password. Therefore, the "two-way strong authentication" process design innovatively requires high-security identity authentication at both the initiating and receiving stages of the handover, ensuring the authenticity of the "person".

[0063] Therefore, this application constructs a highly secure digital handover confirmation mechanism that strongly binds handover actions to specific times, locations, personnel identities, and file batches. Specifically, it generates a "one-time password" dynamically changing handover credential, which is valid for a short period. The generation and verification of this credential must be linked to the real-time identity authentication of both parties. The handover is completed by scanning this dynamic credential. The server needs to be able to automatically and accurately capture and solidify a multi-dimensional, tamper-proof chain of evidence of the "handover fact," including timestamps, geographical locations, and digital signatures of both parties, thereby completely eliminating risks such as impersonation, premature / delayed confirmation, and subsequent repudiation.

[0064] The method provided in this application, in response to a file handover request initiated by the handover client, generates a dynamic handover code. The dynamic handover code is sent to the handover client for display; wherein the dynamic handover code includes a bound recipient identity identifier and a list of files to be handed over. A verification request sent by the recipient client is received; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client. The timeliness, identity matching, and uniqueness of the dynamic handover code are checked. If it is determined that the dynamic handover code is in a correct state and the recipient identity of the recipient client matches the recipient identity identifier, the list of files to be handed over is pushed to the recipient client for display. If a confirmation of receipt instruction is received from the recipient client, a handover event record is generated based on the confirmation of receipt instruction, and the hash value of the handover event record is stored in the blockchain. In this solution, the tracking of entity file handover responsibilities based on identity binding and timeliness-based dynamic handover codes is mainly achieved through a dedicated App or mini-program running on the clients of both handover parties (such as smartphones and other mobile terminals), working in conjunction with a background server. By using a time-sensitive, dynamic QR code linked to identity and task, replacing all static handover credentials, document handover is executed, generating a handover event record. The hash value of this record is stored on the blockchain, providing the highest level of decentralized credibility for the handover process. Simultaneously, the four key elements—time, location, person, and event—are automatically captured and merged into an indivisible event record at the moment of handover completion. This solves the problems of strong binding, anti-forgery, and non-repudiation of the four crucial elements: "Who," "When," "Where," and "What was handed over." It addresses the core issues of insufficient security, susceptibility to impersonation, incomplete process information, and easy repudiation in existing document handover methods, significantly improving their security.

[0065] In one example, this application embodiment also provides a file handover tracking system, which includes: a server configured to generate dynamic handover codes and verify file handover requests; and client applications running on the mobile terminals of both parties involved in the handover, for displaying the dynamic codes, scanning the dynamic handover codes, and performing identity authentication.

[0066] Corresponding to the above method, embodiments of this application also provide a blockchain-based file transfer device, such as... Figure 3 As shown, the device includes: The generation module 41 is used to respond to the file handover request initiated by the handover client, generate a dynamic handover code, and send the dynamic handover code to the handover client for display; wherein, the dynamic handover code includes the bound receiver identity identifier and the list of files to be handed over; The receiving module 42 is used to receive a verification request sent by the receiving client; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client; The push module 43 is used to push the list of files to be handed over to the receiving client for display if it is determined that the dynamic handover code is in a correct state and the receiving identity of the receiving client matches the receiving identity identifier. The storage module 44 is used to generate a handover event record based on the confirmation of receipt instruction sent by the receiving client if the confirmation of receipt instruction is received, and to store the hash value of the handover event record in the blockchain.

[0067] The functions of each functional unit of the blockchain-based file transfer device provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the blockchain-based file transfer device provided in the embodiments of this application will not be repeated here.

[0068] This application also provides a server, such as... Figure 4 As shown, it includes a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540.

[0069] Memory 530 is used to store computer programs; The processor 510 performs the above steps when executing the program stored in the memory 530.

[0070] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0071] The communication interface is used for communication between the aforementioned server and other devices.

[0072] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0073] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0074] The implementation methods and beneficial effects of the server's various components in the above embodiments for solving the problem can be found in [reference needed]. Figure 1 The steps in the illustrated embodiments are used to implement the process. Therefore, the specific working process and beneficial effects of the server provided in this application will not be repeated here.

[0075] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the blockchain-based file transfer methods described in the above embodiments.

[0076] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the blockchain-based file transfer methods described in the above embodiments.

[0077] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0079] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0080] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0081] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0082] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A blockchain-based method for transferring archives, characterized in that, The method includes: In response to a file handover request initiated by the receiving client, a dynamic handover code is generated and sent to the receiving client for display; wherein, the dynamic handover code includes a bound receiver identity identifier and a list of files to be handed over; Receive a verification request sent by the receiving client; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client; If the dynamic handover code is determined to be in a correct state, and the recipient's identity on the receiving client matches the recipient's identity identifier, then the list of files to be handed over is pushed to the receiving client for display. If a confirmation of receipt is received from the receiving client, a handover event record is generated based on the confirmation of receipt, and the hash value of the handover event record is stored in the blockchain.

2. The method as described in claim 1, characterized in that, In response to a file handover request initiated by the receiving client, a dynamic handover code is generated, including: In response to a file handover request initiated by the client of the handover party, the payload data is obtained; wherein, the payload data includes a handover task identifier, a handover party identity identifier, a receiver identity identifier, a timestamp, and a replay-prevention random number corresponding to the file handover request; Obtain the dynamic key at the current moment, and encrypt or digitally sign the payload data based on the dynamic key to generate encrypted data; The encrypted data is encoded into a graphic code, which serves as the dynamic handover code.

3. The method as described in claim 2, characterized in that, The dynamic handover code has a validity period, which is implemented in at least one of the following ways: The timestamp associated with the dynamic handover code has a time limit; and / or, the dynamic handover code is refreshed periodically according to a preset duration.

4. The method as described in claim 1, characterized in that, If a confirmation of receipt is received from the receiving client, a handover event record is generated based on the confirmation of receipt, and the hash value of the handover event record is stored in the blockchain, including: If a confirmation of receipt instruction sent by the receiving client is received through a preset interface, a handover event record is generated in the current archive database based on the confirmation of receipt instruction; wherein, the confirmation of receipt instruction includes the receiving client's confirmation of receipt signal, the receiving client's digital signature, and the current latitude and longitude coordinates; The handover event records are serialized and hashed to generate hash values, which are then stored in the blockchain.

5. The method as described in claim 1, characterized in that, The file handover request from the handover client and / or the confirmation of receipt instruction from the receiving client are both issued after identity authentication is completed through biometric identification or dynamic password.

6. The method as described in claim 1, characterized in that, After receiving the verification request sent by the receiving client, the method further includes: The timeliness, identity matching, and uniqueness of the dynamic handover code are checked.

7. The method according to any one of claims 1-6, characterized in that, The handover event log includes any one or more of the following: The handover task ID, handover file list, identity IDs of the handover party and the receiving party, handover completion timestamp, geographical coordinates of the handover when it occurred, and digital signature credentials of the handover party and the receiving party.

8. A blockchain-based file transfer device, characterized in that, The device includes: A generation module is used to respond to a file handover request initiated by the handover client, generate a dynamic handover code, and send the dynamic handover code to the handover client for display; wherein, the dynamic handover code includes a bound receiver identity identifier and a list of files to be handed over; A receiving module is used to receive a verification request sent by a receiving client; wherein the verification request includes information obtained by scanning the dynamic handover code displayed by the handover client; The push module is used to push the list of files to be handed over to the receiving client for display if it is determined that the dynamic handover code is in a correct state and the receiving client's identity matches the receiving client's identity identifier. The storage module is used to generate a handover event record based on the confirmation of receipt instruction sent by the receiving client if it receives the confirmation of receipt instruction, and to store the hash value of the handover event record in the blockchain.

9. A server, characterized in that, The server includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images