A cloud data access method and system

Abstract

The application discloses a cloud data access method and system, and particularly relates to the technical field of cloud data access, and comprises the following steps: acquiring a terminal field access message, searching a table index by a header table code to position a cloud table, searching a field index by a field area to position a field node, reading a terminal root first and a terminal meaning position second along a report tail, reading a signature at the end of a reading action code, and generating an access bit; reading a field definition record by the access bit, obtaining a title bit by hashing a field title first, obtaining a source bit by hashing a source path with the title bit, obtaining a unit bit by hashing a unit code with the source bit, obtaining a caliber operator bit by hashing a caliber operator with the unit bit, obtaining a cloud meaning bit by hashing a desensitization number with the caliber operator bit, generating the cloud meaning bit by the field definition record, and obtaining a cloud root by a Merkel hash tree algorithm, and then combining a bifurcation linear consistency checking algorithm, a rule public key signature verification, and a rule action comparison to complete end-cloud collaborative determination.

Description

Technical Field

[0001] This invention relates to the field of cloud data access technology, and more specifically, to a cloud data access method and system. Background Technology

[0002] Existing cloud data access technologies mainly revolve around remote reading of cloud data by multiple terminals, verification of access identity, and recording of access behavior. In engineering implementation, the terminal usually submits an access request, and after the cloud gateway completes identity authentication and permission comparison, the cloud database returns the corresponding data. In scenarios such as mobile office, on-site inspection and cross-regional collaborative operation, access terminals are often in environments with weak networks, frequent network switching and multiple people concurrently reading the same business data. This requires that permission changes be applied to access requests in real time, that the data obtained by the terminal be consistent with the cloud data version, and that the access response not be significantly slower due to repeated authentication and version comparison. In such scenarios, existing centralized access links are prone to problems such as increased request queuing time, repeated authentication by the same terminal in a short period of time, the terminal still reading the old version of data even though the cloud has been updated, and short-term access records of old permissions still exist after permission adjustments. The root cause is that access identity, permission status, data version and terminal access context are handled independently by different links. The terminal side only undertakes request initiation and result reception, and does not participate in the collaborative verification of the status required for access determination. The technical problem this application aims to solve is: how to enable cloud data access to simultaneously meet the requirements of immediate permission activation, consistent data version, and low-latency response under end-to-end cloud collaboration. Summary of the Invention

[0003] To overcome the aforementioned deficiencies in the prior art, embodiments of the present invention provide a cloud data access method and system. This method generates access bits by parsing terminal field access messages, generates cloud definition bits based on field definition records, obtains the cloud root using a Merkle hash tree algorithm, and then combines a fork linear consistency check algorithm, rule public key verification, and rule action comparison to complete end-cloud collaborative determination, thereby solving the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a cloud data access method, comprising: S1. Obtain the terminal field access message, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the terminal root first and then the terminal definition bit along the tail of the message, continue reading the action code and read the signature at the end, and generate the access bit. S2. Read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the cloud definition bit. S3. Using the Merkle hash tree algorithm, the cloud-defined bit is written to the target leaf bit. The sibling hash is read layer by layer from the target leaf bit to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. S4. Perform the bifurcation linear consistency check algorithm with the terminal root and the cloud root. Use the terminal root as the current root to check the root book. If the current root is equal to the cloud root, output the linear position. If the same previous root is connected to different subsequent roots, output the bifurcation position. If there is only one subsequent root, rewrite the current root as the subsequent root and continue checking. If there is no subsequent root and the current root is not equal to the cloud root, output the difference root position. S5. According to the access bit, read the access rule, verify the signature value with the rule public key, and generate the rule bit when the rule action and action code have the same value. In the end-cloud collaborative judgment, when the linear bit is output and the signature value and the rule bit are both one, the end definition bit is equal to the cloud definition bit, return the field value and write back the cloud root and cloud definition bit. When they are not equal, return the meaning update record and write back the cloud root and cloud definition bit. When the difference root bit is output, return the root reconnection record. When the fork bit is output, refuse to return the field value. When the signature value is zero, refuse to return. When the rule bit is zero, refuse to return.

[0005] In a preferred embodiment, S1 includes: S11. After obtaining the terminal field access message, convert the first two bytes into the header length in big-endian order. Starting from the third byte, extract the header length minus two bytes as the table code. Perform SHA256 operation on the table code to obtain the table key. In the table index arranged in lexicographical order of the table key, divide the sum of the start row number and the end row number by two to obtain the middle row number. If the middle row table key is equal to the table key, output the cloud table row number. If the middle row table key is before the table key, change the start row number to the middle row number plus one. If the middle row table key is after the table key, change the end row number to the middle row number minus one. Repeat the search until the cloud table row number is output. When the start row number is equal to the end row number plus one, output the missing table position. Big-endian means that multi-byte integers are interpreted from left to right according to their byte positions, with the first byte written to the binary bits 15 to 8 and the second byte written to the binary bits 7 to 0. The process of converting the big-endian order to the header length is as follows: read the first byte of the field access message and denote it as B1, read the second byte and denote it as B2, shift B1 left by 8 bits and perform a bitwise OR operation with B2, and use the resulting unsigned integer as the header length; SHA256 is a secure hash algorithm that performs a 256-bit hash on an input byte string and outputs a 32-byte hash value. The same input byte string will produce the same 32-byte hash value. The process of performing SHA256 operation is as follows: append a binary 1 to the input byte string, then append a binary 0 until the length satisfies the modulo 512 of 448, then append 64 bits of the original input length, group the input into 512 bits and iterate group by group using SHA256 initial vector, round constant and compression function, and the last round outputs 8 32-bit words concatenated into a 32-byte result; Table key lexicographical order means that all table keys in the table index are 32-byte values. When sorting, the keys are compared byte by byte from byte 1 to byte 32. If a different byte appears first, the order of the two table keys is determined by the natural value of that byte from 0 to 255. Table keys with all 32 bytes being the same are called table keys with the same value. Row number refers to the sequential number of a record in a table index or field index. The first record is numbered 0, and the next record is numbered 1 of the previous record. The cloud table row number is used to point to a cloud table record in the table index. S12. When no missing field is output, the header length points to the start of the field area. Two bytes are read from the start of the field area and converted into the field length. Starting from the start of the field area plus two bytes, the field name is extracted according to the field length. The table code and the field name are subjected to SHA256 to obtain the field key. The field key is searched in the field index pointed to by the row number of the cloud table by halving the first and last rows. When a field key with the same value is found, the field node number is output. When no field key with the same value is found, the missing field is output. The field area refers to the byte area immediately following the header in the field access message. The first two bytes of the field area record the field length, and the field name is stored according to the field length starting from the third byte. The starting point of the field area is determined by the header length. S13. When the missing bit of the field is not output, 64 bytes are truncated from the end of the field access message to obtain the signature, then 2 bytes are truncated from the end to obtain the action code, and then 32 bytes are truncated from the end to obtain the end definition bit. Then 32 bytes are truncated from the end to obtain the end root bit. Using the field node number as the pointer segment, SHA256 is performed on the end root bit to obtain the root bit. The end definition bit is connected to the root bit hash to obtain the end definition bit. The action code is connected to the end definition bit hash to obtain the action bit. The signature is connected to the action bit hash to obtain the end check bit. The pointer segment is connected to the end check bit to generate the access bit.

[0006] In a preferred embodiment, S2 includes: S21. Read the field node number using the pointer segment in the access bit, locate the field node according to the field node number and read the field definition record, and set the read bit to the first byte of the field definition record; the access platform reads two bytes from the read bit and converts them to the current field length in big-endian order, shifts two bytes from the read bit and extracts the byte corresponding to the current field length as the field title, and then rewrites the read bit to the byte after the field title. The field definition record refers to the field description data block pointed to by the field node. The record start position stores the field title, source path, unit code, caliber operator and desensitization number in the order of writing. A two-byte length value is set before each field value. The access platform extracts the field value segment by segment according to the length value and uses the extracted field value to generate the cloud definition bit. S22. Continue reading along the read position. Each time, read two bytes from the read position and convert them to the current field length in big-endian order. Move two bytes after the read position and extract the byte corresponding to the current field length as the current field value. Then rewrite the read position to the byte after the current field value. After the first rewrite of the read position, obtain the source path. After the second rewrite of the read position, obtain the unit code. After the third rewrite of the read position, obtain the caliber operator. After the fourth rewrite of the read position, obtain the desensitization number. S23. Perform SHA256 operation on the field title to obtain the title bit. Attach the source path after the title bit to obtain the source input and perform SHA256 operation to obtain the source bit. Attach the unit code after the source bit to obtain the unit input and perform SHA256 operation to obtain the unit bit. Attach the caliber operator after the unit bit to obtain the caliber input and perform SHA256 operation to obtain the caliber bit. Attach the desensitization number after the caliber bit to obtain the desensitization input and perform SHA256 operation to obtain the cloud-defined bit. Then write the cloud-defined bit into the field node.

