Blockchain-based proof-free service system

Abstract

The present invention relates to the field of information technology, and in particular to a blockchain-based proof-free service system, comprising a file receiving subsystem, a proof storage subsystem, a storage subsystem, and a file sharing subsystem. The file receiving subsystem receives batch files and file description information, scans the files to obtain file scans, the proof storage subsystem extracts a hash value of the file scans, uploads the hash value to the blockchain storage as the proof, and obtains the corresponding block height. The file sharing subsystem establishes a file index, and the service window submits field values ​​to the file sharing subsystem. The file sharing subsystem provides the file scan file file name, file type, and search field value to the service window. The service window sends a file scan download request based on the files required for the service matter, and the file sharing subsystem provides the corresponding file scans, proof hash value, and block height to the service window. The substantial effect of the present invention is to reduce the cost of file preservation and improve the social benefit of archives.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a blockchain-based proof-free service system. Background Art

[0002] Livelihood archives are authentic records generated during the work of safeguarding and improving people's livelihoods. Specifically, they refer to archives related to various aspects of livelihoods, generated by various economic and social organizations, as well as individuals. These include archives required for social security, marriage, retirement, second-child policy, and home purchases. Despite the recent rise in electronic office work, a large number of application forms and qualification certificates are still processed on paper. Livelihood archives involve people's vital interests and serve as the original documentation for safeguarding their rights and interests. Existing archive management systems lack reliable sharing between departments, requiring repeated submission of the same qualification documents when handling livelihood-related matters. The annual increase in paper documents requires dedicated storage areas and must be retained for a predetermined period. This not only creates an administrative burden but also inconveniences in handling livelihood-related matters. Therefore, it is necessary to research new archive management and sharing technologies.

[0003] For example, Chinese patent CN111339085A, published on June 26, 2020, is a blockchain-based trusted archive management method, which is to build an archive management system, including 26 archive collection groups and multiple inquirers. Each archive collection group has an index, an aggregator, and a recorder. Each archive collection group contains multiple archive dumpers, which are composed of a viewing axis, a viewing pointer, an archive column, a service column, and an activity isolation zone. From the perspective of archive records, the archive records are divided into each user and decomposed according to the user's first letter, and the archive viewing function is provided. The detailed settings, the distribution of rights and interests, and the redundancy issues are taken into consideration throughout the process, and the waste of time and operating costs involved in the process is avoided as much as possible. However, its technical solution cannot solve the management and trusted sharing of archives involving the validity of certificates, such as people's livelihood archives. Summary of the Invention

[0004] The technical problem to be solved by this invention is the current lack of trusted file sharing technology. This paper proposes a blockchain-based, proof-free service system that leverages blockchain to achieve trusted file sharing, thereby enabling the processing of proof-free public affairs based on file sharing.

