A blockchain technology-based revenue sharing data management method and system

Abstract

This invention relates to the field of revenue sharing data management, and more particularly to a method and system for revenue sharing data management based on blockchain technology. The method includes: acquiring a multi-source business data set associated with the current transaction and extracting key business feature vectors from each data source; calculating a business multi-source data consistency index based on the key business feature vectors; acquiring basic credit information of the transaction participants, calculating the basic risk coefficient of the participants, and combining this with the business multi-source data consistency index to generate a comprehensive transaction risk coefficient for this transaction; generating an adaptive signature threshold through a preset nonlinear mapping function; executing a blockchain threshold signature process based on the adaptive signature threshold; and triggering a smart contract for fund revenue sharing and settlement after successful signature verification. This invention dynamically adjusts the signature threshold by combining the business multi-source data consistency index and the comprehensive transaction risk coefficient, thereby improving the balance between data reliability and system efficiency.

Description

Technical Field

[0001] This invention relates to the field of revenue sharing data management. In particular, it relates to a method and system for revenue sharing data management based on blockchain technology. Background Technology

[0002] With the widespread application of blockchain technology in supply chain finance and industrial internet platforms, automated settlement based on smart contracts has become an important means of ensuring transparent and trustworthy fund flows. Existing settlement data management methods typically use threshold signature mechanisms with preset fixed thresholds to trigger smart contract execution. However, this approach has limitations in supply chain settlement scenarios.

[0003] Existing mechanisms only verify the legitimacy of the signer's identity, lacking automated semantic verification of the off-chain business data to which the signature is attached. This means that cryptographically valid signatures may map to fraudulent business data. Furthermore, existing mechanisms use fixed signature passing thresholds, failing to adapt to the dynamic credit ratings of the transacting parties or the quality of transaction data. This results in low-risk transactions being hampered by cumbersome verification processes, impacting settlement efficiency, while high-risk transactions may lack sufficient multi-party verification due to fixed thresholds, making it difficult to achieve a balance between risk control security and settlement efficiency. Summary of the Invention

[0004] To address the problems of existing technologies lacking off-chain data semantic verification and fixed thresholds being unable to adapt to dynamic business risks, leading to misjudgments or low settlement efficiency, this invention provides solutions in the following aspects.

[0005] In the first aspect, a blockchain-based method for managing split-ledger data includes: acquiring a multi-source business data set associated with the current transaction and extracting key business feature vectors from each data source; calculating a business multi-source data consistency index based on the key business feature vectors; acquiring basic credit information of the transaction participants, calculating the basic risk coefficient of the participants, and calculating and generating a comprehensive transaction risk coefficient for this transaction in conjunction with the business multi-source data consistency index; generating an adaptive signature threshold based on the comprehensive transaction risk coefficient using a preset nonlinear mapping function; executing a blockchain threshold signature process based on the adaptive signature threshold; and triggering a smart contract for fund split-ledger settlement after the signature verification is successful.

[0006] Preferably, the process of obtaining the business multi-source data consistency index includes: The key business feature vectors of each data source are matched pairwise, and the number of successfully matched data source pairs is counted. The ratio of the number of successfully matched data source pairs to the theoretical maximum number of matched pairs is calculated, and this ratio is used as a consistency indicator for multi-source business data.

[0007] Preferably, the process of obtaining the basic risk coefficient of the participating entity includes: Determine the set of all corporate entities involved in the fund transfers in this transaction, and set the total number of periods for credit assessment tracing; Obtain the historical credit score sequence of each participating enterprise in the set over the past several assessment periods. The historical credit score is derived from the output of the credit assessment model that is updated in real time in the dynamic trusted data pool. Construct a time-weighted sequence, where the time weight of each evaluation period satisfies that the sum of the weights of all periods is 1. For each participating enterprise in the set, calculate the weighted credit score of the participating enterprise based on the historical credit score sequence and time-weighted sequence corresponding to each participating enterprise, and calculate the individual basic risk value of the participating enterprise using a normalization formula according to the maximum and minimum credit score preset by the system. Iterate through the individual basic risk values ​​of all participating companies in the set, and select the largest value as the basic risk coefficient of the participating entity in this transaction.