[0007] In a preferred embodiment, S3 includes: S31. Write the cloud-defined bit into the target leaf position and set it as the current hash. Read the leaf number of the target leaf position as the current sequence number. Read the root layer number of the field tree as the stop layer number. Calculate the current sequence number and XOR it with one bit to get the sibling sequence number. Calculate the current sequence number and shift it right by one bit to get the parent sequence number. Write the current sequence number, sibling sequence number and parent sequence number into the path entry. Then rewrite the current sequence number with the parent sequence number and increment the layer number by one. If the layer number is different from the stop layer number, continue to generate path entries. If the layer number is equal to the stop layer number, output the root path table. The field tree refers to the Merkle hash tree that the access platform builds for the cloud table field definition records. Each leaf node in the leaf layer corresponds to a field node. The leaf node stores the cloud definition bits generated by the field node. The parent node stores the hash value obtained by concatenating the hashes of the two child nodes in order and then performing SHA256 operation. Each node is located by both the layer number and the sequence number. The root level number refers to the number of the level where the root node is located in the field tree. The leaf level number is zero. The level number is incremented by one when moving up one level from the leaf level until there is only one root node. The corresponding level number is written as the root level number. The stopping level number in S31 is the root level number, which is used to limit the end point of the operation from the target leaf position back to the root of the field tree. S32. Read the path entries according to the generation order of the root path table, read the sibling hash corresponding to the sibling sequence number from the field tree, and copy the current hash as the sibling hash if the sibling sequence number is not recorded. If the last digit of the current sequence number is zero, append the current hash to the sibling hash to form a concatenation. If the last digit of the current sequence number is one, append the sibling hash to the current hash to form a concatenation. Then append the layer number to the parent sequence number and the concatenation to form the layer input. Perform SHA256 operation on the layer input to obtain the parent hash, and rewrite the current hash with the parent hash. The sibling hash refers to the hash value of another node that shares the same parent node with the current node at the same level of the field tree. The index of the sibling node is obtained by bitwise XORing the current index with a bit. When the field tree does not record a sibling node, the sibling hash is a copy of the current hash, which is used to calculate the parent hash according to the concatenation rules of S32.

[0008] In a preferred embodiment, S3 further includes: S33. Perform consistency error correction on the path item. First, write the result of the sibling sequence number being equal to the current sequence number and one bitwise XORed as the sibling check bit. Then, write the result of the parent sequence number being equal to the current sequence number shifted right by one bit as the parent check bit. Then, write the result of the current sequence number of the next path item being equal to the parent sequence number as the continuation check bit. Perform a bitwise AND operation on the sibling check bit, parent check bit, and continuation check bit to obtain the path check bit. When the path check bit is one, retain the current hash. When the path check bit is zero, reread the node hash corresponding to the current sequence number and the sibling hash corresponding to the sibling sequence number from the field tree, and recalculate the current hash according to the layer input generation rules in S32. When the root path table is processed, output the cloud root with the current hash.

[0009] In a preferred embodiment, S4 includes: S41. Write the end root as the current root; when the current root is equal to the cloud root, output the linear bit; when the current root is not equal to the cloud root, use the current root to perform an equal value search in the previous root index of the root book. Each row of the root book consists of a previous root segment, a subsequent root segment, and a continuation bit segment. For each row retrieved, perform SHA256 operation on the previous root segment followed by the subsequent root segment to obtain the check bit. When the check bit is equal to the continuation bit byte by byte, write the subsequent root segment and the continuation bit segment into the candidate table. The preceding root index refers to the lookup structure built in the root book with the preceding root segment of each row as the key. The preceding root index records the correspondence between the preceding root segment and the row number of the root book. When querying the preceding root index with the current root, the root book row number of the preceding root segment is output byte by byte. The front root segment, the back root segment, and the successor segment refer to three data segments stored in fixed byte order in each row of the root book. The front root segment is the 32-byte field tree historical root, the back root segment is the 32-byte field tree successor root generated by continuing from the historical root, and the successor segment is the 32-byte checksum obtained by performing SHA256 operation after connecting the front root segment and the back root segment. S42. Perform a fork determination on the candidate table. When there are no rows in the candidate table, output the difference root bit. When there are two rows in the candidate table with different root segments byte by byte, output the fork bit. When the root segments of each row in the candidate table have the same value byte by byte, record the current root as the edge before root, record the root segment of the first row of the candidate table as the edge after root, and search for the root edge item in the root path table where the before root cell is equal to the edge after root. When the root edge item is found, output the difference root bit. When the root edge item is not found, write the edge before root, edge after root, and the continuation bit segment of the first row of the candidate table into a new row of the root path table. The root cell refers to the fixed cell in the root path table used to store the 32-byte root value. The previous root cell is written with the previous root of the edge, and the next root cell is written with the next root of the edge. Each root cell is located by the row number and cell name of the root path table. The root edge entry refers to a continuation record in the root path table. This row consists of a front root cell, a back root cell, and a continuation cell. The front root cell stores the front root of the edge that has passed the verification in this round, the back root cell stores the back root of the edge connected by the front root, and the continuation cell stores the continuation segment in the corresponding root book row.

[0010] In a preferred embodiment, S4 further includes: S43. Perform reverse verification along the edge-after-root; use the edge-after-root to query the root index of the root book, perform SHA256 operation on each row obtained by connecting the previous root segment and the next root segment to obtain the reverse verification bit. If there is a root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is different from the previous root edge byte by byte, output the fork bit. If there is no root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is equal to the previous root edge byte by byte, output the difference root bit. If there is a root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is equal to the previous root edge byte by byte, rewrite the current root with the edge-after-root. If the current root is equal to the cloud root, output the linear bit. If the current root is not equal to the cloud root, return to S41. The back root index refers to the lookup structure built in the root book with the back root segment as the key. The back root index records the correspondence between the back root segment and the root book row number. When querying the back root index using the edge back root, the output of the back root segment is equal to the root book row number of the edge back root byte by byte. A root entry is a single record in the root book, which contains a preceding root segment, a following root segment, and a continuation bit segment. Root entries are used to represent the continuation relationship of a primary field tree root from the preceding root segment to the following root segment, and the continuation bit segment is used to verify that the continuation relationship has not been overwritten.

[0011] In a preferred embodiment, S5 includes: S51. Locate the field node using the pointer segment in the access bit, read the rule page number from the field node, extract the rule public key first by reading the bit in the rule page, then extract the rule action, then extract the value page pointer, then extract the meaning page pointer, and finally extract the reconnection page pointer at the last bit to generate the access rule. The rule page number refers to the rule page location value stored in the field node. The rule page number points to a page of access rule data. The rule page start position stores the rule public key, rule action, value page pointer, meaning page pointer and reconnection page pointer in the order of reading position. The rule public key is the elliptic curve public key registered in the rule page, used to verify the signature in the field access message; the rule action is the field access action code registered in the rule page, used to compare it byte by byte with the action code in the field access message. The value page pointer, meaning page pointer, and reconnection page pointer refer to the page address within which the value page pointer points to the starting byte of the field value record, the meaning page pointer points to the page address within which the meaning update record points to the starting byte of the meaning update record, and the reconnection page pointer points to the page address within which the root reconnection record points to the starting byte of the root reconnection record. Each page address consists of a page number segment and an offset segment. The page number segment locates the data page, and the offset segment locates the starting byte within the data page. S52. Connect the root end to the end definition bit, then the action code, then the cloud root, then the cloud definition bit, and perform SHA256 operation to obtain the digest. Convert the first half of the signature into the first signature number and the second half of the signature into the second signature number. Use the rule public key to perform elliptic curve verification on the digest, the first signature number, and the second signature number. If the verification passes, output the verification value 1; if the verification fails, output the verification value 0. The process of performing elliptic curve verification on the digest, first signature, and second signature using the rule public key is as follows: The curve order and base point of the elliptic curve are read. If the first or second signature does not belong to the curve order minus one, the verification value is zero. If the first and second signatures belong to the curve order minus one, the modulo inverse of the second signature with respect to the curve order is calculated. The modulo inverse is multiplied by the digest and the first signature respectively, and the remainder is taken with respect to the curve order to obtain the first and second verification coefficients. The first verification coefficient multiplied by the base point and the second verification coefficient multiplied by the rule public key are added to obtain the verification point. The x-coordinate of the verification point is taken with respect to the curve order to obtain the verification x-coordinate. If the verification x-coordinate is equal to the first signature, the verification value is one; if the verification x-coordinate is not equal to the first signature, the verification value is zero.

