Data transaction method based on block chain

Abstract

The invention relates to the technical field of data transaction, in particular to a data transaction method based on a block chain, which comprises the following steps: acquiring original consumer transaction data, then executing multi-layer encryption, binding hash value storage after secondary encryption by a block chain node, calling an intelligent contract to match a public key address and authority, and storing the public key address and authority. And monitoring the active state and transaction volume of the block chain network in real time, calculating a log structure by adopting a chained hash process, writing the log structure into a non-tampering storage layer, and generating an audit log identifier. According to the method, the flexibility and efficiency of data access are optimized through intelligent contract automatic verification and dynamic allocation of access permissions, meanwhile, safe data access management is enhanced according to matching of public key addresses and permission conditions and dynamic calculation of consumer credit scores, and the real-time transaction volume and the node active state of a block chain network are monitored; the stability and the response speed of the network are improved, and the security, the efficiency and the reliability of the data in the transaction process are enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of data trading, and particularly to a data trading method based on blockchain. Background Art

[0002] The technical field of data trading encompasses various technologies related to information transmission, data storage, data management, and data trading security. In the technical field of data trading, the core content focuses on how to effectively process, transmit, and protect data exchanged between different systems. This field has been continuously evolving, covering from basic data encoding and transmission protocols to complex data security and privacy protection technologies. The development of data trading technology supports various commercial and financial applications, ensuring the secure transmission and accurate delivery of data in the Internet or network environment.

[0003] Among them, the data trading method refers to the process of using distributed ledger technology to process and record data transactions. The technical matters involved in this technical topic mainly include methods for creating, verifying, and storing transactions in a blockchain network. The security and immutability of transactions are ensured through a consensus mechanism among multiple nodes in the network, and encryption technology is used to protect data from unauthorized access. The data trading method based on blockchain processes various data trading requirements through the application of distributed processing and encryption technology, thereby maintaining the trust between the trading parties and the integrity of the data.

[0004] The main deficiencies faced by the prior art in the field of data trading include limitations in data security and processing efficiency. Although it involves various information transmission and data management technologies, in the case of high-density data trading and complex network environments, it is difficult for the prior art to effectively prevent data leakage and tampering. When dealing with large-scale real-time data transactions, the prior art lacks sufficient flexibility and automated processing capabilities, resulting in delays and low efficiency in the data access and verification processes. The technical limitations not only affect the accurate delivery of data but also increase the security risks during the trading process. In the case of failure to update and verify data permission settings in a timely manner, it may lead to unauthorized access or data abuse, damaging the interests of data owners and the overall security of the network. Summary of the Invention

[0005] To address the limitations of data security and processing efficiency in the existing technology, although it involves various information transmission and data management technologies, in the context of high-density data transactions and complex network environments, it is difficult for the existing technology to effectively prevent data leakage and tampering. When dealing with large-scale real-time data transactions, the existing technology lacks sufficient flexibility and automated processing capabilities, resulting in delays and inefficiencies in the data access and verification processes. These technical limitations not only affect the accurate delivery of data but also increase security risks during the transaction process. In the case of failure to update and verify data permission settings in a timely manner, it leads to unauthorized access or data abuse, damaging the interests of data owners and the overall security of the network. The present invention provides a blockchain-based data transaction method. The technical solution is as follows: On the one hand, a blockchain-based data transaction method is provided, which includes: S1: Obtain the original consumption transaction data, perform multi-layer encryption on the data. The first-layer encryption generates a primary encrypted ciphertext, input the primary encrypted ciphertext into a blockchain node for secondary encryption, calculate the hash value of the multi-layer encrypted ciphertext, and generate an encrypted data identifier; S2: Invoke the smart contract corresponding to the encrypted data identifier, extract the access permission conditions defined in the smart contract, detect the public key address of the consumer and the transaction request type, match the public key address with the address list in the permission conditions. If the match is successful, perform automatic verification, dynamically calculate the credit score based on the consumer's behavior. If the score exceeds the preset threshold, allocate an access permission instruction to generate an access permission value; S3: Invoke the transaction level classification corresponding to the access permission value, monitor the real-time transaction volume and node activity status of the blockchain network, identify the network load status, and evaluate the relevance between the network load status and the transaction level classification to generate a consensus type recognition result; S4: Through the consensus type recognition result, extract the data request frequency and verification response speed of the blockchain node, analyze the deviation status of the node behavior. If the deviation status exceeds the preset threshold, adjust the consensus weight value of the node to generate a node security score.

[0006] As a further aspect of the present invention, the encrypted data identifier includes an encrypted ciphertext hash, a data storage location identifier, and an encryption level marker. The access permission value includes a permission matching status, a dynamic credit level, and a permission instruction code. The consensus type recognition result includes a load status level, a transaction urgency classification, and a consensus mechanism type. The node security score includes a behavior deviation coefficient, a weight adjustment ratio, and a security evaluation label.

[0007] As a further aspect of the present invention, the specific steps for obtaining the encrypted data identifier are as follows: S101: Obtain original consumption transaction data, extract account information, transaction time and transaction amount, call the symmetric key, encrypt the transaction characters after field concatenation, and generate a sequential encrypted ciphertext structure; S102: calling the sequential encrypted ciphertext structure, writing it into the target blockchain node, indexing the input ciphertext in the blockchain node according to the key index value built into the node, combining the node timestamp and the ciphertext sequence number, breaking up and rearranging the field structure, and performing re-encryption calculation to generate a node mixed encryption field; S103: After extracting the field combination structure based on the node hybrid encryption field, perform a hash generation operation, store and combine the hash signature value and the original data, and obtain an encrypted data identifier.

