Property registration core data security protection method based on block chain technology

Abstract

The invention relates to the technical field of data integrity protection, in particular to a property right registration core data security protection method based on a block chain technology, which comprises the following steps: acquiring an anchor point on an identity data generation chain, verifying a historical block to construct a topological structure, and matching a permission mapping field write-in path. And verifying the node permission and generating a data integrity verification report. According to the method, identity anchoring data is generated by binding a registrant identity credential with an address on a chain, structured identity mapping is realized, historical blocks form a logic closed loop through pointer and serial number verification, the integrity of data circulation is enhanced, a field access boundary is established by matching a field set with a node identifier through an authority level, and the accuracy of access control is enhanced. Field contents are written into nodes according to an addressing protocol and a distributed path index is generated, the flexibility and addressability of data positioning are improved, a verification link is fused with a certificate and an authority label to match and screen credible nodes, and integrated verification of path compliance and access security is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data integrity protection, in particular to a property registration core data security protection method based on blockchain technology. BACKGROUND

[0002] The technical field of data integrity protection includes the ability to maintain the integrity of data during storage, transmission and processing through various technical means, prevent unauthorized modification, deletion or forgery, the core content is to ensure the consistency and credibility of data in the life cycle, prevent the risk of data tampering, loss or forgery caused by external attacks, internal operation errors or system failures, widely used in financial, medical, government, property registration and other key scenarios, often using cryptographic verification, digital signature, hash check, access control and other technical means to realize the anti-tampering, traceability and verification functions of data.

[0003] Among them, the property registration core data security protection method based on blockchain technology refers to the recording and verification of key data such as ownership information, transaction records and registration changes in the property registration system through distributed ledger structure and consensus mechanism, in order to prevent data tampering and loss during registration, including ownership information, property location, historical transaction information, etc. In terms of protection, it mainly uses tamper-proof chain data structure, timestamp technology, symmetric encryption combined with asymmetric encryption mechanism for data encryption processing, and completes data checking and backup through inter-node consistency verification and distributed storage mechanism, so as to realize the structured registration and security protection of property core data under the joint maintenance of multiple nodes.

[0004] In the existing property registration core data processing process, in terms of processing structured identity information, it mainly depends on static fields or centralized certificate matching mechanism, lacks field anchoring mode at block level, resulting in blurred identity boundary in multi-role registration scenarios, and it is difficult to provide flexible identity mapping. In the process of block data flow, the historical transaction does not form a chain-like closed loop relationship, and there is a lack of pointer checking or topological association mechanism between blocks, which is easy to cause information discontinuity or traceability blockage. In the access control strategy, the permission matching highly depends on preset rules, lacks real-time adaptation mechanism with data field granularity, and the node role change cannot be mapped to the permission level in time, causing inconsistent data access scope. In terms of data storage layer, path mapping relies on fixed address index, without introducing content addressing mechanism, which is easy to cause index invalidation after data location change or node migration, reducing data positioning efficiency. In the node trust system, the verification means mainly focuses on single certificate matching, and the permission and node compliance do not form a linkage relationship, resulting in weak points in path control, and the permission label is difficult to cover dynamic node behavior, affecting the accuracy and range integrity of trusted verification. SUMMARY

[0005] The application aims to solve the problems in the prior art and provides a property right registration core data security protection method based on a blockchain technology.

[0006] To achieve the above-mentioned purpose, the application adopts the following technical scheme: a property right registration core data security protection method based on a blockchain technology, comprising the following steps:

[0007] S1: obtaining a registration person digital identity certificate, agency authentication information and timestamp data, performing field concatenation, embedding a block metadata field, establishing corresponding mark bits and block chain transaction address binding information, and generating an on-chain identity anchor point;

[0008] S2: based on the on-chain identity anchor point, searching a transaction correlation history block, comparing a block serial number and a current block hash pointer for consistency verification, establishing a chain correlation and marking a fragment identifier and a cross-chain index, and obtaining a block chain fragment topology structure;

[0009] S3: according to the block chain fragment topology structure, performing transaction index sorting on a block field set, extracting a chain network initialization node role permission set and performing permission matching, recording a role permission level and a node identifier to which a matching field belongs, and generating a role permission mapping relationship table;

[0010] S4: based on the role permission mapping relationship table, querying a node storage path, performing a write operation on each matching field, establishing a distributed storage reference, and obtaining a decentralized storage path index;

[0011] S5: based on the decentralized storage path index, detecting a matching relationship of a corresponding digital certificate and an access permission label path by path, marking a trusted storage node, and generating a data integrity verification report.

[0012] As a further scheme of the application, the on-chain identity anchor point comprises an identity certificate hash value, block chain transaction address binding information and block metadata hash digest, the block chain fragment topology structure comprises an original block pointer reference, a new block correlation mark, a fragment ID identifier and a cross-chain index label, the role permission mapping relationship table comprises a field permission level, a node role identifier and a permission access label set, and the decentralized storage path index comprises a distributed storage reference address, a content addressing identifier and a node storage path hash, and the data integrity verification report comprises a trusted node identifier list, a path permission consistency result and a digital certificate matching state.

[0013] As a further scheme of the application, the specific acquisition steps of the on-chain identity anchor point are as follows:

[0014] S111: Obtain the registration person digital identity certificate, the agency authentication information and the timestamp data submitted in the property right registration process, concatenate the registration person digital identity certificate field and the agency authentication information field, combine the timestamp data to complete data structure combination, and obtain a field combination data block;

[0015] S112: Based on the field combination data block, uniformly encode all contents, and perform one-way encryption processing, obtain a hash embedded ciphertext value by constructing an embedding relationship between the encryption structure and the metadata field;