[0012] In a preferred embodiment, S5 further includes: S53. Compare the rule action with the action code byte by byte. If the values ​​are the same, output the rule bit as 1. If the values ​​are different, output the rule bit as 0. When outputting the linear bit, AND the check value with the rule bit to generate the access bit. If the access bit is 1 and the endpoint bit is equal to the cloud bit, output the value read bit. If the access bit is 1 and the endpoint bit is not equal to the cloud bit, output the access bit. S54. When outputting the value read bit, the field value is read according to the value page pointer and returned to the terminal. When outputting the meaning update bit, the meaning update record is read according to the meaning page pointer and returned to the terminal. When outputting the difference root bit, the root reconnection record is read according to the reconnection page pointer and returned to the terminal. When outputting the fork bit, if the signature value is zero or the rule bit is zero, the field value is refused to be returned. After the value read bit or the meaning update bit is output, the cloud root is written to the terminal root position and the cloud meaning bit is written to the terminal meaning bit position. The meaning update record refers to the data record pointed to by the meaning page pointer. The record stores the field definition record content, cloud root, cloud bit and field node number corresponding to the cloud bit. It is used to explain to the terminal the specific changes in the field meaning when the end bit and cloud bit are inconsistent, and to allow the terminal to write back the end root and end bit. The root reconnection record refers to the data record pointed to by the reconnection page pointer. The record stores the terminal root, cloud root, and the root book row number sequence required to connect from the terminal root to the cloud root. When the differential root bit is output, the terminal updates the local terminal root according to the root reconnection record so that the next field access message carries the terminal root that can connect to the cloud root.

[0013] A cloud data access system includes an access location module, a meaning generation module, a root tree generation module, a linearity check module, and a collaborative return module. The access positioning module is used to obtain terminal field access messages, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the end root first and then the end definition bit along the tail of the message, read the action code and then read the signature to generate the access bit. The meaning generation module is used to read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the meaning bit. The root generation module is used to write the cloud-defined bit to the target leaf position using the Merkle hash tree algorithm. It reads the sibling hash layer by layer from the target leaf position to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. The linearity check module is used to perform a bifurcation linearity consistency check algorithm with end roots and cloud roots. It uses the end root as the current root to check the root book. If the current root is equal to the cloud root, it outputs the linear position. If the same preceding root is connected to different following roots, it outputs the bifurcation position. If there is only one following root, it rewrites the current root as the following root and continues to check. If there is no following root and the current root is not equal to the cloud root, it outputs the difference root position. The collaborative return module is used to read access rules based on access bits, verify the signature value by checking the rule public key, and generate rule bits when the rule action and action code have the same value. In the end-cloud collaborative determination, when the linear bit is output and both the signature value and the rule bit are one, the end definition bit is equal to the cloud definition bit, the field value is returned and the cloud root and cloud definition bit are written back. When they are not equal, the meaning update record is returned and the cloud root and cloud definition bit are written back. When the difference root bit is output, the root reconnection record is returned. When the fork bit is output, the field value is rejected. When the signature value is zero, the return is rejected. When the rule bit is zero, the return is rejected.

[0014] The technical effects and advantages of this invention are as follows: This solution uses the terminal root and terminal definition bits to participate in the determination of the field access message, so that the terminal status is verified in the same chain as the cloud root and cloud definition bits, which relatively alleviates the reading of old permissions and old versions and repeated back-transmission verification. Generate cloud-defined bits for field titles, source paths, unit codes, caliber operators, and desensitization numbers, so that changes in meaning can still be identified even when the field name remains unchanged, reducing the risk of misinterpreting fields; Write cloud definitions to the leaf positions of the field and calculate the cloud root layer by layer, so that changes in field definitions are transformed into differences in the root, thus improving the consistency verification of field-level indexes. In the root book, the preceding root segment, the following root segment, and the continuation segment mutually verify the continuation chain. If the same preceding root is found to have multiple following roots or a broken chain, the error return caused by the historical fork in the field definition is relatively suppressed. By verifying signatures with the rule public key and comparing them with the rule actions before routing the data back, the access identity, access action, and field status jointly constrain the reading of field values, thus improving field-level access control. Attached Figure Description

[0015] Figure 1 This is a flowchart of the access location and cloud identity generation process of the present invention; Figure 2 This is a flowchart of the field tree cloud root generation process of the present invention; Figure 3 This is a flowchart illustrating the bifurcation linear consistency and edge-cloud collaborative return process of the present invention. Figure 4 This is a schematic diagram of the system module structure of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Refer to the instruction manual appendix Figure 1-4 The present invention provides a cloud data access method, comprising: S1. Obtain the terminal field access message, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the terminal root first and then the terminal definition bit along the tail of the message, continue reading the action code and read the signature at the end, and generate the access bit. When a terminal field access message enters the access location, the message begins with a header, the field area follows the header, and the message tail stores the root endpoint, endpoint definition bit, action code, and signature in order from front to back. When the processing end reads the message tail from the end of the message, the order of the obtained bits is signature, action code, end definition bit and end root. Then, the fixed order of end root, end definition bit, action code and signature is still used to generate access bits. This process merges cloud table location, field node location, and tail material access into a single field access location, enabling subsequent field definition record reading to continue along the access bit. The header parsing is responsible for cloud table positioning. After obtaining the terminal field access message, S11 reads the first two bytes of the field access message, records the first byte as B1, records the second byte as B2, shifts B1 left by eight bits in big-endian order, and performs a bitwise OR operation with B2 to obtain the header length. If the field access message is less than two bytes, return the record with a missing message header and stop reading the table index; after the message header length is generated, extract two bytes from the third byte of the message header length as the table key, and perform SHA256 operation on the table key to obtain a 32-byte table key; Table indexes are arranged in lexicographical order of the table keys. The lexicographical order of the table keys is determined by comparing each byte from the first byte to the thirty-second byte. When different bytes appear first, the order is determined by the natural value of that byte from 0 to 255. If all 32 bytes are the same, it is a table key with the same value. When retrieving the table index, the starting row number is set to zero, and the ending row number is set to the number of table index records minus one. When the number of table index records is zero, the table missing bit is output. When the number of table index records is not zero, the sum of the starting row number and the ending row number is divided by two to obtain the middle row number. The table key of the middle row is read and compared byte by byte with the table key. When the middle row table key is equal to the table key, the middle row number is output as the cloud table row number. When the middle row table key is before the table key, the starting row number is rewritten as the middle row number plus one. When the middle row table key is after the table key, the ending row number is rewritten as the middle row number minus one, and the search continues according to the rewritten starting and ending row numbers. When the starting row number equals the ending row number plus one, the table missing digit is output. After the table missing digit is output, the missing records of the table are returned to the terminal, and field index reading is stopped. After the cloud table location is completed, the byte content of the field area is entered into the field node retrieval. S12 determines the starting point of the field area with the header length. The first two bytes of the field area record the field length. Starting from the third byte of the field area, the field name is stored according to the field length. If the field area is less than two bytes, the missing field area record is returned and the field key generation is stopped. After obtaining the field length in big-endian order, the corresponding bytes of the field length are extracted starting from the field area two bytes after the starting point and used as the field name. If the remaining bytes in the field access message cannot cover the corresponding bytes of the field length, return the record with the missing field name and stop reading the field index; After obtaining the field name, append the table code before the field name to form the field key input. Perform SHA256 operation on the field key input to obtain a 32-byte field key; read the cloud table record pointed to by the cloud table row number, and search for the field key in the field index associated with the cloud table record in lexicographical order by binary search. When the number of records in the field index is zero, output the missing field bit; when the number of records in the field index is not zero, divide the sum of the start row number and the end row number by two to get the middle row number, read the field key of the middle row and compare it byte by byte with the field key; If the field key in the middle row is equal to the field key, output the field node number; if the field key in the middle row is before the field key, rewrite the starting line number; if the field key in the middle row is after the field key, rewrite the ending line number and continue searching until the output field node number is reached. When the starting row number equals the ending row number plus one, the missing field bit is output. After the missing field bit is output, the missing field record is returned, and the reading of field definition record, generation of cloud definition bit, generation of cloud root, root consistency check and end-to-cloud collaboration determination are stopped. The tail material is used to incorporate the end-side status into the access bits. After the field node number has been output, S13 is executed. Sixty-four bytes are truncated from the end of the field access message as a signature, then two bytes are truncated from the end as an action code, and then thirty-two bytes are truncated from the end as an end definition bit. Finally, thirty-two bytes are truncated from the end as the end root. If the remaining bytes of the field access message during reverse interception cannot cover the fixed length of the signature, action code, end definition bit, and end root, return the tail missing record and stop access bit generation; After the message tail content is extracted, the field node number is written to the pointer segment. SHA256 operation is performed on the root bit to obtain the root bit. The end-definition bit is appended after the root bit to form the end-definition input and SHA256 operation is performed to obtain the end-definition bit. The action code is appended after the end-definition bit to form the action-definition input and SHA256 operation is performed to obtain the action-definition bit. The signature is appended after the action-definition bit to form the end-verification input and SHA256 operation is performed to obtain the end-verification bit. Finally, the pointer segment is appended before the end-verification bit to generate the access bit. The pointer segment in the access bit is used to locate the field node, field definition record and access rules later, and the check bit is used to fix the access order of the root end, end definition bit, action code and signature in this field access message; After header parsing, field area parsing, and tail material access, the terminal field access message is converted into access bits that can be used to subsequently read field definition records and access rules; Missing table bits, missing field bits, missing header records, missing field area records, missing field name records, and missing tail records are all returned before the access bits are generated, so that subsequent processing is only performed when the cloud table, field node, and tail material have been determined. Taking the "Amount" field in the "Order Table" of the cloud table as an example, the header is written with the corresponding table code of the "Order Table", the field area is written with the corresponding field name of "Amount", and the tail is stored according to the root end, the endpoint, the action code and the signature. The processing end first generates a table key from the table code and retrieves the cloud table row number. Then, it generates a field key from the table code and field name and retrieves the field node number. Subsequently, it obtains the end root, end definition bit, action code, and signature from the tail of the message and generates an access bit. The next processing stage reads the field definition record corresponding to "amount" and calculates the cloud definition bit based on this.