[0008] As a further solution of the present invention, the step of obtaining the access permission value is specifically as follows: S201: calling the smart contract corresponding to the encrypted data identifier, extracting the access permission condition field defined in the smart contract structure, the field content including the access address list, the corresponding transaction type and the permission threshold, and locating and indexing the field based on the hash value bound in the identifier structure, and generating a contract permission condition parameter set; S202: According to the address list field in the contract permission condition parameter set, compare the public key address data provided by the consumer with the node address in the address list to see if there is a complete match with the same bit sequence, and identify the verification status according to the match success flag bit to obtain the public key address matching status; S203: Call the transaction type field in the public key address matching status, compare it with the real-time transaction request type data, extract the credit assessment benchmark field corresponding to the successful matching item, and generate the access permission value by combining the consumer transaction frequency, account credit score and transaction requests per unit time.

[0009] As a further solution of the present invention, the formula for comparing whether there are complete matches with the same bit sequence is as follows: ; in, Represents the degree of matching of the public key address, Represents the number of address bytes to be compared. Represents the address list Bit Byte, Represents the first public key address data provided by the consumer Bit Byte, Representative The weight value of the byte, express and The absolute value of the byte difference between the two.

[0010] As a further solution of the present invention, the step of obtaining the consensus type recognition result is specifically as follows: S301: Invoke the transaction level classification field corresponding to the access permission value, extract the level category number and the corresponding processing priority value defined in the field, combine the real-time blockchain network data, monitor the total number of transaction broadcasts and the number of active nodes within the time window, perform time synchronization and cumulative statistical processing on the two types of data, and generate network operation status parameters; S302: Based on the transaction broadcast quantity and the node activity quantity in the network operation status parameters, construct the transaction density value and the node response ratio per unit time, compare and judge with the set blockchain load recognition benchmark value, identify the load status interval identifier, and generate the network load status level; S303: Invoke the transaction level number associated with the network load status level and the access permission value for cross-matching, numerically compare the processing priority value defined in the level number with the resource allocation weight corresponding to the load status, calculate the resource allocation characteristic value, select the consensus identifier corresponding to the processing path, and generate the consensus type recognition result.

[0011] As a further solution of the present invention, the formula for calculating the resource allocation characteristic value is as follows: ; Wherein, represents the resource allocation characteristic value, represents the adjustment factor, represents the resource allocation weight dynamic balance coefficient, represents the processing priority value, represents the resource allocation weight corresponding to the load status, represents the load difference, represents the priority correction coefficient.

[0012] As a further solution of the present invention, the step of obtaining the node security score is specifically as follows: S401: Adopt the consensus type recognition result, invoke the transaction data request record and the block verification response information of the blockchain node, combine the timestamp information and the operation frequency data of each node, and calculate the average data request frequency and the response time of the node within the specified time period respectively, and generate the node behavior frequency parameter group; S402: According to the node behavior frequency parameter group, combine the execution deviation time of multiple operation instructions of the node in the recent period, extract the corresponding node execution delay amount and the response anomaly amplitude, and respectively compare the node delay amount and the response anomaly amplitude with the set offset state threshold for interval comparison, screen the node set that exceeds the threshold range and mark the node number, and generate the node offset measurement result; S403: Invoke the consensus type classification information corresponding to the node number in the node offset metric result, and combine the network transaction activity value and the consensus participation frequency to adjust the consensus weight parameter of the node, so as to obtain the node security score.

[0013] As a further solution of the present invention, the method further includes step S5: S5: Invoke the node security score, extract the block identifier and time stamp of the corresponding transaction, combine the block identifier, time stamp, and permission change record into a log structure, perform hash calculation on the log structure using a chained hash process, bind the root hash identifier to the transaction metadata and write it into the tamper-proof storage layer to generate an audit log identifier; The audit log identifier includes a block height code, a time stamp sequence, and a root hash digest.

[0014] As a further solution of the present invention, the obtaining step of the audit log identifier is specifically: S501: Invoke the node security score, extract the associated transaction number field, and read the block identifier and time stamp data bound under the corresponding transaction number. Combine the three types of structures in sequence with the permission change type, target address, and adjusted time stamp field to obtain the block permission identification result; S502: Based on the field content in the block permission identification result, use a chained hash process to generate local hash values for each log entry in ascending order of the time stamp, perform an aggregate hash operation on the local hash values to construct a hash tree structure, and extract the root node hash field of the hash tree to generate a permission adjustment record; S503: Invoke the transaction metadata bound to the permission adjustment record and the transaction number, index-align the two and combine them into a bound structure, and write the bound structure into the tamper-proof storage layer to generate an audit log identifier.