[0008] Preferably, the process of obtaining the overall transaction risk coefficient includes: The basic risk coefficients of the participating entities are numerically reverse-mapped to obtain the entity credibility coefficient, which represents the basic credibility level of the participating entities. The consistency degree of multi-source business data is weighted and fused with the entity credibility coefficient to obtain the transaction credibility index, which represents the overall credibility level of this transaction. The transaction credibility index is numerically reverse-mapped, and the mapping result is used as the comprehensive transaction risk coefficient for this transaction.

[0009] Preferably, the process of obtaining the adaptive signature threshold includes: The system sets a preset basic number of signers and a maximum number of signers allowed by the system. The basic number of signers serves as the minimum security threshold, and the maximum number of signers serves as the maximum security threshold. The maximum number of signers is less than the total number of participants. The overall transaction risk coefficient is mapped to a dynamic adjustment range consisting of the number of basic signers and the number of maximum signers, to obtain a continuous threshold variable that matches the current transaction risk level. The continuous threshold variable is discretized and rounded down, and the result is determined as the minimum number of signers required to trigger the split settlement, i.e., the adaptive signature threshold. The system generates threshold signature key fragments based on the maximum number of signers, ensuring that the adaptive signature threshold is always within the effective support range of the threshold signature mechanism.

[0010] Preferably, the step of triggering the smart contract to perform fund distribution and settlement specifically includes: Based on the adaptive signature threshold, collect the private key fragment signatures of the transaction participants; When the number of valid signatures collected is greater than or equal to the adaptive signature threshold, the final signature is synthesized and verified. The smart contract is invoked to execute the fund transfer based on the transaction amount in the multi-source business data set and the preset revenue sharing rules.

[0011] Preferably, the step of executing the blockchain threshold signature process based on the adaptive signature threshold, and triggering a smart contract for fund distribution and settlement after the signature verification is successful, includes: Obtain the signature fragments generated by the participating nodes that have reached the adaptive signature threshold, and reconstruct the signature fragments to generate an aggregate signature corresponding to the revenue sharing data; The aggregated signature, adaptive signature threshold, and ledger data are packaged into the blockchain transaction structure and broadcast to the blockchain network; Verification nodes in the blockchain network receive blockchain transactions and verify the validity of aggregate signatures based on the threshold signature public keys stored in the blockchain ledger. If the verification passes and the number of signers corresponding to the aggregated signature is not less than the adaptive signature threshold, the smart contract is executed to record the revenue sharing data into the distributed ledger and generate an immutable data block.

[0012] Secondly, a blockchain-based revenue sharing data management system includes a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the aforementioned blockchain-based revenue sharing data management method is implemented.

[0013] The present invention has the following effects: 1. This invention compares key business feature vectors from various data sources pairwise and uses mathematical algorithms to quantify the consistency of data. It effectively identifies and intercepts semantic conflicts caused by data entry errors, inconsistent formats, or malicious tampering, solving the problem of settlement misjudgment caused by lack of data verification in the prior art and ensuring the credibility of on-chain settlement data from the source.

[0014] 2. This invention weights and integrates the basic risk coefficients of participating entities with the consistency indicators of multi-source business data. It not only considers the historical credit performance of enterprises, but also combines the real-time quality of current transaction data, and generates an accurate comprehensive transaction risk coefficient through a nonlinear mapping function.

[0015] 3. This invention dynamically maps an adaptive signature threshold to a comprehensive transaction risk coefficient. While ensuring the basic and maximum number of signers, it converts continuous risk values ​​into a specific number of signing nodes through discretization. When the risk is high, the threshold is automatically increased to strengthen consensus verification; when the risk is low, the threshold is decreased to accelerate settlement. This flexible mechanism ensures that, in any business scenario, the blockchain ledger system can maintain optimal business processing efficiency while ensuring fund security. Attached Figure Description

[0016] Figure 1 This is a flowchart of steps S1-S4 in a blockchain-based ledger data management method according to an embodiment of the present invention.

[0017] Figure 2 This is a structural block diagram of a blockchain-based revenue sharing data management system according to an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0019] Reference Figure 1 A blockchain-based method for managing distributed ledger data includes steps S1-S4, as detailed below: S1: Obtain the multi-source business data set associated with the current transaction and extract the key business feature vectors of each data source.

[0020] By using pre-defined API interfaces, database middleware, or IoT gateways, heterogeneous data sources from different business systems associated with the current revenue sharing transaction can be accessed. A multi-source business data set can be constructed through these heterogeneous data sources, which includes business voucher data, performance process data, and transaction behavior data.

