KR102456903B1 - System for managing electronic document using ethereum and IPFS and method thereof - Google Patents

Abstract

The present invention discloses a system for managing an electronic document using Ethereum and IPFS and a method therefor. That is, the present invention distribute-manages a file to be uploaded from a terminal through IPFS, provides reliability for the original file by storing a hash value of the relevant file distribute-managed through the IPFS in a block of Ethereum, and enables a problem of attacking or deleting for the original file to be solved through a private IPFS. Therefore, the present invention is capable of having an effect of improving operational efficiency.

Description

Electronic document management system using ethereum and IPFS and method thereof

The present invention relates to an electronic document management system and method using Ethereum and IPFS, and in particular, distributed management of a file to be uploaded from a terminal through IPFS, and a hash value of the file distributed and managed through IPFS, Ethereum It is to provide an electronic document management system and method using Ethereum and IPFS that are stored in blocks of

The electronic document management system is a system that electronically integrates and manages various types of documents and data in a consistent manner for efficient work, and supports registration, storage, management, transmission and reception, and inquiry of various electronic documents.

A blockchain is a data list in the form of dividing data into blocks and linking each block to each other in a loop to manage data to be managed in a distributed manner.

Although an electronic document management system applying such a block chain is being studied, the electronic document management system to which such block chain is applied stores the original file in a separate database and manages only the information of the file with block chain. As the file exists in the database, it cannot be freed from the framework of centralized management of the data itself, and if the original file is incapacitated by a DDoS attack, the system cannot operate normally even if the file information is managed with a block chain. .

In addition, if you want to block and store the original file directly, if you put the file in a block, the storage capacity increases exponentially as blocks are continuously created due to the nature of the block chain, and the speed is also slowed down, resulting in cost and physical limitations. It is difficult to maintain

Korean Patent Registration No. 10-1868029 [Title: Blockchain-based file sharing method and system]

An object of the present invention is an electronic document management system using Ethereum and IPFS that distributes and manages files to be uploaded from a terminal through IPFS, and stores the hash value of the file that is distributed and managed through IPFS in a block of Ethereum, and It's about providing a way.

Another object of the present invention is to use Ethereum and IPFS, which provide a file related to the hash value that is being distributed and managed through IPFS, so that the contents of the file can be checked when a hash value related to the file is input from the terminal. An object of the present invention is to provide an electronic document management system and a method therefor.

Another object of the present invention is when the terminal uploads a file for checking the authenticity of a hash value related to an original file and a file, whether the file is authentic by comparing the original file and the uploaded file through a POA consensus algorithm or a POW consensus algorithm It is to provide an electronic document management system and method using Ethereum and IPFS that provide

The electronic document management system using Ethereum and IPFS according to an embodiment of the present invention accesses a client server through MetaMask, displays an initial screen provided by the client server, and among the displayed initial screens , any one of a plurality of items included in the type selection menu in the initial screen is selected according to a user input, and any one of the one or more files stored in the terminal according to the file selection menu included in the initial screen is selected After being selected, when a preset upload menu included in the initial screen is selected, the terminal transmits the selected type information, the selected file, file upload request information, and identification information of the terminal to the client server; the client server transmitting the type information, the file, and identification information of the terminal to a specific IPFS randomly selected from among a plurality of IPFSs; and the specific IPFS for generating a hash value based on the type information and the file transmitted from the client server, and transmitting the generated hash value to the terminal via the client server.

An example related to the present invention further includes an Ethereum server, wherein the terminal includes a plurality of input items included in the additional information input menu in the initial screen according to a user input of the terminal among the initial screens displayed on the terminal. Receive a plurality of input values corresponding to , and when a preset submission menu displayed on one side of the initial screen of the terminal is selected, the received plurality of input values, block storage request information, and identification information of the terminal to the client transmitting to a server, wherein the client server transmits a plurality of input values transmitted from the terminal and identification information of the terminal to the Ethereum server, wherein the Ethereum server includes a plurality of input values transmitted from the client server stores in the Ethereum block, and transmits the transaction processing result to the client server, the client server transmits the transaction processing result to the terminal, and the terminal displays the transaction processing result transmitted from the client server can do.

An electronic document management method using Ethereum and IPFS according to an embodiment of the present invention includes the steps of connecting to a client server through a metamask by a terminal, and displaying an initial screen provided by the client server; Among the initial screens displayed on the terminal, any one of a plurality of items included in the type selection menu in the initial screen is selected according to a user input of the terminal, and according to the file selection menu included in the initial screen, the After any one of the one or more files stored in the terminal is selected, when a preset upload menu included in the initial screen is selected, by the terminal, the selected type information, the selected file, the file upload request information and the transmitting identification information of the terminal to the client server; transmitting, by the client server, the type information, the file, and identification information of the terminal to a specific IPFS randomly selected from among a plurality of IPFSs; generating a hash value based on the file and the type information transmitted from the client server by the specific IPFS, and transmitting the generated hash value to the terminal via the client server; and displaying, by the terminal, a hash value transmitted in response to the transmitted file upload request information.

As an example related to the present invention, based on the type information and the file transmitted from the client server by the specific IPFS, interworking with the remaining IPFS except for the specific IPFS among the plurality of IPFS, and distributing and storing the file may include more.

As an example related to the present invention, the displaying of the hash value may include automatically inputting the hash value into a hash value input item related to an additional information input menu in the initial screen and displaying the hash value.

As an example related to the present invention, among the initial screen displayed on the terminal by the terminal, a plurality of input values corresponding to a plurality of input items included in the additional information input menu in the initial screen according to a user input of the terminal receiving; When a preset submission menu displayed on one side of the initial screen of the terminal is selected, transmitting, by the terminal, the received plurality of input values, block storage request information, and identification information of the terminal to the client server ; transmitting, by the client server, a plurality of input values transmitted from the terminal and identification information of the terminal to an Ethereum server; storing, by the Ethereum server, a plurality of input values transmitted from the client server in an Ethereum block; transmitting, by the Ethereum server, a transaction processing result to the client server; transmitting, by the client server, the transaction processing result to the terminal; and displaying, by the terminal, a transaction processing result transmitted from the client server.

As an example related to the present invention, the step of storing the plurality of input values in an Ethereum block may include applying a POA (Proof of Authority) and a smart contract, which are preset consensus algorithm methods, to the plurality of input values. It can be stored in the Ethereum block.

As an example related to the present invention, from among the initial screens displayed on the terminal by the terminal, a user input hash value corresponding to a hash value input item included in the hash value input menu in the initial screen according to a user input of the terminal receiving; transmitting, by the terminal, the user input hash value, file search request information, and identification information of the terminal to the client server when a preset file view menu displayed on one side of the initial screen is selected; collecting, by the client server, a plurality of sub-files distributed and stored in one or more IPFSs in association with the user input hash value in association with the plurality of IPFS; generating, by the client server, a single original file corresponding to the user input hash value by combining the plurality of collected sub files; transmitting, by the client server, the generated original file to the terminal; and displaying or downloading, by the terminal, the original file transmitted from the client server.

As an example related to the present invention, among the initial screen displayed on the terminal, according to a user input of the terminal, another hash value corresponding to another hash value input item included in another hash value input menu in the initial screen is received, After any one specific file is selected from one or more files stored in the terminal according to the additional file selection menu in the initial screen, when the file authenticity check menu in the initial screen is selected, by the terminal, the received other transmitting a hash value, the selected specific file, authenticity check request information, and identification information of the terminal to the client server; transmitting, by the client server, the specific file and identification information of the terminal to another specific IPFS randomly selected from among a plurality of IPFSs; generating another hash value based on the specific file transmitted from the client server by the other specific IPFS, and transmitting the generated another hash value to the client server; receiving, by the client server, another hash value transmitted from the other specific IPFS; determining, by the client server, whether another hash value transmitted from the terminal matches another hash value transmitted from the other specific IPFS; generating, by the client server, information on whether a specific file is authentic or not according to the determination result, and transmitting information on whether the generated specific file is authentic or not to the terminal; and displaying, by the terminal, information on whether the specific file transmitted from the client server is authentic or not.

As an example related to the present invention, the information on whether the specific file is authentic or not is information indicating that another hash value related to the specific file and the specific file do not match the analysis target file corresponding to the other hash value Alternatively, it may include information indicating that the specific file matches the analysis target file.