[0016] S113: According to the hash embedded ciphertext value, establish a mapping relationship between the embedding position in the block metadata and the blockchain transaction address, identify the marker bit and complete address binding, and generate an on-chain identity anchor point.

[0017] As a further scheme of the application, the specific acquisition step of the blockchain sharding topology structure is:

[0018] S211: Based on the marker bit content in the on-chain identity anchor point, extract the hash identification field and the corresponding transaction index, and map and match with the historical transaction records on the chain, filter the historical blocks with transaction interaction relationship, and generate a transaction associated block sequence;

[0019] S212: According to all historical block numbers and hash fields in the transaction associated block sequence, establish a hash chain mapping relationship between the historical blocks and the current block, calculate the block consistency offset degree, and if it is lower than the offset consistency tolerance threshold, establish a mapping path, and obtain a blockchain chain mapping result;

[0020] S213: According to the blockchain chain mapping result, construct a chain connection index relationship between the original block and the current registration block, and collect the sharding structure header field to which the current block belongs, parse the belonging shard ID according to the field content, parse the cross-chain address segment and cross-chain pointer, and obtain the blockchain sharding topology structure.

[0021] As a further scheme of the application, the specific acquisition step of the role permission mapping relationship table is:

[0022] S311: According to the path positioning information in the blockchain sharding topology structure, extract the target block number field, detect the data structure content of the corresponding number block in the blockchain, parse the transaction index field group in the field set, reorder in ascending order according to the timestamp field value, and generate a transaction index sorting value group;

[0023] S312: Based on the sorted transaction operation queue in the transaction index sorting value group, read the node initiation address and target operation permission bit recorded by each transaction, retrieve the node role permission set in the chain network initialization configuration file, calculate the permission offset matching degree, and if the matching degree is lower than the set permission error threshold, it is considered that the permission matching is successful, the matching state and node identifier of the current field are recorded, and the permission matching level sequence is obtained;

[0024] S313: According to the matching state information recorded in the permission matching level sequence, construct a field matching identifier table combined with the field bit identifier and the permission matching result, embed the corresponding node identifier field and role permission level value, align all record items in the field and classify the permission level, and generate a role permission mapping relationship table.

[0025] As a further scheme of the application, the specific acquisition steps of the decentralized storage path index are:

[0026] S411: Based on the role permission mapping relationship table, extract the node number and construct a node access request list, compare the node number with the hash identifier in the account book registration node list to match and locate, extract the physical and virtual path fields bound by the matched node, and generate a node storage path set;

[0027] S412: According to the storage address information of each node in the node storage path set, distribute the field content according to the mapped node number, judge the storage compatibility of the field content and the target node path, and perform structured mapping of the field content and the storage location to obtain a field storage mapping value group;

[0028] S413: According to the field storage mapping value group, convert the hash identifier value of each field into a resource identifier structure conforming to the standard format, construct a path ternary structure combined with the field content, resource identifier and the node, establish a field-oriented reverse tracking, and generate a decentralized storage path index.

[0029] As a further scheme of the application, the specific acquisition steps of the data integrity verification report are:

[0030] S511: Based on the decentralized storage path index, extract the target node number of each field, and construct an initial to-be-detected path set by summarizing the node numbers, match the node numbers of the extracted path target nodes with the verification node set, bind map the node path and the certificate record, and obtain a to-be-verified node path table;

[0031] S512: According to the to-be-verified node path table, the access permission label in each path record is parsed, the registered permission use range field and the certification authority field are read, field comparison is performed between the permission level and the certificate allowed operation level, it is judged whether the node has a conflict, the number of the node without conflict is arranged and recorded, and a trusted storage node list is generated.

[0032] S513: According to the trusted storage node list, a field mapping structure between the path and the verification state is established, field integrity review is performed on each record, and a data integrity verification report is output.

[0033] Compared with the prior art, the advantages and positive effects of the present application are that:

[0034] In the present application, identity anchor data is generated by binding the identity certificate of the registrant and the on-chain address, structured identity mapping is realized, a logical closed loop is formed through pointer and serial number verification of the history block, the integrity of data flow is enhanced, the field access boundary is established by matching the permission level and the node identifier of the field set, the precision of access control is strengthened, the field content is written into the node according to the addressing protocol and a distributed path index is generated, the flexibility and addressability of data positioning are improved, the verification link integrates the certificate and the permission label matching to filter the trusted node, the path compliance and access security are integrated and checked, the processing logic constructs a dynamic verification system around the identity binding uniqueness, field permission mapping and path trusted screening throughout the whole chain, promotes the collaborative improvement of the registered data in the identity mapping, path addressing and permission matching links, and enhances the security consistency and complete controllability in response to scenarios such as multi-node change, cross-chain data linkage and dynamic change of role permission. BRIEF DESCRIPTION OF DRAWINGS

[0035] Figure 1 The present application is a main step flowchart.

[0036] Figure 2 The present application is a chain identity anchor point acquisition flowchart.

[0037] Figure 3 The present application is a blockchain sharding topology acquisition flowchart.

[0038] Figure 4 The present application is a role permission mapping relationship table acquisition flowchart.

[0039] Figure 5 The present application is a decentralized storage path index acquisition flowchart.

[0040] Figure 6 The present application is a data integrity verification report acquisition flowchart. DETAILED DESCRIPTION

[0041] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0042] In the description of the present application, it should be understood that the terms "length", "width", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, which are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation of the present application. In addition, in the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise explicitly and specifically limited.

[0043] Please refer to Figure 1 A property registration core data security protection method based on blockchain technology, comprising the following steps:

[0044] S1: Obtain the registration person digital identity certificate (decentralized identity in line with W3C DID standard), institutional authentication information and timestamp data submitted in the property registration process, form a structured data block by field concatenation, and embed the metadata field of the block after hash operation (one-way encryption processing by SHA-3 algorithm), establish the binding information of corresponding mark bit and block chain transaction address (block chain address format in line with BIP-0044 standard), generate chain identity anchor point;