[0021] The business voucher data includes purchase orders, electronic invoices, and contracts; the performance process data includes logistics tracks, warehouse entry and exit records, and payment records; and the transaction behavior data includes user operation logs and environmental parameters collected by IoT devices.

[0022] Multi-source business data sets Each data source The process involves cleaning the data, removing invalid characters and spaces from text fields, converting time fields of different formats to a standard timestamp format, and unifying quantities and amounts from different units of measurement to a standard unit. This is done from the cleaned data sources. The core business attributes are extracted from the data, including the business occurrence timestamp, the unique identifier of the business entity, and the business-related numerical values, and a key business feature vector is constructed. ,in, Indicates the time of occurrence. This means mapping transaction-related fields such as contract number, order number, or batch number to a unified code. Represents quantity and amount fields; a data source Corresponding to a key business feature vector This is to facilitate cross-source data consistency comparison in subsequent modules.

[0023] S2: Calculate the business multi-source data consistency index based on key business feature vectors.

[0024] The key business feature vectors of the data source are combined in pairs to form several data source pairs to be verified, such as: pairing purchase orders with tax invoices, pairing logistics tracks with warehouse records, etc.

[0025] For each data source pair, the system executes consistency verification logic: First, it compares the unique identifiers of both parties, such as whether the order number and invoice number are associated. If the identifier association is valid, it further compares the degree of deviation between the time characteristics and the numerical characteristics. If the time difference between the two is within a preset reasonable threshold (such as 24 hours) and the numerical difference rate is lower than a preset fault tolerance threshold (such as 0.1%), then the data source pair is considered to be successfully matched; otherwise, it is considered to be a failed match.

[0026] Specifically, the consistency index of multi-source business data satisfies the following relationship: ; In the formula, It indicates the degree of consistency of multi-source data in business operations, and is used to measure the degree of consistency between multi-source data related to the current transaction in terms of business logic; Indicates the index number of the data source, representing a specific data source (such as logistics data) in a multi-source business data set. Indicates the index number of the other data source in the pair; This indicates the total number of data sources participating in the verification of this transaction; Indicates the first A key business feature vector participating in the verification Indicates the first Key business feature vectors participating in the verification, key business feature vectors It includes key feature vectors such as time, cargo identification, and quantity; This represents the matching function on the key business feature vectors of two data sources. Before matching, the system first verifies the internal hash integrity of each data source (i.e., recalculates). With storage (Comparison) If the hash verification fails, the data source is directly determined to be unavailable and the transaction is terminated; if successful, the key business feature vectors of the two data sources are matched, with 1 for a successful match and 0 for a failure. This represents the total number of pairwise data source pairs. .

[0027] In the formula, the numerator term This represents the total number of successful pairwise matches after pairing all data sources in a multi-source business data set. The calculation process essentially performs a full-connection consistency scan of the data set, aiming to capture potential record conflicts between any two independent business systems. In supply chain operations, any inconsistency in key business fields between any pair of data sources, such as orders and invoices, or logistics and warehousing, may indicate potential risks of document forgery, operational errors, or fraud. Therefore, calculating the total number of successful matches through iterative summation comprehensively reflects the degree of consistency of current transaction data at the micro level. (Denominator term) This represents the theoretically maximum number of matching pairs that can be formed given the current number of data sources. Its core physical significance lies in eliminating the impact of the number of data sources participating in the verification process. The differences in dimensions arise from variations in data sources. In actual business operations, the complexity of different transactions varies; some transactions may involve only three data sources, while others involve five or more. By dividing by the theoretical maximum logarithm for normalization, transactions of different complexities and data source sizes achieve uniform comparability, ensuring the universality of risk assessment standards.

[0028] The underlying business logic behind the consistency of multi-source business data is to verify whether a transaction constitutes a complete multi-party logical loop. A genuine supply chain transaction will inevitably leave mutually corroborating and logically consistent traces in the systems of multiple participants, such as procurement, logistics, warehousing, and taxation. Therefore, only when the vast majority, or even all, of data source pairs can successfully match will the consistency of multi-source business data approach a high value, conforming to the basic objective laws of multi-party collaborative trade.

[0029] It should be noted that, further, considering the dynamic changes in the number of data sources in actual business scenarios, this embodiment has adaptively extended the calculation logic of the consistency index, specifically including two processing modes: multi-source cross-validation and single-source benchmark evaluation. Furthermore, the matching function employs multi-source cross-validation logic, which is specifically represented by the logical product of three independent sub-validation results. That is, only when the results of identity verification, quantity consistency verification, and time logic verification simultaneously meet the preset conditions are the two data sources determined to be successfully matched.