The present invention distributes management of files to be uploaded from the terminal through IPFS, and stores the hash value of the file that is distributed and managed through IPFS in a block of Ethereum, thereby providing reliability for the original file, and providing reliability for the original file. The problem of attack or deletion has an effect that can be solved through private IPFS.

In addition, in the present invention, when a hash value related to a file is input from the terminal, the file related to the hash value that is being distributed and managed through IPFS is called and the contents of the file are provided so that the contents of the file can be checked, thereby improving the operational efficiency of the entire system There is an effect that can make it happen.

In addition, the present invention provides the authenticity or not through comparison between the original file and the uploaded file through the POA consensus algorithm or the POW consensus algorithm when the terminal uploads a hash value related to the original file and a file for checking the authenticity of the file. By doing so, there is an effect that maintenance is easy and network stability can be provided.

1 is a block diagram showing the configuration of an electronic document management system utilizing Ethereum and IPFS according to an embodiment of the present invention.
2 is a graph measuring the difference in speed until transaction completion according to the number of nodes in the Ethereum network using the POW algorithm according to an embodiment of the present invention.
3 is a graph measuring the difference in speed until transaction completion according to the number of nodes in the Ethereum network using the POA algorithm according to an embodiment of the present invention.
4 is a graph of measuring the time until transaction completion of POW and POA of three nodes after 60 hours have elapsed according to an embodiment of the present invention.
5 and 6 are graphs comparing upload speed and download speed by increasing the file size by 10 MB from 10 MB to 90 MB, respectively, in public IPFS and private IPFS according to an embodiment of the present invention.
7 and 8 are graphs converted into upload bytes and download bytes per 1 ms for each file size according to an embodiment of the present invention.
9 to 11 are flowcharts illustrating an electronic document management method using Ethereum and IPFS according to an embodiment of the present invention.
12 to 16 are diagrams showing examples of screens of a terminal according to an embodiment of the present invention.

It should be noted that the technical terms used in the present invention are only used to describe specific embodiments, and are not intended to limit the present invention. In addition, the technical terms used in the present invention should be interpreted as meanings generally understood by those of ordinary skill in the art to which the present invention belongs, unless otherwise defined in the present invention, and excessively comprehensive It should not be construed as a human meaning or in an excessively reduced meaning. In addition, when the technical term used in the present invention is an incorrect technical term that does not accurately express the spirit of the present invention, it should be understood by being replaced with a technical term that can be correctly understood by those skilled in the art. In addition, general terms used in the present invention should be interpreted as defined in advance or according to the context before and after, and should not be interpreted in an excessively reduced meaning.

Also, the singular expression used in the present invention includes the plural expression unless the context clearly dictates otherwise. In the present invention, terms such as "consisting of" or "comprising" should not be construed as necessarily including all of the various components or various steps described in the invention, and some components or some steps may not be included. It should be construed that it may further include additional components or steps.

Also, terms including ordinal numbers such as first, second, etc. used in the present invention may be used to describe the components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component.

Hereinafter, a preferred embodiment according to the present invention will be described in detail with reference to the accompanying drawings, but the same or similar components are given the same reference numerals regardless of the reference numerals, and the redundant description thereof will be omitted.

In addition, in the description of the present invention, if it is determined that a detailed description of a related known technology may obscure the gist of the present invention, the detailed description thereof will be omitted. In addition, it should be noted that the accompanying drawings are only for easy understanding of the spirit of the present invention, and should not be construed as limiting the spirit of the present invention by the accompanying drawings.

1 is a block diagram showing the configuration of an electronic document management system 10 utilizing Ethereum and IPFS according to an embodiment of the present invention.

As shown in FIG. 1 , the electronic document management system 10 using Ethereum and IPFS consists of a terminal 100 , a client server 200 , a plurality of IPFS 300 and an Ethereum server 400 . . Not all of the components of the electronic document management system 10 shown in FIG. 1 are essential components, and the electronic document management system 10 may be implemented by more components than the components shown in FIG. The electronic document management system 10 may be implemented with fewer components.

The terminal 100 includes a smart phone, a portable terminal, a mobile terminal, a foldable terminal, a personal digital assistant (PDA), and a portable multimedia (PMP). Player) terminal, telematics terminal, navigation terminal, personal computer, notebook computer, slate PC, tablet PC, ultrabook, wearable device Device, for example, watch-type terminal (Smartwatch), glass-type terminal (Smart Glass), HMD (Head Mounted Display), etc.), Wibro (Wibro) terminal, IPTV (Internet Protocol Television) terminal, smart TV, for digital broadcasting It can be applied to various terminals such as a terminal, an audio video navigation (AVN) terminal, an audio/video (A/V) system, a flexible terminal, and a digital signage device.

The client server 200, the plurality of IPFS 300, and the Ethereum server 400 may be implemented in the form of a web server, a database server, a proxy server, and the like. In addition, the client server 200, the plurality of IPFS 300 and the Ethereum server 400 have a network load balancing mechanism, or the corresponding client server 200, the plurality of IPFS 300 and the corresponding Ethereum. One or more of various software that enables the server 400 to operate on the Internet or other networks may be installed, and may be implemented as a computerized system through this. Also, the network may be an http network, and may be a private line, an intranet, or any other network. Furthermore, the connection between the terminal 100, the client server 200, the plurality of IPFS 300 and the Ethereum server 400 is secured so that data is not attacked by any hacker or other third party. It can be connected to a network. In addition, the client server 200 , the plurality of IPFS 300 , and the Ethereum server 400 may include a plurality of database servers, and these database servers are connected to any type of network including a distributed database server architecture. It may be implemented in such a way that it is separately connected to the client server 200 , the plurality of IPFS 300 , and the Ethereum server 400 through connection.

Each of the terminal 100, the client server 200, the plurality of IPFS 300 and the Ethereum server 400 includes a communication unit (not shown) for performing a communication function with other terminals, various information and A storage unit (not shown) for storing a program (or application), a display unit (not shown) for displaying various information and program execution results, and an audio output for outputting voice information corresponding to the various information and program execution results It may include a unit (not shown) and a controller (not shown) for controlling various components and functions of each terminal.

The terminal 100 communicates with the client server 200 , the plurality of IPFS 300 , the Ethereum server 400 , and the like. At this time, the terminal 100 stores the file being stored in the terminal 100 distributedly through the IPFS 300 , or stores the hash value and additional information in the Ethereum block through the Ethereum server 400 , or It may be a terminal possessed by a user who wants to check or download a file stored in the IPFS 300 using a value or check the authenticity of a specific file using a hash value.

In addition, the terminal 100, by interworking with the client server 200, a file upload function, hash value, additional information, etc. through a dedicated app and/or website provided by the game server 200 Ethereum Register as a member as a general user to receive a block storage function, a file check/download function corresponding to a hash value, and a function to check the authenticity of a specific file, and register personal information in the client server 200 . In this case, the personal information includes ID, email address, password (or password), name, gender, date of birth, contact information, address (or address information/residence area), and the like.

In addition, the terminal 100 may sign up as a user to the client server 200 by using the SNS account information or account information of a third-party site registered by the user of the terminal 100 . Here, the SNS account may be information related to Facebook, Twitter, Instagram, Kakao Story, Naver blog, and the like. In addition, the third-party account may be information related to YouTube, Kakao, Naver, and the like.

In addition, when performing the membership registration procedure, the terminal 100 must complete the authentication function through a self-authentication means (eg, including a mobile phone, credit card, i-PIN, etc.) to perform the membership registration procedure for the client server 200 can be completed normally.

In addition, after membership registration is completed, the terminal 100 is a dedicated app (or application/application program/specific app) provided from the client server 200 in order to use the service provided by the client server 200 . is installed in the corresponding terminal 100 . In this case, the dedicated app may be an app for performing a file upload function, a hash value, an Ethereum block storage function such as additional information, a file check/download function corresponding to the hash value, a function to check the authenticity of a specific file, and the like.

In addition, the terminal 100 joins as a general user to store information in the Ethereum block by interworking with the Ethereum server 400 , and registers personal information and the like in the Ethereum server 400 . In this case, the personal information includes ID, email address, password (or password), name, gender, date of birth, contact information, address (or address information/residence area), and the like.

In addition, the terminal 100 may sign up as a user to the Ethereum server 400 by using the SNS account information or account information of a third-party site registered by the user of the terminal 100 as a user. Here, the SNS account may be information related to Facebook, Twitter, Instagram, Kakao Story, Naver blog, and the like. In addition, the third-party account may be information related to YouTube, Kakao, Naver, and the like.