[0045] S2: Based on the mark bit content recorded in the chain identity anchor point, find the historical block with transaction association in the block chain, compare the block serial number and the current block hash pointer for consistency check, establish the chain association relationship between the original block and the new registration block, and mark the shard identification (shard ID in block chain sharding technology, such as Zilliqa sharding scheme) and cross-chain index, obtain the block chain sharding topology structure;

[0046] S3: According to the block content positioned in the block chain sharding topology structure, execute transaction index sorting on the block field set, and extract the node role permission set initialized by the chain network, match the field index and access control execution permission, record the role permission level and node identifier to which the matching field belongs, and generate the role permission mapping relationship table;

[0047] S4: Based on the role and node identifier recorded in the role permission mapping relationship table, the node storage path is queried through the distributed ledger, and the write operation is performed on each matching field according to the content addressing protocol (content addressing method of IPFS protocol (CIDv1 standard)) to establish the distributed storage reference of the field to the target node (storage resource identifier conforming to RFC6920 standard), and the storage location hash is recorded synchronously to obtain the decentralized storage path index;

[0048] S5: Based on the node path formed in the decentralized storage path index, the current verification node set is extracted in the chain network, the matching relationship between the corresponding digital certificate (X.509v3 digital certificate based on PKI system) and access permission label is detected path by path, it is confirmed that there is no permission conflict in the path, and the compliant node is marked as a trusted storage node (trusted node list through TLS two-way authentication), and a data integrity verification report is generated.

[0049] The on-chain identity anchor point includes identity certificate hash value, blockchain transaction address binding information, block metadata hash digest, the blockchain shard topology includes original block pointer reference, new block association label, shard ID identification, cross-chain index label, the role permission mapping relationship table includes field permission level, node role identification, permission access label set, the decentralized storage path index includes distributed storage reference address, content addressing identifier, node storage path hash, and the data integrity verification report includes trusted node identification list, path permission consistency result, and digital certificate matching state.

[0050] Please refer to Figure 2 , the specific steps of S1 are:

[0051] S111: Obtain the registration person digital identity certificate, institution authentication information and timestamp data submitted in the property registration process, concatenate the registration person digital identity certificate field and the institution authentication information field, and complete the data structure combination combined with the timestamp data to obtain the field combination data block.

[0052] Obtain the registration person digital identity certificate, institution authentication information and timestamp data submitted in the property registration process, the registration person digital identity certificate is a Base58 string with a 256-bit asymmetric encryption structure, which is generated by the user in the identity initialization stage and submitted through off-chain signature, in actual application scenarios, for example, a city real estate registration platform, the user submits the DID identity certificate exported by MetaMask through a digital wallet, and the institution authentication information is the institution certificate number and its authentication level identification issued by the platform, the identification is a 64-bit Base64 encoded data string, and the timestamp data is a UTC millisecond level time value recorded by the server. Each item of data is shown in the following table:

[0053] Table 1 field combination data table

[0054] Field number Length of the registrar's certificate field (bits) Length of the organization authentication information (bits) Timestamp value (ms) Field 1 256 128 1620345678000 Field 2 256 128 1620345678200 Field 3 128 256 1620345678300 Field 4 512 128 1620345678500 Field 5 256 256 1620345678600

[0055] As shown in Table 1, the registrant certificate field generally adopts a structure of 256 bits or more, the institution authentication information is set to 128 or 256 bits according to the authentication level, and the timestamp uniformly adopts a 13-bit millisecond Unix time format. In the field splicing process, the system places the registrant certificate field in the first place, followed by the institution authentication field, and finally splices the timestamp field. The fields are connected by ASCII hexadecimal line feed characters, the total length of the fields is not less than 512 bits according to the bit statistics, the splicing order of each data field is parsed and matched through the rule table in the server configuration file, and the formation of the field combination data block is normalized by the configuration rules. Different length fields are arranged in a fixed bit length structure and input into the subsequent hash processing module. For example, the registrant certificate is "0xA23...7EF", the institution information is "LEG202501", and the timestamp is 1620345678000. The combination structure is "0xA23...7EF\nLEG202501\n1620345678000". The structure data is checked by the matching rule and no empty field or format error is found, that is, it enters the combination data block registration queue. The system periodically checks and extracts valid field data in the queue for structure fixation processing. If the field length is insufficient, it is aligned to the set length by zero padding. After the above splicing, the field combination data block is generated.

[0056] S112: Based on the field combination data block, all contents are uniformly encoded and processed, and one-way encryption processing is performed. Through the construction of the embedding relationship between the encrypted structure and the metadata field, the hash embedded ciphertext value is obtained.

[0057] Based on the field combination data block, the above spliced data content is uniformly converted into a UTF-8 encoded format string. The system first removes redundant white spaces and invisible characters through a standard hash preprocessing mechanism, then separately converts each field paragraph into a string, performs data integrity checking after the conversion is completed, confirms that there is no nesting or displacement error between the field paragraphs, then introduces a SHA-3 hash operation module to perform one-way encryption processing on the unified format data string. In the encryption process, a 512-bit hash target bit width is used, and a domain separator is added to each field paragraph for block encryption. The hash calculation uses the Keccak hash function for multiple rounds of iteration compression, and each round is executed by an independent 64-bit block processor. The processor state matrix is composed of 25 64-bit registers arranged in a 5x5 matrix. The field data is used as input to perform permutation, arrangement, XOR and other operations on the state matrix. Each group of field combination data can obtain a 128-byte length hash output ciphertext. The ciphertext example is a hexadecimal string in the form of "3ef4d09e...". Then the system inserts this hash value into the preset block metadata field position according to the block structure to construct a hash embedding structure. If the length of the ciphertext is less than 128 bytes, it is filled with redundant bits to meet the embedding structure template requirements. Finally, the binding relationship between the ciphertext and the structure is completed, and the system updates the state mapping table and generates the hash embedded ciphertext value after detecting that the field header information and the field tail instruction match.