[0018] S2. Read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the cloud definition bit. The field meaning generation stage is used to convert the field description content in the field node into a cloud meaning bit, so that the subsequent Merkle hash tree algorithm can use the field meaning change as the input of the leaf node; The field definition records are saved in a fixed order, including field title, source path, unit code, caliber operator, and desensitization number. Each field value is preceded by a two-byte length value. The access platform extracts field values ​​segment by segment by reading bits, and stops generating cloud-defined bits when any length value or field value cannot be completely read, to avoid continuing to generate incorrect cloud-defined bits when the field definition record is incomplete; the specific processing flow is as follows; The reading of field definition records begins from the pointer segment of the access bit. In S21, the access platform first reads the field node number from the pointer segment of the access bit with a fixed length, then locates the field node according to the field node number, and reads the starting address of the field definition record from the field node. The starting byte of the field definition record is written as the read bit, which is used to mark the position of the next read length value. Before reading the field title, the access platform first checks whether the field definition record can cover the two-byte length value starting from the read position. If it cannot be covered, it outputs the definition missing bit and stops S2. If it can be covered, read two bytes from the read position and convert them to the current field length in big-endian order. Then check whether the field definition record can cover the bytes corresponding to the current field length starting from the position two bytes after the read position. If it cannot be covered, output the definition missing bit and stop S2. If it can be covered, extract the byte corresponding to the current field length as the field header, and then rewrite the read bit to the byte after the field header; The field definition record is the field description data block pointed to by the field node. The record starts by storing the field title, source path, unit code, caliber operator and desensitization number in the order of writing. The field title is used to indicate the field name displayed on the terminal, the source path is used to indicate the position of the source column of the field value in the cloud table, the unit code is used to indicate the unit expression of the field value, the caliber operator is used to indicate the statistical generation method of the field value, and the desensitization number is used to indicate the desensitization rule used when the field value is returned. After the initial rewrite, the read position enters the continuous field value truncation process. S22 continues to read the source path, unit code, caliber operator and desensitization number along the same read position movement rule. Before each read, the access platform first determines whether the field definition record can cover the two-byte length value starting from the read position. If it can cover, the two bytes are converted to the current field length in big-endian order. Then it determines whether the field definition record can cover the byte corresponding to the current field length starting from the position two bytes after the read position. If it can cover, the byte corresponding to the current field length is truncated as the current field value, and the read position is rewritten to the byte after the current field value. When the read bit performs its first continuous read at the byte following the field header, the source path is captured; when the read bit performs its second continuous read at the byte following the source path, the unit code is captured. When the read position is read for the third consecutive time at the byte following the unit code, the caliber operator is captured; when the read position is read for the fourth consecutive time at the byte following the caliber operator, the desensitized number is captured. If the remaining bytes of a field definition record cannot cover a two-byte length value or the bytes corresponding to the current field length during any read, the access platform outputs the definition missing bit and returns the field definition missing record; after the definition missing bit is output, S23 is not executed, the cloud definition bit is not written, and it is not entered into subsequent cloud root generation; After obtaining the field title, source path, unit code, caliber operator, and desensitization number, the cloud-defined bit is generated in S23 according to the fixed access sequence; the access platform first performs SHA256 operation on the field title to obtain the title bit, appends the source path to the title bit to obtain the source input, and performs SHA256 operation on the source input to obtain the source bit; Then, the unit code is appended to the source bit to obtain the unit input, and SHA256 operation is performed on the unit input to obtain the unit bit; then, the caliber operator is appended to the unit bit to obtain the caliber input, and SHA256 operation is performed on the caliber input to obtain the caliber bit; Finally, the desensitization number is appended to the caliber bit to obtain the desensitization input, and the SHA256 operation is performed on the desensitization input to obtain the cloud-defined bit; After the cloud-defined bits are generated, the access platform locates the cloud-defined bit writing position of the field node according to the field node number, overwrites the cloud-defined bit at the cloud-defined bit writing position, and records the writing completion marker, so that S3 can write the cloud-defined bit to the target leaf position. If the missing bit has been defined and output, the original clouded bit in the field node will not be overwritten, and subsequent processing will directly return the field definition missing record. Through the above reading and calculation, the five field values ​​in the field definition record are converted into the same cloud identity bit. Any change in the field title, source path, unit code, caliber operator or desensitization number will change the cloud identity bit, so that the field meaning drift can be identified before the field value is returned. Taking the "Amount" field in the "Order Table" of the cloud table as an example, the field title is "Amount", the source path is "Order Table / Actual Amount Received Column", the unit code is "RMB Yuan", the caliber operator is "Sum by Order Details", and the desensitization number is "No Desensitization". The access platform extracts the values ​​of the five fields in sequence according to the read position and performs SHA256 operation in order to generate the corresponding cloud definition bit and writes it into the field node of "Amount". Subsequently, S3 generates the cloud root with this cloud definition bit.