In addition, when performing the membership registration procedure, the terminal 100 must complete the authentication function through a self-authentication means (eg, mobile phone, credit card, i-Pin, etc.) to complete the membership registration procedure for the Ethereum server 400 can be completed normally.

In addition, after membership registration is completed, the terminal 100 uses an electronic wallet (or electronic wallet related account information) issued from the Ethereum server 400 in order to use the service provided by the Ethereum server 400 . ) is installed (or registered/stored) in the corresponding terminal 100 .

In addition, the terminal 100 accesses the client server 200 through a metamask and displays (or outputs) an initial screen provided by the client server 200 . Here, the initial screen is a type selection menu (or type selection item/button) for selecting the type of IPFS, which is public or private, in relation to the file to be uploaded to the IPFS 300 , IPFS 300 . File selection menu to select a file to be uploaded to IPFS (300), Upload menu to upload a file to IPFS 300 , an additional information input menu for entering hash values according to file upload, additional information related to files, etc., a submission menu for storing information entered through the additional information input menu in the Ethereum block, and display of transaction processing results a transaction result display menu (or transaction result display area) for A file view menu for searching a related file, a download menu for downloading a file searched according to a file search related to a corresponding hash value, a verification target file for checking the authenticity of a specific file according to a user input of the terminal 100, and Another hash value input menu for inputting a related verification target hash value, an additional file selection menu for selecting a specific file for which authenticity is to be checked, and for checking the authenticity of a specific file according to a user input of the terminal 100 and a file authenticity check menu, a fidelity result display menu (or a fidelity result display area) for displaying a file authenticity result result, and the like.

In an embodiment of the present invention, a menu for uploading a file to the IPFS 300 in the initial screen, a menu for storing information in an Ethereum block, a menu for searching and downloading a file corresponding to a hash value, a specific Although it is configured to display a menu for checking the authenticity of a file at a time, it is not limited thereto, and according to a designer's design, the initial screen is displayed by function (for example, through a plurality of taps). Upload tab, file view tab, file authenticity check tab, etc.) The user interface can also be configured by separating the corresponding menus.

In addition, among the initial screen displayed on the terminal 100, according to a user input (or user selection/touch/control) of the corresponding terminal 100, any one item (eg, For example, public, private, etc.) is selected, any one of the one or more files stored in the terminal 100 is selected according to the file selection menu, and then the preset upload menu is selected, the terminal ( 100) transmits the selected type information (including, for example, public, private, etc.), the selected file, file upload request information, identification information of the terminal 100, and the like to the client server 200 . Here, the identification information of the terminal 100 includes a mobile directory number (MDN), mobile IP, mobile MAC, subscriber identity module (Sim) card unique information, serial number, and the like. In this case, the upload menu may be activated when the type information and the file are selected in the terminal 100 while maintaining an inactive state by default.

In the embodiment of the present invention, it is mainly described that the terminal 100 transmits the file stored in the terminal 100 to the client server 200, but is not limited thereto, and the terminal 100 A specific electronic document according to a user selection of the corresponding terminal 100 among one or more electronic documents stored in the corresponding terminal 100 may be transmitted to the client server 200 . Here, the electronic document represents information that is created, transmitted, received, or stored in an electronic form by a system that classifies, organizes, selects, calculates and processes data using a computer.

In addition, the terminal 100 receives the hash value transmitted from the client server 200 in response to the previously transmitted type information, the file, the file upload request information, and the like.

In addition, the terminal 100 displays (or outputs) the received hash value. In this case, the terminal 100 may automatically input and display the received hash value in the hash value input item related to the additional information input menu in the initial screen.

In addition, among the initial screen displayed on the terminal 100 , a plurality of input items corresponding to a plurality of input items included in the additional information input menu according to a user input (or user selection/touch/control) of the terminal 100 are provided. receive input. Here, the plurality of input values include hash values and additional information (eg, author name, company name, department/team name, date, etc.).

In addition, when the preset submission menu displayed on one side of the initial screen of the terminal 100 is selected, the terminal 100 receives the plurality of input values, block storage request information, and It transmits identification information and the like to the client server 200 . In this case, the submission menu may be activated when a plurality of input values corresponding to a plurality of input items included in the additional information input menu are received from the terminal 100 while maintaining an inactive state by default.

In addition, the terminal 100 receives the transaction processing result transmitted from the client server 200 in response to the plurality of input values and the block storage request information transmitted previously.

In addition, the terminal 100 displays (or outputs) the received transaction processing result and the like. In this case, the terminal 100 may automatically display the received transaction processing result, etc. on the transaction result display menu in the initial screen.

In addition, among the initial screen displayed on the terminal 100, a user input corresponding to a hash value input item included in the hash value input menu according to a user input (or user selection/touch/control) of the terminal 100 Receive a hash value. Here, the user input hash value may be a hash value for the user of the terminal 100 to check the contents of a file corresponding to a specific hash value or to download a file corresponding to the specific hash value.

In addition, when the preset file view menu displayed on one side of the initial screen of the terminal 100 is selected, the terminal 100 displays the received user input hash value, file search request information, and the terminal 100 . and transmits the identification information of the client server 200 to the client server 200 . At this time, the file view menu maintains an inactive state by default and receives an input value (eg, including the user input hash value, etc.) corresponding to one or more items included in the hash value input menu in the terminal 100 . It can be activated if

In addition, the terminal 100 receives the original file transmitted from the client server 200 in response to the previously transmitted user input hash value, file search request information, and the like.

In addition, the terminal 100 displays (or outputs) the received original file. Here, the terminal 100 may download (or store) the received original file to the corresponding terminal 100 .

At this time, if the file related to the corresponding user input hash value does not exist in the IPFS 300 , the terminal 100 receives the previously transmitted user input hash value, file search request information, etc. from the client server 200 . Receives information indicating that the transmitted file related to the corresponding user input hash value does not exist in the IPFS 300, and acknowledges that the file related to the received user input hash value does not exist in the IPFS 300 It is also possible to display (or output) the indicated information or the like.

In addition, among the initial screen displayed on the terminal 100, according to a user input (or user selection/touch/control) of the terminal 100, the other hash value input items included in the other hash value input menu correspond to After receiving another hash value and selecting any one specific file from among one or more files stored in the terminal 100 according to the additional file selection menu, if the preset file authenticity check menu is selected, the terminal ( 100) transmits the received other hash value, the selected specific file, authenticity check request information, identification information of the terminal 100, and the like to the client server 200 . In this case, the file authenticity check menu may be activated when the specific file is selected after receiving the other hash value from the terminal 100 while maintaining the inactive state by default.

In addition, the terminal 100 receives information on the authenticity of the specific file transmitted from the client server 200 in response to the previously transmitted other hash value, the specific file, the authenticity check request information, etc. do.

In addition, the terminal 100 displays (or outputs) information on whether the received specific file is authentic or not. In this case, the terminal 100 may display information on whether the received specific file is authentic or not in the authenticity result display menu in the initial screen.

In an embodiment of the present invention, various functions (eg, file upload function, hash value, additional information, etc.) provided by the client server 200 in the form of a dedicated app or website in the terminal 100 are stored function, file check/download function corresponding to hash value, authenticity check function of a specific file, etc.) can be performed.

The client server 200 communicates with the terminal 100 , the plurality of IPFSs 300 , the Ethereum server 400 , and the like.

In addition, the client server 200 performs a membership registration procedure for a user such as the terminal 100 .

In addition, the client server 200 registers personal information related to a user of the terminal 100 and the like. In this case, the client server 200 may register (or manage) the corresponding personal information in a DB server (not shown).

In addition, the client server 200 performs a member management function for a user such as the terminal 100 .

In addition, the client server 200 is a dedicated app that provides a file upload function, a hash value, an Ethereum block storage function such as additional information, a file check/download function corresponding to the hash value, a function to check the authenticity of a specific file, etc. and/or provides a web site to the terminal 100 or the like.

In addition, the client server 200 provides a bulletin board function for announcements and events.

Also, when the terminal 100 accesses the client server 200 through a metamask, the client server 200 provides the initial screen to the terminal 100 .

In addition, the client server 200 receives type information (eg, including public, private, etc.) transmitted from the terminal 100 , the file, the file upload request information, identification information of the terminal 100 , and the like. do.