[0058] S113: According to the hash embedded ciphertext value, a mapping relationship between the embedded position in the block metadata and the blockchain transaction address is established, the marker bit is identified and the address binding is completed, and a chain identity anchor point is generated.

[0059] According to the hash embedded ciphertext value, the embedded position identifier is read from the metadata structure, the metadata offset address and the mapping label number corresponding to it are obtained by parsing the position mapping table, the system finds the blockchain transaction address candidate set through the mapping label number, and filters the address segment matching the label number. In the filtering process, the transaction address format is checked for compliance, and it is judged whether it meets the BIP-0044 standard, i.e. the path format needs to meet the m / purpose' / coin_type' / account' / change / address_index style. The system sets the format verification reference value in the judgment process: the path depth is 5 layers, the field separator is forward slash, and the field value is an integer or an integer modified by a single quotation mark. If a certain address format does not meet the standard, the candidate address is excluded. For example, if the ciphertext mapping label number is "TAG123", the system filters the address with the path "m / 44' / 0' / 0' / 0 / 123" from the candidate set for binding. During the address binding process, the hash embedded ciphertext value and the filtered transaction address are written into the marker bit index table, the transaction mapping table is updated to lock the identity pointer address, and finally the chain identity anchor point is generated.

[0060] Referring to Figure 3 , the specific steps of S2 are:

[0061] S211: Based on the content of the mark bit in the on-chain identity anchor point, the hash identification field and the corresponding transaction index are extracted, and the mapping matching is performed with the historical transaction records on the chain to screen the historical blocks with transaction interaction relationship and generate the transaction-related block sequence.

[0062] Based on the content of the mark bit recorded in the on-chain identity anchor point, the hash identification field and the transaction index field contained in the mark bit are first extracted. The hash field is usually the result of the hash conversion of the identity ciphertext submitted by the registrant, and the standard length is 128 bits. The transaction index field records the historical on-chain behavior track address corresponding to the identity, such as the mark bit content of the anchor point "ab34d912..." and the transaction index "TX74329". The system reads all the hash fields of the transactions from the complete transaction log on the chain one by one, and matches them with the above mark hash value. The matching is performed by byte-level comparison of the hash value string. Assuming that the matching function is whether they are the same in full bytes, "ab34d912..." and "ab34d912..." are matched,

[0063] "ab34d912..." and "ab34d913..." are not matched. The number of the block to which the transaction record in the matching successful transaction belongs is listed in the candidate block set. The system records the block number and the index in the block to which each successful matching transaction belongs in this process, continues to screen the blocks in the set that meet the condition that the number of transactions is not less than 3 to exclude abnormal or isolated transactions. If the matching successful blocks of an anchor point are 4388, 4390, 4392 and the corresponding transaction numbers are 3, 4, and 2, they all meet the screening condition. Then the system extracts the number fields of these blocks to establish a preliminary number sequence, continues to call the block header information to read the hash field content of each block, and then performs byte-level consistency comparison to determine whether it is consistent with the mark hash value. If it is consistent, it is confirmed that the transaction interaction relationship is established, and the transaction aggregation sequence of the batch of blocks is generated. Finally, the sequence of the block numbers 4388, 4390, and 4392 is output as the transaction-related block sequence.

[0064] S212: According to all the historical block numbers and hash fields in the transaction-related block sequence, the hash chain mapping relationship between the historical blocks and the current block is established, using the formula:

[0065]

[0066] Calculate the block consistency offset degree If it is lower than the offset consistency tolerance threshold, the mapping path is established, and the block chain chain mapping result is obtained, wherein, B i represents the i-th historical block number value, Hi S represents the integer mapping value of the hash value of the i-th block header. i T represents the bit length value of the i-th block structure. j This represents the timestamp field value of the j-th current block header, where n is the number of historical blocks, m is the number of blocks currently being compared, and the tolerance threshold is set to R. T =10 6 ;

[0067] Based on all block numbers and corresponding hash field data in the transaction-related block sequence, the hash field value, structure length, and timestamp field of each block's block header structure are read, and the hash pointer value of the currently registered block is included in the comparison. The structure length is uniformly 2048 bits, the timestamp value is taken from UTC time encoding, and the hash field needs to be mapped to an integer for addition. Assuming the timestamp of the currently registered block is 1620310080, the following data recording and structure processing are performed on each historical block, as shown in the table below:

[0068] Table 2 Block Comparison Parameters

[0069] Block number History hash value Length of the structure bit Timestamp value 5012 983411 2048 1620310000 5013 983455 2048 1620310020 5014 983492 2048 1620310040 5015 983510 2048 1620310060

[0070] Substitute the data from Table 2 into the offset calculation formula.

[0071]

[0072] Substitute the parameters as follows:

[0073]

[0074]

[0075]

[0076] The result indicates that the combined offset between the current block and historical blocks in the transaction sequence in terms of number, structure, and time reaches 10245534529.13, which is significantly higher than the set tolerance threshold R. T =10 6 Therefore, if the direct chain structure mapping requirement is not met, it is necessary to re-search for candidate sequences or reduce the error tolerance of structural parameters. If the final offset meets the set conditions, the mapping channel is determined to be established, and the blockchain chain mapping result is obtained.

