Blockchain-based file processing method and apparatus, device, and file contribution system

Abstract

Embodiments of the present application disclose a blockchain-based file processing method and device, equipment and a file contribution system. The method comprises: initiating, by an author account, a call to a first smart contract deployed on a blockchain to transmit a contribution file and file-related information into the first smart contract; generating, in the first smart contract, a ciphertext corresponding to the contribution file according to a first access policy, and storing the ciphertext and the file-related information on the blockchain, wherein the first access policy comprises that an editing account has access rights to the contribution file; returning, by a blockchain network, a credential corresponding to the contribution file to the author account, and sending a notification message to the editing account to indicate that the contribution file has been stored on the blockchain. Embodiments of the present application can greatly reduce the possibility of the original text of the contribution file being leaked, and can also perform credible peer review on the contribution file.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a blockchain-based document processing method and apparatus, and also to a document submission system. Background Technology

[0002] Blockchain is an important component of the next generation of information technology. It is a new type of database software that integrates multiple technologies such as distributed networks, encryption technology, and smart contracts. By making data transparent, tamper-proof, and traceable, it solves the trust and security problems in cyberspace and promotes the transformation of the Internet from transmitting information to transmitting value.

[0003] Currently, blockchain technology is gradually being applied in the field of copyright. Generally, after hashing the original text of a submitted document using a hash algorithm, the resulting hash value is stored on the blockchain as proof of the document's existence. The original text is then publicly published on the blockchain network. While this facilitates convenient submissions and provides proof of the document's existence on the blockchain, it also increases the likelihood of large-scale leaks of the original text and plagiarism. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a blockchain-based file processing method, a blockchain-based file processing device, an electronic device, a computer-readable storage medium, and a computer program product, as well as a file submission system.

[0005] According to one aspect of the embodiments of this application, a blockchain-based file processing method is provided, comprising: initiating a call to a first smart contract deployed on the blockchain through an author account to pass a submitted file and file-related information into the first smart contract; generating ciphertext corresponding to the submitted file in the first smart contract according to a first access policy, and storing the ciphertext and the file-related information on the blockchain, wherein the first access policy includes that an editor account has access rights to the submitted file; returning a credential corresponding to the submitted file to the author account through the blockchain network, and sending a notification message to the editor account indicating that the submitted file has been stored on the blockchain.

[0006] According to one aspect of the embodiments of this application, a blockchain-based file processing device is provided, comprising: a file input module configured to initiate a call to a first smart contract deployed on the blockchain through an author account, to input a submitted file and file-related information into the first smart contract; a file on-chain module configured to generate ciphertext corresponding to the submitted file in the first smart contract according to a first access policy, and store the ciphertext and the file-related information on the blockchain, wherein the first access policy includes that an editor account has access rights to the submitted file; and an information return module configured to return a credential corresponding to the submitted file to the author account through the blockchain network, and send a notification message to the editor account indicating that the submitted file has been stored on the blockchain.

[0007] According to one aspect of the embodiments of this application, a document submission system is provided, comprising: a blockchain network on which multiple smart contracts are deployed; a key management terminal for generating public parameters and a master key required for attribute encryption, and generating a private key for each business account based on the public parameters, the master key, and the identity attributes of each business account, wherein the business account includes at least one of author accounts, editor accounts, and review accounts; an author client, wherein an author account is logged in, which, by calling a first smart contract deployed on the blockchain, uploads the ciphertext corresponding to the submitted document and related document information to the blockchain, and obtains a certificate corresponding to the submitted document returned by the blockchain network, wherein the ciphertext corresponding to the submitted document is generated using the attribute encryption algorithm according to a first access strategy, the first access strategy including editor accounts with access rights to the submitted document; an editor client, wherein an editor account is logged in, which, by calling a second smart contract, obtains whether there is a target file on the blockchain with content similar to the submitted document, and obtains access rights to the target file by calling a third smart contract; and a review client, wherein a review account is logged in, which, after the editor client obtains that there is no target file on the blockchain with content similar to the submitted document, calls a fourth smart contract to review the submitted document.

[0008] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the blockchain-based file processing method as described above.

[0009] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the blockchain-based file processing method as described above.

[0010] According to one aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the blockchain-based file processing method described above.

[0011] In the technical solution provided in the embodiments of this application, the existence proof function of the submitted document is provided by combining blockchain technology with attribute encryption. Specifically, firstly, attribute encryption is used to generate the ciphertext corresponding to the submitted document according to the first access policy. Then, the ciphertext and document-related information are uploaded to the blockchain. It can be seen that the technical solution of this embodiment publicly discloses the ciphertext corresponding to the submitted document in the blockchain network. Since the first access policy includes the editor account having access rights to the submitted document, the editor account can successfully decrypt the ciphertext stored on the blockchain to obtain the original text. Other accounts not included in the second access policy cannot obtain the original document, which greatly reduces the possibility of the original document being leaked, thereby reducing the possibility of the document content being plagiarized.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0014] Figure 1 This is a schematic diagram illustrating the structure of a blockchain network in an exemplary embodiment;

[0015] Figure 2 This is a schematic diagram illustrating the application scenarios involved in the embodiments of this application;

[0016] Figure 3 This is a flowchart illustrating a blockchain-based file processing method in an exemplary embodiment of this application;

[0017] Figure 4 An exemplary process for file ownership confirmation based on blockchain and attribute encryption algorithms is revealed;

[0018] Figure 5 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application.

[0019] Figure 6This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application.

[0020] Figure 7 An exemplary process for detecting multiple submissions of a single document based on blockchain and attribute encryption algorithms is presented.

[0021] Figure 8 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application.

[0022] Figure 9 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application.

[0023] Figure 10 An exemplary process for document review functionality based on blockchain and attribute encryption algorithms is revealed;

[0024] Figure 11 This is a block diagram illustrating a blockchain-based file processing apparatus as an exemplary embodiment of this application;

[0025] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0028] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0029] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0030] First, it should be noted that the embodiments of this application involve blockchain technology. Blockchain technology is a novel distributed infrastructure and computing method that utilizes a block-chain data structure to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script code to program and manipulate data. Blockchain refers to a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like manner, enabling secure storage of sequentially related data that can be verified within the system, and using cryptography to ensure that the data is immutable and unforgeable. Simply put, blockchain is a decentralized distributed ledger, with each chain acting as an independent ledger.

[0031] Figure 1 This is a schematic diagram illustrating the structure of a blockchain network as shown in an exemplary embodiment. Figure 1 The blockchain network 100 shown may include node devices 10a, 10b, 10c, and 10d. Node devices 10a, 10b, 10c, and 10d are all... Figure 1 The blockchain nodes (referred to as nodes) in the blockchain network 100 shown can be any form of computing device connected to the blockchain network 100, such as servers, user terminals, etc. Figure 1 The node devices 10a, 10b, 10c, and 10d shown can also be connected to form a blockchain network 100 through network communication.