In addition, the client server 200 transmits the received type information, file, identification information of the terminal 100, etc. to a specific IPFS 300 randomly selected from among a plurality of IPFS 300 .

That is, the client server 200 selects the specific IPFS 300 randomly or in a preset manner from among a plurality of IPFS 300 interworking with the corresponding client server 200 .

In addition, the client server 200 transmits the received type information, the file, and identification information of the terminal 100 to the selected specific IPFS 300 .

In addition, the client server 200 receives a hash value (or a hash value related to the file) transmitted from the specific IPFS 300 , identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received hash value, etc. to the terminal 100 corresponding to the identification information of the corresponding terminal 100 .

In addition, the client server 200 receives the plurality of input values transmitted from the terminal 100 , the block storage request information, identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received plurality of input values, identification information of the terminal 100, and the like to the Ethereum server 400 .

In addition, the client server 200 receives the transaction processing result transmitted from the Ethereum server 400 , identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received transaction processing result, etc. to the terminal 100 corresponding to the identification information of the terminal 100 .

In addition, the client server 200 receives the user input hash value transmitted from the terminal 100 , the file search request information, identification information of the terminal 100 , and the like.

In addition, the client server 200 cooperates with the plurality of IPFS 300 to collect a plurality of sub files distributed and stored in one or more IPFS 300 in relation to the user input hash value. Here, when the original file is divided into plural, the sub-file indicates the individual file divided into plural.

In addition, the client server 200 generates one original file corresponding to the user input hash value by combining the plurality of collected sub files.

Also, the client server 200 transmits the generated original file (or a file/original file corresponding to the user input hash value) to the terminal 100 .

At this time, when the plurality of sub files related to the user input hash value are not collected due to the interworking between the client server 200 and the plurality of IPFS 300 , the client server 200 receives the user input hash value and Information indicating that a related file does not exist in the IPFS 300 may be transmitted to the terminal 100 .

In addition, the client server 200 receives the other hash value, the specific file, the authenticity check request information, the identification information of the terminal 100, and the like transmitted from the terminal 100 .

In addition, the client server 200 transmits the received specific file and identification information of the terminal 100 to another specific IPFS 300 randomly selected from among the plurality of IPFS 300 .

That is, the client server 200 selects the other specific IPFS 300 randomly or in a preset manner from among a plurality of IPFS 300 interworking with the corresponding client server 200 .

In addition, the client server 200 transmits the received specific file and identification information of the terminal 100 to the other selected specific IPFS 300 . At this time, when the type information is not included in the information transmitted from the terminal 100, the client server 200 provides other type information (eg, including a private item) preset by default. It may be transmitted to the other specific IPFS 300 together with a specific file, identification information of the terminal 100, and the like.

In addition, the client server 200 receives another hash value (or a hash value related to the specific file) transmitted from the other specific IPFS 300 , identification information of the terminal 100 , and the like.

Also, the client server 200 determines (or confirms) whether another hash value related to the received specific file matches another hash value previously received.

In addition, the client server 200 generates information on whether the specific file is authentic or not according to the determination result (or the verification result), and transmits information on whether the generated specific file is authentic or not to the terminal ( 100) to the Here, the information on the authenticity of the specific file is information indicating that the specific file does not match the analysis target file (or the analysis target file corresponding to the other hash value), and the specific file matches the analysis target file , and another hash value associated with that particular file.

The Inter Planetary File System (IPFS) 300 communicates with the terminal 100 , the client server 200 , the Ethereum server 400 , and the like. In this case, the IPFS 300 is configured in plurality, and the plurality of IPFS 300 is configured to interwork with each other. Here, the IPFS 300 is a protocol for sharing large files or data in a peer-to-peer (P2P) manner such as Napster or Torrent, and is a network for sharing and storing data in a distributed file system.

Also, the IPFS 300 identifies each file in a global namespace that connects all computer devices (not shown) using a content-address.

That is, the IPFS 300 is a method of exchanging objects in a Git repository like a single BitTorrent Swarm.

In addition, the IPFS 300 uses a distributed hash table, combines a self certifying namespace and an incentive block exchange method, and SPOF (Single Point of Failure) is Therefore, there is no need for trust between nodes as a result.

In addition, the IPFS 300 has a unique hash value that differs depending on the content of the data, and the content (or file/sub-file) distributed and stored in the plurality of IPFS 300 is found using this hash value, and the corresponding It can be provided by breaking the data into small pieces, fetching them at high speed, and merging them back into one. At this time, the hash table is stored as a pair (key, value), and since many distributed nodes store this information, the user can store and retrieve data at a faster speed than the HTTP method.

Also, the IPFS 300 selected from the client server 200 receives the type information, the file, and identification information of the terminal 100 transmitted from the client server 200 .

In addition, the specific IPFS 300 generates a hash value based on the received type information, the file, and the like.

In addition, the specific IPFS 300 transmits the generated hash value (or a hash value related to the file), identification information of the terminal 100, and the like to the client server 200 .

In addition, the specific IPFS 300 interworks with a plurality of other IPFS 300 (or the remaining IPFS 300 excluding the specific IPFS 300 among the plurality of IPFS 300) to distribute and store the file ( or management).

In addition, the plurality of IPFS 300 cooperates with the client server 200 to provide a plurality of sub files distributed and stored in one or more IPFS 300 in relation to the user input hash value to the client server 200, respectively. Provide (or transmit).

In addition, another specific IPFS 300 selected from the client server 200 receives the specific file, the other type information, and identification information of the terminal 100 transmitted from the client server 200 .

In addition, the other specific IPFS 300 generates another hash value based on the received specific file, the other type information, and the like. At this time, when the other specific IPFS 300 does not include type information among the information transmitted from the client server 200, other type information preset by default (eg, including a private item) and The other hash value may be generated based on the received specific file or the like.

In addition, the other specific IPFS 300 transmits the other generated hash value (or a hash value related to the specific file), identification information of the terminal 100, and the like to the client server 200 .

In addition, the other specific IPFS 300 interworks with another plurality of IPFS 300 (or the other IPFS 300 excluding the other specific IPFS 300 among the plurality of IPFS 300), and the specific file distributed storage (or management).

The Ethereum server (Ethereum Server) 400 communicates with the terminal 100 , the client server 200 , the plurality of IPFSs 300 , and the like. In this case, the Ethereum server 400 may be a server that provides an Ethereum block (or an Ethereum block chain). Here, the Ethereum is a distributed computing environment based on a public block chain, and may be open source software that can build applications with smart contracts.

In an embodiment of the present invention, the Ethereum server 400 may be configured as a public block chain and/or a private block chain, and may be configured as a private Ethereum block chain network to implement key features.

In addition, the Ethereum server 400 receives the plurality of input values transmitted from the client server 200 , identification information of the terminal 100 , and the like.

In addition, the Ethereum server 400 stores the received plurality of input values in an Ethereum block. At this time, the Ethereum server 400 includes a consensus algorithm method preset to the plurality of input values (for example, POA (Proof of Authority), POW (Proof of Work: Proof of Work), etc.), smart contract (smart contract) may be applied, and the received plurality of input values may be stored in the Ethereum block. Here, in the POA, as the determined management entity takes turns generating blocks (or registered accounts sequentially generate blocks), resource consumption and block generation time are shorter than those of the POW. At this time, the Ethereum server 400 may be configured as a private network to maintain speed and confidentiality. In addition, the smart contract is a promise placed on the block chain, and a code to take a specific action when a specific condition is satisfied is added to the transaction.

In addition, the Ethereum server 400 transmits the transaction processing result, identification information of the terminal 100, and the like to the client server 200 . Here, the transaction processing result (or Ethereum block storage result) includes a block hash value, a block number, receiver information (to), a transaction hash value, and the like.

In addition, for the performance test, the electronic document management system 10 using Ethereum and IPFS is the same AWS EC2AWS (Amazon Web Services Elastic Compute Cloud) specification Ubuntu Server 20.04 LTS, instance type t2.xlarge (4 vCPUs) , memory 16GB), and SSD 60Gb, directly installed and operated a private Ethereum network using geth.

The electronic document management system 10 using Ethereum and IPFS according to an embodiment of the present invention performed performance evaluation on which consensus algorithm among POW and POA is faster when constructing an Ethereum private network.

That is, the electronic document management system 10 using Ethereum and IPFS records the actual time difference from the time of the transaction request to the completion of the transaction in order to compare the performance of POW and POA when constructing the Ethereum private network. ) to output and measure. At this time, in order to check whether there is a significant performance difference according to the number of nodes, the POW and the POA are measured with 1 node, 3 nodes, and 6 nodes, respectively.