[0077] The block consistency offset degree is a composite numerical indicator for measuring the overall difference between the current registered block and a group of transaction-associated historical blocks in terms of structural number, hash mapping, bit length standard and timestamp parameters. The indicator is calculated by the structural proportional relationship of block number and hash field and normalized by combining the timestamp change intensity to reflect the degree of fit between the two types of blocks in terms of chain structure continuity and information integrity. The smaller the value, the stronger the continuity and directionality between the current block and the target historical block in the block chain logical structure. If the offset degree exceeds the set threshold, it indicates that the block and the selected historical block have a large gap or drift in structural mapping or time path, making it difficult to establish a reliable chain connection. Therefore, this value is the core parameter for judging the effectiveness of chain mapping relationship and the rationality of structural attribution.

[0078] The operation logic design of the formula aims to comprehensively measure the matching offset degree between the historical block and the current registered block in terms of number, hash value, structural bit length and timestamp, etc. Among them, Part of the historical block number B i is added to the corresponding hash value H i and then divided by its structural bit length S i to evaluate the ratio relationship between the number and the hash information in the structural length under the unified scale, thereby expressing the mapping strength of the historical block in the chain structure. The larger the value, the closer the historical block is to the current block in the structure, Part of the current block's multiple timestamps T j is squared and summed and then the square root is taken to eliminate positive and negative deviations and enhance the weight of the time dimension. The root processing can enhance the influence of time value change on the overall offset. Finally, the absolute value between the two parts is taken to represent the comprehensive offset amplitude in structure and time, which is used to judge whether it is within the tolerance range. This structure can not only handle comparisons between large-scale block groups, but also has the ability to quantify time drift and hash chain continuity, thereby establishing a rigorous chain mapping criterion.

[0079] S213: According to the chain mapping result of the block chain, the chain connection index relationship between the original block and the current registered block is constructed, and the head field of the current block belonging to the shard structure is collected. According to the field content, the belonging shard ID is parsed, the cross-chain address segment and cross-chain pointer are parsed, and the block chain shard topology structure is obtained;

[0080] According to the block mapping relationship structure provided in the blockchain chain mapping value, the system first calls the shard mark field in the registered block data structure, the field bit depth is set to 16-bit integer, the value domain range is set to 0 to 31, which is used to represent the shard ID of the block in the Zilliqa structure. After reading, it is judged whether the value is within the specified interval. If not, the shard index exception processing is triggered. In this embodiment, the value is 12, which means it belongs to the 13th shard. Then the cross-chain path information in the transaction index field is called. The field format is set to "chainIndex-pathDepth". For example, if the read value is "03-04", it means that the cross-chain target is the 3rd chain of the 4th layer path. The system extracts the target chain structure code through the path comparison mapping table and combines it with the shard structure where the current block is located to construct the path topology node group. For example, the current node is "12::03", which means building a path channel from the 12th shard chain to the 3rd chain. If the channel already exists in the path atlas, the number of times is accumulated. If it does not exist, a new atlas node is created and added to the full chain structure. Finally, all path nodes and edge information are combined to form a structure atlas with cross-chain attributes, and the output is the blockchain shard topology structure.

[0081] Please refer to Figure 4 The specific steps of S3 are as follows:

[0082] S311: According to the path positioning information in the blockchain shard topology structure, extract the target block number field, detect the data structure content of the corresponding number block in the blockchain, parse the transaction index field group in the field set, and generate the transaction index sorting value group according to the ascending order of the timestamp field value;

[0083] According to the path positioning information provided in the blockchain sharding topology, first extract the target block number marked in the path structure diagram, such as the node path chain in the current topology is "shardID::blockIndex", the system identifies "09::5048" as the target block number 5048, then reads the block data structure content corresponding to the number from the blockchain database, locates the transaction index field group in the field set, each index in the field group contains transaction number, timestamp and field offset information, in the parsing process, the system extracts the hash positioning information and execution time information from each transaction record according to the field bit depth setting of 256 bits, then sorts all index fields according to the timestamp value, the sorting method is to convert the timestamp to integer type first and then perform ascending arrangement, for example, if the timestamps in the transaction record are 1620310020, 1620310000, 1620310060 and 1620310040 in turn, the sorted transaction queue numbers are TX002, TX001, TX004 and TX003, the system constructs the sequential execution structure queue after sorting, writes the transaction index sequence into the intermediate cache table, and attaches its original field offset position index and the block number as the auxiliary field, and finally obtains the transaction index sorting value group.

[0084] S312: Based on the sorted transaction operation queue in the transaction index sorting value group, read the node initiation address and target operation permission bit recorded by each transaction, retrieve the node role permission set in the chain network initialization configuration file, and use the formula:

[0085]

[0086] Calculate the permission offset matching degree If the matching degree is lower than the set permission error threshold, it is considered as permission matching success, record the matching state and node identifier of the current field, and obtain the permission matching level sequence, wherein, A g represents the access permission field value in the gth transaction, R g represents the permission level value in the gth node role permission set, W g is the weight coefficient corresponding to the gth role, T h represents the execution timestamp of the hth transaction, T0 represents the role permission set initialization timestamp, N is the number of transactions, and M is the number of participating role nodes.

[0087] Based on the sorted transaction operation queue in the transaction index sorting value group, the system extracts the initiating node address, permission request value and execution timestamp from each transaction record, reads the permission role mapping set in the chain network initialization configuration table, which includes node address, corresponding permission level value, weight factor and permission set initialization time field, and performs matching operation to judge whether the permission value of each transaction is less than or equal to the node role permission level. Before matching, the permission offset degree needs to be calculated first, using the following data for calculation, see Table 3:

[0088] Table 3: Permission matching calculation table According to the data in the table, the formula is:

[0089]

[0090] Among them, the offset part is:

[0091]

[0092] The sum is 0.6167

[0093] The time offset part is:

[0094]

[0095] The final offset matching degree is:

[0096]