[0019] S3. Using the Merkle hash tree algorithm, the cloud-defined bit is written to the target leaf bit. The sibling hash is read layer by layer from the target leaf bit to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. The field tree root generation process follows the cloud meaning bit writing result, and the goal is to convert the field meaning changes of the field node into cloud roots, so that the subsequent end roots and cloud roots can enter the bifurcation linear consistency check algorithm. The field tree adopts a layer numbering rule where the leaf layer number is zero and increments by one layer towards the root node. The target leaf position is determined by both the leaf layer number and the leaf number. Each time the operation moves up one level, the current sequence number is XORed with a bit to obtain the sibling sequence number, the current sequence number is shifted right by one bit to obtain the parent sequence number, and the last bit of the current sequence number determines the concatenation order of the current hash and the sibling hash; the specific processing is as follows; After the cloud-defined bit enters the field tree, the operation path from the leaf node to the root node is first established. In S31, the cloud-defined bit is written into the node hash corresponding to the target leaf position, and the cloud-defined bit is set as the current hash. The target leaf position contains the leaf layer number and the leaf number. The leaf layer number is fixed to zero, and the leaf number is written as the current sequence number. Read the root layer number of the root node in the field tree and write it as the stop layer number. The root layer number is the layer number when the field tree is incremented by one from the leaf layer to the next layer and the operation is performed until a single root node is reached. If the leaf layer number is equal to the stop layer number, then the target leaf position is also the root node, and the current hash is directly output as the cloud root. When the leaf layer number is different from the stop layer number, a path entry is generated using the current layer number and the current sequence number. The path entry contains the current layer number, the current sequence number, the sibling sequence number, and the parent sequence number. The sibling sequence number is obtained by bitwise XORing the current sequence number with one, and the parent sequence number is obtained by right-shifting the current sequence number by one bit. Then, the parent sequence number is rewritten as the current sequence number, the current layer number is incremented by one, and the next path entry is generated. When the current layer number equals the stopping layer number, path entry generation stops, and the root path table is output in the order of generation. Each row of the root path table stores the current layer number, current sequence number, sibling sequence number, and parent sequence number at the time of generation. When reading the root path table later, the sequence number value stored in the path entry is used, and the current sequence number that has been rewritten to the previous layer is not used. After the root path table is determined, the parent hash is generated layer by layer. S32 reads the path items according to the order of writing the root path table and locates the field tree node table by the current layer number and sibling sequence number in the path item. The field tree node table records the layer number, sequence number, and node hash of each node. When the node corresponding to the sibling sequence number exists, the node hash of that node is read as the sibling hash; when the node corresponding to the sibling sequence number does not exist, the current hash is copied as the sibling hash, so that the current node still forms two 32-byte inputs when there is no sibling node at the same level. The concatenation order is determined by the last digit of the current sequence number in the path item. When the last digit of the current sequence number is zero, the current hash is appended before the sibling hash to form the concatenation; when the last digit of the current sequence number is one, the sibling hash is appended before the current hash to form the concatenation. Then, the current layer number in the path item is appended to the parent sequence number and then to the concatenation body to form the layer input. The SHA256 operation is performed on the layer input to obtain the parent hash. After the parent hash is generated, it is written into the node hash position in the field tree node table, which is located by the previous level number and the parent sequence number. At the same time, the current hash is rewritten with the parent hash so that the next path item can continue to participate in the parent hash operation. When the root path table is finished reading, the current hash corresponds to the node hash of the root node of the field tree. To prevent errors in path item generation from causing the cloud root calculation to deviate from the field tree structure, S33 performs consistency error correction on each path item in the root path table; After reading the current path item, first use the current sequence number in the path item to XOR with a bit to recalculate the check sibling sequence number, and compare it bit by bit with the sibling sequence number in the path item. If they are the same, write the sibling check bit 1; otherwise, write the sibling check bit 0. Then, right-shift the current sequence number in the path item by one position to recalculate the parent sequence number and compare it bit by bit with the parent sequence number in the path item. If they are the same, write parent check bit 1; otherwise, write parent check bit 0. If the current path item has a next path item, compare the current sequence number of the next path item with the parent sequence number of the current path item bit by bit. If they are the same, write 1 to the continuation check bit; otherwise, write 0 to the continuation check bit. If the current path item is the last row of the root path table, write 1 to the continuation check bit. The path check bit is obtained by bitwise ANDing the sibling check bit, parent check bit, and continuation check bit. When the path check bit is one, the current hash generated by S32 is retained. When the path check bit is zero, the current node hash is reread from the field tree node table according to the current layer number and current sequence number in the current path item. The sibling hash is reread according to the current layer number and sibling sequence number. If the sibling sequence number is not recorded in the field tree node table, the current node hash obtained by rereading is copied as the sibling hash. Then, the SHA256 operation is re-executed according to the concatenation order and layer input generation rules of S32 to obtain the recalculated parent hash. The recalculated parent hash is used to cover the node hash position jointly located by the previous layer number and parent sequence number. At the same time, the current hash is rewritten with the recalculated parent hash. After all root path tables are processed, the cloud root is output with the current hash. The cloud root is used by S4 and the end root to perform the fork linear consistency check algorithm. After writing the target leaf position, generating the root path table, performing layer-by-layer parent hash operations, and correcting path entries, the cloud-defined bits are converted into cloud roots that can represent the current state of the field tree. When the field title, source path, unit code, caliber operator, or desensitization number of the same field changes, the cloud definition bit changes, the node hash of the target leaf position changes accordingly, and is passed down layer by layer along the field tree to the cloud root. Taking the "Amount" field of the "Order Table" in the cloud table as an example, after the cloud-defined part writes the target leaf position corresponding to this field, the processing end reads the leaf number of the target leaf position to generate the sibling sequence number and the parent sequence number, reads the sibling hash layer by layer and determines the concatenation order according to the last digit of the current sequence number, and finally obtains the cloud root of the order table field tree. After the terminal root and cloud root enter the root book for verification, it can be determined whether the field definition history held by the terminal is linearly connected to the current field definition history in the cloud.

[0020] S4. Perform the bifurcation linear consistency check algorithm with the terminal root and the cloud root. Use the terminal root as the current root to check the root book. If the current root is equal to the cloud root, output the linear position. If the same previous root is connected to different subsequent roots, output the bifurcation position. If there is only one subsequent root, rewrite the current root as the subsequent root and continue checking. If there is no subsequent root and the current root is not equal to the cloud root, output the difference root position. When the end root and cloud root enter the consistency check, the root book is used to record the connection relationship of the field tree root from the historical state to the successor state, the previous root index is used to find the successor root by the current root, and the subsequent root index is used to reverse look up the access source by the edge and the subsequent root. During the testing process, only one of the linear bit, bifurcation bit, or difference root bit is output in each round. Only when no output is generated is the edge root rewritten as the current root and the next round begins. When entering S4, the access platform creates an empty root path table for this test. In this stage, the root path table stores the previous root cell, the next root cell, the continuation cell, and the root book row number by row. It is used to record the root continuation edges that have passed the test and to prevent the same root value from being continuated repeatedly. The root book retrieval first puts the end root value into the same continuation chain. S41 writes the end root as the current root and compares the current root with the cloud root byte by byte. When the current root is equal to the cloud root, it means that the terminal root carried by the terminal is consistent with the cloud root generated by the cloud. The linear bit is output directly and S4 ends. When the current root is not equal to the cloud root, use the current root to query the previous root index of the root book. The previous root index uses the previous root segment of each row of the root book as the key, and outputs the root book row number of the previous root segment that is equal to the current root byte by byte. Each line of the root book stores the previous root segment, the next root segment, and the continuation segment in a fixed order. The previous root segment is the historical root of the 32-byte field tree, the next root segment is the successor root of the 32-byte field tree, and the continuation segment is the 32-byte checksum obtained by performing SHA256 operation on the previous root segment followed by the next root segment. For each root book row number returned by the previous root index, the access platform reads the corresponding root entry, appends the previous root segment to the previous root segment to form the verification input, and performs SHA256 operation on the verification input to obtain the verification bit. When the check bit is equal to the continuation segment byte by byte, the root segment, continuation segment, and root book row number of the root entry are written into the candidate table in ascending order of root book row number. Root entries whose check bit is different from the continuation segment are not written into the candidate table and do not participate in the fork determination and difference root determination in this round. After the candidate table is formed, the process proceeds to the next step. S42 reads the number of rows in the candidate table. If there are no rows in the candidate table, it means that the current root has no successor root that has passed the check in the root book. The difference root bit is output and S4 ends. If there are rows in the candidate table, the access platform compares the successor root segments in the candidate table row by row. If the successor root segments of any two rows are different byte by byte, it means that the same preceding root leads to different successors. The fork bit is output and S4 ends. When the root segment of each row in the candidate table has the same value byte by byte, the current root is recorded as the root before the edge, and the root segment after the first row of the candidate table is recorded as the root after the edge. The first row of the candidate table is written in ascending order of the root book row number as the first row after the candidate table. Then, in the root path table established in this S4, the root edge entry whose previous root cell is equal to the root of the next edge byte by byte is searched. When the root edge entry is found, it means that the root of the next edge has appeared as the previous root of the previous continuation edge. If the continuation continues, it will enter the visited root value, output the difference root bit and end S4. If no root edge item is found, create a new row at the end of the root path table, write the root before the edge into the root cell, write the root after the edge into the root cell, write the continuation segment of the first row of the candidate table into the continuation cell, and write the root book row number of the first row of the candidate table into the root book row number cell, so that subsequent root reconnection records can be read according to the continuation order. After the edge root is written into the root path table, it is necessary to confirm the access source of the successor root. S43 uses the edge root to query the root index of the root book. The root index uses the root segment of each row of the root book as the key and outputs the root segment byte by byte equal to the root book row number of the edge root. The access platform rereads the front root segment, the back root segment, and the continuation segment for each root entry found. It then performs SHA256 operation before the back root segment to obtain the reverse check bit. Root entries whose reverse check bits are different from the continuation segment do not participate in the reverse check result. If there is a root entry where the reverse check bit is equal to the continuation segment byte by byte and the preceding root segment is different from the preceding root of the edge byte by byte, it means that the following root of the edge is connected by another preceding root. Output the fork bit and end S4. If there is no root entry where the reverse check bit is equal to the continuation segment byte by byte and the previous root segment is equal to the previous root of the edge byte by byte, it means that the continuation relationship from the previous root of the edge to the next root of the edge in this round cannot be mutually verified by the next root index. Output the difference root bit and end S4. If there is a root entry where the reverse check bit is equal to the continuation segment byte by byte and the previous root segment is equal to the previous root of the edge byte by byte, the access platform rewrites the current root with the edge root, and then compares the current root with the cloud root byte by byte. If the current root is equal to the cloud root, the linear bit is output; if the current root is not equal to the cloud root, return to S41 to continue the next round of retrieval. After completing the above root value tracing, the relationship between the end root and the cloud root is classified into three results: linear continuation, fork conflict, or root difference interruption. Root entries that fail to be verified in the root book are excluded from the candidate table. Visited root continuation edges are written into the root path table to prevent duplicate continuation. The reverse verification of the post root index is used to confirm that the post root of the edge has not been accessed by different pre-roots at the same time. When accessing fields in the cloud table, the terminal carries the end root from the previous access write-back, and the cloud root is generated from the current field tree. If the end root continues to the cloud root line by line along the root book, the subsequent end-cloud collaborative judgment continues to compare the end definition bit and the cloud definition bit. If the same preceding root leads to two subsequent roots, the field value is rejected. If the end root cannot be continued to the cloud root, the root reconnection record is returned. The root book row number sequence in the root reconnection record comes from the root book row number cell saved in the current root path table according to the write order.