In addition, the electronic document management system 10 using Ethereum and IPFS is re-measured after about 60 hours to measure the stability of the private network. At this time, each measurement is performed 30 times, and a Poisson distribution is used to measure the average every 1 minute.

As a result of the measurement, as shown in the following [Table 1], similar speeds were measured for POW and POA when the private network was just started. In case of one node, the POW was 14.59 seconds and the POA was 15.10. Second, the POW is 14.73 seconds and the POA is 15.19 seconds when there are 3 nodes, and when there are 6 nodes, the POW is 15.36 seconds and the POA is 15.85 seconds. In all three cases, the POW is better The results came out. Also, it can be seen that the speed gradually slows down as the number of nodes increases.

number of nodes algorithm POW POA 1 node - average time (ms)/tx 14,590 15,102 3 nodes - average time (ms)/tx 14,730 15,199 6 nodes - average time (ms)/tx 15,364 15,857 Total - Average Time (ms)/tx 14,895 15,386

2 is a graph measuring the difference in speed until transaction completion according to the number of nodes in the Ethereum network using the POW algorithm, and it can be seen that the average transaction speed is slow although each deviation is different.

3 is a graph measuring the difference in speed until transaction completion according to the number of nodes in the Ethereum network using the POA algorithm. You can see the slowness.

In addition, as shown in [Table 2], POA showed much superior performance compared to POW in the results measured after about 60 hours after the Ethereum network was operated.

That is, in the case of three nodes, the average POW time to complete a transaction was 26.38 seconds, which was significantly lower than the initial performance, whereas the POA performance was 17.16 seconds, which was slightly lower, but it can be confirmed that it is more stable than POW.

number of nodes algorithm POW POA 3 nodes - average time (ms)/tx 26,386 17,161

4 is a graph measuring the time until transaction completion of POW and POA of three nodes after 60 hours. After 10,000 or more blocks are created, respectively, the POW has a large deviation in difficulty and speed, so that the transaction is completed until the completion of the transaction. While the time of POA is irregular, it can be confirmed that POA is in a regular state.

According to monitoring, due to changes in mining difficulty during the proof-of-work process, irregularity in block generation time, etc., the average speed of block generation was 5 seconds (about 5.09 seconds), which was initially set by POA. , because the POW increased to an average of 12.58 seconds. Therefore, from the point of view of network stability, it can be judged that POA is more suitable than POW when establishing a blockchain private network between fixed nodes.

In addition, the electronic document management system 10 using the Ethereum and IPFS according to an embodiment of the present invention compared and measured the performance of the public IPFS and the private IPFS.

That is, in the electronic document management system 10 using Ethereum and IPFS, the upload capacity limit of the public IPFS is 100 MB for IPFS performance measurement, so 9 text dummy files from 10 MB to 90 MB are created in 10 MB units, each Upload and download times were measured 10 times, and Poisson distribution was used to measure the average every minute. At this time, the private IPFS was configured by directly installing a separate node in two AWS.

As a result of measurement, private IPFS performed much better than public IPFS for both upload and download.

As shown in [Table 3] below, when comparing the upload bytes per 1ms, the public IPFS is 420 bytes and the private IPFS is 17,167 bytes, which is 40.85 times better than the private IPFS.

Also, when comparing download bytes per 1ms, public IPFS is 1,749 bytes and private IPFS is 45,155 bytes, which is 25.81 times better than private IPFS.

Upload Byte Download Byte Public IPFS 420 1,749 Private IPFS 17,167 45,155

In addition, when expressing this in terms of upload speed (ms) and download speed (ms) per 1MB, as shown in the following [Table 4], in the case of upload, it took an average of 124.53 seconds for public IPFS and 2.98 seconds for private IPFS, For download, it took an average of 28.73 seconds for public IPFS and 1.13 seconds for private IPFS.

Upload Speed(ms) Download Speed(ms) Public IPFS 124,539 28,739 Private IPFS 2,988 1,139

5 and 6 are graphs comparing upload speed and download speed in public IPFS and private IPFS by increasing the file size by 10 MB from 10 MB to 90 MB, respectively.

As shown in FIGS. 5 to 6, upload and download times significantly increased as the file size of both public IPFS and private IPFS increased.

7 and 8 are graphs in which the contents of FIGS. 5 and 6 are converted into upload bytes and download bytes per 1 ms for each file size, and in each case, it can be confirmed that the performance of the private IPFS is excellent.

As such, it can be seen that private IPFS shows better performance than public IPFS.

As such, the electronic document management system 10 using Ethereum and IPFS according to an embodiment of the present invention is configured to store information using a POA with a constant block generation rate in general user organizations including public institutions. can

In addition, the electronic document management system 10 using Ethereum and IPFS can be configured to distribute and store information (or files) using private IPFS when considering the difference in document security and performance.

In addition, when it is desired to delete (or shred) a specific file distributed and stored in the plurality of IPFS 300 , the client server 200 interworks with the plurality of IPFS 300 , and simultaneously the plurality of IPFS 300 . By simultaneously deleting a specific file (or a plurality of sub-files related to the specific file) distributed and stored in the , when a life cycle is set for a specific file in a public institution, it may be configured to permanently delete the specific file.

In this way, the file to be uploaded from the terminal can be managed distributedly through IPFS, and the hash value of the file that is distributed and managed through IPFS can be stored in a block of Ethereum.

In addition, when a hash value related to a file is inputted from the terminal as described above, a file related to the hash value being distributed and managed through IPFS can be called and the contents of the file can be checked.

In addition, when uploading a file for checking the authenticity of the hash value related to the original file and the file in the terminal as described above, the authenticity is provided through comparison between the original file and the uploaded file through the POA consensus algorithm or the POW consensus algorithm. can do.

Hereinafter, an electronic document management method using Ethereum and IPFS according to the present invention will be described in detail with reference to FIGS. 1 to 16 .

9 to 11 are flowcharts illustrating an electronic document management method using Ethereum and IPFS according to an embodiment of the present invention.

First, the terminal 100 accesses the client server 200 through a metamask, and displays (or outputs) an initial screen provided by the client server 200 . Here, the initial screen is a type selection menu (or type selection item/button) for selecting the type of IPFS, which is public or private, in relation to the file to be uploaded to the IPFS 300 , IPFS 300 . File selection menu to select a file to be uploaded to IPFS (300), Upload menu to upload a file to IPFS 300 , an additional information input menu for entering hash values according to file upload, additional information related to files, etc., a submission menu for storing information entered through the additional information input menu in the Ethereum block, and display of transaction processing results a transaction result display menu (or transaction result display area) for A file view menu for searching a related file, a download menu for downloading a file searched according to a file search related to a corresponding hash value, a verification target file for checking the authenticity of a specific file according to a user input of the terminal 100, and Another hash value input menu for inputting a related verification target hash value, an additional file selection menu for selecting a specific file for which authenticity is to be checked, and for checking the authenticity of a specific file according to a user input of the terminal 100 and a file authenticity check menu, a fidelity result display menu (or a fidelity result display area) for displaying a file authenticity result result, and the like.

As an example, the first terminal 100 provides an Ethereum network (or a block chain network) through the metamask using web3.js, which is an Ethereum Compatible JavaScript API, the client server ( 200), and as shown in FIG. 12, the initial screen 1200 provided from the client server 200 is displayed (S910).

Thereafter, among the initial screen displayed on the terminal 100, according to a user input (or user selection/touch/control) of the corresponding terminal 100, any one item (eg, For example, public, private, etc.) is selected, any one of the one or more files stored in the terminal 100 is selected according to the file selection menu, and then the preset upload menu is selected, the terminal ( 100) transmits the selected type information (including, for example, public, private, etc.), the selected file, file upload request information, identification information of the terminal 100, and the like to the client server 200 . Here, the identification information of the terminal 100 includes MDN, mobile IP, mobile MAC, Sim (subscriber identification module) card unique information, serial number, and the like. In this case, the upload menu may be activated when the type information and the file are selected in the terminal 100 while maintaining an inactive state by default.