[0097] If the permission error threshold is set to 80 (the value is set according to the maximum relative difference between the permission level and the access value, and the composite proportional conversion between the node weight fluctuation and the maximum time span offset limit in the chain network. The threshold is set by multiplying the maximum possible difference of the role permission level value (i.e. the maximum difference of 2 levels between the access permission value and the level difference) by the maximum weight coefficient 1.2, plus the square root value of the unit time offset within the maximum expected offset 60 seconds. The overall offset critical value will not fluctuate with a single transaction, but will be determined together with the permission set stable interval and the maximum role time limit. This value can be set according to the system security level, for example, the high sensitivity node is set to 60, and the low sensitivity node can be relaxed to 100), then 75.45 is less than the threshold, and it is judged that all records match successfully. The system records the permission level value and node identifier of each matching field to obtain the permission matching level sequence.

[0098] The permission offset matching degree is a comprehensive numerical index for measuring the matching degree between the access permission value in the chain network transaction request and the node role permission level, and the smaller the value is, the lower the deviation between the access permission and the role permission level is, which means that the node behavior fluctuates less within the authorized scope of the role, and the index also considers the time difference between the transaction execution time and the role permission setting time, and reflects the time effectiveness stability of the node permission behavior through the time offset item. Therefore, the index is not only used to judge the legality of a single transaction permission, but also used to evaluate the permission consistency of the entire node in multiple transactions and the compliance of the behavior, which is an important basis for determining whether the node permission state is stable and matched in the permission control.

[0099] The operation logic of the formula reflects the comprehensive measurement relationship between the permission value deviation and the time stability, wherein the first part calculates the absolute value of the relative deviation between the access permission value of each transaction and its corresponding role permission level, and performs weighted multiplication with the role weight coefficient, which reflects the permission offset strength of each node in the permission matching process, and the smaller the offset value is, the higher the matching degree is. This part accumulates the offset contribution of all transactions by summation. The second part adopts the form of summing the square of the timestamp difference and taking the square root, i.e., the Euclidean distance structure, to measure the time offset degree between the current transaction execution time and the permission set setting time, which represents the time effectiveness offset risk of the permission configuration. The sum of the two constitutes a unified offset matching degree index, and the final matching degree value below the threshold value means that the overall permission configuration and the access permission request have stable consistency. This structure integrates the structural offset (permission level comparison) and the time offset (request time effectiveness) in the same operation framework, and embodies the multi-dimensional permission tolerance logic.

[0100] S313: According to the matching state information recorded in the permission matching level sequence, the field matching identification table is constructed by combining the field bit identification and the permission matching result, the corresponding node identification field and the role permission level value are embedded, all record items are field-aligned and permission level-classified, and the role permission mapping relationship table is generated;

[0101] According to the matching state of each field in the permission matching level sequence, the system writes the record data into the permission mapping structure with the transaction number as the primary key. Each item in the structure contains the field bit number, permission level value and node identifier. Then the node grouping operation is performed to group the data belonging to the same node identifier into a group, and the binding index of the field and the permission is constructed. During the index construction process, the matching field needs to be aligned in bit depth. If the permission level of the field bound by a node is 3, 3, 2 and 4 respectively, the levels are sorted to form a level sequence. The node number is written into the mapping table as a secondary primary key. Each record generates a triple structure: "field index-permission level-node number". All triple structures are combined into a mapping matrix. The final output table records the binding relationship between the field and the node permission in the block. The role permission mapping relationship table is obtained.

[0102] Please refer to Figure 5 The specific steps of S4 are as follows:

[0103] S411: Based on the role permission mapping relationship table, the node number is extracted and the node access request list is constructed. The node number is matched and positioned by comparing the node number with the hash identifier in the ledger registration node list. The physical and virtual path fields bound by the matched node are extracted to generate a node storage path set.

[0104] Based on the bound field and node identifier content in the role permission mapping relationship table, the system extracts the node number field corresponding to each field in the mapping table in sequence, constructs a node access linked list, and then accesses the distributed ledger registration module to read the resource configuration index of all registered nodes, which includes node identifier, resource path information and content addressing state flag. The system matches the extracted node number with the ledger node identifier in the field value. The matching method is complete consistency judgment of the node number. After successful judgment, the path field of the matched node is called. The field points to the default write address in its registered distributed storage network and uses a standard content addressing structure to represent it. The field value is a writable path hash prefix. Since the path structure standard uses CIDv1 encoding form, the system needs to perform path format consistency check, that is, the path hash prefix needs to comply with the multi-byte Base32 encoding specification and have a legal content type identifier. In the example, node N12 returns the path hash "bafybei...". After successful matching, the system writes the node number and path hash record pairing result into the cache table, outputs the node path structure in the order of node number and merges it into the unified resource pool. At the same time, the address index set is generated by removing the path hash, forming the structure reference mapping between the node resource and the field, and establishing the node storage path set.

[0105] S412: According to the storage address information of each node in the node storage path set, the field content is allocated according to the mapped node number, the storage compatibility of the field content and the target node path is judged, the structured mapping of the field content and the storage location is performed, and the field storage mapping value group is obtained;

[0106] According to the storage address of each node in the node storage path set, the system retrieves the binding relationship between each field and its node from the permission mapping relationship, and sequentially imports the field content into the writing process according to the field number. Before writing, the system performs hash digest processing on the original content of the field to obtain a content hash value, and then uses a content addressing coding rule to convert the hash value into a storage identifier that can be recognized by the target node. The CID structure format is used to check the integrity of the prefix type and length, and if it meets the standard, the identifier is compared with the node path and a binding relationship is established. After writing is completed, the writing node identifier and field number index information are recorded, and the field number and node path pairing relationship is written into the structured result set to form a field reference group. In the example, field F001 maps to path "bafybei...", and field F002 corresponds to "bafybef...". Each field number and path pairing records the storage success status, forming a bidirectional reference structure mapping between field content and path, and generating a field storage mapping value group.