[0030] Identity verification determines whether two data sources to be compared point to the same physical transaction. It extracts pre-defined transaction association identifiers from both data sources, such as a unified contract number, batch number, or business transaction number, for comparison. Identity verification is considered successful only if the association identifiers are completely identical. By locking the comparison object at the business logic level, it effectively avoids incorrect matching or confusion of data from different transaction objects, ensuring that subsequent comparisons are based on correctness.

[0031] Quantity consistency verification determines whether there is a reasonable deviation between the business values ​​recorded by two data sources. First, the absolute value of the difference between the business quantity or transaction amount in the two data sources is calculated, and then this absolute value is divided by the larger of the two values ​​to obtain the relative error ratio. Subsequently, the relative error ratio is compared with a preset quantity business tolerance threshold. If the relative error ratio is less than or equal to the quantity business tolerance threshold, the quantity consistency verification is considered successful. Using a relative error rather than absolute equality method accommodates reasonable losses or differences in measurement accuracy that may exist in actual supply chain business scenarios, such as logistics weighing and warehouse inventory counting. This ensures data authenticity while avoiding matching failures due to minor objective deviations.

[0032] The time logic check determines whether two data sources belong to the same transaction cycle in terms of business occurrence sequence. It extracts the business occurrence timestamps from both data sources under a unified time standard and calculates the absolute value of the time difference between them. Then, it checks whether this absolute value of the time difference is within a preset transaction cycle time window threshold. If the time difference is within the preset transaction cycle time window threshold, the time logic check is considered passed. This ensures that the data sources participating in the comparison are correlated in the time dimension, effectively preventing the system from incorrectly matching current real-time transaction data with historical legacy data or future pre-entered data, thus guaranteeing the temporal correctness of the business logic.

[0033] In summary, by employing a logical product-based verification mechanism, the system only determines that the two data sources are logically matched if the identity verification, quantity consistency verification, and time logic verification all pass. If any one of these verifications fails, the matching is deemed unsuccessful. This veto-based approach ensures that the final calculated consistency index is based solely on truly relevant and logically consistent transaction data, significantly improving the accuracy of subsequent risk assessment and revenue sharing.

[0034] In addition, it should be noted that, typically, the number of data sources included in the multi-source business data set acquired by the system is... Greater than or equal to 2. In this scenario, the business multi-source data consistency index is derived by calculating the ratio of the number of successful matches between different data sources to the theoretical maximum number of matches. Utilizing the mutual corroboration of multi-source data can comprehensively and objectively reflect the integrity and authenticity of the transaction chain.

[0035] In certain special business scenarios, such as when there is only a single purchase order and a lack of subsequent logistics or invoice data, the number of data sources to be acquired is... The result equals 1. At this point, due to the lack of other data sources for cross-comparison, the above ratio calculation cannot be performed. Therefore, a single-source benchmark assessment is used to replace the formula calculation result.

[0036] For example, a preset single-source consistency benchmark value is established, which is a positive constant with a preset value less than 1; in this embodiment, it is set to 0.5. Since cross-system data loops cannot be used for mutual verification, the data authenticity and tamper resistance are relatively weak. Therefore, the system uses the benchmark value to provide a reasonable and conservative basis for credibility in risk assessment under single-source scenarios, avoiding the erroneous assignment of excessively high trust scores due to missing data sources.

[0037] S3: Obtain the basic credit information of the transaction participants, calculate the basic risk coefficient of the participants, and combine it with the business multi-source data consistency index to calculate and generate the comprehensive risk coefficient of this transaction.

[0038] The steps for extracting basic credit information are as follows: obtain all transaction participants involved in fund transfers in the split transaction and form a set, preset the credit assessment traceability period, and extract the historical credit score of each transaction participant in the set within the past preset credit assessment traceability period, thereby forming a historical credit score sequence for each transaction participant, reflecting the credit performance at different historical stages.

[0039] Using the current moment as a time base point, the system traces back and retrieves all historical credit score records of the transaction participants within a preset time period, for example, the past 6 months or the past year. These historical credit score records constitute the basic dataset for subsequent statistical analysis, reflecting the credit fluctuations of the participants over a period of time.