For example, on the initial screen 1200 displayed on the first terminal, a private item is selected from the type selection menu according to a user selection of the first terminal, and a plurality of files stored in the first terminal according to the file selection menu are selected. When the upload menu 1210 displayed on one side of the initial screen 1200 is selected after the first file (eg, img001.jpg of 5KBytes, which is a jpg image file) is selected from among the files, the first terminal transmits first type information including the selected private item, the selected first file (eg, img001.jpg of 5KBytes), first file upload request information, identification information of the first terminal, etc. to the client server 200 ) to (S920).

Thereafter, the client server 200 receives type information (eg, including public, private, etc.) transmitted from the terminal 100 , the file, the file upload request information, identification information of the terminal 100 , and the like. do.

In addition, the client server 200 transmits the received type information, file, identification information of the terminal 100, etc. to a specific IPFS 300 randomly selected from among a plurality of IPFS 300 .

That is, the client server 200 selects the specific IPFS 300 randomly or in a preset manner from among a plurality of IPFS 300 interworking with the corresponding client server 200 .

In addition, the client server 200 transmits the received type information, the file, and identification information of the terminal 100 to the selected specific IPFS 300 .

For example, the client server 200 includes first type information (eg, including a private item, etc.) transmitted from the first terminal, the first file (eg, img001.jpg of 5KBytes), and the first file Receive upload request information, identification information of the first terminal, and the like.

In addition, the client server 200 randomly selects the first IPFS from among the first IPFS 300 to the tenth IPFS 300 interworking with the corresponding client server 200, and uses the selected first IPFS as the first IPFS. Type 1 information, the first file, identification information of the first terminal, and the like are transmitted (S930).

Thereafter, the specific IPFS 300 receives the type information, the file, and identification information of the terminal 100 transmitted from the client server 200 .

In addition, the specific IPFS 300 generates a hash value based on the received type information, the file, and the like.

In addition, the specific IPFS 300 transmits the generated hash value (or a hash value related to the file), identification information of the terminal 100, and the like to the client server 200 .

In addition, the specific IPFS 300 interworks with a plurality of other IPFS 300 (or the remaining IPFS 300 excluding the specific IPFS 300 among the plurality of IPFS 300) to distribute and store the file ( or management).

For example, the first IPFS receives the first type information, the first file, and identification information of the first terminal transmitted from the client server 200 .

In addition, the first IPFS generates a first hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) based on the received first type information and the first file.

In addition, the first IPFS transmits the generated first hash value, identification information of the first terminal, and the like to the client server 200 .

In addition, the first IPFS interworks with the second IPFS to the tenth IPFS, and distributes and stores the first file (eg, 001.jpg of 5KBytes) ( S940 ).

Thereafter, the client server 200 receives a hash value (or a hash value related to the file) transmitted from the specific IPFS 300 , identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received hash value, etc. to the terminal 100 corresponding to the identification information of the corresponding terminal 100 .

For example, the client server 200 receives a first hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) transmitted from the first IPFS, identification information of the first terminal, and the like.

In addition, the client server 200 transmits the first hash value, etc. to the first terminal corresponding to the received identification information of the first terminal (S950).

Thereafter, the terminal 100 receives the hash value transmitted from the client server 200 in response to the previously transmitted type information, the file, and the file upload request information.

In addition, the terminal 100 displays (or outputs) the received hash value. In this case, the terminal 100 may automatically input and display the received hash value in the hash value input item related to the additional information input menu in the initial screen.

For example, the first terminal receives a first hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) transmitted from the client server 200 in response to the first type information and the first file transmitted earlier.

In addition, as shown in FIG. 13 , the first terminal automatically inputs and displays the received first hash value in the hash value input item in the additional information input menu in the initial screen ( 1310 ) ( S960 ).

Thereafter, among the initial screen displayed on the terminal 100 , a plurality of input items corresponding to a plurality of input items included in the additional information input menu according to a user input (or user selection/touch/control) of the terminal 100 are provided. receive input. Here, the plurality of input values include hash values and additional information (eg, author name, company name, department/team name, date, etc.).

In addition, when the preset submission menu displayed on one side of the initial screen of the terminal 100 is selected, the terminal 100 receives the plurality of input values, block storage request information, and It transmits identification information and the like to the client server 200 . In this case, the submission menu may be activated when a plurality of input values corresponding to a plurality of input items included in the additional information input menu are received from the terminal 100 while maintaining an inactive state by default.

For example, according to the user's selection of the first terminal among the initial screen 1300 displayed on the first terminal, the first hash value and the first additional information (for example, the author woo dong ho, the affiliated company ABCDE co ., etc.) receives a first input value including

In addition, when the submission menu 1320 displayed on one side of the initial screen 1300 is selected, the first terminal includes the first input value (eg, the first hash value, the first additional information, etc.) ), first block storage request information, identification information of the first terminal, and the like are transmitted to the client server 200 (S970).

Thereafter, the client server 200 receives the plurality of input values transmitted from the terminal 100 , the block storage request information, identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received plurality of input values, identification information of the terminal 100, and the like to the Ethereum server 400 .

For example, the client server 200 receives the first input value transmitted from the first terminal, the first block storage request information, identification information of the first terminal, and the like.

In addition, the client server 200 transmits the first input value, identification information of the first terminal, etc. to the Ethereum server 400 interworking with the corresponding client server 200 (S980).

Thereafter, the Ethereum server 400 receives the plurality of input values transmitted from the client server 200 , identification information of the terminal 100 , and the like.

In addition, the Ethereum server 400 stores the received plurality of input values in the Ethereum block. At this time, the Ethereum server 400 applies a preset consensus algorithm method (including, for example, POA, POW, etc.), a smart contract, etc. to the plurality of input values to convert the received plurality of input values to the Ethereum. It can also be stored in blocks.

In addition, the Ethereum server 400 transmits the transaction processing result, identification information of the terminal 100, and the like to the client server 200 . Here, the transaction processing result (or Ethereum block storage result) includes a block hash value, a block number, recipient information, a transaction hash value, and the like.

For example, the Ethereum server 400 receives the first input value transmitted from the client server 200, identification information of the first terminal, and the like.

In addition, the Ethereum server 400 stores the received first input value in an Ethereum block, and a first block hash value according to the storage of the first input value (for example, 0x6ac532144b0dbb041903b9e9b48e50d84c6c59d0f726ac81d2c45afc8994d9d1), the first block number (for example, 18259), first recipient information (for example, 0xe9f0a99c65924cd33798005c6283bac8f881d199), a first transaction hash value (for example, 0xdb029e3a7d521c8bf75c041f18550a75e9a18209e91043f4ea70b7d1), a first transaction processing result including a result of processing and generating a first transaction processing result, etc. , and transmits the identification information of the first terminal and the like to the client server 200 (S990).

Thereafter, the client server 200 receives the transaction processing result transmitted from the Ethereum server 400 , identification information of the terminal 100 , and the like.

In addition, the client server 200 transmits the received transaction processing result, etc. to the terminal 100 corresponding to the identification information of the terminal 100 .

For example, the client server 200 receives the first transaction processing result transmitted from the Ethereum server 400, identification information of the first terminal, and the like.

In addition, the client server 200 transmits the first transaction processing result, etc. to the first terminal corresponding to the received identification information of the first terminal (S1000).

Thereafter, the terminal 100 receives the transaction processing result transmitted from the client server 200 in response to the previously transmitted plurality of input values and the block storage request information.

In addition, the terminal 100 displays (or outputs) the received transaction processing result and the like. In this case, the terminal 100 may automatically display the received transaction processing result, etc. on the transaction result display menu in the initial screen.

For example, the first terminal transmits a first block hash value (eg, 0x6ac532144b0dbb041903b9e9b48e50d84c6c59d0f726ac81d2c45afc8994d9d1) transmitted from the client server 200 in response to the previously transmitted first input value and the first block storage request information, etc.; Receive 1st transaction result including block number (eg 18259), first recipient information (eg 0xe9f0a99c65924cd33798005c6283bac8f881d199), first transaction hash value (eg 0xdb029e3a7d521c8bf75c041f18550a75e9a18209e91043f4ea70b3), etc.

Also, as shown in FIG. 14 , the first terminal displays the received first transaction processing result 1400 on the transaction result display menu in the initial screen (S1010).

In addition, among the initial screen displayed on the terminal 100, a user input corresponding to a hash value input item included in the hash value input menu according to a user input (or user selection/touch/control) of the terminal 100 Receive a hash value. Here, the user input hash value may be a hash value for the user of the terminal 100 to check the contents of a file corresponding to a specific hash value or to download a file corresponding to the specific hash value.