[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is: a blockchain-based non-proof service system, including an archive receiving subsystem, an evidence storage subsystem, a storage subsystem and an archive sharing subsystem. The archive receiving subsystem receives batch archives and archive description information, and the archive description information records the archive source department, archive type and search field. The archive receiving subsystem scans the archive to obtain an archive scan copy. The evidence storage subsystem extracts the hash value of the archive scan copy and uploads it to the blockchain storage as the evidence hash value to obtain the corresponding block height. The storage subsystem assigns a file name to the archive scan copy and stores it. The archive sharing subsystem establishes an archive index, and the archive index records the archive. Type, source department, evidence hash value, block height and search field value. After the service window verifies the identity of the service provider, it submits the field value to the file sharing subsystem. The file sharing subsystem queries the file index according to the field value, obtains the file whose search field value matches the field value, and provides the file scan file name, file type and search field value to the service window. The service window sends a file scan download request to the file sharing subsystem based on the file required for the service matter. The file sharing subsystem provides the service window with the file scan, evidence hash value and block height corresponding to the download request. After the service window verifies the evidence hash value, it recognizes the file scan as the basis for the service matter.

[0006] Preferably, the archive receiving subsystem formulates a segmentation plan for each archive type, and the segmentation plan segments the archive scan into several slices. The storage subsystem includes several storage nodes, and the several slices of the archive scan are respectively stored in several storage nodes. When the archive sharing subsystem provides the archive scan to the service window, the several slices are spliced ​​together to restore the archive scan.

[0007] Preferably, the field areas of each file type are manually marked, and the segmentation scheme makes the slice contain at most one field area. The field name of the field area corresponding to each slice is manually labeled. The evidence subsystem extracts the hash value of each slice respectively, which is recorded as the slice hash value. All slice hash values ​​constitute a slice hash value set. The hash value of the slice hash value set is extracted as the evidence hash value. The file index records the slice hash value set of each file scan.

[0008] Preferably, the file sharing subsystem stores a matter table, which records the set of field names required for handling matters. The service window submits field values ​​and matters to the file sharing subsystem. The file sharing subsystem queries the file index based on the field value, obtains the file whose retrieved field value matches the field value, obtains the set of field names required for handling matters based on the matter table, obtains several slices corresponding to the set of field names, places several of the slices in a blank image as a special file, and provides the special file, slice hash value set, evidence hash value and block height to the service window. After verifying the slice hash value and evidence hash value, the service window recognizes the received special file as the basis for handling matters.

[0009] Preferably, the field area includes a formatting area and a filling area, the formatting area is an area with the same content as the file type, and the filling area is an area for filling in the file content. The file receiving subsystem cuts an area in the formatting area of ​​each field area to make a hollow area appear in the field area, and then extracts the slice hash value of the slice containing the field area. The cut area is recorded as a patch, and the patch is copied several times. A watermark is added to each patch. The watermark includes a task and an N-digit hexadecimal number. The watermark traverses the combination of the task and the N-digit hexadecimal number, extracts the hash value of each patch after adding the watermark, and records it as a patch hash value set. The hash value of the patch hash value set is used as the patch evidence hash value. The patch evidence hash value is included in the slice hash value set, and then the evidence hash value is extracted and associated with the slice for storage. When the file sharing subsystem provides a special file to the service window, the hash value of the slice, service window identifier, service item and timestamp is extracted and recorded as the service hash value. The hollow area of ​​the patch is selected so that the watermark on the patch matches the service item, and the N-digit hexadecimal number on the patch is the same as the last N digits of the service hash value. The slice after the patch is pasted is used to establish a special file. When the file sharing subsystem provides a special file to the service window, it also provides a patch hash value set.

[0010] Preferably, the storage subsystem reads several slices of the same file type and the same position, calculates the average value of the slice at each pixel position, records it as a slice template, calculates the pixel difference between each slice and the slice template at each pixel position, forms a difference image, uses a preset byte length to represent the pixel value of the difference image, establishes an exception set to record exceptional pixels whose pixel difference exceeds the preset byte length, and the exception set records the pixel coordinates and pixel values ​​of the exceptional pixel points. When reading the slice, the storage subsystem superimposes the difference image and the slice template, and then uses the exceptional pixels in the exception set to replace the corresponding pixel positions to obtain a restored slice.

[0011] Preferably, when scanning the archive, the archive receiving subsystem fine-tunes the pixel values ​​of the archive scan within a preset range so that the slices of the archive scan after fine-tuning have the highest similarity with the corresponding slice template.

[0012] The substantial effects of the present invention are: providing authenticity proof for scanned copies of archives through blockchain, so that scanned copies of archives have the effect of being a certificate, thereby eliminating the need to preserve paper archives and reducing the cost of archive preservation; facilitating the search of archives by establishing an archive index, improving the utilization rate of stored archives, and improving the social benefits of archive preservation; providing the required field area content for service windows through dedicated archives, while keeping other unnecessary field areas confidential, which can improve the security of archive use; and making archive scans occupy less storage space by improving the storage solution, further reducing the cost of archive preservation. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 This is a schematic diagram of the system for handling affairs without certification according to Example 1.

[0014] Figure 2 Schematic diagram of a slice of the embodiment.

[0015] Figure 3 This is a schematic diagram of slice storage in an embodiment.

[0016] Figure 4 This is a schematic diagram of slice storage in Example 2.

[0017] Among them: 10. Archive receiving subsystem, 20. Evidence subsystem, 30. Storage subsystem, 40. Archive sharing subsystem, 50. Blockchain, 61. Slice, 62. Field area, 63. Slice hash value set, 64. Evidence hash value, 65. Slice template, 66. Difference image, 67. Exception set, 68. Patch. DETAILED DESCRIPTION

[0018] The specific implementation of the present invention will be further described below with reference to specific embodiments and in conjunction with the accompanying drawings.

[0019] Example 1:

[0020] For a blockchain-based proof-free service system, please refer to the attached Figure 1, including an archive receiving subsystem 10, an evidence storage subsystem 20, a storage subsystem 30 and an archive sharing subsystem 40. The archive receiving subsystem 10 receives batch archives and archive description information. The archive description information records the archive source department, archive type and search field. The archive receiving subsystem 10 scans the archive to obtain an archive scan. The evidence storage subsystem 20 extracts the hash value of the archive scan and uploads it to the blockchain 50 as the evidence hash value 64 to obtain the corresponding block height. The storage subsystem 30 assigns a file name to the archive scan and stores it. The archive sharing subsystem 40 establishes an archive index. The archive index records the archive type, source department, evidence hash value 64, block height The service window verifies the identity of the service provider and submits the field value to the file sharing subsystem 40. The file sharing subsystem 40 queries the file index based on the field value, obtains the file whose search field value matches the field value, and provides the service window with the file scan file name, file type, and search field value. The service window sends a file scan download request to the file sharing subsystem 40 based on the file required for the service item. The file sharing subsystem 40 provides the service window with the file scan corresponding to the download request, the evidence hash value 64, and the block height. After verifying the evidence hash value 64, the service window recognizes the file scan as the basis for the service item. The files are provided to the file receiving subsystem 10 in batches. The file description information is generated by the file source department. Each batch of files can use the same file description information. The authenticity of the files is ensured by the file source department.

[0021] Table 1 Archive Index

[0022] File Name 800255820014 800255820015 File Type Low-income people registration form Low-income people registration form Source Department XX Community Management Committee XX Community Management Committee Generation time 20220206 20220208 Evidence hash value 64 E7F312…8E7201 C606E3…18D775 Block height 104451023 104451023 Retrieving Field Values {Name: Zhang XX / Age: 78} {Name: Zheng XX / Age: 63}

[0023] The file receiving subsystem 10 formulates a segmentation plan for each file type. Figure 2 The segmentation scheme segments the scanned file into a number of slices 61. The storage subsystem 30 includes a number of storage nodes. The slices 61 of the scanned file are stored in the number of storage nodes respectively. When the file sharing subsystem 40 provides the scanned file to the service window, the slices 61 are spliced ​​together to restore the scanned file.

[0024] The storage subsystem 30 reads a plurality of slices 61 of the same file type and position, calculates the average value of each pixel position of the slice 61, and records it as a slice template 65. Figure 3, calculates the pixel difference between each slice 61 and the slice template 65 at each pixel position, forming a difference image 66. The pixel values ​​of difference image 66 are represented using a preset byte length. An exception set 67 is established to record exceptional pixels whose pixel differences exceed the preset byte length. Exception set 67 records the pixel coordinates and pixel values ​​of exceptional pixels. When reading slice 61, storage subsystem 30 overlays difference image 66 with slice template 65 and then replaces the corresponding pixel positions with the exceptional pixels in exception set 67 to obtain a restored slice 61. When scanning a file, file receiving subsystem 10 fine-tunes the pixel values ​​of the scanned file within a preset range to maximize the similarity between the slice 61 of the fine-tuned scanned file and the corresponding slice template 65.

[0025] For a specific archive source department, when handling the same transaction, it receives a large number of paper archives, such as paper application forms or qualification documents. These documents have formatted content and require only a few designated spaces for information to be filled in and signed. Therefore, the majority of pixel values ​​in these archive scans are identical, regardless of differences in scanning equipment and lighting. For example, various informed consent forms contain identical content and require signatures at the end. These informed consent forms are crucial documents for determining liability in subsequent disputes and must be retained for a predetermined period before being destroyed. In this embodiment, the signed informed consent form is scanned to obtain an archive scan. A hash value of the archive scan is extracted as a stored hash value 64, which is then uploaded to the blockchain 50 for storage, and the paper document can then be destroyed. Archive scans stored on the blockchain 50 are legally binding, thereby reducing the number of archives that need to be physically stored in paper form. When the scanning equipment has good repeatability and the scanning position is essentially the same, the scanned documents can be repositioned using existing techniques to obtain a large number of similar areas with minimal pixel value differences.

[0026] For example, when the slice 61 of the archive scan uses RGB to represent the color. Each pixel has three channels, and each channel occupies 1 byte, that is, 8 bits. The value range of each channel is [0,255]. When representing the pixel difference, 5 bits are used, and the first bit represents the positive and negative signs, that is, the value represented by the subsequent 4 bits is added or subtracted from the corresponding channel value of the pixel position on the slice template 65. The range represented by 4 bits is [0,15]. For pixel points with channel values ​​that exceed the value range that can be represented by 5 bits, the pixel coordinates and pixel values ​​of the corresponding pixel points are directly recorded in the exception set 67. The pixel values ​​referred to in this embodiment include 3 channel values. For example, (25,25,25) represents a light gray. When reading, the exception combination is spliced ​​with the slice template 65, and then the exception pixel recorded in the exception set 67 is used to replace the pixel at the corresponding position. The hash value of the restored archive scan is extracted. The hash value extracted from the correctly assembled archive scan will match the evidence hash value 64 stored in the blockchain 50, proving the authenticity of the archive scan, thereby saving a large amount of storage space.

[0027] The beneficial technical effects of this embodiment are: providing authenticity proof for archive scans through blockchain 50, making archive scans valid as credentials, thereby eliminating the need to preserve paper archives and reducing the cost of archive preservation; facilitating archive search by establishing an archive index, improving the utilization rate of stored archives, and improving the social benefits of archive preservation; providing the required field area 62 content for service windows through dedicated archives, while keeping other unnecessary field areas 62 confidential, which can improve the security of archive use; and making archive scans occupy less storage space by improving the storage solution, further reducing the cost of archive preservation.

[0028] Example 2:

[0029] In a blockchain-based, proof-free service system, field areas 62 for each file type are manually labeled. The slicing scheme ensures that slices 61 contain at most one field area 62. The field name of field area 62 corresponding to each slice 61 is manually labeled. The evidence subsystem 20 extracts the hash value of each slice 61, recording it as the slice 61 hash value. The hash values ​​of all slices 61 constitute a slice hash value set 63. The hash value of slice hash value set 63 is extracted as the evidence hash value 64. The file index records the slice hash value set 63 for each file scan. As shown in Table 2, after slicing 61 for a community's low-income population registration form, the slice hash value set 63 and the evidence hash value 64 are obtained. The evidence hash value 6484FC8309…AE787B is uploaded to the blockchain 50 for storage, and the slice hash value set 63 is stored in the file index.

[0030] Table 2 Slice hash value set 63 and evidence hash value 64

[0031] Slice 611 HASH(Zone1) = E641D3…2E2EB5 Slice 612 HASH(Zone2) = EE56AE…6B76AB Slice 613 HASH(Zone3) = CEDC92…E08B2D … … Slice 618 HASH(Zone8) = FA7296…5F319B Evidence hash value 64 HASH({HASH(Zone1),…, HASH(Zone8)})= FC8309…AE787B

[0032] The file sharing subsystem 40 stores a task table, which records the set of field names required for each task. The field name set records the required fields and the file types in which the fields reside. For a given field name, multiple file types may be listed. In the task table, the keyword "or" can be used to link multiple file types. For example, field name 7, as shown in Table 3, can be found in both file types 4 and 5. When handling task 1, files matching the search key are found in file types 1 and 2, and the values ​​corresponding to field names 1, 2, and 3 are obtained. The service window submits the field value and the handling items to the file sharing subsystem 40. The file sharing subsystem 40 queries the file index according to the field value, obtains the file whose search field value matches the field value, obtains the field name set required for the handling items according to the item table, obtains several slices 61 corresponding to the field name set, places the several slices 61 in the blank image as a special file, and provides the special file, the slice hash value set 63, the evidence hash value 64 and the block height to the service window. After the service window verifies the slice 61 hash value and the evidence hash value 64, it recognizes the received special file as the basis for the handling items.

[0033] Table 3: Item list established in this embodiment

[0034] matter Field name collection Item 1 {field name 1@type 1, field name 2@type 1, field name 3@type 2} Item 2 {field name 2@type 1, field name 3@type 2, field name 4@type 2} Item 3 {field name 1@type 1, field name 5@type 2, field name 6@type 3} … … Item 6 {Field name 2@Type 1, Field name 7@Type 4 or Type 5}

[0035] The field area 62 includes a formatting area and a filling area. The formatting area is an area with the same content as the file type, and the filling area is an area for filling in the file content. The file receiving subsystem 10 cuts out an area in the formatting area of ​​each field area 62, so that the field area 62 appears hollow. Figure 4 , the character "Surname" and the surrounding area in the formatted content are cut out to create a hollowed-out slice 61. The hash value of the hollowed-out slice 61 is extracted as the hash value of slice 61. A watermark is added to patch 68. The watermark includes the item and a 3-digit hexadecimal number. Table 3 lists six items to be handled, so 6*16^3=24576 watermarks need to be created, 24576 patches need to be generated, and the hash value of each patch needs to be extracted. The hash value takes up little storage space. Moreover, it is not necessary to store all 24576 watermarked patches 68. After generating the watermarked patch 68 and extracting the hash value, all watermarked patches can be deleted; only the hash values ​​of all patches need to be retained. An unwatermarked patch is stored, and the location of the watermark addition is recorded once. Since the text content of the watermark can be derived, after recording the watermark addition location, the derived watermark text content can be added to patch 68 according to the watermark addition location. Therefore, the storage space consumed is not large. Figure 4In the process of recording not only the location of the watermark, but also the font, size, transparency, rotation center and rotation angle of the watermark text, the watermark text should be recorded. Since the recording only needs to be done once, the implementation will not cause a large amount of storage space to be used.

[0036] Then extract the hash value of slice 61 of slice 61 containing field area 62, record the cut-out area as a patch, copy the patch several times, add a watermark on each patch, the watermark includes the task and N-digit hexadecimal number, traverse the combination of the task and N-digit hexadecimal number, extract the hash value of each patch after adding the watermark, record it as the patch hash value set, extract the hash value of the patch hash value set as the patch evidence hash value 64, include the patch evidence hash value 64 into the slice hash value set 63, and then extract the evidence hash value 64 and associate the patch hash value set with the slice 61 for storage.

[0037] When the file sharing subsystem 40 provides a dedicated file to the service window, it extracts the hash value of slice 61, the service window ID, the task, and the timestamp, recording this as the task hash value. It then selects a patch to be pasted into the hollowed-out area, ensuring that the watermark on the patch matches the task and that the N hexadecimal digits on the patch match the last N digits of the task hash value. The dedicated file is then created using slice 61 after the patch is pasted. When the file sharing subsystem 40 provides the dedicated file to the service window, it also provides a set of patch hash values. A hash value is a hexadecimal number, with the number of digits determined by the hash function. For a specific task, the file sharing subsystem extracts the hash value of slice 61, the service window ID, the task, and the timestamp. The last three digits of the task hash value are E3D, and the task is Item 2. The file sharing subsystem 40 then generates the watermark text: Item 2 E3D. Using the stored watermark text's font, size, transparency, rotation center, and rotation angle, it adds the watermark to a blank patch and verifies the patch hash value. The patch is then pasted into slice 61 and provided to the service window. The service window can verify the authenticity of slice 61, but cannot use slice 61 for other purposes without authorization, thus effectively protecting the security of the archives.

[0038] The embodiment described above is only a preferred solution of the present invention and does not limit the present invention in any form. Other variations and modifications are possible without exceeding the technical solution described in the claims.

Claims

1. The blockchain-based proof-free service system is characterized by: It includes an archive receiving subsystem, an evidence storage subsystem, a storage subsystem and an archive sharing subsystem. The archive receiving subsystem receives batch archives and archive description information. The archive description information records the archive source department, archive type and search field. The archive receiving subsystem scans the archive to obtain an archive scan. The evidence storage subsystem extracts the hash value of the archive scan and uploads it to the blockchain storage as the evidence hash value to obtain the corresponding block height. The storage subsystem assigns a file name to the archive scan and stores it. The archive sharing subsystem establishes an archive index. The archive index records the archive type, source department, evidence hash value, block height and the retrieval field value. After the service window verifies the identity of the service provider, it submits the field value to the file sharing subsystem. The file sharing subsystem queries the file index according to the field value, obtains the file whose retrieval field value matches the field value, and provides the file scan file name, file type and retrieval field value to the service window. The service window sends a file scan download request to the file sharing subsystem based on the file required for the service matter. The file sharing subsystem provides the service window with the file scan corresponding to the download request, the evidence hash value and the block height. After the service window verifies the evidence hash value, it recognizes the file scan as the basis for the service matter. The storage subsystem reads several slices of the same file type and the same position, calculates the average value of the slice at each pixel position, records it as a slice template, calculates the pixel difference between each slice and the slice template at each pixel position, forms a difference image, uses a preset byte length to represent the pixel value of the difference image, establishes an exception set to record exceptional pixels whose pixel difference exceeds the preset byte length, and the exception set records the pixel coordinates and pixel values ​​of the exceptional pixel points. When reading the slice, the storage subsystem superimposes the difference image and the slice template, and then uses the exceptional pixels in the exception set to replace the corresponding pixel positions to obtain a restored slice.

2. The blockchain-based proof-free service system according to claim 1 is characterized in that: The file receiving subsystem formulates a segmentation plan for each file type, and the segmentation plan divides the file scan into several slices. The storage subsystem includes several storage nodes, and the several slices of the file scan are respectively stored in several storage nodes. When the file sharing subsystem provides the file scan to the service window, the several slices are spliced ​​together to restore the file scan.

3. The blockchain-based proof-free service system according to claim 2 is characterized in that: Manually mark the field area of ​​each file type. The segmentation scheme ensures that the slice contains at most one field area. Manually label the field name of the field area corresponding to each slice. The evidence subsystem extracts the hash value of each slice respectively, which is recorded as the slice hash value. All slice hash values ​​constitute a slice hash value set. The hash value of the slice hash value set is extracted as the evidence hash value. The file index records the slice hash value set of each file scan.

4. The blockchain-based proof-free service system according to claim 3 is characterized in that: The file sharing subsystem stores a matter table, which records the set of field names required for handling matters. The service window submits field values ​​and matters to the file sharing subsystem. The file sharing subsystem queries the file index based on the field value, obtains the file whose retrieved field value matches the field value, obtains the set of field names required for handling matters based on the matter table, obtains several slices corresponding to the set of field names, places several of the slices in a blank image as a special file, and provides the special file, slice hash value set, evidence hash value and block height to the service window. After verifying the slice hash value and evidence hash value, the service window recognizes the received special file as the basis for handling matters.

5. The blockchain-based proof-free service system according to claim 4 is characterized in that: The field area includes a formatting area and a filling area. The formatting area is an area with the same content as the file type, and the filling area is an area for filling in the file content. The file receiving subsystem cuts an area in the formatting area of ​​each field area to make a hollow area appear in the field area, and then extracts the slice hash value of the slice containing the field area. The cut area is recorded as a patch. The patch is copied several times and a watermark is added to each patch. The watermark includes a task and an N-digit hexadecimal number. The watermark traverses the combination of the task and the N-digit hexadecimal number, extracts the hash value of each patch after adding the watermark, and records it as a patch hash value set. The patch hash value set is extracted. The hash value of the hash value set is used as the patch evidence hash value, the patch evidence hash value is included in the slice hash value set, and then the evidence hash value is extracted and obtained, and the patch hash value set is associated with the slice for storage. When the file sharing subsystem provides a special file to the service window, the hash value of the slice, service window identifier, service item and timestamp is extracted and recorded as the service hash value. The hollow area of ​​the patch is selected so that the watermark on the patch matches the service item, and the N-digit hexadecimal number on the patch is the same as the last N digits of the service hash value. The slice after the patch is pasted is used to establish a special file. When the file sharing subsystem provides a special file to the service window, it also provides a patch hash value set.

6. The blockchain-based proof-free service system according to claim 1 is characterized in that: When scanning a file, the file receiving subsystem fine-tunes the pixel values ​​of the file scan within a preset range so that the slices of the file scan after fine-tuning have the highest similarity with the corresponding slice template.

Images