[0032] It should be understood that Figure 1 The nodes in the illustrated blockchain network architecture can form a peer-to-peer (P2P) network. The P2P protocol here can be an application layer protocol running on top of the Transmission Control Protocol (TCP). In the network architecture corresponding to blockchain network 100, any machine, such as a server or terminal, can join and become a node. A node can specifically include a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0033] Each node in blockchain network 100 can be used to maintain the same blockchain ledger (i.e. Figure 1 The blockchain ledger 10e shown can be used to pre-deploy multiple smart contracts. For example, it can pre-deploy agent contracts, permission management contracts, data contracts, agent management contracts, and other smart contracts with different data processing functions. It should be understood that a smart contract is also a computerized protocol that can execute the terms of a contract. This is achieved through code deployed on the blockchain ledger that executes when certain conditions are met, and the code is used to automate transactions based on actual business needs.

[0034] Understandably, in Figure 1 The blockchain network architecture shown includes three main types of blockchains: public blockchains, private blockchains, and consortium blockchains. The type of blockchain used may vary depending on the specific application scenario. A public blockchain is one that is publicly accessible, allowing anyone to join and access it. Blocks on a public blockchain can be viewed by anyone, and anyone can initiate transactions and participate in the consensus process. A private blockchain is used within a private organization, where read / write permissions and participation in record-keeping are determined according to the organization's rules; it is typically used for internal data management and auditing. A consortium blockchain allows members to define their read / write permissions and participation in record-keeping according to the consortium's rules; it is generally used for inter-institutional transactions, settlements, and clearing.

[0035] Based on the application scenarios involved in the embodiments of this application, the type of blockchain network involved in the embodiments of this application is specifically a consortium blockchain. Please refer to... Figure 2 , Figure 2 This is a schematic diagram of an application scenario involved in an embodiment of this application. The exemplary application scenario is a document submission system. The document submission system includes a key management terminal 210, an author client 220, an editor client 230, a review client 240, and a blockchain network 250. The documents submitted by the author client 220 are also called submission documents, which include, but are not limited to, articles, pictures, tables, and other file formats, and are not limited here.

[0036] First, it should be noted that Blockchain Network 250 is a consortium blockchain composed of document editors as blockchain nodes. In other words, the read and write permissions and the right to participate in accounting on the blockchain of document editors as consortium members are specified according to the consortium rules among the members, and this document does not impose any restrictions on this. Multiple smart contracts with different data processing functions are pre-deployed on the blockchain. The first smart contract, also known as the Confirmation Smart Contract (CSC), receives the submission file and related information sent by the author client 220, uploads the file to the blockchain according to the rules, and returns a certificate of submission to the author client 220. The second smart contract, also known as the Detection Smart Contract (DSC), is used to detect multiple submissions of the same manuscript. When the editing client 230 calls this contract, it returns the file information of target files with similar content. The third smart contract, also known as the Authority Smart Contract (ASC), mainly contains the logic related to file permission management. The fourth smart contract, also known as the Review Smart Contract (RSC), mainly contains the logic related to paper review.

[0037] The key management terminal 210, also known as the Key Management Center (KMC), is used to provide encryption keys to the blockchain network 250 and to offer services such as backup, archiving, recovery, and updating of these keys. For example, the key management terminal generates the public parameter pk and master key msk required for attribute encryption, and generates a private key for each business account based on the public parameter pk, master key msk, and the identity attribute S of each business account. This can be represented by the formula KeyGen(pk, msk, S), where KeyGen represents the algorithm part of the attribute encryption algorithm that generates the private key. The private key is then sent to the corresponding business account, and the public parameter and master key are simultaneously published in the blockchain network 250. Business accounts include, for example, at least one of the following: author accounts logged in on author client 220, editor accounts logged in on editor client 230, and reviewer accounts logged in on reviewer client 240.

[0038] The public parameters and master key of the attribute encryption algorithm can be obtained by the formula Stetup(λ,U), where Stetup represents the part of the attribute encryption algorithm used to generate the public parameters and master key, λ represents the security parameters preset for the attribute encryption algorithm, and U represents the total set of attributes preset for the attribute encryption algorithm.

[0039] Author client 220 has the ability to communicate with blockchain network 250. For example, since blockchain network 250 is a consortium blockchain network composed of document editors as blockchain nodes, author client 220 can communicate with these blockchain nodes to submit documents to the document editors corresponding to the blockchain nodes. Specifically, author client 220 calls the first smart contract deployed on the blockchain to upload the encrypted text and document-related information of the submitted document to the blockchain and obtains the corresponding certificate for the submitted document returned by blockchain network 250. In the event of subsequent plagiarism, this certificate can provide the document author with proof of the existence of the submitted document, thus realizing the document ownership confirmation function.

[0040] The editing client 230 obtains information about the existence of a target file on the blockchain that is similar in content to the file submitted by the author client 220 by calling a second smart contract deployed on the blockchain. It also obtains access rights to the target file by calling a third smart contract deployed on the blockchain. This allows the editing client 230 to obtain the original content of the target file. Furthermore, by comparing the content of the file submitted by the author client 220, it determines whether the file submitted by the author client 220 has been submitted to multiple journals or plagiarized.

[0041] After the editing client 230 obtains that there is no target file on the blockchain that is similar to the file submitted by the client 220, the review client 240 calls the fourth smart contract to review the content of the file submitted by the client 220 and puts the review result on the blockchain.

[0042] Figure 2 The application scenario shown can be specifically implemented as a paper submission scenario. Specifically, the blockchain network 250 consists of journal editors as blockchain nodes. The author account logged into the author client 220 is the account of the author whose paper is to be published. The author submits the paper to one of the blockchain nodes in the blockchain network 250. The editor account logged into the editor client 230 is operated by staff of the journal editorial staff who received the submission. This performs checks for multiple submissions and plagiarism, completing basic formal checks before publication. Afterwards, the review client 250 further reviews the content of the submitted paper. Typically, after the paper review is completed, journal publication and other operations can proceed, depending on the specific application requirements.

[0043] Figure 2The application scenario shown can also be implemented as an assignment submission and grading scenario. Specifically, the author client 220 submits the assignment file to the blockchain network 250 for approval, and the editor client 230 checks the assignment file for multiple submissions and plagiarism. Then, the review client further reviews and scores the assignment file. In this application scenario, the blockchain network 250 can be composed of teacher clients as blockchain nodes. The editor account logged in in the editor client 230 is specifically a teacher account, and the review account logged in in the review client 240 can be, for example, a teacher account with senior experience. This forms a scenario where the assignment file is first checked for basic format by a specific teacher, and then the content is reviewed and scored by a senior teacher, thus forming a scenario in which teachers participate in the assignment approval process. Alternatively, in this application scenario, the blockchain network 250 can also be composed of parent terminals as blockchain nodes, the editing account logged in in the editing client 230 is specifically a parent account, and the review account logged in in the review client 240 is a teacher account. Thus, the homework file is first checked by the parent in its basic form, and then the teacher reviews and scores the homework content, thus forming a scenario in which parents and teachers jointly participate in the homework approval process.

[0044] It should also be noted that, Figure 2 The detailed processing flow involved in the application scenarios shown can be found in the embodiments described later, and will not be repeated here. It is understood that... Figure 2 In the application scenario shown, author client 220 executes the steps performed by the author account as described in the following embodiments, editor client 230 executes the steps performed by the editor account as described in the following embodiments, and review client 240 executes the target as described in the following embodiments, performed by the target review account.

[0045] It should also be noted that, Figure 2 The application scenarios shown can also be implemented in other scenarios besides the aforementioned paper submission and homework grading scenarios, depending on actual needs. This document does not impose any restrictions on this.

[0046] Please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based file processing method as an exemplary embodiment of this application. This method can be applied to... Figure 2 The illustrated embodiment shows the application scenario, therefore Figure 2 The descriptions in the application scenarios shown also apply to the methods mentioned in this embodiment. For example... Figure 3 As shown, the method includes at least steps S310 to S330, which are described in detail below:

[0047] Step S310: Initiate a call to the first smart contract deployed on the blockchain through the author's account to pass the submitted document and related document information into the first smart contract.

[0048] First, it should be noted that the submission files passed to the first smart contract through the author account in this embodiment include, but are not limited to, articles, images, tables, and other file formats. File-related information refers to information describing the attributes of the submission files, such as file name, author list, etc.

[0049] The first smart contract, also known as the file ownership confirmation smart contract, is used to implement the ownership confirmation function for files submitted by the author's account. The author's account calls the first smart contract to pass in the submitted file and related information. The first smart contract encrypts the submitted file and uploads it to the blockchain, along with the related file information, to generate a certificate for the submitted file based on the file information.

[0050] Step S320: Generate the ciphertext corresponding to the submitted file in the first smart contract according to the first access policy, and store the ciphertext and file-related information on the blockchain. The first access policy includes that the editor account has access rights to the submitted file.

[0051] As mentioned earlier, smart contracts are program code deployed on a blockchain network. Therefore, smart contracts implement preset data processing functions by executing program code. The data processing functions implemented by the first smart contract include encrypting the submission file sent by the author's account and uploading it to the blockchain, while simultaneously returning the corresponding credential of the submission file to the author's account.

[0052] In this embodiment, the process of the first smart contract generating the ciphertext corresponding to the submission file is implemented through attribute encryption. Attribute encryption, also known as Attribute-Based Encryption (ABE), solves the security problem of sharing private data by reasonably configuring the sharing strategy. For example, a data owner needs to encrypt a plaintext file and send it to N different users. If using a traditional public-key encryption algorithm, the data owner needs to first save the public keys of these N users (without considering public key certificates), use these N different public keys to encrypt the plaintext file N times, forming N different ciphertexts, and then send them to the N users respectively. If using attribute encryption, the data owner only needs to define an access policy that only these N users can satisfy, then input the public parameters, the access policy, and the plaintext file into the attribute encryption algorithm for encryption once, forming a unique ciphertext. After obtaining the ciphertext, the data owner sends the ciphertext to the N different users, who can then decrypt the ciphertext to obtain the original file, while other users will find it difficult to decrypt the ciphertext. As can be seen, attribute encryption has a significant performance advantage over traditional public-key encryption, which is one of the reasons why attribute encryption is used to encrypt files in this embodiment.

[0053] It should also be mentioned that this embodiment has high requirements for the confidentiality of the file content. For example, in the case of paper submission, once the paper content is leaked, it will cause serious consequences of infringement of the author's copyright. Therefore, using attribute encryption to encrypt the file can minimize the possibility of the file being leaked after being uploaded to the blockchain.

[0054] In attribute-based encryption, policy and attributes are two important parameters. A policy is a logical expression composed of attributes and the relationships between them. In this embodiment, the first access policy used for attribute encryption includes granting access rights to the submitted file to editor accounts. These editor accounts can be designated by the author accounts, and there can be one or more designated editor accounts. After the submitted file is encrypted using attributes to obtain the corresponding ciphertext, these one or more editor accounts can decrypt the ciphertext to obtain the original text. Furthermore, the file's author should typically also have access rights to the submitted file. Therefore, the first access policy should also include granting access rights to the submitted file to the author account. If the submitted file has multiple authors, each author can have separate access rights to the submitted file. Therefore, only the editor accounts and author accounts included in the first access policy can successfully obtain the corresponding original text based on the ciphertext stored on the blockchain.

[0055] The process of generating the ciphertext corresponding to the submitted file can be represented by the formula Encrypt(pk,M,A), where Encrypt represents the algorithmic part of the attribute encryption algorithm used to calculate the ciphertext, pk represents the public parameters of the attribute encryption algorithm, M represents the plaintext of the submitted file, and A represents the first access strategy. After obtaining the ciphertext corresponding to the submitted file, the first smart contract stores the ciphertext and file-related information on the blockchain, thereby completing the on-chain operation of the submitted file.

[0056] It's also worth mentioning that in some exemplary application scenarios, the first smart contract needs to calculate the digest hash corresponding to the submitted file. For example, if the submitted file from the author's account contains a digest, the digest hash is obtained by hashing the digest. Conversely, if the submitted file from the author's account does not contain a digest, a digest can be extracted from the submitted file, and then the extracted digest can be hashed to obtain the digest hash. There are no restrictions on this. It can be seen that the digest hash can be associated with the content of the submitted file; therefore, the digest hash can also be used as information to prove the existence of the submitted file. Thus, the first smart contract also records the digest hash on the blockchain and uses it as information contained in the credentials of the submitted file.

[0057] Step S330: Return the credential corresponding to the submitted file to the author's account through the blockchain network, and send a notification message to the editor's account indicating that the submitted file has been stored on the blockchain.

[0058] Once the submitted document is uploaded to the blockchain, a certificate corresponding to the submitted document is returned to the author's account through the blockchain network. This certificate contains information such as the aforementioned paper-related information, abstract hash, upload time, blockchain height and block hash value where the data is stored. This information is used to prove the existence of the submitted document on the blockchain. In the event that the content of the submitted document is subsequently plagiarized, the author can use this certificate to prove their ownership of the document, thus providing the author with a strong proof of ownership and ensuring that the author's interests are not infringed.

[0059] The blockchain network also sends a notification message to the editor account included in the first access policy, indicating that the submitted document has been stored on the blockchain, so as to notify the relevant editor to perform subsequent processing on the submitted document. For details of the processing, please refer to the description in the following embodiments.

[0060] It should be understood that sending data to author and editor accounts via the blockchain network is specifically implemented by the corresponding blockchain nodes. Typically, the two operations are executed by the same blockchain node, specifically the blockchain account receiving the submitted file from the author account, since the personnel editing the submitted file usually belong to the file editor receiving the author's submission. However, this embodiment does not exclude the possibility that the two operations are executed by different blockchain nodes, which can be set according to actual application needs.

[0061] As can be seen from the above, the method provided in this embodiment uses blockchain technology combined with attribute encryption to provide proof of the existence of submitted documents. Specifically, firstly, attribute encryption is used to generate ciphertext corresponding to the submitted document according to the first access strategy. Then, the ciphertext and document-related information are uploaded to the blockchain. Compared with the prior art, the technical solution of this embodiment publicly discloses the ciphertext corresponding to the submitted document in the blockchain network. Since the first access strategy includes the editor account having access to the submitted document, the editor account can successfully decrypt the ciphertext stored on the blockchain to obtain the original document. Other accounts not included in the second access strategy cannot obtain the original document, which greatly reduces the possibility of the original document being leaked, thereby reducing the possibility of the document content being plagiarized.

[0062] Figure 3 The process involved in the example embodiments can be illustrated as follows: Figure 4 The illustrated application scenario for submitting documents (such as papers awaiting publication in journals) reveals an exemplary process for document ownership verification based on blockchain and attribute encryption algorithms. Figure 4 As shown, the author first calls the first smart contract to upload the submitted document to the blockchain for notarization. The author then receives a certificate of the submitted document returned by the blockchain network. In the event that the content of the submitted document is subsequently plagiarized, the author can use this certificate to prove that he / she owns the document. The blockchain network also sends a notification message to the journal editors who have access to the submitted document as included in the first access strategy, so as to notify the relevant editors about the author's submission and to carry out subsequent related processing of the submitted document.

[0063] Figure 5 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application. Figure 5 As shown, the method is in Figure 3 Based on the illustrated embodiment, steps S340 to S350 are further included after step S330, as detailed below:

[0064] Step S340: Based on the editing account, a call is initiated to the second smart contract deployed on the blockchain. The second smart contract detects whether there is a target file on the blockchain with content similar to the file.

[0065] As described above, after receiving a notification message from the blockchain network indicating that the file submitted by the author account has been stored on the blockchain, the editor account calls a second smart contract to detect whether there is a target file on the blockchain with similar content to the file, so as to detect multiple submissions and plagiarism of the file submitted by the author account.

[0066] For example, the process of detecting whether a target file with content similar to the submitted document exists on the blockchain in the second smart contract includes the following steps S341 to S343, which are described in detail below:

[0067] Step S341: Based on the public parameters of the attribute encryption algorithm and the private key of the editing account, decrypt the ciphertext corresponding to the submission file to obtain the original text of the submission file. Then, perform local sensitive hash operation on the original text to obtain the local sensitive hash value corresponding to the submission file.

[0068] Step S342: Obtain the local sensitive hash value corresponding to other files stored on the blockchain;

[0069] Step S343: Obtain the Hamming distance between the local sensitive hash values ​​of the two files. If the obtained Hamming distance is less than or equal to a preset threshold, then this other file is taken as the target file with content similar to the submitted file.

[0070] Locality Sensitive Hashing (LSH) is a special hash algorithm characterized by a high degree of similarity between the hash value calculated after modifying the original text semantically invariantly and the hash value of the original text before modification. Based on this characteristic, this embodiment uses it for file content similarity detection. Specifically, this embodiment can use the Sim Hash hash algorithm from the Locality Sensitive Hashing algorithm, and the specific method of Locality Sensitive Hashing is not limited here.

[0071] In step S341, the formula Decrypt(pk,sk',ct) is first used to obtain the plaintext corresponding to the ciphertext. Decrypt represents the decryption algorithm part of the attribute encryption algorithm, pk represents the public parameters of the attribute encryption algorithm, and sk' represents the private key of the editing account. This private key is generated in the key management server based on the public parameters of the attribute encryption algorithm, the master key, and the identity attributes of the editing account. For detailed process, please refer to [link to relevant documentation]. Figure 2 In the illustrated embodiment, ct represents the ciphertext corresponding to the submitted document. After obtaining the original text corresponding to the ciphertext, a locality-sensitive hash algorithm is used to calculate the locality-sensitive hash value corresponding to the submitted document.

[0072] In step S342, the local sensitive hash values ​​corresponding to other files stored on the blockchain are obtained in the same way, which will not be elaborated here.

[0073] In step S343, the Hamming distance refers to the number of bits that differ in the corresponding bits of two information codes, that is, the number of bits whose corresponding bit values ​​differ in two codewords. In this embodiment, the Hamming distance between the local sensitive hash value of the submitted file and the local sensitive hash values ​​of other files is obtained to determine the similarity between the two local sensitive hash values ​​based on the size of the Hamming distance, and then the content similarity between the submitted file and other files is characterized by the Hamming distance. The smaller the obtained Hamming distance, the higher the content similarity between the submitted file and other files. In this embodiment, specifically, the XOR calculation is performed on the corresponding bit values ​​of the two local sensitive hash values. When the values ​​of the two bits are different, the result is 1, and when the values ​​of the two bits are the same, the result is 0. Finally, the sum of the results corresponding to each bit is taken as the Hamming distance. If the obtained Hamming distance is less than or equal to a preset threshold, it can be determined that the content similarity between the submitted file and other files is high. Therefore, the content of the other files is similar to the content of the submitted file (that is, the file passed by the author's account and already on the chain). For example, the preset threshold mentioned in this embodiment can be determined to be 3 through experiments.

[0074] As can be seen from the above process, this embodiment obtains the similarity between original texts by comparing the similarity between ciphertexts. It achieves the detection of multiple submissions and plagiarism of submitted documents without leaking the original documents. This not only ensures the security of submitted documents, but also, due to the high semantic similarity between the ciphertext used for comparison and the original text, the method of detecting the similarity of document content in this embodiment is also highly effective.

[0075] In step S350, if the target file is detected, the file-related information corresponding to the target file is returned to the editing account through the blockchain network.

[0076] If a target file with content similar to the submitted document is detected on the blockchain in step S340, it indicates that the content of the submitted document may be plagiarized or plagiarized. The relevant information of the target file is sent to the editor's account through the blockchain network to provide an early warning to the editor using the editor's account.

[0077] As can be seen, this embodiment executes the detection process of target files with content similar to the submitted files by setting a second smart contract on the blockchain. In the editing client where the editing account is located, only a call to the second smart contract is needed, which makes the operation in the editing client very convenient and can improve the user experience of peripheral personnel.

[0078] Figure 6 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application. Figure 6 As shown, the method is in Figure 3 Based on the illustrated embodiment, steps S360 to S390 are further included after step S350, as detailed below:

[0079] Step S360: In the editing account, initiate a call to the third smart contract deployed on the blockchain to request access to the target file.

[0080] The third-party smart contract is a smart contract deployed on the blockchain to manage file access permissions. After receiving the file-related information corresponding to the target file from the blockchain network, the editor's account needs to verify the content of the target file to determine whether the submitted file contains plagiarism or has been plagiarized. The editor needs to obtain the original text of the target file through the editing client, therefore, the editor's account needs to initiate a call to the third-party smart contract to request access permissions to the target file.

[0081] Step S370: Send a notification message via the blockchain network to the author account corresponding to the target file, instructing the editor account to request access to the target file.

[0082] Granting access to a target file to an editor account requires permission from the author account corresponding to the target file. In other words, granting access to a target file is contingent upon obtaining permission from the target file's author. A notification message is sent to the author account corresponding to the target file via the blockchain network, instructing the editor account to request permission from the author account of the target file.

[0083] Step S380: In the author account corresponding to the target file, a third smart contract is invoked to update the ciphertext corresponding to the target file stored on the blockchain.

[0084] The author account corresponding to the target file calls a third-party smart contract to update the ciphertext of the target file stored on the blockchain. The updated ciphertext can then be decrypted by the editing account to obtain the original text, thereby granting the editing account access to the target file.

[0085] The process of updating the ciphertext corresponding to the target file stored on the blockchain through a third-party smart contract may include the following steps S381 to S382, which are described in detail below:

[0086] Step S381: In the third smart contract, the ciphertext corresponding to the target file is regenerated according to the updated second access policy. The updated second access policy adds access permissions for the editing account to the target file.

[0087] Step S382: Pass the ciphertext corresponding to the updated target file into the first smart contract, so that the ciphertext corresponding to the updated target file can be stored on the blockchain through the first smart contract.

[0088] Referring to the ciphertext generation process of the submitted document, in step S381, during the process of regenerating the ciphertext corresponding to the target file according to the updated second access policy, the parameters required for ciphertext update are first obtained. These parameters include the public parameter pk of the attribute encryption algorithm, the encrypted information Einfo(M') obtained during the initial generation of the ciphertext corresponding to the target file, the second access policy B used during the initial generation of the ciphertext ct' corresponding to the target file, the updated second access policy B', and the ciphertext M' corresponding to the target file. Then, the attribute encryption algorithm is used to regenerate the ciphertext corresponding to the target file based on these parameters. Since the updated second access policy B' adds access permissions for the editor account to the target file, the updated ciphertext corresponding to the target file can be decrypted by the editor account to obtain the original text.

[0089] For example, the process of regenerating the ciphertext corresponding to the target file described above can be represented by the formula CtUpdate(pk,Einfo(M'),B,B',ct'), where CtUpdate represents the algorithm part of the attribute encryption algorithm used to update the ciphertext of the already chained file.

[0090] Step S390: A notification message indicating that access permission authorization has been completed is returned to the editing account via the blockchain network.

[0091] As can be seen from the above, the editing account can decrypt the ciphertext of the updated target file on the blockchain to obtain the original text of the target file. This means that access permissions to the target file have been granted to the editing account. A notification message indicating the completion of access permission authorization is returned to the editing account through the blockchain network, prompting the relevant editor to begin verifying the content of the target file. It can be seen that the method provided in this embodiment does not leak the original text of the file even during the process of adding access permissions, thus fully ensuring the security of the file content.

[0092] Figure 6 The process involved in the example embodiments can be illustrated as follows: Figure 7 The illustrated application scenario for submitting documents (such as papers awaiting publication in journals) reveals an exemplary process for detecting multiple submissions of the same document based on blockchain and attribute encryption algorithms. Figure 7As shown, the journal editor first invokes a second smart contract to perform a multiple submission check on the submitted manuscript. If a target file with high content similarity to the submitted manuscript is detected, the blockchain network returns relevant information about the target file to the journal editor. The journal editor then invokes a third smart contract to request access to the target file, and the blockchain network notifies the target file's author of this authorization request. The target file's author then invokes the third smart contract to grant the journal editor access to the target file. As mentioned earlier, granting access to the target file to the journal editor is also the process of updating the encrypted text of the target file stored on the blockchain. After authorization is completed, the blockchain network returns a notification message to the journal editor to inform them of the authorization result.

[0093] Figure 8 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application. Figure 8 As shown, the method is in Figure 6 Based on the illustrated embodiment, steps S400 to S440 are further included after step S390, as detailed below:

[0094] Step S400: Initiate a call to the fourth smart contract deployed on the blockchain in the editing account, and upload the introductory information of at least one candidate review account selected by the editing account to the chain.

[0095] After gaining access to the target file, the editor account reviews the original text to determine if the submitted paper is plagiarized or has been plagiarized, and then initiates the review process. The fourth smart contract is used to implement the document review function. Therefore, by calling the fourth smart contract, the editor account can upload the information of at least one candidate reviewer account selected by the editor account to the blockchain. This uploaded candidate reviewer account is then used by the authors of the submitted paper for further selection, thereby increasing the authors' control over the selection of reviewers.

[0096] Candidate reviewer accounts can be understood as the account information of reviewers selected by the editors and chosen by the authors of the submitted manuscripts. The description of each reviewer account includes information about the reviewer, such as their anonymity and research interests. Anonymity information includes details like their affiliation, education, and age. It is understood that when the anonymity of reviewers is used in specific products or technologies, permission or consent from the relevant reviewer account is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0097] Step S410: Send a notification message via the blockchain network to the author's account, instructing them to select a review account.

[0098] In this embodiment, a notification message is sent to the author's account via a blockchain network to instruct the author to select a review account from at least one candidate review account. The reviewer corresponding to the target review account will then review the submitted manuscript.

[0099] Step S420: In the author account, the fourth smart contract is invoked to enable the author account to obtain introductory information of at least one candidate review account, and to select a target review account from the at least one candidate review account. The third smart contract is invoked to regenerate the ciphertext of the submission document based on the target review account.

[0100] The author account calls the fourth smart contract to obtain the introduction information of at least one candidate review account. The author of the submitted paper can then select a target review account based on the introduction information of the candidate review accounts. The selection of the target review account is equivalent to the author granting the target review account access to the submitted paper. The author account also calls the third smart contract to regenerate the encrypted text of the submitted paper based on the target review account.

[0101] The process of regenerating the ciphertext of the submission file can be represented by the formula CtUpdate(pk,Einfo(M),A,A',ct), where CtUpdate represents the algorithm part of the attribute encryption algorithm used to update the ciphertext of the already chained file, pk represents the public parameters of the attribute encryption algorithm, Einfo(M) represents the encrypted information obtained during the initial generation of the ciphertext corresponding to the submission file, ct represents the ciphertext of the initially generated submission file, A represents the first access policy used to generate the ciphertext ct, and A' represents the updated first access policy. It should be noted that the updated first access policy includes the target reviewer's access permissions to the submission file.

[0102] In some embodiments, there may be a need for different components of the same submission to be reviewed by different reviewers. For example, the submission may contain knowledge in four technical fields, each requiring review by an expert in that field. In this case, different components should be associated with corresponding content tags. The author account selects a target reviewer for each component by invoking the description information of at least one candidate reviewer account obtained from a fourth smart contract, and then maps the selected target reviewer account to the tag of the corresponding component. Furthermore, during the process of regenerating the encrypted submission, the updated first access policy used to generate the encrypted text must include permission constraints for the different components of the submission.

[0103] Step S430: In the third smart contract, the first smart contract is called to put the encrypted text of the regenerated submission file on the blockchain.

[0104] By calling the first smart contract from the third smart contract, the encrypted regenerated submission file is uploaded to the blockchain. This grants access to the submission file to the target review account, or grants access to a combination of parts of the submission file. Understandably, the target review account can use its private key to decrypt the encrypted regenerated submission file to obtain the original text, or use its private key to decrypt the parts of the encrypted file that it needs to review to obtain the corresponding original text. However, the target review account cannot view the original text of parts it does not have viewing permissions for, further ensuring the security of the submission file content.

[0105] Step S440: Send a notification message via the blockchain network to the target review account, instructing the submission to be reviewed.

[0106] The blockchain network sends a notification message to the target review account, instructing the reviewer to initiate a review of the submitted document or a component thereof.

[0107] If, after receiving a notification message instructing the target review account to review a submitted document, the reviewer operating the target review account deems themselves incapable of performing the review task, they can initiate a call to the fourth smart contract from within the target review account. This call will upload the introductory information of at least one candidate review account selected by the target review account to the blockchain. Then, a new target review account will be determined by executing the same process described in steps S410 to S440. Alternatively, the target review account can send a notification message to the editor account indicating its inability to participate in the review, allowing the editor account to reselect at least one candidate review account for the author account to choose from. The detailed process will not be elaborated upon here.

[0108] Based on the above description, it can be concluded that the method provided in this embodiment increases the author's controllability in selecting reviewers for submitted documents through attribute encryption algorithms. The authors of the submitted documents can select reviewers who are more suitable for reviewing the submitted documents from among the reviewers initially selected by the editor's account, thereby increasing the reliability of the document review process.

[0109] Figure 9 This is a flowchart illustrating a blockchain-based file processing method, as shown in another exemplary embodiment of this application. Figure 9 As shown, the method is in Figure 8 Based on the illustrated embodiment, steps S450 to S490 are further included after step S440, as detailed below:

[0110] Step S450: In the target review account, the fourth smart contract is invoked to enable the target review account to obtain the content of the submission file and review the content of the submission file. After the review is completed, the original text corresponding to the submission file and the review result are signed to obtain the signature information.

[0111] To enable the target review account to review the content of the submitted document, a fourth smart contract needs to be invoked within the target review account to obtain the content of the submitted document. The target review account reviews the content of the submitted document, and upon completion, signs the original text of the submitted document and the review result to obtain signature information.

[0112] The review results correspond to the review process information of the target reviewer account for the submitted document. For example, if no modifications to the original text of the submitted document are involved, the review results may include comments entered by the target reviewer account, a score for the submitted document, or suggestions for modification. In other embodiments, the review results also include modifications to the submitted document, specifically the modified original text and the modified content.

[0113] Since modifications to data on the blockchain also require consensus within the blockchain network, they lack portability in terms of process and resource data efficiency. In one embodiment, if the target review account is involved in the original text of the submitted document, the original text to be modified is downloaded to the target review account's local machine, and modifications are made based on the locally stored original text to obtain the review content.

[0114] In step S460, the fourth smart contract is invoked again to upload the review results and signature information to the blockchain.

[0115] The target review account calls the fourth smart contract again to upload the review results and signature information to the blockchain, so as to publish the target review account's review results of the submitted documents on the blockchain network.

[0116] In some embodiments, the target review account can also set viewing permissions for the review results. Generally, author and editor accounts should have viewing permissions for the review results. When the review results and signature information are uploaded to the blockchain, the data to be uploaded is still encrypted using attribute encryption before the upload operation is performed. This allows the author account, editor account, or other accounts selected by the target review account (such as other target review accounts participating in the review) to view the original review results on the blockchain. This will not be elaborated further here. In other words, although the review results are published on the blockchain, what is actually published is encrypted text. Only accounts with viewing permissions can obtain the original review results, further ensuring that the review results are not leaked.

[0117] Step S470: Send a notification message to the editing account via the blockchain network indicating that the target review account has completed the review.

[0118] The blockchain network sends a notification message to the editor account indicating that the target review account has completed the review, thereby informing the editor account of the review results for the target review account.

[0119] In step S480, if the editor account determines that the review of the submitted document has been completed based on the received notification message, the final review result is uploaded to the blockchain by calling the fourth smart contract.

[0120] If the editor account determines that it has completed the review of the submitted document based on the received notification message, it means that the content of the submitted document has passed the unanimous review of the target review account. Therefore, the editor account puts the final review result on the blockchain by calling the fourth smart contract. The final review result means that the content of the submitted document has passed the unanimous review of the target review account.

[0121] It should be noted that the editor account's determination that the review of the submitted document has been completed can be achieved by the editor account receiving a notification message indicating that all target review accounts have passed the review of the submitted document. For example, all target review accounts' comments contain information indicating that the review has been passed, or the target review accounts' scores for the submitted document all exceed a preset score threshold. Alternatively, the editor account's determination that the review of the submitted document has been completed can also be achieved by the editor account determining, based on the received notification message, that the ratio between the target review accounts whose review results for the submitted document are passed and the total number of target review accounts is greater than a preset ratio threshold. Or, the editor account's determination that the review of the submitted document has been completed can also be achieved by the editor account's modification of the submitted document not exceeding a preset level. The modification level can be represented by the ratio between the modified length and the original length. In scenarios where different target review accounts only review one or more components of the submitted document, the original length should include the evaluation of the components in the original text of the submitted document that the target review accounts have viewing permissions for. Specific details can be determined according to actual application requirements, and this embodiment does not impose any limitations here.

[0122] Step S490: Send a notification message to the author's account via the blockchain network that the submitted document has been reviewed.

[0123] By sending notification messages to author accounts via the blockchain network indicating that their submitted manuscripts have completed the review process, authors can promptly receive the review results for their submitted papers. In a paper submission scenario, once the editor's account confirms that the review of the submitted manuscript has been completed, it can proceed with actions such as publication. The author's account, upon receiving the notification message that the review of the submitted manuscript has been completed, is informed that the manuscript has been reviewed and will subsequently be published, thus concluding the entire paper submission process.

[0124] If the review results involve modifications to the original submitted document, the author, upon receiving a notification message from the blockchain network, obtains the review results from the target review account by invoking a fourth smart contract. Based on these review results, the author recognizes the problems in the submitted document and, after making corrections, can resubmit the revised document through the review process described in the above embodiments until the review results do not modify the document content. If the editing account determines that the submitted document to be processed is a historical document, the processes of multiple submissions, similarity detection, and selection of target review accounts can be omitted. The editing account can directly initiate the review of the current submission by the corresponding target review account, thus saving processing resources required for the process.

[0125] As can be seen from the above process, the method provided in this embodiment further refines the review process for the review results of submitted documents. In this process, both editors and authors of submitted documents can participate and keep abreast of the review progress, providing a better user experience for both editors and authors.

[0126] Figure 9 The process involved in the example embodiments can be illustrated as follows: Figure 10 The illustrated application scenario for submitting documents (such as papers awaiting publication in journals) reveals an exemplary process for document review functionality based on blockchain and attribute encryption algorithms. Figure 10 As shown, the journal editor first invokes the fourth smart contract to recommend candidate reviewers. Then, the blockchain network notifies the authors of the submitted manuscript to select reviewers. The authors can then use the fourth smart contract to confirm their selected reviewers. Subsequently, the blockchain network notifies the selected reviewers to review the submitted manuscript. Specifically, these reviewers invoke the fourth smart contract to upload the review results to the blockchain, and the blockchain network notifies the journal editor of the completion of the review. Finally, the journal editor invokes the fourth smart contract to upload the final review results to the blockchain.

[0127] Figure 11 This is a block diagram illustrating a blockchain-based file processing apparatus as an exemplary embodiment of this application. Figure 11 As shown, the device includes:

[0128] The file input module 510 is configured to initiate a call to the first smart contract deployed on the blockchain through the author account to input the submitted file and file-related information into the first smart contract; the file on-chain module 520 is configured to generate the ciphertext corresponding to the submitted file in the first smart contract according to the first access policy, and store the ciphertext and file-related information on the blockchain, wherein the first access policy includes the editor account having access rights to the submitted file; the information return module 530 is configured to return the credential corresponding to the submitted file to the author account through the blockchain network, and send a notification message to the editor account indicating that the submitted file has been stored on the blockchain.

[0129] The above device provides proof of the existence of submitted documents by combining blockchain technology with attribute encryption. Specifically, it first generates ciphertext corresponding to the submitted document using attribute encryption according to a first access policy, and then uploads the ciphertext and document-related information to the blockchain. As can be seen, the technical solution of this embodiment publicly discloses the ciphertext corresponding to the submitted document in the blockchain network. Since the first access policy includes access to the submitted document by the editor account, the editor account can successfully decrypt the ciphertext stored on the blockchain to obtain the original document. Other accounts not included in the second access policy cannot obtain the original document, which greatly reduces the possibility of the original document being leaked, thereby reducing the possibility of document content being plagiarized.

[0130] In another exemplary embodiment, the device further includes:

[0131] The content monitoring module is configured to initiate a call to a second smart contract deployed on the blockchain based on the editor's account. The second smart contract detects whether there is a target file on the blockchain with content similar to the submitted document. If a target file is detected, the module returns the file-related information corresponding to the target file to the editor's account through the blockchain network.

[0132] In another exemplary embodiment, the algorithm used to generate the ciphertext corresponding to the submission file includes an attribute encryption algorithm; the content monitoring module includes:

[0133] The first hash calculation unit is configured to decrypt the ciphertext corresponding to the submitted file to obtain the original text of the submitted file based on the public parameters of the attribute encryption algorithm and the private key of the editing account, and obtain the local sensitive hash value corresponding to the submitted file by performing a local sensitive hash operation on the original text; the second hash calculation unit is configured to obtain the local sensitive hash values ​​corresponding to other files stored on the blockchain; the hash comparison unit is configured to obtain the Hamming distance between the local sensitive hash values ​​of the two files, and if the Hamming distance is less than or equal to a preset threshold, the other files are regarded as target files with similar content to the submitted file.

[0134] In another exemplary embodiment, the device further includes:

[0135] The first parameter generation module is configured to generate public parameters and a master key for the attribute encryption algorithm on the key management server; the second parameter generation module is configured to generate a private key for each business account based on the public parameters, the master key, and the identity attributes of each business account, including the editing account; the parameter processing module is configured to publish the public parameters and the master key, and send the corresponding private key to each business account.

[0136] In another exemplary embodiment, the device further includes:

[0137] The permission request module is configured to initiate a call to a third-party smart contract deployed on the blockchain from the editor's account to request access to the target file; the access notification module is configured to send a notification message to the author's account corresponding to the target file via the blockchain network, instructing the editor's account to request access to the target file; the ciphertext update module is configured to call the third-party smart contract from the author's account corresponding to the target file to update the ciphertext of the target file stored on the blockchain via the third-party smart contract; and the authorization notification module is configured to return a notification message to the editor's account via the blockchain network, indicating that the access permission authorization has been completed.

[0138] In another exemplary embodiment, the ciphertext update module includes:

[0139] The new ciphertext generation unit is configured to regenerate the ciphertext corresponding to the target file in the third smart contract according to the updated second access policy. The updated second access policy adds access permissions for the editing account to the target file. The new ciphertext on-chain unit is configured to pass the updated ciphertext corresponding to the target file into the first smart contract so that the updated ciphertext corresponding to the target file can be stored on the blockchain through the first smart contract.

[0140] In another exemplary embodiment, the new ciphertext generation unit includes:

[0141] The parameter acquisition subunit is configured to acquire the parameters required for ciphertext updates. The parameters include the public parameters of the attribute encryption algorithm, the encryption information obtained during the initial generation of the ciphertext corresponding to the target file, the second access strategy used during the initial generation of the ciphertext corresponding to the target file, the updated second access strategy, and the ciphertext corresponding to the target file. The ciphertext regeneration subunit is configured to regenerate the ciphertext corresponding to the target file using the attribute encryption algorithm based on the parameters.

[0142] In another exemplary embodiment, the device further includes:

[0143] The review candidate module is configured to initiate a call to a fourth smart contract deployed on the blockchain from the editor's account, and upload the introductory information of at least one candidate review account selected by the editor's account to the blockchain; the review selection notification module is configured to send a notification message to the author's account via the blockchain network to instruct the selection of a review account; the review selection module is configured to call the fourth smart contract in the author's account to enable the author's account to obtain the introductory information of at least one candidate review account, and select a target review account from at least one candidate review account, and regenerate the ciphertext of the submission document based on the target review account by calling a third smart contract; the new ciphertext upload module is configured to call the first smart contract in the third smart contract to upload the ciphertext of the regenerated submission document to the blockchain; and the review notification module is configured to send a notification message to the target review account via the blockchain network to instruct the review of the submission document.

[0144] In another exemplary embodiment, the device further includes:

[0145] The review operation module is configured to call the fourth smart contract in the target review account so that the target review account can obtain the content of the submission file and review the content of the submission file. After the review is completed, the original text of the submission file and the review result are signed to obtain the signature information. The review on-chain module is configured to call the fourth smart contract again to upload the review result and signature information to the blockchain.

[0146] In another exemplary embodiment, the device further includes:

[0147] The review result notification module is configured to send a notification message to the editor account via the blockchain network indicating that the target review account has completed the review; the final review result on-chain module is configured to, if the editor account determines that the review of the submitted document has been completed based on the received notification message, then call the fourth smart contract to upload the final review result on the blockchain; the document author notification module is configured to send a notification message to the author account via the blockchain network indicating that the review of the submitted document has been completed.

[0148] It should be noted that the blockchain-based file processing device and the blockchain-based file processing method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the blockchain-based file processing device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0149] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain-based file processing method provided in the above embodiments.

[0150] Figure 12 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 12 The computer system 900 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0151] like Figure 12 As shown, the computer system 900 includes a Central Processing Unit (CPU) 901, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 902 or programs loaded from storage portion 908 into Random Access Memory (RAM) 903, such as performing the methods described in the above embodiments. The RAM 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An Input / Output (I / O) interface 905 is also connected to the bus 904.

[0152] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 910 as needed so that computer programs read from them can be installed into storage section 908 as needed.

[0153] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit (CPU) 901, it performs various functions defined in the system of this application.

[0154] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. Computer programs contained on computer-readable media can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0156] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0157] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the blockchain-based file processing method described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not incorporated into the electronic device.

[0158] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based file processing method provided in the various embodiments described above.

[0159] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A file processing method based on blockchain, characterized in that, include: The author's account initiates a call to the first smart contract deployed on the blockchain to pass the submitted document and related document information into the first smart contract; In the first smart contract, an attribute encryption algorithm is used to generate ciphertext corresponding to the submitted file according to a first access policy, and the ciphertext and the file-related information are stored on the blockchain. The first access policy includes that the editor account has access rights to the submitted file. The author's account is returned a certificate corresponding to the submitted file via the blockchain network, and a notification message indicating that the submitted file has been stored on the blockchain is sent to the editor's account. The editor initiates a call to a second smart contract deployed on the blockchain based on the editor's account, and the second smart contract detects whether there is a target file on the blockchain with content similar to the submitted file; If the target file is detected, the file-related information corresponding to the target file is returned to the editing account through the blockchain network; The editor initiates a call to a third smart contract deployed on the blockchain within the editing account to request access to the target file; A notification message is sent to the author account corresponding to the target file via the blockchain network, instructing the editor account to request access to the target file. The third smart contract is invoked in the author account corresponding to the target file to regenerate the ciphertext corresponding to the target file according to the updated second access policy. The updated second access policy adds the access permission of the editor account to the target file and passes the updated ciphertext corresponding to the target file to the first smart contract. The updated ciphertext corresponding to the target file is then stored on the blockchain through the first smart contract. A notification message indicating that access permission authorization has been completed is returned to the editing account via the blockchain network; After the editing account determines that the submitted document is not plagiarized or has been plagiarized by viewing the original text of the target document, it initiates a call to the fourth smart contract deployed on the blockchain to upload the introductory information of at least one candidate review account selected by the editing account to the chain. A notification message instructing the author's account to select a reviewer is sent via the blockchain network. The author's account of the submitted document invokes the fourth smart contract to obtain the introductory information of the at least one candidate reviewer account, selects a target reviewer account from the at least one candidate reviewer account, and regenerates the encrypted text of the submitted document based on the target reviewer account by invoking the third smart contract. The first smart contract is invoked in the third smart contract to upload the encrypted version of the regenerated submission file to the blockchain; A notification message instructing the target review account to review the submitted document is sent via the blockchain network.

2. The method according to claim 1, characterized in that, The step of detecting whether a target file with content similar to the submitted file exists on the blockchain in the second smart contract includes: Based on the public parameters of the attribute encryption algorithm and the private key of the editor account, the ciphertext corresponding to the submission file is decrypted to obtain the original text of the submission file. By performing a local sensitive hash operation on the original text, the local sensitive hash value corresponding to the submission file is obtained. Obtain the local sensitive hash values ​​corresponding to other files stored on the blockchain; Obtain the Hamming distance between the local sensitive hash values ​​of the two files. If the Hamming distance is less than or equal to a preset threshold, then the other files are considered as target files with content similar to the submitted file.

3. The method according to claim 1, characterized in that, Before initiating a call to the first smart contract deployed on the blockchain through the author's account to pass the submitted document and related document information to the first smart contract, the method further includes: The public parameters and master key of the attribute encryption algorithm are generated on the key management server. A private key for each business account is generated based on the public parameters, the master key, and the identity attributes of each business account, wherein the business account includes the editing account; The public parameters are disclosed, and the corresponding private key is sent to each business account.

4. The method according to claim 1, characterized in that, The step of regenerating the ciphertext corresponding to the target file in the third smart contract according to the updated second access policy includes: Obtain the parameters required for ciphertext update, including the public parameters of the attribute encryption algorithm, the encryption information obtained during the initial generation of the ciphertext corresponding to the target file, the second access strategy used during the initial generation of the ciphertext corresponding to the target file, the updated second access strategy, and the ciphertext corresponding to the target file; The attribute encryption algorithm is used to regenerate the ciphertext corresponding to the target file based on the parameters.

5. The method according to claim 1, characterized in that, After sending a notification message instructing the target review account to review the submitted document via a blockchain network, the method further includes: The fourth smart contract is invoked in the target review account to enable the target review account to obtain the content of the submission file and review the content of the submission file. After the review is completed, the original text and review result corresponding to the submission file are signed to obtain signature information. The fourth smart contract is invoked again to upload the review results and the signature information to the blockchain.

6. The method according to claim 5, characterized in that, After uploading the review results and the signature information to the blockchain, the method further includes: A notification message indicating that the target review account has completed the review is sent to the editing account via the blockchain network; If the editor account determines that it has completed the review of the submitted document based on the received notification message, it will put the final review result on the blockchain by calling the fourth smart contract; A notification message indicating that the submission has been reviewed is sent to the author's account corresponding to the submission via the blockchain network.

7. A blockchain-based file processing device, characterized in that, include: The file input module is configured to initiate a call to the first smart contract deployed on the blockchain through the author's account, so as to input the submitted file and file-related information into the first smart contract; The file-to-chain module is configured to use an attribute encryption algorithm in the first smart contract to generate ciphertext corresponding to the submitted file according to a first access strategy, and store the ciphertext and the file-related information on the blockchain. The first access strategy includes that the editor account has access rights to the submitted file. The information return module is configured to return the credential corresponding to the submitted file to the author's account via the blockchain network, and send a notification message to the editor's account indicating that the submitted file has been stored on the blockchain. The content monitoring module is configured to initiate a call to a second smart contract deployed on the blockchain from the editing account. The second smart contract detects whether there is a target file on the blockchain with content similar to the submitted file. If the target file is detected, the module returns file-related information corresponding to the target file to the editing account through the blockchain network. The permission request module is configured to initiate a call to a third smart contract deployed on the blockchain from the editing account in order to request access to the target file; The access notification module is configured to send a notification message via a blockchain network to the author account corresponding to the target file, instructing the editor account to apply for access to the target file. The ciphertext update module is configured to call the third smart contract in the author account corresponding to the target file, so as to regenerate the ciphertext corresponding to the target file in the third smart contract according to the updated second access policy. The updated second access policy adds the access permission of the editor account to the target file, and passes the updated ciphertext corresponding to the target file to the first smart contract. The updated ciphertext corresponding to the target file is then stored on the blockchain through the first smart contract. The authorization notification module is configured to return a notification message indicating that the access permission authorization has been completed to the editing account via a blockchain network; The review candidate module is configured to initiate a call to a fourth smart contract deployed on the blockchain from the editing account, and upload the introductory information of at least one candidate review account selected by the editing account to the blockchain; The review selection notification module is configured to send a notification message via a blockchain network to the author's account of the submitted document, instructing them to select a reviewer account. The review selection module is configured to, after the editing account determines that the submitted file does not contain plagiarism or have been plagiarized by viewing the original text of the target file, call the fourth smart contract to enable the author account of the submitted file to obtain the introduction information of the at least one candidate review account, select the target review account from the at least one candidate review account, and regenerate the encrypted text of the submitted file based on the target review account by calling the third smart contract. The new encrypted on-chain module is configured to call the first smart contract in the third smart contract to upload the encrypted version of the regenerated submission file to the blockchain. The review notification module is configured to send a notification message via a blockchain network to the target review account, instructing the submission to be reviewed.

8. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the blockchain-based file processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the blockchain-based file processing method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the blockchain-based file processing method as described in any one of claims 1 to 6.

Images