[0040] Historical credit scoring records refer to structured data stored in the back-end credit management database or third-party credit reporting system interface that can quantitatively reflect the past performance capabilities and credit status of transaction participants. Specifically, historical credit scoring records include, but are not limited to, objective indicators such as: the entity's quantitative credit score, credit rating (e.g., A / B / C / D) in past transaction periods, number of historical defaults, administrative penalty records, or industry disciplinary points.

[0041] A time-weighted sequence is constructed to quantify the influence of data from different historical periods on the current risk assessment. The time weight coefficient of each assessment period satisfies the condition that the sum of the weights of all periods is 1, and the period weight value shows an increasing trend as the assessment time approaches the current time. This makes the recent credit performance of the participating entities more important than their long-term credit performance, thereby more accurately capturing the current credit dynamics of enterprises.

[0042] The historical credit scores of transaction participants are weighted and summed using time-weighted sequences to obtain a weighted credit score reflecting the overall creditworthiness. Normalization is then performed: the difference between the weighted credit score and the system's preset minimum credit score is calculated, and this difference is divided by the difference between the system's preset maximum and minimum credit scores to obtain a relative credit ratio. Finally, the relative credit ratio is subtracted from 1. This transforms the original credit score into a risk probability value with a uniform dimension; the lower the credit score, the higher the calculated risk value.

[0043] The system iterates through the individual basic risk values ​​of all participants in the transaction set and selects the maximum value. This maximum value is then determined as the basic risk coefficient for this transaction. Following the "weakest link" principle in risk management, the security of the entire transaction chain depends on the participant with the worst creditworthiness. By selecting the maximum risk value, the system can measure the overall basic risk of this transaction with the most stringent standards, thus providing a conservative and safe benchmark for subsequent comprehensive risk adjustments.

[0044] Specifically, the underlying risk coefficient satisfies the following relationship: ; In the formula, This represents the basic risk coefficient of the participating entities, used to measure the initial risk level of participating companies in a transaction based on their historical credit history. This refers to the set of corporate entities involved in the fund transfer in this transaction, including all entities involved in the fund transfer; Indicates the index number of the participating company. , ; This indicates the total number of periods for which credit assessments are retrospectively applied (e.g., past). (months) The index number indicating the evaluation period. ; Indicates the first The time weight of each evaluation period satisfies Furthermore, the weight of recent periods is greater than that of long-term periods. For example, an exponential decay method can be used for calculation, as shown in the formula: ,in Attenuation coefficient (recommended) ), To assess the total number of cycles, The index is set to the current period, making the weight of recent periods significantly higher than that of distant periods; alternatively, a linear decay method can be used for calculation, as shown in the formula. This ensures that the weights increase uniformly with the periodic index, guaranteeing that the weight of the most recent period is the same as that of the earliest period. Both methods ensure that more recent data has a greater impact on risk assessment; Indicates the first The participating companies in the first The current credit score for each assessment period is derived from the real-time updated credit assessment model output in a dynamic trusted data pool. This represents the minimum value of the system's credit score, that is, the lowest passing grade or theoretical lower limit in the credit assessment system; This represents the maximum value of the system's credit score, that is, the highest rating or theoretical upper limit in the credit assessment system.

[0045] The above steps overcome the technical limitations of relying solely on the basic risk coefficient of participating entities for risk control decisions. Since the basic risk coefficient of participating entities is mainly derived from the historical credit records of enterprises, it is a static indicator and cannot reflect the quality and authenticity of specific business data in a single transaction in real time. This can easily lead to misjudgments by the system when faced with abnormal transactions from high-credit entities or high-quality transactions from ordinary credit entities, thereby triggering financial risks or reducing the settlement efficiency of normal business. Therefore, to achieve more accurate risk assessment, the consistency degree of multi-source business data is introduced as a dynamic correction factor to calibrate the static basic risk in real time. By calculating the comprehensive transaction risk coefficient, the logical transmission from the historical credit of the entity to the real-time credit of the transaction is realized. The specific steps are as follows: The obtained basic risk coefficients of participating entities are subjected to numerical inverse mapping processing to obtain the entity credibility coefficient, which characterizes the basic credibility level of the participating entities. An inverse logical relationship between risk and credibility is established, that is, the lower the basic risk coefficient of a participating entity, the higher its corresponding entity credibility coefficient, thereby quantifying the basic creditworthiness of the enterprise over a historical dimension.