[0015] The beneficial effects brought by the technical solutions provided by the embodiments of the present invention at least include: By performing multi-layer encryption on the original transaction data and combining the encryption process with the secondary encryption of the blockchain node, the security and tamper-proof ability of the data are significantly improved. The hash value of the encrypted ciphertext is bound to the ciphertext and stored to further ensure the integrity and traceability of the data. Through the automatic verification of smart contracts and the dynamic allocation of access permissions, the flexibility and efficiency of data access are optimized. At the same time, according to the matching of the public key address and permission conditions, and the dynamic calculation of the consumer credit score, personalized and secure data access management is strengthened. Monitor the real-time trading volume and node active status of the blockchain network, and dynamically adjust the consensus weight of the node according to the correlation between the network load and the transaction level, improve the stability and response speed of the network, enhance the overall data processing ability, and enhance the security, efficiency, and reliability of the data during the transaction process. Brief Description of the Drawings

[0016] Figure 1 This is a schematic diagram of the working process of the present invention. Detailed Embodiments

[0017] The technical solutions in the present invention will be described below with reference to the accompanying drawings.

[0018] In the embodiments of the present invention, words such as "exemplarily" and "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as an "example" in the present invention should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of the word "example" is intended to present concepts in a specific manner. In addition, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one of the two.

[0019] To make the technical problems, technical solutions and advantages to be solved by the present invention clearer, the following will be described in detail with reference to the accompanying drawings and specific embodiments.

[0020] Please refer to Figure 1 , the embodiments of the present invention provide a blockchain-based data transaction method, and the processing flow of this method may include the following steps: S1: Obtain the original consumption transaction data, perform multi-layer encryption on the data. The first layer of encryption generates a primary encrypted ciphertext, input the primary encrypted ciphertext into the blockchain node for secondary encryption to obtain the multi-layer encrypted ciphertext, calculate the hash value of the multi-layer encrypted ciphertext, bind the hash value to the encrypted ciphertext and store it to generate an encrypted data identifier; S2: Invoke the smart contract corresponding to the encrypted data identifier, extract the access permission conditions defined in the smart contract, detect the public key address of the consumer and the type of transaction request, match the public key address with the address list in the permission conditions. If the match is successful, perform automatic verification, dynamically calculate the credit score with reference to the consumer's behavior. If the score exceeds the preset threshold, allocate an access permission instruction to generate an access permission value; S3: Invoke the transaction level classification corresponding to the access permission value, monitor the real-time transaction volume and node activity status of the blockchain network, identify the network load status, and evaluate the relevance between the network load status and the transaction level classification to generate a consensus type recognition result; S4: Through the consensus type recognition result, extract the data request frequency and verification response speed of the blockchain node, analyze the deviation status of the node behavior. If the deviation status exceeds the preset threshold, adjust the consensus weight value of the node to generate a node security score; S5: Call the node security score, extract the block identifier and time stamp of the corresponding transaction, combine the block identifier, time stamp, and permission change record into a log structure, use the chain hash process to hash the log structure, bind the root hash identifier to the transaction metadata, and write it into the tamper-proof storage layer to generate an audit log identifier; Encrypted data identification includes encrypted ciphertext hash, data storage location identification, and encryption level mark. Access permission values ​​include permission matching status, dynamic credit level, and permission instruction code. Consensus type identification results include load status level, transaction emergency classification, and consensus mechanism type. Node security scores include behavior deviation coefficient, weight adjustment ratio, and security assessment label. Audit log identification includes block height code, timestamp sequence, and root hash summary.

[0021] The specific steps for obtaining the encrypted data identifier are: S101: Obtain original consumption transaction data, extract account information, transaction time and transaction amount, call the symmetric key, encrypt the transaction characters after field concatenation, and generate a sequential encrypted ciphertext structure; When obtaining original consumer transaction data from financial transactions or mobile payment platforms, the transaction records within the day or specified time period are obtained by calling the data synchronization interface. The records contain account information (such as user ID or bank card number), transaction time (timestamp accurate to seconds), and transaction amount (in RMB). After the original fields are cleaned, three key fields are extracted in turn, namely the account field, time field, and amount field. Then, according to the pre-defined splicing rules, the three are combined into a single string in the form of "account_time_amount" for subsequent encryption. For example, a user's transaction account is "AC987654" and the transaction time is "20250418120 233", the amount is "1000.00", and the concatenation result is "AC987654-20250418120233-1000.00". The preset symmetric key is called to perform the AES encryption operation. The order of the fields is not changed during the encryption process. Only the key and initialization vector are used as input to execute the encryption process. The encrypted content generates a ciphertext, which is encoded with Base64 to form a structured string. The ciphertext sequence number and key number are generated to form a complete structure. The structure records the original concatenation method of the encrypted fields, the key number used, the ciphertext content, the corresponding data ID and other meta-information, which is convenient for subsequent verification and processing, and the output sequence encrypted ciphertext structure.

[0022] S102: Call the sequential encrypted ciphertext structure, write it into the target blockchain node, index the input ciphertext in the blockchain node according to the key index value built into the node, combine the node timestamp and the ciphertext sequence number, break up and rearrange the field structure, and perform re-encryption calculation to generate a node mixed encryption field; When writing the sequential encrypted ciphertext structure to the target blockchain node, the node identification interface is used to confirm the running status and built-in key index of the current blockchain node. According to the key number field in the sequential ciphertext structure, the corresponding key is found from the key index table inside the node. The index table records the number, encryption rule and applicable time range of each group of keys. After the search is successful, the ciphertext field is imported into the node encryption module. The node encryption module breaks up the field order of the original ciphertext structure according to the configuration rules. For example, "account-time-amount" is reordered to "amount-account-time". The breaking process is strictly performed according to the pre-set field mapping table. The fields are rearranged by shifting or exchanging the fields. After the rearrangement is completed, the encryption key independently maintained by the current node is used to re-encrypt the fragmented structure. The encryption key is different from the key used for the previous sequential encryption. After the new encrypted content is formed, the current node write timestamp and the original ciphertext sequence number are combined to generate a unique index. The "node write time + ciphertext sequence number" is set to form a unique key value. The encrypted field structure and the node identification number are synchronously written into the data block of the blockchain node, and the field position information is marked for subsequent field restoration operations. The generation process of the node mixed encryption field is completed, and the node mixed encryption field is generated.