In addition, when the preset file view menu displayed on one side of the initial screen of the terminal 100 is selected, the terminal 100 displays the received user input hash value, file search request information, and the terminal 100 . and transmits the identification information of the client server 200 to the client server 200 . At this time, the file view menu maintains an inactive state by default and receives an input value (eg, including the user input hash value, etc.) corresponding to one or more items included in the hash value input menu in the terminal 100 . It can be activated if

For example, a first user input hash value (eg, QmXETN6mzhivT5UgEC4B5HjYCGMZnnhzdzac1bW99pu2A) is received according to the user selection of the first terminal among the initial screen 1200 displayed on the first terminal.

In addition, when the file view menu 1220 displayed on one side of the initial screen 1200 is selected, the first terminal provides the first user input hash value (eg QmXETN6mzhivT5UgEC4B5HjYCGMZnnhzdzac1bW99pu2A), first file search request information, The identification information of the first terminal is transmitted to the client server 200 (S1020).

Thereafter, the client server 200 receives the user input hash value transmitted from the terminal 100 , the file search request information, identification information of the terminal 100 , and the like.

In addition, the client server 200 cooperates with the plurality of IPFS 300 to collect a plurality of sub files distributed and stored in one or more IPFS 300 in relation to the user input hash value. Here, when the original file is divided into plural, the sub-file indicates the individual file divided into plural.

In addition, the client server 200 generates one original file corresponding to the user input hash value by combining the plurality of collected sub files.

Also, the client server 200 transmits the generated original file (or a file/original file corresponding to the user input hash value) to the terminal 100 .

At this time, when the plurality of sub files related to the user input hash value are not collected due to the interworking between the client server 200 and the plurality of IPFS 300 , the client server 200 receives the user input hash value and Information indicating that a related file does not exist in the IPFS 300 may be transmitted to the terminal 100 .

For example, the client server 200 receives the first user input hash value transmitted from the first terminal, the first file search request information, identification information of the first terminal, and the like.

In addition, the client server 200 cooperates with the first IPFS to the tenth IPFS to collect the first sub-file to the tenth sub-file in relation to the first user input hash value, and the collected first A second file (eg, kookmin.png), which is an original file, is generated by combining the sub-files to the tenth sub-files.

Also, the client server 200 transmits the generated second file (eg, kookmin.png) to the first terminal (S1030).

Thereafter, the terminal 100 receives the original file transmitted from the client server 200 in response to the previously transmitted user input hash value, file search request information, and the like.

In addition, the terminal 100 displays (or outputs) the received original file. Here, the terminal 100 may download (or store) the received original file to the corresponding terminal 100 .

At this time, if the file related to the corresponding user input hash value does not exist in the IPFS 300 , the terminal 100 receives the previously transmitted user input hash value, file search request information, etc. from the client server 200 . Receives information indicating that the transmitted file related to the corresponding user input hash value does not exist in the IPFS 300, and acknowledges that the file related to the received user input hash value does not exist in the IPFS 300 It is also possible to display (or output) the indicated information or the like.

For example, the first terminal transmits a second file (eg, kookmin.png) transmitted from the client server 200 in response to the previously transmitted first user input hash value, the first file search request information, etc. receive

Also, as shown in FIG. 15 , the first terminal displays the received second file 1500 ( S1040 ).

In addition, among the initial screen displayed on the terminal 100, according to a user input (or user selection/touch/control) of the terminal 100, the other hash value input items included in the other hash value input menu correspond to After receiving another hash value and selecting any one specific file from among one or more files stored in the terminal 100 according to the additional file selection menu, if the preset file authenticity check menu is selected, the terminal ( 100) transmits the received other hash value, the selected specific file, authenticity check request information, identification information of the terminal 100, and the like to the client server 200 . In this case, the file authenticity check menu may be activated when the specific file is selected after receiving the other hash value from the terminal 100 while maintaining the inactive state by default.

For example, in the initial screen 1200 displayed on the first terminal, a second hash value corresponding to another hash value input item included in the other hash value input menu according to a user selection of the first terminal (for example QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) is received, and a third file (eg, Kookmin University.png, which is an image file in a png format) is selected from among a plurality of files stored in the first terminal according to the additional file selection menu, and then the initial screen 1200 ), when the file authenticity check menu 1230 displayed on one side is selected, the first terminal transmits the received second hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An), the selected third file (eg, in the form of png The image file (Kookmin University.png), the third authenticity check request information, and the identification information of the first terminal are transmitted to the client server 200 (S1050).

Thereafter, the client server 200 receives the other hash value, the specific file, the authenticity check request information, the identification information of the terminal 100, and the like transmitted from the terminal 100 .

In addition, the client server 200 transmits the received specific file and identification information of the terminal 100 to another specific IPFS 300 randomly selected from among the plurality of IPFS 300 .

That is, the client server 200 selects the other specific IPFS 300 randomly or in a preset manner from among a plurality of IPFS 300 interworking with the corresponding client server 200 .

In addition, the client server 200 transmits the received specific file and identification information of the terminal 100 to the other selected specific IPFS 300 . At this time, when the type information is not included in the information transmitted from the terminal 100, the client server 200 provides other type information (eg, including a private item) preset by default. It may be transmitted to the other specific IPFS 300 together with a specific file, identification information of the terminal 100, and the like.

For example, the client server 200 includes the second hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) transmitted from the first terminal, the third file (eg, Kookmin University.png which is an image file in the form of png), the Receives third authenticity confirmation request information, identification information of the first terminal, and the like.

In addition, the client server 200 randomly selects the tenth IPFS from among the first IPFS to the tenth IPFS interworking with the corresponding client server 200, and uses the selected tenth IPFS to use the third file (eg, For example, a png image file, Kookmin University.png), default third type information (eg, including a private item), and identification information of the first terminal are transmitted ( S1060 ).

Thereafter, the other specific IPFS 300 receives the specific file, the other type information, and identification information of the terminal 100 transmitted from the client server 200 .

In addition, the other specific IPFS 300 generates another hash value based on the received specific file, the other type information, and the like. At this time, when the other specific IPFS 300 does not include type information among the information transmitted from the client server 200, other type information preset by default (eg, including a private item) and The other hash value may be generated based on the received specific file or the like.

In addition, the other specific IPFS 300 transmits the other generated hash value (or a hash value related to the specific file), identification information of the terminal 100, and the like to the client server 200 .

In addition, the other specific IPFS 300 interworks with another plurality of IPFS 300 (or the other IPFS 300 excluding the other specific IPFS 300 among the plurality of IPFS 300), and the specific file distributed storage (or management).

For example, the 10th IPFS includes the third file (eg, Kookmin University.png which is an image file in png format) transmitted from the client server 200 , the third type information, and identification information of the first terminal receive etc.

In addition, the tenth IPFS generates a third hash value (eg, QmXETN6mzhivfT5UgEC4B5HjYCGMZnnhzdzac1bW99pu2A) based on the received third file and the third type information.

In addition, the 10th IPFS transmits the generated third hash value, identification information of the first terminal, and the like to the client server 200 .

In addition, the tenth IPFS interworks with the first IPFS to the ninth IPFS to distribute and store the third file (eg, Kookmin University.png, which is an image file in a png format) (S1070).

Thereafter, the client server 200 receives another hash value (or a hash value related to the specific file) transmitted from the other specific IPFS 300 , identification information of the terminal 100 , and the like.

For example, the client server 200 receives the third hash value (eg, QmXETN6mzhivfT5UgEC4B5HjYCGMZnnhzdzac1bW99pu2A) transmitted from the 10th IPFS, identification information of the first terminal, and the like (S1080).

Thereafter, the client server 200 determines (or confirms) whether another hash value related to the received specific file matches another hash value previously received.

In addition, the client server 200 generates information on whether the specific file is authentic or not according to the determination result (or the verification result), and transmits information on whether the generated specific file is authentic or not to the terminal ( 100) to the Here, the information on the authenticity of the specific file is information indicating that the specific file does not match the analysis target file (or the analysis target file corresponding to the other hash value), and the specific file matches the analysis target file , and another hash value associated with that particular file.

For example, the client server 200 determines whether the second hash value (eg, QmVoxPe97q7SQFeJK9CnxjknJRLZR1BtsYZTpAnxBE32An) received from the first terminal and the third hash value (eg, QmXETN6mzhivfT5UgEC4) matched from the 10th IPFS match. judge