[0021] S5. According to the access bit, read the access rule, verify the signature value with the rule public key, and generate the rule bit with the same value as the rule action and action code. In the end-cloud collaborative judgment, when the linear bit is output and the signature value and the rule bit are both one, the end definition bit is equal to the cloud definition bit, return the field value and write back the cloud root and cloud definition bit. When they are not equal, return the meaning update record and write back the cloud root and cloud definition bit. When the difference root bit is output, return the root reconnection record. When the fork bit is output, refuse to return the field value. When the signature value is zero, refuse to return. When the rule bit is zero, refuse to return. The access result return process includes the connection bit, difference root bit, fork bit, cloud root bit, and cloud definition bit, which are used to merge the signature, action code, and access rules in the field access message into the end-cloud collaborative judgment. The rule page is the access rule data page associated with the field node. The rule page stores the rule public key used for signature verification, the rule action used for action comparison, and the reading location of field values, meaning update records, and root reconnection records. This step only generates the results of field value return, meaning update, root reconnection, or rejection after the signature, rule action, and root consistency results are all completed. Rule page reading begins with the field node as the entry point. In S51, the field node number is first read from the pointer segment in the access bit, the field node is located according to the field node number, and then the rule page number is read from the field node. The rule page number is the rule page location value stored in the field node, which is used to point to a page of access rule data. The processing end sets the first byte of the rule page as the read bit, first reads two bytes from the read bit and converts them into the rule public key length in big-endian order, then truncates the corresponding byte of the rule public key length two bytes after the read bit as the rule public key. The rule public key contains the curve number and the elliptic curve public key coordinates. The curve number is used to find the curve order and base point, and the elliptic curve public key coordinates are used for signature verification. Then, the read bit is rewritten as the next byte of the rule public key, and two bytes are truncated from the read bit as the rule action. After the read bit continues to move forward, the value page pointer, meaning page pointer, and reconnection page pointer are captured in sequence. Each page pointer consists of a page number segment and an offset segment. The page number segment locates the data page, and the offset segment locates the starting byte within the data page. The value page pointer points to the field value record, the meaning page pointer points to the meaning update record, and the reconnection page pointer points to the root reconnection record. If the remaining bytes of the rule page cannot cover the fixed read length of the rule public key, rule public key, rule action, value page pointer, meaning page pointer, or reconnection page pointer, then the rule missing record is returned, and signature verification, rule action comparison, and result return are stopped. Signature verification is performed under the common constraints of field meaning and root consistency result. S52 appends the end root to the end definition bit to form the first input, then appends the action code to the first input to form the second input, then appends the cloud root to the second input to form the third input, and appends the cloud definition bit to the third input to form the signature verification input. SHA256 operation is performed on the signature verification input to obtain a 32-byte digest; the digest is converted to an unsigned integer in big-endian order and used for elliptic curve signature verification. The signature is fixed at 64 bytes. The first 32 bytes are converted into the first signature number in big-endian order, and the last 32 bytes are converted into the second signature number in big-endian order. The curve number in the rule public key is used to find the curve order and base point in the curve parameter table. If there is no corresponding record for the curve number, the verification value is zero. If the first signature number or the second signature number is not within the range of one to one curve order minus one, the verification value is zero. If both the first signature number and the second signature number are within the range of one to one curve order minus one, the extended Euclidean algorithm is used to calculate the modular inverse of the second signature number with respect to the curve order. The first verification coefficient is obtained by multiplying the digest by the modular inverse and taking the remainder with respect to the curve order. The second verification coefficient is obtained by multiplying the first signature number by the modular inverse and taking the remainder with respect to the curve order. The verification point is obtained by adding the first verification coefficient multiplied by the base point and the second verification coefficient multiplied by the rule public key. If the verification point does not exist, output the verification value of zero. If the verification point exists, take the modulo of the x-coordinate of the verification point with respect to the curve order to obtain the verification x-number. If the verification x-number is equal to the first signature, output the verification value of one. If the verification x-number is not equal to the first signature, output the verification value of zero. The rule action comparison enters the cloud-edge collaborative judgment preprocessing. S53 compares the rule action with the action code in the field access message byte by byte. If both bytes are the same, the rule bit is output as 1; if either byte is different, the rule bit is output as 0. The linear bit, root bit, and fork bit output by S4 appear only once in the same access; when the fork bit is output, a rejection bit is generated directly, a rejection bit is generated when the signature value is zero, and a rejection bit is generated when the rule bit is zero. When no rejection bit is generated and the root bit is output, a reconnection bit is generated; when no rejection bit is generated and the linear bit is output, the verification value is ANDed with the rule bit to obtain the admission bit. When the admission bit is one and the endpoint bit is equal to the cloud bit byte by byte, the value read bit is output; when the admission bit is one and the endpoint bit is not equal to the cloud bit byte by byte, the value change bit is output. When the linear bit is not output, the difference root bit is not output, and the fork bit is not output, the root status missing record is returned, and the field values, meaning update records, or root reconnection records are not read. In S54, return and write-back are performed by result bit. When outputting value read bits, the data page where the field value is located is located by the page number segment in the value page pointer, and then the field value record is read by the offset segment and returned to the terminal. When the meaning is updated, the meaning update record is read according to the meaning page pointer and returned to the terminal. The meaning update record stores the field node number, field title, source path, unit code, caliber operator, desensitization number, cloud root and cloud meaning. After receiving the meaning update record, the terminal replaces the corresponding content in the local field definition cache according to the field node number. When reconnecting to the output, the root reconnection record is read according to the reconnection page pointer and returned to the terminal. The root reconnection record stores the end root, cloud root, and the root book row number sequence required to connect from the end root to the cloud root. The root book row number sequence comes from the root book row number cells saved in the root path table in S4 according to the writing order. When the rejection bit is output, a rejection record is returned and the field value is refused to be returned; after the value read bit or the definition bit is output, the terminal locates the local field status item by the field node number. The first 32 bytes of the local field status item is the terminal root position and the last 32 bytes are the terminal definition bit position. The cloud root is overwritten to the terminal root position and the cloud definition bit is overwritten to the terminal definition bit position, so that the next field access message carries the updated root and definition bits. At this point, the return of field values ​​depends not only on the field name matching, but also on rule public key verification, rule action comparison, linear consistency between the end root and the cloud root, and byte-by-byte comparison between the end definition bits and the cloud definition bits. When the meaning of a field changes, return the updated meaning record; when the root history cannot be continued, return the root reconnection record; when a fork or rule validation fails, reject the field value. Taking the terminal reading the "Amount" field of the "Order Table" in the cloud table as an example, the rule action registered on the rule page indicates reading the field value, and the rule public key is used to verify the signature of this access message; When the linear bit output, the verification value is one, the rule bit is one, and the terminal definition bit is equal to the cloud definition bit, the processing terminal returns the "amount" field value according to the value page pointer, and writes the cloud root and cloud definition bit back to the terminal field status item. When the source path of "Amount" changes from "Order Amount Column" to "Actual Amount Received Column", causing the terminal definition bit to be different from the cloud definition bit, the processing terminal returns a meaning update record, so that the terminal can complete the field meaning update before the next access.