[0023] S103: After extracting the field combination structure based on the node hybrid encryption field, perform a hash generation operation, store and combine the hash signature value and the original data, and obtain an encrypted data identifier; The field structure is decomposed, and the timestamp, key index, ciphertext content and sequence number contained therein are extracted as structural units in turn, and combined and reconstructed according to the preset field parsing format to generate a field combination structure. Each group of structural units will be used as the input content of the subsequent hash operation to perform hash generation processing. In the specific process, hash calculation is performed, and summary operations are performed on the combination structure in turn. If the first group of field combinations is "March 5, 2025 14:20, key index 003, ciphertext fragment A, sequence number 5", the corresponding hash signature value such as "hash value A1" is generated after hash processing. , the signature value is bound to the original field combination to form a record item, all field combinations are processed in turn, their hash signature results are generated and saved one by one, a mapping structure between fields and signatures is constructed, and a data storage structure is established at the same time. Each combination structure and its hash signature value are classified and managed, and the generated record item data sets are combined and stored in the node database to ensure that the field structure is traceable and verifiable. Each record uses its generated hash value as a unique identifier, and the specific encrypted data identifier is quickly located through the index structure to ensure that the encrypted field has independent identifiability and supports subsequent fast query and verification to obtain the encrypted data identifier.

[0024] The specific steps to obtain the access permission value are as follows: S201: Invoke the smart contract corresponding to the encrypted data identifier, extract the access permission condition fields defined in the smart contract structure. The field content includes the list of accessed addresses, the corresponding transaction types, and the permission thresholds. Then, perform field positioning and indexing based on the hash value bound in the identifier structure to generate a set of contract permission condition parameters. When invoking the smart contract bound to the encrypted data identifier, perform contract mapping retrieval through the hash value in the input encrypted data identifier. In this process, search for the smart contract address bound to the hash value in the contract registry. After the contract address is detected, enter the contract reading process to read the permission condition fields defined in the contract structure, including three types of key information: the list of accessed addresses, the transaction type field, and the permission threshold setting. The list of accessed addresses is a set of preset whitelist addresses, represented by hexadecimal public keys, such as "0xAB34...F1"; the transaction type field specifies the transaction behavior type number allowed for this address. For example, "TRX01" represents query type, and "TRX02" represents transfer type; the permission threshold field sets the access permission score for each type of transaction, such as setting the upper limit scores to 60 points, 80 points, 90 points, etc. After extracting the fields item by item from the contract structure, use the initial hash identifier value to perform positioning and matching on the field content to determine the structural offset position, ensuring the integrity and correct order of reading of the fields. Then, form each field into a parameter structure body, which records each address, the corresponding transaction type, and its permission threshold setting, and is used for the processing link of the subsequent access authorization process to generate a set of contract permission condition parameters.

[0025] S202: According to the address list field in the set of contract permission condition parameters, compare the public key address data provided by the consumer with the node addresses in the address list to check whether there are exact matching items with the same bit order, and obtain the public key address matching status based on the matching success flag bit to identify the verification status. The formula for comparing whether there are exact matching items with the same bit order is as follows: ; Where represents the degree of public key address matching, represents the number of address bytes to be compared, represents the th byte in the address list, represents the th byte in the public key address data provided by the consumer, represents the th byte, represents and the absolute value of the byte difference between them; Parameter meaning and formula calculation derivation process: and : Obtained by comparing the byte values in the address list and the public key address data provided by the consumer; : Set according to the importance of the byte in the address, and the first few bytes of the address have high weights; : Obtained by calculating the total number of address bytes; Set the number of address bytes to be compared , that is, each address consists of 4 bytes; Bytes in the address list: ; Bytes in the public key address data provided by the consumer: ; Byte weight: ; Calculate the absolute value of the difference of each byte: ; ; ; ; Calculate the sum of the weighted differences: ; Calculate the square root of the weight value: ; Calculate the sum of the square roots of the weight values: ; ; Substitute the above results into the formula: ;

[0026] The result shows the degree of address matching. The smaller the value, the more matching the address is. The larger the value, the greater the address difference.