As a result of the determination, when the second hash value and the third hash value do not match, the client server 200 transmits the third file (eg, Kookmin University.png, which is an image file in png format) to the second hash value. Information indicating that the file corresponding to the second hash value does not match (eg, does not match the original document) and the third hash value are transmitted to the first terminal (S1090).

Thereafter, the terminal 100 receives information on the authenticity of the specific file transmitted from the client server 200 in response to the previously transmitted other hash value, the specific file, the authenticity check request information, etc. do.

In addition, the terminal 100 displays (or outputs) information on whether the received specific file is authentic or not. In this case, the terminal 100 may display information on whether the received specific file is authentic or not in the authenticity result display menu in the initial screen.

For example, the first terminal responds to the previously transmitted second hash value, the third file (eg, Kookmin University.png, which is an image file in png format), and the third authenticity check request information, etc., to the client Information indicating that the third file transmitted from the server 200 does not match the file corresponding to the second hash value (eg, does not match the original document), the third hash value, and the like are received.

In addition, as shown in FIG. 16, the first terminal displays information indicating that the received second file does not match the file corresponding to the second hash value in the authenticity result display menu in the initial screen ( For example, it does not match the original document), the third hash value, etc. (1600) is displayed (S1100).

As described above, the embodiment of the present invention distributes and manages the file to be uploaded from the terminal through IPFS, and stores the hash value of the file that is distributed and managed through IPFS in a block of Ethereum, It provides reliability, and the problem of attack or deletion of the original file can be solved through private IPFS.

In addition, as described above, in the embodiment of the present invention, when a hash value related to a file is input from the terminal, a file related to the hash value being distributed and managed through IPFS is called and the contents of the file are checked. Thus, it is possible to improve the operating efficiency of the entire system.

In addition, as described above, in the embodiment of the present invention, when uploading a file for checking the authenticity of a hash value related to an original file and a file in the terminal, the file is uploaded with the original file through the POA consensus algorithm or the POW consensus algorithm. By providing authenticity through comparison between files, maintenance is easy and network stability can be provided.

Those of ordinary skill in the art to which the present invention pertains may modify and modify the above-described contents without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical spirit of the present invention, but to illustrate, and the scope of the technical spirit of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

10: electronic document management system 100: terminal
200: client server 300: multiple IPFS
400: Ethereum Server

Claims (10)

Accessing the client server through MetaMask, displaying the initial screen provided by the client server, among the displayed initial screens, from among a plurality of items included in the type selection menu in the initial screen according to a user input After any one item is selected and any one of the one or more files stored in the terminal is selected according to the file selection menu included in the initial screen, when a preset upload menu included in the initial screen is selected, the selected the terminal for transmitting type information, the selected file, file upload request information, and identification information of the terminal to the client server;
the client server transmitting the type information, the file, and identification information of the terminal to a specific IPFS randomly selected from among a plurality of IPFSs;
the specific IPFS for generating a hash value based on the type information and the file transmitted from the client server, and transmitting the generated hash value to the terminal via the client server; and
It includes an Ethereum server,
The terminal is
Among the initial screens displayed on the terminal, a plurality of input values corresponding to a plurality of input items included in the additional information input menu in the initial screen are received according to a user input of the terminal, and on one side of the initial screen of the terminal When the displayed preset submission menu is selected, the received plurality of input values, block storage request information, and identification information of the terminal are transmitted to the client server,
The client server is
Transmitting a plurality of input values transmitted from the terminal and identification information of the terminal to the Ethereum server,
The Ethereum server is
Storing a plurality of input values transmitted from the client server in an Ethereum block, and transmitting the transaction processing result to the client server,
The client server is
Transmitting the transaction processing result to the terminal,
The terminal is
An electronic document management system using Ethereum and IPFS, characterized in that it displays the transaction processing result transmitted from the client server. delete accessing, by a terminal, a client server through a metamask, and displaying an initial screen provided by the client server;
Among the initial screens displayed on the terminal, any one of a plurality of items included in the type selection menu in the initial screen is selected according to a user input of the terminal, and according to the file selection menu included in the initial screen, the After any one of the one or more files stored in the terminal is selected, when a preset upload menu included in the initial screen is selected, by the terminal, the selected type information, the selected file, the file upload request information and the transmitting identification information of the terminal to the client server;
transmitting, by the client server, the type information, the file, and identification information of the terminal to a specific IPFS randomly selected from among a plurality of IPFSs;
generating a hash value based on the file and the type information transmitted from the client server by the specific IPFS, and transmitting the generated hash value to the terminal via the client server;
displaying, by the terminal, a hash value transmitted in response to the transmitted file upload request information; and
Based on the type information and the file transmitted from the client server by the specific IPFS, the method further comprises the step of interworking with the remaining IPFS except for the specific IPFS from among the plurality of IPFS, and distributing and storing the file. Electronic document management method using Ethereum and IPFS. delete 4. The method of claim 3,
Displaying the hash value comprises:
An electronic document management method using Ethereum and IPFS, characterized in that the hash value is automatically input and displayed in a hash value input item related to the additional information input menu in the initial screen. 4. The method of claim 3,
receiving, by the terminal, a plurality of input values corresponding to a plurality of input items included in an additional information input menu in the initial screen according to a user input of the terminal, from among the initial screens displayed on the terminal;
When a preset submission menu displayed on one side of the initial screen of the terminal is selected, transmitting, by the terminal, the received plurality of input values, block storage request information, and identification information of the terminal to the client server ;
transmitting, by the client server, a plurality of input values transmitted from the terminal and identification information of the terminal to an Ethereum server;
storing, by the Ethereum server, a plurality of input values transmitted from the client server in an Ethereum block;
transmitting, by the Ethereum server, a transaction processing result to the client server;
transmitting, by the client server, the transaction processing result to the terminal; and
The electronic document management method using Ethereum and IPFS, characterized in that it further comprises the step of displaying, by the terminal, the transaction processing result transmitted from the client server. 7. The method of claim 6,
Storing the plurality of input values in the Ethereum block comprises:
Electronic document management method using Ethereum and IPFS, characterized in that the plurality of input values are stored in the Ethereum block by applying POA (Proof of Authority) and smart contract, which are preset consensus algorithm methods . 4. The method of claim 3,
receiving, by the terminal, a user input hash value corresponding to a hash value input item included in a hash value input menu in the initial screen according to a user input of the terminal from among the initial screen displayed on the terminal;
transmitting, by the terminal, the user input hash value, file search request information, and identification information of the terminal to the client server when a preset file view menu displayed on one side of the initial screen is selected;
collecting, by the client server, a plurality of sub-files distributed and stored in one or more IPFSs in association with the user input hash value in association with the plurality of IPFS;
generating, by the client server, a single original file corresponding to the user input hash value by combining the plurality of collected sub files;
transmitting, by the client server, the generated original file to the terminal; and
The electronic document management method using Ethereum and IPFS, characterized in that it further comprises, by the terminal, displaying or downloading the original file transmitted from the client server. 4. The method of claim 3,
Among the initial screens displayed on the terminal, according to a user input of the terminal, a different hash value corresponding to another hash value input item included in another hash value input menu in the initial screen is received, and an additional file in the initial screen is selected After selecting any one specific file from among one or more files stored in the terminal according to the menu, when the file authenticity check menu in the initial screen is selected, the other hash value received by the terminal, the selected specific file , transmitting authenticity confirmation request information and identification information of the terminal to the client server;
transmitting, by the client server, the specific file and identification information of the terminal to another specific IPFS randomly selected from among a plurality of IPFSs;
generating another hash value based on the specific file transmitted from the client server by the other specific IPFS, and transmitting the generated another hash value to the client server;
receiving, by the client server, another hash value transmitted from the other specific IPFS;
determining, by the client server, whether another hash value transmitted from the terminal matches another hash value transmitted from the other specific IPFS;
generating, by the client server, information on whether a specific file is authentic or not according to the determination result, and transmitting information on whether the generated specific file is authentic or not to the terminal; and
The electronic document management method using Ethereum and IPFS, characterized in that it further comprises the step of displaying, by the terminal, information on the authenticity of the specific file transmitted from the client server. 10. The method of claim 9,
Information about the authenticity of the specific file,
Another hash value related to the specific file and information indicating that the specific file does not match the analysis target file corresponding to the other hash value or information indicating that the specific file matches the analysis target file E-document management method using Ethereum and IPFS.

Images