[0107] S413: According to the field storage mapping value group, convert the hash identifier value of each field into a resource identifier structure that meets the standard format, and construct a path ternary structure by combining the field content, resource identifier and the node to which it belongs, establish a field-oriented reverse tracking, and generate a decentralized storage path index;

[0108] According to the pairing information recorded in the field storage mapping value group, the system calls the field number and resource identifier pair in each record, reads the content hash identifier and performs resource structure conversion operation, converts the original CID structure into the NI resource format defined in RFC6920 standard, and the converted content form is "ni: / / / sha-256; Hash string". This format supports the uniqueness of resource identification and the traceability of path representation. The system constructs an index structure table with the field number as the index field, the node number as the primary key field, and the resource identifier as the value field. The three form a ternary combination of "field-node-resource". After sorting the field numbers in ascending order, output them to the main index set, and embed the complete node path field in the table structure to generate a resource matching main table with clear structure and locatable path. See Table 4:

[0109] Table 4 Field Path Pairing Table

[0110] Field number Node number Resource identifier F001 N12 ni: / / / sha-256;abc... F002 N15 ni: / / / sha-256;def... F003 N12 ni: / / / sha-256;ghi... F004 N16 ni: / / / sha-256;jkl...

[0111] As shown in Table 4, the field number and the resource identification constitute a complete distributed resource structure atlas, the node number and the field are one-to-one paired to form an address mapping table item, and finally all node mapping relationships are merged and output to obtain a decentralized storage path index.

[0112] Please refer to Figure 6 The specific steps of S5 are as follows:

[0113] S511: Based on the decentralized storage path index, the target node number of each field is extracted, and the node numbers are summarized to construct an initial to-be-detected path set. The extracted path target node is matched with the verification node set in the number field, the node path and the certificate record are bound and mapped, and a to-be-verified node path table is obtained.

[0114] Based on the information of the field path and the corresponding node number in the decentralized storage path index, the system extracts the node field according to the path index structure, constructs a node path list, and accesses the current registered verification node set in the chain network. Each record in the node set contains unique number, digital certificate, certificate issuing state, authority identifier and other attributes. The system takes the node number as a reference field to perform consistency comparison between the path list and the verification node set. The specific operation is to extract the node number field in the path and perform full value matching with all node number fields in the verification set. If the node specified by the path field exists in the verification set, the path is marked as a path that needs to be authenticated. The system further reads the digital certificate field of the corresponding node. The certificate structure needs to comply with the X.509v3 format standard. The fields in the certificate mainly include public key, usage range, validity period, certificate issuer, organization unit, identifier information, etc. The system pairs the extracted certificate information with the node path information and writes it into an intermediate cache structure table to form a mapping relationship between the node path and the certificate, which is used as an input source for subsequent verification. The output is a to-be-verified node path table.

[0115] S512: According to the to-be-verified node path table, the access authority label in each path record is parsed, the registered authority usage range field and the authentication agency field are read, the field comparison between the authority level and the certificate allowed operation level is performed, and it is judged whether the node has a conflict. The non-conflict node is numbered and recorded to generate a trusted storage node list.

[0116] According to the records in the path table of the to-be-verified node, the system reads the access path, node number, permission tag and corresponding certificate structure in each record, extracts the permission tag content in the path field, which is generally represented in binary structure to support the combination of operation permissions such as reading, writing and forwarding, and is encoded in bit value form, then the system reads the extension field and organization unit identifier in the certificate structure, and compares the operation types in the permission tag with the allowed operation field in the certificate one by one, if the bit value in the path permission tag does not exceed the allowed operation field in the certificate, the path and the certificate are marked as permission consistent; if it exceeds or does not match, it is marked as a permission conflict record. When performing this process, the bit depth, position and meaning of the permission field need to be clearly judged to avoid misjudgment due to differences in bit values. After the system completes the comparison, it extracts all the node numbers and path information consistent with the permissions into the cache list, removes the data items marked with conflicts from the cache list, and finally obtains the list of trusted storage nodes.

[0117] S513: According to the list of trusted storage nodes, a field mapping structure between the path and the verification state is established, the field integrity of each record is checked, and a data integrity verification report is output;

[0118] According to the path and node pairing data in the list of trusted storage nodes, the system calls the path access record to write into the log structure body. The log field structure includes node number, path identifier, certificate state, permission matching result and other contents. Then the record table structure is uniformly arranged into a three-field combination structure, the field order is "node number", "path identifier" and "verification state", and the verification state can be consistent, conflict or unknown. The system uniformly checks the field integrity after log writing, excludes structure missing records, and retains the verification result records with complete fields and consistent permissions. The system arranges the log structure table items in ascending order of node number and outputs the data integrity structure map, forming a matching mapping result table of node-path-state, see Table 5:

[0119] Table 5 Data integrity verification result table

[0120] Node number Path identification Verification status ND01 / ipfs / aaa Consistent ND02 / ipfs / bbb Consistent ND03 / ipfs / ccc Conflict ND04 / ipfs / ddd Consistent

[0121] As shown in Table 5, the verification state corresponding to each node path recorded by the system is clearly indicated, and the verification state field will be exported as a result item. The system generates a complete authentication audit master record set based on the verification structure and outputs a data integrity verification report.

[0122] The above merely describes the preferred embodiments of the present application, and is not intended to limit the present application in other forms. Any skilled person in the art can modify or change the disclosed technical content into equivalent embodiments with equivalent changes, and apply them to other fields. However, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present application, without departing from the technical solution content of the present application, still falls within the protection scope of the present application.

Claims