[0046] The consistency of multi-source business data in this transaction is weighted and fused with the aforementioned entity credibility coefficients to derive a transaction credibility index reflecting the overall credibility level of this transaction. The consistency of real-time transaction data is then used to correct and weight the static entity credibility. Only when the transaction data exhibits high consistency can the entity's basic credibility be effectively preserved and transferred to the final transaction evaluation; conversely, if data consistency is low, the entity's credibility will be weakened during the fusion process, thus ensuring that the evaluation results accurately reflect the true quality of each individual transaction.

[0047] The transaction credibility index is then subjected to a reverse numerical mapping process, and the mapping result is used as the overall transaction risk coefficient for this transaction.

[0048] Specifically, the overall risk coefficient of the transaction satisfies the following relationship: ; in, This represents the overall risk coefficient of a transaction, used to measure the overall risk level after combining the creditworthiness of the entity and the quality of the transaction data. Indicates the basic risk coefficient of the participating entities; This indicates the degree of consistency of multi-source business data.

[0049] In other words, the basic risk coefficient of the participating entities should be determined first. Perform a numerical inverse mapping to obtain the subject credibility, which characterizes the subject's basic credibility. The range of values ​​for the subject's credibility is as follows: This process reverses the historical credit risk of an entity into its credibility level: the lower the entity's basic risk coefficient, the higher its credibility. Simultaneously, it considers the consistency of multi-source business data. As a measure of data consistency reliability, its value range is also [missing information]. This is used to objectively reflect the consistency and reliability of the real-time data for this transaction.

[0050] Furthermore, the credibility of the subject Reliability of data consistency Perform a product operation to obtain the joint confidence level. The system employs a multiplicative coupling approach to achieve dual credibility logic: the transaction as a whole possesses high credibility only when the subject is trustworthy and the data is consistent; if any dimension carries risk, the value approaches 0, and the joint credibility will decrease accordingly, thereby ensuring that subject risk and data risk are effectively integrated at the same level.

[0051] Finally, a numerical inverse mapping is performed on the joint credibility, and the mapping result is determined as the comprehensive risk coefficient of the transaction. The joint credibility is inversely converted into a comprehensive risk value, enabling a direct quantification of the overall risk level of the transaction and providing data support for subsequent risk control decisions.

[0052] In real-world business scenarios, when the creditworthiness of the main entity is excellent and the data consistency is extremely high, the joint credibility approaches 1, and the overall transaction risk coefficient is low. When the joint trust value approaches 0, the system determines the transaction to be in a low-risk state and generates the minimum signature threshold in subsequent steps to ensure efficient settlement of high-quality transactions. When the creditworthiness of the parties is extremely poor or the data consistency is extremely low, the joint trust value approaches 0, and the overall risk coefficient of the transaction is high. When the value approaches 1, the system determines that the transaction is in a high-risk state. This coefficient, as the main input, will drive the signature threshold to rise, thereby automatically triggering a more stringent multi-party signature verification process, effectively ensuring the security and reliability of the settlement.

[0053] S4: Based on the transaction comprehensive risk coefficient, an adaptive signature threshold is generated through a preset nonlinear mapping function. The blockchain threshold signature process is executed based on the adaptive signature threshold. After the signature verification is successful, the smart contract is triggered to perform fund distribution and settlement.

[0054] Although a comprehensive transaction risk coefficient is calculated and obtained, this coefficient is essentially a continuous numerical indicator. However, the threshold signature mechanism at the blockchain's underlying layer requires a discrete and specific integer number of signers during actual execution. If an unconstrained risk coefficient is directly used for control, the calculated signature threshold could easily exceed the total number of participants, leading to a failure to reach consensus and transaction congestion. Furthermore, existing technologies typically use a fixed signature threshold, requiring the same number of nodes to verify signatures regardless of transaction risk. This one-size-fits-all strategy often results in unnecessary settlement delays for low-risk transactions or security vulnerabilities in high-risk transactions due to insufficient verification.

[0055] To translate abstract risk assessment results into actionable security policies, this step establishes a dynamic mapping relationship between risk coefficients and the number of signatures. The specific implementation steps are as follows: First, define the baseline parameters for the security boundary: the basic number of signers and the maximum number of signers. Basic number of signers (minimum security threshold): This is the bottom line for the system to maintain normal operation. When the transaction risk is extremely low, the system only needs to meet this number of signatures to reach consensus. Its physical significance lies in ensuring the system's liveness, that is, avoiding the failure of normal low-risk transactions to settle due to insufficient signing nodes in pursuit of absolute security. Maximum number of signers (maximum security threshold): This is the highest security level the system can provide, and this number is strictly less than the total number of participants. Its physical significance lies in ensuring the system's fault tolerance, that is, reserving a portion of nodes as redundancy (allowing for disconnections or failures), ensuring that even when the highest security level is required, the system will not be paralyzed due to some nodes going offline.