[0022] Furthermore, the present invention also includes a cloud data access system, the system comprising an access location module, a meaning generation module, a root tree generation module, a linearity check module, and a collaborative return module: The access positioning module is used to obtain terminal field access messages, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the end root first and then the end definition bit along the tail of the message, read the action code and then read the signature to generate the access bit. The meaning generation module is used to read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the meaning bit. The root generation module is used to write the cloud-defined bit to the target leaf position using the Merkle hash tree algorithm. It reads the sibling hash layer by layer from the target leaf position to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. The linearity check module is used to perform a bifurcation linearity consistency check algorithm with end roots and cloud roots. It uses the end root as the current root to check the root book. If the current root is equal to the cloud root, it outputs the linear position. If the same preceding root is connected to different following roots, it outputs the bifurcation position. If there is only one following root, it rewrites the current root as the following root and continues to check. If there is no following root and the current root is not equal to the cloud root, it outputs the difference root position. The collaborative return module is used to read access rules based on access bits, verify the signature value by checking the rule public key, and generate rule bits when the rule action and action code have the same value. In the end-cloud collaborative determination, when the linear bit is output and both the signature value and the rule bit are one, the end definition bit is equal to the cloud definition bit, the field value is returned and the cloud root and cloud definition bit are written back. When they are not equal, the meaning update record is returned and the cloud root and cloud definition bit are written back. When the difference root bit is output, the root reconnection record is returned. When the fork bit is output, the field value is rejected. When the signature value is zero, the return is rejected. When the rule bit is zero, the return is rejected.

[0023] Working principle: Before the terminal accesses field values ​​in the cloud, this solution first parses the terminal field access message, locates the cloud table by table code, locates the field node by field name, and obtains the root endpoint, endpoint definition bit, action code, and signature from the message tail to generate the access bit; then, it reads the field definition record, performs SHA256 operation on the field title, source path, unit code, caliber operator, and desensitization number in a fixed order to generate the cloud definition bit, and uses the cloud definition bit as the leaf node of the Merkle hash tree algorithm to calculate the cloud root layer by layer; then, it performs a fork linear consistency check algorithm on the root endpoint and the cloud root to confirm whether the field definition history saved by the terminal can be linearly continued to the current field definition history in the cloud; finally, it combines rule public key verification and rule action comparison, and decides in the terminal-cloud collaborative judgment to return the field value, return the meaning update record, return the root reconnection record, or refuse to return the field value, so that field access not only looks at the field name and permissions, but also confirms the consistency of the field meaning and the field definition history; In cloud tables or business data dashboards, when an end user accesses the amount field of an order table, the system first locates the amount field node based on the table code and field name in the message. Then, it reads the field title, source path, unit code, caliber operator, and desensitization number of the amount field to generate the cloud definition bit, and calculates the cloud root from the field tree. If the endpoint root carried by the terminal can be connected to the cloud root along the root book, and the signature and action rules are both passed, then the endpoint definition bit and the cloud definition bit are compared. If the endpoint definition bit is equal to the cloud definition bit, the amount field value is returned. If the endpoint definition bit is not equal to the cloud definition bit, it means that the meaning of the amount field has changed, for example, the source path has changed from the order amount column to the actual amount received column. In this case, the meaning update record is returned and written back to the cloud root and cloud definition bit. If the endpoint root cannot be connected to the cloud root, the root reconnection record is returned. If a fork occurs or the rule verification fails, the field value is refused to be returned, thus avoiding the terminal receiving data with the correct field name but whose meaning has changed.

[0024] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud data access method, characterized in that, include: S1. Obtain the terminal field access message, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the terminal root first and then the terminal definition bit along the tail of the message, continue reading the action code and read the signature at the end, and generate the access bit. S2. Read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the cloud definition bit. S3. Using the Merkle hash tree algorithm, the cloud-defined bit is written to the target leaf bit. The sibling hash is read layer by layer from the target leaf bit to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. S4. Perform the bifurcation linear consistency check algorithm with the terminal root and the cloud root. Use the terminal root as the current root to check the root book. If the current root is equal to the cloud root, output the linear position. If the same previous root is connected to different subsequent roots, output the bifurcation position. If there is only one subsequent root, rewrite the current root as the subsequent root and continue checking. If there is no subsequent root and the current root is not equal to the cloud root, output the difference root position. S5. According to the access bit, read the access rule, verify the signature value with the rule public key, and generate the rule bit when the rule action and action code have the same value. In the end-cloud collaborative judgment, when the linear bit is output and the signature value and the rule bit are both one, the end definition bit is equal to the cloud definition bit, return the field value and write back the cloud root and cloud definition bit. When they are not equal, return the meaning update record and write back the cloud root and cloud definition bit. When the difference root bit is output, return the root reconnection record. When the fork bit is output, refuse to return the field value. When the signature value is zero, refuse to return. When the rule bit is zero, refuse to return.

2. The cloud data access method according to claim 1, characterized in that: S1 includes: S11. After obtaining the terminal field access message, convert the first two bytes into the header length in big-endian order. Starting from the third byte, extract the header length minus two bytes as the table code. Perform SHA256 operation on the table code to obtain the table key. In the table index arranged in lexicographical order of the table key, divide the sum of the start row number and the end row number by two to obtain the middle row number. If the middle row table key is equal to the table key, output the cloud table row number. If the middle row table key is before the table key, change the start row number to the middle row number plus one. If the middle row table key is after the table key, change the end row number to the middle row number minus one. Repeat the search until the cloud table row number is output. When the start row number is equal to the end row number plus one, output the missing table position. S12. When no missing field is output, the header length points to the start of the field area. Two bytes are read from the start of the field area and converted into the field length. Starting from the start of the field area plus two bytes, the field name is extracted according to the field length. The table code and the field name are subjected to SHA256 to obtain the field key. The field key is searched in the field index pointed to by the row number of the cloud table by halving the first and last rows. When a field key with the same value is found, the field node number is output. When no field key with the same value is found, the missing field is output. S13. When the missing bit of the field is not output, 64 bytes are truncated from the end of the field access message to obtain the signature, then 2 bytes are truncated from the end to obtain the action code, and then 32 bytes are truncated from the end to obtain the end definition bit. Then 32 bytes are truncated from the end to obtain the end root bit. Using the field node number as the pointer segment, SHA256 is performed on the end root bit to obtain the root bit. The end definition bit is connected to the root bit hash to obtain the end definition bit. The action code is connected to the end definition bit hash to obtain the action bit. The signature is connected to the action bit hash to obtain the end check bit. The pointer segment is connected to the end check bit to generate the access bit.