[0027] S203: Invoke the transaction type field in the public key address matching status, compare with the real-time transaction request type data, extract the credit evaluation benchmark field corresponding to the successfully matched item, and generate an access permission value in combination with the consumer transaction frequency, account reputation score, and transaction requests within a unit time; The transaction type field corresponding to the address will be automatically extracted and compared with the transaction type declared in the real-time transaction request. For example, if the transaction type in the real-time request is "TRX02", a subset containing the "TRX02" transaction permission will be filtered out from the successfully matched addresses. For each matching item, the bound credit assessment benchmark field will be read. The field structure contains three dimensions: transaction frequency, account credit score, and number of requests per unit time. The average daily transaction frequency of the consumer in the past 30 days is read from the transaction database. For example, the average number of transfers per day is 15. The account credit score is generated according to the platform credit assessment model, ranging from 0 to 100. The score is 85 points, the request per unit time is the number of transaction attempts within the current hour, which is 3 times in this round. According to the benchmark values ​​set in the contract, for example, the credit requirement is not less than 80 points, the frequency requirement is less than 20 times per day, and the upper limit of requests per unit time is 5 times. These three indicators are compared with the contract benchmark values ​​one by one, and a three-item combined scoring logic is constructed according to the rules. For example, a comprehensive access right value is generated by weighting through a scoring weight mechanism. If the credit score weight is set to 50%, the frequency is 30%, and the number of requests within the time is 20%, the calculated access right value is 88 points. This value will be used as the core parameter for determining whether to authorize in the subsequent decision-making process to generate the access right value.

[0028] The specific steps for obtaining consensus type identification results are as follows: S301: Call the transaction level classification field corresponding to the access permission value, extract the level category number defined in the field and the corresponding processing priority value, combine the real-time blockchain network data, monitor the total number of transaction broadcasts and the number of active nodes in the time window, synchronize the time and perform cumulative statistical processing on the two types of data, and generate network operation status parameters; After calling the access right value, it is mapped to the predefined transaction level classification field. The transaction level field structure generally contains a level category number (such as LV1, LV2, LV3) and the processing priority value bound to the level (such as P1=low, P2=medium, P3=high). Matching is performed according to the numerical range of the access right value. If the access right value is set between 80 and 100, it is mapped to LV3, corresponding to the P3 priority. After the matching is completed, the current blockchain network status data is further combined to extract the number of broadcast transactions in the current time window from the broadcast nodes of the entire network. In the last 10 seconds, 3760 transactions were broadcast. At the same time, the number of nodes sending or receiving broadcast information in the time window is recorded through the node activity monitoring mechanism, such as 85. The two types of data are synchronized through a unified timestamp mechanism, that is, to ensure that the transaction data and the node data are in the same time segment to ensure the accuracy of the statistical analysis results. Cumulative statistics are performed on these two types of data, including the accumulation of the number of transactions and the total number of active nodes. The current transaction activity and node participation are recorded to provide a data basis for subsequent load judgment and generate network operation status parameters.

[0029] S302: Based on the number of transaction broadcasts and the number of active nodes in the network operation status parameters, construct the transaction density value and node response ratio per unit time, compare them with the set blockchain load identification benchmark value, identify the load status interval identifier, and generate the network load status level; After obtaining the network operation status parameters, convert the number of transaction broadcasts and the number of active nodes into metrics available in the analysis model, namely the transaction density value and node response ratio per unit time. The transaction density value refers to the number of transaction records broadcast per second. Set it to 376 records / second by calculating 3760 records / 10 seconds; the node response ratio refers to the ratio of the number of active nodes to the total number of nodes. If there are 100 nodes in the whole network, the ratio is 85%. Set several load identification benchmark values. For example, a density exceeding 300 records / second and a response ratio exceeding 80% are defined as the "medium-high load" state. Set multiple intervals such as "low load", "medium load", and "high load" to identify the current state of the network. Match and judge the currently calculated density value and response ratio with the benchmark interval. Set the current transaction density to 376 records / second and the response ratio to 85%, which falls into the "high load" interval. The judgment process uses a conditional judgment mechanism. Set the judgment order to first evaluate the transaction density and then consider the response ratio situation. The level name can be "LOAD_H" representing high load, and decide whether to enable the high-priority processing path or switch to the standby consensus mechanism to relieve network pressure and generate the network load status level.

[0030] S303: Invoke the transaction level number associated with the network load status level and access permission value for cross-matching, numerically compare the processing priority value defined in the level number with the resource allocation weight corresponding to the load status, calculate the resource allocation characteristic value, and select the consensus identifier corresponding to the processing path to generate the consensus type identification result; The formula for calculating the resource allocation characteristic value is as follows: ; Among them, represents the resource allocation characteristic value, represents the adjustment factor, represents the resource allocation weight dynamic balance coefficient, represents the processing priority value, represents the resource allocation weight corresponding to the load status, represents the load difference, represents the priority correction coefficient; Parameter meaning and formula calculation derivation process: Adjustment factor Set according to the matching relationship between the transaction level number and the load status, with a value range of 0.1 to 0.9, linearly adjusted with the load volatility. Take , corresponding to a load volatility of 10%; Dynamic balance coefficient Set according to the balance requirement of resource allocation weight and load, with a value range of 0.2 to 0.8, dynamically adjusted according to the resource allocation deviation index, and take this time, corresponding to a deviation index of 15; Processing priority value Mapped to a numerical value through the transaction level number, numbers 1 to 10 correspond to to , and take transaction level number 8 this time, mapped to ; Resource allocation weight Quantified through the load status level conversion table, corresponding to low, medium, and high load status respectively , , , and the current load status is medium, so ; Current load difference Obtained through real-time monitoring equipment, and the calculation formula is: ; Among them, the current load value , load threshold , calculated to be ; Priority correction coefficient Adjusted according to the standard deviation of the processing priority value, and the standard deviation interval of 0.1 to 0.5 corresponds to to , and the standard deviation is 0.3 this time, take ; Calculation process of the numerical example: Substitute the parameters , , , , , , and the formula expands to: ;