[0056] Based on the actual risk level of the current transaction, a continuous theoretical threshold variable is derived by linear interpolation or proportional calculation between the minimum and maximum thresholds. In other words, the higher the transaction risk, the closer the calculated theoretical signature requirement is to the maximum number of signers; conversely, the lower the risk, the closer the requirement is to the basic number of signers.

[0057] Because the threshold signature protocol at the bottom of the blockchain requires that the number of nodes participating in the signature must be an integer, the system needs to perform discretization and rounding on this continuous threshold variable.

[0058] Specifically, the adaptive signature threshold satisfies the following relationship: ; In the formula, This represents the adaptive signature threshold, which is the minimum number of signers required to trigger revenue sharing and settlement, and is a positive integer. This indicates the overall risk coefficient of the transaction; This represents the system's preset minimum number of signers, i.e., the minimum security threshold, which is usually set to a fraction of the total number of participants. The above settings follow the most robust fault-tolerant mathematical model in distributed systems. They satisfy the minimum security requirements for preventing malicious attacks, while also ensuring stability to prevent system forks, and providing ample redundancy for node failures. This indicates the maximum number of signers allowed by the system, i.e., the highest security threshold. (Total number of participants), usually set as a fraction of the total number of participants. The system is based on Generate threshold signature key fragments to ensure dynamic thresholds. Always within the scope of key support ( ).

[0059] The specific steps to trigger a smart contract for fund distribution and settlement include: First, the system acquires signature fragments generated by participating nodes and aggregates and reconstructs these fragments. Specifically, after each node participating in the settlement completes a partial signature using its private key fragments, the system collects these valid signature fragments in real time. Once the number of collected valid signature fragments reaches or exceeds the adaptive signature threshold, the system uses the Lagrange interpolation algorithm to mathematically reconstruct these fragments, generating a complete aggregate signature that strictly corresponds to the current settlement data. This cryptographic approach merges the dispersed authorization intentions of multiple parties into a single legal or technical credential.

[0060] Secondly, the aggregated signature, adaptive signature threshold, and related revenue sharing data are packaged and encapsulated into a standard blockchain transaction structure and broadcast to the entire blockchain network. During this process, the adaptive signature threshold, as a key consensus rule parameter, is also uploaded to the blockchain, providing a clear basis for independent verification by each node in the network, ensuring the integrity and transparency of transaction information.

[0061] Subsequently, validator nodes in the blockchain network receive and parse the blockchain transactions, and perform cryptographic verification of the validity of the aggregated signature based on the threshold signature public key pre-stored in the blockchain ledger. The validator nodes not only verify the mathematical validity of the signature but also read the adaptive signature threshold carried in the transaction to determine whether the number of parties actually participating in the signing of the current aggregated signature meets the requirement of not less than that threshold. Only transactions authorized by a sufficient number of participants and conforming to the dynamic security policy can be accepted by the network.

[0062] Finally, if the verification node confirms that the aggregate signature is valid and meets the signature quantity requirement, the transaction is deemed to have passed consensus verification. At this point, the node will trigger a pre-set smart contract. The smart contract automatically executes the fund distribution operation according to the code logic and records the detailed data of this distribution, including the transaction hash, distribution amount, and participant information, into the distributed ledger, ultimately packaging it into an immutable data block. This process achieves automated execution of fund settlement and permanent storage of transaction evidence, thereby ensuring the security and traceability of fund distribution settlement without the need for a trusted third-party intermediary.

[0063] This invention also provides a blockchain-based revenue-sharing data management system. For example... Figure 2 As shown, the system includes a processor and a memory. The memory stores computer program instructions, which, when executed by the processor, implement a blockchain-based ledger data management method according to the first aspect of the present invention. The system also includes other components well-known to those skilled in the art, such as a communication bus and a communication interface; their configuration and functions are known in the art and will not be described further here.