3. The cloud data access method according to claim 2, characterized in that: S2 includes: S21. Read the field node number using the pointer segment in the access bit, locate the field node according to the field node number and read the field definition record, and set the read bit to the first byte of the field definition record; the access platform reads two bytes from the read bit and converts them to the current field length in big-endian order, then extracts the byte corresponding to the current field length two bytes after the read bit as the field title, and then rewrites the read bit to the byte after the field title. S22. Continue reading along the read position. Each time, read two bytes from the read position and convert them to the current field length in big-endian order. Move two bytes after the read position and extract the byte corresponding to the current field length as the current field value. Then rewrite the read position to the byte after the current field value. After the first rewrite of the read position, obtain the source path. After the second rewrite of the read position, obtain the unit code. After the third rewrite of the read position, obtain the caliber operator. After the fourth rewrite of the read position, obtain the desensitization number. S23. Perform SHA256 operation on the field title to obtain the title bit. Attach the source path after the title bit to obtain the source input and perform SHA256 operation to obtain the source bit. Attach the unit code after the source bit to obtain the unit input and perform SHA256 operation to obtain the unit bit. Attach the caliber operator after the unit bit to obtain the caliber input and perform SHA256 operation to obtain the caliber bit. Attach the desensitization number after the caliber bit to obtain the desensitization input and perform SHA256 operation to obtain the cloud-defined bit. Then write the cloud-defined bit into the field node.

4. The cloud data access method according to claim 3, characterized in that: S3 includes: S31. Write the cloud-defined bit into the target leaf position and set it as the current hash. Read the leaf number of the target leaf position as the current sequence number. Read the root layer number of the field tree as the stop layer number. Calculate the current sequence number and XOR it with one bit to get the sibling sequence number. Calculate the current sequence number and shift it right by one bit to get the parent sequence number. Write the current sequence number, sibling sequence number and parent sequence number into the path entry. Then rewrite the current sequence number with the parent sequence number and increment the layer number by one. If the layer number is different from the stop layer number, continue to generate path entries. If the layer number is equal to the stop layer number, output the root path table. S32. Read the path entries according to the generation order of the root path table, read the sibling hash corresponding to the sibling sequence number from the field tree, and copy the current hash as the sibling hash if the sibling sequence number is not recorded. If the last digit of the current sequence number is zero, append the current hash to the sibling hash to form a concatenation. If the last digit of the current sequence number is one, append the sibling hash to the current hash to form a concatenation. Then append the layer number to the parent sequence number and the concatenation to form the layer input. Perform SHA256 operation on the layer input to obtain the parent hash, and rewrite the current hash with the parent hash.

5. The cloud data access method according to claim 4, characterized in that: S3 also includes: S33. Perform consistency error correction on the path item. First, write the result of the sibling sequence number being equal to the current sequence number and one bitwise XORed as the sibling check bit. Then, write the result of the parent sequence number being equal to the current sequence number shifted right by one bit as the parent check bit. Then, write the result of the current sequence number of the next path item being equal to the parent sequence number as the continuation check bit. Perform a bitwise AND operation on the sibling check bit, parent check bit, and continuation check bit to obtain the path check bit. When the path check bit is one, retain the current hash. When the path check bit is zero, reread the node hash corresponding to the current sequence number and the sibling hash corresponding to the sibling sequence number from the field tree, and recalculate the current hash according to the layer input generation rules in S32. When the root path table is processed, output the cloud root with the current hash.

6. A cloud data access method according to claim 5, characterized in that: S4 includes: S41. Write the end root as the current root; when the current root is equal to the cloud root, output the linear bit; when the current root is not equal to the cloud root, use the current root to perform an equal value search in the previous root index of the root book. Each row of the root book consists of a previous root segment, a subsequent root segment, and a continuation bit segment. For each row retrieved, perform SHA256 operation on the previous root segment followed by the subsequent root segment to obtain the check bit. When the check bit is equal to the continuation bit byte by byte, write the subsequent root segment and the continuation bit segment into the candidate table. S42. Perform a fork determination on the candidate table. If there are no rows in the candidate table, output the difference root bit. If there are two rows in the candidate table whose root segments are different byte by byte, output the fork bit. If the root segments of each row in the candidate table have the same value byte by byte, record the current root as the edge before root, record the root segment of the first row of the candidate table as the edge after root, and search for the root edge entry in the root path table where the edge before root cell is equal to the edge after root. If the root edge entry is found, output the difference root bit. If the root edge entry is not found, write the edge before root, edge after root, and the continuation bit segment of the first row of the candidate table into a new row of the root path table.

7. A cloud data access method according to claim 6, characterized in that: S4 also includes: S43. Perform reverse verification along the edge-after-root; use the edge-after-root to query the root index of the root book, and perform SHA256 operation on the previous root segment followed by the next root segment for each row to obtain the reverse verification bit. If there is a root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is different from the edge-before-root byte by byte, output the fork bit. If there is no root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is equal to the edge-before-root byte by byte, output the difference root bit. If there is a root entry where the reverse verification bit is equal to the continuation segment byte by byte and the previous root segment is equal to the edge-before-root byte by byte, rewrite the current root with the edge-after-root. If the current root is equal to the cloud root, output the linear bit. If the current root is not equal to the cloud root, return to S41.

8. A cloud data access method according to claim 7, characterized in that: S5 includes: S51. Locate the field node using the pointer segment in the access bit, read the rule page number from the field node, extract the rule public key first by reading the bit in the rule page, then extract the rule action, then extract the value page pointer, then extract the meaning page pointer, and finally extract the reconnection page pointer at the last bit to generate the access rule. S52. Connect the root end to the end definition bit, then the action code, then the cloud root to the cloud definition bit, and perform SHA256 operation to obtain the digest. Convert the first half of the signature into the first signature number and the second half of the signature into the second signature number. Use the rule public key to perform elliptic curve verification on the digest, the first signature number, and the second signature number. If the verification is successful, output the verification value 1; if the verification fails, output the verification value 0.

9. A cloud data access method according to claim 8, characterized in that: S5 also includes: S53. Compare the rule action with the action code byte by byte. If the values ​​are the same, output the rule bit as 1. If the values ​​are different, output the rule bit as 0. When outputting the linear bit, AND the check value with the rule bit to generate the access bit. If the access bit is 1 and the endpoint bit is equal to the cloud bit, output the value read bit. If the access bit is 1 and the endpoint bit is not equal to the cloud bit, output the access bit. S54. When outputting the value read bit, the field value is read according to the value page pointer and returned to the terminal. When outputting the meaning update bit, the meaning update record is read according to the meaning page pointer and returned to the terminal. When outputting the difference root bit, the root reconnection record is read according to the reconnection page pointer and returned to the terminal. When outputting the fork bit, if the signature value is zero or the rule bit is zero, the field value is rejected. After outputting the value read bit or the meaning update bit, the cloud root is written to the terminal root position and the cloud meaning bit is written to the terminal meaning bit position.

10. A cloud data access system for implementing the cloud data access method according to any one of claims 1-9, the system comprising an access location module, a meaning generation module, a root tree generation module, a linearity check module, and a collaborative return module, characterized in that: The access positioning module is used to obtain terminal field access messages, locate the cloud table by looking up the table code in the header, locate the field node by looking up the field name in the field area, read the end root first and then the end definition bit along the tail of the message, read the action code and then read the signature to generate the access bit. The meaning generation module is used to read the field definition record by access bit. First, the field title is hashed to get the title bit. The source path is hashed with the title bit to get the source bit. The unit code is hashed with the source bit to get the unit bit. The caliber operator is hashed with the unit bit to get the caliber bit. The desensitized number is hashed with the caliber bit to get the meaning bit. The root generation module is used to write the cloud-defined bit to the target leaf position using the Merkle hash tree algorithm. It reads the sibling hash layer by layer from the target leaf position to the root of the field tree. If the current bit is even, the current hash is concatenated on the left; if it is odd, it is concatenated on the right. The concatenated value is written as the current hash of the upper layer after hash operation, and the cloud root is output at the root of the tree. The linearity check module is used to perform a bifurcation linearity consistency check algorithm with end roots and cloud roots. It uses the end root as the current root to check the root book. If the current root is equal to the cloud root, it outputs the linear position. If the same preceding root is connected to different following roots, it outputs the bifurcation position. If there is only one following root, it rewrites the current root as the following root and continues to check. If there is no following root and the current root is not equal to the cloud root, it outputs the difference root position. The collaborative return module is used to read access rules based on access bits, verify the signature value by checking the rule public key, and generate rule bits when the rule action and action code have the same value. In the end-cloud collaborative determination, when the linear bit is output and both the signature value and the rule bit are one, the end definition bit is equal to the cloud definition bit, the field value is returned and the cloud root and cloud definition bit are written back. When they are not equal, the meaning update record is returned and the cloud root and cloud definition bit are written back. When the difference root bit is output, the root reconnection record is returned. When the fork bit is output, the field value is rejected. When the signature value is zero, the return is rejected. When the rule bit is zero, the return is rejected.

Images