[0031] This result shows that the resource allocation eigenvalue approaches 1, reflecting a high matching degree between the current processing priority and the resource allocation weight. The negative impact of the load difference on the allocation result is offset by the correction coefficient part. The resource allocation eigenvalue is directly related to the calculation of the resource allocation characteristic parameters, and the numerical result is input into the consensus type recognition information, and the consensus type recognition result is generated through threshold judgment.

[0032] The specific steps for obtaining the node security score are as follows: S401: Using the consensus type identification result, calling the transaction data request record and block verification response information of the blockchain node, combining the timestamp information and operation frequency data of each node, respectively calculating the average data request frequency and response time of the node in the specified time period, and generating a node behavior frequency parameter group; Entering the consensus behavior analysis phase, through the identified consensus mechanism type (such as PBFT, DPoS, etc.), call the transaction data request record and block verification response information of each node in the blockchain node management, read the complete behavior log of each node in the specified time period, which can be defined as the past 60 seconds or 10 consensus rounds, obtain the issuance time and verification response time of each transaction request through the timestamp field recorded in the log, and combine the operation number data (such as the number of request issuance is 120 times, the number of response records is 110 times), calculate the average data request frequency and average response time setting of the node. If node A has initiated 120 requests in the past 60 seconds, its average request frequency is 2 times per second; its response time is the average value obtained by accumulating the time difference from each request to receiving confirmation and then dividing it by the number of responses. In this process, the timestamp information of each node needs to be synchronized to avoid time offset interference calculation caused by node clock drift. Each node will generate a set of behavior parameter data including "average request frequency" and "average response delay". This data is used for subsequent analysis of the behavior stability and response capability of the node under the current consensus mechanism and generating a node behavior frequency parameter group.

[0033] S402: According to the node behavior frequency parameter group, combined with the execution deviation time of multiple operation instructions of the node in the recent cycle, the corresponding node execution delay and response abnormality amplitude are extracted, and the node delay and response abnormality amplitude are respectively compared with the set offset state threshold, and the node set exceeding the threshold range is selected and the node number is marked to generate the node offset measurement result; Further analyze its actual operation performance within a specified period, especially focusing on the deviation of operation instruction execution. By retrieving the difference between the actual execution time of each instruction and the scheduled preset execution time, obtain the execution delay amount of each instruction. Set that the preset response should be completed within 10 milliseconds, but a certain execution of node B takes 22 milliseconds, then the delay amount is 12 milliseconds. Organize the delay amounts of operations, calculate the average delay and the maximum value for each node to form a delay performance indicator. At the same time, analyze the abnormal response amplitude, which refers to the degree of delay fluctuation in consecutive requests. If the response time of a node has a large jump, for example, it suddenly increases from 8 milliseconds to 50 milliseconds, then record its maximum abnormal amplitude as 42 milliseconds. The delay amount and the abnormal amplitude will be compared with the set offset status threshold. For example, set the offset delay threshold to 10 milliseconds and the abnormal amplitude threshold to 20 milliseconds. Screen out the nodes that exceed any threshold. During the comparison process, use the interval matching mechanism to label each node as "normal" or "abnormal" respectively, and record its unique node number for subsequent consensus weight adjustment and node risk scoring, forming the node offset measurement result.

[0034] S403: Invoke the consensus type classification information corresponding to the node number in the node offset measurement result, and combine the network transaction activity value and the consensus participation frequency to adjust the consensus weight parameter of the node to obtain the node security score; Invoke the consensus type classification information corresponding to each node number, and combine the transaction activity index in the current network and the participation frequency of the node under this consensus mechanism to correct its consensus weight parameter. The transaction activity value is determined by the number of broadcast transactions per unit time. Set that the number of transactions in the past 10 seconds is 4000, which is defined as a high activity level; the consensus participation frequency counts the number of block validations participated by the node in the past one or more rounds of consensus. For example, if node C participated in 4 rounds out of the past 5 rounds, then its frequency is 80%. Combine the node offset status and the data for comparison. For nodes with abnormal delay or serious response offset, even if their consensus participation frequency is high, their consensus weight will be appropriately lowered. On the contrary, if the node response is stable and the frequency is moderate, then maintain or slightly increase its weight parameter. The adjustment amplitude is controlled by the configured weight correction strategy. The score value quantifies the behavior stability and response reliability of the node in the current network and consensus mechanism, and can be used as the basis for subsequent consensus voting, task assignment, and anomaly elimination, generating the node security score.