[0064] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for managing split-ledger data based on blockchain technology, characterized in that, include: Obtain the multi-source business data set associated with the current transaction, and extract the key business feature vectors from each data source; Based on key business feature vectors, calculate the business multi-source data consistency index of multi-source business data sets; Obtain the basic credit information of the transaction participants, calculate the basic risk coefficient of the participants, and combine it with the business multi-source data consistency index to calculate and generate the comprehensive risk coefficient of this transaction; Based on the comprehensive risk coefficient of the transaction, an adaptive signature threshold is generated through a preset nonlinear mapping function. The blockchain threshold signature process is executed based on the adaptive signature threshold. After the signature verification is successful, the smart contract is triggered to perform fund distribution and settlement.

2. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The process of obtaining the business multi-source data consistency index includes: The key business feature vectors of each data source are matched pairwise, and the number of successfully matched data source pairs is counted. The ratio of the number of successfully matched data source pairs to the theoretical maximum number of matched pairs is calculated, and this ratio is used as a business multi-source data consistency indicator.

3. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The process of obtaining the basic risk coefficient of the participating entities includes: Determine the set of all corporate entities involved in the fund transfers in this transaction, and set the total number of periods for credit assessment tracing; Obtain the historical credit score sequence of each participating enterprise in the set over the past several assessment periods. The historical credit score is derived from the output of the credit assessment model that is updated in real time in the dynamic trusted data pool. Construct a time-weighted sequence, where the time weight of each evaluation period satisfies that the sum of the weights of all periods is 1. For each participating enterprise in the set, calculate the weighted credit score of the participating enterprise based on the historical credit score sequence and time-weighted sequence corresponding to each participating enterprise, and calculate the individual basic risk value of the participating enterprise using a normalization formula according to the maximum and minimum credit score preset by the system. Iterate through the individual basic risk values ​​of all participating companies in the set, and select the largest value as the basic risk coefficient of the participating entity in this transaction.

4. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The process of obtaining the overall risk coefficient of the transaction includes: The basic risk coefficients of the participating entities are numerically reverse-mapped to obtain the entity credibility coefficient, which represents the basic credibility level of the participating entities. The consistency degree of multi-source business data is weighted and fused with the entity credibility coefficient to obtain the transaction credibility index, which represents the overall credibility level of this transaction. The transaction credibility index is numerically reverse-mapped, and the mapping result is used as the comprehensive transaction risk coefficient for this transaction.

5. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The process of obtaining the adaptive signature threshold includes: The system sets a preset basic number of signers and a maximum number of signers allowed by the system. The basic number of signers serves as the minimum security threshold, and the maximum number of signers serves as the maximum security threshold. The maximum number of signers is less than the total number of participants. The overall transaction risk coefficient is mapped to a dynamic adjustment range consisting of the number of basic signers and the number of maximum signers, to obtain a continuous threshold variable that matches the current transaction risk level. The continuous threshold variable is discretized and rounded down, and the result is determined as the minimum number of signers required to trigger the split settlement, i.e., the adaptive signature threshold. The system generates threshold signature key fragments based on the maximum number of signers, ensuring that the adaptive signature threshold is always within the effective support range of the threshold signature mechanism.

6. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The steps for triggering the smart contract to perform fund distribution and settlement specifically include: Based on the adaptive signature threshold, collect the private key fragment signatures of the transaction participants; When the number of valid signatures collected is greater than or equal to the adaptive signature threshold, the final signature is synthesized and verified. The smart contract is invoked to execute the fund transfer based on the transaction amount in the multi-source business data set and the preset revenue sharing rules.

7. The method for managing split-ledger data based on blockchain technology according to claim 1, characterized in that, The process of executing a blockchain threshold signature based on the adaptive signature threshold, and triggering a smart contract for fund distribution and settlement after successful signature verification, includes: Obtain the signature fragments generated by the participating nodes that have reached the adaptive signature threshold, and reconstruct the signature fragments to generate an aggregate signature corresponding to the revenue sharing data; The aggregated signature, adaptive signature threshold, and ledger data are packaged into the blockchain transaction structure and broadcast to the blockchain network; Verification nodes in the blockchain network receive blockchain transactions and verify the validity of aggregate signatures based on the threshold signature public keys stored in the blockchain ledger. If the verification passes and the number of signers corresponding to the aggregated signature is not less than the adaptive signature threshold, the smart contract is executed to record the revenue sharing data into the distributed ledger and generate an immutable data block.

8. A blockchain-based revenue-sharing data management system, characterized in that, include: A processor and a memory, wherein the memory stores computer program instructions that, when executed by the processor, implement the blockchain-based ledger data management method according to any one of claims 1-7.

Images