1. A method for protecting the core data security of property rights registration based on blockchain technology, characterized in that, Includes the following steps: S1: Obtain the registrant's digital identity certificate, institutional certification information, and timestamp data; concatenate the fields; embed the block metadata fields; establish corresponding marker bits and blockchain transaction address binding information; and generate on-chain identity anchors. S2: Based on the on-chain identity anchor, search for transaction-related historical blocks, compare the block sequence number with the current block hash pointer to perform consistency verification, establish chain association relationship and mark shard identifier and cross-chain index to obtain the blockchain shard topology structure; S3: Based on the blockchain sharding topology, perform transaction index sorting on the block field set, extract the initial node role permission set of the chain network and perform permission matching, record the role permission level and node identifier of the matched field, and generate a role permission mapping relationship table. S4: Based on the role permission mapping relationship table, query the node storage path, perform write operations on each matching field, establish a distributed storage reference, and obtain a decentralized storage path index; S5: Based on the decentralized storage path index, detect the matching relationship between the corresponding digital certificate and the access permission tag for each path, mark the trusted storage node, and generate a data integrity verification report.

2. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that: The on-chain identity anchor includes the identity credential hash value, blockchain transaction address binding information, and block metadata hash digest. The blockchain sharding topology includes the original block pointer reference, the new block association marker, the shard ID identifier, and the cross-chain index label. The role and permission mapping relationship table includes the field permission level, the node role identifier, and the permission access label set. The decentralized storage path index includes the distributed storage reference address, the content addressing identifier, and the node storage path hash. The data integrity verification report includes the trusted node identifier list, the path permission consistency result, and the digital certificate matching status.

3. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that, The specific steps for obtaining the on-chain identity anchor are as follows: S111: Obtain the registrant's digital identity certificate, institution authentication information, and timestamp data submitted during the property registration process. Concatenate the registrant's digital identity certificate field and the institution authentication information field, and combine them with the timestamp data to complete the data structure combination and obtain the field combination data block. S112: Based on the data block of the field combination, perform unified encoding processing on all content and one-way encryption processing. By constructing the embedding relationship between the encryption structure and the metadata field, obtain the hash embedded ciphertext value. S113: Based on the hash embedded ciphertext value, establish a mapping relationship between the embedded position in the block metadata and the blockchain transaction address, identify the marker bit and complete the address binding, and generate an on-chain identity anchor.

4. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that, The specific steps for obtaining the blockchain sharding topology are as follows: S211: Based on the marker content in the on-chain identity anchor, extract the hash recognition field and the corresponding transaction index, map and match it with the on-chain historical transaction records, filter historical blocks with transaction interaction relationships, and generate a transaction-related block sequence; S212: Based on all historical block numbers and hash fields in the transaction-related block sequence, establish a hash chain mapping relationship between historical blocks and the current block, calculate the block consistency offset, and if it is lower than the offset consistency tolerance threshold, establish a mapping path to obtain the blockchain chain mapping result. S213: Based on the blockchain chain mapping result, construct the chain connection index relationship between the original block and the currently registered block, collect the shard structure header field to which the current block belongs, parse the shard ID according to the field content, parse the cross-chain address segment and cross-chain pointer, and obtain the blockchain shard topology structure.

5. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that, The specific steps for obtaining the role permission mapping table are as follows: S311: Based on the path location information in the blockchain sharding topology, extract the target block number field, detect the data structure content of the corresponding numbered block in the blockchain, parse the transaction index field group in the field set, and reorder it in ascending order according to the timestamp field value to generate a transaction index sorting value group. S312: Based on the sorted transaction operation queue in the transaction index sorting value group, read the node initiation address and target operation permission bit of each transaction record, retrieve the node role permission set in the chain network initialization configuration file, calculate the permission offset matching degree, if the matching degree is lower than the set permission error threshold, it is considered that the permission matching is successful, record the matching status of the current field and the node identifier, and obtain the permission matching level sequence. S313: Based on the matching status information recorded in the permission matching level sequence, construct a field matching identifier table by combining the field bit identifier and the permission matching result, embed the corresponding node identifier field and role permission level value, align all record items by field and classify permission levels, and generate a role permission mapping relationship table.

6. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that, The specific steps for obtaining the decentralized storage path index are as follows: S411: Based on the role permission mapping table, extract the node number and construct a node access request list. Compare the node number with the hash identifier in the ledger registration node list to locate the node. Extract the physical and virtual path fields bound to the successfully matched node and generate a node storage path set. S412: Based on the storage address information of each node in the node storage path set, the field content is allocated according to the mapped node number, the storage compatibility between the field content and the target node path is determined, and a structured mapping between the field content and the storage location is performed to obtain the field storage mapping value group. S413: Based on the field storage mapping value group, convert the hash identifier value of each field into a resource identifier structure that conforms to the standard format, and jointly construct a path ternary structure with the field content, resource identifier and the node to which it belongs, establish reverse tracing oriented to the field, and generate a decentralized storage path index.

7. The method for protecting the core data security of property rights registration based on blockchain technology according to claim 1, characterized in that, The specific steps for obtaining the data integrity verification report are as follows: S511: Based on the decentralized storage path index, extract the target node number of each field, summarize the node numbers to construct an initial path set to be detected, match the extracted path target nodes with the verification node set by the number field, bind and map the node path with the certificate record, and obtain the node path table to be verified. S512: Based on the path table of nodes to be verified, parse the access permission tag in each path record, read the registered permission scope field and certification authority field, compare the fields according to the permission level and the certificate allowed operation level, determine whether there is a conflict between nodes, number and organize the nodes without conflict and collect the records to generate a trusted storage node list. S513: Based on the trusted storage node list, establish a field mapping structure between the path and the verification status, perform field integrity verification on each record, and output a data integrity verification report.

Images