[0035] The specific steps for obtaining the audit log identifier are as follows: S501: Invoke the node security score, extract the associated transaction number field, and read the block identifier and time stamp data bound under the corresponding transaction number. Combine the permission change type, target address, and adjusted time stamp field, and splice the three structures in sequence to obtain the block permission identification result; Obtain the transaction interaction information of the node through the interface, query all the corresponding transaction numbers of the node in the transaction index table through the unique node identifier. If the numbers are Transaction 001, Transaction 002, Transaction 003, etc., the number records the node behavior data. Process each transaction number one by one, extract the block number and block time marking information corresponding to each transaction number from the transaction details table. If Transaction 001 belongs to Block A001 and the time is 10:15 on March 1, 2025, format it as "Block A001|March 1, 2025 10:15". Continue to process Transaction 002, Transaction 003, etc. After that, query the permission change records related to the transaction, extract the permission change type field (such as permission addition, permission revocation), target address field (such as user address A1B2C3), and adjustment time field (such as 10:16 on March 1, 2025) that match each transaction number from the permission management table. Then splice the data in the order of "block number|block time|permission change type|target address|adjustment time". If it is "Block A001|March 1, 2025 10:15|permission addition|address A1B2C3|10:16 on March 1, 2025", this splicing structure maintains the unity of field order and the integrity of content. Repeat this operation to perform the same extraction and splicing on the transaction numbers for subsequent structure processing and security behavior analysis, and obtain the block permission identification result.

[0036] S502: Based on the field content in the block permission identification result, use the chained hash process to generate local hash values for each log entry in ascending order of time marking, perform an aggregate hash operation on the local hash values to construct a hash tree structure, extract the root node hash field of the hash tree, and generate a permission adjustment record; Sort in ascending order according to the adjusted timestamp field contained in each record to ensure that the processing order conforms to the time logic. During the sorting process, it is necessary to compare the adjusted time field values of all records, and arrange each permission change data in ascending order starting from the earliest time. For example, arrange in the order of 10:15, 10:20, 10:25 on March 1, 2025, etc. Each record is numbered in sequence after sorting, and each record is processed in sequence to generate its local hash value, that is, the overall structure data spliced according to the block number, original time, permission change type, target address, and adjusted time is used as the input, and the chained hash processing method is used to form the encrypted digest of each log. This process can use a programming language to implement the static hash processing logic, take the splicing result as the input string, and generate the digest through the hash function. The hash digest generated by a certain splicing structure is aabb1122. Continue to combine the local hash results in pairs in order to form a new hash input, and perform hash processing again to construct the upper-level hash node. Every two are combined to form a node, and continue to combine to form higher-level nodes to construct a hash tree structure. In this tree structure, the root node is the summary value of the permission change record, representing the consistent structure output of all permission adjustments. The generated root node hash value can be stored in the main record chain as the unique identifier of the permission adjustment record for future permission verification or backtracking operations, and generate the permission adjustment record.

[0037] S503: Call the transaction metadata bound to the permission adjustment record and the transaction number, align the indexes of the two and combine them into a binding structure, and write the binding structure into the immutable storage layer to generate an audit log identifier; Immediately call the transaction metadata of the record corresponding to its transaction number. The metadata includes fields such as transaction type, requester identity, public key address, and original request parameters, forming a set of static information describing the transaction background and attributes. Through the index mapping mechanism, the permission log hash is bound and aligned with the transaction number one by one to ensure that each permission log corresponds to a clear transaction behavior. After alignment, construct a binding structure. The internal fields of this structure include: transaction number, permission adjustment record, block identifier, permission operation details, and original metadata content. After construction, call the write interface of the immutable storage layer, set to use a distributed file or a dedicated audit blockchain node, write this structure into the on-chain storage area as an unchangeable data unit, and at the same time generate a unique data identifier number, set "LOG20250418140001", and record the timestamp of the write operation and the calling node number to ensure the integrity of the log and the ability to trace and trace, and return this log identifier as the audit reference number for external or subsequent verification processes to call and use, and generate the audit log identifier.

[0038] As described above, it is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claimed rights.

Claims

1. A data transaction method based on blockchain, characterized in that: The following steps are involved: S1: Get the original consumption transaction data, perform multi-layer encryption on the data, generate primary encrypted ciphertext through the first layer of encryption, input the primary encrypted ciphertext into the blockchain node for secondary encryption, calculate the hash value of the multi-layer encrypted ciphertext, and generate an encrypted data identifier; S2: calling the smart contract corresponding to the encrypted data identifier, extracting the access permission conditions defined in the smart contract, detecting the consumer's public key address and transaction request type, matching the public key address with the address list in the permission conditions, and automatically verifying if the match is successful, dynamically calculating the credit score with reference to the consumer's behavior, and assigning access permission instructions if the score exceeds a preset threshold, and generating an access permission value; S3: Call the transaction level classification corresponding to the access permission value, monitor the real-time transaction volume and node activity status of the blockchain network, evaluate the correlation between the network load status and the transaction level classification, and generate a consensus type identification result; S4: Through the consensus type identification result, the data request frequency and verification response speed of the blockchain node are extracted, and the node behavior deviation state is analyzed. If the deviation state exceeds the preset threshold, the consensus weight value of the node is adjusted to generate a node security score.

2. The data transaction method based on blockchain according to claim 1 is characterized in that: The encrypted data identifier includes an encrypted ciphertext hash, a data storage location identifier, and an encryption level mark; the access permission value includes an authority matching status, a dynamic credit level, and a permission instruction code; the consensus type identification result includes a load status level, a transaction emergency classification, and a consensus mechanism type; the node security score includes a behavior deviation coefficient, a weight adjustment ratio, and a security assessment label.

3. The data transaction method based on blockchain according to claim 1 is characterized in that: The steps for obtaining the encrypted data identifier are specifically as follows: S101: Obtain original consumption transaction data, extract account information, transaction time and transaction amount, call the symmetric key, encrypt the transaction characters after field concatenation, and generate a sequential encrypted ciphertext structure; S102: calling the sequential encrypted ciphertext structure, writing it into the target blockchain node, indexing the input ciphertext in the blockchain node according to the key index value built into the node, combining the node timestamp and the ciphertext sequence number, breaking up and rearranging the field structure, and performing re-encryption calculation to generate a node mixed encryption field; S103: After extracting the field combination structure based on the node hybrid encryption field, perform a hash generation operation, store and combine the hash signature value and the original data, and obtain an encrypted data identifier.

4. The data transaction method based on blockchain according to claim 3 is characterized in that: The steps for obtaining the access permission value are specifically as follows: S201: calling the smart contract corresponding to the encrypted data identifier, extracting the access permission condition field defined in the smart contract structure, the field content including the access address list, the corresponding transaction type and the permission threshold, and locating and indexing the field based on the hash value bound in the identifier structure, and generating a contract permission condition parameter set; S202: According to the address list field in the contract permission condition parameter set, compare the public key address data provided by the consumer with the node address in the address list to see if there is a complete match with the same bit sequence, and identify the verification status according to the match success flag bit to obtain the public key address matching status; S203: Call the transaction type field in the public key address matching status, compare it with the real-time transaction request type data, extract the credit assessment benchmark field corresponding to the successful matching item, and generate the access permission value by combining the consumer transaction frequency, account credit score and transaction requests per unit time.

5. The data transaction method based on blockchain according to claim 4 is characterized in that: The formula for comparing whether there are exact matches of the same bit sequence is as follows: ； in, Represents the degree of matching of the public key address, Represents the number of address bytes to be compared. Represents the address list Bit Byte, Represents the first public key address data provided by the consumer Bit Byte, Representative The weight value of the byte, express and The absolute value of the byte difference between the two.

6. The data transaction method based on blockchain according to claim 4 is characterized in that: The steps for obtaining the consensus type identification result are specifically as follows: S301: Call the transaction level classification field corresponding to the access permission value, extract the level category number defined in the field and the corresponding processing priority value, combine the real-time blockchain network data, monitor the total number of transaction broadcasts and the number of active nodes in the time window, perform time synchronization and cumulative statistical processing on the two types of data, and generate network operation status parameters; S302: Based on the transaction broadcast quantity and the number of active nodes in the network operation status parameters, construct a transaction density value and a node response ratio per unit time, compare and judge with the set blockchain load identification benchmark value, identify the load status interval identifier, and generate a network load status level; S303: Call the transaction level number associated with the network load status level and the access permission value for cross-matching, perform numerical comparison between the processing priority value defined in the level number and the resource allocation weight corresponding to the load status, calculate the resource allocation characteristic value, select the consensus identifier corresponding to the processing path, and generate a consensus type identification result.

7. The data transaction method based on blockchain according to claim 6 is characterized in that: The formula for calculating the resource allocation characteristic value is as follows: ； in, represents the characteristic value of resource allocation, represents the adjustment factor, Represents the dynamic balance coefficient of resource allocation weight, Represents the processing priority value, Represents the resource allocation weight corresponding to the load status, Represents the load difference, Represents the priority correction factor.

8. The data transaction method based on blockchain according to claim 6 is characterized in that: The steps for obtaining the node safety score are specifically as follows: S401: Using the consensus type identification result, calling the transaction data request record and block verification response information of the blockchain node, combining the timestamp information and operation frequency data of each node, respectively calculating the average data request frequency and response time of the node in the specified time period, and generating a node behavior frequency parameter group; S402: extract the corresponding node execution delay and response abnormality amplitude according to the node behavior frequency parameter group and the execution deviation time of multiple operation instructions of the node in the recent cycle, and compare the node delay and response abnormality amplitude with the set offset state threshold respectively, select the node set exceeding the threshold range and mark the node number, and generate the node offset measurement result; S403: Call the consensus type classification information corresponding to the node number in the node offset measurement result, combine the network transaction activity value and the consensus participation frequency, adjust the consensus weight parameter of the node, and obtain the node security score.

9. The data transaction method based on blockchain according to claim 1, characterized in that: The method further comprises step S5: S5: Call the node security score, extract the block identifier and time stamp of the corresponding transaction, combine the block identifier, time stamp, and permission change record into a log structure, use a chain hash process to perform hash calculation on the log structure, bind the root hash identifier to the transaction metadata, and write it into the tamper-proof storage layer to generate an audit log identifier; The audit log identifier includes a block height code, a timestamp sequence, and a root hash summary.

10. The data transaction method based on blockchain according to claim 9 is characterized in that: The steps for obtaining the audit log identifier are specifically as follows: S501: calling the node security score, extracting the associated transaction number field, and reading the block identifier and time stamp data bound to the corresponding transaction number item, combining the permission change type, target address and adjustment timestamp fields, sequentially splicing the three types of structures to obtain a block permission identification result; S502: Based on the field content in the block permission identification result, a chain hash process is used to generate a local hash value for each log entry in ascending order of the time stamp, an aggregate hash operation is performed on the local hash value to construct a hash tree structure, a root node hash field of the hash tree is extracted, and a permission adjustment record is generated; S503: Call the transaction metadata bound to the permission adjustment record and the transaction number, align the indexes of the two and combine them into a binding structure, write the binding structure to the tamper-proof storage layer, and generate an audit log identifier.

Images